The intersection of Master Data Management (MDM) and Business Process Management (BPM) is a very interesting aspect of implementing MDM solutions.
We may divide this battleground into three sectors:
- Business processes that purely consumes master data
- Business processes that potentially changes master data
- Business processes that purely updates master data
Business processes that purely consumes master data
An example of such a business process is the execution of a direct marketing campaign. Doing this in an effective way is heavily dependent on clean and updated master data. A key capability is the ability to separate which targeted real world entities belongs to the so called “new market” and which are existing customers (or prospects or churned customers). When working with known customers the ability to intelligently relate to previously products and their categories of interest is paramount. Often knowing about the right relation between targeted parties and locations is very valuable.
When doing MDM implementations and ongoing refinement the insight on how master data are used and creates value in business processes is the starting point.
Business processes that potentially changes master data
The most commonly mentioned wide business process is the order-to-cash process. During that process especially customer master data may be affected. A key question is whether the order is placed by a new customer or a known customer. If it truly is a new customer, then effective collection of accurate and timely master data determines the successful outcome of receiving the cash based on correct credit check, correct shipping information and more. If it is a known customer this is a chance to validate and eventually update customer master data.
While customer master data often is changed through business processes having another main purpose, this is not the case with product master data.
Business processes that purely updates master data
An example is from within manufacturing, distribution and retail where we have business processes with the sole purpose of enriching product master data. With the rise of customer self-service through e-commerce the data quality requirements for completeness and other data quality dimensions have increased a lot. This makes the orchestration of complex business processes for enriching product master data a whole new flavour of Business Process Management where master data itself is the outcome – of course in order to be optimally used in order-to-cash and other business processes.
PS: If you are interested in discussing BPM and MDM alignment on La Rambla in Barcelona on the 22nd April 2015, here is the chance.
If you haven’t yet implemented a Master Data Management (MDM) solution you typically holds master data in dedicated solutions for Supply Chain Management (SCM), Enterprise Resource Planning (ERP), Customer Relation Management (CRM) and heaps of other solutions aimed at taking care of some part of your business depending on your particular industry.
In this first stage some master data flows into these solutions from business partners in different ways, flows around between the solutions inside your IT landscape and flows out to business partners directly from the various solutions.
The big pain in this stage is that a given real world entity may be described very different when coming in, when used inside your IT landscape and when presented by you to the outside. Additionally it is hard to measure and improve data quality and there may be several different business processes doing the same thing in an alternative way.
The answer today is to implement a Master Data Management (MDM) solution. When doing that you in some degree may rearrange the way master data flows into your IT landscape, you move the emphasis on master data management from the SCM, ERP, CRM and other solutions to the MDM platform and orchestrate the internal flows differently and you are most often able to present a given real world entity in a consistent way to the outside.
In this second stage you have cured the pain of inconsistent presentation of a given real world entity and as a result of that you are in a much better position to measure and control data quality. But typically you haven’t gained much in operational efficiency.
You need to enter a third stage. MDM 3.0 so to speak. In this stage you extend your MDM solution to your business partners and take much more advantage of third party data providers.
The master data kept by any organization is in a large degree a description of real world entities that also is digitalized by business partners and third party data providers. Therefore there are huge opportunities for reengineering your business processes for master data collection and interactive sharing of master data with mutual benefits for you and your business partners. These opportunities are touched in the post MDM 3.0 Musings.
Back in 1990 Michael Hammer made a famous article called Reengineering Work: Don’t Automate, Obliterate.
Indeed, while automation is a most wanted outcome of Master Data Management (MDM) implementations and many other IT enabled initiatives, you should always consider the alternative being eliminating (or simplifying). This often means thinking out of the box.
As an example I today stumbled upon the Wikipedia explanation about Business Process Mapping. The example used is how to make breakfast (the food part):
You could think about different Business Process Re-engineering opportunities for that process. But you could also realize that this is an English / American breakfast. What about making a French breakfast instead. Will be as simple as:
Input money > Buy croissant > Fait accompli
PS: From the data quality and MDM world one example of making French breakfast instead of English / American breakfast is examined in the post The Good, Better and Best Way of Avoiding Duplicates.
An important part of implementing Master Data Management (MDM) is to capture the business rules that exists within the implementing organization and build those rules into the solution. In addition, and maybe even more important, is the quest of crafting new business rules that helps making master data being of more value to the implementing organization.
Examples of such new business rules that may come along with MDM implementations are:
- In order to open a business account you must supply a valid Legal Entity Identifier (like Company Registration Number, VAT number or whatever applies to the business and geography in question)
- A delivery address must be verified against an address directory (valid for the geography in question)
- In order to bring a product into business there is a minimum requirement for completeness of product information.
Creating new business rules to be part of the to-be master data regime highlights the interdependency of people, process and technology. New technology can often be the driver for taking on board such new business rules. Building on the above examples such possibilities may be:
- The ability to support real time pick and check of external identifiers
- The ability to support real time auto completion and check of postal addresses
- The ability to support complex completeness checks of a range of data elements
The term Data Quality 3.0 has been around on this blog for nearly 5 years and was recently aired again in the post Data Quality 3.0 Revisited.
A natural consequence of the concept of Data Quality 3.0 is something we may call Master Data Management (MDM) 3.0.
Master Data Management has in a large degree until now been about how to manage master data internally within organizations. The goal has often been to merge different data silos within the organization into one trusted source of master data. But any organization in itself manages a master data silo too. The master data kept by any organization is in a large degree a description of real world entities that also is digitalized by business partners and other third party entities.
The possibility of sharing customer, or rather party, master data as well as product and location master data was examined in the post Third Party Data and MDM.
But how do popular MDM solutions facilitate the enormous potential of looking outside the implementing organization when it comes to achieving high value master data? Very poor, in general, I’m afraid. From my experience MDM vendors stops at the point of creating more or less readymade interfaces to popular data pools and for product data some kind of supplier portals. While the professional MDM vendor have viable methodologies for internal MDM processes there is an open door to the blue sky when it comes to external collaboration.
Managing relationships between entities is a very important part of Master Data Management (MDM) as told in the post Another Facet of MDM: Master Relationship Management.
There are relationships between entities within the single MDM domains and there are relationships between entities across multiple MDM domains.
Within customer (or rather party) MDM establishing the relationships between entities heavily increases the value of the data assets. Examples are:
- In B2B (Business-to-Business) environments knowing about company family trees supports both analytic and operational challenges. That knowledge is often provided by enriching data from third party data providers, but as most things in life there is no silver bullet available, as the real world is quite complex and in no way fully covered by any provider I know about.
- In B2C (Business-to-Consumer) environments knowing about how individuals are related in households is key to many analytic and operational issues too. Here having high quality location data is a necessity.
In today’s multi-channel world there is a rush for getting product entities enriched with a myriad of attributes to support customer self-service and thus as a minimum mimicking the knowledge of the traditional sales person in a brick and mortar store.
But we also need to mimic that sales persons knowledge about how products relates. That knowledge can be collected in different ways:
- From the manufacturer of the product. This source is often good when it comes to product relationship types as accessory and replacement (succession).
- From the customer. We know this approach from the online sales trick prompting us with the message “People who bought A also bought B”.
- From internal considerations. Facilitating up-sell can be done by enhancing product data with that kind of product relations.
Here we may have:
Multi-Domain MDM, Santa Style, is the title of a post on this blog made a couple of years ago. This post was about how a multi-domain Master Data Management solution could look like in an organization doing business as we think Santa Claus do.
Many organizations around the world who has recently embraced Master Data Management (MDM) has added Data Governance as an imperative parallel or integrated initiative. I guess Santa could have followed that path too.
Below are some thoughts about data governance considerations at the Santa Claus place based on a concept from The Data Governance Institute mentioned in the post Data Governance: Day 2:
What does it mean to be naughty or nice? I guess that must be a key question faced by Santa and his team every day. Santa is probably in no better position here than your are in many real world organizations. It is challenging to document key principles that everyone refer to every day as it turns really hard when you try to put them in a common shared business glossary.
Is Santa able to implement data governance based on the roles that the elves and the reindeers have had in daily operations around Christmas or does he have to ask Rudolph to head up a Data Governance Office or even become Chief Data Officer?
Reactive Issue Resolution
What should Santa do when the logistic elves insist on chimney positions in UTM and the reindeers can only use WGS84 coordinates? If Santa’s data governance programme does not solve this one you better watch out when Santa Claus is coming to Town.