Comment éviter les pièges avec les projets d'analyse de données

Une étude récente de Capgemini a révélé que 15 % des initiatives de Big Data en Europe échouent. Pour faire en sorte que votre projet fasse partie des 85 % qui réussissent, j'ai résumé les quatre principaux écueils à surveiller. (Cet article de blog contient les deux premiers pièges, les deux autres seront publiés dans un article de blog différent. )

En être conscient et les prendre en considération augmentera considérablement les chances de réussite de votre projet d'analyse de données. Ne vous inquiétez pas :vous n'êtes en aucun cas le seul à faire face à ces défis et écueils. Dans notre premier atelier d'analyse de données, nous voyons régulièrement des participants qui les rencontrent, jusqu'à la fin du projet. Ici, j'aimerais partager avec vous mes idées sur de nombreux ateliers et projets réussis, souligner les principaux pièges et les illustrer avec des exemples de cas d'utilisation.

1. L'initiateur - IT vs département

L'analyse des données et les mégadonnées ne sont pas une seule et même chose, même si elles sont souvent utilisées de manière interchangeable.

Les services informatiques voient souvent les projets à travers des « lunettes de données volumineuses ». Ils fournissent l'infrastructure pour collecter de grandes quantités de données; par exemple, sous la forme de clusters de bases de données. Ces bases de données stockent d'énormes volumes de données, ce qui en soi ne crée pas de valeur ajoutée pour l'entreprise. C'est pourquoi le projet d'analyse de données doit toujours avoir un objectif technologique et commercial clairement défini. La collecte de données juste pour le plaisir n'apporte aucun avantage à l'entreprise.

La valeur ajoutée n'apparaît que lorsque l'entreprise exploite les données et les informations qui en résultent. C'est là qu'interviennent ses départements (non administratifs). Ils définissent les objectifs qu'ils souhaitent atteindre avec l'analyse de données, et non avec le big data. Ils fournissent la compréhension technique qui permet aux data scientists de travailler avec les données de manière ciblée. Une coopération étroite entre le fournisseur d'idées (département) et les data scientists est donc un impératif absolu pour atteindre l'objectif défini du projet.

En d'autres termes :le succès ou l'échec d'un projet d'analyse de données dépend de ce qui et de la quantité de compréhension des processus techniques transmis aux scientifiques des données. Les ingénieurs en analyse de données jouent également un rôle important ici. Ils soutiennent la « traduction » et le transfert de connaissances entre les différentes disciplines. Les ingénieurs en analyse de données s'appuient sur leur expérience opérationnelle dans la fabrication ou la logistique et sur une solide compréhension de base des approches d'analyse de données. Les experts en données doivent non seulement comprendre l'objectif du projet, mais aussi et surtout les corrélations dans les données. Plus important encore, ils doivent voir sa relation avec le monde réel (machines, capteurs, etc.) et les étapes de processus associées.

Comme le montre l'étude Capgemini, les DSI sont souvent les initiateurs de projets d'analyse de données. Ce n'est pas en soi un problème, à condition que les autres services soient étroitement associés et définissent les objectifs techniques du projet.

2. Toutes les données ne sont pas égales

Projet initié, son objectif défini – allez-y !

Arrêtez !

Avant que les data scientists puissent commencer, vous devez vérifier la qualité et la quantité des données.

a) Qualité des données

Ici, il est important de déterminer dans quel format les données sont disponibles, où rechercher quelles données et si les données sont transparentes entre différentes sources.

Exemple :

Pour intégrer un ensemble de données provenant de plusieurs sources, vous avez besoin d'un identifiant unique qui permette de collationner correctement les données. Cela peut être un horodatage ou un numéro de pièce, par exemple. L'utilisation d'un horodatage rend l'intégration plus compliquée si différents formats de date/heure sont utilisés dans les sources de données individuelles (format de date allemand vs américain, heure en UTS, etc.); cependant, cela reste possible. En revanche, c'est pratiquement impossible si des bases de temps différentes sont utilisées. C'est le cas lorsqu'il n'y a pas de synchronisation horaire uniforme qui génère les horodatages pour toutes les sources de données.

b) Quantité des données

Plus il y en a, mieux c'est, dit le proverbe. Mais en ce qui concerne l'analyse des données, ce n'est que partiellement vrai. De manière générale, bien sûr, plus vous avez de données, mieux c'est. Cependant, ici aussi, il y a un certain nombre d'aspects clés à considérer.

Selon la définition de l'objectif technique, il peut, par exemple, être important que les données sous-jacentes contiennent non seulement des résultats positifs, mais également un nombre suffisant de résultats négatifs.

Exemple :prédire un résultat négatif

Si l'objectif du projet est de développer un modèle pour prédire un résultat négatif, l'ensemble de données d'apprentissage utilisé pour entraîner le modèle de prédiction doit contenir un nombre suffisant de résultats négatifs. Sinon, le modèle n'est pas capable d'apprendre ces résultats négatifs et sera donc incapable de les prédire - par conséquent, vous ne pouvez pas atteindre l'objectif du projet avec cet ensemble de données ! Pour cette raison, lors de la compilation de l'ensemble de données d'apprentissage, vous devez vous assurer qu'il contient une quantité suffisante du paramètre à prédire (variable cible) - dans l'exemple ci-dessus, des résultats négatifs. Une façon d'y parvenir est d'étendre la période à partir de laquelle les données sont collectées.

c) Les « bonnes » données

Il est donc clair que la quantité de données n'est pas le seul critère. Avant tout, vous avez besoin des bonnes données !

Qu'entendons-nous par « bonnes données » ?

Les données doivent contenir les informations pertinentes requises pour atteindre l'objectif technique du projet. Si, par exemple, vous souhaitez développer un modèle pour prédire la qualité du produit telle que définie par une mesure de rugosité de surface, cette variable doit être représentée dans le jeu de données. Si vous effectuez la mesure sans enregistrer ensuite la valeur mesurée, vous ne pourrez pas développer un modèle correspondant. Cela non plus n'est pas un problème insoluble, mais cela peut retarder les progrès car une base de données adéquate doit d'abord être générée (par exemple à l'aide d'une technologie de capteur supplémentaire, en sauvegardant les données pertinentes, etc.).

Qui s'assurera que votre projet d'analyse de données réussira ?

Source :Bosch.IO

Pour aider les experts à atteindre a), b) et c), nous avons pris l'expérience que nous avons acquise dans de nombreux projets réussis et l'avons regroupée dans des directives de qualité des données, que nous fournissons au début d'un projet. Nous traitons également ce sujet dans les ateliers initiaux en identifiant les cas d'utilisation qui offriront des gains rapides. De cette façon, nous sensibilisons les experts de la fabrication à ces sujets, ce qui s'avère toujours être un avantage certain pour les prochaines étapes du processus.