Marrying Process with Master Data: An Example

Share it on Twitter  
Share it on Facebook  
Share it on Linked in  
Slide Show

10 Critical Myths and Realities of Master Data Management

Prevalent myths surrounding MDM alongside an explanation of the realities.

Now that companies have more or less embraced master data management as an important program, some are looking at how MDM can be combined with other initiatives to create something even bigger and better.


I hate to toss the acronyms around, but sometimes it can't be helped. This is one of those times. The trend right now is to look at how companies (and vendors) can combine master data management with business process management to do things like manage data quality and govern data.


Once you can wrap your head around the three-letter acronyms (or TLAs), it actually makes a lot of sense.


I wrote about this line of thinking in March, pointing out that Software AG is really pushing this idea of process-driven MDM.


Full disclosure: I recently began writing for Software AG's vendor-neutral B2B site. I don't frequently mention Software AG on ITBE, because I don't cover B2B integration that often. In fact, I've never interviewed anyone from Software AG for this site, though I have mentioned it in passing, primarily because the company has a BPM tool.


But while I was on a call about the B2B site, the PR person took the opportunity to make an ITBE pitch: The vice president of business infrastructure products and solutions, Jignesh Shah (@jshah0209), wanted to respond to my March post and discuss the process-driven MDM. Fair enough. I'd agree to it with anyone else.


Since it was on topic, I cleared the Q&A with my editor, and we set up an interview, which published this month.


Shah pointed out that, too often, these discussions focus on how BPM can automate master data tasks. He wanted to round out the discussion by looking at why a process-driven approach is a smarter approach to MDM.


To illustrate his point, he shared an example:


Recently, he tried to renew a newspaper subscription. He had both a print and online subscription, so he decided to drop the print version. Since he loved reading this newspaper on the iPad, he signed up for an iPad discount offer for a subscriber.


The problem was, it was only for new subscribers, but nothing in the system caught this. It took repeated calls to the newspaper to figure out that this data problem - he was already a subscriber but had clicked on a link as a new subscriber - had caused the order process to stop, essentially leaving his order stuck in limbo.


"This is a classic case where the marketing processes that were feeding me the offers and promotions were out of sync with the customer information that was in the subscription system and the subscription processes," he said. "So this is an MDM problem: One set of processes is out of sync with another set of processes because they are running on bad data. It's not necessarily even because they're badly designed; they just don't have the good quality data."


A process-driven approach to MDM would've prevented this, he contended.


The traditional approach to MDM is a sort of "boil the ocean" approach to one set of data - usually customer master data. The information architect sits down, maps out all the systems that hold customer data, and creates a sort of grand unified theory of customer information, he said. And then it takes three or four years just to create that vision.


Compare that to a process-driven approach. You take a business process automation tool and you analyze and map all the processes that are used to create and consume customer information. Finally, you map out the processes that should govern changes in customer information.


"Those are the three types of processes we talk about: Processes that create master data, processes that consume data and then processes that should govern any changes to master data," Shah said. "Then based on that, we would say, Look, these are the relevant processes and here's how they use master data.' Based on that, we would then drive the MDM implementation."


You could even automate it and provide more visibility into the subscription process with a BPMS tool, he added.


But more importantly, his point is this: You don't have to wait for a tool to combine MDM with BPM. By starting with a process model first, you break MDM down into manageable steps and ensure you're making a real difference now.