Andrew WhiteI received one particular (spam) email today from www.intermarket.com – not an organization I am that familiar with. However, the email informed me, “If last year’s events and the sudden vanishing of entire markets have made one thing clear to investors it is the following: never again take a price at face value.”
This reminded me of a number of 1-1’s I had with clients last week at the Gartner IT Expo/Symposium. Many clients were asking questions regarding MDM and some specifically explored, “what is master data?” Price, the focus of the Intermarket email, is a difficult concept to tie down with respect to MDM.
Master data has certain characteristics, so a test of “is something master data” has to be thought through in relation to these characteristics. One such characteristic concerns the degree to which the data is re-used (by processes, systems and/or users). Price certainly meets this requirement in that it is re-used by many systems etc. Price can be referred to for quoting, and it can be assigned to a business transaction and embedded into a financial transaction. It can also be used as another reference for comparing to invoices for payment reconciliation. The importance of maintaining price accuracy and completeness (two types of “quality”) can be critical to businesses – in terms of business performance as well as regulatory compliance.
However, for some uses or even entire firms, price can be derived, in that it is calculated a point in time depending on things like terms of a deal, date, event, or any combination or intersection across customer, location, and order etc. Once calculated the price may then be re-used. Once derived data is…derived, then it may yet look and smell like master data.
The bottom line here is that there are few real universal truths for, “what is master data?” It depends – often on the business, uses of the data and other factors.
Category: Defining Master Data Tags: Defining Master Data, Price Master Data
3 responses so far ↓
1 Cliff Longman October 31, 2008 at 2:13 pm
Interesting observations Andrew.
I always thought “master” was a good adjective to use for the kind of data we are talking about because, to me, it is data that will act as a master (to a number of slave copies). To your point about usage of the data: the larger the number of slaves to a given master, the more opportunity there is for inconsistency and (likely) the higher the business value of ensuring the consistency of these slave copies.
We just had a long conversation on the whole topic of price (in the context of rate book maintenance in Insurance companies where regualtions require reporting of rates/prices).
It served to further support my opinion that very often the “subject areas” of master data are interconnected (rate/price being a connection between product and customer/customer type).
2 Andrew White October 31, 2008 at 2:29 pm
I would agree Cliff, the greater the level of re-use the more likely a) that quality will more quickly erode, since more and more copies of the data are likely to be made to serve different uses, and b) that value from the said data is greater to the business.
Interesting point you made on “connection”. I have said before that rules could be master data; they can be re-used and referenced over and over by different processes, and they may be slow to change over time. If you think of product and price configurators in complex multi-channel environments, you are thinking of a rich dialog that will look at managing rules as if they were master data. So your “connections” sound like rules. However, we are having fun just coping with the basics right now – so we will have to look to the future to complete this dialog…perhaps.
3 Cliff Longman November 10, 2008 at 5:35 am
Andrew,
Interesting. I was not focusing on the “rules” aspect of MDM, just the simple first step of getting the “raw master data” into a managable state.
I think regulatory reporting pressures will force insurance and other industries into managing their rate books in a more disciplined way.
That is MDM, and the first step of getting a basic rate book into a master repository requires (really simple) product and customer data and the connection between them.
As you say, one baby step at a time…