Designing an MDM project plan

Creating an MDM business case

2.2 COMMUNICATING BUSINESS VALUE

Interestingly, there is a difference between establishing a reasonable business case supporting the transition to MDM and communicating its value. In Chapter 1 , we looked at a number of ways that a synchronized master data asset supports business productivity improvement associated with organizational initiatives and increasing the organization's ability to respond quickly to business opportunities. However, this message is typically pointed upward in the management chain to achieve senior management buy-in and championship; it does not address the value proposition for each participant and stakeholder.

This becomes particularly important at the beginning of the program when assembling the right team to do the analysis and design, because the people with the most subject matter expertise in each line of business are the same people who are likely to be affected by a transition to a new underlying information layer. Therefore, there is a need for the program champions to engage the business managers in a way that demonstrates the specific value that MDM provides to each line of business.

Buy Master Data Management on Amazon.com

Therefore, as opposed to the organizational business value that was explored in Chapter 1 , the value proposition for each stakeholder focuses more on improving that person's ability to get the job done effectively. This may encompass a number of different aspects of productivity improvement, including but not limited to the notions of improved data quality, reduction in need for cross-system reconciliation, reduction in operational complexity, simplification of design and implementation of applicationware, and ease of integration.

2.2.1 Improving Data Quality

As more inadvertent replicas of the same data instances are consolidated into a unique representation, there will be fewer opportunities for data duplication errors to occur. At the operational level, reducing the number of errors also reduces scrap and rework, the acute need to react to data failures, and the ability to focus resources on productive development and operations management instead of fire fighting. In the long term, MDM improves the trustworthiness of the data, thereby increasing businesspeople's confidence in using the data.

2.2.2 Reducing the Need for Cross-System Reconciliation

The ability to access organizational data sets, copy them locally on the desktop, and configure locally prepared reports is a boon to the business client. However, the proliferation of these "spread-marts" that report based on a statically copied view of the data creates a situation where there are discrepancies that are related to the time that the data was copied or how it was manipulated at the desktop. Variations in reported values must be investigated, and when the source data are pulled from different origins, there is a mad scramble to reconcile numbers, sums, accounts, and so on. Reconfiguring the report generation process to be driven off the master data asset reduces the need for cross-system reconciliation.

2.2.3 Reducing Operational Complexity

Whether an organization grows organically or through acquisitions, the result is that line-of-business application development will have been geared toward acutely developing applications that support the operations of the business. However, there are aspects of each business operation that must coordinate through existing systems. For example, sales transactions, no matter the system through which the system originates, must interact with the organization's order fulfillment system.

With a proliferation of applications and corresponding internal representations of each data entity, there is a great need to coordinate the many interfaces necessary to make the different applications talk to each other. MDM addresses this issue by providing a master data object model that can be used for both information persistence and application communication. Standardizing the interface into and out of the common representation significantly reduces the overhead and management complexity associated with the multitude of connectors to be put in place.

2.2.4 Simplifying Design and Implementation

There are three aspects of master data management that simplify the design and implementation of new applications and improve existing applications. First, it is less the existence of a master data asset (whether it is a single physical repository or one that provides a virtual view across enterprise data sets via a registry) than the existence of master metadata that simplifies application development. A master metadata repository captures the whole story associated with data element use. Instead of a glorified data dictionary, enterprise business metadata combines the knowledge derived from an intelligent analysis of enterprise data sets and the definitions and meanings assigned by subject matter experts. This integrates the semantic analysis associated with names, shapes, structures, formats, associated reference data, and, most important, definitions of data elements collected from across the organization.

The resulting metadata asset becomes an encyclopedia of knowledge of the way that data elements are used in different business purposes and how similar uses are truly distinguished. The ability to have this master metadata available reduces the effort at the beginning of the implementation in designing data models to meet defined business needs for application functionality. Master metadata is discussed at length in Chapter 6.

The second simplifying aspect is unique identification . Many applications frequently need to uniquely identify entities, and the approaches different application programmers use to sort through the set of records that match against identifying information are often diverse and inconsistent. Standardizing the process for unique identification reduces the need for each application developer to design the process at the application level and instead allows the developer to reuse the capability engineered into the master data environment. Tools contribute greatly to the ability to support unique identification, as we will cover in Chapter 10 .

This leads to the third simplifying aspect, which is the ability to define and standardize many different kinds of master data services , which we will cover in Chapter 12 . Clearly defining the component services at the core and the application layers provides a means for unifying the enterprise application architecture, thereby freeing the developers to focus on supporting the application business requirements.

2.2.5 Easing Integration

Simplifying the core representative models and standardizing metadata and access services makes it easier for applications to talk to each other. In fact, as a by-product of the aspects discussed in Sections 2.2.3 and 2.2.4 , reducing complexity and harmonizing metadata and exchange interfaces will better enable applications to conform to an enterprise application architecture driven by business expectations instead of line-of-business functional needs.

Managing an MDM project team

2.3 STAKEHOLDERS

Who are the players in an MDM environment? There are many potential stakeholders across the enterprise:
 

• Senior management
• Business clients
• Application owners
• Information architects
• Data governance and data quality practitioners
• Metadata analysts
• System developers
• Operations staff

Here we explore who the stakeholders are and what their expected participation should be over the course of program development.

2.3.1 Senior Management

Clearly, without the support of the senior management, it would be difficult to execute any enterprise activity. At the senior level, man agers are motivated to demonstrate that their (and their teams') performances have contributed to the organization's successful achievement of its business objectives. Transitioning to a master data environment should enable more nimbleness and agility in both ensuring the predictable behavior of existing applications and systems and rapidly developing support for new business initiatives. This core message drives senior-level engagement.

Senior management also plays a special role in ensuring that the rest of the organization remains engaged. Adopting a strategic view to oversee the long-term value of the transition and migration should trump short-term tactical business initiatives. In addition, the senior managers should also prepare the organization for the behavioral changes that will be required by the staff as responsibilities and incentives evolve from focusing on vertical business area success to how line-of-business triumphs contribute to overall organizational success.

2.3.2 Business Clients

For each of the defined lines of business, there are representative clients whose operations and success rely on the predictable, high availability of application data. For the most part, unless the business client is intricately involved in the underlying technology associated with the business processes, it almost doesn't matter how the system works, but rather that the system works. Presuming that the data used within the existing business applications meet the business user's expectations, incorporating the business client's data into a master repository is only relevant to the business client if the process degrades data usability.

However, the business client may derive value from improvements in data quality as a by-product of data consolidation, and future application development will be made more efficient when facilitated through a service model that supports application integration with enterprise master data services. Supporting the business client implies a number of specific actions and responsibilities, two of which are particularly relevant. First, the MDM program team must capture and document the business client's data expectations and application service-level expectations and assure the client that those expectations will be monitored and met. Second, because it is essential for the team to understand the global picture of master object use, it is important for the technical team to assess which data objects are used by the business applications and how those objects are used. Therefore, as subject matter experts, it is imperative that the business clients participate in the business process modeling and data requirements analysis process.

2.3.3 Application Owners

Any applications that involve the use of data objects to be consolidated within an MDM environment will need to be modified to adjust to the use of master data instead of local versions or replicas. This means that the use of the master data asset must be carefully socialized with the application owners, because they become the "gatekeepers" to MDM success. As with the business owners, each application owner will be concerned with ensuring predictable behavior of the business applications and may even see master data management as a risk to continued predictable behavior, as it involves a significant transition from one underlying (production) data asset to a potentially unproven one.

The application owner is a key stakeholder, then, as the successful continued predictable operation of the application depends on the reliability and quality of the master repository. When identifying data requirements in preparation for developing a master data model, it will be necessary to engage the application owner to ensure that operational requirements are documented and incorporated into the model (and component services) design.

2.3.4 Information Architects

Underlying any organizational information initiative is a need for information models in an enterprise architecture. The models for master data objects must accommodate the current needs of the existing applications while supporting the requirements for future business changes. The information architects must collaborate to address both aspects of application needs and fold those needs into the data requirements process for the underlying models and the representation framework that will be employed.

2.3.5 Data Governance and Data Quality

An enterprise initiative introduces new constraints on the ways that individuals create, access and use, modify, and retire data. To ensure that these constraints are not violated, the data governance and data quality staff must introduce stewardship, ownership, and management policies as well as the means to monitor observance to these policies.

A success factor for MDM is its ubiquity; the value becomes apparent to the organization as more lines of business participate, both as data suppliers and as master data consumers. This suggests that MDM needs governance to encourage collaboration and participation across the enterprise, but it also drives governance by providing a single point of truth. Ultimately, the use of the master data asset as an acknowledged high-quality resource is driven by transparent adherence to defined information policies specifying the acceptable levels of data quality for shared information. MDM programs require some layer of governance, whether that means incorporating metadata analysis and registration, developing "rules of engagement" for collaboration, defining data quality expectations and rules, monitoring and managing quality of data and changes to master data, providing stewardship to oversee automation of linkage and hierarchies, or offering processes for researching root causes and the subsequent elimination of sources of flawed data.

2.3.6 Metadata Analysts

Metadata represent a key component to MDM as well as the governance processes that underlie it, and managing metadata must be closely linked to information and application architecture as well as data governance. Managing all types of metadata (not just technical or structural) will provide the "glue" to connect these together. In this environment, metadata incorporate the consolidated view of the data elements and their corresponding definitions, formats, sizes, structures, data domains, patterns, and the like, and they provide an excellent platform for metadata analysts to actualize the value proposed by a comprehensive enterprise metadata repository.

2.3.7 System Developers

Aspects of performance and storage change as replicated data instances are absorbed into the master data system. Again, the determination of the underlying architecture approach will impact production systems as well as new development projects and will change the way that the application framework uses the underlying data asset (as is discussed in Chapters 9, 11, and 12 ). System analysts and developers will need to restructure their views of systemic needs as the ability to formulate system services grows at the core level, at a level targeted at the ways that conceptual data objects are used, and at the application interface level.

2.3.8 Operations Staff

One of the hidden risks of moving toward a common repository for master data is the fact that often, to get the job done, operations staff may need to bypass the standard protocols for data access and modification. In fact, in some organizations, this approach to bypassing standard interfaces is institutionalized, with metrics associated with the number of times that "fixes" or modifications are applied to data using direct access (e.g., updates via SQL) instead of going through the preferred channels.

Alternatively, desktop applications are employed to supplement existing applications and as a way to gather the right amount of information to complete a business process. Bypassing standard operating procedures and desktop supplements pose an interesting challenge to the successful MDM program, in absorbing what might be termed "finely grained distributed data" into the master framework as well as taming the behavior that essentially allows for leaks in the enterprise master data framework. In other words, the folks with their boots on the ground may need to change their habits as key data entities are captured and migrated into a master environment.

2.4 DEVELOPING A PROJECT CHARTER

As a way to focus attention on the activity, a project charter will capture the business case and value proposition for moving forward on the MDM program, as well as itemize the key individuals associated with the project, including the project sponsors, project managers, team members, and functional beneficiaries. The charter will describe the objectives of the program, the scope of the project, the acceptance and success criteria, and potential risks and mitigation strategies.

In greater detail, the project charter for MDM will contain at least sections for the following:

Business case. As described in Chapter 1 and this chapter, identify the business drivers that are used to justify the intention to create an MDM program.

Identify the key project sponsors. Of the business clients, application owners, and operations staff/managers among the potential stakeholders, it is important to identify the key project sponsors willing to subsidize the budget or provide the resources to support the program.

Description of the current state. The desire to migrate to a new environment should be triggered by issues, constraints, or problems with the current environment. To qualify what needs to be done to improve the environment, it is valuable to detail the specific issues with the current state.

Description of the desired target state. Gaps in the existing environment will be addressed through the evolution into a presumed end state. Comparing the level of maturity of the existing environment to the future state will help identify key priorities in moving the program forward.

Alternatives. To ensure that the proper approach is being selected, describe the alternatives researched as potential solutions.

Proposed solution. Describe the selected approach and why that approach was selected.

Deliverables. Detail what the project team is promising to deliver along with the expectations as directed by the project sponsors.

Budget and resource allocation. Provide high-level details about resource requirements, budgeting, and how acquired resources will be allocated and assigned.

Risks. Identify the risks associated with the project and ways to minimize or eliminate those risks.

Project plan. Provide a high-level overview of the tasks to be performed, the agreed-to dates for project milestones (or deliverables), and the key staff members to be working on those tasks.

Project oversight. Identify the principal individuals accountable for the completing the named deliverables and the processes for overseeing that completion.

2.5 PARTICIPANT COORDINATION AND KNOWING WHERE TO BEGIN

A significant challenge in coordinating participants in an MDM program is knowing where to begin. Often it is assumed that kicking off an initiative by assembling a collection of stakeholders and participants in a room is the best way to begin, but before sending out invitations, consider this: without well-defined ground rules, these meetings run the risk of turning into turf battles over whose data or definitions or application services are the "correct" ones to be mastered.

Given the diversity of stakeholders and participants and their differing requirements and expectations, how can we balance each individual's needs with the organization's drivers for master data integration? A number of techniques are available that can help in organizing the business needs in a way that can manage the initial and ongoing coordination of the participants:
 

• Establishing processes and procedures for collaboration before kickoff and developing ground rules for participation
• Employing a responsible, accountable, consulted, informed (RACI) model for oversight
• Using business process modeling
• Providing master metadata
• Establishing data governance

The preliminary tasks prepare the team members for the first task of establishing the feasibility of creating a master repository by evaluating the business's data requirements. These ideas are introduced in this section and are described in greater detail in subsequent chapters.

2.5.1 Processes and Procedures for Collaboration

There is no doubt that when assembling individuals from different business areas and different applications, there will be a difference of opinion as to the names, definitions, sources, and reasonable uses for the objects to be mastered. In fact, it is likely that there is already "corporate experience" regarding the conversations about defining common terms (e.g., "what is a customer?"). The difference between previous iterations and the one to be performed for MDM is that the objective is not to resolve all cases of the same terms and phrases into a unique definition into which all business applications must now fit their own use. On the contrary, the goal is to determine where the underlying definitions, meanings, and semantics match, as well as where they do not match, and to provide a means for qualifying the terms to ensure that the differences are respected.

This means that the rules for interaction must be changed from what might be considered a confrontational engagement (in which participants vie for definition dominance) to a collaborative engagement where the participants methodically articulate the concepts in use by their constituencies. The process should detail where there is an overlap in meaning and where there is not, properly document where the differences are, and use this as the starting point for collecting and collating master metadata. The processes and procedures for collaborating on master metadata oversee the harmonization and standardization of use where it is possible and the segregation of use where it is not possible.

2.5.2 RACI Matrix

We have listed a number of the participants and stakeholders associated with an MDM program. To ensure that each participant's needs are addressed and that their associated tasks are appropriately performed, there must be some delineation of specific roles, responsibilities, and accountabilities assigned to each person. One useful prototype is the RACI model; RACI is an acronym standing for responsible, accountable, consulted, and informed . A RACI model is a two-dimensional matrix listing the tasks to be performed along the rows and the roles listed along the columns. Each cell in the matrix is populated according to these participation types:
 

• R if the listed role is responsible for deliverables related to completing the task
• A if the listed role is accountable for delivering the task's deliverables or achieving the milestones
• C if the listed role is consulted for opinions on completing the task
• I if the listed role is informed and kept up to date on the progress of the task

There should only be one accountable role per task, meaning that each row has one and only one A. An example is shown in Table 2.1.

Developing the RACI matrix clarifies the roles and responsibilities as assigned to the individuals within particular roles. It even is used to validate that the right set of personalities has been identified for the set of processes.

2.5.3 Modeling the Business

Available tools, implementation constraints, and technology decisions are all factors in the ways that business applications are designed, implemented, and deployed. Application systems are intended to implement the business processes, but as the systems are built and put into production, there may be some confusion as to whether the application implements the business process or becomes the business process.

In other words, implementation decisions based on technology constraints may alter the way that the business process is performed within the context of the built application, and eventually the implementation is perceived as being equivalent to the business process. That being said, as an organization consolidates data into a master environment, it creates the opportunity to truly understand what the business processes are and how they use the different data objects.

Table 2.1 An Example RACI Matrix for Some MDM Tasks

Another way of looking at this is shown in Figure 2.1 , in that the business policies are translated into workflow processes to get the job done. These workflows drive the requirements for building systems to achieve the goals directed by the business policies. Ultimately, these workflows revolve around interactions with the real-world entities that facilitate business operations, such as customers, vendors, products, locations, and payment methods, and these are the same entities that emerge as our master data objects. This suggests that the exercise of modeling the business processes in isolation from the way they are currently implemented will reveal knowledge (and perhaps new opportunities) about coordination across the application horizon.

2.5.4 Consensus Driven through Metadata

The next means for coordination is through common semantics. The variation in use and definitions of commonly used business terms is an artifact of the distribution of work according to each line of business. In an organization committed to master data consolidation, however, there is a finer requirement for coordinating data definitions. The reason is that it is critical to ensure that data sets subjected to consolidation actually refer to the same thing. If not, the resulting master data set will be inconsistent, which violates our expectations for a collection of uniquely identifiable master data objects.

Therefore, another objective for MDM is the need for driving consensus regarding what the master data objects are and how they are defined and used. Providing a common set of processes for reaching consensus and providing a metadata catalog for publicizing the agreed-to definitions establishes the management platform for coordinating the convergence of semantics for shared data objects and data elements.

2.5.5 Data Governance

Data quality and data standards management are part of a larger picture with respect to oversight of master information. In the siloed environment, the responsibilities—and ultimately the accountabilities—for ensuring that the data meet the quality expectations of the client's applications lie within the management of the corresponding line of business. But for MDM, the process for master consolidation must incorporate all the data quality expectations and rules, and the resulting data quality activities must ensure that all client applications' needs are being met.

Because the resulting master data set is no longer "owned" by any one line of business, an enterprise vision for information ownership should be in place to clarify accountability for all organization data sets, and an enterprise governance program should be instantiated to ensure compliance with ownership and stewardship policies. A data governance program will encompass data quality, standards, accountability, and audit and control for reporting on policy compliance. The objective of data governance is to establish that the master data asset is a core enterprise asset for which all staff members must take accountability. Engage senior management stakeholders in creating a functional oversight hierarchy for data governance, custody, and stewardship to make sure that all stakeholder information requirements are being met and that there are procedures for remediating organizational data conflicts. The criticality of data governance is discussed in Chapter 1 , and its value for a successful MDM program is so great that data governance is covered in much greater detail in Chapter 4.

Setting up data requirements

2.6 ESTABLISHING FEASIBILITY THROUGH DATA REQUIREMENTS

Once the stakeholders and participants are aligned, the next step is to evaluate the feasibility of evolving toward a master data environment. The essential question focuses on two aspects: first, whether the business application client requirements support the use of a master repository and, second, whether the available data sources will effectively support the consolidation of the right master data objects. Therefore, the feasibility evaluation for the master data environment focuses on collecting requirements for and evaluating and defining the appropriate level of detail for data and process models in preparation for implementing master data services.

The expectation is that at the end of the process, if there is enough support for the process, there will be a proposed data model for data extraction and consolidation as well as proposed data model for persistent storage and management of master data objects and an appropriate level of detailed process design for automating the collection, management, reporting, and accessibility of master data (for more detail, see Chapter 8 ). To support the design process, it is important to ensure that the data requirements and characteristics for the master data objects are identified, assessed, and tested. This is accomplished by following a data requirements analysis process whose goal is to ensure the identification, suitability, and model quality of the data to meet the business requirements and provide a framework for the application components for the master data model. The process outlined in this section focuses on capturing the business requirements, business processes, and terminology used in practice along with identifying and defining the data sets and data elements that will be integrated within the master repository and ultimately defining the model for these data sets and their attribute elements.

2.6.1 Identifying the Business Context

This task consists of identifying the sources of information that the data analyst will use to understand and document the specific business area processes and assist in developing meaningful and relevant user interview questions. This step requires the identification of source knowledge in coordination with data analysts and the executive sponsors and stakeholders, driven by the MDM program manager. Typical documents include the business case, program charter, system scoping documents, and the business needs assessments. In turn, these artifacts should be evaluated to assess the level of integration across and relationships to existing systems.

The output of this process is to characterize and document the environmental context and essentially document enterprise impacts and constraints related to the collection and subsequent dissemination of master data. The sequence of tasks for this process includes the following:

1 . Identify relevant stakeholders. This may involve the determination of key parties through review of documentation or directly targeted by the project manager and in discussion with other business analysts.

2 . Acquire documentation. Capture all documents related to the scope and the goals of the MDM program, which will probably incorporate a business case, program charter, as well as other relevant artifacts such as organizational or industry standards, design constraints, current system architectures, business process flows, and so on.

3 . Document the program objectives and goals. There are different drivers for establishing master data copies, and it is important to work with the stakeholders from the outset to establish what the objectives and goals are for the program.

4 . Summarize scope of system functional capability. Develop this summary in concordance with the stakeholders and application/process owners and identify the high-level functions and capabilities of the target system as well as how the system supports each stakeholder.

5 . Summarize the relevant system impacts. Do this at an appropriate level of detail to ensure compliance during final data requirements definition and logical modeling.

At the end of this process, it is reasonable to expect three aspects of the environment to be documented: a diagram documenting the environment and context, a summary of potential system impacts, and a summary of constraints that would limit master integration. A context diagram, which is developed as a result of reviewing relevant MDM program and system information, illustrates the general business process flow showing how the business applications will use the capabilities of the target system. The system impacts summary documents the way that transitioning to a master repository impacts the business environment and the associated applications, such as timeliness, quality, currency, transaction semantics, retention issues, and the types of service components necessary to support the information expectations. The systems constraints summary documents any identified constraints of the system, such as system data dependencies, interapplication processing dependencies, use of global reference data, and standards and definitions critical to business operations.

2.6.2 Conduct Stakeholder Interviews

Understanding the stakeholder requirements is a critical step involving collecting the line-of-business data requirements and collating and then synthesizing those requirements into an enterprise view. This process involves preparing and executing stakeholder interviews, including developing the questions, scheduling the interviews, and conducting the interviews. These sessions should be scheduled and conducted with key stakeholders including the executive sponsor(s), primary information consumers, and representatives from impacted business units. Although specific roles and responsibilities may vary by project, it is critical that the data analyst collaborate and participate with the business analyst in conducting stakeholder interviews.

Part of this task is to provide a set of questions tailored to drawing out the specific information needs of the business clients. This task relies on the constraints and impacts summaries produced during the previous stage, and it incorporates the following activities:

1 . Review the general roles and responsibilities of the interview candidate to guide and focus the interview questions within the context of the system.

2 . Develop focused interview questions designed to understand and document the roles, responsibilities, and needs of the information consumer in the context of the master data management system.

3 . Schedule interviews with the stakeholders, starting with the executives and business clients and rounding out the interactions with the application users, developers, and managers. Information gathered as a result of interacting with the executives will provide insight for revising the business questions used in subsequent conversations.

4 . Interview preparation includes reviewing the business questions ahead of each interview and ensuring that supporting material is properly prepared ahead of time. Arrange to capture tabled topics that inspire further discussion into a virtual parking lot.

5 . Conduct the interviews. Provide a brief review of the system goals and objectives, and describe the data requirements gathering process. Ask the business questions that have been developed, and have a scribe capture the answers. Conclude by thanking the interviewees for their time and telling them when to expect the interview summary for review and validation.

6 . Review and organize the notes from the interview including the attendee list, general notes, and answers to specific questions. Also include the business definitions that were clarified related to time, workflow, status, and so forth.

7 . Identify information gaps for follow-up; summarizing the interviews will identify additional questions and highlight areas in need of greater clarity. Contact the interviewees directly for answers to additional questions.

8 . Integrate, summarize, and organize the requirements in preparation for assessing and synthesizing data requirements.

2.6.3 Synthesize Requirements

This task involves reviewing, summarizing, and organizing the information obtained from the stakeholder interviews and merging that information with the business context resulting from the first task. The objective of this task is to look at the intersection between those data objects most frequently identified during the interview sessions and the data objects that are referenced in the business process tasks. The result of this task is the identification of the emergent prototypical data objects that can be tagged as candidates for mastering.

SYNTHESIS REQUIREMENTS STEPS

1 . Create the reference workflow model that depicts how the business processes capture, manage, and use data objects. Use this model to identify the points within the workflow that touch critical data objects and their attributes.

2 . Create a list of candidate master data objects, those data objects that emerge as the most relevant across the workflow models..

3 . For each candidate master data object, document the data elements that carry the data values used for differentiating any one real-world instance from all others, also referred to as the "identifying information.".

4 . For each candidate master data object, document the data elements that are critical for achieving the results of the business processes transcribed in the workflow models..

5 . Validate the candidate master data objects and their critical data elements with stakeholders. Present the list and walk through the workflow models with the stakeholders. Validate data requirements with the participants..

6 . Identify and standardize common business terms, because early identification of the commonly used terms will ease later metadata differences. Document the source of the use of the business term. This could include design documents, policy documents, requirements-gathering sessions, application code, and user guides. Determine if the source has provided a definition for the term, and if so, capture the definition as well as any possible authoritative source for the definition..

7 . Identify candidate source systems. Customer interviews will normally yield a list of candidate source systems for the relevant data objects, and this list will become the starting point for metadata analysis, data element metadata harmonization, and consensus on master data object definitions and semantics..

8 . Document a glossary to capture all of the business terms associated with the business workflows, and classify the hierarchical composition of data object names and structures as used within the workflows.

2.6.4 Establishing Feasibility and Next Steps

At the end of these preliminary tasks, the team should be prepared to answer the question of feasibility. The data requirements process should identify whether there are common business data objects that are used in similar ways across the application infrastructure and whether there are candidate data sets that can be used to effectively populate a master view. These facts, coupled with the business value justifications, establish the feasibility of the master data management program. The next chapters focus on the steps to be taken in assembling a project road map to bring the MDM environment into the necessary level of maturity for the organization.

2.7 SUMMARY

Setting the stage for assembling the right team for an MDM program involves determining the best opportunities to socialize the internal value across the enterprise landscape. As this chapter has shown, this socialization is performed along a number of avenues:
 

• Communicating the value of presenting a centralized master data asset to the business clients, application owners, and operations staff
• Identifying the key stakeholders that will participate in the MDM program
• Carefully articulating within a project charter what will be achieved by the MDM program and how the corresponding milestones will be reached
• Providing a means for coordinating the participants to reduce conflict and encourage consensus
• Carefully detailing roles and responsibilities
• Analyzing the data requirements to establish MDM feasibility

Download Chapter 2: Coordination: Stakeholders, Requirements, and Planning.

Read other excerpts and download more sample chapters from our Data Management Library.