Bear with me – PLEASE!
I mentioned in Part 1 of this series that MDM is not about the technology, you need to get the process and people aspects right first. Strangely enough this did not go down well with a number of my more technology focused friends and colleagues. So I would like to open this blog with a plea:

“To all my technology focused friends and colleagues that I have lost, please come back, I need you!”

If you would bear with me for this and the remaining two parts of this series I believe all will become clear, and we will be able to sit around the bar in peace, without me having to worry about what you might have put into my beer …

Thanks.

So, what’s this process stuff all about?
There are two key tracks to the discussion about process:
1) Business Process – How MDM fits in with business process, especially around MDM’s relationship with Business Process Improvement (BPI) initiatives.
2) MDM Process – The processes that drive the MDM world, including any MDM deployment methodology or framework and Data Governance processes.

I think we should leave the MDM Process piece alone for now, it is key to any MDM deployment and management life-cycle and warrants detailed focus on it’s own. And it leaves me with another topic to blog about, you gotta plan these things you know …

Why we are talking about Business Process
As I mentioned in Part 1, I have been banging on about MDM being about process for a while now. To multi-quote Tony Fisher in his opening speech at DataFluxIDEAS,

“Data management is not done for the sake of data, it is done for the sake of business processes”

“Organizations need to manage data, not just to improve data, but to improve business processes”

Those statements are so very true. Just ‘doing’ MDM on it’s own, in isolation from the rest of the business is a recipe for failure, BPI needs MDM and MDN needs BPI.

What’s the relationship?
MDM’s view: Think about where most of your data quality issues come from, get down to the root cause and I recon you will find that they come from a failure in process. For example, in a typical customer acquisition lifecycle, a new customers details are loaded into a CRM system of sorts, any process issues at that point and you will end up with erroneous customer data. If you can fix the process at the point of failure, you will get better data, and MDM will have less to do. (Look for a link to Data Stewardship here in my next blog post)

BPI’s view: Business Processes define a number of repetitive related and dependant events. These processes are engrained into the business lifecycle, and the ‘production-line’ staff more than often don’t give true focus to the data, it’s not their job (so they say). Let’s take the previous example, as the sales operative makes a sale, and loads the customer details into the system, they don’t want to have to think about, or maybe just aren’t bothered, getting the customers details correct. Having MDM providing clean consistent data to that operative at the right time is critical to an efficient lean process.

I know these are very basic examples, but they show how MDM and BPI need each other. Certainly the two can stand alone for a while, but as they expand across the business they will naturally grow closer together, like good wine and cheese, you can try and enjoy them on their own, but eventually you will realise that they need to be enjoyed together…

One last point
When considering the business benefits for MDM, and how you might want to present them. Which pitch sounds more compelling in today’s business climate:

“With MDM we can drive significant efficiencies in our Customer Acquisition life-cycle, through the provision of clean, consistent data to the front line at the right time! Improving the customer experience and driving down customer churn.”

Or

“With MDM we will be able to cleanse and standardise our data, while integrating it into our SOA environment and we will be able to update 20million records in 2 hours!”

I know which one my CEO would rather hear!