In a previous a post we discussed the importance of the master data Convergence Hub™ pattern.
While researching this pattern, we realized that many companies were still struggling with the right type of MDM deployment to support their business requirements.
A Common Misunderstanding
As an MDM software vendor, we have seen the emergence of MDM solutions that exclusively promote a data governance strategy based on a centralized MDM repository.
In this approach, business users manually collaborate by entering and maintaining the enterprise master data in this repository. Master data from the repository is then distributed to the enterprise applications.
By claiming that master data management is first about data entry and data governance, solution vendors forget to mention two critical points:
- Most of your critical master data (customer, products, etc.) already exists in your transactional applications. It is scattered across all systems, of course, but it is already there!
- Setting up a “governance” strategy in such a way means that you will have to review all your existing master data entry processes and adapt them to a new single data-entry application, which becomes a new critical element in your environment. This is, simply said, an enterprise big-bang.
If you look at these two points, you should think of these solutions as very intrusive. if you are not convinced, look at the example of a Customer MDM data entry hub:
A sales representative receives an order from a customer and a contact that do not exist yet in the ERP application. Can you imagine this sales representative calling a different team – the MDM Data Governance Team – and asking for the new customer and contact to be created in the MDM central repository? This sales representative would wait for another two to four hours for the new customer to show up in his ERP before being able to enter his order?
We all agree that it is not acceptable or realistic.
MDM Hub Styles
Analysts (more of less) agree on the following styles of multi-domain MDM hub deployments:
- The Consolidation Style: In this style of hub, you leverage master data from your existing applications, send it to the MDM that cleanses it, consolidates it, and then make it converge to a certain version of truth.
- The Registry Style: In this hub, master data remains in the existing applications and a global index is created in the registry hub to keep track of it. Data Federation software is used to query this master data.
- The Centralized Style: In this model, you set up a central master data record authoring system. All your master data entry processes should go through the hub regardless of your existing application processes.
- The coexistence style: This is typically a hybrid approach where you would combine the three above.
Given that, what should be the optimal MDM deployment style for your MDM project?
Well, this will not be as simple as choosing a pair of shoes. An MDM project brings organizational changes, and therefore should be considered in terms of adoption lifecycle and organization impacts.
MDM Initiative Lifecycle
In this section, we are making the assumption that there is already a clear understanding of the business value of the MDM project that you want to develop. In other words, that not only you know which domain you want to start with – see this previous post on this topic -, but also that you understand the return on investment this project brings to your enterprise.
The following figure shows the lifecycle for an MDM Project.
The steps of the lifecycle are detailed below:
- Identify Applications: Identify the existing enterprise applications that author the master data relative to your project. In other words, where is the data “created” and “modified” in the first place?
- Identify Processes: Identify the critical business processes around this master data and start setting up a team of business analysts and data architects to expand your understanding of the domain. *Do not* modify the exiting processes. There is no need to fire a big bang in your enterprise.
- Consolidate in a Hub: Implement a Consolidation Style MDM hub: Set up an initial data model that is a super set of the requirements you have gathered in point #2. Deploy it and start loading it in real-time or in batch depending on your needs. This MDM hub would ideally include data quality processes, enrichment and standardization process, matching, de-duplication and data certification processes, data version control process, etc. Data stewards would connect to this hub regularly to monitor the quality of the data that is consolidated, and take human actions for error corrections and duplicates validation.
- Consume for Analytics: The first consumer of the master data should be the Data Warehouse. The first benefits that you will see from an MDM project relates to analytics. The key performance indicators and your daily dashboards will show accurate consolidated figures that are based on trusted master (golden) data. For example:
- Your Top 10 customer list will be updated because the hub has de-duplicated and consolidated your customer master data. Consolidated customer master data will show new opportunities for cross-sell and up-sell.
- Your Top 10 suppliers will be consolidated as well and allow more accurate spend analysis.
- Your products figures will roll-up to the appropriate product families and nomenclature.
- Consume for Operations: The second phase should focus on getting the value of this consolidated master data down to the operational systems to make operational decisions on accurate data. You would achieve this by choosing or combining one of the following methods:
- Re-injecting the golden data from your consolidation hub down to your existing transactional applications.
- Setting up mash-up screens that allow data owners access this master data directly from their applications. In terms of technology, you would use the web services automatically exposed by your consolidation hub and data federation software to build your custom screens. As a result, your operational users will get a 360° view of their master data. For example, the financial services will be able to see, in the same screen, the marketing campaigns that targeted a given customer – from the marketing database – as well as the sales process into which this customer is engaged – from the CRM system, all this coupled to the financial profile of the customer. Such a mash-up is simply not possible before the MDM project since the 3 applications do not share the same customer ID.
- Centralized Authoring: The third phase – which is an optional phase – could be the review of some existing master data authoring processes to have them centralized in terms of governance. This means that you decide to stop entering master data in your existing transactional applications and you set up governance human workflows in the consolidation hub to create and maintain this master data. Note that at this point your consolidation hub becomes a “coexistence” hub. This last step in our cycle (also the first one in the centralized repository approach) is the most invasive. It should be taken with great caution as it has a great impact on operational productivity.
In essence, when you look at this cycle, you would rarely start an MDM project directly from a unique centralized data entry hub. Even if the centralized data entry hub allows you to integrate external data using traditional ETL or Data Integration technologies, the cost of setting it all up, combined with the cost of defining your data entry governance processes would make you miss the point.
So first things first: Set up a true consolidation hub for analytics then try out some federation features for operational reporting, and then finally, move slowly to a coexistence hub to allow data entry.
Needless to say: Semarchy Convergence for MDM natively supports this path to the success of your MDM project.