BY PASCAL ANTHOINE, DIRECTOR OF ENTERPRISE INFORMATION MANAGEMENT PRACTICE, MICROPOLE
" As the MDM 2.0 Forum organized by Micropole opens this morning, I remember that almost 10 years ago, I was implementing my first product repository based on a specialized solution. After the initial reticence linked to the very use of the anagram MDM, the years and numerous projects in fields as wide-ranging as products, structures and organization, bills of material, employees, suppliers, customers... I have now acquired a real understanding of the profound meaning of MDM, and the certainty that what was at first just another technological wave is here to stay. Here are the main reasons why, and some essential advice on how to succeed in what I compare to a cross-country race, given that setting up an MDM project, when you haven't mastered its challenges and subtleties, can sometimes prove complex.
Beyond a good command of the solutions on the market, all more or less based on similar approaches, it is indisputably in the response to business challenges that the heart of the MDM issue lies. The real success of an MDM project is measured in the value added in terms of new services or information generated by the implementation of good governance of customer, supplier, product or other reference data.
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:
- First of all, we can never remind you enough: an MDM project is only valuable if it is integrated with the existing or future information system! Launching an MDM project without addressing the essential role of the exchange platform is simply not possible. This step is really crucial, so we might as well give ourselves the means to get through it with as little difficulty as possible. You need to be well equipped to interface with systems that are more or less recent, more or less known and documented by the teams, with a level of data quality that is sometimes surprising, knowing that today, year in, year out, "business is done".
- 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 these stages have been successfully completed, the satisfaction of having quality, unified, synchronized, auditable and versioned data with a controlled lifecycle finally arrives . All business intelligence and application projects are now based on this reliable, solid data foundation, a real factor 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.
