This is a relatively simple conceptwhereby the hierarchy of various data records and elements is represented. For example, you may break company geographies or markets into EMEA (Europe, Middle East, and Africa), then by country. You may have account hierarchies represented as group accounts, then regional accounts, followed by local office accounts.
Now that we know what MDM is from a theoretical standpoint, we can turn to the considerations for implementing MDM.
As part of the fundamental design of an MDM strategy, consideration should be given to the system landscape, budget, and technical capabilities within an organization for implementing MDM. Several models for implementation exist and can be broadly bucketed into the following categories:
These different implementation methods are explained here.
A single system can be identified as the source of record or definitive source of information. All data operations are performed in that one system or application. This implementation model is extremely simple, and therefore doesn’t lend itself well to organizations of siloed departments or where data federation is necessary. Take my experience of the car dealership. I’m represented twice in the IT enterprise, as a prospect in one system and a qualified (and converted) sales lead in another. This, therefore, is a case of two sources of record (known as data silos) existing in the IT enterprise in the car dealership. This scenario only lends itself to the most simple of IT enterprises, where everything is managed from one application. It may be the case that Salesforce is used for sales and service, with simple integration to a finance system for the issuance and processing of invoices. Salesforce is the system of record, as the finance system doesn’t have any operations performed in it directly; it effectively acts on the instructions of Salesforce.
A central registry links data from multiple systems together through the use of IDs and matched records (which can be cleansed and de-duplicated when identified). Master data changes are still made in the respective source system, with a single source of truth being created on demand by pulling together data from source systems in real time when needed. When it is difficult to determine an authoritative data source in an organization, this method may be suitable. There is a cost consideration as a system to be used as the central registry may not be available prior to implementing the MDM strategy, and additionally, there are processes associated with the population and maintenance of the registry over time.
Master data, as identified from multiple sources, is combined to form a golden record, or single source of truth. Any updates to the golden record are applied to the original sources, typically using middleware. There is a cost consideration to this approach in the implementation of the middleware processes to facilitate data updates to the source systems. This is probably the most common implementation scenario when implementing Salesforce, as it typically is introduced to the IT enterprise to be the definitive source of truth. In order to get there, however, data must be taken from source systems. In short, if there is one system identified as a single view of a customer in an organization, and a number of downstream systems require updating when customer information is updated in Salesforce, this approach is most suitable.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
