In my previous post Secrets of Operational MDM – Part 1 : Choosing System Behaviors, we categorized systems connected to our MDM environment as Consumers, Managers and Creators of master data. We know that systems often have different sets of behaviors for different entities, and can have multiple behaviors for a single master data entity. For example one system may consume and manage customer data but create and manage product data. These behaviors will guide the best way to integrate these systems. In particular, we will look how each system can best contribute master data into the MDM environment—we’re not looking at the data model, but rather understanding which systems will contribute records to be mastered.
Consumers – Systems that only consume master data without the ability to create or edit master data, by design, do not contribute any records to your MDM tool. Since these systems do not provide any new master data information, they would not be used to contribute any master data entities. Bringing data into MDM that is consumed by these systems would just add to record volumes without contributing any new information. These system often do have transactional data that is important, but that data can be integrated outside the MDM environment.
Managers – Some systems manage master data but do not actually create new master data entities. They will also consume master data, since they’d have nothing to manage otherwise :). From these systems you should bring into MDM all master data entities actually edited or augmented by these systems. If possible, avoid bringing in records that the managing system has simply consumed and not touched. This, incidentally, is an example of a system exhibiting multiple behaviors (consumption and management) for a single entity type.
Creators – Finally, there are systems that will actually create new master data entities. Usually these will also manage/edit entities, and will sometimes consume entities. As with managing systems, master data entities that are created or updated by these systems should be added to your MDM tool—but any entities simply consumed should not be contributed. For the creation of new entities in these systems, adding a search before create capability will avoid the creation of unnecessary duplicate records.
One additional note: editing data takes effort, so it is very unusual for operational systems to simply make “bad” edits to master data entities; data is typically only edited to support some specific need. Of course sometimes these needs are not shared, and other systems may see this as “bad” data. However, the ability to see the all operational versions of master data is almost always helpful. This if often truest for the systems that have edited/impacted master data the most, even if data from those systems aren’t “trusted”. Configuring survivorship/trust rules in MDM allows this data from managers and creators to be brought into MDM in order to get the most value from the data while preventing any undesired changes to the trusted master data.
The power of MDM is that it allows each operational system to keep data fit for a specific purpose, while enabling sharing the same entities across different systems. To do this, you really want each and every version of you master data entity to be available. The best news is that if you get this right, it will also improve business intelligence at the same time. Don’t forget insights are great, but actions are better. With proper configuration of operational MDM insightful actions become possible.
The next and final installment of Secrets of Operational MDM will look specifically at how operational systems should consume data from your MDM environment.
