Recent Posts



No tags yet.

The Life cycle of Master Data - Maintenance phase

So, put in simple terms we're talking about the CREATION, MAINTENANCE and REDUNDANCY / RECYCLING of Master Data.

In most cases the CREATION element of this life cycle is the one everyone focuses on. How do we create the Master Data? Who will do it? How do we ensure its accurate? This is VERY important and of course it's the first battle, we're all very much aware of Garbage in and Garbage out. The below also applies to Master Data cleansing projects. If you don't consider the future MAINTENANCE aspect of the process you effectively have a constantly dripping tap, you may clean your Master Data, but in a few months time its degraded again and the cycle continues.

However, in this blog I am going to focus on the MAINTENANCE stage. Unfortunately, many organisations put all of their efforts into CREATION. MAINTENANCE however is the dangerous phase where that, however meticulously and lovingly created, Master Data starts degrading. Why ? This zone is the wild wild west of CHANGE. It is very rare indeed that a Master Data Object is never changed. Yet very few organisations spend enough time understanding the impact of change in their Master Data. Yet it is changes to Master data that can create the most chaos.

Generally Master Data changes are focused on a specific request or task, "Please can you change the sales category of Product Y from 001 to 005"? However it is rare that such a request would affect just one product. Someone in this instance should be checking what other products are categorised as 001 to see if they too require changing , what other Master Data might be linked and therefore affected, and finally ask the question 'should we be making this change at all' who has made this decision? Without the right training and understanding of how a business uses its Master Data its easy to see how the Master Data can rapidly degrade.

Therefore it's really important that Master Data Maintenance processes are explicit in

1. Who and how changes can be requested?

It’s easier to prevent the dilution of Master Data if a few competent roles can process changes rather than the whole business, try to work with 'roles' rather than individuals. What is the best method in your organisation to manage these changes? Some organisations use workflows, some use ticketing systems (think IT issues) some use email some use a combination its about finding what works best for your organisation.

2. How records of changes are held

People get obsessed with audit trails but actually such records of change are useful for problem solving and troubleshooting.

3. What else the processor might need to consider?

There could be linked Master Data e.g. if Sales Category is 001 then other Master Data elements may need to change also. This is why having documented Master Data quality standards is important.

4. A sense check to ensure that records have indeed been changed as requested

It does happen that people get distracted, a system error, a misunderstood rule, unknown background configuration can all result in changes not taking place. Making the change is NOT the end of the process.

5. What reporting is required to ensure appropriate access and visibility for those requesting change but also those processing change?

It is almost impossible to manage Master Data without appropriate reporting. Of course there are issues to consider with privacy and commercial sensitivities. However you must be able to see the Master data for which you are responsible in order to analyse for inaccuracies, inconsistencies and make informed decisions around Master Data changes.

It is possible to employ the same Technology that you might choose for creating Master Data to Maintaining Master data. These offer robust tools for prescribing rules and validations for your Master Data. However you must know enough about your Master Data in order to be able to articulate those rules for configuration, be confident that they won't change frequently (or have robust processes to manage these changes), affect sufficient volumes of Master Data for ROI and finally be confident that you have the right culture within the business to deal with the inevitable 'computer says no' scenario.

Another scenario to consider with Maintenance is the requirements to make similar changes to many thousands of records - or MASS updates. MASS updates have the potential to create complete chaos in your systems, they are really mini data migrations, and you didn't go through that process lightly. The positive is that it is an efficient way of ensuring multiple records are updated consistently without keying errors. If your organisation has a well thought out testing and development environment it might be possible to do a trial run and mini UAT for sensitive changes.

The key steps when undertaking MASS updates are validation and authorisation of the Master Data to be changed then reconciliations to ensure the Master Data has changed as required. Where possible for changes that occur frequently with similar Master Data it would be worth considering building templates, I particularly like templates where you can download the required Master Data, make the necessary changes and then re load the same template.

So its easy to see now how quickly Master Data can be degraded, some of the reasons this occurs and some steps to take to help prevent this occuring.