Rafraîchir tout chaque jour

Joannes Vermorel

La pratique supply chain de Lokad consiste à rafraîchir tous les pipelines de données - prévisions incluses - au moins une fois par jour, même lorsqu’il s’agit de calculs mensuels ou trimestriels. Pour de nombreux professionnels, cette pratique peut sembler contre-intuitive. Pourquoi rafraîchir des prévisions trimestrielles plus d’une fois par trimestre ? Qu’en est-il des instabilités numériques ? Qu’en est-il de la friction impliquée ? Cela va à l’encontre de la plupart des pratiques supply chain établies, en particulier celles des entreprises qui disposent d’un processus S&OP. Pourtant, une décennie d’expérience nous a appris que ne pas respecter cette pratique de « rafraîchir tout » est la recette d’un flot incessant de problèmes de production. Fondamentalement, ce problème doit être abordé de front – en profondeur – grâce à une conception sans état versionnée du logiciel en charge de l’optimisation prédictive de la supply chain. Ce point est examiné plus en détail dans la suite, 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 / dysfonctionnements / bugs / incidents surviennent tout le temps. Cela est particulièrement vrai pour les supply chains, où le paysage applicatif est invariablement un assemblage désordonné de morceaux de logiciels (ERP, EDI, MRP, WMS, OMS, le e-commerce, etc.) mis ensemble au fil de décennies d’activité : chaque application est une source potentielle de problèmes, car elle finit par interagir avec de nombreuses autres applications¹. Chaque changement apporté à l’une de ces applications peut provoquer une panne ailleurs, c’est-à-dire non seulement entraîner l’arrêt de l’application elle-même. Toutes les entreprises ne se valent pas en matière de gestion de leur paysage applicatif ; toutefois, au-delà de 1000 employés, même les entreprises les mieux gérées rencontrent plus d’un dysfonctionnement software supply chain par jour.

Ainsi, les entreprises de taille assez importante font face à un flot incessant de problèmes logiciels à résoudre. La responsabilité de résoudre ces problèmes peut incomber au département informatique, à un fournisseur tiers, à une équipe opérationnelle, à un fournisseur, etc. Pourtant, une fois que l’on considère que ces problèmes sont « censément » résolus, il faut 5 à 10 rounds² pour s’assurer que le problème est véritablement corrigé. En effet, la plupart des problèmes sont des cas limites, qui peuvent ou non se manifester à tout moment. Ainsi, bien qu’un problème puisse sembler résolu, parce qu’il a disparu après l’application d’un correctif quelconque, ce n’est peut-être pas encore le cas. Les supply chains sont des systèmes complexes impliquant de nombreux éléments interdépendants, dont certains ne sont même pas entièrement sous le contrôle de l’entreprise (par exemple, l’EDI avec les fournisseurs). Les gens échouent de façon routinière à fournir des correctifs définitifs non pas parce qu’ils sont paresseux ou incompétents, mais simplement à cause 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 stabiliser. 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 rounds qui compte, et non le temps écoulé. Il faut plusieurs rounds pour évaluer positivement que le cas limite est résolu. À titre d’anecdote, chez Lokad, nous avons eu un bug de planification des jobs lié au changement d’heure qui a mis deux ans à être corrigé, 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 le changement d’heure - soient intrinsèquement rares, la plupart des problèmes peuvent être reproduits « à volonté » simplement en augmentant la fréquence des « rounds ».

Remettre continuellement en question les pipelines de données de bout en bout est la seule façon de s’assurer que les problèmes sont corrigés dans des délais raisonnables. Une exécution peu fréquente conduit invariablement à ce que l’état par défaut du système soit cassé. Les entreprises qui exploitent des pipelines de données intermittents - par exemple, trimestriels - finissent invariablement avec de grandes bureaucraties qui existent uniquement pour relancer le pipeline une fois par trimestre. Pire encore, l’ensemble est généralement si dysfonctionnel que la bureaucratie passe la majeure partie du trimestre à assurer le « rafraîchissement » du trimestre suivant. À l’inverse, les pipelines en temps réel - comme ceux qui alimentent les pages web du site corporate - nécessitent à peine de personnel pour fonctionner.

Chez Lokad, nous avons opté pour des rafraîchissements quotidiens (ou plus) par pure nécessité il y a plus de dix ans. Depuis, nous n’avons toujours trouvé aucune autre méthode pour atteindre une qualité de service décente du point de vue de la supply chain. Il n’en existe probablement aucune. L’analytique prédictive est complexe et, par conséquent, sujette à toutes sortes de « bugs ». Les rafraîchissements quotidiens garantissent que les problèmes sont traités rapidement plutôt que de persister indéfiniment dans des limbes³. À cet égard, nos constats sont loin d’être originaux. Netflix a été le pionnier de tout le domaine du chaos engineering dans une logique similaire : pour concevoir un système robuste, il faut appliquer du stress ; sans stress, la robustesse n’intègre jamais l’état d’esprit d’ingénierie. La plupart des entreprises de logiciels sérieuses - notamment les GAFAM - ont adopté des variantes encore plus rigoureuses de cette approche.

De plus, des rafraîchissements peu fréquents des pipelines de données entraînent non seulement des problèmes de production, du point de vue de la supply chain, mais ils soulignent également toute une série de mauvaises pratiques et de mauvaises technologies.

Chaque fois que les prévisions sont rafraîchies de manière peu fréquente, il devient très tentant de les ajuster manuellement. En effet, les prévisions stagnent la plupart du temps par conception, précisément en raison du rafraîchissement peu fréquent. Ainsi, en se contentant de consulter les données d’hier, le planificateur de la demande peut améliorer une prévision produite par le système il y a trois semaines. Pourtant, ce travail du planificateur de la demande n’apporte aucune valeur ajoutée durable à l’entreprise : il n’est pas cumulatif. Si les recettes numériques qui génèrent les prévisions sont si mauvaises qu’elles nécessitent des ajustements manuels, alors ces recettes numériques doivent être corrigées. Si le fournisseur de logiciels ne parvient pas à fournir 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 exécuter la prévision deux fois et obtenir deux résultats distincts. C’est une bonne chose⁴. Les modèles numériques instables sont nuisibles pour la supply chain en raison d’effets de verrouillage : une fois qu’un ordre de production ou une commande d’achat est passé, l’entreprise est bloquée par les conséquences de cet ordre. Si une commande est passée, il faut que ce soit pour de meilleures raisons que pour une simple question d’instabilité numérique. Plus vite l’entreprise élimine les recettes numériques instables de sa pratique supply chain, mieux c’est. Tenter d’obscurcir le problème sous-jacent en réduisant la fréquence des rafraîchissements de prévisions est absurde : l’instabilité numérique ne disparaît pas parce que l’entreprise décide de ne plus y regarder. Si les recettes numériques sont si mauvaises qu’elles ne parviennent pas à maintenir une forte cohérence⁵ d’un jour à l’autre, de meilleures recettes numériques sont nécessaires. De nouveau, si un fournisseur de logiciels se trouve être en plein cœur du problème et ne peut pas fournir une correction approfondie, alors l’entreprise a aussi besoin d’un meilleur fournisseur.

Les rafraîchissements quotidiens de tous les pipelines de données peuvent sembler extravagants en termes de ressources informatiques. Cependant, compte tenu du matériel informatique moderne et d’un logiciel bien conçu, ce coût est minime, même lorsqu’on considère des recettes sophistiquées telles que la prévision probabiliste⁶. De plus, les supply chains font régulièrement face à des conditions exceptionnelles nécessitant une correction immédiate à grande échelle. Si l’entreprise ne peut pas rafraîchir toutes ses données de supply chain en moins de 60min parce que cela est nécessaire, alors il est garanti que des urgences resteront parfois non traitées, semant le chaos sur le terrain. La règle des 5 à 10 rounds - déjà évoquée - s’applique toujours : une fois qu’un correctif est découvert, il faut plusieurs exécutions - éventuellement avec des paramètres variés - pour avoir la certitude que cette correction d’urgence fonctionne. Ainsi, si le pipeline de données est trop coûteux pour être exécuté « à volonté », la production sera utilisée comme terrain d’essai et le chaos s’ensuivra.

D’un point de vue productif, les rafraîchissements quotidiens éliminent la tolérance aux mauvaises configurations qui continuent de générer des résultats médiocres. Encore une fois, c’est une bonne chose. Il n’y a aucune raison d’être tolérant envers une recette numérique qui continue de produire des résultats médiocres. La planification de la demande n’est pas une forme de création artistique défiant l’analyse numérique. Les recettes numériques dysfonctionnelles devraient être traitées comme des bugs logiciels et corrigées en conséquence. Toutefois, la mise en œuvre d’une correction approfondie nécessite souvent beaucoup plus de réflexion que de se rabattre sur un ajustement manuel ad hoc. La plupart des entreprises se demandent pourquoi leurs équipes supply chain reviennent sans cesse à leurs tableurs. Il s’avère que, fréquemment, les tableurs sont le seul endroit où les correctifs numériques - qui devraient déjà faire partie des systèmes - sont jamais mis en œuvre, précisément parce qu’itérer rapidement sur un tableur ne pose aucun problème (contrairement à itérer sur le système d’entreprise sous-jacent).

Cependant, les rafraîchissements quotidiens (ou plus) ne représentent 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é : statelessness. Un pipeline de données ne devrait pas utiliser de données pré-calculées et doit repartir de zéro à partir des données transactionnelles brutes à chaque fois. En effet, chaque bug ou dysfonctionnement est susceptible de corrompre les données pré-calculées, retardant l’entreprise pour une période indéfinie : la logique peut être corrigée, mais les données erronées subsistent. La solution est simple : le pipeline de données ne devrait avoir aucun état, c’est-à-dire aucune donnée pré-calculée de quelque nature que ce soit. Repartir à neuf garantit que tous les correctifs sont immédiatement exploités dans toute leur ampleur.

À son tour, le versioning, un autre principe de conception logicielle et le deuxième ingrédient d’intérêt, complète la statelessness du système : plus précisément, la gestion de versions des données. En effet, si le pipeline de données lui-même n’a aucun état, alors, combiner simplement la logique du pipeline – qui existe sous forme de code source versionné – avec les données d’entrée devrait suffire à reproduire exactement tout problème rencontré lors de l’exécution du 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 lors de l’exécution du pipeline. En d’autres termes, les données doivent être versionnées parallèlement au code. La gestion de versions des données garantit que les correctifs peuvent être testés dans les mêmes conditions exactes qui ont déclenché le problème initial.

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