Blog

MDM – Is this a Straightforward Implementation or an Iceberg Project?

Increasingly here in the UK, I am getting asked about whether master data management (MDM) has a role in business intelligence (BI). The obvious answer is that master data management systems can play a significant role in BI by supplying the dimension data needed in BI systems. Of course, MDM systems also provide operational systems with this core data and with changes to such data

On the surface, MDM looks fairly straightforward, and looks like it just involves integrating data into core data entity (e.g., product, customer and asset) data hubs and then managing change to such data. But is it that simple? After all, some vertical industries seem to be well down the road here (e.g., manufacturing) and are supplying dimension data to BI systems already from MDM data hubs. However, many people I talk to, across most vertical industries, are still trying to get to grips with the impact of MDM on their business. Why so I wondered? As I have researched more deeply into this problem I am not surprised at the hesitation as there is a lot more to this than first meets the eye. In the work I have been doing with clients, it is clear that introducing master data management hubs into a company is not the problem as long as these hubs are simply systems of record (SORs) and not systems of entry (SOEs). If they are just systems of record, then this in not really master data management; it is master data integration. In other words, changes to master data continue to occur in existing operational applications and these changes are trickle-fed to the master data hubs. However, if we want true MDM, then this means that the MDM system has to become a SOE, and to make that happen means that a company has to undertake a huge amount of business analysis work and application change management to wrestle the problem of master data management to the ground. I am already clear that this is a multi-year project.

While there is a thirst for master data management applications such as customer information management, product information management etc., companies have to think about the consequences of these applications on their business and on capital and IT resources needed to implement it. In my mind, there are all sorts of problems here. Looking at customer data, for example, the issue here is really to do with parties (people or companies, for example). A person can have multiple identities (e.g., an employee number, a customer number, a national insurance number, etc.) Also, in some cases, specific vertical industries such as banking assign even more identifiers to a party. In this case, they often use product numbers to identify customers (e.g., a credit card number, a mortgage roll number, etc.) such that if you have a two credit cards, a loan, a mortgage, and are an employee, you are identified differently across a range of line of business applications. Therefore, a party, for example, is awash with identifiers.

So the first problem is that you need to assign a Global Identifier to a master data entity and a mechanism to map all the other identifiers to the global one. Then there are the master data entity (e.g., customer, product, asset…) attributes that describe that entity. When looking at these attributes, the problem I run into is that many different line of business operational applications are systems of entry (SOEs) for these attributes. These existing disparate operational systems are therefore involved in distributed maintenance of that master data. In addition, in many cases, these disparate systems also double up as systems of record (SORs) for just the attributes they maintain. In other words, we have fractured master data with parts of an entity (subsets of its attributes) maintained by different applications. The consequence for many companies today is that they have had to put in place FTP and messaging solutions to move subsets of master data between systems in order to synchronise it in different applications. While this may have been manageable initially on a few systems, many companies are now at the point were they have FTP and message mania. We talk about XML messaging – well we spelt it wrong. It should take out the M and pronounce it EXCEL messaging!!

When I look at vendor offerings that talk about data hubs as a way to centralise master data, it is clear that these hubs can be systems or record but are a far cry from systems of entry unless you switch off all existing ways to update such data in other applications. Therefore, all I can see is that master data hubs can become the system or record while existing applications remain the systems of entry maintaining changes to master data attributes. Most people I talk to can get their head around that – i.e., line of business changes to master data are propagated to the master data hub. However, this is just master data integration. It is not MDM. MDM requires that the MDM system is the system of record and the system of entry and also that it manages and tracks all changes to such data over time. This includes things like product and customer hierarchies.

Companies therefore have to make sure that what they are buying can do all of this and not just master data integration. Even if an MDM solution can be both an SOR and an SOE, getting to that point is not easy. To implement this means that companies have to:

• Identify and model all the business processes they have in place in order to know what process activities are associated with changing master data – i.e., all SOE activities
• Identify and make a list of all functions in all existing operational applications that maintain specific master data attributes – i.e., that perform maintenance on that data
• Identify all screens in all existing applications that allow users to maintain master data
• Identify all duplicate functions across existing systems that are maintaining the same master data attributes so that potential conflicts in master data systems of entry are identified
• Start a change management implementation program that systematically causes change to line of business systems in order to
  • Weed out duplicate or overlapping functionality to stop master data conflicts in existing systems of entry
  • Change line of business SOE applications to switch off data entry screens or to remove master data attributes from line of business application forms
  • Introduce equivalent forms or screens in the MDM system to directly maintain the master data in MDM data hubs (this is a change from many systems of entry to one system of entry)
  • Understand the impact of that kind of change on existing line of business applications (e.g., line of business SOE systems may update more than master data in a specific transaction in which case the business logic in the line of business application may also have to change)
  • Introduce data synchronisation from the MDM system of record back to the line of business systems to keep these applications in sync
  • Change business processes to cause change to master data using the new process
  • Introduce common master data services that applications should call to access and maintain master data in such data hubs
  • Change existing ETL jobs to start to take specific master data from the MDM system rather than line of business systems to populate BI system databases
  • Etc. etc.

Looking at this, it is clear that in solving the MDM problem, the move towards a true enterprise MDM system as opposed to just a master data hub that integrates master data, is going to be a long hard slog. This is a multi-year program that is more like an “iceberg” project where there is a lot more to it than first might seem necessary.

My concern here is that part of the way down this road, many companies could hit a major roadblock in the form of packaged applications that act as SOEs for master data. An example might be CRM applications maintaining customer data. How can companies remove/disable screens or alter on-line forms in these packaged applications to switch to a true MDM system. It assumes all packages can be customised. Maybe in first tier packaged applications (SAP, Oracle packages, etc.) this is possible, but in other applications reality tells me we’ll be lucky if it’s the case. So reality states, therefore, that you may not get all the way to the true MDM promise land. The best thing is to keep advancing systematically as far as you can go.

Back