02.10.14

Avis d'Expert

Comprendre la dimension organisationnelle du Master Data Management (MDM)

  • #Data Intelligence
  • #Information Management

Le Master Data Management (MDM), ou gestion des données de références, s'est beaucoup développé ces dix dernières années, mais est encore trop souvent abordé comme un projet purement « IT ». Or en redéfinissant les modes de gestion et de contrôle de l'information, le MDM a des incidences sur l'organisation. La prise en compte de celles-ci dès la phase amont du projet conditionne l'adhésion des acteurs, l'alignement des pratiques opérationnelles et les gains d'efficacité attendus.

 

Lire la version PDF

Le MDM a pour but d'organiser la gestion des informations stratégiques de l'entreprise (clients, produits, fournisseurs, etc.) partagées par différentes unités et/ou applications. Ces données, dites 'de référence', servent de base à des processus communs, à la production de reportings de qualité, au lancement de nouveaux services (sites Web) et à la mise en œuvre d'innovations et de stratégies commerciales (omni-canal). Souvent perçu comme un élément supplémentaire du Système d'Information (SI) corporate, au même titre qu'un CRM ou undatawarehouse, le MDM, véritable charpente des données de l'entreprise, a pourtant un impact organisationnel conséquent. Hormis certaines de ses formes primitives limitées à des enjeux techniques, il possède en effet un signe distinctif : il est, par nature, centralisateur.

Par le biais d'une définition commune de l'objet d'une entreprise (ex : un produit, dans sa vue corporate, définie d'une manière précise), le Master Data Management implique d'imposer une vérité au reste de l'organisation et des systèmes d'information (un MDM est d'ailleurs appelé 'point de vérité'). Lancer une démarche MDM, aboutissant à la construction et l'utilisation d'un référentiel, c'est engager de facto une démarche de centralisation pouvant aller à l'encontre des schémas organisationnels établis et des pratiques en place.

Prenons le cas de la gestion des données clients. Un groupe dans le secteur du prêt-à-porter, composé de filiales plus ou moins concurrentes, souhaite fiabiliser ses données clients. Celles-ci sont récupérées de diverses manières : de la caisse des magasins aux saisies web, en passant par des formulaires papier. Le MDM apporte des solutions pour compléter les adresses manquantes chez les uns, récupérer et valider les numéros de téléphone dont disposent les autres, et regrouper le tout en une fiche client unique. Mais, compte-tenu de la concurrence entre les entités, induite par l'organisation, la question de l'échange et du partage des données clients entre celles-ci peut être explosive.

Organisation et architecture : les deux faces d'une même pièce

De par son caractère centralisateur, le MDM implique notamment de réfléchir à ce qui doit être réalisé par les fonctions corporate ou bien par les fonctions locales de l'entreprise. C'est, entre autres, cette réflexion qui conditionne le choix de l'architecture MDM - encore un terme souvent mal interprété, qui peut paraître éloigné des préoccupations des métiers et limité à des problématiques techniques. C'est pourtant tout le contraire et voici pourquoi.

L'architecture MDM oscille entre consolidation d'information et centralisation. Dans le premier cas, les interactions avec les acteurs de l'entreprise sont plutôt limitées, voire inexistantes. Dans le second, le référentiel se positionne comme outil de saisie et potentiellement de contrôle d'où des interactions généralement importantes avec les métiers.

Cependant, même si l'impact organisationnel est différent entre ces deux modes de configuration, la dichotomie fonctions centrales/fonctions locales reste très présente. Décider du degré de liberté qu'auront les détenteurs des vérités « locales » vis-à-vis du point de vérité corporate est souvent un exercice délicat. Qui aura le droit de saisir et gérer au quotidien les données de référence ? De les contrôler et potentiellement d'invalider certaines créations (produits, fournisseurs...) ? Les unités locales pourront/devront-elles partager certaines informations ? Ces questions pratiques appellent des arbitrages susceptibles de remettre en cause les relations, responsabilités et modes de fonctionnement préexistants.

Illustrons ceci par une entreprise du secteur industriel qui commercialise des produits fortement réglementés. Organisée sous un modèle de filiales relativement indépendantes, les unités locales ont à la fois du mal à dégager des ressources pour pouvoir se conformer à la réglementation grandissante et souhaitent garder leur liberté de mise sur le marché des produits. Un projet de référentiel produits, adossé à une expertise réglementaire forte proposée par le siège, devra subtilement prendre en compte ces deux aspects afin de ne pas provoquer de résistances internes trop fortes et mettre en péril l'enjeu de fiabilisation porté par l'entreprise.

 

La dimension organisationnelle, parent pauvre des projets MDM

L'organisation, comme science de gestion, n'a pas de théorie unifiée. Selon les points de vue et les penchants des chercheurs en la matière, les modèles d'analyse produits font un focus plus ou moins fort sur certains aspects organisationnels. Par exemple, si les défenseurs de la théorie de l'Agence décrivent l'organisation comme un assemblage de contrats (entre décideurs et actionnaires, entre patrons et salariés, etc.) d'autres, comme James March1, Henry Mintzberg2 ou encore Michel Croziermettent l'accent sur les aspects politiques et les réseaux d'influence des acteurs entre eux. De son côté, Masahiko Aoki4 propose de comparer l'efficacité de modèles d'organisation sur la base de leur gestion de l'information.

Longtemps, les projets MDM, et informatiques de manière générale, ont été peu réceptifs à ces concepts. Progressivement, l'accompagnement organisationnel de l'intégration de solutions logicielles s'est étoffé. Pourtant, dans le langage courant des projets MDM, le terme 'organisation' reste souvent synonyme d'organigramme et cantonné à la manière de coordonner le projet et la gouvernance encadrant la solution logicielle choisie. La notion 'gouvernance' est, quant à elle, aussi assez trompeuse : par son emploi, nous réduisons souvent l'organisation à des procédures et à des comités de pilotage. Les entreprises dans leur majorité, dans le rush opérationnel, ont tout au plus eu le réflexe de définir des processus et workflows de gestion de la donnée de référence et d'identifier des administrateurs. Or le risque d'une telle approche est de passer à côté de ce qu'est vraiment l'organisation lors de la phase d'étude et d'opportunités d'une démarche MDM vis-à-vis des décideurs et des différentes parties prenantes.

Imaginons une société de trading de matières premières. Ses traders, répartis dans le monde entier, travaillent avec des contreparties qui peuvent faire défaut. Sans vue commune sur ces tiers, chaque zone géographique se réserve le droit de contractualiser avec qui bon lui semble. La mise en place d'un référentiel corporate des contreparties, dans l'objectif de diminuer le risque de défauts de paiement, implique une limitation des opportunités/du champ d'action de chaque zone. Un département « Risques » corporate pourra utiliser le référentiel pour bloquer des opérations que voudraient réaliser certains traders (eux-mêmes payés sur ces opérations...) avec des contreparties connues dans d'autres zones géographiques pour être « à risque ».

Ne pas engager de projet sans évaluation organisationnelle

Ces exemples illustrent les difficultés organisationnelles auxquelles un métier ou un support projet peut-être confronté lors d'une démarche MDM.

En premier lieu, l'organisation doit être appréhendée dans son ensemble. Quel est son style général de gestion de l'information : anarchique, féodal, fédératif ?5 Est-ce un état souhaité ou à améliorer ? Quels projets précédents se sont heurtés à ce style de gestion, ou au contraire en ont bénéficié ?

Ensuite, une bonne compréhension des enjeux des parties prenantes est nécessaire, notamment en termes d'autonomie et de responsabilité, afin de concevoir le bon design organisationnel, à savoir une 'centralisation intelligente'. Ces parties prenantes doivent s'engager et comprendre la nature de leur engagement : l'organisation va changer, quelle place souhaitent-elles y prendre ? Si l'organisation à mettre en place pour le build (projet) est souvent l'unique objet de discussion, il peut aussi être nécessaire de présenter celle pour le run (fonctionnement de routine). Les acteurs peuvent vouloir analyser au plus tôt les gaps organisationnels.

Une attention particulière doit être portée sur la cellule administratrice (à terme) de la donnée de référence. Quelles ressources lui affecter, en particulier humaines ? Cela va-t-il nécessiter de regrouper des compétences en l'état actuel dispersées dans différentes entités ? A qui la rattacher ? La cellule sera-t-elle cantonnée aux aspects SI/outil, à une simple coordination métier ou composée de personnes avec de vraies compétences métier, capables de prendre des décisions en connaissance de cause ?

Enfin, il faut garder à l'esprit que, comme la Business Intelligence, le MDM est la pratique et l'outil d'une population : fonctions support & métier corporate. Ceci n'est pas anodin dans la manière de 'vendre' le projet en interne et, une fois l'infrastructure et les processus techniques pertinents mis en place, garantir la pérennité de la démarche.

1 March, J. G., Simon, H. A. (1958). Organizations, John Wiley & Sons Inc, New York.

2 Mintzberg H., (1990). Le pouvoir dans les organisations, Paris, Les Éditions d'Organisation.

3 Crozier M., (1977). L'acteur et le système, Le Seuil, Paris, Coll Sociologie politique.

4 Aoki M., (2000). Information, Corporate Governance, and Institutional Diversity: Competitiveness in Japan, the Usa, and the Transitional Economies, Oxford University Press,

Oxford.

5 Thomas Davenport, dans son article "Information Politics" (Sloan Management Reviaw, 1992) décrit des modes que l'on retrouve couramment dans les organisations.

Télécharger