Understanding Enterprise MDM
Ever since we started to use data to make sense of the ‘workings’ around us, there has been awareness and initiatives around classification of such data as master data and transactional data. Over the decades, the volume of data has grown exponentially, architecture approaches has varied to support such volume and the distributed nature of uncontrolled growth. This has resulted in the need for ‘putting the house in order’ when it comes to data, for the analytics solutions to be effective. The one, simple rule to remember in technology is — garbage in, garbage out & there is no silver bullet. With the size of organizations and the various domains that are in play, it is futile to expect a centralized team to put the house in order — add to the complexities of traditional, purist approach versus contemporary, search driven approach. This has also resulted in a situation where the individual system owners have taken the responsibility of cleaning up and mastering the data domains that is persistent in their systems, with the available business know-how and the available toolset — primarily related to the ERPs
This is simple, natural evolution and there is nothing wrong about it. Organizations have done what they want, with the best of their ability, within the available constraints and the resources they have to extract the best out of it. The role of data stewards that initially dwindled with the large scale ERP onslaught (early 2000s) started becoming more and more prevalent when the importance of clean data was recognized by the policy makers. What was originally defined as the ‘custodians of data in the systems’ were expanded to areas that supported digital and social media presence including responsibilities covering content research and interaction design. By then, we have reached a point where the value of data assets are starting to get recognized and organizations have become serious about learning how to use it! This has the potential to disrupt established business models and drive major product innovations.
At the point when the CXO members of the organization starts to realize the potential and opportunity to invest in data (putting their money where their words are…), organizations start off with an enterprise level initiative of information management and data management. For an enterprise level data initiative to be successful, this must be a business led initiative and not a technology driven initiative. It has to synchronize decisions between business strategy, operational stakeholders and execution procedures with the technology enabling them with the right platform and tools. One of the key components of this strategy is an enterprise level MDM (Master Data Management) initiative. A Gartner survey in 2017 had concluded that more than 80% of enterprise level MDM initiatives fail because they are attempted as a technology initiative with marginal skin-in-the-game by the rest of the organization.
In my personal experience, a key aspect that comes into play, especially in the MDM space is the dynamics that develops around the siloed MDM efforts that has been in progress for a while before the enterprise level initiatives have kicked off. Some corporate functions viz HR, by virtue of business consolidation, would already have a matured discipline whereas few other domains like Chart of Accounts are difficult; thanks to the global organization design against the statutory design of regional entities. The more matured functions or domain owners may start feeling frustrated with the speed (or lack of speed) through the learning cycles where they have already been, whereas the other domains might need business re-alignment and explicit guidance to even start ‘thinking at an enterprise level’.
One of the frequent question I have faced, particularly from the group that is ahead of the learning curve is: — We are already doing MDM & we are ahead of the game. So, what are you going to do over and above?
Before answering this, there are a few facts that we need to consider
- Not all domains are worth mastering at an enterprise level because of insufficient ROI
- Pan organizational visibility of domains may lead us back to the drawing board, teams must be prepared for that
- Democratization of mastered domains into a common catalog for consumption (enabled via APIs) is important at an enterprise level for adoption and increased ROI
At a very high level, mastering of domains must happen at a minimum of 3 levels within the organization with seamless upward and downward integration of data flow.
- Platform / Application / ERP
- Corp Function or Business Family
- Enterprise
Each of these levels are not a substitute for each other, instead will complement each other. Once we understand the differences, the basic premise of a competition goes away, and collaboration falls in.
To understand the concept better, lets look at this in terms of a simple example.
Now, you could draw the correlation that the more people who can afford home cooked dinner, the less reliance on the next levels making it easier to consolidate information and focus on the areas that needs to be focused on. Similarly, much robust processes established at the entry points and the subsequent steps as you go up in the hierarchy, it pays into the success of the enterprise level initiative by filtering out the mess and feeding the relevant characteristics of the domain. And the key take away is that… you wouldn’t stop cooking dinner at home (if you can afford it) for the reason that there are food stamps available
The business, technology and the functions needs to play on the same side of the team, and not against each other, to be successful.
I would like to hear your experience from such initiatives, challenges and most importantly how did you overcome that?
Originally published at https://www.linkedin.com.
