1) Anticipate the saboteurs. With CDI there will be people in your organization claiming that "we already do that...
with our data warehouse/ODS/CRM system/toothpicks-and-glue." Anticipate their arguments and educate them, offering deliberate examples of why they're full of it. Nicely, of course.
2) Articulate more than one business problem that CDI can solve. You want to position your CDI effort as an ongoing program that can enable different business needs. If you position CDI as a one-trick pony (for instance, it can handle identity resolution), you'll only be able to ride that horse for so long…
3) Know your functional requirements. It never ceases to amaze me how quickly companies want to enlist vendors. "We've gotten everyone in a room and we know what we need," they explain as they cherry-pick brochures off of vendor websites and schedule proofs of concept (POC). Not so fast! At best, this is a well-intentioned attempt to fill in the blanks by talking to smart vendors. At worst, it's tire-kicking in a vacuum. Unlike with business intelligence (BI), master data management (MDM) requires a huge and measured focus on functional requirements. Until you have your list in hand, you won't be able to give the vendors what they need to deliver the goods.
4) Don't underestimate the need for savvy development skills. This isn't your father's data warehouse. Many IT environments are so accustomed to buying off-the-shelf applications that they lack the development skills necessary to configure and maintain an MDM solution. Not that it's a science project, but it's not a packaged app either. If your business is complex, your MDM solution will be, too.
5) Don't prematurely launch data governance. Not to be an alarmist; I've never yelled "Fire!" in a crowded theater. (Though I have yelled "Fire!" twice, both times during Terms of Endearment.) But you can rush data governance, and the results can be disastrous and long-lasting. If someone asks you to come to a council meeting, and they haven't defined data governance for you, duck and cover.
6) Don't just assume the enterprise application vendors will fit the bill. Just because you already have a [fill in the blank] license doesn't mean that's the right MDM product to suit your needs. See number three, above, or call me.
7) If you're not sure where to start, convene presumptive stakeholders for an executive workshop that defines MDM, explains the pros and cons, profiles the key vendor products, and foreshadows the "gotchas." A good consulting company can deliver such a workshop and follow it up with an Observations Report that highlights key conversations and questions and recommends tactics for moving forward.
If you've already anticipated all of these, there are more where these came from! See the booklet Evan and I wrote for TDWI, called: "10 Mistakes to Avoid When Planning Your CDI/MDM Program." Now go get 'em.
Dig Deeper on Customer data integration software
Related Q&A from Jill Dyché
Is it better for companies to go with an enterprise-wide master data management (MDM) implementation or deploy MDM departmentally? Find out which ... Continue Reading
What’s the biggest BI problem companies keep running into? Overloading data at the expense of functionality, says an expert. Find out how to avoid ... Continue Reading
There’s a lot of confusion about agile business intelligence (BI). Get an expert’s take on what agile BI really is and if it’s a valid BI development... Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.