Mastering the data domain: How you can get started

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

This article complements “Master the Data Domain,” which appeared in the January/February 2019 issue of Disclosures. That article discusses how CPAs are uniquely qualified to help implement Master Data Governance (MDG) — essential for Master Data Management (MDM).

Part 1, “Master the Data Domain,” outlined the necessity for a Master Data Governance (MDG) mechanism to complement a Master Data Management (MDM) undertaking. This article details the roles of MDG and how to implement them, and that data governance is built around data fields versus data records.

From a very binary perspective, within a company’s business processes, data is either 1.) produced; or 2.) consumed. Produced includes created, captured, modified or deleted. Consumed means the data causes or enables someone (or a process they control) to take an action or make a decision. Key role assignments are based on whether someone produces or consumes the data. Data consumers have the greatest vested interest in the data being correct.

Often the producers and consumers of a data element reside in different departments. A data element can be consumed by Department A. Department A can then produce a new piece of data (based on a calculation or the execution of an instruction) that is consumed by Department B. The data produced by Department A and consumed by Department B would be a new piece of data stored in a separate field from the one Department A initially consumed. For example, Department A consumes an order number, fills the order and then produces a shipment number. Department A sends the shipment number to Department B, which consumes the shipment number so the items can be loaded and sent.

It is also common that the same piece of data is consumed by multiple departments. In the above example, Department B would likely consume the order number along with the shipment number; Departments A and B both consume the order number. Another good example is product code. A product code is consumed and used by the buying department to order product. It is also consumed by warehouse management to enable the receiving, storing and shipping of the product. Pricing teams need it to add the item to the point-of-sale systems. The shelf management team needs it to properly place it on the shelf and authorize it to the store.

For data governance purposes, it is necessary to distinguish between:

• The first consumer of the data: Considered to be the key consumer, and
• Downstream consumers: Considered to be the key consumer’s data constituents.

The outcome of the business process mapping sessions will identify who the first data consumer is versus the downstream consumers. In some instances, there can be some ambiguity in isolating the first consumer. In these rare cases, the oversight roles will make the final designation.

Primary Role Descriptions (those with day-to-day execution responsibilities):

Data Guardian: The key consumer of the data. Functionally applies the data on a routine basis; identifies critical data elements (CDEs) and provides the business rules with respect to acceptable data (in consultation with their data constituents); interacts directly with the data stewards and provides needed controls to the data custodians.

Data Steward: Person responsible for the inputting, capture or creation of the CDEs (i.e. the data producer). Works with the data guardians to implement control procedures; ensures data quality at the time of entry and maintenance; seeks clarifications and support from data guardians as needed.

Data Custodian: Usually in IT. Responsible for the data infrastructure, applications and related electronic data storage; routing and processing controls to ensure programmatic support of the activities of the data guardians and data owners.

These primary roles are the active control mechanisms.

Oversight Role Descriptions (those having departmental level responsibilities):

Business Data Owner: Owns the rules for the data field. The executive ultimately responsible for the business decisions made with the data field. Responsible for the reliability, supporting security and privacy of the data fields within his/her purview, including responsibility for business quality monitoring; has corporate level authority; appoints the data guardians.

Operational Process Owner: Owns entry and maintenance execution for the data field. The executive ultimately responsible for producing/capturing the data on a timely basis and having procedures in place to ensure that the data is complete, accurate and consistent with the business rules defined by the business data owner; has corporate level authority; appoints the data stewards.

These oversight roles are critical because the strength of the controls is derived from them. Significant issues, observations and recommendations from the primary levels should be raised to the corresponding oversight levels. This includes where inappropriate pressure is being applied to the guardians or stewards.

Implementing the Governing Structure

Using the pilot project and the results of the business mapping sessions and working with the respective data producers and data consumers, the team can begin compiling a governance dictionary. (The data custodians may eventually develop an automated repository where this can reside and be made available to the enterprise.) The governance dictionary would have a table for each data record with a row for each data field and columns listing the:

• Name of the Data Field
• Description of the Data Field (agreed upon by the Guardian and Steward)
• Business Data Owner
• Operational Process Owner
• Data Guardian
• Data Steward

The initial phase would focus on the tier 1 CDEs. Completing this table requires a number of sessions as supplemental research and intra-departmental discussions are needed. It frequently takes a few iterations for the participants to truly grasp the roles and how they are designed to interact. A CPA who is a Certified Information Technology Professional (CITP) or Chartered Global Management Accountant (CGMA) can play a critical role as the facilitator of these sessions.

The oversight roles provide levels of support and recourse for the primary roles. It is not uncommon for stewards and guardians to come under pressure from other departments to bypass standards or requirements for the sake of perceived expediency. Think of Example #2 from Part 1.

To help flesh out the business governance roles a little more, consider the following statements related to each role when identifying who should fill it:

• Data Steward: “The information is sent to me; it’s up to me to get it into the system correctly.”
• Data Guardian: “If the data is wrong, I can’t do my job.”
• Operational Process Owner: “If bad data disrupts the business process, I’m ultimately on the hook.”
• Business Data Owner: “If the business function that produces the data doesn’t execute correctly, I’m ultimately on the hook.”

Figure 1, below, depicts the roles and their interaction.

Referring back to the questions posed in Example #2 in Part 1:

• The supply chain executive is the business data owner over the vendor-approval field even though it originates in the merchandising system; the manager of the purchasing/supply chain team would be the data guardian over that field.
• Merchandising produces the data in the vendor and item fields; the merchandising executive would be the operational process owner for these fields.
• The purchasing/supply chain teams are the first data consumers of the vendor approved field — they are responsible for rules management and would dictate the criteria for that field.
• There are also downstream data constituents whose needs purchasing/supply chain would need to consider when dictating criteria.
• The merchandising teams are the data stewards over these fields and are responsible for the initial enforcement of rules. If they are having difficulty with enforcement, they should turn to the data guardians. The data stewards should also advise their own merchandising management (the business data owner) so execution management and rules management (inclusive of the operational process owner) work together to resolve the issue.

During the implementation of an MDM system, discussing and assigning these roles sometimes results in new data fields being needed. Considering Example #1 from Part 1, the team could clarify the existing field is “last shipment from supplier” and request a new field be created for “expiration date for store shipping”; there are likely different consumers for each of these fields.

The data guardians, data stewards and data custodians from the pilot project should constitute the initial Data Governance Working Group; the initial business data owner(s) and operational process owner(s) constitute the initial Data Governance Oversight Council, along with the CIO.

The Working Group and Oversight Council would work out the detailed procedures for the entity such as resolving contention over MDG role assignments, ensuring all CDEs are identified and addressed, and periodically producing initial compliance or data error monitoring metrics. They would also be the clearing house for new master data fields that may be requested. These roles would be in addition to their regular day-to-day responsibilities; these should not be incremental FTE additions for the organization. They would consult other internal departments as needed — for things such as customer data privacy requirements, etc. Figure 2, below, depicts initial governance formation.

Over time, the scope of the initial governance organization could expand as the organization makes its way up the EIA maturity curve. This would be the impetus to begin moving from “managing” standards within projects to “defining” them across projects and organizational units. Guardians, stewards, custodians, data owners and process owners would be added as they become part of the enterprise’s MDM/MDG effort. Eventually, a formal data governance officer could be put in place and seats given to representatives from the law and finance departments. It should evolve from ad hoc status to formally falling under one of the business chiefs — ideally not IT. MDM can be seen as IT-driven, but MDG — data content, should be cemented as a business responsibility. As strategic shifts occur in the business, the chief executive can communicate them to the Council so new data governance needs or risks can be proactively vetted. Figure 3, below, shows target MDG organization.

For the CITP or CGMA, becoming an integral active member of the MDM project team is an excellent opportunity to help the organization make the most in gaining control of their data by bringing the need for MDG to the table. The role can begin with leading or co-leading the business process mapping sessions where MDG gaps can be illustrated.

Helping the project team understand that in addition to the right data models and architecting the system correctly, the content of each data field, and the controls surrounding it, need to be rationalized by the business and properly owned and guarded. The resulting data governance structure becomes the forum for maintaining the quality of the data in the organization’s enterprise systems and for effectively and efficiently evolving it as needed. The result is

• Improved data integrity: More reliable information for improved decision-making
• The elimination of wasteful business cycles researching and resolving transaction errors
• Improved customer service through more efficient supply chain and other mission-critical support processes

This is a true value-add opportunity for the CPA.

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. Contact him at [email protected] or find him on LinkedIn at linkedin.com/in/thosschmitt.