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 reluctance to use the anagram MDM, the years and the numerous projects on domains as wide as products, structures and organization, bills of material, employees, suppliers, customers... I have now acquired a real understanding of the deep meaning of MDM, and the certainty that what was at the beginning just another technological wave is here to stay. Here are the main reasons why, and some essential tips for succeeding in what I compare to a long-distance race, as the implementation of an MDM project, when you don't master its stakes and subtleties, can sometimes prove to be complex.
Beyond a good mastery of the solutions on the market, all more or less based on similar approaches, the heart of the MDM problem lies indisputably in the response to business challenges. The real success of an MDM project is measured in the value added in terms of new services or information that will be 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 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.
