Archives du mot-clé Référentiels

Urbanisme des référentiels – partie III

Après avoir posé ce que pouvait être une démarche référentielle et souligné les écueils d’une telle démarche, il s’agit maintenant d’identifier quelques principes d’urbanismes applicables aux données de référence.

Ces principes sont à utiliser comme des indications et non comme des lois ou des dogmes. Il est tout à fait possible que par moment, violer ou s’écarter de ces principes soit une bonne option. Néanmoins, il convient de bien vérifier les motivations de ces écarts, la plupart étant de fausses bonnes idées.
Il ne s’agit que des principes de base de gestion des données de références, il convient de les enrichir et les adapter avec :
• le retour d’expérience suite à la mise en œuvre des premiers référentiels dans le SI,
• des illustrations et des exemples concrets appliqués dans les projets pour communiquer plus efficacement auprès des autres projets,
• une adaptation au contexte de chaque système d’information.

Unicité du référant

L’objectif de l’unicité du référant est de favoriser la cohérence des données référentielles au sein du SI.

ref_unicite

Ce principe propose que pour chaque type de donnée référentielle il y ait unicité du référant. Par exemple, un seul référentiel produit, un seul référentiel fournisseur. Plusieurs points importants sont à préciser :
• Le référant n’est pas nécessairement le créateur de la donnée référentielle.
• Il n’y a pas de contrainte d’unicité des sources de données référentielles sur des périmètres disjoints. Par exemple le référentiel des personnes peut provenir de deux systèmes de Paye qui concernent chacun des populations différentes de l’entreprise.
• Dans le cas d’applications très intégrées entres-elles, l’une d’elles peut jouer le rôle de point de diffusion pour les autres – elles sont vus comme globalement une seule application dans le circuit de diffusion des données référentielles.

Centralisation des mises à jour

Bien que leur cycle de vie soit souvent plus lent que les données opérationnelles, les données référentielles ne sont pas immuables. Elles font l’objet de mises à jour et ce n’est pas toujours le référant ou même le créateur de la donnée qui est à l’initiative de cette mise à jour. Il s’agit souvent de contribution sur des facettes particulières des données référentielles.

Le référant doit toutefois être le point de centralisation et diffusion de ces mises à jour pour favoriser la cohérence des données référentielles et éviter à chaque consommateur d’être à l’écoute des contributions de chacun.

ref_centralisation

Les modifications d’une donnée sous contrôle d’un référentiel sont diffusées par le référentiel uniquement si cette modification est susceptible d’être utilisée par d’autres applications.

Une exception particulière à cette règle concerne les ensembles d’applications très intégrées entre elles (plusieurs applications d’une suite progicielle exemple) ou l’une joue un rôle de mandataire pour les autres.

Unicité de l’identifiant

L’unicité de l’identifiant a pour objectif de faciliter les possibilités de rapprochement des données référentielles et les correspondances entre les applications.
Une donnée référentielle possède un unique identifiant fourni par le référant. Cet identifiant est la clé qui permet à tout composant du SI (producteur ou consommateur) de pouvoir identifier et distinguer les données référentielles. Ceci n’empêche pas une donnée référentielle d’avoir une codification propre dans chaque composant du SI qui l’utilise. C’est souvent le cas dans un progiciel qui gère ses propres codifications internes mais aussi dans toute application qui a le bon gout de gérer dans son modèle de données les liens avec des clé technique et non les clé fonctionnelles.
Le référentiel est également en charge des gérer les identifiants alternatifs et la correspondance avec l’identifiant standard. Cela permet de gérer les identifiants « historiques » des applications ; le référentiel étant rarement la première brique construite dans le SI ! Ceci est par ailleurs une nécessité pour les applications (en général progiciel) qui ne permettent pas d’utiliser un identifiant externe. L’idée est que le référentiel fournisse à chacun la table de correspondance afin que ces identifiants spécifiques ne contaminent pas tout le SI et soient éliminés dans les couches d’interfaces au plus tôt.

Indépendance du référant

L’indépendance du référant est sans doute le principe le plus délicat à mettre en œuvre. L’objectif est d’amortir le plus possible les impacts sur le SI de l’évolution des applications qui créent les données référentielles. Le référant faisant écran des évolutions et transitions entre les créateurs/contributeurs des données référentielles et les consommateurs.

Pour assurer cette indépendance, la structure de la donnée dans le référant doit être la plus indépendante possible des producteurs et des consommateurs :
• Indépendance de la structure technique : format, type, nommage
• Indépendance de la structure fonctionnelle : règles de gestion spécifiques et modèle conceptuel des données

Cette indépendance est toujours relative et les formats sont souvent teintés des applications créatrices de données référentielles. Les formats pivots purs et parfaitement indépendants n’existent que dans les livres et les organismes de normalisation ou dans de rares cas simples de données largement échangées. Il s’agit donc de trouver le compromis entre les gains à s’aligner en partie sur le format et les concepts de l’application créatrice et la capacité à gérer le remplacement de cette application sans impact trop lourd sur les consommateurs.

Dans le cas ou le référentiel est porté par une application métier de type progiciel, il faut bien prendre en compte les limites suivantes :
• Les consommateurs de ces données référentielles seront contraints par la modélisation et l’évolution propres au métier de cette application. Les capacités d’adaptation (au-delà de simples attributs personnalisés) du progiciel sont donc à étudier de près avant de prendre une telle décision.
• Ce référentiel ne peut être qu’un sous-ensemble des données gérées par cette application. Si ces données sont étendues et que le progiciel n’en gère qu’une partie, les deux options ne sont pas idéales : charger dans le progiciel des informations qu’il ne gère pas, au risque de l’alourdir, pour maintenir son rôle de référentiel, ou bien créer un second référentiel pour ce nouveau périmètre de données.

Ce raccourci, qui consiste à s’appuyer sur un progiciel métier comme référentiel, est souvent une bonne option pour les SI de petite taille ou bien complètement structuré autour d’un progiciel intégré qui couvre la majorité des métiers de l’entreprise. Cela est toujours plus simple à mettre en œuvre et le couplage aux formats des données référentiels n’a que peu de conséquences pour les SI déjà entièrement modelé autour d’un progiciel.

Mise sous contrôle d’une donnée référentielle

La mise sous contrôle d’une donnée référentielle a un cout et toutes les données référentielles ne nécessitent pas autant d’attention.

ref_controle

En première approche, il est souhaitable de mettre une donnée référentielle sous le contrôle d’un référentiel quand au moins une de ces conditions est remplie :
• Quand elle est produite par plus d’une application
• Quand elle est consommée par plus d’une application
• Quand les fonctions à valeurs ajoutées du référentiel (historisation, gestion à date etc.) sont souhaitées

Conclusion

Ces principes ne sont qu’une ébauche qu’il convient d’adapter à chaque contexte (taille du SI, présence ou non d’un ERP jouant un rôle de centre de gravité…) et à chaque donnée référentielle (niveau de diffusion, multiplicité et stabilité des sources etc,). Le référant, point de vérité de la donnée référentielle, se doit de posséder plusieurs qualités et fonctionnalités pour justifier son existence. Celles-ci seront développées dans le prochain  article de cette série.

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.

Urbanisme des référentiels – partie I

Ce billet a pour objectif de présenter la vision d’enioka sur l’urbanisme des référentiels. Il vise à expliquer le rôle et l’intérêt d’un référentiel et comment celui-ci peut s’intégrer dans les projets d’évolution du SI. Il s’agit du premier billet d’une série sur les référentiels. Il aborde plus spécifiquement la définition de ce qu’est une démarche de gestion des référentiels (ou MDM : Master Data Management). De prochains billets traiteront des sujets suivants :

  • Ce que n’est pas une démarche référentielle et les difficultés d’une telle démarche
  • Les principes d’urbanisme des référentiels
  • Les fonctionnalités attendues d’un référentiel

La problématique des données de référence

Les données de référence du SI (clients, produits, fournisseurs, organisation…) sont très souvent créées par les applications de gestion de leur domaine respectif (gestion de la relation client, gestion commerciale,
comptabilité, ressources humaines…). Ces données sont également utiles à toute autre application du SI qui manipule des données opérationnelles s’y référant (une commande ou stock référence un produit par exemple).

Les données référentielles sont ainsi souvent échangées conjointement avec les données
opérationnelles. Le cycle de vie de ces données de référence n’est pourtant pas toujours aussi simple : enrichissement par des applications tierces, contradictions entre plusieurs domaines du SI sur la forme et la nature d’une donnée référentielle, besoins de réconciliations entre plusieurs créateurs de données référentielles, workflows de validation, besoin de contrôle de cohérence… Ceci est d’autant plus flagrant dans les SI distribués dont la colonne vertébrale n’est pas très fortement structurée par une application de gestion interne ou un ERP « tout en un ».

Sans une démarche adaptée, la gestion de ces données de référence devient, pour un SI d’une certaine taille, une problématique complexe dont les conséquences les plus visibles sont :

  • La multiplication des interfaces et des formats représentant les mêmes données,
  • Un manque de traçabilité et de cohérence des données,
  • Des difficultés de réconciliation entre les données de transaction d’applications qui n’utilisent pas les mêmes référentiels ; ceci est particulièrement visible au niveau des systèmes décisionnels,
  • La propagation mal maîtrisée de notions spécifiques d’un progiciel.

Face à cette problématique, structurer les données de référence du SI, leur cycle de vie et leur gestion devient un enjeu fort pour l’urbanisme du SI afin d’en conserver la maîtrise. L’objectif d’une démarche référentielle est de répondre à cet enjeu.

Qu’est-ce qu’une démarche référentielle ?

Une démarche référentielle vise la mise en œuvre d’une gestion des données référentielles au sein du SI. Il ne s’agit ni de la simple mise en œuvre d’un outil ni d’incantations ou de recueil de bonnes pratiques. Il s’agit d’une
démarche globale, transverse et continue qui change la manière de gérer les données référentielles à tous les niveaux du SI, de l’urbanisme à la conception des applications. Une telle démarche a pour objectif de :

  • matérialiser des principes d’urbanismes,
  • concentrer des données et des règles de gestion,
  • mettre en œuvre des processus et des outils de gestion des données de référence.

Une matérialisation des principes d’urbanismes.

Une approche référentielle a pour objectif de matérialiser les principes d’urbanisme autour des référentiels d’entreprise qui sont partagés entre les applications, et de participer au découplage des applications entre elles. L’objectif est d’avoir une vision fédérée des référentiels sans que chaque
application ait à connaître quelle application gère quel élément de référentiel.

Une approche référentielle doit s’appuyer avant tout sur une cartographie des données de référentiel, et l’identification de la ou des application(s) maître(s) de chaque donnée de référentiel, selon :

  • Chaque facette du référentiel (i.e. groupe d’attributs/relations d’une donnée de référentiel – par exemple : facettes budgétaire, structuration de l’offre, achat, logistique, stock, etc.),
  • Chaque élément d’organisation de l’entreprise (certaines données peuvent être partitionnées en fonction de l’organisation de l’entreprise, et avoir des niveaux de partage variables – (exemple par filiale commerciale, par business unit),
  • Chaque étape du cycle de vie de la donnée de référentiel (ex. pour un produit : pré-référencement, référencement, commercialisé, retiré).

Une concentration des données et des règles de gestion

Une approche référentielle s’appuie sur une concentration des données et des règles de gestion des données référentielles. Ce point de concentration sert de fédérateur à toutes les applications et « orchestre » le partage de l’information entre elles au fil des évolutions des référentiels.

Enfin, un référentiel gère structurellement la cohérence de l’information de référentiel
au sein du SI et sa dimension temporelle. Cela s’appuie notamment sur les notions de statuts et de dates d’effet des modifications apportées aux référentiels.

La mise en œuvre de processus et d’outils de gestion des données de référence

Une démarche référentielle se concrétise par la mise en œuvre de processus et d’outils de gestion des données de référence. Une application de gestion des
données de référence, bien que centrale dans le SI, n’est pas nécessairement unique, mais au contraire peut être partitionnée par domaine ou par entité afin de refléter des particularités d’une données (par exemple la donnée client) ou bien d’apporter une souplesse tactique lors de l’urbanisation d’une partie du SI.

Par ailleurs une application de gestion des données de référence n’est pas pour autant nécessairement perçue par les utilisateurs métier du SI. Il est très souhaitable que la gestion de chaque élément de référentiel soit déléguée à l’application légitime pour le faire à chaque fois que cela est possible.

Conclusion

Cette définition d’une démarche référentielle pose les bases de notre démarche. Nous verrons dans un prochain article les risques et difficultés à adopter une telle démarche.