Master the data domain

By Thomas E. Schmitt, CPA/CITP, CGMA, CISA

Ready to put a Master Data Management plan into action? Check out the second part of this article, "Mastering the Data Domain: How You Can Get Started."

Have you ever been working on a project, performing research or executing analyses, only to find later you wasted days because some of the data is suspect? Perhaps the data was initialized correctly but the maintenance was inconsistent, or it was updated based on varying field definitions. As companies become more data-driven, the risk of bad decisions related to faulty data is increasing. There are significant hard costs and opportunity costs related to detecting and correcting these data inconsistencies. As the data gets worse, so do the consequences.

What is master data management?

Master Data Management (MDM) is the initiative an entity undertakes to structure, formalize and standardize its enterprise database(s). The focus is on data elements that are shared across departments and that are considered essential in processing transactions, analyzing customers and/or competitors and supporting strategic decision-making. This is true for private as well as public entities, for profit as well as nonprofit.

Often the need for an MDM initiative arises over time. Enterprises in development and start-up stages frequently begin by relying on systems and automated tools that are mostly departmentally controlled and focused. The initial users of these parochial systems are the ones that designed, selected and implemented them, so their underlying data records and model serve fairly narrowly defined purposes. As new records are created and existing records maintained, in the short run the respective fields are clearly understood and properly populated.

But as an entity moves into growth and expansion, and an organization needs to share data across departments or units, problems can arise. Typical scenarios are:

• Enhancements are made expanding functionality and adding complexity to the data records/data models.
• The entity has made acquisitions and must integrate systems and processes.
• The organization moves to entity-wide platforms.

Potential master data confusion

Making the changes without a well-thought-out MDM plan risks cross-departmental data and information confusion. The resulting contention easily destroys projected MDM benefits and some elements of the entity’s internal controls can be at risk.

Consider the following supply chain situation. Both the buyer and warehouse manager have a field in their respective legacy departmental systems called “Last Ship Date.” When implementing the new comprehensive MDM database, IT only asks one department what data to use to populate a similarly named field in the new enterprise system. Relying on a single answer could result in data confusion. The buyer may see this as the date of the last shipment from the supplier. The warehouse manager may view it as the latest date he/she can send the product to the stores and be assured it remains fresh for the customer — two different uses for what seems to be the same piece of information.

There are different examples where the same data is intended to be in multiple applications, but it is not linked or coordinated updates don’t happen. Questions then arise over which value is correct.

Master data management vs. governance

The risks around sub-par MDM implementations are exacerbated if it is seen solely as an IT responsibility and not accompanied by a parallel Master Data Governance (MDG) effort. Two different perspectives must be maintained in the overall master data undertaking: the IT view and the business view. Think of the IT view as the data element perspective and the business’s as the data content perspective. Working together, they help deliver master data quality. MDM working in tandem with MDG provides this dual view. The ultimate objective is to present the right corporate information to the many departmental users that need it while eliminating data redundancy — to have a “single version of the truth” for enterprise data.

MDM helps to ensure all the right data records and fields are created and presented where needed, and that unneeded or redundant fields are eliminated. MDG helps ensure the records and fields contain the right values, and changes are restricted to valid values. The two work together to ensure records are altered only by those authorized to do so. Validation rules that MDM systems apply are prescribed by MDG.

There are various approaches used to draw out MDM database requirements and manage MDM project scope (which should be approached in phases). Those approaches are outside the scope of this article except to say the MDM and MDG framework is built around first developing a deep understanding of the respective business processes and having a good grasp of Enterprise Information Architecture (EIA) principles (see below).

Excerpts: Enterprise information architecture principles

Principle 1: Information architecture shall be driven by clearly articulated and properly documented business processes.

Principle 3: Any modifications/corrections to master data can be made only according to the rules and policies established by the business, including the rules of resolving data change conflicts; these changes will be made available to all downstream systems based on agreed-upon service level agreements (SLA).

Principle 4: Every data item shall have an identified business owner, a custodian (steward) and a single authoritative source that is used by all enterprise stakeholders (regardless of how many systems may be used to capture and update master data operationally). The authoritative voice should obtain all updates in real time and make policy-based decisions about acceptance or rejection of the change for the purpose of enterprise use.

Principle 12: Information management will include and be based on well-defined data governance rules and policies administered and enforced by appropriately structured and empowered groups, including an Enterprise Data Governance group.

Source: "Master Data Management and Data Governance," 2nd edition, by Berson & Dubov.

Before building the MDG structure, a few myths must be dispelled:

• The first is the myth of “the record.” We sometime refer to “the item record” or “the vendor record,” but seldom is all the relevant item or vendor information contained in a single IT record, nor are all the relevant pieces of information created at one time or by a single department — various fields serve different departments and needs.
• This leads to the second myth — that of “the owner of the record.” To fully attribute resources (e.g. item, vendor, customer, etc.), no single department can be responsible for all facets.
• The third myth is “the department that created the data owns it.” This is the most critical myth to dispose of, but the reason won’t become apparent until better understanding the MDG process. Additionally, there is a division of data responsibilities within a sound MDG structure that provides a valuable set of checks and balances.

Formalizing data governance

To bring effective data governance to life, the entity needs to:

• Establish the framework
• Define the key roles
• Implement the governing structure

It must do it in a way that avoids slipping into “ambiguous bureaucracy” — the risk of making the endeavor about administrative structure building instead of getting data management and governance up and running. As we go through building the governance structure, consider the following (not so) hypothetical situation:

A company is under pressure to merge newly acquired stores into their organization so they can become operational as soon as possible. Unique items they sell must be quickly set up in the merchandising system. This requires related vendors new to the acquiring company first be set up in the contract management and accounts payable systems.

Once internal vendor approvals are completed, an acknowledgement is sent back to merchandising where they are marked approved and item ordering begins. For any of these vendors delivering directly to the stores (DSD vendors), their “approved” vendor records flow from accounts payable to the store’s back door receiving system.

The SVP of Strategic Initiatives pressures the data entry teams in merchandising to “speed up” the item approval process. Not knowing where to turn for process enforcement support, the data entry teams set the flag to “approved” for these new vendors and items.

Things come to a screeching halt when DSD deliveries are rejected at the back door. For deliveries made directly to the distribution centers, accounts payable rejects vendor invoices because the vendors are not yet approved in the financial and contract control systems.

As you read on, contemplate the following:

• Who owns the “vendor approved” field in the merchandising system?
• Who produces the data in that field?
• Who first consumes it?
• Who should dictate the criteria for setting the flag?
• Who is responsible for the initial enforcement of rules? If they are having difficulty with enforcement, where should they turn for help?

Establish the framework

The framework is interwoven with where the organization tracks, or desires to track, along the EIA information management maturity scale (see below). The ideal objective of EIA maturity is having a proactive process in place with established quantitative performance goals for measuring, assessing and maintaining a high level of data quality. This includes feedback loops to key participants so monitoring and process refinements are continuous. There’s no crime in having an initial target that is shy of the ideal — a practical target also helps in the avoidance of “ambiguous bureaucracy.”

Maturity levels

Level 1: Initial
Ad hoc operations that rely on individuals' knowledge and decision-making.

Level 2: Managed
Projects are managed but lack cross-project and cross-organizational consistency and repeatability.

Level 3: Defined
Consistency in standards across projects and organizational units is achieved.

Level 4: Quantitatively Managed
The organization sets quantitative quality goals leveraging statistical/quantitative techniques.

Level 5: Optimizing
Quantitative process improvement objectives are firmly established and continuously revised to manage process improvement.

Source: "Master Data Management and Data Governance," 2nd edition, by Berson & Dubov.

To aid in arriving at a practical EIA-driven MDG objective, one of the outcomes of the business process documentation effort is identifying Critical Data Elements (CDE). It’s easy to say all information is critical, but to make the MDG effort manageable and set a reasonable project scope, there must be a priority ranking. The business should be able to identify the data subsets that are most crucial to the basic execution of their respective processes. Tiers can also be assigned to the resulting CDEs. This further enables a logical, phased approach to the MDM/MDG initiative.

The ideal governance framework consists of:

• Data governance strategy (such as an oversight board or council)
• Data governance organization (like working groups or committees)
• Data governance policies to be based on EIA principles
• Data governance process (i.e., how the work will actually get done)
• Data investigation and monitoring (response procedures are integrated with the process)
• Technology and architecture (an active and accessible library by CDE record and field)

Because most organizations realize they need a (or a better) MDM solution as the horses are leaving the barn, the most practical approach is not to embark on instituting the framework top-down; it is best going middle out. Start with a small working group and begin developing initial governance processes. Over time, grow the working group(s) into more formalized committees that highlight the need for an oversight board or coordinating council.

A suggested initial goal on the EIA maturity curve is also in the middle: Level 3, in which consistency in standards across projects is achieved, with the aspirational goal of getting to level 4 within a reasonable timeframe. Level 3 provides a target for the first working group that they have a vested interest in achieving.

Often a burning platform already exists; you just need to find it. There is usually at least one project relying on MDM that is foundering due to issues around the lack of data governance. I’ve been on IT-driven data clean-up projects in which IT spent considerable time with a group of “assumed” data owners. Decisions are made on valid values for a series of data fields. IT spends numerous days making, testing and implementing the changes. Then, unbeknownst to the first group, a second department calls IT, disagrees and has IT undo the changes. At the very least, people begin to see a platform begin to smoke.

Using an existing project to begin piloting data governance standards yields a far greater return toward enterprise data management maturity then dozens of senior management presentations of governance theory. Work with the project sponsors to begin defining MDG roles for that project. These sponsors will serve as the initial data governance oversight mechanism. Recognize that the end result will serve as the template for the larger overall MDM/MDG project. Eventually this template should become part of the company’s project management playbook.

Define the key roles

For a data governance process to work, a number of key roles must be put in place. The role names may vary from organization to organization and can be tailored to fit into the organization’s culture.  The names are not as important as the functions they serve and their alignment with the business and related business processes. Allow the organization to select terminology that enables them to embrace the substance of role they need to fulfill. Where, when and how various business associates interact with each piece of data determines which of the following roles they play with the respective data fields.

Oversight roles include business data owner and operational process owner. Primary responsibility roles are data guardian, data steward and data custodian. These roles provide the infrastructure for establishing MDG in an organization.

Now that you know how MDM and MDG work together, the importance of establishing a framework with the correct stakeholders and how to define the key roles for success, an MDG structure can come to life. Learn how to do it in part two of this article, "Mastering the Data Domain: How You Can Get Started."

Thomas E. Schmitt, CPA/CITP, CGMA, CISA, is managing director of Thomas E. Schmitt & Company, LLC, a public accounting and management consulting firm in Warrenton. His company works primarily in the retail industry, addressing merchandising strategy and tactics, systems implementation and business transformation.