La maintenance de l'optimisation

Joannes Vermorel

Les frais facturés par Lokad à ses clients entreprises sont simples[^fees] : un forfait mensuel fixe pour un mélange de logiciels+experts¹. À la surprise de certains, nos frais mensuels ont tendance à rester stables au fil du temps, plutôt que de diminuer brusquement à la fin de la phase de mise en service. Cependant, la plupart ne sont pas surpris, car faire face à une démonstration absurde de cupidité de la part d’un fournisseur est juste un autre lundi dans le monde des logiciels d’entreprise. Cependant, il ne s’agit pas d’une démonstration classique de cupidité effrénée. Ces frais sont nécessaires pour atteindre des performances durables de la supply chain.

Le chemin le plus rentable pour les fournisseurs de logiciels d’entreprise est, et a toujours été, de “prendre l’argent et de partir”. Les frais de licence initiaux équivalent à imprimer de l’argent. Comparée à la licence, l’intégration est plus ardue. Les risques sont plus élevés et les marges plus minces. Par conséquent, les grands fournisseurs sous-traitent généralement entièrement cette partie en cultivant un réseau d’intégrateurs qui peuvent prendre la chaleur à leur place. Cependant, la partie la moins rentable, du point de vue du fournisseur, est - de loin - la maintenance. De manière anecdotique, c’est pourquoi les fournisseurs, malgré des frais de maintenance importants, imposent toujours des mises à jour à leurs clients. Les frais de maintenance, bien qu’importants, sont loin de ce qu’il faudrait pour que le fournisseur supporte son propre héritage.

L’optimisation de la supply chain est un cas particulier, cependant, car les fournisseurs (pas Lokad) ont “réussi” à éliminer la maintenance. Cette “réussite”, cependant, n’est certainement pas celle que leurs clients avaient envisagée.

Depuis les années 1980, les fournisseurs (comme Lokad, mais des décennies plus tôt) fournissent des logiciels pour automatiser les décisions de la supply chain[^decisions]. Depuis lors, presque toutes les grandes entreprises ont acquis non pas une, mais souvent plusieurs de ces solutions. Même les ERP, ce qui signifie Enterprise Resource Planning, ont été nommés ainsi dans les années 1990 en raison de cette ambition d’automatiser la partie “planification”. Sinon, les ERP seraient appelés ERM, ce qui signifierait Enterprise Resource Management.

Pourtant, l’automatisation des décisions de la supply chain ne s’est pas produite. Les systèmes ont été déployés, mais ils sont soit couverts de poussière, soit évitent leur mission initiale[^spreadsheets]. En conséquence, la grande majorité des supply chains sont encore gérées via des feuilles de calcul, prouvant que même si ces solutions d’optimisation étaient initialement considérées comme un succès, quelque chose s’est mal passé avec la maintenance.

Ces échecs sont rentables pour les éditeurs de logiciels. L’éditeur repart avec les frais de licence, éventuellement sous la forme d’un engagement pluriannuel (dans le cas du SaaS). Étant donné que les solutions ne fonctionnent pas - du moins pas la partie optimisation - peu ou pas de maintenance est nécessaire. Les clients ne se soucient pas des fonctionnalités logicielles qu’ils n’utilisent de toute façon pas, et par conséquent, ils ne mettent pas beaucoup de pression sur l’éditeur. De la solution initiale, seul un fragment reste en cours d’utilisation - généralement, une passerelle de saisie de données légère pour gérer les règles d’automatisation de base intégrées aux systèmes de l’entreprise (par exemple, les paramètres min/max pour les SKUs).

À l’autre extrémité du spectre, Lokad réussit à fournir des décisions automatisées de la supply chain de qualité industrielle. Cependant, cela nécessite des efforts continus d’une équipe dédiée au client - les scientifiques de la supply chain dans le jargon de Lokad - pour que cela se produise. Le scientifique est chargé de concevoir, puis de maintenir, la recette numérique qui génère les décisions de la supply chain d’intérêt.

La recette numérique résultante peut être laissée sans surveillance. C’est, en gros, ce que signifie l’automatisation “de qualité industrielle” dans le contexte de l’optimisation de la supply chain. Ainsi, le scientifique de la supply chain peut être retiré de l’équation à tout moment sans causer de préjudice à l’entreprise.

Cela dit, la supply chain est une bête en constante évolution, ce qui entraîne naturellement des effets en cascade. Bien que nos algorithmes puissent gérer les flux qui changent en magnitude, nous n’avons pas encore d’algorithmes qui peuvent gérer tous les autres changements subtils nécessaires pour maintenir la recette numérique de qualité industrielle.

En conséquence, les scientifiques de la supply chain se retrouvent avec une série de tâches à accomplir une fois que Lokad est en production:

• De nouvelles données deviennent disponibles[^newdata], et la recette numérique doit être mise à jour pour tirer parti de ces nouvelles données. À l’inverse, certaines sources de données sont abandonnées et les dépendances numériques doivent être rompues en conséquence. Dans les grandes entreprises, le paysage applicatif évolue constamment, pas seulement lors de la mise à niveau de l’ERP.

• La stratégie de l’entreprise change. La recette numérique est le reflet de l’intention stratégique du client, et ce reflet va beaucoup plus loin que le choix des valeurs pour quelques paramètres. Il n’est pas rare que le scientifique de la supply chain réécrive des parties entières de la recette pour tenir compte des inflexions de la stratégie, mais cela arrive occasionnellement.

• La confiance doit être maintenue. La direction de la supply chain a besoin que le scientifique de la supply chain fournisse des preuves continues que la recette numérique se comporte bien. On attend du scientifique non seulement qu’il produise de nouveaux instruments pour refléter les indicateurs de performance réactualisés, mais aussi qu’il réponde à toutes les questions que la direction pourrait poser.

• La transparence doit être maintenue. Le scientifique est responsable de la “mise en boîte blanche” de la recette numérique. Cela implique de former les équipes pour qu’elles aient un niveau de compréhension adéquat, ce qui leur permet à leur tour de tirer le meilleur parti de l’automatisation fournie par la recette numérique. Lorsque les équipes changent, les nouveaux arrivants doivent être (re)formés.

Si nous échouons dans l’une de ces tâches, les praticiens de la supply chain n’ont d’autre choix que de revenir à leurs feuilles de calcul.

Par conséquent, bien que la recette numérique puisse être laissée sans surveillance pendant des semaines[^sans_surveillance], sa pertinence se dégrade invariablement avec le temps. Ainsi, des ressources d’ingénierie continues sont nécessaires pour maintenir la pertinence de la recette numérique. Malgré les progrès récents en matière d’intelligence artificielle[^intelligence_artificielle], l’ingénierie d’un logiciel capable d’auto-maintenance reste bien au-delà de l’état actuel de l’art. C’est peut-être controversé à écrire, mais la tâche semble aussi difficile que le défi de parvenir à une intelligence artificielle générale.

Bien que les contributions continues du scientifique de la supply chain soient nécessaires, on pourrait pardonner de penser que ces efforts diminueront une fois que la recette numérique sera en production. Notre expérience a prouvé le contraire. La complexité de la recette numérique s’étend invariablement pour correspondre au niveau de ressources d’ingénierie disponibles².

Au cours de la dernière décennie, nous avons observé à plusieurs reprises un point de basculement en ce qui concerne l’investissement en ressources. Si les ressources initiales investies dans la configuration de la recette³ dépassent ce que l’entreprise prévoit d’investir chaque année dans sa maintenance, alors la recette ne reçoit pas le niveau de soin nécessaire pour préserver son statut de production. Le symptôme le plus fréquent de cette négligence est un retard prolongé pour toutes les pièces importantes, mais pas immédiatement critiques : documentation, revues de code, nettoyage du code, instrumentation, etc.

Aucune technologie ou processus ne garantit le succès commercial[^succes], mais une maintenance inappropriée est une recette éprouvée pour ramener une entreprise à la case départ - avant de la noyer sommairement dans une mer de feuilles de calcul. Ne laissez pas votre entreprise devenir un autre point de données dans notre registre croissant d’échecs de la supply chain parfaitement évitables.