Planning and Design

One of the first and most serious mistakes commonly made with implementing a data governance plan is that it is not considered and planned for early enough. The need for data governance usually emerges only after there has been widespread recognition and executive consensus that data quality and integrity problems are at a sufficient level of impact to warrant a governance focus. A lack of standardization and control of the data will eventually raise its ugly head during data integration or migration projects, or if compliance, privacy, or data security issues are creating risk factors, or if poor data is sufficiently hindering the ability to produce good business intelligence.

Often, large IT projects involving data migration and integration are planned, budgeted for, and launched without a data governance plan, only to quickly realize that there are many business issues with the data definition, usage, standards, mapping, and the acceptable level of quality that need to be resolved before the data migration requirements and integration processes can be completed. Had these issues been better anticipated and a governance forum created early on in the plan to address these issues, the project would have proceeded far more smoothly.

Early consideration and planning for data governance will pay its dividends later. Let's look at how to get a CDG planning and design process started.

Establishing the Charter

There can be any number of reasons why companies begin to recognize the need for data governance, such as:

• Historically, the management, quality, and control of a company's data have been lacking and that now is being acknowledged as causing significant operational, reporting, marketing, or customer satisfaction issues.
• Cross-functional discord due to quality problems, distrust of data, hoarding of data, or lack of a source of truth.
• Issues or risks related to legal or compliance requirements.
• Hardships with data migration and integration related to mergers or acquisitions.
• System infrastructure changes are driving need or opportunity for implementing data governance.

Whatever the drivers are, be sure to zero in on the fundamental needs along with how and where implementing data governance can effectively address the needs. Don't overshoot and assume that data governance can solve or control all the deep-rooted legacy data management or quality issues that have existed, or undershoot with doing just a test pilot focused on some low-hanging fruit that offers little challenge and will hardly exercise the intended governance process. A data governance initiative needs some meaty issues to be in scope, but also needs a realistic sense of approach. Success will be dependent on the governance council having both a dedicated MDM core team and aligned LOB-oriented data steward type teams who can address various tactical needs, data analysis, front-end tasks, user training, or clarification needs that are identified by the CDG process.

Distinguishing a Data Governance Charter

Data governance needs to be clearly distinguished from other types of governing bodies and steering committee charters that typically exist in a company. Don't be surprised if in the initial discussions about data governance there may be some confusion or a perception of overlap with existing steering committees or change control processes that already exist in the LOB and IT practices. To distinguish and advance the data governance dialog, it will be necessary to firmly establish the fundamental positioning and purpose of an enterprise data governance initiative and how it will coexist with other type decision-making charters and processes. When positioned correctly, a data governance function can nicely fill a data management authority void and serve a very valuable role with an existing IT decision-making process and design methodology, as illustrated by Figure 4.2.

Figure 4.2 Example of CDG Interaction with IT Projects and Standard Design Methodology

In general, building the data governance charter should start with gathering together the Customer MDM executive sponsor, as we discussed in Chapter 2, to define and agree on a clear mission, set of objectives, scope and jurisdiction, top priorities, key operating assumptions, the representation and commitment expected, and the budgeting and resource needs. Covering this may require a facilitated process and will likely take several meetings to iron out. In the next sections of this chapter, we provide more context and examples for the charter building and ratification process.

Mission and Objectives

For a CDG initiative, start by considering what will be the fundamental purpose, what will need to be controlled, and what are the key objectives. Answers to these questions will be the foundation of the charter. Following are some examples of statements that describe a Customer MDM charter:

• Establish processes, policies, and organizational principles around managing and protecting customer data as a corporate asset.
• Establish the authority and control board for the decisions related to managing the fitness, quality, and standardization of the targeted data assets.
• Establish Customer Data Governance as a core competency in the company.
• Implement Data Steward and Data Maintenance practices with clear accountability and responsibilities to ensure there will be comprehensive data management and quality management in place for the data assets.
• Enable data governance interaction and influence on the design of data management solutions (e.g., tools, processes, services) and the improvement or resolution of data quality issues (e.g., driving cleanup initiatives, sponsoring Bugs and RFEs, providing a help desk).

For the charter discussions, be sure you can put these statements and objectives into a realistic business case context to help sufficiently qualify the intent so that the executive can easily relate to the underlying data governance issues and needs. This will help enable the executives to more specifically provide their perspectives and expectations regarding these objectives. This is also a critical step in the process to establish executive buy-in and acceptance (remember the CAP equation: Quality × Acceptance = Effectiveness). Be sure there are no hidden agendas. This effort should truly be about implementing data governance practices and not an adjunct to, or reliant on, delivery of other specific business objectives.

Don't assume that the executives will just rubber-stamp your proposed charter. Do assume that you may just initially receive a lot of feedback indicating more clarification or detail is needed before decisions can be made. As we said, the process to nail down and gain approval on a data governance charter will likely require a few rounds.

Scope and Jurisdiction

In preparing the charter, carefully consider, and be able to clearly express, what is in scope and what is out of scope. What is in scope should include the type of data assets and characterization of the types of decisions, policies, standards, systems, and process areas within the data governance jurisdiction. In addition to establishing policy, rules, and direction, governance needs to be both analytical and actionable, so be sure that the scope expresses this aspect, as well. In general, expect that any aspects of the scope could receive a lot of scrutiny and require refinement before gaining approval. Be clear about what is out of scope so that there is no confusion or charter conflict with other decision-making bodies or steering committees.

The scope of your CDG model can vary depending on the approach and positioning of your MDM initiative and how the executive sponsorship falls into place, but in general here are some statements that are examples of how to define and distinguish scope:

In Scope

• The definition and implementation of a customer data governance model.
• Defining and managing policies, rules, and standards governing the quality and integrity of the customer master data including the data entry and data maintenance practices, customer classification, segmentation, relationships, and hierarchy structure.
• Defining policies, standards, and rules related to definition of customer life cycle or 360° reporting views.
• Oversee the IT and business support practices associated with the quality, integrity, and maintenance of the customer master data assets.
• Ensure that the integrity and design of the common customer data model and structure is maintained. Ensure that no particular business practice can alter or compromise this design to accommodate their business needs while adversely impacting other practices and stakeholders using this same functional design and integrated model.
• Define and oversee customer data quality standards, goals, and measurements.
• Oversee all access to this master data. Ensure audit and gatekeeping processes are in place in that meet security, privacy, and other compliance requirements.
• Resource and budget planning for the ongoing customer governance process and core Data Steward and Data Maintenance functions.
• Oversee third-party tools and data or services necessary for enabling the governance practices or management and enrichment of the customer master data (e.g., D&B or other third-party data quality and enrichment services).

Out of Scope

• Data residing in other boundary system or processes areas that may be linked or associated with the customer master data but considered under the control and governance of other data entity or transaction process areas (e.g., products, suppliers, partners, employees, agreements, materials).
• Other transaction systems' or boundary systems' business rules, metadata, configurations, and policies defined for those processes that are not directly associated with the assets, rules, policies in scope of Customer Data Governance.
• Design, implementation, release management, or Change Control Board (CCB) functions related to specific infrastructure, applications, or processes that may utilize or interact with this master data. This data governance role and function should align and have influence with other IT or Business program functions or steering committees but will not be a replacement or overlapping management function for those other charters and jurisdictions.

Roles and Responsibilities

The charter should clearly define the roles and responsibilities expected in the governance model, but should not necessarily get hung up on dictating that only specific titles and job levels be engaged in the governance team. Yes, it is very important to involve the right leaders and influencers in a governance model, but equally important is to engage the doers, who are empowered to act on what needs to be addressed. Who is in command and control of the data can vary greatly across different business functions. This can typically vary between director, manager, analyst, functional lead, or IT consultant roles. Ensure that the person representing a business or IT function who has the best ability to engage, understand, and execute governance actions is part of the team. Title is less important.

In Chapter 2, we presented an MDM roles and responsibility model (Figure 2.2) that presented a high-level list of the governance roles, which are shown here in Figure 4.3.

Figure 4.3 Customer Data Governance (CDG) Roles

In the remaining sections of this chapter, we'll touch more on the context for each of these role descriptions, but as we discussed in Chapter 2, we want to reiterate that ownership and governance need to be a carefully orchestrated dynamic in a successful MDM practice. Because a Customer MDM practice is sufficiently complex due to its cross-functional nature, it will be necessary to plan and implement an effective cross-functional engagement model in combination with a well-defined and coordinated set of roles and responsibilities as part of the data governance process.

Most importantly, a LOB representative—typically a director or senior Manager—on the CDG council will need to have sufficient authority and influence with the functional team or teams that enter customer master data. Establishing a close and beneficial relationship with the functional teams is key to MDM success. A LOB representative who does not have sufficient authority and influence with these functional teams will not provide much value to the MDM initiative and CDG process. Insufficient authority and influence may also reflect a lack of genuine engagement or commitment from that LOB with regards to the MDM initiative and governance charter. Getting the right type of LOB representation on the CDG council may actually take a few attempts. Often, it is not until the CDG process has been initiated and the priorities and expectations are more fully vetted out, that the right type of representation will settle in.

Council members with sufficient authority and influence will typically need to work closely with designated data stewards or team leads in the LOB processes areas where the data entry occurs. These data stewards or leads will provide the ground-level eyes, ears, and task management focus needed to monitor, coordinate, and carry out specific actions driven from the CDG council.

Set Top Priorities

Set top priorities initially for activities that support immediate, actionable, and foundational needs that also align well with the overall CDG objectives and roadmap activities or are needed to help support critical operational problems that have been identified. Avoid setting top priority for interests that are too ambiguous, have too many dependencies, are not of immediate need, or simply don't have the right underlying foundation in place yet to realistically be addressed.

Let's again refer to the example we used earlier in the Figure 4.2 where there is a requirement to convert all U.S. postal codes associated with ERP activity from the current five-digit format to the nine digit (ZIP+4) format in order to support implementation of a new tax calculation engine. Let's just say that there is a six-month window to complete this conversion. In order to meet that goal there are a number of actions needed, such as to analyze the current state of the zip codes, determine the scope, impact, and amount of existing codes that need to be converted, use a U.S. postal code reference for address and zip verification, and ensure the data entry teams and BI teams are oriented and preparing for this change.

Each of these actions needs to be prioritized against each other so that the right sequence of actions and dependencies are addressed. For example, to initiate the data analysis and scope activities, there may be a concurrent set of immediate actions needed, such as a dependency on a reporting team or data analysts to run some current state reports, a business impact assessment needs to be conducted, and a need to immediately identify the method and cost for doing the postal code verification against the U.S. postal code reference. These actions become top priorities because of their immediate need and other activities being dependent on this. Once these initial top priorities are addressed, the next set of top priorities will emerge, and so on.

The CDG council needs to be very interactive and able to quickly address a variety of business- and IT-involved actions that will typically be part of MDM projects and issues.

Let's look at another example involving data migration and integration. A company-wide systems infrastructure initiative is underway where processes and data from various legacy systems are being migrated to a new integrated application suite that will be sharing a common customer master. The processes and data from the legacy systems will phase in over a two-year period. A similar situation may also exist in a merger or acquisition scenario. In either case, a CDG council may have to set top priority on support of the data migration plans and defer initiatives to improve various quality aspects of the customer master data until all or most of that data migration phases are completed and the data is in a fully integrated state.

In general, a CDG charter needs to be broad and specific enough to allow the council to always balance focus and decisions between efforts to improve data and quality management needs and with efforts to help address operational needs or issues related to data.

Resourcing and Budgeting

The formal interactions and decision making expected from the CDG council will be largely based on need, priority, time, and budget considerations similar to other business decision processes. And like all business functions, the CDG council will need to weigh new initiatives versus other priorities, support of ongoing functions, and possibly consider spend reduction in conformance with the fiscal plans of the company and the sponsoring organization. Because many Customer MDM activities, particularly data cleanup projects, will often require a cross-functional effort, the CDG executive sponsor and the other members of the CDG council will need to plan for and facilitate cross-functional budget planning and resourcing needs. This will be a critical success factor.

Inability to sufficiently anticipate and coordinate this dynamic can severely limit or even kill the ability for MDM to execute effectively. As an example, consider how your CDG council will need to handle these types of budgeting or resourcing scenarios:

• An annual budget is required for third-party services and licenses that are needed for customer data enrichment, credit management, customer research, customer entity matching, hierarchy management, or other needs.
• Incremental budget is needed to evaluate and potentially purchase some new data profiling and analytical tools that now are emerging in the MDM market that could greatly assist areas such as data analysis, quality assessment, and metadata management. These tools would give your data analysts and stewards the ability to get their jobs done more efficiently and effectively and with less dependency on IT support.
• Consultants are needed for a six-month project to help scope, define, and pilot a data quality dashboard requiring standardized validation rules and measurements that the CDG council will use to evaluate data quality and target where improvement needs to be focused.
• Some data security and compliance issues have been identified that require immediate attention and remediation by IT and certain business teams. Some resources will need to be temporarily shifted off of some existing projects to address this problem.
• Corporate spending has tightened up and each LOB is tasked with cutting back on projects and expenses. This will impact CDG-related projects and resources. The CDG council needs to reprioritize their plans and coordinate changes in line with the cutback expectations.

Be sure that the CDG council has the charter to be able to effectively address these types of scenarios.

Ratify the Charter

Once the charter has been fully defined and discussed by the CDG council, be sure that all executive sponsors and council members formally declare their approval for the execution of the charter. This ratification is critical for the communication and ongoing legitimacy of the CDG process. A clear and solid charter in place with an active and effective council will continue to demonstrate its value within the company and in coordination with other steering committee and decision-making processes.

Over time it may be necessary to adjust the charter and council member roles in line with organizational or other corporate changes that will typically occur in a company, but adjusting what has been a good existing charter should be a much easier task than having to build a new one.

Policies, Standards, and Controls

With the charter ratified and the council engaged, there are still some important CDG process planning and design activities that need to be addressed before preparing to launch the process.

Define Key Policies, Big Rules, and Quality Standards

Customer master data is largely a fixed asset with only a limited amount of ability to maintain, change, enrich, or cleanse it. Therefore, its value is highly dependent on how accurately the data is captured and how relevant that data is in context to its usage. The responsibility for this primarily falls on the data entry processes. These data entry processes are where the governance council needs to have sufficient influence to ensure that data standards, validation rules, and quality control expectations are actively involved in the process.

The ability to accurately capture customer identity info such as name, address, contact info, and tax IDs may seem to be a rather straightforward task, but then consider that it is often dependent on how and where a person enters this data and to what degree this data entry event is subject to a fixed format, validation rules, field length limitations, and so on. Local data entry behavior is typically influenced by the requirements and limitations associated with the particular application and business process being used. Then consider that these types of data entry conditions can vary by system, application, region, or country.

The net result is that the aggregate quality and consistency of this data from these various entry processes will undoubtedly be poor unless common rules, standards, and controls have been applied to these data entry processes by a governance process. This is where governance influence matters most. The extent that governance rules, standards, and monitoring capability can directly influence master data entry practices and specific work behavior—but without undue burden that could negatively impact transactional performance—will reflect how well data governance is effectively in motion with a company. Governance policies, rules, and standards will have little impact if they are not appropriately positioned and effectively enforced. Figure 4.4 reflects how data entry practices in an integrated environment need to be bound by common rules and standards.

Figure 4.4 Common Standards and Rules with Entry of the Customer Master

Define Key Metrics, Monitors, and Quality Improvement Targets

There is nothing worse than a new governance council getting out the door only to find a blind alley. Once the charter and expectations are set, the CDG council and process will be expected to begin demonstrating effective monitoring and governance of the customer master data. To do this, there needs to be at least a baseline level of information available about the current state of the data and its quality. Therefore, before launching the CDG process the council needs to establish the necessary baseline information and ability to begin tracking this.

Key metrics—often called Key Performance Indicators (KPIs)—as well as a tracking process will need to be defined and initially implemented to start serving as the Customer MDM baseline metrics and monitors when the CDG process is launched. These key metrics should generally cover at least the basic volume and quality measurements needed to report and monitor the fundamental statistics and incremental changes (at least weekly or monthly) associated with the customer master data. Chapters 6 and 8 will cover this in much more detail, but suffice to say that having a baseline understanding of the makeup, volumes, and quality of the customer master data is fundamental for the CDG council to operate effectively. This baseline data will also be necessary for setting any immediate priorities associated with quality improvement. With this baseline data, the CDG council should be able to at least start seeing the obvious quality issues or other concerns that should become targets for further analysis and improvement plans.

Once CDG is launched, it can be expected that there will be a need to further expand on the metrics and monitors in line with CDG objectives to drive more standardization, improve data quality, or monitor critical process events that can impact data integrity. Expansion of such metrics and monitors is a natural and ongoing aspect of an MDM practice.

Identify Data Entry Points and Team Leads

Similar to establishing metrics and monitors to at least ensure a baseline understanding of the customer master data and its quality, a CDG council needs to have a clear understanding of the customer master data entry points and what processes have create, update, and delete capability with this data. You can't begin to govern this if you don't know who is touching the data and where this is occurring.

As part of the CDG planning, an exercise needs to be conducted to identify these entry points, what business functions are involved, and who the team leads are for those processes. This is an exercise where a consultant can be very helpful with gathering and summarizing this information. The summarization of this can create a very valuable and maintainable matrix that will serve as a fundamental roadmap indicating who, how, and where in relation to the entry and change of customer master data. Table 4.1 provides a very basic example of this matrix. This type of matrix can, and probably should, be expanded to add other useful details related to the processes, rules, and maintenance teams associated with the data element and its touch-point conditions.

Table 4.1 Example of a Data Entry Point Matrix.

As we'll discuss and illustrate in more detail in the next chapters, establishing this type of roadmap and entry point detail will serve as a common and underpinning thread across Data Governance, Data Stewardship, Data Quality Management, and Data Access Management.

Quality and Service Level Agreements

There are essentially two levels of quality agreement that should be addressed. First, as part of the ratification of the CDG charter, there should be high-level agreement across the CDG board that ensures each board member is committed to the CDG mission, objectives, and the data quality management goals. Second, at the operational level it is good practice to implement service level agreements (SLAs) where appropriate with IT or between business teams where data maintenance expectations exist.

It's important that an SLA reflect reasonable expectations and corrective action time or it will quickly become an ineffective instrument that may have only resulted in creating contention between the parties if the expectations cannot be reasonably met. Also, consider that it is far better to allow some latitude and demonstrate some patience with regard to getting the support needed than to regularly disparage a support team for not always meeting the SLA terms and conditions. Support teams generally do want to meet their obligations and have happy customers, but backlogs, resource issues, and shifting priorities are all realities in the service delivery business. Quality improvement needs will typically compete with, and often take lower priority to, operational support needs. So keep this in mind and be prepared to accept or make adjustments to SLAs from time to time.

What's most important is to maintain a good flexible relationship between the data users and the support teams that will continue to enable support and address data maintenance needs as part of the ongoing ebb and flow between operational and data management practices.

Define Critical Metadata Management Needs

In Chapter 3, we spent some time on the topic of metadata management, including some of the challenges and problems associated with organizing and managing it. Although pulling together, managing, and maintaining metadata with a comprehensive cross-domain solution—usually requiring an IT solution—can be one of the more complicated and hard to achieve aspects of MDM, from a customer data governance perspective, there are a few areas of metadata that will be critical to focus on and ensure that this information is accurate and easily available for reference by the CDG council.

Entity Relationship Diagram (ERD)

Often, this is metadata that only the IT or business reporting teams are familiar with or have access to. Being at least generally familiar with the conceptual representation of the customer master data should also be a requirement for the CDG Council, MDM core team, and other associated data steward teams that are engaged in overall MDM practice. Having an ERD easily accessible, or even printed in hard copy and posted on your office or cubicle wall, is a great way to stay familiar with the data model.

Data Dictionary or Attribute Listing by Entity Type

Again, this is also metadata that isn't often generally available to the business teams, but typically will exist somewhere along with the ERD. If a formal metadata repository exists, there should be some form of a data dictionary there. Depending on what work went into creating the data dictionary, the level of detail may vary significantly. What's most important is that for each data element associated with a data entity (as represented by the ERD), there is at least the name, definition, size, type, and any relevant comments related to use and ability to modify the data element. In some cases, not all of these data elements will actually be implemented, and there should be information in the application setup documentation indicating what data elements were actually implemented and if any custom elements were defined and implemented. An accurate and well-maintained data dictionary, or other form of data attribute listing by entity type, is must-have reference information for a data governance process. In the Data Stewardship and Data Access Management chapters we'll see how this type of reference information is utilized in the various data management tasks.

Data Element Business Definition

The previously mentioned data dictionary or attribute listing will typically just reflect the generic out-of-the-box data definitions and descriptions. As the applications that use these data models are set up and implemented there is typically some form of adaptation to business practices and business definition that will replace or add to the generic data definition. Capturing and managing this business definition should be a key responsibility of the data governance process in alignment with IT and any general metadata management practices. All business definition of the data should be maintained directly with the existing data dictionary or data attribute listing so there no confusion or conflicting references to the data definition.

Policies and Standards

A data governance council and process need to ensure that data governance policies and standards are well documented, communicated, and enforced. The governance council needs to define a simple method where such policies and standards can be easily referenced. If a company already has a flexible metadata management solution in place, then adding or linking to policies and standards information should be able to be accommodated, but often that will not be the case. Short of that, the CDG council and the MDM core team should determine what other documentation and posting methods can best serve this need. In many cases, the policies and standards will relate to specific data entity areas or even specific data elements (e.g., customer name or address standards, DUNS or SIC code standards, data privacy policy and rules). In such cases, the CDG council should consider how to cross-link policies and standards with the data dictionary or data attribute listing. Being able to identify the policies and standards associated with specific data entities or elements is, quite simply, good governance practice.

Mapping and Cross-Reference Information

Some form of data mapping and system cross-reference tables will typically exist in an MDM environment. In Chapter 1, we covered various MDM architectures where data mapping and cross-reference tables are involved. Whether that is in relation to how converted data was mapped to the master data model, how data is mapped over a systems interface, or how a systems cross-reference table is maintained to express how entities such as parties and sites are connected between systems and what the original source of data is, understanding this mapping and cross-reference data is critical to understanding the integrity, origin, and reach of the data. Not being able to understand this mapping and cross-reference can lead to uninformed decisions that can severely impact many stakeholders in the food chain of the master data.

Additional types of reference information related to data quality, volumes, users, types of usage, and access to or maintenance of the data, is also critical information that the CDG Council will need to be able to reference and potentially associate to the previously mentioned metadata areas, but because we don't consider this additional information to necessarily be considered metadata—as opposed to just being metrics or type of operational information—we cover the description and need for this additional reference information more specifically in other chapters.

Since the common types of metadata can represent a large amount of detail about the data, what's most important is to zero in on—and to more conveniently summarize if needed—the metadata that will frequently be needed to accurately understand the structure, definition, policies, standards, and where applicable, how the customer master data is mapped or linked to other data in the overall architecture and boundary system model. Understanding and being able to easily reference this key metadata is essential to developing the core knowledge and underlying awareness that a CDG Council and the associated data analysts and stewards must possess. This type of metadata should not be buried or restricted to just IT access.