MDM Implementation – Managing Expectations!
Managing customer expectations – this is a big topic. We restrict ourselves to discussing a couple of expectations from customers when they plan to implement an MDM solution. MDM is a growing field – people have limited knowledge and there is no clear leader in MDM product offering. So obviously customers will have certain expectations and inhibitions about the MDM implementation.
First the inhibition – “We will implement MDM but we will not allow it to act as a single source of truth. Our current masters will be in place until we are satisfied with the new system.” Sounds logical right? But we have this typical problem for MDM implementations.
In recent times, we are coming across few instances where companies introducing MDM in their landscape, want to hold their current masters. The new MDM master is expected to get information from the current master and feed it to downstream systems. This will create problems in implementing the MDM program successfully. Typically, the legacy masters are meant for some transactions and hold the master data (Product/Supplier/Customer) as an additional responsibility. In addition, there could be multiple masters for the same data. Those systems are not capable of incorporating best practices of MDM and that is the main reason for any company to implement an MDM program. When there is inbound data from multiple masters – ensuring the data quality inside MDM system is a pain. Also, as the legacy system continues to own the data there could be changes in the data after the last update into the MDM system – this leads to obsolete data flowing into downstream applications. The premise on which MDM is conceptualized is that it should own master data and act as a single source of truth for master data. But the concern of the customer is genuine…what to do?
The solution is to identify a set of data (that belongs to one product category), completely migrate it to the new MDM system and retire the legacy master after the cut-over date – that is, after cut-over date, for the migrated category, the new MDM system will be the only master. Initially, this could be done for a smaller non-critical category or a new line of products for which there is no legacy master data. This helps to tide over the initial problems involved with migrating it to a new system and once the new system is stable, more categories may be migrated and finally, all other master systems will be retired.
The next one is an expectation…
We also see a trend of expecting Product MDM systems to handle transactions – this will dilute the purpose of Product MDM systems. Product MDM systems are meant for managing master data and giving the right data to subscribing applications. Also, most of the major vendors are not supporting transactions in the Product MDM system. This means a custom component is required to handle the transactions. Having a custom component is not advisable when other out-of-the box applications are available for transactions. Maintaining the custom component will involve higher costs.
Implementing partners tend to address all the client’s requirements even if it means developing custom components. This will only meet their expectations but not add value to them. It is the duty of implementation partners to set the right expectations on MDM system. Also, they have to articulate the need for incorporating MDM best practices during implementation.
MDM implementation best practices? Will come back soon with that!
Comments
Krithivasan,
The terms that “MDM cannot be used as a transactional hub” is a misnomer. If you refer to Gartner, there are four styles of MDM implementation. These are centralized, registry, consolidated and transactional. IBM MDM server and Siebel UCM is the key transactional MDM. These operational MDM are able to manage transactions as high as 100-200 transactions per second.
However I agree with the part that MDM should not be used as a silver bullet for managing non master data E.g. card life cycle management, application life cycle management, offers management etc. Each of these needs to be managed in different systems. If you believe in the term Core competency, proponent of the concept is the leading management guru C.K. Prahlad, we can extend this thought into MDM space as well. Let the MDM system be your transactional hub for managing customer data and the custom application be the transactional system for managing offers, application and card life cycle.
Posted by: Jairaj Asok Kumar | June 5, 2009 12:49 PM
Thanks Jairaj for your comments. We faced certain problems when product MDM is asked to manage quotes. We have other core modules which can handle transactions on product data. This blog is based on that experience. I will explore this further based on your comments. Thanks Again !
PS: The blog content is slightly modified to avoid ambiguity.
Posted by: Krithivasan | June 8, 2009 02:48 AM