Team KickAss: lavorare dove fa male
Con il nome di un supereroe, il team KickAss si è proposto di ottimizzare il processo di restituzione, lavorando dietro le quinte in un campo minato con un alto potenziale di esplosione.
Quando Daniel Gnägi sale sul tappeto del Brazilian Jiu Jitsu Dojo di Zurigo, non è l'unica lotta che il 24enne deve affrontare. In realtà, Daniel era un pugile dilettante con molto potenziale. Fino a quando un infortunio alla spalla lo ha costretto ad appendere i guantoni al chiodo. Per sempre.
Ma non solo: Daniel ha voltato le spalle alla sua casa nella Svizzera orientale dopo la laurea, perché il primo compito che attende l'ingegnere software junior dopo gli studi è a Zurigo ed è una battaglia che non può vincere: i resi.
Daniel è un membro del team KickAss.
«Non è affatto glorioso, ma lo facciamo con orgoglio», dice Daniel. È seduto su una poltrona, comodamente reclinata, e non parla né a voce alta né con noncuranza. Quando non rilascia interviste, scrive su una tastiera. La sua lingua non è il tedesco, ma il C#.
Fonte di preoccupazione di ogni rivenditore online
Quando Daniel parla del suo lavoro, per lui due cose in particolare sono importanti: non è il capo del team. E devi capire che i resi sono uno dei più grandi problemi di un rivenditore online. «Elaborazione backend dei resi e dei casi di garanzia» o «after sales» è il termine tecnico. Un argomento che i rivenditori temono. In un mondo ideale, tutti dovrebbero essere soddisfatti della merce ordinata.
«Pensaci dal punto di vista di digitec», dice e comincia.
Tu come cliente compri qualcosa su Galaxus. Per qualche motivo è rotto. Quindi deve tornare indietro. O si va in una delle nove filiali o si rispedisce il pacco per posta. Anche qui, un processo deve avere già due variabili se si considera «prodotto difettoso» e non «cellulare: schermo rotto» oppure «cellulare: fotocamera rotta». Perché due variabili dovrebbero essere in grado di reagire a due variabili.
Da allora in poi, per un momento diventa più facile: il dispositivo viene restituito all'After Sales Handling. Dal negozio con i camion, oppure dall'ufficio postale. Poi diventa di nuovo più complesso. Il danno deve essere valutato. Il dispositivo è ancora recuperabile? Poi a uno degli oltre 2000 fornitori con cui lavora Digitec Galaxus. I percorsi postali, i termini di consegna, le condizioni di consegna, i requisiti burocratici per una consegna di ritorno e così via determinano la vita quotidiana del reparto after sales.
Da qualche parte nel sistema, tutto questo deve essere intercettato, preso in considerazione ed elaborato. Tracciabile, efficiente e automatizzato il più possibile.
«Consegniamo sempre più merce, quindi sempre più merce viene restituita», dice Daniel.
Ecco perché sembra che lui e KickAss non possano vincere questa lotta. Perché non importa quanto semplice diventi il processo, quanto più efficiente e veloce: non c'è meno lavoro negli uffici e nei magazzini dell'azienda. E nessuno è contento di niente.
KickAss prende il lavoro
«Molte cose venivano ancora risolte manualmente», dice Daniel e sospira quando pensa agli inizi del suo team, che sono stati anche gli inizi della sua vita professionale e del suo lavoro presso Digitec Galaxus.
Daniel si candida come Solution Architect. Volontariamente. E ottiene il lavoro. O meglio: il ruolo. Daniel Gnägi comincia il suo lavoro. È la prima iniziativa di Kickass.
Sulla sua maglietta leggo «Working Class Hero». In un team di sette Software Engineer e un Product Owner, cerca di rendere l'elaborazione dei resi il più indolore possibile.
La lotta inizia con l'analisi dei processi già in atto. KickAss non crede nel taglio dei posti di lavoro: se Galaxus continuerà a crescere, anche i resi aumenteranno. Tutti sono necessari.
«La quantità di lavoro manuale per il processo dei resi era scioccante», dice Daniel.
Ottimizzare i processi sulla base di qualche piccolo errore non funziona. Il problema deve essere sistemico perché l'ottimizzazione del processo abbia senso. È necessaria un'analisi approfondita. Un problema è aneddotico – accade solo una volta ma in modo spettacolare – o è sistematico e accade ogni volta che il processo viene eseguito?
«Ancora più generale: prima abbiamo dovuto capire il senso di ogni parte del processo».
Sorgono domande su domande
Le analisi dei requisiti devono essere precise. Proprio come la valutazione delle nuove tecnologie. Includere semplicemente uno script qui o infilare qualche riga lì perché sembra divertente al momento non funziona. Perché alla fine, la soddisfazione di tutti dipende dal lavoro del team. I clienti dovrebbero avere a che fare con i resi per il minor tempo possibile. Lo stesso vale per il personale dell'azienda. I fornitori e i centri di riparazione devono ricevere tutti i dati di cui hanno bisogno. Il tutto in un formato che gli convenga, e alla fine il tutto deve essere compatibile con i backend sia di Digitec Galaxus che di terze parti.
Nel mezzo, le fasi e gli elementi superflui del processo devono essere eliminati. Meno fasi di processo inutili («busywork» in gergo tecnico) ci sono, meglio è.
Da tutto questo emerge una bozza di architettura. Questa passa poi attraverso una revisione. Funziona tutto? Dove sono gli ostacoli? Cosa potrebbe andare storto dopo? Abbiamo bisogno di tutto questo? Occorre altro?
Respiro profondo.
Attuazione pratica. Nuove tecnologie? Forse? Mantengono ciò che promettono? Sono compatibili con noi? Con altri?
Le domande si accumulano. Daniel e KickAss affrontano storia per storia, sprint per sprint. Uno dopo l'altro.
«Per quanto possa sembrare tedioso, in realtà è stato molto interessante e divertente».
La ricerca, lo scavo e l’indagare, la discussione sulle soluzioni e il pensiero che KickAss sono i primi e gli unici a dedicarsi solo a questo argomento: questi sono gli elementi a cui Daniel si rivolge quando parla di divertimento.
Iniziamo. Codice qui, una maschera nel backend dell'azienda là, Daniel e KickAss automatizzano quello che possono. Il processo diventa più snello, più veloce e più potente. KickAss continua a sviluppare il suo motore interno del Workflow in .NET. Lo adatta dove necessario, lo integra nel processo dei resi. Il busywork viene gradualmente abolito. Tutto questo viene messo alla prova. Gli eventi vengono inviati all'Azure Service Bus in ogni fase del processo in modo che i dati possano essere valutati in seguito. Ogni singolo passo è testato automaticamente usando test unitari basati su NUnit. Tutti i processi e i diagrammi sono documentati in LucidChart.
Alla fine, KickAss può rilassarsi. O prendere il go-kart del dipartimento per un giro intorno all'ufficio. Perché il processo è in atto, testato, scalabile e pronto per il rollout.
C'è sempre qualcosa da ottimizzare. KickAss continua a combattere.
Giornalista. Autore. Hacker. Sono un contastorie e mi piace scovare segreti, tabù, limiti e documentare il mondo, scrivendo nero su bianco. Non perché sappia farlo, ma perché non so fare altro.
Novità sulle funzionalità del negozio, informazioni dal marketing o dalla logistica e molto altro ancora.
Visualizza tutti
