Generally speaking, Master Data Management is thought of as being leveraged in four different ways in an organization. These approaches are, for the most part, exactly the same for the management of customers, vendor, employee, product master or any other master data object in an organization.
Traditional | Registry | Co Existent | Consolidated
Centralized-Customer-MDM-supporting-Transactional-use
Consider what you hope to achieve from implementing MDM. Pretectum observes that implementing customer MDM can be considered, on the one hand, to help meet compliance and regulatory obligations. It can be considered as a mechanism that reduces risk and ensures business process optimization too. For some, it is simply recognized as an essential piece of the puzzle in having a better view and understanding of the customer. In reality, though, MDM and customer MDM, in particular, can serve to address all of these needs and potentially more.
Pretectum’s view is that one critical aspect of all of this is the establishment of an authoritative, consistent, and correct understanding of who and what a given customer is. The benefits that flow from managed and controlled understanding under a CMDM could range from cost and operational savings in maintenance of the customer master to reduced loss and risk through collections and fraud avoidance when working with the different buyer and consumption audiences and prospects accompanied by increases in confidence and trust amongst your employees and associates.
Traditional and Legacy
Typically an organization starts with a traditional approach to MDM. I need to sell something to customers, so I need to establish them so that I can provide them with a quotation, deliver to them, or bill them. For that, I need to have enough information to complete the task at hand. This type of MDM setup is focused purely on support of the transaction and often starts in the record-keeping system that is used to perform the transactions.
That might be the Point of Sale (POS), the Customer Relationship Management (CRM), or the Enterprise Resource Planning (ERP) system. In a medical setting, that might be the Patient Administration and Billing System (PAS), and in Banking it might be in the Retail, Credit, or Lending system. These types of systems typically have a way of defining all the attributes of the customer based on a definition in the system that prescribes what needs to be provided to perform the transaction.
Control and management of the data are typically done at the record level with varying degrees of governance and control. The challenge with this approach is that often the master record is limited in its usefulness to other systems and sometimes not even shared or made available to other systems. So, instead of being a customer master, it is simply a transactional master which may be limiting for some parts of the business since the master may not be elaborate enough for all the divisions’ needs. The control here is at the application level dictating all capability within that application framework. Redundant listings are therefore inevitable with the risk of wastage and misalignment between systems and divisions.
For most, this isn’t considered as MDM at all though within a given System of Record (SoR) the customer entity, for example, may be considered the golden master if all other systems know about this system and what it contains. SAP, ERP, or CRM for example, might be considered your nominated customer master.
Coexistence
The coexistence master data management approach may see data from the transactional masters across several systems, being consolidated to a single customer view of the customer master. This is typically updated posthoc and periodically synchronized reflecting all the external keys. The content of the master from various systems may be inconsistent and more importantly, no single entry is necessarily considered to be more correct and appropriate than any other.
Conflicts between records can and do occur and because the authoring is undertaken in the different systems, the result may only be useful for generalized reference and may not be considered as a true or absolute authority. Further, if harmonization of the redundancies between the entries is not remediated, there may well be duplicated and conflicting records.
The harmonized records then become known as the “golden nominal” of the customer and are held centrally but updated in principle, by regular updates from the surrounding systems of record. The problem remains, deciding which updates are the most correct ones. Often most suited to organizations where there is no real authority or ownership of the ‘whole’ description of the customer, mirroring the data is deemed the most important objective but often with shared responsibility by all, for what defines the golden nominal. This can be a risky approach if the control of the master is deemed essential. The Pretectum CMDM supports this approach as one way to maintain the customer “golden nominal” but you also need to keep in mind that the optimal configuration is with the Pretectum CMDM being able to provide suggested updates back to the satellite systems.
Registry
A registry master data management approach is primarily employed as a central index linkage to the concept of master data, in that the master records are authored across the different systems, but with a linkage that is commonly referenced by the different systems as an external key. Just as for the transactional and coexistence approaches, the authoring remains in the satellite systems, and at best, the registry serves as a skeleton that contains essential attributes of the master that are common across the systems.
Often the data is simply used for interrogation, lookup, or reference. Because you are working with a skeleton of definition, there is relatively loose control over the customer master because this point of reference only provides a sliver of definition to the customer master. External keys become useful if held.
The Skeleton Key becomes an authority of sorts, but only if it is referenced in the peripheral systems, as an external key for referencing and minimization of duplication. This approach is fast to implement and provides some degree of central and distributed master data governance if all participants agree the skeleton can operate as a central reference point or authority. The Pretectum CMDM can be used in this way, never touching your source systems but it may never fully operate as the latest and greatest version of your customer master.
Consolidated
Used primarily to support business intelligence (BI) or data warehousing initiatives. This is generally referred to as a downstream MDM style, in that MDM is applied downstream of the operating systems where master data is created.
Here the MDM Hub is the system of reference for all reporting, search, and reference purposes and it likely stores all the master data needed with no need to connect to or be connected with backend systems.
This consolidated customer master can operate in a complete vacuum because it is self-contained, simply taking feeds from the satellite systems – beneficiary applications beyond the CMDM enjoy the benefits of the collated records while sources maintain business as usual. The Pretectum CMDM can be used in this way.
Centralized Customer MDM supporting Transactional use
With the Pretectum CMDM, we believe that one of the most optimal ways to approach MDM is in a centrally governed way, adopting a centralized customer MDM approach. Here the Customer MDM Hub is both a system of reference and a system of entry – it can update and receive all necessary data updates from any backend systems – we do this by making use of APIs.
From within the centralized Pretectum CMDM, you have access to schema master data definitions, including data domains for reference and lookups, and then whatever subordinate datasets make full or partial use of those definitions. You also can have derivatives of existing data and permission-based access. Forms are available for manual data curation and bulk replacement and appends are also possible. Most importantly, you can do everything through a rich browser-based cloud UI or you can use API-based methods. All customer master data creation and curation are managed from the Pretectum CMDM hub, and satellite systems outside no longer create or amend the master, instead, they subscribe to syndicated data from the CMDM for any new records or updates.
As suggested by many in the industry, the centralized MDM is the ideal implementation but also the most challenging to implement because it requires discipline and a change in the data ownership philosophy of a given organization. You might often see the implementation of a centralized Customer MDM as part of a digital transformation initiative.
