Les livrables du projet

L’objectif de la Supply Chain Quantitative est de fournir des décisions concrètes – des quantités suggérées pour les bons de commande étant un exemple archétypal. Ci-dessous, nous clarifions davantage la forme spécifique et le mécanisme de livraison de ces décisions. Établir des attentes claires pour les livrables est une étape importante dans le parcours que représente la Supply Chain Quantitative. De plus, les résultats numériques optimisés ne sont pas l’unique sortie souhaitable : plusieurs autres résultats, notamment la surveillance de la qualité des données et les KPI de gestion, doivent également être inclus dans le livrable. En pratique, les livrables d’une initiative de Supply Chain Quantitative dépendent de la flexibilité de la solution logicielle utilisée pour soutenir l’initiative elle-même. Néanmoins, ils sont principalement définis par leur intention, qui est indépendante de la technologie utilisée.

Scripts en tant que livrable

La Supply Chain Quantitative met l’accent sur des pipelines de données entièrement automatisés. Cela n’implique pas que l’installation logicielle doive fonctionner de manière autonome. Un haut degré de supervision rapprochée est naturellement souhaitable dès qu’une supply chain de grande envergure est envisagée. Néanmoins, le pipeline de données doit être entièrement automatisé dans le sens où aucune étape du pipeline ne dépend d’une opération manuelle. En effet, comme le manifeste le souligne, dès qu’une opération manuelle est impliquée dans le traitement des données de la supply chain, la solution ne peut tout simplement pas être mise à l’échelle en pratique.

Par conséquence directe de ce constat, les livrables d’une initiative de Supply Chain Quantitative sont invariablement de véritables pièces de logiciel. Cela n’implique pas que l’équipe en charge doive tout réimplémenter : une solution logicielle dédiée à la Supply Chain Quantitative offre la possibilité de se concentrer strictement sur les aspects pertinents des défis de supply chain. Toutes les subtilités techniques de bas niveau, telles que l’exploitation de ressources de calcul distribuées auto-allouées au sein d’une plateforme de cloud computing, sont censées être abstraites. L’équipe n’a pas besoin de se pencher sur ces questions, car ces aspects sont supposés être gérés de manière appropriée par les outils eux-mêmes.

Les livrables se matérialisent sous forme de scripts, typiquement écrits dans un langage de programmation capable de répondre aux exigences de la supply chain, tout en offrant un haut niveau de productivité. Le terme “script” est utilisé ici plutôt que “source code”, mais les deux termes sont étroitement liés : un “script” souligne l’idée d’un haut degré d’abstraction et d’un focus sur la tâche elle-même, tandis qu’un “source code” met en avant une perspective de niveau inférieur, destinée à être une représentation fidèle du matériel informatique lui-même. Pour la Supply Chain Quantitative, c’est évidemment la perspective supply chain qui compte le plus, et non le matériel informatique, qui est un aspect technique d’importance secondaire.

Au cours de la dernière décennie, le succès des interfaces utilisateur WYSIWYG (what-you-see-is-what-you-get) pour les applications destinées aux clients finaux a conduit de nombreux vendeurs de logiciels de supply chain à tenter d’imiter cette approche avec une solution WYSIWYG pour la planification et l’optimisation supply chain. Cependant, la leçon tirée de l’échec quasi systématique de ce type d’interfaces est que les supply chains sont complexes et ne peuvent contourner le besoin d’outils programmatiques. D’après notre expérience, s’attendre à ce qu’un outil de type glisser-déposer reflète correctement les non-linéarités complexes impliquées dans, par exemple, des MOQ chevauchantes (quantités minimales de commande), est au mieux illusoire. Une expressivité programmatique est nécessaire, car sinon, le défi de la supply chain ne peut même pas être exprimé dans l’outil.

Naturellement, du point de vue de l’utilisateur final, les scripts ne sont pas ce à quoi les praticiens de la supply chain s’attendraient comme résultat tangible d’une initiative de Supply Chain Quantitative. Les utilisateurs interagiront avec des dashboards qui contiennent des KPI consolidés et des tableaux rassemblant les décisions suggérées. Cependant, ces dashboards sont transitoires et jetables. Ils sont simplement obtenus en exécutant à nouveau les scripts sur les données supply chain pertinentes. Bien que la distinction soit un peu subtile, il est important de ne pas confondre le script, qui représente le véritable livrable, avec son expression numérique, qui est typiquement ce que l’utilisateur final de la solution peut voir.

Tableaux de bord de la santé des données

Avant d’envisager la livraison de décisions optimisées pour la supply chain, nous devons nous assurer que les données traitées par le système qui supporte l’initiative de Supply Chain Quantitative sont à la fois correctes sur le plan numérique et sémantique. Le but des tableaux de bord de surveillance de la santé des données, ou simplement tableaux de bord de la santé des données, est d’assurer un haut degré de confiance dans la justesse des données, ce qui est naturellement une exigence essentielle pour la précision de tous les résultats numériques renvoyés par la solution. Ces dashboards assistent également l’équipe supply chain dans l’amélioration de la qualité des données existantes.

Les erreurs numériques sont simples : le fichier CSV exporté de l’ERP indique que le produit ABC dispose de 42 unités en stock, alors que la console web de l’ERP ne rapporte que 13 unités en stock. Il est manifeste que nous avons des chiffres divergents alors qu’ils devraient être identiques. Les tableaux de bord de la santé des données traitent ces problèmes relativement évidents en vérifiant simplement que les agrégats de données restent dans les plages numériques attendues.

Les erreurs sémantiques sont plus subtiles et, en pratique, beaucoup plus difficiles à identifier. La majeure partie du travail réalisé lors de la préparation des données consiste en réalité à identifier et corriger toutes les erreurs sémantiques. Par exemple : le champ stockinv dans l’ERP pourrait être documenté comme étant le stock disponible. Ainsi, l’équipe supply chain suppose que cette quantité ne peut jamais être négative, car, évidemment, si ces unités sont physiquement accessibles sur l’étagère, il doit s’agir d’une quantité positive. Pourtant, la documentation de l’ERP pourrait également s’avérer légèrement trompeuse, et cette quantité aurait été plus justement nommée stock disponible, car dès qu’une rupture de stock survient et que le client émet une commande en souffrance, la quantité peut devenir négative pour refléter qu’un certain nombre d’unités sont déjà dues à un client. Ce cas illustre une erreur sémantique : le nombre n’est pas faux en soi - c’est la compréhension du nombre qui est approximative. En pratique, ces approximations sémantiques peuvent générer de nombreux comportements inconsistants, qui, à leur tour, génèrent des coûts de friction continus au sein de la supply chain.

Les tableaux de bord de la santé des données consolident des chiffres qui permettent à l’entreprise de décider sur-le-champ si les données peuvent être considérées comme suffisamment fiables ou non. En effet, puisque la solution va être utilisée quotidiennement pour des objectifs de production, il est impératif qu’un problème de données significatif soit identifié par une inspection quasi-instantanée. Dans le cas contraire, il y a de fortes chances que la supply chain fonctionne pendant des jours, voire des semaines, sur des données défectueuses. À cet égard, le tableau de bord de la santé des données est semblable à un feu de circulation : vert, vous passez ; rouge, vous vous arrêtez.

De plus, lorsqu’on considère une supply chain de grande envergure, il y a généralement une quantité irréductible de données corrompues ou autrement erronées. Ces données proviennent d’entrées manuelles défectueuses ou de cas limites rares dans les systèmes de l’entreprise eux-mêmes. En pratique, pour toute supply chain de grande taille, il est déraisonnable d’attendre que les données supply chain soient 100% exactes. Au lieu de cela, nous devons nous assurer que les données sont suffisamment précises pour que les coûts de friction générés par ces erreurs restent quasi négligeables.

Ainsi, on s’attend également à ce que les tableaux de bord de la santé des données recueillent des statistiques sur les erreurs de données identifiées. Ces statistiques sont essentielles pour établir que les données peuvent être considérées comme fiables. À cet effet, un Supply Chain Scientist est souvent sollicité pour établir des seuils d’alerte bien choisis, généralement associés à un arrêt brutal de la solution. Il convient de faire preuve de prudence dans l’établissement de ces seuils, car s’ils sont trop bas, la solution devient inutilisable, étant arrêtée trop fréquemment pour des “problèmes de données identifiés” ; toutefois, s’ils sont trop élevés, les coûts de friction générés par les erreurs de données peuvent devenir significatifs et compromettre les avantages apportés par l’initiative elle-même.

Au-delà du signalement par vert-rouge, les tableaux de bord de la santé des données sont également destinés à offrir des insights priorisés sur les efforts d’amélioration des données. En effet, de nombreux points de données peuvent être erronés mais également sans importance. Par exemple, il importe peu que le prix d’achat d’un produit soit incorrect si la demande du marché pour ce produit a disparu il y a des années, puisque il n’y aura plus aucun bon de commande pour ce produit.

La Supply Chain Quantitative souligne que la résolution fine des erreurs de données, qui peut impliquer une quantité considérable de travail manuel, doit être priorisée par rapport à l’impact financier estimé de l’erreur de données elle-même contre le coût de main-d’œuvre associé à la correction. En effet, selon la situation, le coût associé à la correction d’un seul point de données erroné varie énormément, et doit être pris en compte dans la priorisation suggérée. Enfin, lorsque le coût des corrections est jugé plus élevé que les coûts supply chain générés par ces erreurs, le processus d’amélioration des données peut s’arrêter.

Tableaux de bord de décisions priorisées

Comme nous l’avons vu, seules les décisions supply chain peuvent être véritablement évaluées d’un point de vue quantitatif. Il n’est donc pas surprenant que l’unique livrable opérationnel clé d’une initiative de Supply Chain Quantitative soit les tableaux de bord qui consolident les décisions obtenues sous forme de résultat numérique final de l’ensemble du pipeline de données. Un tel dashboard peut être aussi simple qu’un tableau listant, pour chaque produit, la quantité exacte en unités à commander immédiatement. Si des MOQ (quantités minimales de commande) sont présentes - ou toute autre contrainte de commande - alors les quantités suggérées seront la plupart du temps nulles, jusqu’à ce que les seuils appropriés soient atteints.

Pour simplifier, nous supposons ici que ces résultats numériques sont rassemblés dans un dashboard, qui est une forme spécifique d’interface utilisateur. Cependant, le dashboard lui-même n’est qu’une option, qui peut ou non être pertinente. En pratique, on s’attend à ce que le logiciel pilotant l’initiative de Supply Chain Quantitative soit très flexible, c’est-à-dire programmatiquement flexible, offrant de nombreuses manières de conditionner ces résultats dans divers formats de données. Par exemple, les résultats numériques peuvent être consolidés dans des fichiers texte simples, destinés à être automatiquement importés dans l’ERP principal utilisé pour gérer les actifs de l’entreprise.

Bien que le format des décisions dépende fortement de la tâche supply chain abordée, la plupart des tâches requièrent de prioriser ces décisions. Par exemple, l’acte de calculer les quantités suggérées pour une commande peut être décomposé à travers une liste priorisée d’unités à acquérir. L’unité la plus rentable est classée en première position. Comme les stocks présentent des rendements décroissants, la deuxième unité acquise pour le même produit répond à une fraction décroissante de la demande du marché. Par conséquent, la deuxième unité pour ce même produit peut ne pas être la deuxième entrée de la liste globale. Au lieu de cela, la deuxième unité la plus rentable peut être associée à un autre produit, etc. La liste priorisée des unités à acquérir est conceptuellement sans fin : il est toujours possible d’acheter une unité de plus. Comme la demande du marché est finie, toutes les unités achetées deviendraient des invendus à un certain moment. Transformer cette liste de priorités en quantités finales à commander ne nécessite que l’introduction d’un critère d’arrêt, et la somme des quantités par produit. En pratique, les contraintes de commande non linéaires compliquent encore cette tâche, mais, pour simplifier, nous mettrons ces contraintes de côté à ce stade de la discussion.

La priorisation des décisions est une opération très naturelle du point de vue de la Supply Chain Quantitative. Comme chaque décision est associée à un résultat financier exprimé en dollars, classer les décisions de la plus rentable à la moins rentable est simple. Ainsi, de nombreux dashboards compilant les décisions supply chain suggérées peuvent, en pratique, être attendus comme des listes de décisions priorisées. Ces dashboards contiennent des listes avec les décisions les plus rentables en haut, et les moins rentables en bas. Alternativement, les praticiens de la supply chain peuvent décider de tronquer les listes lorsque les décisions sont non rentables. Cependant, il y a fréquemment des insights à obtenir en pouvant inspecter des décisions qui se situent juste en dessous du seuil de rentabilité – même si l’on ne s’attend évidemment pas à ce que l’entreprise agisse sur ces entrées non rentables.

Pour fournir ce type de dashboards axés sur les décisions, la solution logicielle supportant la Supply Chain Quantitative doit explorer numériquement d’immenses quantités de décisions possibles. Par exemple, la solution devrait être capable de considérer l’impact financier de l’achat de chaque unité, unité par unité, pour chaque produit dans chaque emplacement. Sans surprise, cette opération peut nécessiter d’importantes ressources informatiques. Heureusement, de nos jours, le matériel informatique est capable de gérer même les plus grandes supply chains globales. En supposant que la solution logicielle sous-jacente soit correctement architecturée pour la Supply Chain Quantitative, l’évolutivité du traitement des données ne devrait pas poser de problème pour les équipes supply chain.

Whiteboxing des résultats numériques

Les systèmes désignés avec dérision comme boîtes noires dans la supply chain, et dans d’autres domaines également, sont des systèmes qui génèrent des résultats qui ne peuvent pas être expliqués par les praticiens qui interagissent avec ces systèmes. La Supply Chain Quantitative, avec son focus spécifique sur un pipeline de données automatisé, fait également face au risque de livrer ce que les équipes supply chain qualifieraient de “black boxes”. En effet, les implications financières des décisions supply chain sont très importantes pour une entreprise, et, bien qu’un système plus récent puisse améliorer la situation, il peut également potentiellement créer des disasters. Bien que l’automatisation soit très souhaitable, cela ne signifie pas que l’équipe supply chain ne doit pas avoir une compréhension approfondie de ce qui est livré par le pipeline de données soutenant l’initiative de Supply Chain Quantitative.

Le terme whiteboxing se réfère à l’effort nécessaire pour rendre la solution entièrement transparente au bénéfice des équipes supply chain. Cette approche souligne qu’aucune technologie n’est transparente par conception. La transparence est le résultat final d’un effort spécifique, qui fait partie intégrante de l’initiative elle-même. Même une simple régression linéaire peut générer des résultats déconcertants en pratique. À l’exception de quelques individus exceptionnels, la plupart des gens n’ont pas une compréhension intuitive de ce à quoi devrait ressembler la sortie « attendue » du modèle linéaire dès lors que 4 dimensions ou plus sont impliquées. Pourtant, les problèmes supply chain impliquent souvent des dizaines de variables, voire des centaines. Ainsi, même les modèles statistiques simplistes sont de facto des boîtes noires pour les praticiens supply chain. Naturellement, lorsque des algorithmes de machine learning sont utilisés, comme le recommande la Supply Chain Quantitative, ils laissent les praticiens encore plus dans l’ombre.

Bien que l’effet de boîte noire soit un véritable problème, une solution réaliste ne réside pas dans la simplification du traitement des données en calculs immédiatement intuitifs pour l’esprit humain. Cette approche est une recette d’inefficacité extrême, qui démolit entièrement tous les bénéfices des ressources informatiques modernes, qui peuvent être utilisées pour s’attaquer à la complexité brute des supply chains modernes. Simplifier à outrance le processus n’est pas la solution. Le whiteboxing l’est.

Même les recommandations supply chain les plus complexes peuvent être rendues en grande partie transparentes pour les praticiens supply chain, simplement en décomposant les calculs internes à l’aide de indicateurs financiers, qui représentent les Facteurs Economiques soutenant la recommandation elle-même. Par exemple, au lieu d’afficher simplement un tableau nu à deux colonnes — produit et quantité — en tant que commande d’achat suggérée, le tableau devrait inclure quelques colonnes supplémentaires facilitant la prise de décision. Ces colonnes peuvent comprendre le stock actuel, la demande totale sur le dernier mois, le lead time attendu, le coût financier prévu en cas de rupture de stocks (si aucune commande n’est passée), le coût financier prévu d’un excès de stocks (risque associé à la commande suggérée), etc. Les colonnes sont conçues afin de fournir aux équipes supply chain des vérifications rapides de cohérence des quantités suggérées. Grâce à ces colonnes, l’équipe peut rapidement instaurer une confiance dans le résultat numérique et identifier certaines faiblesses d’une solution nécessitant des améliorations supplémentaires.

Étendre les tableaux de bord dans un but de whiteboxing relève en partie de l’art. Générer des millions de chiffres est facile, même en ayant accès à des ressources informatiques n’excédant pas celles disponibles sur un smartphone. Pourtant, générer 10 chiffres dignes d’être examinés quotidiennement est très difficile. Ainsi, le principal défi consiste à identifier une douzaine ou moins de KPI suffisants pour éclairer les décisions supply chain recommandées. De bons KPI requièrent généralement beaucoup de travail ; ils ne devraient pas être des définitions naïves, généralement trompeuses en supply chain. Par exemple, même une colonne aussi simple que le “prix d’achat unitaire” peut être très trompeuse si le fournisseur propose par hasard des remises sur volume, rendant ainsi le prix d’achat dépendant de la quantité achetée.

Tableaux de bord stratégiques

Alors que l’accent sur les décisions à petite échelle est nécessaire — l’une des rares approches permettant une évaluation quantitative des performances — la supply chain peut aussi nécessiter des ajustements à plus grande échelle, plus disruptifs, afin de porter la performance à un niveau supérieur. Par exemple, l’achat de davantage d’unités de stocks judicieusement choisies augmente marginalement le taux de service. Cependant, à un certain moment, l’entrepôt est plein, et aucune unité supplémentaire ne peut être acquise. Dans cette situation, il convient d’envisager un entrepôt plus grand. Pour évaluer l’impact de la levée de cette limitation, nous pouvons supprimer la contrainte de capacité de l’entrepôt des calculs et évaluer le potentiel financier global lié à l’exploitation d’un entrepôt de grande taille et arbitraire. La gestion de la supply chain pourra alors surveiller l’indicateur financier associé au coût de friction imposé par la capacité d’entreposage et décider quand il sera temps d’augmenter cette capacité.

Typiquement, les supply chains fonctionnent selon de nombreuses contraintes qui ne peuvent être révisées quotidiennement. Ces contraintes peuvent inclure le fonds de roulement, la capacité d’entreposage, les retards de transport, le débit de production, etc. Chaque contrainte est associée à un coût d’opportunité implicite pour la supply chain, qui se traduit généralement par plus de stocks, plus de retards ou davantage de ruptures de stocks. Le coût d’opportunité peut être évalué en mesurant les gains de performance qui seraient obtenus en supprimant ou en affaiblissant la contrainte elle-même. Bien que certaines de ces simulations puissent s’avérer difficiles à mettre en œuvre, elles ne sont fréquemment pas plus ardues que l’optimisation des décisions routinières, c’est-à-dire l’établissement des quantités des commandes d’achat.

La Supply Chain Quantitative souligne que les coûts d’opportunité associés à ces contraintes devraient faire partie du pipeline de production de données et, typiquement, être matérialisés par des tableaux de bord dédiés, spécifiquement conçus pour aider la gestion de la supply chain à décider quand il est temps d’apporter des changements majeurs. Ces types de tableaux de bord sont désignés sous le nom de tableaux de bord stratégiques. Cette approche diffère de la pratique supply chain traditionnelle qui privilégie les initiatives ad hoc lorsqu’elle estime que la supply chain est sur le point d’atteindre une limite opérationnelle. En effet, les KPI fournis par les tableaux de bord stratégiques sont actualisés quotidiennement, ou plus fréquemment si nécessaire, tout comme le reste du pipeline de données. Ils n’ont pas besoin de faire un effort de dernière minute, car ils sont à jour et prêts à capitaliser sur les enseignements tirés d’une initiative de longue durée.

Les tableaux de bord stratégiques soutiennent le processus de prise de décision de la gestion de la supply chain. Puisqu’ils font partie du pipeline de données, dès que le marché commence à évoluer à un rythme plus rapide que d’habitude, les KPI restent à jour par rapport à la situation actuelle de l’entreprise. Cette approche évite les écueils traditionnels des investigations ad hoc qui ne font qu’ajouter des retards supplémentaires aux problèmes déjà en souffrance. Elle atténue également en grande partie le problème des décisions stratégiques précipitées qui s’avèrent non rentables — une condition regrettable qui aurait pu être anticipée dès le départ.

Tableaux de bord inspecteurs

Les supply chains sont à la fois complexes et erratiques. Ces propriétés rendent la débogage du pipeline de données une tâche redoutablement difficile. Pourtant, ce pipeline de données constitue la colonne vertébrale de l’initiative de la Supply Chain Quantitative. Des erreurs de traitement des données, ou bugs, peuvent survenir n’importe où dans ce pipeline. Pire encore, le type d’erreur le plus fréquent n’est pas une formule incorrecte, mais une sémantique ambiguë. Par exemple, au début du pipeline, la variable stockinv pourrait désigner les stocks disponibles (où des valeurs négatives sont possibles), alors que plus tard, cette même variable est utilisée pour signifier des stocks en main (où des valeurs positives sont attendues). Cette interprétation ambiguë de la variable stockinv peut engendrer une grande variété de comportements erronés, allant de plantages systèmes — évidents, et donc modérément nuisibles — à une corruption silencieuse et généralisée des décisions supply chain.

Comme les supply chains sont presque toujours constituées d’un ensemble unique de solutions logicielles mises en place au fil des années, il n’existe aucun espoir d’accéder à une solution logicielle “prouvée” et exempte de bugs. En effet, la plupart des problèmes surgissent aux frontières des systèmes, lors de la réconciliation des données provenant de systèmes différents, voire simplement des modules différents au sein d’un même système. Ainsi, peu importe à quel point la solution logicielle peut être éprouvée, les outils doivent être capables de prendre en charge efficacement le processus de débogage, car ce genre de problème est inévitable.

Le but des tableaux de bord inspecteurs est de fournir des vues détaillées permettant une inspection minutieuse des ensembles de données supply chain. Toutefois, ces tableaux de bord ne se contentent pas d’une simple analyse descendante des tables de données d’entrée. Une telle approche de forage, ou toute méthode similaire de segmentation des données, manquerait l’essentiel. Les supply chains reposent avant tout sur les flux — flux de matériaux, flux de paiements, etc. Certains des problèmes de données les plus graves surviennent lorsque la continuité du flux est « logiquement » rompue. Par exemple, lors du transfert de marchandises de l’entrepôt A vers l’entrepôt B, la base de données de l’entrepôt B pourrait manquer de quelques entrées de produit, générant ainsi de subtiles corruptions de données, car des unités provenant de l’entrepôt A sont reçues dans l’entrepôt B sans être correctement associées à leur produit. Lorsque les résultats numériques semblent anormaux, ces tableaux de bord inspecteurs constituent l’option par excellence pour que le Supply Chain Scientist réalise une rapide investigation par échantillonnage des données.

En pratique, un tableau de bord inspecteur offre un point d’entrée de bas niveau, tel qu’un code produit ou un SKU, et consolide toutes les données associées à ce point d’entrée en une vue unique. Lorsque les marchandises circulent à travers de nombreux emplacements, comme c’est le cas, par exemple, dans les supply chains aérospatiales, le tableau de bord inspecteur tente généralement de reconstituer les trajectoires des marchandises, lesquelles ont pu transiter non seulement par plusieurs emplacements physiques, mais également par de multiples systèmes. En rassemblant toutes ces données en un seul endroit, il devient possible pour le Supply Chain Scientist d’évaluer si les données ont du sens : est-il possible d’identifier d’où proviennent les marchandises expédiées ? Les mouvements de stocks sont-ils alignés avec les politiques supply chain officielles, etc. ? Le tableau de bord inspecteur est un outil de « débogage » conçu pour rassembler des données étroitement couplées, non pas d’un point de vue informatique, mais d’un point de vue supply chain.

Une des questions les plus étranges auxquelles Lokad a fait face lors de l’analyse des ensembles de données supply chain fut le cas des pièces téléportées. L’entreprise — dans ce cas, une compagnie aérienne — disposait de pièces d’avion stockées à la fois en Europe continentale et en Asie du Sud. Comme la sécurité des avions est une exigence absolue pour opérer, l’entreprise tenait des registres impeccables des mouvements de stocks pour toutes ses pièces. Pourtant, en utilisant un tableau de bord inspecteur nouvellement conçu, l’équipe de Lokad s’est aperçue que certaines pièces se déplaçaient d’Asie vers l’Europe, et vice versa, supposément en seulement 2 ou 3 minutes. Étant donné que les pièces d’avion sont transportées par avion, le temps de transport aurait dû être d’au moins une dizaine d’heures — certainement pas quelques minutes. Nous avons immédiatement suspecté un problème de fuseau horaire ou un autre souci lié à l’heure informatique, mais les enregistrements temporels se sont également révélés impeccables. En approfondissant l’analyse des données, il est apparu que les pièces téléportées étaient effectivement utilisées et montées sur les avions dès leur lieu d’atterrissage, une découverte d’autant plus déconcertante. En laissant les équipes supply chain examiner elles-mêmes les tableaux de bord inspecteurs, le mystère fut finalement élucidé. Les pièces téléportées étaient des roues d’avion composées de deux demi-roues et d’un pneu. La roue pouvait être démontée en séparant les deux demi-roues et le pneu. Dans le cas extrême, si les deux demi-roues et les pneus étaient retirés, il ne restait rien de physique. Ainsi, la roue entièrement démontée pouvait être remontée librement n’importe où, sans tenir compte de son emplacement d’origine.

Les tableaux de bord inspecteurs sont le pendant à bas niveau du tableau de bord de la santé des données. Ils se concentrent sur des données entièrement désagrégées, tandis que les tableaux de bord de la santé des données adoptent généralement une approche plus globale. De plus, les tableaux de bord inspecteurs font typiquement partie intégrante de l’effort de whiteboxing. Face à une recommandation déconcertante, les praticiens supply chain doivent examiner de près un SKU ou un produit afin de déterminer si la décision recommandée est raisonnable ou non. Le tableau de bord inspecteur est généralement adapté dans ce but précis en incluant de nombreux résultats intermédiaires qui contribuent au calcul de la recommandation finale.