Lessons learned from a MDM workshop.

Last week i joined a SAI workshop "Master Data Management" teached by Jan Henderyckx and it was a learnfull session. Below i'll describe some interesting topics about this workshop (in my opinion).

Business case
The first point is about what the reason could be for implementing MDM. There are two indicators for this: Risk and Value. Risk is about quality of the data in your systems and what is the change that this would result in a business problem. For instance, what is the risk that information about adresses of customers in a database is wrong and that letters/email are bounced back. For example, commercial ads being delivered to the wrong address is a small problem but delivering invoices to the wrong address is a much bigger problem.

Values is about Return Of Investments (ROI). How much can we save if we implement MDM? Lets say we have a business that have erroneous data about customers and due to wrong adresses invoices are returned. In this case it's easily to calculate the losses because of wrong addresses. Surveys among MDM users tells us that they find it very difficult to calculate ROI on MDM. So there is much work to do.

What is correct data?
This seems to be a difficult question. Correct data is always compared to something else and there are two distinctions possible: comparison with the real world objects (identity management) and comparison with other data ("i know that the data is different but i don't know which data is correct"). And an another interesting statement is that you can invest unlimited time and money in approving dataquality. Focus on the most important attributes and define a KPI for a to be reached goal of dataquality.

MDM goes EIM
Without 5 or 10 year we are not talking about MDM anymore, but we are talking about EIM (Enterprise Information Management). We shouldn't be careful with masterdata ONLY, but we need to handle ALL data carefully.  So the leassons we learn from MDM projects should be adopted in EIM. We need to care about Governance, Compliance, Business Process Redesign (BPR), Business Process Management.

So thats it for now.

Hennie

You don't need a MDM tool implementing MDM!

In one of my projects we are defining a MDM project and currently i am into all kind of discussions about MDM. This post is about one of the statements that have been passed during the different meetings: "You don't need a MDM tool to do MDM!". I'm not saying that this statement is erroneous. It only gave me some food for thought.

Well this is an interesting statement! You don't need a MDM tool to do MDM?! For instance, do you need to adopt a seperate MDM tool when there is only one source system for every Master Data Element? This isn't an easy question and the answer is somewhere between "offcourse" and "nope".

Pro MDM System
When your organization is scattered around the globe and has multiple systems involved for maintaining master data elements then, yes you'll benefit very much of integration of the disparate data into a "golden record". As my current understanding of MDM is that the main benefit of a MDM Application is on the input side of MDM: how to integrate the different Master Data Elements from the sourcesystems into a MDM system. The benefits on the output side of the MDM system is less obvious (in case of one input application per Master Data Element).

Contra MDM system
As i read the blog from Andrew White from Gartner that, for instance, ERP systems are supposed to give a single view on the business but because of implementations of multiple ERP systems because of multiple federated subsidiairies consolidation is needed. This is a heterogenous situation. But when is a MDM application not really necessary?

I think there are a couple of situations:

• There is a homogeneous situation available.
• Master Data elements are uniquely created in one source system.
• Data Elements are not integrated that very much.

So perhaps you don't need a MDM application but you do need to organize and define processes "for doing" MDM! Think about data stewardship, governance, policies and dataquality.

Gr,
Hennie