Livrables du projet

L’objectif de la Supply Chain Quantitative est de fournir des décisions exploitables, telles que les quantités suggérées pour les bons de commande, qui en sont un exemple archétypal. Ci-dessous, nous clarifions davantage la forme spécifique et le mécanisme de livraison de ces décisions. Fixer 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 les seules sorties souhaitables : plusieurs autres sorties, notamment la surveillance de la santé des données et les indicateurs de gestion, doivent également être incluses dans les livrables. 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 livrables

La Supply Chain Quantitative met l’accent sur les pipelines de données entièrement automatisés. Cela n’implique pas que la configuration logicielle est censée fonctionner de manière autonome. Une supervision étroite est naturellement souhaitable chaque fois qu’une chaîne d’approvisionnement à grande échelle est envisagée. Néanmoins, le pipeline de données est censé être entièrement automatisé dans le sens où aucune étape du pipeline ne dépend réellement d’une opération manuelle. En effet, comme le souligne le manifeste, chaque fois que des opérations manuelles sont impliquées dans le traitement des données de la chaîne d’approvisionnement, la solution ne peut tout simplement pas être mise à l’échelle en pratique.

En conséquence directe de cette constatation, les livrables d’une initiative de Supply Chain Quantitative sont invariablement des ensembles de logiciels. Cela n’implique pas que l’équipe en charge est censée 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 la chaîne d’approvisionnement. Toutes les techniques de bas niveau, telles que l’utilisation de ressources informatiques distribuées allouées automatiquement au sein d’une plateforme de cloud computing, sont censées être abstraites. L’équipe n’a pas besoin de se plonger dans de tels détails, car ces aspects sont censés être gérés de manière appropriée par l’outil lui-même.

Les livrables se matérialisent sous la forme de scripts généralement écrits dans un langage de programmation capable de répondre aux exigences de la chaîne d’approvisionnement, tout en offrant un haut niveau de productivité. Le terme “script” est utilisé ici plutôt que “code source”, mais les deux termes sont étroitement liés : un “script” met l’accent sur l’idée d’un haut degré d’abstraction et d’une focalisation sur la tâche elle-même, tandis qu’un “code source” met l’accent sur une perspective de plus bas niveau, destinée à être un reflet précis du matériel informatique lui-même. Pour la Supply Chain Quantitative, c’est évidemment la perspective de la chaîne d’approvisionnement qui importe 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 incité de nombreux fournisseurs de logiciels de chaîne d’approvisionnement à essayer d’imiter cette approche avec une solution WYSIWYG pour la planification et l’optimisation de la chaîne d’approvisionnement. Cependant, l’enseignement tiré de l’échec quasi systématique de ces types d’interfaces est que les chaînes d’approvisionnement sont complexes et ne peuvent pas se passer d’outils programmatiques. D’après notre expérience, s’attendre à ce qu’un outil de glisser-déposer puisse refléter correctement les non-linéarités complexes impliquées, par exemple, dans les quantités minimales de commande (MOQ), relève de l’illusion. L’expressivité programmatique est nécessaire, car sinon, le défi de la chaîne d’approvisionnement 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 professionnels de la chaîne d’approvisionnement s’attendent à voir comme une production tangible de l’initiative de la Supply Chain Quantitative. Les utilisateurs interagiront avec des tableaux de bord qui contiennent des indicateurs de performance clés consolidés et des tableaux qui rassemblent les décisions suggérées. Cependant, ces tableaux de bord sont transitoires et jetables. Ils sont simplement obtenus en exécutant à nouveau les scripts sur les données pertinentes de la chaîne d’approvisionnement. Bien que la distinction soit un peu subtile, il est important de ne pas confondre le script, qui représente le livrable réel, avec son expression numérique, qui est généralement ce que vous pouvez voir en tant qu’utilisateur final de la solution.

Tableaux de bord de santé des données

Avant de considérer la fourniture de décisions optimisées pour la chaîne d’approvisionnement, nous devons nous assurer que les données traitées par le système qui soutient l’initiative de la Supply Chain Quantitative sont à la fois numériquement et sémantiquement correctes. L’objectif des tableaux de bord de surveillance de la santé des données, ou simplement des tableaux de bord de santé des données, est de garantir 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 tableaux de bord aident également l’équipe de la chaîne d’approvisionnement à améliorer la qualité des données existantes.

Les erreurs numériques sont simples : le fichier CSV exporté depuis l’ERP indique que le produit ABC a 42 unités en stock, tandis que la console web de l’ERP ne signale que 13 unités en stock. Il est évident ici que nous avons des chiffres divergents là où ils devraient être les mêmes. Les tableaux de bord de santé des données abordent 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 plupart du travail effectué lors de la préparation des données consiste en réalité à identifier et à résoudre toutes les erreurs sémantiques. Par exemple : le champ stockinv dans l’ERP peut être documenté comme étant le stock disponible. Ainsi, l’équipe de la 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. Cependant, la documentation de l’ERP peut aussi être légèrement trompeuse, et cette quantité aurait été plus justement appelée stock disponible, car chaque fois qu’une rupture de stock se produit 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 incorrect en soi - c’est la compréhension du nombre qui est approximative. En pratique, les approximations sémantiques peuvent générer de nombreux comportements incohérents, qui, à leur tour, génèrent des coûts de friction continus au sein de la supply chain.

Les tableaux de bord de santé des données consolident les chiffres qui permettent à l’entreprise de décider sur place si les données peuvent être considérées comme suffisamment fiables ou non. En effet, comme la solution va être utilisée quotidiennement à des fins de production, il est impératif qu’un problème de données significatif soit identifié grâce à une inspection quasi-instantanée. Sinon, il est probable que la supply chain continuera à fonctionner pendant des jours, voire des semaines, sur la base de données défectueuses. À cet égard, le tableau de bord de santé des données est semblable à un feu de signalisation : vert vous passez, rouge vous vous arrêtez.

De plus, lorsqu’on considère une supply chain de taille importante, il y a généralement une quantité irréductible de données corrompues ou incorrectes. Ces données résultent de saisies manuelles erronées ou de cas particuliers rares dans les systèmes de l’entreprise eux-mêmes. En pratique, pour toute supply chain de taille importante, il est déraisonnable de s’attendre à ce que les données de la supply chain soient exactes à 100 %. 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 soient quasi-négligeables.

Par conséquent, les tableaux de bord de santé des données sont également censés collecter des statistiques sur les erreurs de données identifiées. Ces statistiques sont essentielles pour établir la confiance dans les données. À cette fin, un Supply Chain Scientist est souvent sollicité pour établir des seuils d’alerte bien choisis, généralement associés à un arrêt complet de la solution. Il convient de faire preuve de prudence dans l’établissement des seuils, car s’ils sont trop bas, la solution est inutilisable, car elle est trop fréquemment arrêtée pour “problèmes de données identifiés” ; cependant, 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à de la signalisation rouge-verte, les tableaux de bord de santé des données sont également destinés à offrir des informations prioritaires sur les efforts d’amélioration des données. En effet, de nombreux points de données peuvent être incorrects mais aussi sans conséquence. Par exemple, il n’a pas d’importance si le prix d’achat d’un produit est incorrect si la demande du marché pour ce produit a disparu il y a des années, car il n’y aura plus de commandes d’achat pour ce produit.

La Supply Chain Quantitative insiste sur le fait que la résolution fine des erreurs de données, qui peut nécessiter 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 par rapport au 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 défectueux 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 de la 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écision prioritaires

Comme nous l’avons vu, seules les décisions de la supply chain peuvent vraiment être évaluées d’un point de vue quantitatif. Il n’est donc pas surprenant que l’un des livrables opérationnels clés d’une initiative de Supply Chain Quantitative soit les tableaux de bord qui consolident les décisions obtenues en tant que résultat numérique final de l’ensemble du pipeline de données. Un tel tableau de bord peut être aussi simple qu’un tableau qui liste pour chaque produit la quantité exacte en unités à commander immédiatement. Si des MOQ (quantités de commande minimales) sont présentes - ou toute autre contrainte de commande alternative - les quantités suggérées peuvent être nulles la plupart du temps, 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 tableau de bord, qui est une forme spécifique d’interface utilisateur. Cependant, le tableau de bord lui-même n’est qu’une option, qui peut être pertinente ou non. En pratique, on s’attend à ce que le logiciel alimentant l’initiative de Supply Chain Quantitative soit très flexible, c’est-à-dire programmable, offrant de nombreuses façons de présenter ces résultats dans différents formats de données. Par exemple, les résultats numériques peuvent être consolidés dans des fichiers texte plats, destinés à être importés automatiquement dans l’ERP principal utilisé pour gérer les actifs de l’entreprise.

Alors que le format des décisions dépend fortement de la tâche de la supply chain en question, la plupart des tâches nécessitent de prioriser ces décisions. Par exemple, le calcul des quantités suggérées pour une commande d’achat peut être décomposé à travers une liste priorisée des unités à acquérir. L’unité la plus rentable est classée en premier. Comme les stocks ont des rendements décroissants, la deuxième unité acquise pour le même produit couvre 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 dans la liste globale. Au lieu de cela, l’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 stocks morts à un moment donné. Transformer cette liste de priorités en quantités finales à acheter 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 d’ordonnancement non linéaires compliquent davantage cette tâche, mais, pour simplifier, nous mettrons de côté ces contraintes à 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 tableaux de bord qui compilent les décisions d’approvisionnement suggérées peuvent être, en pratique, des listes priorisées de décisions. Ces tableaux de bord contiennent des listes avec des décisions très rentables en haut et des décisions très peu rentables en bas. Alternativement, les praticiens de la supply chain peuvent décider de tronquer les listes lorsque les décisions ne sont pas rentables. Cependant, il est souvent possible de tirer des enseignements en examinant les décisions qui se situent juste en dessous du seuil de rentabilité, même si l’entreprise n’est évidemment pas censée agir sur ces entrées non rentables.

Afin de fournir ce type de tableaux de bord axés sur les décisions, la solution logicielle qui soutient la Supply Chain Quantitative doit explorer numériquement de vastes quantités de décisions possibles. Par exemple, la solution doit être capable de prendre en compte l’impact financier de l’achat de chaque unité, unité par unité, pour chaque produit et dans chaque emplacement. Sans surprise, cette opération peut nécessiter des ressources informatiques considérables. Heureusement, de nos jours, le matériel informatique est capable de gérer même les plus grandes chaînes d’approvisionnement mondiales. En supposant que la solution logicielle sous-jacente soit correctement architecturée pour la Supply Chain Quantitative, la scalabilité du traitement des données ne devrait pas poser de problème pour les équipes de la supply chain.

Détail des résultats numériques

Les systèmes désignés de manière péjorative comme des 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 accent spécifique sur un pipeline de données automatisé, est également confrontée au risque de fournir ce que les équipes de la supply chain classeraient comme des “boîtes noires”. En effet, les implications financières des décisions de la 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 catastrophes. Alors que l’automatisation est très souhaitable, cela ne signifie pas que l’équipe de la supply chain n’est pas censée avoir une compréhension approfondie de ce qui est livré par le pipeline de données qui soutient l’initiative de la Supply Chain Quantitative.

Le terme “détail des résultats” fait référence à l’effort nécessaire pour rendre la solution entièrement transparente au bénéfice des équipes de la supply chain. Cette approche souligne que aucune technologie n’est transparente par conception. La transparence est le résultat final d’un effort spécifique, qui fait partie 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. Mis à part quelques individus exceptionnels, la plupart des gens n’ont pas une compréhension intuitive de ce que devrait être la sortie “attendue” du modèle linéaire lorsque 4 dimensions ou plus sont impliquées. Pourtant, les problèmes de la 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 de la supply chain. Naturellement, lorsque des algorithmes d’apprentissage automatique sont utilisés, comme le recommande la Supply Chain Quantitative, ils laissent les praticiens encore plus dans le noir.

Bien que l’effet boîte noire soit un problème réel, une solution réaliste ne consiste pas à simplifier le traitement des données en calculs immédiatement intuitifs pour l’esprit humain. Cette approche est une recette pour une inefficacité extrême, qui détruit complètement tous les avantages des ressources informatiques modernes, qui peuvent être utilisées pour aborder la complexité brute des chaînes d’approvisionnement modernes. Simplifier le processus n’est pas la réponse. Le détail des résultats l’est.

Même les recommandations les plus complexes de la supply chain peuvent être rendues largement transparentes pour les praticiens de la supply chain, simplement en décomposant les calculs internes avec des indicateurs financiers bien choisis, qui représentent les facteurs économiques qui soutiennent la recommandation elle-même. Par exemple, au lieu de simplement afficher un tableau nu avec deux colonnes produit et quantité comme commande d’achat suggérée, le tableau devrait inclure quelques colonnes qui aident à la prise de décision. Ces colonnes supplémentaires peuvent inclure le stock actuel, la demande totale du dernier mois, le délai d’approvisionnement prévu, le coût financier prévu de la rupture de stock (si aucune commande n’est passée), le coût financier prévu de la surstock (risque associé à la commande suggérée), etc. Les colonnes sont conçues pour donner à l’équipe de la supply chain des vérifications rapides de la cohérence des quantités suggérées. Grâce aux colonnes, l’équipe peut rapidement établir sa confiance dans les résultats numériques et peut également identifier certaines des faiblesses d’une solution qui nécessite des améliorations supplémentaires.

Étendre les tableaux de bord à des fins de whiteboxing est en partie un art. Générer des millions de chiffres est facile, même en n’ayant accès à aucune ressource informatique autre que celle disponible sur un smartphone. Cependant, générer 10 chiffres dignes d’être examinés quotidiennement est très difficile. Ainsi, le défi principal consiste à identifier une douzaine de KPI (indicateurs clés de performance) ou moins qui sont suffisants pour éclairer les décisions recommandées en matière de supply chain. Les bons KPI nécessitent généralement beaucoup de travail ; ils ne doivent pas être des définitions naïves, qui sont généralement trompeuses en matière de supply chain. Par exemple, même une colonne aussi simple que le “prix unitaire d’achat” peut être très trompeuse si le fournisseur propose des remises en fonction du volume, ce qui rend le prix d’achat dépendant de la quantité achetée.

Tableaux de bord stratégiques

Bien que la focalisation sur les décisions à petite échelle soit nécessaire - car c’est l’une des rares approches qui se prête aux évaluations quantitatives des performances - la supply chain peut également avoir besoin d’être ajustée de manière plus importante et perturbatrice pour améliorer ses performances à un niveau supérieur. Par exemple, l’achat de plus d’unités de stock bien choisies augmente marginalement le taux de service. Cependant, à un certain moment, l’entrepôt est plein et aucune unité supplémentaire ne peut être achetée. Dans cette situation, il convient de considérer un entrepôt plus grand. Afin d’é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 l’avantage financier global de fonctionner avec un entrepôt arbitrairement grand. La gestion de la supply chain peut ensuite surveiller l’indicateur financier associé au coût de friction imposé par la capacité de l’entrepôt et décider quand il est temps de considérer une augmentation de la capacité de l’entrepôt.

Généralement, les supply chains fonctionnent sur la base de nombreuses contraintes qui ne peuvent pas être révisées quotidiennement. Ces contraintes peuvent inclure le capital de travail, la capacité de l’entrepôt, 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 stock, plus de retards ou plus de ruptures de stock. Le coût d’opportunité peut être évalué par 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 généralement pas plus difficiles que l’optimisation des décisions de routine, c’est-à-dire l’établissement des quantités de commande.

La Supply Chain Quantitative souligne que les coûts d’opportunité associés à ces contraintes doivent faire partie du pipeline de données de production et, généralement, doivent être matérialisés par des tableaux de bord dédiés, qui sont spécifiquement destinés à aider la gestion de la supply chain à décider quand il est temps d’apporter des changements plus importants à leur supply chain. Ces types de tableaux de bord sont appelés tableaux de bord stratégiques. Cette approche diffère de la pratique traditionnelle de la supply chain qui met l’accent sur des initiatives ad hoc lorsqu’elle estime que la supply chain est sur le point d’atteindre une limite d’exploitation. En effet, les KPI fournis par les tableaux de bord stratégiques sont actualisés quotidiennement, voire 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 à tirer parti des informations obtenues grâce à 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. Comme ils font partie du pipeline de données, lorsque le marché commence à évoluer plus rapidement que d’habitude, les KPI restent à jour sur la situation actuelle de l’entreprise. Cette approche évite les écueils traditionnels associés aux enquêtes ad hoc qui ajoutent invariablement des retards supplémentaires à des problèmes déjà en retard. Cette approche atténue également largement le problème alternatif, qui est de prendre des décisions stratégiques hâtives qui se révèlent non rentables - une condition regrettable qui aurait pu être anticipée dès le départ.

Tableaux de bord d’inspection

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 est la moelle épinière de l’initiative de la Supply Chain Quantitative. Des erreurs de traitement des données, ou des bugs, peuvent se produire n’importe où dans le pipeline de données. Pire encore, le type d’erreur le plus fréquent n’est pas la formule incorrecte, mais la sémantique ambiguë. Par exemple, au début du pipeline, la variable stockinv peut se référer au stock disponible (où des valeurs négatives sont possibles), tandis que plus tard, la même variable est utilisée avec une interprétation de stock en main (où des valeurs positives sont attendues). L’interprétation ambiguë de la variable stockinv peut générer une grande variété de comportements incorrects, allant des plantages du système - qui sont évidents, donc seulement modérément nuisibles - à une corruption silencieuse et généralisée des décisions de la supply chain.

Comme les supply chains sont presque toujours construites à partir d’un mélange unique de solutions logicielles mises en place au fil des ans, il n’y a aucun espoir d’accéder à une solution logicielle “éprouvée” exempte de bugs. En effet, la plupart des problèmes surviennent aux limites du système, lors de la conciliation des données provenant de différents systèmes, voire simplement de la conciliation des données provenant de différents modules au sein du même système. Ainsi, quelle que soit la fiabilité de la solution logicielle, l’outillage doit être en mesure de soutenir facilement le processus de débogage, car ce type de problème est inévitable.

Le but des tableaux de bord d’inspection est de fournir des vues détaillées pour une inspection minutieuse des ensembles de données de la supply chain. Cependant, ces tableaux de bord ne sont pas de simples forages pour inspecter les tables de données d’entrée. Une telle approche de forage ou de découpage des données manquerait le point. Les supply chains sont avant tout des 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” perdue. Par exemple, lors du déplacement de marchandises de l’entrepôt A à l’entrepôt B, la base de données de l’entrepôt B peut manquer quelques entrées de produits, ce qui génère des corruptions de données subtiles, car les unités provenant de l’entrepôt A sont reçues dans l’entrepôt B sans être correctement rattachées à leur produit. Lorsque les résultats numériques semblent étranges, ces tableaux de bord d’inspection sont l’option privilégiée du Supply Chain Scientist pour effectuer une enquête rapide sur les données d’échantillon.

Dans la pratique, un tableau de bord d’inspecteur fournit un point d’entrée de bas niveau tel qu’un code produit ou un SKU, et il consolide toutes les données associées à ce point d’entrée en une seule vue. Lorsque les marchandises circulent dans de nombreux endroits, comme c’est le cas dans les chaînes d’approvisionnement aérospatiales par exemple, le tableau de bord de l’inspecteur tente généralement de reconstituer les trajectoires des marchandises, qui peuvent avoir transité non seulement par plusieurs emplacements physiques, mais également par plusieurs 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 l’origine des marchandises qui sont expédiées ? Les mouvements de stocks sont-ils alignés sur les politiques officielles de la chaîne d’approvisionnement, etc. ? Le tableau de bord de l’inspecteur est un outil de “débogage” car il est conçu pour rassembler les données qui sont étroitement liées, non pas d’un point de vue informatique, mais d’un point de vue de la chaîne d’approvisionnement.

L’un des problèmes les plus étranges auxquels Lokad a été confronté lors de l’analyse de jeux de données de chaîne d’approvisionnement était le cas des pièces téléportées. L’entreprise - dans ce cas une compagnie aérienne - avait des 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 fonctionner, l’entreprise tenait des registres de mouvement de stocks impeccables pour toutes ses pièces. Pourtant, en utilisant un tableau de bord d’inspecteur nouvellement conçu, l’équipe de Lokad a réalisé que certaines pièces se déplaçaient de l’Asie vers l’Europe, et vice-versa, en seulement 2 ou 3 minutes. Comme les pièces d’avion étaient transportées par avion, on aurait pu s’attendre à ce que le temps de transport soit d’au moins une douzaine d’heures - certainement pas de minutes. Nous avons immédiatement soupçonné un problème de fuseau horaire ou de temps informatique, mais les enregistrements de temps se sont également révélés impeccables. En enquêtant davantage sur les données, il est apparu que les pièces qui avaient été téléportées étaient effectivement utilisées et montées sur des avions à leur lieu d’atterrissage, une découverte d’autant plus déconcertante. En laissant les équipes de la chaîne d’approvisionnement jeter un coup d’œil elles-mêmes aux tableaux de bord de l’inspecteur, le mystère a finalement été résolu. 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 le plus extrême, si les deux demi-roues et les pneus étaient enlevés, il ne restait physiquement rien. Ainsi, la roue entièrement démontée pouvait être remontée librement n’importe où, en ignorant complètement son emplacement d’origine.

Les tableaux de bord de l’inspecteur sont le pendant de 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 des données. De plus, les tableaux de bord de l’inspecteur font généralement partie intégrante de l’effort de whiteboxing. Lorsqu’ils sont confrontés à ce qui semble être une recommandation déconcertante, les praticiens de la chaîne d’approvisionnement 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 de l’inspecteur est généralement ajusté à cette fin précise, en incluant de nombreux résultats intermédiaires qui contribuent au calcul de la recommandation finale.