Les POC ne fonctionnent pas dans l'optimisation quantitative de la supply chain
Les preuves de concept sont l’une des demandes les plus fréquentes que nous recevons de la part de nos clients potentiels souhaitant essayer notre service d’optimisation de la supply chain. Pourtant, nous déclinons fréquemment de telles demandes ; d’abord parce qu’elles nuisent à l’entreprise du client, et ensuite parce qu’elles nuisent également à Lokad dans le processus. Étant donné que les POC - ou preuves de concept - sont si répandus dans les logiciels B2B, il est généralement difficile de comprendre pourquoi ils peuvent être carrément nuisibles dans le cas spécifique de l’optimisation quantitative de la supply chain (1). Dans cet article, nous rassemblons nos conclusions sur les POC, les considérant comme un “anti-pattern” de la supply chain.
Les POC ne coûtent pas moins cher
Une hypothèse fondamentale derrière la méthodologie des POC est que les POC coûtent moins cher que la vraie solution. Malheureusement, cette hypothèse est presque toujours incorrecte.
Tout d’abord, établir un petit périmètre au sein d’un réseau de supply chain ne fait que déplacer légèrement l’aiguille. Dans le passé, les fournisseurs de logiciels ont eu du mal avec des problèmes de scalabilité et les déploiements à grande échelle réels nécessitaient généralement d’importants investissements matériels initiaux, éventuellement regroupés avec des licences logicielles telles que des bases de données. Sans ces investissements, il n’était même pas possible de commencer à traiter les données. Cependant, à l’ère actuelle du cloud computing, cette contrainte n’existe plus, et si une application est conçue correctement, rien de plus n’est nécessaire pour commencer à traiter les données. La facture du cloud computing augmentera seulement de manière marginale pour chaque client supplémentaire, mais dans l’ensemble, ce coût est négligeable par rapport, par exemple, aux coûts liés à l’établissement d’une discussion avec le prospect. Deuxièmement, la majeure partie des efforts initiaux consiste à qualifier les données, suivie d’une identification appropriée dans l’établissement d’une relation commerciale B2B avec le client.
Pire encore, avoir plus de données rend généralement les choses plus faciles, pas plus difficiles, chaque fois que la prévision statistique est impliquée. Par conséquent, en limitant la portée des données, les POC ont tendance à rendre les choses plus difficiles, et donc plus coûteuses, par rapport à l’adresse de la portée complète des défis. Notre expérience indique que même lorsque les POC se concentrent sur seulement 5% de l’ensemble du réseau de supply chain, ces 5% impliquent généralement presque toute la complexité du réseau dans son ensemble. En fait, c’est précisément parce que les POC intègrent presque toute la complexité d’un projet à grande échelle, que les POC devraient avoir du sens en premier lieu.
Ignorer la complexité n’est en effet pas une option. Si votre réseau d’approvisionnement comprend des expéditions de conteneurs et que vous travaillez avec des fournisseurs peu fiables, comment un POC pourrait-il être convaincant si ces éléments ne sont pas pris en compte dans l’initiative ? Si une contrainte spécifique est ignorée, telle que les MOQs (quantités minimales de commande), les résultats numériques deviennent inutilisables.
Les coûts au-delà du POC sont motivés par les efforts à fournir des deux côtés, à la fois par Lokad et son client, pour gérer la complexité complète de la supply chain. Ces coûts sont motivés par les spécificités de l’entreprise considérée, l’échelle n’ayant qu’un impact marginal sur les coûts.
Les POC augmentent les chances d’échec
Lorsqu’ils optent pour un POC, les entreprises finissent souvent par “essayer des trucs” pour améliorer leur supply chain. Cependant, dans ce cas précis, je voudrais citer Yoda : “Fais-le ou ne le fais pas. Il n’y a pas d’essai.” Malgré les affirmations des éditeurs de logiciels, l’optimisation de la supply chain est difficile. Le problème avec les POCs est qu’ils laissent trop de marge de manœuvre aux parties pour échouer.
- “Extraire l’historique des ventes est extrêmement compliqué.” Hélas, il n’y a de toute façon pas d’alternative : on ne réussira jamais à optimiser la supply chain sans des données représentant la demande.
- “Les niveaux de stock électroniques sont inexacts.” La technologie peut aider à détecter automatiquement les écarts les plus évidents et à hiérarchiser les recomptages. Cependant, il n’est pas rare que les responsables de la supply chain aient également affaire à des stocks fantômes.
- “Les prévisions restent mauvaises quoi qu’il arrive.” Les entreprises devraient apprendre à embrasser un avenir incertain au lieu de souhaiter cette incertitude. Les prévisions probabilistes sont particulièrement bonnes pour capturer l’incertitude future.
“Les complications sont autant d’excuses pour abandonner.”
Il y a des situations où l’on s’attend à ce que les solutions soient faciles et sans problème : par exemple, créer un nouveau compte de messagerie pour un nouvel employé. Cependant, l’optimisation de la supply chain est presque toujours difficile : si l’entreprise existe depuis plus de quelques années, la partie “facile” de l’optimisation de la supply chain a déjà été faite il y a des années. La partie “difficile” est ce qui reste.
D’après notre expérience, la plupart des POCs échouent aux premières étapes du projet, lorsque les équipes luttent encore avec des problèmes de données. Pourtant, cela ne dit rien sur la solution d’optimisation des stocks elle-même, car la solution n’est jamais mise à l’épreuve.
Les POCs détournent les initiatives d’optimisation de la supply chain
Les POCs mettent l’accent sur un point de vue qui n’est pas exactement le point de vue de la “production”. Les dirigeants cherchent des références à établir ou des KPI à établir. Cependant, que se passe-t-il si un certain KPI s’avère plus difficile à calculer que la réalisation de l’optimisation elle-même ? Et si le KPI lui-même, bien qu’instructif, n’offre aucune option praticable pour améliorer quoi que ce soit ?
Notre expérience indique que les POCs sont régulièrement détournés par des considérations qui ne sont tout simplement pas des exigences du point de vue de la production. Essayer de répondre à ces exigences empoisonne généralement le POC car soudainement, le POC devient en réalité un défi encore plus grand que la production elle-même.
De plus, comme le principal objectif d’un POC est de rechercher des garanties, la plupart des POCs souffrent de modèles anti-patterns où l’entreprise cliente pousse le fournisseur à tout inclure en capturant chaque aspect de leur activité, même au détriment de la fiabilité globale de la solution. La solution résultante est souvent trop fragile pour être utile du point de vue de la production.
Nous avons vu de nombreux POCs échouer sur des problèmes “imaginaires” également. Par exemple, si le meilleur modèle de prévision, testé empiriquement sur des milliers de SKUs, s’avère non saisonnier et surpasse tous les autres modèles saisonniers disponibles, cela devrait-il être considéré comme un problème ? Il ne fait aucun doute que l’activité en question est saisonnière : elle l’est. Mais que se passe-t-il si la meilleure façon connue d’anticiper la demande future est de simplement ignorer la saisonnalité dans ce cas ? Cela devrait-il être considéré comme un problème ? Dans notre expérience, ce seul “problème” a été considéré comme un obstacle bloquant pour de nombreux POCs, alors que les praticiens de la supply chain eux-mêmes admettaient que les quantités de commandes d’achat suggérées étaient pertinentes.
Optez pour la production et révisez le projet si nécessaire
Les POCs sont généralement et à juste titre perçus comme des distractions par les praticiens qui ont besoin de maintenir l’activité en cours pendant que la solution de nouvelle génération arrive. Notre expérience indique que passer directement à la production est moins cher et moins risqué. Cependant, cela doit être fait avec la méthodologie appropriée.
Premièrement, échouer en raison de la “logistique des données” n’est pas une option. On ne peut pas optimiser ce que l’on ne mesure pas. Si les données sont insignifiantes, alors toutes les tentatives d’optimisation seront également insignifiantes. Le succès est une exigence, car sinon l’entreprise pourrait ne plus exister dans quelques années. Il se trouve que la grande majorité des efforts à investir sont associés à cette logistique des données, et cet investissement peut être presque entièrement séparé de la solution envisagée pour la production. Et c’est une bonne chose ! Si la solution d’optimisation s’avérait insuffisante pour une raison quelconque, l’investissement n’est pas perdu et doit simplement être redirigé vers une meilleure solution alternative.
Deuxièmement, bien que l’objectif soit de passer directement à la production, cela ne signifie pas que les chiffres ne sont pas remis en question, bien au contraire. Le processus ancien et nouveau devraient coexister, en tirant le maximum de bénéfices possibles du processus ancien (2) pendant que le nouveau est peaufiné.
Ensuite, des dizaines de problèmes se posent généralement. Il est important de les trier :
- les problèmes qui affectaient déjà l’ancien processus, bien que de manière plus silencieuse. Les bons processus et les bonnes technologies rendent les problèmes évidents ; ce n’est pas un défaut mais une vertu.
- les problèmes qui ne peuvent pas être résolus par le logiciel déployé. Si la préparation des SKUs n’est pas fiable dans l’entrepôt, ne vous attendez pas à ce que le module de prévision de la demande le rende fiable.
- les écarts entre les problèmes réels et les attentes. La prévision statistique est profondément contre-intuitive ; ne laissez pas vos attentes l’emporter sur ce que les mesures quantitatives vous disent.
- les problèmes de conception qui ne peuvent pas être résolus sans une refonte significative de la solution, ce qui se produit généralement lorsque le logiciel n’a pas le bon angle pour relever le défi.
Le dernier point nécessite une autre solution à envisager. Cependant, comme mentionné ci-dessus, cela ne devrait pas être la fin de l’initiative, mais simplement le début d’une collaboration avec un autre fournisseur.
Abandonner l’idée d’un POC signifie généralement perdre tout l’élan qui a été investi dans l’initiative. De plus, la plupart des POC échouent pour de mauvaises raisons, ce qui signifie que les chances de succès des tentatives futures seront à peine améliorées car les véritables défis restent en grande partie intacts.
Aller directement en production est en réalité moins risqué qu’il n’y paraît. Cela permet de prévenir toute une série d’échecs qui ont tendance à être ignorés dans le cas des POC, alors qu’ils ne devraient pas l’être. Cela force l’initiative à adopter une approche étroite sur ce qui est réellement nécessaire pour obtenir des améliorations, et à mettre de côté les vœux pieux. Lorsqu’une entreprise est confrontée à un échec sérieux d’un fournisseur, elle peut encore capitaliser sur son élan interne et passer à un autre fournisseur, sans perdre ledit élan comme cela se produit généralement avec les POC.
(1) Il existe de nombreuses façons d’optimiser la supply chain : de meilleurs processus, de meilleurs fournisseurs, de meilleurs transporteurs, de meilleurs recrutements… Cet article se concentre sur l’optimisation quantitative : les défis de la supply chain qui peuvent être abordés grâce à des prévisions statistiques et/ou des solveurs numériques.
(2) Résoudre les problèmes d’inventaire fantôme est bénéfique pour tous les processus d’optimisation des stocks. Il en va de même pour la révision et l’amélioration des évaluations des stocks.
