Archives mensuelles : octobre 2012

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.

Le coût des performances

Après une première introduction à la problématique de la performance des SI, il est nécessaire de se préoccuper du coût des performances. La raison pour laquelle il n’y a pas de vérité absolue en matière de performance est que les trois points de vue essentiels à optimiser (le travail à effectuer, le temps imparti et les ressources utilisées) sont à équilibrer par rapport à des critères objectifs. L’un de ces critères essentiel est le coût. Ce n’est sans doute pas le seul critère (il y en a d’autres, comme la qualité de service, qui peuvent influer sur le comportement des utilisateurs ou des clients de manière indirecte), mais c’est en tout cas le plus objectif.

On distingue deux coûts à équilibrer : le coûts des ressources employées et le coût du temps consommé par le SI.

le coût des ressources employées.

Ce volet du coût est le plus simple à mesurer,  même si le plus souvent il ne l’est pas de manière satisfaisante :

  • ni complètement : le coût complet des ressources n’est pas si trivial à évaluer. Amortissement des investissements matériels, coûts de licence des logiciels, maintenance, opérations, coûts indirects de m2 ou de climatisation de  l’hébergement, etc.
  • ni analytiquement : quelle est la contribution de chaque fonction/usage au  coût des ressources ? La difficulté est à ce niveau double : avoir la capacité de tracer l’usage des ressources par les fonctions/utilisateurs et d’autre part discerner ce qui réellement dimensionne les ressources. Par exemple, un système peut être taillé pour supporter une activité transactionnelle de jour très lourde, et du coup, le coût de l’usage des (ou de certaines) ressources pour les traitements batch est sans influence sur le coût total.

le coût du temps consommé par le SI.

Il s’agit du temps pendant lequel les utilisateurs ou l’entreprise  ou les clients attendent ou travaillent à la place du SI. La valorisation de ce coût est très variable selon l’usage :

  • 10 secondes d’attente d’un utilisateur à chaque transaction représente peu si l’utilisateur utilise la fonction une fois par jour, beaucoup plus si l’utilisateur l’utilise
    des centaines de fois. Si très peu d’utilisateurs sont concernés, le compromis peut rester acceptable, surtout si la solution apporte par ailleurs des bénéfices.
  • En deçà d’un certain seuil (< 300 ms pour une fonction interactive par exemple) un gain de temps n’est plus pertinent, et ce surtout si ce gain correspond à une unité
    de travail de l’utilisateur naturellement associée à une rupture de charge (comme le passage à la facture suivante à traiter).
  • Le coût du temps est toujours délicat à valoriser. C’est une notion élastique qui est  souvent liée à l’organisation du travail ou du modèle d’activité de l’entreprise (selon le modèle d’activité, le temps de traitement SI est ou n’est pas un enjeu de compétitivité). Selon les activités il y a ou non des enjeux associés au temps de réponse ou au temps de traitement.
  • Il y a également quelquefois à considérer le coût d’un défaut de service : certains problèmes de performance (notamment lors de pics d’activité) peuvent créer une
    indisponibilité dont les conséquences financières peuvent être très graves.

Pour équilibrer ces coûts, un troisième coût est à prendre en compte : le coût d’optimisation ou d’alignement de la solution pour réduire l’usage des ressources et/ou réduire le temps de traitement. Ce coût est à considérer comme un investissement pour améliorer l’efficacité. L’optimisation suit souvent le principe de Pareto : 80% des
gains sont relativement faciles à obtenir mais les derniers 20% coûtent très chers à obtenir. Il faut donc toujours mesurer la valeur marginale des gains en comparaison des coûts engagés. Et les gains les plus forts ne sont pas toujours à attendre des investissements les plus lourds.

Cette approche de valorisation des coûts (et des bénéfices) du SI est d’ailleurs une approche d’analyse de la valeur qui va bien au-delà de la performance d’une application. Elle devrait s’appliquer comme dans l’industrie aux fonctions offertes par le SI aux utilisateurs comme moyen d’arbitrage des fonctions à implémenter dans le SI.