Launching a Master Data Management Program: Eight Key Steps in the Journey
In the current world of online marketing and digital commerce, master data management (MDM) is a critical component of corporate infrastructure. Just as the engine of a car controls its overall performance, MDM controls the usage of information throughout the enterprise.
One of the prime applications of MDM is in supporting a 360 degree view of the customer as part of a strategic plan. This view provides insight into what customers are buying and through what channels; it also offers insights into their household or relationships with other customers and prospects. To get the most interesting insights; however, companies need to obtain and manage data from disparate sources, such as social media and internal customer and product data, and then tie it together. Mastering product data will ease some of the challenges with data complexity and provide for a better customer experience on the web.
In this article we describe eight major components of an MDM program. Whether your company is just starting its MDM journey or is already in the process of implementing it, you will find valuable insights that will help you properly design and manage your MDM program. Although not all of these points need to be resolved in the early stages of discussion about an MDM program, they should be resolved before the project is launched. The below are outlined in the order in which they should be done, but some of them could be done in parallel or at least with some overlap.
Create a data governance program ahead of the MDM Roadmap
Many companies get scared off by the data governance programs that consulting companies propose because they look large and costly. But there are some very important advantages to having a program in place, including improved data quality and better compliance, even if a company does not plan an MDM program. By establishing a strong data governance program, however, MDM implementation can be streamlined. In fact, without a data governance program in place, the progress of an MDM initiative is likely to be disrupted, since issues such as data ownership and rules for data validation and enrichment will need to be resolved along the way and previous work revised.
Without a data governance program in place, the progress of an MDM initiative is likely to be disrupted.
A data governance program can be up and running with just a small group of data stewards. The focus at this stage should be on the key elements of data governance. These include data ownership, data lineage, and data quality. For example, in the data governance process, duplicate records will be identified. In addition, business rules associated with consolidating master data should be defined so that when the MDM process begins, everyone has the same understanding of what it is intended to accomplish. We have also discovered during initial discussions that users have conflicting views on many terms, including such basics as “customer” (e.g., business customer vs. individual customer vs. prospect) and “product.” These issues can be resolved through data governance, and it is important to do so before the MDM program is launched.
The number of data stewards that are needed depends on the quality of the data and the risk tolerance of your company; for example, what would be the impact of failing to detect duplicates or incorrectly identifying a record as a duplicate? In the health care industry, the match percentage must be very high before data is released to end users. As the program matures and the match quality improves, the data governance program can be expanded to other aspects of data quality.
Understanding where your company is in the journey and what value MDM will bring to the organization will allow you to deliver results throughout the MDM program. Whether you are planning on implementing one domain or a multi-domain MDM, meeting the needs of users of the data must always be the first priority. This means involving the users early in the process, listening carefully to what they want, choosing the right data sources, and developing an effective interface. It’s a challenging job, but one that will pay off both in the near term and as your organization grows over the years.
This step is a must-have for successful MDM implementation. If companies are skipping data governance or not solidifying it, they will be forced to come back to it after the first couple issues. It will be more expensive, and by that time some opportunities and customer benefits will be lost.
Set clear objectives
What problem are you trying to solve? Sometimes the stated objective of an MDM program can be too generic: Create a “golden record” or “Create a 360-degree view of the customer.” What do you mean by 360-degree view? What problem will it solve? What value will it bring the organization? How will it move the organization closer to a strategic goal? An MDM program without a clear vision and objective is unlikely to be funded, as executives will not understand the value it brings. Alternatively, the decision-makers may have misconceptions about what an MDM program is, and believe that it is a data warehouse or reporting project. In that case, either they might not fund it, or if it does move forward, they will consider it a failure because the outcome does not match their expectations. Because of the specifics of MDM program there are often discussions where the budget should come from: IT or business.
The main purpose of an MDM program is to create master data and make it available to end users or other applications. MDM provides an enterprise-wide infrastructure to standardize, integrate, and establish an authoritative source for data from disparate sources of information that have similar and/or duplicate attributes to support business operations and decisions.
The need for master data comes from the creation of duplicate records in multiple order entry systems, customer relationship management (CRM) systems, Salesforce automation tools, or a combination of these systems. The duplication may also have been caused by acquisitions over the years, or from the creation of separate departments and systems. Many companies have legacy systems that do not have edit checks or proper search techniques to locate records (customer, product, vendor, location, etc.) that already exist. This leads to the end user unknowingly creating a duplicate record. Having master data will help navigate data duplication issues of all kinds.
Another objective of an MDM program is augmentation or enhancement of existing data from either internal systems or external vendors. For example, if your customers are large corporations, your company may need to know the level in the corporate hierarchy to which it sells. Matching customer records against third-party corporate hierarchies such as D&B or InfoUSA will provide that view.
An MDM program is not a data quality program. Of course, as part of the implementation, the data will be cleansed, but only for the purposes of matching records to create master data. An MDM program that focuses too intensively on data quality will bog down the implementation. An overarching data quality program should be addressed as a separate program.
MDM programs are usually implemented by IT, and business stakeholders may find it difficult to understand the need for such a program or appreciate complexity of it. Too many companies have the mindset of “if we build it they will come,” thinking they should get the data in the hub to create the golden record and then figure out what to do with it afterwards. The full range of business stakeholders should be engaged early in the journey to educate them about MDM and the value it will bring the organization.
Choose a focus for the master data hub
An MDM hub can be used for either operational or analytical purposes. Operational MDM, sometimes called transactional MDM, is used by core systems for business users (sales, service, order management, manufacturing, purchasing, billing, accounts receivable and accounts payable) or customer-facing websites. Users will either be retrieving master data from the hub or creating data to be fed into it. For this reason, updates to or from an MDM system are typically handled on a real-time basis. The downside of operational MDM is that it relies heavily on integration technologies, which can affect performance.
Analytical MDM supports a company's decision making. The data may be stored in a data warehouse or data marts to be utilized by business intelligence (BI) tools for predictive analysis, ad hoc queries, and report generation. Typically, only batch updates (daily or a couple of times per day) are necessary, but it depends on the needs of the users. In general, hierarchies and relationships are more important in analytical MDM than in operational MDM.
Determine who will own/access the data
The producers, consumers, and owners of the data may be different, depending on whether the system is being used for operational or analytical purposes. Many companies want a custom user interface (UI), in addition to the data steward user interface that comes with most MDM products, directly accessing the hub to “see what’s in the hub.” Many IT executives feel they can use the UI to show business executives the magic of MDM. However, this capability brings little or no value to the organization. The important thing is to consider actual usage. If the system is for internal operational purposes, such as customer service, sales or production, the focus should be on how the users will use and access this UI. Will it be through another application, or will it be through the current application set (ERP, CRM, salesforce automation, or production)?
An additional factor to be considered is the usage by external customers. Will customers be accessing the master data through your company’s website? If so, data governance and data stewardship will be more important. Data stewards will need to be 100% accurate on matched records to ensure one customer doesn’t see another customer’s information. This can happen when two records are incorrectly determined to be for the same customer.
For analytical MDM, users typically access the data through a data warehouse or data mart rather than accessing it directly from the hub. The IT department normally addresses this requirement, but the users should be involved early in the development process so they can determine which data is needed and buy into the program. Analytical teams may want the data fed directly into their analytical environment, while business end users will likely want it available through their business intelligence reporting platform (e.g., SAP Business Objects or IBM Cognos).
Decide on the data sources
The objective of the MDM program will dictate what data sources are loaded into the hub. The main reason companies implement MDM systems is to resolve a duplication issue or to create a golden record from multiple sources. The duplication can come from the same source system or from multiple source systems. In addition, companies may be using a third party data source to augment their data, or provide data as the primary source. As a general rule, if the data source has no alternate, duplicate source or is not augmenting any data, an MDM solution may not be necessary, since the match and merge functionality is not needed. For example, if there is only one source of data and there are no duplication issues, then there is no need to match and merge records, nor a need for a data steward interface. A master hub can be created without the use of the MDM software.
Data augmentation does not need to take place at the onset of the project; that decision can be deferred. But decisions about the quantity and type of historical data that is included must be made up front. How many years of data will be included? The longer the history, the worse the data quality is likely to get. Are only active records being included? If so, how is “active” being defined? Identifying the source system and the type of records to load into the hub is one of the determining factors of whether an MDM program is needed and how it will be utilized.
Determine which data should be mastered
One of the most difficult questions every company struggles with in the MDM program is the definition of the data domain. How is the “customer” defined? Does the term include inactive customers or prospects? Does “products” include their smaller elements or accessories? Is “location” a building or a department in the building? Trying to get consensus across business units is
Extremely difficult and time consuming. Defining terms should be a priority, though, as it will dictate software license costs, storage costs, and the stakeholders that will be involved, as well as the timeline of the implementation.
Master data should be lightweight and less volatile than transactional data. In other words, it does not change very often. Drawing the line between master data and transactional data can be difficult, however. Remember that the main purpose of MDM is to match and merge records to create a single master record, not to build a data warehouse.
Identify Hierarchies, Relationships and Groupings
In many cases, hierarchies, relationships, and groupings are an afterthought, decided on during the implementation. Although the specifics can be gathered during the requirements stage, defining how the master data elements will be related to each other will go a long way toward selling the value of the MDM program to the end users. The linkage of the elements of the master data is just as valuable as the data itself.
Usually this information is not available in other internal applications or from third parties, so identifying which are “must-haves” and which are “nice-to-have” may alter your vendor choice, implementation strategy, and data governance model.
Hierarchies are typically more useful for analytical MDM than for operational MDM. In some cases, hierarchies are also a useful tool for internal departments such as sales and customer service. Sometimes these hierarchies are already captured in internal systems, such as sales force automation and CRM for corporate location and operations, and HR for employee/manager. Some hierarchies can be purchased from external vendors, such as D&B and Harte Hanks. Multiple hierarchies may also be captured and used for the same data. For example, customer hierarchies may be different depending on the view that the user requires. Sales, marketing, finance and customer service may each require different views of the customer.
Relationships between the master data elements are very useful to organizations, but in most cases they can only be captured manually, especially party-to-party relationships in the customer domain. To decide whether such relationships should be captured in the MDM system, the value these relationships will bring to the organization should first be determined. Then explore whether that information is already being captured in another application or from a third-party source. If not, is the value that the information brings worth the cost of manually capturing or purchasing the data?
Some examples of relationships include parent-to-child and spouse-to-spouse for customers. In addition, the employer of the customer and the role that person plays in that company may be important; for example, finding out whether a customer is on the board of another company would be very valuable information. If you’re working through a broker or dealer network, you may not have direct contact with the end customer, so a broker/dealer-to-customer relationship may be warranted. Other examples of relationships may be product-to-accessory or customer-to-contract.
Groupings are similar to relationships and in fact, many MDM systems handle them the same way internally. Two of the most valuable groupings are households and region. An address is usually a prerequisite before being able to create these two groupings.
Develop a clear, feasible implementation plan
The best implementation plan starts with a small number of sources and provides meaningful information to the business in a very short period of time. Problematic plans tend to be either very large implementations (many sources, multiple integration points, and complex data) that plan a “Big Bang,” or those that build a hub with no specific objective in mind. When a project achieves specific objectives quickly, the business will see the value of the MDM program even if it is small, which will provide enough benefit to justify continued funding. Once the initial project is successful, a roadmap should be prepared that shows how other stages will be accomplished, consistent with the strategic objectives of your company.
Start with a small number of sources and provide meaningful information to the business as soon as possible.
The development of an MDM program is a journey and requires a lot of preparation and like all programs, it should be thought through before implementation starts. An MDM program requires that employees on the business side and the technology side work together to solve a variety of issues. Proper planning and strategy can ensure the success of this program. Although every company and situation is different, the steps described will help lay out a solid roadmap for a successful journey.