Summary
The article adequately describes various Master Data management approaches at a conceptual level. Unfortunately, we live in the real world where disparate systems are the norm and investment dollars are tight. From 20 years of being held accountable for implementing systems and processes which drive financial benefits, I have found that narrowing the focus to critical data elements is essential, and that these critical elements must be evaluated from front to back in a company
Analysis
The article is written from the perspective of a data architect and I find it somewhat academic. It paints the picture of several conceptual approaches to organizing master data. These are valid for what they are. However, delivering value from master data efforts requires two elements which are barely mentioned in the article,
- Focusing the effort on high value data (i.e. data which enables better decisions and better outcomes)
- Evaluating the end to end processes which use and transform that data (but only for these focus areas, not all data)
The author asserts that these efforts have significant benefits, but offers no guidance on how to achieve these. I have found that these focus areas are essential to achieve actual benefits.
Not all data is of equal value. The boil the ocean data architecture efforts often become consumed by creating huge books of information. A high level description is absolutely required, but the books are often wasted effort. The real question is which data elements will drive the most significant improvements in the business and for factors that are important to the company. This is no easy effort and is a combination of objective and subjective analysis. The end goal is to get a "good enough" analysis that can ensure that your approach is appropriate. Some companies are looking for transformation (e.g. driving cross sell across multiple divisions). Others are looking to identify where data is critical to achieve annual improvement goals (e.g. reducing inventory). In either case, a giant data architecture effort is not required. Also, notice that my examples are business outcomes, not data speak.
Additionally, the processes which use the data are critical in any evaluation of the quality of a master data approach. We have learned from the Japanese that work must be mistake proofed and that errors should be immediately visible to staff. Just putting master data under the bureaucratic control of a central group and system does not ensure it is correct (nor do the mapping and registry schemes discussed). In fact, errors in many types of data are unlikely to be caught by a central team who just goes down a list of things to check. For instance, a planner / buyer in a plant should be on top of material lead times and have processes and systems which help them quickly recognize issues. Lacking these processes, there is no way a centralized person with no detailed business knowledge will actually recognize that a lead time might just be obviously wrong. The detectability of issues is really key with master data and the technical and organizational decisions alone are not enough.
These efforts are almost always iterative. As a team drills down into the first high value area, they typically find interrelationships which were not previously understood. These new findings need to be quickly considered using a "good enough" decision rule. In a few cases, you might make discoveries which require significant revisions to scope. Most of the time, you will put the new findings in the parking lot for the next phase.
This author consults with leading institutions through GLG
Analyses are solely the work of the authors and have not been edited or endorsed by GLG.
