Aligning MDM with Business Processes

At a recent master data management seminar arranged by a software company, the following scenario was presented:

1. A salesperson meets with a new client and makes a deal.
2. When he gets back to the office, he enters the data for the new customer in a central MDM system, where a workflow triggers a message to a data steward.
3. The data steward performs a duplicate check on the new record and discovers that the customer already exists. He merges the two records to avoid duplication.

This is a very typical scenario we hear over and over again. So what’s wrong with that? You may ask. Isn’t it great that we identify the duplicate records and then merge them?

The problem here is that the master data process is not integrated in the business process, rather, it is considered a separate process that comes after. Let’s consider the new customer scenario again. Do you really want your salesperson to go out to a customer and negotiate a price, only to return to the office and realize that another salesperson from the same company sold products from a different product line to that same customer three weeks ago? Wouldn’t you prefer if your salespeople searched for the existence of a customer in your system before they contact what they think is a new customer? Knowing what else you have sold to a customer before the sales meeting is very valuable information.

If you’re in the business of selling books and DVDs online, where new customers can register themselves, then it’s a different story. Then, you’ll be merging new customer records that are simply duplicates. But often software companies and technically oriented consultants think that the duplicate check is universally relevant and applies at the time of data entry. In their excite-ment over the fuzzy logic algorithms, they completely miss the point of properly aligning  master data process with business process.

We had a discussion with an expert consultant from SAP about whether a duplicate check on new product records at the time of data entry makes sense and should be enforced by the system. We were working at a food and beverage client that creates roughly 20 new products per year, and each new product is a result of months of development and experimentation within a signifi-cant budget. Once the product design is complete, a new product record is required in the enter-prise resource planning system. Just imagine what happens when the chief designer enters the new product data only to discover that a colleague developed exactly the same product last year, and the product record exists already.

Or consider a large car manufacturer that has acquired several other manufacturers over time. Typically, these are companies in various countries and regions and the brands remain independ-ent. Synergies of such mergers are expected in the areas of procurement and manufacturing. These types of companies usually have several design departments and develop new cars indi-vidually for each brand or market. Innovation and speed of product development is key for suc-cess in this industry. Yet, it’s easy to imagine a scenario where an engineer in one region needs a component that is already being produced by other part of the company.  As with the food and beverage example above, a search for the component in a central master data system prior to starting the development is very sensible and will prevent double work. And imagine the savings potential and the positive effect on time to market. 

There are many scenarios where duplicate checks at the time of entry makes a lot of sense. When creating new spare parts, for example, a duplicate check is typically very meaningful. It’s likely that a spare part has been bought before by someone else and, thus, already exists in your sys-tem. A duplicate check here should prevent you from entering the same spare part again.

For supplier master data, the story is somewhat similar to that of customers. Wouldn’t you like to know if you’re already a good customer at a given supplier before you call him to ask for a price? If you are the buyer in a division of a global organization, you should search to see if a given supplier record exists before you contact him. Not doing so is more a business process challenge than master data challenge. But of course, the scenario is not the same for strategic suppliers as for the mom and pop stores where you buy flowers for someone’s anniversary. In the latter case, a data entry-triggered duplicate check could be very relevant. 

Defining where and how to perform duplicate checking is not trivial. For the purpose of analyti-cal MDM it really doesn’t matter  too much, and here it’s a simple matter of keeping your data clean. But to realize the full benefit of operational MDM, you have to design data processes that reflect the needs of the business processes and consider the likelihood of mistakes. Duplicate checking must be considered as part of the business process, and it should be used where and when needed to effectively support your business operations.