Le pipeline d'extraction de données

Ce document est destiné à servir de guide aux départements IT pour construire un pipeline qui extrait des données des systèmes d’entreprise existants et les met à disposition sur la plateforme de Lokad. La mise en place d’un pipeline d’extraction de données est l’une des premières phases d’une initiative de la Supply Chain Quantitative. Le document couvre l’approche recommandée par Lokad, y compris le périmètre des données à extraire et à rendre disponibles sur la plateforme de Lokad, le format des données et les stratégies de transfert.

Motivation et contexte

Lokad définit une initiative de la Supply Chain Quantitative comme étant celle qui délivre une recette numérique automatisant les décisions (ou du moins des 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.

initial-phases-of-a-quantitative-supply-chain-initiative

Les problèmes typiques incluent :

Décider des quantités de stocks à réapprovisionner
Décider des quantités de stocks à produire
Décider s’il faut augmenter ou diminuer les prix
Décider si les stocks doivent être déplacés au sein du réseau

Si l’entreprise parvient à optimiser ces décisions, elle peut généralement réduire ses coûts opérationnels, diminuer ses besoins en fonds de roulement et améliorer sa qualité de service. Au minimum, l’entreprise devrait être capable de réviser ce mélange de coûts, de liquidités et de service pour l’aligner davantage sur sa stratégie globale de supply chain.

La recette numérique, qui répond au problème d’intérêt, est destinée à être mise en œuvre au sein de Lokad. En conséquence, la recette numérique nécessite que des données pertinentes de l’entreprise soient mises à disposition sur la plateforme de Lokad. Cela conduit aux questions suivantes :

Quelles données doivent être transférées vers Lokad ?
Quel format doit être utilisé pour les données ?
Quels schémas 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 proviennent généralement des données transactionnelles historiques de l’entreprise (les ventes historiques, par exemple).

Le département IT du client est généralement responsable de la mise en place et de la maintenance du pipeline d’extraction de données. Dans les sections suivantes, ce qui est spécifiquement requis du département IT sera expliqué en détail.

Une fois le pipeline d’extraction de données créé, les ingénieurs côté Lokad - appelés Supply Chain Scientists - sont responsables de la mise en place et de la maintenance de la recette numérique. Ces ingénieurs sont fréquemment fournis par Lokad dans le cadre d’un accord de service « Platform+Experts », mais il est également possible pour le client d’internaliser cette compétence. Cependant, même lorsque ces ingénieurs sont internes, nous recommandons de les affecter au département supply chain, plutôt qu’au département IT.

Indépendamment du fait que cette partie de l’initiative supply chain soit externalisée ou non, la perspective exposée dans ce document reste la même.

Perspective technique de haut niveau

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

Chaque compte Lokad est doté d’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 IT (mais plutôt à la fourniture de tableaux de bord pour les utilisateurs non spécialistes). Nous nous attendons à ce que les données pertinentes, généralement extraites des systèmes transactionnels principaux utilisés par l’entreprise, soient exportées sous forme de fichiers plats (plus de détails ci-dessous) et uploadées sur le système de fichiers de Lokad.

preferred-file-types-to-be-transferred-to-lokad

Sauf accord contraire, le département IT du client est responsable de tout ce qui concerne les données jusqu’au moment où les fichiers plats sont uploadés sur le système de fichiers de Lokad. La conception de la plateforme de Lokad est telle qu’elle peut traiter des échecs partiels d’extraction de données (plus de détails ci-dessous), offrant ainsi une certaine latitude au département IT à cet égard.

Une fois les données mises à disposition de Lokad, une série de scripts Envision (Envision est le langage de programmation spécifique développé par Lokad) les traite et génère les décisions optimisées supply chain d’intérêt.

Il existe plusieurs applications pratiques d’une telle extraction de données, dont beaucoup vont au-delà de l’initiative d’optimization de la supply chain de Lokad. Les équipes marketing, finance et ventes – pour n’en nommer que trois – sont les 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 » – qui est exclusivement réservée à la fourniture de ces données aux équipes concernées et aux systèmes analytiques tiers (comme la plateforme de Lokad).

flow-of-files-from-client-company-to-lokad-via-data-lake

La création d’un data lake n’est pas une exigence pour utiliser Lokad, mais simplement une architecture potentielle qui facilite les opérations de l’entreprise. Il est à noter qu’un data lake facilite également l’émergence d’une « data practice » au sein d’une entreprise – dans le cas où une telle pratique n’existerait pas déjà.

Le périmètre des données pertinentes

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

Comme mentionné précédemment, la plateforme de Lokad est assez flexible dans ses capacités de traitement, par conséquent, il n’y a aucune exigence stricte en matière de données. Il est fort probable que le client ne puisse pas fournir bon nombre des éléments de données énumérés ci-dessous, et Lokad est capable d’opérer dans de telles limites. Ainsi, la liste ci-dessous tente d’être aussi exhaustive que possible pour identifier les sources de données utiles, sans exiger la fourniture rigoureuse 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, catégories, familles, sous-familles), si elle est présente, est pertinente – tant pour les besoins de reporting qu’à des fins analytiques. Les attributs structurés (par exemple, couleur, taille, poids, forme) qui qualifient les produits sont également utiles. En règle générale, toute donnée décrivant les produits – du point de vue de la supply chain – est pertinente. Les relations entre produits - comme les nomenclatures (BOMs, bills of materials) - le sont également.

Historique des commandes de vente : La liste des commandes de vente historiques du client. Cette liste est importante car les ventes sont presque toujours le meilleur indicateur dont dispose l’entreprise pour estimer la demande du marché. Ces données doivent inclure les montants monétaires associés aux transactions, car l’optimization de la supply chain doit être réalisée d’une perspective financière. (Cette perspective financière est abordée plus en détail ultérieurement.) Dans la mesure du possible, il est (toujours) préférable de fournir les transactions de commandes brutes, par opposition à 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 retard, annulées, reportées, modifiées, des retours, etc., qui sont autant de points de données potentiellement pertinents. Si les clients sont identifiés dans ces données, les identifiants anonymisés des clients 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 devraient également inclure les montants monétaires associés aux transactions. Dans la mesure du possible, il est (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 disponible, 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, tout en nous permettant d’identifier les goulots d’étranglement qui peuvent exister dans la supply chain. Selon la situation, la production peut afficher des rendements variables ou parfois des lots peuvent être rebutés en raison de problèmes de qualité. Ces événements sont pertinents.

Mouvements de stocks : La liste des mouvements de stocks historiques du client s’il existe plusieurs sites. Cette liste est importante car elle éclaire l’origine des stocks utilisés pour déclencher des processus de production ou servir les clients. Selon la situation, les délais de ces mouvements peuvent varier. Le détail des dates (date de commande de transfert, date d’expédition, date de réception) est également pertinent.

Niveaux de stocks : La liste de tous les SKU du client (stock-keeping unit) 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 des stocks peut être plus complexe que de simples niveaux de SKU. Des dates d’expiration peuvent également être présentes. Certains ou l’ensemble des stocks peuvent être suivis au niveau des numéros de série. Si le suivi des stocks par numéro de série est utilisé, la liste complète des numéros de série et leurs emplacements associés est pertinente. De manière plus générale, tous les éléments qui décrivent l’état actuel des actifs de stocks détenus par l’entreprise sont pertinents.

Étiquettes de prix : La liste des prix pratiqués par le client lors de la mise en service des biens (et possiblement des services associés). Cette liste est importante car la politique de tarification actuelle du client peut différer de ce qu’elle facturait auparavant. Les nouveaux prix influencent la demande future, mais aussi la rentabilité des décisions supply chain. Des promotions, des réductions 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.

Des instantanés des niveaux de stocks passés, des anciennes étiquettes de prix et des anciennes commandes d’achat en attente sont également pertinents pour la plupart des besoins de la supply chain (cependant, ces données sont rarement disponibles dans les systèmes d’information). Dès qu’un pipeline d’extraction de données est en place, ces instantanés peuvent être implémentés au sein même de Lokad – sans intervention directe du département IT du client.

Bien que cette liste soit déjà conséquente, il existe généralement plus de sources de données pertinentes dans les entreprises que celles qui ont été listées ici. En règle générale, si une information est utile à la division supply chain, elle est très probablement pertinente pour l’optimisation prédictive et devrait être dirigée vers Lokad.

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

La liste des tables de données potentiellement pertinentes énumérées ci-dessus n’est pas destinée à submerger. En pratique, il est important d’identifier quelles tables sont nécessaires pour mettre l’initiative en production, par opposition à celles qui sont appréciables. Il est également important de prioriser correctement les extractions afin de permettre aux supply chain scientists de dépasser la phase d’extraction de données pour passer à l’optimisation.

Ainsi, dans le cadre de notre pratique supply chain, Lokad recommande que les supply chain scientists produisent un schéma priorisé des données préparées et partagent ce document avec le département IT du client dès le 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 offre une liste de souhaits de haut niveau pour les données à extraire. Cependant, ce document ne doit pas être interprété comme une spécification des fichiers générés lors de l’étape d’extraction des données. Les supply chain scientists 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 de données, diffère largement du schéma « idéalisé » associé aux données préparées. Ce point est abordé plus 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’où dans le passé l’extraction de données doit-elle remonter ? Deuxièmement, quelle est la profondeur historique minimale nécessaire pour que l’initiative supply chain réussisse ?

De manière générale, nous recommandons d’extraire l’historique complet disponible pour toutes les tables qui comptent moins d’un milliard de lignes. Modifier l’historique équivaut à perdre des données qui pourraient être pertinentes pour évaluer l’évolution à long terme de la supply chain. Des filtres seront néanmoins mis en place côté Lokad dans le cadre de la préparation des données, donc transférer davantage de données ne se traduit pas nécessairement par une augmentation des 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 schémas statistiques, comme la saisonnalité, ne peuvent pas être estimés. Cependant, les praticiens de la supply chain, qui doivent prendre les décisions d’intérêt avant l’initiative Lokad, sont soumis aux mêmes limitations. La recette numérique de Lokad sera mise en œuvre de manière à exploiter toute la profondeur historique disponible, même si elle peut paraître insuffisante pour le client.

Données manquantes

Bien que les systèmes d’entreprise modernes soient généralement vastes, il y a invariablement beaucoup de données qui semblent être manquantes. Comme on perçoit que des données sont manquantes, la viabilité de l’initiative de la Supply Chain Quantitative est remise en question. Cependant, peu importe la quantité de données qui se trouve être « manquante », les employés au sein de l’organisation parviennent toujours à prendre les décisions nécessaires pour que la supply chain fonctionne. 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 grand public qui imposent des exigences définitives en matière de données et ne fonctionneront pas à moins que toutes les exigences ne soient remplies.

Selon notre expérience, il existe deux grandes catégories de données « manquantes » qu’il convient de distinguer : d’abord, les données qui devraient être intégrées dans le système d’entreprise ; ensuite, les données que l’on considère comme extrêmement bénéfiques pour le système analytique (comme Lokad).

Les quantités minimales de commande (MOQs), les remises de prix et les semaines de fermeture des fournisseurs sont des données qui manquent fréquemment dans les systèmes d’entreprise. Cependant, ces données sont précieuses du point de vue de l’optimization de la supply chain. Ces données peuvent se retrouver dispersées dans des tableurs et des e-mails, empêchant toute analyse structurée directe côté Lokad. Face à ces situations, nous suggérons d’utiliser des heuristiques (à coder par Lokad) et d’utiliser des tableurs ad hoc (à uploader sur Lokad). Une fois la recette numérique opérationnelle, Lokad fera intervenir 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 précise elle-même quelles données importent réellement et dans quelle mesure.

Les données de veille concurrentielle, telles que les prix des concurrents, constituent une catégorie que l’on considère comme très utile mais, selon notre expérience, cela n’est pas évident. De manière anecdotique, l’obtention de ce type de données se fait souvent à un coût considérable, sinon les entreprises le feraient déjà. Pour cette raison, fournir ces données n’est pas une exigence. Quoi qu’il en soit, la recette numérique de Lokad sera déterminante pour évaluer - ultérieurement - les gains financiers réels associés aux données additionnelles.

Extractions transactionnelles brutes

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

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

De plus, la préparation des données introduit sa propre couche de complexité par-dessus la complexité des systèmes d’entreprise eux-mêmes. Certes, la recette numérique qui délivre l’optimization de la supply chain souhaitée ne peut é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, elle transforme un problème déjà difficile en un problème démesurément difficile. Les extractions transactionnelles brutes garantissent que Lokad ne se retrouve pas à s’attaquer à un problème encore plus grand que celui qui doit être résolu.

D’un point de vue informatique, les extractions transactionnelles brutes sont simples. Des copies simples de tables devraient ê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 aucun filtre n’est impliqué, et performantes, puisqu’il n’y a pas de jointure. Cependant, les très grandes tables requièrent une attention particulière. Ce point est abordé ci-dessous.

Si un data lake est en place, alors le data lake devrait miroiter les données relationnelles telles qu’elles se trouvent dans les systèmes d’entreprise. Tous les systèmes de bases de données grand public disposent de capacités de mirroring intégrées. Nous recommandons de tirer parti de ces capacités lors de la mise en place du data lake. De plus, la réplication des données est infiniment plus facile que la préparation des données – surtout du point de vue du service informatique, puisque la préparation des données dépend fortement du problème spécifique à traiter.

L’antipattern d’extraction BI

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

De plus, de nombreuses complications difficiles à visualiser mais pertinentes, telles que les commandes sur 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 supply chain qui doivent être prises en compte.

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) disposent généralement de données précises. Les saisies incorrectes des données transactionnelles sont rares et se produisent typiquement une ou deux fois par 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 suppositions incorrectes sur les données, plutôt que dans la mauvaise qualité des données elles-mêmes.

Les niveaux de stocks en magasin pour les grands réseaux de distribution B2C sont presque toujours inexacts. Toutefois, du point de vue de Lokad, cette situation relève de données bruyantes, et non de mauvaises données. Si ces niveaux de stocks sont (incorrectement) supposés être précis, les résultats seront dénués de sens. Nous abordons cette situation spécifique avec une vision probabilistique des niveaux de stocks, en acceptant l’incertitude plutôt qu’en la rejetant.

En somme, les systèmes de Lokad ont été conçus pour recevoir des données et permettre au client d’exploiter sa supply chain sans se soucier de ces préoccupations. Lokad établit une sémantique de données pour traiter ces questions, et cela représente la partie la plus difficile de la phase de préparation des données.

Données personnelles

Une initiative supply chain n’a presque jamais besoin de données personnelles pour fonctionner. Ainsi, du point de vue de la supply chain, nous recommandons de traiter les données personnelles comme un passif, et non comme un atout. Nous déconseillons fortement le transfert de données personnelles vers la plateforme Lokad. En pratique, cela signifie généralement filtrer les colonnes de la base de données (voir 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 opaques anonymes – si l’information est pertinente du point de vue de la supply chain. Par exemple, des identifiants clients opaques sont utiles car ils permettent à Lokad d’identifier des tendances liées à la fidélité des clients – comme l’impact négatif des ruptures de stocks. 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-détaillées, jusqu’au niveau de la transaction.

Si vous n’êtes pas certain 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 security.

Données financières

Les montants monétaires pour les biens achetés, transformés et vendus par le client revêtent une importance primordiale pour l’optimization de la supply chain que Lokad fournit. En fait, Lokad met l’accent sur une perspective financière de la supply chain qui optimise les dollars de retour plutôt que les pourcentages d’erreur.

Contrairement aux fournisseurs qui ne prennent en compte que les données liées aux quantités de stocks, Lokad utilise les données financières d’un client – si elles sont mises à disposition. Logiquement, les coûts supply chain les plus préoccupants se concentrent aux extrêmes : une demande exceptionnellement élevée génère des ruptures de stocks, et une demande exceptionnellement faible génère des radiations de stocks. Entre-temps, les stocks tournent correctement. Ainsi, afin d’optimiser véritablement les décisions concernant les stocks, un compromis financier doit être établi en tenant compte de 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 fortement d’automatiser l’extraction des données, éventuellement par une approche progressive si le nombre de tables pertinentes est important. Cette automatisation fonctionne mieux si elle est mise en place dès le premier jour. Cependant, des extractions ponctuelles partielles utilisées pour identifier les tables pertinentes peuvent s’avérer utiles. Ce point est abordé dans les passages suivants.

Il existe trois raisons principales de soutenir une approche par 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 périmées sont sans pertinence quant aux décisions supply chain actuelles. Une extraction ponctuelle produirait des résultats basés sur un instantané unique de l’historique d’affaires du client, donnant ainsi des résultats de valeur limitée. De plus, les praticiens de la supply chain doivent voir le système en action afin de faire confiance à sa capacité à gérer la variabilité quotidienne.

Deuxièmement, bien que la mise en place d’un pipeline de données hautement fiable soit difficile, il est préférable aux alternatives. Un pipeline de données peu fiable compromet l’ensemble de l’initiative de la Supply Chain Quantitative, car aucune quantité d’analyses ne peut résoudre des problèmes de données fondamentaux, tels que l’absence d’accès à des niveaux de stocks à jour.

Il faut généralement de nombreuses exécutions programmées pour perfectionner le processus d’extraction, car certains problèmes se manifestent de manière intermittente. Le moyen le plus sûr de résoudre ces problèmes est de démarrer le pipeline de données le plus tôt possible, permettant ainsi à Lokad d’identifier et de résoudre les éventuels problèmes. En particulier, les exécutions programmées figurent également parmi les options les plus sûres pour évaluer les performances de bout en bout de l’ensemble de la séquence de processus, y compris ceux qui aboutissent à la livraison des décisions supply chain recommandées.

Troisièmement, selon notre expérience, la cause la plus fréquente de retards 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 IT sont souvent sous une forte pression pour livrer de nombreux projets et que la construction d’un pipeline d’extraction de données constitue une tâche supplémentaire à laquelle ils doivent faire face. Ainsi, il est tentant – pour le service IT – 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 le départ des catégories entières de problèmes potentiels (comme décrit dans le paragraphe précédent).

Fréquence d’extraction des données

Nous recommandons d’actualiser 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, selon notre expérience, des actualisations automatisées fréquentes sont la seule manière d’obtenir un processus de bout en bout hautement fiable.

Pour la plupart des situations supply chain, nous recommandons une routine d’extraction qui fournit une image complète des données jusqu’à la clôture de la journée en cours (par exemple, extraire le jeudi soir toutes les données historiques pertinentes jusqu’à la clôture des affaires du jeudi). Le pipeline d’extraction de données s’exécute en fin de journée, suivi du traitement analytique – au sein de la plateforme Lokad. Des résultats frais sont disponibles dès le début de la journée ouvrable 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 re-téléversées intégralement sur Lokad chaque jour, des mises à jour incrémentielles doivent être utilisées. Nous recommandons que ces mises à jour suivent la règle 2+1 pour les incréments : la fenêtre temporelle de l’upload quotidien couvre les deux dernières semaines complètes, plus 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. Selon notre expérience, même d’excellents services IT rencontrent 1 à 2 défaillances de pipeline par an. Lorsque l’upload quotidien échoue, le dernier jour de données est compromis. Si chaque upload quotidien ne couvre qu’une seule journée (pas de chevauchement entre les uploads), Lokad se retrouve avec un historique de données partiellement corrompu. Corriger cet historique, côté Lokad, nécessite une seconde intervention manuelle du service IT, en plus de la réparation de ce qui a empêché le bon fonctionnement du pipeline d’extraction de données en premier lieu. Cette « correction de l’historique des données » risque d’être retardée de quelques jours – étant donné qu’il s’agit d’une opération inhabituelle pour le service IT. Pendant ce temps, les résultats renvoyés par Lokad sont impactés négativement, certaines données récentes se trouvant partiellement corrompues.

Au contraire, si chaque upload quotidien couvre les deux dernières semaines ouvrables complètes, plus la semaine en cours, un échec ponctuel du pipeline d’extraction de données bénéficie d’une récupération complète le lendemain. En effet, puisque le pipeline d’extraction de données fait partie des opérations routinières du service IT, le retour à un état normal de fonctionnement est susceptible de se produire en une journée ouvrable. Cette récupération ne nécessite aucune interaction spécifique entre le service IT et le personnel de support de Lokad ni les utilisateurs finaux de la solution Lokad. La correction des données est automatiquement effectuée via les réécritures qui se produisent quotidiennement pour couvrir la fenêtre temporelle 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ésilient face aux problèmes transitoires. Bien que nous puissions espérer que tout problème avec le pipeline d’extraction de données soit résolu en une journée ouvrable, le service IT peut avoir des priorités plus pressantes. En effet, l’échec du pipeline d’extraction de données pourrait n’être que le symptôme d’un problème plus grave que le service IT se fait un devoir de résoudre. Ainsi, la récupération peut prendre quelques jours. La règle 2+1 garantit qu’aussi longtemps que le service IT parvient à réparer le pipeline en moins de deux semaines, les opérations peuvent reprendre comme d’habitude avec un impact minimal sur l’initiative d’optimization. Cependant, si la fenêtre temporelle est trop longue, l’upload incrémentiel devient alors trop lourd en termes de ressources informatiques, contrecarrant ainsi la raison même pour laquelle les uploads incrémentiels ont été introduits dès le départ.

Si les trois dernières semaines représentent moins de 100Mo de données, nous suggérons d’adopter la variante mensuelle de la règle 2+1 : la période de l’envoi quotidien couvre les deux mois complets précédents, plus le mois en cours.

Identifier les 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, selon notre expérience, ces API offrent rarement des performances satisfaisantes pour les extractions complètes historiques programmées. Au contraire, interroger directement la base de données via SQL s’avère fréquemment à la fois simple à mettre en œuvre et assez performant, car les requêtes SQL recommandées par Lokad ne nécessitent aucun join.

Ainsi, une fois qu’un système d’entreprise (par exemple, ERP) a été jugé comme une source de données pertinente pour l’initiative supply chain, et en supposant que la base de données relationnelle sous-jacente est accessible, il faut identifier la liste restreinte spécifique des tables et colonnes pertinentes. De nombreux systèmes d’entreprise contiennent des centaines de tables et des milliers de colonnes, dont la plupart ne sont pas pertinentes pour l’initiative supply chain. En règle générale, une initiative supply chain a rarement besoin de plus d’une douzaine de tables pour démarrer et seulement de quelques dizaines pour atteindre un degré élevé de couverture de données.

Si l’entreprise a accès à un expert qui connaît le schéma de la base de données de l’entreprise, tirer parti de cette expertise est la manière la plus simple d’identifier les tables pertinentes dans la base de données. Cependant, en l’absence d’un expert, rétroconcevoir la base de données pour identifier les zones d’intérêt peut généralement être réalisé en une semaine ou deux (même en présence d’un système assez complexe). En plus d’exploiter toute documentation technique accessible concernant le système en question, nous suggérons de commencer par une extraction complète du schéma de la base de données, incluant:

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

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

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 également 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 également 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 également 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 supporte les formats de fichiers texte brut, les formats de fichier à plat (typiquement les formats CSV ou TSV) ainsi que les tableurs Microsoft Excel, tant pour les opérations de lecture qu’en écriture. La section Read and Write Files 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 :

Plain text est utilisé à la place des tableurs (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 ni 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 partagent le même format à travers les tables.
Les montants monétaires isolent la devise dans une colonne distincte
Le nom du fichier correspond au nom de 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 100Mo, nous recommandons de compresser le fichier à l’aide de GZIP.

Pour le transfert, nous recommandons d’utiliser SFTP avec authentification par clé publique.

Tables partitionnées

Nous recommandons de partitionner les tables qui sont trop volumineuses pour être rétéléversées intégralement vers Lokad de façon quotidienne. La partition permet généralement des envois incrémentaux si la partition reflète l’âge des données. En règle générale, les tables contenant moins d’un million de lignes ne valent généralement pas l’effort de les partitionner.

Lors de la partition d’une table en une liste de fichiers, le schéma de nommage recommandé consiste à regrouper les fichiers dans un sous-dossier dédié au sein de /input (nommé d’après la table concernée), 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
/input/mytable/mytable-2022-10-..

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

Microsoft Excel

La plateforme Lokad supporte la lecture de données à partir de tableurs Microsoft Excel, tant que le tableur 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 devrait éviter de transférer les tableurs vers Lokad.

Les tableurs sont acceptables si les fichiers sont téléversés manuellement vers Lokad, par opposition à un transfert par le pipeline d’extraction de données automatisé. Les téléversements manuels sont acceptables si :

Les données n’existent pas (encore) dans les systèmes d’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éversés manuellement.

Écrasement de fichiers

Les fichiers dans le système de fichiers Lokad représentent les données telles que perçues par Lokad. L’écrasement des fichiers existants est la méthode recommandée pour rafraîchir les tables extraites non partitionnées. Dans le cas d’une table partitionnée, il est attendu par défaut qu’un nouveau fichier soit 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) ont été transférés vers 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, dès la toute première étape du pipeline au sein de Lokad, nous recommandons de mettre en place des tableaux de bord de santé des données. Ces tableaux de bord sont destinés au département informatique (bien qu’il ne soit pas attendu qu’ils en aient la charge). Le but collectif de ces tableaux de bord est de signaler toute anomalie de données et d’accélérer la résolution éventuelle par le département informatique. Cette mise en œuvre, comme le reste de la recette numérique qui pilote l’initiative supply chain optimisée, est censée être réalisée par un expert supply chain, voire 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 est stabilisé, nous recommandons de produire une spécification pour l’extraction de données. Ce document devrait lister tous les fichiers attendus et leurs colonnes, ainsi que le calendrier de l’extraction de données. La stabilisation du pipeline de données est prévue dans les six mois suivant le lancement de l’initiative. Ce document devrait être approuvé conjointement par le département informatique et le département supply chain. Ce document contient les détails des données qui devraient être mises à disposition, en temps opportun, par le département informatique sur la plateforme Lokad.

Le format des données peut encore être révisé ultérieurement, mais il est attendu que le département informatique en informe le département supply chain avant d’apporter toute modification au format des données ou au calendrier associé. En général, une fois la spécification approuvée, les opérations supply chain devraient s’appuyer, pour les besoins de la production, sur l’intégrité de l’extraction de données. Ainsi, en cas de changement, le département supply chain devrait prévoir une « période de grâce » raisonnable, suffisante pour mettre à jour la logique au sein de Lokad (afin d’accommoder le format des données révisé).

Comme produire une spécification détaillée nécessite un temps et un effort considérables, nous recommandons de retarder 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 – tant pour l’extraction de données que pour les segments analytiques – évolue rapidement. 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 supply chain (par exemple, les réapprovisionnements des stocks) générées sur la plateforme Lokad peuvent être exportées sous forme de fichiers plats pour être réintégrées dans les systèmes d’entreprise. Ce mécanisme est appelé la feedback loop. Notre expérience indique que la feedback loop est peu susceptible d’être implémentée dans les quatre mois suivant le lancement de l’initiative. La confiance dans la recette numérique requise pour permettre à ne serait-ce qu’une partie de la supply chain de fonctionner en pilotage automatique est considérable, et ce niveau de confiance peut prendre plusieurs mois à se cultiver. Ainsi, la feedback loop n’est pas un enjeu au début de l’initiative.

D’après notre expérience, la mise en place de la feedback loop représente un défi bien moindre que celle du pipeline d’extraction de données. Par exemple, les chiffres, tels qu’ils sont produits au sein de Lokad, sont censés être faisant autorité et définitifs ; s’il y a d’autres règles à appliquer pour transformer ces chiffres en valeurs exploitables (par exemple, en appliquant des MOQs), alors la recette numérique est incomplète et doit être corrigée du côté Lokad. D’autre part, la plateforme Lokad a la capacité de traiter et de produire toute forme de données tant qu’elle est raisonnablement tabulaire. Ainsi, la simplicité de la feedback loop est conçue pour refléter la simplicité des décisions supply chain. Par exemple, il peut y avoir des dizaines de contraintes qui déterminent 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èce.

Cependant, nous recommandons que la plateforme Lokad ne se voie pas accorder un accès direct aux systèmes d’entreprise du client. À la place, les fichiers devraient être mis à disposition en temps utile dans le système de fichiers Lokad. Le département informatique reste en charge d’importer ces données dans les systèmes d’entreprise. Cela garantit qu’une éventuelle faille de sécurité du compte Lokad ne puisse pas être utilisée pour accéder à d’autres systèmes au sein de l’entreprise. De plus, cela offre la possibilité de reporter cette opération de feedback si elle entre en conflit avec une autre opération réalisée par le département informatique sur les systèmes d’entreprise.

Étant donné que la feedback loop implique, par définition, des données relatives aux opérations réelles de supply chain, 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 approuvé conjointement par les départements informatique et supply chain.