InetSoft Webinar: MDM as an Enterprise Initiative

This is the continuation of the transcript of a Webinar hosted by InetSoft in April 2018 on the topic of "Building a Business Case for Master Data Management." The speaker is Abhishek Gupta, product manager at InetSoft.

While MDM is an enterprise initiative, I think in the end it should be a horizontal kind of platform solution for the organization. I think it’s best, and most of the success will come by looking at the problem a little bit more vertically and trying to solve actual business problems. When should vendor technology evaluations and selections come into the process? Are there any tips for evaluating and sorting out MDM technology options?

Well, there are multiple definitions of MDM out there. I think that’s one issue that I know everybody is dealing with because we often still get questions what is MDM? What exactly do you mean by that? So I think that there are a lot of rival definitions.

Consulting Performance Measurement Dashboard

I think there is also a general distinguishing feature between analytical and operational MDM, and that is one that we see as well where analytical is more about supporting BI and reporting and analysis activities, including things like reporting hierarchies, whereas operational MDM is more about establishing a gold copy or reference data that can be used by multiple transaction-oriented applications.

So that’s one distinction that people should look at when they are looking at tools and looking at technology to combat the problem. And then you do have both small vendors and large talking about MDM, and of course, as you get to the larger vendors, it often includes a lot of services approaches that go with the software. So again, organizations have to look at what they really want to take on in terms of build versus buy and bringing in tools themselves that their IT staff can work with versus outsourcing a lot of the effort to more service-oriented organizations.

I think the first step is to see what assets and processes are already in place to handle some of the key activities involved in MDM such as data integration and the profiling and discovery and business rules management that will be involved. Then you can see what’s missing from your current set of tools and current set of technology expertise in the organization to accomplish a specific business purpose identified.

Another key here I think is to make MDM efforts repeatable so you don’t want to have to reinvent the wheel as you go from business function to business function to address MDM problems, and that’s where I get to the idea that you really need that enterprise view ultimately with MDM.

So that way as you are consolidating systems throughout the organization, particularly after mergers and acquisitions, you are able to move from one scenario to another and set up rules and processes and workflow that will be working again and again and can be refined and continuously improved as you go along.

Then a final recommendation, I think IT and the business side need to be in agreement over goals, no question about that, so that both can be happy with the deliverables and also that filters into how the technology acquisition works and whether those are successful. Since master data management supports all different kinds of departments and initiatives, how does funding for master data management work? Who pays for it, and how should it work?


That's an age-old issue, certainly for IT. How to get business departments and business functions to pay for things that don’t seem to elicit an obvious payback? So I think that’s where it's important again for IT and business to begin to work together to establish specific deliverables and solve specific business problems. So that’s a good way to get funding because I think if the business side can see how we are going to solve a customer data problem that will lead to more use of customer self-service which is going to drive down their cost, then that’s obviously something they are going to be very interested in.

I think going back again a little bit to the analytical and operational MDM differences, I think there you can see that certainly on the analytical side you are going to have finance very interested in this because it's going to improve their reporting hierarchies and make them more agile that way. When hierarchies are changed or altered, particularly again through acquisition or re-shifting of sales territories in other departments, it isn’t going to involve an enormous effort to redo the entire system of reporting in an organization. So MDM can be very useful and drive down cost there.

On the operations side, every organization is trying to get their applications integrated. That’s been going on for a long time, and the information integration side of it is some of the most difficult to do. And so MDM is being applied there within certain ERP systems, but obviously most organizations have multiple systems.

They might have, for example, Oracle and SAP, or even if they have all the different systems that say Oracle has been acquiring lately, these systems are still discreet enough that MDM is something that they really need to be looking at in terms of unifying the applications and improving the information flow and therefore getting more return on investment from those applications. So there I think again, an MDM effort can attract interest from supply chain, manufacturing, inventory management people if, again, it can be shown there is a direct business benefit to what they are trying to do.


How should MDM success be measured? How do you know you have done it successfully?

Well, again, and I keep repeating myself, but I think that if you look at it again through business benefits, that’s how it really should be measured. I think that's what's distinct about MDM from previous integration efforts is that if you can point to a business problem that was improved or resolved, cost being driven down, not only in IT, but that’s certainly a significant issue IT cost, but also on the business side, as well. That’s really success in terms of MDM.

Because it’s little bit difficult to measure in terms of amount of data reconciled or number of data quality problems solved, just on that basis alone, because I think organizations are going to have data quality and data inconsistency issues they are going to have to resolve. They are never going to get to the end of it. So it's better to just look at the business issues that are being resolved. I think it’s another big issue with MDM to be able to set in place the rules and the workflow and the processes so that you can move from one issue to the next. In the end you will start to build this horizontal function that will begin to address a much greater number of problems that the organization is facing in terms of data inconsistency and information quality problems.

So I think there are three things really, to be incremental, to address business problems and measure the success in terms of business problems solved and then establish the process and the workflow ability so that the solution can be repeatable.

Previous: MDM's Very Clear Mission