Les POCs ne fonctionnent pas dans la Supply Chain Quantitative

Joannes Vermorel

Les proofs of 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 ; premièrement parce qu’elles nuisent directement à l’entreprise du client, et deuxièmement parce qu’elles nuisent également à Lokad dans le processus. Puisque les POCs – ou proofs-of-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 de la la Supply Chain Quantitative (1). Dans ce billet, nous rassemblons nos conclusions sur les POCs, que nous considérons comme un « anti-pattern » supply chain.

Les POCs ne coûtent pas moins cher

Une hypothèse fondamentale de la méthodologie des POC est que les POCs coûtent moins cher que le produit final. Malheureusement, cette hypothèse est presque toujours fausse.

Premièrement, établir un périmètre restreint au sein d’un réseau complet de supply chain ne fait que peu bouger les lignes. Par le passé, les vendeurs de logiciels rencontraient des problèmes de scalabilité et les déploiements à grande échelle nécessitaient en général d’importants investissements initiaux en matériel, potentiellement 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. Pourtant, à l’ère du cloud computing, cette contrainte n’existe plus, et si une application est conçue correctement, rien d’extra n’est requis pour commencer à traiter les données. La facture du cloud computing n’augmentera que marginalement pour chaque client supplémentaire, mais dans l’ensemble, ce coût est négligeable comparé, par exemple, aux frais engagés pour établir un premier contact 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.

Mieux encore, disposer de plus de données rend généralement les choses plus faciles, et non plus difficiles, lorsqu’il s’agit de la prévision statistique. Par conséquent, en restreignant le périmètre des données, les POCs ont tendance à compliquer les choses – et donc à augmenter les coûts – par rapport à l’approche du périmètre complet des défis. Notre expérience indique que, même lorsque les POCs se concentrent sur seulement 5 % du réseau complet de supply chain, ces 5 % impliquent généralement presque toute la complexité du réseau dans son ensemble. En réalité, c’est précisément parce que les POCs intègrent presque toute la complexité d’un projet à grande échelle que l’on s’attend à ce qu’ils aient du sens dès le départ.

Passer sous silence la complexité n’est en effet pas une option. Si votre réseau supply chain inclut des expéditions en conteneur et implique de travailler 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, comme les MOQ (quantités minimales de commande), les résultats numériques deviennent inutilisables.

Les coûts au-delà du POC sont déterminés par les efforts à déployer, tant par Lokad que par son client, pour gérer l’intégralité de la complexité de la supply chain. Ces coûts dépendent des spécificités de l’entreprise considérée, la taille n’ayant qu’un impact marginal sur les coûts.

Les POCs augmentent les risques d’échec

En optant pour un POC, les entreprises finissent fréquemment par tenter des expériences pour améliorer leur supply chain. Cependant, dans ce cas précis, j’aimerais citer Yoda, Fais-le. Ou ne le fais pas. Il n’y a pas d’essai. Malgré les affirmations des vendeurs de logiciels, optimiser la supply chain est difficile. Le problème avec les POCs est qu’ils laissent trop de latitude aux parties pour échouer.

• Extraire l’historique des ventes est terriblement compliqué. Hélas, il n’existe pas d’alternative, de toute façon : on ne réussira jamais à optimiser la supply chain sans disposer de données représentant la demande.
• Les niveaux de stocks électroniques sont inexacts. La technologie peut aider à détecter automatiquement les écarts les plus évidents et à prioriser les recomptages. Cependant, il n’est pas rare que les responsables supply chain doivent également gérer des stocks fantômes.
• Les prévisions restent médiocres quoi qu’il en soit. Les entreprises devraient apprendre à accepter un avenir incertain, plutôt que de vouloir éliminer cette incertitude. Les prévisions probabilistes sont particulièrement efficaces pour appréhender l’incertitude future.

Les complications sont autant d’excuses pour lâcher prise.

Il existe des situations où l’on s’attend à ce que les solutions soient simples et sans accrocs : par exemple, la création d’un nouveau compte e-mail pour un nouvel employé. Cependant, optimiser la supply chain est presque toujours difficile : si l’entreprise existe depuis plusieurs années, la partie « facile » de l’optimisation de la supply chain a déjà été réalisée il y a longtemps. C’est la partie « difficile » qui reste.

Selon notre expérience, la plupart des POCs échouent aux premières étapes du projet, lorsque les équipes rencontrent encore des problèmes liés aux données. Pourtant, cela n’en dit rien sur la solution d’optimisation de stocks elle-même, car celle-ci n’est jamais mise à l’épreuve.

Les POCs détournent les initiatives d’optimisation de la supply chain

Les POCs mettent en avant un point de vue qui n’est pas exactement celui de la production. Les dirigeants recherchent des repères à établir ou des KPI à fixer. Cependant, que se passerait-il si un certain KPI s’avérait plus difficile à calculer que l’exécution de l’optimisation elle-même ? Et si le KPI, malgré son intérêt, n’offrait aucune option concrète pour améliorer quoi que ce soit ?

Notre expérience indique que les POCs se laissent régulièrement détourner par des considérations qui ne sont tout simplement pas essentielles du point de vue de la production. Tenter de satisfaire ces exigences empoisonne généralement le POC, car soudainement, le POC devient un défi encore plus important que la production elle-même.

De plus, étant donné que le but principal d’un POC est de rassurer, la plupart des POCs souffrent du phénomène de « gold plating » dans lequel l’entreprise cliente met la pression sur le fournisseur pour qu’il intègre chaque aspect de son activité, même au détriment de la fiabilité globale de la solution. La solution qui en résulte est souvent trop fragile pour être réellement utile en production.

Nous avons également constaté que de nombreux POCs échouent sur des problèmes « imaginaires ». Par exemple, si le meilleur modèle de prévision, testé empiriquement sur des milliers de SKU, s’avère non saisonnier et surpasse tous les autres modèles saisonniers disponibles, cela doit-il être considéré comme un problème ? Il ne fait aucun doute que l’entreprise en question est saisonnière : elle l’est. Mais que se passe-t-il si la meilleure méthode connue pour anticiper la demande future consiste simplement à ignorer la saisonnalité dans ce cas ? Cela doit-il être considéré comme un problème ? D’après notre expérience, ce simple « problème » a constitué un obstacle pour de nombreux POCs, alors même que les praticiens de la supply chain 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 doivent maintenir l’activité pendant l’arrivée de la solution de nouvelle génération. Notre expérience indique que passer directement en production est moins coûteux et moins risqué. Cependant, cela doit être réalisé selon une méthodologie appropriée.

Premièrement, échouer à cause 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 dénuées de sens, toutes les tentatives d’optimisation le seront également. Le succès est une condition sine qua non, sans quoi l’entreprise pourrait disparaître dans quelques années. Il se trouve que la grande majorité des efforts à investir est consacrée à cette logistique des données, et cet investissement peut être quasiment entièrement dissocié de la solution envisagée pour la production. Et c’est tant mieux ! Si, pour une raison quelconque, la solution d’optimisation venait à faillir, l’investissement n’est pas perdu et il suffirait de le rediriger vers une solution alternative meilleure.

Deuxièmement, bien que l’objectif soit de passer directement en production, cela ne signifie pas pour autant que les chiffres ne soient pas remis en question, bien au contraire. L’ancien et le nouveau processus devraient coexister, en récoltant autant de fruits à portée de main que possible de l’ancien processus (2) pendant que le nouveau est peaufiné.

Ensuite, des dizaines de problèmes surviennent généralement. Il est important de les trier :

• des problèmes qui affectaient déjà l’ancien processus, certes de manière plus discrète. De bons processus et de bonnes technologies rendent les problèmes évidents ; ce n’est pas un défaut, mais une vertu.
• des problèmes qui ne peuvent être résolus par le logiciel déployé. Si le prélèvement des SKU est peu fiable dans le entrepôt, n’attendez pas du module de prévision de la demande qu’il le rende fiable.
• un décalage entre les problèmes réels et les attentes. La prévision statistique est profondément contre-intuitive ; ne laissez pas vos attentes primer sur ce que les mesures quantitatives vous indiquent.
• des problèmes de conception qui ne peuvent être résolus sans une refonte significative de la solution, ce qui se produit généralement lorsque le logiciel n’aborde pas le défi sous le bon angle.

Le dernier point nécessite qu’une autre solution soit envisagée. Cependant, comme mentionné ci-dessus, cela ne devrait pas marquer la fin de l’initiative, mais seulement 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 investi dans l’initiative. De plus, la plupart des POCs échouent pour les mauvaises raisons, ce qui signifie que les chances de succès des tentatives futures seront à peine améliorées puisque les véritables défis restent majoritairement intacts.

Passer directement en production est en réalité moins risqué qu’il n’y paraît. Cela aide à prévenir toute une catégorie d’échecs souvent ignorés dans le cas des POCs, alors qu’ils ne devraient pas l’être. Cela force l’initiative à se concentrer strictement sur ce qui est réellement nécessaire pour obtenir des améliorations, en laissant de côté les illusions. En cas d’échec sérieux d’un fournisseur, une entreprise peut toujours capitaliser sur son élan interne et basculer vers un autre fournisseur, sans perdre l’élan acquis comme c’est souvent le cas avec les POCs.

(1) Il existe de nombreuses manières d’optimiser la supply chain : de meilleurs processus, de meilleurs fournisseurs, de meilleurs transporteurs, une meilleure embauche… Ce billet se concentre sur l’optimisation quantitative : des défis de la supply chain pouvant être relevés grâce à des prévisions statistiques et/ou des solveurs numériques.

(2) Corriger les stocks fantômes bénéficie à l’ensemble des processus d’optimisation de stocks. Il en va de même pour la révision et l’amélioration des évaluations de stocks.