De plus en plus d’entreprises consacrent des budgets importants à l’implantation de tableaux de bord car elles comprennent bien la valeur de ceux-ci. Toutefois, peu de gestionnaires comprennent la complexité rattachée à l’élaboration de KPI dans un environnement multi-systèmes.
Besoins de reporting dans un environnement multi-systèmes
Dans votre tableau de bord, vous voudrez sans doute présenter des KPI rattachés à la profitabilité des clients, à la performance des fournisseurs, à la productivité des ressources, à la performance stratégique de l’entreprise, etc. Et il est fort à partier que les données nécessaires au calcul de ces KPI proviennent souvent d’un environnement multi-systèmes et devront être croisées. Ces données proviendront de systèmes transactionnels comme:
- ERP
- CRM
- Système de gestion d’inventaire
- Système de gestion de la paie
- Système d’enregistrement de transactions de vente
- Système comptable
Que devrait faire un bon tableau de bord ?
D’abord, demandons-nous ce que devrait faire un bon tableau de bord. À mon avis, le tableau de bord devrait:
- Être intuitif et permettre d’accéder facilement aux données clés, au moment opportun
- Faire ressortir les éléments qui méritent une attention spéciale
- Permettre de découvrir de nouvelles opportunités de croissance
- Permettre d’identifier les problèmes et les dangers potentiels pour l’entreprise et fournir des pistes de solutions
- Permettre de creuser pour obtenir des explications sur les valeurs obtenues
- Permettre d’enclencher des actions correctives sur le champs
- Fournir les informations nécessaires à la prise de décisions d’affaires (arrêter ou augmenter la production d’un item, etc.)
Quelle est la problématique souvent rencontrée ?
Malheureusement, un très grand nombre de projets tableaux de bord ne rapportent pas le ROI escompté à cause d’une mauvaise planification de l’architecture des bases de données impliquées et d’erreurs d’architecture fondamentales. Souvent, les bases de données ne sont tout simplement pas élaborées dans le but de répondre aux besoins de reporting. Pour élaborer de bons KPI dans un environnement multi-systèmes, il faut bien comprendre comment structurer les données et les sources de données à partir desquelles nos tableaux de bord vont s’alimenter.
Impact sur les tableaux de bord ?
Cette problématique est souvent fatale pour un projet d’implantation de tableau de bord, puisque dans ce contexte:
- Les tableaux de bord contiennent des informations qui sont inappropriées
- La façon de naviguer dans le tableau de bord et de présenter les résultats ne conviennent pas aux objectifs de départ
- La performance du tableau de bord est si pauvre que les utilisateurs n’en voient plus les bénéfices (ne convient pas aux besoins d’interactions).
OLTP : Online Transaction Process
On réfère souvent aux systèmes transactionnels des entreprises comme étant des OLTP (Online transaction process), qui ont comme objectif de collecter et emmagasiner les données dans le système. Les données entrées dans les OLTP (souvent via une interface web), sont sauvegardées automatiquement dans une base de données sous-jacente. Pour consulter les données, il est parfois possible d’effectuer des requêtes mais celles-ci devront être simples et similaires au formulaire d’entrée de données. Ce n’est donc pas en se connectant sur ces sources de données, que nous allons élaborer nos KPI.
OLTP : Problématiques rencontrées
La réalité, c’est qu’au fil du temps, les usagers poseront des questions de plus en plus complexes, auxquelles l’OLTP ne pourra pas répondre (besoin de performer des calculs avancés et/ou de croiser l’information avec données d’autres systèmes). D’un point de vue système, l’OLTP a été conçu pour faire de l’entrée de données (une transaction à la fois) et non pas pour performer des calculs sur de larges bases de données. Comme les gens veulent quand même des réponses à leurs questions, ils voudront faire de plus en plus de requêtes dans le système, ce qui le ralentira inévitablement, autant au niveau de l’entrée de données que des requêtes, et ce qui parfois l’empêchera carrément de fonctionner.
ODS : Operational Data Store
La façon la plus rapide de combattre un problème de performance d’un système OLTP est de copier les données dans un autre système, qu’on nommera ODS (Operational Data Store). Ainsi, l’OLTP servira à l’entrée de données et le ODS servira pour fins de requêtes et de reporting. Ces copies de données pourront se faire à une certaine fréquence (chaque heure, chaque jour, chaque minute). Comme nous copions ainsi des données d’un système vers un autre, nous pourrons aussi combiner des données de plusieurs sources. Au cœur du processus, nous voudrons peut-être également en profiter pour nettoyer les données afin d’augmenter l’intégrité des données et ainsi augmenter la valeur du reporting rattaché. Ainsi, nous créerons un environnement séparé pour désengorger les ressources du système OLTP en production et nous créer un environnement pour tranformer les données en vue d’être migrées dans un entrepôt de données. Cela dit, certaines entreprises créent directement leurs KPI depuis un ODS.
ETL: Transformation des données
Pour créer des KPI dans un environnement multi-systèmes, il faudra assurément apporter des transformations aux données de chaque système pour mieux les faire parler entre elles. Quand on parle de transformation des données ou de ETL (Extract, Transform and Load), on fait référence au processus qui prend les données d’un système et les amène vers un autre système, tout en les transformant au passage. En effet, la plupart des systèmes sources ne sont pas « report friendly ». Par exemple, la plupart des systèmes financiers emmagasinent les données dans des tables avec des noms cryptiques (ex.: F0411, G2948). Les noms des champs sont aussi cryptiques (ex.: AG0402, GL7362, etc.). Afin de pouvoir utiliser de telles données, des transformations sont inévitables. Même chose quand les noms de clients ne sont pas écrits de la même façon dans deux systèmes… il faut les remettre sur la même base. Il existe plusieurs méthodes pour réduire le temps de transformation et d’importation mais il faut les connaître. Par exemple, il est plus rapide de filtrer des tables avant de les lier que de faire l’inverse.
Conclusion sur les KPI dans un environnement multi-systèmes
En général, on créera, à partir de l’ODS, un entrepôt de données, qui nous permettra de travailler avec des données structurées. Ces entrepôts de données, nourris par les ODS, seront conçus de façon à faciliter le reporting et l’alimentation des tableaux de bord. Et de ces entrepôts de données, nous pourrons créer des “data marts” qui seront des échantillons de l’entrepôt de données avec des vocations spécifiques pour les usagers. Dans un article subséquent, je vous parlerai de la modélisation tabulaire (liaison de tables de données) pour créer des entrepôts de données.
La mission du CFO masqué est de développer les compétences techniques des analystes et des contrôleurs de gestion en informatique décisionnelle avec Excel et Power BI et favoriser l’atteinte de leur plein potentiel, en stimulant leur autonomie, leur curiosité, leur raisonnement logique, leur esprit critique et leur créativité.
