Déployer un logiciel dans le commerce : ce que m’a appris un ERP mis en place en deux mois

Le premier système de gestion que j’ai mis en place, je l’ai construit à dix-neuf ans, seul, en deux mois environ. Avec le recul de vingt ans de déploiements depuis, presque rien de ce que j’ai réussi pendant ces deux mois ne tenait au code.

L’entreprise distribuait des journaux et des magazines par plus de cinquante kiosques répartis dans une ville. Livraisons, stock, invendus, un entrepôt, la gestion des espèces et les règlements avec les fournisseurs, le tout sur un produit dont la vie commerciale est d’une brièveté brutale. Un journal perd sa valeur plus vite que le lait, et chaque processus de cette entreprise était façonné par ce fait.

J’étais le seul programmeur. Un administrateur système m’a appris à décomposer un problème et à garder le code dans un certain ordre. Tout ce qui relevait de la mise en œuvre (parler aux gens, changer leur façon de travailler, faire adopter l’outil), je l’ai appris en me trompant devant tout le monde.

Cinquante kiosques, deux mois, et aucune idée que c’était déraisonnable

Il s’agissait de reprendre une base logicielle existante et de l’étendre aux opérations, au stock et aux espèces de toute l’entreprise. Ce qui me frappe aujourd’hui, c’est la manière dont le PDG s’y est pris. Dès les premières conversations, il parlait à un garçon de dix-neuf ans de processus métier, de la façon dont les services se passaient le travail, des endroits où l’information restait bloquée et de ce qui, selon lui, pouvait être mieux organisé. Pas de cahier des charges. L’activité.

Une partie de la réussite tient à une raison peu flatteuse : je n’en savais pas assez pour savoir que la tâche était déraisonnable. Un manager expérimenté aurait fait une analyse des risques, rédigé un plan, demandé une équipe et expliqué pourquoi deux mois, c’était presque impossible. Il aurait souvent eu raison. Ne pas mesurer la taille d’un problème fournit parfois une énergie qu’une personne correctement calibrée ne dépenserait jamais.

Ignorer à quel point une tâche est déraisonnable peut être une vraie source d’énergie. Ce n’est pas un plan, et cela ne survit pas au deuxième site.

Écrit la nuit, testé le matin

La méthode, si le mot convient, était la suivante : écrire un morceau la nuit, le mettre le matin entre les mains de vrais employés faisant un vrai travail, l’observer pendant la journée, trouver l’exigence que j’avais oubliée, recommencer. Quand je n’en pouvais plus, je dormais dans la salle des serveurs, maintenue à dix-huit degrés, ce qui se supporte à cet âge. Je ne pensais pas à un pilote ni à un déploiement par phases. J’appelais cela coder la nuit, lancer le matin, corriger dans la journée.

Des années plus tard, j’ai lu les travaux de Hackman et Oldham de 1976 sur la façon dont la conception du travail produit la motivation : l’autonomie, des résultats visibles, le sentiment que le travail compte et un retour immédiat. J’avais les quatre par accident, parce qu’il n’y avait personne d’autre pour les avoir. La distance entre une décision et sa conséquence était de quelques heures, et le retour venait de gens qui devaient vivre avec ce que j’avais livré. Il était rarement diplomate et jamais faux.

C’est l’argument le plus solide que je connaisse pour garder les équipes de déploiement près de l’opérationnel. Dans les grandes entreprises où j’ai travaillé ensuite, les services, les passations et les niveaux de validation étiraient cette distance à des semaines, et la qualité du retour se dégradait tout au long du chemin.

Pourquoi l’héroïsme cesse de fonctionner au deuxième site

Le système a été mis en service et a fini par tenir la comptabilité d’une entreprise de plus de cinquante kiosques et de plusieurs centaines de clients grossistes. J’ai reçu une prime de 300 dollars et je l’ai dépensée dans un vélo, ce qui, à dix-neuf ans, était une allocation de capital défendable. Le travail a continué après la mise en service : logique de réapprovisionnement, génération des bons de commande, recommandations pour la mise au rebut des invendus et, pour finir, un module d’entrepôt qui indiquait aux gens où aller. Un deuxième programmeur est arrivé et je suis devenu mentor sans avoir la moindre idée de la façon de l’être.

Ce qui m’amène à la correction que je ferais à mon moi de dix-neuf ans. La responsabilité personnelle porte un premier projet remarquablement loin, puis elle s’arrête. Aucune organisation ne devrait dépendre de la disposition d’une seule personne à renoncer au sommeil. Elle doit se transformer en processus, en documentation, en savoir détenu par plus d’une personne, et en systèmes qui continuent de tourner sans qu’on ait à les sauver. Le point voisin, propre à la couche de reporting, à savoir qu’elle ne peut pas être spécifiée une fois puis laissée en l’état pendant des années, fait l’objet de pourquoi votre reporting ne peut pas être un projet ponctuel.

Les questions qui disent si un déploiement a réussi

La tentation est de juger un déploiement selon qu’il a été livré conformément au plan et que l’ingénierie est propre. L’architecture compte, et une mauvaise architecture finit par devenir un problème pour l’activité, simplement sur une horloge plus lente. Mais une équipe technique ne peut pas se noter uniquement sur la qualité de son propre processus. Voici les questions que je pose à la place, un mois ou deux après la mise en service :

• Le taux d’erreurs a-t-il vraiment baissé, et le voit-on dans les données plutôt que dans les impressions ?
• Les gens terminent-ils le même travail plus vite, ou le travail est-il simplement passé à quelqu’un d’autre ?
• La direction reçoit-elle la même information plus tôt, ou seulement dans un format plus joli ?
• Le stock est-il plus lisible qu’avant, par site, par catégorie et par période ?
• Quelles étapes manuelles ont entièrement disparu, et lesquelles ont seulement changé de mains ?
• Une décision de gestion a-t-elle changé grâce au système, et pouvez-vous nommer cette décision ?

Si aucune de ces questions n’a de réponse, le système est en service. Ce n’est pas la même chose qu’être déployé, et c’est dans l’écart entre les deux que se perd l’essentiel de l’argent de ces projets.

Le logiciel devient une partie de l’activité, pas un outil à côté

Les travaux d’Eric Trist sur les systèmes sociotechniques, plus anciens que la plupart des logiciels dont nous débattons, le disent mieux que moi. Un nouveau système ne remplace pas seulement un outil. Il change les relations, qui décide de quoi, la façon dont la responsabilité est répartie, la confiance que les gens accordent à ce qu’ils ont sous les yeux et ce sur quoi ils finissent par se disputer.

Si les gens ne font pas confiance aux données de base, ne comprennent pas pourquoi le système recommande quelque chose ou passent une partie de chaque journée à le corriger, le dommage a quitté le logiciel pour entrer dans les relations de travail qui l’entourent. L’arrivée de l’IA a rendu cet argument plus aigu, pas plus doux. Une recommandation que personne ne peut examiner est un problème de confiance avant d’être un problème d’expérience utilisateur.

Ce que nous avons emporté dans marql

marql est une couche au-dessus des systèmes de caisse, de comptabilité et d’e-commerce qu’une chaîne de magasins, un groupe de restaurants ou un réseau de franchise utilise déjà : il les lit sans les remplacer, avec un hébergement dans l’UE. Ne remplacer ni la caisse ni l’ERP est un choix délibéré sur la part d’une activité qu’un seul déploiement devrait avoir le droit de perturber à la fois.

Notre engagement est volontairement étroit : une revue qualifiée de vos outils actuels, une première vue en direct sous 24 heures et des tarifs à partir de 200 € par mois. Ce sur quoi nous préférons être jugés, c’est la liste ci-dessus : est-ce qu’un directeur des opérations obtient une réponse plus tôt qu’avant, et est-ce que cela change quelque chose. Un exemple concret de ce que cela donne quand un chiffre dérape se trouve dans comment enquêter sur un écart d’inventaire.