Published
Author
The mention of the term Masterdata often leads to sorrowful looks and sighs. Most customers have heard the term and know deep down that this is something "they should address" but it is an activity that rarely gets so high on the list that it actually gets done. It is only when a system change or another major change in the infrastructure is about to take place that the issue becomes relevant, and then many customers realise that this is going to "hurt". The question is why this is perceived as tedious and why it is seldom done? The simple answer is probably a combination of the fact that the term is "vague" and unclear to many, while in everyday life there are rarely such big problems that force the business to undertake a masterdata project.
Let us start with the vague. A common and incorrect perception is that masterdata only involves organising your main registers such as the customer register, vendor register and article register. Over time, these registers usually (at least formerly) lose quality because responsibility for registration has shifted between several users and the needs for content have changed over time as the business focus has evolved. However, masterdata is not only about cleaning up your registers and organising nomenclatures and categorisations. It is also about establishing ownership of the information model at large, with clarity about data sources, principles for information exchange between systems, conditions for changes of data content and much more. Organisations that have been through a so-called masterdata project know that it is rarely a one-off task. Instead, it involves several steps beginning with mapping, implementation and not least the establishment of a management organisation also for masterdata.
Masterdata is not something new. We have talked about it for many years. What is worth noting today and going forward is that we can anticipate that the demands for "order and quality" in masterdata and registers will become even more essential in the future. The reason for this is that we see a clear trend that IT landscapes are once again becoming "fragmented" with the advent of cloud-based systems/services that should collaborate with the existing infrastructure. In this context, the word fragmented should not be perceived negatively, as has been the case previously. Instead, one should see fragmented in light of the fact that there are today greater opportunities to utilise external systems/services while maintaining a relatively "seamless" whole. One should always respect integrations, but many of today's systems offer good possibilities to exchange information, which entails fewer challenges compared to what we have been used to over the past 30 years.
In addition to the fact that the number of data sources is gradually increasing, we clearly see that data volumes are rising. It is increasingly common to store information in the form of "real-time data" such as monitoring what happens on the internet, user patterns and experiences from customer service, phone queues, chats, and the like. This also leads directly into the subject of "unstructured" data, which is becoming more and more common.
As a consequence of the increasing number of data sources and the overall increase in data volume, masterdata will therefore be an important aspect for being able to take control over one’s own situation. The challenge is that this often requires a change in mindset. Masterdata is something one should work on continuously and not a one-off project. But somewhere one has to start, and the first step should be to inventory the current situation and compare this against the business development plans concerning how one intends to develop and change its role in the market and the relationship with its customers and vendors. Once this is clear, one can perform a gap analysis and clarify roles of responsibility and when and how to supplement and achieve quality in one’s information flows. If one can change the mindset, masterdata instead appears as an important and even critical piece of the puzzle in the company's development and survival.
