
Dans les coulisses
Lego et iPhone : les plus fréquentes recherches de la clientèle
par Manuel Wenk
Nommée d'après un superhéros, l'équipe KickAss a entrepris d'optimiser le processus de retour. Ils travaillent en coulisses dans un champ de tensions qui a un fort potentiel explosif.
Lorsque Daniel Gnägi monte sur le tapis du Brazilian Jiu-Jitsus Dojo à Zurich, ce n'est pas le seul combat que le jeune homme de 24 ans dispute. Daniel a été boxeur amateur avec beaucoup de potentiel. Jusqu'à ce que son épaule soit en trop mauvais état et qu'il a dû arrêter. Pour toujours.
Mais pas seulement : Daniel a tourné le dos à sa région natale de Suisse orientale après ses études, car à Zurich, la première tâche qui attend le Junior Software Engineer après l'obtention de son diplôme est un combat qu'il ne peut pas gagner : les retours.
Daniel est un membre de l'équipe KickAss.
« Ce n'est pas glorieux, mais nous le faisons avec fierté », dit Daniel. Il est confortablement assis dans un fauteuil, il n'hausse pas la voix et parle de manière réfléchie. Quand il ne donne pas d'interviews, il tape des choses au clavier. Sa langue de prédilection n'est pas l'allemand, mais le C#.
Lorsque Daniel parle de son travail, deux choses sont importantes pour lui : d'une, il n'est pas le chef de l'équipe et de deux les retours sont l'un des plus gros problèmes d'un détaillant en ligne. « Traitement back-end des retours et des cas de garantie » ou « après-ventes », est le terme utilisé dans le jargon. Un sujet sur lequel les détaillants essaient d'attirer le moins d'attention possible. Dans un monde idéal, tout le monde devrait être satisfait de la marchandise commandée.
« Pensez-y du point de vue de digitec », dit-il.
Vous achetez quelque chose sur Galaxus en tant que cliente ou client. Le produit vous parvient cassé, pour une raison quelconque. Le produit doit donc être retourné. Soit vous vous rendez dans l'une des neuf succursales, soit vous renvoyez le colis. Un processus doit déjà prendre en compte deux variables, si vous considérez le sinistre comme un « sinistre » et non comme une chose indépendante comme « téléphone portable : écran cassé » et « téléphone portable appareil photo cassé ». En effet, il faudrait alors que deux variables puissent réagir à deux variables.
À partir de là, les choses deviennent brièvement plus faciles : l'appareil retourné est renvoyé à l'After Sales Handling. De la succursale avec des camions, sinon la poste. Ensuite, les choses redeviennent plus complexes. Le dommage doit être expertisé. L'appareil peut-il encore être sauvé ? Puis envoyé à l'un des plus de 2000 fournisseurs avec lesquels Digitec Galaxus collabore. Les voies postales, les délais de livraison, les conditions de livraison, les exigences en matière des documents d'une livraison de retour et ainsi de suite déterminent le quotidien du service après-vente.
Quelque part, tout cela doit être intercepté, pris en compte et traité par le système. Si possible de manière traçable, efficace et le plus automatisé possible.
« Nous livrons de plus en plus de marchandises, il y a donc de plus en plus de retours », explique Daniel.
C'est pourquoi ce combat semble être celui que lui et KickAss ne peuvent pas gagner ; quelle que soit la simplicité du processus, quelle que soit son efficacité et sa rapidité : il n'y aura pas moins de travail dans les bureaux et les entrepôts de l'entreprise. Et personne n'est heureux de quoi que ce soit.
« Beaucoup de choses étaient encore résolues manuellement », dit Daniel en soupirant lorsqu'il repense aux débuts de son équipe, qui étaient aussi les débuts de sa vie professionnelle et de son travail chez Digitec Galaxus.
Daniel se présente en tant que Solution Architect. Et obtient le poste. Ou encore mieux, le rôle. Daniel Gnägi prend ses fonctions. C'est la première initiative de Kickass.
« Working Class Hero » est inscrit sur son t-shirt. Au sein d'une équipe de sept ingénieurs logiciels et d'un Product Owner, il essaie de rendre le traitement des retours aussi indolore que possible.
La lutte commence par l'analyse des processus déjà en place. KickAss ne croit pas à la suppression des postes. Car si Galaxus doit continuer à se développer, les retours vont également augmenter. Tout le monde réfléchit.
« La quantité de travail manuel impliquée dans les processus de retour était tout de même impressionnante », explique Daniel.
Daniel et KickAss revoient un bon nombre de choses. En effet, optimiser les processus sur la base de quelques petites mésaventures ne fonctionne pas. Le problème doit être systémique pour qu'une optimisation des processus ait un sens. Une analyse approfondie est nécessaire. Est-ce que le problème est anecdotique, c'est-à-dire qu'il ne se produit qu'une seule fois, mais de manière spectaculaire, ou est systémique et se produit à chaque fois que le processus est en cours ?
« De manière encore plus générale : nous avons d'abord dû travailler sur ce que veut exactement tel ou tel service dans le processus. »
Les analyses d'exigences doivent être bien faites. Tout comme l'évaluation de nouvelles technologies. Il ne suffit pas d'intégrer un script par-ci ou de rajouter quelques lignes par-là parce que cela semble amusant. Au final, la satisfaction de tous dépend du travail de l'équipe. Les clients devraient avoir affaire à des retours le moins longtemps possible. Les employés de l'entreprise aussi. Les fournisseurs et les services de réparation doivent recevoir toutes les données dont ils ont besoin, et rien de plus. Le tout dans un format qui leur convient, et à la fin, tout cela doit encore être compatible avec les back-ends aussi bien de Digitec Galaxus que de tiers.
Entre les deux, les étapes et les éléments du processus superflus doivent être supprimés. Moins il y a de « busywork », c'est-à-dire d'étapes inutiles, mieux c'est.
De tout cela naît un projet d'architecture. Celle-ci passe ensuite par une révision. Est-ce que tout fonctionne ? Où sont les écueils à éviter ? Qu'est-ce qui pourrait devenir fatal à l'avenir ? Est-ce que tout cela est nécessaire ? Faut-il plus ?
Respirer profondément,
penser à une mise en œuvre pratique. De nouvelles technologies ? Peut-être ? Est-ce qu'elles tiennent leurs promesses ? Sont-elles compatibles avec nous ? Avec des tiers ?
Les questions s'accumulent. Daniel et KickAss les travaillent story après story, sprint après sprint, l'une après l'autre.
« Aussi nul que cela puisse paraître, c'était en fait très passionnant et amusant. »
La recherche, le fait de creuser et de chercher, la discussion pour trouver des solutions et l'idée que KickAss est le premier et le seul à se consacrer uniquement à ce thème : ce sont les éléments auxquels Daniel fait allusion lorsqu'il parle de plaisir,
au travail. Du code par-ci, un masque dans le back-end de l'entreprise par-là, Daniel et KickAss automatisent tout ce qu'ils peuvent. Le processus devient plus simple, plus rapide et plus performant. KickAss poursuit le développement de son propre moteur de workflow en .NET. L'adapte si nécessaire, l'intègre dans le processus de retour qu'il domine alors. Le busywork est progressivement supprimé. Tout cela est testé. Les événements sont envoyés au bus de services Azure à chaque étape du processus afin de pouvoir évaluer les données ultérieurement. Chaque étape est testée automatiquement au moyen de tests unitaires basés sur NUnit. Tous les processus et diagrammes sont documentés dans LucidChart.
Au final, KickAss peut se reposer. Ou faire un tour au bureau avec le karting driftant du département, car le processus est en place, testé, évolutif et prêt à être déployé.
Il y a toujours quelque chose à optimiser. KickAss continue de se battre.
Journaliste. Auteur. Hackers. Je suis un conteur d'histoires à la recherche de limites, de secrets et de tabous. Je documente le monde noir sur blanc. Non pas parce que je peux, mais parce que je ne peux pas m'en empêcher.