One of the biggest issues I have with most MDM implementation is the sacrificing of assessing data consumer requirements in deference to data consolidation. In general, my complaint is that the creation of a master data repository does not guarantee any creation or improvement of value to the organization unless there are clearly-defined ways in which the master data sets are to be used.
But as organizations gain more experience in socializing the use of master data and developing use cases that demonstrate the value, they will begin to see similarities in which the key technical capabilities that make master data management “work” can contribute to business processes in a more standard manner. At the same time, these capabilities are integral, by themselves and in combination, to a wide variety of business processes, and there is value in packaging those capabilities so that they can provide advantage in different ways.
As an example, during a recent conversation about the topic of authenticating and authorizing external vendors to access a set of internal applications, one of our customers asked whether they could use the MDM identity resolution methods used for customers as part of the vendor identity management implementation. In other words, they saw the value in the technical capability and essentially wanted to use MDM components to build their business application. Other examples include data standardization, the implementation of data controls using data validation rules, as well as data cleansing.
The real value, though, occurs when the developers evolve libraries of prefabricated components that rely on the MDM capabilities. By plugging these components directly into the business applications, the business consumers can easily create MDM-aware applications. While many business processes can benefit from MDM capabilities (such as identity resolution or the use of a unique entity identifier), the methods by which these capabilities are provide are largely irrelevant to the business user. Encapsulating MDM within predefined components provides the benefits but does not force each user to become an MDM expert. Customer data creation is a good example: embedding customer data search and match within a “access customer record” service will prevent the creation of duplicate new records when the new customer already exists, but create a new record if necessary and this can be completely opaque to the invoking business process.
To hear more details on the topic of this blog series, you can listen to the replay of this Webinar: “Experts Share How to Launch an MDM Program Quickly & Successfully.”