Comment modéliser son glossaire?

De quelles données dispose-t-on sur nos fournisseurs?

Quelle est la différence entre un prospect et un client?

Comment être sûr de la formule de calcul de cet indicateur?

Si comme moi vous avez entendu ces questions de manière récurrente, il y a des chances que vous caressiez l'idée de fabriquer votre glossaire de données! Vous vous êtes peut-être même posé la question "Pourquoi alors qu'on entend parler partout de l'importance des données, je ne dispose pas encore d'un référentiel me permettant de les comprendre". 

Lors de mes premières tentatives de construction d'un glossaire, plusieurs défis me sont apparus : Identifier et définir les objets à cartographier, contextualiser les objets… mais le plus complexe était de savoir comment construire une modélisation qui s’affranchisse de la réalité technique et donne une vision fonctionnelle faisant sens pour les utilisateurs.

Cet article s’adresse à ceux qui voudraient se lancer dans l'aventure de la modélisation d'un glossaire. Il a pour vocation d'étudier les avantages et inconvénients de deux approches de modélisation d'un glossaire

L'approche par verticaux de données

Si la première question de cet article vous a interpellé, il y a de fortes chances pour que cette approche vous parle. En effet, elle vise à définir au mieux les grands objets gérés par l'organisation : Employé, Fournisseurs, Article. A ces données maîtres, on va rattacher hiérarchiquement des termes métiers, permettant ainsi de les décrire, quelle que soit leur provenance organisationnelle ou logicielle… un peu comme on le ferait avec une approche type master data management.

Prenons l'exemple d'un fournisseur: nous avons bien sûr des données liées aux contacts que nous avons avec lui (commercial, comptabilité), des données liées à l'entreprise... En les rattachant hiérarchiquement, nous pourrions avoir une représentation de ce type:

Le grand avantage de cette méthode est que l’on s’intéresse à la donnée, indépendamment

• Des complexités de gestion : plusieurs systèmes (parfois redondants) peuvent gérer ces données.
• des domaines organisationnels : plusieurs départements peuvent intervenir sur ces données : en tant que producteur, consommateur etc…

Pour moi, cette approche présente néanmoins deux limites   

• La gestion des objets connexes : comment décrire les liens entre les différents concepts, ou tout simplement comment décrire la relation entre un prospect et un client ? sans parler de la gestion des synonymes…
• La capacité d'appréhension pour des utilisateurs habitués à réfléchir en termes de silos applicatifs.

Approche orientée urbanisation 

La démarche consiste à s’appuyer sur les principes d’urbanisation d’entreprise chers aux architectes d’entreprise pour modéliser les données.

Nous pouvons alors décrire 4 couches principales :

• L’architecture métier qui correspond à la cartographie des processus métiers de l’organisation
• La vision fonctionnelle qui correspond à la description fonctionnelle du SI
• La vision applicative : soit les différentes briques logicielles composant la couche service du SI
• La vue technique : c’est-à-dire les éléments techniques permettant le fonctionnement de la vision applicative mais aussi les échanges d’informations: dictionnaire des bases de données, référentiels de traitements… 

Selon le degré de finesse que l’on voudra atteindre, on peut choisir de mettre en oeuvre tout ou une partie de ces couches. Dans un premier temps les couches fonctionnelles et techniques me semblent suffire.

La couche fonctionnelle nous permettra de décrire les données gérées d’un point de vue métier. 

Des subdivisions, les zones, peuvent être utilisées pour distinguer 

• Les zones d’activités (opérations, support, pilotage…) découpées par ordre de finesse en quartiers, îlots et données
• La zone de référentiels : correspondant aux données mises à disposition du reste du glossaire qui sont transverses et relativement stables : master data, nomenclature…

 Cette approche me semble apporter deux grands avantages :

• La cartographie colle au plus près des réalités fonctionnelles de gestion tout en faisant ressortir des grands silos de données transverse à certains processus ou activités de l’organisation.
• La modélisation est ainsi plus facile à réaliser et plus facile à accepter.

Conclusion

Le glossaire étant un des principaux points d'entrée à la data pour de nombreux utilisateurs, sa modélisation est un enjeu important de vos démarches de cartographie et de gouvernance des données. Il convient donc que celui-ci

• Soit compréhensible par tous, 
• Suffisamment complet sans être complexe
• Affranchi de la réalité physique afin de ne pas être un succédané de votre dictionnaire

Les deux approches présentées dans cet article permettent à la fois une appropriation rapide et une bonne compréhension métier. J’ai volontairement axé cet article sur ces deux points, d'autres peuvent être pris en compte par exemple :   

• La maintenance : est ce que ce modèle va pouvoir évoluer facilement? 
• La description : quels sont les éléments dont je vais avoir besoin pour décrire mes objets? une description simple sous forme de texte est un bon premier pas mais elle est vite limitée que ce soit en termes d’analyse, de possibilité d’évolution… sans parler de l’harmonisation des informations apportées. . 
• La contextualisation : on l’a vu plus haut, le glossaire doit pouvoir être resitué dans son environnement, tant métier que technique. Le risque est grand d’avoir une vision purement théorique qui soit inutilisable. Il faut donc disposer à la fois 
• De liens transverses à l’intérieur du glossaire
• De liens avec les objets hors du glossaire : le lien avec la contrepartie technique (si existante), l’intégration dans les processus métier, l’accès via des tableaux de bord, des écrans etc...

Pour conclure, j’ai une préférence pour l’approche orientée urbanisation car elle me semble plus complète : elle ne se limite pas au glossaire mais permet d’appréhender également les autres aspects d’une démarche de cartographie des données : où est gérée la donnée, comment elle est transformée et comment est elle exploitée. Pour autant c’est également cette complétude lié à une certaine rigidité qui font que des fois, l’approche par verticaux de données est bien plus simple à déployer et appréhender par des utilisateurs ayant des niveaux de maîtrise différents. On pourrait alors envisager une démarche itérative permettant de progressivement passer de la première à la seconde!