Tombez amoureux du problème, pas de la solution
Chaque SKU appelle à des décisions quotidiennes banales, telles que l’ajout de stock ou le changement du prix sous-jacent. Naturellement, le fait de s’en tenir à un processus entièrement manuel pour ces décisions est intensif en main-d’œuvre, et les entreprises adoptent des solutions d’automatisation basées sur des logiciels variés. La stratégie de conception la plus courante pour ces solutions consiste à tenter de reproduire - à travers des logiciels - quelque chose d’essentiellement similaire à la pratique “humaine” existante.
Cette approche n’est pas nouvelle. On pourrait même dire que c’était la perspective mise en avant par les systèmes experts qui sont tombés en disgrâce pendant le deuxième hiver de l’IA à la fin des années 1980 et au début des années 1990. Pourtant, bien que le terme à la mode “systèmes experts” n’existe plus - je ne pense pas qu’il y ait encore un (important) fournisseur de logiciels qui se présente comme un fournisseur de “systèmes experts” de nos jours - je ne peux m’empêcher de remarquer que la perspective sous-jacente reste prédominante dans la plupart des secteurs.
En effet, la plupart des fournisseurs de logiciels, ainsi que la plupart des initiatives internes, restent bloqués dans la perspective de reproduire la pratique existante, qui elle-même a émergé en imitant le processus entièrement manuel d’origine. Le système expert d’autrefois a peut-être été remplacé par un algorithme d’apprentissage profond plus moderne, mais le paradigme d’ensemble reste (presque) inchangé.
Dans la supply chain, ce schéma est frappant car presque toute la pratique reste bloquée sur des approches qui ont émergé dans un monde où les ordinateurs n’existaient tout simplement pas encore. Par exemple, de nombreuses - la plupart - des entreprises distinguent encore l’équipe de “planification”, les personnes qui établissent les prévisions de demande pour chaque produit, de l’équipe d’approvisionnement, les personnes qui passent les commandes d’achat en fonction des prévisions de demande. Cette approche est issue d’une perspective tayloriste où les employés devaient être aussi spécialisés que possible afin d’être performants au maximum dans leur travail.
Pourtant, en ce qui concerne l’optimisation de la supply chain, le taylorisme est en contradiction avec la réalité de la supply chain. La réalité dicte que la demande future n’est pas indépendante des décisions actuelles. Si une commande d’achat beaucoup plus importante est passée - ce qui entraîne un prix d’achat unitaire beaucoup plus bas - le prix de vente peut également être réduit, ce qui peut potentiellement concurrencer le marché et donc augmenter considérablement la demande. Dans un monde sans ordinateurs, le taylorisme était l’option la moins mauvaise car, bien qu’il ne soit pas très efficace, il était extrêmement évolutif. Cependant, dans un monde avec des ordinateurs, la situation appelle à une approche plus intégrée qui tient compte, même de manière rudimentaire, de ces rétroactions. Comme dit le dicton, il vaut mieux être approximativement juste qu’exactement faux.
Lorsqu’on interroge les clients ou les prospects à ce sujet, la situation est souvent floue. Les solutions - initialement conçues pour reproduire un processus purement manuel - sont en place depuis si longtemps que les gens ont perdu de vue les aspects plus fondamentaux du problème qu’ils essaient de résoudre. Trop souvent, les gens sont devenus des spécialistes de la solution en place, plutôt que de devenir des spécialistes du problème auquel l’entreprise est confrontée. Ainsi, lorsqu’ils essaient d’améliorer la situation, toutes les réflexions sont littéralement ancrées dans ce qui est perçu comme les défauts de la solution actuelle. En raison de ce biais, les approches qui revisitent le problème en profondeur sont perçues comme risquées tant par la direction que par leurs équipes. En revanche, l’option d’améliorer progressivement la solution existante est considérée comme sûre; ou du moins beaucoup plus sûre.
En regardant en arrière, l’histoire des logiciels d’entreprise est malheureusement remplie d’histoires de fournisseurs imposant leur “nouvelle façon” de faire les choses, qui se sont révélées beaucoup plus fastidieuses et beaucoup plus rigides que les processus anciens; ne générant aucun gain de productivité, voire même des pertes. De manière anecdotique, j’observe que la plupart des entreprises qui exploitent de grandes chaînes d’approvisionnement n’ont pas réduit de manière substantielle leur effectif de cols blancs - soutenant leurs chaînes d’approvisionnement - au cours des deux dernières décennies, tandis que les cols bleus ont été automatisés de manière agressive grâce à de meilleures usines ou de meilleurs entrepôts. Ces événements malheureux ont injecté une bonne dose de scepticisme dans l’écosystème contre ces “réorganisations” épuisantes dans le seul but de se conformer à une nouvelle solution logicielle.
Cependant, je constate également que les cadres de la supply chain sous-estiment généralement largement les risques associés à tout logiciel “intelligent” - c’est-à-dire tout logiciel dont la correction ne peut pas être entièrement et clairement spécifiée. En effet, la plupart des logiciels d’entreprise ne sont rien de plus que des applications CRUD, c’est-à-dire des comptables diligents de listes banales telles que: factures, fournisseurs, produits, paiements, etc.
Réussir dans les affaires avec un logiciel “bête” est déjà assez difficile - de nombreuses entreprises de commerce électronique ont déjà du mal à maintenir une bonne disponibilité de leur interface web - mais chaque fois que des composants de logiciel pointilleux tels que l’apprentissage automatique sont impliqués, la réussite devient beaucoup plus difficile. Peu d’entreprises communiquent ouvertement sur ce sujet, mais chaque fois que l’apprentissage automatique est impliqué, les échecs dominent le domaine. Cependant, la situation n’est pas aussi sombre qu’il n’y paraît, car les inconvénients sont limités, tandis que les avantages ne le sont pas.
Ainsi, à long terme, les entreprises qui essaient et échouent le plus sont aussi celles qui réussissent le plus.
Néanmoins, les risques liés aux logiciels sont bien réels, et il n’y a certainement aucun intérêt à accroître ces risques encore davantage. Cependant, s’en tenir au paradigme de la reproduction d’une pratique manuelle désormais obsolète entraîne inévitablement une série de complications accidentelles. Par exemple, lorsque l’équipe de planification et l’équipe d’approvisionnement sont distinctes, toute une série de problèmes émergent dans le seul but de maintenir ces équipes synchronisées. En règle générale dans le développement de logiciels, augmenter les exigences de 25% augmente les coûts de 200%. La résolution de ces complications augmente considérablement les coûts, et donc en pratique le risque, car les entreprises ont tendance à mettre fin - une réaction saine - aux initiatives qui font exploser leur budget ou leurs délais.
Ainsi, lorsqu’il s’agit de répondre à la question vieille de cinquante ans de savoir s’il faut adapter le logiciel à l’organisation ou adapter l’organisation au logiciel, il est sage de partir de la feuille blanche sur le plan intellectuel, et de d’abord déterminer quels sont les problèmes de haut niveau qui doivent être résolus. La performance est-elle mesurée en pourcentage ? Ou en dollars ? Tenons-nous correctement compte des implications à long terme ? Comme habituer les clients à n’acheter que pendant les soldes. L’approche capitalise-t-elle sur les contributions humaines ou se contente-t-elle de les consommer ? La pratique est-elle motivée par des habitudes ou par une nécessité impérieuse ? Comme deux collections de mode par an, contre deux récoltes par an.
La compréhension intime du problème à résoudre - qui différencie clairement le problème lui-même de sa solution actuelle - est la clé pour déterminer si la solution existante vaut la peine d’être conservée, ou si elle doit être simplifiée à mesure que de nouvelles capacités logicielles appellent à une résolution plus simple et plus directe du problème.
