Démarrer une initiative de supply chain quantitative - Lecture 7.1

00:00 Introduction
02:31 Causes racines d’échec dans la nature
07:20 Livrable : une recette numérique 1/2
09:31 Livrable : une recette numérique 2/2
13:01 L’histoire jusqu’à présent
14:57 Réaliser des choses aujourd’hui
15:59 Chronologie de l’initiative
21:48 Portée : paysage applicatif 1/2
24:24 Portée : paysage applicatif 2/2
27:12 Portée : effets système 1/2
29:21 Portée : effets système 2/2
32:12 Rôles : 1/2
37:31 Rôles : 2/2
41:50 Pipeline de données - Comment
44:13 Un mot sur les systèmes transactionnels
49:13 Un mot sur le data lake
52:59 Un mot sur les systèmes analytiques
57:56 Santé des données : niveau bas
01:02:23 Santé des données : niveau élevé
01:06:24 Inspecteurs de données
01:08:53 Conclusion
01:10:32 Prochaine conférence et questions du public

Description

Mener à bien une optimisation prédictive d’une supply chain est un mélange de problèmes complexes et simples. Malheureusement, il n’est pas possible de séparer ces aspects. Les facettes complexes et simples sont profondément entrelacées. Habituellement, cet enchevêtrement entre en collision frontale avec la division du travail telle que définie par l’organigramme de l’entreprise. Nous observons que, lorsque les initiatives de supply chain échouent, les causes racines de l’échec sont généralement des erreurs commises aux premiers stades du projet. De plus, les erreurs précoces ont tendance à façonner l’ensemble de l’initiative, les rendant presque impossibles à corriger a posteriori. Nous présentons nos principales conclusions pour éviter ces erreurs.

Transcription complète

Bienvenue dans cette série de conférences sur la supply chain. Je suis Joannes Vermorel et aujourd’hui je vais présenter “Getting Started with a Quantitative Supply Chain Initiative”. La grande majorité des initiatives de supply chain basées sur l’analyse de données échouent. Depuis 1990, la plupart des entreprises opérant de grandes supply chains lancent des initiatives majeures d’optimisation prédictive tous les trois à cinq ans avec peu ou pas de résultats. De nos jours, la plupart des équipes de supply chain ou de data science, qui entament une nouvelle série d’optimisation prédictive - généralement présentée comme un projet de prévision ou un projet d’optimisation des stocks - ne réalisent même pas que leur entreprise a déjà tenté cela et a échoué peut-être une demi-douzaine de fois.

Se lancer dans une nouvelle tentative est parfois motivé par la croyance que cette fois-ci sera différente, mais souvent, les équipes ne sont même pas conscientes des nombreuses tentatives infructueuses qui ont eu lieu auparavant. La preuve anecdotique de cette situation est que Microsoft Excel reste l’outil numéro un pour prendre des décisions en supply chain, alors que ces initiatives étaient censées remplacer les feuilles de calcul par de meilleurs outils. Pourtant, de nos jours, il y a encore très peu de supply chains qui peuvent fonctionner sans feuilles de calcul.

L’objectif de cette conférence est de comprendre comment donner une chance de succès à une initiative de supply chain qui vise à fournir une quelconque optimisation prédictive. Nous passerons en revue une série d’éléments critiques - ces éléments sont simples et pourtant ils sont très souvent contre-intuitifs pour la plupart des organisations. À l’inverse, nous passerons en revue une série de contre-exemples qui garantissent presque l’échec d’une telle initiative.

Aujourd’hui, je me concentre sur l’exécution tactique du tout début d’une initiative de supply chain avec une mentalité de “faire avancer les choses”. Je ne discuterai pas des implications stratégiques majeures pour l’entreprise. La stratégie est très importante, mais j’en parlerai lors d’une prochaine conférence.

La plupart des initiatives de supply chain échouent, et le problème est rarement mentionné publiquement. Les milieux universitaires publient des dizaines de milliers d’articles par an vantant toutes sortes d’innovations en supply chain, y compris des cadres, des algorithmes et des modèles. Souvent, les articles prétendent même que l’innovation a été mise en production quelque part. Et pourtant, ma propre observation informelle du monde de la supply chain est que ces innovations ne sont nulle part visibles. De même, les éditeurs de logiciels promettent depuis trois décennies des remplacements supérieurs pour les feuilles de calcul, et là encore, mon observation informelle indique que les feuilles de calcul restent omniprésentes.

Nous revenons sur un point qui a déjà été abordé dans le deuxième chapitre de cette série de conférences sur la supply chain. En bref, les gens n’ont aucune incitation à annoncer un échec, et donc ils ne le font pas. De plus, comme les entreprises qui opèrent des supply chains tendent à être grandes, le problème est généralement aggravé par la perte naturelle de mémoire institutionnelle lorsque les employés passent d’un poste à l’autre. C’est pourquoi ni les milieux universitaires ni les éditeurs de logiciels ne reconnaissent cette situation plutôt sombre.

Je propose de commencer par une brève enquête sur les causes les plus fréquentes d’échec du point de vue de l’exécution tactique. En effet, ces causes sont généralement identifiées à un stade précoce de l’initiative.

La première cause d’échec est une tentative de résoudre les mauvais problèmes - des problèmes qui n’existent pas, qui sont insignifiants ou qui reflètent une sorte de mécompréhension de la supply chain elle-même. L’optimisation des pourcentages de précision des prévisions est probablement l’archétype d’un tel problème incorrect. Réduire le pourcentage d’erreur de prévision ne se traduit pas directement par des euros ou des dollars supplémentaires de retour pour l’entreprise. La même situation se produit lorsqu’une entreprise recherche des taux de service spécifiques pour son inventaire. Il est très rare d’avoir des euros ou des dollars de retour à montrer pour cela.

La deuxième cause d’échec est l’utilisation d’une technologie logicielle et d’une conception logicielle inadaptées. Par exemple, les éditeurs de ERP essaient invariablement d’utiliser une base de données transactionnelle pour soutenir les initiatives de traitement des données car c’est sur quoi repose l’ERP. À l’inverse, les équipes de data science essaient invariablement d’utiliser la boîte à outils d’apprentissage automatique open source de pointe du jour car c’est une chose cool à faire. Malheureusement, les pièces de technologie inadaptées génèrent généralement une immense friction et beaucoup de complexité accidentelle.

La troisième cause d’échec est une répartition incorrecte du travail et de l’organisation. Dans une tentative malavisée d’attribuer des spécialistes à chaque étape du processus, les entreprises ont tendance à fragmenter l’initiative entre trop de personnes. Par exemple, la préparation des données est très souvent effectuée par des personnes qui ne sont pas responsables des prévisions. Par conséquent, les situations de “garbage-in-garbage-out” sont monnaie courante. Diluer marginalement la responsabilité des décisions finales de la supply chain est une recette pour l’échec.

Un élément que je n’ai pas mentionné dans cette courte liste en tant que cause première est les mauvaises données. Les données sont très souvent blâmées pour les échecs des initiatives de supply chain, ce qui est bien pratique, car les données ne peuvent pas exactement répondre à ces accusations. Cependant, les données ne sont généralement pas en cause, du moins pas au sens de lutter contre de mauvaises données. La supply chain des grandes entreprises est devenue numérique il y a des décennies. Chaque article acheté, transporté, transformé, produit ou vendu a des enregistrements électroniques. Ces enregistrements ne sont peut-être pas parfaits, mais ils sont généralement très précis. Si les gens échouent à traiter correctement les données, ce n’est pas vraiment la transaction qui est à blâmer.

Pour qu’une initiative quantitative réussisse, nous devons mener le bon combat. Qu’est-ce que nous essayons de livrer en premier lieu ? L’un des livrables clés d’une supply chain quantitative est une recette numérique de base qui calcule les décisions finales de la supply chain. Cet aspect a déjà été discuté dans la leçon 1.3 du tout premier chapitre, “Livraison orientée produit pour la supply chain”. Revisitons les deux propriétés les plus critiques de ce livrable.

Premièrement, la sortie doit être une décision. Par exemple, décider combien d’unités recommander aujourd’hui pour un SKU donné est une décision. En revanche, prévoir combien d’unités seront demandées aujourd’hui pour un SKU donné est un artefact numérique. Pour générer une décision qui est le résultat final, de nombreux résultats intermédiaires sont nécessaires, c’est-à-dire de nombreux artefacts numériques. Cependant, nous ne devons pas confondre les moyens et la fin.

La deuxième propriété de ce livrable est que la sortie, qui est une décision, doit être entièrement automatisée grâce à un processus logiciel entièrement automatisé. La recette numérique elle-même, la recette numérique de base, ne doit impliquer aucune opération manuelle. Naturellement, la conception de la recette numérique elle-même est susceptible de dépendre fortement d’un expert humain en science. Cependant, l’exécution ne doit pas dépendre d’une intervention humaine directe.

Avoir une recette numérique en tant que livrable est essentiel pour faire de l’initiative de la supply chain une entreprise capitaliste. La recette numérique devient un actif productif qui génère des rendements. La recette doit être entretenue, mais cela nécessite une ou deux ordres de grandeur de moins de personnes par rapport aux approches qui maintiennent les humains dans la boucle au niveau des micro-décisions.

Cependant, de nombreuses initiatives de supply chain échouent car elles ne définissent pas correctement les décisions de la supply chain comme le livrable de l’initiative. Au lieu de cela, ces initiatives se concentrent sur la livraison d’artefacts numériques. Les artefacts numériques sont destinés à être des ingrédients pour parvenir à la résolution finale du problème, soutenant généralement les décisions elles-mêmes. Les artefacts les plus courants rencontrés dans la supply chain sont les prévisions, les stocks de sécurité, les EOQ, les KPI. Bien que ces chiffres puissent être intéressants, ils ne sont pas réels. Ces chiffres n’ont pas de contrepartie physique tangible immédiate dans la supply chain et ils reflètent des perspectives de modélisation arbitraires sur la supply chain.

Se concentrer sur les artefacts numériques conduit à l’échec de l’initiative car ces chiffres manquent d’un ingrédient essentiel : un retour d’information direct du monde réel. Lorsque la décision est erronée, les mauvaises conséquences peuvent être attribuées à la décision. Cependant, la situation est beaucoup plus ambiguë en ce qui concerne les artefacts numériques. En effet, la responsabilité est diluée partout, car de nombreux artefacts contribuent à chaque décision. Le problème est encore plus grave lorsqu’il y a une intervention humaine au milieu.

Ce manque de retour d’information est fatal pour les artefacts numériques. Les chaînes d’approvisionnement modernes sont complexes. Choisissez n’importe quelle formule arbitraire pour calculer un stock de sécurité, une quantité économique de commande ou un indicateur de performance clé (KPI) ; il y a de fortes chances que cette formule soit incorrecte de toutes sortes de manières. Le problème de la justesse de la formule n’est pas un problème mathématique ; c’est un problème commercial. Il s’agit de répondre à la question : “Est-ce que ce calcul reflète vraiment l’intention stratégique que j’ai pour mon entreprise ?” La réponse varie d’une entreprise à l’autre et même d’une année à l’autre, car les entreprises évoluent avec le temps.

Comme les artefacts numériques manquent de retour d’information direct du monde réel, ils manquent du mécanisme même qui permet d’itérer à partir d’une implémentation initiale naïve, simpliste et très probablement largement incorrecte vers une version approximativement correcte de la formule qui pourrait être considérée comme étant de qualité de production. Pourtant, les artefacts numériques sont très tentants car ils donnent l’illusion de se rapprocher de la solution. Ils donnent l’illusion d’être rationnels, scientifiques, voire entreprenants. Nous avons des chiffres, des formules, des algorithmes, des modèles. Il est même possible de faire des comparaisons avec d’autres chiffres tout aussi inventés. S’améliorer par rapport à un benchmark inventé donne également l’illusion de progresser, et c’est très réconfortant. Mais en fin de compte, cela reste une illusion, une question de perspective de modélisation.

Les entreprises ne réalisent pas de profits en payant des gens pour regarder des KPI ou faire des benchmarks. Elles réalisent des profits en prenant une décision après l’autre et, espérons-le, en s’améliorant à chaque fois pour prendre la décision suivante.

Cette conférence fait partie d’une série de conférences sur la chaîne d’approvisionnement. J’essaie de rendre ces conférences quelque peu indépendantes, mais nous avons atteint un point où il est plus logique de les regarder dans l’ordre. Cette conférence est la toute première conférence du septième chapitre, qui est consacré à l’exécution des initiatives de la chaîne d’approvisionnement. Par initiatives de la chaîne d’approvisionnement, je veux dire des initiatives quantitatives de la chaîne d’approvisionnement - des initiatives qui visent à fournir quelque chose dans l’ordre de l’optimisation prédictive pour l’entreprise.

Le tout premier chapitre était consacré à mes points de vue sur la chaîne d’approvisionnement à la fois en tant que domaine d’étude et en tant que pratique. Dans le deuxième chapitre, j’ai présenté une série de méthodologies essentielles à la chaîne d’approvisionnement, car les méthodologies naïves sont vaincues en raison de la nature adversaire de nombreuses situations de chaîne d’approvisionnement. Dans le troisième chapitre, j’ai présenté une série de personae de la chaîne d’approvisionnement axées uniquement sur les problèmes ; en d’autres termes, qu’est-ce que nous essayons de résoudre ?

Dans le quatrième chapitre, j’ai présenté une série de domaines qui, bien qu’ils ne soient pas la chaîne d’approvisionnement à proprement parler, sont essentiels à une pratique moderne de la chaîne d’approvisionnement. Dans les cinquième et sixième chapitres, j’ai présenté les éléments clés d’une recette numérique destinée à orienter les décisions de la chaîne d’approvisionnement, à savoir l’optimisation prédictive (la perspective généralisée de la prévision) et la prise de décision (essentiellement l’optimisation mathématique appliquée aux problèmes de chaîne d’approvisionnement). Dans ce septième chapitre, nous discutons de la manière de rassembler ces éléments dans une initiative de chaîne d’approvisionnement réelle qui vise à mettre ces méthodes et technologies en production.

Aujourd’hui, nous passerons en revue ce qui est considéré comme la bonne pratique pour mener une initiative de chaîne d’approvisionnement. Cela comprend la définition de l’initiative avec le bon livrable, dont nous venons de discuter, mais aussi avec le bon calendrier, la bonne portée et les bons rôles. Ces éléments représentent la première partie de la conférence d’aujourd’hui.

La deuxième partie de la conférence sera consacrée au pipeline de données, un élément essentiel pour le succès d’une initiative axée sur les données. Bien que le pipeline de données soit un sujet assez technique, il nécessite une répartition appropriée des tâches et une organisation entre les services informatiques et la chaîne d’approvisionnement. En particulier, nous verrons que les contrôles de qualité devraient être principalement entre les mains de la chaîne d’approvisionnement, avec la conception de rapports sur l’état des données et d’inspecteurs de données.

L’intégration est la première phase de l’initiative, où la recette numérique de base, celle qui génère la décision avec seulement des éléments de soutien, est élaborée. L’intégration se termine par un déploiement progressif en production, et pendant ce déploiement, les processus antérieurs sont progressivement automatisés par la recette numérique elle-même.

Lorsqu’on envisage le calendrier approprié pour la première initiative de chaîne d’approvisionnement quantitative dans une entreprise, on pourrait penser que cela dépend de la taille de l’entreprise, de sa complexité, du type de décisions de chaîne d’approvisionnement et du contexte global. Bien que cela soit vrai dans une certaine mesure, l’expérience que Lokad a accumulée au cours d’une décennie et de dizaines de telles initiatives indique que six mois sont presque invariablement le calendrier approprié. Étonnamment, ce délai de six mois a peu à voir avec la technologie ou même les spécificités de la chaîne d’approvisionnement ; il a beaucoup plus à voir avec les personnes et les organisations elles-mêmes et le temps qu’il leur faut pour se familiariser avec ce qui est généralement perçu comme une manière très différente de mener une chaîne d’approvisionnement.

Les deux premiers mois sont consacrés à la mise en place du pipeline de données. Nous reviendrons sur ce point dans quelques minutes, mais ce délai de deux mois est causé par deux facteurs. Premièrement, nous devons rendre le pipeline de données fiable et éliminer les problèmes peu fréquents qui peuvent prendre des semaines à se manifester. Le deuxième facteur est que nous devons comprendre la sémantique des données, c’est-à-dire comprendre ce que les données signifient d’un point de vue de la chaîne d’approvisionnement.

Les troisième et quatrième mois sont consacrés à des itérations rapides sur la recette numérique elle-même, qui guidera les décisions de la chaîne d’approvisionnement. Ces itérations sont nécessaires car générer des décisions finales réelles est généralement le seul moyen d’évaluer s’il y a quelque chose de faux ou non dans la recette sous-jacente ou dans toutes les hypothèses intégrées à la recette. Ces deux mois sont également généralement le temps qu’il faut aux praticiens de la chaîne d’approvisionnement pour s’habituer à la perspective très quantitative et financière qui guide ces décisions basées sur des logiciels.

Enfin, les deux derniers mois sont consacrés à la stabilisation de la recette numérique après une période généralement intense d’itérations rapides. Cette période est également l’occasion pour les équipes de la chaîne d’approvisionnement de gagner confiance en cette solution émergente.

Bien qu’il puisse être souhaitable de compresser davantage ce calendrier, il s’avère généralement très difficile de le faire. La mise en place du pipeline de données peut être accélérée dans une certaine mesure si l’infrastructure informatique appropriée est déjà en place, mais il faut du temps pour se familiariser avec les données et comprendre ce qu’elles signifient d’un point de vue de la chaîne d’approvisionnement. Dans la deuxième phase, si l’itération sur la recette numérique converge très rapidement, les équipes de la chaîne d’approvisionnement sont susceptibles de commencer à explorer les subtilités de la recette numérique, ce qui prolongera également le délai. Enfin, les deux derniers mois sont généralement nécessaires pour voir la saisonnalité se déployer et gagner confiance dans le logiciel qui guide les décisions importantes de la chaîne d’approvisionnement en production.

Dans l’ensemble, cela prend environ six mois, et bien qu’il serait souhaitable de le compresser davantage, cela est difficile à réaliser. Cependant, six mois représentent déjà une période considérable. Si dès le premier jour, la période d’intégration, où la recette numérique ne guide pas encore les décisions de la chaîne d’approvisionnement, est prévue pour durer plus de six mois, alors l’initiative est déjà en danger. Si le retard supplémentaire est lié à l’extraction des données et à la mise en place du pipeline de données, alors il y a un problème informatique. Si le retard supplémentaire est lié à la conception ou à la configuration de la solution, éventuellement apportée par un fournisseur externe, alors il y a un problème avec la technologie elle-même. Enfin, si après deux mois de fonctionnement stable similaire à la production, le déploiement en production ne se produit pas, alors il y a généralement un problème avec la gestion de l’initiative.

Lorsqu’il s’agit d’introduire une nouveauté, un nouveau processus ou une nouvelle technologie dans une organisation, la sagesse populaire suggère de commencer petit, de s’assurer que cela fonctionne, et de construire sur le succès initial pour s’étendre progressivement. Malheureusement, la chaîne d’approvisionnement ne se prête pas à la sagesse populaire, et cette perspective comporte une particularité spécifique en ce qui concerne le périmètre de la chaîne d’approvisionnement. En termes de périmètre, il existe deux forces principales qui définissent largement ce qui est et ce qui n’est pas un périmètre éligible en ce qui concerne une initiative de chaîne d’approvisionnement.

Le paysage applicatif est la première force qui impacte le périmètre. Une chaîne d’approvisionnement dans son ensemble ne peut pas être observée directement ; elle ne peut être observée que de manière indirecte à travers les logiciels d’entreprise. Les données seront obtenues grâce à ces logiciels. La complexité de l’initiative dépend grandement du nombre et de la diversité de ces logiciels. Chaque application est sa propre source de données, et extraire et analyser les données de n’importe quelle application métier tend à être une tâche importante. Traiter avec plus d’applications signifie généralement traiter avec plusieurs technologies de base de données, des terminologies incohérentes, des concepts incohérents, et complique considérablement la situation.

Ainsi, lors de l’établissement du périmètre, nous devons reconnaître que les frontières éligibles sont généralement définies par les applications métier elles-mêmes et leur structure de base de données. Dans ce contexte, commencer petit doit être compris comme garder l’empreinte initiale d’intégration des données aussi petite que possible tout en préservant l’intégrité de l’initiative de chaîne d’approvisionnement dans son ensemble. Il vaut mieux approfondir plutôt qu’élargir en termes d’intégration d’applications. Une fois que vous avez le système informatique en place pour obtenir quelques enregistrements d’une table dans une application donnée, il est généralement facile d’obtenir tous les enregistrements de cette table et tous les enregistrements d’une autre table dans la même application.

Une erreur courante dans le périmètre consiste à échantillonner. L’échantillonnage est généralement réalisé en sélectionnant une courte liste de catégories de produits, de sites ou de fournisseurs. L’échantillonnage est bien intentionné, mais il ne suit pas les limites telles que définies par le paysage applicatif. Pour mettre en œuvre l’échantillonnage, des filtres doivent être appliqués lors de l’extraction des données, et ce processus crée une série de problèmes qui sont susceptibles de mettre en danger l’initiative de la chaîne d’approvisionnement.

Tout d’abord, une extraction de données filtrées à partir d’un logiciel d’entreprise nécessite plus d’efforts de la part de l’équipe informatique par rapport à une extraction non filtrée. Les filtres doivent être conçus en premier lieu, et le processus de filtrage lui-même est sujet aux erreurs. Le débogage des filtres incorrects est invariablement fastidieux car il nécessite de nombreux échanges avec les équipes informatiques, ce qui ralentira l’initiative et, par conséquent, la mettra en danger.

Deuxièmement, laisser l’initiative effectuer son intégration sur un échantillon de données est une recette pour des problèmes de performance logicielle massifs lorsque l’initiative s’étend ultérieurement à l’ensemble du périmètre. La mauvaise évolutivité, ou l’incapacité à traiter une grande quantité de données tout en maîtrisant les coûts de calcul, est un défaut très fréquent dans les logiciels. En laissant l’initiative fonctionner sur un échantillon, les problèmes d’évolutivité sont masqués mais reviendront en force à un stade ultérieur.

Travailler sur un échantillon de données rend les statistiques plus difficiles, pas plus faciles. En effet, avoir accès à plus de données est probablement le moyen le plus simple d’améliorer la précision et la stabilité de presque tous les algorithmes d’apprentissage automatique. L’échantillonnage des données va à l’encontre de cette idée. Ainsi, lors de l’utilisation d’un petit échantillon de données, l’initiative peut échouer en raison de comportements numériques erratiques observés sur l’échantillon. Ces comportements auraient été largement atténués si l’ensemble des données avait été utilisé à la place.

Les effets systémiques sont la deuxième force qui impacte le périmètre. Une chaîne d’approvisionnement est un système, et toutes ses parties sont couplées dans une certaine mesure. Le défi avec les systèmes, n’importe quel système, est que les tentatives d’amélioration d’une partie du système ont tendance à déplacer les problèmes plutôt qu’à les résoudre. Par exemple, considérons un problème d’allocation des stocks pour un réseau de vente au détail avec un centre de distribution et de nombreux magasins. Si nous choisissons un seul magasin comme périmètre initial pour notre problème d’allocation des stocks, il est trivial de garantir que ce magasin bénéficiera d’une très haute qualité de service de la part du centre de distribution en réservant les stocks à l’avance. En faisant cela, nous pouvons nous assurer que le centre de distribution ne sera jamais en rupture de stock tout en servant ce magasin. Cependant, cette réservation de stock se ferait au détriment de la qualité de service des autres magasins du réseau.

Ainsi, lors de la définition d’un périmètre pour une initiative de chaîne d’approvisionnement, nous devons tenir compte des effets systémiques. Le périmètre doit être conçu de manière à empêcher largement une optimisation locale au détriment des éléments qui se trouvent en dehors du périmètre. Cette partie de l’exercice de définition du périmètre est difficile car tous les périmètres sont plus ou moins perméables. Par exemple, toutes les parties de la chaîne d’approvisionnement sont en concurrence pour la même quantité de liquidités disponibles au niveau de l’entreprise. Chaque dollar alloué quelque part est un dollar qui ne sera pas disponible à d’autres fins. Néanmoins, certains périmètres sont beaucoup plus faciles à manipuler que d’autres. Il est important de choisir un périmètre qui tend à atténuer les effets systémiques plutôt que de les amplifier.

Penser à la définition du périmètre d’une initiative de chaîne d’approvisionnement en termes d’effets systémiques peut sembler étrange pour de nombreux praticiens de la chaîne d’approvisionnement. En ce qui concerne la définition du périmètre, la plupart des entreprises ont tendance à projeter leur organisation interne sur l’exercice de définition du périmètre. Ainsi, les limites choisies pour le périmètre ont invariablement tendance à imiter les limites de la division du travail en place au sein de l’entreprise. Ce schéma est connu sous le nom de loi de Conway. Proposée par Melvin Conway il y a un demi-siècle pour les systèmes de communication, cette loi s’est depuis révélée avoir une applicabilité beaucoup plus large, notamment une pertinence primordiale pour la gestion de la chaîne d’approvisionnement.

Les limites et les silos qui dominent les chaînes d’approvisionnement actuelles sont dictés par des divisions du travail qui sont la conséquence de processus assez manuels mis en place pour prendre des décisions en matière de chaîne d’approvisionnement. Par exemple, si une entreprise estime qu’un planificateur de l’offre et de la demande ne peut pas gérer plus de 1 000 références, et que l’entreprise doit gérer au total 50 000 références, l’entreprise aura besoin de 50 planificateurs de l’offre et de la demande pour le faire. Cependant, répartir l’optimisation de la chaîne d’approvisionnement entre 50 paires de mains est garanti d’introduire de nombreuses inefficacités au niveau de l’entreprise.

Au contraire, une initiative qui automatise ces décisions n’a pas besoin de tenir compte de ces limites qui ne reflètent que la division du travail obsolète ou bientôt obsolète. Une recette numérique peut optimiser ces 50 000 références en une seule fois et éliminer les inefficacités résultant de la confrontation de dizaines de silos. Ainsi, il est naturel qu’une initiative visant à automatiser largement ces décisions chevauche de nombreuses limites préexistantes dans l’entreprise. L’entreprise, ou plutôt la direction de l’entreprise, doit résister à la tentation de reproduire les limites organisationnelles existantes, en particulier au niveau de la définition du périmètre, car cela tend à donner le ton pour la suite.

Les chaînes d’approvisionnement sont complexes en termes de matériel, de logiciel et de personnel. Malheureusement, le lancement d’une initiative de chaîne d’approvisionnement quantitative augmente encore la complexité de la chaîne d’approvisionnement, du moins initialement. À long terme, cela peut en fait réduire considérablement la complexité de la chaîne d’approvisionnement, mais nous en parlerons probablement lors d’une prochaine conférence. De plus, plus il y a de personnes impliquées dans l’initiative, plus la complexité de l’initiative elle-même est grande. Si cette complexité supplémentaire n’est pas immédiatement maîtrisée, il y a de fortes chances que l’initiative s’effondre sous son propre poids.

Ainsi, lorsque nous réfléchissons aux rôles de l’initiative, c’est-à-dire à qui fera quoi, nous devons penser à l’ensemble le plus restreint possible de rôles qui rend l’initiative viable. En réduisant au minimum le nombre de rôles, nous réduisons la complexité de l’initiative, ce qui améliore considérablement ses chances de réussite. Cette perspective tend à être contre-intuitive pour les grandes entreprises qui aiment travailler avec une division du travail extrêmement fine. Les grandes entreprises ont tendance à privilégier des spécialistes extrêmes qui ne font qu’une seule chose. Cependant, une chaîne d’approvisionnement est un système, et comme tous les systèmes, c’est la perspective de bout en bout qui compte.

Sur la base de l’expérience acquise chez Lokad dans la réalisation de ce type d’initiatives, nous avons identifié quatre rôles qui représentent généralement la division minimale du travail nécessaire pour mener à bien l’initiative : un responsable de la chaîne d’approvisionnement, un responsable des données, un scientifique de la chaîne d’approvisionnement et un praticien de la chaîne d’approvisionnement.

Le rôle du responsable de la chaîne d’approvisionnement est de soutenir l’initiative afin qu’elle puisse se concrétiser en premier lieu. Obtenir une recette numérique bien conçue pour piloter les décisions de la chaîne d’approvisionnement en production représente un énorme avantage tant en termes de rentabilité que de productivité. Cependant, cela représente également beaucoup de changements à assimiler. Il faut beaucoup d’énergie et de soutien de la direction pour qu’un tel changement se produise au sein d’une grande organisation.

Le rôle du responsable des données est de mettre en place et de maintenir le pipeline de données. La majeure partie de sa contribution est censée se produire au cours des deux premiers mois de l’initiative. Si le pipeline de données est correctement conçu, il y a très peu d’efforts continus pour le responsable des données par la suite. Le responsable des données n’est généralement pas très impliqué dans les phases ultérieures de l’initiative.

Le rôle du scientifique de la chaîne d’approvisionnement est de concevoir la recette numérique de base. Ce rôle part des données transactionnelles brutes telles qu’elles sont mises à disposition par le responsable des données. Aucune préparation des données n’est attendue de la part du responsable des données, seulement l’extraction des données. Le rôle du scientifique de la chaîne d’approvisionnement se termine lorsqu’il prend en charge la décision de la chaîne d’approvisionnement générée. Ce n’est pas un logiciel qui est responsable de la décision ; c’est le scientifique de la chaîne d’approvisionnement. Pour chaque décision générée, le scientifique lui-même doit être en mesure de justifier pourquoi cette décision est adéquate.

Enfin, le rôle du praticien de la chaîne d’approvisionnement est de remettre en question les décisions générées par la recette numérique et de fournir des commentaires au scientifique de la chaîne d’approvisionnement. Le praticien n’a aucun espoir de prendre la décision. Cette personne a généralement été responsable de ces décisions jusqu’à présent, du moins pour une sous-étendue, et généralement avec l’aide de feuilles de calcul et de systèmes en place. Dans une petite entreprise, il est possible qu’une personne remplisse à la fois le rôle de responsable de la chaîne d’approvisionnement et de praticien de la chaîne d’approvisionnement. Il est également possible de contourner le besoin d’un responsable des données si les données sont facilement accessibles. Cela peut se produire dans des entreprises très matures en ce qui concerne leur infrastructure de données. Au contraire, si l’entreprise est très grande, il est possible d’avoir quelques personnes, mais seulement très peu, pour chaque rôle.

Le déploiement réussi en production de la recette numérique de base a un impact considérable sur le monde du praticien de la chaîne d’approvisionnement. En effet, dans une large mesure, l’objectif de l’initiative est d’automatiser le travail précédent du praticien de la chaîne d’approvisionnement. Cependant, cela n’implique pas que la meilleure solution soit de licencier ces praticiens une fois que la recette numérique est en production. Nous reviendrons sur cet aspect spécifique lors de la prochaine conférence.

Être organisé ne signifie pas être efficace ou être efficace. Il existe des rôles qui, malgré de bonnes intentions, ajoutent des frictions aux initiatives de la chaîne d’approvisionnement, souvent au point de les faire échouer complètement. De nos jours, le premier rôle qui contribue le plus à faire échouer de telles initiatives tend à être le rôle du scientifique des données, et encore plus lorsque toute une équipe de scientifiques des données est impliquée. En passant, Lokad a appris cela à ses dépens il y a une dizaine d’années.

Malgré la similitude de nom entre les scientifiques des données et les scientifiques de la chaîne d’approvisionnement, les deux rôles sont en réalité très différents. Le scientifique de la chaîne d’approvisionnement se soucie avant tout de fournir des décisions réelles et adaptées à la production. Si cela peut être réalisé avec une recette numérique semi-triviale, tant mieux ; la maintenance sera un jeu d’enfant. Le scientifique de la chaîne d’approvisionnement assume l’entière responsabilité de traiter les moindres détails de la chaîne d’approvisionnement. La fiabilité et la résilience face au chaos ambiant importent plus que la sophistication.

En revanche, le scientifique des données se concentre sur les parties intelligentes de la recette numérique, les modèles et les algorithmes. Le scientifique des données, de manière générale, se perçoit comme un expert en apprentissage automatique et en optimisation mathématique. En termes de technologies, un scientifique des données est prêt à apprendre les derniers outils numériques open source de pointe, mais cette personne est généralement réticente à en apprendre davantage sur le progiciel de gestion intégré (ERP) vieux de trois décennies qui fait fonctionner l’entreprise. De plus, le scientifique des données n’est pas un expert en chaîne d’approvisionnement, et n’est généralement pas disposé à en devenir un. Le scientifique des données tente de fournir les meilleurs résultats selon les métriques convenues. Le scientifique n’a pas l’ambition de traiter les détails très banals de la chaîne d’approvisionnement ; ces éléments sont censés être gérés par d’autres personnes.

Impliquer des scientifiques des données est fatal pour ces initiatives, car dès que des scientifiques des données sont impliqués, la chaîne d’approvisionnement n’est plus au centre des préoccupations - les algorithmes et les modèles le sont. Ne sous-estimez jamais le pouvoir de distraction que représente le dernier modèle ou algorithme pour une personne intelligente et technophile.

Le deuxième rôle qui tend à entraver une initiative de chaîne d’approvisionnement est l’équipe de business intelligence (BI). Lorsque l’équipe de BI fait partie de l’initiative, elle a tendance à être un obstacle plutôt qu’autre chose, bien que dans une moindre mesure que l’équipe de science des données. Le problème avec la BI est principalement culturel. La BI fournit des rapports, pas des décisions. L’équipe de BI est généralement disposée à produire d’innombrables tableaux de bord de métriques demandés par chaque division de l’entreprise. Ce n’est pas la bonne attitude pour une initiative de chaîne d’approvisionnement quantitative.

De plus, la business intelligence en tant que logiciel est une classe très spécifique d’analyse de données axée sur les cubes ou les cubes OLAP qui permettent de découper et d’analyser la plupart des systèmes en mémoire des systèmes d’entreprise. Cette conception est généralement peu adaptée pour prendre des décisions en matière de chaîne d’approvisionnement.

Maintenant que nous avons défini l’initiative, examinons l’architecture informatique de haut niveau requise par l’initiative.

Le schéma à l’écran illustre une configuration typique de pipeline de données pour une initiative de chaîne d’approvisionnement quantitative. Dans cette conférence, je discute d’un pipeline de données qui ne prend pas en charge les exigences de faible latence. Nous voulons être en mesure de terminer un cycle complet en environ une heure, pas une seconde. La plupart des décisions en matière de chaîne d’approvisionnement, telles que les commandes d’achat, ne nécessitent pas une configuration à faible latence. La réalisation d’une faible latence de bout en bout nécessite un type d’architecture différent, qui dépasse le cadre de la conférence d’aujourd’hui.

Les systèmes de transaction représentent la source de données principale et le point de départ du pipeline de données. Ces systèmes comprennent l’ERP, le WMS et l’EDI. Ils traitent le flux de marchandises telles que les achats, le transport, la production et la vente. Ces systèmes contiennent presque toutes les données requises par la recette numérique de base. Pour presque toutes les entreprises de taille importante, ces systèmes ou leurs prédécesseurs sont en place depuis au moins deux décennies.

Comme ces systèmes contiennent presque toutes les données dont nous avons besoin, il serait tentant de mettre en œuvre la recette numérique directement dans ces systèmes. En effet, pourquoi pas ? En intégrant la recette numérique directement dans l’ERP, nous éliminerions la nécessité de mettre en place l’ensemble de ce pipeline de données. Malheureusement, cela ne fonctionne pas en raison de la conception même de ces systèmes transactionnels.

Ces systèmes de transaction sont invariablement construits autour d’une base de données transactionnelle. Cette approche de conception de logiciels d’entreprise est restée extrêmement stable au cours des quatre dernières décennies. Prenez une entreprise au hasard et il y a de fortes chances que chaque application métier en production ait été mise en œuvre sur une base de données transactionnelle. Les bases de données transactionnelles offrent quatre propriétés clés connues sous l’acronyme ACID, qui signifie Atomicité, Cohérence, Isolation et Durabilité. Je ne vais pas entrer dans les détails de ces propriétés, mais il suffit de dire que ces propriétés rendent la base de données très adaptée pour effectuer en toute sécurité et simultanément de nombreuses petites opérations de lecture et d’écriture. Les quantités respectives d’opérations de lecture et d’opérations d’écriture sont également censées être assez équilibrées.

Cependant, le prix à payer pour ces propriétés ACID très utiles au niveau le plus granulaire est que la base de données transactionnelle est également très inefficace lorsqu’il s’agit de traiter de grandes opérations de lecture. Une opération de lecture qui couvre une partie importante de l’ensemble de la base de données, en règle générale, si les données sont traitées par le biais d’une base de données qui se concentre sur une livraison très granulaire de ces propriétés ACID, alors vous pouvez vous attendre à ce que le coût des ressources informatiques soit multiplié par un facteur de 100 par rapport aux architectures qui ne se concentrent pas autant sur ces propriétés ACID à un niveau aussi granulaire. ACID est bien, mais cela a un coût élevé.

De plus, lorsque quelqu’un tente de lire une partie importante de l’ensemble de la base de données, la base de données risque de devenir non réactive pendant un certain temps car elle consacre la majeure partie de ses ressources à la satisfaction de cette seule grande demande. De nombreuses entreprises se plaignent que l’ensemble de leurs systèmes métier sont lents et que ces systèmes se figent fréquemment pendant une seconde ou plus. En général, cette mauvaise qualité de service peut être attribuée à des requêtes SQL lourdes qui tentent de lire trop de lignes à la fois.

Par conséquent, la recette numérique de base ne peut pas être autorisée à fonctionner dans le même environnement que les systèmes transactionnels qui soutiennent la production. En effet, les recettes numériques auront besoin d’accéder à la plupart des données chaque fois qu’elles sont exécutées. Ainsi, la recette numérique doit être strictement isolée dans son propre sous-système, ne serait-ce que pour éviter de dégrader davantage les performances de ces systèmes transactionnels.

Au fait, bien qu’il soit connu depuis des décennies que c’est une terrible idée d’avoir un processus intensif en données fonctionnant au sein d’un système transactionnel, cela n’empêche pas la plupart des fournisseurs de systèmes de transaction (ERP, MRP, WMS) de vendre des modules analytiques intégrés, par exemple, des modules d’optimisation des stocks. L’intégration de ces modules conduit inévitablement à des problèmes de qualité de service tout en offrant des capacités décevantes. Tous ces problèmes peuvent être attribués à ce problème de conception unique : le système transactionnel et le système analytique doivent être strictement isolés.

Le data lake est simple. Il s’agit d’un miroir des données transactionnelles destiné à de très grandes opérations de lecture. En effet, nous avons vu que les systèmes transactionnels sont optimisés pour de nombreuses petites opérations de lecture, pas pour de très grandes opérations. Ainsi, afin de préserver la qualité de service du système transactionnel, la conception correcte consiste à reproduire soigneusement les données transactionnelles dans un autre système, à savoir le data lake. Cette réplication doit être mise en œuvre avec soin, précisément pour préserver la qualité de service du système transactionnel, ce qui signifie généralement lire les données de manière très progressive et éviter de mettre des pics de pression sur le système transactionnel.

Une fois que les données transactionnelles pertinentes sont reproduites dans le data lake, le data lake lui-même répond à toutes les demandes de données. Un avantage supplémentaire du data lake est sa capacité à servir plusieurs systèmes analytiques. Bien que nous discutions ici de la supply chain, si le marketing souhaite ses propres analyses, il aura besoin de ces mêmes données transactionnelles, et il en va de même pour la finance, les ventes, etc. Ainsi, au lieu de faire en sorte que chaque service de l’entreprise mette en œuvre son propre mécanisme d’extraction de données, il est logique de consolider toutes ces extractions dans le même data lake, le même système.

Au niveau technique, un data lake peut être mis en œuvre avec une base de données relationnelle, généralement optimisée pour l’extraction de big data, en adoptant un stockage de données en colonnes. Les data lakes peuvent également être mis en œuvre sous la forme d’un référentiel de fichiers plats servis sur un système de fichiers distribué. Comparé à un système transactionnel, un data lake renonce aux propriétés transactionnelles fines. L’objectif est de servir une grande quantité de données aussi bon marché et aussi fiable que possible, rien de plus, rien de moins.

Le data lake doit refléter les données transactionnelles d’origine, ce qui signifie les copier sans les modifier. Il est important de ne pas préparer les données dans le data lake. Malheureusement, l’équipe informatique chargée de la mise en place du data lake peut être tentée de faciliter les choses et de simplifier les choses pour les autres équipes, et donc de préparer un peu les données. Cependant, la modification des données introduit invariablement des complications qui compromettent les analyses à un stade ultérieur. De plus, respecter une politique de réplication stricte réduit considérablement les efforts nécessaires à l’équipe informatique pour mettre en place et maintenir le data lake.

Dans les entreprises où une équipe BI est déjà en place, il peut être tentant d’utiliser les systèmes BI comme data lake. Cependant, je déconseille fortement de le faire et de ne jamais utiliser une configuration BI comme data lake. En effet, les données dans les systèmes BI (systèmes d’intelligence d’affaires) sont invariablement déjà fortement transformées. Utiliser les données BI pour piloter des décisions automatisées de la supply chain est une recette pour des problèmes de qualité des données. Le data lake ne doit être alimenté qu’à partir de sources de données primaires telles que l’ERP, et non à partir de sources de données secondaires telles que le système BI.

Le système analytique est celui qui contient la recette numérique de base. C’est également le système qui fournit tous les rapports nécessaires pour instrumenter les décisions elles-mêmes. Au niveau technique, le système analytique contient les “parties intelligentes”, comme les algorithmes d’apprentissage automatique et les algorithmes d’optimisation mathématique. Bien que, dans la pratique, ces parties intelligentes ne dominent pas la base de code des systèmes analytiques. En général, la préparation des données et l’instrumentation des données nécessitent au moins dix fois plus de lignes de code que les parties liées à l’apprentissage et à l’optimisation.

Le système analytique doit être découplé du data lake car ces deux systèmes sont complètement opposés du point de vue technologique. En tant que logiciel, le data lake est censé être très simple, très stable et extrêmement fiable. Au contraire, le système analytique est censé être sophistiqué, en constante évolution et extrêmement performant en termes de performance de la supply chain. Contrairement au data lake, qui doit offrir un temps de disponibilité quasi parfait, le système analytique n’a même pas besoin d’être disponible la plupart du temps. Par exemple, si nous envisageons des décisions quotidiennes de réapprovisionnement des stocks, alors le système analytique ne doit fonctionner et être disponible qu’une fois par jour.

En règle générale, il vaut mieux que le système analytique échoue à produire des décisions plutôt que de générer des décisions incorrectes et de les laisser passer en production. Retarder les décisions de la supply chain de quelques heures, comme les commandes d’achat, est généralement beaucoup moins grave que de prendre des décisions incorrectes. Comme la conception du système analytique tend à être fortement influencée par les parties intelligentes qu’il contient, il n’y a pas nécessairement grand-chose à dire en général sur la conception du système analytique. Cependant, il y a au moins une propriété de conception clé qui doit être respectée pour l’écosystème : ce système doit être sans état.

Le système analytique doit éviter d’avoir un état interne dans la plus grande mesure possible. En d’autres termes, l’ensemble de l’écosystème doit commencer avec les données telles qu’elles sont présentées par le data lake et se terminer avec les décisions de la supply chain générées, ainsi que les rapports de soutien. Ce qui se passe souvent, c’est que chaque fois qu’il y a un composant à l’intérieur du système analytique qui est trop lent, comme un algorithme d’apprentissage automatique, il est tentant d’introduire un état, c’est-à-dire de persister certaines informations de l’exécution précédente pour accélérer la prochaine exécution. Cependant, faire cela, en s’appuyant sur des résultats précédemment calculés plutôt que de tout recalculer à partir de zéro à chaque fois, est dangereux.

En effet, avoir un état au sein du système analytique met la décision en danger. Alors que les problèmes de données se poseront inévitablement et seront corrigés au niveau du data lake, le système analytique peut encore renvoyer des décisions qui reflètent un problème qui a déjà été corrigé. Par exemple, si un modèle de prévision de la demande est entraîné sur un ensemble de données de ventes corrompu, alors le modèle de prévision reste corrompu jusqu’à ce qu’il soit réentraîné sur une version fraîche et corrigée de l’ensemble de données. La seule façon d’éviter que le système analytique souffre d’échos de problèmes de données qui ont déjà été corrigés dans le data lake est de tout rafraîchir à chaque fois. C’est là l’essence de l’état sans état.

En règle générale, si une partie du système analytique s’avère trop lente pour être remplacée quotidiennement, alors cette partie doit être considérée comme souffrant d’un problème de performance. Les supply chains sont chaotiques et il y aura un jour où quelque chose se produira - un incendie, un confinement, une cyberattaque - qui nécessitera une intervention immédiate. L’entreprise doit être capable de rafraîchir toutes ses décisions de la supply chain dans l’heure. L’entreprise ne doit pas attendre et rester bloquée pendant 10 heures pendant que la phase d’apprentissage automatique lente se déroule.

Pour fonctionner de manière fiable, le système analytique doit être correctement instrumenté. C’est ce que permettent le rapport sur la santé des données et les inspecteurs de données. D’ailleurs, tous ces éléments relèvent de la responsabilité de la supply chain ; ils ne relèvent pas de la responsabilité de l’informatique. La surveillance de la santé des données représente la toute première phase de traitement des données, même avant la préparation des données proprement dite, et elle se déroule au sein du système analytique. La santé des données fait partie de l’instrumentation de la recette numérique. Le rapport sur la santé des données indique s’il est acceptable ou non d’exécuter la recette numérique. Ce rapport identifie également l’origine du problème de données, le cas échéant, afin d’accélérer la résolution du problème.

La surveillance de la santé des données est une pratique chez Lokad. Au cours de la dernière décennie, cette pratique s’est révélée inestimable pour éviter les situations de “garbage in, garbage out” qui semblent être omniprésentes dans le monde des logiciels d’entreprise. En effet, lorsque l’exploitation des données échoue, on met souvent en cause des données de mauvaise qualité. Cependant, il est important de noter qu’en général, il n’y a presque aucun effort d’ingénierie pour garantir la qualité des données en premier lieu. La qualité des données ne tombe pas du ciel ; elle nécessite des efforts d’ingénierie.

Le pipeline de données qui a été présenté jusqu’à présent est assez minimaliste. La duplication des données est aussi simple que possible, ce qui est une bonne chose en ce qui concerne la qualité logicielle. Pourtant, malgré ce minimalisme, il y a encore de nombreux éléments en mouvement : de nombreuses tables, de nombreux systèmes, de nombreuses personnes. Ainsi, il y a des bugs partout. C’est un logiciel d’entreprise, et le contraire serait assez surprenant. La surveillance de la santé des données est mise en place pour aider le système analytique à survivre au chaos ambiant.

La santé des données ne doit pas être confondue avec le nettoyage des données. La santé des données consiste uniquement à s’assurer que les données mises à disposition du système analytique sont une représentation fidèle des données transactionnelles existantes dans les systèmes de transaction. Il n’y a aucune tentative de corriger les données ; les données sont analysées telles quelles.

Chez Lokad, nous distinguons généralement la santé des données de bas niveau de la santé des données de haut niveau. La santé des données de bas niveau est un tableau de bord qui consolide toutes les anomalies structurelles et volumétriques des données, telles que des problèmes évidents tels que des entrées qui ne sont même pas des dates ou des nombres raisonnables, par exemple, ou des identifiants orphelins qui ne sont pas accompagnés de leurs homologues attendus. Tous ces problèmes peuvent être identifiés et sont en réalité les plus faciles. Le problème difficile commence avec des problèmes qui ne peuvent pas être identifiés car les données manquent en premier lieu. Par exemple, si quelque chose s’est mal passé lors d’une extraction de données et que les données de vente extraites d’hier ne contiennent que la moitié des lignes attendues, cela peut vraiment mettre en danger la production. Les données incomplètes sont particulièrement insidieuses car elles n’empêchent généralement pas la recette numérique de générer des décisions, sauf que ces décisions seront des déchets, car les données d’entrée sont incomplètes.

Techniquement, chez Lokad, nous essayons de regrouper la surveillance de la santé des données sur un seul tableau de bord, et ce tableau de bord est généralement destiné à l’équipe informatique, car la plupart des problèmes capturés par la santé des données de bas niveau sont liés au pipeline de données lui-même. Idéalement, l’équipe informatique devrait pouvoir voir d’un coup d’œil si tout va bien ou non et si aucune intervention supplémentaire n’est nécessaire.

La surveillance de la santé des données de haut niveau prend en compte toutes les anomalies au niveau de l’entreprise - des éléments qui semblent incorrects lorsqu’ils sont observés d’un point de vue commercial. La santé des données de haut niveau couvre des éléments tels que des niveaux de stock négatifs ou des quantités de commande minimales anormalement élevées. Elle couvre également des choses comme des prix qui n’ont aucun sens car l’entreprise fonctionnerait à perte ou avec des marges ridiculement élevées. La santé des données de haut niveau tente de couvrir tous les éléments où un praticien de la supply chain regarderait les données et dirait : “Ça ne peut pas être vrai ; nous avons un problème.”

Contrairement au rapport de santé des données de bas niveau, le rapport de santé des données de haut niveau est principalement destiné à l’équipe de la supply chain. En effet, des problèmes tels que des quantités de commande minimales anormales ne seront perçus comme des problèmes que par un praticien qui est quelque peu familiarisé avec l’environnement commercial. L’objectif de ce rapport est de pouvoir dire d’un coup d’œil que tout va bien et qu’aucune intervention supplémentaire n’est nécessaire.

Auparavant, j’ai dit que le système analytique était censé être sans état. Eh bien, il s’avère que la santé des données est l’exception qui confirme la règle. En effet, de nombreux problèmes peuvent être identifiés en comparant les indicateurs actuels avec les mêmes indicateurs collectés les jours précédents. Ainsi, la surveillance de la santé des données persiste généralement une sorte d’état, qui sont essentiellement des indicateurs clés tels qu’observés au cours des jours précédents, afin de pouvoir identifier les valeurs aberrantes dans l’état actuel des données. Cependant, comme la santé des données est une question pure de surveillance, le pire qui puisse arriver s’il y a un problème au niveau du lac de données qui est corrigé, puis que nous avons des échos de problèmes passés dans l’état de la santé des données, ce sont une série de fausses alarmes provenant de ces rapports. La logique qui génère les décisions de la supply chain reste entièrement sans état ; l’état ne concerne qu’une petite partie de l’instrumentation.

La surveillance de la santé des données, tant au niveau bas qu’au niveau élevé, est une question de compromis entre le risque de fournir des décisions incorrectes et le risque de ne pas fournir de décisions à temps. Lorsque l’on examine de grandes supply chains, il n’est pas raisonnable de s’attendre à ce que 100 % des données soient correctes - des entrées transactionnelles incorrectes se produisent, même si elles sont rares. Ainsi, il doit y avoir un volume de problèmes qui devrait être considéré comme suffisamment faible pour que la recette numérique puisse fonctionner. Le compromis entre ces deux risques - être trop sensible aux problèmes de données ou être trop tolérant aux problèmes de données - dépend fortement de la structure économique de la supply chain.

Chez Lokad, nous concevons et affinons ces rapports au cas par cas pour chaque client. Au lieu de traquer tous les cas concevables de corruption des données, le scientifique de la supply chain, qui est chargé de mettre en œuvre la santé des données de bas niveau et de haut niveau ainsi que les inspecteurs de données dont je parlerai dans un instant, essaie d’ajuster la surveillance de la santé des données pour être sensible aux problèmes qui sont réellement dommageables et qui se produisent réellement pour la supply chain concernée.

Dans le jargon de Lokad, un inspecteur de données, ou simplement un inspecteur, est un rapport qui consolide toutes les données pertinentes concernant un objet d’intérêt. L’objet d’intérêt est censé être l’un des citoyens de première classe du point de vue de la supply chain - un produit, un fournisseur, un client ou un entrepôt. Par exemple, si nous envisageons un inspecteur de données pour les produits, alors pour n’importe quel produit vendu par l’entreprise, nous devrions pouvoir voir à travers l’inspecteur sur un seul écran toutes les données qui sont attachées à ce produit. Dans l’inspecteur de données pour les produits, il y a effectivement autant de vues qu’il y a de produits, car lorsque je dis que nous voyons toutes les données, je veux dire toutes les données qui sont attachées à un code-barres ou à un numéro de pièce, et non à tous les produits en général.

Contrairement aux rapports de santé des données de bas niveau et de haut niveau qui sont censés être deux tableaux de bord qui peuvent être inspectés en un coup d’œil, les inspecteurs sont mis en œuvre pour répondre aux questions et préoccupations qui se posent invariablement lors de la conception et de l’exploitation de la recette numérique de base. En effet, pour prendre une décision d’approvisionnement, il n’est pas rare de consolider des données provenant d’une douzaine de tables, provenant éventuellement de plusieurs systèmes transactionnels. Comme les données sont éparpillées partout, lorsqu’une décision semble suspecte, il est généralement difficile de localiser l’origine du problème. Il peut y avoir un décalage entre les données telles qu’elles sont perçues par le système analytique et les données qui existent dans le système transactionnel. Il peut y avoir un algorithme défectueux qui échoue à capturer un modèle statistique dans les données. Il peut y avoir une perception incorrecte, et la décision qui est jugée suspecte pourrait en fait être correcte. Dans tous les cas, l’inspecteur est destiné à offrir la possibilité de zoomer sur l’objet d’intérêt.

Pour être utiles, les inspecteurs doivent refléter les spécificités à la fois de la supply chain et du paysage applicatif. En conséquence, la création d’inspecteurs est presque toujours un exercice sur mesure. Néanmoins, une fois le travail terminé, l’inspecteur représente l’un des piliers de l’instrumentation du système analytique lui-même.

En conclusion, alors que la plupart des initiatives quantitatives de la supply chain sont vouées à l’échec avant même leur lancement, cela ne doit pas être le cas. Un choix judicieux des livrables, des délais, de la portée et des règles est nécessaire pour éviter les problèmes qui condamnent invariablement ces initiatives à l’échec. Malheureusement, ces choix sont souvent quelque peu contre-intuitifs, comme Lokad l’a appris à ses dépens au cours des 14 années d’exploitation jusqu’à présent.

Le tout début de l’initiative doit être consacré à la mise en place d’un pipeline de données. Un pipeline de données peu fiable est l’un des moyens les plus sûrs de garantir l’échec de toute initiative axée sur les données. La plupart des entreprises, même la plupart des services informatiques, sous-estiment l’importance d’un pipeline de données hautement fiable qui ne nécessite pas de lutte constante contre les incendies. Alors que la majeure partie de la mise en place du pipeline de données incombe au service informatique, la supply chain elle-même doit être responsable de l’instrumentation du système analytique qu’elle exploite. Ne vous attendez pas à ce que le service informatique le fasse pour vous ; cela relève de l’équipe de la supply chain. Nous avons vu deux types d’instrumentation différents, à savoir les rapports de santé des données qui adoptent une perspective à l’échelle de l’entreprise et les inspecteurs de données, qui permettent des diagnostics approfondis.

Aujourd’hui, nous avons discuté de la façon de démarrer une initiative, mais la prochaine fois, nous verrons comment la terminer ou plutôt, espérons-le, comment la mener à bien. Dans la prochaine conférence, qui aura lieu le mercredi 14 septembre, nous avancerons dans notre parcours et verrons quel type d’exécution il faut pour élaborer une recette numérique de base, puis amener progressivement les décisions qu’elle génère en production. Nous examinerons également de plus près ce que cette nouvelle façon de faire la supply chain implique pour le fonctionnement quotidien des praticiens de la supply chain.

Maintenant, examinons les questions.

Question : Pourquoi exactement six mois est-il une limite de temps après laquelle une mise en œuvre n’est pas effectuée correctement ?

Je dirais que le problème n’est pas vraiment d’avoir six mois comme limite de temps. Le problème est que, généralement, les initiatives sont vouées à l’échec dès le départ. C’est ça le problème. Si votre initiative d’optimisation prédictive commence avec la perspective que les résultats seront livrés dans deux ans, il est presque garanti que l’initiative se dissoudra à un moment donné et échouera à livrer quoi que ce soit en production. Si je le pouvais, je préférerais que l’initiative réussisse en trois mois. Cependant, six mois représentent le délai minimal, d’après mon expérience, pour amener une telle initiative en production. Tout retard supplémentaire augmente le risque d’échec de l’initiative. Il est très difficile de compresser davantage ce délai, car une fois que vous avez résolu tous les problèmes techniques, les retards restants reflètent le temps nécessaire aux personnes pour se mettre en mouvement dans le cadre de l’initiative.

Question : Les praticiens de la supply chain peuvent être frustrés par une initiative qui remplace la majorité de leur charge de travail, comme le service des achats, en conflit avec l’automatisation des décisions. Comment conseilleriez-vous de gérer cela ?

C’est une question très importante, qui sera abordée, espérons-le, dans la prochaine conférence. Pour aujourd’hui, ce que je peux dire, c’est que je pense que la plupart de ce que les praticiens de la supply chain font dans les supply chains actuelles n’est pas très gratifiant. Dans la plupart des entreprises, les gens reçoivent un ensemble de références ou de numéros de pièces, puis les parcourent sans fin en prenant toutes les décisions nécessaires. Cela signifie que leur travail consiste essentiellement à regarder une feuille de calcul et à la parcourir une fois par semaine, voire une fois par jour. Ce n’est pas un travail épanouissant.

La réponse courte est que l’approche Lokad aborde le problème en automatisant tous les aspects routiniers du travail, de sorte que les personnes en place avec une véritable expertise dans la supply chain peuvent commencer à remettre en question les fondements de la supply chain. Cela leur permet de discuter davantage avec les clients et les fournisseurs pour rendre tout plus efficace. Il s’agit de recueillir des informations afin que nous puissions améliorer la recette numérique. L’exécution de la recette numérique est fastidieuse, et il y aura très peu de personnes qui regretteront l’époque où elles devaient parcourir des feuilles de calcul tous les jours.

Question : Les praticiens de la supply chain sont-ils censés travailler avec des rapports de santé des données afin de remettre en question les décisions générées par les scientifiques de la supply chain ?

Les praticiens de la supply chain sont censés travailler avec des inspecteurs de données, et non avec des rapports de santé des données. Les rapports de santé des données sont comme une évaluation à l’échelle de l’entreprise qui répond à la question de savoir si les données à l’entrée du système analytique sont suffisamment bonnes pour qu’une recette numérique puisse fonctionner sur l’ensemble de données. Le résultat du rapport de santé des données est une décision binaire : donner le feu vert à l’exécution de la recette numérique ou s’y opposer et dire qu’il y a un problème à résoudre. Les inspecteurs de données, qui seront discutés plus en détail dans la prochaine leçon, sont le point d’entrée pour les praticiens de la supply chain afin d’obtenir des informations sur une décision de supply chain proposée.

Question : Est-il possible de mettre à jour un modèle analytique, par exemple, en définissant une politique d’inventaire quotidiennement ? Le système de supply chain ne peut pas répondre aux changements de politique quotidiens, ne va-t-il pas simplement générer du bruit dans le système ?

Pour répondre à la première partie de la question, mettre à jour un modèle analytique quotidiennement est certainement faisable. Par exemple, lorsque Lokad opérait en 2020 avec des confinements en Europe, nous avions des pays qui fermaient et rouvraient avec seulement 24 heures de préavis. Cela a créé une situation extrêmement chaotique qui nécessitait des révisions immédiates constantes sur une base quotidienne. Lokad a fonctionné sous cette pression extrême, gérant des confinements qui commençaient ou se terminaient quotidiennement dans toute l’Europe pendant près de 14 mois.

Donc, mettre à jour un modèle analytique quotidiennement est faisable, mais pas nécessairement souhaitable. Il est vrai que les systèmes de supply chain ont beaucoup d’inertie, et la première chose qu’une recette numérique appropriée doit reconnaître est l’effet cliquet de la plupart des décisions. Une fois que vous avez commandé la production et que les matières premières sont consommées, vous ne pouvez pas annuler la production. Vous devez prendre en compte le fait que de nombreuses décisions ont déjà été prises lors de la prise de nouvelles décisions. Cependant, lorsque vous réalisez que votre supply chain a besoin d’un changement radical dans son mode d’action, il n’y a pas de raison de retarder cette correction simplement pour retarder la décision. Le meilleur moment pour mettre en œuvre le changement, c’est maintenant.

En ce qui concerne l’aspect du bruit de la question, cela dépend de la conception correcte des recettes numériques. Il existe de nombreuses conceptions incorrectes qui sont instables, où de petits changements dans les données génèrent de grands changements dans les décisions représentant le résultat de la recette numérique. Une recette numérique ne doit pas être instable à chaque petite fluctuation dans la supply chain. C’est pourquoi Lokad a adopté une perspective probabiliste sur la prévision. Lors de l’utilisation d’une perspective probabiliste, les modèles peuvent être conçus pour être beaucoup plus stables par rapport aux modèles qui tentent de capturer la moyenne et qui sont instables chaque fois qu’un écart survient dans la supply chain.

Question : L’un des problèmes auxquels nous sommes confrontés dans la supply chain avec de très grandes entreprises est leur dépendance à l’égard de différents systèmes sources. N’est-il pas extrêmement difficile de regrouper toutes les données de ces systèmes sources sous un système unifié ?

Je suis tout à fait d’accord pour dire que l’obtention de toutes les données est un défi important pour de nombreuses entreprises. Cependant, nous devons nous demander pourquoi c’est un défi en premier lieu. Comme je l’ai mentionné précédemment, 99% des applications métier exploitées par les grandes entreprises de nos jours reposent sur des bases de données transactionnelles courantes et bien conçues. Il peut encore y avoir quelques implémentations COBOL super anciennes fonctionnant sur un stockage binaire obscur, mais cela est rare. La grande majorité des applications métier, même celles déployées dans les années 1990, fonctionnent avec une base de données transactionnelle de qualité de production propre en backend.

Une fois que vous disposez d’un backend transactionnel, pourquoi serait-il difficile de copier ces données vers un data lake ? La plupart du temps, le problème est que les entreprises ne se contentent pas de copier les données - elles essaient d’en faire beaucoup plus. Elles essaient de préparer et de transformer les données, souvent en compliquant le processus. La plupart des configurations de bases de données modernes disposent de capacités intégrées de mise en miroir des données, vous permettant de répliquer toutes les modifications d’une base de données transactionnelle vers une base de données secondaire. Il s’agit d’une propriété intégrée pour probablement les 20 systèmes transactionnels les plus utilisés sur le marché.

Les entreprises ont tendance à avoir du mal à consolider les données parce qu’elles essaient d’en faire trop, et leurs initiatives s’effondrent sous leur propre complexité. Une fois les données consolidées, les entreprises commettent souvent l’erreur de penser que la connexion des données doit être effectuée par les équipes informatiques, de BI ou de data science. Le point que je veux souligner ici, c’est que la supply chain doit être responsable de ses propres recettes numériques, tout comme le marketing, les ventes et la finance. Ce ne devrait pas être une division de support transversale qui essaie de le faire pour l’entreprise. La connexion des données provenant de différents systèmes nécessite généralement de nombreuses connaissances métier. Les grandes entreprises échouent souvent parce qu’elles essaient de faire faire ce travail par un expert des équipes informatiques, de BI ou de data science, alors qu’il devrait être réalisé au sein de la division concernée.

Merci beaucoup pour votre temps aujourd’hui, votre intérêt et vos questions. À bientôt après l’été, en septembre.