Tombez amoureux du problème, pas de la solution
Chaque SKU nécessite des décisions quotidiennes banales, telles que le réapprovisionnement en stocks ou la modification de l’étiquette de prix sous-jacente. Naturellement, s’en tenir à un processus entièrement manuel pour ces décisions est très chronophage, et les entreprises ont adopté diverses solutions d’automatisation basées sur le logiciel. La stratégie de conception la plus courante pour ces solutions consiste à tenter de répliquer - via le logiciel - quelque chose d’essentiellement similaire à la pratique “humaine” existante.
Cette approche n’est pas nouvelle. On pourrait dire qu’elle était la perspective mise en avant par les systèmes experts, qui ont pour la plupart perdu de leur crédibilité lors du second hiver de l’IA à la fin des années 1980 et au début des années 1990. Pourtant, bien que le mot à la mode systèmes experts ne soit plus utilisé - je ne pense pas qu’il existe de nos jours un éditeur de logiciels (significatif) se présentant encore comme un fournisseur de “systèmes experts” - je ne peux m’empêcher de constater que la perspective sous-jacente reste prévalente dans la plupart des secteurs.
En effet, la plupart des éditeurs de logiciels, ainsi que la majorité des initiatives internes, restent enfermés dans la perspective de répliquer la pratique existante, qui est née en imitant le processus entièrement manuel d’origine. L’ancien système expert a peut-être été remplacé par un algorithme deep learning plus moderne, mais le paradigme global reste (presque) intact.
Dans la supply chain, ce schéma est frappant car presque toute la pratique reste bloquée sur des approches ayant vu le jour dans un monde où les ordinateurs n’existaient tout simplement pas. Par exemple, de nombreuses - voire la plupart - des entreprises distinguent encore l’équipe de planification, c’est-à-dire les personnes qui établissent les prévisions de demande pour chaque produit, de l’équipe d’approvisionnement, les personnes qui passent les bons de commande en fonction de la prévision de demande. Cette approche est issue d’une perspective tayloriste dans laquelle les employés devaient être aussi spécialisés que possible afin d’être au maximum performants dans leur travail.
Cependant, lorsqu’il s’agit de l’optimization de la supply chain, le taylorisme est en contradiction avec la réalité de la supply chain. La réalité dicte que demande future n’est pas indépendante des décisions actuelles. Si un bon de commande bien plus important est passé - entraînant un prix d’achat unitaire bien plus bas - le prix de vente peut également être réduit, potentiellement pour dominer le marché, et ainsi augmenter considérablement la demande. Dans un monde sans ordinateurs, le taylorisme était la meilleure des mauvaises options, car, bien qu’il ne fût pas très efficace, il était considérablement évolutif. Pourtant, dans un monde avec ordinateurs, la situation exige une approche plus intégrée qui prend en compte, même de manière approximative, de telles rétroactions. Comme le dit l’adage, mieux vaut être approximativement juste qu’exactement faux.
Lorsqu’on interroge des clients ou des prospects à ce sujet, la situation est souvent floue. Les solutions - conçues à l’origine pour répliquer un processus purement manuel - sont en place depuis si longtemps que l’on a perdu de vue les aspects plus fondamentaux du problème que l’on cherche à résoudre. Trop souvent, les gens deviennent spécialistes de la solution en place, plutôt que spécialistes du problème auquel l’entreprise est confrontée. Ainsi, en cherchant à améliorer la situation, toutes les réflexions sont littéralement ancrées dans ce qui est perçu comme des défauts de la solution actuelle. En raison de ce biais, les approches qui revisitent en profondeur le problème sont perçues comme risquées tant par la direction que par leurs équipes.
Rétrospectivement, l’histoire des logiciels d’entreprise est malheureusement jalonnée d’histoires d’éditeurs imposant leur « nouvelle manière » de faire, qui s’est avérée bien plus fastidieuse et rigide que les processus d’antan, ne générant aucun gain de productivité, voire des gains négatifs. Anecdotiquement, j’observe que la plupart des entreprises opérant de grandes supply chains n’ont pas réduit de manière substantielle leurs effectifs de cols blancs - soutenant leur supply chain - au cours des deux dernières décennies, alors que les cols bleus ont été agressivement automatisés grâce à de meilleures usines ou de meilleurs warehouses. Ces événements malheureux ont injecté une bonne dose de scepticisme dans l’écosystème à l’égard de ces épuisantes “reorgs” mises en œuvre pour se conformer à une nouvelle solution logicielle.
Cependant, je note également que les supply chain executives sous-estiment généralement largement les risques associés à tout logiciel « intelligent » - c’est-à-dire tout logiciel dont la justesse ne peut être entièrement et précisément 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 commercialement avec un logiciel « stupide » est déjà assez difficile - de nombreuses entreprises du e-commerce peinent déjà à maintenir une bonne disponibilité de leur site web - mais dès qu’il s’agit de modules logiciels capricieux tels que des composants de machine learning, réussir devient beaucoup plus ardu. Peu d’entreprises communiquent ouvertement à ce sujet, mais dès que le machine learning est impliqué, les échecs dominent le domaine. Cependant, la situation n’est pas aussi sombre qu’elle 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 mieux.
Néanmoins, les risques liés aux logiciels sont bien réels, et il n’est certainement pas judicieux de les accroître davantage. Pourtant, s’en tenir au paradigme de répliquer une pratique manuelle désormais obsolète entraîne invariablement une série de complications accidentelles. Par exemple, comme l’équipe de planification et l’équipe d’approvisionnement sont distinctes, une catégorie entière de problèmes surgit dans le seul but de maintenir ces équipes synchronisées. En règle générale dans le développement logiciel, gonfler les exigences de 25 % augmente les coûts de 200 %. La résolution de ces complications augmente considérablement les coûts et, par conséquent, dans la pratique, le risque, puisque les entreprises ont tendance à annuler - réaction saine - les initiatives qui font exploser leurs budgets ou leurs délais.
Ainsi, lorsqu’on est confronté depuis un demi-siècle à la question d’adapter le logiciel à l’organisation ou l’organisation au logiciel, il est judicieux de commencer par une feuille blanche et de déterminer d’abord quels sont les problèmes de haut niveau qui doivent être résolus. La performance se mesure-t-elle en pourcentages ? Ou en dollars ? Prenons-nous correctement en compte les implications à long terme ? Par exemple, former les clients à n’acheter qu’en période de soldes. L’approche mise-t-elle à profit les apports humains ou se contente-t-elle de les consommer ? La pratique est-elle guidée par des habitudes ou par une nécessité impérieuse ? Par exemple, deux collections de mode par an, contre deux récoltes par an.
La compréhension approfondie du problème à résoudre - qui distingue clairement le problème lui-même de sa solution actuelle - est la clé pour déterminer si la solution existante mérite d’être préservée, ou si elle devrait être simplifiée au profit de capacités logicielles plus récentes qui permettent une résolution du problème plus simple et directe.
