Analyse de l'entropie pour la découverte des systèmes informatiques de la supply chain
Le paysage informatique des supply chains est presque toujours complexe. En effet, par nature, les supply chains impliquent de multiples acteurs, de multiples sites, de multiples systèmes, etc. Par conséquent, l’élaboration d’informations basées sur les données dans les supply chains est un défi en raison de l’hétérogénéité même du paysage informatique. Trop souvent, les analyses de la supply chain fournissent des résultats absurdes précisément en raison de problèmes de qualité des données.
Chez Lokad, nous avons non seulement développé une pratique qui examine en détail le paysage informatique et les ensembles de données qui l’habitent, mais nous avons également créé des outils technologiques pour faciliter les opérations d’examen elles-mêmes. Dans cet article, nous détaillons une étape de notre méthodologie d’examen, qui est basée sur l’entropie de Shannon. Nous avons utilisé avec succès l’analyse de l’entropie pour plusieurs initiatives de supply chain à grande échelle.
Notre processus d’examen commence par passer en revue toutes les tables de base de données qui sont considérées comme pertinentes pour l’initiative de la supply chain. Les supply chains sont complexes et, par conséquent, les systèmes informatiques qui les exploitent reflètent cette complexité. De plus, les systèmes informatiques peuvent avoir évolué pendant plusieurs décennies, et des couches de complexité tendent à s’accumuler dans ces systèmes. Par conséquent, il n’est pas rare d’identifier des dizaines de tables de base de données, chaque table ayant des dizaines de colonnes, c’est-à-dire des champs dans la terminologie des bases de données.
Pour les grandes supply chains, nous avons observé des situations où le nombre total de champs distincts dépasse 10 000. En utilisant l’analyse de l’entropie, nous sommes en mesure d’éliminer immédiatement la moitié des colonnes et de réduire ainsi considérablement la quantité de travail restante.
Traiter autant de colonnes est une tâche considérable. Le problème n’est pas les capacités de traitement des données : avec le cloud computing et un stockage de données adéquat, il est relativement facile de traiter des milliers de colonnes. Le véritable 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 pour un champ occupe environ une page, lorsque les cas d’utilisation intéressants et les cas particuliers sont couverts. Sans une documentation appropriée des données, la sémantique des données est perdue, et il est très probable que toute analyse complexe effectuée sur les données souffrira de graves problèmes de qualité des données. Ainsi, avec 10 000 champs, nous sommes confrontés à la production d’un manuel de 10 000 pages, ce qui demande un effort vraiment monumental.
Pourtant, nous avons observé que ces grands systèmes informatiques transportent également une quantité massive de poids mort. Bien que le nombre total de champs semble très élevé, en pratique, cela ne signifie pas que chaque colonne trouvée dans le système contient des données significatives. À l’extrême, la colonne peut être entièrement vide ou constante et, par conséquent, ne contenir aucune information. Quelques champs peuvent être immédiatement écartés car ils sont réellement 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 date du jour où le système a été mis en marche ; le champ n’a jamais été réutilisé par la suite. Bien que les champs entièrement vides soient relativement rares, nous observons généralement que les champs dégénérés sont extrêmement nombreux. Ces champs contiennent des colonnes avec très peu de données, 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 peut avoir une colonne Incoterms qui n’est pas vide que dans 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 n’y a aucun intérêt à essayer de donner un sens à ces données. 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 un excellent candidat. L’entropie de Shannon est un outil mathématique permettant de mesurer la quantité d’information contenue dans un message. L’entropie est mesurée en Shannons, qui est une unité de mesure quelque peu similaire aux bits d’information. En considérant les valeurs trouvées dans la colonne elle-même comme le message, l’entropie de Shannon nous donne une mesure de l’information contenue dans la colonne exprimée en Shannons.
Bien que tout cela puisse sembler très théorique, mettre cette idée 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 d’entropie d’une table avec 3 champs.
read "data.csv" as T[*]
show table "Liste des 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 que réaliser un filtrage initial basé sur les mesures d’entropie élimine de manière fiable entre un tiers et deux tiers des champs initiaux de l’étendue d’intérêt. Les économies de temps et d’efforts sont très importantes : pour les grands projets de supply chain, nous parlons d’économies de plusieurs années-homme grâce à cette analyse.
Nous avons découvert involontairement 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, l’investigation d’un champ dégénéré s’avère généralement être une tâche épuisante. Comme le champ n’est pas utilisé - parfois plus du tout utilisé - personne n’est vraiment sûr que le champ est réellement dégénéré ou si le champ joue un rôle critique, mais obscur, dans les processus de la supply chain. En raison de la complexité des supply chains, il n’y a souvent personne qui peut affirmer de manière positive qu’un champ donné n’est pas utilisé. Le filtrage par entropie élimine immédiatement les pires contrevenants qui sont garantis de nous entraîner dans une chasse aux oies sauvages.
