I often become involved in an organization’s MDM program when they’ve
reached out to InfoTrellis for help with cleaning up after a failed
project or initiating attempt number X at achieving what, to some, is a
real struggle. There can be a lot of reasons for a Master Data
Management implementation failing, and none of them are due to the
litany of blame game reasons that can be used in these scenarios. Most
failures arise from common problems that people just were not prepared
for.
Let’s examine some of the top reasons MDM implementations fail. In
the end they probably won’t surprise you, but if you haven’t experienced
it yet you will be better prepared to face them if they happen.
Underestimating the work
I am starting with this one because it leads to many of the others,
and is a complex topic. It seems like a simple thing to estimate the
work but there are a lot of aspects to an MDM project that aren’t
obvious that can severely impact timelines and your success.
“It’s just a project like any other”
Let me start by saying MDM is not a project, it’s a journey, or at the very least a program.
Most organizations thinking about implementing MDM are large to
global companies. Even medium sized companies that started small and
experience growth over time have the same problems as their global sized
piers. While the size of the chaos in a global company may seem much
larger, they also have far more resources to throw at the problem than
their smaller brethren.
If we stick to the MDM party domain as a point of reference (most
organizations start here with MDM), the number of sources or points of
contact with party information can be staggering. You may have systems
that:
- Manage the selling of products or services to customers
- Manage vendors you deal with or contract to
- Extract data to data warehouse for customer analytics and vendor performance
- HR systems to manage employees who may also be customers
- Self-service customer portals
- Marketing campaign management systems
- Customer notification systems
- Many others
A lot of large organizations will have all of these systems, each
having multiple applications, and often multiple systems responsible for
the same business function. So by now you are probably saying, yes I
know this, and…? Well your MDM “project” will need to sit in the middle
of all of this, and in many cases since many of these systems will be
legacy mainframe based systems, you will need to be transparent as these
systems won’t be allowed to be changed.
MDM can be on the scale of many of the transformation programmes your
organization may be undertaking to replace aging legacy systems and
moving to modern distributed Service Oriented Architecture based
solutions.
Big Bang Never Works
Now that we have seen the potential size of your MDM problem, let me
just remind you that you can’t do it all at once. Sure you can plan your
massive transformation programme and execute it – but if you have ever
really done one of these, you know it’s a lot harder than it seems and
that the outcome is usually not as satisfying as you expected it to be.
You end up cutting corners, blowing the budget, missing the timelines,
and de-scoping the work just trying to deliver.
What is one of the typical reasons this happens on your MDM transformation project?
You Don’t Know What You Don’t Know
You have all these systems you are going to integrate with and in
many cases you are going to need to be transparent in that those systems
may not know they are going to be interacting with your new MDM
solution. You are going to need to know things like:
- What data do they use?
- How often?
- How much?
- When?
- Do they update the data?
- Do they need to know about changes made by others?
- How often is the change notice required?
- Do they need to know it’s changed, or what the change was?
This type of information seems pretty straight forward. I haven’t
told you anything you probably didn’t know, but, when you go to ask
these questions, the answer you will mostly likely often get is:
“I don’t know.”
Ok, so the documentation isn’t quite up to date, (I am being kind),
but you are just going to go out and find the answer. Which leads to the
next problem.
Not Enough Resources
So this is an easy problem to solve. I’ll hire some more business
analysts, get some more developers to look at the code, get some more
project managers to keep them on track. Seems like a plan, and on the
surface it looks like the obvious answer, (ignoring how hard it is to
locate available quality IT people these days), but these aren’t the
resources that are the problem.
You don’t have enough SMEs.
The BA’s, developers and others are all going to need time from your
subject matter experts. The subject matter experts are already busy
because they
are subject matter experts. There typically aren’t enough of them to
go around, and if you have a lot of systems to deal with, you are facing
a lot of IT and business SME’s.
What your SMEs bring to the table is intellectual property.
Intellectual property is critical to the success of your
implementation. You will need the knowledge your SMEs bring on your
various systems, but there is another kind of intellectual property that
you are going to need and can be tied to a very lengthy process.
Read More
http://www.infotrellis.com/top-reasons-an-mdm-implementation-fails/ 
