L’informatique décisionnelle
Thèse Professionnelle.
Ce document est une thèse professionnelle dont la problématique est : Quelles sont les bonnes pratiques dans la mise en place d’une solution décisionnelle et comment la maintenir en condition opérationnelle ?
Maxime Poletto
01/06/2012
Personnes ayant participées à la rédaction de cette thèse professionnelle :
Natacha SKRZYPCZAK : Manager SII et Ingénieur Décisionnel
Emmanuel LOUF : Ingénieur Décisionnel, Manager pendant 2 ans du centre de service BI pour le groupe ADEO
Thibaut RECULE : Ingénieur Décisionnel
Tristan WOJCIECHOWSKI : Ingénieur Décisionnel Fabrice BELLOTTI : Directeur des opérations chez SII
Chapitre 1 : ... 5
L’informatique décisionnelle... 5
I. Introduction ... 6
II. L’état du marché ... 7
1. Les acteurs ... 7
2. Le marché de la BI ... 7
a. Un marché en pleine croissance ... 7
III. Les bases de l’informatique décisionnelle ... 8
1. Définition ... 8
2. Les indicateurs ... 8
a. Passé ... 9
b. Présent ... 10
c. Futur ... 10
IV. Les ETL ... 11
1. Définition ... 11
2. Fonctionnement ... 11
V. Le Data Warehouse... 13
1. Définition : ... 13
2. Les principes ... 14
3. La conservation des données ... 16
a. Avantages et inconvénients : ... 16
b. Différence entre les données opérationnelles et décisionnelles ... 17
4. La Construction ... 18
5. En conclusion ... 21
VI. Les Outils de mesures ... 22
1. Le tableau ... 22
2. Tableau de bord ... 22
3. Le cube ... 23
4. L'hyper cube ... 24
5. OLAP ... 25
c. Définition ... 25
d. Plusieurs solutions ... 25
VII. Le data mining ... 28
1. Définition ... 28
VIII. Enjeux de l'informatique décisionnelle... 30
1. Le reporting ... 30
IX. Les risques de l’informatique décisionnelle... 31
1. Article du web ... 31
X. Conclusion ... 32
Chapitre 2 : ... 34
Les bonnes pratiques de mise en place d’un projet d’informatique décisionnelle ... 34
I. Introduction ... 35
II. Analyse ... 36
1. Définition du besoin client ... 36
3. Étude de l'existant ... 37
2. Bien définir les indicateurs ... 37
III. Les données ... 38
1. La définition des données ... 38
2. La fiabilité des données ... 39
IV. Les flux ... 40
1. Rappel ... 40
2. Création des flux ... 42
3. Nettoyage ... 42
a. Les doublons ... 42
b. Les incohérences ... 43
4. Reprise en cas d'échec ... 43
5. Planification ... 43
6. Bases de données intermédiaires ... 44
a. Table de chargement ... 44
b. Table de rejet ... 44
V. L’entrepôt de données ... 45
VI. La gestion du changement ... 47
1. Intégration des utilisateurs au projet ... 47
2. Le choix de l'outil ... 48
3. La relance ... 54
4. Les évolutions ... 54
5. Les environnements ... 55
6. La documentation ... 56
III. Gestion des erreurs... 57
1. La définition de l'erreur ... 57
2. Log d'erreur ... 57
3. Les Alertes ... 57
IV. L'intervention humaine ... 58
1. Une équipe dédiée ... 58
2. Un centre de service ... 58
a. La gestion des incidents ... 59
b. Les niveaux de services ... 61
V. Bilan en Conclusion du chapitre ... 62
VI. Bilan et conclusion Générale ... 63
1. Conclusion Générale ... 63
2. Bilan Personnel ... 64
Glossaire ... 65
Annexe : Questionnaire de Thèse Professionnelle ... 68
I. Les bonnes pratiques de mise en place d’un projet d’informatique décisionnelle ... 69
1. Quels conseils donneriez-vous pour bien débuter un projet BI ? (définition des indicateurs, sélectionner uniquement les données utiles, s’assurer de leur fiabilité) ... 69
2. Quels conseils donneriez-vous pour la création des flux ? (tables de chargement, gestion des rejets, reprise en cas d’échec, bien planifier les flux) ... 69
3. Quels conseils donneriez-vous pour la création de l’entrepôt de données ? (MCD, Outils, tables de rejet, tables de chargement, tables d’état, tables de fait, tables de dimension) ... 70
4. Quels conseils donneriez-vous pour la gestion des changements qu’entraînerait un projet BI ? (intégration des utilisateurs au projet) ... 70
5. Autres conseils ou bonnes pratiques sur la mise en place d’un projet BI (Expériences personnelles) ? ... 71
6. Personnes qui pourraient me renseigner sur le sujet ? ... 71
II. Le maintien en condition opérationnelle d’un projet d’informatique décisionnelle ... 72
1. Une fois le projet mis en place, quels conseils donneriez-vous pour le maintenir en condition opérationnelle ? (Gestion des erreurs, Système d’alerte, Équipe dédiée, centre de service) ... 72
Chapitre 1 :
L’informatique décisionnelle
I. Introduction
Par le passé, les entreprises prenaient leurs décisions selon l’intuition du pôle exécutif sans l’aide de l’informatique. Cela était dû au fait que les outils informatiques de l’époque ne permettaient pas d’analyser les données, ni de faire de calculs complexes.
Avec le temps et les progrès de l’informatique, les entreprises ont mis à jour leur processus de récupération de données qui commençaient à s’accumuler. Il fallait donc faire face à des problèmes de stockage et de compatibilité entre les divers systèmes de l’époque.
Tout cela rendait l’exploitation et l’analyse des données difficiles et coûteuses en temps.
Aujourd’hui, la récupération des données est beaucoup plus simple à gérer à l’aide de logiciels d’extraction de données (ETL). Ces logiciels stockent les données dans des entrepôts de données (data warehouse) qui permettent de stocker un très grand nombre de données.
La capacité de stockage de ces entrepôts de données, permet à des outils d’analyse de données, d’extrapoler et ainsi fournir une aide à la prise de décision. De nos jours, il est ainsi possible pour une entreprise de s’évaluer et d’anticiper grâce à l’informatique décisionnelle.
Dans ce chapitre, nous allons définir ce qu’est l’informatique décisionnelle, ses composants, les différents outils qu’elle utilise et enfin les risques de cette nouvelle science.
II. L’état du marché 1. Les acteurs
Le marché de l’informatique décisionnelle est composé de nombreux acteurs, mais seulement 4 d’entre eux représentent 70 % en 2007 du marché de la Business Intelligence (BI) :
• SAP (business object) :
22 %
• Oracle (Oracle BI Solutions) : 15 %
• SAS (SAS BI) : 14 %
• IBM (Cognos) : 12 %
• Microsoft (SSRS and SSAS) : 7 %
• Microstrategty : 3 %
• Autres Éditeurs open source:
27%
En 2009, 40 à 50% du marché de la BI est composé d’acteurs proposant des technologies Open Source qui sont très prisées par les entreprises de petite taille. En effet, aujourd’hui, le décisionnel est utilisé par un grand nombre d’entreprises de taille variable.
2. Le marché de la BI
a. Un marché en pleine croissance
En 2009, le marché du décisionnel était de 2.052 milliards d’euro rien que pour la France et 9 milliards de dollars dans le monde.
En 2009, le décisionnel a connu une croissance de 5.9%, ce qui représente 3 fois celle du logiciel.
III. Les bases de l’informatique décisionnelle
1. Définition
L’informatique décisionnelle (Decision Support System ou Business Intelligence) désigne les méthodes, les outils et les moyens qui permettent de collecter, consolider, modéliser les données d'une entreprise afin d'offrir une aide à la décision et de permettre au corps exécutif d’une entreprise d’avoir une vue d’ensemble de l’activité.
Plus simplement, l’informatique décisionnelle c’est la transformation de données brutes en information puis la transformation de l’information en savoir :
C’est ce savoir qui va fournir une aide à la décision, aux managers ou au corps exécutif d’une entreprise.
2. Les indicateurs
L’informatique décisionnelle est généralement utilisée pour : - Prédire et/ou gérer les ventes
- Evaluer le risque client (par exemple pour les banques et assurances)
- Définir des comportements de population afin d’aider les entreprises à définir leur cible client.
Ainsi on dit souvent qu’on utilise la BI dans le passé, le présent et le futur.
a. Passé
La BI est souvent utilisée pour analyser le passé, par exemple, on va comparer les ventes d’un produit sur plusieurs années ou sur une année afin de voir l’évolution :
b. Présent
La BI est également utilisée dans le reporting afin d’avoir une vue en temps réel d’une activité. Cela permet de savoir à tout moment où nous en sommes :
Généralement, on rend également ce type d’information visible de n’importe où avec la BI Mobile :
c. Futur
Enfin, grâce à des techniques scientifiques et l’aide de l’informatique, il est possible d’obtenir des prévisions sur le futur. Par exemple les ventes de l’année prochaine :
IV. Les ETL
Pour résumer, nous venons de voir que la BI permet de transformer des données en information et l’information en savoir, afin de générer des indicateurs très utiles. Mais comment ça fonctionne ?
Pour analyser les données, il est indispensable de les rassembler en un seul endroit.
Or, les données d’une entreprise se trouvent dans de multiples endroits et, souvent, elles ne sont pas cohérentes. Afin de rassembler et de nettoyer les données, nous utilisons un logiciel de type ETL.
1. Définition
Un outil appelé ETL (Extract, Transform and Load) extrait, nettoie et importe les données dans différentes sources et les charge dans un entrepôt de données (data warehouse).
2. Fonctionnement
Un ETL prend en charge différentes sources de données, en entrée et en sortie.
Une fois la création d’un flux d’extraction-transformation-chargement terminée, celui-ci peut être déclenché régulièrement à l’aide d’un outil de planification de tâches, ou d’ordonnancement.
Il est nécessaire de nettoyer et transformer les données pour :
- les homogénéiser : ceci permet de définir un format commun pour les données ; prenons l’exemple des dates : si certains utilisent le format français 12/01/2012 et d’autres le format us 01/12/2012, on risque une confusion de l’information.
- C’est également l’occasion de nettoyer les données et de supprimer les données anciennes ou incohérentes : par exemple, des produits sans nom ni prix …
a) Quelques ETL :
Open Source Propriétaire
Apatar CloverETL
Pentaho Data Integration Scriptella
Talend Open Studio
IBM InfoSphere DataStage Informatica PowerCenter
Oxio Data Intelligence solution ETL OpenText Genio
BusinessObjects Data Integrato
Cognos DecisionStream (Data Manager) Oracle / Warehouse Builde
SSIS Microsoft
V. Le Data Warehouse
Pour résumer, nous sommes partis de données brutes que nous avons nettoyées et transformées, mais où et comment les stocker ?
Nous allons stocker ces données dans une base de données particulière, appelée Data Warehouse.
1. Définition :
a. Data Warehouse
Un entrepôt de données (Data Warehouse en anglais) est un type de base de données utilisé pour collecter et stocker des informations provenant d’autres sources de
seul data warehouse, ou alors il existe différents data warehouses en fonction du sujet ou du métier en rapport avec chaque information (datamarts).
b. DataMart
Un magasin de données (DataMart en anglais) est un sous-ensemble d’une base de données relationnelle en informatique décisionnelle. Il est généralement exploité pour restituer des informations d’un métier spécifique, constituant pour ce dernier un ensemble d’indicateurs à vocation de pilotage de l’activité et d’aide à la décision. Un DataMart, est issu ou fait partie d’un Data Warehouse, et en reprend par conséquent la plupart des caractéristiques.
2. Les principes
a. L’objectif :
L’objectif d’un entrepôt de données est de stocker l’information de manière détaillée, afin de permettre la prise de décisions autour des activités majeures de l’entreprise. Dans un data warehouse, les données sont ainsi structurées par thèmes contrairement à celles, dans les systèmes de production, qui sont organisées par processus fonctionnel.
entreprise. On peut ainsi passer d’une vision verticale de l’entreprise à une vision transversale beaucoup plus riche en informations. Un entrepôt de données est orienté
«métier», en réponse aux différents métiers de l’entreprise.
b. Les différents axes d’analyse :
Un entrepôt de données est présenté selon différents axes d’analyse ou
«dimensions» (exemple : temps ou population de clients, type de produits etc.). L’entrepôt de données est fait pour stocker les données selon les besoins actuels et futurs de l’entreprise, et répondre à tous les utilisateurs.
Par conséquent, nous ne trouverons pas de règle puriste dans le stockage, ni de modélisation unique : l’entrepôt de données peut contenir certaines informations plus ou moins détaillées, provenant des sources de production, nécessaires à un besoin de management, tout comme des tables de faits.
c. Stables ?
L’entrepôt de données est stable et non modifiable. Ce qui permet de conserver l’évolution des informations et la traçabilité de la prise de décision. Une des règles à ne pas rater dans la conception et dans la mise à jour d’un data warehouse, c’est que les informations ne doivent jamais disparaître. Ainsi, la même requête exécutée à des moments différents (séparée par plusieurs mois par exemple) doit obligatoirement retrouver le même résultat.
Ainsi, les données d’un data warehouse ne sont jamais supprimées ni mises à jour.
Eventuellement un système de purge peut être mis en place pour des données obsolètes.
d. Homogénéité :
L’intégration d’un entrepôt de données est effectuée depuis des sources d’origines diverses (fichiers externes, etc). Dans un monde parfait, les données provenant d’un système d’information sont homogènes et l’entreprise possède les compétences nécessaires
C’est ici que cela se complique : afin d’obtenir la transversalité recherchée, il faut que le système d’information soit bien intégré. Cela n’est possible qu’au prix d’une forte normalisation et à la gestion des référentiels de données.
Tout ceci concerne les données internes mais aussi les données externes, car leur codification ainsi que leur niveau de détails, sont différents par rapport aux données internes. Il est indispensable que l’intégration d’un data warehouse soit réussie afin d’obtenir une vision homogène de l’entreprise. Pour arriver à cela, le système d’information se doit d’être bien structuré et, bien sûr, maîtrisé. Sans cela, l’intégration est vouée à l’échec car on ne peut garantir la qualité des données.
e. Archivage :
Le Data warehouse est archivé et donc daté, avec une conservation de l’historique et de son évolution pour permettre les analyses comparatives (par exemple, d’une année sur l’autre, etc.). La non-volatilité permet l’historisation. D’un point de vue fonctionnel, cette propriété permet de suivre dans le temps l’évolution des différentes valeurs des indicateurs à analyser. De fait, dans un data warehouse, un référentiel de temps est nécessaire.
3. La conservation des données
2 solutions pour conserver les données dans un data warehouse :
- sous forme élémentaire et détaillée (exemple : Pour une banque : conserver chaque opération sur chaque compte client, …) si la volumétrie le permet,
- sous forme agrégée, selon les axes ou dimensions d’analyse prévus (mais ces agrégations sont plus souvent réalisées dans les datamarts que dans les entrepôts de données).
a. Avantages et inconvénients :
Données sous forme élémentaire : Les Avantages :
- Un plus grand niveau de détails dans les données - Plusieurs axes d’analyse
- Possibilité de revenir en arrière (dans le passé) Les Inconvénients :
Données sous forme agrégée : Les Avantages :
- Les données sont rapides d’accès
- Nécessite moins de mémoire de stockage que la forme élémentaire
- L’analyse des données sera plus rapide et plus facile par rapport à la forme élémentaire
Les Inconvénients :
- Perte de détails dans les données
b. Différence entre les données opérationnelles et décisionnelles
Données opérationnelles Données décisionnelles Orientées application, détaillées, précises au
moment de l’accès
Orientées activité (thème, sujet), condensées, représentent des données historiques
Mise à jour interactive possible de la part des utilisateurs
Pas de mise à jour interactive de la part des utilisateurs
Accédées de façon unitaire par une personne à la fois
Utilisées par l’ensemble des analystes, gérées par sous-ensembles
Haute disponibilité en continu Exigence différente, haute disponibilité ponctuelle
Uniques (pas de redondance en théorie) Peuvent être redondantes Petite quantité de données utilisées par un
traitement
Grande quantité de données utilisées par les traitements
Réalisation des opérations au jour le jour Cycle de vie différent Forte probabilité d’accès Faible probabilité d’accès Utilisées de façon répétitive Utilisée de façon aléatoire
4. La Construction
Un entrepôt de données possède un modèle de données particulier : il comporte 3 types de tables :
- Des tables de dimension - Des tables de faits - Des tables d’agrégats
Table de Dimension
Table de faits
Table de faits : Chaque entrepôt de données inclut une ou plusieurs tables de faits. Centrale par rapport à un schéma en étoile ou en flocons, une table de faits capture les données qui mesurent les opérations de l'équipe. Les tables de faits contiennent habituellement de grands nombres de lignes, en particulier lorsqu'elles contiennent une ou plusieurs années d'historique pour un grand projet d'équipe.
Une caractéristique clé d'une table de faits est qu'elle contient des données numériques (faits) qui peuvent être résumées pour fournir des informations sur l'historique des opérations de la société.
Chaque table de faits inclut également un index multipart qui contient, comme clés étrangères, les clés primaires de tables de dimension connexes qui contiennent elles-mêmes les attributs des enregistrements de faits. Les tables de faits ne doivent pas contenir d'informations descriptives ni de données autres que les champs de mesures numériques et les champs d'index qui relient les faits aux entrées correspondantes dans les tables de dimension.
Table de dimension : Les tables de dimension contiennent les données brutes non calculées.
Elles contiennent des attributs sous forme de descriptions textuelles permettant de qualifier l’activité. Par exemple, on peut imaginer des tables de dimensions, catégorie de produit, temps et géographie et une table de faits vente, qui est le croisement des 3 tables de dimension.
Agrégat : D'une manière générale, le mot agrégat désigne l'action d'agréger, de regrouper des éléments. En BI les Agrégats sont les résultats calculés des données contenues dans une table de faits.
Exemple simple :
Dans cet exemple, l’agrégat « VenteGeoMoi »s contient les données agrégées des ventes (table de faits vente) en fonction de la localisation (dimension géographie) et du mois (dimension temps)
5. En conclusion
En informatique décisionnelle, on traite d’immenses volumes de données stockées dans des entrepôts de données qui sont des bases de données multi relationnelles dont le but est de conserver l’information de la manière la plus détaillée possible.
L’information se voit donc attribuer un numéro de version permettant donc le retour dans le temps et le suivi de l’évolution de l’information. Cette base de données ne peut donc pas suivre un scénario de modélisation Merise d’autant plus que le but futur de ce stockage est la recherche d’information.
On stocke les données de manière agrégée ou élémentaire. Le choix se fait au cas par cas. Si l’on a de la place et que l’on a besoin d’un maximum de détails, la forme élémentaire est conseillée. Si, ce qui nous intéresse c’est l’économie de place dans le stockage afin de fournir des recherches rapides peu détaillées, la forme agrégée est toute indiquée.
VI. Les Outils de mesures
L’informatique décisionnelle permet de mesurer des indicateurs aussi appelés mesures, faits ou métriques, qui sont sur plusieurs axes d’analyse, aussi appelés dimensions.
1. Le tableau
Par exemple :
le chiffre d'affaire, les ventes, les taxes, selon l'axe temps : par année, mois etc…
selon l'axe produit : famille, gamme et référence produit.
On obtient donc un tableau à deux entrées :
en lignes : les produits sur 3 niveaux (famille, gamme, référence), en colonnes : les années
Les tableaux croisés des principaux tableurs permettent de construire ce type de tableau de bord depuis une base de données.
2. Tableau de bord
Un tableau de bord est un outil constitué d’indicateurs permettant d’évaluer les performances d’une entreprise (ou organisation) à des moments donnés ou sur une certaine période par rapport à des valeurs de référence. Certains tableaux de bord permettent de visualiser l’état d’une activité en temps réel.
Un indicateur est l’association de plusieurs paramètres représentant l’évolution d’une activité (ventes, etc...). Un indicateur est toujours choisi en fonction des objectifs futurs de l’entreprise.
3. Le cube
Si l’on travaille avec un indicateur de type tableau et que l’on exprime le besoin d’ajouter un axe d’analyse supplémentaire, on devra alors travailler sur un cube qui possède une dimension de plus qu’un simple tableau.
Le champ page et les tableaux dynamiques du logiciel Excel permettent ce type de représentation
Un cube peut être représenté sous la forme d’un tableau N sur N qui permet un accès direct à l’information. De plus, le principe est simple à comprendre avec la forme géométrique de cet outil d’analyse.
Au niveau du stockage, le cube permet de stocker les données de manière agrégée avec plus ou moins de détails et offre un accès rapide à celles-ci grâce au moyen de navigation qu’il propose.
4. L'hyper cube
En partant du cube, si l’on souhaite travailler sur un axe d’analyse supplémentaire on travaillera alors sur un hyper cube. Un hyper cube est un cube qui possède plus de 3 dimensions.
Un hyper cube permet d’organiser un jeu de cube détaillé. Généralement on se sert d’un hyper cube afin de générer tous les cas d’analyses possibles, l’information est alors directement accessible. Bien sûr, il est possible de naviguer dans cet hyper cube et de zoomer sur un cube ou une série de cubes.
L'ensemble de ces caractéristiques définit le concept OLAP (On Line Analytical
5. OLAP
c. Définition
En informatique décisionnelle l’OLAP (online analytical processing ) est une suite de logiciels utilisés pour l’analyse sur les champs d’informations selon plusieurs axes depuis 1993, le but de cette suite de logiciels étant de générer des rapports d’analyse (par exemple les rapports d’analyse financière)
Ainsi, on peut conclure qu’OLAP en informatique décisionnelle apporte une analyse précise des données dans le but de fournir une aide à la décision au manager d’une entreprise ainsi qu’une meilleure vision de l’entreprise et de ses activités.
d. Plusieurs solutions
OLAP possède plusieurs déclinaisons permettant de stocker différemment les données selon les besoins de l’utilisateur :
R-OLAP (Relational OLAP)
D-OLAP (Dynamic ou Desktop OLAP) M-OLAP (Multidimensional OLAP) H-OLAP (Hybrid OLAP)
a) R-OLAP
En informatique décisionnelle, R-OLAP (R pour relationnel dans la technologie OLAP) est une technologie permettant le stockage et la modélisation des données sur une structure relationnelle. Cette technologie a l’avantage d’utiliser les ressources déjà existantes sur une machine : il n’est pas utile d’investir dans une nouvelle base de données multidimensionnelles.
Table de Dimension
Table de faits
Exemple de moteurs R-OLAP : Microsoft Analysis Services, Oracle 10g, MetaCube d'Informix et DSS Agent de MicroStrategy.
Dans une base R-OLAP, on ne stocke pas le cube en tant qu’objet, mais plus comme un modèle en étoile comme sur l’image ci-dessus.
• Les Avantages :
• possibilité de redescendre à la table de faits.
• peu de redondance.
• Inconvénient :
a) Le M-OLAP: Multidimensional OLAP
En M-OLAP, on travaille avec un hypercube multidimensionnel c'est-à-dire à n dimensions. Mais on agrège les données car le but de cette représentation est la rapidité d’accès aux données et donc d’analyse. Techniquement, on stocke dans un seul fichier tous les agrégats.
• Avantage : rapidité d’analyse
• Inconvénients :
• niveau de détail limité car on ne stocke pas toutes les cardinalités.
• redondance d’information
b) H-OLAP: Hybrid OLAP
Le H-OLAP regroupe les 2 technologies vues précédemment (en effet H pour hybrid), c'est-à-dire que l’on essaye de concilier rapidité d’exécution et détail des données.
Techniquement, selon les données, le système utilisera l’une des deux technologies.
• Avantage : accès rapide et détaillé
• Inconvénient : beaucoup de redondance.
VII. Le data mining
1. Définition
Le data mining est un ensemble de techniques tirées des mathématiques et de l’informatique permettant le « forage de données » c'est-à-dire la recherche d’informations dans de grands volumes de données. On parle également de « fouilles » car ces recherches permettent de découvrir de l’information cachée.
2. But et utilisation du data mining
Le data mining traite des données hétérogènes d'un volume gigantesque. Le data mining est surtout employé dans le marketing pour :
prévoir les ventes, l’état des stocks, etc…
cibler les opérations de marketing, fidéliser les clients,
cibler des niches de marché,
définir des comportements de population, suivre les indicateurs de production, contrôler la qualité et
détecter des défaillances, veille technologique.
3. Principe
Trois étapes théoriques sont suivies : exploration,
définition d'une structure, validation de cette structure.
Afin d’obtenir un modèle fiable, on répète le processus plusieurs fois.
4. Algorithmes
Le data mining utilise et combine des méthodes statistiques et adaptatives (machine learning). Les modèles à la mode sont lebagging (voir Glossaire), qui utilise une stratégie aléatoire en réalisant une famille de modèles qui sont ensuite agrégés et leboosting, qui privilégie une stratégie adaptative (voir Glossaire).
a. Exemple de modèle utilisé : Le Réseau de neurones
L’un des principaux modèles utilisés par le data mining est le réseau de neurones qui permet l’exploration des données.
Un neurone est une unité de calcul élémentaire dont le modèle est issu de certains principes de fonctionnement du neurone biologique.
b. Explication du calcul :
L'unité de calcul combine des entrées réelles x1,...,xn en une sortie réelle o. Les entrées n'ont pas toutes la même importance et à chaque entrée xi est associé un poids (ou coefficient synaptique) wi. L'unité calcule d'abord l'activité d'entrée. En règle générale, pour le neurone formel, l'activité en entrée est mesurée par la somme pondérée des entrées Si wixi.
VIII. Enjeux de l'informatique décisionnelle
Nous avons vu l’extraction des données depuis une base de données à l’aide d’un ETL puis leur insertion dans un data warehouse voire même dans des datamarts. Ces entrepôts de données permettent de produire des rapports qui répondent à la question « Que s’est-il passé ? », mais ils peuvent également être conçus pour répondre à la question « Pourquoi est-ce que cela s’est passé ? » et à la question « Que va-t-il se passer ? ». Dans un contexte d’analyse en temps réel, ils répondent également à la question « Que se passe-t-il en ce moment ? », voire dans le cas d’une solution d’entrepôt de données actives, « Que devrait-il se passer ? ».
1. Le reporting
Le reporting est l’ensemble des comptes rendus permettant à une entreprise de suivre son activité. Cela permet à l’entreprise de s’évaluer grâce à la création périodique de rapports et de bilans analytiques sur son activité. Ces rapports sont souvent destinés au manager ou au corps exécutif.
Le but de ces rapports et bilans réguliers est de faire un point ponctuel sur la stratégie de l’entreprise et ainsi permettre d’évaluer les moyens mis en œuvre. Mais ils fournissent également une aide à la décision pour les choix stratégiques et économiques de l’entreprise.
Le reporting est l'application la plus utilisée de l’informatique décisionnelle, il permet au corps exécutif :
de sélectionner des données sur une certaine période (production, secteur, etc...), de trier, regrouper ou répartir ces données selon les critères de leur choix,
de réaliser divers calculs (totaux, moyennes, écarts, comparatifs en diverses périodes, etc...),
fournir une représentation des résultats, synthétique ou détaillée, selon leurs besoins ou les attentes des dirigeants de l’entreprise.
Le reporting n’est pas comme la suite de logiciels OLAP, un logiciel d’aide à la décision, mais plutôt un logiciel d’évaluation pour l’entreprise.
IX. Les risques de l’informatique décisionnelle
Si l’informatique est capable de miracles comme celui de prévenir l’avenir, elle est également capable du pire, c'est-à-dire de se tromper, ce qui conduit les managers à prendre des décisions lourdes de conséquences vouées à l’échec.
Ce genre de problème arrive si l’informatique décisionnelle ou une partie de celle-ci a mal été mise en place. La cause la plus fréquente est de vouloir utiliser cette science à tout prix sans s’assurer de la validité des données et même de la quantité.
Une fois qu’un projet décisionnel est mis en place, le travail n’est pas fini. En effet, il convient de maintenir ce projet en condition opérationnelle afin de fournir des analyses fiables.
1. Article du web
Dans son article intitulé « Les pièges de la business intelligence », Alexis Molten précise bien que cette science n’est pas sans faille si elle est mal utilisée.
« De nombreux concepteurs de logiciels décisionnels ont présenté leurs outils comme étant des solutions, clé en main, miracles garantissant le succès.
Or, le danger tient justement de cette conception erronée des outils décisionnels.
Que vous achetiez le modèle dernier cri d'une pelle, un trou ne se creusera pas tout seul.
De la même manière, un outil décisionnel ne va pas vous apporter l'information que vous cherchez sur un plateau d'argent. Il va falloir que vous retroussiez les manches pour avoir ce que vous voulez. Un outil décisionnel pourra aider, mais ne pourra pas faire le travail à votre place. »
X. Conclusion
L’informatique décisionnelle n’est pas juste une nouvelle mode, on la retrouve dans tous les domaines et corps de métiers pourvu qu’il y ait des données, car elle fournit une réelle aide à la décision. En effet, nous avons vu qu’elle permet de déterminer ce qu’il s’est passé, ce qu’il se passe et, encore plus important, ce qu’il se passera.
C’est également une science fiable qui s’appuie sur des algorithmes de recherche (utilisés par le data mining), poussés et approuvés, couplés avec des outils permettant d’extraire et de découvrir de l’information cachée, rendue visible à l’utilisateur grâce aux outils d’analyse et de mesure.
L’informatique décisionnelle permet la transformation de données brutes extraites et transformées en informations par un ETL. L’information est stockée dans un entrepôt de données pour être analysée par des outils d’analyses qui transforment les informations en savoir.
Nous avons également vu que ce n’est pas une science avec laquelle on gagne à tous les coups. En effet, si l’analyse est mal faite ou si les données sont trop pauvres ou inexactes, l’analyse des données est vouée à l’échec et entraînera la prise de mauvaises décisions.
Outre la prise de mauvaises décisions, un projet BI provoque de multiples changements pour les utilisateurs finaux : ces derniers acceptent-ils toujours la chose? On peut également se demander comment intervenir si un bug survient pendant l’utilisation de la solution décisionnelle mise en place ou un mauvais transfert de données.
On s’aperçoit rapidement qu’un projet d’informatique décisionnelle n’est pas simple à mettre en place et que le maintien en bonne condition reste une question sans réponse.
Enfin, en terme d’évolution, si mon entreprise évolue (création de nouveaux services, etc...)
Chapitre 2 :
Les bonnes pratiques de mise en place d’un projet d’informatique
décisionnelle
I. Introduction
Ce chapitre a pour but de centraliser les bonnes pratiques dans la mise en place d’un projet décisionnel. Pour rédiger ce chapitre, je m’appuie sur mon expérience personnelle mais également sur les témoignages de professionnels.
Pour recueillir ces témoignages, j’ai rédigé un questionnaire dont un exemple est disponible en Annexe.
Dans ce chapitre, nous verrons les bonnes pratiques générales d’un projet BI mais également des bonnes pratiques ciblées sur les différentes étapes d’un projet BI vues dans le chapitre précédent.
Par rapport à ce chapitre, nous verrons les bonnes pratiques liées à l’Analyse, la définition des données, sur la création des flux, sur la création de l’entrepôt de données et enfin sur la création de l’outil.
D’une manière plus générale nous verrons si un projet BI est comparable à un autre projet informatique, quelles sont les différences et les points communs s’il y en a et quels sont les enjeux ?
J’appuierai donc mes bonnes pratiques sur des citations de professionnels issues des questionnaires réalisés.
II. Analyse
1. Définition du besoin client
Comme tout projet, un projet BI est destiné à des utilisateurs, il faut donc que le projet réponde à leur besoin, sinon il ne sera pas utilisé.
Emmanuel LOUF : « Il faut bien comprendre le besoin utilisateur et s’assurer que celui-ci ne va pas évoluer, définir le périmètre de projet. »
Thibaut RECULE : Interview(s) utilisateur(s) pour définition des besoins et compréhension de la demande utilisateur.
Il est donc impératif d'être à l'écoute des utilisateurs afin de cerner avec précision le besoin client. Cela peut commencer par l'étude de l'existant.
Fabrice BELLOTTI : « La partie spécification est la plus importante dans un projet BI. D’ailleurs la charge d’un projet est plus importante pour les spécifications que pour les développements. »
L’enjeu dans la mise en place d'un projet BI est dans l'analyse. Il faut que la solution mise en place réponde aux besoins exprimés dans un temps acceptable avec les contraintes liées à l'entreprise. Sans oublier d'anticiper les évolutions futures de l'entreprise.
La conclusion de tout ceci est qu'il y a un fort enjeu dans l'analyse d'un projet BI.
Emmanuel LOUF : « Découper le projet en lots et donner des objectifs. »
La mise en place d'un projet BI peut être longue et complexe, il est alors bon de le découper en lots. Une fois le premier lot mis en place, les autres demanderont moins de temps et ils respecteront les mêmes normes.
3. Étude de l'existant
S'il y a un existant, il faut l'étudier et communiquer avec les utilisateurs finaux. Il faut déterminer en quoi la solution existante répond à leur besoin et ce qu'il manque afin que le projet apporte des changements utiles aux utilisateurs.
2. Bien définir les indicateurs
Un projet BI commence par la fin : il faut définir avec les utilisateurs finaux les indicateurs nécessaires à leur travail quotidien.
Natacha SKRZYPCZAK : « Le mieux est de faire une étude du besoin en terme de reporting, c'est-à-dire qu'il faut commencer par la partie visible du projet pour avoir l'expression du besoin client en termes de graphiques fonctionnels. »
Les indicateurs doivent donc être définis avec précision, il faut aller jusqu'au type de graphique que les utilisateurs veulent utiliser.
C'est à ce moment, dès le début du projet, qu'il faut choisir l'outil d'analyse et de reporting. Il doit être validé par les utilisateurs.
III. Les données
1. La définition des données
Une fois les indicateurs définis, il est alors possible de déterminer les données nécessaires à leur construction.
Natacha SKRZYPCZAK : « On remonte le fil de la donnée pour identifier les sources, puis on définit les formules de calcul et enfin on crée le data warehouse. »
Il faut donc définir les données et leurs origines. Un projet BI permet également le nettoyage des données : c'est le moment de mettre d'accord les différents services de l'entreprise sur l'origine des données et les méthodes de calcul.
En effet, il est courant que différents services utilisent les mêmes données provenant de sources différentes ou n'utilisent pas les mêmes règles de calcul.
A la fin de cette étape, vous devez avoir identifié les données dont vous avez besoin, ainsi que leur origine et règle de calcul.
2. La fiabilité des données
Il est impératif de s'assurer de la fiabilité des données car c'est sur elles que reposera la fiabilité des indicateurs. Il faut donc écarter les données non fiables au risque de supprimer des indicateurs.
Natacha SKRZYPCZAK : "Il est très important de fiabiliser les données tout au long du projet et cela passe par la vérification des données au fur et à mesure et à la correction si besoin."
Cette fiabilisation s'effectue tout au long du projet avec les utilisateurs lors de tests. Il nous faut donc des jeux de tests fournis par les utilisateurs afin de prouver la fiabilité des indicateurs.
Fabrice BELLOTTI : « Classiquement, il faut toujours les cas de tests et données de tests en sortie de la phase de spécification détaillée. Ceci permet de valider avant livraison les développements et ainsi la conformité avec la spécification => indicateurs, données utiles,
… »
Les données peuvent être non fiables parce qu'elles ne sont pas à jour : il faut alors déterminer la fréquence de rafraichissement de chaque donnée pour pouvoir les rapatrier. Cette vérification précède la création des flux de données.
IV. Les flux
Les flux de données permettent d'exporter les données depuis leur source jusqu'à l'entrepôt de données.
(Voir figure "flux de données")
1. Rappel
Les données sont extraites des diverses sources de données sous forme de fichiers et envoyées sur un serveur.
Dans le cas où nous avons de nombreuses sources de données identiques, par exemple les données issues des caisses de différents magasins, il est bon de consolider les fichiers afin de réduire les traitements.
Les fichiers consolidés sont lus par un ETL qui exporte les données vers une base de chargement. La base de chargement est à l'identique de l'entrepôt de données.
En cas d'erreur, les données sont intégralement envoyées en base de rejets.
En cas de réussite, c'est-à-dire si toutes les données des fichiers ont pu être intégrées en base de chargement, elles seront chargées dans l'entrepôt de données.
Tables de dimensions Tables de faits Tables d'agrégats Tables similaires
à celles du Data WareHouse
Tables de Rejets Consolidation
Fichiers de données
ETL
Base de Chargement
Flux de Chargement
Flux de rejet
ETL ETL
Data Warehouse
2. Création des flux
Natacha SKRZYPCZAK : « Le mieux est de factoriser au maximum les flux pour avoir un modèle de flux réutilisable. »
La création des flux doit être homogène et les flux doivent avoir les mêmes étapes afin de les normaliser.
Cela permettra de mieux comprendre les flux. Les prochains flux seront plus rapides à mettre en place et enfin, le fait d'avoir la même logique pour chaque flux permettra d'accélérer le temps de résolution.
Thibaut RECULE : « Avoir une conception claire des flux avant le début des développements et prévoir tous les prérequis au développement des flux. »
Comme dans toute phase de développement, il faut avoir une définition claire et prévoir tout ce dont on a besoin avant de commencer pour ne pas perdre de temps et réaliser un travail de qualité.
3. Nettoyage
Dans le point précédent nous avons déjà parlé de nettoyage des données, mais il s'agissait du nettoyage de la source des données. Dans les flux, nous allons nettoyer les données de manière plus informelle.
a. Les doublons
Le premier nettoyage consiste en l'élimination des doublons. En effet, les sources de données n'étant pas soumises à des contraintes strictes, il est courant d'avoir des doublons.
La meilleure solution consiste à éliminer les doublons parfaits directement dans l'ETL. Quant aux doublons imparfaits, le mieux est de les faire passer en rejets.
b. Les incohérences
Il peut être judicieux d'ajouter à l'ETL un script qui élimine les données incohérentes afin que celles-ci soient envoyées en base de rejet : par exemple, des articles avec des prix de vente négatifs.
4. Reprise en cas d'échec
Il est impératif d'ajouter à chaque flux de données un moyen de reprise en cas d'échec. Ainsi, en cas d'erreur imprévue, le flux peut être relancé et beaucoup de temps peut être gagné.
Thibaut RECULE : « Pour la création des flux, il faut prévoir tous les scénarios possibles (différentes possibilités d’échecs, réussites). »
Ainsi, chaque flux doit disposer d'une table de travail.
Cette table sera vidée à chaque nouvelle exécution du flux. Si le flux s'arrête, il sera ainsi possible de savoir où il s'est arrêté et pourquoi. Cette table permettra également, en cas de reprise du flux, que celui-ci ne retraite pas les lignes déjà traitées.
5. Planification
Les flux de données doivent être planifiés aux heures où les bases sont le moins utilisées, généralement la nuit.
Il faut également éviter de planifier des flux simultanément ce qui ralentit le serveur.
Table de travail Flux
Étape : export / nettoyage / transformation / import
Source Destination Ligne traitée Erreur
Échantillon de données
6. Bases de données intermédiaires
a. Table de chargement
La base de chargement est à l'identique de l'entrepôt de données. En cas d'erreur, les données sont intégralement envoyées en base de rejets.
b. Table de rejet
Les tables de rejet doivent être à l'identique des tables chargement hormis qu'elles ne contiennent pas les contraintes.
Elles doivent également contenir les colonnes suivantes : - le détail de l'erreur
- le numéro de ligne du ficher si les données viennent d'un fichier - la date et l'heure
- le nom du flux.
Il faut essayer de rejouer les rejets de manière plus tardive : par exemple des éléments peuvent être mis en rejets car ils surviennent avant d'autres.
Autre exemple, il est possible d'avoir une journée de tickets de caisse en rejets car un article a été vendu en magasin mais ce dernier n'est pas encore référencé dans l'entrepôt de données.
Il faut donc s'assurer d'intégrer les données dans l'ordre.
V. L’entrepôt de données
Un datawarehouse doit respecter les règles de construction vues dans le premier chapitre de ce document, mais ce n’est pas tout.
Thibaut RECULE : « Il faut avoir une conception claire et précise du DataWareHouse par le biais de MCD, découlant des interviews utilisateurs faites en amont. »
Il y a un fort travail d’analyse pour que le datawarehouse puisse répondre aux besoins clients actuels mais aussi qu’il puisse évoluer pour répondre aux besoins futurs.
Natacha SKRZYPCZAK : « Il est impératif d'anticiper l’évolutivité du datawarehouse en terme d’architecture et de modèle, pour éviter de submerger le datawarehouse et d’augmenter le temps de réponse. »
Lors de l’évolution d’un datawarehouse il faut estimer l’impact que cela entraine, et pour cela, il faut savoir ce qui a déjà été fait. C’est pourquoi il est nécessaire d’avoir des descriptions des changements apportés par chaque nouvelle version.
Par mesure de sécurité, il est bon d’avoir des procédures. Ainsi quel que soit l’ingénieur en charge des évolutions, les noms, méthodes… seront cohérents entre les différentes versions.
Natacha SKRZYPCZAK : « Il est courant qu'au début d'un projet, 3 datamarts soient suffisants, mais très vite on passe de 3 à 10 et on multiplie par 3 les ressources nécessaires. »
Il faut anticiper les besoins clients en termes de modélisation, c'est-à-dire faciliter l’évolution et les modifications (procédure, etc.) mais également anticiper au niveau matériel et stockage des données. En effet, il est courant qu’au fil des années, le nombre de données explose dans un entrepôt.
Cela a pour conséquence d’augmenter les temps de réponse et de rendre l’entrepôt de données inutilisable.
Il faut donc anticiper les besoins futurs afin que le client ait besoin de faire évoluer son entrepôt le plus tard possible.
Thibaut RECULE : « Bien choisir la technologie dans laquelle sera développé l’entrepôt de données, en fonction des besoins clients. »
Le choix de la technologie est important dans la création de l’entrepôt de données, et ce choix va être déterminé par l’analyse que nous avons effectuée en amont. Chaque technologie a ses avantages, le tout est que celle-ci réponde aux besoins clients en termes de coût, performance, qualité et compétence requise.
Il faut également créer un système d’alerte afin d’anticiper les évolutions et ne pas stopper l’activité car une fois qu’un projet décisionnel est mis en place, les outils font partie du quotidien des utilisateurs et sans ces outils ils ne peuvent pas travailler, ce qui ralentit l’activité de l’entreprise.
VI. La gestion du changement
1. Intégration des utilisateurs au projet
Pour ne pas avoir de résistance au changement, les utilisateurs doivent être intégrés dès le début du projet.
Fabrice BELLOTTI : « Comme tout projet informatique, il est bon que les utilisateurs finaux participent à la recette externe (recette MOA). Ceci permet de conforter la solution mais aussi d’avoir des alliés qui permettront de mieux accompagner le changement. »
Il est moins facile de critiquer un projet quand on y a participé.
Certains utilisateurs sont plus sensibles à l'aspect sécurité et d'autres sont résistants à la nouveauté, il est donc difficile de faire accepter la mise en place d'un projet BI.
Natacha SKRZYPCZAK : « Il faut accompagner les utilisateurs, leur faire comprendre l'intérêt du changement et les former. »
Thibaut RECULE : « Préparer en amont une liste des utilisateurs impactés par le projet afin de prévoir une montée en compétences sur les outils de ces personnes. »
Cette phase est non négligeable et, souvent, on sous-estime l'importance d'accompagner les utilisateurs et de les faire monter en compétences pour qu’ils puissent utiliser pleinement les outils mis à leur disposition.
Thibaut RECULE : « Faire se sentir l’utilisateur au centre de la réalisation du projet, ne pas hésiter à le faire participer aux réunions, à l’avancée du projet. »
Thibaut RECULE : « Il est également important lors d’un projet BI que l’intermédiaire principal entre le client et le développeur soit disponible facilement pour répondre aux questions techniques et métiers que pourrait se poser le développeur. »
Un projet BI est mis en place pour répondre à des besoins métiers spécifiques. Il faut donc désigner au moins un interlocuteur métier pour le mener à bien car seul quelqu’un connaissant le métier et ses enjeux pourra valider et répondre aux questions des développeurs.
2. Le choix de l'outil
Natacha SKRZYPCZAK : « Pour bien construire un projet BI il est nécessaire d'avoir un interlocuteur métier disponible afin de comprendre les enjeux et encore une fois pouvoir identifier les impacts et anticiper les évolutions futures. »
Il est possible de présenter plusieurs outils répondant aux besoins et budget du projet.
Au final, les utilisateurs choisiront celui qui leur correspond le mieux.
Pour avoir le moins d'impacts possibles, on peut désigner un nombre restreint d'utilisateurs qui participeront au projet.
Thibaut RECULE : « Réaliser si possible des interviews ou réunions avec ces personnes afin de répondre à un maximum de besoins utilisateurs dans le projet. »
Le choix de l’outil va, comme les autres, reposer sur une analyse du besoin des utilisateurs. L’outil doit répondre au besoin au niveau performance et service mais il doit également être accepté par les utilisateurs car ce sont ces derniers qui l’utiliseront au quotidien.
VII. Bilan en Conclusion du chapitre
Un projet BI reste un projet informatique, par conséquent on peut y appliquer toutes les règles de bonnes pratiques adaptées à un projet informatique. Il est donc possible de gérer un projet BI en méthode Agile ou en utilisant le PMI.
Outre les bonnes pratiques s’appliquant à tout projet, dans le cas d’un projet BI on peut retenir qu’un projet BI a un enjeu fort sur l’analyse. En effet, dans un projet BI tout découle de l’analyse : c’est pendant cette phase que l’on va définir les indicateurs et, des indicateurs, nous allons déduire les données nécessaires. Reste ensuite à savoir où les trouver.
En effet, dans une entreprise il y a souvent plusieurs sources de données pour des données similaires et, parfois, ces données sont légèrement différentes. Il va donc falloir faire un travail de compréhension métier et d’enquête pour déterminer les données à utiliser ainsi que les règles de calcul. Cela va permettre d’uniformiser les pratiques de l’entreprise et de fiabiliser les données.
Dans tout projet, mais d’autant plus dans un projet BI, il est bon d’avoir des intervenants métiers car les indicateurs finaux seront utilisés de manière quotidienne.
L’analyse ne s’arrête pas là : il va falloir anticiper les besoins futurs du client afin que le projet ne soit pas obsolète dès le lendemain de sa création. Cette dernière analyse va déterminer la création de l’entrepôt de données.
Il faut garder à l’esprit qu’un projet BI est naturellement et fatalement amené à
Une fois les indicateurs définis et les données identifiées validées, uniformisées et après la création de l’entrepôt de données, il reste à rapatrier les données. C’est à ce moment et seulement maintenant que l’on crée les flux de données.
Cette étape va permettre le transfert des données, mais c’est également le moment de nettoyer des données. Il faut une nouvelle fois garder à l’esprit que le projet va évoluer : il faut donc construire les flux de façon homogène et normalisée, afin de faciliter l’ajout et surtout la résolution.
La planification des flux a son importance car il faut que ces derniers ne se gênent pas et qu’il soit possible de les relancer en cas de panne avant l’utilisation des indicateurs.
Enfin, nous avons vu dans ce chapitre que les utilisateurs finaux ont un rôle très important dans un projet BI car c’est à eux qu’est destiné le projet. Comme dans tout projet, il faut les intégrer au projet mais il est important de comprendre les subtilités métiers pour que le projet soit un réel outil pour eux.
Le choix de l’outil passe également par la validation des utilisateurs mais sans oublier qu’il est impératif que l’outil réponde au besoin exprimé en termes de coût et de fonctionnalité.
Pour finir, l’accompagnement du changement est capital dans un projet BI car les utilisateurs passent souvent d’un outil qu’ils maîtrisent depuis des années (Excel) à un nouvel outil, il y a donc un travail d’accompagnement important à réaliser pour que le projet soit un succès.
Nous avons également parlé des bonnes pratiques lors de la création d’un projet BI permettant de faciliter le maintien, pour ce faire, y a-t-il d’autres moyens? C’est le point du chapitre suivant.
Chapitre 3 :
Le maintien en condition
opérationnelle d’un projet
d’informatique décisionnelle
I. Introduction
Comme tout outil, une solution BI a besoin d'être maintenue. Nul n'est à l’abri des bugs informatiques ou de l'erreur humaine.
Selon les dysfonctionnements, c'est tout ou une partie de la chaîne décisionnelle qui peut être impactée et le temps de résolution peut être plus ou moins long.
Le préjudice subi par l'entreprise peut être plus ou moins grand en fonction de la criticité du dysfonctionnement et du temps de correction de ce dernier.
Il y a plusieurs moyens de se prémunir ou de réduire le temps de résolution de nombreux dysfonctionnements impactant la chaîne décisionnelle que nous verrons dans ce chapitre.
L’informatique décisionnelle d’aujourd’hui n’est plus utilisée que par la Direction mais par de nombreux autres utilisateurs, et elle leur est indispensable au quotidien. Il y a donc un important niveau de service à fournir pour maintenir un système en place.
Ce chapitre comme le précédent s’appuie sur mon expérience personnelle ainsi que sur les témoignages de professionnels.
Comme le chapitre précédent, j’appuierai donc mes bonnes pratiques sur des citations de professionnels issues des questionnaires réalisés.
II. La gestion des flux
1. L’intégration des données
Les principales causes d'erreurs viennent de l'intégration des données : généralement, les données ne sont pas au bon format, l'encodage des fichiers n'est pas celui attendu ou autre.
Conformément au chapitre précédent, il est impératif que les flux renseignent des fichiers de logs et des tables de travail afin de pouvoir trouver la source de l'erreur et de la corriger.
Nous avons également parlé d'un système de reprise d'un flux : ce système va se révéler très utile pour maintenir une solution décisionnelle.
2. Les fichiers
L'erreur peut venir de l'encodage des fichiers si celui-ci n'est pas celui attendu par l'ETL. Une solution palliative sera de ré-encoder le fichier et de relancer le flux mais il faut déterminer la cause de ce changement afin que le problème ne survienne pas tous les jours.
L'ordre des colonnes du fichier a son importance : il se peut qu'une colonne soit manquante, ainsi les données insérées en base passent en rejet ou sont incohérentes. Il faut donc vérifier la cohérence des données.
3. La relance
En cas de plantage, un flux doit être relancé avant sa prochaine planification sinon le problème s'accumulera et d'autres erreurs pourraient être générées.
Emmanuel LOUF : « Il faut relancer les flux le plus tôt possible également si ces derniers ont planté, car les utilisateurs ont besoin de leurs chiffres pour travailler. »
Il faut également relancer les flux le plus rapidement possible après leur plantage afin de pénaliser le moins possible les utilisateurs ; mais le plus important est de déterminer précisément la cause du plantage et de la corriger pour éviter que cela ne se reproduise.
4. Les évolutions
Un projet BI évolue nécessairement car les besoins des utilisateurs changent. Avant toute modification et évolution, il faut s’assurer qu’il n’y a pas d’impact sur le système actuel ni de régression.
Tristan Wojciechowski : « Concernant les évolutions : bien s’assurer que la mise en place ne crée pas d’impacts négatifs. Exemple : ne pas mettre en vigueur une nouvelle version d’un flux alors qu’il reste à intégrer des flux de l’ancienne version. »
L’idéal est de mettre en place des procédures pour les modifications et d’autres pour les évolutions afin que la personne en charge des modifications fasse les vérifications nécessaires.
Thibaut RECULE : « Il est important de savoir s’adapter à un contexte client qui évolue en continu : le maintien en condition opérationnelle n’étant pas un projet avec des spécifications fixées en début de projet et qui ne bougent pas au cours de sa réalisation, il est par conséquent important de savoir s’adapter à l’évolution du contexte client. »
Il faut maintenir une communication forte avec le client pour suivre ses évolutions et anticiper ses besoins. Un projet BI est évolutif et évolue avec les activités du client afin de toujours répondre à ses besoins.
5. Les environnements
Il est nécessaire d’avoir plusieurs environnements en BI. Par exemple, un environnement de développement permettant les développements, un environnement de recette permettant les tests des évolutions et développements, et, enfin, un environnement de pré-production qui est la copie conforme de l’environnement de production.
Tristan Wojciechowski : « Ne pas faire des modifications directement en production. Suivre le processus en utilisant les environnements prévus c’est-à-dire Développement puis Recette puis (Pré-production ) Production. »
Généralement, on retrouve la procédure suivant : réalisation des développements et modifications en développement, évolution vers la recette pour les tests, mise en pré- production, et, si après tests, tout fonctionne, passage en production.
6. La documentation
Emmanuel LOUF : « Il faut une documentation très détaillée, pour avoir un partage des compétences. Une bonne documentation permet de mutualiser les connaissances et d’accélérer la prise en main et les résolutions. »
Une documentation peut être très utile dans le maintien d’une solution BI. Une documentation permet de réduire le temps d’intégration des nouveaux arrivants et, en cas de partage des compétences, une documentation permet de mutualiser les compétences. Le but est que le savoir ne soit pas restreint à une ou deux personnes.
Thibaut RECULE : « Il est important qu’une TMA ou un Centre de Service ait à sa disposition des documentations claires et précises sur tout ce qui touche au DataWareHouse du client, documentations rédigées par ce dernier. »
Il est important de maintenir à jour une documentation technique et fonctionnelle de l’environnement BI. Nous avons parlé dans ce document des évolutions que doit avoir un projet BI pour répondre aux besoins client ; il faut bien sûr créer une documentation précise et faire évoluer celle-ci afin d’avoir des plans précis de l’environnement du projet.
Tout ça dans le but de fournir une meilleure qualité de service et de pérenniser l’information.
