TDWI Research offers a step-by-step route to success, regardless of the application.

Features

Feature

Jump-start your MDM initiative

TDWI Research offers a step-by-step route to success, regardless of the application.

Getting a handle on master data management (MDM) can be difficult because its real-world solutions are so diverse. The process can be linked to many types of applications, owned by various departments, applied to multiple data domains, organized around various types of hubs, and enabled by many tools and technologies. Instead of fretting over the many things it can be, jump straight to what it must do to be successful. Doing so makes it clear that all MDM solutions involve the same four steps constituting a program applicable to almost every variation of the process.

Knowing and following a consistent program helps organizations avoid getting bogged down in academic definitions. This approach also helps users get started with a solution and extend its reach over time.


1. Select an application or data domain as a starting point

Everything new must start somewhere. With MDM, the starting point is regularly at least one operational application for enterprise resource planning (ERP), customer relationship mana­gement (CRM) or financials. Just as often, however, it is applied to analytic systems for data warehousing and business intelligence (BI). It is also common with hybrid applications that are both operational and analytic, as with customer data integration, product information management and financial performance management. (See figure 1.)

Figure 1: MDM practices and application types

Click to enlarge

Sometimes MDM is used on only one application. For example, it might help to integrate multiple ERP instances or provide consis­tency for the reports generated from an enterprise data warehouse. However, a solution of any maturity will govern data definitions in multiple applications to assure accurate data sharing among them. Hence, MDM for a single target can be a useful starting point. But user organizations should anticipate the list of applications integra­ted to grow over time and to reach across operational, analytic and hybrid varieties.

Instead of an application, many solutions focus on a data domain that spans the databases of multiple applications. The most popular domains involve data about customers, financials or products. Re­levant to these domains, inconsistent cross-system data definitions can affect customer retention, financial closings or supply chain efficiency. Pain points like these make a data domain a likely starting point for MDM.


2. Define core business entities

Master data, sometimes called reference data, consists of facts that define a business entity and that may be used to model one or more definitions or views of an entity. Entity definitions based on master data provide business consistency and data integrity when multiple IT systems across an organization or beyond identify the same entity differently. It’s important that diverse business and technical parties who use the data contribute to the data definitions, so they are accurate, practical and based on consensus.

Master data is often organized into hierarchies, such as employee/supervisor, product/product class, and consumer/household. Organi­zational “buckets” are as critical as the individual bits of master data, and are even more commonly seen in reporting, so expectations for accuracy, consistency, and governance of hierarchies must be carefully considered and are often a point of differentiation when it comes to MDM tool capabilities and vendor expertise. (See figure 2.)

Figure 2: Entities commonly represented by master data

Click to enlarge


3. Establish a central system of reference or hub

Common across the many approaches is the creation (or selection) of a system of reference, sometimes called a system of record or trusted source. The point is to establish a central, authen­ticated master copy from which entity defini­tions (and perhaps physical data, too) are propagated among all IT systems integrated via the MDM solution.

The system of reference can take multiple forms. Many users build a central database (like a data warehouse or operational data store) as a hub through which master data, metadata and physical data are synchro­nized. Some hubs are simply master files or master tables that collect and collate re­cords. Sometimes a pre-existing application (typically for ERP or CRM) has the needed definitions already, so it’s selected as the system of reference and the basis for entity modeling elsewhere.


4. Use integration techniques to acquire, improve and share master data

Regardless of the technology approach, the goal of the system of reference is to provide a central mechanism for collecting and sharing consistent definitions, usually across otherwise unrelated IT systems. Obviously, this requires technologies and best practices for system, data and application integration.

Hence, many technical users consider MDM to be an integration practice, enabled by tools and techniques for extract, transform and load (ETL), data federation, and replication. When the system of reference is a hub that connects many diverse systems, multiple integration technologies may be required, including newer ones like Web services operating within a service-oriented architecture (SOA).

Define MDM by what it must do, not what it is.

Common goal

Clearly, MDM practices are diverse. Regardless of the approach, however, all solutions share a common goal: consensus-driven definitions of common business entities—like customers, products and financials—applied consis­tently across an agreed-upon list of IT applications and business units. In turn, consistent data usage (as enabled by MDM) leads to greater accuracy, insight and compliance in data-based operations and decision making.

It’s all about sharing data consistently, so you’ll need to define how applications and databases should represent shared business entities. To reach the goal of sharing data, you must agree first on definitions, then establish the needed teams, policies and procedures. Ongoing owners­hip of each area of master data must be established. Doing so will speed up resolution of future issues, identify data stewards and establish ap­proval workflows implemented as part of the overall solution.

Enlist business people to define entities. For master data to achieve its primary goal—consensus-driven definitions applied consistently—a cross-functional team of technical and business people must drive the agreement. In order for IT to hand over responsibility for master data additions, updates and deletions to business data stewards, seve­ral steps should be taken. The organization must secure facilities such as role-based security, deep history of workflow-driven actions, and management agreement to enforce accountability for actions taken—and not taken.

Singular approach

Define MDM by what it must do, not what it is. Just about every organization has its own definition, because MDM is enabled by diverse technologies and varying amounts of business participa­tion. Plus, the number of applications and business units involved varies greatly. And every organization needs to strike its own balance between operational and analytic MDM.

Yet, across all this diversity, the four steps outlined remain constant. Know the four-step program and follow it. The result will be a course to success, regardless of the organization’s situation at the beginning.


Your Comment:
  
Your Rating:

Comments
EMC Q3-2014