Jul 11, 2011 (04:07 AM EDT)
Mastering Master Data Management
Read the Original Article at InformationWeek
There's a disconnect between the emphasis companies place on real-time metrics and the amount of time IT organizations spend developing policies and procedures for managing the data that comprises those metrics. Everyone wants to turn raw stats into wisdom in real time, but you can't even begin to do that if you don't have a handle on your data. And, complicating things further, cloud providers rarely provide customers with the tools necessary to manage their data stored off site--meaning it's being copied, moved around, and inevitably pushed out of sync.
Consider a manufacturer of steel widgets that sells to the public as well as in bulk to major suppliers. A customer orders online and gets a quote, but when the product is received, the cost is higher than expected because the price of the item on the customer front end was less than the actual cost on the back-end billing system. Hopefully, with good customer service, the problem will get resolved, and the customer will return for future purchases--and not tweet derogatory remarks about the experience.
The problem could have been avoided altogether, however, with a master data record for widget prices that's referenced by both the front- and back-end systems. In response, an entire industry has emerged to offer IT organizations ways to ensure they can offer the business authoritative data sources. But this isn't a problem that can be solved with technology, and, sadly, the discipline of master data management (MDM) hasn't gotten the attention it deserves in many enterprises. For example, in our most recent InformationWeek Analytics Business Intelligence and Information Management Survey, MDM systems came in seventh out of 10 information management technologies (see chart, below). MDM is in extensive use by just 11% of survey respondents.
We think it's time to change that.
For years, we've talked about the value of having a "single version of the truth," but the concept of master data involves a bunch of different elements, including how information is created, read, updated, deleted, and searched.
What's keeping many companies we work with from taking advantage of their master data? A methodology to manage it. A master data set with errors can wreak havoc, especially if multiple applications depend on it. Beyond outright errors, such as incorrect pricing, overlapping data sets from acquisitions can lead to subtle inconsistencies, like one customer having multiple entries in the CRM system.
The solution, MDM, isn't available in a nice little application you can buy, install, and forget. Rather, it's a cohesive collection of technologies and processes that combine to create and maintain consistent and accurate data throughout your entire company, including data that resides off site.
You can spend a small fortune on data warehouses and connectors to enterprise systems, and the technology piece is important. However, without the business processes to maintain consistent data, undertaking an MDM project is pointless. Processes critical to MDM include data collection, normalization, transformation, governance, and consolidation. MDM may be applied to customer data integration (CDI) and product information management (PIM). CDI is about the management of customer information for internal use. PIM is related to managing product data from a central location for internal, and potentially external, consumption.
Become an InformationWeek Analytics subscriber and get our full report on master data management.
This report includes 19 pages of action-oriented analysis. What you'll find:
For some companies, applications whose data is maintained in a read-only state may be better suited for outsourcing, with transactional data kept internally. As you make plans for adopting software as a service or off-site storage services, keep data management and consistency in mind. Again, consider our widget maker. A corporate customer decides to order 3,000 widgets through a public cloud service, where pricing data should be in sync with the company's on-site list. The customer is quoted $15 per widget, for a total cost of $45,000. Unfortunately, the item price of that widget was changed to $17 a month ago, but a network connectivity glitch between headquarters and the cloud provider resulted in a failure to update the front-end systems. This order ends up representing a $6,000 loss for the manufacturer, with additional losses for other orders placed since the price change.
Data integration tools like Hubspan WebSpan, IBM WebSphere Cloud, and SnapLogic could help manage data traversing multiple cloud sources and on-premises applications, but we've seen these systems add six figures to a data management strategy, so factor that cost into your cloud calculations.
Business processes are just as important as technology for MDM, as we discuss in depth in our full report. Critical areas to address include:
>> Executive buy-in, because this project touches all areas of the business. The employees who generate data need to recognize the importance of MDM.
>> A data governance council, to decide questions related to master data.
>> Consistent change and configuration management processes.
>> Ways to federate data sources and break down silos.
>> A plan to regularly review data sources for errors and anomalies. For example, if the service desk isn't updating and deleting incorrect customer master data, then your CRM system isn't accurate. Inconsistencies could propagate throughout your data stores; how serious that is depends on integration points with provisioning, event management, billing, and other applications.
The ripple effects of unreliable master data eventually will be felt from the service desk all the way up to the highest levels of management.
The Road To MDM
When embarking on an MDM project, start small and implement in phases. Take one data pain point, and identify the source of the problem. For example, if you're an ISP and a customer goes online to order high-speed Internet service for her home, where is the service speed captured? The right answer is, in your CRM, billing, and provisioning systems, and ideally the capture happens in a coordinated and automated fashion.
Say that customer then calls in requesting an upgrade that the service desk captures in the request management system. Unfortunately, this system is linked only to the billing system, so the customer is now paying more money for a service she may not receive. Or the request system may link only to the provisioning system, in which case the customer may end up paying less for more speed--that's lost revenue.
Another important factor in an MDM project is to identify both the producers and consumers of data. We find that pinpointing the producers of a given category of data is typically less difficult than ascertaining its consumers. Say that, due to regulatory considerations and application access rules, the widget manufacturing unit doesn't have privileges to see customer data. But someone from that unit might request a periodic export of that data from a colleague and keep it in a spreadsheet on his desktop, for purposes of following up on special requests. If you think this sort of back-door data use could be happening in your company, consider starting a review of access rules as they relate to business processes.
One of the most important facets of MDM is to establish who owns and is accountable for various data sets. These data stewards should:
>> Play a central role in identifying the sources, producers, and consumers of the data they're responsible for.
>> Be included in discussions related to a data maintenance plan and the company's overall data model.
>> Assist in transforming source data into master data.
>> Be responsible for updating and verifying the accuracy of master data. Various processes and tools can help data stewards identify and correct data inconsistencies. Your maintenance plan should include a way to notify stewards of any changes to their master data.
Once data is accurate, processes are required to insert or update the MDM system and distribute the data to the required consumers. A data model for business and IT personnel, for example, documents details of information flow, data storage, and accessibility. We've seen it take a significant amount of effort to determine which data attributes are important and why. Creating a data model will help map data sources to master data. However, this process isn't always straightforward. Products may have multiple part numbers, for example, creating confusion for the data consumer. Data stewards should make the final decision on which data attributes and formats are acceptable.
Why We Fail At Data Management
One of the main criticisms of MDM suites is that they cost a lot of money but deliver a low return. One option to reduce costs and increase ROI is virtual MDM software that can manage multiple master data domains. IT gains a single view of master data, with data governance and data quality issues addressed at the virtual, not physical, layer. Virtual MDM saves money by using abstraction layers in data modeling to create an MDM metadata catalog, without actually moving or consolidating data from its sources. Incoming requests from business applications, like ERP and CRM, can be processed dynamically, eliminating the need for data warehouse repositories.
MDM projects also fail because of problems validating data integrity, lack of data governance and executive support, and an inadequate focus on business processes. End-to-end data validation testing is critical during an MDM project and on an ongoing basis.
Before implementing any MDM tool, address data quality--first by defining what, exactly, quality is, something that may depend on your industry. For some companies, quality may simply be meeting customer expectations, while in another, quality relates to the number of defects. What's important is that desired data traits are defined and measurable.
Design your MDM architecture before trying to determine the best tools for your company. Is a single, unified view of master data sufficient, or will you maintain multiple instances, where master data is pushed out to various locations and stored locally? How is the system going to merge, reconcile, and maintain versions, and audit data modifications? Ideally, the MDM system will maintain a data hierarchy.
Is an MDM suite necessary, or could a less costly data integration project fill the bill? Based on your business processes, design a data model and data maintenance plan. Identifying data sources, producers, and consumers will be beneficial, irrespective of whether you undertake an MDM project.
Work to establish trust between data consumers and stewards, and trust in the data itself. When service desk employees are confident in the data they're using, they'll provide better customer service, whether an order is placed via phone, online, or other methods. When customers receive their bills, everyone can be confident they're paying the right price for the goods or services received. Improved customer satisfaction hopefully will translate into increased revenue.
Michael Sharpe is an enterprise architect at Fusion PPT, a technology and management consulting firm. Write to us at firstname.lastname@example.org.
Three Guidelines For Implementing MDM
Pacific Northwest National Laboratory's MDM Experience
Download a free PDF of