top of page

I’m a Master Data entity — Get me out of here!


Let’s get a couple of things out of the way…


Firstly, Master Data is the critical, consistent business data that defines the organisations you do business with, the people you work with and the places, structure and characteristics of your organisation. Master Data is wide-ranging and diverse. Customer photos, chart of account structure, your product list and customer addresses are all examples of Master Data.


Secondly, every organisation already has most of the Master Data it needs, it may be heavily silo’d, duplicated and/or be of inconsistent quality. An organisation may not know where the data is or which version is the master or have a clear view on the quality of the data but it is there, somewhere, within the systems, processes and knowledge of the organisation.


What your organisation may not have is Master Data Management (MDM). MDM provides the framework required to break down the silos, understand and govern data, gain confidence in data quality and enable the reporting, analysis and transformational capabilities that your business requires.


Do you need MDM? Look at your own organisation — if the confident answer to any of these questions is more than ONE then you need MDM:

  • how many competing sources of customer-related data do you have?

  • how many competing sources of product-related data do you have?

  • how many different ways are customers onboarded to your organisation?

First and foremost, this is not about technology and tooling. MDM tools are a trap that the unprepared fall into. You’ll need them, but not yet!


Fixing Master Data starts with identifying ownership for the problem. It is both a business problem AND a business-led solution. If your business considers Master Data is a solely IT problem give up now… if not, then start with identifying the key roles; a sponsor and a head of data governance.


Their focus must start with defining the operating model for the framework of processes, governance and people required to support the consolidation of Master Data. In conjunction, they will provide a plan and roadmap for the approach with suitable waypoints or milestones to prioritise the needs and to act as a guide for this journey.


Achieving quality data will be reliant on the operating model and roadmap. I can almost hear the cry “what does good look like?”….


  • good is data that achieves a level of quality that means it will empower not constrain your business

  • good is sharing key data between key systems so they remain relevant and consistent

  • good is having the capability to accelerate the onboarding of customers, the execution of a transaction and integration with customers and suppliers

  • good is being confident about your data quality so that you know that your standard processes (sales, billing, procurement) have less errors, rework, reconciliation and audit need

To get to good efficiently and sustainably requires MDM and it needs a repeatable approach, data domain by data domain.


Consider each data domain as characterised by the definition of what is stored (the columns) and actual data stored (the rows). By way of example...The columns: Product code, Product Name, Product Size

The rows:

  • SKMLK1, Skimmed Milk, 1 Litre

  • SKMLK2, Skimmed Milk, 2 Litres

  • SSMLK1, Semi-Skimmed Milk, 1 Litre

  • WMLK1, Whole Milk, 1 Litre

For each data domain that is agreed to be adopted as Master Data the design process is repeatable and simple to explain…

Firstly we deal with the columns

  • DISCOVER where the data currently is and what state it is in — it is likely to be in multiple systems

  • DECIDE what data columns are required by speaking to those that understand the business

  • DESIGN a model to hold the data — this is often called the canonical model — essentially the superset of information the business requires

  • PREPARE the technology to hold, cleanse and distribute the data

Then we deal with the rows

  • CHANGE the Producer systems to feed data rows to the MDM

  • CHANGE the Consumer systems to receive or harvest data rows from the MDM

  • CLEANSE the source data and prepare the initial Master Data set for the domain

  • BUILD exception management capability to merge duplicates, validate and repair data

  • DESIGN and BUILD the new operating processes for standard operations that will manage the Master Data, for example: duplicate handling during client onboarding, verification and approval during product catalogue changes, etc.

None of the steps above happen in isolation, they are part of a comprehensive, often multi-year plan for MDM and they are focused on providing a single, monitored, quality, immutable view of your Master Data.

Start small, think big

The business landscape is littered with failed MDM projects. Examination shows that in many cases they fell at some of the simple hurdles:


  • lack of sponsorship (often IT owned without business buy-in)

  • they went technology first and did not have the necessary governance and processes to control the outcome

  • they did not take a gradual, learning approach, generating incremental business value but jumped straight in, ill-prepared, with a big-bang approach across the most complex data domains

  • they did not engage people and tooling with relevant experience in MDM delivery

a journey of a thousand miles starts with a single step

So if you haven’t already take the opportunity to embark on a step-change approach, free your Master Data entities from the scattered and competing systems that currently silo them.


By investing in MDM and putting in place the operating model and capability to pull your Master Data together you will provide a platform that returns business value in terms of sustainable data quality, efficiencies of growth and consistency across the organisation.


Paul Krisman heads up strategic IT and occasionally writes, opines and helps enterprises taken on data challenges



Comentários


bottom of page