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.