L informatique décisionnelle

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 1

Table des matières 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 2. But et utilisation du data mining... 28 3. Principe... 28 2

4. Algorithmes... 29 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 VII. Bilan en Conclusion du chapitre... 49 Chapitre 3 :... 51 Le maintien en condition opérationnelle d un projet d informatique décisionnelle... 51 I. Introduction... 52 II. La gestion des flux... 53 1. L intégration des données... 53 3

2. Les fichiers... 53 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 4

Chapitre 1 : L informatique décisionnelle 5

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. 6

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. On peut en conclure que le marché de la BI est en pleine croissance, et que cela n est pas prêt de changer dans la société de consommation actuelle. De plus, avec les offres Open Source, ce secteur devient accessible pour les entreprises de toutes tailles. 7

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. 8

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 : Prenons l exemple d un produit : grâce à ce type d indicateur, nous savons où et quand il s est le mieux vendu, qui l achète et qui le vend. Le croisement de ces informations peut par exemple aider une entreprise à prévoir ses stocks. 9

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 : 10

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. Les principales : - SGBD relationnels, - les flux XML, - fichiers à formats fixes ou avec séparateurs (CSV). 11

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 IBM InfoSphere DataStage CloverETL Informatica PowerCenter Pentaho Data Integration Oxio Data Intelligence solution ETL Scriptella OpenText Genio Talend Open Studio BusinessObjects Data Integrato Cognos DecisionStream (Data Manager) Oracle / Warehouse Builde SSIS Microsoft 12

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 données. Toute information collectée se verra affecter une date, ou un numéro de version, afin d éviter l écrasement d une information déjà présente dans l entrepôt de données et également permettre un suivi de l évolution au cours du temps. Les informations collectées peuvent provenir de plusieurs bases de données. Parfois, les informations des différentes bases de données d une entreprise sont collectées dans un 13

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. L intérêt de cette organisation est de centraliser les informations utiles sur un sujet le plus souvent transversal aux structures organisationnelles et fonctionnelles d une 14

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 à son exploitation. Mais dans notre monde, les données sont issues de diverses sources et d applications de production. Il faut alors homogénéiser les données afin d en garantir la qualité et fournir un vocabulaire commun pour les utilisateurs. 15

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 : - Nécessite plus de mémoire de stockage 16

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 Orientées application, détaillées, précises au moment de l accès Mise à jour interactive possible de la part des utilisateurs Accédées de façon unitaire par une personne à la fois Haute disponibilité en continu Uniques (pas de redondance en théorie) Petite quantité de données utilisées par un traitement Réalisation des opérations au jour le jour Forte probabilité d accès Utilisées de façon répétitive Données décisionnelles Orientées activité (thème, sujet), condensées, représentent des données historiques Pas de mise à jour interactive de la part des utilisateurs Utilisées par l ensemble des analystes, gérées par sous-ensembles Exigence différente, haute disponibilité ponctuelle Peuvent être redondantes Grande quantité de données utilisées par les traitements Cycle de vie différent Faible probabilité d accès Utilisée de façon aléatoire 17

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. 18

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. 19

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) 20

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. 21

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. 22

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 23

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 Processes). 24

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) 25

a) R-OLAP Business Intelligence 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 : très lent pour des requêtes non optimisées 26

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. 27

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. 28

4. Algorithmes Le data mining utilise et combine des méthodes statistiques et adaptatives (machine learning). Les modèles à la mode sont le bagging (voir Glossaire), qui utilise une stratégie aléatoire en réalisant une famille de modèles qui sont ensuite agrégés et le boosting, 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 x 1,...,x n en une sortie réelle o. Les entrées n'ont pas toutes la même importance et à chaque entrée x i est associé un poids (ou coefficient synaptique) w i. 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 S i w i x i. 29

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. 30

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.» http://www.informatiquedecisionnelle.com/home/les-pieges-de-la-business- Source : intelligence/ 31

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. Voici le récapitulatif des différentes étapes nécessaires à un projet d informatique décisionnelle : 32

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...) comment faire évoluer mon décisionnel? On peut alors se demander quelles sont les bonnes pratiques dans la mise en place d une solution décisionnelle et comment la maintenir en condition opérationnelle? Aujourd hui il n existe pas de guide de ce type, ce sera donc le sujet de ma thèse professionnelle. 33

Chapitre 2 : Les bonnes pratiques de mise en place d un projet d informatique décisionnelle 34

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. 35

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. 36

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. 37

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. 38

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. 39

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. 40

Base de Chargement Data Warehouse Fichiers de données ETL Flux de Chargement Tables similaires à celles du Data WareHouse ETL Tables de dimensions Tables de faits Tables d'agrégats Consolidation Flux de rejet Tables de Rejets ETL Tables d erreurs et de rejets Figure : flux de données

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. 42

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. Table de travail Flux Étape : export / nettoyage / transformation / import Source Destination Ligne traitée Erreur Échantillon de donné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. 43

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. 44

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. Il faut donc une nouvelle fois normaliser les tables, vues et autres objets mais également avoir des procédures d évolution et de modification sans oublier un versionning. 45

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. 46

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.» Les utilisateurs doivent donc être acteurs du projet, il faut les consulter pour le choix de l'outil et la définition des indicateurs, sans oublier de les maintenir informés du bon déroulement du projet. 47

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. 48

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é à évoluer. Il faut donc construire les choses de telle façon que l ajout d un nouvel élément ou évolution sera simple à mettre en place et avec le moins d impacts possibles. 49

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. 50

Chapitre 3 : Le maintien en condition opérationnelle d un projet d informatique décisionnelle 51

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. 52

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. 53

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. 54

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. Cette procédure permet d éviter les dégâts lors des tests 55

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. 56

III. Gestion des erreurs 1. La définition de l'erreur La définition des erreurs est capitale : elle doit être aussi claire que possible. A la lecture on doit reconnaitre les données sur lesquelles l'erreur s est produite, d'où provenaient les données, le flux et son étape. Natacha SKRZYPCZAK : «Une bonne gestion des erreurs (etl) pour avoir une reprise la plus rapide possible. Optimiser les chaînes de traitement nocturne, éviter les chevauchements de flux.» 2. Log d'erreur Tristan Wojciechowski : «Gestion des erreurs : il faut mettre en place des rapports d erreurs les plus complets et explicites possibles.» Afin d'accélérer la résolution des erreurs de flux, il faut que le flux renseigne à chaque étape un fichier de logs. Ainsi, en parcourant ce fichier, nous aurons plus d'informations sur ce qu'a fait le flux avant plantage. Les logs doivent être extrêmement précis si on veut une résolution rapide. 3. Les Alertes En cas d'erreur, il faut générer une alerte. Le minimum étant une alerte par email, le mieux étant mail et sms. Il faut envoyer un mail également en cas de réussite sinon comment savoir si l opération a réussi? Tristan Wojciechowski : «Pour le Système d alertes il faut pondérer l importance des flux selon la nature de leurs données et selon leurs impacts afin d établir la priorité des alertes.» Effectivement, tous les flux n ont pas la même importance. Par exemple, si les flux des ventes et des stocks plantent, les stocks sont prioritaires car les entreprises ont besoin de connaître leur stock pour gérer leur activité (un vendeur ne peut pas travailler sans connaître ses stocks). 57

IV. L'intervention humaine 1. Une équipe dédiée Pour répondre de manière efficace aux 2 points précédents il faut, dans toute solution BI, une équipe dédiée au bon fonctionnement du système. L'intervention humaine est nécessaire en cas d'erreur pour la correction et la relance du flux. Une équipe est également requise pour toute évolution de la solution BI. 2. Un centre de service Pour les utilisateurs finaux et dans le cas de grandes entreprises, un centre de service BI est nécessaire. Il va intervenir dans : - La gestion des incidents : il peut s agir des incidents liés à l exploitation (typiquement les flux de données) ou des incidents utilisateurs - La gestion des problèmes : un problème est une cause qui provoque un ou plusieurs incidents. - La gestion des configurations : administration informatique (par exemple les serveurs) - La gestion du changement : évolution du système pour corriger des incidents - La gestion des niveaux de service : ce processus est lié à l amélioration du niveau de service (utilisation de SLA) 58

La gestion d un centre de service BI n est pas très différente de celle des autres centres de service, on peut donc y appliquer des référentiels de bonnes pratiques, tel qu ITIL. Toutefois, il reste des bonnes pratiques propres à la BI applicables dans un centre de service BI. a. La gestion des incidents Dans un centre de service BI il y a deux types d incidents : ceux liés à l exploitation de nuit (les flux de données) et ceux liés aux utilisateurs. Thibaut RECULE : «Avoir un outil de gestion des incidents, type Easyvista, afin de pouvoir déléguer une TMA ou un Centre de Service sur les problématiques de gestion d incidents.» Quel que soit le type d incident, il faut que ce dernier soit centralisé dans un logiciel de résolution afin de pouvoir définir un interlocuteur au client qui prend en charge l incident. a) Incidents d exploitation La nuit, les données d exploitation sont rapatriées vers le data warehouse : par exemple, les données relatives aux ventes de chaque magasin. Ces données sont intégrées dans le data warehouse et seulement après, les agrégats sont calculés puis les indicateurs des outils finaux sont rafraîchis avec les nouvelles donné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.» En cas de plantage des flux, il manquera une partie des données dans le data warehouse et donc les indicateurs fournis seront faux car ils ne contiendront pas les dernières données. La priorité est donnée dans ce type d incident car il est bloquant pour la majorité des utilisateurs et compromet la fiabilité des indicateurs sur lesquels s appuie la prise de décisions. 59

Emmanuel LOUF : «Dans un contexte BI il faut adapter les horaires d'un centre de service afin que les résolutions soit effectuées le plus tôt possible. Le décisionnel est une activité quotidienne.» Ce type d incident étant prioritaire et les flux, agrégats (calculs) s exécutant la nuit, l activité d un centre de service est plus importante le matin. Il est donc bon d adapter les horaires afin de rétablir les données avant l arrivée des utilisateurs. b) Incidents utilisateurs Les incidents utilisateurs sont typiquement des problèmes rencontrés par les utilisateurs des outils décisionnels. Il peut s agir de bugs liés aux données ou à l utilisation de l outil ou encore à des soucis d accès. Emmanuel LOUF : «Pour un utilisateur, tout est toujours urgent, il est judicieux de définir des priorités.» Il est naturellement humain de vouloir résoudre son incident immédiatement mais il est évident que certains incidents sont plus urgents que d autres, c est pourquoi il faut définir des priorités en fonction de la catégorie de l incident. Par exemple, un incident lié à une erreur dans les données est prioritaire sur un problème d affichage. Emmanuel LOUF : «Le décisionnel a un impact fort pour l utilisateur car cela lui donne plus de liberté, c est une source d information pour lui et il en est dépendant. Pour un utilisateur, tout incident est très important car cela est bloquant même si ça n est pas un incident grave.» La communication est très importante avec les utilisateurs, pour qu ils continuent à signaler des incidents permettant d améliorer le système : il faut communiquer régulièrement. Un utilisateur ne doit pas avoir l impression que son incident ne sera jamais résolu. Emmanuel LOUF : «Enfin il faut s exprimer dans un langage compréhensible par l utilisateur et ne pas lui parler de termes techniques.» 60

Un utilisateur n a pas nécessairement de connaissance technique, par conséquent, il faut s exprimer dans un langage connu de tous et éviter les termes techniques ou les expliquer. Il est important de communiquer mais c est inutile si nous ne sommes pas compris. b. Les niveaux de services Cela est vrai pour tout centre de service. Il faut fournir des indicateurs de qualité de service (SLA) et les respecter pour garantir un bon niveau de service. Emmanuel LOUF : «Il faut mettre en place des indicateurs (SLA) de qualité et les suivre de manière quotidienne avec le client. (Exemple heure d ouverture datamart). Le but est de rassurer le client.» Fabrice BELLOTTI : «Il faut mettre en place un suivi de la qualité de données du décisionnel. Ceci permet de faire adhérer les utilisateurs à l usage du décisionnel (indicateurs qualité de données).» La mise en place d un niveau de service va permettre de rassurer les utilisateurs et va contribuer à leur adhésion au projet BI si ce n était pas déjà le cas. Fabrice BELLOTTI : «Enfin, il faut mettre en place un outil et une organisation permettant la prise en charge de toute demande en provenance des utilisateurs (finaux ou IT) => permet de donner de la visibilité sur la qualité complète et sur un plan de charge de MCO, de justifier de moyens IT.» En plus des indicateurs de qualité, il faut également que les utilisateurs et la Direction aient une remonté de la charge du centre de service, cela est important pour l évaluation du budget. Si les besoins augmentent, l effectif et les moyens doivent augmenter sinon nous y perdrons en qualité de service. Ces indicateurs permettent d évaluer le coût par rapport à la qualité de service fourni. Natacha SKRZYPCZAK : «ll faut être force de proposition pour le client, le client ne voit que le bout de la chaine BI et n a pas conscience de ce qu il se passe derrière.» La BI est une science qui évolue très vite : on compte en moyenne un nouvel outil par mois depuis 2011. Il faut donc se maintenir informé pour fournir le meilleur service possible, un centre de service BI a un devoir de conseil auprès de ses clients. 61

V. Bilan en Conclusion du chapitre L informatique décisionnelle d aujourd hui est destinée à de nombreux types d utilisateurs qui en ont un usage quotidien. Il faut donc assurer une gestion des incidents permettant une reprise de l activité la plus rapide possible. Nous avons vu dans ce chapitre que pour garantir le maintien et un retour en condition opérationnelle le plus rapide possible, il faut optimiser tous les tenants de la chaîne du décisionnel. Cela commence par les fichiers de logs : plus l erreur est explicite, plus elle sera facile à résoudre. Il faut également un système d alerte qui signale l état des flux que celui-ci ait fonctionné ou pas. Nous avons également vu qu après la correction d un flux, il faut le relancer le plus vite possible pour avoir le moins d impact sur l activité de l entreprise. Les chaînes tournent la nuit : il faut donc intervenir dès que possible pour résoudre les problèmes rapidement, afin, une nouvelle fois, de limiter l impact négatif. En BI, il faut une équipe pour maintenir une solution décisionnelle car celle-ci est complexe et fait appel à de nombreuses compétences. Il faut donc une équipe dédiée et un centre de service est conseillé. Un centre de service va permettre une résolution plus rapide des incidents mais va également permettre de garantir un niveau de service élevé. Les utilisateurs finaux ne resteront pas seuls avec leurs problèmes mais pourront faire remonter l information au centre de service pour correction. Une entreprise évolue et ses besoins aussi, il est donc normal qu une solution BI ait besoin d évoluer. Pour effectuer ces évolutions, une équipe est nécessaire : cette équipe doit connaître l environnement métier et les précédentes évolutions effectuées afin de garantir que les modifications ne vont pas entraîner de régressions. Enfin, des indicateurs de niveaux de service sont nécessaires pour permettre d évaluer le niveau de service fourni et le coût. 62

VI. Bilan et conclusion Générale 1. Conclusion Générale L informatique décisionnelle est une science jeune mais déjà vaste qui évolue constamment. Il y a donc un fort investissement requis pour se maintenir au fait des dernières nouveautés mais cela en vaut la peine car cette science fournit des informations non négligeables pour la gestion quotidienne d une activité et fournit une réelle aide à la décision. Pour que cela fonctionne, il faut garantir au quotidien la fiabilité des informations fournies par des outils décisionnels. Ce document permet de décrire l informatique décisionnelle et débouche sur 2 chapitres qui contiennent une liste non exhaustive des bonnes pratiques liées à l informatique décisionnelle dans sa mise en place et dans son maintien. Il est vrai que les deux chapitres sont liés, car si on suit les bonnes pratiques énoncées dans le chapitre 1, pour concevoir un projet d informatique décisionnelle, celui-ci sera d autant plus facile à maintenir. Par ailleurs, en suivant les bonnes pratiques du chapitre 2, on limite les risques de dégrader le système mis en place. On peut également retenir que l informatique décisionnelle reste un projet informatique : un projet BI peut donc se voir appliquer les bonnes pratiques relatives à tout autre projet informatique, mais ce projet reste spécifique par le nombre d outils et de compétences nécessaires à sa réalisation. Un projet d informatique décisionnelle requiert de l analyse, de la gestion de projet, du management, de la communication, des connaissances techniques dans les outils utilisés et en gestion de bases de données et serveurs, etc Un projet requiert donc une équipe BI dotée des compétences citées ci-dessus, que ce soit pour la création ou le maintien en condition opérationnelle. 63

L informatique décisionnelle est un travail d équipe qui a besoin de la participation de l ensemble des services de l entreprise. 2. Bilan Personnel Il n existait pas de guide de bonnes pratiques en informatique décisionnelle, ce document est un très bon début mais je me dois de le maintenir à jour étant donné que la BI évolue énormément. Personnellement, je suis satisfait du travail que j ai accompli. Pour écrire ce document, je me suis appuyé sur mon expérience personnelle, mes recherches, sur des documentations que l on m a fournies et enfin sur des témoignages de professionnels. Je remercie d ailleurs toutes les personnes qui m ont aidé à composer cette Thèse. J ai beaucoup appris en rédigeant cette Thèse et j ai l intention de poursuivre une carrière en tant qu ingénieur décisionnel. 64

Glossaire Consolidation : En informatique, la consolidation est le regroupement cohérent de données, et concerne généralement des données organisées logiquement ou liées entre elles. Le SIAD est un outil d observation et de description qui vise, à partir de données de gestion et/ou de statistiques, à donner aux managers d une entreprise les moyens d identifier des alertes de gestion, de suivre l évolution de l activité et de disposer d outils d investigation de sujets ou phénomènes particuliers. Il ne fournit pas les explications ni les commentaires qui relèvent d une phase de travail postérieure à l observation. EIS (Entreprise Information System) : un système d'information (SI) est un ensemble organisé de ressources (matériels, logiciels, personnel, données et procédures) qui permet de regrouper, de classifier, de traiter et de diffuser de l'information sur un phénomène donné. 65

Bagging = "bootstrap aggregation" Business Intelligence Fonctionnement : Diversification par ré-échantillonnage o Créer T réplicats bootstrap de l'ensemble d'apprentissage D (échantillons de même taille que D par tirages avec remplacement) o Appliquer la méthode d'apprentissage choisie aux T réplicats pour produire T modèles/hypothèses Intégration statique o Prédiction de l'ensemble = moyenne (régression) ou vote uniforme (classification) des T modèles Boosting : Diversification par ré-échantillonnage, séquentielle et adaptative, par pondération des instances Au départ : toutes les instances ont le même poids 1/ T RN A chacune des T itérations, - lancer l'algorithme et évaluer l'erreur pondérée sur T RN - augmenter les poids des instances mal classées (focalise l'apprentissage sur les cas difficiles) Intégration par vote pondéré : o Appliquer les T modèles de base à une nouvelle instance o Retourner la prédiction majoritaire désignée par un vote pondéré (poids des classeurs déterminés à l'apprentissage). 66

Les classes de données : Un entrepôt de données peut se structurer en quatre classes de données organisées selon un axe historique et un axe de synthèse. - Les données agrégées : Elles correspondent à des éléments d analyse représentant les besoins des utilisateurs. Elles constituent déjà un résultat d analyse et une synthèse de l information contenue dans le système décisionnel, et doivent être facilement accessibles et compréhensibles. - Les données détaillées : Elles reflètent les événements les plus récents. Les intégrations régulières des données issues des systèmes de production vont habituellement être réalisées à ce niveau. - Les métadonnées : Elles constituent l'ensemble des données qui décrivent des règles ou processus attachés à d'autres données. Ces dernières constituent la finalité du système d'information. - Les données historisées : Chaque nouvelle insertion de données provenant du système de production ne détruit pas les anciennes valeurs, mais crée une nouvelle occurrence de la donnée. Incident : Un incident est un événement qui ne fait pas partie du fonctionnement normal d'un service et qui peut entrainer une interruption de ce service ou une détérioration de sa qualité. SLA : Le Service Level Agreement (SLA) est un document qui définit la qualité de service requise entre un prestataire et un client. 67

Annexe : Questionnaire de Thèse Professionnelle Problématique : Quelles sont les bonnes pratiques dans la mise en place d une solution décisionnelle et comment la maintenir en condition opérationnelle? Ce document est une synthèse de deux questionnaires. Il comprend la partie "mise en place d'un projet décisionnel" du questionnaire réalisé avec Natacha SKRZYPCZAK qui a une très forte expérience dans la mise en place de projets décisionnels. La seconde partie du questionnaire comprend la partie "Maintien en condition opérationnelle" réalisée avec Emmanuel LOUF qui a managé pendant deux ans un centre de service BI composé de 11 collaborateurs. J'ai fait ce choix de présenter une fusion de 2 questionnaires afin que cet exemple soit le plus riche et le plus complet possible. 68

I. Les bonnes pratiques de mise en place d un projet d informatique décisionnelle 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é) "Il est nécessaire 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 terme de graphique fonctionnel. Ensuite 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 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." 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) "Factoriser au maximum les flux pour avoir un modèle de flux réutilisable. C'est-à-dire avoir les mêmes types de fichiers de logs. Il est important de normaliser la gestion des erreurs et de la centraliser pour réduire le temps d'identification des problèmes et de correction." 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) "Il est impératif d'anticiper l évolutivité du datawarehouse en terme d architecture et de modèle pour éviter de le submerger et d augmenter le temps de réponse. Il ne faut pas oublier également d'anticiper les besoins et futurs besoins qu'engendre un projet décisionnel, également au niveau matériel. 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. Enfin, il faut anticiper l explosion du volume de données." 4. Quels conseils donneriez-vous pour la gestion des changements qu entraînerait un projet BI? (intégration des utilisateurs au projet) "Conduite du changement comme dans tout projet, mais au niveau du métier le passage d outil classique Excel à un outil de reporting (QlikView) est difficile. 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. Il faut accompagner les utilisateurs, leur faire comprendre l'intérêt du changement et les former. Cette phase est non négligeable et souvent on sous-estime l'importance d'accompagner les utilisateurs." 70

5. Autres conseils ou bonnes pratiques sur la mise en place d un projet BI (Expériences personnelles)? "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 difficile de Négocier le budget, car certains considèrent la BI comme un gadget et non comme un outil. Il faut alors leur démontrer les forces des outils BI et le gain qu'ils pourront en tirer. C'est également peu facile d'évaluer le retour sur l investissement d'un projet BI." 6. Personnes qui pourraient me renseigner sur le sujet? "Emmanuel Louf : pour la partie Maintien en condition opérationnelle (MCO)" 71

II. Le maintien en condition opérationnelle d un projet d informatique décisionnelle 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) "Il faut mettre en place des indicateurs (SLA) de qualité et les suivre de manière quotidienne avec le client. (Exemple : heure d ouverture datamart). Le but est de rassurer le client. Il faut mettre en place plusieurs niveaux de résolution d incident et un système d'escalade afin de fournir une résolution la plus rapide possible. Dans un centre de service il est nécessaire de diviser les compétences au sein de l'équipe. C'est-à-dire qu'il faut bien répartir les fonctions de chacun afin que le fonctionnement du centre de service soit en continu. Il faut démultiplier l information au niveau des compétences et de la hiérarchie, le savoir ne doit pas dépendre de quelques personnes. Il y a plusieurs types de MCO : Le MCO, dit utilisateur qui comprend les incidents liés aux utilisateurs tels que les bugs, que les utilisateurs rencontrent en utilisant les outils, le temps de réponse. Pour ce type de MCO il faut fournir un délai de résolution et définir des priorités. Pour un utilisateur tout est toujours urgent, il est donc bon de définir des priorités. Pour que le centre de service fonctionne bien, les utilisateurs doivent avoir confiance en lui, il faut donc leur fournir des délais de résolution et les prévenir en cas de changement. 72

A ce sujet, il faut régulièrement communiquer : l utilisateur a toujours l impression que son problème n est pas pris en compte, il faut le maintenir informé et lui donner des délais de résolution. Le décisionnel a un impact fort pour l utilisateur car cela lui donne plus de liberté, c est une source d information pour lui et il en est dépendant. Pour un utilisateur, tout incident est très important car cela est bloquant même si ça n est pas un incident grave. Enfin, il faut s exprimer dans un langage compréhensible pour l utilisateur et éviter d employer des termes techniques. Le MCO dit de "mise à disposition des données" comprend les flux de données. Cette partie est capitale car c'est généralement la nuit que les indicateurs sont calculés et on ne s'aperçoit d un dysfonctionnement que le matin. Dans un contexte BI il faut adapter les horaires d'un centre de service afin que les résolutions soient effectuées le plus tôt possible. Il faut relancer les flux très rapidement également si ces derniers ont planté, car les utilisateurs ont besoin de leurs chiffres pour travailler. Le décisionnel est une activité quotidienne. 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. Enfin, le décisionnel n a pas la même priorité selon les clients et pas la même importance : par exemple une banque a un impact beaucoup plus fort qu'un concessionnaire si le décisionnel tombe. Les solutions doivent donc être adaptées en fonction de l'importance de la position du client. Il n'y a donc pas de règles sur la composition d'un centre de service, le nombre de collaborateurs et les contraintes dépendent encore une fois de l'importance que celui-ci donne aux décisionnels." 73