Master data management (MDM) projects require enterprise buy-in and participation in order to be successful. In this chapter, learn how to identify the people in the organization that can benefit from MDM and how to assemble an MDM project team. Discover how to establish and communicate the MDM business case, learn tips for collecting and prioritizing data requirements, developing a plan for enterprise data integration and designing a migration plan for the participating applications. Learn how to tackle these key steps and how to develop a successful MDM project plan in this chapter.
[IMAGE]
2.1 INTRODUCTION
Master data present a view into the core shared information asset within the
enterprise, and as such, managing the master data asset should be considered a
critical component of an enterprise information management strategy. Any
initiative that spans the enterprise is bound to require significant amounts of
energy for coordination: identifying the key stakeholders, gaining their support,
harnessing participant collaboration, gathering requirements, and establishing
the roles and responsibilities of the right set of people to make the project
successful. In other words, as an enterprise initiative, master data management
(MDM) requires enterprise buy-in and participation. To deploy an enterprise
initiative, one must understand who the key stakeholders are within the
organization; identify the individuals who will participate in the marketing,
education, championing, design, implementation, and ongoing support of the
program; and delineate a process for identifying their needs and requirements
for the purpose of engineering a high-quality master data asset.
As a prelude to actually building and configuring the master data management
environment, team members should therefore perform a number of tasks
specifically intended to do the following:
-
Identify the people in the organization that can benefit from MDM.
-
Establish the business value of MDM and develop a business justification.
-
Collect and prioritize the data requirements that will drive the design and
development of the underlying MDM infrastructure.
-
If building an application framework from scratch, design and engineer an MDM
environment that supports the application infrastructure.
-
Design a plan for enterprise data integration.
-
Design a migration plan for the participating applications.
To do this, we must work with the many stakeholders and align their expectations
so that as the master environment grows it is able to deliver value along the
project life cycle. Therefore, in this chapter we look at the individual roles
within the organization that are associated with master data management and
examine what the responsibilities and accountabilities are for each of these
roles. In addition, we examine ways to evaluate the data requirements in
anticipation of designing the master repository.
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.
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
[IMAGE]
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.
![[IMAGE]](http://media.techtarget.com/digitalguide/images/Misc/lh_table_2_1.gif){kind=link}