Le Pipeline d'Extraction de Données

Ce document est destiné à servir de guide aux services informatiques pour la construction d’un pipeline qui extrait les données des systèmes d’entreprise existants et rend ces données disponibles dans la plateforme de Lokad. La mise en place d’un pipeline de données est l’une des premières phases d’une initiative de supply chain quantitative. Le document couvre l’approche recommandée par Lokad, y compris la portée des données à extraire et à rendre disponibles sur la plateforme de Lokad, le format des données et les stratégies de transfert des données.

Motivation et contexte

Lokad définit une initiative de supply chain quantitative comme une initiative qui fournit une recette numérique qui automatise les décisions (ou du moins les recommandations) face aux défis de la supply chain. Lokad propose une plateforme programmatique conçue pour la résolution de problèmes d’optimisation prédictive liés à la supply chain.

Les problèmes typiques comprennent :

• Décider des quantités de stocks à réapprovisionner
• Décider des quantités de stocks à produire
• Décider d’augmenter ou de diminuer les prix
• Décider si les stocks doivent être déplacés dans le réseau

Si l’entreprise réussit à optimiser ces décisions, elle peut généralement réduire ses coûts d’exploitation, diminuer ses besoins en fonds de roulement et améliorer sa qualité de service. Au minimum, l’entreprise devrait être en mesure de réviser ce mix de coûts, de trésorerie et de service pour le rendre plus aligné sur sa stratégie globale de supply chain.

La recette numérique, qui aborde le problème d’intérêt, est destinée à être mise en œuvre au sein de Lokad. Par conséquent, la recette numérique nécessite que les données pertinentes de l’entreprise soient mises à disposition dans la plateforme de Lokad. Cela soulève les questions suivantes :

• Quelles données doivent être transférées à Lokad ?
• Quel format doit être utilisé pour les données ?
• Quels modèles de transfert doivent être utilisés pour actualiser les données ?

Bien que les problèmes énumérés ci-dessus soient variés, les données d’entrée pertinentes sont très similaires et sont généralement fournies par le biais des données historiques transactionnelles de base de l’entreprise (par exemple, les ventes historiques).

Le service informatique du client est généralement responsable de la configuration et de la maintenance du pipeline d’extraction de données. Les sections suivantes expliqueront en détail ce qui est spécifiquement requis du service informatique.

Une fois que le pipeline d’extraction de données est créé, les ingénieurs de Lokad - appelés Supply Chain Scientists - sont responsables de la configuration et de la maintenance de la recette numérique. Ces ingénieurs sont souvent fournis par Lokad dans le cadre d’un accord de service “Plateforme+Experts”, mais il est également possible pour le client d’intégrer cette compétence en interne. Cependant, même lorsque de tels ingénieurs sont en interne, nous recommandons de les placer dans le département de la supply chain plutôt que dans le département informatique.

Qu’il s’agisse ou non d’une externalisation de cette partie de l’initiative de la supply chain, la perspective décrite dans ce document reste la même.

Perspective technique de haut niveau

Lokad est une couche analytique qui fonctionne par-dessus les systèmes transactionnels existants du client. En d’autres termes, Lokad ne remplace pas l’ERP ; il le complète avec des capacités d’optimisation prédictive qui, réaliste-ment, ne peuvent pas être mises en œuvre dans le cadre d’un système transactionnel traditionnel.

Chaque compte Lokad est livré avec un système de fichiers accessible via les protocoles SFTP et FTPS. Une interface web est également disponible, bien que cette interface ne soit généralement pas destinée à notre public informatique (mais plutôt à la fourniture de tableaux de bord pour les utilisateurs non spécialistes). Nous attendons que les données pertinentes, généralement extraites des systèmes transactionnels de base utilisés par l’entreprise, soient exportées sous forme de fichiers plats (plus de détails ci-dessous) et téléchargées dans le système de fichiers de Lokad.

Sauf accord contraire, le service informatique du client est responsable de tout ce qui concerne les données jusqu’au moment où les fichiers plats sont téléchargés dans le système de fichiers de Lokad. La conception de la plateforme de Lokad est telle qu’elle peut traiter les échecs partiels d’extraction de données (plus de détails ci-dessous), de sorte que le service informatique dispose d’une certaine latitude à cet égard.

Une fois que les données sont mises à disposition de Lokad, une série de scripts Envision (Envision est le langage de programmation spécifique au domaine développé par Lokad) les traite et génère les décisions d’optimisation de la supply chain qui présentent un intérêt.

Il existe plusieurs applications pratiques de cette extraction de données, dont beaucoup vont au-delà de l’initiative d’optimisation de la supply chain de Lokad. Le marketing, la finance et les équipes de vente - pour n’en nommer que trois - sont des bénéficiaires potentiels des mêmes données de ventes historiques que Lokad traite finalement. Pour cette raison, Lokad recommande de consolider les données transactionnelles dans une couche de service dédiée - un “data lake” - réservée exclusivement à la fourniture de telles données aux équipes appropriées et aux systèmes analytiques tiers (comme la plateforme de Lokad).

La création d’un data lake n’est pas une exigence pour utiliser Lokad, mais plutôt une architecture potentielle qui facilite les opérations de l’entreprise. Il convient de noter qu’un data lake facilite également l’émergence d’une “pratique des données” au sein d’une entreprise - si une telle pratique n’existe pas déjà.

La portée des données pertinentes

La supply chain consiste à optimiser les décisions liées au flux de biens physiques (achats, transport, production, ventes, etc.). Par conséquent, les données les plus pertinentes pour une initiative d’optimisation prédictive sont presque toujours les données qui décrivent les flux qui se produisent au sein de l’entreprise. Ces données se trouvent généralement dans les systèmes d’exploitation transactionnels du client.

Comme mentionné précédemment, la plateforme de Lokad est assez flexible dans ses capacités de traitement, il n’y a donc aucune exigence stricte en matière de données. Il est fort probable que le client ne soit pas en mesure de fournir bon nombre des éléments de données énumérés ci-dessous, et Lokad est capable de fonctionner dans de telles limites. Ainsi, la liste ci-dessous tente d’être aussi complète que possible pour identifier les sources de données utiles, sans exiger la fourniture stricte de chacune d’entre elles.

Catalogue de produits : La liste des produits (ou articles, pièces) que l’entreprise achète, transforme, assemble et/ou vend. Cette liste est importante car de nombreuses décisions se prennent au niveau du “produit”. La hiérarchie (par exemple, les catégories, les familles, les sous-familles), si elle existe, est pertinente - à la fois à des fins de reporting et à des fins analytiques. Les attributs structurés (par exemple, la couleur, la taille, le poids, la forme) qui qualifient les produits sont également utiles. En règle générale, toutes les données qui décrivent les produits - du point de vue de la supply chain - sont pertinentes. Les relations entre les produits - comme les nomenclatures (bill of materials) - sont également pertinentes.

Historique des commandes clients : La liste des commandes de vente historiques du client. Cette liste est importante car les ventes sont presque toujours le meilleur indicateur que l’entreprise a pour estimer la demande du marché. Ces données doivent inclure les montants monétaires associés aux transactions, car l’optimisation de la supply chain doit être effectuée d’un point de vue financier. (Ce point de vue financier est revisité plus en détail ultérieurement.) Dans la mesure du possible, il est (toujours) préférable de fournir des transactions de commandes brutes, plutôt que des agrégats quotidiens/hebdomadaires/mensuels. (Ce point est également discuté plus en détail ci-dessous.) L’historique des commandes de vente peut inclure des commandes en attente, des commandes annulées, des commandes reportées, des commandes modifiées, des retours, etc., qui sont tous des points de données potentiellement pertinents. Si des clients sont identifiés dans ces données, les identifiants de clients anonymisés deviennent pertinents. (Les données personnelles ont leur propre section ci-dessous.)

Commandes d’achat : La liste des commandes d’achat historiques du client, ainsi que les commandes d’achat en attente (non encore reçues). Cette liste est importante car les commandes d’achat sont presque toujours le meilleur indicateur pour estimer les délais de livraison des fournisseurs et leur qualité de service. Les commandes d’achat en attente reflètent le “stock en commande”. Les commandes d’achat doivent également inclure les montants monétaires associés aux transactions. Dans la mesure du possible, il est également (toujours) préférable de fournir l’historique des commandes brutes plutôt que des agrégats. L’historique des commandes d’achat devrait inclure, si possible, les dates pertinentes : date de commande, date d’expédition, date de livraison, etc.

Ordres de production : La liste des ordres de production historiques du client (le cas échéant), ainsi que les ordres de production en attente (non encore exécutés). Cette liste est importante car ces ordres reflètent le flux de transformation des biens qui se produit au sein de l’entreprise, ainsi que permettant d’identifier les goulots d’étranglement qui peuvent exister dans la supply chain. Selon la situation, la production peut avoir des rendements variables ou parfois des lots peuvent être mis au rebut en raison de problèmes de qualité. Ces événements sont pertinents.

Mouvements de stocks : La liste des mouvements de stocks historiques du client si plusieurs emplacements sont présents. Cette liste est importante car elle éclaire sur l’origine des stocks utilisés pour déclencher les processus de production ou servir les clients. Selon la situation, les délais de livraison de ces mouvements peuvent être variables. Si tel est le cas, les détails des dates (date de commande de transfert, date d’expédition, date de réception) sont également pertinents.

Niveaux de stocks : La liste de tous les SKUs (stock-keeping unit) du client avec leur niveau de stock actuel. Cette liste est importante car elle caractérise l’état actuel de la supply chain. Selon l’industrie, la représentation de l’inventaire peut être plus complexe que de simples niveaux de SKU. Des dates d’expiration peuvent également être présentes. Une partie ou la totalité de l’inventaire peut être suivi au niveau des numéros de série. Si l’inventaire sériel est utilisé, l’ensemble de la liste des numéros de série et de leurs emplacements associés est pertinent. Plus généralement, tous les éléments qui décrivent l’état actuel des actifs d’inventaire détenus par l’entreprise sont pertinents.

Étiquettes de prix : La liste des prix pratiqués par le client lors de la fourniture des biens (et éventuellement des services associés). Cette liste est importante car la politique de tarification actuelle du client peut différer de ce qu’il facturait auparavant. Les nouveaux prix ont un impact sur la demande future, mais aussi sur la rentabilité des décisions de la supply chain. Des promotions, des réductions de prix ou des options de tarification peuvent également être présentes. Tous les éléments qui contribuent au calcul de ce qui est facturé aux clients sont pertinents.

Les instantanés des niveaux de stocks passés, des étiquettes de prix passées et des commandes d’achat en attente passées sont également pertinents pour la plupart des besoins de la supply chain (cependant, ces données sont rarement disponibles dans les systèmes d’entreprise). Dès qu’un pipeline d’extraction de données est en place, de tels instantanés peuvent être mis en œuvre au sein de Lokad lui-même - sans intervention directe du service informatique du client.

Bien que cette liste soit déjà importante, en ce qui concerne les entreprises, il y a généralement plus de sources de données pertinentes que celles qui ont été énumérées ici. En règle générale, si une information est utile à la division de la supply chain, il est très probable qu’elle soit pertinente à des fins d’optimisation prédictive et doit être transmise à Lokad.

Schéma priorisé des données préparées

La liste des tables de données potentiellement pertinentes citées ci-dessus n’a pas pour but d’être exhaustive. En pratique, il est important d’identifier quelles tables sont nécessaires pour passer à la production de l’initiative, par opposition à celles qui sont agréables à avoir. Il est également important de prioriser correctement les extractions afin de permettre aux scientifiques de la supply chain de passer de la phase d’extraction de données à la phase d’optimisation.

Ainsi, dans le cadre de notre pratique de la supply chain, Lokad recommande que les scientifiques de la supply chain produisent un schéma priorisé des données préparées et partagent ce document avec le service informatique du client au début de l’initiative. Ce document répertorie les tables - et leurs champs - qui devraient être disponibles à la fin du segment de préparation des données. Ce document liste également les priorités respectives de tous les champs demandés.

Ce schéma fournit une liste de souhaits de haut niveau pour les données à extraire. Cependant, ce document ne doit pas être mal interprété comme une spécification pour les fichiers générés à l’étape d’extraction des données. Les scientifiques de la supply chain sont responsables de la préparation des données. Il est acceptable (et courant) que le schéma des données, tel qu’il est mis à disposition par le pipeline d’extraction des données, diffère considérablement du schéma “idéalisé” associé aux données préparées. Ce point est réexaminé en détail dans la section “Extraits transactionnels bruts” ci-dessous.

Profondeur historique des données

En ce qui concerne la profondeur historique des données à extraire, il y a généralement deux préoccupations distinctes. Premièrement, jusqu’à quelle date remonter dans le passé pour l’extraction des données ? Deuxièmement, quelle est la profondeur historique minimale nécessaire pour que l’initiative de la supply chain réussisse ?

En général, nous recommandons d’extraire l’ensemble de l’historique disponible pour toutes les tables qui ont moins d’un milliard de lignes. Modifier l’historique se traduit par la perte de données qui pourraient être pertinentes pour évaluer l’évolution à long terme de la supply chain. Les filtres seront mis en place du côté de Lokad dans le cadre de la préparation des données, de toute façon, il n’est donc pas nécessairement nécessaire de transférer plus de données pour obtenir plus de ressources informatiques pour Lokad.

En ce qui concerne la profondeur historique, il n’y a pas d’exigence minimale. Si l’historique du système est court (par exemple, six mois), alors certains modèles statistiques, comme la saisonnalité, ne peuvent pas être estimés. Cependant, les praticiens de la supply chain, qui doivent prendre les décisions qui les intéressent, avant l’initiative de Lokad, sont soumis aux mêmes limitations. La recette numérique de Lokad sera mise en œuvre de manière à tirer parti de la profondeur historique disponible, même si elle peut sembler peu abondante pour le client.

Données manquantes

Bien que les systèmes d’entreprise modernes soient généralement étendus, il y a invariablement beaucoup de données qui semblent manquer. Lorsque des données sont perçues comme manquantes, la viabilité de l’initiative de la supply chain quantitative est remise en question. Cependant, quelle que soit la quantité de données qui semblent être “manquantes”, les employés au sein de l’organisation parviennent toujours à prendre les décisions nécessaires au bon fonctionnement de la supply chain. En bref, il y a un moyen. L’approche technologique de Lokad repose sur le fait de faire le maximum avec ce qui est disponible - tout comme le font les employés. Cette approche est l’opposée des logiciels d’entreprise traditionnels qui ont des exigences de données finales et qui ne fonctionneront pas tant que toutes les exigences ne seront pas satisfaites.

D’après notre expérience, il existe deux grandes catégories de données “manquantes” qui doivent être distinguées : premièrement, les données qui devraient être intégrées dans le système d’entreprise ; deuxièmement, les données qui sont considérées comme très bénéfiques pour le système analytique (comme Lokad).

Les quantités minimales de commande (MOQ), les paliers de prix et les semaines de fermeture des fournisseurs sont des données qui manquent fréquemment dans les systèmes d’entreprise. Pourtant, ces données sont précieuses d’un point de vue d’optimisation de la supply chain. Ces données peuvent être dispersées dans des feuilles de calcul et des e-mails, ce qui empêche toute analyse structurée directe du côté de Lokad. Dans de telles situations, nous suggérons d’utiliser des heuristiques (à coder par Lokad) et des feuilles de calcul ad hoc (à télécharger sur Lokad). Une fois que la recette numérique est opérationnelle, Lokad travaillera avec le service informatique du client pour intégrer les données dans le(s) système(s) d’entreprise. De plus, la recette numérique elle-même clarifie quelles données sont réellement importantes et dans quelle mesure.

Les données de veille concurrentielle, telles que les prix des concurrents, sont une catégorie qui est considérée comme très utile, mais, d’après notre expérience, cela n’est pas évident. Anecdotiquement, obtenir ce type de données a souvent un coût substantiel, sinon les entreprises le feraient déjà. Pour cette raison, fournir de telles données n’est pas une exigence. Dans tous les cas, la recette numérique de Lokad sera essentielle pour évaluer - à une date ultérieure - les gains financiers réels associés aux données supplémentaires.

Extraits transactionnels bruts

Nous recommandons vivement de préserver la forme originale des données. Les données transmises à Lokad ne doivent être rien de plus que des copies brutes des tables et des colonnes d’origine, telles qu’elles se trouvent dans le SGBDR qui soutient les systèmes d’entreprise de la société. Toute la préparation des données doit être déléguée à la plateforme Lokad, qui a été spécialement conçue pour la préparation des données.

Tenter de préparer les données aboutit invariablement à une perte de données. Que cette perte soit acceptable ou non dépend des décisions spécifiques d’optimisation de la supply chain qui vous intéressent. Si les données sont déjà perdues au moment où elles atteignent la plateforme de Lokad, rien ne peut être fait pour récupérer cette perte. Les extraits transactionnels bruts garantissent que l’intégralité des informations disponibles dans les systèmes d’entreprise devient accessible dans Lokad.

De plus, la préparation des données introduit sa propre couche de complexité en plus de la complexité des systèmes d’entreprise eux-mêmes. Certes, la recette numérique qui permet d’obtenir l’optimisation de la supply chain souhaitée ne peut pas éviter de traiter des classes de complexité intrinsèque. Cependant, si cette recette numérique doit également faire face à la complexité accidentelle introduite par la préparation préalable des données, cela transforme un problème déjà difficile en un problème déraisonnablement difficile. Les extraits transactionnels bruts garantissent que Lokad ne se retrouve pas à affronter un problème encore plus important que celui qui doit être résolu.

D’un point de vue informatique, les extraits transactionnels bruts sont simples. Des copies de table simples doivent être utilisées (par exemple, SELECT * FROM MyTable), ce qui est la forme la plus simple de requêtes sur une base de données relationnelle. Ces requêtes sont simples, car il n’y a pas de filtres impliqués, et performantes, car il n’y a pas de jointure impliquée. Cependant, les très grandes tables nécessitent une attention particulière. Ce point est abordé ci-dessous.

Si un lac de données est en place, alors le lac de données doit refléter les données relationnelles telles qu’elles se trouvent dans les systèmes d’entreprise. Tous les systèmes de bases de données courants ont des capacités de mise en miroir intégrées. Nous recommandons de profiter de ces capacités lors de la mise en place du lac de données. De plus, la mise en miroir des données est beaucoup plus facile que la préparation des données - en particulier du point de vue du service informatique, car la préparation des données dépend fortement du problème spécifique à résoudre.

L’anti-pattern d’extraction BI

Les données à envoyer à Lokad ne doivent pas provenir d’une source secondaire (par exemple, un système de Business Intelligence (BI)) où les données ont déjà été largement modifiées, généralement dans le but d’une consommation directe par l’utilisateur final. Bien qu’il soit plus facile d’extraire des données à partir d’un système BI que d’un ERP, cela crée invariablement des problèmes insolubles par la suite. Par conception, les aspects transactionnels des données sont perdus, car les données sont agrégées en séries temporelles quotidiennes / hebdomadaires / mensuelles.

De plus, de nombreuses complications pertinentes mais difficiles à visualiser, telles que les commandes à plusieurs lignes, sont éliminées des systèmes de Business Intelligence (comme les cubes BI). Ces détails sont précieux car ils reflètent l’essence des situations de la supply chain qui doivent être traitées.

Mauvaises données

D’après l’expérience de Lokad, les cas de mauvaises données sont rares. Au contraire, les systèmes d’entreprise transactionnels (comme les ERP) ont généralement des données précises. Les erreurs de saisie de données transactionnelles incorrectes sont rares et se produisent généralement une ou deux fois pour 1000 entrées. Lorsque des codes-barres ou des dispositifs similaires sont utilisés, le taux d’erreur est encore plus faible. Le véritable problème réside dans le logiciel qui fait des hypothèses incorrectes sur les données, plutôt que dans les données elles-mêmes.

Les niveaux de stock en magasin pour les grands réseaux de vente B2C sont presque toujours inexacts. Cependant, du point de vue de Lokad, cette situation relève de données bruitées, et non de mauvaises données. Si de tels niveaux de stock sont (à tort) supposés être précis, les résultats seront sans signification. Nous abordons cette situation spécifique avec une vision probabiliste des niveaux de stock, en embrassant l’incertitude plutôt qu’en la rejetant.

En fin de compte, les systèmes de Lokad ont été conçus pour recevoir des données et permettre au client de gérer sa supply chain sans se soucier de ces problèmes. Lokad établit une sémantique des données pour aborder ces problèmes, ce qui représente la partie la plus difficile de l’étape de préparation des données.

Données personnelles

Une initiative de supply chain n’a presque jamais besoin de données personnelles pour fonctionner. Ainsi, d’un point de vue de la supply chain, nous recommandons de considérer les données personnelles comme une responsabilité, et non comme un atout. Nous déconseillons vivement le transfert de données personnelles vers la plateforme de Lokad. En pratique, cela signifie généralement filtrer les colonnes de la base de données (voir la discussion ci-dessous) qui contiennent des identifiants personnels (par exemple, nom, adresse, numéro de téléphone, e-mail, etc.).

Ces identifiants personnels peuvent être remplacés par des identifiants anonymes opaques - si l’information est pertinente d’un point de vue de la supply chain. Par exemple, les identifiants clients opaques sont utiles car ils permettent à Lokad d’identifier des modèles liés à la fidélité des clients - tels que l’impact négatif des ruptures de stock. Contrairement à la plupart des technologies de prévision qui ne peuvent fonctionner qu’avec une perspective de séries temporelles, la plateforme de Lokad peut tirer parti de données historiques ultra-granulaires, jusqu’au niveau de la transaction.

Si vous n’êtes pas sûr de la position de Lokad concernant les informations personnelles identifiables (PII), ce sujet est abordé dans les sections 1, 3 et 4 de notre document sur la sécurité.

Données financières

Les montants monétaires des biens achetés, transformés et vendus par le client sont d’une importance primordiale pour l’optimisation de la supply chain que Lokad propose. En fait, Lokad met l’accent sur une perspective financière de la supply chain qui optimise les dollars de retour par rapport aux pourcentages d’erreur.

Contrairement aux fournisseurs qui ne considèrent que les données relatives aux quantités de stock, Lokad utilise les données financières d’un client - si elles sont disponibles. Logiquement, les coûts de supply chain les plus préoccupants sont concentrés aux extrêmes ; une demande inattendue épuise les stocks ; et une demande inattendue faible entraîne des dépréciations d’inventaire. Entre les deux, l’inventaire tourne très bien. Ainsi, pour optimiser véritablement les décisions d’inventaire, un compromis financier doit être fait concernant ces risques. Lokad exploite les données financières d’un client pour calculer un compromis adéquat.

Pipeline de données vs extraction ponctuelle

Un pipeline d’extraction de données actualise automatiquement les données transférées à Lokad. Cette configuration représente un effort plus important qu’une extraction ponctuelle de données. Si possible, nous recommandons vivement d’automatiser l’extraction des données, éventuellement avec une approche progressive si le nombre de tables pertinentes est élevé. Cette automatisation fonctionne mieux si elle est installée dès le premier jour. Cependant, des extractions ponctuelles partielles utilisées pour identifier les tables pertinentes peuvent être utiles. Ce point est discuté dans les passages suivants.

Il y a trois raisons principales de soutenir une approche de pipeline de données.

Premièrement, du point de vue du praticien de la supply chain, des données datant de 3 semaines sont de l’histoire ancienne. Les résultats obtenus à partir de données obsolètes sont sans pertinence en ce qui concerne les décisions de supply chain actuelles. Une extraction ponctuelle produirait des résultats basés sur un seul instantané de l’historique commercial du client. Cela produirait des résultats de valeur limitée. De plus, les praticiens de la supply chain ont besoin de voir le système analytique en action afin de gagner confiance en sa capacité à gérer la variabilité quotidienne.

Deuxièmement, bien qu’il soit difficile d’élaborer un pipeline de données hautement fiable, il est préférable aux alternatives. Un pipeline de données peu fiable met en danger toute l’initiative de la supply chain quantitative, car aucune quantité d’analyse ne peut résoudre les problèmes de données de base, tels que l’absence d’accès à des niveaux de stock à jour.

Il faut généralement plusieurs exécutions planifiées pour perfectionner le processus d’extraction, car certains problèmes ne se présentent que de manière intermittente. La meilleure façon de résoudre ces problèmes est de commencer à exécuter le pipeline de données le plus tôt possible, ce qui permet à Lokad d’identifier et de résoudre tout problème. En particulier, les exécutions planifiées sont également l’une des options les plus sûres pour évaluer les performances de bout en bout de toute la séquence de processus, y compris ceux qui conduisent à la fourniture de décisions de supply chain recommandées.

Troisièmement, d’après notre expérience, la cause la plus fréquente de retard dans les initiatives de supply chain quantitative est la mise en place tardive du pipeline d’extraction de données. Nous reconnaissons que les services informatiques sont souvent sous pression pour livrer de nombreux projets et la construction d’un pipeline d’extraction de données est une tâche supplémentaire à laquelle ils doivent faire face. Ainsi, il est tentant - pour le service informatique - de reporter la partie pipeline, optant plutôt pour une série d’extractions ponctuelles. Bien que cette approche soit viable, elle présente le risque d’introduire des retards dans l’initiative, ainsi que d’empêcher Lokad d’identifier dès que possible des classes entières de problèmes potentiels (comme décrit dans le paragraphe précédent).

Fréquence d’extraction des données

Nous recommandons de rafraîchir tous les pipelines de données - les segments d’extraction ainsi que les segments analytiques - au moins une fois par jour, même lorsqu’il s’agit de calculs mensuels ou trimestriels. Cela peut sembler contre-intuitif, mais d’après notre expérience, des rafraîchissements automatisés fréquents sont le seul moyen d’obtenir un processus de bout en bout hautement fiable.

Pour la plupart des situations de supply chain, nous recommandons une routine d’extraction qui fournit une image complète des données jusqu’à la clôture de l’activité du jour en cours (par exemple, extraire le jeudi soir toutes les données historiques pertinentes jusqu’à la clôture de l’activité le jeudi). Le pipeline d’extraction de données s’exécute à la fin de la journée de travail, et le traitement analytique - au sein de la plateforme Lokad - suit. Les résultats frais sont disponibles dès le début de la journée de travail suivante.

Profondeur d’extraction des données : la règle 2+1 pour les incréments

Lorsque les données sont trop volumineuses pour être rechargées intégralement dans Lokad chaque jour, des chargements incrémentiels doivent être utilisés. Nous recommandons que ces chargements suivent la règle 2+1 pour les incréments : la fenêtre temporelle du chargement quotidien couvre les deux dernières semaines complètes, ainsi que la semaine en cours. Suivre cette règle est important pour assurer la haute fiabilité de la solution Lokad.

Le pipeline d’extraction de données échouera de temps en temps - indépendamment de Lokad. D’après notre expérience, même d’excellents services informatiques connaissent 1 à 2 échecs de pipeline par an. Lorsque le chargement quotidien échoue, le dernier jour de données est compromis. Si chaque chargement quotidien ne couvre qu’une seule journée (pas de chevauchement entre les chargements), Lokad se retrouve avec un historique de données partiellement corrompu. Pour corriger cet historique, du côté de Lokad, une deuxième intervention manuelle du service informatique est nécessaire, en plus de corriger ce qui a empêché le pipeline d’extraction de données de s’exécuter correctement en premier lieu. Cette “correction de l’historique des données” est susceptible d’être retardée de quelques jours - car il s’agit d’une opération inhabituelle pour le service informatique. Pendant ce temps, les résultats retournés par Lokad sont impactés négativement, car certaines données récentes se révèlent partiellement corrompues.

Au contraire, si chaque chargement quotidien couvre les deux dernières semaines complètes d’activité, ainsi que la semaine en cours, un échec quotidien du pipeline d’extraction de données bénéficie d’une récupération complète le lendemain. En effet, étant donné que le pipeline d’extraction de données fait partie des opérations de routine couvertes par le service informatique, le retour à l’état normal est susceptible de se produire dans un délai d’un jour ouvrable. Cette récupération ne nécessite aucune interaction spécifique entre le service informatique et le personnel de support de Lokad, ni avec les utilisateurs finaux de la solution Lokad. La correction des données est automatiquement effectuée grâce aux réécritures qui se produisent quotidiennement dans la fenêtre temporelle de 2+1.

La règle 2+1 reflète un compromis basé sur l’expérience de Lokad : plus la fenêtre temporelle est longue, plus le pipeline d’extraction de données devient résistant aux problèmes transitoires. Bien que nous puissions espérer que tout problème avec le pipeline d’extraction de données puisse être résolu dans un délai d’un jour ouvrable, le service informatique peut avoir des problèmes plus urgents. En fait, le pipeline d’extraction de données défaillant peut n’être qu’un symptôme d’un problème plus grave que le service informatique donne la priorité à résoudre. Ainsi, la récupération peut prendre quelques jours. La règle 2+1 garantit que tant que le service informatique parvient à réparer le pipeline dans les deux semaines, les opérations peuvent reprendre normalement avec le moins d’impact possible sur l’initiative d’optimisation. Cependant, si la fenêtre temporelle est trop longue, alors le chargement incrémentiel devient trop lourd en termes de ressources informatiques, ce qui contredit la raison même pour laquelle les chargements incrémentiels ont été introduits en premier lieu.

Si les trois dernières semaines représentent moins de 100 Mo de données, nous suggérons d’adopter la variante mensuelle de la règle 2+1 : la fenêtre temporelle du chargement quotidien couvre les deux mois complets précédents, ainsi que le mois en cours.

Identification des tables et colonnes pertinentes

La grande majorité des logiciels d’entreprise sont construits sur des bases de données relationnelles. Bien que des API web puissent exister, dans notre expérience, ces API ne fournissent que rarement des performances satisfaisantes en ce qui concerne les extractions complètes planifiées de l’historique. Au contraire, interroger directement la base de données via SQL s’avère souvent à la fois simple à mettre en œuvre et assez performant également, car les requêtes SQL recommandées par Lokad ne nécessitent aucune jointure à effectuer.

Ainsi, une fois qu’un système d’entreprise (par exemple, un ERP) a été jugé une source de données pertinente pour l’initiative, et en supposant que la base de données relationnelle sous-jacente puisse être consultée, la liste restreinte spécifique des tables et colonnes pertinentes doit être identifiée. De nombreux systèmes d’entreprise contiennent des centaines de tables et des milliers de colonnes, dont la plupart sont sans rapport avec l’initiative de la supply chain. En règle générale, une initiative de supply chain n’a rarement besoin que d’une douzaine de tables pour commencer et seulement quelques dizaines pour obtenir un degré élevé de couverture des données.

Si l’entreprise dispose d’un expert qui connaît le schéma de la base de données de l’entreprise, il est plus simple de tirer parti de cette expertise pour identifier les tables pertinentes dans la base de données. Cependant, s’il n’y a pas d’expert, il est généralement possible de rétro-ingénierie la base de données pour identifier les domaines d’intérêt en une ou deux semaines (même en présence d’un système assez complexe). En plus de tirer parti de toute documentation technique accessible concernant le système d’intérêt, nous suggérons de commencer par une extraction complète du schéma de la base de données, comprenant :

• le nom de la table
• le nom de la colonne
• le type de colonne
• la taille de la table

Nous suggérons de regrouper ces informations dans un tableau. Les tables potentielles peuvent être identifiées par leurs noms et leurs tailles. Nous suggérons de commencer par une inspection plus approfondie des tables les plus grandes, car c’est là que l’on peut généralement découvrir les plus pertinentes (pour une initiative d’optimisation de la supply chain). Pour inspecter une table, nous suggérons une inspection visuelle de quelques dizaines de lignes de données. Les observations doivent être ajoutées au tableau au fur et à mesure de l’avancement des travaux.

Diagnostic du schéma PostgreSQL

La requête pour extraire toutes les tables et colonnes :

SELECT column_name, data_type
FROM information_schema.columns
WHERE table_name = '‘table_name'’;

Voir aussi https://stackoverflow.com/questions/20194806/how-to-get-a-list-column-names-and-datatypes-of-a-table-in-postgresql

La requête pour extraire toutes les tailles de table :

select table_name, pg_relation_size(quote_ident(table_name))
from information_schema.tables
where table_schema = '‘public'’

Voir aussi https://stackoverflow.com/questions/21738408/postgresql-list-and-order-tables-by-size

Le modèle de requête pour extraire un échantillon de lignes :

select column from table
order by RANDOM()
limit 10000

Voir aussi https://stackoverflow.com/questions/19412/how-to-request-a-random-row-in-sql

Diagnostic du schéma Oracle

La requête pour extraire toutes les tables et colonnes :

SELECT table_name, column_name, data_type FROM ALL_TAB_COLUMNS

La requête pour extraire toutes les tailles de table :

SELECT table_name, num_rows FROM ALL_TABLES

Le modèle de requête pour extraire un échantillon de lignes :

set colsep ,
set headsep off
set pagesize 0
set trimspool on
spool c:/temp/oracle/output/foo_my_table.csv
SELECT * FROM FOO_MY_TABLE FETCH FIRST 10000 ROWS ONLY;
spool off

Formats de fichiers et transferts

La plateforme Lokad prend en charge les formats de fichiers texte brut, tels que les formats CSV ou TSV, ainsi que les feuilles de calcul Microsoft Excel, à la fois pour les opérations de lecture et d’écriture. La section Lire et écrire des fichiers documente les capacités d’E/S de Lokad. Bien que Lokad prenne en charge un ensemble assez diversifié d’options de formatage, nous recommandons ce qui suit :

• Le texte brut est utilisé à la place des feuilles de calcul (voir la discussion ci-dessous).
• La première ligne contient les en-têtes de colonnes et correspond aux noms de colonnes d’origine.
• Les noms de colonnes ne contiennent pas d’espaces ou de tirets.
• UTF-8 est utilisé pour l’encodage des caractères.
• Le point (.) est le séparateur décimal pour les nombres fractionnaires.
• Toutes les dates ont le même format dans toutes les tables.
• Les montants monétaires isolent la devise dans une colonne séparée.
• Le nom du fichier correspond au nom de la table d’origine.
• /input est le dossier côté Lokad utilisé, par convention, pour déposer les fichiers extraits.

Chaque fois qu’un fichier plat extrait dépasse 100 Mo, nous recommandons de le compresser à l’aide de GZIP.

En ce qui concerne le transfert, nous recommandons d’utiliser SFTP avec une authentification par clé publique.

Tables partitionnées

Nous recommandons de partitionner les tables qui sont trop volumineuses pour être réimportées facilement dans Lokad en totalité sur une base quotidienne. La partition permet généralement des téléchargements incrémentiels si la partition reflète l’âge des données. En règle générale, les tables qui contiennent moins d’un million de lignes ne valent généralement pas l’effort nécessaire pour les partitionner.

Lors de la partition d’une table en une liste de fichiers, le modèle de nommage de fichier recommandé consiste à regrouper les fichiers dans un sous-dossier dédié à l’intérieur de /input (nommé d’après la table respective) et à suffixer chaque fichier avec le segment extrait correspondant :

/input/mytable/mytable-2022-10-17.csv
/input/mytable/mytable-2022-10-18.csv
/input/mytable/mytable-2022-10-19.csv
/..

Même si toutes les lignes à l’intérieur d’un fichier ont la même valeur “date” (correspondant à celle trouvée dans le nom du fichier), nous recommandons de conserver cette colonne “date” dans le fichier.

Microsoft Excel

La plateforme de Lokad prend en charge la lecture des données à partir de feuilles de calcul Microsoft Excel, tant que la feuille de calcul suit un format tabulaire (la première ligne contient les en-têtes, puis un enregistrement par ligne). Cependant, le pipeline d’extraction de données doit éviter de transférer des feuilles de calcul vers Lokad.

Les feuilles de calcul sont acceptables si les fichiers sont téléchargés manuellement sur Lokad, plutôt que d’être transférés via le pipeline d’extraction de données automatisé. Les téléchargements manuels sont acceptables si :

• Les données n’existent pas (encore) dans les systèmes de l’entreprise.
• Les données sont mises à jour très rarement.

/manual est le dossier côté Lokad utilisé, par convention, pour recevoir les fichiers téléchargés manuellement.

Écrasement de fichiers

Les fichiers dans le système de fichiers de Lokad représentent les données telles que vues par Lokad. Écraser les fichiers existants est la méthode recommandée pour actualiser les tables extraites qui ne sont pas partitionnées. Dans le cas d’une table partitionnée, l’attente par défaut est d’avoir un nouveau fichier créé pour chaque période (un fichier par jour, ou par semaine, ou par mois).

Une fois que tous les fichiers à créer (ou à écraser) sont transférés sur Lokad, nous recommandons de créer (ou de mettre à jour) un fichier nommé /input/end-of-transfer.csv qui contient :

• une seule colonne nommée LastTransfer
• une seule ligne de données (deux lignes en comptant l’en-tête) avec un horodatage du transfert le plus récent

Ce fichier peut être utilisé pour déclencher une séquence de projets qui traite les données fraîchement mises à jour.

Santé des données

Le pipeline d’extraction de données doit fonctionner de manière fiable. La plateforme Lokad elle-même peut être utilisée pour instrumenter la sortie du pipeline d’extraction et évaluer l’intégrité, l’exhaustivité et la fraîcheur des données extraites. Ainsi, en tant que première étape du pipeline au sein de Lokad, nous recommandons de mettre en place des tableaux de bord sur la santé des données. Ces tableaux de bord sont destinés au service informatique (bien qu’il ne soit pas attendu qu’il en prenne la responsabilité). Le but collectif des tableaux de bord est de mettre en évidence tout problème de données et d’accélérer la résolution éventuelle par le service informatique. Cette mise en œuvre, comme le reste de la recette numérique qui pilote l’initiative d’optimisation de la supply chain, doit être réalisée par un expert en supply chain, éventuellement par l’équipe Lokad (dans le cas d’un abonnement Platform+Experts).

Spécification de l’extraction de données

Une fois que le pipeline d’extraction de données a été stabilisé, nous recommandons de produire une spécification pour l’extraction de données. Ce document devrait répertorier tous les fichiers attendus et leurs colonnes, ainsi que le calendrier de l’extraction de données. La stabilisation du pipeline de données devrait se produire dans les six mois suivant le lancement de l’initiative. Ce document devrait être convenu conjointement par le service informatique et le service supply chain. Ce document contient les détails des données attendues qui doivent être mises à disposition, en temps voulu, par le service informatique à la plateforme Lokad.

Le format des données peut encore être révisé ultérieurement, mais le service informatique est tenu d’informer le service supply chain avant d’apporter toute modification au format des données ou au calendrier associé. En général, une fois que la spécification a été convenue, il faut s’attendre à ce que les opérations de la supply chain reposent, à des fins de production, sur l’intégrité de l’extraction de données. Ainsi, en cas de changement(s), le service supply chain devrait bénéficier d’une “période de grâce” raisonnable suffisante pour mettre à niveau la logique au sein de Lokad (afin de prendre en compte le nouveau format des données).

Comme la production d’une spécification détaillée nécessite du temps et des efforts considérables, nous recommandons de différer la production de ce document jusqu’à ce que le pipeline soit stabilisé. D’après notre expérience, au cours des premiers mois, le pipeline - à la fois son extraction de données et ses segments analytiques - connaît une évolution rapide. Cette évolution rapide est susceptible de rendre obsolètes les premières tentatives de production d’une telle spécification.

Boucle de rétroaction

Les décisions de la supply chain (par exemple, les réapprovisionnements de stocks) générées au sein de la plateforme Lokad peuvent être exportées sous forme de fichiers plats pour être réintégrées dans le(s) système(s) d’entreprise. Ce mécanisme est appelé la boucle de rétroaction. Notre expérience indique que la mise en place de la boucle de rétroaction est peu probable dans les quatre mois suivant le lancement de l’initiative. La confiance dans la recette numérique nécessaire pour permettre à une partie de la supply chain de fonctionner en pilote automatique est importante, et ce degré de confiance peut prendre plusieurs mois à cultiver. Ainsi, la boucle de rétroaction n’est pas une préoccupation au début de l’initiative.

D’après notre expérience, la mise en place de la boucle de rétroaction est un défi beaucoup moins important que la mise en place du pipeline d’extraction de données. Par exemple, les chiffres, tels qu’ils sont produits dans Lokad, sont censés être autoritaires et définitifs ; s’il y a d’autres règles à appliquer pour transformer ces chiffres en chiffres exploitables (par exemple, des MOQ appliqués), alors la recette numérique est incomplète et doit être corrigée du côté de Lokad. D’autre part, la plateforme Lokad a la capacité de traiter et de produire n’importe quelle forme de données tant qu’elle est raisonnablement tabulaire. Ainsi, la simplicité de la boucle de rétroaction est conçue pour refléter la simplicité des décisions de la supply chain. Par exemple, il peut y avoir des dizaines de contraintes qui définissent si une commande d’achat donnée est valide ou non, mais le contenu de la commande d’achat finale est une liste simple de quantités associées à des numéros de pièces.

Cependant, nous recommandons que la plateforme Lokad ne soit pas donnée un accès direct aux systèmes d’entreprise du client. Au lieu de cela, les fichiers doivent être mis à disposition en temps opportun dans le système de fichiers Lokad. Le service informatique reste responsable de l’importation de ces données dans les systèmes d’entreprise. Cela garantit qu’une éventuelle violation de sécurité du compte Lokad ne peut pas être utilisée pour accéder à d’autres systèmes au sein de l’entreprise. De plus, cela permet de reporter cette opération de rétroaction si elle entre en conflit avec une autre opération effectuée par le service informatique sur le(s) système(s) d’entreprise.

Étant donné que la boucle de rétroaction implique, par définition, des données relatives aux opérations de la supply chain réelle, nous recommandons de produire une spécification dédiée à ce processus. Cette spécification reflète celle de l’extraction de données, mais avec des données transférées dans la direction opposée. Ce document est également censé être convenu conjointement par les départements informatique et supply chain.