Le pipeline d'extraction de données

Ce document est destiné à servir de guide pour les départements informatiques afin de construire un pipeline qui extrait des données à partir des systèmes d’information existants et rend ces données accessibles au sein de 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 la Supply Chain Quantitative. Le document couvre l’approche recommandée par Lokad, incluant 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.

Motivation et contexte

Lokad définit une initiative de la Supply Chain Quantitative comme une démarche qui fournit 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’optimization prédictive liés à la supply chain.

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 d’exploitation, diminuer ses besoins en fonds de roulement et améliorer sa qualité de service. À tout le moins, l’entreprise devrait être en mesure de réviser ce mélange de coûts, de trésorerie 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 soulève les questions suivantes :

• Quelles données doivent être transférées à 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 sont généralement fournies par les données transactionnelles historiques principales de l’entreprise (les ventes historiques, par exemple).

Le département informatique 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 à venir, ce qui est spécifiquement requis de la part du département informatique 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. Toutefois, même lorsque ces ingénieurs sont en interne, nous recommandons de les affecter au département de la supply chain, plutôt qu’au département informatique.

Que cette partie de l’initiative de la supply chain soit externalisée ou non, la perspective exposée dans ce document demeure la même.

Perspective technique de haut niveau

Lokad est une couche analytique qui opère par-dessus les 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’optimization prédictive qui, en pratique, ne peuvent pas être mises en œuvre dans le cadre d’un système transactionnel traditionnel.

Chaque compte Lokad est accompagné 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 audience informatique (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 téléversées sur le système de fichiers de Lokad.

Sauf accord contraire, le département informatique du client est responsable de tout ce qui concerne les données jusqu’au moment où les fichiers plats sont téléversé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), ce qui confère au département informatique une certaine marge de manœuvre à 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 pour la supply chain.

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 commerciales – pour ne citer qu’elles – sont des bénéficiaires potentiels des mêmes données historiques de ventes 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).

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 pour l’entreprise. Il est à 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à.

Le périmètre des données pertinentes

La supply chain concerne l’optimization des décisions liées au flux de marchandises physiques (achats, transport, production, ventes, etc.). En conséquence, les données les plus pertinentes pour une initiative d’optimization prédictive sont presque toujours celles qui décrivent les flux se produisant 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 très flexible dans ses capacités de traitement ; il n’existe donc aucune exigence stricte en matière de données. Très probablement, le client ne sera pas en mesure de fournir bon nombre des éléments de données listés ci-dessous, et Lokad est capable d’opérer dans ces limitations. Ainsi, la liste ci-dessous tente d’être aussi complète que possible pour identifier des sources de données utiles, sans exiger la fourniture rigoureuse de chacune d’entre elles.

Catalogue de produits: La liste des produits (ou articles, références, 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 existe, est pertinente – tant pour le reporting que pour l’analyse. 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 – d’un point de vue supply chain – est pertinente. Les relations entre les produits – comme les nomenclatures (BOMs) – le sont aussi.

Historique des commandes de vente: La liste des commandes de vente historiques du client. Cette liste est importante, car les ventes constituent presque toujours le meilleur indicateur dont dispose l’entreprise pour estimer la demande du marché. Ces données devraient inclure les montants monétaires associés aux transactions, puisque l’optimization de la supply chain doit s’effectuer d’un point de vue financier. (Ce point de vue financier est repris plus en détail par la suite.) Lorsque cela est possible, il est (toujours) préférable de fournir les 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 retard, annulées, reportées, modifiées, des retours, etc., autant de points de données potentiellement pertinents. Si les clients sont identifiés dans ces données, les identifiants client anonymisés deviennent pertinents. (Les données personnelles ayant 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 (pas encore réceptionnées). Cette liste est importante car les commandes d’achat constituent presque toujours le meilleur indicateur pour estimer les délais fournisseurs et leur taux 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. Autant que 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 (pas encore exécutés). Cette liste est importante car ces ordres reflètent le flux de transformation des marchandises qui se produit au sein de l’entreprise, tout en permettant d’identifier les goulots d’étranglement éventuels dans la supply chain. Selon la situation, la production peut présenter 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 historiques de stocks du client, en cas de présence de plusieurs sites. Cette liste est importante car elle éclaire l’origine des stocks utilisés soit pour déclencher les processus de production, soit pour servir les clients. Selon la situation, les délais de ces mouvements peuvent être variables. 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 (unités de gestion de stock) du client avec leurs niveaux de stock actuels. Cette liste est importante car elle caractérise l’état actuel de la supply chain. Selon le secteur, 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 la totalité des stocks peuvent être suivis au niveau du numéro de série. Si le suivi des stocks par numéro de série est utilisé, l’ensemble des numéros de série et leurs emplacements associés est pertinent. Plus généralement, 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 appliqués par le client lors de la vente des marchandises (et éventuellement des services associés). Cette liste est importante car la politique de tarification actuelle du client peut différer de ce qu’elle pratiquait auparavant. De nouveaux prix influent sur la demande future, mais également sur la rentabilité des décisions en matière de supply chain. Des promotions, des remises ou d’autres options de tarification peuvent également être présentes. Tous les éléments qui contribuent au calcul des montants facturés 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 usages de la supply chain (cependant, ces données sont rarement disponibles dans les systèmes métiers). Dès qu’un pipeline d’extraction de données est en place, ces instantanés peuvent être implémentés directement au sein de Lokad – sans intervention directe du département informatique du client.

Bien que cette liste soit déjà conséquente, en général, les entreprises disposent de bien plus de sources de données pertinentes que celles qui ont été listées ici. En règle générale, si une information est utile au département de la supply chain, elle est très probablement pertinente pour l’optimization prédictive et devrait ê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 vocation à être exhaustive. En pratique, il est important d’identifier quelles tables sont indispensables pour mettre l’initiative en production, par opposition à celles qui seraient simplement optionnelles. 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 et de passer à celle de l’optimization.

Ainsi, dans le cadre de notre pratique supply chain, Lokad recommande aux Supply Chain Scientists de produire un schéma priorisé des données préparées et de partager ce document avec le département informatique du client dès le début de l’initiative. Ce document répertorie les tables – et leurs champs – qui sont censés être disponibles à la fin du segment de préparation des données. Il indique é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 interprété comme une spécification des fichiers générés lors de la phase 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 fourni par le pipeline d’extraction, diffère largement du schéma « idéalisé » associé aux données préparées. Ce point est repris de manière plus détaillée 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 période dans le passé l’extraction de données doit-elle aller ? Deuxièmement, quelle est la profondeur historique minimale nécessaire pour que l’initiative de supply chain réussisse ?

De manière générale, nous recommandons d’extraire l’intégralité de l’historique disponible pour toutes les tables contenant moins d’un milliard de lignes. Modifier l’historique revient à perdre des données qui pourraient être pertinentes pour évaluer l’évolution à long terme de la supply chain. Des filtres seront mis en place côté Lokad dans le cadre de la préparation des données, de toute façon, ainsi 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’existe aucune exigence minimale. Si l’historique du système est court (par exemple, six mois), alors certains schémas statistiques, tels que la saisonnalité, ne peuvent être estimés. Cependant, les praticiens de la supply chain, qui doivent prendre les décisions d’intérêt 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 toute profondeur historique disponible, même si elle peut sembler limitée aux yeux du 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. Comme les données sont perçues comme manquantes, la viabilité de l’initiative de la Supply Chain Quantitative est remise en cause. Cependant, peu importe combien de données semblent être “manquantes”, les employés de l’organisation parviennent toujours à prendre les décisions nécessaires pour que la supply chain fonctionne. Bref, il y a une solution. L’approche technologique de Lokad repose sur le principe de tirer le maximum de ce qui est disponible – exactement comme le font les employés. Cette approche s’oppose aux logiciels d’entreprise classiques qui imposent des exigences définitives en matière de données et ne fonctionneront pas tant que toutes ces exigences ne seront pas satisfaites.

Selon notre expérience, il existe deux grandes catégories de données “manquantes” qu’il convient de distinguer : premièrement, les données qui devraient être intégrées dans le système d’entreprise ; deuxièmement, les données considérées comme extrêmement bénéfiques pour le système analytique (tel que Lokad).

Les quantités minimales de commande (MOQs), 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 du point de vue de l’optimization de la supply chain. Ces informations peuvent être éparpillées dans des feuilles de calcul et des emails, ce qui empêche toute analyse structurée directe côté Lokad. Face à ces situations, nous suggérons d’utiliser des heuristiques (à coder par Lokad) et des feuilles de calcul ad hoc (à téléverser sur Lokad). Une fois la recette numérique opérationnelle, Lokad fera appel au département 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 comptent vraiment et dans quelle mesure.

Les données de veille concurrentielle, telles que les prix des concurrents, constituent une catégorie réputée 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 engendre souvent un coût important, sinon les entreprises s’en procureraient 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 supplémentaires.

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 RDBMS supportant 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 supply chain spécifiques qui sont en jeu. 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 extractions transactionnelles brutes garantissent que l’ensemble des informations disponibles dans les systèmes d’entreprise devient accessible dans Lokad.

De plus, la préparation des données ajoute sa propre couche de complexité par-dessus celle des systèmes d’entreprise eux-mêmes. Certes, la recette numérique qui permet d’atteindre l’optimization de la supply chain désirée ne peut éviter de faire face à des classes de complexité intrinsèque. Cependant, si cette recette numérique doit aussi gérer la complexité accidentelle introduite par une préparation préalable des données, elle transforme un problème déjà difficile en un problème démesurément complexe. Les extractions transactionnelles brutes permettent d’éviter que Lokad ne se retrouve à traiter un problème encore plus important que celui qui doit être résolu.

Du point de vue informatique, les extractions transactionnelles brutes sont simples. Des copies de tables simples doivent être utilisées (par exemple, SELECT * FROM MyTable), ce qui est la forme la plus élémentaire de requêtes sur une base de données relationnelle. Ces requêtes sont simples, car aucun filtre n’est appliqué, et performantes, puisqu’aucune jointure n’est impliquée. Cependant, les tables très volumineuses nécessitent une attention particulière. Ce point est abordé ci-dessous.

Si un data lake est en place, celui-ci devrait miroiter les données relationnelles telles qu’elles se trouvent dans les systèmes d’entreprise. Tous les systèmes de base de données grand public possèdent des 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, le mirroring des données est de beaucoup plus simple que la préparation des données – notamment du point de vue du département informatique, puisque cette préparation dépend fortement du problème spécifique à résoudre.

L’antipattern d’extraction BI

Les données à envoyer à Lokad ne doivent pas provenir d’une source secondaire (par exemple, d’un système de Business Intelligence (BI)) dans lequel les données ont déjà été largement modifiées, généralement pour le bénéfice d’une consommation directe par l’utilisateur final. Bien qu’extraire des données d’un système BI soit plus simple 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 celles-ci sont agrégées en séries temporelles journalières / hebdomadaires / mensuelles.

De plus, de nombreuses complications difficiles à visualiser mais pertinentes, telles que les commandes à lignes multiples, 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 entrées de données transactionnelles incorrectes sont rares et se produisent typiquement une ou deux fois par millier d’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 erronées sur les données, plutôt que dans la qualité intrinsèque des données elles-mêmes.

Les niveaux de stocks en magasin pour les grands réseaux de distribution 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 stocks sont (à tort) supposés être précis, les résultats seront dénués de sens. Nous abordons cette situation spécifique avec une vision probabiliste des niveaux de stocks, en acceptant l’incertitude plutôt qu’en la rejetant.

En fin de compte, les systèmes de Lokad ont été conçus pour recevoir les données et permettre au client de faire fonctionner sa supply chain sans se soucier de ces préoccupations. Lokad établit une sémantique des données pour traiter ces questions, ce qui représente la partie la plus difficile de l’étape 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 une charge, et non comme un atout. Nous décourageons fortement 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 discussion ci-dessous) qui contiennent des identifiants personnels (par exemple, nom, adresse, numéro de téléphone, email, etc.).

Ces identifiants personnels peuvent être remplacés par des identifiants opaques et 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 schémas liés à la fidélisation de la clientèle – tels que l’impact négatif des ruptures de stocks. Contrairement à la plupart des technologies de prévision qui ne fonctionnent 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 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 des biens achetés, transformés et vendus par le client revêtent une importance primordiale pour l’optimization de la supply chain proposée par Lokad. En fait, Lokad met l’accent sur une perspective financière de la supply chain qui optimise les dollars de rendement plutôt que les pourcentages d’erreur.

Contrairement aux fournisseurs qui ne prennent en compte que les données relatives aux quantités de stocks, Lokad utilise les données financières du client – si celles-ci sont disponibles. Logiquement, les coûts supply chain les plus préoccupants se concentrent aux extrémités : une demande exceptionnellement élevée engendre des ruptures de stocks, tandis qu’une demande exceptionnellement faible conduit à des radiations de stocks. Entre ces deux extrêmes, les stocks tournent comme il se doit. Ainsi, afin d’optimiser véritablement les décisions relatives aux stocks, il faut établir un compromis financier concernant ces risques. Lokad exploite les données financières du client pour calculer ce 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 considérable qu’une extraction ponctuelle de données. Si possible, nous recommandons vivement d’automatiser l’extraction des données, éventuellement par étapes si le nombre de tables concernées 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 paragraphes suivants.

Il existe trois raisons principales d’opter pour une approche par pipeline de données.

Premièrement, du point de vue du praticien de la supply chain, des données vieilles de 3 semaines sont du passé. Les résultats obtenus à partir de données obsolètes sont sans pertinence pour les décisions supply chain actuelles. Une extraction ponctuelle produirait des résultats basés sur un seul instantané de l’historique commercial du client, ce qui limiterait leur valeur. De plus, les praticiens de la supply chain ont besoin de voir le système analytique en action pour avoir confiance en 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, elle est préférable aux alternatives. Un pipeline de données peu fiable met en péril 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 planifiées pour perfectionner le processus d’extraction, certaines problématiques n’apparaissant qu’intermittemment. La meilleure solution pour résoudre ces problèmes est de démarrer le pipeline de données dès que possible, permettant ainsi à Lokad d’identifier et de régler les éventuelles anomalies. En particulier, les exécutions programmées constituent l’une des options les plus sûres pour évaluer la performance end-to-end 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 des 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 départements informatiques sont souvent sous une énorme pression pour livrer de nombreux projets, et construire un pipeline d’extraction de données représente une tâche supplémentaire à laquelle ils doivent faire face. Il est donc tentant – pour le département informatique – de reporter la partie pipeline, en 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 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 de rafraîchir tous les pipelines de données – tant les segments d’extraction 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 la seule façon d’obtenir un processus end-to-end 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 de travail en cours (par exemple, extraire le jeudi soir toutes les données historiques pertinentes jusqu’à la fin de la journée). 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 actualisés 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 entièrement re-téléversées sur Lokad chaque jour, des chargements incrémentiels doivent être utilisés. Nous recommandons que ces chargements respectent 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. Respecter cette règle est important pour garantir 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 départements informatiques connaissent entre 1 et 2 pannes de pipeline par an. Lorsque l’upload quotidien échoue, la dernière journée de données est compromise. Si chaque upload quotidien ne couvre qu’une seule journée (sans chevauchement entre les uploads), Lokad se retrouve avec un historique de données partiellement corrompu. La correction de cet historique, du côté de Lokad, nécessite une seconde intervention manuelle de la part du département informatique, en plus de la réparation de ce qui avait empêché le bon fonctionnement du pipeline dès le départ. Cette « réparation de l’historique des données » risque d’être retardée de quelques jours – car il s’agit d’une opération inhabituelle pour le département informatique. Pendant ce temps, les résultats renvoyés par Lokad sont négativement impactés, puisque certaines données récentes se retrouvent partiellement corrompues.

En revanche, si chaque upload quotidien couvre les deux dernières semaines complètes de travail, plus la semaine en cours, une exécution quotidienne échouée du pipeline d’extraction de données bénéficie d’une récupération complète dès le lendemain. En effet, comme le pipeline d’extraction de données fait partie des opérations de routine du département informatique, il est probable que le retour à un fonctionnement normal intervienne en une journée ouvrable. Cette récupération ne nécessite aucune interaction spécifique entre le département informatique et le support de Lokad, ni avec les utilisateurs finaux de la solution Lokad. La correction des données est automatiquement assurée par les écrasements effectués quotidiennement sur la fenêtre 2+1.

La règle 2+1 reflète un compromis fondé 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 les éventuels problèmes du pipeline d’extraction de données soient résolus en une journée ouvrable, le département informatique peut avoir des priorités plus urgentes. En effet, le pipeline défaillant n’est peut-être qu’un symptôme d’un problème plus grave que le département souhaite résoudre en priorité. Ainsi, la récupération peut prendre quelques jours. La règle 2+1 garantit que tant que le département informatique parvient à réparer le pipeline en moins de deux semaines, les opérations pourront reprendre comme d’habitude avec le moins d’impact possible 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 de calcul, contrecarrant ainsi la toute raison pour laquelle les uploads incrémentiels ont été introduits dès le départ.

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 téléchargement quotidien couvre les deux derniers mois complets, plus le mois en cours.

Identifier les tables et colonnes pertinentes

La grande majorité des logiciels d’entreprise est construite sur des bases de données relationnelles. Bien que des API web puissent exister, d’après notre expérience, ces API n’offrent que rarement des performances satisfaisantes lorsqu’il s’agit d’extractions complètes programmées de l’historique. 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 aucune jointure.

Ainsi, une fois qu’un système d’information (par exemple, ERP) est jugé être une source de données pertinente pour l’initiative, et en supposant que la base de données relationnelle sous-jacente soit accessible, il convient d’identifier la liste restreinte spécifique des tables et colonnes pertinentes. De nombreux systèmes d’information 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 n’a pas besoin de plus d’une douzaine de tables pour démarrer, et seulement quelques dizaines pour atteindre un haut niveau de couverture de données.

Si l’entreprise dispose d’un expert connaissant le schéma de la base de données du système d’information, tirer parti de cette expertise constitue le moyen le plus simple d’identifier les tables pertinentes de la base de données. Cependant, en l’absence d’un tel expert, l’ingénierie inverse de la base de données pour identifier les zones d’intérêt peut généralement être réalisée en une ou deux semaines (même dans le cas d’un système assez complexe). En plus de tirer parti de 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 :

• the table name
• the column name
• the column type
• the table size

Nous suggérons de rassembler ces informations dans un tableur. Les tables potentielles peuvent être identifiées par leurs noms et leurs tailles. Nous recommandons de commencer par un examen approfondi des plus grandes tables, car c’est généralement là que l’on peut découvrir les plus pertinentes (pour une initiative supply chain optimisée). Pour inspecter une table, nous suggérons un examen visuel de quelques dizaines de lignes de données. Les observations doivent ê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 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 la taille de toutes les tables :

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 tables :

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 le texte brut, les formats de fichiers plats (généralement au format CSV ou TSV) ainsi que les tableurs Microsoft Excel, tant pour la lecture que pour l’écriture. La section Lire et écrire des fichiers documente les capacités d’I/O de Lokad. Bien que Lokad prenne en charge une grande diversité d’options de mise en forme, nous recommandons ce qui suit :

• Texte brut 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 originaux des colonnes.
• Les noms de colonnes ne contiennent ni espaces ni 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 dans toutes les tables.
• Les montants monétaires isolent la devise dans une colonne séparée.
• Le nom du fichier correspond au nom original de la table.
• /input est le dossier côté Lokad utilisé, par convention, pour déposer les fichiers extraits.

Chaque fois qu’un fichier plat extrait est plus grand que 100 Mo, nous recommandons de le compresser en utilisant GZIP.

Pour les transferts, 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 re-téléchargées en totalité vers Lokad quotidiennement de manière pratique. Le partitionnement permet généralement des chargements incrémentaux si la partition reflète l’ancienneté des données. En règle générale, les tables comportant moins d’un million de lignes ne justifient pas l’effort requis pour les partitionner.

Lors du partitionnement d’une table en une série de fichiers, le schéma de nommage recommandé consiste à rassembler 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
/..

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 Lokad supporte la lecture des 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échargés manuellement sur Lokad, plutôt que 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 d’information.
• Les données sont mises à jour très peu fréquemment.

/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 Lokad représentent les données telles que perçues par Lokad. Remplacer 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 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) sont 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) contenant 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é, la complétude et la fraîcheur des données extraites. Ainsi, comme toute première étape du pipeline au sein de Lokad, nous recommandons la mise en place de 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’ils en aient la charge). L’objectif collectif de ces tableaux de bord est de mettre en lumière tout problème de données et d’accélérer leur résolution éventuelle par le service informatique. Cette mise en œuvre, comme le reste de la recette numérique à l’origine de l’initiative supply chain optimisée, est censée être réalisée par un expert en supply chain, éventuellement par l’équipe de Lokad (dans le cadre d’un abonnement Platform+Experts).

Spécification de l’extraction de données

Une fois le pipeline d’extraction de données stabilisé, nous recommandons de produire une spécification de 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 doit être approuvé conjointement par le service informatique et le service supply chain. Ce document contient les détails des données que le service informatique doit mettre à disposition de la plateforme Lokad en temps opportun.

Le format des données peut encore être révisé ultérieurement, mais il est attendu du service informatique qu’il en informe le service supply chain avant d’apporter toute modification au format des données ou au calendrier associé. De manière générale, une fois la spécification approuvée, les opérations supply chain devraient se reposer, pour des besoins de production, sur l’intégrité de l’extraction de données. Ainsi, en cas de modification(s), le service supply chain devrait s’attendre à une « période de grâce » raisonnable, suffisante pour mettre à jour la logique au sein de Lokad (afin de s’adapter au format des données révisé).

Comme la production d’une spécification détaillée nécessite un temps et un effort significatifs, nous recommandons de retarder la production de ce document jusqu’à ce que le pipeline soit stabilisé. D’après notre expérience, durant les premiers mois, le pipeline – aussi bien sa partie extraction de données que ses segments analytiques – subit une évolution rapide. Cette évolution rapide risque 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 approvisionnements en stocks) générées au sein de la plateforme Lokad peuvent être exportées sous forme de fichiers plats afin d’être réintégrées dans le(s) système(s) d’information. Ce mécanisme est nommé la boucle de rétroaction. D’après notre expérience, il est peu probable que la boucle de rétroaction soit mise en place dans les quatre mois suivant le lancement de l’initiative. La confiance dans la recette numérique requise pour permettre à une partie même de la supply chain de fonctionner en mode pilote automatique est considérable, et ce degré de confiance peut prendre plusieurs mois à se développer. Ainsi, la boucle de rétroaction ne constitue pas une préoccupation au démarrage de l’initiative.

Selon notre expérience, la mise en place de la boucle de rétroaction représente un défi bien inférieur à celui du pipeline d’extraction de données. Par exemple, les chiffres produits au sein de Lokad sont censés être faisant autorité et définitifs ; s’il existe d’autres règles à appliquer pour transformer ces chiffres en nombres exploitables (par exemple, les MOQs appliquées), 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, pourvu qu’elles soient sous forme tabulaire. Ainsi, la simplicité de la boucle de rétroaction est conçue pour refléter la simplicité des décisions supply chain. Par exemple, il peut y avoir des dizaines de contraintes définissant si un bon de commande donné est valide ou non, mais le contenu du bon de commande final est une liste simple de quantités associées aux numéros de pièce.

Cependant, nous recommandons que la plateforme Lokad ne reçoive pas un accès direct aux systèmes d’information du client. À la place, les fichiers doivent être mis à disposition de manière opportune dans le système de fichiers Lokad. Le service informatique reste responsable de l’importation de ces données dans le(s) système(s) d’information. 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 rétroaction si elle entre en conflit avec une autre opération menée par le service informatique sur le(s) système(s) d’information.

Étant donné que la boucle de rétroaction 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 le sens inverse. Ce document doit également être approuvé conjointement par le service informatique et le service supply chain.