I called into a real peach of an inquiry today with a large, industrial end-user organization. The written part of the question was really well structured and actually applies to many medium to large organizations, but especially larger, more complex industrial organizations. In a nutshell, it went like this:
- We are a large diversified industrial organization with plants and facilities in multiple countries
- We have a business application strategy centered on ERP, even one vendor, but we still have different business requirements by line of business or product organization
- A single global ERP instance does not fit our business strategy (too homogenous, too standardized for non-commoditized business processes), so we have to exploit out complexity of multiple ERP/Suite and best-of-breed applications
- We do need to share an amount of common business data between core and differentiated business systems
So the question is – how do we do this in the most effective way? Common solutions in the past are many and range from:
- Use a redundant copy of an ERP system to act as a ‘clearing house” into which all the various copies of the ‘common data’ can be aggregated, harmonized, then re integrated out to the source ERP systems, or even a data warehouse for reporting
- Periodic data quality projects whereby a 3rd party is paid to clean up a boat load of data from numerous business systems, only to repeat the exercise (and cost) every 9 to 18 months
- Adoption of numerous data warehouses, over the years, each one meant to address an aspect of “single version of the truth” only to find that data warehouses are not good business solutions to the problem – only possible technical solutions that have little chance of attracting the necessary level of business led information governance required to “make it work” as desired
Even Master Data Management is not the perfect solution. On paper, MDM is in fact the ideal solution, but the reality is that MDM was not designed to do all of what is needed. MDM was designed to operate in a similar way, but only to help assure consistency of the master data that links the primary or core business processes and systems. Master Data is a subset of all the application data that is used by business applications. The scenario laid out above requires more than master data to be synchronized and governed for re-use.
So what to do?
Well, this client – like many others – could start with an effective MDM program that would, with the right design and architecture, get the foundational parts in place. But the questions will arise: what to do about the other, non-master data that needs to be synched across the businesses?
The challenge is this: The chosen MDM hub vendor will, no doubt, offer to handle the extra data. Why not? Surely it’s nothing to worry about – surely you can just fill the master data hub with lots more business application data. If the information infrastructure can handle the master data, why not just a little more?
This is a slippery slope. It leads in fact to an ERP moment. Why not put everything into the hub? Worse, some of the data you try to put into the hub is data for which the hub is not actually designed to handle. For example, in this case, Bills of Material (BOM). This is quite a complex object. It may consist of a parent and any number of children (this means a relationship, or a hierarchy). For each parent-child relation there maybe any number of rules or attributes spanning used on quantity, effective dates, population (for options and features), release codes and so on. Some BOM’s are many levels deep. Some may have hundreds or even thousands of children. Then there are many types of BOM – such as engineering BOMs, after-market service BOMs, repair BOMs, and marketing BOMs. So BOM does not fit the ideal definition of master data. It certainly behaves like master data, but it fails the test “does the (master) data describe what your business does?”
You see, master data is not an IT conversation. It should always and in every case start with “what does the business use to describe what it does” such as provide processes or services to consumers; or sell products to customers; or process loans for students. That is where the definition of master data starts. It should NOT start with a discussion by IT about frequency of use of common data across the application landscape. That approach tends to create the apparent need for an MDM program they may or may not be aligned with business needs. It tends to create a whole lot of data that is not really that important. If there are no business needs, even if the data is ungoverned and out of control, no one will really care.
So to conclude this exciting inquiry today: Yes, this will start out as a regular MDM program but it will quickly become something else. I am not sure what we (or the end user client) will call it, but MDM it shouldn’t be. We are all on an exciting, continuing to develop journey.