Développez des KPI dans un environnement multi-systèmes

Publié le 12 mai 2014
par Sophie Marchand M.Sc., CPA, CGA, MVP
KPI multi-systèmes

Développez des KPI dans un environnement multi-systèmes

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 basés sur des sources de données multiples.

 

Besoins de reporting

KPI multi-systèmesDans 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 proviendront de plusieurs 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.

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.

 

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.

 

ETL: Transformation des données

KPI multi-systèmesQuand 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

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.

 .

CFO-Masque_Formations-en-ligne_FB Le CFO masqué offre un vaste choix de formations en informatique décisionnelle avec Excel et Power BI, via un portail en ligne et à distance en temps réel, selon un calendrier. Si vous désirez organiser des formations privées, faites nous simplement parvenir un courriel à info@lecfomasque.com . Des certificats convenant aux normes de formation continue des divers ordres professionnels du Québec sont offerts pour l'ensemble des formations.  

Découvrez quelles formations vous conviennent

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Scroll to Top