10 Mistakes to Avoid When Writing an RFP for Master Data Management

You know you need to figure out a better way to manage your company’s massive amount of critical “master” data. Don’t worry—you’re not alone. In a 2007 Accenture survey of 162 global CIOs, 75 percent said they want to develop an overall information management strategy in the next three years. Doing so would “reinforce[e] the need to fully manage their organizations’ data and leverage that data for strategic advantage,” said the report.

To succeed, you need a master data management (MDM) strategy that spells out how you’re actually going to pull this off. It must address how you’re going to get organizationwide buy-in, what the end state of your systems and data management practices will look like, and the technologies you’ll use. Selecting an MDM vendor is a critical initial step for your software development team.

Since you get only the services you ask for, writing a precise and informed request for proposal (RFP) document can only help your overall MDM effort. Siperian, a provider of MDM platforms, has seen a sizable increase in the number of RFPs it has received during the last two years. Company executives noticed that many proposals lack the unified, comprehensive view that is necessary to ensure long-term success. As a result of looking at more flawed RFPs than you’ve seen programmer résumés, Siperian identified 10 common mistakes that CIOs make when companies put together an RFP for their master data management efforts.

Ravi Shankar, director of product marketing at Siperian, urges CIOs to avoid these critical mistakes in their RFPs. Doing so can lay the foundation for a complete and flexible MDM solution that addresses both current requirements and unforeseen future data integration requirements. If not, he notes, CIOs “will end up with broad master data management silos.” Which is the exact opposite of what an MDM solution should do.

Mistake 1: Failing to ensure that multiple business data entities be managed within a single MDM platform.

This is a biggie. “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,” Shankar advises. “By doing so, system maintenance is simplified and more cost effective, which results in lower total cost of ownership.”

A large Siperian pharmaceutical customer recognized that it would need to add more business groups and functionality to its enterprise MDM system and can do that today because the flexibility was built into the strategy from the outset. Shankar notes that an alternative is to deploy and manage separate master data solutions, wherein each manages a different business data entity. However, he says, this approach would result in additional system maintenance and integration efforts and a higher total cost of ownership.

Mistake 2: Ignoring data governance needs at the project or enterprise level.

“The important thing to realize is that when doing MDM, you’re really doing data governance,” Shankar says. Data governance is unique to each company since it is based on the company’s business processes, culture and IT environment, he points out. However, most companies select an MDM platform without much thought to their enterprise data governance needs. “It is critical that the underlying MDM platform is able to support the data governance policies and processes defined by your organization,” Shankar notes. “In contrast, your data governance design could be compromised and forced to adapt to the limitations of some MDM software platforms with fixed or rigid data models and functionality.”

Controls and auditing capabilities are also important data governance components, according to Shankar. To properly support this function, the RFP should “require the MDM platform to integrate with a company’s security and reporting tools to provide fine-grained access to data and reliable data quality metrics.”

Mistake 3: Failing to ensure the MDM platform works with a company’s standard workflow tool. Workflow is an important component of both MDM and data governance because 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, Shankar says.

Workflow can also be used to automatically alert the data steward (the employee who’s in charge of the data) to any data quality issues. “It is important to raise the question of how the MDM platform will integrate with the standard workflow tool that you have selected,” Shankar notes, adding that several MDM vendors bundle their own workflow tool, which may not offer integration with a CIO’s standard workflow tool. “An open architecture that’ll work with any workflow tool is key,” he says.

For more on enterprise workflow, see Making Workflow Work and Flow for You.

Mistake 4: Failing to ensure the MDM solution supports complex relationships and hierarchies.

With a single-entity master data hub, such as a customer hub for sales and marketing, the hierarchies and relationships are relatively straightforward, Shankar notes. Conversely, hierarchies among multiple data entities can be highly complex. Examples include retail locations in the Eastern region stocking only certain products, complex counter-party legal hierarchies determining credit risk exposure, or an account holder’s spouse being an individual of high net worth. “Relationships have been an afterthought for most of the MDM vendors,” Shankar says. “Here is the MDM system, and then you slap on hierarchies. That’s not right. Hierarchies need to be treated as master data.”

He advises CIOs to ensure that their RFP requires the solution to be capable of modeling complex B2B and B2C hierarchies, along with the definitions of those master data entities within the same MDM platform.

Mistake 5: Relying on fixed service-oriented architecture (SOA) services.

Shankar points out that reliable data is a prerequisite to supporting SOA applications-meaning, applications that automate business processes by coordinating enterprise SOA services. “Since MDM is the foundation technology that provides reliable data, any changes made to the MDM environment will ultimately result in changes to the dependent SOA services, and consequently to the SOA applications,” he notes.

Therefore, CIOs need to ensure that the MDM platform can automatically generate changes to the SOA services whenever its data model is updated with new attributes, entities or sources. “It needs to be truly configurable,” he says. In turn, this key piece of an RFP will protect higher-level SOA applications from any changes made to the underlying MDM system. In contrast, Shankar points out that MDM solutions with fixed SOA services that are built on a fixed data model require custom coding to accommodate underlying changes to the data model. (And we all know what custom coding means: $$$$.)

Mistake 6: Cleaning data outside the MDM platform.

Data cleansing includes name corrections, address standardizations and data transformations, Shankar says. And while a lot of RFPs ask about data cleaning and data quality, those RFPs fail to ask about how and where the data will get cleansed—outside the MDM system or inside the system. This is an important distinction.

Typically the number of source applications that provide reference data to department-level customer data integration (CDI) or product information management (PIM) solutions is typically small. In these cases, Shankar notes, the data can be efficiently cleansed at the source using commonly available data quality tools. However, the number of sources for an enterprise MDM rollout spans multiple departments and comprises tens or even hundreds of systems. “In this scenario, cleansing the data at the source systems is not viable,” he points out. “Rather, data cleansing needs to be centralized within the MDM system.”

If your company has already standardized on a cleansing tool, then it is important to ensure the MDM solution has out-of-the-box integration with the cleansing tool, Shankar advises. In addition, CIOs who don’t know the complete “lineage” of their data will face loads of headaches when it comes time for audit and compliance checks, he notes.

Mistake 7: Thinking “probabilistic” matching is adequate.

Don’t be scared; this isn’t as complicated as it seems. “Matching” simply means the MDM system’s techniques to reconcile the data. “If you look at an MDM hub, the crux of the system is matching,” he says. “The truth that [CIOs] don’t realize is that the matching is in eye of the beholder.”

For example, Shankar points out that several types of matching techniques are commonly in use, such as deterministic, probabilistic and empirical. “No single technique is capable of compensating for all of the possible classes of data errors and variations in the master data,” he says.

In order to achieve the most reliable and consolidated view of master data, Shankar advises that the MDM platform should support a combination of these matching techniques, with each able to address a particular class of data matching-a hybrid-type technology, so to speak. A single technique, such as probabilistic, likely cannot find all valid match candidates, or worse, may generate false matches, he says.

Mistake 8: Underestimating the importance of creating a golden record.

Ahhh, the golden record. The single version of the truth. This is what everyone is after. “Unless you have a golden record, you don’t have MDM,” Shankar says. “MDM needs a single point of truth in order to cater to all processes.” So for MDM to be successful, believes Shankar, 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 should be reconciled and centrally stored within a master data 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 or asset.”

In addition, he notes that the MDM system should provide a robust “unmerge” functionality to roll back any manual errors or exceptions-a typical activity in large organizations where several data stewards are involved with managing master data.

Mistake 9: Overlooking history and lineage features to support regulatory compliance.

Today, business users not only demand clean and reliable data, but they also require validation that the data is in fact reliable, which is a newer trend. “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,” Shankar says.

The history of all changes to master data and the lineage of how the data has changed need to be captured as metadata, which forms the foundation for auditing and is a critical part of data governance and regulatory compliance reporting initiatives, he notes. Even if CIOs think they don’t need those financial capabilities, their marketing department may need to keep track of customers who opt in or out of marketing campaigns, for example, which could become important, Shankar says.

Mistake 10: Implementing MDM for only a single mode of operation—analytical or operational.

“You cannot look at MDM for a single use, whether it’s operations or analytical reporting or campaign management,” Shankar says. An enterprise MDM platform needs to synchronize master data with both operational and analytical applications in order to adequately support real-time business processes and compliance reporting across multiple departments, he says. Without the ability to synchronize master data with both operational and analytical applications, a CIO’s ability to extend the MDM platform across the organization is limited, and maintenance costs will increase. And nobody wants that.