Extending transactional data elements in MDM Hub: Desirable or Unnecessary?
By definition Master data is core data which does not change frequently. The very objective of Master Data Management is to consolidate master data, cleanse, enrich, and publish to consuming applications, like CRM, ERP, Data Warehouses, etc. This leads to a belief that Master Data Hubs should only have master data like customer, product, assets etc and there should not be any (or limited) transactional data in MDM Hub. E.g. Sales Orders, Opportunities, Service Requests, Invoices.
Contrary to the above, MDM vendors like Oracle are offering MDM Hub license with additional options of integrating Sales Hub, Service Hub, Activity Hub with MDM Hub. IBM and Siperian too have a very flexible Data Model and their out-of-the-box data model could be extended to include transactional data elements. What are the real implications of this? Would the Organizations that are implementing MDM or have plans to do so in their IT roadmap, be better served by extending transactional data elements in MDM Hub?
The answer could be both yes or no and depends on the Organizations’ Business Case for MDM. Moreover, it needs good consulting proficiency on the part of SI’s to help clients refrain from establishing incorrect expectations from MDM. MDM is not supposed to replace any existing transactional application; it is to consolidate the master data from various application silos and to aid the business functions that need accurate representation of master data. Expectations from MDM like ‘Ability to raise customer invoices’ or ‘Ability to Create Sales Orders / Service Requests’ should be laid to rest, even while preparing/validating the Business Case. Usually, during the initial assessment of MDM programs, we have seen a huge list of master data (customer, product etc) related pain points being set forth by client IT after duly collating such pain points from various departments. While it may be prudent to analyze the list and recommend solution to all pain points, the customer is better served if the non-MDM pain points are identified and an alternate solution proposed to address those.
This being said, MDM application may still have the Sales, Service and Activity related details but it should only facilitate establishing the accurate customer profile to help with customer segmentation, prepare target audience for campaigns, various reporting purposes etc.
The MDM space continues to be dynamic and as the leading vendors (Oracle, IBM, SAP) and niche players (Siperian, Initiate etc) carry on with their roadmap, we will witness quite a few new products being introduced and in relatively newer domains E.g. Site Management (to streamline supply chain) etc. In addition to this, the concept of Enterprise MDM, or a true ‘multi-entity MDM’ has already been widely recognized and the newer versions of leading packages should see support for both ‘party’ and ‘product’ based entities. This would make MDM consulting even more exciting and would call for greater refinement in MDM solution offerings E.g. Data Modelling, Data Rationalization, Consolidation etc.
Comments
Hello Anshuman,
This is an excellent post. Recently I have seen many clients looking at converting their MDM solution as an all encompassing transactional system. This is against the ideology where you utilize the MDM package for its core capability i.e. managing master data, with a limited amount of customization to help manage the strategic way an organization manages its master data (what differentiates the organization from other players in the same business domain)
Posted by: Jairaj | May 18, 2009 8:45 AM
Anshuman,
The compilation was very good. I also think, to have enterprise level MDM, there is a need to do the enterprise data objects/entities and modeling first. For each important entity like customer, product, address, order, asset/product instance, bill, service, supply chain related entities (I am not good at these), payment, etc.
1) Consolidate the referential information from each application and now try representing at a common place.
2) After this, with regular MDM techniques all the information can be collated.
Of course, there will be some basic data entities like time that needs to be modelled and referred by each application whether it is MDM or regular transactional applications.
In fact, every industry and company is facing this problem and as you rightly said, it is not only exciting, it is the way that one should offer MDM consulting / solutions. All Oracle/SAP or niche players' products are only enablers.
Posted by: RajaSekhar Ravi | May 19, 2009 5:41 AM