La Data est une information ou un ensemble d’informations, sensible[2] ou non, collectée sur un individuune machine, un outil, un produit ou un service via une application à des fins d’utilisations diverses. Son usage, sa gestion et sa sécurité sont capitales pour les entreprises car, répondant à leurs besoins, elle leur permet d’accroitre leur chiffre d’affaires. Dans un service de vente ou sur un site d’achat, par exemple, les données recueillies comprennent généralement l’historique et la catégorie des achats, le modèle, le nom et/ou la marque de chaque produit acheté afin de permettre la réalisation de prévisions et la détermination de catégories d’individus prétendant à l’achat de tels produits à partir des données d’intention d’achat obtenues.

La Business Intelligence, aussi appelée informatique décisionnelle, est l’analyse de données structurées réalisée par des outils technologiques, fondée sur des pratiques techniques et des méthodes fonctionnelles offrant de l’information utile à tous les groupes de travail dans leurs prises de décisions au profit de leur entreprise.

Pour comprendre la Business Intelligence, il est important de comprendre l’usage de la donnée qui est réalisé au sein de l’entreprise à travers des outils informatiques, comme le montre le schéma simplifié ci-dessous. Ce système informatique n’étant pas techniquement et de façon pratique simple à mettre en place, contrairement à ce que l’on imagine en théorie, nous mettrons dans cet article l’accent sur son cycle de vie au sein de l’entreprise. Nous citerons et expliquerons le rôle de chacun des outils utilisés pour chaque étape du traitement de la donnée. Nous analyserons également l’importance de sortir des méthodes relationnelles traditionnelles avec le client et d’adopter des méthodes sous forme d’itérations dites Agiles.

1-    Analyse de l’information

Le passage à l’analyse de données (Cf. schéma ci-dessous) ne se décide pas précipitamment car elle demande la réalisation d’une analyse de l’information, qui se traduit dans un premier temps par le discernement et la connaissance du besoin du client et du métier, puis par la formulation de ce besoin, par la collecte d’informations appropriées et enfin par la définition de ce besoin. Cette définition du besoin est identifiée dans les grandes lignes d’un document, appelé CDC[3], Cahier des Charges, permettant le chiffrage du projet. Ce cahier des charges devient alors un support pour définir le DEB[4], Document d’Expression du Besoin, rédigé par la MOA[5], c’est-à-dire le client. Ce document contient de manière générale la rédaction théorique du Besoin de la MOA et peut être enrichi par un AMOA[6], un consultant fonctionnel (CF[7]) interne ou un prestataire[8] lors de la phase de cadrage du projet. Il permet de construire les maquettes et spécifications fonctionnelles du projet reprises dans le DFB[9], le Document Fonctionnel du Besoin, dans lequel sont définies : les règles de gestion, la structure des données, les schémas des tables traitées dans la base de données, les interactions des tables entre elles et des utilisateurs ainsi que la forme que peut avoir la solution. Ce même document, le DFB, permet à la MOE[10], l’équipe de développement, d’avoir un support pour réaliser le DCG[11], Document de Conception Général, qui induit une étude générale de conception architecturale du projet et de ses STD[12], Spécifications Techniques Détaillées, afin de permettre aux développeurs d’être en adéquation avec le résultat attendu : la solution finale. Les spécifications détaillées permettent à l’équipe de Maintenance d’assurer la maintenance corrective et évolutive de la solution lorsqu’elle est mise en place.

La définition du besoin, la collecte et l’analyse de l’information constitue la première partie d’un projet en Business Intelligence. Mais ne se limitant pas là, nous en étudierons à présent la seconde partie qui s’intéresse à la transformation de l’information, à l’analyse de données puis à leur synthétisation en plusieurs livrables ou rapports stratégiques. Cette transformation se fait de façon technique via des outils informatiques (Cf. Schéma ci-dessous).

2-    Analyse de données

L’analyse de données se résume de façon simplifiée à l’ETL[13], Extraction-Transformation-Chargement des données, que nous allons définir. Préalablement, il s’avère important de nettoyer les données qui peuvent avoir différents types d’erreurs : un processus permet d’identifier les données erronées et de les corriger de manière automatique grâce à un programme informatique ou manuellement, avant leur usage par l’ETL. Les données ne provenant pas toutes de mêmes sources, il existe en réalité différentes manières d’extraire des données. Ainsi, en observant le schéma le plus simple de la BI, nous constatons que la donnée peut venir de bases de données ou de fichiers structurés (xls, csv, xml, json, …), de façon directe ou par l’intermédiaire de logiciels (ERP, CRM,…). N’ayant été soumise à aucun traitement ou manipulation, c’est une donnée brute, qui peut être entrée dans le programme informatique d’outils décisionnels, appelé ETL, tels qu’Informatica Power Center ou Talend par exemple, pour subir des transformations en données statistiques (Cf. Schéma ci-dessous). Ces technologies transforment la donnée selon le besoin client, décrit dans les documents précédemment cités dans la présentation de l’analyse de l’information. Après ce processus de transformation initié par l’ETL, la donnée est directement chargée dans un entrepôt de données appelé DWH[14], Data WareHouse. Dans cet entrepôt, n’est stockée que de la donnée prête à être restituée en analyse via des documents de synthèse. Les livrables contenant de la donnée statistique issue du Data Warehouse sont alors réalisés par des outils décisionnels, appelé outils de restitution, sous forme documentaire, tels que SAP BI ou Cognos par exemple, ou sous forme applicative, tels que QLik ou Power BI, dans lesquels les données sont notamment présentées sous forme graphique (histogrammes, camemberts, …). Ces IHM[15] doivent être en conformité avec la demande exprimée par le client dans les documents DCG, DFB et DEB régulièrement mis à jour selon les nouvelles demandes exprimées par la MOA.

3- Méthodes Agiles

Par ailleurs, à présent, dans les entreprises, on se rend compte que la méthode traditionnelle du cycle de vie de la BI, basée sur un cycle de développement en cascade[16], est très lourde, puisqu’on observe que le temps qui s’écoule entre le moment où le client exprime son besoin et la livraison est très long, et admet difficilement une souplesse vis-à-vis de l’évolution du besoin du client. Ces méthodes et stratégies employées manquent ainsi souvent de transparence et de compréhension du besoin de la MOA. La participation du client lors des phases de développement du produit est en effet quasiment inexistante : la communication entre celui-ci et les équipes fonctionnelles et de développement est souvent très limitée, malgré une demande de souplesse du client vis-à-vis de l’évolution de son besoin et une exigence du respect des délais de livraison. Il en résulte généralement que les livrables ne sont pas conformes aux attentes exprimées par le client, générant alors tensions, perte de temps, d’argent et de confiance, voire même une rupture entre le client et l’entreprise de prestation.

Pour pallier à tous ces problèmes, en février 2001, dix-sept experts du domaine informatique, spécialistes du développement logiciel aux Etats-Unis, ont publié un manifeste pour le développement agile de logiciels, rendu public sous le nom de Manifeste Agile. Plusieurs méthodes dites agiles, présentées ci-dessous, y sont ainsi décrites. Ces experts, considérant que la méthode traditionnelle ne correspondait plus aux exigences des organisations, ont estimé qu’elles devraient se tourner vers de nouvelles pratiques. Les entreprises étant en effet entrées dans une nouvelle ère, où elles sont soumises à une évolution permanente et rapide de leur environnement, il est alors important de développer des méthodes de travail et de gestion de projets permettant de s’adapter à ces évolutions technologiques, sociétales et organisationnelles, ce à quoi répondent les méthodes agiles.

Ces méthodes sont un ensemble de pratiques de pilotages de projets, pensées de manière pragmatique, impliquant directement le client afin de permettre aux équipes de réalisation de concevoir et développer avec réactivité la demande exprimée par le client. Ces méthodes demandent l’implication de toutes les équipes concernées : MOA[17], AMOA[18], CF[19], CP[20] et Développeurs des équipes supports (déploiement, système, …) qui interagissent de façon importante, tous impliqués dans l’avancement, le planning et les revues de sprint notamment des projets (Cf. schéma ci-dessus, page 5), ayant un objectif commun de travail, en toute transparence et usant de souplesse, répartissant les tâches par priorité et effectuant des points réguliers sur l’avancement du projet, car le résultat visé est de répondre aux attentes du client en développant une confiance mutuelle et des échanges enrichissants pour les deux parties. Ce cycle de développement itératif, incrémental et adaptatif doit alors respecter certaines valeurs communes et/ou complémentaires.

Les valeurs fondamentales des méthodes Agiles, au nombre de quatre, détaillées en douze principes résumés en quelques lignes dans le paragraphe ci-dessous, sont : favoriser davantage l’interaction entre les individus que les processus et les outils technologiques ; privilégier un logiciel qui fonctionne plutôt qu’une documentation exhaustive ; préférer la collaboration avec les clients que la négociation contractuelle ; et enfin opter pour l’adaptation au changement plutôt que suivre un plan.

Lors d’un projet décisionnel, il est important de se focaliser et de mettre en application ces valeurs non seulement afin de créer une harmonie et une symbiose entre les équipes mais aussi pour obtenir un résultat final très satisfaisant. Les principes issus de ces valeurs sont alors centrés sur l’autonomie des ressources humaines, sur le dialogue et la communication en face-à-face ainsi que sur le maintien d’un rythme soutenable dans le processus de développement. Les équipes doivent développer des compétences techniques et managériales afin de devenir plus efficaces dans chaque étape de développement du produit opérationnel jusqu’à sa livraison. Enfin, les équipes seront capables de s’adapter à leur environnement et de modifier en conséquence leur mode fonctionnement, tel que le pratiquent les équipes travaillant par exemple sur le projet SID chez EOLE Consulting. Dans ce projet, les équipes travaillent en symbiose, s’appuient sur des outils de développement, de gestion de projets, favorisant les tâches définies prioritaires, en usant de méthodes plus souples et de communication en face-à-face, c’est-à-dire en proximité avec les métiers : ce projet est réalisé en méthode Agile, ce qui permet à EOLE de répondre efficacement aux attentes du client et de renouveler sa confiance.

Un projet BI peut ainsi être réalisé selon des méthodes pouvant être qualifiées d’agile, c’est par exemple le cas des RAD (Rapid Application Development), DSDM (Dynamic System Development), ASD (Adaptive Software Development), FDD (Feature Driven Development), BDD (Behavior Driven Development) et Crystal Clear. Deux de ces approches de méthodes agiles, de développement d’application ou d’amélioration continue, sont particulièrement utilisées actuellement : il s’agit de la Méthode Extreme Programming (XP), qui concerne la réintégration immédiate des processus de développement, et de la Méthode Scrum, qui concerne l’amélioration continue ; qui toutefois sont complémentaires, la méthode XP proposant les techniques d’obtention de la qualité du code complémentaire à Scrum dans un projet BI ou de système d’information.

Conclusion

Un projet Business Intelligence comprend ainsi deux grandes phases différentes et complémentaires : l’« Analyse de l’Information » et l’« Analyse de Données ». La première partie, l’Analyse de l’Information est axée sur des connaissances théoriques et des compétences relationnelles mais sur peu d’expertise technique : la connaissance du métier, du secteur d’activité, du marché et du management de projet sont ici très importantes. La seconde partie, l’Analyse de Données, est quant à elle davantage axée sur des connaissances techniques et sur une grande capacité d’adaptation aux nouvelles technologies et aux outils informatiques. Il s’avère néanmoins que ces deux phases peuvent être envisagées tant selon des méthodes traditionnelles, longues et coûteuses, que selon des méthodes Agiles, facilitant la collaboration entre les équipes pour un résultat apprécié. Nous préconisons donc d’utiliser la méthodologie Agile lors d’un projet BI en y formant les équipes du projet et y sensibilisant le client, les qualités importantes de la Business Intelligence résidant aujourd’hui dans sa capacité à faire appel à de nombreuses ressources et compétences théoriques, techniques et relationnelles en les intégrant et développant leur interaction au sein d’un même projet, permettant ainsi d’accroître la compétitivité de l’entreprise. La Business Intelligence est pour toutes ces raisons actuellement l’un des domaines les plus créateurs d’emploi.

Par Hasmiou Diallo, promotion 2015-2016 du M2 IESCI et Consultant BI chez EOLE Consulting

[1] BI : Business Intelligence

[2] Sensible : c’est-à-dire ici privée, on non sensible : publique

[3] CDC : Cahier des Charges

[4] DEB : Document d’Expression du Besoin

[5] MOA : Maîtrise d’Ouvrage

[6] AMOA : Assistant Maitrise d’Ouvrage

[7] CF : Consultant Fonctionnel

[8] Prestataire : Consultant d’une entreprise de Prestation

[9] DFB : Document Fonctionnel du Besoin

[10] MOE : Maîtrise d’œuvre (équipe de développement)

[11] DGC : Document de Conception Général

[12] STD : Spécifications Techniques Détaillées

[13] ETL : Extraction-Transformation-Chargement

[14] DWH : Data WareHouse

[15] IHM : Interface utilisateur ou de communication qui relie l’homme et la machine.

[16] Cycle de développement en cascade : Organisation d’un projet sous forme de phases linéaires et séquentielles, où chaque phase correspond à une spécialisation des tâches et dépend des résultats de la phase précédente.

[17] MOA : Maitrise d’Ouvrage (client)

[18] AMOA : Assistant Maitrise d’Ouvrage

[19] CF : Consultant Fonctionnel

[20] CP : Chef de Projet

L’article Comprendre le Processus d’un Projet en Business Intelligence est apparu en premier sur Master Intelligence Economique et Stratégies Compétitives.