If CRM has been a struggle or a passion for you then Infosys’ CRM blogs is the place to be in. Come join us as we discuss the latest trends, innovations and happenings which will have a bearing on CRM.

« SAAS - Where is the money, honey? | Main | Customer Master Data : Plan or Perish »

Customer Relationship Management/Enterprise Application Integration/Business Intelligence and Data Warehousing (CRM/EAI/BI) products can fulfill MDM Needs - Biggest Myth!!!

Fully fledged Master Data Management (MDM) packages have been in the market space since the turn of the decade and many fortune 500 companies have implemented the MDM solution to achieve tremendous value within their industry domain. I have been in the MDM Consulting stream for the last couple of years but still realize the need to evangelize the need for an MDM solution among peers within the CRM/EAI/BI domain space. Many of the renowned implementation using matured products such as CRM, EAI and BI has put forth a view that the respective products within various domains can indeed be customized to meet the MDM specific requirements. This is predominantly wrong for the very reason that just because each product stack (CRM/EA/BI) can fulfill a partial subset of requirements within the MDM domain, the central core of an MDM suite (360 view of customer including Data stewardship process to manage the golden copy of the customer) cannot be customized on a CRM/BI/EAI product stack. This blog helps in acting as a myth buster for some of the common misconception around CRM/EAI/BI products fulfilling the MDM requirements.

CRM is able to handle all the customer attributes and can manage 360 degree view of customer/CRM does handle customer demographics- Myth buster

Some customers think that a CRM product implementation can manage customer demographics and can fulfill the need of getting a single view of customer in the enterprise. The claim though partially true, cannot meet various functionalities around the Customer Master data. A few are listed below

  • CRM products come with a data model to manage customer interactions and customer management, however it is not able to support the multi-form, multi-domain requirements that truly represents a 360 degree view of customer.
  • CRM products are not able to group the customer demographics requirements into customer preference management.
  • CRM  products are not truly designed for Service Oriented Architecture (SOA) based master data services, to facilitate Create Read, Update and Delete (CRUD) transactions on Customer data from various systems in the enterprise

EAI is able to provide the true integration between disparate Customer information systems- Myth buster

I have seen many of colleagues within the EAI space mentioning that EAI product has all capabilities to handle Meta data related to Master data entities and can transform and share the data with disparate systems. Though it is partially true, EAI products fall short in meeting various requirements in the MDM space.

  • EAI products typically are not packaged with pre built Schemas for multi domain, multi form master data entities like Customer, Product, and Location etc.
  • EAI products seldom come with data consolidation frame work and built-in data quality features.
    Even if one want to leverage existing EAI and CRM investments and convert them as a custom MDM solution they  may end up undertaking massive customization and having higher footprint with less than optimal performance
  • EAI built over CRM data model cannot meet the Non functional requirements stated in a typical MDM project.

BI does handle consolidation among various customer repositories- Myth buster

Additionally I have seen references where many customers treat their BI solution as a customer master data hub. The concept itself is dismal, since a truly integrated transactional multi channel ecommerce system requires real time data which cannot be met through a BI solution. (Key channel systems ended up getting stale data). BI packages are built up for OLAP (for reporting and analysis purpose), but not to maintain and manage transactional Master data. Though BI packages come with Data consolidation frame work (summarization and aggregation) they are not able to meet the functional requirements of a true MDM solution.

  • BI products do not support transactional data and cannot fulfill the real time transactional data requirements mandated in most domain space.
  • Typically BI products do not come with SOA frame work to support the primary needs of data synchronization required in an MDM product.

My personal experience so far with clients who have tried to retro fit their existing CRM/EAI/BI products into a fully fledged MDM customer data hub have failed  Either their existing CRM system could not meet the transactional requirement required in terms of performance or data synchronization and/or EAI system having limitation in providing the multi-domain, multi-form customer focus and/or BI systems failed to provide the real time information for business critical systems like Banking, Telecom, and Insurance domain etc.

This discussion is not definitely old wine in new bottle, and many a times there requires a need to convince the customer (both internal and external) the need for procurement of a commercial of the shelf MDM solution to meet the extensive Master Data management requirement over a much hyped view of converting their existing investment into a fully fledged MDM solution. Though it is prudent to carry out a fit-gap analysis against their existing CRM packages, it is extremely important for clients to understand the limitations of CRM and other domain packages in fulfilling MDM needs.



As the author rightly said my experience is also that the MDM requirements cannot be met by individual applications representing functional blocs. Of late, the convergence and divergence of businesses done by a company (many verticals) leads to MDM need.
In my opinion, the starting point is to have/prepare an enterprise information model.
Then identify the same data objects used by different applications. This is to start with reference data of customer (customer category, etc.), bill (bill cycle, etc.), supply chain, etc. and then goes towards little complex reference/less dynamic data like products & service data master preparation followed by dynamic entities like customer, order, etc.

After identifying/modeling the entities, it is time to prepare a business case for mastering the data followed by preparing a road map on how to master the data of these entities. Then comes fit-gap analysis for the COTs products of MDM.

Identifying the key entities that need to be part of the MDM solution is one key thing to do in the beginning. That brings up the importance of Data Governance in MDM context. It is extremely important to prepare a framework for Data Governance in the very beginning of the MDM initiative. When data is sourced through multiple channels, it is common to have data duplicated and some key data elements to become inconsistent with respect to rules and standards. When critical business data is duplicated and in conflict across systems, it is difficult to establish its reliability or establish source of the data. These challenges result from poor data governance and can result in productivity loss, higher operating costs, profit erosion and noncompliance. Support to Data Governance is one key thing to be analyzed while carrying out fit gap analysis.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter