Why is the first part of a master data project usually so hard?
In this instance I am not talking about selecting a vendor from the plethora who offer the technology to solve all ills, or producing a high level data model of the many and various subject areas, or even mapping out a Create, Read ,Update and Delete matrix for all these subject areas.
The reality is that these activities are simple when compared to the central challenge - defining the terminology which will be used to communicate across the project and organisation when discussing master data and data governance.
Some projects jump through some seriously convoluted semantic hoops when framing up their terms of reference. My personal favourite so far is Management of Static and Reference Data; anybody guess what this was about? This is fuelled further when master data is described as slowly changing dimensions.
Practitioners often take this to mean that master data is pedestrian and staid by comparison with the more dynamic and exciting transaction data. However, this should be looked at from another angle – transaction data is a fact. It happened, it cannot be changed. By comparison it is master data that is dynamic and ever changing.
To use Andy Hayler’s favourite example, you go into a store and buy a chocolate for 99c at 11:13AM on Monday the 3rd February 2010. That value date and time cannot ever change, it happened, it is a fact. However, over time the master data which surrounds the transaction does often change, the store name, brand of chocolate, your name and even your gender can all be different today from the values they had on the date of the transaction.
So what we really need as MDM practitioners is a recognition that there is value to be unlocked by understanding and managing the change of master data over time, and that we need a consistently applied definition of terms.
Walk into the majority of areas of business and there are clear definitions of the roles which people play, the process which they follow and the tasks which they deal are all known and easily understood.
Walk into the finance department, invoice, debits and credits, financial controller, auditor, accounts receivable clerk, order to cash and so on are well understood. The same cannot be said for your average MDM project. In MDM such definitions are just as important as significant confusion can be created by not having the definitions well thought out and communicated up front.
Providing a sensible common language will reduce lost time and confusion at the start of the project. My recommendation would be to use externally generated standards such as those advocated by DAMA and avoiding domain specific idiosyncrasies.
The task gains further importance when placed against the backdrop of the impending tsunami in the shape of a Yottabyte of data. The absence of ways of providing structure and meaning to this data will make today’s information overload seem like a mere shore break by comparison.