Archives du mot-clé Urbanisme

Pour un urbanisme concret

L’urbanisme est un gros mot. Après avoir volé le mot architecte au génie civil, pourquoi s’arrêter en si bon chemin ? Au delà d’une définition pas toujours évidente d’un terme très français (les anglo-saxons parlent d’Enterprise Architecture), c’est d’abord beaucoup de théorie… mais un cruel manque de pratique.

L’échec (relatif) de l’urbanisme des SI peut être expliqué par plusieurs facteurs :

  • Les urbanistes sont souvent très éloignés des réalités du SI et des projets. La littérature est plutôt bien fournie… mais délicate à appliquer. La plupart du temps, c’est l’architecture transcendantale qui prévaut, au détriment de l’expérience et la pratique ;
  • Les urbanistes ont en général une faible culture technique qui les poussent à faire du top-down au mépris des réalités techniques. On cherche ainsi un découpage du SI avant tout guidé par un découpage fonctionnel, lui-même calqué sur une organisation ou la représentation à date de la chaîne de valeur de l’entreprise ;
  • La recherche de la cible idéale (et idéalisée) passant par des transformations big-bang (qui se soldent souvent par des big-crash) au lieu de privilégier des transitions douces et flexibles ;
  • Les vraies questions d’urbanismes (nous essaierons d’en poser quelques unes ci-dessous) sont souvent rapidement abandonnées au profit des projets phares des urbanistes : mettre en place un MDM ou un ESB ou les deux à la fois. L‘outil magique comme réponse à un problème…
  • L’intérêt court terme d’un projet (budget, planning et réponse à un périmètre circonscrit) n’est pas toujours compatible  avec la feuille de route d’évolution du SI imaginée par les urbanistes.

L’attitude la plus fréquente face à cela est d’ignorer les urbanistes ou tout du moins ce qu’ils disent et écrivent. C’est ce que font la plupart des directeurs de projets afin de préserver leur projet. On les comprends !

Les urbanistes restent trop souvent dans leur tour d’ivoire et, au mieux, cartographient le SI (à l’échelle 1:1 de préférence !), mais n’ont pas de réelle influence sur l’organisation du SI.

À défaut d’enlever les taches, au moins, les urbanistes n’abiment pas le linge

L’alternative est de promouvoir un urbanisme plus simple, plus concret et plus appliqué. Loin des salons et plus près des projets et des architectes applicatifs et techniques. Esquissons les contours ce que pourrait être cet urbanisme concret.

À quoi sert l’urbanisme ?

Dans ce contexte, on peut se demander à quoi sert l’urbanisme… Les besoins sont pourtant véritables, et répondent à des problématiques très concrètes. On peut distinguer quatre objectifs majeurs :

  1. Donner une visibilité globale du SI à tous les acteurs pour améliorer leur efficacité collective en explicitant les principaux processus, fonctions (hiérarchisées et regroupées), les applications, les données et les flux du SI.
  2. Permettre au SI d’obtenir des qualités globales et transverses sur différents plans :
    • Alignement aux besoins métier de « bout en bout »
    • Cohérence transversale des données et des processus
    • Efficacité dans la durée
    • Agilité aux évolutions
  3. Faire contribuer les projets à la dynamique d’ensemble en orientant les choix projets vers des décisions cohérentes.
  4. Aider à arbitrer les choix ou décisions en identifiant toutes les options, avec une meilleure visibilité sur leurs conséquences, court/moyen/long terme.

Il faut faire des choix…

L’urbanisme n’a pas de réponse absolue à des questions absolues. La plupart du temps les choix d’urbanisme sont à faire entre plusieurs options réellement possibles.

L’urbanisme vise à remettre les choix unitaires des projets en perspective de la globalité du SI. Les choix principaux d’urbanisme jouent typiquement sur :

  • Le niveau de partage des processus et des données entre organisations
  • La décomposition du SI en applications
  • L’allocation des fonctions aux applications
  • Le niveau de partage des applications entre organisations
  • Les processus de gestion et de diffusion des référentiels
  • La duplication (ou non) d’informations entre applications
  • Les flux d’échange et/ou de synchronisation de données entre applications

Les choix d’urbanisme ne sont ni des choix fonctionnels, ni des choix d’organisation, même s’il peut il y avoir un lien.

… guidés par certains principes…

Les choix d’urbanisme doivent pouvoir s’appuyer sur des règles d’urbanisme (ou plus généralement SI) partagées, compréhensibles et largement reconnues. L’objectif de ces principes est d’expliciter les règles souvent implicites qui gouvernent le fonctionnement du SI.

Le SI peut ne pas avoir d’urbaniste, il y a toujours un urbanisme. Plus ou moins spontané, plus ou moins anarchique, mais le résultat est là : les projets construisent et transforment des briques applicatives et techniques qui façonnent le SI. Le rôle de l’urbaniste est de mettre en lumière ces règles et principes, les rendre visible, faire prendre conscience aux parties prenantes des clés d’arbitrage.

Certaines de ces règles sont d’ordre générales et applicables à tous les domaines, notamment :

  • Règles de découplage et de modularité du SI
  • Règles de gestion des référentiels
  • Règles d’intégration des applications

D’autres règles résultent de choix d’urbanisme spécifiques sur des périmètres fonctionnels qui peuvent être plus variables dans le temps, par exemple :

  • Règles définissant les objets structurants du SI (données, domaines, etc.)
  • Règles identifiant les applications maîtresses des principaux objets du SI
  • Règles spécifiques entérinant des arbitrages passés

Ces règles ne sont pas absolues et peuvent, pour des raisons tactiques ou stratégiques, être enfreintes. Il s’agit de guides plutôt que de limites. Enfreindre ces règles indique simplement qu’il faut être en mesure de justifier et motiver son choix.

Enfin, et surtout, ces règles doivent s’enrichir et évoluer avec le SI et son environnement.

… et bâtis sur des modèles

Pour raisonner efficacement sur le SI et être en mesure de l’appréhender de manière globale, il faut s’appuyer sur un modèle simplifié du SI. Ce modèle traite de plusieurs plans dont les principaux sont :

  • Plan métier : quels sont les processus métier ? quelle est la chaîne de valeur de l’entreprise ?
  • Plan fonctionnel : quels sont les fonctions rendues par le SI pour supporter ces processus ? Comment organise-t-on ces fonctions en domaines ? Quels sont les objets métiers manipulés ? Selon quelles facettes ?
  • Plan applicatif : comment sont implémentés les fonctions du SI ? Quelles sont les applications du SI ? Comment sont-elles déclinées sur un périmètre ? Quelles données échangent-elles ?

Ces modèles doivent avoir des représentations et une structure permettant de communiquer sur l’organisation du SI à tous les acteurs impliqués dans sa transformations, du développeur au management, aux métiers en passant par les équipes de production.

 

Projets et urbanisme

L’urbanisme devrait être le plus possible porté par les projets. Ces derniers restent les meilleurs vecteurs de transformation du SI et donc de l’évolution de l’urbanisme du SI.

Souvent, les grands projets portent intrinsèquement des transformations structurantes du SI.  L’urbaniste doit savoir surfer sur ces grandes évolutions du SI.

Il peut parfois être nécessaire d’investir dans le cadre d’un projet métier au-delà de ses besoins propres et court terme pour constituer un bien commun plus large.

Une approche d’urbanisme doit favoriser ces investissements sans plomber les projets.

Il s’agit alors d’entrer dans un cercle vertueux à chaque projet : l’approche d’urbanisme sera d’autant plus efficace si la transformation s’opère étape par étape, du moment que ces états intermédiaires sont suffisamment stables. Il ne s’agit donc pas d’imposer des arbitrages par une réponse absolue, mais de remettre en perspective les choix des projets dans la globalité du SI : il convient alors de convaincre et de séduire les projets du bien fondé de cette démarche. C’est finalement une approche d’amélioration continue, avec ses bons côté (les améliorations des uns profitent aux autres projets et vice versa), mais qui possède son pendant vicieux bien connu : chaque projet porte alors le fardeau des prédécesseurs.

Quelques exceptions toutefois : il peut être nécessaire, à moyen/long terme, de faire des investissements transversaux que les projets métier ne peuvent pas toujours (planning…) ou ne doivent pas (indépendance…) porter. Par exemple des services d’intégration transverses, des référentiels, des services décisionnels…  Idéalement, ces investissements doivent pouvoir être valorisés par des projets métier bien identifiés qui en seront les clients et bénéficiaires à chaque étape. Il ne s’agit donc pas d’être en dehors des projets mais transverse aux projets.

Comment faire ?

L’urbanisme est avant tout un processus de réflexion transversal. Ce processus a besoin d’éléments partagés qui supportent de manière opérationnelle les choix :

  • Un référentiel qui décrit l’existant du SI (modèle)
  • Une cible et une trajectoire d’évolution qui définissent les orientations d’évolution du SI à 2/3 ans
  • Un guide d’urbanisme qui explicite les principes d’urbanisme partagés et les choix faits qui expliquent la trajectoire
  • Une organisation opérationnelle qui permette aux projets de construire leur trajectoire en cohérence avec celle du SI et aux responsables de domaines (métier et applicatif) de piloter les évolutions SI et amender la cible et la trajectoire

Il est essentiel que les urbanistes acquièrent non seulement une bonne compréhension du métier mais aussi de la technique (développement, système, exploitation…). Sans cette clé technique de compréhension du SI, le dialogue avec les équipes de développement et de production restera en grande partie stérile et les plus belle idées d’urbanismes conduiront à des catastrophes.

Le bon sens est trop souvent négligé par des urbanistes, on les caricature souvent comme des monarques un peu éloignés des réalités du SI. Au delà de toutes les méthodes, démarches, modèles d’urbanismes etc., il faut savoir viser la simplicité et faire preuve de pragmatisme. Les SI actuels sont déjà des monstres de complexité. Un urbaniste et architecte talentueux ne se distingue pas en construisant un énième composant tapageur dans le SI composé de toutes les dernières technologies ou principes à la mode mais en construisant quelque chose de simple, sobre et fonctionnel. La parcimonie n’est pas souvent à la mode chez les urbanistes, c’est pourtant un principe essentiel.

Pluralitas non est ponenda sine necessitate (G. d’Ockham)

En définitive, on voit que l’urbanisme tient plus à l’urbaniste qu’aux théories, concepts et autres éléments de littérature pourtant nombreux (Zachman, Togaf…) qui n’ont pas vraiment changé le monde, au contraire. C’est un constat amère d’un coté (tant d’énergie et de complexité pour en rester aux balbutiements) mais également porteur d’espoir : tout reste à construire, à reconstruire et à transformer.

Mesdames et messieurs les urbanistes, mettons nous au travail !

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.