L'analyse d'entropie pour la découverte des systèmes informatiques de supply chain
Le paysage informatique des supply chain est presque toujours complexe. En effet, par nature, les supply chain impliquent de multiples acteurs, de multiples sites, de multiples systèmes, etc. Par conséquent, construire des insights basés sur les données dans les supply chain est un défi en raison de l’hétérogénéité du paysage informatique. Trop fréquemment, l’analytique de supply chain fournit des résultats dénués de sens précisément à cause de problèmes « garbage in, garbage out ».
Chez Lokad, nous avons non seulement développé une démarche qui dresse un état des lieux complet du paysage informatique et des jeux de données qui l’habitent, mais nous avons également créé quelques briques technologiques pour faciliter ces opérations de recensement. Dans ce billet, nous détaillons une étape de notre méthodologie de recensement, qui repose sur l’entropie de Shannon. Nous avons exploité avec succès l’analyse de l’entropie pour plusieurs grandes initiatives de supply chain.
Notre processus de recensement commence par l’examen de toutes les tables de base de données considérées comme pertinentes pour l’initiative de supply chain. Les supply chain sont complexes et, par conséquent, les systèmes informatiques qui les gèrent reflètent cette complexité. De plus, ces systèmes informatiques peuvent évoluer depuis plusieurs décennies, et des couches de complexité tendent à s’accumuler sur ces systèmes. Par conséquent, il n’est pas rare d’identifier des dizaines de tables de base de données, chaque table comportant des dizaines de colonnes, c’est-à-dire des champs dans la terminologie des bases de données.
Pour de grandes supply chain, nous avons observé des situations où le nombre total de champs distincts dépasse 10 000. En exploitant l’analyse de l’entropie, nous sommes capables d’éliminer immédiatement la moitié des colonnes et, par conséquent, de réduire de manière significative le travail restant.
Gérer autant de colonnes est une entreprise de grande envergure. Le problème ne réside pas dans les capacités de traitement des données : avec cloud computing et un stockage de données adéquat, il est relativement simple de traiter des milliers de colonnes. Le vrai défi est de donner un sens à tous ces champs. En règle générale, nous estimons qu’une documentation bien rédigée d’un champ occupe environ une page, lorsqu’elle couvre des cas d’utilisation intéressants et des cas limites. Sans documentation adéquate des données, la sémantique des données est perdue, et il est fort probable que toute analyse complexe réalisée sur les données souffre de sérieux problèmes de « garbage in, garbage out ». Ainsi, avec 10 000 champs, nous sommes confrontés à la production d’un manuel de 10 000 pages, ce qui requiert un effort véritablement monumental.
Pourtant, nous avons constaté que ces grands systèmes informatiques comportent également une quantité massive de poids mort. Bien que le nombre brut de champs semble très élevé, cela ne signifie pas que chaque colonne du système contient des données significatives. Dans les cas extrêmes, la colonne peut être entièrement vide ou constante et, par conséquent, ne contenir aucune information. Certains champs peuvent être immédiatement écartés car ils sont véritablement vides. Cependant, nous avons observé que les champs entièrement vides sont en réalité assez rares. Parfois, la seule information non constante dans la colonne remonte au jour où le système a été mis en service ; le champ n’a jamais été réutilisé par la suite. Bien que les champs réellement vides soient relativement rares, nous constatons généralement que les champs dégénérés sont extrêmement nombreux. Ces derniers contiennent des colonnes avec presque aucune donnée, bien en dessous de tout seuil raisonnable pour exploiter ces données à des fins de production.
Par exemple, une table PurchaseOrders contenant plus d’un million de lignes pourrait comporter une colonne Incoterms non vide dans seulement 100 lignes ; de plus, toutes ces lignes datent de plus de cinq ans, et 90 lignes contiennent l’entrée thisisatest. Dans ce cas, le champ Incoterms est clairement dégénéré, et il ne sert à rien de tenter de lui donner un sens. Pourtant, un filtre SQL naïf ne parviendra pas à identifier une telle colonne comme dégénérée.
Ainsi, un outil permettant d’identifier les colonnes dégénérées est nécessaire. Il s’avère que l’entropie de Shannon est une excellente candidate. L’entropie de Shannon est un outil mathématique permettant de mesurer la quantité d’information contenue dans un message. Celle-ci est mesurée en shannons, une unité de mesure quelque peu comparable aux bits d’information. En considérant les valeurs présentes dans la colonne elle-même comme le message, l’entropie de Shannon nous fournit une mesure de l’information contenue dans la colonne, exprimée en shannons.
Bien que tout cela puisse sembler hautement théorique, mettre cette approche en pratique est extrêmement simple. Il suffit d’utiliser l’agrégateur entropy() fourni par Envision. Le petit script ci-dessous illustre comment nous pouvons utiliser Envision pour produire l’analyse de l’entropie d’une table comportant 3 champs.
read "data.csv" as T[*]
show table "List of entropies" with
entropy(T.Field1)
entropy(T.Field2)
entropy(T.Field3)
Tout champ associé à une entropie inférieure à 0,1 est un très bon indicateur d’une colonne dégénérée. Si l’entropie est inférieure à 0,01, la colonne est garantie d’être dégénérée.
Notre expérience indique qu’effectuer un filtrage initial basé sur des mesures d’entropie élimine de manière fiable entre un tiers et deux tiers des champs initiaux du périmètre d’intérêt. Les économies de temps et d’efforts sont très substantielles : pour de grands projets de supply chain, il s’agit de plusieurs années-homme économisées grâce à cette analyse.
Nous avons découvert par inadvertance un effet secondaire positif du filtrage par entropie : il réduit la fatigue informatique associée à la (re)découverte des systèmes informatiques. En effet, enquêter sur un champ dégénéré s’avère généralement être une tâche épuisante. Puisque le champ n’est pas utilisé – parfois plus – personne n’est vraiment sûr s’il est effectivement dégénéré ou s’il joue un rôle critique, mais obscur, dans les processus de supply chain. En raison de la complexité des supply chain, il est souvent impossible d’affirmer avec certitude qu’un champ donné ne soit pas utilisé. Le filtrage par entropie élimine immédiatement les pires cas, nous évitant ainsi de nous lancer dans une quête vaine.
