Urbanisme des référentiels – partie II

Suite à un premier billet qui posait la problématique des données de référence dans le SI et ce que pouvait être une démarche référentielle, il est ici question d’étudier les difficultés  et les écueils d’une telle démarche.

Ce que n’est pas une démarche référentielle

Ce n’est pas un simple outil MDM

Une approche référentielle n’est pas nécessairement associée à la mise en œuvre d’un  produit du marché.  Les outils de type MDM (Master Data Management), qu’ils soient  génériques ou spécialisés par domaines métiers, sont des facilitateurs, mais bien  rarement des solutions « clé en main » au-delà d’une simple maquette. L’enjeu essentiel  d’une démarche référentiel n’est donc pas l’outil mis en œuvre mais la transformation  progressive du SI pour urbaniser ses données de référence.

Néanmoins, certains domaines (relation client, gestion des identités) sont plus matures et plus standardisés que d’autres, laissant la place à des solutions verticales de gestion des données référentielles plus abouties que les outils génériques multi domaines.

Ce n’est pas un progiciel métier

Les progiciels métiers de type ERP (gestion commerciale, comptabilité, RH etc.)  consomment des données référentielles et sont souvent créateurs de données référentielles. Mais ce rôle de créateur de donnée référentiel n’en fait pas pour autant toujours un candidat idéal pour assumer le rôle de référentiel d’entreprise.

Ils sont rarement de bons référentiels d’entreprise du fait de leur rigidité et la restriction de leur vision du référentiel à leur métier. Par ailleurs, faire porter le rôle de référentiel central à un ERP complexifie l’évolution de celui-ci alors même qu’un des rôles d’un référentiel est d’amortir pour partie les évolutions des ERP.

Toutefois, dans le cas de SI de petite ou moyenne taille fortement structuré autour d’un seul progiciel, ou d’une suite intégrée de progiciel, l’option de gérer le référentiel dans le progiciel est souvent l’option la meilleure (simplicité, cohérence).

Ce n’est pas un projet d’intégration

La mise en œuvre d’un référentiel s’accompagne de la mise en œuvre de nombreux flux. Une des difficultés de mise en œuvre d’un référentiel, tout comme la mise en œuvre d’un ERP, est la gestion de ces nombreux flux et des interfaces associées. Ce besoin d’intégration pousse parfois à confondre démarche référentielle et mise en œuvre d’outils d’intégration spécifiques.

Une approche référentielle n’a pas pour objectif de définir les moyens techniques d’intégration des différentes applications.  Tout au plus elle définit des patterns d’intégration des applications au référentiel, indépendamment des technologies :

  • Diffusion de type publish & subscribe en mode événementiel ou de type batch par annule/remplace (full) ou modifications (delta)
  • Intégration par services synchrones vs messages vs fichiers

Il convient donc de s’intégrer aux pratiques existantes d’intégration du SI et si nécessaire de les faire évoluer

Les difficultés d’une démarche référentielle

Un travail de fond nécessaire…

Une approche référentielle demande une réflexion plus importante sur modéliser la forme des données de référentiel, et notamment sur leur généralité,  les règles de mise à jour et de cohérence, ainsi que les principes de diffusion dans le SI

Une approche référentielle n’a pas de sens si elle n’est pas accompagnée d’une étude d’urbanisme des briques du SI et des données de référentiel.  Le risque est sinon de construire un élément jetable,  au mieux satellite d’une petite portion du SI,  qui ne fera qu’ajouter de la complexité.

La mise en œuvre d’un référentiel simplifie et unifie l’intégration des référentiels dans le SI, mais ceci n’est pas pour autant une solution « magique » : les capacités et limites des progiciels à intégrer restent ce qu’elles sont…

Un arrimage nécessaire aux projets métiers

Bien que transverse, il est rarement possible d’initier un référentiel en dehors du cadre d’un projet métier. En règle générale, les deux principaux écueils sont :

  • L’absence d’un sponsor métier du fait de la forte transversalité
  • Le choix du périmètre initial (données et facettes des données) est difficile sans cas d’usage concret.

Néanmoins, une approche référentielle trop ambitieuse requiert un travail significatif peu compatible avec les plannings des projets métiers.  Les risques de « court circuit » du référentiel en cours de projet sont dans ce cas élevés. Il est souvent long et difficile de relancer un projet référentiel suite à ce type d’échec.

De fait, un arrimage aux projets métier est nécessaire mais la trajectoire de mise en œuvre est toujours délicate et doit gérer le compromis entre la masse critique nécessaire et les risques/coûts de mise en œuvre. De fait,  un référentiel prend de la valeur à mesure qu’il accumule et croise des données référentielles en nombre suffisant et qu’il alimente une majorité des applications du SI, mais une première version doit se contenter d’un périmètre restreint de données et d’applications connectées pour limiter les risques coût et planning.

Dans quels cas une démarche référentielle est-elle pertinente ?

Pour les SI et les entreprises qui préparent des grands projets de transformation. Dans ces situations, le SI a besoin d’absorber les évolutions et non seulement les subir. Les projets de transformation sont aussi l’occasion d’extraire certains référentiels des applications métiers et mettre en œuvre progressivement des référentiels d’entreprise.

Lorsqu’une application centrale du SI perd petit à petit son rôle de centre de gravité au profit d’une ou plusieurs nouvelles applications, la mise en œuvre progressive d’un référentiel permet de faciliter la transformation de ce patrimoine en amortissant les impacts de ses évolutions et en évitant  de faire porter à ce patrimoine tous les concepts et contraintes des nouveaux progiciels ou applications qui visent à le remplacer.

L’arrivée de nouveaux progiciels bouleverse souvent l’équilibre du SI et posent des nouveaux concepts sans la distance nécessaire. Certaines notions structurantes sont amenées par des progiciels et il convient de déterminer s’il s’agit d’un patois local au nouveau progiciel ou bien d’un terme partagé dans le SI et l’entreprise. Ceci conduit à l’émergence forte d’un besoin d’une plate-forme neutre qui matérialise le vocabulaire de l’entreprise.

Laisser un commentaire

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