développement de kpi dans un environnement multi-systèmes

Sophie Marchand, M.Sc., CPA, CGA Experte en modélisation d’affaires Site web: lecfomasque.com Cell.: 514-605-7112 Courriel: [email protected]

LE CFOMASQUÉ

DÉVELOPPEZ DES KPI,DANS UN ENVIRONNEMENT

MULTISYSTÈME


LE CFOMASQUÉ

INTRODUCTION


LE CFOMASQUÉ

INTRODUCTION

*Que devrait faire un bon tableau de bord? Ê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.)


LE CFOMASQUÉ

INTRODUCTION

Quelle est la problématique souvent rencontrée? 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 entrepôts de données impliqués

Et 85% des projets d’entrepôts de données ne rencontrent pas leurs objectifs (40% sont carrément des échecs)*

Les gestionnaires impliqués n’ont pas une idée claire de leur rôle, de leur autorité et des objectifs à rencontrer

Il n’y a pas suffisamment de ressources affectées au projet Il y a des erreurs d’architecture d’entrepôts de données fondamentales (celles-ci ne

sont pas élaborées dans le but de répondre aux besoins de reporting)

*source: Sid Adelman, Data Warehouse Project Management


LE CFOMASQUÉ

INTRODUCTION

A une idée claire de l’information qu’il serait utile d’obtenir afin de prendre de

meilleures décisions d’affaires.

Ne parle pas le même langage

Ne parle pas le même langage

Gère rapidement un projet de “mapping” et de “crunching” de données afin d’extirper les

données du système propriétaire.

Doit travailler avec des données qui ont été extirpées

avec une mauvaise compréhension des

implications du produit final.


LE CFOMASQUÉ

INTRODUCTION

Impact sur 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).


LE CFOMASQUÉ

INTRODUCTION


LE CFOMASQUÉ

INTRODUCTION

+ ETLOLTP


LE CFOMASQUÉ

OLTP: ONLINE TRANSACTION PROCESS


LE CFOMASQUÉ


*Systèmes transactionnels usuels ERP CRM Système de gestion

d’inventaire Système de gestion de la

paie Système d’enregistrement

de transactions de vente

*Besoins de reporting associés Profitabilité des clients Performance des

fournisseurs Productivité des

ressources Performance stratégique

de l’entreprise


LE CFOMASQUÉ


OLTP : Online Transaction Process Objectif du système de base de données:

Collecter et emmagasiner les données dans le système Entrée de données:

Souvent par interface web (avec sauvegarde automatique des données dans la base de données sous-jacente)

Consultation des données: Requêtes simples et similaires au formulaire d’entrée de données Création de rapports simples et fixes comme:

• Imprimer le nom de l’employé que l’entreprise a engagé hier• Obtenir l’adresse du client ABC


LE CFOMASQUÉ


OLTP : Évolution des besoins Les questions deviennent plus complexes au fil du temps Certaines informations dépendent d’autres départements et/ou

d’autres systèmes Peu de gens ont réellement besoin de voir tout le détail, par exemple,

des salaires par employé (avec NAS, adresses, etc.) Une petite quantité de données devient importante pour des groupes

de personnes différents, avec des perspectives différentes, ce qui implique des calculs différents pour chaque besoin.


LE CFOMASQUÉ


Source: Business dashboards : Nils Rasmussen, Claire Y. Chen, Manish Bansal.


LE CFOMASQUÉ


Problématiques rencontrées L’OLTP ne comprend souvent pas toutes les données nécessaires afin

de répondre à certaines questions (besoin de croiser avec données d’autres systèmes)

D’un point de vue système, le OLTP a été conçu pour faire de l’entrée de données individuelles (une transaction à la fois)

Ce n’est pas un système conçu pour performer des calculs sur de larges bases de données.

Comme les gens veulent quand même les réponses à leurs questions, ils font tous plusieurs requêtes dans le système, ce qui le ralentit inévitablement, autant au niveau de l’entrée de données que des requêtes.


LE CFOMASQUÉ

ODS: OPERATIONAL DATA STORE


LE CFOMASQUÉ


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. OLTP: entrée de données ODS: requêtes et reporting

Ces copies peuvent 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 pouvons 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é


LE CFOMASQUÉ


ODS: Caractéristiques Capture les transactions en temps réel ou presque donc hautement

transactionnel Suit souvent la même indexation que le système source Certains ODS vont être modélisés en suivant une structure dimensionnelle

plutôt qu’une structure transactionnelle, pour se conformer à la structure d’un entrepôt de données et ainsi pouvoir être importés plus facilement

Crée un environnement séparé pour désengorger les ressources du système OLTP en production

Permet d’intégrer de multiples sources de données Crée un environnement pour tranformer les données en vue d’être

migrées dans un entrepôt de données


LE CFOMASQUÉ



LE CFOMASQUÉ

ETL: EXTRACTING, TRANSFORMING AND LOADING


LE CFOMASQUÉ

ETL

ETL ETL (Extract, Transform and Load) est un 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, et souvent dans le contexte de construire un entrepôt de données

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. Par exemple, il est plus rapide de filtrer des tables avant de les lier que de faire l’inverse.


LE CFOMASQUÉ

ENTREPÔTS DE DONNÉES


LE CFOMASQUÉ

ENTREPÔTS DE DONNÉES

Pourquoi c’est important Les entrepôts de données permettent de travailler avec des

données structurées Les entrepôts de données sont conçus de façon à faciliter le

reporting et l’alimentation des tableaux de bord Pour créer une bonne architecture, on doit comprendre:

Différents types de structures d’entrepôts de données Différents langages de requêtes


LE CFOMASQUÉ

ENTREPÔT DE DONNÉES


LE CFOMASQUÉ

OLAP: ONLINE ANALYTICAL PROCESSING


LE CFOMASQUÉ


OLAP: Online analytical processing (ou cubes OLAP) Permet de regrouper les données par « dimension » Les tableaux de bord conçus à partir de bases de données OLAP

permettent aux utilisateurs de répondre à plusieurs questions à partir d’une seule composante (graphique, tableau, etc.), en sélectionnant les dimensions voulues (performance + flexibilité)

Pour répondre à la même question, dans un système OLTP ou ODS, il faut souvent plusieurs requêtes (et parfois, il est même impossible de répondre directement à la question)


LE CFOMASQUÉ


OLAP Mesures:

Les « Mesures » sont des items mesurables (montants ou quantités) Dimensions:

Une dimension est un regroupement de mesures et peut comprendre une hiérarchie ou de multiples hiérarchies, ce qui permet le forage éventuel

Par exemple, on pourrait chercher à obtenir le nombre total d’employés, et ensuite obtenir le résultat par année d’embauche, par trimestre, par mois ou carrément par journée.

La séquence de « Années » à « Trimestres » à « Mois » à « Jour » est une hiérarchie de la dimension date d’embauche (c’est la piste de forage!) et « Années » est un membre de la dimension date d’embauche


LE CFOMASQUÉ


http://www.lecfomasque.com/produit/tableau-de-bord-des-ventes/


LE CFOMASQUÉ


*Avantages du OLAP: Un des bénéfices du OLAP est de fournir aux usagers des tableaux de

bord des capacités de voir l’information sous divers angles « Drill up/Drill down »: les usagers peuvent voir les données de façon

plus ou moins regroupée Un autre bénéfice du OLAP est la capacité de « Drill across » (se

promener d’une dimension à une autre). Par exemple, vous pouvez regarder le total des ventes par client et ensuite vous pouvez regarder les produits vendus à l’un de ces clients. Ce ne sont pas tous les tableaux de bord qui permettent de faire ça.

« Drill through »: quitter le OLAP et voir la transaction dans le système relationnel de base pour éviter des délais


LE CFOMASQUÉ

“D”OLAP: DESKTOP


LE CFOMASQUÉ

« D »OLAP: DESKTOPFAST TRACK (PowerPivot, PowerQuery, VBA, etc.)


LE CFOMASQUÉ

« D »OLAP: DESKTOP


LE CFOMASQUÉ


DOLAP : Desktop OLAP Est habituellement construit par l’utilisateur final. Il télécharge la base de données (habituellement dans Excel) et

construit des tableaux croisés dynamiques et des tables de données. Les TCD permettent de filtrer et de forer dans toutes les dimensions. Le forage peut se faire jusqu’au niveau de la transaction. La structure est similaire à la structure ROLAP mais à plus petite

échelle et s’emploie généralement directement sur l’ordinateur de l’utilisateur final.


LE CFOMASQUÉ


Excel Importation de données via certains add-ins Excel

Add-ins vendus par fournisseurs de systèmes comptables F9 PowerPivot / PowerQuery Etc.

Importation de données à l’aide de macros Données résident ou non directement dans Excel Liaisons à des données « pré » structurées

Tableau Jet / Nav Reports


LE CFOMASQUÉ


Interface de tableau de bord

dans Excel

http://www.lecfomasque.com/produit/tableau-de-bord-des-ventes/


LE CFOMASQUÉ


Bases de données directement dans Excel


LE CFOMASQUÉ


Liaison de tables à l’aide de sumifs


LE CFOMASQUÉ



dans Excel


LE CFOMASQUÉ

« D »OLAP: DESKTOPInterface de

tableau de bord dans Excel


LE CFOMASQUÉ



dans Excel


LE CFOMASQUÉ

« D »OLAP: DESKTOPBases de données dans PowerPivot (add-in Excel)


LE CFOMASQUÉ


Permet d’importer des données de plusieurs

sources différentes


LE CFOMASQUÉ


Permet de lier les tables de données importées grâce à des champs communs


LE CFOMASQUÉ


POWER QUERY

Power Query pemet d’importer, de transformer et de fusionner des tables de données provenant de diverses sources.


LE CFOMASQUÉ


Tableau est un autre outil

pouvant être utilisé pour faire des tableaux de

bord


LE CFOMASQUÉ


Comme avec PowerPivot, on

peut importer des tables de données

et les lier entre elles


LE CFOMASQUÉ


Dans tous les cas Il faut savoir bien organiser ses données afin de concevoir des

tableaux et des graphiques qui répondent aux objectifs du tableau de bord et aux besoins d’information

Il faut prévoir en fonction de la croissance éventuelle de l’entreprise

*** Il peut être utile de se lancer à petite échelle avec des données locales avant d’enclencher un plus gros projet (prototype)


LE CFOMASQUÉ

“R”OLAP: RELATIONAL


LE CFOMASQUÉ

« R »OLAP: RELATIONAL

ROLAP Pour obtenir une « R »OLAP, il faut transformer une base de données

relationnelle OLTP en schéma en étoiles Un schéma en étoiles de base a une table simple de « Mesures » en son centre

et les dimensions autour d’elle



LE CFOMASQUÉ


ROLAP Les clés secondaires

dimensionnelles sur cette table simple échangent avec les clés primaires de chacune des dimensions de la table, ce qui forme une étoile



LE CFOMASQUÉ


ROLAP et schéma en étoiles Délai entre les systèmes OLTP et ROLAP à cause de la restructuration

des données Importation des données se fait de façon incrémentale pour réduire le

temps requis Utilisé surtout pour les besoins de forage jusqu’à l’unité

transactionnelle Par exemple, pour une cie manufacturière, la dimension « PRODUITS »

peut contenir des milliers de SKUs. Les données restent dans la BD et des tables d'agrégation sont créées

à même la BD. Sollicitation de la base de données à chaque relance


LE CFOMASQUÉ


ROLAP et schéma en étoiles Si une dimension a plusieurs attributs, elle devrait résider dans une

ROLAP. * Un attribut est une information concernant un membre d’une

dimension.



LE CFOMASQUÉ


ROLAP et schéma en étoiles Les attributs peuvent également être utilisés dans des requêtes

Ex.: Ventes totales de tous les clients en Californie Cette requête fait un filtre sur la dimension client et sur l’attribut

région De façon à emmagasiner et regrouper ces valeurs, la base de données

va croître très rapidement, particulièrement lorsqu’il y a un millier de clients

Ainsi, les aggrégations d’attributs sont souvent calculés sur-demande.


LE CFOMASQUÉ

TABLES D’AGRÉGATION


LE CFOMASQUÉ


Tables d’agrégation Ne font pas vraiment partie de la famille OLAP mais la structure sous-

jacente est très similaire à la structure ROLAP Il s’agit de données répliquées sur la base d’un déclencheur Les données sont physiquement emmagasinées de façon regroupée et

créent des tables Par exemple, on pourrait partir avec une table comme la suivante:


LE CFOMASQUÉ


Tables d’agrégation Quand le système source envoie une nouvelle transaction, cela

ressemble à ceci:

Le système garde un « snapshot» de la table originale : Le vendeur a vendu 4,500$ au client D le 28 janvier 2014.

Ensuite, le système transforme le tout et additionne la nouvelle transaction pour rencontrer le format mois.

Ainsi, Jan 28 2014 devient Jan 2014


LE CFOMASQUÉ


Tables d’agrégation L’ajout de la nouvelle transaction se fait comme suit:

Pour aboutir avec une table d’agréation finale ressemblant à ceci:


LE CFOMASQUÉ

“M”OLAP: MULTIDIMENSIONAL


LE CFOMASQUÉ

« M »OLAP: MULTIDIMENSIONAL

MOLAP: Multi-dimensional OLAP Similaire à ROLAP

basé sur des dimensions et des mesures construit avec des scripts d’aggrégation

Différence au niveau de l’entreposage des données: MOLAP emmagasine les résultats dimensionnels agrégés alors que ROLAP

emmagasine les tables de dimensions et de mesures MOLAP a tendance à regrouper les données à un niveau supérieur et

utilise plus efficacement l’espace du disque dur Les données sont stockées dans un cube (BD multidimensionnelle), dans

une structure indépendante Tous les croisements possibles sont ainsi pré-calculés


LE CFOMASQUÉ


MOLAP Pas besoin de joindre les tables ensemble, chaque table est alimentée

directement dans la hiérarchie dimensionnelle, une par une Chaque donnée importée doit contenir la colonne parent et la colonne

enfant

http://apandre.wordpress.com/data/datacube/


LE CFOMASQUÉ


« M »OLAP : CAS PRATIQUE Est-ce qu’on a embauché plus de personnes que prévu? Pour répondre à cette question, supposons que notre cube a comme: Mesure: Le nombre d’employés Dimensions:

Scénario Date d’embauche Employé


LE CFOMASQUÉ


Employés par date

d’embauche par scénario

# d’employés par poste par

date d’embauche par scénario

# d’employés par département par date d’embauche par scénario


LE CFOMASQUÉ


« M »OLAP : CAS PRATIQUE

Note: Mesure peut être le nombre d’employés, le salaire moyen, etc.


LE CFOMASQUÉ



Note: Dimension additionnelle disponible pour fin d’analyse.


LE CFOMASQUÉ



Note: Les employés sont rattachés à un poste et à un salaire.


LE CFOMASQUÉ


« M »OLAP : CAS PRATIQUE * Laquelle des deux BD ci-bas est appropriée pour un cube?


LE CFOMASQUÉ




LE CFOMASQUÉ

“H”OLAP: HYBRID


LE CFOMASQUÉ

« H »OLAP: HYBRID

HOLAP: Hybrid OLAP S’appuit avantageusement sur les technologies ROLAP et MOLAP. Offre la grande performance et les attributs complexes de MOLAP,

avec l’habilité de faire du forage à un niveau beaucoup plus bas de transactions, comme le fait ROLAP.

Les données de base restent dans la BD et le cube crée des structures pour les agrégations.


LE CFOMASQUÉ

DATA MARTS


LE CFOMASQUÉ

DATA MARTS

Data Marts C’est une collection de sujets organisés pour le support à la décision

basés sur les besoins d’un département quelconque Deux genres de data marts:

Data marts dépendants: la source est un entrepôt de données / sont tous alimentés par la même source STABLE

Data marts indépendants: la source est le système d’origine / alimenté de façon individuelle et séparée, souvent INSTABLE

On peut considérer les Data Marts comme des parties de MOLAP/ROLAP ou une section filtrée d’un ODS. Il peut y avoir des transformations additionnelles afin de personnaliser les données, en fonction de la terminologie des usagers.


LE CFOMASQUÉ

DATA MARTS


LE CFOMASQUÉ

CAS PRATIQUE


LE CFOMASQUÉ

CAS PRATIQUE

Desciption du cas Type d’entreprise

Vente de logiciels et services d’implantation / soutien technique Systèmes disponibles

Site web transactionnel Système de facturation Rapports de vente des partenaires CRM Système de gestion de l’inventaire Grille de tarifs des services Grille de taux de commissions par canal Gestion des RH


LE CFOMASQUÉ

CAS PRATIQUE

ROLAP (shéma en étoile) De quels systèmes proviendraient les données de la table centrale? À quoi ressemblerait cette table centrale? Que contiendraient les tables de dimensions et d’où proviendraient les

données? Comment les tables seraient-elles reliées entre elles?


LE CFOMASQUÉ

CAS PRATIQUE

ROLAP


LE CFOMASQUÉ

CAS PRATIQUE

Quels KPI pourraient être dérivés de cette base de données? Table centrale, croisée avec la dimension client:

Ventes par client (dollars et unités) Ventes par région (dollars et unités) Ventes par secteur d’activités (dollars et unités) Ventes par taille d’entreprise (dollars et unités)

Croisée avec produits: Mêmes indicateurs mais par catégorie de produits Même indicateurs mais par coûts/rabais/profits

Croisée avec services: Mêmes indicateurs mais par catégorie de services Même indicateurs mais par coûts/rabais/profits

On peut ajouter à cela les combinaisons d’attributs:Ventes par secteur d’activités, par région ou ventes par taille d’entreprise, par produit


LE CFOMASQUÉ

CAS PRATIQUE

Quels KPI pourraient être dérivés de cette base de données? Table centrale, croisée avec la dimension canal:

Ventes par canal (dollars et unités) Ventes par partenaire (dollars et unités) Commissions en % des ventes

Croisée avec client Ventes par canal, par secteur d’activité (dollars et unités) Ventes par canal, par taille d’entreprise (dollars et unités)

Croisée avec produits/services Mêmes indicateurs mais par catégorie de produits/services Mêmes indicateurs mais pour les coûts, les rabais et les profits

On peut ajouter à cela les combinaisons d’attributs:Comissions par canal


LE CFOMASQUÉ

CAS PRATIQUE

Quels KPI pourraient être dérivés de cette base de données? Table centrale, croisée avec la dimension représentant:

Ventes par représentant (dollars et unités) Ventes par territoire (dollars et unités)

Croisée avec canal Ventes par représentant, par canal

Croisée avec client Ventes par représentant, par secteur d’activité (dollars et unités) Ventes par représentant, par taille d’entreprise (dollars et unités)

Croisée avec produits/services Mêmes indicateurs mais par catégorie de produits/services Mêmes indicateurs mais pour les coûts, les rabais et les profits

On peut ajouter à cela les combinaisons d’attributs:Ventes par représentant, par territoire


LE CFOMASQUÉ

CAS PRATIQUE

Quels KPI pourraient être dérivés de cette base de données? Table centrale, croisée avec la dimension produits:

Ventes par catégorie de produits (dollars et unités) Idem mais pour coûts, rabais et profits

Table centrale, croisée avec la dimension services Ventes par catégorie de services (dollars et unités) Idem mais pour coûts, rabais et profits

Les deux tables croisées Répartition des ventes, coûts, rabais, profits entre services et produits

On peut ajouter à cela les combinaisons d’attributs:Niveau de stock par catégorie de produits


LE CFOMASQUÉ

CAS PRATIQUE

Types de KPI possibles: Données brutes: Volumes, dollars, proportions, etc. Évolution des données: Comportement de la donnée dans le temps Comparaison des données: Comparaison de la donnée vs la même

donnée à un autre moment dans le temps, vs une cible, vs un compétiteur, « ranking », « top » et « bottom », etc.

Dans notre cas pratique, que se passerait-il si nous voulions comparer les ventes réelles avec le budget?

Pouvez-vous définir quelques pistes de forage intéressantes?


LE CFOMASQUÉ

CONCLUSION


LE CFOMASQUÉ

CONCLUSION

Pour construire des KPI multi-systèmes, il faut: Déterminer et documenter les besoins des usagers du tableau de bord

(quelles seront les KPI qui serviront à prendre de meilleures décisions d’affaires)

Identifier les sources de données qui seront utilisées pour construire les KPI

Définir le processus d’importation des données en provenance de ces différentes sources

Planifier la structure des bases de données de l’entrepôt de données Élaborer le tableau de bord en accord avec les besoins des usagers L’idéal demeure d’élaborer d’abord un environnement de test, peu

coûteux


LE CFOMASQUÉ

CONCLUSION

Pour vos projets de tableaux de bord, faites affaires avec l’équipe du CFO masqué:

développement de kpi dans un environnement multi-systèmes

Data & Analytics