Jill Dyché and Evan Levy, partners and co-founders, Baseline Consulting
Viewpoints
Enterprise View
Scope Matters
How to establish the boundaries of master data management.
by Jill Dyché and Evan Levy
Here's something we've learned the hard way: There's no single right way to launch your master data management (MDM) program.
The point of MDM is to make sure that business organizations and their IT departments are aligned when data is integrated and shared. Most companies are organized into departments or business units to address specific functional responsibilities. These business units have different relationships with one another and different relationships with external customers. Thus, their definitions of "customer" may vary based on their responsibilities.
MDM means unifying common reference data across multiple applications while maintaining distinct views for each business unit. The scope of an MDM initiative generally falls under one of four categories:
ENTERPRISE
An organization's starting point for MDM can differ according to the targeted problem. Ultimately, an MDM initiative will begin when there is conflicting data—often manifesting itself through a financial or operational issue—that needs to be shared.
Some companies will immediately understand the need for enterprise MDM, usually because of existing challenges linking customer records or product records across systems. The economies-of-scale benefits that MDM offers can be a boon for them.
BUSINESS UNIT
In other circumstances, individual business units may need to link data across a handful of systems for a specific purpose. These units are usually weary of the manual reconciliation and cleanup necessary to link data across various applications.
For instance, in the long-distance organization of one communications company, the billing systems reflected individual geographic regions—a holdover from the days of regulation. Many larger customers had locations across multiple regions, and the long-distance unit wasn't necessarily interested in other divisions' data issues.
Acquiring an MDM hub allowed the long-distance department to link customer data across 11 different billing systems, a complex problem but nonetheless one more narrowly defined as business unit MDM.
ORGANIZATION
As an example of organization-specific MDM, consider customer support within a large electronic components company that has multiple systems, the result of a dozen mergers in the past five years.
Members of this group need to link their systems to begin tracking trouble tickets by clients, regardless of region or subsidiary. This means coming up with a unique customer ID so these employees can link only their systems
with the various support organizations. The resulting ID will not be visible to or accessible by outside systems.
PROJECT
Usually, project-specific MDM enables a single function and involves tracking, understanding and reconciling individual system values in order to link them.
For instance, a salesperson may want to see sales, payments and support for a customer. The data may be across three different systems or found within the same system (different enterprise resource planning modules, for example).
A SENSE OF PERSPECTIVE
We recently worked with a clinical research organization that needed greater visibility into its products and services. Because of the geographically distributed nature of the business, its clients interacted with multiple business units. This resulted in constant battles about revenue calculations for individual customers. The MDM project was a single-purpose integration activity that allowed the company to reconcile, match and calculate revenues for its clients.
Data management has taught us that data might have an enterprise definition and various departmental ones, and these often conflict.
For instance, a high-tech company views an organization like General Electric (GE) as a single named customer, despite its many subsidiaries. But sales organizations consider it to be a collection of different customers. The way they price products for GE varies by location and business unit; GE Aviation may get a software license price different from that of GE Consumer Electronics. In the meantime, the support organization views the company as a single customer, deserving Tier 1 support regardless of which division contacts the firm.
An MDM team deploying a solution needs to understand the scope of the problem. If the solution is built solely for the sales organization, changes to customer details shouldn't affect systems or individual businesspeople outside of sales. However, if the MDM solution is geared to support the enterprise, it will affect a broader population of systems and people.
In the case of enterprise MDM, if the sales organization has unique metrics and policies—for instance, how territories are established based on customer groupings—then these standards cannot conflict with enterprise standards. If the enterprise has already established the concept of "territory," then sales must conform to that definition. The enterprise has the overriding authority.
MDM MEANS CHANGE
Whether it's enhanced revenues due to sales territory alignment, improved regulatory compliance, or streamlined merger and acquisition efforts, MDM's benefits always accompany broader business and cultural change. This might not entail an all-encompassing organizational transformation, but regardless of the starting point, it means operating differently.
Dealing with the disruption brought about by MDM is a matter of approach. Research by Debra E. Meyerson in Harvard Business Review revealed that different leadership styles drive change—from very public, top-down alliance building to quieter, behavioral styles that instill gradual change. Meyerson calls this "disruptive self-expression." The best technique for instilling change through MDM depends on the scope of the effort.
“The point of MDM is to make sure that business organizations and IT are aligned when data is integrated and shared.”
A recent experience manifested cultural change at a medical equipment company. For years the business had dozens of different product catalogs. Most replicated data from other catalogs, though few actually matched. Different organizations within the company would create special versions of the same product with new identifiers. When a successful MDM effort promised to yield a single "master" product catalog, turf wars erupted.
So when the medical equipment company had to standardize on a single product master across the enterprise, the resulting cultural shift had to involve executive leadership at the highest level. Management could have waited for the owners of the various catalogs to admit that their versions of product data were sub-par. But the company's entire order-to-cash process was reliant on the new product master. The leadership couldn't wait.
The edict? If salespeople continued to use their old product catalogs, their orders would not be processed until they contacted order administration to manually fix the product data. Sales would then be cross-charged by order administration for the service time. Meanwhile, the business units standardized and converted the old product IDs to conform to the new rules, and the order system would spit out bad IDs. The combination of executive edict, penalties for noncompliance, available training and system changes transformed behaviors. The new product catalog became the company-wide standard within four months of going online.
A COMPREHENSIVE STRATEGY
Executives on both IT and business sides need to understand the importance of data as an asset. Perhaps even more importantly, they must adopt a comprehensive program to link information—regardless of whether MDM begins as an enterprise effort or as an isolated project—with corporate success.
Jill Dyché and Evan Levy are partners and co-founders of Baseline Consulting, a technology and management firm specializing in data integration and business analytics. They are co-authors of the book, "Customer Data Integration: Reaching a Single Version of the Truth" (John Wiley & Sons).
