If you are working with data, from time to time you will be confronted with “multimaster” situations where the same kind of information (typically client, product, installed base etc. data) is managed in multiple systems in parallel.
Let me give you an example: one of my projects some years ago. Our goal was to cleanse and sustain high quality of master client data. The data was managed in a CRM system and other systems in parallel.
But why did our client have all these systems? Why didn’t they build just a single client management system? Didn’t they know that everything else was not good ab ovo?
Well, it is easy to make this statement now. But historically the story is a different one.
Some years back all business lines were happy with their own systems and processes. (Hands up how many of you have seen this…) Some of these business lines were even completely different companies. There was no valid business case justifying the integration of the client data.
Also different systems stored different information about the same client. For one business unit a client meant a corporate, for an other unit a private person.
The business requirements for the systems managing client data were captured in separate projects. One of the projects finished one year ago and one in the last century. Of course one of the systems was designed to serve the needs primarily e.g. of the sales team, the other system design concentrated on the marketing needs, and so on.
How many times, do you think the sales team spoke about the client during their project? I guess the client was the single central topic of most discussions. I would bet the same applies to the marketing project. Even if the two projects would have had run in parallel, the chances that the projects share the same understanding of the client in terms of processes and data is (at least in the real life) surprisingly small. Why? The respective project teams were responsible for their own scope and budget and had to decide what aspects of the client are in scope and which are not.
Imagine the second project were started 2-3 years after finishing the first: how many people would participate in both projects? (Attrition rate.) Is the first project documented in a way that the knowledge gained can be reused in the second project? Well, usually not.
After the systems were finally created some teams were interested in more data their systems could manage. An easy and cost-efficient solution was to create some spreadsheet-tables to store some specific attributes in some special cases. The more so as this could work without involving any other business lines or IT. Anyhow the business team was under pressure and needed a solution ASAP – no time for lengthy discussions and no energy to convince the whole corporate.
Later times changed. Marketing and sales both wanted to have all client information stored and managed in a single, central place. The world has changed and there were dozens of viable business cases requiring to do so (up-selling, cross-selling, uniform communications, GDPR – just to name a few).
Of course designing the CRM the goal was to make it the single system managing client data. Sadly the task of collecting, cleansing and syncing already existing data was so huge that the integration was never fully finished in fact. Why? Because before the CRM implementation nobody integrated the client data in this depth in a permanent read-write manner and hence nobody had a realistic estimate on the complexity of this task.
When I joined the project the same client data was partially synchronized automatically, partially manually and partially… well, not at all.
The business processes were modified to work around this situation – somehow. There was a responsible person for the CRM system – but there was no single person responsible for the client data.
If you realize that this could be your organization as well, you might be right. This situation is more common then participants of an analytics conference would admit.
It is important to emphasise that a multimaster situation is usually a consequence of a series of valid business decisions.
This is especially interesting now when most companies want to exploit data in a more advanced way then before. Sadly with questionable data quality no really valuable analytics can be done.
In our project IT experts were working on finding a solution. They were trying to figure out e.g. why client types for marketing are entirely different from client types for sales. They involved business experts but somehow there was no agreement in sight.
In my view the root cause of data challenges lies within the business processes. In this project it was also not different: IT tried to solve a business problem – and it did not work out.
In the next blog entry we I will give you some insights what we did to get rid of this situation and how we managed to give business quality data.
(Please note: the above client situation is based on actual client projects. Some details were changed to comply with contractual obligations.)