BY PASCAL ANTHOINE, DIRECTOR OF ENTERPRISE INFORMATION MANAGEMENT PRACTICE, MICROPOLE
« Alors que s’ouvre ce matin le Forum MDM 2.0 organisé par Micropole, je me souviens qu’il y a presque 10 ans, je mettais en œuvre mon premier référentiel produit basé sur une solution spécialisée. Passés les premières réticences liées à l’utilisation même de l’anagramme MDM, les années et les nombreux projets sur des domaines aussi larges que les produits, structures et organisation, nomenclatures, employés, fournisseurs, clients… J’ai aujourd’hui acquis une vraie compréhension de la signification profonde du MDM, et la certitude que ce qui n’était au début qu’une vague technologique de plus est parti pour durer. En voici les principales raisons, et quelques conseils essentiels pour réussir ce que je compare au quotidien à une course de fond, tant la mise en place d’un projet de MDM, lorsque l’on ne maîtrise pas ses enjeux et subtilités, peut parfois s’avérer complexe ».
Au-delà d’une bonne maitrise des solutions du marché, toutes plus ou moins basées sur des approches similaires, c’est indiscutablement dans la réponse aux enjeux métiers que réside le cœur de la problématique du MDM. Le véritable succès d’un projet de MDM se mesure en effet dans l’apport de valeurs en termes de nouveaux services ou d’informations que va engendrer la mise en place d’une bonne gouvernance des données clients, fournisseurs, produits, ou autres données de référence.
The preparatory phase is essential
The identification of value contributions must be addressed during the pre-project phase, which is quite complex to tackle without the enlightened support of a domain expert. At this stage, the difficulty lies in identifying and projecting the benefits that an MDM approach will bring to the company's businesses, even though paradoxically this solution will often remain invisible to the vast majority of its users. Fortunately, these benefits are numerous, as long as we know how to identify them, personalize them so that each business department can find its way around, and make them understandable to decision-makers.
Throughout the project, and then during the change management phase, this value contribution must be regularly validated and closely monitored, in order to be able to demonstrate that the project has achieved its objectives and resolved the initial problems. Indeed, users tend to quickly forget the problems that have been solved...
Avoiding the pitfalls of implementation
Once the project has been agreed upon, the race to completion begins and the transformation of the promise into a shared success between business and IT teams. Here are some tips to avoid the most common obstacles:
- Premièrement, on ne le rappelle jamais assez : un projet MDM n’a de valeur que dans le cadre d’une logique d’intégration avec le système d’information existant ou futur ! Se lancer dans un projet MDM sans aborder le rôle primordial de la plateforme d’échange n’est tout simplement pas possible. Cette étape est réellement cruciale ; autant donc se donner les moyens de la passer le moins difficilement possible. Il faudra en effet être bien outillé pour ensuite interfacer des systèmes plus ou moins récents, plus ou moins connus et documentés par les équipes, avec un niveau de qualité des données parfois surprenant, sachant qu’aujourd’hui bon an, mal an, le « business se fait !».
- Another point: managing the volume of reference data exceeding ten million records in synchronous hub mode is a real challenge! This information may come as a surprise when you hear the impressive promises made by all the publishers about the data volume management capabilities of their solutions.... What is not said is that in order to respect the adage that in real projects (and not benchmarks) the implemented models should be as "business" and "business agile" as possible, there is a tendency to standardize them as much as possible... This makes access to a group of business data more atomized, and/or therefore more complex, and leads to much longer response times. Let's bet that the expected arrival of solutions based on "Big Data" oriented storage models will quickly become an essential criterion in the choice of an MDM solution.
- Let's not forget theabusive use of "customizations" on MDM solutions, which make version changes complex. These specific development needs are often linked to a misuse of the solution. If there is a need for excessive customization, you should ask yourself whether the data you are working on is actually reference data.
- Finally comes the final stretch, the judge of all MDM projects with a significant volume of data: data recovery and repository initialization. If not properly prepared, this last step can be long and difficult. Hence the importance of identifying this project as a real project in its own right, with its own particularities: its scoping phase (only take on what is strictly necessary), its profiling phase, with or without tools, of the quality of existing sources, etc.
Once all of these steps have been successfully completed, the satisfaction of having quality, unified, synchronized, auditable, versioned data with a controlled life cycle finally arrives. This reliable and solid data base is now the basis for all business intelligence and application projects, which are real factors in accelerating business performance.
MDM projects are certainly specific and complex, but once the finish line is reached, the benefits are undeniable. The information system is finally based on a foundation that simplifies its evolution, allowing for greater reactivity and effectively supporting the company in its growth and differentiation strategy in its market.
