Conseil 72: décoder les processus métiers

Dans le conseil 69, l'identification des processus métiers, l'auteur discutait de l'importance de reconnaître les processus métiers de votre organisation et fournissait des lignes directrices pour les repérer. Nous plongeons dans plus de détails ici.

Mettre l'accent sur les processus métiers est absolument essentiel pour mettre en œuvre avec succès une solution d'entrepôt de données à l'aide de la méthode Kimball. Les processus métiers sont la pierre angulaire d'un entrepôt de données dimensionnel. Nous vous proposons de construire votre entrepôt de données de manière itérative, un processus à la fois. Vous pouvez vous demander , " Qu'y a-t-il de si magique avec les processus métiers? Comment l'identification des processus métiers nous aide dans nos activités de modélisation dimensionnelle?". La réponse est que l'identification correcte des processus métiers lance toute la conception dimensionnelle. Le secret est que chaque processus se traduira par au moins une table de fait. En résumé, l'identification des processus métiers permet d'identifier les tables de faits à construire.

Conseil 71: le nommage des champs

La question de la dénomination des champs se pose lorsque vous créez le modèle de données dimensionnel. Le nommage est complexe parce que les gens ont des significations différentes pour un même nom, comme "chiffre d'affaire", et des noms différents avec le même sens, comme "ventes". La difficulté vient de la nature humaine: la plupart d'entre nous ne voulont pas renoncer à ce que nous savons pour apprendre une nouvelle façon. La tâche peu enviable de déterminer les noms tombe généralement sur le gestionnaire des données. Si vous êtes responsable de cette tâche, vous trouverez l'approche suivante en trois étapes utile. Les étapes 1 et 2 se produisent généralement avant que le modèle soit présenté aux utilisateurs métiers. L'étape 3 arrive généralement après que les utilisateurs métiers aient vu et compris le modèle.

Conseil 69: Identifier les processus métiers

Les lecteurs qui suivent l'approche de Kimball peuvent souvent réciter les quatre décisions clés de la conception d'un modèle dimensionnel: identifier le processus métier, la granularité, les dimensions et les faits. Bien que cela semble simple, les équipes butent souvent sur ​​la première étape. Ils peinent à définir le processus métier, car c'est un terme qui semble prendre un sens différent selon le contexte. Puisque l'identification du processus métier est le premier point de la conception d'un modèle dimensionnel, nous voulons éliminer la confusion dans notre contexte.

Tout d'abord, nous allons commencer par discuter de qu'un processus métier n'est pas. Lors de la conception d'un modèle dimensionnel, le processus métier ne se réfère pas à une direction de l'organisation ou à une fonction. De même, il ne doit pas faire référence à un seul rapport ou à une analyse spécifique.

Pour un concepteur décisionnel, le processus métier est un événement ou une activité qui génère ou recueille des métriques. Ces mesures sont des mesures de performance pour l'organisation. Les analystes d'affaires veulent les examiner et les évaluer selon une combinaison illimitée de filtres et de contraintes. En tant que concepteur, il est de notre devoir de présenter ces mesures dans une structure facile à comprendre qui répond rapidement aux demandes imprévisibles.

Lors de l'identification du processus métier pour la modélisation dimensionnelle, des caractéristiques et des tendances communes émergent souvent.

1. Les processus métiers sont généralement pris en charge par un système opérationnel. Par exemple, le processus de facturation de l'entreprise est soutenue par un système de facturation; de même pour les processus achats, commandes, ou reception.
2. Les processus métiers génèrent ou recueillent des mesures uniques avec une granularité et une dimensionnalité unique utilisées pour évaluer la performance de l'organisation. Parfois, les mesures sont le résultat direct du processus métier. D'autres fois, les mesures en sont dérivées. Peu importe, les processus métiers fournissent des indicateurs de performance utilisés par divers procédés analytiques. Par exemple, le processus de gestion des commandes de vente entraine de nombreux rapports et analyses, telles que l'analyse de la clientèle, la performance des commerciaux, et ainsi de suite.
3. Les processus métiers sont souvent exprimés comme des verbes d'action avec les dimensions associées comme des noms décrivant le qui, quoi, où, quand, pourquoi et comment liées au processus. Par exemple, les résultats du processus de facturation de l'entreprise seront découpés et analysés par date, client, service/produit, et ainsi de suite.
4. Les processus métiers sont généralement déclenchés par une entrée et produisent un résultat en sortie qui doit être surveillé. Par exemple, une proposition acceptée est entrée dans le processus de commande qui se traduit par un bon de commande et ses paramètres associés. Dans ce scénario, le processus métier est la commande de vente. Vous aurez donc une table de faits des commandes avec la commande client comme dimension - potentiellement dégénérée - et les montants et le nombre de commande comme faits. Essayez d'imaginer le flux général d'entrée d'un processus métier, et créant des métriques en sortie. Dans la plupart des organisations, il existe un ensemble de processus métiers où les résultats de l'un deviennent les entrées d'un autre. Dans le langage d'un concepteur décisionnel, ces processus métiers se traduiront par une série de tables de faits.
5. Les analystes veulent parfois croiser les processus métiers, comparant ainsi le résultat d'un processus à celui d'un autre. Croiser les processus est certainement réalisable si les dimensions communes aux deux processus sont conformes .

Déterminer les processus métiers de base de votre organisation est essentielle pour établir le cadre global de vos modèles dimensionnels. La meilleure façon de déterminer ces processus est d'être à l'écoute des utilisateurs. Quels sont les processus qui génèrent les indicateurs de performance les plus intéressants pour suivre l'activité? Dans le même temps, l'équipe de l'entrepôt de données doit évaluer les réalités de l'environnement source pour fournir les données convoitées par l'entreprise.

Un dernier commentaire ... Il va sans dire qu'un tableau de bord n'est pas un processus métier, il présente seulement les résultats de la performance de nombreux processus métiers différents.

Source originale: www.kimballgroup.com

Article original "Kimball Design Tip #69: Identifying business processes", publié le 5 juillet 2005.

Conseil 68: Forer latéralement dans les données avec SQL

Le forage latéral fait réfèrence au processus qui interroge plusieurs tables de faits et en combine les résultats dans un ensemble de données unique. Un exemple courant consiste à combiner les données prévisionnelles avec des données réelles. Les données prévisionnelles sont généralement conservées dans une table séparée, capturé à un niveau de détail différent de celui des données réelles. Quand un utilisateur veut un rapport qui compare le réel et le prévisionnel par client, la requête doit mixer deux tables de faits. (Note: les données des deux tables de faits peuvent être combinées uniquement si elles sont construites en utilisant des dimensions conformes. Le client, la date et toutes autres dimensions partagées doivent être exactement les mêmes dans les deux schémas en étoile).

Le moyen le plus efficace de combiner les données des deux tables de fait est d'exécuter des requêtes distinctes sur chaque table, puis de combiner les deux ensembles de résultats en faisant correspondre leurs attributs communs. Cette solution focntionne bien car la plupart des optimiseurs de base de données reconnaissent chaque requête unique et retournent rapidement les deux ensembles de résultats.

Conseil 67: Maintenir des références vers les sources opérationnelles

Nos entrepôts de données sont de plus en plus orientés vers le suivi des opérations détaillées des clients en quasi temps réel. Et comme Patricia Seybold souligne dans son livre, Customers.com (Times Business, 1998), la gestion des relations client, c'est avoir accès aux données de tous les processus d'une organisation en relation avec les clients.

Garder les informations détaillées issues de tous les processus faisant face aux clients, et en même temps fournir une vision intégrée, présente un défi intéressant pour l'architecte ETL. Supposons que nous ayons une entreprise orientée client avec une quinzaine de systèmes en relation avec celui-ci comme la gestion des ventes des magasins, des ventes en ligne, des livraisons, des paiements, des crédits, des contrats de maintenance, des centres d'appels et diverses formes de communications commerciales. Beaucoup de ces systèmes créent leur propre clé naturelle pour chaque client, et certains d'entre eux ne traitent pas les doublons se référant à un même client. Au final, Il se peut que nous n'ayons aucun identifiant client unique et fiable à travers tous ces systèmes.

Conseil 66: Répondre à la paralysie de l'analyse

De nombreuses équipes en charge de l'entrepôt de données penchent fortement vers le côté pratique. Ils passent rapidement à la mise en œuvre sans passer assez de temps et d'énergie à développer leurs modèles de données, à identifier minutieusement les règles métiers, ou à planifier leurs processus de réconciliation des données. Par conséquent, ils chargent à toute vitesse et finissent par revoir leurs processus, fournissant au passage des données incorrectes ou incomplètes, et entraînant généralement des difficultés.

D'autres équipes ont le défi inverse. Ces équipes se sont engagées à faire leurs devoirs dans tous les domaines critiques. Ils sont concentrés sur la qualité des données, la cohérence, l'exhaustivité et l'administration. Cependant, ces équipes s'enlisent parfois dans des problèmes qui auraient dû être résolus depuis longtemps. Bien sûr, cette impasse se produit au pire moment - les dates de mise en œuvre promises approchent rapidement et les décisions de conception qui devaient être prisent lors de la mise en œuvre restent en suspens.

Conseil 65: Documentez votre système ETL

Que vous utilisiez un outil ETL ou codiez à la main votre système d'ETL, celui-ci est un logiciel comme les autres qui doit être documenté. De même que votre entrepôt de données évolue, le système ETL évolue également, et vous et vos collègues devez être en mesure de comprendre rapidement l'ensemble de l'architecture du système ainsi que ses petits détails.

Il ya un mythe répandu affirmant que les outils ETL sont auto-documentés. Ceci n'est vrai que pour la comparaison avec les systèmes développés manuellement. N'adhérez pas à ce mythe: vous avez besoin de développer une architecture globale et cohérente pour votre système ETL. Et vous devez documenter ce système. Oui , rédiger un document.

Conseil 64: Eviter l'isolation entre les équipes décisionnelles

Peut-être est-ce juste une coïncidence, mais plusieurs personnes ont posé la même question récemment: "Est ce que l'équipe décisionnelle devrait récolter les exigences des métiers?" Honnêtement, cette question me fait froid dans le dos. Je crains que beaucoup d'organisations aient trop compartimentées leurs équipes décisionnelles et celles en charge de l'entrepôt de données.

Conseil 63: Construire un système qui capte les changements de données

Le flux de données ETL commence par transférer les données les plus récentes de la source dans l'entrepôt de données. Dans presque tous les entrepôts de données, nous devons transférer que les modifications pertinentes de la source de données depuis le dernier transfert. Rafraichir complètement nos tables de faits et nos dimensions est généralement inopportun.

L'activité d'isoler les dernières données de la source s'appelle "la capture de données". L'idée derrière cela semble assez simple: il suffit de transférer les données qui ont été modifiées depuis le dernier chargement. Mais la construction d'un bon système de capture de données n'est pas aussi facile qu'il n'y paraît.

Conseil 62: Hiérarchies alternatives

De nombreux utilisateurs demandent souvent à voir des données groupées de différentes façons. Dans le cas le plus simple, un service, comme le marketing, veut voir les clients regroupés selon une hiérarchie donnée et un autre service, comme le commercial, veut les voir dans une hiérarchie différente. Lorsque c'est simple, il est logique d'inclure les deux hiérarchies dans la dimension Client et de les nommer distinctement. Malheureusement, il est possible de construire de nombreuses hiérarchies dans une dimension avant que cela  ne devienne inutilisable.

La nécessité d'adapter de manière plus souple les hiérarchies alternatives se produit donc lorsque plusieurs services veulent voir les choses à leur façon, et veulent voir cela de plusieurs manières. Dans ce cas, nous travaillons généralement avec les utilisateurs pour définir le moyen le plus courant de regrouper les données. Cela devient ensuite la norme ou la hiérarchie par défaut dans la dimension de base. Toutes les autres hiérarchies couramment utilisées sont également intégrées dans la dimension afin de simplifier le travail des utilisateurs.

Nous proposons ensuite une table de hiérarchie alternative qui permet aux utilisateurs de manipuler les données en fonction de leur choix et des hiérarchies alternatives disponibles. La figure ci-dessous montre un exemple d'une table intermédiaire de hiérarchie alternative appelée CustomerRegionHierarchy pour aligner les régions géographiques.

Chaque hiérarchie de la table des hiérarchies alternatives doit inclure toute la hiérarchie de son attribut le plus fin, qui sert de jointure avec la dimension associée, à celui le plus haut. Dans le cas illustré ici, la hiérarchie commence au niveau de l'état (State) et remonte à partir de ce point. Il est également possible de commencer à un niveau de détail plus fin, le code postal par exemple, mais cela rendrait la table intermédiaire plus grosse et n'apporterait pas d'avantages supplémentaires. D'un autre coté, s'il y a besoin de créer des groupes de codes postaux dans les états, la table hiérarchique intermédiaire doit évidemment commencer au niveau du code postal.

Pour simplifier les rapports et analyses, la table intermédiaire inclue la définition de la hiérarchie standard. Ce choix devient alors celui par défaut dans tous les rapports structurés, permettant aux utilisateurs de changer ensuite entre la hiérarchie standard et les hiérarchies alternatives. La création d'une table Hiérarchie séparée simplifie la maintenance en ayant une ligne par hiérarchie, mais accroit la complexité visuelle. Cette table peut également être dénormalisée dans la table intermédiaire.

La table CustomerRegionHierarchy peut être utilisée dans les rapports structurés ou par les utilisateurs avancés. La jointure avec la table Client entrainera des cumuls inexacts à moins que le champ HierarchyName soit filtré sur une hiérarchie unique. Tous les rapports structurés qui ont accès à la table des hiérarchies alternatives peuvent être construit en utilisant la hiérarchie par défaut et devraient posséder un filtre choisir une seule hiérarchie.

La table des hiérarchies alternatives est un exemple de valeur ajoutée dans un entrepôt de données. Ce genre de regroupement personnalisé est couramment utilisé par les métiers, mais les définitions sont rarement centralisées et gérées de manière formelle. Habituellement, elles sont stockées dans un fichier Excel sur un ordinateur personnel.

Source originale: www.kimballgroup.com

Article original "Kimball Design Tip #62: Alternate hierarchies", publié le 7 décembre 2004.