Rafraîchir tout chaque jour

Joannes Vermorel

La pratique de la supply chain de Lokad consiste à rafraîchir tous les pipelines de données - y compris les prévisions - au moins une fois par jour, même lorsqu’il s’agit de calculs mensuels ou trimestriels. Pour de nombreux praticiens, cette pratique peut sembler contre-intuitive. Pourquoi rafraîchir les prévisions trimestrielles plus d’une fois par trimestre ? Qu’en est-il des instabilités numériques ? Qu’en est-il des frictions impliquées ? Cela va à l’encontre de la plupart des pratiques établies en matière de supply chain, en particulier celles des entreprises qui ont mis en place un processus de S&OP. Pourtant, une décennie d’expérience nous a appris que ne pas respecter cette pratique de “rafraîchir toutes les choses” est la recette d’un flux incessant de problèmes de production. Au cœur du problème, il est essentiel d’aborder frontalement - en profondeur - cette question grâce à une conception sans état versionnée du logiciel chargé de l’optimisation prédictive de la supply chain. Ce point est examiné plus en détail ci-dessous, mais commençons par examiner de plus près le problème lui-même.

Dans le monde des logiciels d’entreprise, les problèmes / les bugs / les erreurs / les problèmes surviennent tout le temps. Cela est particulièrement vrai pour les supply chains où le paysage applicatif est invariablement une collection de logiciels disparate (ERP, EDI, MRP, WMS, OMS, ecommerce, etc.) assemblés au fil des décennies d’activité : chaque application est une source potentielle de problèmes car elle finit par interagir avec de nombreuses autres applications¹. Chaque modification apportée à l’une de ces applications a une chance de causer des problèmes ailleurs, c’est-à-dire pas seulement dans l’application elle-même. Toutes les entreprises ne sont pas égales en ce qui concerne la gestion de leur paysage applicatif, cependant, au-delà de 1000 employés, même les entreprises les mieux gérées rencontrent plus d’un “problème” de supply chain lié aux logiciels par jour.

Ainsi, les grandes entreprises sont confrontées à un flux incessant de problèmes logiciels à résoudre. La responsabilité de résoudre ces problèmes peut incomber au service informatique, à un fournisseur tiers, à une équipe opérationnelle, à un fournisseur, etc. Cependant, une fois que l’un de ces problèmes est “soi-disant” résolu, il faut 5 à 10 cycles² pour s’assurer que le problème est réellement résolu. En effet, la plupart des problèmes sont des cas particuliers, qui peuvent se présenter ou non à chaque instant. Ainsi, bien qu’un problème puisse sembler résolu, car il a disparu après l’application d’une correction quelconque, ce n’est peut-être pas encore le cas. Les chaînes d’approvisionnement sont des systèmes complexes impliquant de nombreux éléments interdépendants, dont certains ne sont même pas entièrement contrôlés par l’entreprise (par exemple, l’EDI avec les fournisseurs). Les gens échouent régulièrement à apporter des solutions définitives non pas parce qu’ils sont paresseux ou incompétents, mais simplement en raison de la complexité ambiante irréductible.

Par conséquent, si un pipeline de données est exécuté quotidiennement après un incident de production, il faut 5 à 10 jours pour le ramener à la stabilité. Si le pipeline de données est exécuté mensuellement, le même processus de résolution prend 5 à 10 mois. Ce sont le nombre de cycles qui importent, pas le temps écoulé. Il faut plusieurs cycles pour évaluer positivement si le cas particulier est résolu. À titre d’exemple, chez Lokad, nous avons eu un bogue de planification des tâches lié au changement d’heure qui a pris deux ans à résoudre, précisément parce que les conditions déclenchant le problème étaient si rares - deux fois par an par fuseau horaire. Pourtant, bien que certains problèmes - comme les changements d’heure - soient intrinsèquement peu fréquents, la plupart des problèmes peuvent être reproduits “à volonté” en augmentant simplement la fréquence des “cycles”.

Remettre constamment en question les pipelines de données de bout en bout est le seul moyen de garantir que les problèmes soient résolus dans un délai raisonnable. Une exécution peu fréquente conduit invariablement à ce que l’état par défaut du système soit “défectueux”. Les entreprises qui utilisent des pipelines de données intermittents - par exemple, trimestriels - finissent invariablement par avoir de grandes bureaucraties dont le seul but est de remettre en marche le pipeline une fois par trimestre. Pire encore, tout le processus est généralement si dysfonctionnel que la bureaucratie passe la majeure partie du trimestre à assurer le “rafraîchissement” du trimestre suivant. En revanche, les pipelines en temps réel - comme le service des pages web du site web de l’entreprise - ont à peine besoin de personnel pour continuer à fonctionner.

Chez Lokad, nous avons opté pour des “rafraîchissements quotidiens” (ou plus) par pure nécessité il y a plus d’une décennie. Depuis lors, nous n’avons toujours pas identifié d’autre moyen d’obtenir une qualité de service décente d’un point de vue de la supply chain. Il n’y en a probablement pas. Les analyses prédictives sont complexes et, par conséquent, sujettes à toutes sortes de “bugs”. Les rafraîchissements quotidiens permettent de résoudre les problèmes rapidement au lieu de les laisser traîner indéfiniment dans les limbes³. À cet égard, nos conclusions sont loin d’être originales. Netflix a été pionnier dans le domaine de l’ingénierie du chaos selon des lignes de pensée similaires : pour concevoir un système robuste, il faut appliquer du stress ; sans stress, la robustesse ne fait jamais partie de la mentalité de l’ingénierie. La plupart des grandes entreprises de logiciels sérieuses - notamment les GAFAM - ont adopté des approches encore plus rigoureuses.

De plus, les rafraîchissements peu fréquents des pipelines de données ne conduisent pas seulement à des problèmes de production, d’un point de vue spécifique de la supply chain, ils mettent également l’accent sur toute une série de mauvaises pratiques et de mauvaises technologies.

Lorsque les prévisions sont rafraîchies peu fréquemment, il devient très tentant de les ajuster manuellement. En effet, les prévisions sont la plupart du temps bloquées par conception, précisément en raison du rafraîchissement peu fréquent. Ainsi, en jetant simplement un coup d’œil aux données d’hier, le demand planner peut améliorer une prévision qui a été produite par le système il y a trois semaines. Pourtant, ce travail du demand planner ne fournit aucune valeur ajoutée durable pour l’entreprise : il n’est pas accretif. Si les recettes numériques générant les prévisions sont si médiocres qu’elles nécessitent des ajustements manuels, alors ces recettes numériques doivent être corrigées. Si le fournisseur de logiciel ne peut pas apporter la correction, alors l’entreprise a besoin d’un meilleur fournisseur.

Les rafraîchissements fréquents des prévisions exacerbent les instabilités numériques des modèles statistiques sous-jacents, c’est-à-dire que si on exécute la prévision deux fois, on obtient deux résultats distincts. C’est une bonne chose⁴. Les modèles numériques instables sont nuisibles pour la supply chain en raison des effets de cliquet : une fois qu’un ordre de production ou un ordre d’achat est passé, l’entreprise est coincée avec les conséquences de cet ordre. Si un ordre est passé, il vaut mieux que ce soit pour de meilleures raisons qu’une question d’instabilité numérique. Plus tôt l’entreprise élimine les recettes numériques instables de sa pratique de la supply chain, mieux c’est. Essayer d’occulter le problème sous-jacent en réduisant la fréquence du rafraîchissement des prévisions est absurde : l’instabilité numérique ne disparaît pas parce que l’entreprise décide de ne plus la regarder. Si les recettes numériques sont si médiocres qu’elles ne peuvent pas maintenir une forte cohérence⁵ d’un jour à l’autre, de meilleures recettes numériques sont nécessaires. Encore une fois, si un fournisseur de logiciel se trouve au milieu du problème et ne peut pas apporter une correction en profondeur, alors l’entreprise a également besoin d’un meilleur fournisseur.

Les rafraîchissements quotidiens de toutes les pipelines de données peuvent sembler extravagants en termes de ressources informatiques. Cependant, compte tenu du matériel informatique moderne et des logiciels correctement conçus, ce coût est faible même lorsqu’on considère des recettes sophistiquées telles que la prévision probabiliste⁶. De plus, les supply chains sont régulièrement confrontées à des conditions exceptionnelles qui nécessitent une correction à grande échelle immédiate. Si l’entreprise ne peut pas rafraîchir toutes ses données de supply chain en moins de 60 minutes parce qu’elle en a besoin, alors les urgences sont garanties de rester sans réponse de temps en temps, provoquant le chaos sur le terrain. La règle des 5 à 10 rounds - précédemment discutée - s’applique toujours : une fois qu’une correction est découverte, il faut plusieurs exécutions - éventuellement avec des paramètres variés - pour gagner en confiance que cette correction d’urgence fonctionne. Ainsi, si la pipeline de données est trop coûteuse pour être exécutée “à volonté”, la production sera utilisée comme terrain de test et le chaos s’ensuivra.

D’un point de vue de la productivité, les rafraîchissements quotidiens éliminent la tolérance aux mauvaises configurations qui continuent de générer des résultats erronés. Encore une fois, c’est une bonne chose. Il n’y a aucune raison d’être tolérant avec une recette numérique qui continue de générer des résultats erronés. La planification de la demande n’est pas une sorte de création artistique qui défie l’analyse numérique. Les recettes numériques dysfonctionnelles doivent être traitées comme des bugs logiciels et corrigées en conséquence. Cependant, apporter une correction en profondeur nécessite souvent beaucoup plus de réflexion que de se contenter d’une substitution manuelle ad hoc. La plupart des entreprises se demandent pourquoi leurs équipes de supply chain reviennent sans cesse à leurs feuilles de calcul. Il s’avère que fréquemment, les feuilles de calcul sont le seul endroit où les corrections numériques - qui devraient déjà faire partie des systèmes - sont jamais mises en œuvre, précisément parce qu’itérer rapidement sur une feuille de calcul ne pose aucun problème (contrairement à l’itération sur le système d’entreprise sous-jacent).

Cependant, les rafraîchissements quotidiens (ou plus) ne sont qu’un aspect opérationnel du problème. En termes de conception logicielle, cette approche doit être complétée par un premier ingrédient clé : l’absence d’état. Une pipeline de données ne doit pas utiliser de données précalculées et recommencer à partir des données transactionnelles brutes à chaque fois. En effet, chaque bogue ou dysfonctionnement risque de corrompre les données précalculées, retardant l’entreprise pour une durée indéterminée : la logique peut être corrigée mais les données défectueuses restent. La solution est simple : la pipeline de données ne doit pas avoir d’état, c’est-à-dire aucune donnée précalculée d’aucune sorte. Repartir de zéro garantit que toutes les corrections sont immédiatement exploitées au maximum.

À son tour, la versioning, un autre principe de conception logicielle et le deuxième ingrédient d’intérêt, complète l’absence d’état du système : plus précisément, la versioning des données. En effet, si la pipeline de données elle-même n’a pas d’état, alors, simplement combiner la logique de la pipeline - qui existe sous forme de code source versionné - et les données d’entrée devrait suffire à reproduire exactement tout problème rencontré lors de l’exécution de la pipeline. En d’autres termes, cela rend les problèmes reproductibles. Cependant, pour y parvenir, il est nécessaire de conserver une copie exacte des données telles qu’elles étaient au moment de l’exécution de la pipeline de données. En d’autres termes, les données doivent être versionnées avec le code. La versioning des données garantit que les corrections peuvent être testées dans les mêmes conditions exactes qui ont déclenché le problème initial.

Lokad a été conçu autour de ces principes. Nous encourageons un rafraîchissement quotidien de bout en bout de tout. Nos pipelines de données sont sans état et versionnés - à la fois la logique et les données. Et votre entreprise ?