January 2009, Intelligence Central
How do executives prevent Master Data Management (MDM) from becoming another Y2K?
How do executives prevent Master Data Management (MDM) from becoming another Y2K?
It wasn’t that long ago when executives were asked to spend millions of dollars to “Solve the year 2000 (Y2K) problem”. The Y2K problem was the bug in software, built before the 2nd millennium, that was expected to explode precisely at 12:01 am, 2000. While there has been a great deal of debate, with regard to the reason the problem never materialized as expected, the fact is, 100s of millions of dollars were requested to solve the problem and 100’s of millions were spent with a bunch of quizzical executives looking on.
Now executives are being asked to spend millions on Master Data Management (MDM) or Customer Data Integration (CDI) software. Ironically, executives are being told that all the new software, implemented to solve Y2K, had the unintended consequence of decentralizing the maintenance of “Master Terms” (a.k.a. Master data) used to tag and find business events in databases. Consequently, it is not unusual for the same master term (e.g. Customer, Supplier, Product name, etc.) to be recorded differently in different databases and to create conflicts when a centralized understanding of the term, and the events it tags, is required.
To be fair the introduction of new Internet systems that coexist with predecessor systems and new systems introduced as a result mergers and acquisitions (M&A) have had a similar effect on the decentralization of master terms. Regardless of the cause the operational impact of decentralizing maintenance of master terms has not been lost on executives. Every Account Executive (AE) for a National or Global Customer of any size understands the often Herculean effort required to reconcile all the different terms used to record transactions for their customer. As the AE and her team prepare for an upcoming meeting with their customer’s CFO they are often embarrassed when the CFO has a better understanding of events than the account team.
Very similar situations occur when Global Supply Chain executives try to consolidate purchases for the same supplier at a national or global level. Engineering executives have similar frustrations when they try to reuse parts in Bills of Material for products sold by different business units. The root cause is the same. Databases, used to record the names of real world things, are decentralized and consequently terms that describe the same thing are often stored differently. In many cases the need to record the terms differently, for legitimate business reasons, cannot be dismissed either.
So what are executives to do? Just grin and bear it? Well kind of. Unlike the Y2K problem though, no one is suggesting the sky is falling and a business will come to a dead stop if Master Data is not reconciled. MDM is the cause of increasing inefficiency. Some studies suggest business people spend 15 - 20% of their time resolving differences in terms found in company reports that should have a common meaning.
Because the issue is so pervasive, companies that do solve it could realize a competitive advantage over those who don’t especially when it results in better purchasing and retention of customers who expect to be known, regardless of the company representative or system with which they are speaking. There are 3 things executives can do without turning MDM into Y2K:
1. Put business people in charge of the vocabulary – Make sure business people, who understand the meaning of business terms, are in charge of any MDM service. There are two major ways a MDM service can be organized:
a. System of Reference – The MDM service collects all of the different terms and standardizes them.
b. System of Record – Standard terms originate in the MDM service and are distributed to operational services
Regardless of the way the service is organized, effective operation requires sign- off on the use of the standard terms that are the end product of the MDM service. That sign‐off is not the job of technologists. It is the job of a person who understands how business people need to communicate and the vocabulary of business terms needed to enable communications.
2. Don’t buy a “pig in the poke” – Might sound a little anachronistic to use this old-fashioned term for advice related to something so modern but the advice is sound none-the-less. It simply means don’t buy something until you have seen it. The colloquial phrase is enshrined in common law as “Caveat Emptor”; let the buyer beware.
The market for commercially available MDM systems is immature. Products are advancing through a classical technology maturity life cycle. Some are still the tools of technologists. Some are applications and some have matured to platforms, from which various solutions to manage master terms, can be deployed and economies of scale realized. So make sure you know the state in the maturity cycle in which the products under consideration are or as the old English would say, “When ye proffer the piggy, open the poke”.
3. Focus all efforts on the “R” in ROI – It is not unrealistic to think that development and maintenance of a business vocabulary will require the expenditure of millions of dollars. That is not to say, however, that millions need to be expended immediately or that an entire vocabulary needs to be available to all immediately.
There is a time value to money and it will take time to get a vocabulary of master terms developed and widely adopted so that a workflow improves. Consequently, like all investments it is essential to understand how the adoption of some portion of the vocabulary will improve communication and the workflow for a group of people. The “R” in the ROI of MDM needs to articulate improvements in communications and work before funds are authorized.
The job of executives is to simplify, not to complicate. The “MDM thing” is really simple. To simple we often want to make it complicated to justify spending the time it requires but just to say it is simple is not to say it is not important or fundamental to the efficient operations of a business. After all if people don’t have a vocabulary they don’t have a language; and if the don’t have a language they can’t communicate and if they can’t communicate…Well, you get the point.
Linguists tell us that communication requires a “Chain of Transmission”. All that means is their needs to be an unbroken chain in the meaning a person assigns to a “thing” and the words used to communicate something about that “thing” to other persons. If there is a break in the chain of transmission ambiguity results and people receiving the message will likely spend time resolving the ambiguity that results from the break in the chain.
For all of their wonders, modern computerized systems create a real risk that a break in the chain of transmission will occur because they are the principle tools of 21st century organizations to automate communications. Computerized systems risk breaking the chain of transmission & need MDM to mitigate risk for 3 reasons:
1. They are asynchronous – They put data in a place at a point in time and expect people to get that data at another point in time. This means the people who put the data in the place will likely not be available to explain what they meant by the data when people come to get it.
2. They are decentralized – Lacking a coordination mechanism, different people operating in different times and places will in all likelihood use different terms to mean the same thing. Those different words or terms will be recorded differently in the decentralized systems.
3. Human beings operate them – This is probably the most compelling reason to invest in MDM. Unless a business intends to go completely “lights-out” people will always be involved in one side or the other of a communication and ultimately it is people who assign meaning to things; not computers.
Fundamentally MDM systems mitigate the risk of a break in the chain of transmission and all of the inefficiency that creates. Should executives invest in them? With the proper controls, yes they definitely should. It’s not another Y2K.