La maintenance de l'optimisation

Joannes Vermorel

Les frais que Lokad facture à ses clients d’entreprise sont simples¹: un tarif mensuel fixe pour un ensemble de logiciels+experts². À la surprise de certains, nos frais mensuels tendent à rester constants dans le temps, plutôt que de diminuer brusquement à la fin de la phase d’intégration. La plupart ne sont pas surpris, cependant, car être confronté à une démonstration ridicule d’avidité de la part d’un fournisseur n’est qu’un lundi de plus dans le monde du enterprise software. Cependant, il ne s’agit pas d’une vitrine théorique d’avidité démesurée. Au contraire, ce tarif est ce qu’il faut pour obtenir une supply chain performance durable.

Le chemin le plus rentable pour les fournisseurs de enterprise software est, et a toujours été, take the money and run. Les frais de licence initiaux sont comparables à de l’impression de billets. Par rapport à la licence, l’intégration est plus ardue. Les risques sont plus élevés et les marges plus fines. En conséquence, les grands fournisseurs externalisent généralement cette partie en cultivant un réseau d’intégrateurs capables d’encaisser les coups pour leur compte. 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 conséquents, obligent encore leurs clients à procéder à des mises à niveau. Les frais de maintenance, bien qu’ils soient importants, ne sont même pas proches de ce qu’il faudrait pour permettre au fournisseur de supporter son propre héritage.

L’optimisation de la supply chain est un cas particulier, cependant, car les fournisseurs (et non Lokad) ont « réussi » à éliminer la maintenance. Ce « succès » n’est toutefois certainement pas celui que leurs clients avaient envisagé.

Depuis les années 1980, les fournisseurs (comme Lokad, mais des décennies auparavant) fournissent des logiciels pour automatiser les décisions de supply chain³. Depuis, presque toutes les grandes entreprises ont acquis, non pas une mais souvent plusieurs de ces solutions. Même les ERP, c’est-à-dire Enterprise Resource Planning, tirent leur nom des années 1990, en raison de cette ambition d’automatiser la partie « planification ». Sinon, les ERP auraient été nommés ERM, signifiant Enterprise Resource Management.

Pourtant, l’automatisation des décisions de supply chain ne s’est pas concrétisée. Les systèmes ont été déployés, mais ils ne font qu’accumuler la poussière ou éludent leur mission initiale⁴. En conséquence, la grande majorité des supply chains est toujours gérée via des spreadsheets, prouvant que, même si ces solutions d’optimisation étaient initialement considérées comme un succès, quelque chose s’est mal passé au niveau de la maintenance.

Ces échecs sont rentables du point de vue des fournisseurs de logiciels. Le fournisseur emporte 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 requise. Les clients ne se préoccupent pas des fonctionnalités logicielles qu’ils n’utilisent pas de toute façon, et par conséquent, ils ne mettent pas trop de pression sur le fournisseur. De la solution originale, seul un fragment reste en usage – généralement, une passerelle de saisie de données minimale pour gérer des règles de base d’automatisation intégrées aux systèmes de l’entreprise (par exemple, les réglages min/max pour les SKU).

À l’autre bout du spectre, Lokad réussit à fournir des décisions de supply chain automatisées de qualité production. Toutefois, cela nécessite des efforts continus d’une task force dédiée au client – les supply chain scientists dans le parlance de Lokad – pour que cela se réalise. Le scientist est chargé de concevoir, puis de maintenir, la recette numérique qui génère les décisions de supply chain d’intérêt.

La recette numérique résultante peut être laissée sans surveillance. C’est, en quelque sorte, ce que signifie l’automatisation de qualité production dans le contexte de l’optimisation de la supply chain. Ainsi, le supply chain scientist peut être retiré de l’équation à tout moment sans nuire à l’entreprise.

Cela dit, la supply chain est une bête en constante évolution, ce qui entraîne naturellement des effets d’entraînement. Bien que nos algorithmes puissent gérer des flux changeant en ampleur, nous ne disposons pas encore d’algorithmes capables de traiter toutes les autres évolutions subtiles nécessaires pour maintenir la recette numérique de qualité production.

En conséquence, les supply chain scientists se retrouvent avec une série de tâches qui doivent être traitées une fois que Lokad est en production:

• De nouvelles données deviennent disponibles⁵, 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 retirées, et les dépendances numériques doivent être rompues en conséquence. Dans les grandes entreprises, le paysage applicatif est en constante évolution, 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 bien au-delà du simple choix des valeurs pour quelques paramètres. Il n’est pas courant que le supply chain scientist réécrive des portions entières de la recette pour accommoder les inflexions de la stratégie, mais cela arrive occasionnellement.

• La confiance doit être maintenue. La direction de la supply chain a besoin que le supply chain scientist fournisse des preuves continues que la recette numérique se comporte correctement. On s’attend à ce que le scientist produise non seulement de nouveaux outils d’instrumentation pour refléter des indicateurs de performance nouveaux ou révisés indicators, mais également qu’il réponde à toute question que la direction pourrait poser.

• La transparence doit être assurée. Le scientist est responsable de la mise en « white-boxing » de la recette numérique. Cela implique de former les équipes afin qu’elles disposent d’un niveau de compréhension suffisant, ce qui leur permet de tirer pleinement parti de l’automatisation fournie par la recette numérique. Au fur et à mesure de la rotation des équipes, les nouveaux arrivants doivent être (re)formés.

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

Ainsi, bien que la recette numérique puisse être laissée sans surveillance pendant des semaines⁶, sa pertinence se dégrade inévitablement avec le temps. En conséquence, des ressources d’ingénierie continues sont nécessaires pour maintenir la recette numérique pertinente. Malgré les récents progrès en artificial intelligence, concevoir un logiciel capable de se maintenir par lui-même reste bien au-delà de l’état actuel de l’art. Il est peut-être discutable d’écrire cela, mais la tâche apparaît aussi difficile que le défi d’atteindre une intelligence artificielle générale.

Bien que des contributions continues du supply chain scientist soient nécessaires, on pourrait se croire en droit de penser que ces efforts diminueraient une fois la recette numérique en production. Notre expérience a prouvé le contraire. La complexité de la recette numérique s’accroît invariablement pour correspondre au niveau de ressources d’ingénierie disponible⁷.

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

Aucune technologie ni processus ne garantit le succès commercial⁹, mais une maintenance inappropriée est une recette éprouvée pour ramener une entreprise à la case départ - avant de l’engloutir sommairement dans une mer de spreadsheets. Ne laissez pas votre entreprise devenir une autre donnée dans notre registre croissant d’échecs de supply chain parfaitement évitables.