MDM Success Mantra: Be Holistic, Be Agile
Most of us working in this area of information management know that MDM implementations have a high failure rate. According to a study, only 24% MDM programs end successfully. There are many reasons why these projects sink or don’t deliver what was initially promised. Poor management, lacks of organization support, unclear objectives are some of the common reasons to blame.
I have been helping customers with MDM implementation for almost a decade now. Keeping aside aforementioned reasons, my experience has shown me that there are two key organizational traits that trigger failure.
The number one reason is, the absence of a holistic approach to MDM. Many organizations think implementing MDM in a silo environment, purely as a technology endeavor is a good way to go. But as most of us know, this approach as often proved to be catastrophic.
Second important reason for MDM failure is the missing agility, the inability of organizations to adapt to the change. MDM requires a nimble methodology, which helps in looking at data quality issues not just as an afterthought, but also to fix the complications in an incremental and iterative manner.
Being Holistic
MDM implementations are unique in that they are not run in a silo setting delivering value to only a department or a small business area. MDM impacts large area of an organization. As you start consolidating master data records, which have multiple touch points and application specific usage, you soon will realize that you not only need technology, but also require changes to the way people and processes use master data.
Being holistic is about being business driven.Being holistic is about being business driven. Implementing a solution to address a specific problem occurring in a business function is a great way to start MDM. At the onset this might sound tactical, but the strategic aspects can happen in following ways and help you implement MDM holistically.
- As you plan to integrate master data from different sources, ensure you have done systematic data discovery process. This allows you cross check your data with your business rules and accordingly tune your transformation layer to ensure clean data gets loaded to MDM.
- Every entity and data element housed in MDM should go through strict standards and quality check process.
- Master data should be managed under your organization’s data governance umbrella with focus on stewardship, accountability and clearly defined roles and responsibilities.
- Different sources of master data such as order processing, customer service, billing etc. treat data in their own unique way resulting in lack of consistency. The data quality and integration effort should focus on applying standard rules to bring the data to a common, agreeable, enterprise standard structure.
Many organizations are still looking at MDM implementation from a purely infrastructure and technology standpoint. This has to stop and the only way to achieve that is to bring the business leaders to the table. As many of my blogger friends and analysts have been saying – always have the MDM owned by the business, backed by strong data governance practice with primary focus on improving the quality of master data.
Being Agile
Being agile is about doing things in small chunks (phases or sprints) with a vision on bigger picture. Sounds like a key missing aspect of an MDM implementation isn’t it?
In reality, agile implementation style offers more. Agile is about doing things quickly (and failing fast) so we learn from it. This works perfectly with the data management efforts where the chance of failures is high. You want to try different approaches, which are precise and short to see if they deliver expected result. And if you know that a particular approach is not a right option, you take a different route.
One of the examples I can provide you here is the de-duplication process which is a key feature of MDM. Although the matching & merging rules change across organization we implement MDM, I spend couple of weeks (a sprint) with customers to use out of the box rules delivered with our MDM product to identify and remove duplicated records. One key advantage of this is, these rules are tuned & enhanced with years of experience. Most of the time, these exercise prove to be very beneficial as the rules we are providing with product turn out to be right fit (with minor tweaks off course), many times much better than what clients tend to come up with on their own.
Agile approach helps you achieve your enterprise master data management goals in a sustainable way Agile provides a lean approach to MDM implementations. It helps you achieve your stated enterprise master data management goals in a sustainable way. With this approach, you can greatly increase your chance of success.
One of the things we don’t often hear is the aspect of technology being a reason for MDM program failure. Tools and technical acumen are sure necessary, but what matters the most is, how your organization approaches MDM culturally. Winning organizations succeed because of their disruptive thinking. They are agile to changes and challenge the norms, which help blur the organization boundaries. This is key aspect of agile and helps you succeed with MDM.
Do you agree? What do you think are the success factors for MDM? I would love to hear your feedback.
Image courtesy of cooldesign/FreeDigitalPhotos.net
COMMENTS
Leave A Comment
RECENT POSTS
Composable Applications Explained: What They Are and Why They Matter
Composable applications are customized solutions created using modular services as the building blocks. Like how...
Is ChatGPT a Preview to the Future of Astounding AI Innovations?
By now, you’ve probably heard about ChatGPT. If you haven’t kept up all the latest...
How MDM Can Help Find Jobs, Provide Better Care, and Deliver Unique Shopping Experiences
Industrial data is doubling roughly every two years. In 2021, industries created, captured, copied, and...
Great article! It reminds me of my data management path, except I would use simpler words, like vision, plans, ideas, values, or methods. Reader might quickly relate to the experience you had: changes do take time and being agile is what drives us forward: we often need flexible solution, making mistakes and learning from them quickly is essential to business in these fast paced times. Holistic view allows a clear foundation to be set for service or function, and it eliminates doubts in many ways when solving day-to-day or bigger challenges. And of course, communicate, communicate, communicate.
Great points and well summarized.
It fascinates me that with so much evidence to support these points so many MDM projects still get tossed over the hill to IT an either fail outright or simply become yet another data source of poor quality data.
MDM is a business capability enabled by technology. I talked about this in my post http://blog.masterdata.co.za/2012/11/08/avoid-this-simple-mdm-mistake-and-get-business-buy-in/
I support you belief that MDM must be agile – I used the term incremental.
Don’t get me started on the Data Quality angle….
One client of ours has a customer MDM solution (implemented using a commercial MDM tool) and they have their “single view of the customer” solution – implemented using a commercial EDQ platform. They have the single view project because they cannot trust either the data quality or the matching provided by the MDM stack.
Prashant, Thanks for sharing your opinions. Great article.
Let me add another perspective to this. Success of an MDM project is always defined by its consumers ultimately and if you can apportion the MDM running cost to them, of course with amicable agreement. I mean the departments funding these consumers. For e.g. if a Marketing Platform or an Order Management System uses MDM services, the costing of the turnkey solutions should include apportioned MDM cost. This cost sharing discussion itself brings with it things beyond considerations around sources. Agile methods. Yes fair but logical release goals should be chunked to assist full flow of business processes. This is a planning detail.
DQ issues in MDM inclusive of trust issues rise due to many reasons the key is how sources are standardized. Bad standardization leads to many upstream isses. Agility is required in the lifecycle mgmt of the DQ rules as well.
Prash nice post. Can you give me the reference to the study you cited in the first paragraph? who did it? When?
Thanks,
My experience also support the agile approach to the MDM solution. “Change” is like a cancer. People aren’t fond of the word change, so your point to “Being Holistic” do play a big role of implementing a smooth business process if you would bring all business units on to one table.
Amendments can be doable but achieving “a single version of a truth” would be really hard if doesn’t get the sign off from all parties involved.
My experience also support the agile approach to the MDM solution. “Change” is like a cancer. People aren’t fond of the word change, so your point to “Being Holistic” do play a big role of implementing a smooth business process..
Amendments can be doable but achieving “a single version of a truth” would be really hard if doesn’t get the sign off from all parties involved.
My experience also support the agile approach to the MDM solution. “Change” is like a cancer. People aren’t fond of the word change, so your point to “Being Holistic” do play a big role of implementing a smooth business process..
Amendments can be doable but achieving “a single version of a truth” would be really hard if doesn’t get the sign off from all parties involved.
Interesting post. I have a couple points to add:
1. MDM projects tend to take a long time to implement and get to where they are value adding. Like any long running project, they are subject to organizational, economic or corporate focus changes that occur until the project is live. Any of these can kill a project that isn’t live.
2. MDM’s a foundational system, i.e. it adds value by assisting other systems, not inherently in-and-of itself. Understanding that, especially on a long running project can be a problem.
3. MDM implementations are often expensive, much more expensive than expected. Organizations often have to bring in consultants to do analysis, development and testing. The number of consults tend to grow much more than expected and the organizational structures to manage those consultants also tends to grow.
4. MDM implementations often bring in software and software ecologies that are not well known within organzations. These ecologies layer on top of multiple infrastructure layers (vmware, sans, luns etc) that are not well understood. By this I mean, configuration errors in virtualization layers can effect MDM systems in unexpected ways that are not easy to debug. Especially in large, federated organizations.
5. MDM implementations often suffer during the long build phase. Let me explain. Prior to their starting, situations are reasonably well understood. After they are implemented, problems can be addressed in a disciplined and organized fashion. During the implementation phase, there tends to be a lot of “not well understood” pain. For an implementation that may take between 3 and 18 months, getting from “here to there” may well be prohibitively painful and/or expensive. The details may vary, but the horror show is predictable.
Others may have had different experiences, but that’s a summary of what we encountered during our successful implementation.
Andy
A Briliant article indeed.
The challenge is “Change” in itself, the challenges faced are
1. Adopting the Change
2. Educating and Bringing the right functions from the start of the programme
3. Inheritint the business to appreciate that it is not IT driven but business driven and enabling the respective functions to take right decisions due to MDM solutions.
4. Preparing the business Mind set.
Just a question: What is the reasonable amount of time for Implementing MDM solutions if we think about 3 Major Domains (Supplier, Customer and Material)
regards
Prakash
[…] approach to MDM for a really long time. Our community continuously talks about importance of taking holistic approach mastering data in the form of blogs, webinars and tweets. I believe, our efforts have not gone wasted. While we […]
So would you use Scrum, or Kanban in implementing MDM? Do you have an Agile MDM project plan you could share. I am on a MDM project, Phase 1 we did waterfall and now we’re considering an Agile aproach for the very main points you covered in this article. I am glad I ran across this article to know that Agile is the approach we need to take for Phase 2. Any help is greatly appreciated.
This is such a great blog. you really covered it all. Thank you for sharing such an important information. Hope to get some more information in future also.many more by click here ttp://www.ltecindia.com/