Conseil 40: Structure d'une application analytique

Un environnement d'application analytique compréhensible à besoin de fournir un cadre qui transporte les utilisateurs au delà des simples rapports standards. Cet environnement doit les guider de manière proactive à travers l'analyse d'une situation métier, pour les aider à prendre une décision pertinente et réfléchie. Les buts du cycle de vie de cette application analytique sont:

• La proactivité guide les utilisateurs au delà des rapports basiques
• Identifier et comprendre les situations où la performance est exceptionnelle
• Capturer les meilleures pratiques de prise de décision pour chaque situation où la performance est exceptionnelle
• Partager le résultat des meilleures pratiques ou le connaissance à travers l'organisation

Nous divisons le processus en cinq étapes distinctes:

1. Publier les rapports: fournir des rapports opérationnels et managériaux standards sur l'état courant du métier
2. Identifier les exceptions: mettre en valeur les situations où la performance est exceptionnelle (qu'elle soit supérieure ou inférieure à ce qui est attendu) pour attirer l'attention
3. Déterminer les causes: chercher à comprendre le "pourquoi" et les causes à la base de ces exceptions
4. Modéliser des alternatives: fournir un scénario pour évaluer les différentes décisions possibles
5. Suivre les actions: évaluer l'efficacité des actions recommandées et fournir un retour aux systèmes opérationnels et à l'entrepôt de données (qu'affichera les rapports de l'étape 1), bouclant ici la boucle

Revoyons chacune de ces étapes en détail pour comprendre leurs objectifs et l'impact sur l'architecture de nos entrepôt de données.

Etape 1: Publier les rapports. Les rapports opérationnels et managériaux standards sont le point de départ du cycle de vie des applications analytiques. Ces rapports montrent les résultats actuels au regard des périodes précédentes ou résultats attendus afin de fournir un état de l'activité (par exemple: "la part de marché à grimpé de 2 points, mais les profits ont baissés de 10%").

Les exigences de l'entrepôt de données pour cette étape se concentrent sur l'amélioration de la couche de présentation et inclus les technologies associées comme les tableaux de bords, les portails, et les scorecards. Alors que beaucoup d'implémentations d'entrepôts de données arrivent à fournir ces rapports, ils s'arrêtent à cette étape en se déclarant victorieux.

Etape 2: Identifier les exceptions. Cette étape se concentre sur l'identification des phases d'analyses du type "que c'est-il passé?" ou "où est le problème?". Le but de cette étape est d'identifier les exceptions liées aux performances normales ainsi que les opportunités. La plupart des managers métiers ont demandés à l'équipe en charge de l'entrepôt de données de répliquer une pile de rapports dans l'entrepôt, quand en réalité, ils veulent vraiment les rapports avec des alertes (marqueurs différentiels,  surlignage...). Cette étape est essentielle pour aider les utilisateurs à s'y retrouver parmi le déluge de données, et à se concentrer sur les opportunités qu'offrent les meilleurs retours métiers; ceux qui demandent le moins d'attention.

Etape 3: Déterminer les causes. Cette étape essaie de comprendre le "pourquoi" et les causes initiales de ces exceptions. Identifier les relations fiables et les interactions entre les variables qui provoquent ces performances exceptionnelles est la clé.

Soutenir avec succès les efforts des utilisateurs dans cette étape demandera à notre architecture d'entrepôt de données d'inclure un logiciel comme des outils statistiques et/ou des algorithmes de data-mining (association, séquence, classification, segmentation) pour quantifier les causes et les effets.

Etape 4: Modéliser des alternatives. Dans cette étape, nous construisons des relations de cause-à-effet pour développer des modèles d'évaluation des différentes alternatives possibles.

La capacité à fournir des analyses de type "Si... alors..." et des simulations sur un ensemble de décisions potentielles est considéré comme le but final lorsqu'on suit le cycle de vie typique des applications analytiques. Nous espérons répondre correctement aux questions stratégiques comme:"qu'arrive-t-il à ma part de marché, mon revenu, ma quantité vendue, si j'augmente de 10% mes prix par rapport à mes deux principaux concurrents? ou, quels sont les impacts sur mes coûts d'inventaires si je peux couvrir 5% de mes prévisions au lieu des 10% habituels? Notre architecture d'entrepôt aura besoin d'accueillir de nouvelles technologies comme des outils statistiques et des algorithmes de data-mining pour évaluer les différents modèles, comme l'analyse de sensibilité, les simulations Monte-Carlo, et les optimisations.

Etape 5: Suivre les actions. Cette étape évalue l'efficacité des décisions recommandées par l'étape précédente. Idéalement, nous sommes capables de faire un processus en boucle et fournir un retour sur les actions conseillées au système opérationnel. L'efficacité des décisions devrait être capturée et analysée afin d'améliorer constamment le processus d'analyse, les règles métiers et les modèles.

Cette étape ajoute des contraintes à notre entrepôt. Nous devons être capable d'enregistrer les retours dans le système opérationnel et dans l'entrepôt. Nous recommandons également l'amélioration des modèles dimensionnels existants ou la construction de data-marts de suivi de la performance pour enregistrer et suivre les résultats des décisions métiers spécifiques pour déterminer lesquelles fonctionnent et lesquelles ont échouées. 

Source originale: www.kimballgroup.com

Article original "Kimball Design Tip #40: Structure of an analytic application", publié en octobre 2002.