Foreword

Everything should be made as simple as possible, but not simpler.

—Albert Einstein

When Evan Levy and I wrote Customer Data Integration: Reaching a Single Version of the Truth (John Wiley & Sons, 2006), we were confident we'd chosen a topic of high business import, one with innumerable use cases and a clear value proposition. Our book was the first book published on the topic of CDI—now commonly known as customer master data management (MDM)—and it was a direct result of our having seen what had happened at companies that didn't have MDM.

Earlier in the decade, my second book, The CRM Handbook (Addison Wesley, 2000), was published just as customer relationship management was getting white-hot. Companies were investing tens of millions buying CRM systems, redesigning customer-facing business processes, and training customer-facing staff members in cross-selling conversations.

After all the vendor hype, millions in investment, and inordinate executive mindshare, it turned out that CRM systems were generating data that was no more useful than it was before CRM. CRM had been a downright failure—industry analysts were throwing around the 80 percent figure—at these early-adopter companies, most of which had naively believed the vendors and taken a ready, shoot, aim! approach to CRM delivery.

The ongoing phenomenon of duplicate or incomplete customer records continued to be the culprit behind compliance fines, fraught financial reporting, eroding sales revenues, and embarrassing marketing gaffes. Even with CRM in place, billing, support, inventory, order management, and other systems weren't sharing customer data, and when they were it was often the result of years spent building and maintaining custom code. “We're data rich, but information poor,” became the refrain of millions of executives whose budgets were attached to multimillion dollar system failures and perpetual programming. Why wouldn't companies adopt MDM?

As the buzz about our CDI book reverberated in both IT and business circles, the most common question wasn't definitional. Executives on both sides of the fence “got” MDM. They'd been waiting for a way to tie customer data together across systems and business processes. They were sold. What they wanted to know again and again was:

“Where do we start?”

The question was deceptive in its simplicity. Many secretly wished we'd whip out a template or hand them a checklist. A few brazenly asked to see our methodologies. And some duly retained us to develop detailed roadmaps for MDM delivery. One thing we confirmed—and proved again and again—was that while MDM might solve similar business problems from one company to the next, no two MDM roadmaps were ever the same. There was no template for MDM delivery. Replicate another company's MDM plan at your peril.

After all, there are too many wildcards for there to be a single, standardized plan for MDM. These include:

• The need for a business case. Some managers have the organizational authority to explain a broad problem and its implications, and get the budget to go fix it. Some companies can't start anything new unless someone's calculated hard return on investment numbers. The way MDM is pitched in the organization can affect its delivery.
• A company's incumbent skill sets. Some companies launch MDM efforts having existing data stewards, policies for data usage, and an understanding of operational systems development issues. Others still struggle with how to manage and store data, hoping that MDM will automate data integration using staff who can only be dedicated part-time to the effort (and that it will be cheap).
• The need for sponsorship. The mandate of executive sponsorship means different things at different companies. Top-down MDM may mean C-level involvement. Bottom-up MDM might mean a visionary middle manager and a bright team of intrepid data stewards working late for a month or two to deliver meaningful data in the context of a real project, then showing off their good work.
• Existing data management capabilities. Some companies have data people. These people understand the data in the context in which it's used, and they and their colleagues have crafted deliberate strategies for managing that data. Other companies still see data as a by-product of their packaged applications. The behaviors across this continuum can inform where to begin.
• The weight of data governance. As Evan and I said in our book (and many times since), data governance—the policy making and oversight of corporate information—is critical to sustainable MDM. A company's grasp of data governance and its role in MDM is directly proportional to its chances for MDM success.

Mark and Dalton have written about these topics and other topics from a bird's eye view. They turn out the core components of MDM—data governance, ROI analysis, implementation processes, data stewardship, and data quality being among them—in a way that's as easy for beginners to grasp as it is for experienced practitioners to execute. As seasoned MDM delivery experts themselves, they've seen the pitfalls from on high and warn you away from them even as they help navigate a better path for delivery.

MDM has come a long way since we wrote what we like to think of as the seminal book on the topic. People have stopped equating MDM with analytic databases or metadata or middleware. They understand that in many cases it's the missing link between their companies' technology infrastructures and relevant, timely interactions with customers. Yes, our CDI book was the first book on MDM, but not the last. And for Mark and Dalton's readers, that's fabulous news indeed!

Jill Dyché
February 2011