David Saunders general manager, Siperian Europe, tells DCM the seven deadly mistakes to avoid when writing an RFP for Master Data Management

Critical master data management (MDM) functionality can be easily overlooked when request for proposals (RFP) are narrowly focused on a single business data type – such as customer (Customer Data Integration) or product (Product Information Management) – or on near-term requirements within a single business function.  Consequently, IT teams and systems integrators alike run the risk of selecting and investing in technologies that may be difficult to extend to other data types or difficult to scale across the organization.  Worse, such solutions will likely require costly and extensive custom coding in order to add additional business data entities or data sources, or to extend the system to other lines of business or geographies.  In order to avoid these costly pitfalls, bolster the return on investment, and reduce the over-all project risk, it is important that your RFP include key business data requirements across several critical business functions including sales, marketing, customer support and compliance.

To avoid the most common mistakes made by evaluation teams in looking for MDM solutions and to lay the foundation for future success you should make sure that key components are built into your master data management RFP. There are seven key MDM requirements you should include in your RFP to ensure you are laying the foundation for a complete and flexible MDM solution that will address your current – and future – requirements. For example, while it is desirable to reach a point where there is a single best version of what a customer is to an organisation, you do not want to do this at the expense of a more convergent, multi data type platform. In other words, you do certainly do not want to be implementing a quite separate infrastructure in order to establish, at a later stage, say, branch profitability.

Mistake 1:  Failing to ensure multiple business data entities can be managed within a single MDM platform
When you select and deploy an MDM platform make sure it is capable of managing multiple business data entities such as customers, products, and organizations all within the same software platform.  By doing so, system maintenance is simplified and more cost effective which results in lower total cost of ownership.  A less favorable alternative is to deploy and manage separate master data hub solutions that each manages a different business data entity.  However, this approach would result in additional system maintenance and integration efforts and a higher total cost of ownership.  Another advantage of an MDM platform which can handle multiple data types is that implementation can begin with a single business data entity like customer, and can later be extended to accommodate other master data types – resulting in rapid return on investment.

Mistake 2:  Failing to ensure the MDM platform can work with your standard workflow tool
Workflow is an important component of both MDM and data governance, as it can be used to approve the creation of a master data entity definition and to determine, in real-time, which conflicting data entities survive.  Workflow can also be used to automatically alert the data steward of any data quality issues.  So in preparing a master data management RFP, it is important to raise the question of how the MDM platform will integrate with the standard workflow tool that you have selected.  Several MDM vendors bundle their own workflow tool and may not offer integration with your standard workflow tool. Remember the key to lasting Data Quality is to have an accurate and sustainable process around the creation, modification and consumption of data.

Mistake 3:  Failing to ensure the solution supports complex relationships and hierarchies
With a single entity master data hub, such as customer, hierarchies and relationships are relatively straightforward.  For example, organizational relationships are depicted as legal hierarchies of parent and child organizations, while consumer relationships are those belonging to a common household.  On the other hand, hierarchies among multiple data entities can be highly complex.  Examples include: retail locations in the Eastern region stocking only certain products; complex counterparty legal hierarchies determining credit risk exposure; or an account holder’s spouse being a high net-worth individual.  Make sure your MDM request for proposal requires the solution to be capable of modeling complex business-to-business (B2B) and business-to-consumer (B2C) hierarchies, along with the definitions of those master data entities within the same MDM platform. Without the ability to define what a branch is and how it relates to others, it is near impossible to maintain the complex relationships required in order to establish this key performance indicator in a rapidly changing world.

Mistake 4:  Cleansing data outside of the MDM platform
Data cleansing includes name corrections, address standardizations, and data transformations.  Typically the number of source applications that provide reference data to departmental level Customer Data Integration (CDI) or Product Information Management (PIM) solutions is relatively small.  In these cases, the data can be efficiently cleansed at the source using commonly available data quality tools.  In contrast, the number of sources for an enterprise MDM deployment spans multiple departments and typically comprises tens or hundreds of systems.  In this scenario, cleansing the data at the source systems is not viable.  Rather, data cleansing needs to be centralized within the MDM system. 

Mistake 5:  Thinking probabilistic matching is adequate
There are several types of matching techniques commonly in use – deterministic, probabilistic, heuristic, phonetic, linguistic, empirical, etc.  The fact is, no single technique is capable of compensating for all of the possible classes of data errors and variations in the master data.  In order to achieve the most reliable and consolidated view of master data, the MDM platform should support a combination of these matching techniques with each able to address a particular class of data matching. 

Mistake 6: Underestimating the importance of creating a golden record
For MDM to be successful within an organization, it is not enough to simply link identical data with a registry style because this will not resolve inconsistencies among the data. Rather, master data from different sources need to be reconciled and centrally stored with an MDM hub.  Given the potential number of sources across the organization and the volume of master data, it is important that the MDM system is able to automatically create a golden record for any master data type such as customer, product, asset, etc.  In addition, the MDM system should provide a robust unmerge functionality in order to rollback any manual errors or exceptions — a typical activity in large organization where several data stewards are involved with managing master data.

Mistake 7:  Overlooking the need for history and lineage to support regulatory compliance
As mentioned above, business users are increasingly being driven by regulators and governmental agencies to submit data electronically in pre-defined machine-readable forms. Not only are compliance departments being asked for regulatory data, but they also require validation that the data is in fact reliable.  This is a challenging and daunting undertaking considering that master data is continually changing with updates from source systems taking place in real-time as business is being transacted, and while master data is merged with other similar data within the master data hub.  The history of all changes to master data and the lineage of how the data has changed needs to be captured as metadata.  In fact, metadata forms the foundation for auditing and is a critical part of data governance and regulatory compliance reporting initiatives.  As a result, and because metadata is such an essential component of MDM, it is important that your RFP defines the need for history and lineage.

MDM Success begins with selecting an Integrated and Flexible MDM Platform.
Success is defined as having access to the ‘best version of the truth’ of your data, across multiple domain types and consequently being confident of it is of verifiable high quality.
Once your organization starts to make its departmental master data management projects operational, you will find that your larger enterprise requirements will expand to include other business data types and other lines of business or geographies.  Therefore, it is important to first seek out and evaluate an MDM solution that adequately addresses these ten essential MDM capabilities.  It is also important to assess the MDM platform’s ability to support these seven core capabilities out-of-the-box, as they should be integrated components of a complete enterprise-wide MDM platform.  In this way, you will be able to mitigate against technology risk and improve your return on investment, since additional integration and customization will not be necessary in order to make the system operational.  Another benefit gained by having these ten MDM components integrated within the same MDM platform is that software deployment is much faster and easier to migrate over time.  Finally, it is wise to check customer references to evaluate their enterprise-wide deployment and to ensure that the vendor’s MDM solution is both proven and includes all seven enterprise MDM platform capabilities.
By including these critical MDM requirements in your RFP you will achieve greater success with your MDM initiative along with a more rapid deployment and faster time to value.  Not to mention, a well thought out RFP will allow you to quickly reap the returns from selecting an integrated and flexible MDM platform that is able to address both your current and future business requirements.