Customer MDM has a lot of layers of complexity and cross-functional involvement. As these layers become better understood and reveal the coordination needed to successfully drive data quality improvement initiatives, it will be the data stewards who will make the difference between poor and successful execution of the initiatives. For example, it should not come as a surprise if in the analysis of a significant data quality issue, the mitigation plan will require a number of orchestrated tasks from a number of committed resources from across business and IT functions. Often, the IT expertise and resources will already exist—although they may not be immediately available—but on the business side, the resources, skills, and the time commitment needed are often nonexistent or will only partially exist. Business functions or geographies that are most impacted by the problem may try to offer some resources on a short-term or part-time basis. In other situations, use of contractors may have to be considered, but often the cost associated with that has not been planned in anyone's budget—all of which makes it repeatedly difficult to get data management and quality improvement projects underway and fully completed.
Now, contrast that with a scenario where data steward roles have been considered and positioned across the business in key functional and regional areas, are sufficiently skilled and empowered, and can immediately help support the projects and priorities determined through the data governance process. This scenario demonstrates that there is process readiness and business commitment to data management and quality improvement.
In Chapter 2, we presented an MDM roles and responsibility model (Figure 2.2) that included a high-level view of data steward functions and roles shown in Figure 5.1.
Figure 5.1 Data Steward Roles
Let's take a more detailed look at these functions and roles.
MDM Process Core Team
These are the data steward resources focused primarily on the business support and data quality management of the actual customer master environment. This core team and its management layer should be considered the owners of the overall Customer MDM process as well as the caretakers of the customer master environment with a focus across various roles and responsibilities, which we'll be describing further.
MDM Process Management
The fundamental disciplines of a Customer MDM implementation (governance, data stewardship, quality management, and data access management) will contain the majority of the ongoing processes that make up the MDM process model. In addition, there will be other more incidental and discrete processes related to planning, budgeting, vendor management, data integration, and so on. The coordination and management of all these processes, such as when they are engaged, how well they are performing, and where to adjust the dials on them so that the overall MDM goals and objectives are being supported correctly, will be a key focus of the manager and lead data stewards on the MDM core team.
This core team is where executive dashboard formats should be developed and maintained that reflect the performance, quality, and operational well-being of the Customer MDM practice as a whole. These dashboards will typically summarize key status or statistical trends related to governance, data quality, data volume, and budget spend, as well as highlighting the top issues and accomplishments.
This type of status provided or presented by the MDM core team should be part of a regularly scheduled review process between the core team and the CDG council. Outside of the CDG council, there may also be other executive or stakeholder teams that will request similar types of presentations as part of their business review processes or simply due to interest in the Customer MDM initiative. It is good practice to always be prepared with timely and accurate information that can be readily presented regarding the Customer MDM operations.
Lead the Data Quality Forum
In Chapter 6, we will cover the purpose and the content of the data quality forum. This forum should be led by a role we describe as the data quality lead. This lead role should be a part of the MDM process core team, and in addition to facilitating the data quality forum, should also drive the creation and reporting of the data quality metrics and may often need to participate in the CDG council meetings to drive data quality agenda items. The person in this role will work closely with other data quality specialists or analysts in the data quality forum who are representing their functional or regional areas, and this person may also need to represent Customer MDM as part of a broader data quality interest group within the company.
Data Access Gatekeeper
System and data access control has historically been an IT-directed task, and usually carried out in response to a user-submitted and manager-approved request, which may also be subject to security or system access rules that IT will check before granting the permission. In some cases, a user may automatically be provided certain default data access capabilities based on his job role. Unfortunately though, and all too often, this is where awareness and control of user access to the data starts and stops. A lack of sufficient ongoing review and management of user access capabilities will contribute to poor data management and accumulation of excessive capabilities by users, and will make it increasingly difficult to quickly spot and prevent unexpected access or changes to the master data.
In an MDM environment with a customer master that is shared across an application suite and can involve other interfaced systems, there may be a complex variety of data access needs from various user groups involving different combinations of create, update, delete, or read-only type requirements. Often, the customer master application will only provide generic and default data access capabilities and user roles that do not necessarily align well with a company's actual operational practices. In other words, these generic capabilities and roles may be too narrow or too broad and often hard to customize to better fit the business model. If these are applied as defaults, there may be some immediate data access issues that emerge such as users complaining of too little access and not being able to get their jobs done; or if too much access is granted, this can lead to overexposure and ensuing change control problems with the data.
In a broadly used Customer MDM environment, the methodology and control practices related to access management need to be more rigorous and should involve a business gatekeeper function associated with the MDM core team. This gatekeeper function will be expected to define and manage a more robust set of checks and controls in the process that will maintain a tighter and more accurate management focus on who has and receives authority for direct access. This gatekeeper process will be an additional layer injected into the overall access control process which will typically still require a user request, manager approval, and IT to fulfill the request. In Chapter 7, we will go into greater detail on the topic of data access management, along with how to define and manage a gatekeeper function.
Analysis and Measurement
Data stewards need to be analytically minded and need to largely function through the ability to measure, monitor, and maintain various data management and quality elements within a targeted or acceptable range of performance. Previously, we have stressed the importance of having metrics, monitors, and reporting capabilities in place to immediately support data governance and data steward functions. In most cases, it will be the MDM core team that will keep a close eye on these measurements and their trends in accordance with the MDM objectives and CDG standards.
Through regular review and analysis of these measurements and monitors, subtle behavioral aspects of the operational process will be discovered, which can often have significant impact on the integrity and quality of the master data if not managed correctly. Like many things, the more you study something and watch its behavior, the more you learn about how the micro-aspects support or impact the overall system. Following are a few such examples from a Customer MDM perspective:
- Example 1. The customer master data quality metrics are showing an unexpected increase in customer account duplication following implementation of an interface with a new partner management application. Upon further analysis, it appears that on the partner management side a country code attribute was not set up as a mandatory field. This code is necessary to help determine the legal entity and country specific distinction for accounts under the same parent company. When this country code is not entered, there can appear to be duplicate accounts. Changing this to become a mandatory field and updating existing accounts that originated from the partner application resolved the duplication problem.
- Example 2. In the initial phase of a data migration plan, the customer master volume metrics are showing a disproportional ratio of new accounts versus account sites being created. The rule is that all customer entities being migrated should have at least one site designated as the account site, but the migration volumes are showing more accounts than account sites. After further analysis, it was discovered that in some of the data sets being migrated, there were special internal accounts or other exception cases that may not have account sites. The migration logic was corrected to exclude these cases, and any such cases were removed from the customer master.
- Example 3. A monitor is in place that reports cases where the customer name in the customer name field has been changed. There are specific rules and standards that apply to name changes, and only certain authorized groups are allowed to make such changes. The monitor is indicating that some non-authorized users have made name changes. After further investigation, it was determined that a new customer service group had the ability to update the customer name field and was unaware of the control process that should have been followed for name changes. The training for this customer service group was updated to cover the name change process, and the capability to update the customer name field was removed from their data entry forms.
In Chapters 6 and 8, we will dive further into the implementation of data quality management, monitoring, and maintenance practices, but it is these practices that are a central part of the MDM core team's role and analytical focus. From this, the core team will be able to better understand the checks and balances needed in a successful Customer MDM practice. That includes not only understanding how and where to work with the operational process areas and regional data stewards to address corrective action needs, but also—very importantly—to recognize and praise where good quality management practices are occurring in the regional and local teams.
Governance Council Engagement
The MDM core team will generally be the primary engagement point for the CDG council. Although the council members will be expected to directly represent their operational or regional business function, if at the data steward level there is a well-functioning relationship between the MDM core team and the operational process teams, most any significant quality and governance issues should already be visible at the data steward layer with active dialog or analysis in process before the CDG council is actively engaged. In other words, the data stewards associated with the MDM core team and operational process areas should be constantly checking pulse, communicating, and pre-evaluating the open issues and needs prior to engaging the CDG council. In many cases, these data steward teams can address the issues without even needing CDG involvement.
In cases where CDG should be engaged, it will be through this pre-evaluation process that CDG agenda items will need to get properly prepared and presented to the council. Remember, the council will not typically want, nor be able to act on, any items that are not well prepared for their review and decision-making process. In Chapter 4, we discussed how the CDG process should provide a clear set of submission guidelines, a standard format for providing content, and what the process expectations will be.
The MDM core team manager can serve a valuable role in having the responsibility to monitor CDG submissions, ensure guidelines are met, and to facilitate these submissions as part of the CDG council meetings. With these types of roles and responsibilities in place, the MDM core team should become the primary engagement point for the CDG council. This makes sense because the majority of CDG decisions that will require further support will usually be directed back to the MDM core team to act on or define more specific action plans. Therefore, the MDM core team should play an active role in the CDG process.
IT Engagement
Similar to what we just described regarding the core team's role with the CDG process, this team should also be actively engaged in the IT engagement process. Because this MDM core team is providing the business representation for the customer master data and its associated processes, this team needs to be highly involved in IT activities or requests that are related to the customer master data or can have impact on the overall customer operational process. In most cases, this will involve IT-oriented service requests or change requests that are targeted at the system or process points where the customer data is entered or maintained.
In the previous chapter, we pointed out how having data touch-point mapping will greatly assist with identifying where the customer master data is entered or maintained. This mapping will also largely represent the system and process points for any service requests or change requests where the MDM core teams needs to be engaged. In a best case scenario, one or more members of the MDM core team should be formally engaged in the review and approval path for these types of requests. Usually the IT engagement process, similar to the CDG process, will require specific detail and business justification before the request can be further acted on. The MDM core team should be engaged as needed in the preparation of this. Although many general types of IT service requests or change requests can often be handled without CDG council involvement, it is important for the IT process, the CDG council, and the MDM core team to collectively determine the guidelines for how and when to engage CDG with these types of requests.
Operational Process Areas
A comprehensive customer data stewardship model should include data stewards representing the operational teams in sales, marketing, finance, services, and potentially other business functions that are the primary creators, updaters, and consumers of the customer master data. These operational area data stewards work closely with the MDM core team to form an extended customer data steward team responsible for the day-to-day quality focus and data management practices associated with the customer master data. Depending on the makeup of data governance council and the data quality forum dynamics, these data stewards may also be closely involved in those processes.
What is most important is that these operational areas are represented and highly engaged in the Customer MDM model in order to create that top-down and bottom-up data management dynamic discussed in Chapter 2. Let's take a closer look at the responsibilities associated with an operational area data steward role.
Process Area Expert
As we often point out, data stewards need to be dedicated to the MDM mission, have specific roles and responsibilities, and be actively engaged. A passive data stewardship model will not offer much value. Active engagement is accomplished through having specific, data management oriented processes and participation expectations that enable the process area data stewards to be continually engaged. This essentially boils down to two types of expertise that are needed from the data stewards:
1. Being well versed in the overall operational process area they represent, the local business practices associated with it, and the specific process points (e.g., tools, forms, interfaces, reporting, and so on) in that process area that interact with the customer master data.
2. Being fully aware of how the local data entry and management practices can influence or impact the larger MDM picture, and vice versa, how MDM practices or changes can influence or impact the local operational practices.
The ability to leverage this type of process area expertise within a data management context is extremely valuable and necessary for a successful MDM practice. In the past, this type of expertise and context was often only recognized and leveraged by local business reporting teams, or simply may not have been utilized at all. With the emergence of MDM disciplines, this type of expertise can be highly utilized via the data steward roles.
Manage Local MDM Initiatives
From the CDG process and Data Quality forum there will be various initiatives that emerge that can range from complex data migration and integration projects to fairly simple and one-time data cleanup projects. Most such initiatives will have some level of impact to the operational or reporting processes, or at least should require the need for an assessment to determine if there are any impacts. In either case, the process area data stewards—in conjunction with the data council member who represents that business function—will be the point persons who will need to help manage the initiative or at least be accountable for specific action items.
These data stewards will usually work within a specific protocol or action plan framework that the MDM core team, CDG process, or data quality forum has defined, depending on from where the action is being driven. Depending on the depth and complexity of the actions needed, the data steward may need to engage with various teams in the operational areas. Any issues or concerns that emerge with planning or executing the activity should immediately be discussed between the data steward and the CDG council member to determine how to best address the situation. The actions taken or mitigation plans related to issues should all be part of a closed-loop process with the initiating team. Not having effective accountability and closure with local initiatives and actions can often result in later discovery that all expected actions were not fully or properly executed, accompanied by an inability to trace those steps or the root causes of the situation further.
Enforce Policies and Standards
As discussed in Chapter 2 with the topic of ownership, local enforcement of policies and standards is critical in the ecosystem of MDM. Enforcement is a key responsibility of the process area data stewards. Through the governance process, the data stewards should be given sufficient orientation and reference information to understand how and where policies need to be applied and enforced within their process areas. In addition to that, the data steward will also be expected to provide input or feedback with regard to the creation and implementation of policies and standards. Policies and standards need to be realistic and able to be applied locally without causing undue hardship or disruption to the operational processes. If any execution or enforcement issues emerge with regard to these policies and standards, the data steward should immediately review them with the data governance council representative.
Lack of enforcement is one of the primary causes of the garbage in, garbage out (GIGO) issue we often bring to attention throughout this book. Although the GIGO problem is widely recognized, there generally seems to be a lack of focus on addressing this persistent issue. And that, historically, may very well be due to the lack of having MDM and data governance practices in place. It is important to recognize that enforcement of policies and standards is a critical function of the data steward role. In a good MDM model with a solid governance process in place, the ability to declare and enforce policies and standards should be a natural course of action.
Data Quality Control
A constant complaint from the reporting teams or business intelligence teams is along these lines: “Why can't the front end enter the data correctly and consistently so we can trust this data and don't have to keep spending or scrubbing it to make it more useful?” While there is usually truth in this type of statement, it also reflects a shallow perspective with a tendency to place easy blame on the front-end teams. Historically, there has been a disconnect between the front-end and back-end teams. With a broader understanding of the front-end processes and drivers, the complexities and sensitivities that are involved with driving quality improvement become more apparent, and it also becomes clear that data quality will not improve without an end-to-end quality control plan that can enable front-end functions to effectively get on board.
It should be the job of the data governance council in conjunction with a data quality forum to define a reasonable quality control plan. This plan should utilize the process area data stewards who create that quality management connection between the front and back end. As such, these data stewards need to be highly engaged in the data quality management forum and must be prepared to manage action items directed to them. This responsibility will require the data steward to be involved in the analysis, planning, execution, and monitoring of data quality activities associated with their process area. The data steward will also likely need to coordinate with the MDM core team and CDG council to determine what specific areas of data quality are most important to monitor and control within their process area. Ultimately, it is assignment of quality control responsibilities and a shared focus across the process area data stewards that will enable an end-to-end data quality management process.
Raise Issues, Help Resolve
And finally, in addition to having the process expertise and quality management focus we have already described, these process area data stewards need to play a key role in the incident management process. In the next section, and again later in Chapter 8, we will discuss how a company's internal support model needs to support the data management process. With that model in place there needs to be a network of people who are actively involved in that support process, both as a submitters of problems and as persons who can help resolve the problems. Data management and quality improvement is often a circular process. A person who discovers or submits the problem will often also need to help solve and manage the problem. Following are two examples of this:
1. A regional order management team lead submits a service request ticket indicating that a number of customer accounts they have created seem to later be deactivated and merged into another account associated with the same customer. Upon review of this by the process area data steward and MDM core team, it is determined that this regional team has been creating duplicate accounts due to insufficient instruction regarding how to search for and select existing accounts that should be used. These duplicate accounts are eventually identified in the back-end account merge process causing them to be merged into what is considered the master account for these transactions. The data steward and the regional order management team lead work together to correct the team's work instructions to prevent the creation of these duplicate accounts.
2. In the data quality forum, a process area data steward raises the issue that there does not seem to be a consistent standard for how customer names should be entered. This is causing problems for the process area reporting teams who are constantly complaining they have to frequently edit or normalize customer names in order for them to create clean reports for management. The data quality forum and governance council recognize this problem and define standards for entering customer/company names, but because these standards will need to be phased in, the data quality council requires the process area data stewards to complete an implementation plan so that a phase-in schedule can be defined. The data steward completes an implementation plan that is approved.
There can be any number of scenarios like this that will require this type of two-way engagement. A dedicated data steward or process team lead will usually be quite happy to participate in any way possible to help define and resolve the problem as long as there is a support process that is responsive and able to identify sound solutions.