Sap BW Project Plan Methodology

Excerpt from
Project
Methodology
for SAP BW
Data Warehousing and Reporting
BW Project Plan Methodology
The text throughout the document in red indicates SAP content. 2002 SAP AG. All rights reserved. SAP, the SAP
logo, R/3, Accelerated SAP and ASAP are trademarks of SAP AG.
Table of Contents
INTRODUCTION.........................................................................................................................................................4
PROJECT PREPARATION........................................................................................................................................7
A
B
C
D
E
F
Project Start-Up............................................................................................................................................10
Data Warehousing Project Abstract.............................................................................................................24
Change Integration.......................................................................................................................................47
Prototyping...................................................................................................................................................53
Technology Planning, Support and Cutover.................................................................................................65
Project Preparation Checkpoint.................................................................................................................101
BUSINESS BLUEPRINT.........................................................................................................................................110
G
H
I
J
K
L
M
N
O
P
Analysis and Decision Process Definition..................................................................................................113

Analytical Processing Data Definition.......................................................................................................133
Business Blueprint Definition Checkpoint..................................................................................................155
Data Transformation System Design..........................................................................................................160
Presentation System Design.......................................................................................................................180
Data Design................................................................................................................................................190
User Documentation...................................................................................................................................218
Training......................................................................................................................................................231
Acceptance Testing.....................................................................................................................................242
Business Blueprint Checkpoint...................................................................................................................250
REALIZATION STAGE..........................................................................................................................................260
Q
R
S
T
U
Custom Extract System Construction.........................................................................................................264

BW Administrators Workbench Construction............................................................................................291
BW Business Explorer Construction..........................................................................................................314
System and Integration Testing...................................................................................................................322
Realization Checkpoint...............................................................................................................................346
FINAL PREPARATION STAGE............................................................................................................................358

V
System Implementation...............................................................................................................................360
GO LIVE AND SUPPORT.......................................................................................................................................368

W
X
Production Support.....................................................................................................................................369
Post-Implementation Review......................................................................................................................375
Introduction
Ready access to information about an organization's business, products and customers is a key element
in supporting decision making. When searching for information to support business decisions in today's
dynamic global business environment, many business users find that the traditional sources of data transaction-based systems - are inadequate in content, accessibility, form, performance and availability.
The problem often lies not with the data or its source, but in the limitations of current technology to bring
together information from many disparate systems. Increasingly, the solution to these problems is data
warehousing.
A data warehouse (DW) can be defined as an orderly and accessible repository of known facts and
related data that is used as a basis for making better management decisions. The DW provides a unified
repository of consistent data for decision making that is subject-oriented, integrated, time-variant and nonvolatile. The data can also be characterized as accessible, transformed and management-oriented.
Data warehousing provides a multidimensional view of an organization's operational data that is designed
to be accessible and valuable to decision-makers. Those users that benefit most from better data access
and analysis capabilities are likely to be executives, analysts, knowledge workers and front-line staff.
Data warehousing is a concept that also implies the existence of an underlying discipline, structure and
organization, which ensures that business users will be able to find the correct information when they
need it. Technologies that support this concept allow organizations to extract and store information in a
specialized database that can be accessed by flexible, intuitive tools.
Today, data warehousing is considered the most effective way to transform "data" into "information". This
information is increasing in importance, as organizations need to adapt continually to changes resulting
from competitive pressures, shrinking business cycles, a global market and a transforming business
environment.
The value of data warehousing lies in its ability to help users make more informed, faster decisions. Users
can make quicker and more accurate decisions through the analysis of the key trends and events that
affect business. As a result, users spend less time finding and accumulating data and more time
analyzing relevant information and working to implement solutions.
DWs are often built starting with a few of the most valuable data areas and required infrastructure.
Additional and more complex data, infrastructure and tools are often added over time as users learn more
about their requirements and then identify additional data needs.
As an organization's data increases in both volume and complexity, the DW will become an even more
critical repository of timely and accurate data for decision making. DWs can also address the data
overload problem experienced by many executives.
Analytical Processing Versus Transaction Processing
Information systems traditionally have been developed around functional requirements associated with
the day-to-day running of the business. Separate operational systems accept orders, schedule
installations and service, generate bills, do the accounting and process the payroll.
Operational systems generally capture and generate only the information necessary to process
transactions and manage the clerical aspects of their respective functional areas. Sometimes
management reporting components of these systems may summarize the results of transaction
processing for analytical purposes. However, the management reporting components of most operational
Page 4
systems are secondary afterthoughts to the transaction processing functions and often relate only to the
narrow functional area within the scope of a particular system. For all the investments that organizations
have made in their information systems, the world remains a "data rich but information poor" place.
The concept of a DW has been developed to focus on analytical processing. It integrates data from
various internal transaction processing systems and external data sources to meet The firm's various
analytical processing information needs. In addition, a DW can also help to improve the performance of
transaction processing systems by removing some of the operational reporting requirements of these
systems.
Objectives of the Data Warehousing Methodology
The BW Project Plan Methodology presents a structured approach to planning and developing a data
warehousing system using SAPs Business Information Warehouse product. The objectives of the BW
Methodology include:
To develop a business-driven knowledge management solution in meeting The firms analytical
processing information needs considering the characteristics and needs of the:
business environment,
organizational environment, and
technology environment;
To determine analytical processing information requirements based on an analysis of The firm's
performance measurement and decision analysis processes including the uses of quantitative
analysis methods (e.g., in data mining);
Page 5
Business Information Warehouse Development Life Cycle

CPDEP Phase
1
CPDEP Phase
2
Project Preparation
CPDEP Phase
3
Business Blueprint
CPDEP Phase
5
Final Preparation
Support
Go Live &
Q Custom Extract
System Construction
R BW Administrators
Workbench
Construction
K
Presentation
System
Design
H Analytical
Processing
Data
Definition
B
DW
Project
Abstract
Realization
J Data
Transformation
System
Design
G Analysis
and
Decision
Process
Definitions
A
Project
Start-up
CPDEP Phase
4
V
System
Implementati
on
S
BW Business Explorer
Construction
L
Data
Design
T System and Integration

Testing
M
User Documentation
N
Training
O
Acceptance Testing
C Change Integration
D Prototyping
E Technology Planning, Support and

Cutover
F Project Prep
Checkpoint
I Definition
Checkpoint
P
Design
Checkpoint
Project Management
Cross-Life Cycle Phases
Formal Approval Points
U
Realization
Checkpoint
Page 6
W
Production
Support
X
PostImplementation
Review
Project Preparation
The purpose of this stage is to provide planning and preparation for the BW project. It is
concerned with understanding the business requirements or aspects of the planned DW system "what" the business does and "what it needs to do" to either resolve current business problems or
improve the way it does business at The firm. There is also a focus on understanding the project
environment and defining the requirements or scope for the planned data warehousing system.
Although each project will have its own unique objectives, scope and priorities, the steps in
Project Preparation will help confirm and plan the principal topics that will need to be considered.
Key Deliverables:
1) Project Charter A clear definition of issues relating to The firm and implementation of the
BW system. This includes objectives, scope, implementation strategy, deadlines and
responsibilities. The project manager, as part of the Project Preparation stage, draws up the
Project Charter. The contents of the Project Charter include:
a) Project Scope To ensure that there is a precise understanding of the expectations and
objectives for the project.
b) Key Assumptions
c) Critical Success Factors Those key areas that have specific impact on the
implementation process. Typical factors include: executive sponsoring, change
management and control, resources (appropriate, enough and committed), issue
resolution, user involvement, clear objectives and scope
d) Project Team Organization Roles and responsibilities
e) Team Processes Status meetings, deliverable review, issue resolution
2) Project Abstract
a) Data Abstract High-level overview of the key data and system relationships.
b) Process Abstract (High-level Data Flow Diagrams) High-level understanding of the
data, process and technology of the proposed system. Provides a high-level summary of
the purpose, function and overall structure of the potential business analytical processes
to be investigated. It defines in general terms, the functions of the proposed DW system
and provides an initial boundary for the scope of the project.
c) Source System Abstract Provides an overview of the source systems relevant to the
scope of the project. The source systems include not just internal systems but also any
relevant external supplier systems, customer systems, syndicated data systems or
business partner systems.
d) Technology Abstract - Documents the current technology environment as well as the
proposed technology environment for the new system. The proposed environment will
often be based on the current BW environment supplemented with the planned
implementation of any new technologies or tools.
i) Include analysis of growth requirements and number and types of users.
ii) Where non-R/3 sources are used or where non-standard technology is employed
(e.g. 3rd party ETL tool or front-end tool other than Cognos), the technology
environment analysis needs to be present.
e) Data Conversion Abstract High-level understanding of the scope and complexity of the
different tasks necessary to create the initial data for the project.
3) ID the Guidance Review Team
4) ID the key Stakeholders
5) High-level Project Plan To identify the phases, tasks and steps to be used to successfully
complete the project.
6) Develop a Class 1 Estimate
Page 7
Project Start-up
During Project Start-up, a clear agreement on the scope of the project between management and
the project team is obtained. All standards, techniques and tools to be used should be defined
and the organizational structure of the project as well as the project reporting mechanisms should
be confirmed and agreed. A project risk assessment is completed. A Project Charter for the
project is also established and agreed between the business users and the project team.
Data Warehousing Project Abstract
The DW Project Abstract provides a high-level summary of the purpose, function and overall
structure of the DW system to be developed. It is built on an understanding of The firm's critical
success factors (CSFs) and related performance measures and uses the CSFs to validate the
business processes and business events to be included in the project. The DW Project Abstract
consists of the following major components:
Data Abstract which provides a high-level overview of the key data entities to be included
within the scope of the DW system;
Process Abstract which identifies the potential key analytical or decision processes within
the scope of the project and may also include definition of some of the key outputs from
the proposed DW system;
Source System Abstract which provides an overview of the source systems providing
inputs to the DW system;
Technology Abstract which provides an overview of the relevant current and target
technology environments for the planned DW system; and
Data Conversion Abstract which provides an overview of the scope and complexity of the
data conversion effort for the project.
In certain cases, a technology or "proof-of-concept" pilot will be required and, where this is
appropriate, it may be completed as part of the Technology Abstract definition. Additional
deliverables:
Alternative development options are identified and evaluated.
Identification of stakeholders and GRT
A Class 1 Estimate and high-level project plan is completed as part of the evaluation in
deriving a recommended development approach.
An initial assessment of the project risk is also completed.
During the Project Preparation Stage, several Cross-Life Cycle Phases may be started. These
include: Change Integration, Prototyping, and Technology Planning, Support and Cutover. These
phases are briefly described in the paragraphs below.
Change Integration
Change Integration is a Cross-Life Cycle Phase that spans all stages of the DW life cycle. Its
main purpose is to ensure that all relevant business and organization issues relating to the
development and roll-out of the DW system are properly addressed. Opportunities for
performance improvement may also be identified in the course of analyzing and developing the
DW. As appropriate, separate change integration projects may be initiated or the scope of the DW
project may be expanded to address these change issues.
Prototyping
The Prototyping Phase stretches across the DW life cycle. Depending on the development
strategy identified and adopted in the Project Start-up Phase, prototyping may be:
Performed exclusively in one phase; or
Repeated across the life cycle, potentially many times.
Prototyping may be used in various ways on a DW project such as:
Defining user requirements for the presentation systems (i.e., requirements prototypes);
Page 8
Proving the viability of a particular technology or suite of technologies (i.e., proof-ofconcept prototypes); or
Incrementally developing the DW system (i.e., evolutionary prototypes).
Technology Planning, Support and Cutover

The Technology Planning, Support and Cutover Phase identifies support roles and responsibilities
for the new system and planning for the procurement, installation and transitioning between the
legacy, development and production environments.
Project Management
In addition to the Cross-Life Cycle Phases, project management and quality management
activities are also ongoing for the duration of the project.
A Project Charter is developed in the Project Start-up Phase and progress is continually
monitored against the plan. At the completion of each of the stages in the life cycle, a formal
review of the work completed is performed to validate that there have been no major deviations
from the original plan. The Project Preparation Checkpoint Phase includes the specific tasks to
validate the Project Preparation Stage models and to ensure that adequate planning for the next
stage(s) has been completed.
The Checkpoint Phases also mark the points at which quality reviews should be completed as
well as re-visiting the project risk assessment.
Page 9
A.1
Project Start-Up
Purpose
To plan for the effective and efficient conduct of the project.
Overview
All of the different tasks necessary to formally begin the project are completed in this phase. The
tasks and steps are intended to reduce the risk of unplanned scope adjustments, significantly
revised work products, misunderstandings and cost overruns. All projects, no matter how small or
unique, can benefit from an appropriate degree of preliminary planning.
The scope definition as defined in the proposal and any other contractual documents are formally
agreed.
The project management structure and standards are created together with detailed work plans
for all of the different resources.
The project team staffing skills and resources and organization structure are defined and
orientation sessions completed.
The Project Charter is prepared and agreed. The standard contents of the Project Charter
include:
Project background
Scope of the project
Project risk assessment and management approach
Project organization and staffing
Roles, responsibilities, skills required, staffing and training
Deliverables and third-part commitments
Change and issues resolution procedures
Estimates for the project
Project work plan
Detailed work plans
This list of contents includes all aspects of project management that need to be addressed by
management. Some sections of the document, such as the project work plans may be placed in
separate documents for ease of maintenance and to keep the size of the Project Charter
manageable. Any such stand alone documents are referenced within the main body of the Project
Charter to ensure that the Project Charter remains a single reference point for the management
of the project.
The Project Charter is a living document that will be continually updated throughout the life cycle
of the project. Amendments will be made during each stage as changes are identified and the
results of quality reviews are included. At the end of each stage, a major revision of the Project
Charter is required and this is the main focus of the Checkpoint Phases.
Revisions to the plan fall into three broad categories:
Minor changes to static information;
Major revisions to existing sections; and
The addition of new information not previously recorded.
As the project progresses, there will be a continual need to monitor and report on project status,
to identify and address scope issues and to conduct appropriate Quality Management Reviews.
Page 10
The structure established in the Project Start-up Phase is maintained during the Checkpoint
Phases and the deliverables initiated in this phase are refined as the project moves towards
completion.
Project Start-Up Task Relationships
P r o je c t O p p o r tu n it y
R o le s a n d R e s p o n s ib ilit ie s
A1
C o n f ir m a n d A g r e e
P r o je c t O b je c t iv e
P r o je c t M is s io n S t a te m e n t
B u s in e s s D r iv e r s
H ig h - le v e l P r o je c t S c o p e
A2
D e f in e P r o j M g m t
O r g a n iz a tio n S tr u c tu r e
a n d S ta n d a rd s
P r o je c t M a n a g e m e n t S t r u c t u r e
Is s u e r e s o lu tio n a n d s c o p e c o n t r o l p r o c e d u r e s
P r o je c t s t a t u s r e p o r t in g p r o c e d u r e s
A3
D e v e lo p D e ta ile d W o r k
P la n s a n d S c h e d u le s
P r o je c t r is k a s s e s s m e n t
P r o je c t w o r k p la n
A4
F in a liz e P r o je c t T e a m
O r g a n iz a tio n ,S t a ff in g
a n d L o g is tic s
P r o je c t t e a m o r g a n iz a t io n
A5
D e v e lo p P r o je c t
C h a rte r
Page 11
P r o je c t C h a r te r
A.1.1 Confirm and Agree Project Objective

Purpose
To ensure that there is a precise understanding of expectations and objectives from the project
and to agree any changes in scope or deliverables which should be incorporated in the time and
cost estimates supporting the project.
Overview
Effectively managing a project requires a clear, precise understanding of expectations and
objectives. Establishing this understanding early in the project allows the developers to focus their
efforts on delivering the appropriate services and helps to avoid misunderstandings, false starts
and rework of project deliverables.
A.1.2 Define Project Mission Statement

Definition
A mission statement defines the overall purpose of the project. The mission statement should be
clear and concise, inspiring and motivating the team.
Use
Mission statements can:
Focus attention on purpose - what the project team exists to do.
Convey top management's vision about the purpose of the BW project.
Provide a foundation upon which strategic plans can be built.
A.1.3 Determine the business drivers for the DW project

Determine the underlying business reasons (i.e., business drivers) for developing the DW such
as:
Proactive action to gain competitive advantage;
Reactive response to competitive pressure;
Customer service focus;
The move to an e-business model;
Supplier performance focus;
Profitability focus;
Taxation management/reduction focus;
Cost reduction focus; or
Integral part of an organizational transformation program.
This step may be accomplished in a workshop or in one-on-one interviews with senior
management.
The business drivers are identified at a high level in this step to provide a framework for
determining the appropriate nature and scope of the DW project. For instance, a DW project may
be:
An attempt by The firm to improve its operational or business performance;
An integral part of an organizational change program (such as Business Process
Transformation or Total Quality Management);
An organizational initiative to gain and sustain competitive advantage through improved
management and control of The firm's data resource (e.g., making data more accessible
to management or business analysts); or
Page 12
An organizational effort to integrate and share disparate data (e.g., as the result of a
business merger).
In determining the project drivers, it is also useful to determine whether the DW project is:
An organization-wide effort or focused on selected business segments; and
Driven top-down by senior management or proposed by lower level functional or
operational managers.
Understanding the business drivers helps in defining and focusing the objectives and scope of the
DW project.
Page 13
A.1.4 Define Project Management Organization Structure and Standards

Purpose
To agree the management structure to be used in controlling the project as well as any standards
or procedures needed to support the management process.
Overview
It is important to establish the overall framework used for directing and controlling the project and
to identify the key user and development staff required to fill the various management roles.
Management roles will vary by project and as such need to be clearly defined at the outset of the
project.
In addition to defining the management structure of the project, this task addresses the creation
of project management standards and working procedures needed to support the agreed
structure.
A.1.5 Agree project management structure.

Identify key individuals to fill roles within the project management structure including:
System/application owners;
Ongoing, day-to-day maintainer(s) of the system;
Guidance Review Team (GRT) members;
Project coordinator (e.g., project producer and director roles); and
Identify and assign any key user contacts for the project.
If the project is to be directed or guided by a Guidance Review Team, assist management in
establishing the committee.
Ensure that the GRT has representation from all of the business functions involved in using,
operating and setting policy for the proposed DW system. Consider the following types of
personnel for membership of the GRT:
Senior management - depends upon whether management wishes to delegate steering
committee roles or function in a "hands-on" mode;
Information systems personnel - representing database administration, data
administration, operations management and applications development;
Key end-users - representing major functional areas, individuals with key understanding
of the business; and
Technology personnel - with detailed understanding of the new technology and its impact
on The firm.
Business sponsors
Help define the role of the Guidance Review Team:
Determine whether the GRT has approval authority or will operate in a guidance mode
with approval authority vested in the managers, especially for:
project schedule,
project standards,
project personnel assignments, and
project deliverables;
Establish the checkpoints at which the GRT should review deliverables;
Establish the mechanisms by which the steering committee communicates to senior
management and to the project members; and
Page 14
If the steering committee is functioning in an approval mode, define the procedures by

which it provides approval.
Alternatively, if the project is to be managed through a senior management organization position,

this reporting line and accountability is established and agreed.
Identify and agree the key user contacts in the organization, the role they are expected to play
and the amount of time their expected involvement in the project will require.
Initiate and maintain communications with the Functional Analysts and the Production Support
Lead. This contact is critical in order to ensure a smooth cutover, and they should be included on
any project-wide communication or e-mail group lists.
Define the roles which any third-parties will play (e.g., suppliers or contractors) and the
appropriate responsibilities for their liaison and their management.
A.1.6 Confirm approach to be used for scope management and project

issue resolution.
Define the scope control methods for the project. Identify all of the appropriate techniques and
forms to be used including:
Issue Resolution;
Issue Resolution Log;
CAB Process;
RFC (Requests For Change);
System Change Request;
System Change Request Log;
Test Problem Report;
Test Problem Report Log; and
Walk-through Worksheet.
Define the different types and levels of severity for Test Problem Reports and how each level will
be addressed and managed.
Define procedures for managing System Change Requests and Issue Resolutions.
A.1.7 Define frequency, dates and formats for progress reporting.

Define expected reporting periods and report contents for the project team. Agree any variations
with management. Include:
Internal reporting to the project manager and within the project team;
Reporting to senior management;
Reporting to the Guidance Review Team; and
Formal approval points.
Page 15
A.1.8 Develop Detailed Work Plans and Schedules

Purpose
To identify the phases, tasks and steps to be used to successfully complete the project and the
degree of risk associated with the project.
Overview
This task is concerned with defining the detailed activities to be completed to provide a framework
for confirming project scope, to assist in estimating the project duration and to determine the
resources needed. A risk assessment is completed if one has not been completed earlier.
For most projects, a detailed work plan will be developed for the Project Preparation Stage and a
high-level schedule will be developed for the remainder of the project. Additional schedules may
need to be developed to identify other items such as deliverable dates, milestones, project review
meetings and quality review meetings.
A critical path schedule should be developed to highlight tasks upon which other tasks are
dependent and, if delayed, will have a ripple effect on the overall project duration or scope.
A.1.9 Evaluate risks associated with project size.

Identify the components of size that are appropriate for the project. Potential components to
assess may include:
Total budgeted hours;
Total anticipated elapsed time;
Number of sub-projects;
Time-oriented business constraints;
Length of the payback period;
Project team size;
Number of user departments affected; and
Number of geographic locations involved.
Also assess whether the organization is used to managing projects of a similar size or whether
the project represents a significant increase in size, which may then increase the project risk.
A.1.10Evaluate risks associated with experience with the technology.

Consider the risks that may arise due to unfamiliarity with new technology.
The definition of what constitutes a high risk will vary with the technical sophistication of the
organization; however, the categories of risk remain reasonably constant. Generally, the more
new items that will form part of the development, test and production IT environments, the higher
the risk.
The database technology knowledge of The firm's IT and non-IT staff (e.g., concepts of data
administration, data modeling, data replication and data warehousing) may hinder the
development work, acceptance and success of the DW project deliverables.
If the project is being managed by a team external to the The firm Financial Center System
Support group (THE SERVICE ARM OF THE FIRM), then consider the following integration
points:
BW Environment Management
BW OSS, Support Packages, Notes Application
Page 16
Common Design
BW Security
Frontend Tools Selection
and Strategy
Long term strategy for BW use
Transition to BW On-going Support
CAB Process During Development
DBA Support
Consulting - Short-term / Long Term - Testing Strategies
Performance Testing
Integration Testing
Training Development / Documentation Standards
BW Project Unique Training
Consistency of Deliverables
Ownership of Common Data - CC/WBS Hierarchies
BW Design Architecture
A.1.11Evaluate risks associated with the project structure.

Risk increases on projects where the system requirements cannot easily be defined or validated
at the commencement of the project. This type of risk relates to the structure of the project and
can be assessed by considering:
Degree of organizational change involved;
Impact on existing methods or procedures;
Reliance of the DW system on other feeder or support systems;
Senior management commitment; and
The general attitude of the users.
A.1.12Summarize the risk assessment.

Compare the figures for each component to the average size of projects undertaken by The firm
and/or by the system developers.
Identify the potential risk areas and review the data in these areas to see if there are any ways to
reduce the risk without adversely impacting the overall system requirements. Alternatives may
include:
Extending the project time frame;
Reducing the project scope;
Increasing the project resources and/or budget; or
Providing more resources from the organization.
Discuss any alternative suggestions with management and agree on the approach to adopt.
A.1.13Determine what methodology tailoring is required.

Determine which of the detailed work tasks and steps will be required for the project.
A.1.14Identify project planning assumptions, constraints and risks.

During the process of developing project work plans, assumptions are made, constraints are
enforced and risks are identified along the critical path. The validity of the work plan is governed
by these boundaries. Identify and document these items as support for the work plan.
Page 17
A.1.15Develop overall project work plan.

Develop an overall project work plan following the guidelines of the BW Project Baseline which
establishes a standard life cycle work plan with tasks and deliverables. Where tailoring of the
standard BW Baseline is required, discuss and agree and then incorporate the changes in the
project work plan.
Derive and present the work products in a hierarchical task structure within phases, tasks and
steps as defined in the Baseline. Define the content and completeness requirements for each
deliverable where they differ from the Baseline deliverables.
A.1.16Develop detailed project work plan(s) for the Project Preparation

Stage.
Develop detailed work plan(s) for the Project Preparation Stage. Address such issues as:
Identify work products related to each task/step;
Identify dates for review and acceptance of work products;
Identify dates for status meetings;
Highlight on a separate schedule or as part of the work plan, project critical path
activities;
Calculate level of effort by task and/or time period for all resources including contractor
staff, external supplier staff and other third-parties;
Arrange for an independent review of estimates;
Identify critical path activities; and
Balance the resources and project schedule so that the completion date is acceptable
and the required resources are within the staffing capacity. Adjust the scope of the project
to meet these requirements as necessary.
A.1.17Develop approaches for Cross-Life Cycle Phases.

Specify the approaches to be followed in conducting the Cross-Life Cycle Phases and record the
different tasks and steps to be used from the Cross-Life Cycle Phases as part of the overall
project work plan.
Approaches may include detailing if a specific phase is outside of the scope of the project or is to
be the sole responsibility of the system users, e.g., the User Documentation Phase.
Approaches should be specific for the following phases:
Technology Planning, Support and Cutover;
Change Integration;
Prototyping;
During the subsequent stages of the project, these approaches will be refined into strategies and
plans for implementation. In practice, the development of the strategies and plans should be
completed in the specific phases listed above and consolidated in the Checkpoint Phases.
A.1.18Develop supporting project schedules.

Identify the need for supporting schedules such as:
Project team staffing plan;
Sub-project work schedules;
Resource use schedule;
Third-party resource and work schedule; and
Contractor resource and work schedule.
Page 18
A.1.19Conduct quality review of the work plan.

Complete a quality review of the work plan and make any adjustments where necessary.
A.1.20Review and agree work plan with management.

Submit the plan to the Guidance Review Team and/or management and discuss the contents.
Resolve any questions and issues and, if necessary, modify the plan. This step may involve more
than one meeting.
Page 19
A.1.21Finalize Project Team Organization, Staffing and Logistics

Purpose
To identify suitable staff to undertake the project, to identify project team training requirements
and to ensure that all logistical arrangements for the project resources have been defined.
Overview
Staff with appropriate skills are identified and assigned to the project and the training
requirements for each project team member are defined.
Project team facilities are defined and obtained, e.g., obtaining office space at the project site is
generally required unless the work is to be completed off-site. Ensuring that the development
team has access to the appropriate hardware/software components needs to be managed and in
most cases some of the components may need to be acquired.
The staffing requirements for a BW project varies based on which stage the project is currently in.
The following exhibit shows a recommended approach:
Page 20
Business Information Warehouse Project Team Makeup

Project
Preparation
Business
Blueprint
Realization
Final
Preparation
Project Management
DW Architecture
Business Design Team
Business Analysts
SAP Process
Training
Technical Team
Data Specialist
SAP BASIS
SAP ABAP
Presentation System Team

Business Explorer Specialist
Web Specialist
Data Transformation Team
Administrators Workbench Specialist
ABAP (custom SAP extracts, routines)
Page 21
Go Live &
Support
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology
A.1.22Confirm project team organization and staffing commitments.

Carefully define the skills and resources required, both by discipline and number, for each
member of the project team ensuring that the skill mix is carefully matched to the project needs.
Derive the team organizational structure and staffing requirements:
Develop a project organization chart defining the lines of responsibility and the roles of all
participants;
Assign the tasks and deliverables to specific personnel and publish job assignment lists;
Confirm the need for any specialist skills;
Identify training needs for project staff;
Determine staffing to be provided by contractors and other third-parties (e.g., hardware or
software suppliers), where relevant; and
Determine availability of staff.
A.1.23Prepare individual work plans for each project team member.

Prepare individual work plans for each project team member. No work step should be greater
than 80 hours in duration for each team member.
A.1.24Arrange for facilities and resources required by the project team.

Determine which additional facilities will be required by the project team including:
Office space/supplies, furniture, storage, photocopiers and facsimile machines;
Telephones/telephone lists/electronic mail/voice mail/video conferencing;
Clerical/administration support;
Security access; and
Computer equipment including networking needs and access.
Page 22
A.1.25Develop Project Charter

Purpose
To develop, discuss and agree a Project Charter.
Overview
This task is largely one of collating the earlier task deliverables and checking them for internal
consistency, before approval of the Project Charter is obtained.
The aim is to provide a single source plan that:
Incorporates a work breakdown structure for the project;
Assigns roles and responsibilities to specific individuals;
Defines the management procedures under which the project will operate;
Defines the standards, methods and tools the project will use; and
Specifies the quality measures that will be used to assess organizational acceptance and
that will be used as the yardstick against which progress will be measured.
Quality review points are considered an integral part of the work breakdown structure defined
earlier and as such it should not be necessary to "add in" quality checkpoints. The work plans are
reviewed at this point to confirm that the quality review points identified are sufficient.
A.1.26Create Project Charter for the project.

Include in the Project Charter such items as:
Scope document;
Project management organizational structure;
Project team organizational structure;
Schedule and deliverable samples for reporting progress;
Project standards cross-reference;
Scope management definition;
Organization quality measures;
Project work plan;
Detailed work plans;
Project schedules (e.g., critical path schedule);
Work product and pro forma schedule;
Staff assignments; and
Project quality review checklist(s).
A.1.27Confirm completeness of the Project Charter.

Submit the Project Charter for assessment, implement any corrective action required and agree
the quality assessment schedule.
Obtain approval and distribute the Project Charter.
Page 23
A.2
Data Warehousing Project Abstract
Purpose
To scope the BW project based on a high-level understanding of the data, process and
technology requirements of the proposed data warehousing system.
Overview
The Data Warehousing Project Abstract provides a high-level summary of the purpose, function
and overall structure of the potential business analytical processes to be investigated. It defines in
general terms, the functions of the proposed DW system and provides an initial boundary for the
scope of the project.
The organization's current and "to-be" (as appropriate) business is analyzed to obtain a proper
context and perspective in planning and developing the DW system. The focus is to align the DW
system development effort with The firms business objectives. The project requirements are
captured in a Data Warehousing Project Abstract consisting of the following major components:
Data Abstract;
Process Abstract;
Source System Abstract;
Technology Abstract; and
Data Conversion Abstract.
The Data Abstract is a high-level overview of the key data and system relationships. It is derived
primarily from an understanding of the existing system and from interviews with users concerning
the proposed system. In these interviews, any existing or new areas for which data will need to be
recorded should be defined. The Data Abstract also describes the relationships between the
potential kernel data entities in the system in the form of an Entity Relationship Model (ERM).
The Process Abstract graphically describes the potential key processes of the system and clearly
identifies the scope of the project. The Management Overview Diagram is the technique used for
this graphical description together with some narrative describing the processes. It also shows
the expected inputs and outputs and interfaces with other existing or future systems and business
processes and should also indicate activities that are outside of the project scope.
The Source System Abstract provides an overview of the source systems relevant to the scope of
the DW project. The source systems include not just internal systems but also any relevant
external supplier systems, customer systems, syndicated data systems or business partner
systems.
The Technology Abstract documents the current technology environment as well as the proposed
technology environments for the new system. The proposed environment will often be based on
the current environment supplemented with the planned implementation of any new technologies.
The Data Conversion Abstract provides a high-level understanding of the scope and complexity of
the different tasks necessary to create the initial data for the DW project. This may include:
Purging/cleansing existing data;
Balancing/reconciling existing data;
Creating new data; and
Converting existing data.
In some cases there may be a need for a Technology Pilot to provide a "proof-of-concept" that the
proposed technology components are a viable solution to the business problems identified.
Page 24
Depending on the specific project circumstances, the objectives of a Technology Pilot may
include one or more of the following:
To assess and determine the capabilities of the various proposed hardware and software
components for the new technology components;
To demonstrate the connectivity and compatibility of the proposed hardware and software
components;
To simulate performance/capacity definition before embarking on a major project; or
To determine the organizational impact and training needs for both the IS and user
personnel in the new technology environment.
The rationale for the Technology Pilot and its impact on the project scope must be clearly
determined and documented in the project plans.
Alternative approaches to developing the DW system should be identified and evaluated to select
or confirm the most appropriate development approach to use. As needed, high-level Cost/Benefit
analyses for the alternative approaches may be completed to support the evaluation process.
The completed Data Warehousing Project Abstract is presented, discussed and formally
approved by senior management.
Page 25
Data Warehousing Project Abstract Task Relationships
P r o je c t O p p o r t u n ity
C h e v r o n I n f o r m a tio n A c c e s s S tr a t e g y
H ig h - le v e l P r o je c t S c o p e
B1
D e fin e C r itic a l
S u c c e s s F a c to rs
B3
P re p a re P ro c e s s
A b s tra c t
B4
P re p a re S o u rc e
S y s te m A b s tra c t
B2
P re p a re D a ta A b s tra c t
O v e r v ie w o f S o u r c e S y s te m s
B6
P re p a re D a ta
C o n v e r s io n A b s tr a c t
D a ta C o n v e r s io n A b s tr a c t
B7
E v a lu a te D a ta
W a r e h o u s in g
D e v e lo p m e n t O p tio n s
P r o je c t R is k A s s e s s m e n t
B5
P r e p a r e T e c h n o lo g y
A b s tra c t
In v e n to ry o f c u rre n t s y s te m s
T e c h n o lo g y A r c h ite c t u r e D ia g r a m
T e c h n o lo g y P ilo t R e q u ir e m e n t s
M a n a g e m e n t O v e r v ie w D ia g r a m
E n tit y R e la tio n s h ip M o d e l
CSFs
P e rfo rm a n c e M e a s u re s
B8
S u b m it D a ta
W a r e h o u s in g P r o je c t
A b s t r a c t D e liv e r a b le
Page 26
C o s t / B e n e f it A n a ly s is
D a t a W a r e h o u s in g D e v e lo p m e n t O p t io n s
R e c o m m e n d e d D a ta W a r e h o u s in g D e v e lo p m e n t O p t io n
U p d a te d P r o je c t R is k A s s e s s m e n t
D a t a W a r e h o u s in g P r o je c t A b s tr a c t D e liv e r a b le
A.2.1 Define Critical Success Factors

Purpose
To ensure that the objectives of the business are fully understood and documented so that they
can be used to control the scope of the Data Warehousing Project Abstract activities.
Overview
CSFs are the essential circumstances or conditions that have a major influence on whether a
particular business objective is achieved. If CSFs do not exist within the organization, they should
be developed by the organization's management.
CSFs assist in defining the:
Factors in the business that the eventual system must support;
Performance measures for the eventual system;
Events that the eventual system must support; and
Scope of the project.
The power of CSFs lies in the focus that they bring to a project by ensuring that the solution is
aimed at solving the correct business issues.
Depending on the scope of the system and the number of senior management executives to
interview, the following steps may be sequential or may be accomplished in parallel. For a small
system, all of the steps may be able to be completed in one meeting.
A.2.2 Interview senior management.

Identify a limited number of senior management who are able to provide a high-level description
of the current system and who can explain any additional processes that are expected to be
incorporated within the new system.
Gain an understanding of the organization, current business practices and how the proposed
system will fit into the operations of the business process.
Document what the users expect of the new system. This should reflect the functionality to be
provided and the performance measures attributable to the functions such as the time scales
within which the users expect the system to be implemented and to be fully operational, as well
as any indication of budget constraints for the project.
Document current system problems by producing a list of the problems and deficiencies with the
current system.
Discuss and confirm with the users those problems they anticipate will be resolved by the
introduction of the new system. The intention at this point is not to suggest solutions to all of the
problems but to ensure that a detailed picture of the problem areas is produced.
A.2.3 Identify CSFs.

Review and, if necessary, define the objectives and goals of the area of the business under
investigation. Specify how the proposed application is expected to assist in achieving these
business objectives in the form of CSFs for the application, at the business process level.
The CSFs are essential circumstances or conditions that have a major influence on whether a
particular business objective is achieved.
Page 27
CSFs should be identified at the level of tangible activities that can be associated with specific
performance measures, i.e., they must be capable of measurement.
A.2.4 Define performance measures and targets for the CSFs.

Associate with each business process CSF one or more performance measures that can be used
to identify constraints and/or targets to be achieved. The performance measures should specify
"what" needs to be measured and the targets should define the acceptable range of results for
the CSF. Additional details useful to capture include any constraints related to the implementation
of the CSF, e.g., the number of staff involved in a particular process cannot exceed 25, although
this could also be specified as a performance target such as staff size 10-25.
A.2.5 Discuss and obtain approval of the CSFs.

Review the CSFs with senior management and confirm that they are correct and that the
performance measures and targets are appropriate. Resolve any questions and issues and, if
necessary, modify the CSFs. This step may require more than one meeting.
Page 28
A.2.6 Prepare Data Abstract

Purpose
To develop a Data Abstract in the form of an Entity Relationship Model (ERM) as a high-level
framework for coordinating, modeling and managing the scope of the DW project.
Overview
This task develops a Data Abstract in the form of an ERM to define the scope of the DW project
from a data perspective. An ERM is a high-level definition of an organization's data resource from
a business perspective and captures, at a high-level, an organization's business rules in terms of:
Kernel entities (i.e., things of significant interest to the business); and
Relationships among these entities.
The primary uses of a Data Abstract or an ERM on a DW project include:
Project scope definition. An ERM may be used in conjunction with the Process Abstract
(i.e., the Management Overview Diagram), the Source System Abstract and the Data
Conversion Abstract in defining the scope of the DW project;
Management communications. Because an ERM is a high-level, business-oriented data
model, it provides an effective vehicle for communicating with management various
project issues such as project scope and business understanding;
Business foundation. An ERM provides a business focus in developing the DW as it
reflects the significant data entities and their relationships from a business perspective;
and
Data modeling approach. An ERM is the highest level data model that may be developed
on a DW project. It provides a foundation for developing other lower level data models
such as the Conceptual Data Model (CDM), the Logical Data Model (LDM) and the
Multidimensional Data Model (MDM).
A.2.7 Define kernel entities.

Define potential kernel entities through interviews or reviews of current systems documentation. A
kernel entity is a primary business object or concept that can stand alone (i.e., it is not dependent
on any other entities). Some typical examples of kernel entities include CUSTOMER, SUPPLIER
and PART.
In defining the kernel entities, consider:
Differentiating between entities which are dependent on other entities and kernel entities
which must be able to stand alone (e.g., if the entity ORDER LINE depends on the entity
ORDER, it is not a kernel entity). If the non-kernel entities are of significant interest to the
business, they may be included on the ERM;
Ensuring that each entity is clearly distinct and different from other entities;
Removing any entities which do not represent business objects or concepts. Things such
as listings, computer reports, paper forms or documents or other output-related objects
are usually not entities; e.g., a schedule may be identified as an entity when in fact it is a
listing containing attributes from a number of entities such as flight, work order or task,
each of which has schedule dates attributes; and
Removing from consideration any entities that do not clearly have many occurrences
(e.g., the accounting department, credit agency).
Assign a descriptive name to each entity. The name of each entity should be singular, unique and
logically describe the object in accordance with established data naming standards and
conventions.
Page 29
A.2.8 Establish relationships between entities.

Determine the relationships between the entities. In practice, kernel entities and their
relationships are determined simultaneously as an integral process. Thus, this step is completed
concurrently with the steps discussed above in identifying kernel entities.
A business rule sentence structure may be used in guiding the identification of entity
relationships. Considering entities as nouns, a rule sentence may consist of one entity noun as
the subject and the other as the object with the verb in the middle (e.g., a PURCHASE ORDER is
placed with a SUPPLIER, PURCHASE ORDER and SUPPLIER are the entities and is placed
with is the relationship).
While the definition of an entity relationship is a form of business rule representation, formal
business rule analysis is not completed until the development of the CDM.
Name and describe the identified relationships. A relationship name should be an action verb
depicting the role of the relationship. The sentence structure formalism may be used to describe a
relationship as follows:
Each {first entity name} {must/may} (e.g., "Each FLIGHT may");
{relationship name} (e.g., "terminates at"); and
{one/many} {second entity name} (e.g., "many AIRPORTS").
Prepare a textual description of the relationship as needed to further explain the meaning of the
relationship.
A.2.9 Model the entities and entity relationships on an ERM diagram.

Model each entity as a rectangular or oval box containing the entity name on the ERM.
Include appropriate administrative information such as title, organization, project name and date
of preparation.
Add the identified relationships to the ERM by connecting the rectangular boxes representing the
related entities.
If the entity relationships are named, use the clockwise convention to indicate the direction the
relationship on the ERM; e.g., in Exhibit B-1a, the relationship should be read as "a PERSON
drives a CAR" and in Exhibit B-1b, the relationship should be read as "a CAR is driven by a
PERSON."
In general, names should be given to relationships on the ERM in only one direction.
Page 30
A.2.10Identify the subject areas.

Based on the knowledge of the organization's business gathered on the project, identify initial
subject areas as natural divisions of an enterprise focusing on the major resources or activities of
the enterprise. Starting with the ERM:
Identify the kernel entities as the initial subject areas;
Include other entities and relationships associated with a particular kernel entity in the
corresponding subject area; and
Review and refine the subject areas.
Document and define each subject area identified. The definition of the subject areas should be
completed using business terms familiar to users and management.
A.2.11Discuss and agree the Data Abstract.

Discuss and agree the content of the Data Abstract. Resolve any questions or issues and, if
necessary, modify the contents.
Page 31
A.2.12Prepare Process Abstract

Purpose
To provide an overview of the business analytical processes to be included in the proposed DW
system and to identify those processes that are outside the scope of the study.
Overview
The Process Abstract is designed to show at a high-level the business analytical or decision
processes to be incorporated within the proposed DW system as well as any interfaces with
current or future systems.
The Process Abstract for a DW system is comprised of:
Narrative describing the system at a high-level;
A Management Overview Diagram (MOD) that shows the desired processes and
interfaces in a graphical format; and
A list of excluded processes.
A project scope definition is derived that provides both a framework for assessing the
development options and for determining the development workload.
A.2.13Prepare for user discussions.

Prepare a list of management and selected key users and schedule interviews with them to gain
an overall understanding of the proposed system. To develop this understanding quickly, the list
should be small and should focus on the departmental heads of those business units addressed
by the CSFs.
On some projects, this interview process may already have been included as part of the CSF or
earlier discussions and may not have to be repeated.
Develop a standard interview questionnaire to ensure a common approach to the interview
process. This is particularly useful when some interviews have to be conducted by telephone.
A.2.14Conduct user discussions and summarize results.

Complete the discussions with the appropriate user representatives to ascertain the essential
processes of the system. At this point, it is not necessary to define all processes but a high-level
description of those processes considered essential for inclusion in the proposed project must be
incorporated in the Process Abstract.
In some cases, it may be practical to group department heads or other individuals together in
group design sessions to obtain agreement on the processes and priorities of the proposed
system.
A.2.15Confirm discussion results.

Organize and document the information obtained at the interviews. Confirm the interview results
in meetings, discussions or documents to help ensure that they accurately reflect the processes
of the current system and those required in the new system.
This should be a very brief process because the primary feedback mechanism will be the Process
Abstract, not the interview results.
Page 32
A.2.16Discuss and agree the Process Abstract.

Assemble the results of this task into a Process Abstract document in both graphical and
narrative form. Discuss and agree the content of the Process Abstract. Resolve any questions or
issues and, if necessary, modify the contents.
Page 33
A.2.17Prepare Source System Abstract

Purpose
To identify and provide an overview of the source systems, both internal and external, relevant to
the scope of the DW system to be developed.
Overview
This task identifies both the internal and external source systems that provide inputs to the
proposed BW system being developed. A Source System Abstract is then developed to provide
an overview of the identified relevant internal and external source systems.
A.2.18Identify the source systems relevant to the scope of the proposed

DW system.
Identify the relevant SAP and non-SAP source systems that provide inputs to the proposed DW
system.
The DW may use existing legacy system components (e.g., through the use of software
reengineering tools) and/or co-exist with the different legacy systems (in modified or unmodified
form) after implementation. These relationships and boundaries should form part of the Source
System Abstract together with brief narrative describing the intended approach to the legacy
systems. In addition to the internal source systems, the relevant external data/systems should
also be determined such as:
Forecast data/systems;
Supplier data/systems;
Customer data/systems; or
Business partner data/systems.
A.2.19Identify the systems that are outside the scope of the project.
Develop a list of the internal and external systems that are outside the scope of the project. For
each of these systems, determine as appropriate the impact of excluding the system from the
project on the proposed DW system in terms of any constraints or limitations placed on the
capabilities of the DW system.
A.2.20Develop an overview of the source systems.

Develop an overview of the source systems capturing such characteristics as:
Ownership of the systems;
System/data distribution characteristics;
Media of the source data;
Volumes;
Source system technology; and
Costs of capturing and transferring data to the data warehouse.
Develop Management Overview Diagrams of the relevant source systems and interfaces, as
appropriate.
Several different types/views may need to be prepared for areas such as:
A Legacy System Abstract which shows how existing legacy systems (changed or
unchanged) will work with the new DW system;
Page 34
An Interface Abstract which shows further levels of details for the different interfaces
shown on the MOD(s) e.g., an interface may be shown as a single item on the MOD but
may be composed of different sub-systems and programs; and
A 3rd Party Report Tool Abstract which shows details of report production at a high level
e.g., where additional software or processing is required to generate outputs from the BW
system via ODBO or downloaded from the InfoCube. It is important that the estimated
volumes of data to be processed are also included as part of this Abstract.
As well as what is included within the project scope, statements of items/areas that are
specifically excluded from scope may also need to be prepared.
A.2.21Assess the impact of the source systems on the DW system.

Assess the impact of the source systems on the DW system. Revise the project plan as
necessary based on the review of the source systems and their assessed impact on the project.
A.2.22Review Source System Abstract with management.

Assemble the source system descriptions into a Source System Abstract in both graphical and
narrative form. Review the Abstract with management. Discuss and resolve any outstanding
issues. Revise the Abstract as appropriate.
Obtain formal written management approval of any changes in the original project scope.
Page 35
A.2.23Prepare Technology Abstract

Purpose
To provide an understanding of the current technology platforms and to provide a high-level view
of the target technology environment for the proposed BW system.
Overview
The Technology Abstract documents the desired technology components and describes the
technology environments for the new BW system that, at a minimum, should include
development, staging and production environments.
The necessary configuration is subject to change as the project progresses but the intent is to
provide some initial guidance to assist in project estimation.
Note: The Technology Abstract is a high-level view of a proposed technical architecture. While the
steps in this task attempt to identify a comprehensive list of considerations associated with the
analysis of both the current and proposed architectures, the intent of this task is to obtain a level
of understanding and comfort with the technology aspects of the project and is not intended to be
an exhaustive, detailed study of all of the technology components of the new system. This task
provides an understanding of the level of effort required to conduct the detailed technology tasks
in the Technology Planning, Support and Cutover Phases.
A.2.24Analyze the existing systems.

Produce a current system technology schematic showing the main technology components
included in the current system (e.g., Database servers, Application servers, Web servers, and
client machines).
Indicate on the schematic where the various components currently reside (e.g., nation, region,
state, building, floor) and any interconnectivity between platforms.
A.2.25Determine the need for a Technology Pilot.

If a new version of BW is to be implemented, or new supporting technology components are
incorporated into the architecture environment, it is strongly recommended that an early pilot of
the planned architecture should be planned for to address such issues as:
Determine the capacity of all portions of the system and the network to enable the system
to run with the planned data volumes, processing timetable and frequency and response
times;
Determine whether all components as defined in the Technology Abstract will work in
conjunction with one another (e.g., hardware, operating system, network and tool
compatibility);
Begin the definition of technical support resources required;
Begin the organizational training in the use of different components of the proposed
technology architecture including any new or emerging technologies; or
The technology components defined in the Technology Abstract may be presented in a matrix
format (as illustrated in Exhibit B-2) to highlight the characteristics of the various technology
components in supporting the different DW levels or layers. These characteristics may include:
Software/application class (e.g., legacy systems, OLTP systems, back-office systems
such as financial applications, relational OLAP or multidimensional OLAP);
Hardware platform;
DBMS/file organization;
Data communications protocols;
Page 36
Information delivery channel (e.g., LAN/WAN or Internet/Web);

Name of application system (e.g., SAP package);
Location (where the respective DW level/layer resides); and
Organizational unit (responsible for the respective DW level/layer).
Experience in developing and implementing technology changes has shown that a project can
diminish or transfer the risks associated with using complex client/server and emerging
technologies early on through the use of a Technology Pilot.
As a Technology Pilot is sometimes difficult to estimate before a project commences, it may be
useful to treat the pilot as a distinct sub-project that is proposed for and managed separately from
the main project.
With an understanding of the proposed technology environment, determine the need to test and
validate the proposed environment through a Technology Pilot. Document the decision, the
reasons for the decision and a work plan for conducting the Technology Pilot.
A.2.26Discuss and confirm the Technology Abstract.

Assemble the technology information into a Technology Abstract in both graphical and narrative
form. This may also include some discussion of any items/areas that are specifically excluded
from the project scope. Review the Abstract with management. Discuss and resolve any
outstanding issues. Revise the Abstract as appropriate.
Review with management any open issues such as obtaining agreement for an appropriate
technology infrastructure and/or the need for a Technology Pilot.
Page 37
Resolve as many issues as possible or agree that further investigation will be completed during
the Technology Planning, Support and Cutover Phase of the project. Ensure that further
investigations are included within the scope of the Project Preparation Stage.
Page 38
A.2.27Prepare Data Conversion Abstract

Purpose
To provide a high-level understanding of the scope and complexity of data conversion to create
the initial data for the DW project. This is typically the one-time data load of legacy system data
that will not be converted to the BW system.
Overview
Data conversion is accomplished through manual and/or automated means and includes the
creation of any data needed for new data records. It enables the new system to accurately reflect
the current status of organizational data at the start of production.
The term "data conversion" is used in the DW Methodology in a wider sense than the dictionary
definition in that it is defined to include four separate elements:
Purging/cleansing of existing data;
Reconciliation/balancing of the old data and the old system/new system;
Creation of new/additional data; and
Conversion of the old data to the new system to create master file data and opening
balance data (where appropriate) for the new DW system.
The conversion of data from a source system usually requires the creation of a conversion
system. The conversion system can be manual, automated or both:
Logically, conversion is taking data from one system and moving it to another system at a
point in time;
Conversion may translate the format of the data but not update it; and
Conversion programs may be run more than once:
may be run multiple times with each execution converting a subset of data, such as one
calendar month,
may be run multiple times for parallel running, phased or staged implementation where
progressive data conversion is required, and
may be run multiple times until reconciliation shows a valid conversion.
In addition to the normal problems of system development, data conversion has several unique
requirements:
Data may need to be created if it does not exist;
Current data may need to be purged, corrected or verified;
The existing system (manual or automated) may need to be corrected or balanced within
itself before conversion can be commenced or completed;
Converted data may need to be reconciled to the old system such as reconciling the
closing balances of the old system to the opening balances of the new system; and
Timing of the data conversion process may vary, e.g., data cleansing or creation may
precede other tasks by several months.
Data Conversion Management
There are a number of management issues to address for data conversion projects. Depending
upon the size, scope and duration, it is quite often more appropriate to have a separate data
conversion project team as:
Different resources may be required such as clerical support for data clean-up;
Specific programs may need to be written to either identify missing or invalid data in the
existing systems or to correct data. This may require specific detailed IS technical
Page 39
knowledge of the current system and will certainly require input from experienced
business users; and
The timing and duration of the project may differ (as discussed above).
During data conversion clean-up, data may be found that is incomplete or incorrect. This then
may require adjustments or write-offs that need senior management and internal/external audit
approval. This has even greater significance where these adjustments affect statutory financial
statements.
At the conclusion of a data conversion project, there must be formally approved documents,
signed-off by senior management, that contain the reconciliation(s) between the old and the new
systems and that comply with the formal acceptance criteria established to determine completion
of the data conversion project.
A.2.28Determine the condition of the existing data.

Review the existing data to determine the condition of the data, whether it has been regularly
reconciled and balanced, what data will need to be created and what can be converted to form an
opinion on the impact that these activities will have on the project work plan.
Early review of the existing manual or computer system maintained data is necessary to
determine whether:
The data conversion component of the new system will be large or small;
The current data needs to be corrected or its quality improved; and
A separate project team is required to address the data conversion management.
This step is included at this time to ensure that an early view of the existing data is obtained as
the data conversion work tasks may need to be commenced immediately if they prove to be long,
complex and involve large volumes of data.
A.2.29Determine conversion method and approach.

Determine the appropriate methods for converting the data. Alternatives may include:
For simplistic, low-volume record conversions, manual conversion methods may be
appropriate;
For conversions requiring source data from multiple production or legacy systems, a
more complex automated conversion approach may be derived; or
If a staged conversion process is an option, determine the appropriate methods and
approaches for converting data in multiple cycles (and in multiple locations) over
extended time frames.
A.2.30Determine the scope and complexity of the data conversion effort.

Based on the understanding of the source systems, determine the scope and complexity of the
data conversion effort considering factors such as:
The source data that requires a one-time conversion (e.g., "dead" system data);
The quality of the source data to be converted;
The manual data entry requirements;
The capabilities of the source systems in generating the conversion data; and
The capabilities of the data transformation system that could be used for one-time data
conversion purpose.
Discuss with IS management and staff to clarify or resolve any outstanding issues. Validate any
assumptions made in estimating the scope and level of complexity of the data conversion effort.
Page 40
A.2.31Discuss and confirm the Data Conversion Abstract.

Assemble the results of this task into a Data Conversion Abstract document in both graphical and
narrative form. This may also include some discussion of any items/areas that are specifically
excluded from the project scope.
Review the Abstract with management. Discuss and resolve any outstanding issues. Revise the
Abstract as appropriate.
Page 41
A.2.32Evaluate Data Warehousing Development Options

Purpose
To evaluate various DW development options to ensure that the selected development approach
is warranted and can be cost justified.
Overview
The various approaches to developing the proposed DW system are determined and evaluated.
A high-level Cost/Benefit Analysis is completed for each option considered feasible. The results of
this evaluation are reviewed with management and the most appropriate course of action is
selected.
This task may be completed to define one development option for a DW project or, on a DW
program where there may be multiple DW projects, multiple development options may need to be
defined. For example, a Product DW program may include several DW applications such as
Product/Promotion Planning, Product/Volume Reporting, Product/Volume Analysis, Financial and
Non-Financial Performance Measurement.
A.2.33Define the system development options.

The various DW development approaches and issues discussed in the DW Baseline should be
reviewed to assist in identifying alternative development approaches in this step.
Examine the information collected to this point. Document the alternative courses of action
available to meet the organization's requirements considering development issues such as:
Top-down versus bottom-up development approaches:
Top-down - starting by building an enterprise DW from a subject area perspective and
then gradually moving subsets of data to data marts. This approach may take a longer
time to implement,
Bottom-up - starting by building data marts to quickly provide data to users. This
approach may encounter difficulties in integrating data from an enterprise perspective, or
Bottom-up development with a top-down framework - starting by developing a high-level
enterprise or subject area DW framework to guide the incremental development of the
data marts or DW;
Data marts contain subsets of informational data of interest to users in certain organizational units
or geographical locations. In a BW environment, these may consist of more specialized
InfoCubes.
Prototyping as an approach for:
defining user requirements for the presentation systems (i.e., requirements prototypes),
proving the viability of a particular technology or suite of technologies (i.e., proof-ofconcept prototypes), or
incrementally developing the DW system (i.e., evolutionary prototypes);
Technology Pilot(s);
DW development often follows an iterative and incremental approach. As illustrated in Exhibit B-3,
iterative development should be planned along three major dimensions - what technology
components to include, which subject areas to address and within what time frames
Page 42
A.2.34Refine the system development options.

Discuss the different system development options and exclude options that are unacceptable or
inappropriate. Document the rationale for this exclusion.
For the remaining options, estimate the degree to which the approach would both fulfill the
requirements and meet expectations, e.g., a custom development may fully meet the defined
requirements but may be totally unacceptable in terms of cost, implementation time scales or
support levels.
A.2.35Define the system development approach.

Define the system development strategy to be adopted. Document the rationale for the selection.
Refine the options as necessary to obtain a better fit of requirements and expectations, e.g.,
consider phasing the implementation of the system's functionality to meet the urgent user needs
as quickly as possible and to implement the less pressing needs progressively.
A.2.36Prepare a Class 1 Estimate.

Prepare a high-level Class 1 Estimate of either the chosen alternative or several of the
alternatives, as appropriate.
Provide an initial estimate for each viable system development option that defines the potential
development, implementation and maintenance costs.
Page 43
Compare these estimates against the anticipated benefits from implementing the new system.
Wherever possible, the users of the system should be assigned responsibility for providing details
of the anticipated benefits from the proposed system.
The costs and benefits can only be approximated but they are needed to provide an indication of
the scale of costs involved and to provide some indication of how the costs vary across the
different system development options.
A.2.37Recommend a system development option.

Discuss each alternative system development option to ensure that the evaluation process has
been thorough and includes all pertinent facts.
Recommend a system development option that should be based upon the evaluation of each
alternative's advantages and disadvantages combined with the Cost/Benefit Analysis.
A.2.38Discuss and confirm the recommended system development option.

Review the analysis of the recommended system development option with management. Resolve
any questions and issues and, if necessary, make any changes. This step may require more than
one meeting.
Agree the selected option and obtain formal written approval from management to continue the
project, following the agreed option.
Page 44
A.2.39Submit Data Warehousing Project Abstract Deliverable

Purpose
To confirm the scope of the assignment with management and to obtain formal written approval
and authorization to proceed.
Overview
It is important to ensure that there is a precise understanding of expectations and objectives from
the project and to agree any changes in scope or deliverables.
Effectively managing a project requires a clear, precise understanding of the scope and
objectives of the project. Establishing this understanding early in the project allows the project
team to focus their efforts on delivering the appropriate services and helps to avoid
misunderstandings, false starts and rework of project deliverables.
As there may be a period of time between proposal submission and agreement to proceed with
the project, it is essential to confirm the project scope and deliverables with senior management
before commencing the detailed analysis.
The Data Warehousing Project Abstract deliverable provides the high-level understanding of the
system. The DW project risk is assessed and the constituent parts of the Data Warehousing
Project Abstract are reviewed for content and clarity and the final Data Warehousing Project
Abstract deliverable is discussed with management to obtain formal written approval to proceed.
A.2.40Assess project risk.

Complete an initial risk assessment if one has not already been completed. Consider:
Business/organizational issues/risks such as:
availability and accessibility of data,
impact of the DW on organizational communications and decision making processes,
data ownership and distribution issues, or
staff training issues;
Data issues/risks such as:
general level of data quality. While a DW system may augment and format data for
analysis, it cannot compensate for missing controls in source operational systems,
inconsistent codes or abbreviations across data sources. A standard codes repository
and decode procedures may need to be developed to decode, convert and
standardize inconsistent codes or abbreviations across data sources,
non-uniformity of data maintenance and update. This may potentially add complexity
to the data integration, synchronization and update processes, or
availability and accuracy of documentation of required source data and reporting
systems; and
Technology issues/risks such as:
learning curve of the project team in using the data warehousing toolsets,
need to procure additional technical architecture components adding risk to project
cost, effectiveness and schedule,
adequacy of initial analysis of end-user tool requirements and impact on flexibility and
overall applicability of the toolset, or
ability of the architecture to accommodate update cycles and incremental
requirements of the data warehouse,
Where the project risk is perceived to be inappropriate, changes may need to be made to the
original project scope; e.g., if the project is too large, either some functions may be deleted or the
Page 45
project broken into several smaller projects. Alternatively, project staffing or funding may require
changes.
A.2.41Assemble and review Data Warehousing Project Abstract

deliverables.
Review the individual parts of the Data Warehousing Project Abstract deliverable that were
prepared in the preceding tasks for clarity and consistency and package them together into a
formal management deliverable.
Document any assumptions made during the preparation of the Data Warehousing Project
Abstract.
A.2.42Submit and walk-through the scope deliverables with management.

Ensure that interim work products have been approved by the appropriate stakeholders and any
updates incorporated. Resolve any questions or issues. Using a structured walk-through or
presentation approach, present the scope deliverable to management for review.
A.2.43Obtain formal written approval of scope document.

The initial scope document is critical to define the boundaries of the project for level of effort
analysis purposes and project scope control. All key personnel, including project team members,
project sponsors, steering committee members and some key stakeholders must understand the
scope document and agree to its components.
Obtain formal written approval to ensure that all expectations are aligned with the project scope
and that the formal written review is agreed and approved.
*** FORMAL APPROVAL POINT ***
Page 46
A.3
Change Integration
Purpose
To identify and address change integration issues across the DW development life cycle as the
organization envisions the management of organizational knowledge.
Overview
Changes may occur at two levels in the process of developing an integrated architectural view of
knowledge management for an organization:
Changes at the organization's strategic level. These are the strategic changes associated
with the management of knowledge and business information across organizational
boundaries addressing issues such as competitive drivers, strategic opportunities and
organizational structural, procedural and cultural changes; and
Changes at the organization's tactical level. These are the changes associated with
developing an information architecture that promotes and facilitates information sharing
within an organization. There are many areas within an organization that can benefit from
sharing the same piece of data, information or knowledge. However, an organization's
data resource is often not managed from an enterprise-wide, strategic perspective, rather
it is maintained by individual organizational units to meet local business needs.
Thus, to truly manage data resource as an organizational asset, an enterprise-wide data resource
management program is needed to provide a proper business focus and a framework for
coordinating the implementation and integration of the organization's data resources. Many
change issues must be addressed at the tactical level such as the organizational structure,
authority, responsibility and technology of the data resource management program.
To obtain the greatest value from a DW development initiative, it must be an integral part of a
broader organizational knowledge management program which does not only address technology
matters but, more importantly, must align technology with the organizational structures and
business processes.
While, in practice, many of the change integration tasks discussed in this phase may themselves
be separate organizational initiatives or projects, the focus of this phase is on determining the
impact of implementing a DW on the organizational structure, business processes and
other technologies and the improvement opportunities which a DW offers.
As an organizational initiative, the roll-out of a data warehousing program must be carefully
planned addressing various organizational issues such as stakeholder interest, knowledge
transfer, training and technical support.
The scope of a typical DW project often does not include addressing change integration issues. However,
these issues are often critical for the ultimate success of a DW program. Furthermore, additional
improvement opportunities may be identified in the course of analyzing or developing the DW. Thus, the
project team must bring to the attention of management any significant change integration issues
identified. As appropriate, separate change integration projects may be initiated or the scope of the DW
project may be expanded to address these issues. Any scope changes must be discussed with
management and formal written approval of the changes obtained before any work commences.
Page 47
Change Integration Task Relationships

K n o w le d g e o f c u r r e n t e n v ir o n m e n t
K n o w le d g e o f t a r g e t ( B W ) e n v ir o n m e n t
D a ta W a r e h o u s in g P r o je c t A b s tr a c t
C1
A s s e s s D a ta
W a re h o u s e Im p a c t o n
O r g a n iz a tio n
O r g a n iz a tio n a l Im p a c t
B u s in e s s P r o c e s s Im p a c t
T e c h n o lo g y I m p a c t
C2
D e v e lo p C h a n g e P la n
( o p tio n a l)
I m p le m e n t a t io n s t r a t e g y
C h a n g e P la n
C3
In te g ra te C h a n g e s
Page 48
Im p le m e n t e d c h a n g e s
A.3.1 Assess Data Warehouse Impact on Organization

Purpose
To assess the impact of the DW system being developed on the organization.
Overview
This task determines the impact of implementing the DW on the organization. There are two
primary objectives of this task:
To ensure the success of the implementation and roll-out of the DW program; and
To identify business opportunities (e.g., improving the organization's business analytical
capabilities) enabled by making data accessible and shareable by the organization's
information users.
A.3.2 Assess data warehouse impact on business processes.

Assess the impact of implementing the DW on the organization's current or target business
processes. Focus on improvement opportunities enabled by the DW such as:
Business process reengineering;
Workflow integration; and
New business opportunities (e.g., customer relationship banking enabled by the
availability of a centralized DW to show all of the relationships which a customer has with
the bank; selling "data" as a product).
A.3.3 Assess data warehouse impact on organizational structure.

Assess the impact of implementing the DW program on the organizational structure considering
issues or opportunities such as:
Organizational job changes, i.e., the impact of the implementation of the DW on different
individual jobs and positions including changes to existing positions, addition of new
positions and the deletion of existing positions;
Changes to physical locations of employees;
Organizational restructuring (e.g., organizational delayering as a result of more timely
availability of management or performance measurement information);
Organizational changes to implement a centralized data resource management program
in support of the DW initiative; and
Interorganizational alliance opportunities (e.g., sharing inventory data with a primary
supplier to facilitate replenishment of inventory stock).
Some training issues may arise from assessing the organizational impact which should be fed
into the Training phase of the methodology to ensure that all training needs are met.
A.3.4 Assess data warehouse impact on technology and facilities

infrastructure.
Assess the impact of implementing the DW on the organization's technology and facilities
infrastructure considering issues such as the integration of previously independent transaction
processing systems and the integration of transaction processing and analytical processing
systems.
The facilities may be impacted by the organization structure changes such as the physical
relocation of personnel, redesign of office layout or acquisition of new equipment (e.g., new
switchboard/telephone system).
Page 49
A.3.5 Evaluate the impact findings.

Evaluate the impact findings and identify any significant issues or opportunities. While focusing
on the change integration issues affecting the DW program, other business opportunities may
also be identified.
Discuss with management the findings and their implications both for the project and for the
organization as a whole. Determine what actions need to be taken to remove any barriers and to
ensure the successful and effective implementation of the DW systems.
Page 50
A.3.6 Develop Change Plan (Optional)

Purpose
To develop the change implementation strategy and an integrated change plan.
Overview
This task develops an integrated change plan based on the change actions required to implement
the target environment and guided by management's decisions in defining an implementation
strategy.
A.3.7 Develop implementation strategy.

Develop an integrated implementation strategy to guide detailed change planning and
implementation efforts and decision making.
A.3.8 Identify change actions.

Identify the changes that will need to take place to achieve the target environment.
A.3.9 Analyze feasibility of change actions.

Determine the feasibility of each of the potential change actions.
A.3.10Integrate change actions into projects.

Integrate individual change actions into a prioritized list of projects.
A.3.11Develop change plan.

Integrate project descriptions into a change plan.
Page 51
A.3.12Integrate Changes
Purpose
To coordinate and integrate various change actions taking place on the project.
Overview
Many change activities are taking place on a typical DW project - both technical and
organizational.
The coordination of the technical tasks (e.g., coordinating the data, process and technology
design activities) is the responsibility of project management.
The broader change projects such as those identified in the change plan developed in Task C2
are often considered as separate project initiatives and are outside the scope of the DW project.
Thus, the focus of this task is on the organizational activities that need to take place in support of
the DW program being developed.
A.3.13Develop a DW change integration plan.

Develop a DW change integration plan in support of the planned DW initiative addressing
activities such as:
Establishing the organizational infrastructure in supporting the planned DW program;
Establishing new or modified organizational or business processes (e.g., to align with a
new performance measurement or decision support system enabled by the planned DW
program);
Developing a hiring plan to staff the new DW-enabled business and technology
environments;
Developing an education/training program (including logistics and scheduling);
Developing a facilities plan to enable changes in personnel and equipment;
Developing plans for knowledge transfer (i.e., positioning the user organization for
ownership, leadership and management of the DW program); and
Developing a roll-out plan for the new DW program.
If a broader change integration task is within the scope of the DW project, the DW change
integration plan could be an integral part of this plan.
A.3.14Implement the DW change integration activities.

Implement the DW change integration activities as described in the plan.
Some of the activities may be completed by the project team (e.g., providing user or knowledge
transfer training sessions) and others may be completed by various organizational units (e.g., the
Human Resource department may be responsible for staff hiring).
These activities may occur at various points during the DW development life cycle and may
continue subsequent to the project completion. It is important to coordinate and integrate, as
appropriate, these various DW change integration activities in the DW project detailed work plans.
Page 52
A.4
Prototyping
Purpose
To create a common understanding of the requirements of the proposed DW system to facilitate
decisions relating to the "look and feel" of the new system and to confirm that the proposed
interface will appropriately support the roles and responsibilities of the business users.
Overview
Prototyping may be completed on a DW project as an approach for:
Defining user requirements for the presentation systems (i.e., requirements prototypes);
Proving the viability of a particular technology or suite of technologies (i.e., proof-ofconcept prototypes); or
Incrementally developing the DW system (i.e., evolutionary prototypes).
The key activity of this phase is the analysis and design of the user interface. Prototyping is a
technique often used to assist in the development and approval of the user interface but, even if a
traditional prototype is not going to be developed, these tasks are still relevant to help define how
the users will ultimately interact with the system being built.
The Prototyping Phase stretches across the DW life cycle. Depending on the development
strategy identified and adopted in the Project Start-up Phase, the tasks in this phase may be:
Completed exclusively in one phase; or
Repeated across the life cycle, potentially many times.
For example, if a waterfall development approach is adopted, the initial set of tasks for defining
acceptance criteria, standards, development and navigation strategies and building the
preliminary prototype would all be Business Blueprint tasks, as would the walk-through of the
prototype with the users. The goal of these tasks would be to use the prototype to identify and
confirm the organization's DW requirements. The further revisions and development of the
prototype would also potentially be Business Blueprint tasks, where the actual interaction with the
application system would be designed and documented.
However, If a spiral development strategy was to be adopted, it would be viable to complete all of
the tasks in the phase a number of times within what would be the Realization Stage of
development.
If an iterative approach was adopted, all of the tasks may be completed for each iteration of the
life cycle.
The decision on which strategy to follow should be made in the Data Warehousing Project
Abstract Phase and this will largely dictate how the tasks in this phase will be used.
The tasks defined in this phase will also be influenced by decisions made in the technologybased phases of the life. For instance, specific tools selected for the project may either constrain
or direct the developer towards appropriate standards and development techniques. However, the
outputs from the Prototyping Phase should drive the technical design of the application instead of
vice versa.
Page 53
Prototyping Task Relationships
CSFs
P r o je c t A b s t r a c t
T e c h n o lo g y P ilo t r e q u ir e m e n ts
CSFs
P r o je c t A b s t r a c t
T e c h n o lo g y P ilo t r e q u ir e m e n ts
D a ta T r a n s fo r m a tio n
R e q u ir e m e n t s
D2
P re p a re P ro to ty p e
D a ta
D3
P ro to ty p e D a ta
T r a n s fo r m a tio n
D1
D e fin e P r o to t y p e
P ro to ty p e s tra te g y
B u s in e s s s c e n a r io s
P r o to ty p e a c c e p t a n c e c r it e r ia
P ro to ty p e d a ta
D a ta T r a n s f o r m a tio n P r o to ty p e
D6
R e fin e P r o to ty p e
A n a ly s is a n d D e c is io n P r o c e s s
D e f in itio n
D4
P ro to ty p e E n d -U s e r
P r e s e n ta tio n
E n d - U s e r P r e s e n t a tio n P r o to t y p e
D5
R e v ie w a n d P r e s e n t
P ro to ty p e s
P ro to ty p e p re s e n ta tio n
D7
E v a lu a t e a n d S u b m it
th e P ro to ty p e
D e liv e r a b le
P r o to ty p e D e liv e r a b le
Page 54
A.4.1 Define Prototype

Purpose
To define the objectives, scope and approach for the prototype.
Overview
The criteria for accepting the prototype and the responsibility for arbitration and authorization of
changes to the prototype are defined and approved in this task. The steps in this task also
determine how the prototype will be presented to management and the users and in what form
comments and suggestions will be recorded. These criteria must be established before the
prototyping effort can begin. The means of determining the completion of the prototype must also
be defined and agreed before commencement.
All of the different standards to be used within the prototype are defined for each component
including query views, workbooks, web pages, reports, languages, tools, naming and numbering
conventions, security and documentation.
The common format for each query and query definition is identified. The format should be the
same for the entire system.
If standards are already in place or industry standards exist, the prototype should conform to
those standards. Some customization will probably be required.
If standards are not in place or if the organization decides not to use them, new standards must
be defined, approved and documented.
In addition to practical standards, the prototype developer must have a set of conceptual
guidelines. These guidelines help determine how to aggregate data and functions as well as how
to have the user move through the system. The user metaphor and the navigation strategy are
developed to ensure that user-oriented systems are understandable and easy to use.
Business Scenarios are created and used to help guide prototype development, to validate that
the prototype supports the way in which the organization wishes to work and to support testing in
later phases. The Business Scenarios may also be used to describe the system to the nontechnical user or senior management.
A Business Scenario represents any of several realistic sequences of activities from the user's
point of view, like a script. Scenarios, by definition, are procedural in nature and may be used to
build the prototype (using the scenario as a script for demonstrating how business events function
in the new system) or in system testing of all of the possible paths through the system.
A.4.2 Define prototype acceptance criteria.

Prepare a clear articulation of the prototype purpose and what it is intended to achieve.
Identify the key system users and determine the criteria that will be used to control the
prototyping process and confirm that the prototyping process is completed.
These criteria should include the duration of the process (e.g., number of iterations to be
performed or the length of time the prototyping process will last), expected response times and
form of interface In addition, a minimum statement of functionality may be stated, e.g., it has to
process certain transactions or data, at minimum.
Any acceptance criteria defined must be precise and measurable.
Page 55
A.4.3 Define usability goals.

Define precise and measurable goals for assessing the usability of the prototype. Consider:
Ease of learning (amount of training required to learn the system);
Efficiency of the system once learned (ease of use);
Ability of infrequent users to return to the system without having to learn it all over again;
and
User satisfaction.
A.4.4 Determine user interface prototype strategy.

Determine the best strategy for modeling the user interface as a part of the overall development
strategy.
The prototyping software and hardware to be used and type of interface environment should be
selected here if not already identified. Refer to the Technology Abstract and the Technology
Definition to identify any decisions that may have been made concerning the hardware and
software components of the prototype. The IT infrastructure components and environment
necessary to develop the prototype must be in place and functioning satisfactorily before the
prototype commences.
Be certain that the approach used does not conflict with the ultimate development, test or
production IT environments or give unrealistic expectations for the system. The strategy should
also answer the following questions:
Will the prototype be evolved into the production system?
Evolutionary prototypes are functional in addition to representing the look and feel of the system.
Before the prototyping begins, the team must determine if it will be evolved into the production
system or not; this will have a definite impact on the prototyping tool selected;
Is it a requirements-only prototype?
Some prototypes deal exclusively with "look and feel" issues, those that help define user
requirements for the system interface. If the prototype is a requirements prototype and will not be
developed further, this must be specified;
Is it a disposable prototype?
The future of the prototype must be established. Will it be discarded once the team has acquired
what it needs? Will it be kept for historical or audit trail purposes? If it will be kept, an explicit
policy for what should be done with it should be devised;
Is it a proof-of-concept prototype?
Sometimes a prototype is developed to prove whether or not a particular technology, suite of
technologies or application design idea can be realized. Proof-of-concept prototypes are usually
developed in the very early phases of a project (e.g., proposal, system abstract or technology
definition), are not used to elicit user requirements and have very strict hardware and software
requirements; or
Is it clearly a prototype and not a pilot?
A pilot is usually a small, controlled installation or a functioning system. While a functional
prototype might evolve into a pilot, a requirements only prototype would not. This distinction is
important to understand so that the appropriate prototyping tools are used.
In addition to these strategy questions, decisions may need to be made and documented about
which items are specifically excluded from the prototype such as year-end processing features.
Document the strategy to be used and any considerations of the alternatives considered.
A.4.5 Assign authorization and responsibility.

Determine who can authorize changes to the prototype and who is responsible for acceptance of
the prototype.
Page 56
While many users may be involved in the development of the prototype, one person should be
the ultimate authority. This person needs to be able to resolve conflicts between competing
requirements or expectations.
A.4.6 Confirm resources and skills to conduct the prototype.

The definition of the prototype strategy may result in changes to the original planned resources
and skills needed for the completion of the prototype.
Redefine the skill and resource needs together with any training requirements for the prototyping
team (e.g., for prototyping tools, languages or the prototyping techniques and approach to be
used) and complete any necessary training.
A.4.7 Create Business Scenarios.

For each business event identified, create a Business Scenario.
A Business Scenario is a narrative, script-like document that represents a realistic scenario for
the user. For example, a business analyst is tasked to complete a comparative profitability
analysis by customer segment within a specified period on sales of certain products in selected
locations. This is triggered by the sales revenue shortfalls in two particular locations during a
specified period of time. The outputs of the analysis (in terms of both contents and format) are not
well defined in advance and will be driven by the analysis findings. The analyst will need to
analyze the sales data from various dimensions to identify the relevant factors contributing to the
sales shortfalls being investigated.
The Business Scenario for this particular example requires that the BW system contain the
necessary data to support the analysis needs of this scenario.
Ensure that each common contingency is covered by at least one of the Business Scenarios.
Each scenario should have as much detail as possible. Also, some scenarios will require no
system action, e.g., suppose a customer calls to ask about information that is currently displayed
on the monitor or a user is looking up multiple pieces of information within a particular customer's
file. The user simply would remain within the particular query/workbook already opened.
A.4.8 Review Business Scenarios.

Complete a structured walk-through of the Business Scenarios for validity and completeness.
Make corrections where required.
Page 57
A.4.9 Prepare Prototype Data

Purpose
To prepare source data for the prototype.
Overview
This task prepares the data to be used in the prototyping effort. The work to be completed in this
task may vary depending on the objectives and scope of the prototyping project.
A.4.10Determine prototype data requirements.

Review the objectives, strategies, business events and business scenarios relevant to the
prototype effort to determine data requirements.
As appropriate, refer to and tailor the tasks and steps in the following phases in completing this
step:
Analysis and Decision Process Definition;
Analytical Processing Data Definition; and
Data Design.
A.4.11Develop prototype data capture strategy.

Develop a strategy for capturing or developing data for the planned prototype effort considering
alternatives such as:
Converting subsets of real source data; and
Creating mock data.
Review the prototype data capture strategy with relevant management and users. Revise the
strategy as appropriate.
A.4.12Develop prototype data.

Develop or capture the prototype data based on the established strategy or approach.
Document any assumptions made in developing the prototype such as those regarding
completeness, quality or user inputs.
Page 58
A.4.13Prototype Data Transformation

Purpose
To develop a prototype data transformation system.
Overview
This task develops a prototype data transformation system. Depending on the objectives of the
prototyping effort, this task may be completed to:
Evaluate existing InfoSources or new ones that need to be developed;
Evaluate the data transformation architecture;
Assess the volumes and capacity needs for the data transformation system;
Assess the quality and completeness of the source data; or
Develop prototype InfoCubes.
A.4.14Determine the functional requirements for the prototype data

transformation system.
Review the prototype objectives and strategies, business events and business scenarios to
determine the functional requirements for the data transformation system.
As appropriate, refer to and tailor the tasks and steps in the following phases in completing this
step:
Analysis and Decision Process Definition; and
Analytical Processing Data Definition.
A.4.15Develop the prototype data transformation system.

Develop the prototype data transformation system based on the defined requirements.
This includes building new InfoSources or utilizing existing Business Content extractors and
InfoSources.
Page 59
A.4.16Prototype End-User Presentation

Purpose
To develop a prototype presentation system.
Overview
During the Realization Stage, all designated queries, workbooks, and/or web views are
incorporated within the prototype. Designated queries may be only risky (high security access
only), high use or those deemed important to the business as defined by the Business Scenarios
or may be all queries in the application. The difference is significant in terms of the development
effort and needs to be clearly specified as part of the prototyping scope definition.
Modifications requested and agreed with the users are added to the preliminary prototype.
Queries, workbooks, web views and processes are refined and may incorporate prompts,
restrictions, filters, and conditional logic where appropriate.
Detail formatting is added and system flow is refined. Calculated and restricted key figure
structures are defined and incorporated. The level of detail and amount of work necessary is
dependent on the requirements stated in the prototype acceptance criteria.
At this point, the queries in the interface have been identified and prototyped and the main
information content, navigation options and drill paths have been defined. This phase leads to
finalized detail design for each query, workbook and web view..
A.4.17Refine and incorporate all required queries/workbooks.

Based on the requirements established in the prototype acceptance criteria and walk-through,
build and incorporate all remaining queries and workbooks into the prototype. These should
include additional details such as filters and all navigation actions.
Ensure that any user-requested changes not specified earlier support the CSFs and are not an
expansion of scope.
A.4.18Refine or prepare all Report Layouts and Definitions.

Refine any existing reports and prepare any remaining or additional reports.
A.4.19Finalize data content.

Compare the prototype with the Logical Data Model (LDM) to ensure that all required data is
available on the query views. Be certain that the prototype uses data as defined in the LDM or
that is consistent with any denormalization decisions made during Data Design.
A.4.20Define and incorporate required calculated key figures and

selections.
Ensure that all calculated key figures and selections are correct and have been incorporated
appropriately. Pay special attention to any calculations or formulae requiring correct interpretation
of:
Organizational policy or procedures;
Mathematical consistency and precision; and
Statutory or other external requirements (e.g., taxation rules).
Page 60
Ensure that all of the algorithms and formulae are fully documented and that manual examples of
the calculations exist to confirm that they are accurately replicated in the system.
A.4.21Define and incorporate system/program alert/exception messages.

Where applicable, define and incorporate required prompts and variables. Include:
Range checks;
Numeric checks; and
Code validations.
Code, test and link any necessary prompts, restrictions, and formula path variables.
A.4.22Define and incorporate interfaces.

Where applicable, define and incorporate input and output transfer files containing data that will
be needed to interface with other current or future systems.
Details of the format, content and size of these records and files are prepared in the Analysis and
Decision Process Definition Phase and are recorded as a Process Description.
Page 61
A.4.23Review and Present Prototypes

Purpose
To review the preliminary prototype.
Overview
The prototype acceptance criteria, prototype development standards, user interface metaphor,
navigation strategy and preliminary prototype (queries and workbooks) make up the prototype
strategy. A walk-through of the strategy and the prototype itself is necessary to obtain user
approval and acceptance.
A.4.24Walk-through preliminary prototype and prototype strategy with

system users.
Conduct a structured walk-through of the preliminary prototype and strategy to identify errors,
omissions, modifications and any additional processes that need to be added. The strategy is
composed of the prototype acceptance criteria, prototype development standards, user interface
metaphor, navigation strategy and preliminary prototype.
Confirm the contents of the preliminary prototype with the process and data models, checking for
consistency or conflicts.
Define roles and responsibilities of potential prototype users. How are they expected to use the
prototype? How will the prototype accommodate the user needs? Have all appropriate processes
been included in the prototype strategy?
Use the issue resolution process to document changes to the preliminary prototype where
decisions such as policy issues require approval from outside the project team. Resolve the
issues with the user designated to authorize changes to the prototype.
A.4.25Evaluate preliminary prototype and decide next tasks.

Compare the preliminary prototype with the prototype acceptance criteria.
Determine the extent to which the prototype can be considered complete. Identify any
outstanding issues and assign responsibilities for resolving them.
Review with the system users and application developers exactly how the prototype is to be used
during the Realization Stage of the project. Produce a work plan to document tasks to be
completed and resources required to complete the remaining tasks in this phase.
Page 62
A.4.26Refine Prototype
Purpose
To iteratively refine the prototype.
Overview
The Business Scenarios created earlier in this phase represent realistic depictions of the
business world. They are developed in narrative form so that non-technical users may read and
understand them.
This task involves refining and finalizing the Business Scenarios that will be used as a
communications device as well as a support tool for the testing process.
A.4.27Revise Business Scenarios.

Review, revise and finalize the Business Scenarios created earlier in this phase. Add new
scenarios if omissions are found. Delete scenarios that are redundant or obsolete. Revise all
scenarios for clarity and content.
A.4.28Obtain approval for Business Scenarios.

Discuss the content and coverage of the Business Scenarios with management. Ensure that the
scenarios reflect, at minimum, typical business situations. Ensure that the expected results of
each scenario are clearly documented.
Obtain formal written sign-off from management on the content of the Business Scenarios.
A.4.29Apply Business Scenarios to the prototype.

Develop test scripts for the Business Scenarios and apply against the prototype. Check off the
expected results for each scenario, document any variations and discuss the differences with
users and the prototype developers.
If the differences are significant, document them using the issue resolution process.
A.4.30Document the final set of Business Scenarios for use in user

acceptance and system testing.
Assemble the final set of agreed Business Scenarios for subsequent use in developing and
validating both the User Acceptance Test Plan and the System Test Plan.
Page 63
A.4.31Evaluate and Submit the Prototype Deliverable

Purpose
To complete a user interface prototype that is supportive of the functional requirements of the
application, that is a viable solution for the selected technology environment and that reflects the
way in which the business intends to work.
Overview
The focus of the phase thus far has been to develop an interface specification that meets the
organization's requirements and captures and maintains all of the information needed to support
defined business events.
There are a number of other variables, however, that need to be addressed in an application
design. All of the earlier work has been integrated into a prototype design that not only supports
the way the user wishes to operate the system but also meets the requirements of the business
from the perspectives of security, maintainability, use of technology, standards, ease of use,
distribution strategies and potential reuse.
A.4.32Apply external factors to the prototype design.

Identify any external factors that help to shape the final look and feel of the prototype. These
decisions will have an impact on the look of the user interface and will also have a subsequent
impact on both the technical design and construction activities. The approach adopted should
also be used throughout the rest of the application so that the user can become accustomed to
working with a consistent interface. Ideally these decisions need to be made before starting the
Prototyping Phase, although there will be situations where alternative approaches are evaluated
through the use of the prototype.
A.4.33Validate prototype against Business Scenarios.

Compare the prototype to the Business Scenarios to ensure that all appropriate activities have
been included. The prototype also may be used to validate and refine the Business Scenarios.
A.4.34Finalize Query/Workbook Layouts and Definitions.

Based on the windows developed for the prototype, finalize the Query/Workbook Layouts and
Definitions.
A.4.35Finalize Report Layouts and Definitions.

Make any adjustments, as necessary, to finalize the Report Layouts/Definitions for the prototype.
A.4.36Assemble and review prototype deliverable.

Package together the components of the prototype and review them for completeness and
consistency.
A.4.37Submit and discuss prototype deliverable with management.

Discuss the prototype deliverable with management and resolve any questions and issues. If
necessary, prepare an action item list of items to modify in the prototype. This may involve more
than one meeting.
A.4.38Obtain formal written approval of the prototype deliverable.

Once the prototype has been reviewed and necessary changes made, obtain formal written
approval.
Page 64
A.5
Technology Planning, Support and Cutover
Purpose
To define, establish, and maintain the detailed IT environments in which the proposed Business
Information Warehouse system will be developed, tested and implemented.
Overview
Using the Technology Abstract as input, the IT infrastructure necessary to support the new DW
system is defined and designed in this phase.
The IT environment is often characterized as a complex integration of heterogeneous hardware,
software and communications components which must be flexible and scaleable to meet the
future needs of the organization and to take advantage of advances in technologies.
The IT infrastructure consists of hardware, peripherals, software and communications
components that may be transitioned and/or migrated from the existing environment and/or
procured from hardware and software suppliers.
Certain elements of the development environment such as components used in the Technology
Pilot tasks may need to be established very early in the project. It is important that project team
members with responsibility for these tasks communicate regularly with project team members
with responsibility for completing the DW Project Abstract and Prototyping Phases.
There are a number of distinct environments created during the implementation of a DW project
including development, staging and production environments. These separate environments are
built by analyzing the technology determining factors of the desired (production) system,
identifying a set of IT infrastructure alternatives and selecting the desired alternative. The choice
of the infrastructure components, in concurrence with the selection of primary suppliers, will drive
the requirements for the different environments.
The creation of each of the environments follows a set of steps, although the emphasis and the
content of the steps may differ from environment to environment. Many of these steps occur
concurrently within the creation of each environment, e.g., the design of the development
environment can proceed before analyzing all of the requirements.
Furthermore, the creation of each environment can occur concurrently with respect to the other
environments. Analyzing the requirements for the test environment may begin concurrently with
the requirements for the development environment. There is also a continual information
exchange between the life cycle of each environment, e.g., features of the development
environment may influence the requirements for the test environment.
The work in this phase can be discussed in terms of three areas:
Technology definition. The IT infrastructure support requirements for the target DW
system are defined based on an understanding of:
the current IT environment, and
the technology infrastructure requirements for the DW system addressing not just
technology issues but also organizational and business.
Strategies and standards are developed to guide the definition, design and implementation of the
different IT environments to be developed for the DW system. IT infrastructure and product
selection criteria are also determined.
Page 65
Alternative IT infrastructures are identified and refined during the task to Identify IT Infrastructure
Alternatives. The selected infrastructure is defined in the IT infrastructure abstract which is
submitted to management for approval in the Select IT Infrastructure Alternative task;
Technology Pilot. Conduct Technology Pilot is an optional task and may be completed in
some project circumstances where the IT components and environment may be complex
and the use of a Technology Pilot is warranted. In general, a Technology Pilot may be
considered in project situations:
where the IT infrastructure will form a significant component of the project (e.g., a
high proportion of the total project cost),
where there are a large number of IT components that are new to an organization,
where there is a need to prove the effectiveness or compatibility of different IT
components or explore their function/use/applicability (e.g., adoption of new
peripheral components such as hand-held data input or recording devices), or
where there is a large technology training need or culture adjustment to be made
(e.g., the organization is a slow adopter of new technologies); and
Technology design. Based on the approved technology definition, the development, test
and production environments are designed. The completed IT environment designs are
then assembled into a Technology Design Deliverable for management approval.
While the methodology discusses only the design of the development, test and production
environments, the work steps may be adopted to design other IT environments as required by a
particular project (e.g., the Technology Pilot, prototyping or training environments).
Page 66
Technology Planning, Support and Cutover Task Relationships
O v e r a ll w o r k p la n
T e c h n o lo g y A r c h ite c t u r e
T e c h n o lo g y A b s t r a c t
E x is tin g B W B a s is S t a n d a r d s
E x is tin g H a r d w a r e /S o ft w a r e c o m p o n e n t s
P r o je c t w o r k p la n
T e c h n o lo g y A b s t r a c t
P r o c e s s D e f in it io n
D a t a D e fin itio n
E5
D e s ig n a n d E s t a b lis h
t h e D e v e lo p m e n t
E n v ir o n m e n t
D e v e lo p m e n t E n v ir o n m e n t
R e q u ir e m e n ts
S tra te g y
D e s ig n
E1
D e v e lo p T e c h n o lo g y
I m p le m e n ta tio n W o r k
a n d S t a f fin g P la n s
T e c h n o lo g y I m p le m e n t a t io n w o r k p la n
E2
R e fin e U n d e r s ta n d in g
o f th e C u rre n t S y s te m s
E3
A n a ly z e IT
In fra s tru c tu re
I T In f r a s t r u c tu r e R e q u ir e m e n t s
E4
D e v e lo p B W
Landscape
B W E n v ir o n m e n t L a n d s c a p e
E6
th e S t a g in g
E7
t h e P r o d u c tio n
E n v iro n m e n t
E8
I n s t a ll a n d C o n f ig u r e
T e c h n o lo g y
C o m p o n e n ts
S ta g in g E n v ir o n m e n t
S tra te g y
D e s ig n
T e s te d E n v ir o n m e n t
E9
S u b m it T e c h n o lo g y
D e s ig n D e liv e r a b le
T e c h n o lo g y D e s ig n D e liv e r a b le
E10
S u p p o r t T e c h n o lo g y
E n v ir o n m e n ts
H e lp D e s k p r o c e d u r e s
B a c k - u p / A r c h iv e p r o c e d u r e s
E11
P la n n in g f o r
P r o d u c t io n C u to v e r
P ro d u c tio n S u p p o rt T e a m
C u to v e r p la n
Page 67
P r o d u c tio n E n v ir o n m e n t
S tra te g y
D e s ig n
A.5.1 Develop Technology Implementation Work and Staffing Plans

Purpose
To ensure that personnel have a clear understanding of their roles in establishing and maintaining
the desired DW IT infrastructure environments.
Overview
Identifying individual responsibilities for all of the different IT environments that need to be created
during a DW development project ensures that all areas are properly addressed and effort is not
duplicated.
Roles and responsibilities should be established for all tasks necessary to create the
development, test, production and any other IT environments. It is important to identify individuals
early as schedules may need to be adjusted and departments coordinated with to complete all of
the required tasks.
A.5.2 Create technology implementation work plan.

Use the Technology Implementation Strategy and the details of the target IT environments from
the Technology Planning, Support and Cutover Phase to develop a work plan for the evaluation,
selection and implementation of the DW IT architecture.
This work plan should include consideration of a number of issues in addition to the project
team's work tasks such as:
The organization's purchasing standards and approach;
The organization's formal budget and approval process for capital equipment and staff
recruiting;
Payment and funding policies and alternatives for equipment (e.g., purchase, lease or
rent);
Outsourcing issues for some components and services (e.g., network maintenance); and
Compliance with any statutes or rules for items such as health, safety and ergonomics.
Careful attention should be paid to the project scope boundaries and task allocations during this
step.
A.5.3 Identify required organization skills and roles.

Based on the required tasks, define the skills and roles that are necessary to complete all of the
specified tasks to define the total resource requirements for all of the different environments.
New or changed roles may include:
Database Administrator, Data Administrator and Data Security Administrator;
Network Administrator;
Configuration Control Librarian;
Hardware and software support Technician for each environment;
Application Developer;
Purchasing Agent; and
Help Desk staff.
Define skills matrices, job descriptions and organizational reporting lines for any new or amended
positions.
Page 68
A.5.4 Assess existing personnel.

Once all required roles have been identified, consider existing personnel for assignment to these
areas. Consideration should be given to skills of the individuals as well as available time to be
devoted to the required tasks. Cross-reference personnel to required roles. Define any training
that is required to enable the required level of skills to be developed or existing skills enhanced.
Define any roles where recruitment is required. Where necessary, commence the formal
recruitment cycle following the organization's recruitment process including approvals.
A.5.5 Derive training needs.

From the individual training requirements, derive training plans. Determine the means by which
the training will be completed such as through:
Self-teach (e.g., computer-based training);
External courses;
Internal courses; or
Apprenticeships (working closely with relevant experienced personnel).
Define any skill gaps that may require the use of external resources on a short or medium term
basis. Refer to the Training Phase for further information.
A.5.6 Discuss and confirm the work plan and staffing plans.
Discuss the technology implementation work plan and staffing plans. Resolve any questions or
issues and make changes as necessary. Obtain formal written approval.
Page 69
A.5.7 Refine Understanding of the Current Systems

Purpose
To refine the understanding of the existing systems developed in the Technology Abstract as a
frame of reference for the DW system's IT environment.
Overview
Depending on the project scope, some of the information contained in this task may have been gathered
earlier in the project during the development of the Technology Abstract or the Project Abstract. This may
mean that the work in this task focuses on adding any missing information or verifying collected
information.
The goal of this task is to review existing system components to identify the components that may
be used in the DW IT environment or will have to co-exist with the DW environment.
A thorough understanding of existing systems is essential as:
Existing systems frequently perform important functions that users may not be aware of;
Existing data structures and program code may be the only sources of information about
detailed business data, data transformation and calculations; and
Implementing new systems will usually require some amount of conversion of current and
historical data structures.
Commitment, support and cooperation from IS management, technical subject matter experts and
operations staff are critical to successfully complete this task.
A.5.8 Establish liaison with Information Systems and related departments.

Establish working relationships with the Information Systems department and related
departments to gain access to the corporate knowledge associated with the legacy systems.
These departments are critical sources that can be used to develop required models of the
system. Information to be gathered may include items such as:
Process documentation (i.e., Process Descriptions);
Data documentation (e.g., Conceptual Data Model, Logical Data Model, Physical Data
Storage Characteristics and/or Record Definitions);
Technology documentation (e.g., System Distribution Strategy, Data Communications
Network Design and/or Inventories of Hardware and Software);
Test documentation (e.g., Test Plans and Test Data for system and acceptance testing);
Source program listings;
Sample input forms and outputs;
User documentation;
Operations manuals;
Outstanding System Change Requests; and
Volume information (e.g., file record counts, file size statistics, access statistics and
capacity utilization data).
In many cases, existing systems often do not perform according to their documentation. This
does not mean however, that the documentation is of no use. It may provide the necessary
"missing link" that permits the project team to discover mandatory functionality of a system.
Information gathered in the subsequent steps will use these sources of information supplemented
with interviews with the information systems and end-user department's staff to develop a
complete picture of the current and required systems.
Page 70
A.5.9 Evaluate existing environments.

Gather and evaluate information related to the current systems, environments, organization and
policies. Include:
An identification of the different environments used to support information systems
development and processing (e.g., development, prototype, test, production);
The location and physical condition of facilities for equipment and personnel;
The IT skill level and experience of personnel, in both the IS department and in end-user
departments;
The extent to which the organization as a whole is committed to specific products or
suppliers for any hardware, software or services;
The extent to which the organization is committed to in-place technologies; and
Any ongoing or planned projects to change or upgrade any other applications or
technologies.
Page 71
A.5.10Analyze IT Infrastructure Requirements

Purpose
To Identify the target IT environments to be established for the DW project and to identify the
detailed requirements for the proposed DW production environment.
Overview
Multiple IT environments (e.g., development, staging or production environments) may be created
on a DW project. The approach followed in the methodology is to select the components of each
environment for development based on the needs of the respective environments and the ability
of the selected components to build towards the eventual production system.
A.5.11Identify the target IT environments.

Identify the target IT environments and their required components to be developed for the DW
project. The potential environments may include:
Technology Pilot environment;
Development environment (including unit test);
Prototype environment;
Staging environment (including system test or acceptance test environments);
Production environment; and
Training environment.
In general, the development, staging and production environments should be defined at a
minimum.
Review the deliverables from Phase A - Project Start-up and Phase B - Data Warehousing Project
Abstract to determine the requirements and timing for each environment.
Selected tasks in this phase may need to be completed for each of the different IT environments
to be developed. Some of the requirements, standards/strategies and IT decisions may apply to
multiple target environments while others may only be relevant to certain specific environments.
A.5.12Analyze the business issues that may impact upon the technology
infrastructure.
Determine business issues that may have an impact upon the technology infrastructure:
Identify categories of information and information access that are relevant to the overall
organizational DW program but are out of scope for this project.
This is a critical step in managing scope and user expectations for a DW project.
These information/data sources should be viewed with the understanding that they may be
integrated into the warehouse at a later time, and therefore, may add stress to the infrastructure.
Some examples of information sources may include: syndicated, public domain or other
corporate/internal information. Some examples of alternative categories of information access
may include: WWW/Internet, private networks or information sharing consortiums;
Determine the types of analytical/decision processes supported by the DW system
including:
performance measurement,
analysis and decision processes, or
quantitative analysis including data mining or profiling applications;
Page 72
Determine any complex or highly-sophisticated analytical processing requirements to be

supported by the DW system such as:
use of complex equations and statistical techniques,
requirements and value of data visualization techniques, or
requirements and value of intelligent agents;
Analyze functional requirements with respect to the technical infrastructure of the data
warehouse;
Analyze impact of any strategic imperatives such as:
impact of collaborative decision making,
impact of infrastructure centralization,
impact of decentralization of decision making,
impact of strategic partnership, merger or acquisition, and
impact of change integration/business process transformation;
Analyze impact of regulatory requirements; and
Analyze impact of competitive environment or major industry trends.
As the business environments evolves, the scope and complexity of the DW environments will
also change. Thus, the business environment should be assessed on a continuous basis to
determine the impact of any changes on the DW technology infrastructure.
A.5.13Analyze the management issues that may impact upon the

technology infrastructure.
Assess existing methods and procedures that will impact upon the DW IT infrastructure. This
provides input to the analysis and design of both the IT environments and the new methods and
procedures needed to support them. When considering IT infrastructure alternatives, include the
current methods and procedures in the current IT infrastructure profile.
Assess organizational issues that may hinder or facilitate the use of certain technologies, the
distribution of the environments and the management of the systems. Training of personnel in
specific technologies, management issues that determine the size of development efforts and
pre-existing team structures may affect the choice of technology. Identify issues that may suggest
a change in the centralization of the infrastructure.
Document any decisions, existing standards (e.g., supplier preferences) or agreements (e.g.,
lease agreements or contracts for supply) that the organization has already made. Determine
whether any of these decisions will present constraints or limitations on the new IT infrastructure.
Consider the costs or benefits that will result from these established decisions.
Document the amount of risk that the organization is willing to take with regard to new
technologies. New technologies may promise significant benefits to the organization but may also
present a greater risk. It is imperative to determine the organization's perception of an
"acceptable" amount of risk.
A.5.14Analyze the external factors that may impact upon the technology
infrastructure.
Analyze the external factors that may impact upon the technology infrastructure such as:
Regulatory factors that may influence the design of the technology infrastructure (e.g.,
financial reporting compliance, product development regulatory controls or privacy
considerations);
Industry standards that may have an impact on the design of the technology
infrastructure either currently or in the anticipated future, e.g., compliance with industryestablished data standards is important in conducting electronic data interchange (EDI)
or electronic commerce (EC) transactions with an organization's trading partners.
Page 73
With the increasing use of inter-enterprise systems (electronic partnering), the compliance with
industry standards in managing an organization's data resource (e.g., data definition) is becoming
an important business requirement;
Any potential or pending mergers or acquisitions and their impact on the design of the
technology infrastructure; and
Opportunities of selling the organization's data as a "product" (e.g., customer mailing list)
and their impact on the design of the technology infrastructure (e.g., privacy law
compliance, security issues, copyright issues, intellectual property issues).
A.5.15Analyze user base.

Analyze the characteristics of the user base in terms of:
Number of users by management level;
Roles of users in the organization;
Geographic locations of the users and number of users at each location; and
Types of analytical processing performed by user/location (e.g., EIS, DSS, data mining
applications, unstructured data access, ad hoc queries).
Determine the maturity/sophistication of the user base with activities such as:
Performance measurement analysis;
Quantitative decision analysis;
Business modeling and analysis;
Data mining applications; or
IT applications.
Estimate the growth rate of the user base.
A.5.16Analyze the technology infrastructure stress factors.

Analyze the impact of the technology infrastructure factors on the DW technology infrastructure
such as:
Expected life of technology infrastructure components;
Expected current or anticipated data characteristics of the DW environment such as:
data integration requirements (for both internal and external data),
data synchronization requirements (for both internal and external data),
data sources,
data granularity requirements,
data periodicity requirements,
data distribution requirements, and
frequency of data update, refresh and access;
Expected data volumes, frequencies and growth in terms of:
data storage volumes (for both live and archival data),
number of users,
number of modules to be created,
number and size of input transactions,
number and size of outputs, and
amount of stored data required for both system management software (such as
security, back-up/recovery, network management) and user applications;
Planned data access and sharing requirements. Determine the access that developers
and users will need to data and applications, both locally and remotely and the type of
information that will be accessed (i.e., whether the information is network-intensive traffic
such as multimedia or imaging). These access and data sharing requirements should
help determine access methods and communications needs such as LAN configuration,
Page 74
WAN or dial-up connections, line types, Internet/intranet connectivity and the system
distribution strategy;
Current and forecast geographic distribution requirements; and
Current and forecast network, Internet and intranet requirements.
As the technology factors evolve, the scope and complexity of the DW environments will change.
The above stress factors should be assessed on a continuous basis to determine their impact on
the DW technology infrastructure.
A.5.17Analyze business requirements driving the distribution of the IT

infrastructure.
Identify aspects of the business that require specific placement of hardware, processing or data
storage. Business aspects to consider include:
Pre-existing processing sites;
Logistics and distribution channels;
Availability of appropriately skilled personnel in certain areas;
Technological resource availability and levels in certain areas;
Tax considerations;
Security issues;
Disaster contingency/recovery issues;
Legal requirements; and
Distributed work force.
A.5.18Analyze IT infrastructure growth requirements.

Analyze the expected growth in processing, data and the user community of the DW system. The
expected growth must be considered in the design of the new IT infrastructure. Specifically,
enough capacity and scalability must be provided to ensure that the IT infrastructure effectively
supports the anticipated business requirements for the desired time horizon.
In the analysis of growth expectations, consider that the new systems or applications may affect
the organization's growth. e.g., if the system is supposed to improve productivity, existing growth
projections may be understated.
In the growth forecast, document expansion requirements and assumptions. Consider the
following areas:
Growth of the user base - number, locations and roles;
Business expansion - new ventures, products and services;
Business process transformation changes;
Future processing needs;
Expected lifetime of the system;
Expected data storage volumes; and
Expected change in geographic distribution and networking requirements.
A.5.19Determine back-up/recovery requirements.

Determine the frequency and type of back-ups required for system recovery.
Consider how much downtime is acceptable in the event of a system failure, the extent of
recovery that is necessary and what constitutes an acceptable loss, e.g., if the entire system goes
down, it may be imperative that every node of the network be recovered as of one week prior and
all data be recovered as of the previous night. In such cases, there will be a need for a weekly full
network back-up and a daily full data back-up. Back-up could be full (where all data is backed-
Page 75
up), partial (where only critical data is backed-up) or incremental (where only data that has been
affected since the last back-up is backed-up).
Consider the disaster planning back-up needs that are compatible with the organization's disaster
contingency approach (e.g., remote hot-site or cold-site facilities).
This information will impact upon the identification of back-up and recovery standards, strategies,
hardware and tools (e.g., it may be necessary to include disk mirroring in the configuration).
Determine the criteria, frequency and media for purging and archiving data.
A.5.20Determine security requirements.

Determine the requirements for access and data security. Business and legal issues may require
a certain level of security to be maintained by the IT infrastructure.
Page 76
A.5.21Develop BW Environment Landscape

The BW Environment Landscape is used at The firm by the Environment Management group and
the Technical Team's Environment Manager. They work together on changes needed for the
environment from the application standpoint and the technical infrastructure.
The Environment Landscape serves the following purpose:
Initially starts the discussions between the project team and the Technical Team over the
following:
Feasibility
Timing
Environment Planning (Servers, Disk Storage)
Shows the flow of environments from the start of the project to the implementing into a
production system
Additional tool which the project team can use to communicate to Management the scope of
the project
Multiple landscapes may be required for complex BW projects, detailing:
BW Environments
Web Technologies (ITS, Mysap.com, Cognos)
Multiple R/3 Environments
A.5.22Develop Environment Landscape

Include in the Landscape the following:
Document General Timeline
Environment Creates
Environment Upgrades
Environment Deletes
Document sources for the environment (i.e.. How will they be created?):
New Creation
Environment copy
Client Copy from Production -> Import to Development? (This would apply for R/3)
Upgrade?
Any Plug-in/Add-on required
Document dependencies on existing environments (include examples)
Extract from staging
What version of extractors, at what patch level will be required?
Version of the Software Highlighted
Basis (4.5a, 4.6...)
Version of the Component (BW 1.2B, 2.0A, 2.0B, 2.1C, 3.0A, 3.0B, 3.1C)
Document estimated sizing requirements when known
A.5.23Submit Landscape
Submit the Environmental Landscape for approval to the Environment Management group and
the Technical Team.
Page 77
A.5.24Design and Establish the Development Environment

Purpose
To create the environment that will support the design and construction of the target applications.
Overview
Three discrete environments are addressed - development, staging and production - in
technology infrastructure design. Many of the steps for each environment are the same; these
steps have been repeated in the methodology so that the steps for creating each environment
can be found in one place. However, the focus when performing these steps may differ from
environment to environment and this difference is reflected in the details of the steps.
Once operational, the development environment requires ongoing support and this must be in
place from the commencement of use of the environment. The scope of the development
environment includes the Business Blueprint and Realization Stages.
Isolation of Environments
It is important to maintain complete logical separation between the different environments. This
discipline is required to prevent applications from accessing resources that are only intended to
be present in a particular environment, e.g., if development resources are available in the test
environment, the possibility exists that the applications being tested may rely on some
development resource that may not be present in the production environment. This invalidates
the testing and could lead to application failures during production. The process of migrating
applications from one environment to another is easier to control when there is some physical
separation of the environments and when applications are moved between them using formal
change control techniques. This may be achieved by using physically separate platforms or
security mechanisms that enforce separation on a single platform.
Risk Factors
Differences between the development environment and the test environment shift the risk
associated with different components into the testing phase. For example, if a particular
infrastructure component or application is simulated, problems relating to the component or
service may not be discovered until they are migrated to the test environment. Project managers
must decide which components will be implemented in the development environment and which
components will be introduced in the test environment. Implementing components in the
development environment will provide more time to overcome or compensate for the challenges
inherent with new technologies. This risk can be mitigated to an extent by adding a string test
step which follows unit test and precedes system test.
A.5.25Analyze development environment requirements

Estimate development platform capacity requirements, in terms of the amount of processing
power, memory and storage required for each development platform, based on inputs such as the
number of users, the number of modules being created and the amount of development data.
Determine what data and files will need to be shared among developers. This requirement
impacts the need for network connections and access and the number, configuration and
connectivity of common file servers and databases.
Determine the development network needs:
Determine type of network traffic. Determine whether network-intensive applications (e.g.,
multimedia, imaging or large file transfers) will operate over the network during
Page 78
application development. This type of network traffic can increase the network bandwidth
requirements during the development effort;
Estimate volume of network traffic. Using inputs such as type and frequency of network
traffic and the number of users, estimate the volume requirements for network traffic. This
information is a key input into the selection of networking technology and capacity for the
development environment;
Determine developer access requirements. Determine what access developers will need
to data and applications, both locally and remotely. If remote access is needed, access
methods must be provided such as WAN connections or dial-up access. Local access
requirements will help to determine LAN configuration and may affect platform and
environment decisions;
A.5.26Estimate BW data volume

Purpose
The purpose of this task is to develop specific sizing proposals for your initial BW hardware, with
assistance from your hardware partner.
Procedure
Do initial hardware sizing separately for the development system and the technical
experimentation system
Determine how many applications go live at the same time
Determine the requirements for backup, recovery, and reset of the development system
Consider the following:
What hardware platform will you use later for quality assurance, and for your
production system?
What language and time zone dependencies do you need to consider on the
development system?
What software development projects of your own do intend to carry out in the future?
What enhancements do you plan to make to the standard BW system?
What development system growth do you expect?
Technical experimentation system:
What system platform will you use later for quality assurance, and for your production
system?
What time window do you expect for system recovery in the future?
What time window will you allow for a data backup in the future?
How will you organize data backup in the BW system in future?
What BW interfaces will you have to use or administer in the future?
Desktop Level:
Standard PCs available, allowing for future network requirements and office products
Applications Server Level:
Memory sizing, reflecting BW sizing model
Disk distribution on the application server
Scalability of the application server (memory, CPU, disk space)
Database Server Level:
Database disk distribution
Growth path for the database server
Delivery lead times for additional disks, backup media, and similar
Scalability of the database server (memory, CPU, disk space)
Possible migration paths to more powerful database servers from the same hardware
vendor
Page 79
A.5.27Define Software Environment

Purpose
The purpose of this task is to define the BW software environment and to formulate a plan for any
necessary installation of application software to comply with the target release of the BW system.
This plan could include the following:
Interfaces
Legacy systems
Applications external to R/3
You should take into account that considerable amounts of resources and time may be required
to accomplish this task.
Procedure
Determine the start and target configuration for each of the necessary software profiles
Once these tasks have been established, the information can be channeled into the flowchart
available in the installation manual, to determine at which point during the process the
software should be installed.
All the systems throughout the BW environment are on supported and fully functional software
profiles. Early planning enables the scheduling of the non-BW software installs to be performed at
the most suitable point in the BW installation timetable.
A.5.28Order Hardware
Purpose
The purpose of this task is to place the initial hardware order with the appropriate vendor,
determine the expected delivery date of the hardware, and to determine the expected lead-time
needed to procure the productive system hardware. Also, order any additional dependent
hardware required for the development.
Procedure
On the basis of the internal project Service Level Agreements, and subject to the external
hardware partner Service Level Agreements, place the purchase order for the initial BW
development system hardware.
Inform the project steering committee
Where required by the internal service level description, the other project leaders and the project
steering committee should be kept informed of the status of the BW system installation.
A.5.29Order Software
Purpose
The purpose of this task is to place the initial software order with the appropriate vendor,
determine the expected delivery date of the software, and to determine the expected lead-time
needed to procure the productive system software. Also, order any additional dependent software
required for the development.
Page 80
Procedure
software partner Service Level Agreements, place the purchase order for the initial BW
development system software.
A.5.30Order Network Facilities

Purpose
The purpose of this task is to order and install the network connection to the BW system
environment.
Procedure
Decide on a network provider to establish the physical network connection to the BW system
environment
Configure your online connection to the BW system environment
Check the necessary security aspects for the BW system environment
Implement network connection access
A.5.31Install Development Environment

Refer to Task E8 Install and Configure Technology Components for a summary of the steps
involved in installing the Development Environment.
Page 81
A.5.32Design and Establish the Staging Environment

Purpose
To design an environment that will support the systems, integration and user acceptance testing
of the target applications and infrastructure systems.
Overview
After each application software module is unit tested in the development environment, it moves
into the staging environment for the other remaining tests. The construction of the test
environment requires the selection and integration of hardware, network services and tools to
simulate the production environment. The necessary environment may include special products
to test particular features of the applications to be developed. Once it is determined how to meet
testing-support requirements, a testing strategy must be devised. This strategy includes the use
of specific testing tools and the definition of procedures as well as the locations and
communications requirements of test team members.
The overall objective of the staging environment is to closely simulate the production
environment, so as to accurately test the functionality and interactions of all applications,
technology components and operations tools and procedures.
It is important to maintain complete logical separation between the different environments. The
staging environment should be isolated from the development environment so that development
resources are not available in the test environment. For instance, if the development resources
are available in the test environment, the test may be invalidated because the applications may
rely on some development resource (e.g., a particular configuration, a different code library or
development data) that may not be present in the production environment. The process of
migrating applications from the development environment to the staging environment is much
easier to control when there is a physical separation between the environments.
The isolation of the staging environment from the production environment also offers migration
safeguards. Test resources should not be available in the production environment and migration
between the test and production environments must be tightly controlled. This control is most
easily implemented with a distinct division between environments.
It should be noted that the specific tests performed in the development versus the staging
environment may vary from project to project, e.g., a string or component test may be executed in
the development environment following the unit test to ensure that the entire business unit is
tested.
A.5.33Analyze staging environment requirements

Analyze staging environment requirements as follows:
Determine the number of testers, required skill sets and their physical locations. This information
will impact upon the configuration of the test team workstations and the test network topology.
Determine data sharing requirements. Determine what data and files will need to be shared
among the test team. This requirement impacts the need for network connections and access and
the number, configuration and connectivity of common file servers and databases.
Determine the network requirements for testing:
Page 82
Determine type of network traffic. Determine whether network-intensive traffic (e.g.,

multimedia, imaging or large data file transfers) will be sent over the network during the
testing effort which can significantly increase the network bandwidth requirements;
Estimate volume of network traffic. Using inputs such as type and frequency of network
traffic and the number of users, estimate the volume of network traffic during the testing
effort. This information is a key input into the selection of network technology for the
staging environment;
Determine tester/developer access requirements. Determine what access testers will
need to data and applications, both locally and remotely. If remote access is needed,
access methods must be provided such as WAN connections or dial-up access. Local
access requirements will help to determine the LAN configuration and may affect platform
and environment decisions; and
Determine the platforms and network protocols that must be accessible from end-user
machines. It is significantly more difficult to configure an end-user machine to use
multiple network protocols simultaneously and to access different platforms than it is to
configure for a single protocol and platform.
Determine test team, user and support personnel remote access requirements.
Determine security requirements.
Determine the necessary security for the testing effort. This may require the installation of security
software which was not needed in the development environment as well as the instigation of
security profile management. Determine who will have access to the staging environment and the
responsibility for maintaining the security of the staging environment. Members of the test teams
may also require education in the use of the security system.
Obtain formal written approval of the staging environment requirements.

Purpose
The purpose of this task is to develop specific sizing proposals for your initial BW hardware, with
assistance from your hardware partner.
Procedure
Do initial hardware sizing for the staging environment

Determine how many applications go live at the same time
Determine the requirements for backup, recovery, and reset of the test system
Desktop Level:
Standard PCs available, allowing for future network requirements and office products
Applications Server Level:
Disk distribution on the application server
Scalability of the application server (memory, CPU, disk space)
Database Server Level:
Database disk distribution
Growth path for the database server
Delivery lead times for additional disks, backup media, and similar
Scalability of the database server (memory, CPU, disk space)
Possible migration paths to more powerful database servers from the same hardware
vendor
Page 83

Purpose
The purpose of this task is to define the BW software environment and to formulate a plan for any
necessary installation of application software to comply with the target release of the BW system.
Interfaces
Legacy systems
Procedure
Purpose
Procedure
Purpose
Page 84
Procedure

Purpose
environment.
Procedure
environment
A.5.39Install Staging environment

involved in installing the Staging environment.
A.5.40Set Up User Master Records

Purpose
The purpose of this task is to create user master records for project team members with the
authorization profiles necessary for the Staging Environment. These profiles must be created in
the SAP master Client to propagate them to other clients, or they may have been transported
from the development environment. The project team must be permitted to perform business
application functions in the development environment Customizing client (DEV), but a restricted
subset of this activities should only be allowed in the Staging Environment (SAS). This ensures
the team can model business processes in your BW (DEV) System without restriction, and also
has access to check their environment as it gets transported into the Staging Environment (SAS).
Procedure
In order to complete this task you must do the following:
When the Development (DEV) system is first installed, Configurators/customizers,
Developers, System Administrators, recent trainees, and other project members comprise the
bulk of the BW users most of this users will need access to the Staging Environment also,
however the access to this system should be a subset of the Development System since
changes most take place in the Development system (with very few exceptions).
Most users in a newly installed BW system begin with the SAP_ALL authorization profile in
their user master record. This profile allows a user to perform all tasks in an BW system. As
the BW project progresses, the need to limit user access increases. In general, users in the
DEV system have more access than users in the Test (QAS) or Production (PRD) system.
Page 85
At this time, the Security Administrator should know the BW Authorization Concept. Initially,
we recommend creating a new profile, modeled after the profiles in the Development
environment.
Please refer to "The SAP BW Authorization made Easy Guidebook, Chapter 7 Special Cases,
Setting Up Authorization Profile. Assign the activity group to all non-super users in the QAS
system and update their user master records as described in Chapter 8: Assigning Activity
Groups and Authorization Profiles to Users.
A.5.41Secure Staging Environment

Purpose
The purpose of this task is to determine if it is necessary for the functional project team to access
the operating system and database. Analyze the types of reports, interfaces, data feeds, and
customizing that is projected. Determine from this the reports and interfaces requiring operating
system and database access, and at what level. Create operating system and database level
access for project team members. Provide security to ensure the integrity of the SAP technical
environment and data. Determine a procedure for requesting operating system and database
access for the staging environment. Provide and ensure security for the BW operating system
and database users. Access to these users must only be given to key members of the technical
project team.
Procedure
Create Operating System and Database Level Access for Project Team Members
Analyze the types of reports, interfaces, data feeds, and customizing that is projected.
Determine from this the reports and interfaces requiring operating system and database
access, and at what level. Provide security to ensure the integrity of the BW technical
environment and data.
Provide and Ensure Security for the BW Operating System and Database Users
Access to these users must only be given to key members of the technical project team.
Change the password, and provide security for the following users:
SAP users: SAP* and DDIC
Operating system users: <SID>adm, ora<SID>, pctemu
Database users: sapr3
Determine a Procedure for Requesting Operating System and Database Access for the
Development System
Access to the operating system and database in the project must only be permitted after
running the checks in step one above. Changes to access rights of project members must be
documented.
A.5.42Set Up Printing Services

Purpose
The purpose of this task is to use the technical infrastructure design document to determine the
type of printers used by the technical project team. Verify that each printer is installed and
accessible by the local PC client or the operating system of the development system. Install,
configure, and test printing services for each printer.
Page 86
A.5.43Set Up Client Management and Transport System

Purpose
The purpose of this task is to install and configure development system clients. See the
documentation on the BW client structure, and the roles of each client system in a BW
implementation. During this activity you must define client management. Set up client
management for the functions of your clients. Consider Automatic Transport, Client Roles, and
Cross-Client maintenance.
Procedure
Install and Configure Development System Clients.

Configure Workbench Organizer.
Change Country Specific Settings.
Initial Test of Transport System.
Page 87
A.5.44Design and Establish the Production Environment

Purpose
To create the production environment that will support the target applications.
Overview
The production environment requires that the platform components and supporting services be
integrated to form a complete system in support of the business applications. However, because
of changes made during development and testing, some changes in supplier and product
selection may be necessary.
Operations and management is the area of greatest complexity. Although all of the operations
and management tools and procedures have been tested during the system and integration tests,
they must now be deployed and formal responsibility taken for them.
It is important to maintain complete logical separation between the different environments to
prevent applications from accessing resources that are only intended to be present in a particular
environment, e.g., if development resources are available in the staging environment, the
applications may rely on some development resource (e.g., a particular configuration, a different
code library or development data) that may not be present in the production environment. This
would invalidate the testing and could lead to application failures during production. Maintaining
integrity of the environments insures that the applications will still function even if the environment
is completely rebuilt and the applications reloaded. The process of migrating applications from
one environment to another is easier to control when there is physical separation of the
environments and applications are moved between them using formal change control techniques.
This may be achieved by using physically separate platforms or security mechanisms that
enforce separation on a single platform.
Timing
The creation of the production environment begins concurrently with the construction of the
staging environment. Implementation of the environments, however, is staggered so that the
staging environment begins before the production environment. How much earlier the
construction starts will depend upon such items as the project timeline, lead times for purchasing
components, set-up times and training for operations personnel.
A.5.45Confirm and refine production environment requirements.

Confirm and refine network requirements. The volumes and types of traffic on the network
determine the choice of network and the necessary hardware and software to maintain the
required traffic flow. Local and remote access points for the network must be determined to
properly set-up the various hardware components that route and process network
communications. The type and placement of particular network components (such as hubs and
routers) are determined at this time.
Confirm and refine remote access requirements. Users and support personnel may require
access to the system. Determine the needs and evaluate the impact on system performance and
security.
Confirm and refine printing requirements. The speed, volume and print quality of the output of the
applications will determine the choice of printers for the environment. Fast, high-quality printers
such as high-speed laser printers may be necessary for reports. Slow, medium-quality printers
Page 88
such as ink jet printers, may be adequate for administrative needs. There may also be special
printer requirements such as for special stationery, remote printing or special fonts.
Confirm and refine client machine requirements. Confirm and refine the processor, memory and
storage requirements for the client machines.
Confirm and refine application server requirements. Confirm and refine the processor, memory
and storage requirements for all of the different types of application servers.
Confirm and refine database server requirements. Confirm and refine the processor, memory and
storage requirements for the database servers.
Refine production operations and management roles and responsibilities.
Confirm and refine configuration management/change control requirements.
Consider the difficulty of managing the configurations of production hardware, software and
network devices. Large or distributed production environments complicate the task of managing
configurations and may require more sophisticated tools and/or processes. Remote configuration
management allows the system administrator to update desktop configurations and software
electronically from a central or remote location and to accelerate the testing and deployment of
updated components.

Purpose
The purpose of this task is to develop specific sizing proposals for the production environment,
with assistance from your hardware partner.

Purpose
The purpose of this task is to define the BW software environment required for the Production
system.
Interfaces
Legacy systems
Procedure
Page 89
Purpose
Procedure
Purpose
Procedure

Purpose
environment.
Procedure
environment
Page 90
A.5.51Install Production environment

involved in installing the Staging environment.
A.5.52Secure Operating System and Database

Purpose
The purpose of this task is to determine operating system and database security for users. Create
operating system and database level access for users. Provide security to ensure the integrity of
the BW SAP technical environment and data. Define a procedure for requesting operating system
and database access for the production system. Provide and ensure security for BW SAP
operating system and database users. Access for these users must only be given to key
members of the technical project team.
Procedure
Implement appropriate operating system and database level access security

Analyze the types of reports, interfaces, data feeds, that is projected. Determine from this the
reports and interfaces requiring operating system and database access, and at what level.
Provide sufficient security to insure the integrity of the BW SAP system.
Provide and insure proper security around the BW SAP operating system and database users
Change the password and provide security for the following users:
BW SAP users: SAP* and DDIC
BW Operating system users: <SID>adm, ora<SID>, pctemu
BW Database users
Determine an ongoing procedure for requesting operating system and database access for
the development system
Additional access to the operating system and database in production should be restricted to
exceptional cases. Every change of the access rights owned by the project members has to
be well documented.
Page 91
A.5.53Install and Configure Technology Components

Purpose
To install the different environments necessary to support the entire DW system development
effort.
Overview
The steps in this task will be repeated for each of the different IT environments to be created.
Depending upon the complexity of the different environments, this task may be extremely
complex taking months to complete and much effort to accomplish. Alternatively, it may be
accomplished in one day by one person. Regardless of the size of the effort, it is important to
approach the task in a structured manner to reduce rework and to ensure a high quality
installation.
A.5.54Coordinate with network and communications personnel.

Meet with network and communications personnel to determine the extent of support to be
provided as well as to identify any existing configuration standards that must be adhered to.
Standards may include:
Node naming conventions; and
Server naming and configuration conventions.
A.5.55Install Initial Hardware

Purpose
The purpose of this task is to engage the services of the hardware vendor to install the
appropriate hardware, install any additional dependent hardware defined during identification of
BW technical requirements (for example, printers, additional servers, network devices, routers),
and connect the hardware to the existing network. It is important to request that the hardware
vendor perform appropriate post-installation hardware exercises (for example, verify tape device,
verify disk devices).
A.5.56Install Operating System on Business Information Warehouse Server

Purpose
The purpose of this activity is to demonstrate the installation of Operating System on Business
Warehouse Server.
Procedure
Check the Installation Requirements

Adapt UNIX Kernel Parameters and Swap Space
Choose an R/3 System Name
Setup File Systems and Raw Devices
Create and Mount the Transport Directory
Setup and Installation Directory
Page 92
A.5.57Install Business Information Warehouse Software

Purpose
The purpose of this activity is to demonstrate the installation of Business Information Warehouse
Software.
Procedure
SAP License
SAPOSCOL for AIX
Performance increase by Shared Memory Pools
Delete Temporary Files
Change Permissions of the Transport Directory
Install Additional SDKs
Install the BW Front End
Starting and Stopping the R/3 System
Logging on to the R/3 System
Install the Online Documentation
Post-Installation Steps Described in the Online Documentation
Installation Backup
SAProuter
Online Service System (OSS)
Import Hot Packages after the installation
A.5.58Install Business Information Warehouse Add-on on OLTP System

Purpose
The purpose of this activity is to define Business Information Warehouse Add-on OLTP System
document. When install BW, there are the extractors on the R/3 side and in the BW. These
extraction programs will be installed on an R/3 development box.
An integrated R/3 and BW environment consists of a BW instance and a R/3 instance with BW
Extractor. The purpose of this activity is to define the process of installing Business Information
Warehouse Extractor Add-on to the R/3 OLTP System.
Procedure
Preparation
Review OSS notes.
Create an installation directory.
Manual checks
Installation
Run startup
Monitoring the installation
Final Steps
Please refer to "R/3 add-on-installation and delta upgrade guide" for detailed steps.
A.5.59Establish ALE System Connectivity

Purpose
The purpose of this activity is to establish ALE system connectivity.
Page 93
Procedure
To set up the link from BW to Source System:
Go To Source System Screen -> Create R/3 Source System manually or automatically
Specify the Target Source (Source System)
Execute IMG: Bring the user to Source system IMG
To set up the link from Source System to BW
IMG at Source System -> Cross Application Components -> ALE Basic Configuration -> Set
Up Logical System ->
Maintain Logical System: Create BW Logical System
Allocate Logical System to the Client: Set Up the Source System
Transaction Code: SM59 ->
R/3 Connection
RFC Destination: Identify BW System
Target Machine: Identify application server
Test Connection
A.5.60Install Desktop Components

Purpose
The purpose of this task is to use the Installing BW Front-end Software for PCs guide to install
and test client software. This task specifically addresses the installation and configuration of the
BW OLAP Business Explorer software component. The Business Explorer allows users to display
existing reports, create new BW reports, or modify existing BW reports.
The software component utilizes Microsoft Excel to access and view BW reports.
Procedure
Install the required desktop components on a PC configured to meet the SAP BW PC

standard. The required PC components are shipped with the installation package.
Determine a flexible initial installation procedure.
In parallel, review the Help Desk procedure you defined in the Determine System Problems
and Error Handling task. If necessary, train the Help Desk staff.
A.5.61Install Additional Components

Purpose
The purpose of this task is to ensure that there is a proper hardware and software configuration
for each user. Verify the user can perform the activities with the hardware. Configure and install
the front-end hardware for the user. Install and configure the SAP GUI on each client.
Test the SAP GUI capabilities for each clients configurations. Tests include:
SAP interactive graphics
Integration of MS Office products (MS Office 97 is required to ensure that the right
version of MS Excel is installed on the PC Desktop, otherwise the BW Business Explorer
component will not work)
Coexistence with external client software
Procedure
Review the defined standard PC for the BW System for:

Availability
Maintenance availability, maintenance procedure, and upgrade procedure
Components required
Page 94
Review or define normal cases to apply for the following:

The system for ordering or reporting the initial installation of an BW desktop work center
Agreed maintenance procedures required by service agreements in the project for Define
Desktop Management Strategy and Establish Service Level Commitment
Purchase order procedure for the standard BW PC
Page 95
A.5.62Submit Technology Design Deliverable

Purpose
To assemble and submit the Technology Design deliverable for management review and
approval.
Overview
The findings and issues from this phase are assembled into the Technology Design deliverable
for presentation to management for review and approval.
A.5.63Assemble and review the Technology Design deliverable.

Package the work products from this phase into a deliverable document to include:
The Technology Infrastructure Alternatives;
The results of the evaluation process and any relevant supporting documentation;
The specification of the selected technology design;
Selected primary suppliers (if applicable); and
Technology Pilot results (if applicable).
A.5.64Submit the Technology Design deliverable to management for

approval.
Submit the Technology Design deliverable to management or the steering committee. Discuss the
key findings of the significant sections and resolve any questions or issues. This may take more
than one meeting.
Obtain formal written approval of the Technology Design deliverable.
Weighted Ranking Assessment
A technique that could be used for assessing products and services is Weighted Ranking
Assessment (WRA) which requires "weights" to be assigned to each requirement based on its
significance. The requirements are then "scored" by measuring the degree of compliance to a
standard. Establishing a WRA evaluation process consists of the following basic steps:
Assign appropriate weightings to each of the requirements to reflect its relative importance. An
example of such a weighting is:
Weights Requirement
10
Mandatory
5
Highly desirable
1
Desirable
Define the scoring system to be used to assess each requirement. For example: allocating the
scores ranging from zero at the low end (i.e., feature does not exist/requirement not met) to five
at the high end (i.e., requirement fully met/exceeded), or using a scale such as:
Point Level
5
Exceeds
4
Fully meets
3
Partly meets
1
Ineffective
0
Does not have
Page 96
The most important part of the scoring process is that consistency is applied when the evaluation
process is completed. Validate the weights and score system.
Page 97
A.5.65Support Technology Environments

Purpose
To ensure that a stable environment is available at all times and, in the event of system problems,
to minimize any down time.
Overview
The steps in this task will be repeated for each of the different IT environments to be created.
Providing technical support for the different environments is an ongoing process and includes all
members of the project team, e.g., developers should be discouraged from modifying their
workstation configurations. Maintenance should also be proactive. Any changes or upgrades
should be tested thoroughly before deployment.
A.5.66Establish Help Desk procedures.

Regardless of the size of the development team and accompanying environment, each project
should have established procedures for reporting problems and resolving hardware and software
issues. These procedures may include establishing a formal Help Desk facility but, at minimum,
should identify technical support personnel responsible for specific support issues. Support
issues may include:
Development tool problem reports;
Hardware failures;
Software problems;
Network errors;
Poor performance; or
Application support.
Establish the Help Desk procedures.
A.5.67Establish back-up/archive procedures.

Establish back-up, recovery and restore procedures.
Although there are a number of back-up rotation alternatives, the primary objective is to identify
what data needs to be backed-up and procedures put in place. The frequency of back-ups must
also be determined. On a large project in the middle of design and construction, nightly back-ups
may not be sufficient as the loss of one day's work in the event of a hardware failure could
represent hundreds of lost hours. Accordingly, consideration needs to be given to on-line back-up
procedures and technologies as appropriate.
Page 98
A.5.68Planning for Production Cutover

Purpose
To coordinate with the Production Support team in order to ensure a smooth transition upon
achieving a production state for the system. The process of integrating with Production Support
should begin as early as possible. The planning should include any personnel considerations
(availability, training, adequate coverage) along with infrastructure issues (problem tracking
system in place, appropriate procedures, etc.).
Tasks
Determine Production Support Plan

Determine Cutover Plan
A.5.69Coordinate with the Production Support Team

Project communications with the Production Support Team Leads ideally should begin during the
Project Start-Up stage, or as soon thereafter as possible. Throwing support over the fence can
result in unpleasant experiences for your users as they begin using the production system.
As the project progresses through the Business Blueprint and Realization stages, ongoing
communications with Production Support should be maintained. Engaging part of the support
team as testers after the system and integration tests can help their training efforts, along with
providing more real-world testing conditions for the system.
A strategy for providing support should also be determined. In some cases, power-users or
functional analysts will provide the first level of support, particularly for business-related issues.
The Production Support Team can be called upon for assistance with technical issues, and basic
BW-related questions and issues (Level 1 Support). Problems requiring advanced knowledge of
the warehouse or BW should be referred to a Level 2 Support team, which can typically be
comprised of the implementation project team members.
A.5.70Determine Cutover Plan

Purpose
The purpose of this task is to plan system cutover activities in the appropriate sequence to ensure
preparatory steps are complete and that the right people are available when required. The
Cutover Plan covers activities for setting up and initializing the production environment. The plan
must cover application data, such as, master data, transaction data, and customizing and
repository objects.
Procedure
Create Cutover Plan

Prepare a plan for migrating the system and organization to a production system. The plan is
called a Cutover Plan.
The Cutover Plan focuses on the activities, tasks, and timing of the final days of effort. The
main benefit is a plan to ensure a smooth transition to production. Referring to this plan if
difficulties arise can serve as a guide to action when issues arise. The Cutover Plan includes
a checklist that reviews points of readiness, and provides the basis for approval to progress.
Page 99
The Cutover Plan schedule and timing must cover the procedures to close legacy systems
and entering data in the new system. Consider operations in other time zones. The
production system can start at a time earlier than 8 AM Monday morning.
The plan must include:
Data conversion estimates of the types of data, and how long the process can take
Timing of when the conversions are performed
Team leaders for the cutover
Roles and responsibilities of the core project team, power users, users, and so on
Team assignments and working hours
Company management involvement and decision-making designates
Procedures for shutting down legacy systems
Reconciliation procedures to ensure business transactions are cut off in the legacy
systems
Source Management Database (SMDB) Setup to handle Problem Reports and Product
Lines & Billing
Security
Periodic Processing
Tech Support
Environment Management
CAB Process
Reconciliation procedures to ensure data is converted to the new system
The written Cutover Plan must be reviewed and approved by the Project Manager, core
project team leaders, and key company senior management. The plan must be presented in
summary form to the Steering Committee.
Create a Final Checklist

This final checklist reviews points of readiness and provides the signal to progress.
Create a Contingency Plan

The Cutover Plan must include a contingency plan for delays. The contingency plan must
address how long (in hours or days) the new production system cutover can progress but be
stopped, and legacy systems restored. It is standard practice to have a point of no return for
making the new system operative. After a few hours or days, it may not be possible to convert
the business operations back to the legacy system. However, it is important to consider this
option.
Determine Conversion Timing and Schedule

Determine the timing and schedule of the final data transfer (conversion). Estimate how long
it can take for each type of conversion (master data and transaction data) including executing
the data conversion programs, and time for manual data conversion. When must the data be
backed up? Determine who reconciles the data and when. Determine how much time is
required to rerun programs if programs abort. Can programs be restarted only from the
beginning?
Test Operation of the New System

The final stage of the conversion process and system readiness check is to test the operation
of the production system, ensure that transactions are working, and users have appropriate
system access. This can be done through display transactions and reports, or live
transactions.
Page 100
The Cutover Plan can provide for an initial start up of the new system before most users sign
on. For example, a Power User can enter the first transactions to ensure that everything is
operating as designed.
Page 101
A.6
Project Preparation Checkpoint
Purpose
To confirm the results of the Project Preparation Stage of the DW project with management.
Additionally, in this Phase, the CPDEP Phase 1 task of Identify and Assess Opportunities is
completed, and a recommendation and Class 1 Estimate provided for the DRB/GRT.
Overview
Throughout all of the stages of the DW life cycle, there is a need to monitor and report project
status, to identify and address scope issues and to conduct appropriate Quality Management
Reviews.
However, at specific points in the life cycle, additional tasks will have to be completed. One of
these points is the completion of the Project Preparation Stage and these additional tasks are
described in the Project Preparation Checkpoint Phase.
The primary objective of this phase is to check progress against the Project Charter and to
update the plan to reflect the start of a new stage.
Charter occurs and this is the main focus of the checkpoints.
In the Project Preparation Checkpoint, many of the items fall into the first category. Items such as
project background, change and issue resolution procedures and project organization will
generally change little on transition from Project Preparation to the Business Blueprint.
Revisions may be needed to the project work plan and the detailed work plans, the risk
assessment needs to be reviewed to reflect changed risks in construction, the baseline for the
project will change from the Project Preparation Stage to the Business Blueprint Stage
deliverables and estimates should be reviewed to reflect this.
Page 102
Project Preparation Checkpoint Task Relationships
D a ta w a r e h o u s in g p r o je c t a b s t r a c t
F1
C o n fir m C o m p le te n e s s
o f th e P r o je c t
P re p a r a tio n S ta g e
C o n f ir m e d P r o je c t P r e p a r a t io n S t a g e D e liv e r a b le s
O p e n Is s u e s
F2
R e v ie w I s s u e s
P r o je c t p la n s
F3
U p d a t e P r o je c t P la n s
U p d a te d p r o je c t p la n s
Q u a lit y P la n
F4
U p d a t e Q u a lit y P la n
U p d a te d Q u a lit y P la n
F5
O b t a in A p p r o v a l o f
P r o je c t P r e p a r a tio n
S ta g e D e liv e r a b le s
P r o je c t P r e p a r a t io n S t a g e D e liv e r a b le s
F o r m a l A p p r o v a l P o in t
Page 103
Is s u e r e s o lu tio n s
A.6.1 Confirm Completeness of the Project Preparation Stage

Purpose
To complete an integrity check of the Project Preparation Stage deliverables.
Overview
The data, process and technology definition work products developed during the Project
Preparation Stage are discussed with management. The focus is on confirming the completeness
of the results and findings and determining their impact on the project.
A.6.2 Confirm the completeness of the data, process and technology

abstracts with management.
Discuss and confirm with management the completeness and accuracy of the data, process and
technology abstracts.
Resolve the issues as possible and document any outstanding issues to be addressed by the
Issue Resolution Process.
Determine the impact of the findings or issues on the project. If a project scope change is
needed, obtain formal written approval of the change from management.
Page 104
A.6.3 Review Issues

Purpose
To identify all outstanding issues and either resolve or agree future actions.
Overview
All issues must be reviewed and appropriate action agreed/taken.
A.6.4 Review and resolve any outstanding issues.

Review all open issues contained in the Issue Resolution Log. Identify possible resolutions and
initiate appropriate corrective action.
For any issues that will not be resolved immediately, an approach describing how these will be
resolved should be developed and agreed.
Ideally, no issues should remain outstanding at the end of the Project Preparation Stage. In
practice, not all issues will need to be fully resolved before progressing to the Business Blueprint
Stage. The decision on the importance of resolving an issue should be made by the project
manager in conjunction with senior management.
Assess the impact of any outstanding issues and reflect in the plans and risk assessment for the
next stage.
A.6.5 Agree approach to outstanding issues.

Document on the Issue Resolution Form or cross-reference to the Issue Resolution Form, an
agreed approach to resolving all outstanding issues.
Ensure that procedures for investigating outstanding issues are fully understood by both
developers and system users. The cost of investigating outstanding issues may need to be split
between both parties, e.g., if after investigating an issue, it turns out to be an expansion of scope
or an error in information provided by the user, the cost of the investigation as well as the
resolution of the error should be borne largely by the system users.
Page 105
A.6.6 Update Project Plans

Purpose
To update the project plans based on the findings and information obtained during the Project
Preparation Stage.
Overview
This task updates the project plans to reflect the impact of the findings obtained in the Project
Preparation Stage.
A.6.7 Develop plans for the Business Blueprint Stage.

Develop plans for the Business Blueprint Stage considering the understanding, findings and
issues relating to the DW project gathered during the Project Preparation Stage.
The Business Blueprint Stage consists of the following main phases:
Analysis and Decision Process Definitions;
Analytical Processing Data Definition;
Technology Planning, Support and Cutover (begun or continued);
Data Transformation System Design;
Presentation System Design; and
Data Design.
In addition, update the project plans for the following Cross-Life Cycle Phases as appropriate:
User Documentation;
Training;
Acceptance Testing;
Change Integration;
Prototyping; and
Technology Planning, Support and Cutover.
A.6.8 Consolidate plans into the project work plan.

Ensure that all plans are included in the project work plan that combines all tasks, dependencies
and milestones for the remaining stages of the project.
A.6.9 Revise estimates in light of previous experience.

Review the original estimates for the Business Blueprint Stage which were made based on the
best knowledge at the time. Experience gained during execution of the Project Preparation Stage
may indicate variances from these original estimates that will need to be reflected in the
estimates for the next stages.
Consider experiences on similar projects and on any prior design work that might already have
been undertaken on this project to date and use to validate the estimates.
A.6.10Produce detailed work plans for the Business Blueprint Stage.

Develop detailed work plans for the Business Blueprint Stage. Use the plans currently contained
in the project work plan and the revised estimates, taking into account the available staff and
skills.
Identify the tasks needed to complete these stages. The standard tasks may, however, need
some tailoring for the particular project. For each task estimate:
Page 106
Number of project staff;

Amount of time each person is allocated to a task;
Duration and scheduled completion of each task;
The estimates should include the amount of time and effort required from the users.
Any changes to the project work plan necessitated by resource or other constraints should be
reflected accordingly.
A.6.11Validate overall project cost and time estimate.

Develop final cost and timing plans, based on the detailed work plans. For each subsequent
phase, prepare a high-level estimate including:
Staffing resources by skill level;
Amount of time estimated to complete a phase;
Scheduling;
Some of the data needed to prepare an estimate may not be available. For these situations,
determine and document the assumptions used to prepare the estimates.
Compare the final cost and timing plans with the originally agreed figures, review any
discrepancies and take appropriate action. This may include:
A negotiated reduction in scope based on changed costs;
Re-phasing of the work to ensure that time scales are met;
Revisiting the original scope to see if scope has changed over the lifetime of the project;
Agreeing a revised cost of the project;
Increasing the staff complement in an attempt to reduce time scales at increased cost; or
Reducing the staff complement to reduce cost but increase time scales.
Seek formal written approval for any actions to be taken and revise plans accordingly.
Page 107
A.6.12Update Project Charter

Purpose
To ensure that all aspects of planning and quality have been properly addressed.
Overview
To this point, the Project Preparation Checkpoint Phase has largely been concerned with work
planning. Many issues are addressed in the Project Charter that go hand-in-hand with the work
plans. These are reviewed and appropriate amendments made to reflect the end of this stage and
the start of the next.
Those sections of the Project Charter that need to be updated for design are reviewed and
amended or created, as appropriate. In particular, the Project Risk Assessment needs to be
revisited.
A.6.13Review and revise Project Risk Assessment.

Review the Project Risk Assessment documentation that has been maintained throughout the
project as a result of the Project Preparation Stage experience and the updated project plans for
the Business Blueprint Stage. Consider:
How has the anticipated project commitment been in practice?

How has the anticipated commitment and quality of third parties been in practice?
How has the scope changed and why did this occur?
Have the volumes and anticipated performance levels changed significantly?
Has the user base changed significantly?
Are the resources needed still available?
Is the experience and knowledge of available resources as anticipated?
Has information about the business and the technology been learned that was unknown
before?
Has the anticipated processing changed significantly and does this affect previous
assumptions?
Have budget and time considerations changed (e.g., by project overrun)?
To what extent have the needs of the business changed during the project to date?
Have other projects started that have made demands on the resources required for this
project?
A.6.14Review project risk dimensions.

Identify where the risk ratings described in the Project Risk Assessment are higher than expected
or are greater than originally. Obtain agreement with management on the appropriate actions to
take.
Possible options may include reviewing the project and strictly monitoring any deviations from the
project work plan to be able to identify possible symptoms of a larger problem or may involve
changing the project scope or project team composition to try to resolve the issues.
In this latter instance, assess the impact of making changes to the project plan on the associated
strategy documents developed in this stage. Update the implementation strategy, data conversion
strategy and appropriate testing strategies as necessary.
Page 108
A.6.15Revise risk management approach.

Review the Project Risk Assessment to identify any changes from the initial assessment. For
identified threats, document:
The likelihood of impact on the project;
The severity of the risk;
How will the fact that the risk factor has come to fruition be recognized; and
How will the situation be addressed (e.g., avoidance, control, assumption or transfer).
A.6.16Revise the Project Charter.

Many areas within the Project Charter may not have been completed in full until this point since
they primarily affect the Business Blueprint Stage. Ensure that all these areas have been properly
addressed before progressing to the Business Blueprint Stage.
Revise the Project Charter as appropriate.
Page 109
A.6.17Obtain Approval of Project Preparation Stage Deliverables

Purpose
To seek final review and formal written approval of the Project Preparation Stage deliverables. At
this point, the deliverables and a Class 1 estimate are provided for approval to the GRT/DRB as
per CPDEP.
Overview
Throughout the Project Preparation Stage, formal written approval should be sought for
deliverables on an ongoing basis. At the close of the stage, a final review of deliverables is
undertaken and formal written approval obtained for all of the Project Preparation Stage
deliverables.
A.6.18Summarize findings of the Project Preparation Stage.

Combine the findings of this stage into a Project Preparation Stage document.
A.6.19Submit and discuss Project Preparation Stage deliverables.

Discuss the Project Preparation Stage deliverables with management and resolve any questions
and issues.
Responsibility and time scales for formal sign-off should have been defined in the Project Charter
and project contract.
Many of the deliverables should have already been subject to review and formal written sign-off
by user representatives. Review the work deliverables and address any outstanding sign-off
issues.
A.6.20Obtain formal written approval of the Project Preparation Stage

deliverables.
Obtain formal written approval of the Project Preparation Stage deliverables as defined in the
Project Charter and the project contract. Complete the necessary approval procedures to
complete CPDEP Phase 1 Identify and Assess Opportunities.
Page 110
Business Blueprint
The Business Blueprint Stage derives a design for the DW system including the data
transformation system, the data warehouse database (InfoCubes), and the presentation system.
In design, an integrated model is developed to depict "how" the requirements are to be
implemented in the new system from a business and technical perspective.
During this stage, you also:
Refine the original project goals and objectives
Refine the overall project schedule and implementation sequence
Key Deliverables:
1) Business Analytical Process Definition
a) Business requirements both general and subject area specific
b) Detailed presentation requirements for each subject area
c) History Considerations
d) Load timing
e) Users of the DW
f)
Reporting
i) Online
ii) Ad-hoc
iii) Operational reporting requirements
2) Data definition and design (CDM, LDM, MDM)
3) High-level Design
4) Data Conversion Specification
5) Data Transformation System design
a) InfoObject Characteristic, including master data, texts, and hierarchies
b) InfoSource
c) InfoCube
d) DataSource metadata
e) InfoObject key figure
6) Presentation System design
a) Restricted key figure
b) Variable specification
c) Query specification
d) Structure specification
e) Calculated key figure
f)
Worksheet specification
g) (others as identified for 3.0B/3.1c)
7) Security design
8) Testing approach and plan
9) User documentation (cross life-cycle)
10) Ongoing support documentation
a) Process external interfaces to SAP
b) Process SAP interfaces
11) Training (cross life-cycle)
12) Technology design
a) Review of overall technology design
b) Sizing
Page 111
Analysis and Decision Process Definition
An understanding of the analysis and decision processes within the scope of the planned DW
system is obtained. Based on an analysis of the organization's business events, the analysis and
decision processes including the performance measurement processes, quantitative analysis
processes and ad-hoc analytical processes are identified. The data requirements and
presentation characteristics of these processes are determined to form a basis for defining the
data requirements for the data warehouse and the end-user data access requirements. The data
access requirements provide the key inputs to the development of the DW presentation system.
Analytical Processing Data Definition
The requirements for the data warehouse are defined in the form of a Conceptual Data Model. To
support the analysis and decision processes, data definition on a DW project focuses on
determining the information needs of the various user views including performance measurement
and quantitative analysis. Unstructured data entities, such as multimedia data, required to support
business processes are also identified, if applicable.
The source data and the derivation or transformation rules are also determined. The data
transformation requirements provide the key inputs to the development of the data transformation
system.
Data Transformation System Design
The data transformation (DT) requirements defined during the Project Preparation Stage are
translated into a set of technical specifications for the DT system. DT system design must be
completed within a relevant overall BW architecture.
Data transformation is the process of transforming source data to target DW data. The key
components of a DT system include:
Data extracting;
Data cleansing/scrubbing (Transfer rules/routines);
Data transforming (InfoSource integration);
Data transfer;
Data refreshing, update and maintenance; and
InfoCube monitoring.
Presentation System Design
The data access and presentation requirements are translated into a set of technical
specifications for the DW presentation system. The presentation system design should address
issues relating to the three major layers of a presentation system architecture:
Data access layer is concerned with accessing the required data for the analytical
applications addressing issues such as data volume needed for the planned analysis,
level of data aggregation, format of data, data source and its media;
Data analysis layer is concerned with the core analysis tasks such as performance
measurement, data mining, statistical analysis and decision analysis; and
Data presentation layer is concerned with the media used in presenting the analysis
results to the end-users such as visualization, audio presentation, graphical presentation
or other forms of presentation media.
Data Design
The data requirements defined during the Analytical Processing Data Definition Phase, in the
form of a Conceptual Data Model (CDM) with the associated performance measurement,
quantitative measurement and unstructured data entities, are translated into a DW database
design consisting of a Logical Data Model (LDM) and a Multi-Dimensional Data Model (MDM).
[duplicate from a few paragraphs above]
Page 112
During the Business Blueprint Stage, several Cross-Life Cycle Phases may have started
including User Documentation, Training, and Acceptance Testing. These phases are briefly
described in the paragraphs below.
Other Cross-Life Cycle Phases, all started during the Project Preparation Stage and continuing
beyond the Business Blueprint Stage, include:
Change Integration;
Prototyping; and
Depending upon the specific project requirements, each of these Phases may have specific tasks
and steps to be completed during the Business Blueprint Stage.
User Documentation
Identifies and analyses current documentation and defines the purpose, audience, content and
media of any new procedures.
Training
Identifies the personnel to be trained, defines the training scope and strategy, creates the courses
and course materials, completes any pilot courses as appropriate and commences the training
program.
Acceptance Testing
Defines the acceptance test criteria against which the eventual system will be assessed. The test
plans needed to conduct and document the results of the acceptance test are defined and
generally refined during the Business Blueprint and Realization Stages and the final test is
conducted in the Final Preparation Stage.
Project Management
Although project management activities are ongoing throughout the project life cycle, in the
Business Blueprint Checkpoint Phase a formal confirmation of progress against the Project
Charter is completed and plans are developed for the Realization and Final Preparation Stages.
Page 113
A.7
Analysis and Decision Process Definition
Purpose
To obtain an understanding of the organization's analytical processes within the DW project scope
to provide a basis for determining the data requirements for the DW and the end-user DW access
requirements.
Overview
This task obtains an understanding of the business analysis and decision processes within the
scope of the project to provide a basis for:
Determining the data (content) requirements for the DW, i.e., the data which end-users
require in conducting the analytical processes. These data requirements are defined and
modeled in the Analytical Processing Data Definition Phase which is completed
concurrently with this phase; and
Determining the end-user data access requirements in conducting these analytical
processes. These requirements are the primary drivers for the design and development
of the presentation architecture for the proposed DW system.
Based on the business drivers identified for the project, an understanding of the organization's
business processes and events is obtained to provide a foundation for identifying the analysis
and decision processes. Business event modeling is discussed as a technique to be used in the
analysis of an organization's business processes and events.
The analysis and decision processes generally fall into two main categories:
Performance measurement processes; and
Quantitative analysis processes (e.g., data mining applications).
The characteristics of these processes in terms of their data and data access requirements are
determined. In addition, if possible, typical ad hoc analysis processes and their characteristics
should also be determined.
Page 114
Analysis and Decision Process Definition Task Relationships

B u s in e s s d r iv e r s
D a ta a b s tra c t
P ro c e s s a b s tra c t
G 2
Id e n tify P e r fo r m a n c e
M e a s u re m e n t
P ro c e s s e s
P e rfo rm a n c e m e a s u re m e n t
p ro c e s s e s a n d d a ta
p r e s e n ta t io n c h a r a c te r is tic s
Q u a n tita tiv e a n a ly s is p r o c e s s e s
a n d d a ta p r e s e n ta tio n
c h a r a c te r is tic s
G1
A n a ly z e B u s in e s s
P ro c e s s e s a n d E v e n ts
G3
Id e n t ify Q u a n tit a tiv e
A n a ly s is P r o c e s s e s
G5
D o c u m e n t A n a ly s is
a n d D e c is io n
P ro c e s s e s
B u s in e s s p r o c e s s e s
B u s in e s s e v e n ts
G4
Id e n tif y A d h o c
A n a ly s is P r o c e s s e s
A d h o c a n a ly s is p r o c e s s e s a n d
d a ta p r e s e n ta tio n
c h a r a c te r is tic s
A n a ly s is a n d d e c is io n
p r o c e s s d e s c r ip tio n s
G6
C o n fir m R e la t e d
P r o c e s s M o d e ls
C o n f ir m e d a n a ly s is a n d
d e c is io n p r o c e s s d e s c r ip tio n s
G7
S u b m it P r o c e s s
D e f in it io n D e liv e r a b le
P r o c e s s d e f iin it io n d e liv e r a b le
Page 115
A.7.1 Analyze Business Processes and Events

Purpose
To analyze an organization's business processes and events to provide a basis for determining
their business information needs.
Overview
This task analyses the organization's business processes and events to provide a basis for
determining the organization's business information needs. The business event modeling
technique discussed in this task is based on the work completed by Denna, Cherrington, Andros
and Sawyer Hollander as discussed in their book, Event-Driven Business Solutions - Today's
Revolution in Business and Information Technology [Irwin Professional Publishing, 1993].
Another technique for analyzing the business processes is through the development of Use
Cases. A Use Case is a modeling technique used to represent a view of the activities carried on
by the business. Each activity is described a a scenario (use instance) of people, actions, and
information that combine to achieve a necessary business result.
This technique is particularly effective for modeling business situations that are characterized by
significant interaction between people and information technology. Use Cases are also valuable
in projects that employ an Event-Driven approach to analysis. In these cases, some of the
elements of the Event-Driven models can be substituted by Use Case elements.
For further details, refer to the Use Case Modeling.doc document.
A business event is defined as an essential organizational activity that management wishes to
plan, control and evaluate to achieve a business objective (e.g., receiving a customer order,
shipping merchandise and collecting the customer payment).
The basic premise of business event modeling is to identify and capture the essential data
supporting an organization's business events, from which the information needs (or views) of
different information users (e.g., senior management, operational management, accountants,
production planners or service technicians) within the organization can be supported. The key is
to integrate the organization's data by focusing on what is represented by the data (i.e., the
business events) and not on the individual information user views (e.g., financial statements,
specific management reports or regulatory reports). Thus, by focusing on business events,
different user perspectives of the organization's data, including both transaction processing and
business/decision analysis views, can be supported.
Depending on the specific circumstances and scope of the DW project, the specific formalism
presented in this task may be utilized in various ways such as:
Business event modeling may be completed as part of process definition of a related
system development project and thus provides the inputs to the data modeling process;
The specific business event modeling formalism discussed in this task is used in
determining the information contents (or requirements) for the CDM; or
The specific business event modeling formalism discussed in this task is not used but the
general framework and concepts are utilized in determining the organization's information
needs (e.g., the business event analysis framework may be used to structure or guide
management interviews and to analyze the interview findings).
Page 116
Scope of Process Definition
On a DW project, the scope of process definition is typically limited to a high-level understanding
and description of the analytical processes and user access requirements for the purpose of
developing the DW data transformation and presentation systems.
If some or all of these analytical processing applications are also going to be developed, they
should be considered as separate custom or package software development projects.
The scope of the DW project may be expanded to include the development of these analytical
applications or a separate custom or package software development project may need to be
defined.
Critical Concepts of Event-Driven Business Modeling
Event-driven business modeling is the concept of building systems that fully support a business
by capturing all relevant information contained in "business events". The contention is that by
focusing on business events, a comprehensive view of an organization centered around business
processes can be developed as opposed to the more traditional and often limited view that
concentrates on the functions or information processes of an organization.
The critical concepts of event-driven business modeling include:
Focus on business events. A horizontal (business process) rather than a vertical

(functional) view of an organization's business is obtained by focusing on business
events. This approach transcends traditional organizational boundaries and focuses on
the business processes of an organization's value chain. It thus provides a basis for
transforming an organization such as organizational restructuring or business process
transformation;
Simplify business processes and organizational structures. The business process and
organizational structure must first be simplified before applying IT;
Integrate data. Business event data must be integrated and shared by all authorized
knowledge users in the organization;
Integrate information processes and controls. Information processes and controls must
be integrated and where possible and appropriate, real-time controls applied; and
Realign system component and business process ownership. The ownership and
management of information systems and business processes must be changed to realign
with the new envisioned organization enabled by the above business solutions concepts.
Decision Support Analysis Framework

Quantitative analysis processes may be identified and analyzed within a decision support
framework consisting of the following key concepts:
Operational performance/transaction processing level including detailed information
needed for the day-to-day operation of an organization's business,
Operational/management control level including information used by management in the
organization's operational planning/control activities (this level is sometimes split into
separate operational control and management control levels), and
Strategic planning level including information used by senior management in the
organization's policy setting and strategic planning activities.
As the level moves from the operational performance level to the strategic planning level, the
information needs tend to be:
more dependent on external information,
less dependent on internal information, and
less dependent on current performance data.
Page 117
Information at the higher level is often required on an as-needed basis (as opposed to the often
scheduled reporting of operational performance information); and
Phases of a decision process. A decision process can be described as consisting of
three phases (Herbert Simon, The New Science of Management Decisions, revised
edition, Prentice-Hall, 1977):
Intelligence - searching the environment for conditions that call for a decision. During this
phase, management seeks to gather data to:
perceive future trends having an impact on the organization before they actually
occur, or
more clearly define the problem and provide some input to the solution process;
Design - finding possible courses of action. During this phase, management seeks to
invent, develop and analyze possible courses of action. It involves manipulation of the
data obtained to develop various solutions to the problem, and
Choice - choosing among courses of action. During this phase, management seeks to
select the best among the alternatives developed during design using techniques such as
sensitivity analysis.
Management decision support information needs may be identified by focusing on the information
management needs in each of these decision making phases.
Examples of Quantitative Analysis
Quantitative analysis may be completed in many forms or shapes to support an organization's
business analytical or decision making processes. Some examples include:
A custom quantitative analysis model for a large downstream retail chain, including a
causal-based sales forecasting model that leveraged daily point-of-sale data from
approximately 400 stores to track promotional effectiveness;
Estimating inventory shrinkage at the store level for a convenience store using a samplebased statistical model;
Combining business rules with statistical sampling expertise to improve the market for
service stations.
Data Mining/Data Profiling
Data mining/data profiling (DM/DP) is the analysis of data, typically using quantitative analysis
techniques, to uncover valuable business information to support an organization's analytical or
decision making processes. The key elements in planning for a DM/DP effort consist of:
The business objectives to be supported; and
The quantitative analysis technique(s) to be employed including the associated input and
output data.
DM/DP addresses five kinds of data:
Classification (or pattern recognition i.e. rules) such as:
Classifying customers into those with "high profit potential" versus those with "low profit
potential" or those "satisfied" versus those "unsatisfied" to:
Target special promotions,
Differentiate level of service provided, or
Improve customer satisfaction;
Classifying locations/channels into those with "high profit potential" versus those with "low
profit potential" to:
Target direct expansion to new locations with highest potential, or
Target incentives to best channels,
Prediction/forecasting such as:
Page 118
Sales forecasting for:

Supply chain management, or
Promotion planning;
Sequences (or events over time, e.g., house, refrigerator);
Association (or things done together e.g., buy groceries) such as:
Market basket, sequential purchase for:
Planning store layout to maximize cross-sell, or
Micro-marketing based on sales history; or
Segmentation/clustering (or definitions of new groups) such as:
Demographic grouping of customers/prospects for:
Target marketing/conjoint analysis, or
Segments as a basis for classification models.
DM/DP techniques include: statistical analysis (e.g. regression, optimization, linear programming,
time series analysis), neural networks and expert systems, fuzzy logic, intelligent agents,
multidimensional analysis, data visualization and decision trees.
Scope of Analytical Process Definition
The main purpose in defining the analytical processes in this phase is to provide a basis for
determining the data requirements for the DW and the data access requirements for the
presentation systems. Actually developing the application systems supporting these analytical
processes is typically outside the scope of a DW project. Thus, the documentation of the
analytical processes as discussed in this task is not at the same detailed level as would be
required for the actual project implementation. However, depending on the specific project
objectives, the scope of the DW project may be expanded or a separate project may be initiated
to encompass the development of selected performance measurement or quantitative analysis
processes.
Understanding business processes/events helps in identifying analytical information needs from an
enterprise perspective. In particular, the characteristics of business processes/ events often provide useful
inputs in determining performance measures, quantitative analysis or other analytical processing
information needs which are the foundation for multidimensional data analysis as discussed in this phase
and in the Data Design phase.
A.7.2 Review and confirm the organization's business processes.

Review the organization's business processes with user representatives and management to
determine their accuracy and make any changes as required.
Ensure that the business processes to be investigated in this task are relevant to supporting the
business drivers identified during the Project Start-up phase.
This review may be conducted as a group discussion or with a single key user (one who has an
overall view of the business). Obtain confirmation of the list of business processes.
During this review, the key users from each business process should be identified, if not already
known.
A.7.3 Identify business events based on the understanding of business

processes.
Identify the organization's business events based on an examination of the definitions of the
business processes and discussions with users or subject matter experts.
Page 119
Business events should be identified at the level at which management wishes to plan, control
and evaluate to accomplish specific business objectives; e.g., the focus of an acquisition/
payment process is on purchasing only what is needed and can be paid for, receiving only what is
ordered, paying for only that which is received and making sure that the resources acquired are
available when needed. Thus, while an acquisition/payment process may involve a wide variety of
goods and services (e.g., human resources, financial resources, supplies or inventories), the
basic types of business events may include:
Request the goods or services;
Select a supplier;
Order the goods or services;
Receive the goods or services;
Inspect the goods or services; and
Pay for the goods or services.
As needed, the business events may be further decomposed to lower level events to meet the
needs of a specific analysis or objective.
In determining business events, it is important to distinguish between business events and
information processes. The latter are the activities that record business event data, maintain the
reference data about business events and report the information to authorized users. Thus, the
relationship between the two is that - business events trigger information processes.
The differences between the two concepts can be illustrated using the following examples:
Business Event
Deliver a product to a customer
Receive a payment from a customer for goods
and services provided
Information Process
Record data about the delivery
Record data about customer payment
Information systems should be developed to support the essence of business processes by

focusing on business events rather than information processes. By capturing data about
underlying business events, a wide variety of information user views (e.g., executive view, human
resource view, accounting view, marketing view and production view) can be supported.
Document the business events including their characteristics and the information used by the
business event.
A.7.4 Identify the essential characteristics of the business events.

Review with management to identify the essential characteristics of each business event. The
information to be captured can often be determined by answering the following questions about
the business events:
What happened and when?
What roles were played and who/what performed the roles?
What kinds of resources were involved and how much were used?
Where did the event occur?
Document the identified characteristics for each of the business events.
A.7.5 Analyze the characteristics of the business events.

Analyze the characteristics of the identified business events. The REAL business modeling
technique (discussed in Denna, Cherrington, Andros and Sawyer Hollander, Event-Driven
Business Solutions: Today's Revolution in Business and Information Technology [Irwin
Page 120
Professional Publishing, 1993]) may be used as a framework for business event analysis. REAL
is an acronym for:
Resources - Organizational resources used by the business event either directly or
indirectly. If it is difficult to identify a resource for a business event, the event is probably
unnecessary or adds little value. Resources may be physical (e.g., buildings, equipment,
supplies, inventories) or conceptual (e.g., employee skills, patents, financial resources);
Event - The business event being modeled;
Agents - People or machines that execute the business event (i.e., play roles or perform
responsibilities with respect to the business event). Agents could be internal (e.g.,
engineers, cashiers, production workers) or external (e.g., customers, suppliers). Roles
may sometimes be performed by machines (e.g., ATM machines, robots); and
Locations - Places where the business event took place.
In REAL modeling, "time" is an attribute of a business event. Alternatively, a "time" dimension may
be explicitly modeled.
Using the REAL business event modeling formalism, business events and the associated
resources, agents and locations are represented in rectangular boxes with lines connecting the
event box with the associated resource, agent and location boxes. Resources and locations are
typically placed on the left side of events and agents are placed on the right side.
Analyzing business events provides a process perspective in determining the information content
of the data models. By capturing the essential characteristics of an organization's business
events, the information needs (or views) of the various information users can be supported. Thus,
analyzing business events facilitates the integration and sharing of data within the organization.
A.7.6 Discuss and confirm the business event analysis results with
management.
Discuss the business events and their characteristics with knowledgeable users, in a structured
walk-through format, as appropriate. Resolve any questions or issues and make any changes as
necessary.
Page 121
A.7.7 Identify Performance Measurement Processes

Purpose
To identify the performance measurement processes to be supported by the proposed DW
system.
Overview
Identifying and understanding performance measures helps in determining the information content and
data access requirements of the DW system. It is beyond the scope of a typical DW project to develop an
organization's performance measures. If required, the scope of a DW project may be expanded or a
separate performance measurement project may be initiated to define the performance measures.
This task focuses on identifying the organization's performance measurement processes which
are to be supported by the DW system being developed. Based on an understanding of these
processes, the data required to support these processes is defined and modeled in the Analytical
Processing Data Definition phase. In addition, the data access characteristics of the performance
measurement processes are also determined which form part of the requirements for the design
of the presentation architecture of the DW system.
Performance measures are the carefully selected measures derived from the drivers of business
success that represent a tool for management to use in communicating strategic direction to the
organization and for motivating change. If defined and used correctly, they may constitute the
major portion of the information used in an organization's business analysis and decision making
activities.
The usefulness of performance measures in supporting an organization's business or decision
analysis activities depends on how well the measures have been defined and used. Some of the
general characteristics of performance measures include:
An organization's performance measures should align with its business strategy and
critical success factors. They should focus on the important business functions and direct
attention to key matters of management concern. Measurement feedback should indicate
whether these strategies are being achieved;
Performance measures must have measurable goals;
Performance measures should constitute a balanced set consisting of both:
result measures (usually financial in nature) and process measures (about the
underlying business processes),
leading measures (showing immediate results of a completed operation such as
defects and cycle time) and lagging measures (showing results of completed
operations over time such as customer satisfaction),
cost and non-cost measures, and
external and internal business perspectives; and
The performance measurement set should encompass all business processes of an
organization and present a comprehensive and integrated view of the business.
An organization's performance measurement set must:
Align with the organization's business strategy; and
Include all relevant aspects of the business processes as reflected in the organization's
value chain.
Page 122
A.7.8 Gather information on the current performance measurement

system.
Gather information and assess performance measurement usage within the organization related
to the scope of the DW project:
Contact selected key functional and operations managers to obtain representative
samples of the information, reports and performance measures that they create, receive
or present.
Functional and operations managers should represent the organization's key functional areas
such as finance, human resources, marketing and sales, customer order entry, materials
management and information management and the major operating units of The firm.
Obtain copies of reports prepared by the IS Department and a list of recipients of each
report. For some information systems, data may only be available as screen formats or
output files; and
Obtain current performance measurement usage information/documentation from key
management/performance review meetings (including both formal or informal review
sessions) such as the meeting agenda, minutes and other relevant information presented
or discussed during these meetings.
This information should also include cyclical or annual events such as the budget creation and
review process and the capital expenditure budgeting process, if separately derived.
A.7.9 Identify the current performance measures.

Analyze the current performance measurement data gathered that relates to the project scope
and identify the current performance measures.
While some of the performance measurement data may be clearly stated or presented (e.g., data
obtained from performance review reports or management meeting documentation), other data
may be hidden in various management or operation reports/information presented or used by
functional/operational managers or senior executives. It is, therefore, necessary to analyze the
current performance measurement data gathered from various sources and organize it into
individual performance measures.
In reviewing the current performance measurement data (e.g., performance measurement
reports, management/performance meeting documentation), focus on understanding the:
Objectives of each measure;
Performance measurement goal setting mechanisms;
Data sources including both internal and external sources;
Data collection and/or generation processes together with timing and frequency; and
Reporting and usage of performance measurement data.
If the performance measures are of interest to the project, define and document the measures as
discussed in the Identify Performance Measurement Entities task of the Analytical Processing
Data Definition phase.
Review and refine the list of information needs as appropriate based on the findings of the
analysis of the current performance measures.
A.7.10Develop a balanced set of performance measures. (Optional)

Determine the need to develop a new performance measurement system based on the findings
of the review of the current performance measures.
In proposing to develop a new performance measurement system:
Page 123
The justification for developing a new performance measurement system must be

developed. A well-constructed performance measurement system is not only important
for determining business analytical information needs but is a critical element for the
successful implementation of an organization's business strategy and its continuous
improvement effort. The need to develop a new performance measurement system
should be determined not just from a business analytical perspective but also from a
broader organizational context;
The additional work required to develop a new performance measurement system must
be determined; and
The project resources (e.g., skill sets) required to develop a performance measurement
system must be identified.
The scope impact on the current DW project must be assessed and discussed with management.
It may be appropriate to prepare presentations for management on the concepts and benefits of a
new performance measurement system. Senior management commitment and support is critical
for the success of a performance measurement project.
Discuss with management and determine whether it is appropriate to expand the scope of the
current DW project or to initiate a separate performance measurement project for the
development of a new performance measurement system.
If the scope of the DW project is to change:
Formally document the amended scope;
Determine the resource requirements;
Prepare an amended work plan and timing and cost estimates; and
Obtain formal written approval of the changes before proceeding.
A.7.11Determine the data presentation characteristics of the performance

measurement processes.
Determine the distribution characteristics of the end-user data accesses including areas such as:
Geographical distribution of users;
Organizational distribution of users;
Divisional/functional organization of users; and
Vertical/horizontal organization of users.
Determine the data access characteristics of the performance measurement processes
considering:
Volume of data required for analysis;
Level of information required (i.e., the granularity of data requirements);
Data "drill-through" requirements;
Data sources (internal or external sources);
Source data media (e.g., structured versus unstructured data); and
Integration or interoperability requirements.
Determine the data analysis characteristics of the performance measurement processes
considering:
User analysis perspectives of data (e.g., analysis dimensions such as product, region
and time);
Top line/exception reporting;
Standard performance measurement reports;
Priorities of performance measurement reports;
Continuous improvement analysis;
Page 124
Any new information created as a result of the analysis processes (e.g., resulting
performance measures);
Whether the analyses are currently performed or are planned in anticipation of the
availability of the DW data; and
Determine the presentation media characteristics of the performance measurement processes

such as:
Visualization;
Audio presentation;
Graphical presentation; and
Other forms of presentation media.
A.7.12Discuss with management the identified performance measurement

processes.
Discuss the identified performance measurement processes and their data presentation
characteristics with management. Resolve any questions or issues and make any changes as
necessary.
Page 125
A.7.13Identify Quantitative Analysis Processes

Purpose
To identify the quantitative analysis processes to be supported by the proposed DW system.
Overview
This task identifies the quantitative analysis processes supporting management decision making
in the organization within the scope of the DW project. Unlike transaction processing,
management decision making is not as well defined and is typically ad hoc in nature. Quantitative
analysis processes are identified in this task based on both a:
Top-down approach based on a decision support analysis framework and an
understanding of the organization's business environment and its industry; and
Bottom-up approach based on interviewing management and reviewing current
quantitative analysis data usage.
Based on an understanding of these processes, the data required to support these processes is
defined and modeled in the Analytical Processing Data Definition phase. In addition, the data
access characteristics of the quantitative analysis processes are also determined which form part
of the requirements for the design of the presentation architecture of the DW system.
A.7.14Analyze the information infrastructure supporting the organization's

decision process structure.
Review the project team's understanding of the organization's information infrastructure obtained
thus far on the project to provide the project team with a proper frame of reference in addressing
the organization's decision support information needs:
Review the ERM (developed in the Data Warehousing Project Abstract phase) and initial
CDM (developed concurrently in the Analytical Processing Data Definition phase) to
obtain an understanding of the major entities and entity relationships of interest within the
organization;
Review the understanding of the organization's current business environment focusing on
the key decision processes; and
Based on the project team's understanding of the business and information infrastructure
environments and discussions with management:
Identify the major decision processes within the organization;
Analyze each major decision process to determine the information required to support
each phase of the decision process (i.e., the intelligence, design and choice phases
discussed in the Task Overview):
Intelligence Phase: Information required to proactively anticipate problem or opportunity
situations before they occur (e.g., scanning internal and external databases for
opportunities and problems and generating performance measurement exception
reports),
Design Phase: Information required to generate alternative courses of action, and
Choice Phase: Information required to determine the consequences of taking each
alternative action for use as the basis for choosing among alternative courses of action
(e.g., completing "what if" type sensitivity analysis).
In addition to raw transaction processing data, decision support data may also include data used
in or generated by quantitative analysis models or processes such as customer profile data or
sales trend analysis.
Page 126
A.7.15Analyze the quantitative analysis processes.

Identify any quantitative analysis processes or models used in the business analysis or decision
making processes; e.g., several approaches may be employed by an organization to target
marketing with different levels of sophistication or levels of effort:
Profile current customers (e.g., based on suburban/urban residence, age, family structure
or race) and seek similar prospects by targeting marketing efforts on postal codes that
match the desirable customer profile;
Develop a model that predicts customer profitability at the household level and target
marketing efforts on those households with high potential profitability; or
Segment customers first and then build models for each customer segment (e.g., college
students may be worthwhile targets despite their current low income and no credit
history).
Each of the target marketing approaches will have different implications in terms of the data used
in the quantitative models and the outputs from the models.
Review available quantitative analysis plans addressing issues such as:
Data requirements for the analysis including, for each data element, details such as:
description of data elements,
time frame that the data covers,
level of aggregation,
volume of data needed (i.e., sample versus population), and
format of data;
Potential data sources (including both internal and external sources);
Derived data elements arising from situations such as:
where data is available but is too costly or too difficult to obtain and can be more
easily derived from other attainable data, or
where data is not available but can be derived from available data;
Quality checks and cleaning/editing procedures including:
procedures for range checks, including upper and lower bounds of reasonableness
for each data element,
imputation guidelines,
procedures for verifying collected or extracted data,
procedures to address inadequate/incorrect data, and
procedures for performing consistency checks across data elements;
Exploratory analysis to be conducted for further examination and understanding of the
data, its use and its use in application and development of potential quantitative analysis
models. Examples of some analysis methods include:
listing, graphing and plotting the data,
univariate analysis,
correlation analysis, and
variance analysis;
Relevant models and methods describing the:
quantitative analysis to be performed,
variables to be modeled,
resulting outputs of the model,
required hardware/software support,
required skills to employ the methods and develop the models, and
procedures to test and validate each method or model.
A.7.16Determine the implications of the quantitative analysis processes on

the DW.
Determine the implications of the quantitative analysis processes on the DW in terms of:
Page 127
The DW as a source of input data to the quantitative analysis processes; or

The results of the quantitative analysis processes as a source of data for the DW.
Identify the relevant quantitative measurement (QM) data either as DW input to or as DW source
data from the quantitative processes. Define the QM data describing:
The business objectives supported by the QM data;
The quantitative analysis process that uses or creates the data;
The quantitative analysis techniques used in deriving the QM data; and
The interpretation of the resultant QM values focusing on their business implications.
A.7.17Determine the data presentation characteristics of the quantitative

analysis processes.
Summarize the data access characteristics of the quantitative analysis processes as determined
earlier including:
Volumes of data required for analysis;
Summarize the data analysis characteristics of the quantitative analysis processes including:
User analysis perspectives of data (e.g., analysis dimensions such as product, region
and time);
Top line/exception reporting;
Standard performance measurement reports;
Priorities of quantitative analysis reports;
Continuous improvement analysis;
Any new information created as a result of the quantitative analysis;
Determine:
Whether the analyses are currently performed or are planned in anticipation of the
availability of the DW data; and
Whether any analysis tools (e.g., data mining tools) are currently available or being
developed and the impact of the availability of these tools on the work of the DW project.
Determine the presentation media characteristics of the quantitative analysis processes such as:
Visualization;
Audio presentation;
A.7.18Discuss with management the identified quantitative processes.

Discuss with management the identified quantitative analysis processes and their presentation
characteristics. Resolve any questions or issues and make any changes as necessary.
Page 128
A.7.19Identify Ad hoc Analysis Processes.

Purpose
To determine the characteristics of the ad hoc analysis processes to be supported by the
proposed DW system.
Overview
This task focuses on identifying the organization's ad hoc analysis processes which are to be
supported by the DW system being developed. Based on an understanding of these processes,
the data required to support these processes is defined and modeled in the Analytical Processing
Data Definition phase.
By definition, ad hoc analysis processes cannot be predetermined. However, the types and nature
of the likely ad hoc analysis processes may be identified by analyzing past data usage or
discussing with management and business analysts. The performance measurement and
quantitative analysis frameworks discussed in Tasks G2 and G3 may also provide a context for
identifying ad hoc processes.
A.7.20Identify the types of ad hoc analysis processes to be supported by

the DW system.
Identify the types of ad hoc analysis processes to be supported through:
Analyzing past ad hoc data usage patterns (e.g., the types of data accesses and the
access paths);
Discussing with management or business analysts to determine their ad hoc analysis
information needs; or
Reviewing the performance measurement and quantitative analysis frameworks and
processes.
Determine the types of data required to support the identified ad hoc analysis processes.
A.7.21Determine the data presentation characteristics of the ad hoc

analysis processes.
Determine, if possible, the data access characteristics of the ad hoc analysis processes
considering:
Volume of data required for analysis;
Determine the data analysis characteristics of the ad hoc analysis processes considering
whether:
Page 129
The analyses are performance measurement, quantitative analysis or other analysis

processes;
Any new information created as a result of the analysis processes;
The analyses are currently performed or are planned in anticipation of the availability of
the DW data; and
Any analysis tools are currently available or being developed and the impact of the
availability of these tools on the work of the DW project.
Determine the presentation media characteristics such as:

Visualization;
Audio presentation;
A.7.22Discuss with management the data presentation characteristics of

the ad hoc processes.
Discuss with management the types of ad hoc analysis processes to be supported and their data
presentation characteristics. Resolve any questions or issues and make any changes as
necessary.
Page 130
A.7.23Document Analysis and Decision Processes

Purpose
To document the analysis and decision processes to be supported by the proposed DW system.
Overview
Process Descriptions are prepared for each of the analysis and decision processes identified in
the previous tasks including the performance measurement processes, quantitative analysis
processes and ad hoc analysis processes. These descriptions provide a major source of input for
determining the information content of the DW and the data access requirements of the DW
presentation systems.
A.7.24Develop high-level descriptions for each of the analysis and decision

processes.
Develop high-level descriptions for each of the analysis and decision processes identified
including items such as:
A description of analytical process;
The type of analysis performed:
compliance analysis and reporting,
management decision analysis and reporting,
customer analysis and reporting,
supplier analysis and reporting, or
financial analysis and reporting;
The organizational units or users performing the process;
The type of data required to support the process (e.g., performance measures or
quantitative analysis data); and
The sources of the data (i.e., external or internal sourced data).
A.7.25Define reporting requirements for the analysis and decision

processes.
Define the reporting requirements as appropriate for the analysis and decision processes
considering items such as:
Reporting data elements and their sources;
Summarization levels;
Data aggregation requirements;
Data "drill-down" requirements;
Unstructured data requirements; and
Reporting frequency and distribution requirements.
A.7.26Determine and document Operational Reporting Requirements

The purpose of this task is to determine and document operational reporting requirements.
Procedure
Review standard reports used/created/distributed from the R/3 system
Page 131
A.7.27Discuss and confirm the required system models with management.

Discuss and confirm the identified analysis and decision processes with management. Present
the unified model integrating the transaction and analytical processes as appropriate. Resolve
any questions or issues and make any changes as necessary.
Page 132
A.7.28Confirm Related Process Models

Purpose
To reconcile and validate the analytical processes against the CSFs (business focus) and the
related transaction processes.
Overview
This task confirms the analytical processes identified in the previous tasks both in terms of their
support for the organization's critical success factors (CSFs) and their consistency with the
transaction processes.
A.7.29Confirm support of the Critical Success Factors.

Prepare an Analytical Process/CSF Matrix indicating which CSFs are supported by which
analysis and decision processes defined in Process Descriptions.
Confirm with management the accuracy of the support relationships between the analytical
processes and the organization's CSFs as depicted in the Matrix.
A.7.30Reconcile the analytical processes with the source processes.

Identify the source processes or systems providing inputs to the identified analytical processes.
Reconcile the analytical processes with the associated internal source transaction processes to
obtain a consistent, unified process view for the purposes of:
Understanding and validating the flow of data between the transaction processing and
analytical processes; and
Confirming the sources of data for the analytical processes provided by the associated
transaction processing processes.
For external source processes or systems, document their characteristics such as:
Ownership of the external systems (e.g., suppliers, customers or government agencies);
Data communications/access infrastructure (e.g., via network connections or the
Internet);
Quality of data (e.g., timeliness, cleanliness);
Data media (e.g., numerical, textual, audio or video); and
Data availability (e.g., whether data is in the public domain or is available only with
specific data sharing agreements such as those with customers or suppliers).
A.7.31Reconcile the analytical processes with the CDM.

Reconcile the analytical processes with the CDM to ensure that the data requirements of the
analytical processes are adequately supported by the data defined in the CDM, specifically
focusing on the definitions of the:
Performance measurement entities;
Quantitative measurement entities; and
Unstructured data entities.
A.7.32Discuss and confirm the reconciliations with management.

Discuss and confirm the reconciliations with management. Resolve any questions or issues and
make any changes as necessary.
Page 133
A.7.33Submit Process Definition Deliverable

Purpose
To provide a management checkpoint at which the results of the process definition tasks can be
reviewed and verified.
Overview
The outputs from the individual tasks are consolidated into a process definition deliverable. This
deliverable is reviewed for content and clarity and presented to management for confirmation of
the contents and to obtain formal written agreement to the recommendations made in the
deliverable.
A.7.34Assemble process definition deliverable.

Consolidate the individual parts of the process definition deliverable prepared in the earlier tasks
of this phase by packaging together the interim work products into a formal deliverable.
A.7.35Conduct structured walk-through of the analysis and decision

processes.
Review the Process Descriptions for the analysis and decision processes for completeness and
accuracy. Include the associated Process Descriptions in the structured walk-through. Make any
amendments as necessary.
A.7.36Submit and discuss process definition deliverable with management.

Discuss the process definition deliverable with management and resolve any questions and
issues. If necessary prepare an action list of items to modify. This step may involve more than
one meeting.
A.7.37Obtain formal written approval of process definition deliverable.

Confirm that the process definition deliverable accurately reflects the functionality needed by
management and the users and obtain formal written approval.
Approval at this point consists only of confirmation of the processes. The formal written approval
of all of the analysis activities will be addressed as part of the Analysis Checkpoint Phase.
Page 134
A.8
Analytical Processing Data Definition
Purpose
To determine the data requirements for the proposed DW.
Overview
This phase determines the requirements for the DW database being developed. While the DW
system (and its database) may be developed on an incremental basis (e.g., on a subject area by
subject area basis), the development should be guided by an enterprise Conceptual Data Model
(CDM). Otherwise, the various DW databases developed over time may become "islands of
information" with data that may be inconsistent or redundant. An enterprise CDM also ensures
that the DW databases are consistent with the transaction processing databases which are the
major data sources for the DW databases.
As illustrated in Exhibit E-1, an organization's enterprise data model environment can be viewed
as consisting of three data model types:
The Enterprise CDM;
The Analytical Processing/OLAP Data Model in the form of performance measurement
(PM) entities, quantitative measurement (QM) entities and unstructured data entities; and
The Transaction Processing/OLTP CDM,
The major tasks of this phase can be described as follows:

A high-level CDM is prepared to provide an enterprise view (as determined by the project
scope) of the organization's data resources at the conceptual level;
The analytical processing data requirements are then determined in the form of
performance measurement entities, quantitative analysis entities and unstructured data
entities; and
The data transformation requirements for the analytical data elements are determined in
terms of data sources, cleansing, calculation and derivation algorithms. The data sources
may be either internal or external sources. These requirements provide the major inputs
for the design of the data transformation system and possibly also the presentation
system.
The analytical processing data definition is validated against the corresponding process definition
completed concurrently in the Analysis and Decision Process Definition phase.
Page 135
Analytical Processing Data Definition Task Relationships
P ro c e s s a b s tra c t
D a ta a b s tra c t
H2
Id e n t ify P e r fo r m a n c e
M e a s u r e m e n t E n titie s
H1
D e v e lo p C o n c e p t u a l
D a ta M o d e l
H3
I d e n tif y Q u a n tita tiv e
M e a s u r e m e n t E n t it ie s
P e rfo rm a n c e m e a s u re m e n t
e n tit ie s
C o n c e p tu a l D a ta M o d e l
H4
Id e n tify U n s tr u c tu r e d
D a ta E n titie s
U n s tr u c t u r e d a t a e n t itie s
Q u a n t ita tiv e m e a s u r e m e n t
e n t itie s
H5
Id e n tif y S A P S o u r c e s
H6
A s s e s s R e q u ir e d n o n S A P D a ta S o u rc e s
M a s te r D a ta r e q u ir e m e n ts
S A P D a ta M a p p in g d o c u m e n t
N o n - S A P D a ta M a p p in g
docum ent
H7
I d e n t ify M a s te r D a ta
H8
D e te r m in e D a t a
T r a n s fo r m a t io n
D a ta tr a n s fo r m a tio n r e q u ir e m e n ts
H9
V a lid a t e P r o c e s s / D a ta
D e fin it io n
V a lid a t e d d a t a d e f in it io n s
H10
S u b m it D a t a D e f in it io n
D e liv e r a b le
D a t a d e f iin it io n d e liv e r a b le
Page 136
A.8.1 Develop Conceptual Data Model

Purpose
To determine the data requirements for the proposed DW in the form of a Conceptual Data
Model.
Overview
A CDM depicts the structure of an organization's data resource at a conceptual level in terms of
data entities and their relationships. It is the second data model in the top-down progression of
data models as discussed in the Methodology Overview. While the CDM is a key part of data
modeling in developing a transaction processing database, it may also be developed on a DW
project for reasons such as:
A CDM helps in defining or confirming the scope of a DW;
A CDM helps in understanding an organization's data resources and identifying data
sources for the DW;
The entities and entity relationships defined in a CDM provide useful inputs for
multidimensional data modeling (i.e., defining dimensions and their measures) on a DW
project; and
The performance measurement entities, quantitative measurement entities and
unstructured data entities provide the direct inputs to the multidimensional modeling
process.
Multidimensional data modeling is discussed as an integral part of logical and physical data
modeling in Data Design.
A.8.2 Develop CDM.

The purpose of this task is to create a structured business view of the data required to support
current business processes, business events, and related performance measurement and
analysis efforts.
The creation of the CDM builds upon the Entity Relationship Model (ERM) and organizes all of
the identified data into a single integrated data structure. The CDM reflects the structure of the
business functions rather than the processing flow or physical arrangement of data.
For large complex data models, the process of building the CDM may be easier by building
separate, smaller CDM pieces. Each component CDM is built from a copy of the ERM.
Page 137
A.8.3 Identify Performance Measurement Entities

Purpose
To define performance measurement data identified during information content analysis.
Overview
This task defines the selected performance measures identified during the development of the
CDM. The performance measures are typically derived data that do not normally form part of the
CDM. However, they represent a major part of an organization's business analytical processing
information requirements and thus should be formally defined and documented.
The identified performance measures are grouped into "entities" or "categories" for
documentation purposes. They may be translated into Dimension Tables or Fact Tables in
multidimensional data analysis during logical data modeling in the Data Transformation System
Design phase.
A.8.4 Review the performance measures identified to be of relevance to

the organization.
Review the performance measures identified in the analysis of the performance measurement
processes to ensure that they are relevant measures within the organization's overall
performance measurement framework.
These measures may be current measures or new measures identified in an expanded DW
project or a separate performance measurement project.
A.8.5 Categorize the performance measures.

Group the performance measures into their respective categories which may be referred to as
performance measurement entities.
The main purpose of categorizing measures into entities is to facilitate understanding and
documentation of the performance measures.
A.8.6 Document the performance measures.

Document the performance measures as a part of business analytical information requirements
which are an integral part of the CDM.
Depending on the nature of the performance measures and project standards, the measures may
be captured in one of the following ways:
As attributes (i.e., derived attributes);
As information facts in Business Analytical Information Tables; or
As entries in a Performance Measurement Documentation Database.
The documentation of performance measures provides a key input to multidimensional data
modeling - the definition of dimension and fact tables in Data Design.
A.8.7 Discuss and confirm with management the performance

measurement entities.
Discuss with management the definitions of the performance measurement entities focusing on
confirming the relevance of the measurement categories and respective measures in supporting
the organization's business analytical/decision support activities. Resolve any questions or issues
and make any changes as necessary.
Page 138
A.8.8 Identify Quantitative Measurement Entities

Purpose
To define the data inputs, outputs and attributes of the quantitative measurement entities that
support an organization's business analytical processing requirements.
Overview
This task defines both the data required and the data generated by the organization's quantitative
analysis processes within the project scope. These quantitative processes were first identified in
the Analyze Business Environment task and further refined in the Identify Quantitative Analysis
Processes task. Although quantitative measures are not traditionally part of the CDM, they often
represent an important part of an organization's business analytical information and processing
requirements and thus should be formally defined and documented.
Quantitative analysis processes and models are documented in this task in the form of
quantitative measurement (QM) entities, which correspond to particular quantitative analysis
models. One QM process can correspond to many QM entities; e.g., the process of sales
forecasting can generate a different quantitative forecasting model for each product or product
class. Each QM entity requires specific data inputs and produces specific data outputs. In
addition, each QM entity has particular characteristics or attributes that should be captured.
The main purpose of the CDM is to define the information content requirements for the databases
being developed. How the data is categorized is sometimes an arbitrary decision. The importance
of clearly defining the QM entities lies in identifying all relevant attributes that play a role as either
inputs or outputs of the quantitative analysis processes. This helps to assure that important
predictive information is gathered and included in the appropriate databases and that the outputs
of the QM entities are properly distributed and used. However, whenever data is referred to in
different types of entities in the CDM (e.g., in the standard CDM entity, performance
measurement entity and/or QM entity), it should be cross-referenced and defined in only one
place to ensure data definition consistency.
A.8.9 Identify and define the quantitative measurement data.

Review the analytical processing business rules identified during the completion of the CDM as
well as the quantitative analysis processes identified during the Analyze Business Environment
and Identify Quantitative Analysis Processes tasks.
For each QM entity, define:
Its data inputs, data outputs and relevant entity attributes;
The business objectives supported by the entity; and
The manner in which the outputs will be used and interpreted.
The data inputs of QM entities may contain various types of data including:
Data generated through business operations such as:
customer transaction histories,
product cost data,
product defect data from the quality control process, and
advertising expenditures by market and channel; and
Data purchased or gathered specifically to support quantitative analysis processes such
as:
purchased demographics data of customers or prospects,
census data,
survey research data, and
Page 139
competitor pricing data;
The data outputs of QM entities are also of various types and some examples include:
Estimated probabilities of default for individual bank loans;
Sales forecasts for individual products in specific markets;
Vehicle routing schedules that minimize total transportation costs; and
Targeted lists of prospects for direct marketing campaigns.
The definition of the QM entities should include information such as:
The knowledge worker(s) or analyst(s) responsible for the entity;
The model performance measures (e.g., statistical confidence measures);
The model parameters (e.g., regression coefficients); and
The quantitative techniques used (e.g., neural networks, optimization algorithms).
Thus, the scope of QM data is broad and may overlap that of other entities. In particular, the data
inputs and outputs of the QM entities are often attributes of other entities in the CDM and may
also be classified as performance measures.
A.8.10Document the quantitative measurement data.

Document the quantitative measurement data as a part of business analytical information
requirements which are an integral part of the CDM.
A.8.11Complete a structured walk-through of the quantitative measurement

entities.
Discuss with management the identification and definitions of the QM entities focusing on
confirming the relevance of the measurement categories and respective measures in supporting
the organization's business analytical/decision support activities. Resolve any questions or issues
and make any changes as necessary.
Page 140
A.8.12Identify Unstructured Data Entities

Purpose
To identify the unstructured data entities required to support an organization's business
information needs.
Overview
This task identifies and defines the unstructured data entities required to meet an organization's
business information needs.
The exhibit illustrates the notion of data structuredness by depicting a spectrum ranging from
highly structured data (e.g., payroll records), to semi-structured data (e.g., financial statements)
and to unstructured data (e.g., news articles or novels). While text data represents a major type of
unstructured data, other types of data may also be required in meeting an organization's
operational and/or analytical information requirements. Specifically, unstructured data can be
characterized as being multimedia in nature and may include data types such as:
Text (e.g., published financial statements including footnotes, comments, service records,
customer or employee complaints, contact records, meeting summaries, reports,
regulations, corporate policies or news articles);
Audio (e.g., speech, music or sound effects);
Images (e.g., scanned images of paper documents, receiving faxes or photographs);
Video (e.g., training materials, marketing presentations, security recordings or media
industry contents);
Desktop application outputs (e.g., Lotus Notes databases, rich text, presentations,
drawings, spreadsheets or schedules); or
Graphical objects (e.g., 3-D models or objects used in animations or interactive
simulations).
With the advances of various multimedia enabling technologies such as data transmission (e.g.,
fiber optics or cable), data compression techniques, special-purpose processors (e.g., video
servers) and improved disk or optical storage capacities, there is an increasing need for an
organization to address unstructured or multimedia data issues in managing its data resource.
Unstructured or multimedia data management issues may fall into one of the following three basic
categories:
Extracting data from unstructured data sources (e.g., extracting specific information such
as new product announcements from news releases);
Efficiently storing the unstructured data (e.g., as Binary Large Objects or BLOBs); and
Delivering data to users in a multimedia format (e.g., a voice presentation).
Page 141
This task focuses on determining the unstructured or multimedia data requirements in terms of
the data sources, the extraction requirements and the output requirements. Data storage issues
are addressed in Data Design as appropriate.
A.8.13Identify the unstructured data elements to be supported by the DW

system.
Review the data requirements to identify any data sources which are unstructured in nature. Data
may be considered as unstructured not only because of its inherent nature but also because the
organization has no control over the format in which the information is supplied (e.g., data
obtained from external sources such as users, customers, suppliers, syndicated third-party data
providers or the Internet).
Determine the characteristics of the identified unstructured data required to meet the business
information needs such as:
The type of information captured in the unstructured data (e.g., competitor financial
results, customer complaints or external news of business event);
Quantitative data that must be extracted from other sources;
Qualitative data that may be available as an individual field or record or which may have
to be extracted;
Data that needs to be converted from data in another medium (e.g., scanning paper
documents into document images); and
Data to be viewed by users one data item at a time or as collections of data items.
If data is going to be viewed as collections of data items, determine the needs for preparing
summary data for the collections (e.g., generating an individual summary for each data item or a
global summary for a collection).
A.8.14Determine the output requirements for the unstructured data.

Determine the requirements for the output data to meet the identified user business needs
considering issues such as:
Format of output data (e.g., text, .XLS or other application format, .GIF file, .WAV file or
video clip);
Attributes to be used as keys for data retrieval;
The maximum time available to process a query;
The required level of completeness (i.e., how important it is that nothing in the original
data source be missed);
The required level of accuracy or precision (i.e., how important it is that everything in the
resulting information be extracted and classified correctly);
The maximum lag time allowed between the time the data is available in the source
system and the time it is ready for use in a query to the DW; and
Any additional requirements e.g., classification or relevance ranking that must be
included in the presentation of query results to users;
A.8.15Identify the input sources for the unstructured data.

Identify the input sources for the unstructured data such as:
Internal source systems;
Customer source systems;
Supplier source systems;
External syndicated data sources; and
Public data (e.g., government, industry or competitor publications).
Determine the properties of the data sources considering:
Page 142
Availability of access mechanisms (e.g., availability of API's, if any);

Restrictions on data redistribution (e.g., copyright and security);
Cost;
Timeliness; or
The frequency with which new data is added or existing data updated.
Determine whether any source data context information is available for verifying the accuracy of
the data extraction processing such as:
Data-provider supplied tags and other uniformities in the data;
Formatting;
Logical structure of the document (e.g., abstract versus text body, titles and headings);
Numbering of items or cross-references;
Arithmetic relationships; and
Fields in semi-structured data.
Determine the input media format such as:
On-line service suppliers (e.g., Dialog, Bloomberg);
World Wide Web (WWW);
Industry databases;
CD-ROM's;
Tapes; or
Diskettes.
A.8.16Determine processing resource constraints.

Determine the constraints of the resources for extracting and transforming the unstructured data
for the DW considering:
The availability of human resources for assisting in processing and verifying the results;
The availability of development resources for building custom data extraction and
transformation software;
The availability of software tools for data extraction and transformation;
The availability of an appropriate software environment for running the custom or
package software;
If the data is compressed or encrypted, the availability of the appropriate decompression
and decryption tools and facilities;
Impact of storage constraints on:
pre-extract,
index, or
extract on demand;
Budget constraints; and
Development timing constraints.
Determine the availability of alternate data sources with different properties such as:
Possibilities for filling in gaps in individual sources;
Possibilities for different points on the resource/quality spectrum; or
Necessity of merging multiple sources.
The difficulties in working with unstructured data dictate that trade-offs may need to be made in
the design process. It is expensive, if not impossible, to achieve complete accuracy in working
with unstructured data. Substantial human involvement is often required if a high degree of
accuracy is needed.
Page 143
The following exhibit illustrates the levels of effort for data transformation based on a paradigm of
internal/external and structured/unstructured dimensions.
Page 144
A.8.17Identify SAP Sources

The purpose of this activity is to identify the required fields from the R/3 system. These tasks try
to identify the source to target mapping from the R/3 to the BW systems.
A.8.18Identify Information in R/3 Sources Necessary to Satisfy

Requirements
The purpose of this task is to identify all information in R/3 Sources (Application Modules FL, FI,
SD, etc.) necessary to satisfy the BW data content requirements.
Procedure
Identify potential SAP R/3 source system data at the functional module level, which could
satisfy unique BW analysis and reporting requirements
Review potential R/3 data sources with Power User, Data Architect/Modeler, and BW
Analysis/Extraction Developer team members
Identify the GOLDEN Source of R/3 system data
Capture Data Mapping and Transformation Rules (i.e., Source to Target Mapping)
Review all documentation for new BW queries and reports (i.e. report mockups and query
samples)
A.8.19Create SAP Data Mapping Document

The purpose of this task is to create the SAP R/3 Data Mapping document. This document will be
developed using the source system details gathered earlier in the requirement gathering process.
The primary objectives of Data Mapping are listed below:
For each dimension attribute and fact attribute, identify the source element(s) that make
up the target data item.
Finalize data format and type of the target after reviewing formats and data type of the
source data items
Identify any code conversion needs and finalize domain values for the target data items.
Procedure
The biggest challenge in developing the BW system is integrating the data from SAP R/3 and
Non-SAP disparate legacy systems/applications feeding the BW system. This task deals with (at
a high level) data mapping activities that support the data extraction processes from the source
systems and its conversion into pure, scrubbed information for populating the BW system.
Steps
Collect data samples from Source System, one sample for each data frequency (i.e., daily,
weekly, monthly, etc.)
The data contained in the various sources may vary per frequency.
Review Source data collections for data availability and determine GOLDEN Source of data
Update data mapping document with actual file or database names.
Study current data collection field formats, data types, etc., and determine reformatting, type
conversion needs, and update data mapping document
Page 145
Identify different methods of moving data from the source systems to the BW system, and
update data mapping document
Define extract processing frequency, will full updates or delta file updates (data changes only)
be performed, before/after images be compared, time-stamped data or log/audit files be used
Update data mapping document.
Determine filtration needs and update data mapping document
Identify summarization requirements and update data mapping document
Review all data models and field layouts for each SAP R/3 reporting environment
Review all reporting documentation for each SAP R/3 data source
Identify the following BW components to satisfy End User requirements:
Characteristics
Key figures
Master Data
InfoObjects
Result
To clearly identify and map applicable SAP R/3 source system data that will satisfy the BW query
and reporting needs.
Page 146
A.8.20Assess Required Non-SAP Data Sources

The purpose of this activity is to Identify Non-SAP Sources. These sources could be Legacy
systems or other operational systems.
A.8.21Identify Data from Non-SAP Sources Necessary to Satisfy

Requirements
Purpose
The purpose of this task is to identify data from Non-SAP sources necessary to satisfy
requirements.
Procedure
Identify all Non-SAP reporting environments found in your organization

Review all data models and field layouts for each Non-SAP reporting environment
Review all reporting documentation for each Non-SAP
Identify the following to satisfy end user requirements:
Characteristics
Key figures
Master Data
InfoObjects
Result
To clearly identify data from Non-SAP sources necessary to satisfy end user requirements.
A.8.22Develop Plan for Capturing Non-SAP Source Data into Flat Files
Purpose
The purpose of this task is to develop a plan for capturing Non-SAP source Data into Flat Files.
Consider utilization of 3rd party Extract and Transform tools (see ETL Strategy Document).
Procedure
Create a plan for each source system

Document a flat file layout for source system
A.8.23Assign Resources to Obtain the Data

Purpose
The purpose of this task is to assign resources to obtain the data.
Procedure
Identify specialists in each of the source system

Estimate the length of time required to obtain the data from each source system
Assign them to the project plan
Result
Flat files will be generated to load into BW
Page 147
A.8.24Create Non-SAP Data Mapping Document

Purpose
The purpose of this task is to create the Non-SAP Data Mapping document. This document will
be developed using the source system details gathered earlier in the requirement gathering
process
.
The primary objectives of Data Mapping are listed below:
For each dimension attribute and fact attribute, identify the source element(s) that make
up the target data item.
Finalize data format and type of the target after reviewing formats and data type of the
source data items
Identify any code conversion needs and finalize domain values for the target data items.
Procedure
The biggest challenge in developing the BW system is integrating the data from SAP R/3 and
disparate Non-SAP legacy systems/applications feeding the BW system. This task deals with (at
a high level) data mapping activities that support the data extraction processes from the source
systems and its conversion into pure, scrubbed information for populating the BW system.
Steps
Collect data samples from Source System, one sample for each data frequency (i.e., daily,
weekly, monthly, etc.)
The data contained in the various sources may vary per frequency.
Review Source data collections for data availability and determine GOLDEN Source of data
Update data mapping document with actual file or database names.
Study current data collection field formats, data types, etc., and determine reformatting, type
conversion needs, and update data mapping document
Identify different methods of moving data from the source systems to the BW system, and
update data mapping document
Define extract processing frequency, will full updates or delta file updates (data changes only)
be performed, before/after images be compared, time-stamped data or log/audit files be used
Update data mapping document.
Determine filtration needs and update data mapping document
Identify summarization requirements and update data mapping document
Review all data models and field layouts for each Non-SAP reporting environment
Review all reporting documentation for each Non-SAP reporting environment
Identify the following BW components to satisfy End User requirements:
Characteristics
Key figures
Master Data
InfoObjects
Result
To clearly identify and map applicable Non-SAP source system data that will satisfy the BW query
and reporting needs.
Page 148
A.8.25Identify Master Data Requirements

Purpose
The purpose of this task is to identify R/3 and Non-R/3 master data that is required to fulfill the
end user requirements. Also, resources are identified to obtain master data.
The master data sources fields and the master data merging strategy should be clearly defined.
Master data can be sources from multiple R/3 and Non-R/3 systems.
A.8.26Create Master Data Requirements Document

Purpose
The purpose of this task is to create Master data requirements document. Data is stored in BW
Master Data tables to reduce data redundancy. There are various ways of accessing Master
Table data, each unique requirement for access must be defined within the requirements
document.
Procedure
Define Master Data Table Requirements

End User Requirements Document
It is important to define the End User requirements for NAVIGATION, using master data
tables. A master data table normally exists for each characteristic in a dimension table, except
for some characteristics in the required dimensions, namely time, unit, and packet. The
attributes in a master data table may be referred to as navigational attributes, such as drilldown, up, across, or within. From a reporting point of view, they behave like characteristics.
Changes to the values of a characteristic in a dimension table and a navigational or reporting
attribute located in the associated master data table for the characteristic can be applied by
supplying the valid from and valid through attributes in the master data table.
BW Data Mapping Document

Modeling Master Data Issues to consider
In the BW star schema, attributes are separated into InfoCube-dependent attributes called
characteristics that are assigned to the dimension tables, and InfoCube-independent
attributes that are primarily stored in the Master Data tables.
The use of InfoCube-independent tables like the master data tables is one step toward and a
prerequisite for an enterprise-wide data warehouse because the master data table for a
characteristic only exists once. This is a definite advantage in integration and architecture.
Shared master data tables allow for easy handling of "slowly changing dimensions".
A master data table is not required for each characteristic. In the definition of an InfoObject
the choice is optional as to whether or not there shall be a master data table for the
characteristic. This applies for the characteristics belonging to the required dimensions for
time, unit, and packet.
Result
A clearly defined Master Data Requirements Document
Page 149
The master data source fields and the master data merging strategy should be clearly defined.
Master data can be sources from multiple R/3 and Non-R/3 systems.
Page 150
A.8.27Determine Data Transformation Requirements

Purpose
To determine the rules for transforming the source data into the identified analytical data to be
maintained in the DW.
Overview
This task is a key task in the BW Methodology. It is used to determine the data transformation
requirements which specify for each analytical data element:
The source data (including both internal and external data);
The derivation rules used in creating the target data; and
The update, maintenance or refresh requirements.
The data cleansing can be performed by developing transformations, aggregations, filtering and
identifying the grain of extracted data.
A.8.28Define Transformation Rules

Purpose
The purpose of this task is to identify the transformation rules to be used for key figure (facts),
characteristics, master data and hierarchies.
Overview
Summarize the analytical processing information needs determined in the previous tasks. The
information needs may be clustered, for presentation purposes, based on similarity of need or
type of analysis. There may not be a one for one correlation between clusters and particular
analysis functions. In fact, the information needs may be common to many different user groups
within an organization through the required levels of summarization or aggregation may vary.
Develop a high-level understanding of the data transformation requirements in terms of:
The business events that originate the analytical data to be captured in the DW. Consider the
following as appropriate in defining the business events:
Frequency(i.e., how often the event occurs),
Periodicity (e.g., whether data is captured daily, weekly, monthly, quarterly), and
Source(s) of data;
The analytical data of interest;
The source data providers (from both business and technical perspectives);
The relevant data transformations;
The different user views of the analytical data;
The target performance measures or their components; and
The relevant analysis reports.
Review the definitions of the analytical data. In particular, focus on the definitions of the
performance measurement, quantitative measurement and unstructured data entities.
Determine the derivation rules for each of the analytical data elements identified for inclusion in
BW, specifying such information as:
The source data (including the source systems generating the data);
Page 151
The rules for mapping the source data to the target analytical data (e.g., calculation or
aggregation); and
The strategies for resolving conflicts between different data sources regarding data definitions
or values.
Result
The exact flow of key figures, characteristics, master data and hierarchies from the source
system to an InfoObject in a report is clearly defined. All aspects of the of this data for end users
should be reviewed and clearly documented in the Data Conversion Document.
A.8.29Define Aggregation Rules

Purpose
The purpose of this activity is to identify the aggregation rules to be used in BW. Aggregate tables
can be created to speed up end user access to BW Work Books.
Procedure
Review all key figures, characteristics and hierarchies that can benefit from adding aggregate
tables
Review all combinations of key figures, characteristics and hierarchies that can benefit from
adding aggregate tables
Result
The exact number of aggregate tables to be created in the production environment should be
defined and documented in the Data Conversion Document.
A.8.30Define Prestaging Requirements

Purpose
The purpose of this activity is to identify the Pre-staging requirements for key figure (facts),
characteristics, master data and hierarchies. Cleansing is considered as the process of
normalizing the data entering BW, completing the Unit of measure conversion, smoothing out
currency anomalies, and more.
Procedure
Identify how the pre-staging process can be accomplished. Some pre-staging methods are:
Loading data into flat files and using utilities to cleanse the data.
Store the data in an database and cleanse the data using programs
A.8.31Define Granularity Rules

Purpose
The purpose of this task is to identify the granularity rules to be used for key figure (facts),
characteristics, master data and hierarchies in BW.
Procedure
Review the following documents for granularity requirements for each InfoObject:
End User Requirements Document
Current Data Warehouse and Information Access Environment Document
Page 152
SAP Data Mapping Document
Non-SAP Data Mapping Document
Master Data Requirements Document
Identify granularity rules for each InfoObject in the BW
Some data warehouses summarize data from monthly to quarterly for older years. Therefore,
year1 through year 2 hold monthly granularity data. But, year 2 through year 5 data is lightly
summarized, it is stored at the monthly level.
Some of the granularity are decisions to be made are:

How many years worth of data should be stored? The typical data warehouse can
contain 2-5 years of data.
How do we roll off data? There are 2 options: delete or archive the data to be rolled
off
A.8.32Estimate Volume
Purpose
The purpose of this task is to identify the size and growth estimates of the target production
database.
Procedure
Identify the disk space required for each InfoObject

Identify the disk space required for aggregates, ODS and all other non-InfoObjects
A.8.33Define Filtering Rules

Purpose
The purpose of this task is to identify the filtering rules to be used for all InfoObjects.
Procedure
Identify filtering rules for all InfoObjects entering BW
The exact filtering rules for each InfoObject is clearly defined. All aspects filtering rules for this
data should be reviewed and clearly documented in the Data Conversion Document.
A.8.34Complete structured walk-throughs of the data transformation

requirements.
Complete structured walk-throughs of the findings, issues and recommendations for the data
transformation requirements to ensure their relevance and completeness.
Ensure that the requirements are in a format suitable for input to the Data Transformation System
Design and the Presentation System Design Phases. Resolve any questions or issues and make
any changes as necessary.
A.8.35Discuss and confirm the data transformation requirements with

management.
Discuss the data transformation requirements with management. Resolve any questions or
issues and make any changes as necessary.
Page 153
A.8.36Validate Process/Data Definitions

Purpose
To ensure that the deliverables produced during the Analysis and Decision Process Definition
Phase are complete, consistent and supportive of the business objectives of the organization.
Overview
Deliverables from this phase and the Analysis and Decision Process Definition Phase are brought
together and validated against each other to ensure that all of the appropriate views of the
business have been documented and are complete.
A.8.37Confirm the consistency and completeness of the process and data

models.
Confirm the completeness and consistency of entity and attribute identification in the CDM
through:
Cross-checking the data view, access and presentation requirements of the analytical
processes against the entities and assigned attributes in the CDM; and
Cross-checking the output views of the DW system (e.g., in terms of any prototyped
screens and reports and interface requirements) against the entities and assigned
attributes in the CDM.
Completeness of relationship identification may be independently confirmed by considering the
contents and structure of the DW system outputs. For each of the major system outputs, identify
which data element(s) represent the "key" to each grouping of data required by the output. The
structure of the groupings of data should be demonstrative of relationships in the CDM.
If the relationships between the data and process models are inconsistent, conduct further
analysis to reconcile the two views and modify the process descriptions and/or the analytical
processing data definition as appropriate.
A.8.38Confirm the data transformation requirements.

Review and confirm the data transformation requirements following the reconciliation. Ensure that
the information needs of the performance measurement, quantitative analysis and/or ad hoc
analysis processes are properly supported by the data definition. Make any adjustments as
necessary.
Page 154
A.8.39Submit Data Definition Deliverable

Purpose
To provide a checkpoint where the analytical processing data definition deliverable can be
reviewed and verified.
Overview
The outputs from the individual tasks are consolidated into an analytical processing data
definition deliverable. These deliverables are reviewed for content and clarity and presented to
management for confirmation and formal written approval.
A.8.40Partition the development of the CDM (only for large complex data
models).
For large complex data models, the process of building the CDM may be easier by building
separate, smaller CDM pieces. Each component CDM is built from a copy of the ERM.
The identification of data elements is achieved by review of the processes. Each process is
assigned to one and only one component CDM. The number of processes determines the
number of component CDMs that need to be created. The processes can be partitioned based on
their logical relationships such as common activities and transaction types of common subsystems. This partitioning process is not necessary for simpler data models as all entities can be
accommodated on one CDM.
Where necessary, complete the partitioning of the CDM.
A.8.41Consider ramifications of large volumes of data.

Where there will be large volumes of data in the DW system, it may be necessary to test the data
design through a proof-of-concept test.
If not already addressed in a Technology Pilot, this test may need to address such issues as:
Use of parallel processing architectures;
Use of specific tools/approaches;
Use of compression techniques; or
Use of different types of storage devices.
Determine whether additional steps will be required to address the volumes of data to be used in
the new system.
A.8.42Conduct structured walk-through of the CDM.

Conduct a peer group review of the CDM including the performance measurement, quantitative
measurement and unstructured data entities to check the model for logic, consistency and
adherence to standards.
Ensure that the model contains complete entity definitions, cardinality and optionality notation and
check for invalid relationships.
Note: The CDM does not require complete attribute definitions.
Review the model to reflect any problems identified in the walk-through. Issues that arise and are
unresolved should be routed through the issue resolution process.
Page 155
A.8.43Specify the database scope.

Specify the scope of the data to be included in the system. Entities which are excluded should be
listed or a scope boundary should be shown on the model. This procedure is important when the
CDM is derived from an Enterprise Data Model.
Further definition of data to the physical implementation should not be completed for entities
which are outside of the DW system.
A.8.44Assemble and review analytical processing data definition

deliverable.
Package the various components of the analytical processing data definition deliverable.
Review the analytical processing data definition deliverable focusing on content of the CDM and
clarity of presentation.
A.8.45Submit and discuss the analytical processing data definition

deliverable with management.
Discuss the analytical processing data definition deliverable with management and resolve any
questions and issues. If necessary, prepare an action list of items to modify. This step may
involve more than one meeting.
A.8.46Obtain formal written approval of the analytical processing data

definition deliverable.
Page 156
A.9
Business Blueprint Definition Checkpoint
Purpose
To confirm the results of the Business Blueprint Definition stages (Analysis and Decision Process
Definition, Analytical Processing Data Definition, and the Technology Definition) with
management. Additionally, in this Phase, the CPDEP Phase 2 task of Generate and Select
Alternative(s) is completed, and a recommendation and Class 2 Estimate provided for the
DRB/GRT.
Overview
Reviews.
update the plan with any required modifications.
In the Design Checkpoint, many of the items fall into the first category. Items such as project
background, change and issue resolution procedures, project organization and much of the
contractual information will generally change little.
Business Blueprint Definition Checkpoint Task Relationships
P r o c e s s d e f in it io n d e liv e r a b le
D a t a d e f in it io n d e liv e r a b le
I1
o f t h e B u s in e s s
B lu e p r in t D e f in itio n
O p e n Is s u e s
I2
I3
U p d a te P r o je c t a n d
Q u a lit y P la n s
Page 157
C o n f ir m e d B u s in e s s B lu e p r in t D e fin itio n S ta g e
D e liv e r a b le s
U p d a te d p r o je c t a n d q u a lit y p la n s
A.9.1 Confirm Completeness of the Business Blueprint Definition

Purpose
To complete an integrity check of the Business Blueprint Definition deliverables.
Overview
The data, process and technology definition work products developed during the Business
Blueprint Stage are discussed with management. The focus is on confirming the completeness of
the results and findings and determining their impact on the project.
A.9.2 Confirm the completeness of the data, process and technology

definitions with management.
Discuss and confirm with management the completeness and accuracy of the data, process and
technology definitions including:
The descriptions of the analysis and decision processes (including the performance
measurement, quantitative analysis and any ad hoc analytical processes);
The data requirements in supporting the analysis and decision processes (including the
CDM and analytical processing data entities);
The data access requirements of the analysis and decision processes; and
The technology definition (including the IT infrastructure requirements, strategies and
standards, IT infrastructure alternatives, selected IT infrastructure and Technology Pilot
requirements, as applicable).
Resolve the issues as possible and document any outstanding issues to be addressed by the
Issue Resolution Process.
Page 158
A.9.3 Review Issues

Purpose
Overview
A.9.4 Review and resolve any outstanding issues.

Assess the impact of any outstanding issues and reflect in the plans and risk assessment.
A.9.5 Agree approach to outstanding issues.

Page 159
A.9.6 Update Project Charter and Project Plan

Purpose
To update the Project Charter and Project Plan based on the findings and information obtained
during the Business Blueprint Definition Checkpoint.
Overview
This task updates the Project Charter and Project Plan to reflect the impact of the findings
obtained in the Business Blueprint Definition Checkpoint.
A.9.7 Validate overall project cost and time estimate.

Seek formal written approval for any actions to be taken and revise plans accordingly.
A.9.8 Review and revise Project Risk Assessment.

Review the Project Risk Assessment documentation that has been maintained throughout the
project. Consider:
before?
assumptions?
project?
Have advances in the marketplace (e.g., new versions of software) significantly affected
the project?
A.9.9 Review project risk dimensions.

Identify where the risk ratings described in the Project Risk Assessment are higher than expected
or are greater than originally anticipated. Obtain agreement with management on the appropriate
actions to take.
Page 160
A.9.10Revise risk management approach.

Review the Project Risk Assessment to identify any changes from the initial assessment. For
identified threats, document:
Page 161
A.10 Data Transformation System Design

Purpose
To convert the data transformation (DT) system requirements determined during the Business
Blueprint Stage into a set of technical design specifications.
Overview
This phase translates the data transformation requirements, defined during the Analytical
Processing Data Definition phase, into a set of technical specifications for the DT system.
Data transformation is the process of transforming source data to target DW data. The key
components of a DT system include:
Data extracting;
Data cleansing/scrubbing (Transfer rules/routines);
Data transforming (InfoSource integration);
Data transfer;
Data refreshing, update and maintenance; and
InfoCube monitoring.
Data Transformation System Design Task Relationships
C o m m o n D e s ig n s ta n d a r d s
U s e r In te rfa c e P ro to ty p e
J2
D e v e lo p D a t a E x tr a c t
S y s te m In te rfa c e
D e s ig n
J1
D e v e lo p H ig h - le v e l
D a ta T r a n s fo r m a tio n
S y s te m D e s ig n
J3
D e v e lo p D a t a
T r a n s f o r m a tio n
S y s te m In fo S o u rc e
D e s ig n S p e c if ic a tio n s
S y s te m D ia g r a m
In te r fa c e D e fin it io n s
C u s to m E x tr a c t P r o g r a m L o g ic S p e c s
I n t e r f a c e A c c e s s a n d S e c u r it y D e f in it io n s
(u p d a te d )
H ig h - le v e l D a ta T r a n s f o r m a t io n S y s t e m D e s ig n
J4
D e v e lo p D a t a
C o n v e r s io n D e s ig n
S p e c ific a t io n s
D a t a C o n v e r s io n D e s ig n S p e c ific a t io n s
D a t a C o n v e r s io n P r o g r a m S p e c if ic a t io n s
D a t a C o n v e r s io n U n it T e s t P la n s
I n f o S o u r c e S p e c if ic a t io n s
T r a n s fe r R o u tin e S p e c ific a t io n s
U n it T e s t P la n s ( I n it ia l)
J5
S u b m it D a t a
T r a n s f o r m a tio n
D e liv e r a b le
Page 162
D a t a T r a n s f o r m a t io n S y s t e m D e s ig n D e liv e r a b le
A.10.1Develop High-level Data Transformation System Design

Purpose
To develop a high-level system design for the DT system.
Overview
This task develops a high-level design of the DT system which shows:
A DT system architecture depicting:
the DT system components,
the other components of the DW system,
the internal source transaction processing systems, and
any external data source systems;
The interfaces between the various components of the DT system showing both:
custom developed DT components, and
tool-supported/generated DT components;
Design specifications for the tool-supported DT system components; and
Design specifications for the custom developed DT system components.
This task discusses the DT design steps in terms of the basic components of a DT system
including the:
Extractors;
InfoSources from Data Sources;
PSA and staging, Scheduling;
ODS and InfoCubes, Master Data, hierarchies, and text; and
Monitoring.
The BW High Level Architecture Diagram (following page) shows the key components of the BW
architecture. The top of the diagram depicts which components are addressed by key phases
and tasks of the methodology.
Page 163
BW High Level Architecture Diagram

High Level Transformation Design (DWA)
Data
Data Transformation System Design (ET/DT/DWA)
Design (DWA)
Custom
BW Administrators Workbench
Extract Build
System Construction (DT)
(ET)
Legacy
System
Source Systems
PSA
Inf
o
C
ub
es
Legacy
System
E
xt
ra
ct
Legacy
System
Update
Rules/
Routines
Queries/
Reports/
HTML
BEx
Anal
yzer
Legacy
System
In
te
rf
ac
e
E
nv
ir
o
n
m
en
t
Pr
ot
oc
ol
Legacy
System
Transfer
Rules/
Routines
InfoObjects
O
L
A
P
E
ng
in
e
Non R/3
Tr
an
sf
er
St
ru
ct
ur
e
(D
at
a
S
ou
rc
e)
BAPI/3rd Party
BW Business Explorer Construction (PT)
BEx
Bro
wser
Non R/3
C
o
m
m
un
ic
ati
on
St
ru
ct
ur
e
(In
fo
S
ou
rc
e)
tRFC
SAP R/3
Presentation System Design

(PT/DWA)
Scheduler/Monitor(InfoPackage)
Business Information Warehouse

Page 164
Users
D
at
a
C
on
ve
rsi
on
Bl
ue
pri
nt
an
d
R
ea
liz
ati
on
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting

A.10.2Develop a System Architecture Diagram for the broader system

environment.
If not already prepared earlier, develop a System Architecture Diagram for the broader system
environment showing:
The interfaces between the DT system and other components of the DW system;
The interfaces between the DT system and its internal/external source feeder systems;
and
The interfaces among the components within the DT system.
The DT system architecture should depict key design characteristics such as:
What types of transformation processing are occurring where (e.g., business rule
processing and logic distribution guidelines);
What role the data staging area (if one is used) plays in the DT process; and
What role the ODS (if one is used) plays in the DT process.
A.10.3Design data extract system component.

Analyze data extract processing requirements:
Review Conceptual Data Model (CDM);
Analyze data sources;
Confirm data required is available or can be created from data sources:
select inclusion/exclusion criteria, and
identify and document data gaps with Business Content extractors;
Define/refine common extract structure;
Analyze data source cleansing requirements;
Develop resolution strategy for data integrity/cleansing/formatting issues;
Resolve data integrity, cleansing issues/formatting;
Map data elements from the source systems to the common extract output format;
Develop algorithms for cleansing, integrity checking, formatting;
Determine the data cleansing and quality assurance strategy for external source data
considering alternatives such as:
data cleansing and quality assurance is the responsibility of the source data provider,
data cleansing and quality assurance of external source data is part of the data
extraction function, or
external source data is not subject to the same cleansing and quality assurance
requirements as the internal source data;
Review/refine processing volume estimates for the extract system:
evaluate historical data requirements and volumes,
develop a processing model for extract system,
historical data may require a one time stand alone extract conversion process, and
the current system data extract processing model will be ongoing; and
Assemble and document the extract system processing requirements.
A.10.4Determine Uses of Pre-Configured InfoSources.

Purpose
The purpose of this activity is to determine uses of SAP pre-configured InfoSources.
Page 165

Procedure
Review the end user requirements

Identify pre-configured InfoSources
Maintain Communication Structure
Maintain Transfer Rules
Result
Utilize the existing sources for a better performance
A.10.5Identify New InfoSources to be Created.

Purpose
The purpose of this activity is to identify new InfoSources from Non-R/3 system. The new
InfoSource can also be the master data from Non-R/3 system.
Procedure
Identify information in Non-R/3 sources necessary to satisfy requirements

Create user defined InfoObjects, Characteristics and Key Figures
Create data mapping document
A.10.6Design data transform system component.

Analyze data transform processing requirements including:
Integration DataSources to InfoSources;
Attribution of master data;
Translation of source data;
Calculation of derived business InfoObjects;
Aggregation of summary data;
Synchronization for currency or update; and
Indexing or parsing mechanisms for accessing unstructured data.
A.10.7Design data transfer system component.

Analyze the data transfer processing requirements:
Review the extract system process model with respect to source system:
volumes,
capacity,
timing,
technology, and
geographic distribution;
Review the transform system process model with respect to data destination platform for
processing:
volumes,
capacity,
timing,
technology, and
geographic distribution;
Analyze data transfer requirements for DW processing architecture;
Review potential physical data distribution requirements and target data destination
platform for access;
Page 166

Analyze DW physical data distribution requirements;

Develop model for data transfer processes;
Integrate data transfer processing model with DW processing models; and
Analyze volumes, complexity, modularity, processing resource requirements and
administration/maintenance requirements of the transfer model.
A.10.8Design data refresh/update system component.

Determine for each source system a data refresh/update strategy governing the timing and
approach in updating the DW with changes in the source system. Some of the alternative DW
refreshing approaches include:
Tightly coupled synchronous replication where data is updated in the DW by the same
transaction as it updates the source operational system;
Loosely coupled synchronous replication where DW data should be updated by the same
transaction but, due to some constraints, the update is left pending on a log for later
processing; and
Asynchronous replication where DW data is updated off-line, usually in batch processing
at night.
A.10.9Design end-of-period update system component.

Determine the end-of-period updating requirements for the DW including:
Adding/changing/deleting data to InfoCubes, ODS, and master data;
Archiving data;
Refreshing data;
Replicating data;
Completing audit procedures; and
Completing period-end closing processes including:
tax year-end,
calendar or fiscal year-end (e.g., rolling year considerations), and
quarter or month-end.
Some of the factors affecting end-of-period update processes include:
Data dependencies;
Availability of data;
Volumes of data; and
Balancing requirements.
A.10.10
Determine the audit and monitoring requirements of the data
transformation system.
Determine the audit and monitoring requirements of the DT system.
The requirements to be considered for the three DT system components include:
Data extract audit requirements:
audit and control points based on the extract system processing model,
high-level audit and control requirements and generalized format,
mapping selected data elements to audit/control requirements/formats,
requirement rules for audit processing including selection/creation/conversions to
common extract output requirements/format,
extract system conversion requirements for audit/control reports including control
totals (e.g., record totals, value totals, hash totals, file control record comparisons),
integrity errors, cleansing errors, range checking, data change reporting,
Page 167

recommended model for the actionable extract system audit processing, and
management approval of the extract system audit processing model;
Data transform audit requirements:
audit and control points passed on to transform system sub-processes and the
overall process flow and sequence,
high-level audit and control requirements,
generalized format for audit/control data,
mapping selected data elements to audit/control requirements and formats,
rules for audit/control processing including selection/creation/conversion from
common extract formats to data transform output formats,
data transform conversion requirements to define audit reports including control
totals, integrity errors, data transform sub-processing errors and data change
reporting,
recommended model for the actionable transform system audit processing, and
management approval of the transform system audit processing model; and
Data transfer audit requirements:
audit and control points based on the data transfer process model,
high-level audit and control requirements and generalized format,
mapping of selected data elements to audit/control requirements format,
data transfer audit and control reports detail,
volumes, complexity, modularity, processing resource requirements and
administration/maintenance requirements of the transfer module,
recommended model for the actionable transfer system audit processing, and
management approval of the transfer system audit process model.
Determine whether any encryption or other protection is required for sensitive or confidential data
which is contained within the transformation process. If required, define the selected approach.
Develop an approach for providing feedback to the source data provider concerning the usability
and quality of the source data. Some of the alternatives include:
Correcting the source data directly in the source data system;
Correcting the source data through normal operational transactions (e.g., using a
reversing/correcting transaction pair); or
Not responsible for correcting the source data but maintaining a cleansed and integrated
operational data store.
Correcting source data is often a sensitive organizational issue. Different approaches may be
appropriate for different source data systems.
A.10.11
Evaluate data transformation system design.
Evaluate design integration, modularity, maintenance and performance characteristics.

Modify any deliverables that have changed as a result of the technical design.
Ensure that potential changes do not alter the scope of the application. Scope changes should be
documented through the Issue Resolution process and agreed between project management and
user management and/or escalated to the steering committee for resolution.
Discuss and agree the high-level DT system design with management. In some circumstances,
the use of the structured walk-through technique may be applicable.
Obtain formal written approval.
Page 168

A.10.12
Develop Data Extract System Interface Design
Purpose
To identify and specify the interface requirements for data extraction from the source systems,
both existing and proposed.
Overview
This task develops the specification for data extraction from the source feeder systems. These
requirements will need to include a provision for any ongoing balancing procedures that may be
required.
A.10.13
Refine the interface requirements for data extraction from the
source systems.
Review the Management Overview Diagram(s) or other Abstract diagrams/documentation to
confirm which interfaces are required. Include also the refresh/update interface requirements.
Obtain and review any requirement or design specifications that have been prepared as outputs
from the Prototyping Phase.
Identify the data elements that will be extracted.
Define the file layouts or extract structures for each interface required as input to and output from
the new system.
The aim should be for input files to provide data to the data extract system in a form that can be
processed through the normal input programs and validation routines in the same way as any
other input data.
A.10.14
Review interface source systems.
When designing interfaces, it is imperative that a careful review of each source system is
completed (i.e., the system that will provide the interface input). The review should address:
Level of detail - whether the system is capable of generating the necessary information at
the appropriate level of detail or whether some additional interim processing will be
needed (e.g., does a payroll system provide pay information at a departmental total level;
at an individual employee pay level; or at an individual employee pay level sub-divided by
job);
Information availability - whether all of the data required for input is able to be generated
and in the appropriate format (e.g., for an interface to a general ledger system, does the
source system provide records or data for each type of financial transaction completed or
are some transaction types ignored?);
Internal integrity - whether the source system balances within itself (e.g., for an inventory
system: opening balances + receipts - issues +/- adjustments = closing balance or with
an accounts payable system for each check run: opening balance value - invoices paid +
credit notes adjusted +/- adjustments = closing balance value) and reports are available
from the system with this type of information to assist with the ongoing balancing of the
new systems, both for reconciliation purposes and for error correction if the systems do
not balance;
System maintenance - whether the source system is properly maintained to ensure data
integrity (e.g., DBMS integrity utilities are regularly run to ensure that any corrupted data
is corrected);
Page 169

Validation/error checking - whether the input validation and error checking for the source
system itself is sufficient to prevent inaccurate or incomplete data from entering the
source system and thus the interface; and
Currency/timing - whether the source system is kept current and up-to-date and that the
interface data is available with the desired timing on a consistent basis both during the
financial year and at year-end.
Review each source system. Where current systems are either old or poorly documented, this
may require considerable effort or an alternative approach (e.g., use of software reengineering
tools to re-document the system).
Similar considerations are required for interfaces that are output files from the newly developed
system and the integrity of the systems which will receive any interface output files.
A.10.15
Determine system interface approaches.
Determine appropriate system interface approaches considering:

Interfaces that require special programs to be written to ensure that the data is at the
appropriate level of detail and in the right format for input;
Interfaces that receive data from subsidiary systems, that are then reformatted using online editors or utilities and then input to the system using the normal input transaction
processing routines;
Micro-host links that can be a proprietary third-party product; or
Translation software packages.
Determine whether a temporary data store should be used as a staging area in the data
extraction process considering factors such as:
The complexity of the data extraction/transformation process (e.g., a temporary data
store may be used as a staging area to synchronize and simplify the process of
aggregating data from multiple sources); and
The cost of communications between the DT system and the data warehouse (e.g.,
instead of sending bulk data directly from the source systems to the data warehouse,
only smaller amounts of aggregated data may need to be communicated if a temporary
data store is used to stage the "raw" source data).
The work effort and tasks to create the various interfaces will vary by the type of interface to be
used, as will the technical specialist skill mix required.
For instance, if the interfaces are acquired from a software supplier, they should be checked to
ensure that they are complete. A detailed functional specification and software package
evaluation may be required and some of the issues to be addressed in this instance may include:
At what level of detail is the interface provided;
Control totals provided or not;
Validation required and provided;
Audit trails provided and, if so, what data is included;
Whether any options are provided;
Speed of processing;
Recovery/restart routines;
Job control language provided or not;
Testing issues;
Source system reconciliation/output of data issues;
Receiving system requirements to be created; and
Documentation accurate and sufficient.
Page 170

A.10.16
Design each interface.
Design and document each interface including the access and security definitions and Unit and
Component Test Plans. Also include the design for the data refresh/update interface.
Determine the volumes of records for each interface and also the timing and availability of the
data (e.g., daily, weekly or monthly). Also determine whether there are variations in volumes
caused by such items as holidays, peaks (e.g., summer), month-end or year-end.
The volumes may also impact upon the timing of the interfaces (e.g., if the interface is only
required weekly or monthly but this will cause interim storage or processing difficulties and it may
then be necessary to run the interface on a daily basis to improve efficiency).
Define the ongoing interface system balancing:
Identify potential changes in the organization's methods of operation that are likely to
occur as a consequence of implementing a new system and the interface balancing
impact of these changes;
Ensure that the ongoing integrity of the system is maintained by establishing and
documenting the procedures for reconciliation and balancing of the interface data.
Consider:
interface sub-system balancing (e.g., the integrity of the source system before the
interface data is presented),
internal data completeness of the new system application itself (e.g., total opening
balance plus receipts minus issues plus/minus transfers plus/minus adjustments
equals closing balance), and
physical record numbers through such means as run activity control numbers for both
the source and receiver systems; and
In addition to the technical design, define the clerical procedures to ensure that the
system is continually reconciled. This should include the responsibilities and tasks that
must be completed:
daily,
weekly,
monthly, and
year-end.
Define the interface program/procedure specifications. Where special programs need to be
written to provide interfaces or where existing sub-systems need to be modified to produce
interface data with the correct degree of integrity and at the appropriate level of detail, prepare
program design specifications.
For BW, interface designs can follow one of the following approaches, and can depend primarily
on the nature of data transformation requirements and source data analysis:
Utilize standard Business Content extractors: In this case, no extra design work is
necessary apart from the previously mentioned interface system balancing concerns and
reconciliation procedures. The extractors should already have been installed previously
during the Technology Planning, Support, and Cutover phase.
Extend Business Content extractors: In cases where the standard content extractors do
not provide all of the necessary data elements to be brought into the BW, develop
specifications that define which new data fields to add to the extractors. Follow the
necessary steps as defined in the THE SERVICE ARM OF THE FIRM BW Cook Book or
documentation to add the proper fields and refresh the meta data in BW.
Page 171

The extractors may not always be extendable. This can depend on if the new fields come
from the same basic structures that are sources for the existing content extractor. If the new
fields come from different tables, and new source system data modeling must be considered,
the Generic Data Extractor should instead be used.
Generic Data Extractor: Using the source system analysis from the Data Definition and the
high level designs, develop specifications for building DB views or ABAP/4 Query
specifications as sources for the Generic Data Extractor.
ETL tool: If none of the above meets the project requirements for source data extraction,
and an ETL tool has been selected and chosen, follow the specific tool guidelines and
approaches in developing or generating extraction programs.
Custom ABAP extraction: The following steps represent standard interface design
considerations from an R/3 system. Follow any standards in place for non-R/3 systems being
interfaced from:
1. Identify the data which has to be exchanged: The data of the business transaction and the
way the data has to be exchanged must be determined for each interface based on the
business objects. The structure and typing of the data could be pre-determined by R/3
interface definition or there are recommendations for their handling (see specific scenario
with its business objects in the "Interface Advisor").
If there is no business scenario that was used, an own structuring of the data could be used
filled from specifically identified data sources in SAP (outbound) or for SAP (inbound). The
use of standard formats and structures is recommended (e.g. the SAP IDOC container
structure). In certain cases it may be beneficial to use a newly defined data structure.
Standard structuring becomes more important when many different systems interact with
each other. There are certain vendors for conversion software offering various interfacing
techniques and arbitrary formats for data exchange with external systems.
2. Determine the roles of the systems and how the data handling has to be done: There are two
basic types of requests passing through an interface:
(1) requests for processing the passed data in a remote system and
(2) requests for getting information for analysis purposes.
Both types of request could be addressed by one single interface. The data transfer for
requests processing data in a distributed transaction has to keep the data consistent. Several
processing issues have to be considered on this subject.
Specific parts of a data form logical units of work (LUW) for data integrity reasons: Creating
the transfer data and maintaining the application data in the sending system, sending data
and setting the status of the transmission, in the receiving system update the application data
and processing status, sending back the acknowledgement and setting the transmission
status.
The "lead" system maintaining the business objects data and triggering the data exchange
has to be determined.
Depending on the business needs the serialization of the transferred data packets and their
processing has to be implemented. This could drastically increase the complexity of an
interface considering the implementation logic and error handling.
The received data has to be processed only once in the receiving system. This is especially
Page 172

of importance, when the lead system repeats transfers in case of restart, crash recovery or
loss of communication connections.
Resynchronize of the interfacing systems must be implemented, so that the sending and
receiving systems can be brought to a synchronous processing state after back out and
recovery situations. Such situations can also be implemented through manual procedures
supported by tools (e.g. re-scheduling jobs).
Technical and application based logging functionality is essential for both the monitoring of an
interface and the ability to identify and resolve error situation. This feature could range from a
simple log writing process to a complicated monitoring tool for several interfaces.
3. Consider the time frame of the data transmission (synchronous/asynchronous): Based on the
business needs, the time frame of a transmission, the technical infrastructure and the
interfacing capabilities of the application systems a basic transfer method must be selected.
There are two basic methods of transferring data from and to SAP systems:
(1) file access
(2) program-to-program communication.
The files access method uses file systems to create, write and close a file. The file is then
"somehow" transferred to the other application system (e.g. by a tool like "ftp") or the use of
share file systems. After the file is accessible to the partner system the data processing is
triggered or the partner system polls for further processing. This transfer method only allows
data transfer asynchronously (also often referred to as "batch" interfaces).
The program-to-program communication requires for each communication partner an
interface program. The connection is established by the client (the source of the data) and
accepted by the server (the processing side of the data). These methods allow synchronous
data transfer and processing.
4. Plan for error handling and maintenance: Consider already from the beginning of the project
the monitoring, error handling and restart ability for the interfaces. Define clear responsibilities
for these maintenance activities.
A.10.17
Complete a structured walk-through of the extract system
interface design.
Discuss and confirm each interface's (input and output) detailed design by completing a
structured walk-through of each design.
Submit and discuss each interface design with management. Resolve any questions and issues.
This step may involve more than one meeting.
Update the Management Overview Diagram and other documentation as appropriate as a result
of the various interface system design specification preparations.
Obtain formal written approval of the design of each different interface.
Page 173

A.10.18
Develop Data Transformation System InfoSource Design
Specifications
Purpose
To complete and assemble the data transformation system InfoSource design specifications.
Overview
For the custom developed data transformation components, this task brings the results of the
previous tasks together into a final InfoSource specification package for each procedure,
elementary process and common logic module. The InfoSource specification package will be
used in the Realization Stage to develop the BW components for the application.
The format and content of the InfoSource specifications will vary depending on the development
language and/or approach. The InfoSource distribution guidelines and the interaction layer
architecture defined in this phase are both used to determine the most appropriate development
approach, before developing InfoSource specifications.
To prepare an InfoSource specification package, prepare Edit/Validation Specifications and
identify associated error processing, identify Table Definitions for codes/decodes, develop detail
logic requirements and then assemble all additional relevant documentation into the package.
A.10.19
Design Communication Structure for Subject Area InfoSource.
The Communication Structure defines the format of the InfoSource. Within the overall
transformation architecture, they represent the end-point of transformed, integrated subject areabased data. Communication Structures contain mapped fields from source system DataSources
(see below) as well as derived fields as identified in the Data Definition.
A.10.20
Identify/Design Data Source Transfer Structures.
The Transfer Structure represents the format of incoming data from source system interfaces. It
defines the layout of DataSources, from which InfoSources can be mapped. DataSources can
map to one or more InfoSources, and an InfoSource can map one or more DataSources to
integrate the data required.
A.10.21
Prepare Edit/Validation Specifications for Local Transfer
Routines.
Data integrity must be maintained by preventing invalid data from entering the system. The user
must be notified when information entered is invalid, told why it is invalid and be allowed to reenter corrected data.
Each data element has a characteristic format that must be enforced when it enters the system.
Typically, data element level edits can be completed without reference to any other stored
information. Such edits include checks for numeric data, null entries, date formats, valid dates,
syntax edits, range checks and required fields
Data must also be compared and cross-validated against other data for illogical combinations of
data, reasonableness checks and data comparisons.
Document the edit/validation rules so that they can be considered for subsequent implementation
as part of a stored procedure(s).
Page 174

A.10.22
Develop Table Definitions.
Table Definitions relate to code/decode definitions. They are small utility data files for look-up or
data validation purposes. Each must be developed in terms of structure and, if reasonably small,
data content. Decisions on whether the table should be physically maintained as part of a
InfoSource, as part of the Data Dictionary, in a separate file or in a database will have an impact
on the tasks completed in both this phase and the Data Design Phase.
During this step, identify all known tables and gather documentation regarding valid values for
codes/decodes. This will help in preparation of test data, detail test steps and data conversion
activities.
A.10.23
Develop Monitor Response for Edits/Validations.
Specify the associated action (e.g., Help message, error or warning message) for each edit and
validation.
A.10.24
Prepare initial test plans for each InfoSource and component
grouping.
Develop test objectives, test conditions and general expected results at the InfoSource level. This
provides valuable input for the BW developer. The Unit Test Plan further describes nuances of the
logic that the BW developer must understand and will often validate the other parts of the
InfoSource specification.
A.10.25
Conduct a structured walk-through of the InfoSource design
specifications.
Review and cross-reference the InfoSource design specifications against the application level
documentation as confirmed in the Analysis Checkpoint Phase.
Conduct a structured walk-through, within the project team, to confirm the completeness and
consistency of each design specification and to ensure compliance with both quality and
development standards.
A.10.26
Evaluate and resolve issues as required.
Any shortcomings in the design should be resolved through the formal issue resolution process
and changes made, where appropriate.
Page 175

A.10.27
Develop Data Conversion Design Specifications.
Purpose
To determine what data needs to be created and/or converted and to plan how this will occur.
Overview
Other than scope, no set of issues has a more profound impact on project planning than the data
conversion strategy.
The current and proposed data elements are analyzed to develop a systematic approach for
capturing currently available information and creating any new data for the proposed system.
During this task, a data conversion plan with resource estimates and data conversion
requirements is prepared.
A.10.28
Determine the condition of the existing data.
The data in the existing systems, whether manual or computer-based, is reviewed to determine
its condition. Check:
How often and in what ways is the existing data used or managed;
Completeness and accuracy of data. Computer programs may have to be written to
check the existing system for such items as blank fields, missing or inconsistent data;
Whether there is any non-current data in the system;
Whether the system has been balanced and reconciled regularly;
Whether the system has its own internal integrity (e.g., opening balances + receipts issues +/- adjustments = closing balances);
If the system has sufficient input validation and error checking to prevent any invalid data
from entering the system; and
If DBMS software is used, whether the housekeeping routines have been run regularly to
check the integrity of the DBMS.
Depending upon the condition of each source system, a detailed review of some existing
applications may be required to determine the integrity of existing data. If some of these systems
are either old or poorly structured/documented, this may require considerable effort or a different
approach to extract and review the present data. e.g., the use of software reengineering tools to
document old programs or extra data.
A.10.29
Map data elements.
Develop a Data Conversion Map by assigning the old data elements in the existing system to the
data elements in the new system to decide which data is:
To be transferred;
To be translated/converted;
Redundant;
New and has to be created and by what means; and
To be verified/balanced/reconciled.
This is a very important part of determining what needs to be completed in the data conversion
process. Careful mapping should provide more accurate information on the time and resources
required for data conversion.
Page 176

A.10.30
Determine volumes of all data for conversion.
Determine the volumes of each file to be converted. Initial estimates may need to be adjusted
following purging/cleansing.
Determine volumes of data that need to be created. Initial estimates may need to be further subdivided, depending upon the various means of creation determined in subsequent steps.
If opening balances are to be created in the new system, determine the volumes of data for
creation and conversion for these types of records.
If tables have to be created or converted, derive their volumes.
A.10.31
Determine the source data for conversion and the conversion
method.
Once the required conversion data has been identified, the source for each data element must be
identified. These data elements may be currently maintained on an existing computerized system
or on paper documents or for some new systems, it may all have to be created.
Once the source and the format are determined, the method of conversion may be decided.
Select from the alternative methods to create the new master file data and table files including:
Keying the data;
Service bureau (keying);
Computer software bulk or mass maintenance routines;
Custom programs;
Utilities;
File conversion software;
Scanners to scan data; and
External databases (buy data).
Generally, a combination of these different alternatives are used to create the data. Note the
source of the input for each data field in the new system.
Select the most appropriate method to create the new system's opening balances and history
files where needed.
The source of each data element and the means should be noted on the Data Conversion Map.
A.10.32
Define required selection and purge criteria, creation and
translation rules.
The data requirements must be reviewed to determine if:
Any limiting selection criteria are necessary (i.e., only source data after a certain date will
be converted);
Any purge criteria are necessary. The purge criteria are basically the opposite of the
selection criteria. Selection criteria specify what to include; purge criteria specify what to
exclude; and
Any translation of data formats is required.
It should be noted that selection, purge and translation rules may not be all encompassing. In
most instances, human intervention and decision making will be required to decide if some
information should be converted or not converted and exactly how it should be translated or filled
out.
Page 177

A.10.33
Review data conversion requirements to determine error
identification and cleansing strategies.
The data conversion requirements are reviewed to determine edit and validation requirements
and to determine error handling procedures. The Edit/Validation Specifications defined for the
application system being developed should assist in determining the error identification
requirements.
This step may result in the identification of additional purge criteria that should be added to the
purge criteria specified in the previous step. Identify data cleansing strategies and document the
data cleansing procedures. In addition, it is important to ensure that:
The approach to data clean-up has been thoroughly planned to ensure that
dependencies between data items are maintained;
Data items to be amended and enhanced have been identified;
Criteria have been agreed for determining the data conversion rules;
An auditable trail of the changes applied is produced for management review and sign-off
by the data owner or nominated deputies;
All changes applied are reversible or can be backed out using back-up copies of the data;
and
Changes are never applied directly to production data.
If during the conversion process it is discovered that the existing system contains anomalies such
as incorrect information or items not capable of being reconciled, these may need to be written
off. If this leads to an impact on the organization's financial statements and/or the need for formal
management approval is required, agreement must be reached on the responsibility and the
methods used to make these adjustments.
A.10.34
Develop a strategy for reconciling converted data.
Specify the tests that will be needed to prove that converted data is sufficiently "clean" to be used
and that data inaccuracies have not been introduced during the conversion process.
A.10.35
Develop data conversion acceptance criteria and acceptance
test strategy.
Derive the conditions that will determine that the data conversion has been successfully
completed and documented.
After the data conversion acceptance criteria are defined and agreed, develop a strategy for
conducting the acceptance testing of the data conversion process.
The definition of the criteria and the strategy may need to include internal and external audit
resources as well as the definition for responsibility for formal written sign-off of completion of the
testing process.
The criteria must be clear, explicit, measurable and verifiable.
A.10.36
Develop a System Diagram for the conversion sub-system.
Create a detailed System Diagram of the conversion system that includes:

The sequence and interrelationships among conversion job steps;
All input and output data files required;
Audit trail and reconciliation reports shown as program outputs;
Converted data files shown as program outputs; and
Interface requirements for sending/receiving data to/from other system(s).
Page 178

A.10.37
Define staff resources and project management required for
conversion.
Depending upon the size and nature of the data conversion effort required, a separate project
team may be needed to complete the various tasks.
If a separate project team is to be created, derive the type, quantity and level of personnel
resources required. Consider the mix of skills needed including:
Detailed knowledge of the existing systems and data;
Clerical effort for manual reconciliations;
Programming effort to cleanse, purge and list data and to create conversion programs;
Systems programming skills to create the data conversion system;
Project management skills to manage the data conversion project team; and
Audit skills to approve reconciliations and/or write-offs.
Determine the availability and scheduling for all resources.
The entire data conversion process should be treated as if it were a separate systems
development project. Thus, the normal project management controls should be in place,
including:
Adherence to a structured systems development methodology;
Use of project management tools and techniques to define and manage resources,
outputs, the critical path, costs and time;
Project risk assessment; and
The responsibility for approval and the means for any write-offs or adjustments
discovered as part of the data conversion process are defined.
Define and agree the project management structure required.
A.10.38
Assemble the data conversion strategy and prepare a data
conversion work plan.
Assemble the various inputs from the work steps into a data conversion strategy document.
Prepare a detailed data conversion work plan that includes:
Project management strategy, responsibilities and organization structure;
Staff resources required;
What data will be converted;
The source of each data element;
The cleanliness of the data and the strategy for cleansing;
The conversion, selection and purging rules;
The acceptance criteria and acceptance testing strategy;
The data conversion reconciliation procedures and documentation filing requirements;
The different conversion means;
Hardware and technology component resources required;
When the data conversion will begin;
How long the data conversion is estimated to take; and
Whether mock conversion will be employed for testing purposes.
Hundreds of detailed steps need to be accomplished in a precise sequence during a data
conversion process and the migration of the application to production status. To ensure that all
factors are considered, a controlling schedule/checklist must be designed and prepared. The use
of critical path techniques and software is most appropriate in this area.
Page 179

A.10.39
Submit and discuss the data conversion plan with
management.
Submit the Data Conversion Plan to management and resolve any questions and issues. If
necessary, prepare an action list of items to modify. This step may require more than one
meeting.
A.10.40
Obtain formal written approval of the data conversion plan.
Obtain formal written approval of the data conversion plan including agreement of the
responsibility for the sign-off of the completed data conversion reconciliations.
Page 180

A.10.41
Submit Data Transformation System Design Deliverable
Purpose
To assemble the various DT system design deliverables.
Overview
When approved by management, the design specification assembled in this task will be refined in
the Realization Stage and be developed as InfoSources.
The DT system design deliverable is discussed with management and approved. In some
circumstances, this task may be delayed and completed as part of the Business Blueprint
Checkpoint Phase.
A.10.42
Assemble data transformation system design deliverable.
Review all of the documentation for each design specification and ensure that all of the relevant
work products are present. Ensure the consistency and completeness between individual
InfoSource specification packages.
Review the Management Overview Diagram or other relevant Abstract documents to ensure that
any changes resulting from the completion of the DT System Design have been correctly
included.
A.10.43
Conduct a structured walk-through of the design specification.
Conduct a structured walk-through, within the project team, to confirm the completeness of each
design specification and to ensure compliance with both quality and development standards.
A.10.44
Document and resolve issues as required.
Any problems in the design should be resolved through the formal issue resolution process. All
open DT system design issues should be resolved before the completion of this phase.
A.10.45
Submit and discuss the data transformation system design
deliverable.
Discuss the DT system design deliverable with management and resolve any questions and
issues. If necessary, prepare an action list of items to modify. This step may require more than
one meeting.
A.10.46
Obtain formal written approval of the data transformation
system design deliverable.
Page 181

A.11 Presentation System Design

Purpose
To convert the user data access requirements determined during the Business Blueprint Stage
into a set of technical design specifications for the DW presentation system.
Overview
This phase develops a set of technical specifications for the BW presentation system, including
those for queries, workbooks, key figure structures and selections, restricted and calculated key
figures, and variables.
Presentation System Design Task Relationships
P r o c e s s D e f in itio n
D a ta D e fin itio n
K1
D e v e lo p H ig h - L e v e l
P r e s e n ta tio n D e s ig n
H ig h - L e v e l P r e s e n t a t io n D e s ig n
C h e v r o n S e c u r it y P o lic y
K2
C r e a t e A u t h o r iz a t io n
D e t a ile d D e s ig n
A u th o r iz a t io n D e s ig n
K3
D e v e lo p P r e s e n t a tio n
S y s te m In te rfa c e
D e s ig n
Q u e r y s p e c if ic a t io n s
W o r k b o o k s p e c if ic a t io n s
S t r u c t u r e s p e c ific a tio n s
R e s tr ic t e d K e y F ig u r e s p e c ific a t io n s
C a lc u la t e d K e y F ig u r e s p e c if ic a t io n s
V a r ia b le s p e c if ic a t io n s
U n it T e s t P la n ( In it ia l)
K4
S u b m it P r e s e n ta tio n
D e liv e r a b le
P r e s e n ta tio n D e s ig n D e liv e r a b le
Page 182

A.11.1 Develop High-level Presentation System Design

Purpose
To develop a high-level system design for the BW presentation system.
Overview
Presentation systems may be developed for different user environments and at different levels to
meet an organizations business information needs. The steps in this task are similar to those in
J1, except as noted, to develop a high-level presentation system design.
A.11.2 Develop a system diagram for the broader system environment.

Develop a high-level system diagram for each of the presentation system environments
supported such as:
Central office;
Regional office;
Branch office; or
Stand alone office.
The system diagram should highlight the interfaces between the various technology components
of the respective presentation system environments addressing issues such as:
Use and distribution of BW Browser or other query/report distribution mechanism;

Ad hoc versus standard or canned queries; and
Usage of portal interfaces for consolidating reporting and query presentation.
A.11.3 Develop high-level system design for the presentation system

components.
Develop a high-level system design for the presentation system components based on an
understanding of the specific data access requirements of the analytical processes identified in
Phase G Analysis and Decision Process Definition.
A BW presentation system is not a stand alone system but must align with and support the other
elements of the broader organizational context such as:
Organizational structure;
Performance measurement;
Decision support;
Business processes;
Technology infrastructure; and
Geographical distribution of user groups.
Within this broader organizational framework, the presentation system architecture requirements
identified in Phase G are analyzed and consolidated into a consistent overall presentation
system. The key user requirements driving the design of the presentation system include items
such as:
Information access requirements including:
Page 183

geographical distribution of users,
organizational distribution of users,
divisional/functional organization of users,
vertical/horizontal/transversal organization of users,
data volume availability requirements, and
data source, media, integration, interoperability requirements including external data
(e.g., telephone traffic analysis) not available from traditional transaction processing
systems;
Data analysis requirements such as:
types of business/decision support analysis,
DSS applications,
performance measurement applications,
data mining (exploring data for unknown facts; seeking business opportunities),
what levels of analysis effort are performed (e.g., econometric modeling or topline/exception reporting), and
what, if any, new information is created as a result of the analysis processes; and
Data presentation requirements such as:
the required media of presentation,
user interface requirements (e.g., GUI requirements), and
Internet/intranet Web access.
A.11.4 Determine the query/report design requirements for the presentation

system analysis tools.
Determine the query/report design requirements for the presentation system analysis tools
including:
Defining query standards addressing such issues as:

text element format,
row/column structure and format,
totaling standards,
display of run-time parameters selected, and
distribution requirements.
Agreeing on any Business Content queries in BEx to be retained, those not required and any
requiring minor modifications. Major modifications to these standard queries should be
classed as new queries and are detailed separately;
Preparing query grouping within Activity Groups and Clusters, considering:
internal reports used by the organizations management, and
external reports created to satisfy an outside demand;
Determining query/report generation methods and identifying individuals responsible for the
creation and maintenance of each individual query/report; and
Completing query documentation to supplement documentation provided by BEx.
A.11.5 Develop high-level design for presentation tools.

Develop design specifications for presentation tools to support the identified analytical data
access requirements. Some general BEx specifications include:
Develop drag and drop specifications;

Specify drill-down requirements;
Page 184

Specify slice and dice requirements;

Develop presentation system metadata;
Develop Web query views for items to be included in HTML; and
Specify security requirements.
Based on the identified presentation system architecture requirements, determine whether one or
more analysis tools would be required.
A.11.6 Discuss and obtain formal written approval for the high-level
presentation system design.
Page 185

A.11.7 Create Authorization Detailed Design

Purpose
The purpose of this activity is to create a detailed authorization design for the BW
implementation. Each BW business application component provides options for controlling the
use of functions through authorizations and profiles.
Tasks
Review the Organizations Security Philosophy

Document Access Required by Job Functions
Conduct Authorization Interview with Data Owners
Identify General Information Access and Service Usage
Create Authorization Management Procedures
Create Authorization Detailed Design Document
A.11.8 Review the Organizations Security Policy

Purpose
The purpose of this task is to confirm security requirements in the organization.
Review security policies for each department by asking the following questions:
Can users in the department execute all relevant transactions (DO ALL), and have they
access to data across the organization (SEE ALL)?
access to only specific data across the organization (SEE SOME)?
Can users in the department execute a selected set of transactions (DO SOME), and have
they access to data across the organization (SEE ALL)?
Can users in the department execute a selected set of transactions (DO SOME), and have
they access to only specific data across the organization (SEE SOME)?
Procedure
Ask Questions
What is the security policy in your organization?
What level of security does your data require?
How much risk can you permit in each application area? The less risk the organization
assumes, the greater the resources needed to implement BW Security.
Communicate your Security Implementation Concept
Conduct a workshop with the authorization administrators and application areas (data
owners) to review the BW Authorization Concept, and how it impacts data owners.
Explain the implementation framework. Then interview each application area.
Document Security Requirements of each Affected Department

This document answers the following questions for each data type:
access to data across the organization (SEE ALL)?
access to only specific data across the organization (SEE SOME)?
Page 186

Can users in the department execute a selected set of transactions (DO SOME), and
have they access to data across the organization (SEE ALL)?
Can users in the department execute a selected set of transactions (DO SOME), and
have they access to only specific data across the organization (SEE SOME)?
A.11.9 Document Access Required Associated by Job Functions

Purpose
The purpose of this task is to define the level of access required based on the job functions.
The authorization design must include the level of access required based on the job functions.
Using the profile generator to set up security, activity groups build the framework for access rights
in BW.
To build the activity groups and authorization profiles you must know which menu paths or reports
each job function requires.
Procedure
Document Access Paths or Access Rights for each Role.

Each application area must supply Roles (R/3 job descriptions) to define activity groups.
A Role is one task or activity, or a combination of tasks and activities. For each
application area, document the different roles in a job role matrix, and for each job role,
document the menu paths and transactions (tasks) the users access. In the same matrix
document, note the default values for organizational levels and access restrictions to
specific organizational levels, and restrictions concerning access rights, such as Display,
Change, and Create for each job role. You can use user training documents or scripts in
this process.
All authorizations are based on the selection of activities (Transactions, Reports, Tasks)
grouped in the appropriate activity group. Authorization Profiles are based on the Roles
supplied. Therefore, the activity group represents the corresponding job role. Some
activities must be in separate activity groups (for example, printing rights), therefore, a
user can be assigned more than one activity group at a time.
Review the enterprise-wide job role matrix before you build the activity groups.
Determine the security options (authorization object options) for each job role. You can do
this by creating a sample activity group for a job role and generating its authorization
profile. Discuss the security options (for example, setting up authorization groups, and so
on) with each application area (data owner), based on the security options you have
concerning the automatically generated and, therefore, necessary authorization
objects. Application data owners must be aware of the potential risks (such as, excessive
accesses) that result from their decisions.
A.11.10
Conduct Authorization Interview with Data Owners
Purpose
The purpose of this task is to obtain information about the types of data, and who owns the data.
To set up access to the data, you must specify which data a user uses, and the type of access the
user must have. For example, a user can be allowed to change certain data, and to display other
data. Access to remaining data must be denied to the user.
Page 187

Procedure
Communicate your Security Implementation Concept

Conduct a workshop with the security administrators and application areas (data owners)
to review the BW Authorization Concept, and how it impacts data owners. Explain the
implementation framework. Then interview each application area.
Review
Review the enterprise-wide job role matrix before you build the activity groups. Determine
the security options (authorization object options) for each job role. You can do this by
creating a sample activity group for a job role and generating its authorization profile.
Discuss Security Options

Discuss the security options (for example, setting up authorization groups, and so on)
with each application area (data owner), based on the security options you have
concerning the automatically generated and, therefore, necessary authorization
objects. Application data owners must be aware of the potential risks (such as, excessive
accesses) that result from their decisions.
A.11.11
Identify Information Access and Service Use
Purpose
The purpose of this task is to identify the needs of users to access information, such as business
data not directly related to job functions. Other types of access include access to SAPoffice and
online documentation.
Determine the need for access to BW System services, such as printing, faxing, and SAPoffice
for each user.
Procedure
Identify access rights or service use users need for their job functions. Such access rights
can be to SAPoffice, access to online documentation, reporting, Online Service System
access, basis services permissions, such as printing and faxing.
Page 188

A.11.12
Develop Presentation System Interface Design
Purpose
To design the presentation system interface both with the users and the other components of the
BW system.
Overview
This task develops an interface design for the BW presentation system in terms of both the user
access interface and interface between the presentation system and the other components of the
BW system.
A.11.13
Identify Presentation/Layout Preferences
Purpose
The purpose of this task is to define required presentation/layout preferences or layout sets for
BW standard reporting. Identify the processes and functions where layout sets must be used.
Determine how documents must be formatted to reflect the corporate standards.
Procedure
The procedure describes how to create Layout Set definition. Obtain the information needed to
develop standard company reports and forms.
Determine Information Access and Presentation Requirements

This task involves the End Users doing a serious review of how they currently use
information.
The output of this activity forms the foundation for determining the End Users front-end
decision support requirements.
Users often have difficulty expressing data and functional requirements since their process is
intuitive. They frequently do not have a clear knowledge of just what is available to them in a
Decision Support environment. This step results in determining BW system usage
characteristics and presentation requirements.
The need for canned static reports versus the capability to do "active analysis" (OLAP) is also
explored along with expected response times.
Determine Layout Requirements

Determine what new or changed sets are needed, and obtain sample layout sets from the
system.
Define Detail Specification

The task develops the technical specification for creating a layout set
Page 189

A.11.14
Determine Uses of Pre-Configured Reports
Purpose
The purpose of this activity is to determine uses of SAP pre-configured Reports.
Procedure
Review the end user requirements

Identify Reports
Maintain/Execute Query
A.11.15
Prepare Query Specifications.
In addition to the preparation of standard query definition templates, the following should also be
performed:
Prepare Workbook specifications;

Prepare Key Figure Structure and Selection specifications;
Prepare Restricted Key Figure specifications;
Prepare Calculated Key Figure specifications; and
Prepare Variable specifications.
A.11.16
Assemble Business Explorer Object specifications.
Assemble the components of the Business Explorer Object specifications.
A.11.17
Conduct a structured walk-through of the Business Explorer
Object specifications.
Review and cross-reference the program design specifications.
Conduct a structured walk-through, within the project team, to confirm the completeness and
consistency of each design specification and to ensure compliance with both quality and
development standards.
A.11.18
Evaluate and resolve issues as required.
Any shortcomings in the design should be resolved through the formal issue resolution process
and changes made, where appropriate.
Page 190

A.11.19
Submit Presentation System Design Deliverable
Purpose
To assemble the various presentation system design deliverables.
Overview
When approved by management, the design specification assembled in this task will be refined
and coded in the Realization Stage.
The presentation system design deliverable is discussed with management and approved. In
some circumstances, this task may be delayed and completed as part of the Business Blueprint
Checkpoint Phase.
A.11.20
Assemble presentation system design deliverable.
program specification packages.
Review the Management Overview Diagram or other relevant Abstract documents to ensure that
any changes resulting from the completion of the presentation system design have been correctly
included.
A.11.21
A.11.22
open system design issues should be resolved before the completion of this phase.
A.11.23
Submit and discuss the presentation system design
deliverable.
Discuss the presentation system design deliverable with management and resolve any questions
and issues. If necessary, prepare an action list of items to modify. This step may require more
than one meeting.
A.11.24
Obtain formal written approval of the presentation system
design deliverable.
Page 191

A.12 Data Design

Purpose
To develop a data design in support of the identified data requirements for the DW environment.
Overview
The Logical Data Model (LDM) and Multidimensional Data Model (MDM) are the final two data
models in the top-down progression of data models as discussed in the Methodology Overview
section.
With the data models defined, each type of InfoObject required for analysis must be identified and
reviewed. The data design exercise can be performed by reviewing the user requirement for
analysis.
Specifically, the data design asks may be of varying degrees of relevance in developing the
various types of databases in a BW architecture such as:
Operational Data Store (ODS) a subject-oriented database containing detailed data
consolidating selected information on a subject area scattered over multiple systems in an
organization. An ODS provides the granular data required to support various analytical
processing applications such as data mining, data profiling and other decision support
applications. ODS is also the source of clean, integrated data from which summarized or
segmented data stores can be derived;
Data Warehouse (InfoCubes) a subject-oriented, integrated, time-variant and non-volatile
collection of information designed to support an organizations management analytical and
decision making processes. A DW may contain both granular and summarized data to
support the identified management analytical processing information needs. Depending on
the DW architecture, the source of data for a DW may come from an ODS or directly from
the source databases.
Tasks
Develop Logical Data Model

Develop Multidimensional Data Model
Design InfoCube
Page 192

Data Design Task Relationships
C o n c e p tu a l D a ta M o d e l
L1
D e v e lo p L o g ic a l D a t a
M odel
L2
D e v e lo p
M u ltid im e n s io n a l D a ta
M odel
H ig h - le v e l D a t a T r a n s fo r m a tio n
D a ta T r a n s fo r m a tio n S y s te m D e s ig n
M a s te r D a ta re q u ire m e n ts
L3
In f o C u b e D e s ig n
L4
S u b m it D a t a D e s ig n
D e liv e r a b le
Page 193
L o g ic a l D a ta M o d e l
M u lt id im e n s io n a l D a t a M o d e l
In fo C u b e s
A g g re g a te s
D a t a D e s ig n d e liv e r a b le

A.12.1Develop Logical Data Model

Purpose
To develop an LDM for the data warehouse.
Overview
This task transforms the CDM into an LDM following the major steps below:
Reviewing the completeness of the inputs for the development of the LDM.
The completeness of the inputs for the development of the LDM should be reviewed
especially when there is a time lag between the developments of the CDM and the LDM.
In addition, if an LDM is to be developed based on existing or previously completed
CDM(s), LDM(s) or PDM(s), the completeness of these models in supporting the
development of the LDM should be examined. The inputs to the LDM development
process also include application design documentation and existing system
documentation.
The CDM is then transformed into a preliminary LDM to provide a starting basis for
logical database design;
Refining the definitions of attributes including defining any new design or overlooked
business entities and attributes, placing each entity into third normal form, determining
the primary and foreign keys and finalizing the definition of the attributes.
New entities and attributes may be identified during the Data Transformation System
Design and Presentation System Design Phases; e.g., some new attributes may have
been created to manage and/or control application processes or to reduce redundant
processing (e.g., storing totals to eliminate frequent recalculation of those totals). Some
entities or attributes may simply have been overlooked in developing the CDM.
Each entity is placed into third normal form. When an entity has several candidate keys, a
primary key is selected. Foreign keys are also determined for implementing the identified
entity relationships.
The definitions of each entity and attribute are reviewed to ensure that all appropriate
information to be recorded in the Data Dictionary is complete and up-to-date;
Refining the entity relationships from a logical design perspective.
The entity relationships defined in the CDM are reviewed and refined as necessary from a
database design perspective considering such design issues as:
refining entity relationships based on design criteria (e.g., resolving many-to-many
relationships),
refining subtyping hierarchy structures,
determining entity relationship cardinalities, and
defining referential integrity requirements; and
Estimating the data volumes for use in determining data storage requirements.
The data volumes for the implementation of the database environment are estimated considering:
volumes of all data for conversion,
historical data requirements,
Page 194

interface data volumes, and

all of the defined data entities, including the lookup tables, for the production
environment.
The data volume estimates need to be reviewed and revised as necessary as the LDM evolves or
as more knowledge is gained about the application environment.
A.12.2Review the completeness of the inputs.

Review any relevant data models including as appropriate:
The CDM developed on the same DW project;
CDM(s), LDM(s) or PDM(s) developed for the existing databases; or
Previously completed or partially completed CDM(s), LDM(s) or PDMs.
Review any relevant application (or process) design documentation.
Review any relevant existing system documentation.
Determine the completeness of the inputs for the development of the LDM including:
Scope statement and interface definitions;
Business rules (including any relevant data security rules);
CDM diagram;
Definition of subject areas;
Entity definitions;
Relationship definitions;
Attribute definitions (optional);
Critical business data (for business continuation or survival);
Logical segmentation requirements (if available);
Existing data structures;
Data conversion strategy;
Existing Business Content InfoCubes; and
LDM development considerations.
Determine the impact of any missing or incomplete inputs on the development of the LDM.
Obtain the required inputs from the appropriate DW staff or application development team(s).
It may be necessary to develop some of the missing or incomplete inputs by completing selected
tasks/steps as discussed in the Analytical Processing Data Definition phase. For instance, if an
LDM is to be developed based on existing CDMs or LDMs, some tasks/steps may need to be
completed to fill in any missing elements.
Discuss with management the impact of the missing or incomplete inputs and any assumptions or
planned actions. Obtain formal written management approval of any project scope changes
before work commences.
Gather further inputs as needed based on the approved actions determined in the previous step.
Any changes to the CDM should be completed following the established change control process
of the DW project.
Ensure that all of the changed or newly derived inputs receive structured walk-throughs to ensure
consistency and completeness before beginning the remaining work tasks and steps.
Page 195

A.12.3Transform the CDM into a preliminary LDM.

Transform the CDM into a preliminary LDM as the starting basis for logical database design.
Depending on the established corporate or project data modeling and definition standards and
conventions, the transformation of the CDM into the LDM may be a simple mapping process
involving:
Mapping the CDM entities into the LDM entities or data groups;
Mapping the CDM attributes into the LDM attributes or data fields; and
Mapping the CDM entity relationships into the LDM entity or data group relationships.
Identify any interface entities which represent the data outside the scope of the data model but
may interact with the data in the data model. Interface entities may be presented as entity boxes
outside the perimeter of the data model without any relationships.
Identify any legacy system data entities which may need to be converted to data entities in the
target environment or maintained as historical data entities.
Draw a diagram to depict the preliminary LDM.
Review the processing controls and security strategy and consider:
Processing controls and security information such as audit trails, run-to-run control totals,
user IDs and passwords;
System distribution information such as replication frequencies and statistics,
synchronization errors and transaction files for asynchronous updates;
User interface performance statistics such as error rates; and
Environmental information such as terminal and printer IDs.
When developing the LDM, introduce design entities, attributes and relationships that comply with
the organization's security policy standards to support the security and control needs of the
application.
Define additional data element requirements uncovered during application design. These
elements are required to support the business requirements at a detail level.
The new data elements should be assigned to entities as attributes and added to the Data
Dictionary. As needed, new entities and entity relationships may need to be created to capture
these new business information requirements.
Define the newly identified attribute InfoObjects in the InfoObject catalog to include information
such as:
Description of the attribute;
Conversion routine; and
Data type (CHAR, NUMC, etc.).
Conform to the established data definition standards and conventions in defining the attributes.
Include computed or derived data that is important to the business in the InfoObject catalog with
definitions as well as derivations. Decisions will be made later as to whether this computed data
will be stored in the InfoCube or calculated dynamically in queries.
Exclude relatively unimportant derived data such as totals and subtotals on reports from the
analysis.
Define the code sets for each of the coded data attributes defined in the LDM:
List all of the applicable code values;
Page 196

Determine whether the code set is extensible (i.e., whether the code values are static or
dynamic); and
Determine the ownership of the code sets (i.e., the user groups responsible for defining
and maintaining the code sets).
A code set is defined as a code table entity consisting of at least two attributes - the data code
value and the data code name (e.g., the Country Code Table consists of COUNTRY CODE and
COUNTRY NAME.) The primary key for a code table is the attribute representing the data code
value.
A code table may be associated with one or more entities to characterize the occurrences of the
related entity. Thus, the data code attribute (e.g., COUNTRY CODE) in the related entity is the
foreign key for accessing the Country Code Table entity.
A.12.4Place each entity into third normal form.

Review each entity and verify that it is in:
First normal form.
Review the attributes of each entity to determine whether any attribute or group of attributes
occurs multiple times for each occurrence of the primary key of the entity.
Remove any repeating attributes from the entity and create a new entity for the repeating
attributes. This new entity should have a one-to-many relationship back to the original entity.
Typically, this new entity will be an associative or characteristic entity and inherit the primary key
of the original entity. Once all repeating groups of attributes have been eliminated, all entities will
be in first normal form;
Second normal form.
Review each attribute of each entity to ensure that it is determined by the entire primary key of
the entity rather than only part of the primary key.
Remove any attributes which are dependent on only part of the key (i.e., the attributes which
describe a fact about a part of the entity's key). Create a new entity for these attributes. Typically,
this new entity will be an associative or characteristic entity and will include part of the primary
key of the original entity.
Add a one-to-many relationship between the new entity and the original entity with the "many" on
the original entity end. The CDM is in second normal form once all partial dependencies have
been removed from the model; and
Third normal form.
Review each attribute of each entity in the model to ensure that it is dependent on only the
primary key of the entity and no other attribute of the entity (i.e., there is no transitive
dependency).
Remove any attributes within the entity that describe a fact about another attribute that is not part
of the key. Create a new entity for these attributes which has the non-key attribute they describe
as the key for the new entity.
Page 197

Add a relationship between the new entity and the original entity. Once all transitive
dependencies have been removed, the model is in third normal form and can be considered fully
normalized.
During normalization, a database designer sometimes needs to choose among different
normalized designs. Often, the driving factor in making the decision is the patterns of data usage.
For instance, consider two normalized designs - one consisting of a single entity ("XYZ")
consisting of three attributes (the key X and two non-key attributes Y and Z) and the other
consisting two entities ("XY" and "XZ"). Data usage should be considered in choosing between
the two normalized designs. For instance:
The design with a single entity XYZ may be more suitable than the two-entity design as it
allows a query to access X, Y and Z together without requiring a "join" operation; but
The two-entity normalized design may be better if:
user accesses tend to partition between the two sets most of the time, and
attribute Y values or attribute Z values or both are large.
The two-entity normalized design will identify where compound InfoObjects are required.
Name, assign ID numbers, define and add to the InfoObject catalog new entities created as a
result of the normalization process.
Label, if necessary and mark with optionality, degree and maximum cardinality any new
relationships.
A.12.5Finalize the selection of primary and foreign keys.

Select a primary key for each entity:
Review and confirm the preliminary primary key for the entity if one is selected in
developing the CDM; or
Select one as the primary key if an entity has multiple candidate keys.
Entity integrity rule - No part of the primary key may have a null value. This rule ensures that every
occurrence of an entity has a complete identifier.
In reviewing and selecting a primary key for an entity, consider:
The basic requirements of uniqueness, applicability, minimality and stability as discussed
in the Analytical Processing Data Definition Phase; and
The appropriateness of the selected primary key as a foreign key in the related entities
(e.g., if both PART-NUMBER and PART-NAME are candidate keys for an entity, PARTNAME may be chosen as the primary key if it is a preferred candidate foreign key as
users are more interested in knowing or familiar with part name than part number).
Identify foreign keys in selected entities to support the relevant entity relationships. A foreign key
is an attribute in an entity that provides a logical pathway to another entity because that attribute
is part of or the entire primary key of the related entity. Thus, foreign keys are used to support
relationships in a relational data model.
The basic rule in translating a one-to-many relationship into a foreign key structure is to place the
primary key of the entity at the "one" end of the relationship as a foreign key into the table
representing the entity at the "many" end of the relationship. For example, as illustrated in Exhibit
P-1, the one-to-many relationship between SUPPLIER and PURCHASE ORDER is implemented
by placing Supplier # (the primary key for SUPPLIER) as a foreign key into the PURCHASE
ORDER table.
Page 198

A.12.6Finalize the definitions of attributes.

Review and refine the definitions of attributes as appropriate:
Review the attribute assignments in each entity to ensure that each attribute is properly
assigned to the entity to which it belongs;
Identify and resolve any attribute naming conflicts such as aliases, homonyms and
synonyms;
Define any important computed data including their derivation formulae, calculations or
algorithms;
Define logical attribute concatenations (e.g., ADDRESS consisting of NUMBER,
STREET, CITY) as needed;
Determine column constraints (e.g., NO NULL, NO DUPLICATE); and
Finalize the characteristics of the attributes to include information such as:
relative positioning within an entity where relevant, particularly for links based on
foreign keys or internal sort keys,
syntax and edit/validation values (e.g., range limits),
data type (e.g., numeric, alphabetic),
internal storage format,
presentation formats (e.g., date as yy/mm/dd or mm/dd/yy or dd/mm/yy),
default display formats (e.g., the '/' in dates, thousands comma separators, number of
display decimals),
the number of storage positions occupied,
for numeric elements, the number of decimal or binary positions,
whether zero suppression is to be used, and
whether negative values are allowed.
Complete a structured walk-through of the refined attribute definitions to ensure completeness
and correctness. The review team should include representatives from appropriate user and
system development groups.
A.12.7Refine entity relationships.

Refine the entity relationships defined in the CDM using as appropriate:
Associative entities to resolve the many-to-many relationships;
Characteristic entities to describe further selected entities; and
Subtyping to enhance database design and to facilitate implementation of the data
model.
Associative entities, characteristic entities and subtyping are discussed in detail during the
development of the CDM. Some of these refinements may not have been deemed appropriate in
developing the CDM from a business user perspective but may be considered desirable in the
Page 199

LDM from a database design viewpoint. Other refinements may be identified subsequent to the
completion of the CDM (e.g., due to overlooked information requirements).
Review the subtyping hierarchies (defined in the CDM or in the previous step) and determine an
appropriate implementation design for each considering such options as:
Including the identifier and attributes applying to all subtypes in the supertype entity. This
results in a large table that will have null values for inapplicable attributes. This option
may be preferable if the dominant query load relates to the supertype or to several
subtypes simultaneously. It may be desirable to add a type classification attribute to
indicate subtype membership for each entity occurrence;
Including the supertype identifier and attributes in each of the subtype entities. The result
is that there is a table for each subtype entity containing the attributes of the subtype as
well as the attributes common to all subtypes. This option may be preferable if the
majority of queries refer to a single subtype; or
Defining separate supertype and subtype entities each with the relevant identifier and
attributes. This option minimizes redundancy and null-valued attributes at the cost of
query complexity. A join operation is required whenever information from the supertype
and subtype entities is needed.
Review and refine as necessary the entity relationship optionalities (in terms of "Optional" or
"Mandatory") and cardinalities (in terms of "One" or "Many") defined in the CDM.
Estimate, for each relationship, the number of entity occurrences related to a single entity at the
other end of the relationship (sometimes referred to as the degree of a relationship). The
estimates should be captured in terms of the minimum, maximum and modal average For
instance, in a SUPPLIER-PURCHASE ORDER relationship, if suppliers are sometimes inactive,
the minimum would be zero. If the most frequently used supplier has no more than 50 purchase
orders active at any one time, the maximum would be 50. If most suppliers have 10 purchase
orders active at any given time, the modal average of the relationship would be 10.
Identify any special situations such as skewness of the cardinalities if known (e.g., over 60% of
the purchase orders may be placed with only 10% of the suppliers).
Define global field-level constraints (e.g., valid codes, values and ranges). These constraints
represent business rules to be implemented.
Complete a structured walk-through of the refined entity relationship definitions to ensure
completeness and correctness. The review team should include representatives from appropriate
user and system development groups.
A.12.8Estimate data volumes.

Estimate the data volumes for the databases to be developed. Consider the following four main
categories of data in estimating, as appropriate:
Current detail;
Old detail;
Lightly summarized; and
Highly summarized.
Current detail generally involves roughly two years of history, typically maintained on magnetic
disk devices. Old detail is roughly assumed to be up to 10 years of history, maintained on tape or
other low-cost storage devices. While dependent of the application's scope, nature of the
business and size of the enterprise, volumes in the multi-million/multi-billion record range should
Page 200

be anticipated for annual additions to enterprisewide detail data. Storage space requirements can
range from tens of gigabytes to terabytes.
Current and old detail data represents the highest data volumes and the richest information sources. It
corresponds most closely to the detailed transaction-level data from operational systems. Because the
volume of detail data is the primary cost driver for DWs, the largest impact on cost - or cost avoidance - is
achieved by making the right technology platform choices in this area.
Lightly summarized data is a reduction to the level of detail appropriate for the general
requirements of a departmental decision making application. Highly summarized data is a further
reduction for specific decision-support modeling requirements.
What constitutes lightly summarized or highly summarized data regarding the degree of volume
reduction from the corresponding detail can vary greatly. Some applications may require
reprocessing of large subsets of the detail (e.g., customer scoring applications). On the other
hand, many applications can be satisfied with a very small subset of the data, summarized at one
or two orders of magnitude of reduction (e.g., modeling financial performance for products or
product categories over time).
Estimate the data volumes for the specific database being designed considering:
The volumes of each file to be converted. Initial estimates may need to be adjusted
following purging/cleansing;
The volumes of data that need to be created. Initial estimates may need to be further
sub-divided, depending upon the various means of creation;
If opening balances are to be created for the DW system, the volumes of data for creation
and conversion for these types of records;
The volumes of tables to be created or converted;
If a staged implementation is to occur (e.g., by location, store, state or product group), the
data volumes derived based on the staged implementation schedule; and
The timing for conversion as some data may only be available after specific processing
(e.g., financial year-end).
If historical data is not to be converted but is to be retained (e.g., for enquiry, legal or statutory
purposes), determine how that data is to be kept. Consider alternatives such as:
Imaging;
Compact disc;
Tape;
Microfilm; or
Retaining the old system for historical data usage only.
Determine the volumes of records for each interface and also the timing and availability of the
data (e.g., daily, weekly or monthly). Also determine whether there are variations in volumes
caused by such items as holidays, seasonal peaks (e.g., summer), month-end or year-end.
The volumes may also impact upon the timing of the interfaces (e.g., if the interface is only
required weekly or monthly but this will cause interim storage or processing difficulties and it may
then be necessary to run the interface on a daily basis to improve efficiency).
Determine the statistical data related to frequency and volume of each relevant event/process in
the application environment including:
The expected frequency for execution of each event (e.g., once per hour, day, week or
month);
The expected number of data accesses to each entity required by each event for each
use;
Page 201

The nature of each entity access required by each event (i.e., add, update, delete or
read-only);
The response time requirement or allowable duration for each event; and
The expected volumes of data to be stored for each entity.
Estimate the data volumes for the production environment including as appropriate:
The conversion data, historical data and interface data requirements as determined in the
previous steps;
Code tables;
Transaction master data;
Back-up data;
Work space tables; and
Index tables.
Estimate the data volumes in terms of:
At the beginning of production;
At the end of first year of production; and
The projected annual growth rates of the data volumes.
Multimedia data is space intensive (e.g., audio or video data). In estimating the data volumes for
multimedia, the data storage configurations and the capability of the DBMS supporting the multimedia
data must be considered as appropriate. For example, multimedia may be stored directly in a database as
Binary Large Objects (BLOBs) or long fields or in a separate mass storage device.
Document any assumptions used in determining the various data volume estimates and the data
volume growth rates.
Discuss and confirm with management and appropriate user groups the data volume estimates
including any assumptions used in making those estimates.
Revise the estimates and/or assumptions as appropriate.
A.12.9Complete a preliminary analysis of performance efficiencies.

(Optional)
Complete a preliminary analysis of the high-level database design with consideration of data
volume estimates. As appropriate, refine the high-level database design for performance
considerations.
Refer to the Analysis Performance Efficiencies task for a detailed discussion of performance
efficiency analysis.
Page 202

A.12.10
Develop Multidimensional Data Model
Purpose
To model the business analytical processing information requirements in the form of a
multidimensional data design.
Overview
A multidimensional data model organizes data to support analytical and decision making processes in a
manner similar to how the business people think of their data. It makes it easier and more efficient for the
end-users to access the critical business information. The multidimensional data model is flexible and
more easily manages reorganizations, new products and different types and levels of analysis.
Multidimensional data modeling organizes the data into two types of entities - facts and dimensions. Fact
entities contain key numerical measurements of business performance and the dimension entities contain
the description information about the performance indicators. The facts are the WHAT information and the
dimensions are the HOW an analyst wishes to query and view the information
Multidimensional data modeling is a useful technique for modeling an organization's analytical
processing information requirements. While the specific information that a user needs in business
or decision analysis may be ad hoc in nature and difficult to predefine, the dimensions of analysis
are generally rather stable. These dimensions define the various data views or perspectives of
interest to users in their business analysis or decision making activities such as:
Whom does the organization serve (i.e., the Customer dimension)?
How does the organization serve the customers (i.e., the Distribution Channels
dimension)?
Where does the organization serve the customers (i.e., the Markets dimension)?
What does the organization provide to its customers (i.e., the Products/Services
dimension)?
How is the organization performing through time (i.e., the Timing of Business
Event/Activity dimension)?
The information about these dimensions or their combinations which is of interest to a business
analyst is referred to as facts. As illustrated in the exhibit, an analyst may be interested in
knowing about the facts of sales and marketing, profitability, quality, risk, productivity or
compliance relating to the dimensions of customer, service, market, delivery channel, product,
organization or time. For example, an analyst may be interested in the total dollar sales amount
(a sales fact), for a particular product (product dimension), during a particular month (time period
dimension) in all markets (market dimension).
In particular, the "time" dimension is commonly found in multidimensional modeling as it captures
historical data required to support many types of analytical applications such as trend analysis.
Data may be analyzed at various aggregation levels (e.g., at the national, division or region
levels) or may be "drilled down" to examine the underlying detail data.
The primary inputs to multidimensional data modeling in this task come from various sources
including:
The Conceptual Data Model, including the performance measurement entities,
quantitative measurement entities and unstructured data entities, developed in the
Analytical Processing Data Definition phase; and
The understanding of the organization's business events and processes obtained in the
Analysis and Decision Process Definition phase.
Page 203

The business analytical information requirements are translated into:

A set of Dimension Tables each describing a valid dimension of interest; and
A set of Fact Tables each describing the facts of interest relating to the corresponding
dimension or dimensions.
A physical multidimensional data design is then completed based on the nature and
characteristics of the InfoCube design in BW.
For further background information regarding multidimensional data modeling, refer to The Data
Warehouse Toolkit, Ralph Kimball, 1996 John Wiley & Sons.
A.12.11
Identify analytical dimensions.
Identify the analytical dimensions and facts by examining the business analytical information
needs:
Examine current data usage (i.e., bottom-up driven) such as:
report parameters (e.g., the selection criteria may directly suggest dimensions),
contents of the standard or selected ad hoc management reports (i.e., examining the
facts of interest to determine the corresponding dimensions), or
record keys (e.g., records keys such as Customer-ID or Product-ID may suggest
dimensions);
Examine the analysis and decision processes identified in the Analysis and Decision
Process Definition phase, specifically focusing on the performance measurement
processes and quantitative measurement processes;
Review the essential data characteristics of the organization's business events or
processes identified in the Analysis and Decision Process Definition phase. Determine
the major data views or perspectives of interest to users such as:
any events of a business process by time, agents, resources or locations,
any period of time by events, agents, resources or locations,
resources by type of event, time, agents or location,
agents by type of event, time, resources or locations, and
location by type of event, time, agents or resources;
Review the entity types defined in the ERM or CDM (e.g., a kernel entity may be a
candidate analysis dimension). The following exhibit depicts the identification of potential
dimensions on a CDM; and
Identify the attributes for each dimension describing the aspects of the dimension which
are of interest to the business analysts. These attributes may also be used as constraints
in selecting specific "acts" of interest in analytical processing; e.g., a sales trend analysis
may focus only on selected regions by selecting specifying selected values of the
attribute Region of the MARKET dimension.
These attributes will become either true characteristics of an InfoCube dimension or
navigational attributes of a dimensional characteristic.
Develop a logical data model of the relevant dimensions and facts within the scope of the project
as illustrated in the sample model.
Dimensions and facts are interdependent. On the one hand, dimensions may be determined
based on the identified facts; on the other hand, knowing the dimensions, facts may be
determined. Thus, identifying dimensions and facts is completed concurrently as an integral step.
Page 204

A.12.12
Define dimension tables.
Define a dimension table for each dimension identified in terms of:

A key that uniquely identifies the dimension; and
One or more attributes that describe the dimension.
In BW, dimensions of an InfoCube are likely to represent master data and their associated
attributes. They could be composed, however, of related characteristics.
The following exhibit provides an example of a MARKET Dimension Table that contains:
A key data element Market Key to uniquely identify an occurrence of the dimension table;
and
The following attribute data elements to describe the MARKET dimension:
Market Description,
Division,
Region, and
Market Level.
Page 205

Some of the characteristics or considerations in defining dimension tables include:

Dimension tables provide the basis for multi-data source integration. They define a user
perspective of data of interest to his/her business analytical activities. The dimension
key will usually result in a master data link to other related master data within the
business analytical or decision support data structure. The data to be retrieved may
come from different physical databases or database environments.
In general, a new key structure may need to be developed instead of using an existing source
system key for reasons such as:
dimension table data may come from multiple sources with multiple key structures,
the source system keys are often concatenated keys,
it may be necessary to integrate with external data or non-key file structures, and
a new key structure is necessary to store multiple summary levels of data in one
dimension table.
This new key structure will then define the keys of the InfoObject characteristic included in
InfoCube dimensions. These could also be compound InfoObjects.
For very large dimension tables (e.g., the TIME Dimension), an intelligent key structure should be
considered to facilitate database partitioning or fragmentation.
The key from the OLTP or source system may be stored as an attribute on the dimension table to
provide a linkage between the OLTP and the DW for data transformation processing;
The dimension tables should be easy to understand; e.g., business-oriented analysts
should be able to use the dimension tables without the need to know the technical
aspects of the system or to memorize specific coding or mnemonics schemes.
Business language should be used in designing attributes and attribute values to facilitate enduser access to data in the dimension table; e.g., the attributes in the MARKET Dimension Table
example indicate that "Philadelphia" (MARKET DESCRIPTION) is a "market" (MARKET LEVEL)
in the "Baltimore Region" (REGION) which is part of the "Eastern Division" (DIVISION). Businessoriented users may select this dimension based on the values of the attributes without having to
memorize that the key for this market is "4";
Page 206

A commonly used attribute in defining dimension tables is the "level" attribute which
describes the various aggregation (summary or roll-up) of atomic level facts relevant to
the related dimension; e.g., in the MARKET Dimension Table example, the MARKET
LEVEL attribute indicates that facts relevant to the "market dimension" may be retrieved
at the "national", "division", "regional" or "market" (atomic) levels. These are known as
internal hierarchies in BW;
External hierarchies may also be defined for dimension keys or attributes of a dimension
that define additional ways a given characteristics values can be aggregated; and
A sequence or order attribute may be defined to facilitate consistent and intelligent sorting
or ordering of the dimension table when the sort requirements are not based on numeric
data; e.g., a "MONTH ORDER" attribute may be defined to facilitate displaying data in
month name order.
An effective-date and/or currency indicator attributes will be required if source system data
changes need to be stored in the dimension tables; e.g., the following exhibit reflects the fact that
a customer, whose name was Mary Smith up until December 1994, changed her name to Mary
Jones since then. Mary Jones is still her current name. Query processing will have to take this
into consideration when returning the current information. These will determine if time-dependent
characteristics are to be included in InfoCubes;
Default or unknown values may be allowed in a dimension table especially when the
corresponding source data for the attribute is not mandatory; e.g., GENDER is often not a
mandatory attribute and thus should allow for an unknown attribute value;
Denormalized dimension tables may be defined to enhance their understandability. In
general, business information users may find it easier to visualize data consolidated in a
single chunk than to perceive data broken down into many smaller tables.
Denormalization may also simplify end-user access by providing short, medium, or long
text descriptions instead of just using code values.
A dimension table may also be denormalized for technical design considerations such as
improving performance by reducing the number of joins required.
Other concepts to be considered in defining dimension tables include:
Page 207

A TIME PERIOD dimension table is almost always required to facilitate the historical or
trending aspect of a DW; and
The more dimension tables, the greater the number of rows is required in the fact tables.
A.12.13
Define fact tables.
Identify the facts or measures of interest to analytical processing:

Review the analytical processing information needs identified in the Analytical Processing
Data Definition Phase (e.g., performance measures or quantitative measures); and
Categorize these information needs into the respective dimensions or dimension
combinations.
Facts represent the InfoObject key figures to be populated in the InfoCube.
Focus initially on identifying a preliminary set of representative measures which serve various
purposes including:
Helping to identify or validate the dimensions or dimension combinations;
Adding to the understanding of the related dimensions (i.e., the facts serve to describe
the related dimensions);
Capturing any known facts of interest to the users in business or decision analysis; and
Providing a starting basis for user prototyping in validating or elaborating the analytical
processing requirements (i.e., the identified dimensions and facts).
Define a fact table for each group of facts with the same set of dimensions in terms of:
A key component containing key data elements pointing to the relevant dimension of the
fact table; and
A fact component containing attribute data elements representing the facts of interest.
The primary key of a fact table is generally a concatenation of the foreign keys of the related
dimension tables.
Some of the characteristics or considerations in defining fact tables include:
The measures in a fact table may be of various types such as:
unit volumes, revenue, cost or distribution metrics,
non-additive information (e.g., average price or average cost), and
derived or calculated information (e.g., gross margin amount);
The measures generally involve time series data or may be appropriately cast into a time
series format to support trending. Thus, a fact table often includes a time dimension as
one of its key data elements;
Aggregation measures (i.e., roll-up of selected lower level measures) based on selected
attributes (often defined as "level" attributes) from one or more dimension tables may be
represented in fact tables to facilitate aggregation level analysis; and
Fact tables are frequently designed to support "drill-down" analysis of detailed measures
underlying an aggregation measure.
The next exhibit provides an example of a fact table showing the Dollar Sales and Unit Sales (the
facts of interest) for each valid combination of the PRODUCT, MARKET and PERIOD
dimensions. Using this fact table, an analyst may:
Request information (i.e., Dollar Sales or Unit Sales) from the fact table based on the
dimension values of interest (i.e., a specific PRODUCT/MARKET/PERIOD combination);
"Drill-down" into the underlying detail data supporting an aggregate measure (e.g., the
underlying detail "market level" measures supporting the aggregate measure at the
"region" level as defined in the MARKET dimension); or
Page 208

Perform calculations involving specific "cells" of the fact tables to meet the information
needs of a particular business or decision analysis situation.
A.12.14
Validate the dimension and fact tables.
Cross-check the dimension and fact tables to ensure their consistency. Revise or refine the tables
as needed.
A.12.15
Develop a physical multidimensional data design.
Develop a physical database structure supporting the dimension and fact tables defined in the
previous steps considering factors such as:
Denormalization requirements;
Design parameters or BW InfoCubes and InfoObjects; and
Performance considerations.
The next exhibit provides an example of a physical data model in the form of a star schema
linking a fact table to the related dimension tables.
Page 209

Page 210

A major design consideration in developing a multidimensional physical data model includes:

Aggregation strategy - It relates to the issue of whether summary data should be stored
or calculated as needed. The trade-off is between increased data storage and faster
query times. If the end-user access or middleware tools used provide very fast and
efficient aggregation processing, the amount of stored summary information may be able
to be reduced. In general, summary data should be physically stored when:
many rows are involved in the calculations,
the queries against the calculated data are run frequently,
the calculation requirements frequently change,
there is a need to standardize the calculation to avoid incorrect values,
the selected tools do not facilitate fast and easy aggregation, or
adequate storage capacity is available.
The query activities of the DW environment should be monitored and the design parameters,
such as the aggregation strategy, should be re-evaluated on a regular basis, using the BW
Statistics InfoCube.
The next task, L3 InfoCube Design, addresses the physical InfoCube design parameters that
must be addressed
A.12.16
Complete a structured walk-through of the multidimensional
data model.
Complete a structured walk-through of the multidimensional data model to confirm its
completeness and consistency. Resolve any questions or issues and make any changes as
necessary. Obtain formal written approval.
Page 211

A.12.17
InfoCube Design
A.12.18
Identify Key Figures Required for Each Subject Area
Purpose
The purpose of this activity is to identify and document key figure (facts) requirements for each
functional area.
Procedure
Review the following documents for technical and functional requirement for each Key Figure:
Information Access Environment Document
Data Definition
Multi-Dimensional Data Model
High-level Design
Identify, review and document the following:
InfoSource enhancement requirements for each Key Figure
Aggregate requirements for each Key Figure
Data extract schedule requirements for each Key Figure
Data volume requirements and infrastructure implications for each Key Figure
Transfer Routine user exit requirements for these key figures in BW
Conversion Routine user exit requirements for these key figures in BW
Update Rules requirements for each Key Figure
VBA routines required in the Excel Workbooks for each key figure
Key Figures include in target InfoCube, Templates, Channels, Excel Work Books
Currency or unit of measure requirements for these key figures
Cross modular integration and cleansing requirements each cross modular key figure
Presentation characteristics of each key figure (summarized with hierarchy, shown in
thousands, etc.)
Navigational characteristics of each key figure
Delta versus full update for each key figure
Key figures used for calculated key figures
Key figures used for restricted key figures
Result
The exact flow of key figures from the source system to an InfoObject in a report is clearly
defined. All aspects of the transport and presentation of the key figures for end users should be
reviewed and clearly documented.
A.12.19
Identify Characteristics Required for Each Subject Area
Purpose
The purpose of this activity is to identify and document characteristic requirements for each
functional area.
Procedure
Review the following documents for technical and functional requirement for each
Characteristic:
Page 212

Data Definition
High-level Design
InfoSource enhancement requirements for each Characteristics
Aggregate requirements for each Characteristics
Data extract schedule requirements for each Characteristics
Data volume requirements and infrastructure implications for each Characteristics
Transfer Routine user exit requirements for these Characteristics in BW
Conversion Routine user exit requirements for these Characteristics in BW
Update Rules requirements for each Characteristics
VBA routines required in the Excel Workbooks for each Characteristics
Characteristics include in target InfoCube, Templates, Channels, Excel Work Books
Currency or unit of measure requirements for these characteristics
Cross modular integration and cleansing requirements each cross modular
characteristics
Presentation characteristics of each characteristics (using a hierarchy)
Navigational characteristics of each characteristics
Delta versus full update for each characteristics
Language requirements for each characteristics
Result
The exact flow of characteristics from the source system to an InfoObject in a report is clearly
defined. All aspects of the transport and presentation of the characteristics for end users should
be reviewed and clearly documented.
A.12.20
Identify Dimensions Required for Each Subject Area
Purpose
The purpose of this activity is to identify and document dimension requirements for each
functional area.
Steps
Review the following documents for technical and functional requirement for each Dimension:
Data Definition
High-level Design
InfoSource enhancement requirements for each Dimension
Aggregate requirements for each Dimension
Data extract schedule requirements for each Dimension
Transfer Routine user exit requirements for these Dimension in BW
Conversion Routine user exit requirements for these Dimension in BW
Update Rules requirements for each Dimension in BW
VBA routines required in the Excel Workbooks for each Dimension
Dimension include in target InfoCube, Templates, Channels, Excel Work Books
Currency or unit of measure requirements for these dimension
Cross modular integration and cleansing requirements each cross modular dimension
Presentation characteristics of each dimension (using a hierarchy)
Page 213

Result
The exact definition of each dimension from each functional area should be clearly identified. All
aspects of the presentation of the dimension for end users should be reviewed and clearly
documented.
A.12.21
Identify Compound Characteristics Required for Each Subject
Area
Purpose
The purpose of this activity is to identify and document compound characteristic requirements for
each functional area.
Procedure
Review the following documents for technical and functional requirement for each Compound
Characteristic:
Data Definition
High-level Design
InfoSource enhancement requirements for each Compound Characteristics
Aggregate requirements for each Compound Characteristics
Data extract schedule requirements for each Compound Characteristics
Data volume requirements and infrastructure implications for each Compound
Characteristics
Transfer Routine user exit requirements for these Compound Characteristics in BW
Conversion Routine user exit requirements for these Compound Characteristics in BW
Update Rules requirements for each Compound Characteristics
VBA routines required in the Excel Workbooks for each Compound Characteristics
Compound Characteristics include in target InfoCube, Templates, Channels, Excel Work
Books
Currency or unit of measure requirements for these Compound characteristics
Cross modular integration and cleansing requirements each cross modular Compound
characteristics
Presentation characteristics of each Compound characteristics
Navigational characteristics of each Compound characteristics
Delta versus full update for each Compound characteristics
Language requirements for each Compound characteristics
Result
The exact flow of Compound characteristics from the source system to an InfoObject in a report is
clearly defined. All aspects of the transport and presentation of the Compound characteristics for
end users should be reviewed and clearly documented.
Page 214

A.12.22
Identify Calculated Key Figures Required for Each Subject
Area
Purpose
The purpose of this activity is to identify and document the calculated key figure requirements for
each functional area.
Procedure
Review the following documents for technical and functional requirement for each Calculated
Key Figure:
Data Definition
High-level Design
InfoSource enhancement requirements for each calculated Key Figure
Data extract schedule requirements for each calculated Key Figure
Infrastructure implications for each calculated Key Figure
VBA routines required in the Excel Workbooks for each calculated key figure
Currency or unit of measure requirements for these calculated key figures
Cross modular integration and cleansing requirements each cross modular calculated
key figure
Presentation characteristics of each calculated key figure (summarized with hierarchy,
shown in thousands, etc.)
Navigational characteristics of each calculated key figure
Delta versus full update extract of data impact for each calculated key figure
Result
The exact definition of the calculated key figure clearly defined. All aspects of the presentation of
the calculated key figures for end users should be reviewed and clearly documented.
A.12.23
Identify Hierarchies Required for Each Subject Area
Purpose
The purpose of this activity is to identify and document hierarchies requirements for each
functional area.
Procedure
Review the following documents for technical and functional requirement for each Hierarchy:
Data Definition
High-level Design
InfoSource enhancement requirements for each Hierarchies
Aggregate requirements for each Hierarchies
Data extract schedule requirements for each Hierarchies
Data volume requirements and infrastructure implications for each Hierarchies
Transfer Routine user exit requirements for these Hierarchies in BW
Page 215

Conversion Routine user exit requirements for these Hierarchies in BW

Update Rules requirements for each Hierarchies
VBA routines required in the Excel Workbooks for each Hierarchies
Hierarchies include in target Templates, Channels, Excel Work Books
Currency or unit of measure requirements for these Hierarchies
Cross modular integration and cleansing requirements each cross modular Hierarchies
Presentation characteristics of each Hierarchies
Delta versus full update implications for each Hierarchies
Result
The exact definition of the hierarchies are clearly defined. All aspects of the presentation of the
hierarchies for end users should be reviewed and clearly documented.
A.12.24
Identify Aggregates Required for Each Subject Area
Purpose
The purpose of this activity is to identify and document aggregates requirements for each
functional area.
Procedure
Review the following documents for technical and functional requirement for each Aggregate:
Data Definition
High-level Design
Data extract schedule requirements for each Aggregates
Data volume requirements and infrastructure implications for each Aggregates
Aggregates include in target InfoCubes, Excel Work Books
Delta versus full update implications for each Aggregates
Result
The identification and documentation of the exact aggregate required .
A.12.25
Identify Business Rules by Field for Each Subject Area
Purpose
The purpose of this activity is to identify and document business rules by field for each functional
area.
Procedure
Review the following documents for technical and functional requirement for each Business
Rule:
Data Definition
High-level Design
Identify, review and document business rules for the following:
For each Characteristic
Page 216

For each Key Figure
Result
The identification and documentation of the exact business rule required for all objects, processes
and reports in BW.
A.12.26
Identify Data and Retention Requirements
Purpose
The purpose of this task is to identify data and retention requirements for BW InfoSource and
InfoCube Objects. Identify the processes and functions where InfoSources and InfoCubes are
updated and/or archived. Determine how long data should be stored on-line and how long data
should be archived according to defined corporate standards.
Procedure
Determine Data Retention Requirements

Define levels at which the data will be stored and the retention period for each level.
Identify the amount of historical data that will ideally be required and how much is actually
available that is accurate.
Based on how the data will be used, determine the need for a detail sample (living sample) of
the summarized data.
Define Detail Specification

The task develops the technical specification for creating a layout set. The Application
Architect and Technical Architect define the specification. When it is defined, the Business
Process Master List must be updated with the new set, and mapped to the business process
that triggers it.
Are there statements about archived data for:

Test procedures and plans to evaluate archived data
Retention period for archived data
Reloadability of data into the BW System
What Data is needed to ensure successful external and internal auditing in the applications?
For example:
Double archiving
Archives kept externally
Are there inconsistencies, gaps, or overlaps for the applications?
Are owners for the standard procedure appointed for the archiving processes in the
application?
Is the division of responsibilities defined between the application and Basis?
Is there a Company procedure depicting the division of responsibilities:
Is BW application team is responsible for customizing, scheduling, performing, and
validating archiving?
Does the IT department provides the system support, and is it responsible for retaining
data to meet auditing requirements?
Page 217

Do the IT and BW application departments agree on joint procedures for exceptional

situations or problems? The BW application team must own the procedure.
Work with the business process owners to supply missing details
Results
Create an archiving manual, based on the information gathered, to record standard procedures
and schedules, and what to do in exceptional circumstances
Page 218

A.12.27
Submit Data Design Deliverable
Purpose
To assemble the various data design deliverables.
Overview
When approved by management, the data design specification assembled in this task will be
refined in the Realization Stage and be developed as InfoCubes and ODS.
The data design deliverable is discussed with management and approved. In some
circumstances, this task may be delayed and completed as part of the Business Blueprint
Checkpoint Phase.
A.12.28
Assemble data design deliverable.
specification packages.
A.12.29
A.12.30
open data design issues should be resolved before the completion of this phase.
A.12.31
Submit and discuss the data design deliverable.
Discuss the data design deliverable with management and resolve any questions and issues. If
necessary, prepare an action list of items to modify. This step may require more than one
meeting.
A.12.32
Obtain formal written approval of the data design deliverable.
Page 219

A.13 User Documentation

Purpose
To create a set of descriptions and instructions to guide the user in operating and managing the
system.
Overview
This phase addresses the development of all types of user documentation and because of the
inter-linkages, should be considered together with the Training Phase.
The project team must first determine which types of information must be produced. These may
include paper-based volumes such as user manuals and operations guides as well as automated
types such as on-line information and on-line Help.
Once the different types and media have been determined, standards must be defined or adopted
from existing standards for all components. The contents of the different items are then derived
together with any supporting information.
If the proposed system involves a significant amount of organizational change, the User
Documentation and Training Phases will take on even more importance than normal as they are
the phases that assist in forming the users' perception of the overall system.
Paper-based Documentation
Where paper-based documentation is to be prepared, the approach used in this phase is that the
paper-based documentation consists of three main parts:
Introduction - describes the organization and format of the document, a summary-level
description of the system and interfaces to and from the system;
Procedures Summary - describes the system's purpose and what the system does. It
also describes what procedures are documented and their interrelationships; and
User Procedures - describes the individual activities that need to be understood to use
and manage the system and includes the detailed documentation created for each
procedure identified in the procedures summary.
Careful attention has been paid in this phase to the level of detail at which the paper-based
documentation is prepared. The bulk of the user documentation is written at a medium level of
detail while recognizing that, on specific occasions, greater detail may be required.
If the approach to be used for preparation of the paper-based documentation is different, then
further customization of the work tasks and steps will be required.
Help System Development
The development of User Documentation as on-line Help is included in this phase as a complete
and separate task (Develop On-line Documents Sub-system). However, some of the detailed
steps should have been completed at earlier points in the methodology. All of the necessary work
steps to create the Help system have been included in this phase to assist in overall project
planning and project management.
Page 220

User Documentation Task Relationships

M 1
D e t e r m in e U s e r
D o c u m e n t a t io n
S tra te g y a n d W o rk
P la n s
R o le s a n d R e s p o n s ib ilitie s
M 2
E s ta b lis h P a p e r - b a s e d
D o c u m e n ta t io n
S ta n d a rd s
U
U
D
D
D
ser
ser
ocu
ocu
ocu
D
D
m
m
m
o c u m e n ta t io n S t r a t e g y
o c u m e n ta t io n w o r k p la n
e n ta t io n A u d ie n c e t a r g e t
e n t a t io n D is tr ib u t io n lis t
e n ta t io n C o n te n t
D o c u m e n t a tio n s t a n d a r d s
D o c u m e n t a t io n d e liv e r y m e c h a n is m
D o c u m e n t a tio n r e s p o n s ib ilitie s
M 7
D e v e lo p O n - lin e
D o c u m e n ts S u b S y s te m
O n - lin e U s e r D o c u m e n t a t io n
D o c u m e n t a t io n C o n t e n t
M 3
P re p a re P a p e r-b a s e d
D o c u m e n t In t r o d u c t io n
D o c u m e n t a t io n in t r o d u c t io n
P r o c e s s D e f in it io n D e liv e r a b le
A p p lic a t io n D e s ig n D e liv e r a b le
M 4
D e v e lo p P a p e r - b a s e d
U s e r D o c u m e n t a t io n
D ocum ent Body

- U s e r D o c u m e n ta tio n O v e r v ie w
- M a n a g e m e n t S u m m a ry
- U s e r P ro c e d u re s
- S y s t e m R e s p o n s ib ilit ie s
M 5
P re p a re P a p e r-b a s e d
A p p e n d ic e s
D o c u m e n t A p p e n d ic e s
- S e c u r it y P r o f ile s
- P r o c e s s in g S c h e d u le s
M 6
S u b m it P a p e r - b a s e d
U s e r D o c u m e n t a tio n
P a p e r - b a s e d U s e r D o c u m e n t a t io n D e liv e r a b le
Page 221

A.13.1Determine User Documentation Strategy and Work Plan(s)

Purpose
To determine the target user audience and their particular documentation needs, to define the
types of documentation to be developed and to produce a work plan for the development of the
appropriate user documentation.
Overview
Before this phase may proceed, the system's intended user community must be determined.
Once the users are identified, their needs for documentation, both automated and manual are
then derived.
Each project has its own special needs and project teams must be careful not to overlook
important aspects of each user community. The training needs analysis may also form useful
input to this task.
A.13.2Create project team and detailed work plan.

Define the specialist skills needed to develop the paper-based or on-line documents.
Select and create the project team.
Develop a detailed work plan for all of the tasks necessary to create fully tested and working User
Documentation.
Ensure that the User Documentation work plan is fully integrated with the overall project work
plan.
While it is generally recommended that a start is made on User Documentation early in the
project so that deliverables are available to assist in Training and System Testing, this approach
can result in a high degree of re-work. As requirements and the "look and feel" of the application
evolve during analysis and design, care needs to be taken not to stray too far in front of the
application in developing User Documentation, unless it is clearly not going to change.
A.13.3Identify target audiences for documentation.

Identify the target audience for the user documentation and determine their characteristics. This
should also include management's needs.
Answer questions such as:
Who will be using the system?
Where are the users located?
What will be the frequency of updates both for the system and the user documentation?
Will there be different levels of users?
What sorts of skills will each user level have?
Is resistance anticipated from any user level?
A.13.4Determine documentation need by target audience(s).

Once the target audiences have been identified, their documentation needs can be defined, e.g.,
a user level with little or no computer background would need documentation with a very different
focus from a user level with sophisticated systems skills.
Page 222

Determine the user documentation needs by target audience and which should also be linked to
the training needs assessment and training course content as some material may be common.
A.13.5Define types of documentation to be developed.

Once the user levels and document needs have been identified for the target audience, define the
types of documents to be developed that are appropriate for the target audience.
Paper-based document types may include:
System overview/summary;
User manuals or guides;
User procedures;
Systems procedures; and
Supplementary documents such as Help Desk procedures.
Automated document types may include:
On-line Help - electronic files that form an integral part of the application; and
Information - electronic versions of user manuals that can be referenced with differing
degrees of sophistication depending upon the functionality of the access software used.
A.13.6Review and obtain approval of the user documentation strategy and

work plans.
Discuss the proposed user documentation strategy and detailed work plans with management
and obtain approval.
Page 223

A.13.7Establish Paper-based Documentation Standards

Purpose
To prepare standards that provide a consistent approach to the preparation and maintenance of
the paper-based user documentation.
Overview
User documentation standards are required to address how the documents should be prepared
and how they should look. They define a format that allows for consistency across documents
and for future document maintenance.
A.13.8Define or confirm use of user documentation standards.

Define documentation standards. These should address:
Numbering and naming conventions;
Style (language and text format);
Organization issues (e.g., chapters v. modules);
Format, stationery sizes and types and binding;
Word processing/graphics/desktop publishing software to be used for initial preparation
and ongoing maintenance; and
Production, archiving and distribution policies.
When the organization has existing user documentation standards in use, they should be
adhered to or altered accordingly.
A.13.9Determine media to be used.

Determine how the documents are to be distributed such as in three-ring notebooks, bound
volumes, on diskettes, on compact disk or by e-mail.
A.13.10
Determine responsibilities.
Establish the responsibilities for:

Initial publishing;
Ongoing maintenance/updates;
Change control;
Storage/distribution; and
Training linkages.
A.13.11
Discuss and obtain formal written approval of the paper-based
documentation standards.
Page 224

A.13.12
Prepare Paper-based Document Introduction
Purpose
To provide an introduction for each paper-based document.
Overview
Each document should have an introductory chapter or module that describes the format and
organization of the volume, the audience for whom it is intended and instructions for its use.
A.13.13
Prepare document introduction.
Using the definition of types of documentation to be developed produced earlier in the phase,
prepare an introduction for each document. This should describe:
What aspect of the system the document addresses (e.g., user guides, system
operations manuals);
Which users the particular document addresses (e.g., casual users, full-time users);
The intended use of the document; and
Related documents.
A.13.14
Prepare document usage instructions.
Prepare a narrative that describes the format of the document. This should describe the
organization and medium of the document and include sample forms, a catalogue and description
of icons (symbols) used and a list and definition of any reserved words.
This task should also indicate how the materials are to be used, e.g., should the user read it, use
it in concert with the application or use it as a training reference.
A.13.15
Discuss and confirm the paper-based document introductions.
Page 225

A.13.16
Develop Paper-based User Documentation
Purpose
To create the main section of each document to be produced.
Overview
The main section of each document is written during this task. Any appendices or supporting
documentation to accompany the main body is created in the next task.
A.13.17
Identify user documentation requirements.
Determine what user documentation is required. Key considerations are who will use the
information and how much detail is required.
A.13.18
Prepare table of contents.
Develop a structure to incorporate all user procedures identified into groups of logically related
processes. Each logical grouping of user procedures is defined in the table of contents for the
documents.
A.13.19
Prepare User Documentation Overview.
The User Documentation Overview provides a visual representation of the system and the
procedures needed to support the system. It shows the user's interactions with the system and
defines the scope of the system to the user. All user procedures identified are placed into groups
of logically related processes.
Define a numbering scheme for the user procedures and assign a number to each user
procedure.
A.13.20
Prepare management summary.
Prepare the management summary which is a general description of the system. It should
incorporate an updated Management Overview Diagram or other Abstracts and support the User
Documentation Overview by explaining the system in terms of:
Business needs and objectives that the system is designed to meet;
Scope of the system in terms of the processes incorporated to meet the objectives;
What the system does;
Primary users of the system;
Key features of the system; and
Major inputs and outputs of the system.
A.13.21
Prepare User Procedures.
Prepare the User Procedures which form the main body of the document. They describe the
manual activities to be executed in sequence and their main purpose is to inform users how to
complete the different tasks that compose the various processes in the system and identify:
The starting and ending points of the procedure;
The steps to be completed;
The sequence of the steps; and
The person(s) responsible for completing the steps.
The main components of each User Procedure are:
Responsibility - Who completes the action;
Page 226

Procedure steps - What action to take presented in a logical time sequence and any
dependencies on other User Procedures; and
Supporting documents - Which things (e.g., reports, input forms or control logs) are
related to and needed to complete the procedure step.
Each procedure step should begin with a strong action verb telling the person responsible what to
do. The procedure steps are described in order of occurrence and sequentially numbered.
A.13.22
Prepare Detail Task Descriptions, if necessary.
Where the responsibility for a set of procedure steps is long, complex or detailed, then it may be
easier to document these steps as a Detail Task Description, which details work steps for a single
individual. The Detail Task Description does this without overloading the User Procedure with too
much detail as they are written at a more detailed level than the User Procedure.
It describes the sequence of work steps in a similar manner to the User Procedure with action
verbs and work steps in a logical time sequence, sequentially numbered.
Prepare any Detail Task Descriptions, as necessary.
A.13.23
Assemble and cross-reference Report Layouts.
Assemble samples of each report for inclusion with the User Procedures. These provide a visual
representation of the information produced by the system.
Cross-reference the Report Layouts to the procedures they relate to for ease of use. The Report
Layouts can be either a mock-up of the report or a copy of an actual report from the system. The
means used to create or initiate the reports is also included.
A.13.24
Document System Responsibilities.
Document the System Responsibilities which define the roles of the users as they relate to the
system. They define the title of the user and the types of procedures for which the user is
responsible.
A.13.25
Discuss and confirm the content of the draft User
Documentation content.
Page 227

A.13.26
Prepare Paper-based Appendices
Purpose
To create any supporting paper-based appendices.
Overview
To make it easier for users to navigate through a particular document, information that is useful
but not appropriate to place in the body of the document should be included as an appendix.
Alternatively, the appendices may be prepared as separate documents and not be included as
part of the User Procedures manual as the distribution may be different.
A.13.27
Prepare glossary.
Develop a glossary of key terms in simple and clear language and terminology with which the
users are familiar. Also include definitions of key data elements and their relationship to other
data elements used in the system.
A.13.28
Document system interfaces and data transformation.
Document the system interfaces and the data transformation flows.

The data transformation systems are documented in the Management Overview Diagram and
should include:
Information received from other systems;
Method used to exchange information;
Controls used to ensure the accuracy of all the information exchanged; and
Balancing and reconciliation procedures necessary to keep all of the various systems in
balance.
A.13.29
Document processing schedules.
Document the processing schedules which include details of the frequency with which each part
of the system is run such as a monthly closing schedule.
The schedule should include references to the User Procedures covered by the schedule, the
names of the User Procedures, when they are executed, in what order they are executed and any
cut-off dates that must be met.
A.13.30
Document other appendix items.
Create any other appendix items, as necessary.
A.13.31
Discuss and confirm the draft paper-based appendices
content.
Page 228

A.13.32
Submit Paper-based User Documentation Deliverable
Purpose
To provide a management checkpoint at which the paper-based user documents can be reviewed
and verified.
Overview
The change control procedures and responsibility for ongoing maintenance of the paper-based
documents are defined.
All of the paper-based documents developed during this phase are consolidated into a user
documentation deliverable. This deliverable is reviewed for content and clarity and presented to
management for approval.
A.13.33
Define User Documentation change control procedures.
Define change control steps necessary to update the user documentation with amendments
derived from system testing.
Define ongoing maintenance responsibilities and steps to ensure that the user documentation is
kept current once the system has commenced live production.
A.13.34
Assemble and review paper-based documentation deliverable.
Consolidate the individual parts of the paper-based User Documentation prepared during this
phase.
Review on the basis of content and clarity of presentation.
A.13.35
Submit and discuss documents with management.
Discuss the documents with management and resolve any questions and issues.
If necessary, prepare a list of items to be modified. In practice, this step may involve more than
one meeting to resolve outstanding issues.
A.13.36
Obtain formal written approval of the completed documents
and arrange distribution.
Obtain formal written approval.
Complete the reproduction and distribution of the completed documents. Include the control
logging of the distribution for subsequent update purposes.
Page 229

A.13.37
Develop On-line Documents Sub-system
Purpose
To develop the on-line portion of the user documentation.
Overview
This task outlines the activities that support the development of on-line documents either as a
supplement to or replacement of paper-based documentation.
Very often a project will include the development of on-line documents for all or part of the User
Documentation. These generally include two main types of on-line document:
Help - where the User Documentation is programmed as an integrated part of the new
system's functionality; and
Information - where the User Documentation is in a similar format to the paper-based
procedures but is stored and presented in an electronic fashion.
Depending upon the specific project, this can be a long, complex task. The development of Help
systems must be integrated with the development of the system itself. On some occasions,
because of the scale of the project and the different skills mix required, a separate sub-group or
project team may need to be formed to complete the Help system development.
A.13.38
Select on-line document development tool (optional).
As mentioned above, many operating systems provide facilities for the development of on-line
documentation. If the operating system or development tools do not provide for this, select an
appropriate on-line documentation development tool at this time.
This may require a formal tool requirements definition to be prepared and a package software
evaluation and selection to be completed.
A.13.39
Define or confirm use of Screen/Window Layout and text
composition standards.
Define on-line document standards that should include:
Screen/window types (e.g., warning, Help, glossary);
Screen/window size, layout and colors;
Criteria for creation (when should a screen/window be created);
Content (e.g., what is included/excluded); and
Navigation guidelines (e.g., function key usage).
Where on-line document standards are already defined and being used, they should be adhered
to. The on-line document screen/window standards should also conform to application
screen/window standards for the project (where applicable). Before commencing text
composition, standards must also be established including:
Verb tense;
First, second or third person usage; and
Style.
A.13.40
Develop the Help text.
Using the selected development tool, design, write and create the Help text. The Help text design
will need to map exactly to all of the system's functionality including:
Page 230

System introduction and overview;

All input/output/inquiry/interface processing;
All file maintenance;
Security and controls including housekeeping and system balancing; and
Glossary/explanation of terms and acronyms.
As each component of the Help system is developed, complete structured walk-throughs to

ensure that the contents are of the requisite quality and accurately support and reflect the
system's functionality.
A.13.41
Load and test Help text at the program level.
There is always difficulty in loading and testing the Help text during a project, as it is rare that the
final system is completed and time is available for separate addition of the Help system.
Ideally, the Help text should form part of the Unit and Component Testing of each program in the
system that contains Help text. If this is not possible, the Help text must be added to these fully
tested single programs and then re-tested to ensure that the Help text functions as designed and
the program continues to function as specified after the addition of the Help text.
This will necessitate careful consultation with the application development group to minimize
duplication in the testing process. Load and test the Help text at the program level.
A.13.42
System testing of Help text.
Ensure that all of the unit/component tested text is included within the system testing process.
The Help system should form an integral part of the overall System Integration and Testing and
not be treated separately.
Change control steps necessary to update the Help text with amendments derived from system
testing need to be created.
A.13.43
Develop ongoing maintenance procedures for the Help
system.
To ensure that whenever any subsequent changes are made to the system once it has
commenced live processing, define the tasks necessary to maintain the Help system in
synchronization with the changed functionality.
The responsibilities/resources necessary to complete the maintenance should be determined and
agreed.
A.13.44
Develop on-line information.
Develop the on-line information where the User Documentation is presented as an electronic form
of paper-based documents, the development process should largely follow the steps described
above for the development of the Help system.
A.13.45
Submit and discuss the on-line documents with management.
Discuss the on-line documentation content with management and resolve any questions and
issues.
Page 231

A.13.46
Obtain formal written approval of the completed on-line
documents sub-system.
Obtain formal written approval of the completed on-line documents sub-system. This should also
include definition and approval of the responsibilities for:
Ongoing maintenance/updates;
Distribution of changes and additional access to the sub-system; and
Training linkages.
Page 232

A.14 Training
Purpose
The objectives of this phase are:
To provide management with an overview of the new system; and
To teach users how to complete their work procedures with the new system.
Overview
It is assumed that all of the Training Phase tasks and steps will be completed in conjunction with
the organization's Training or Human Resource departments. This should ensure that there is full
participation and involvement, which should result in a seamless hand over of all items.
This phase is aimed primarily at the training needs of the user community and facilitates the
introduction of the DW system to its users to ensure that there is both comprehension of the
capabilities of the system and an understanding of how to use it.
Training should be tailored to management and groups of users based on their position in the
organization and their expected use of the system. For each of these groups, course materials
are developed with the approach and content of each course module being determined by its
learning objective.
Instructors are trained to ensure that they are able to convey the course content using the
prescribed approach. If the course is to be repeated several times, then a pilot training session
can be run to validate the training. The pilot training session is evaluated and the training
approach and materials modified, if necessary, before the main training sessions are scheduled
and conducted.
The training needs assessment occurs throughout the DW project and training needs are defined
and actioned progressively throughout the project. Although the emphasis in this phase is on user
training, the same tasks can be used to assess other training needs such as the needs of the
development project team and to schedule/develop appropriate training. For instance, it may be
necessary to have team members attend specific tool training in the Prototyping Phase before the
Realization Stage activities.
Page 233

Training Task Relationships
P e r s o n n e l d e t a ils
T r a in in g n e e d s
N1
Id e n t ify P e r s o n n e l t o
b e T r a in e d
N2
D e t e r m in e T r a in in g
S c o p e a n d S tra te g y
N3
D e v e lo p T r a in in g
C o u r s e M a t e r ia ls
N4
D e v e lo p a n d C o n d u c t
I n s t r u c t o r T r a in in g
( o p tio n a l)
N5
C o n d u c t P ilo t T r a in in g
S e s s io n s ( o p tio n a l)
N6
C o n d u c t T r a in in g
S e s s io n s
Page 234
P e r s o n n e l r e q u ir in g t r a in in g
T r a in in g S c o p e a n d S tr a t e g y
T r a in in g c o u r s e m a te r ia ls
- C o u r s e M o d u le
- L e a r n in g O b je c t iv e s
- T r a in in g M e t h o d s
- T r a in in g T e c h n iq u e s
- C o u r s e P la n /S c h e d u le s
- In s ru c to r M a n u a l
- P a r tic ip a n t W o r k b o o k
In s tr u c to r G u id e
I n s t r u c t o r T r a in in g M a t e r ia ls
R e v is e d T r a in in g M a t e r ia ls a n d A p p r o a c h
T r a in e d P e r s o n n e l

A.14.1Identify Personnel to be Trained

Purpose
To identify the target audiences, their levels and their work activities.
Overview
To build an effective training program, the target audiences, their levels and work activities all
must be identified. This initial analysis provides the basis for developing appropriate courses to
meet the specific requirements of each group.
A.14.2Confirm application and automation boundaries.

Confirm the scope of the DW and the positioning of automation boundaries as a means of
establishing the areas of the business that will require training.
A.14.3Identify target audiences.

To develop appropriate training programs, information must be gathered regarding the needs of
each group of potential training students. Assess:
Level within the organization (e.g., management, clerical, operational);
System responsibilities (e.g., users, system maintenance operations); and
Experience level and skill base of identified personnel.
A.14.4Determine how each of the personnel within a group will interact

with the new system.
Each group will interact with the system differently, e.g., management may be enquiry only users,
while data entry staff may be on-line maintenance users only. Each of these different groups may
require separate training courses that should be tailored to that group's specific needs.
A.14.5Determine the numbers and locations of personnel to be trained in

each group.
The numbers and locations of personnel to be trained in each group may affect the instructional
method chosen, training resources required, number of training sessions scheduled and/or
required training time needed.
A.14.6Confirm with management the personnel to be trained.

Present the potential trainee list to management to verify the assessment of who must be trained
and their relationships with the system. This information must be as accurate as possible as it will
have an effect on the number, size and type of training courses to be developed.
A.14.7Obtain formal written approval of the personnel training profile.
Page 235

A.14.8Determine Training Scope and Strategy

Purpose
To determine the training needs and the type of training to be conducted.
Overview
Once the personnel to be trained are identified, then the training scope and strategy can be
defined.
The scope defines the number of courses to be developed, their purpose and number of training
sessions.
The strategy determines whether training will be completed by a group of teachers or by a
nucleus of trained staff. The nucleus of trained staff can either train the next level of staff or use
self-teaching modules that are passed on to other staff members.
A.14.9Identify training courses.

In assessing the training courses required, it is mandatory that the organization-wide impact of
the system is considered and not just the impact upon the immediate users of the system.
Define the training courses needed based upon individual requirements. Courses may be
required in areas such as:
System features and overview;
Balancing/reconciliation for daily processing and period-end and year-end processing;
and
Data conversion.
In addition to these general areas, consideration should be given to addressing project-specific
issues in the training such as:
Implementation issues;
Sub-system interface issues; and
Organizational structure issues.
If a Help Desk support function is to be provided, specific training for the Help Desk support
personnel may be required.
In addition to the detailed aspects of the day-to-day operation of the system, management
training in the system should not be ignored. Some high-level and specific training in the
management issues of the system should also be created.
Based on the types of courses needed and the levels of the target activities and their activities,
identify each of the training classes to be prepared. Include:
Course title;
Course purpose and prerequisites;
Target audience;
Estimated number of sessions;
Estimated number of students for each session; and
Optimum class size.
Page 236

A.14.10
Determine the instruction strategy for each course.
The instruction strategy defines the means of delivery of the different courses. Consider various
options such as:
Self-taught courses, e.g., interactive computer-based training (CBT);
Classroom sessions taught by a team of instructors;
Classroom sessions taught by trained staff members who become the trainers of other
staff members;
One-on-one training for some senior managers;
Use of supplier or external third-party training; and
Use of discovery learning (simulation of actual tasks).
A.14.11
Develop standards for each type of training.
If standards do not exist, they should be created for such items as:
Style (language and text format);
Organization issues;
Format, stationery and binding;
Page size;
Responsibility for ongoing storage, maintenance, publishing and distribution; and
Production responsibilities.
Standards are required for:
Presentation and preparation software (e.g., word processing, graphics, desktop
publishing);
Student workbooks - style and content;
Overheads and 35 mm slides;
Instructor guides - style and content (optional); and
CBT authoring software.
A.14.12
Create training development work plan.
Construct a comprehensive training development work plan, based on the training strategy,
A.14.13
Discuss and obtain formal written approval of the training
scope and strategy.
Page 237

A.14.14
Develop Training Course Materials
Purpose
To prepare course materials for each course module based on the specific method of delivery.
Overview
The content of each course module is determined by considering the course learning objectives
and the level of target audience(s). Training approaches and supplemental training techniques
are selected for each course module. The course modules are sequenced and course materials
are developed.
A.14.15
Determine learning objectives for each course and course
module.
For each course, decide what should be accomplished.
The learning objectives describe the purpose of the course module. They emerge from the
training needs analysis and by assessing how the users will execute the different tasks to
maintain the system.
Objectives are written from the learner's perspective.
A.14.16
Determine desirable training methods to be employed.
A training course should employ both discovery learning and information giving as required by the
system being implemented and by the specific course module objectives.
Discovery learning (exchanging and doing) Involves a high degree of trainee participation. This
approach uses hands-on problem solving or interactive techniques to add reinforcement and
understanding to the learning experience.
Information giving (telling and showing) Involves verbal or visual presentation of material to the
trainee. Examples include lectures, reading materials and demonstrations.
Consider and determine the different delivery approaches.
A.14.17
Divide training course into modules.
For each course, divide the training course into logical, manageable modules, each representing
one training session. Describe the content and flow for each module.
A.14.18
Determine sequence and content of each course module.
Each module's content should be able to be presented in no more than one-and-a-half hours.
There should be no more than two procedural tasks included in a course module. Use key words
to identify major concepts, techniques or information that must be included.
A.14.19
Determine training course plan and schedule.
Derive the following for each different course:

Sequence of course module presentation;
Estimated length of course by module; and
Anticipated time frame for executing training courses.
Page 238

A.14.20
Prepare student workbooks or materials.
Using the training standards, create the student workbooks, which should provide structure for
the course materials as well as materials that can be taken away for later reference. Consider
including:
Parts of the user procedures;
Copies of slides, overheads and charts;
Outlines of videotape materials;
Exercises/case studies;
Examples and tips, tricks and traps;
Relevant readings;
Pages for note taking; and
Guides or schedules for individual and group activities.
A.14.21
Prepare or acquire other training materials.
Dependent upon the different delivery approach, create or acquire the training materials.
A.14.22
Determine training delivery computer equipment needs.
Where the training is to use a subset of the production computer application system, a separate
technology environment may need to be acquired and installed.
Define the necessary computer environment and configuration and where appropriate, acquire
and install all of the various components. This may also require a separate installation (on a
smaller scale) of the production application.
Define the responsibilities for the management and maintenance of the training system.
A.14.23
Prepare application-specific training exercises.
Practice exercises may need to use the computer system. Define and create these exercises and
case studies.
When using the automated system there is additional work to prepare for computerized exercises
that may include:
Setting up user IDs and passwords;
Setting up test libraries and test data; and
Loading and testing the exercises and case studies.
A.14.24
Discuss and obtain formal written approval of training course
materials.
Submit topics/modules to designers and functional experts for review. Make corrections and
additions where required.
Discuss and obtain formal written approval of the materials.
Page 239

A.14.25
Develop and Conduct Instructor Training (Optional)
Purpose
To ensure that the training instructors are knowledgeable and are able to convey the course
content using prescribed methods.
Overview
Instructor materials are prepared and instructor training is completed. The mix and experience of
instructors will determine the depth and type of instructor training required before teaching
commences.
A.14.26
Determine the instructors and define their individual training
needs.
Determine who will fill the training instructor roles. Determine each instructor's individual training
needs. Consider:
Orientation for those who are technically competent and are experienced in using the
educational method chosen; and
Instructor training for those who are technically competent but not experienced in either
teaching or using the educational method chosen.
A.14.27
Prepare instructor guide.
Prepare a detailed instructor guide for each course.

An instructor guide is needed in cases where the training will be given multiple times and given by
others besides the course developers. In these cases, an instructor guide helps to explain course
timing, course objectives, detailed content of each course module and exercises and answers.
A.14.28
Prepare instructor materials.
Prepare the audio-visual or other materials needed to conduct the instructor training sessions.
A.14.29
Schedule and conduct instructor training.
Complete appropriate individual training for each instructor to ensure that they have the
appropriate teaching skills before they begin to provide tuition.
For the course content training, prepare the schedule and arrange for:
A location for the course;
Audio-visual, computer or other equipment availability;
Course material preparation and distribution; and
Establish test training technology environment (e.g., components such as LAN, database
and application). Allow adequate time to "fine tune" the environment.
A.14.30
Evaluate and modify instructor training.
Complete the pilot course.

Evaluate the pilot instructor training course and modify the training approach/materials as
required based on the evaluation.
A.14.31
Discuss and obtain formal written approval of instructor
training materials and course.
Page 240

A.14.32
Conduct Pilot Training Sessions (Optional)
Purpose
To test the training to ensure that all training courses are understandable, relevant and wellreceived by students.
Overview
Pilot training session(s) are scheduled and conducted to enable the course designers and
instructors to evaluate the course content, approach and techniques. Modification of the training
approach and materials may be required as a result of feedback from the pilot training session(s).
A.14.33
Schedule and conduct pilot training session(s).
Define which students will attend the pilot course and which instructors will teach.
Prepare schedule and arrange for:
Establish test training environment (LAN, database and application). Allow adequate time
to "fine tune" the environment.
Observe student reaction to the course and request student evaluation(s) of the course
presentation, materials and exercises.
A.14.34
Evaluate and modify training materials and approach.
Evaluate the training session in relation to objectives, presentation, content, materials, exercises
and test results based on:
Student reaction;
Student evaluation;
Instructor evaluation; and
Observer evaluation.
Modify training approach/materials as required based on the evaluation.
A.14.35
Discuss and obtain formal written approval of final training
materials and approach.
Present the revised materials for review and obtain formal written approval.
A.14.36
Hand over training materials to internal training group.
Provide copies of all training materials developed for the project and any other developmental
data, documents or programs.
Ensure that responsibility for ongoing maintenance and updating of the materials has been
assigned to the appropriate personnel.
Page 241

A.14.37
Conduct Training Sessions
Purpose
To train the management and users on how to use the new system in an efficient manner.
Overview
The training session(s) are scheduled, students notified and the courses are conducted. If a
course is to be offered more than once, initial sessions should be evaluated and appropriate
modifications included in subsequent sessions. If many sessions are to be offered, it may be
appropriate to conduct a pilot session for the specific purpose of evaluation and modification.
Ongoing course maintenance and subsequent training responsibilities are established.
Depending upon the specific project, completion of the training to begin the implementation of the
new DW system may take some considerable time, particularly if there is a wide or dispersed
audience for the training (e.g., if there is a staged or phased implementation). In these
circumstances, this step may need to be supplemented with additional work tasks, additional
planning and resources and increased project management responsibilities.
A.14.38
Prepare for training sessions.
Arrange for the following:

Establish test training computer environment (e.g. LAN, database and application). Allow
adequate time to "fine tune" the environment.
If a pilot training session is to be conducted, identify students representative of those attending
the subsequent training sessions.
A.14.39
Schedule personnel to attend training session(s).
Notify the personnel who will attend each training session of the location, date, time and any
required preparation.
Any required pre-course materials should be distributed to the students.
If a Help Desk support function is to be provided to support the new system, early training of the
Help Desk personnel may be required before the bulk of the user training occurs.
A.14.40
Conduct training session(s).
Complete the schedule of training sessions. This should not be limited to the sessions completed
at the commencement of the new system but should address other issues such as those related
to a staged or phased implementation and include refresher courses as well as addressing staff
transfers, new hires and other ongoing training needs.
A.14.41
Evaluate and modify training approach/materials as required.
Observe student reaction to the courses and request student and instructor evaluation(s) on the
course presentation and materials. If necessary, modify the training courses based upon the
evaluations. Course evaluations should be included in all courses presentations.
Page 242

A.14.42
Define and approve responsibilities for ongoing maintenance
and presentation of training courses and materials.
As changes are made to the system, the training courses and materials need to be maintained to
keep them in step with the system and presented to the users during the life of the system.
Page 243

A.15 Acceptance Testing

Purpose
To confirm with the system users that the delivered DW system executes in accordance with the
agreed requirements and to obtain an acceptance sign-off from the users.
Overview
The intent of the phase is to ensure that:
A formal acceptance sign-off document is prepared and agreed. This document should
contain the agreed upon user acceptance criteria related to functional and data integrity;
and
A complete and detailed test is completed and results verified by both the management
and users. The sign-off document is then used to confirm acceptance.
Although the acceptance test is executed during the Final Preparation Stage, the planning and
criteria for the acceptance should be defined before the design is completed. Only if the
acceptance criteria are created early in the life cycle can both management and the developers
be sure of the target that the system is trying to meet.
It is important to ensure that the acceptance tests are suitable for management, end-users of the
system and computer operations, so that only one set of acceptance tests is needed. In addition,
wherever possible, the acceptance test criteria should form part of the system and integration
tests to ensure early testing of the acceptance process. On some projects, the acceptance testing
may form part of the integration testing.
An Acceptance Test Team must be formally created and be composed of the correct skill mix with
each member having defined tasks and responsibilities. A project manager with relevant skills and
experience must also be selected and be responsible for all of the different acceptance test
components.
The approach and documents used for system testing provide an appropriate outline and
structure that should form the basis of the acceptance test design and execution.
The technology environment to be used for acceptance testing must be discussed and agreed, as
the combination of technology components will impact significantly on the test itself, e.g., if the
acceptance test is not using the final production environment and configuration, what will be the
impact?
The deliverables from this phase should be an operational and fully documented BW system and
a formal written acceptance and sign-off from the system users.
Page 244

Acceptance Testing Task Relationships

S y s te m a b s tra c t
P r o c e s s d e fin itio n
D a ta d e fin it io n
T e c h n o lo g y d e f in it io n
O 1
A g re e A c c e p ta n c e
C r it e r ia a n d T e s t
S tra te g y
S t a f f r e s p o n s ib ilit ie s
A c c e p ta n c e c r itie r ia
A c c e p ta n c e te s t s tra te g y
Test C ases
P ro to ty p e
B u s in e s s S c e n a r io s
O2
D e v e lo p A c c e p ta n c e
Test C ases
A p p r o v e d A c c e p ta n c e C r ite r ia
A c c e p ta n c e T e s t P la n
A c c e p ta n c e T e s t S tra te g y
S y s t e m T e s t e d A p p lic a t o in
O3
C o n d u c t A c c e p ta n c e
Test
A c c e p ta n c e T e s t D a ta
A c c e p ta n c e S ig n - o f f
Page 245

A.15.1Agree Acceptance Criteria and Test Strategy

Purpose
To ensure that acceptance criteria and an acceptance test strategy are developed which are
comprehensive, quantifiable and accurately reflect the agreed scope of the system.
Overview
A statement of quantifiable acceptance criteria will need to be derived by the end of the Business
Blueprint Stage. Based on the acceptance criteria, an acceptance test strategy should then be
developed. This contains testing procedures for verifying the acceptance criteria and/or
identifying critical deficiencies in meeting them.
The acceptance criteria and acceptance test strategy will need to be reviewed by the
development team before they are agreed and signed-off. The end of the Business Blueprint
Stage is the earliest point in the life cycle at which it is viable to begin development of the detailed
acceptance criteria and the acceptance test strategy. On many projects, the sign-off for this task
will not occur until the Business Blueprint Checkpoint Phase. However, where possible every
effort should be made to start this activity as early as practicable.
A.15.2Select the staff and assign responsibilities.

Select a team to work on the development and execution of the acceptance test.
Select a project manager and assign the responsibility of supervising the team and managing all
aspects of the acceptance test definition and execution. A suggested team composition is:
Representatives from the internal IS department who are familiar with the new system's
functionality and the technology architecture and environment;
A representative from each of the user departments affected by the new system;
Where viable, a back-up person for each representative; and
System owner input where required.
Assign responsibilities to each member of the team which should include:
Test planning and scheduling;
Resource allocation and acquisition;
Definition of acceptance criteria;
Test data preparation, creation and storage;
Test execution and result verification; and
Error identification and problem resolution.
In addition, one or two members of the development team should be assigned, as a focal point, to
deal with queries from the user team.
The Acceptance Test Team may require some education or training in the tasks that they are
required to complete. This should form part of the establishment tasks for the acceptance test.
A.15.3Prepare a statement of acceptance criteria.

Derive acceptance criteria from the agreed requirements system models developed in the
Business Blueprint Stage. It should be clear to the users that these criteria must be within the
range of the agreed and signed-off scope of the system being developed.
Page 246

The criteria must be clear, explicit and verifiable. For example "meeting user needs" is too vague.
The criteria should state, say "retrieve journal entries for the month and verify the results against
the current production system". Vague or inexplicit acceptance criteria can lead to the risk of
"defining" a system that the developers can never complete.
System performance criteria should only be specified where they are a critical factor for system
acceptance. Where performance criteria are specified the system conditions, timing, locations,
hardware capacity and the load under which this performance is required must also be carefully
specified.
Specify the technology environment in which the acceptance testing will be completed. This is
particularly important if the tests do not use the final production environment.
A.15.4Review and confirm acceptance criteria.

The responsibility for producing the acceptance criteria and for conducting the acceptance test
must be with the system users and appropriate management. However, this work should not be
completed in isolation from the project development team and each step of the acceptance test
should be reviewed and accepted by the development team before continuing with the testing
process.
Complete a review with the development team to ensure that no vague or unmeasurable criteria
are used and all criteria stated are within the agreed scope of the system.
Items that are initially included in the acceptance criteria but are outside of the agreed system
scope must be documented as a change on the appropriate issue resolution forms.
Vague or unmeasurable items should be returned to the user test team to be fully defined.
Service levels must always be clearly stated and the means of measurement documented (e.g.,
for those to be included in a Service Level Agreement).
A.15.5Define acceptance test strategy.

After the criteria have been defined and agreed, develop and document a strategy for conducting
the acceptance testing.
The strategy should contain an outline of the type of testing required to verify each of the
acceptance criteria. For example:
Criterion - verifying each data table in the DW; and
Test - all dimensions values fit in dimension selectors; rows and columns can be
accessed as appropriate; space has been used in optimal fashion yet data is still
readable; revisiting previous accesses and changing the values for the rows and/or
columns works.
The impact of the means of commencing live processing must also be addressed (e.g., parallel,
staged or phased), as the acceptance testing may need to be repeated several times in different
locations (e.g., a staged implementation by location, office or state).
A.15.6Review and agree acceptance test strategy.

Review the acceptance test strategy with the user test team to check for completeness and
appropriateness.
Any problems and issues identified should be resolved and if necessary routed through the issue
resolution process.
Page 247

When this process is complete, the acceptance test strategy is agreed and signed-off by the
project team manager and the user team representative.
Review, agree and obtain formal written approval from management.
Page 248

A.15.7Develop Acceptance Test Cases

Purpose
To ensure that the test cases are defined, are consistent with the acceptance test criteria and
agreed acceptance test strategy and are adequate to test the system.
Overview
The acceptance test strategy and agreed upon acceptance criteria are reviewed for
completeness and accuracy.
Monitoring the acceptance test criteria and strategy should continue throughout the development
life cycle. Acceptance criteria should have been defined based on the Business Blueprint Stage
deliverables but as requirements change during a project, the acceptance criteria may also
change and should only be modified when agreed by both the developers and the business
users. The acceptance criteria are subject to the same degree of change control as the original
requirements.
Development of acceptance test cases is the responsibility of the system users and the
Acceptance Test Team. It is their responsibility to develop a set of tests that when successfully
executed will provide an appropriate level of confidence in the new system.
From a developer's perspective, the contents of the acceptance test cases should be fully
understood, so that:
A check can be executed to ensure that the acceptance test cases are within the agreed
scope of the project;
Guidance can be provided to the users on the type of tests to be executed and potential
sources of data; and
The contents of the user acceptance test can be included in the System Test Plans as
one potential test cycle.
A.15.8Review the acceptance criteria.

Determine the implications of any changes made to the system design since the acceptance
criteria were originally defined. In particular, consider whether any design changes are significant
enough to require changes in the methods to assess:
Number of successful production cycles;
Verification of system output;
Data conversion quality and accuracy;
Data transformation quality and accuracy;
Adequacy of User Procedures and system operations instructions;
Adequacy of processing under peak load (volume testing);
Adequacy of system processing efficiency;
Adequacy of security; and
Completion of any specified acceptance test cases.
The technology environment warrants special attention, particularly if the project is using a new
configuration. As the different environments have been created during the project (e.g.,
development, test, production), their impact on the acceptance test should have been assessed.
Page 249

A.15.9Review the acceptance test strategy.

Review the acceptance test strategy. To effectively assess the validity and the
comprehensiveness of the proposed acceptance test cases, the overall acceptance test strategy
must first be understood including:
An acceptance test script (i.e., a series of test steps for each acceptance test condition).
Because of the time scales involved in producing this type of test data and associated
expected results, it is more likely to be generated in parallel with system testing, rather
than as a separate deliverable at this point in a system development;
The re-running of one or a number of previously executed system test runs, under user
and computer operations control, as a substitute for specifically designed acceptance
tests; or
The execution of parallel processing for a specified period or number of processing
cycles.
A.15.10
Confirm contents of acceptance test cases.
Review the acceptance test cases developed by the system users. If they have not been
developed at this point, assist them in building appropriate test cases.
Provide the system users with copies of the generic test forms (Test Plan, Test Data Specification,
etc.) and the appropriate phases of the methodology to give them a framework for developing
acceptance test cases.
Suggest the use of Business Scenarios developed jointly with the users in the Prototyping Phase
as useful starting points.
Complete a structured walk-through of the acceptance test script and test cases with the
Acceptance Test Team. Make any adjustments as necessary.
A.15.11
Discuss and confirm acceptance criteria with management.
Discuss and confirm the acceptance criteria and the overall approach to be used in conducting
the acceptance tests with management including the responsibilities for verifying the test results.
Develop an acceptance test work plan with the system users to prioritize and sequence the
acceptance test cases and to organize available resources for conducting the tests.
A.15.12
Obtain formal approval of the acceptance criteria and
approach.
Obtain formal written approval of the acceptance criteria, the approach to be used, the
acceptance test cases and the responsibilities for management and execution of the acceptance
test.
Page 250

A.15.13
Conduct Acceptance Test
Purpose
To confirm that the completed system meets the agreed requirements.
Overview
The acceptance test(s) is completed and results verified. Based upon successful completion of
the test, the operational system is approved as ready for production.
A.15.14
Execute and verify acceptance test, if applicable.
Depending on the degree of involvement in the acceptance test process, complete either of the
following:
Provide support to both the users of the system and the staff operating the system during
the acceptance tests; or
Direct the acceptance test on behalf of the users with users and operations staff (if
possible, to avoid potential conflicts of interest, this should not involve the same
personnel that have been responsible for system testing).
The acceptance test may have to be completed more than once, depending upon the means of
system implementation. If there is a staged or phased implementation or parallel running of the
old and new systems, each acceptance test must be documented and checked. At the completion
of all tests, the individual results may need to be aggregated.
A.15.15
Document compliance with acceptance criteria.
The results of the acceptance tests must be fully documented and checked against the test plan
to confirm that all of the acceptance criteria have been successfully met.
In the event of the acceptance criteria not being met, the standard issue resolution procedures
should be invoked. The reasons for non-acceptance should be documented and the issues
investigated further.
The outcome of this process will either be that the problem is successfully resolved, in which case
approval can take place or that a modification to the acceptance criteria or system is negotiated
between the relevant groups and the tests re-executed.
A.15.16
Obtain formal written acceptance sign-off of the operational
system.
Confirm that the DW system meets the user acceptance criteria and obtain a formal written
approval and acceptance sign-off from all parties concerned, especially the identified system
owner.
Archive the acceptance test results with the project working papers, along with the formal sign-off.
Cross-reference to the Project Charter.
Page 251

A.16 Business Blueprint Checkpoint

Purpose
To confirm the results of the business Blueprint Stage of the DW project with management.
Additionally, in this Phase, the CPDEP Phase 3 task of Develop Preferred Alternative(s) is
completed, and a recommendation and Class 3 Estimate provided for the DRB/GRT.
Overview
Reviews. However, at specific points in the life cycle, additional tasks will have to be completed.
One of these points is the completion of the Business Blueprint Stage and these additional tasks
are described in the Business Blueprint Checkpoint Phase.
Some sections of the Project Charter such as the project work plans may be placed in separate
documents for ease of maintenance and to keep the size of the Project Charter manageable. Any
such stand alone documents are referenced within the main body of the Project Charter to ensure
that the Project Charter remains a single reference point for the management of the project.
Charter occurs and this is the main focus of the checkpoints.
In the Business Blueprint Checkpoint, many of the items fall into the first category. Items such as
project background, change and issue resolution procedures, and project organization will
generally change little on transition from Business Blueprint to Realization.
assessment needs to be reviewed to reflect changed risks in Realization, the baseline for the
project will change from the Business Blueprint Stage to the Realization Stage deliverables and
estimates should be reviewed to reflect this.
New information may include details of the development environment, details of testing
environments and new staff members on the project.
Page 252

Business Blueprint Checkpoint Task Relationships

D a ta tr a n s fo r m a tio n s y s te m d e s ig n
P r e s e n t a t io n s y s t e m d e s ig n
D a ta d e s ig n
P1
o f t h e B u s in e s s
B lu e p r in t S t a g e
C o n f ir m e d B u s in e s s B lu e p r in t S ta g e D e liv e r a b le s
O p e n Is s u e s
P2
P3
Q u a lit y P la n
P4
P5
O b t a in A p p r o v a l o f
B u s in e s s B lu e p r in t
S ta g e D e liv e r a b le s
B u s in e s s B lu e p r in t S t a g e D e liv e r a b le s
Page 253

A.16.1Confirm Completeness of the Business Blueprint Stage

Purpose
To complete an integrity check of the Business Blueprint Stage deliverables.
Overview
The DW system design completed during the Business Blueprint Stage is discussed with
management. The focus is on confirming the completeness of these results and determining their
impact on the project.
A.16.2Confirm the completeness of the data transformation system design

with management.
Discuss and confirm with management the completeness of the data transformation system
design. Focus on ensuring that the system design adequately satisfies the data transformation
requirements defined during the Business Blueprint Stage as described in the following phases:
Ensure that the data transformation system design is consistent with:
Data design;
Presentation system design; and
IT infrastructure design.
Resolve the issues as soon as possible and document any outstanding issues to be addressed
by the Issue Resolution Process.
A.16.3Confirm the completeness of the presentation system design with

management.
Discuss and confirm with management the completeness of the presentation system design.
Focus on ensuring that the system design adequately satisfies the data transformation
requirements defined during the Business Blueprint Stage as described in the following phases:
Ensure that the presentation system design is consistent with:
Data design;
Data transformation system design; and
Page 254

A.16.4Confirm the completeness of the data design with management.

Discuss and confirm with management the completeness of the data design. Focus on ensuring
that the data design adequately satisfies data requirements defined during the Business Blueprint
Stage as described in the following phases:
Ensure that the data design is consistent with:
Presentation system design;
Data transformation system design; and
A.16.5Confirm the completeness of the IT infrastructure design with

management.
Discuss and confirm with management the completeness of the IT infrastructure design. Focus
on ensuring that the system design adequately satisfies the technology requirements defined
during the Business Blueprint Stage as described in the:
Technology Abstract completed in the Data Warehousing Project Abstract phase; and
Technology Definition completed in the Technology Definition and Design phase.
Ensure that the IT infrastructure design adequately supports the:
Data Design;
Data Transformation system design; and
Presentation system design.
Page 255

A.16.6Review Issues
Purpose
Overview
A.16.7Review and resolve any outstanding issues.

Ideally, no issues should remain outstanding at the end of the Business Blueprint Stage. In
practice, not all issues will need to be fully resolved before progressing to the Realization Stage.
The decision on the importance of resolving an issue should be made by the project manager in
conjunction with senior management or the GRT.
next stage.
A.16.8Agree approach to outstanding issues.

Page 256

A.16.9Update Project Plans

Purpose
To update the project plans based on the findings and information obtained during the Business
Blueprint Stage.
Overview
This task updates the project plans to reflect the impact of the results and findings obtained in the
Business Blueprint Stage.
A.16.10
Develop plans for the Realization Stage.
Develop plans for the Realization Stage considering the understanding, findings and issues
relating to the DW project gathered during the Business Blueprint Stage.
A.16.11
Consolidate plans into the project work plan.
Ensure that all plans are included in the project work plan that combines all tasks, dependencies
and milestones for the remaining stages of the project.
A.16.12
Revise estimates in light of previous experience.
Review the original estimates for the Realization Stage which were made based on the best
knowledge at the time. Experience gained during execution of the Business Blueprint Stage may
indicate variances from these estimates that will need to be reflected in the estimates for the next
stages.
Consider experiences on similar projects and on any prior construction work that might already
have been undertaken on this project to date and use to validate the estimates.
A.16.13
Produce detailed work plans for the Realization Stage.
Develop detailed work plans for the Realization Stage. Use the plans currently contained in the
project work plan and the revised estimates, taking into account the available staff and skills.
Identify the tasks needed to complete these stages. The standard tasks may, however, need
some tailoring for the particular project. For each task estimate:
Number of project staff;
Amount of time each person is allocated to a task;
Duration and scheduled completion of each task;
Cost of staff time and expenses; and
Cost of system and administrative support staff time.
The estimates should include the amount of time and effort required from the users.
Reflect any changes to the project work plan necessitated by resource or other constraints.
A.16.14
Validate overall project cost and time estimate.
Develop final cost and timing plans, based on the detailed work plans. For each subsequent
phase, prepare a high-level estimate including:
Staffing resources by skill level;
Amount of time estimated to complete a phase;
Scheduling;
Cost of staff time; and
Page 257

Cost of additional hardware and software.
Some of the data needed to prepare an estimate may not be available. For these situations,
determine and document the assumptions used to prepare the estimates.
Formal written approval should be sought for any actions to be taken and plans revised
accordingly.
Page 258

A.16.15
Update Project Charter
Purpose
Overview
To this point, the Business Blueprint Checkpoint Phase has largely been concerned with work
planning. Many issues are addressed in the Project Charter that go hand-in-hand with the work
plans. These are reviewed and appropriate amendments made to reflect the end of this stage and
the start of the next.
Those sections of the Project Charter that need to be updated for Construction are reviewed and
revisited.
A.16.16
Review and revise Project Risk Assessment.
Review the risk assessment as a result of the Business Blueprint Stage experience and the
updated project plans for the Realization Stage. Consider:
before?
assumptions?
project?
Have advances in the marketplace (e.g., new versions of software) significantly affected
the project?
A.16.17
Review project risk dimensions.
Identify where the risk ratings described in the risk assessment are higher than expected or are
greater than originally anticipated. Obtain agreement with management on the appropriate
actions to take.
Page 259

A.16.18
Revise risk management approach.
Review the Project Risk Assessment completed earlier to identify any changes from the initial
assessment. For identified threats, document:
A.16.19
Revise the Project Charter.
they primarily affect the Realization Stage. Ensure that all these areas have been properly
addressed before progressing to the Realization Stage.
A.16.20
Seek independent approval for the revised Project Charter.
Approval for the revised Project Charter should be sought and the plan should be reviewed for
completeness and correctness including:
Any issues should be discussed between project management and the independent
assessor;
Corrective actions to be taken should be agreed by all parties and documented. Such
actions should have clear time scales and responsibilities assigned; and
Further reviews should be scheduled to ensure corrective action is undertaken.
Page 260

A.16.21
Obtain Approval of Business Blueprint Stage Deliverables
Purpose
To seek final review and formal written approval of the Business Blueprint Stage deliverables. . At
this point, the deliverables and a Class 3 estimate are provided for approval to the GRT/DRB as
per CPDEP.
Overview
Throughout the Business Blueprint Stage, formal written approval should be sought for
deliverables on an ongoing basis. At the close of the stage, a final review of deliverables is
undertaken and formal written approval obtained for all of the Business Blueprint Stage
deliverables.
A.16.22
Submit and discuss Business Blueprint Stage deliverables.
Discuss the Business Blueprint Stage deliverables with management and resolve any questions
and issues.
and project contract.
issues.
A.16.23
Discuss process for approving changes to confirmed design.
It is extremely important that the design of the DW system and its surrounding components to be
approved and "frozen". However, throughout the Realization and Final Preparation Stages,
changes may need to be made to the design.
Ensure that project management and senior management agree on a process to manage these
proposed design changes. This could include formal change requests with justification and cost
estimates.
A.16.24
Obtain formal written approval of the Business Blueprint Stage
deliverables.
Obtain formal written approval of the Business Blueprint Stage deliverables as defined in the
Project Charter and the project contract. Complete the necessary approval procedures to
complete CPDEP Phase 3 Develop Preferred Alternative(s).
Page 261

Realization Stage
The purpose of this stage is to construct system components based on the Business Blueprint.
The objectives are final construction and testing of the system.
Key Deliverables:
1) Program code, constructed BW components, and documentation
a) Data extract programs Extractors, Custom ABAP, or ETL Generated Components
b) Data transformation and DB components InfoSources, InfoCubes, Transfer Rules,
Update Rules
c) Presentation components Queries/Workbooks, Web components, common query
objects
2) Unit and Integrated Test strategy
3) Unit to System Test migration plan
4) Converted data (if applicable)
5) Security testing
6) Stress testing with high data volumes
7) Sizing
Custom Extract System Construction, BW Administrators Workbench Construction, and
BW Explorer Construction
These three phases develop detailed specifications from the design documentation and then
construct, test and document the individual components.
Testing in these phases consists of:
Unit testing;
String testing; and
Preparing the Unit to System Test Migration Plan.
Types of Testing
The purpose of software testing is to identify and correct errors before implementation. In the
methodology, a comprehensive set of testing tasks are described that span the Construction and
Final Preparation Stages of the development life cycle. The main testing activities are:
Unit Testing;
String Testing;
System Testing;
Integration Testing;
Stress Testing;
Back-up/Recovery Testing; and
User Acceptance Testing.
Certain of the types of testing listed are described as discrete phases of work within the
methodology. Others are combined with tasks with which they are tightly coupled (e.g.,
component development and unit testing) and still others are defined as tasks or even steps
within a phase (e.g., stress testing is considered to be a form of system testing).
All of the types of testing are important but they are not all at the same level of decomposition
from the perspective of project planning. e.g., stress testing may be referenced implicitly within
system testing but if it is a critical part of a project, it may be elevated to a separate set of tasks
on a project plan. The decision on the relative importance of the different types of testing will
Page 262

reside with the project team, however, the following paragraphs provide guidance in
understanding the intent of each of the types.
Unit Testing
Unit Testing ensures that a program works as it was designed to work by testing the individual
program or component's compliance with design specifications. Destructive testing techniques
are used to try to "break" the program or component. Some of the unit test objectives are to:
Verify that the program and component modules perform functions as specified in the
design;
Exercise program and component branch decisions (including exceptions and errors);
and
Verify data edit, validation and cross-field validation logic.
Working from the design specifications, a test plan is developed for each program and
component. At their lowest level, test plans consist of a series of testing steps which include input
data, operation instructions and expected results.
After the test plan has been reviewed in a walk-through and approved by the team leader, the test
is executed by following the test plan in a step-by-step fashion. Any variance between the
expected results listed on the Unit Test Plan and the actual results from the execution of the test
should be resolved by the developer and re-tested.
If a separate unit test team is employed, variances will need to be recorded on a Test Problem
Report (TPR). At the conclusion of the test run, the TPRs associated with each program and
component are returned to the developer for resolution. When all TPRs have been resolved and
successfully re-tested, the program or component is declared ready for string testing.
String Testing
String testing builds on the work completed in the unit test by exercising logically related
programs and components to reduce the number of errors uncovered in later and more extensive
testing tasks. Specific focus areas for string testing include:
Program to program interfaces and communications; and
Control structures (e.g., menus and security)
Again, a detailed test plan is developed which specifies testing steps that include input data,
program or component operation and expected results. String test plans are designed to add a
program or component at a time to a previously tested baseline to better isolate the errors and
reduce the amount of time required to fix them. Like unit testing, variances between expected and
actual results may be documented on a TPR and all TPRs must be resolved before a program or
component can be promoted to the next testing task/phase.
System Testing
Unlike unit and string testing, which all take a technical view at the program level, system testing
looks at the entire application from a business perspective to ensure that the application functions
as designed. It focuses on the sub-system to sub-system interfaces within the application not
tested in previous testing tasks.
The test planning process is modified in the system test to reflect the business emphasis by
adding the concept of test cycles. Test cycles act as placeholders for the higher-level business
processes automated by the application. Test objectives and conditions are then defined for each
cycle. Finally, test steps (input data, program operation instructions and expected results) are
defined for each condition. The TPR process is again used to resolve discrepancies between
expected and actual results.
Page 263

Integration Testing
Integration testing focuses on interfaces between applications to ensure the delivery of complete
business functionality and system performance across application boundaries and across
technology platforms. Few systems operate in isolation. Therefore, application testing is not
complete until the external interfaces are tested.
Integration testing ensures that interface standards are met and that no errors are encountered
as information is passed from one system to another. Most interface errors are caused by:
Invalid timing or sequence assumptions related to external signals (incorrect sequence of
jobs or data);
Poor design which does not allow proper system balancing to be completed or confirmed;
Misunderstanding of external input and output formats; and/or
Insufficient tolerance to bad input data.
Rigorous integration testing reveals problems before an application goes into production and
provides the opportunity to address potentially damaging system outages. Actual practitioner
findings have included:
Redundant fields that are stored on separate databases are out-of-sync;
System-to-system control totals and balances do not reconcile;
Table validations which were not established correctly, causing data integrity issues
across applications and across validation tables; and
Expected data content and format of transaction data was not consistent across
applications.
In addition, integration testing checks the effect on the performance and capacity of co-existent
systems to ensure that shared resources are not overburdened.
Stress Testing
Stress testing loads increasingly higher volumes of activity on the system to facilitate throughput
tuning and to find the software's breaking point under specific resource constraints. In particular,
the expected maximum workloads must be tested in a production environment to ensure that the
required performance criteria can be met.
Overall acceptability is based on the following criteria:
Overall throughput;
Response times;
Run time;
Resource utilization; and
Correctness of processing at load.
Back-up/Recovery Testing
Back-up and recovery testing should be completed in the context of the larger contingency
planning effort. If not specifically addressed as part of a contingency planning assignment, it is
generally incorporated within the system and integration testing effort to ensure that predictable
responses to situations which call for back-up and/or recovery of the system are defined and
tested. This is particularly important in the client/server environment because of the complexity of
the back-up and recovery procedures and the difficulties of managing dispersed hardware.
Acceptance Testing
User acceptance testing is executed just before the system goes live and it is the final testing
component in the methodology.
Page 264

The acceptance test is considered to be the user's test and while the project team will often work
closely with user personnel to assist in the development and execution of the acceptance test
plan, it is ultimately the users' responsibility to complete the task and to gain the confidence that
the system performs as expected.
Initial System Tuning
As part of the system and integration testing, initial tuning of the system is completed to ensure
that the system operates as effectively and efficiently as possible. This initial tuning then forms
part of the normal ongoing management and operation of the system after live production
commences.
The Cross-Life Cycle Phases, all started during the Project Preparation Stage and continue
beyond the Realization Stage, include:
Change Integration;
Prototyping;
User Documentation;
Training;
Acceptance Testing; and
Depending upon the specific project requirements, each of these Phases may have specific tasks
and steps to be completed during the Realization Stage.
Project Management
Although project management activities are ongoing throughout the project life cycle, in the
Realization Checkpoint Phase, a formal confirmation of progress against the Project Charter is
completed and plans are developed for the Final Preparation Stage.
Page 265

A.17 Custom Extract System Construction

Purpose
The objectives of the Custom Extract System Construction Phase are to:
Finalize the setting of any functionality parameters of the system extraction software tools
used, including Business Extractors;
Design, code and test programs for any custom system components in accordance with
the Business Blueprint Stage specifications;
Produce a complete set of executable programs and components that perform the
procedures, elementary processes and common routines necessary to support the
application design; and
Ensure that:
all functions work according to program/component specifications,
access to all program/component logic paths and program module interfaces are
working,
program/component edit/validation logic successfully protects the integrity of each
data element, and
all programs and components are fully unit tested, before handing over to system
testing.
Overview
The construction of a extract system involves one or more of the following program development
efforts:
Custom developed programs for data extract and transform functions;
Tool-generated code or components for data extract functions.
In this phase, the development team will:
Design programs, in appropriate development environments and languages, that are
structured, tightly cohesive and minimally coupled;
Produce a complete set of executable programs that perform all tasks necessary to
support the application design;
Develop Unit Test Plans and unit test data under the guidance of a planned test strategy;
Verify that each program executes the functions as outlined in the associated program
specifications including those pertaining to exception and/or error processing; and
Confirm the completeness and the quality of the programs and the program
documentation before the transition to system testing.
This phase contains the tasks necessary to define program specifications in a format and/or
syntax compatible with the requirements of a chosen development tool.
Each program to be developed in a procedural language is documented as a Program Structure
Chart. The Program Structure Chart is an hierarchical representation of the modules in a
program, its basic control logic, all module interfaces and inter-module relationships and the data
content of parameters passed between modules.
Program modules follow a standard naming convention, which may vary with the development
language.
Complex actions may be described further using Detail Logic Charts that describe complex
logical processes (e.g., algorithms) performed by a program module that cannot be succinctly
described on a Program Structure Chart. Action Diagram notation may be used to create the
Page 266

Detail Logic Charts. References to Detail Logic Charts are added to the final program
specifications during this phase. The Detail Logic Charts are generally used to develop functions
or Remote Procedure Calls (RPCs), which are usually custom-coded rather than being toolgenerated. The resulting set of program specifications are then subjected to a structured walkthrough and approval process.
After describing the implementation-independent logic of each program, the development team
produces the executable code for the automated processing portion of the application system.
Other programs may be produced to provide support for system implementation such as data set
conversion, data set initialization and any programs required to interface with other systems.
Command language instructions needed to execute the programs and database definitions will
also be coded during this phase together with any utility parameters (e.g., sorts).
Finally, unit testing represents the first testing activity in the Testing Hierarchy as shown in the
exhibit. Each program module is tested on a stand alone basis by the program developer. The
unit test should attempt to address all program logic paths and range of variables and emphasize
the most frequently used program paths. All utilities (e.g., sorts) used as part of a program also
form part of the unit tests.
Page 267

Custom Extract System Construction Task Relationships

Q 2
P re p a re P ro g ra m
G e n e r a tio n
S p e c if ic a tio n s
Q1
P re p a re P ro g ra m
S tru c tu re C h a rts
F in a liz e d P r o g r a m s p e c if ic a tio n s
Q9
C o n s tru c t D a ta
C o n v e r s io n S y s te m
D e t a il lo g ic c h a r t s
Q3
C o m p le t e S t r u c t u r e d
W a lk - t h r o u g h o f
P r o g r a m S p e c if ic a t io n s
B u s in e s s S c e n a r io s
P r o g r a m s p e c ific a t io n s
P r o g r a m d o c u m e n t a tio n
A p p ro v e d p ro g ra m
s p e c if ic a t io n s
Q 10
E x e c u te D a ta
C o n v e r s io n
Q4
D e v e lo p E x e c u ta b le
P ro g ra m C o d e
P ro g ra m c o d e
P r o g r a m d o c u m e n ta t io n
Q5
C o m p le t e S t r u c t u r e d
P ro g ra m C o d e
A p p ro v e d p ro g ra m c o d e
Q6
D e v e lo p /E x e c u t e U n it
Test
U n it t e s t o b je c t iv e s
U n it t e s t c o n d itio n s
U n it t e s t p la n s
U n it t e s t d a ta
U n it t e s t e n v ir o n e m n t
T e s t p r o b le m r e p o r t s
T e s t p r o b le m r e p o r t lo g
Q7
E x e c u t e S tr in g T e s t in g
S
S
S
T
T
Q8
D e v e lo p U n it to
S y s t e m T e s t M ig r a tio n
P la n
R e v is e d p r o g r a m d o c u m e n t a t io n
U n it t o s y s te m te s t m ig r a tio n p la n
t r in g
t r in g
t r in g
est p
est p
Page 268
te s t s tra te g y
t e s t p la n
te s t d a ta
r o b le m r e p o r t s
r o b le m r e p o r t lo g
C o n s tru c te d D a ta
C o n v e r s io n S y s te m
C o n v e rte d D a ta

A.17.1Prepare Program Structure Charts

Purpose
To decompose each program into independent program modules.
Overview
Each program module should execute only one process since it should be constructed to have a
single entry and a single exit. The Program Structure Chart provides a clear framework for the
development of program code and when developed for a program illustrates the sequence of the
modules and their interrelationships.
The quality of a structured program is based upon the degree of independence of each program
module:
Coupling is the measure of the strength of the inter-module connection - it is desirable to
have modules that are as loosely coupled as possible; and
Cohesion is the measure of the relationships among code structures contained in the
same module - a high degree of module binding or cohesion can minimize the
relationships between modules.
A.17.2Identify mainline program modules.

Identify all of the mainline program modules. The framework of each program is constructed by
decomposing each module contained within the Program Logic Specification prepared in the
Business Blueprint Stage (e.g., edit/validate, update, display/report) into the required "mainline"
processing modules. These mainline program modules comprise the highest control level of the
program and address initialization logic, record processing logic and termination logic.
A.17.3Identify common logic modules and their interface requirements.

Identify those program modules representing sub-programs that may be accessed by several
different program modules. Define data to be passed to and from the shared program modules
(e.g., passed status codes). Include definitions of parameters for called subroutines.
A.17.4Identify data access strategy.

Identify the techniques to be employed for data access. The data can be accessed using called
input/output routines that are written for the entire system or by using a subroutine within the
program that executes the access. Define the data elements needed to access the record (e.g.,
keys).
A called input/output routine may be more difficult to write initially but it can add flexibility to the
system for later changes to the access technique and standardization of the data access
mechanism.
A.17.5Prepare Program Structure Charts of program modules.

Program Structure Charts are created by further decomposition of the Interaction Models created
in the Business Blueprint Stage.
This composite of program modules defines the program functions and the overall program
structure. Program functions are defined using a set of standard verbs. The Program Structure
Chart should be defined to the level of detail such that decision logic associated with all program
paths are clearly presented. This will require detail to the degree(s) described as follows:
Page 269

Major function (e.g., UPDATE, SORT, PROCESS, OPEN, CLOSE). All process related
specifications should depict the possible program pathing decisions, (i.e., the start of
each program path);
Called program interfaces (i.e., execution of subroutines). The inter-module interface
indicates the data to be passed and/or the parameters;
Subordinate functions (e.g., data set input and output, data manipulation at the segment
or record level, data initialization and error processing); and
Execution sequence of the modules (e.g., the definition of all control levels). The control
levels should depict all program linkages, specify the lower level modules to be invoked
and specify under which conditions this takes place.
This final factoring of the Program Structure Chart takes the input and output modules to their
external entry and exit points, respectively and decomposes the central transform into modules of
manageable size while maintaining high cohesion and low coupling within the modules. In
general, in a Program Structure Chart:
Input modules should break down into input and transform modules;
Output modules should break down into output and transform modules; and
Transform modules should break down only into smaller transform modules.
A.17.6Decompose program modules.

Each of the program modules, including the lower level modules, should be depicted using only
the three constructs of structured programming: sequence, selection and iteration.
Address the definition as appropriate:
Database manipulation functions (e.g., OPEN, CLOSE, GET and PUT);
Data manipulation processes (e.g., FORMAT, EDIT, VALIDATE and COMPUTE);
Table/string manipulation processes; and
Conditional logic processes.
A.17.7Select program modules within Program Structure Charts that

require Detail Logic Charts for further definition.
Take care not to decompose too far in the Structure Chart format. Select program modules that
would be better decomposed as Detail Logic Charts (DLC). The selection of appropriate program
modules to decompose as DLCs will vary with the standards established for a particular
language. For instance, if programming in C, the Program Structure Charts should be kept at a
high level, sufficient to identify the functions to be programmed. The majority of the program
specification will be contained in Detail Logic Charts.
For COBOL programming, more of the program specification can be specified in the Structure
Charts and the Detail Logic Charts may be reserved for modules containing complex logic. These
rules are subject to change depending on the standards established earlier in the phase.
As a general rule, each DLC should fit on one page providing this does not contradict the rules of
keeping modules highly cohesive. Use the action diagram decomposition notation (i.e.,
subroutine) to support any DLCs that will exceed one page.
A.17.8Refine Program Structure Chart.

Review the Program Structure Chart using the concepts of coupling and cohesion to improve the
structure of the program. The quality of a structured program is based upon the degree of
independence of each program module:
Coupling is the measure of the strength of the inter-module connection; and
Page 270

Cohesion is the measure of the relationships among code structures contained in the
same module.
Where a module is limited to dealing with one data entity, the degree of cohesion is enhanced.
The intent is to have a module with high cohesion and groups of modules to have loose coupling.
A.17.9Prepare Detail Logic Charts, as required, for selected program

modules.
Prepare a Detail Logic Chart for each selected program module.
These Detail Logic Charts provide a diagram of the detailed processing logic required within a
program module. They normally include a series comprised of the following program logic
structures:
Operation - depicts a single operation or statement;
Decision - depicts a choice to be made and the alternative logic paths that may be taken;
Decomposition - depicts a group of operations and decisions to be executed in sequence
and defined in a separate Detail Logic Chart;
Process while - depicts an iterative process preceded by a decision; and
Process until - depicts an iterative process followed by a decision.
Page 271

A.17.10
Prepare Program Generation Specifications
Purpose
To prepare program specifications in the appropriate format for all programs that are to use a
program generator.
Overview
The objectives of this task are to:
Employ the program generator in an efficient and effective manner;
Select the functions of a program that will be produced via custom coding and the
functions that will be generated;
Modify the program specifications for submission to the program generator;
Generate the program code;
Prepare the source code from the generator and the custom-produced code for unit
testing;
Provide a set of program documentation in accordance with defined standards; and
Use the available facilities of the generator to capture, store and document program
specification contents.
The steps necessary to define modified program specifications in a format and/or syntax
compatible with the requirements of a chosen code generator are defined here.
Program generators are intended to reduce the effort necessary to produce structured programs
and do so by standardizing and automating the production of processing modules such as
mainline and paragraph control, transaction processing, report formatting and edits and
validations.
The work steps are based upon the use of a modified program specification that consists of three
categories of components - input specifications, processing specifications and output
specifications. Each component will vary depending on the requirements of the specific generator
as some generators eliminate the need to encode logic using a precise syntax, whereas others
require it. Typically, each component will consist of:
Input record definitions
Output record definitions
Processing specifications:
Structure Charts,
Program Logic Specifications,
Table Definitions,
Edit/Validation Specifications,
Process Descriptions,
System Messages, and
Detail Logic Charts.
References to Detail Logic Charts are added to the design as part of finalizing the program
specifications, as they will be used to develop customized program code rather than being
generated.
The input, output and processing specifications may have been captured during the Analysis
and/or Business Blueprint Stages if an automated tool has been used on the project and:
Program generation function is an integral part of the automated tool used; or
Page 272

An automated interface exists between the automated tool used and a program
generator.
Regardless of the project situation (i.e., whether an automated tool is used), the steps for
program generation are still applicable, although some of these steps may be completed at
different times in the project depending upon the type of automated tools being used.
A.17.11
Specify program generator produced documentation to be
employed.
Indicate which items on the program documentation checklist are to be machine generated and
which are to be manually produced. Ensure that templates provided with the program generator
to optimize the use of the product are reviewed and used wherever possible.
A.17.12
Select program modules to be generated.
Not all modules may be appropriate for generation. If a program is not going to be generated, it
should be designed and documented in accordance with the one of the alternative paths through
this phase.
Before ruling out a program generator for specific programs, consideration should be given to
using the program generator to produce skeleton programs to which custom code is added. The
benefit of skeleton code produced in this fashion is that the final program will conform to the
structure of programs wholly produced by the program generator. This should ease future
maintenance of the system.
All modules to be generated should have a final processing specification defined that is
appropriate to the generator.
A.17.13
Finalize input and output specifications.
Finalize the content, format and usage of input and output screens/windows/reports.
Capture the screen/window and report definitions within the program generator. Ensure that the
input/output data items are consistent with the Data Dictionary descriptions, edit/validation
specifications and database contents.
Finalize record definitions, including external data tables. Review the data attribute definitions
contained in the Data Dictionary for completeness and accuracy. Analyze primary and secondary
access keys and examine access paths for logical segments and records to minimize path length
where practical.
Capture record definitions within the program generator. Convert data attribute definitions to the
data format rules associated with the program generator. Enter record definitions to the program
generator.
A.17.14
Finalize program specifications.
Finalize Edit/Validation Specifications and define System Messages for all programs to be
generated. Identify potential areas for reuse of common processing.
Finalize processing controls. Include, input controls (e.g., log-on verification, access restrictions,
check digits, batch control totals), processing controls (e.g., data file control records, run-to-run
control totals), as well as output controls (e.g., end-of-report control totals).
Page 273

Specify processing control logic to the program generator. Determine which controls can be
applied by the generator and which will need to be custom-coded.
Identify and define tables to be used in each program. Establish table numbers/names and
confirm adherence to standards. Fully define and describe all data tables according to the Table
Definition format.
Identify and define complex logic to be integrated into the generated code. Develop this logic
according to the rules for the appropriate program development path.
Page 274

A.17.15
Complete Structured Walk-through of Program and/or
Component Specifications
Purpose
To ensure the completeness and quality of the program or component specifications to facilitate
the coding, testing and maintenance activities.
Overview
The structured walk-through process provides a formal procedure for quality assurance of the
program specifications to enable the timely discovery of design errors before beginning the
program development tasks.
For each program, a program specification is assembled, reviewed, cross-referenced against the
Program Control Checklist, subjected to a structured walk-through and finally approved.
A.17.16
Ensure that the program specifications deliverable is
complete.
Review and cross-reference the program specifications against the Program Control Checklist.
Other necessary documentation not produced by the development tool may need to be
developed or modified from documentation developed during the Business Blueprint Stage.
A.17.17
Conduct structured walk-through of the program
specifications.
Conduct a structured walk-through of the program specifications. This process enables the
project team to identify and resolve any discrepancies, omissions and logic errors. Adherence to
standards and conventions as well as structured design techniques should be monitored.
Changes to program specifications should be documented and approved using the System
Change Request form.
Document and resolve issue resolutions, as required. The issue resolution process provides a
formal reporting mechanism for documenting and resolving major decisions/problems.
A.17.18
Obtain team leader or equivalent approval of the program
specifications.
Page 275

A.17.19
Develop Executable Program Code
Purpose
To develop and compile functionally correct program code that is easy to maintain by ensuring
that it conforms to the approved program coding standards, naming conventions and program
specifications.
Overview
All programs are coded from the final program specifications using established language-specific
program coding standards and conventions. Coding proceeds in a "bottom-up" fashion, where
reusable modules and programs are the first to be created so they may be prepared for general
access in a protected library.
Code all shared, common, support and/or utility programs and modules. These are modules and
programs that will be used in or called by more than one program and should be coded once for
the entire project and then shared through a protected library catalogue. In a client/server
environment, they would include the stored procedures and the API library(ies) accessed by
remote procedure calls (RPCs).
A.17.20
Code input/output program modules.
Code all input/output program modules. Because all program specifications to this point have
addressed logical data entities, the program modules to execute input/output should address
physical data records as defined in the Data Design Phase. There should also be reusable code
in these modules as well because the structure of the stored data:
Should be stable;
Will be reflected in the structure of the program; and
Will be needed wherever the same data is accessed.
A.17.21
Code programs and/or modules not generated.
Code programs in accordance with standard structured programming techniques. Structured

programming emphasizes program modules that are loosely coupled through the passing of
some minimum amount of data always transferred as a standard data packet.
Each program module should ideally consist of one function that has one entry point and one exit
point. The program module should always execute the same function and not execute different
functions dependent on the setting of an internal flag.
The sequence in which this step and the next step for generated code are completed may vary
depending upon whether any required custom code is a prerequisite to code generation for
included or called modules or programs.
A.17.22
Generate program code using the development tool.
Execute the program generation software. The result will either be program code (from a
parametric code generator, e.g., TELON) or a ready-to-run program (using 4GLs such as
PowerBuilder).
A.17.23
Resolve all syntax and diagnostic program compile errors.
Resolve all syntax and diagnostic program errors. This is an iterative step. If syntax errors are
found, they need to be corrected and the program code generated again until no errors are found.
Page 276

All program code should comply with the program specifications. Enforce adherence to approved
program coding standards and naming conventions, as well as structured programming
techniques and any exceptions should be justified in the documentation for the module or
program.
Changes to program specifications must be documented and approved through the System
Change Request process.
A.17.24
Code command language and utility parameters.
Code any command language and utility parameters including:

Command language (e.g., JCL);
Back-up, copy and restore; or
Sorts.
Ensure that the coding adheres to the previously defined program coding standards and
conventions.
A.17.25
Verify command language and utility execution.
Compile the program code and command language code and identify and correct any syntax and
diagnostic errors. The program code is then recompiled until no syntax or diagnostic errors are
found.
A.17.26
Complete all program documentation.
Ensure that all of the program documentation is complete using the Program Control Checklist.
Page 277

A.17.27
Complete Structured Walk-through of Program Code
Purpose
To minimize the maintenance effort and to ensure program quality through the timely discovery of
program coding errors and/or omissions, deviations from prescribed specifications and the proper
adherence to established program coding standards and naming conventions.
Overview
Each program is submitted to a structured walk-through and approval process to ensure that only
standardized code is produced.
Program specification changes are documented and approved and the program code is
submitted to the project team leader for formal written approval.
All program code should comply with the program specifications. Adherence to approved program
coding standards and conventions, as well as structured programming techniques, should be
stressed for custom-coded modules. Changes to program specifications must be documented
and approved through the System Change Request process.
Note: The number of programs that are actually walked-through will depend on the size of the
system, the complexity of the processing and the skill and experience of the programmer(s).
A.17.28
Ensure that program documentation is complete.
Review and cross-reference the documentation against the Program Control Checklist. Add any
missing items.
A.17.29
Document any required changes to the program
specifications.
Document any changes to program specifications that may be required to achieve the desired
system processing. Any modification of program specifications can potentially impact other
programs that access the same data. It is essential that all program specification change requests
be adequately researched to determine any possible side effects. All program specification
change requests must be fully documented and approved through the System Change Request
process.
A.17.30
Conduct a structured walk-through of the clean-compiled
program code.
Conduct a structured walk-through of the clean-compiled program code. Correct any errors and
omissions identified and recompile the program code. All programs should comply with the set of
program specifications produced during program design.
A.17.31
Submit program code and System Change Requests to the
project team leader and obtain formal written approval.
Page 278

A.17.32
Develop/Execute Unit Test
Purpose
To complete unit testing of the program code.
Overview
A Unit Test Plan is developed for each program. The plans are reviewed and approved by the
team leader before execution. All conditions, steps to be executed to test each condition, required
unit test data and expected results of each test step are defined. The expected results are
derived from the program specifications to ensure that the program performs as specified.
The structured walk-through process is used to ensure that a complete set of conditions and
steps has been defined. All test steps and/or data files required to complete the unit tests are
created in this task.
The test steps and data files are made up of multiple transactions with variations of data, both
valid and invalid. Examples of invalid data are included to test edit/validation and error
management routines. Hard copies of unit test transactions are attached to each Unit Test Plan. A
test data generator can be used to prepare the unit test data. The recommended approach is to
develop ONE common set of test data to be used in all of the various test steps. Changes to the
command language instructions may be necessary to execute specific modules at the appropriate
times. To some extent, this will depend on whether the changes made are modifications to
existing programs or the addition/deletion of programs. If necessary, command language
instructions are prepared for each program. Special utility steps to facilitate review and
verification of unit test results may be included as needed.
All unit tests are conducted until each test has been successfully completed. Actual results are
reconciled with the expected results and all program logic errors are corrected. Final test results
are attached to the Unit Test Plan for each test condition/step. Successfully conducted Unit Test
Plans are reviewed by the team leader. If a top-down unit test strategy has been adopted, lowerlevel modules will be added to the current set of test modules and tested with the appropriate test
data or scripts. In a bottom-up unit test strategy, the successfully tested program will be moved
into the system test library.
A.17.33
Develop unit test plans.
Develop unit test plans:

Define the unit that is to be tested. Specify the program boundaries. A unit may consist of
a menu program and a related program or it may consist of a single program. The unit to
be tested can be a CALLed program module or any processing module that has testable
stimulus and response characteristics. Definition of the unit boundaries helps to ensure
that all program modules are tested.
Note: In accordance with the design techniques, a unit should be identified as corresponding to
one program. Basically, a unit will relate to a single window, stored procedure or a logical subset
of objects (e.g.,a table window) on a single window;
Define unit test objective(s). For each Unit Test Plan, define specific test objective(s) to
determine the test condition(s), test step(s) and test data scripts or data file(s) to be
prepared including expected results;
Establish test conditions to address the verification of:
output conditions (e.g., displays, reports, updates, error messages),
program logic paths including loop control, exception and/or error processing,
edit/validation logic within the program including table look-ups,
Page 279

error management routines,
processing algorithms,
module to module interfaces within the program,
use of "called" modules,
production of specified output files,
reading of specified input files,
control and security conditions,
command language instructions for the program, and
utilities;
For each test condition, define sets of data required to execute the test conditions.
Identify:
data record(s) and/or screen(s)/window(s) to be constructed to test the condition,
key data element value(s), and
unique sets of data element values.
Where appropriate, multiple Test Data Specifications should be defined for each test condition. All
processes need to be tested by use of "cascades" of Test Data Specifications containing at least
three transactions to determine the integrity of program logic, e.g., testing for invalid data entry
should include Test Data Specifications for different invalid values and for various combinations of
invalid data;
Define individual unit test steps for each test condition. Expand the test conditions to form
the test steps. The test steps represent the different program paths that may be executed
to accomplish the same overall test condition.
Begin at the module level and define unit test steps for simple test conditions. Progress to more
complex conditions. Add test steps for successive modules until all components of each program
path (series of modules) have been tested. Unit test steps are required to create the appropriate
settings for the test condition to be effectively tested. They will occasionally require data to be
available that is referenced rather than directly used by the test condition.
Review the Test Data Specifications to ensure that all of the data required by the unit test steps
for a specific unit test condition is available;
Define the expected results of each test step. Include:
output to be generated (screen, data file and report),
unique program paths to be executed,
status of interim data element values,
status of applicable data file values upon completion, and
status of control totals upon completion; and
Conduct a structured walk-through of the Unit Test Plans by comparing them with the
program specifications (not the source code). A correct Unit Test Plan is one that
addresses all processing contained within the program specification.
Wherever possible, include a member of the System Test Team in the Unit Test Plan walkthrough. This involves the System Test Team early in the development process and allows them
to confirm that the program is being adequately tested as a unit before the start of System
Testing. Update Unit Test Plans as needed with changes resulting from the structured walkthrough.
Obtain project team leader formal written approval of Unit Test Plans.
A.17.34
Generate unit test data.
Generate unit test data:
Page 280

Generate the unit test steps and data files. Test steps and data files may be created
directly from the Unit Test Plan if the test conditions and steps are defined clearly.
Physical data files containing the records required to meet the unit test steps are created.
In general, valid data should be tested first, followed by exception conditions. For on-line
processing, unit test data is a predefined series of screens/windows. Test data transactions
should be sufficient in detail and number to satisfy all test objectives, conditions and steps;
Generate module interface test data, where applicable.
Module interface test data is required to test a "called" module before integrating it with the
"calling" module in a bottom-up testing strategy. When testing called modules this way, it may be
necessary to generate separate interface data files. When a top-down strategy is employed,
interface data files will be created by the higher-level module;
Ensure that a hard copy of the unit test data is produced and attached to each applicable
Unit Test Plan.
The documentation required consists of screen/window printouts or data file dumps of the actual
data used;
Add test data to a common pool or build a test database to improve the testing process
and ease the burden of producing test data. This step should be executed or supervised
by the Database Administrator to ensure that database integrity is maintained; and
During the course of testing, additional test data and conditions may be required. To
facilitate this update process, the means to control the maintenance and distribution of
the common test data set must be established and agreed.
A.17.35
Prepare unit test job steps.
Prepare unit test job steps:

Change or code required command language instructions. Regardless of whether a topdown or bottom-up unit testing strategy has been adopted, it will be necessary to prepare
the computer environment to accept the program being tested and, where appropriate, to
return properly from "stubbed" modules. A stubbed module is used to substitute for a
lower-level module that is not ready to be tested. Typically, it will include an entry point
and an exit point and may set-up a return value(s).
Command language instructions must also be coded for loading data files and interface data files
in the proper sequence;
Identify and code any utility step instructions to assist in confirming that the tests have
been successfully executed or to assist in debugging.
For both on-line and batch processing, utility steps will aid in analyzing the execution of the test
conditions. Utilities are desirable for reviewing or comparing updated files, interpreting data file
dumps, executing sort/merge functions and creating/deleting data file catalogue entries; and
Review command language instructions for errors.
A.17.36
Establish unit test environment.
Establish unit test environment:

Ensure that all of the required technology components and infrastructure necessary to
complete the unit tests are in place and are functioning correctly;
Provide external storage space to store the current and/or previous unit test version of
each executable program;
Provide physical space to store the unit test data files. Allocate enough space to permit
multiple generations of unit test data to be stored;
Page 281

The definition and development of a testing environment should have been initiated in the
Technology Planning, Support and Cutover. At that time, hardware, software and operational
requirements (e.g., configuration management) should have been defined and implemented for
the environment.
Load source programs and copybooks into the library and include record and/or segment
descriptions and common processing routines. This will ensure that multiple programs are
referencing the same items;
Restrict access to unit test libraries and test data to the responsible developer and/or
project team leader. Ensure adequate back-up and restore procedures are in place; and
Tools exist for the generation of test data, the repetition of regression tests and the
emulation of concurrent on-line sessions. If not already specified, determine the type and
specific instance of tools to be employed as well as the procedures related to the use of
automated test tools.
Some projects may require the construction of a test program driver to control the testing of a
variety of transactions through a series of linked programs.
A.17.37
Execute unit tests.
Execute unit tests:

Complete the unit tests following the Unit Test Plans. Test results should indicate the
submission and completion of the unit tests with the date and name of the person
conducting the test. During the test, automated tools specified earlier may be employed;
Document both deviations from the expected results and successfully completed test
conditions;
Attach a hard copy of final unit test results annotated with the test step reference from the Unit
Test Plan. Attach interim screen/window prints as appropriate to confirm the success of specific
unit tests as deemed necessary by the project manager;
Correct all outstanding errors, document the resolutions and conduct the appropriate unit
test(s) again. Automated testing tools may be employed during re-test.
If a separate Unit Test Team has been identified, logging and correcting program errors should be
controlled through the Test Problem Reporting (TPR) process. However, if the programmer is
responsible for unit testing, this degree of formality may not be required;
Document program specification changes. Testing may reveal errors or omissions in
program specifications. Changes to specifications may produce side effects outside of
the current program/module. Carefully examine the impact of these side effects before
recommending the program specification change, which is documented on a System
Change Request.
Analyst and/or team leader approval is required before the change is made;
Where program changes have a wider impact (e.g., a scope change or a policy change),
the issues resolution process should be used;
Complete the Program Control Checklist by including Unit Test Plan and output listings as
appropriate. Append the Unit Test Plan and unit test output listings to the Program Control
Checklist and cross-reference the page numbers on the Unit Test Plan and output listings
to the Program Control Checklist;
Submit program documentation with unit test results to the team leader and obtain formal
written approval; and
The documentation from the completed and approved unit test is annotated and filed as
part of the unit test documentation. This should include the full Unit Test Plan (i.e., test
Page 282

objectives, test conditions, test steps, test data files and expected results), unit test
results and unit test logs. Magnetic media versions of these items should be maintained
in a secure environment.
Page 283

A.17.38
Execute String Testing
Purpose
To identify errors in linked units of a system that exist as a result of the integration of the units and
not within the units.
Overview
String testing is an extension of unit testing that tests the linkages between structurally connected
units and is completed at several levels, which includes testing:
Linked modules of a program;
Linked programs of a functional sub-system; and
Linked sub-systems of a complete system.
Unit testing must be complete for each module of a program before the program level string
testing can be completed; program level testing must be complete before sub-system level testing
can be completed; and so on.
String testing checks for compliance with the program specification and the intended design
structure. As several programmers may be involved in the construction of various units of the
string, testing can be completed by a dedicated tester. Once each component of a program has
been fully unit tested, string testing attempts to identify errors caused by linking the units and in
the interfaces themselves.
A.17.39
Check interface standards.
Identify all internal interface standards and check that they have been adhered to rigorously. Any
interface not within standards should be documented as a failed test and be returned for
redevelopment.
Standards should exist that determine the rules for interfaces between the components of a
functional group. These standards should include:
Those that are implicit in database and calling sequence;
The order of objects by type within a call;
Format of the calling element;
Validation, at what point calling or called;
Indirect reference calls;
Rules for call by value and by name; and
Call syntax.
A.17.40
Develop Test Plan for string tests.
Specify test conditions to be developed to satisfy the test objectives and list the job steps to be
followed in creating the test conditions. Document the test data needed to exercise the test
conditions and indicate where "stub" programs are to be used to test the string.
Stub programs would be appropriate in testing client/server applications where a workstation
program may access a local database to provide input values to verify the functionality of the
program instead of having to access a database server across the network. Testing on the
appropriate technology platforms will be completed during.
A.17.41
Conduct string tests.
Execute and log the string tests using one or a combination of:
Page 284

Top-down testing:
design, develop and test stubs that simulate the functions of the lower level
units/programs,
test the top or driver unit/program using stubs in the place of lower level
units/programs,
add each lower level unit/program re-testing after each one is included, and
regression test to check that new units/programs have not had an adverse effect on
previously tested units/programs;
Bottom-up testing:
design, develop and test a program driver that simulates the driver aspects of the test
group,
test the lower level unit/program using the simulated driver modules, and
add the driver module and re-test the complete group; and
Group testing:
link the units of the string together,
test the integration of the group by exercising all input and output parameters, all
modules and calls and program options and special utilities, and
test the minimum functionality in each test so that errors identified can be retraced.
Each test when executed is fully documented so that the test result can be duplicated. This
includes back-ups of all affected files so that they can be returned to their original condition
before the test. Documentation includes:
Execution date and time;
Completion date and time;
System conditions at the time of testing such as system usage volume, database load
and concurrent processing and system software and utility versions;
The test case executed and the data used; and
Test results (e.g., output generated, data passed/received, errors logged, database
updates).
A.17.42
Document and resolve errors and issues.
Where errors are identified within the strings, these errors are documented and returned with the
test log and any Test Problem Reports to the programmer for correction. After correction, the
program re-enters the testing sequence. Errors that require changes to the original specification
or design should proceed through the issue resolution process.
A.17.43
Repeat for next level of integration.
After all components have been tested at one level, repeat the string testing procedure for the
next level of integration.
A.17.44
Submit program documentation with string test results to the
team leader and obtain formal written approval.
A.17.45
File all string test results.
Page 285

A.17.46
Develop Unit to System Test Migration Plan
Purpose
To execute a quantitative and qualitative check on the unit test deliverables, to ensure
completeness and compatibility with standards and to develop a plan for the controlled transition
from a unit to a system test environment.
Overview
This task provides a formal program hand over checkpoint. The program specifications and the
unit and string test results are reviewed to ensure that all of the necessary documentation has
been developed and that the contents of the documents meet the predetermined standards for
coding practices and quality control.
The migration plan for the transfer of unit tested programs and documentation to a system test
environment is reviewed to confirm the acceptance of both the direct migration path and any
contingency plans and, where necessary, updated.
As a final step, a migration plan to the system test environment is completed to prepare for the
System and Integration Testing Phase.
A.17.47
Validate program specifications.
Review the program specifications for all programs and confirm that all of the supporting
documentation has been provided and is complete. Use the Program Control Checklist as a
means of checking that all documentation has been completed and approved. Check for such
items as Program Logic Specifications, Edit/Validation Specifications, Report Definitions, System
Messages, Program Structure Charts and program code.
A.17.48
Conduct quality review of the program specifications.
Review all programs, as appropriate and confirm consistency of style and programming practices
as well as compliance with standards for coding and quality control.
A.17.49
Validate unit and string test results.
Review the Unit Test Plans and the expected results to confirm that all of the tests have been
executed successfully and verified. Confirm that all string tests have been successfully executed.
Ensure that all of the documentation needed to re-create the tests has been retained in a secure
form. Check specifically for Unit Test Plans and expected results, unit test data and system
change requests. Ensure that test utilities have been removed.
A.17.50
Review program documentation.
Confirm that all of the necessary program documentation has been provided including any job
control statements and library management documentation. Review for completeness and
accuracy.
A.17.51
Develop unit to system testing migration plan.
This step is generally completed by the System Test Team in conjunction with the project team as
it is the System Test Team that will ultimately be responsible for the migration process.
Develop a unit to system test migration plan that includes:
Confirming that the system test environment is properly established;
Recording the software configuration components of the unit test environment
Migrating the unit tested programs to the system test environment;
Page 286

Recovering the transferred programs to a stable base in the event of problems during the
migration process;
Testing the results of migration programs before the start of the system tests to ensure
that the migrated data is correct;
Establishing a software configuration system test baseline; and
Confirming that the responsibilities of the System Test Team and the Project Team for
system and integration testing are clearly defined and understood.
A.17.52
Conduct unit to system test migration.
Follow the procedures outlined in the previous step and record any problems using the issue
resolution process. Review issues that arise with management and determine if the fall back
procedures need to be invoked or if the System and Integration Testing Phase can commence.
A.17.53
Obtain formal written sign-off from the System Test Manager
that the migration has been successful.
Page 287

A.17.54
Construct Data Conversion System
Purpose
To build the programs and other means needed to convert data to the required format to initialize
the BW system.
Overview
The data conversion system design is reviewed and, depending upon which technique or mixture
of techniques is being used to create the master file and opening balance data, the conversion
programs or methods are constructed. If programs need to be written, they are written and tested.
The degree of effort required for these programs should not be underestimated as the conversion
sub-system may contain numerous, very complex programs.
The data conversion task interfaces with BW Administrators Workbench construction tasks.
Conversion input data must be closely aligned with the format required of historical data sources
identified and constructed in those tasks.
A.17.55
Allocate work tasks and responsibilities.
Depending on which methods of conversion are being used, the different detailed work tasks will
vary. The various work tasks are allocated to the project team members together with the
responsibilities for management of the process.
A.17.56
Key the data to be created in-house or through an external
service bureau.
If data is to be keyed using the new system's standard input routines, ensure that any batch input
needs are met, data input operators have the appropriate training and the necessary hardware is
available and functioning correctly.
If an external service bureau is to create the data, the contractual issues, detailed instructions,
media, delivery and receipt of data, error checking and timing should be finalized.
A.17.57
Use computer software bulk or mass maintenance routines.
If program routines or utilities exist that enable mass creation and replication of data, training
must be given in the use of these features.
A detailed structure and sequence of the creation process must be prepared together with the
correct clerical procedures to control the creation process.
The bulk or mass maintenance features should be tested to ensure an understanding of their
functionality and to determine when and what hardware capacity will be required. This is
particularly significant if there is a large amount of data to be created using this means.
A.17.58
Design and create custom data conversion programs.
If custom programs are to be written, then the following steps should be completed:
Design the data conversion programs using the programming techniques described in
earlier tasks in this phase;
Code the data conversion programs using the structured coding techniques described in
earlier tasks in this phase. Alternatively, these programs may be created using a program
generator or file utility; and
Page 288

Test the data conversion programs using the techniques outlined in the earlier tasks in
this phase. The conversion programs should be tested rigorously, particularly any
programs that are involved with reconciliation (e.g., control portions of conversion
programs or old versus new post-conversion comparison programs).
Note: This testing is to determine the proper functioning of the programs and not for validating
source data. Testing of the source data (i.e., cleansing), is completed when the program is
executed during the next task. In addition, test data must reflect erroneous source data to enable
verification of these processes in the data conversion programs. Where practical, mock
conversions can be utilized as a part of conversion systems testing. A mock conversion is a full
execution of the conversion system using real data to ensure reliable production execution of the
conversion.
A.17.59
Use utilities.
If utilities are to be used for some components of the data conversion process, then the tasks
should be completed as for the custom programs.
A.17.60
Use PC to host links.
If data is to be created on PCs and then uploaded to another machine, the tasks should be
completed following the same tasks/steps as for the custom programs.
Hardware utilization and capacity needs should be determined and the facility tested to ensure
that the transfer process functions correctly and at the planned speed.
A.17.61
File conversion software.
If third-party file conversion software or packages are to be used for components of the data
conversion process, this software will need to be installed and tested (using the standard baseline
testing tasks and steps) to ensure that it functions correctly.
Hardware utilization and capacity needs should be determined for usage.
A.17.62
Scan data.
If data is to be input through scanning devices, the scanners should be tested to determine:
Level of accuracy;
Speed of input;
Hardware requirements and utilization; and
Data correction tasks.
A detailed structure of work tasks, data preparation and sequence of the creation process must
be prepared together with the correct clerical procedures to control the creation process. The
routines for checking the scanned data for completeness and accuracy must be established
together with any error correction routines.
A.17.63
Use external databases for acquiring data.
If data is to be acquired externally, the purchasing considerations should be addressed and the
data tested to determine:
Security needs (e.g., Firewalls if the Internet is being used);
Accuracy and completeness of data and any error correction routines;
Method of receipt;
Input means; and
Hardware requirements and utilization.
Page 289

A detailed structure and sequence of the creation process tasks must be prepared.
A.17.64
Document data conversion procedures.
Document all of the data conversion procedures. The documentation of the data conversion
procedures should follow the documentation rules described in the User Documentation Phase,
but it generally need not be as comprehensive as for the new application. However, particular
attention should be paid to documenting the reconciliation and balancing procedures.
A.17.65
Determine training requirements for the data conversion
project team.
Determine if there is a need for additional training materials or training courses to be developed to
educate the data conversion project team members. If required, refer to the Training Phase for
more details.
A.17.66
Complete system testing of the data conversion job streams.
Unit, string and system testing of all parts of the data conversion systems should be tested in the
same comprehensive manner as in a normal systems implementation. The use of "real" data can
prove highly beneficial in this step.
The testing to be completed must include all of the different methods to be used in the conversion
process.
System testing of program jobs is needed in cases where several data conversion programs work
together to convert data. If each data conversion program works independently, then system
testing may not be necessary.
The entire data conversion process should be tested, including the verification procedures,
following the techniques using the System and Integration Testing Phase. If there are places
where multiple programs must work together (i.e., call one another or work on the conversion of
the same data in a multi-step process), System Test Plans should be developed and tests
executed for the integrated testing of those multiple programs. The system testing of the
conversion process should include a final cycle that tests the entire process and may include one
or more mock conversion executions.
A.17.67
Finalize the conversion schedule and resources and submit
and discuss with management.
The Data Conversion Plan should be updated to reflect any new information uncovered in this
task and formal written approval sought and gained. The scheduling of the execution of the data
conversion should be coordinated with the implementation schedule of the main system.
Submit the updated plan and the task deliverables to management and resolve any questions
and issues. If necessary, prepare an action list of items to modify. This step may require more
than one meeting.
A.17.68
Obtain formal written approval from management.
Page 290

A.17.69
Execute Data Conversion
Purpose
To convert data from the current system to the new system format or, if there is no existing
system, create the new data to initialize the DW system.
Overview
The data conversion may need to be completed more than once if there is parallel running or a
phased or staged implementation. This will impact upon the steps in this task.
A.17.70
Prepare for data conversion execution.
Prepare for data conversion execution. Before the execution of any conversion process ensure
that:
All required personnel and hardware resources are available;
Existing data files and data entry documents are frozen; and
The conversion process has sole access to the information during execution.
Generally, the database or master files need to be created as input to the system testing process.
To enable early commencement of data creation because of the volume of records or the
extended duration necessary, the data creation of the master files in a skeletal format may begin
well before the system acceptance testing and commencement of live processing. This impact
must be assessed as part of the preparation process.
A.17.71
Finalize conversion data cleansing.
Complete the data cleansing procedures of the source conversion data.

Corrections, deletions and additions should be made to the conversion data. This must be
completed after the source data is frozen to ensure the no "unclean" data is added to the source
information after the cleansing.
Any adjustments, e.g., write-offs, resulting from the cleansing should be completed and properly
authorized.
A.17.72
Execute data conversion.
Create additional data as necessary and execute the data conversion programs and procedures
according to the Data Conversion Plan. The entire data conversion execution may be a multi-step
operation completed over a length of time (i.e., a week may be scheduled for entry of data,
execution of specific programs may be done on different days or execution of a specific program
may have to wait for error-free reconciliation results from previously run programs).
Complete the acceptance testing according to the defined data conversion acceptance criteria.
Prepare documentation and audit trails of the actual conversion process and ensure that the
conversion results are properly checked by the appropriate resource (e.g., internal audit).
The creation or storage of the appropriate historical data is included as part of this conversion
process.
The steps will also vary if there is parallel running or a staged or phased implementation.
Page 291

A.17.73
Reconcile converted data with existing data.
Reconcile the results of the conversion execution with the original source data. Enter details on a
data conversion reconciliation worksheet. Ensure that the reconciliation process is clearly
documented and supporting information for each reconciliation item is prepared and maintained.
As mentioned above, reconciliation of the results of some conversion processes may be
completed before execution of other processes.
Appropriate formal written approvals must be obtained that the reconciliation has been properly
completed, particularly if the conversion demands that some write-offs or other adjustments occur
that impact upon an organization's financial results or balance sheet.
A.17.74
Retain source data.
After the conversion and reconciliation of data has taken place, archive the old system data in
case the system support team subsequently needs to refer to the original data to resolve any
audit requirements and any problem areas. Agree on the length of time with management for
which the data should be retained.
If parallel running is to take place, ensure that the old system data is maintained along with the
new data to allow periodic comparisons between the old and new systems.
If a staged or phased implementation is to occur, progressive reconciliations should be completed
together with an overall reconciliation when all areas are implemented.
A.17.75
Sign-off on converted data and file conversion reconciliation
worksheets.
Obtain formal written agreement and sign-off from the appropriate authority that all the
appropriate data has been successfully converted and reconciled and that the data is in the
correct state to commence use of the new system.
Maintain copies of the signed-off and authorized balancing procedures, documents and
supporting detail and ensure that these working papers for the actual system balancing are
archived in a secure location, as they may need to be referred to at a later date for a variety of
reasons such as the annual audit.
Page 292

A.18 BW Administrators Workbench Construction

Purpose
To construct the Business Information Warehouse system based on the Business Blueprint
design specifications.
Overview
The BW components will be constructed and tested. In addition, Global Configuration settings
are finalized.
Page 293

BW Administrators Workbench Construction Task Relationships
In s t a lle d B W E x tr a c t io n P r o g r a m s
D a ta D e s ig n
R1
P re p a re S o u rc e
S y s te m s
R2
C h a n g e /U p d a te M e ta
D a ta
R3
C re a te In fo C u b e s
R4
M a in t a in
C o m m u n ic a tio n
S tru c tu re
R5
M a in t a in T r a n s f e r
R u le s
R6
C r e a te / M a in t a in
U p d a te R u le s
R7
S c h e d u le
In fo P a c k a g e s
Page 294
P re p a re d s o u rc e s y s te m s
M a in t a in e d D a ta S o u r c e M e ta D a ta
In fo O b je c t C h a r a c te r is tic s
In fo O b je c t K e y F ig u r e s
In fo C u b e s
A g g re g a te s
In fo S o u r c e C o m m u n ic a tio n S tr u c tu r e
T r a n s f e r r u le s
T ra n s fe r s tru c tu re
P e r s is te n t S ta g in g A r e a ( P S A )
D a ta s o u rc e s
U p d a te r u le s
In fo P a c k a g e s /G ro u p s

A.18.1Prepare Source Systems

The purpose of this task is to maintain the proper BW environment after the BW installation has
taken place. Because the BW is fed externally the task involved with the Production System
Environment is done in two systems - R/3 or non-R/3 sources and the BW server.
Before the design and build stage of the implementation can begin the connection between the
R/3 and BW system must be established. Once the connection is established data can begin to
migrate between the two systems. The following section will outline the necessary steps for
establishing the connection and data migration.
Once the ALE connection is established between the source system (R/3, Non-R/3 or BW
systems), preparation of the InfoSources in source system is necessary for some applications.
Each of the standard InfoSources has assigned extraction tables and programs within the source
system. To make the extraction functionality active certain configuration steps must be executed.
Depending on the extraction application steps involved, there are sometimes different types of
setup and configuration activities, that may not always necessary.
An InfoSource is used to supply the BW with data from an OLTP R/3 System or Non-R/3 System.
In this step we are referring to the source system preparation of data, which will be loaded to the
BW system.
An InfoSource is derived by incorporating several different components. The components
involved are listed below:
Extract Structures (Extraction tables in the Source System)
InfoObjects (field definitions)
Transfer Structure (The structures that passes data between Source Systems and the BW
System)
Communication Structures (The structures that pass data to the InfoCubes once it arrives in
the BW)
Prerequisites
Before the standard InfoSources can be prepared in the Source system the standard extraction
programs must be installed.
Activities
Confirm RFC Destination and Basic ALE Settings

Configure the data extraction components within the BW
For some applications utility programs which prepare the BW environment in the R/3 system
should be executed
LIS - Program RMCSBIWC
CO-PA - Program RKEBIW01
For some applications 3rd Party OLTP extraction utility programs will be used to prepare
and extract data for the BW environment
ETI - Custom developed extraction Programs
Informatica - Custom developed extraction Programs
Page 295

A.18.2Confirm RFC Destination and Basic ALE Settings

Purpose
Source systems are all systems, which provide the Business Information Warehouse with data.
These can be either SAP BW systems from Release 2.0A onwards or external systems.
A communication structure between BW source systems and the Business Information
Warehouse is only possible if service APIs and application APIs have been installed in the source
system. If this is not the case then you have to install both APIs on the BW system using the
Business Information CD.
Before you can insert a new BW source system in the Business Information Warehouse you have
to maintain the RFC description of the Business Information Warehouse server in BW and
maintain the ALE basic settings between the two systems.
Task
The following task are done in both the R/3 and BW systems:
Maintain the OLTP RFC Destination in the R/3 and BW systems
If you define a new source system manually you have to create a RFC destination in the
transaction sm59 R/3connections. The name of the RFC destination must correspond to
the logical system field in the table T000.
Enter the communication parameters (IP address). Please read Creating RemoteFunction-Call-Destination Parameters for more information.
Save your entries.
Maintain the ALE Basic Settings in the R/3 and BW systems
ALE is the underlying mechanism for communication between an R/3 OLTP client and a
BW client.
Maintain logical system.
Identify your system, by using the name of the RFC destination that you created in the
prior steps.
Assign logical system to the client.
Select the client and maintain the logical system, by using the name of the RFC
destination that you created before.
Undertake workflow basic settings.
Test the RFC destination with the corresponding function.
Select the function Automatic customizing, in order to verify the workflow of the run time.
If this step has been successfully concluded then the traffic light should be at least yellow.
Set up ALE users.
A.18.3Implement Using Standard Delivery

Purpose
In this section the standard delivered InfoSources should be maintained. After the BW installation
on the (R/3 or Source System) server several new objects will exist. Setup for several of these
objects is required in the R/3 or Source System environment.
For example, in the Sales and Distribution module the InfoSources for S001-S006 and S260S263 should be maintained using program RMCSBIWC. In addition, the purchasing modules
InfoSources for S011, S012, S013 and S015 should be maintained using RMCSBIWC.
In another example: Accounts Receivable, Accounts Payable, Profit Center Accounting, and Cost
Center Accounting InfoSources do not require additional configuration.
Page 296

Steps
Review the document "OLTP Configuration Steps" for technical and functional requirements
Identify which standard InfoSources need to be configured for your implementation
Complete the necessary configuration steps for data migration
Tools
Use table ROIS to view the standard InfoSources
Programs RMCSBIWC and RKEBIW01
A.18.4Implement Using LIS Structures

Purpose
Often SAP customers are concerned about the data migration for self-defined InfoStructures in
LIS. These are not considered to be standard SAP InfoSources, but still can migrate data to the
BW if the proper configuration steps are executed. Using the utility program RMCSBIWC the
proper BW environment can be installed for any self-defined information structure.
Steps
Review the "OLTP Configuration Steps" document

Identify which self-defined information structures are needed
Use Program RMCSBIWC and execute the necessary steps for each self-defined structure
Refresh the Meta Data in the BW
Configure the InfoSources communication structure and transfer rules
Once the configuration steps are executed and the Meta Data has been refreshed the selfdefined information structure will appear as an InfoSource to the BW server. To migrate data the
InfoSources communication structure and transfer rules should be maintained.
A.18.5Implement Using COPA Structures

Purpose
In addition to LIS, many SAP customers have developed their own reporting structures in the
COPA module. These structures are known as Operating Concerns. Using program RKEBIW01,
any Operating Concerns can be configured within the program to migrate data to the BW system.
Procedure
Review the document "OLTP Configuration Steps"

Execute Program RKEBIW01 in the R/3 system
Refresh the Meta Data in the BW
Configure the communication structure and transfer rules in the BW
Once the Meta Data refresh is executed, the Operating Concern data will appear as an
InfoSource in the BW.
A.18.6Implement Using Flat File Structures

Purpose
Data can be transferred to the Business Warehouse using flat files (sequential files). Flat files are
useful for loading external transactional data, master data, and hierarchies.
Page 297

The following section explains how flat files can be uploaded.
Prerequisites: The data must be in the given format of the current valid transfer structure for the
transfer from files.
Steps
Review the documents on Flat File Uploads

Define the source system in the BW Admin Workbench
Flat files are considered source systems.
Create the application components for the source system file

Decide what type of flat file is being loaded, i.e. transactional data, master data or hierarchies
Assign the source system to the application component
Define what InfoObjects are assign to the flat file InfoSource
Develop data transformation specifications
Maintain the communication structure and transfer rules.
You can fall back on various formats, which are displayed as ASCII flat file, for external systems.
The scheduler falls back on these formats with an external data request. The determination of the
data type (Meta Data or data) is important in the global InfoSource.
The Business Warehouse can process the following formats:
Fixed data record length
Variable data record length
CSV format (colon separated variables, an MS excel format)
Page 298

A.18.7Change/Update Meta Data

Purpose
Meta data is often referred to as "Data about Data". For each of the InfoObjects (field elements)
in the BW there is underlying information that can be of a technical or business nature. This type
of information can be defined as meta data.
The BW meta data refresh feature will read the meta data contained in the source system and
automatically generate the meta data definition within the InfoObject Repository. For example
field lengths, text relationships, the table storage for all valid values can be updated into the BW
via the Change/Update meta data feature.
If a field definition changes, in the source system or a new field is assigned to an InfoSource for
data migration, the meta data update will capture the necessary information to be updated in the
BW.
In the Business Information Warehouse you have the following import and update possibilities
available to you for meta data:
Automatic meta data import from an R/3 System.
Going from the InfoSource catalog, the local InfoSource belonging to the source system
requests meta data.
Manual maintenance of the meta data using the path Administrator workbench ->
InfoSources.
The manual maintenance allows you to insert and delete fields for the local InfoSource and to
change the length of fields. The system automatically integrates the newly created fields in
the global InfoSource.
Use of the BAPI interface for manipulating the meta data in the Business Warehouse
(external system).
The BAPI interface offers the same functionality as the manual maintenance and is subject to
the same restrictions.
Use of the BAPI interface with a third party tool (external system).
This is a special case of the use of the BAPI interface of the Business Information Warehouse.
Here, a third party is used which reads meta data from the source system and transfers it to the
Business Information Warehouse using the BAPI interface.
Prerequisites
Before the meta data refresh is executed, the InfoSource must be properly maintained in the
source system.
Steps
Review what InfoSources are contained in the BW

Decide the frequency of how often the meta data refresh should be done
A.18.8Maintain Meta data on InfoObjects

Purpose
Each InfoObject is stored in the BWs InfoObject Catalog, which is a repository of meta data. For
example, technical aspects like the field length, text descriptions, master data attributes,
navigation and reporting attributes can be influenced by the maintenance of meta data.
Page 299

Both SAP delivered InfoObjects and self-defined InfoObjects can be maintained within the
InfoObject Catalog.
Procedure
Review each InfoObject contain in your data models

Create new InfoObjects if necessary
Maintain meta data on InfoObjects
A.18.9Create Characteristics
Purpose
Characteristics are the BWs dimension elements. Characteristics can be updated via the meta
data refresh or can be maintained manually in the InfoObject catalog. Example characteristics are
InfoObjects like customer, material, company code, and cost center.
When a meta data refresh is executed characteristics are created for automatically for each
InfoObject contained in the BWs InfoSources. Often additional characteristics are needed to
meet reporting requirements. These types of characteristics are often derived using data
transformation techniques.
Procedure
Review the data models that need to be created

Map the data models to the delivered characteristics
Determine if new characteristics need to be created
Add the characteristic to the InfoObject catalog
Maintain the meta data on the new characteristic
A.18.10
Create Key Figures
Purpose
Key figures are the BWs fact table elements. Key figures are often referred to as "facts". Key
Figures can be updated via the meta data refresh or can be maintained manually in the
InfoObject catalog. Key figures are quantities and values. For example, invoice sales, cost, or
discounts.
When a meta data refresh is executed characteristics are created automatically for each
InfoObject contained in the BWs InfoSources. Often additional characteristics are needed to
meet reporting requirements. These types of characteristics are often derived using data
transformation techniques.
Procedure
Review the data models that need to be created

Map the data models to the delivered key figures
Determine if new key figures need to be created
Add the key figures to the InfoObject catalog
Maintain the meta data on the new key figure
Page 300

A.18.11
Create InfoObjects
Purpose
InfoObjects in the BW can be updated via the meta data refresh or created manually. The
purpose of this task is to identify additional InfoObjects needed in the BW that are not updated via
the meta data refresh. These types of InfoObjects are often derived or updated from an external
file.
Procedure
Review your data models and identify new InfoObjects needed.

Determine if the InfoObject is a characteristic or key figure
Add the characteristic to the InfoObject catalog
Maintain the meta data on the new InfoObject
Determine how the new InfoObject will be sourced
Page 301

A.18.12
Create InfoCubes
Purpose
The purpose of this activity is to create the multi-dimensional data containers that are based on
the result of a multidimensional data model (star schema) to be used for queries and evaluations.
Prerequisites
The Star Schema (data model) that represents the end-users query and evaluation
requirements.
Result
A number of relational tables connected by SID tables will be created. This includes a Fact
Table that connects up to 16 Dimension Tables via dimensional keys. System requires a
minimum of a Time, a Unit and a default Data Packet Dimensional Tables plus one or more
Dimensional Tables that consists of characteristics for queries and evaluations.
A.18.13
Select Characteristics
Purpose
The purpose of this activity is to select and assign characteristics to a dimension table according
to the predefined star schema in creating an InfoCube.
Procedure
Review the multidimensional data model

Review the required characteristics (InfoObjects) have been included in the communication
structure
Define Dimension tables and assign characteristics according to the star schema
Refer to "Maintain InfoCubes" section of BW Online documentation.
A.18.14
Select Key Figures
Purpose
The purpose of this activity is to select Key Figures and assign to the Fact Table according to a
predefined star schema.
Procedure
Review Key Figures defined in Fact Table of the star schema (data model)
Verify the Key Figures are defined in the communication structures of the target InfoSources
Refer to "Maintain InfoCubes" section of BW Online documentation for detailed processes
A.18.15
Define Dimensions for Unit, Time, Package
Purpose
The purpose of this activity is to select and assign Time Dimension characteristics and to insure
that the system assigned Unit and Data Package Dimension are corrected defined. These are
mandatory Fixed Dimension Tables of an InfoCube.
Page 302

Procedure
Review the star schema (data model) time characteristics for time dimension
Refer to the online documentation for menu path to define time dimension
Result
Time Dimension Table structure will be created.

Unit Dimension Table structure will be created automatically based on the selected Key
Figures. Data Package Dimension will be automatically created without requiring any manual
action.
A.18.16
Define InfoObjects
Purpose
To define Characteristics, Key Figures and Unit characteristics which are used in creating of an
InfoCube.
Procedure
Click "InfoObject" Icon from the menu tool bar or choose "Edit InfoObject" drop down menu
Select type of InfoObject: Characteristics, Key Figure, Unit or Time Characteristics.
Note: Customer defined Time Characteristics are not a currently supported function.
Enter a name and the description of the InfoObject

You must create the Characteristics with the property "Create with New Check table" if the
InfoObject has text table, with hierarchy, master data attributes or has compounded
characteristics
Enter a description, a data type and the length of the InfoObject
Click on the appropriate Tab to further define Hierarchy, Attributes and Compounding
characteristics
Click the "Check" Icon on the menu bar to verify the definitions are ok
Click Save and Activate to create characteristic or key figures in the InfoCatalog and the new
or changed DDIC objects are saved and activated
Page 303

A.18.17
Maintain Communication Structure
Purpose
The communication structure is localized in the Business Warehouse and displays the structure
of the InfoSource. It contains all of the InfoObjects belonging to the InfoSource of the Business
Warehouse.
The communication structure is either filled from the transfer structure with fixed values or using a
local conversion routine. The routine always refers to just one InfoObject of the transfer structure.
The sum of the InfoObjects of the communication structure can differ from the sum of the
InfoObjects of the transfer structure. The intention here is: The transfer structure brings in all the
OLTP defined fields. Within the communication structure definition we can control which fields will
update the InfoCube.
The InfoSource Communication Structure should define the integrated Subject Area view of data
being brought into BW.
InfoObjects available for defining the Communication Structure are initially provided by the fields
of attached Data Sources, but can be manually added as well.
Trigger
Before you can maintain the communication structure for an InfoSource, the source
system must be assigned. This is done when the meta data refresh occurs for R/3.
Input
Determine if additional InfoObjects are needed.
Determine if the additional InfoObjects will be derived.
Create the communication structure using the BWs Administration Workbench.
Page 304

A.18.18
Maintain Transfer Rules
Purpose
The transfer structure can be found in the source system and is mirrored in the Business
Warehouse. It is the structure, in which data is transported from the source system into the
Business Warehouse. When the transfer structure arrives in the BW the data is in its "raw" format.
Transfer Rules can then be maintained which define how the data should be transformed or
staged. These transfer rules either directly map the InfoObjects in the transfer structure to the
InfoObjects in the communication or provide additional rules for data transformation.
Prerequisites
Before you can maintain the transfer structure you must assign a source system to the
InfoSource and have created a communication structure. This is done when the Meta Data is
executed.
Determine how the data should be transformed.
Document the business rules behind the data transformation,
A transfer structure always refers to one source system and one communication structure. It is
the "Translation" of the extract structure into the Business Warehouse. For each InfoSource,
whether it is SAP delivered or custom, transfer rules need to be generated.
A.18.19
Implement Logic for Transfer Rules (Global)
Purpose
The Staging Engine is employed to implement data mapping and transformation. Transactional
data, master data and hierarchies all can be "staged" within the BWs staging engine.
When staging master data it is important to implement a strategy that clearly outlines the
business rules utilized when the data is being transformed. This is especially important if the
master data is fed from multiple systems.
Procedure
Identify the data source for the master data

Identify what type of master data is contained in the master data InfoSource
R/3 Data
External Data
Derived Master Data
Decide what standards should be followed
Is the external master data going to combined with R/3 data?
Can the master data be converted to R/3 standards?
Is the external master data going to be converted?
Document business rules for the characteristics and key figures
A.18.20
Define InfoSources
Purpose
The BW recognizes the business role played by data and applies this knowledge to data
extraction, to mapping and to the structures used to store the data in the warehouse. Since
multiple applications will provide data to the BW it is important to define the data content for each
InfoSource that will be utilized.
Page 305

Procedure
Identify by application which InfoSources will be utilized by the BW

For each InfoSource identify what data will be provided
For each InfoSource identify the data source
For each InfoSource identify the transformation rules
For each InfoSource identify which data structure will be updated by the InfoSource
A.18.21
Define Master Data Extraction
Purpose
In addition to the extraction of transactional data, the BW can extract master data attributes from
a source system. These attributes will provide the BW with additional navigation attributes when
executing queries. For example, if the InfoObject for customer is used within a query it is possible
to summarize data by the customer attribute region.
It is also important to define how often the master data extraction should be conducted. Master
data attributes are often changed in the source system and capturing these changes in the BW is
essential.
Procedure
Identify which InfoObjects will have additional master data attributes

Identify the content for each of the master data attributes
Identify the source system for the master data attributes
Identify the frequency of the master data extraction
A.18.22
Define Transfer Techniques to Different Application Areas
Purpose
After the data sources have been defined it is important to identify which transfer technique will
be utilized. The different techniques are:
Flat File Upload
Third-Party
BAPI Interfaces
R/3 ALE & TRFC APIs
Steps
Identify each of the source system

Identify the InfoSources for each of the source systems
Document the transformation technique for each InfoSource
A.18.23
Test Data Extraction
Purpose
After the flow of the data has been configure it is important to test the results of the extractions.
This can be done after the data sources have been defined, the InfoSources are configured and
the update to the InfoCube is created.
After creating the data extracts ensure that the data values are correct.
Page 306

Procedure
Identify what data should be extraction

Document the expected results for the query
Schedule the extract
Monitor the extraction
Execute the query
Test the datas integrality ensuring that all transformations worked
Compare the queries results to the expected results
A.18.24
Develop Transfer Schedule
Purpose
BW ensures the consistency of the load process. The transmission of the extract data is
performed in an asynchronous fashion, giving the administrator the flexibility to run the multiple
different tasks for building the extract, transferring it to BW and updating the InfoCubes, at the
same or independent times.
Once the source and target structures and mapping rules are set up, the administrator uses the
Scheduler, the Data Load Monitor and the Data Access Monitor to control and supervise the
ongoing operation of BW. The Scheduler maintains extract and load jobs, which typically run at
recurrent time intervals (e.g. once daily).
The frequency of the data extracts for transactional data, master data and hierarchies should
coincide with the businesss need for data. In addition, it is important to define what data should
be extracted from the source. For example you may want to extract data for Company Code 0001
and Company Code 0002 at different times even though the same data container is being
updated.
Procedure
For each data container identify how often the data should be updated
Identify the InfoSources for each data container
Identify the source systems for of the InfoSources
Identify the content of the data extract
Schedule the data extraction for each of the source system
A.18.25
Implement Logic for Transfer Rules
The Staging Engine is employed to implement data mapping and transformation. Transactional
data, master data and hierarchies all can be "staged" within the BWs staging engine.
When staging transactional it is important to implement a strategy that clearly outlines the
business rules utilized when the data is being transformed. This is especially important if the
transactional data is fed from multiple systems.
Transactional data can be transformed in the following ways:
Clean/Scrub the data
Derived additional business statistics for key figures
Derived additional characteristics for dimension elements
Derived characteristics based on transactional data values
Procedure
Identify the data source for the transactional data
Page 307

Identify what type of transactional data is contained in the datas InfoSource

R/3 Data
External Data
Derived Master Data
Identify the application for the transactional data
Decide what standards should be followed
Will the transactional data be combined with other transactional data?
Will the transactional data be combined with transactional data from another application?
Is the external transactional data going to combined with R/3 data?
Document business rules for the characteristics and key figures
Page 308

A.18.26
Create/Maintain Update Rules
Purpose
The purpose of this activity is to define the data mapping, data condensing and data
transformation logic from InfoSources to an InfoCube
Prerequisites
Completion of InfoCube definition.

The InfoSource maintenance must have been successfully completed. This includes maintain
the transfer structure, communication structure and transfer rules in Administrator
Workbench.
Input
SAP and non-SAP Data mapping documents.

Data definition.
The communication structure of the target InfoSources must have been maintained.
Result
Established the connection between InfoSources and the InfoCube.

System generated data transfer ABAP module with direct data mapping for InfoObjects.
ABAP routines consist of the logic to transform data from communication structure to the
InfoCube.
Tips
Successful maintenance of communication structures of the target InfoSources must be
completed prior create InfoCube update rules.
A.18.27
Implement Logic for Transfer Rules (by InfoCube)
Purpose
The purpose of this activity is to define the mapping rules from InfoSources to InfoCube for key
figures, characteristics and the time characteristics.
Procedure
Review the data transfer and conversion rules documents

Follow procedures in BW online documentation to maintain update rules
If the InfoCube is to be filled by multiple InfoSources determine which key figure is to be
updated by which InfoSource
Select No-update data type for key figures that are not to be updated by this InfoSource
Review system suggested data mapping update rules for appropriateness
If system suggested rule is incorrect or system has no suggestion (status flag is red) you may
either select an available InfoObject from the pull-down list or create a routine to fill it from a
different source
Switch through the characteristic derivation and time reference tabs to correct all
characteristics with red flags
Repeat for each key figure until status flag is green for all key figures
Activate the Update rules
Page 309

Result
System generated or customized ABAP module/routines will be created based on the update
rules that you specified.
Meta data upload to the InfoCube is ready to proceed.
A.18.28
Develop Rules with Formula Editor or ABAP Routine
Purpose
The purpose of this activity is to develop more complicated update rules via the creation of an
ABAP routine.
Procedure
Review data transfer and conversion rules documents

For complicated program logic, a flow chart may be warranted
Review and verify that all data sources including any external tables that will be used within
the program logic have been defined in DDIC
Follow the procedures in BW online documentation, Administrator Workbench: Maintain
Update Rules
Include your table and data declaration in the top of SAP update-routine template
Create the program logic in the section as instructed by SAP update-routine template
Click "Check" icon after you completed your program logic for correctness
Activate the InfoCube
Result
ABAP Routines to create customized update rules using SAP update-routine template will be
created.
Page 310

A.18.29
Schedule InfoPackages
Purpose
The purpose of this activity is to create InfoPackages to request data (transaction data, master
data, attributes or hierarchies) from a source system according to the selection parameters.
Prerequisites
Upon completion of InfoCube and Update Rule creation.
Input
High-level Transformation Design.

R/3 and Non-R/3 Data Mapping Documents.
InfoSources and Source system names.
Data Selection parameters for each InfoObject and/or the whole package.
Result
A new InfoPackage or InfoPackage variant will be created and scheduled, either immediately
or through batch process.
IDOC will be created.
Outcome
InfoCubes connected to the InfoSources and the defined Source systems will be updated
according to the selection parameters.
A.18.30
Select InfoCubes
Purpose
The purpose of this activity is to create or maintain an InfoPackage that prepares for the data
transport request from an R/3 source system.
Procedure
Review the Data Flow document for the involved source system and InfoSources
Determine the selection parameters for each InfoObject that data upload is requested for
The data upload will only process data based on the criteria you specified.
If you are request data upload for a hierarchy then determine the target hierarchy within the
InfoSource
Determine if all InfoCubes relevant to this InfoSource should be updated or only the selected
InfoCubes
Determine if the presence of Master data element is essential prior to transaction data upload
Reference to BW online documentation on Maintain InfoPackages for step by step
procedures
Result
InfoPackage or Variant is defined and ready to be scheduled for data upload
Page 311

A.18.31
Identify InfoSources Transferring Data to InfoCubes
Purpose
The purpose of this activity is to specifically address the InfoPackage definition process for data
sources from a non-R/3 system.
Procedure
Review High-level Transformation Design document for source system and InfoSources
involved
Obtain the source system file name and location
Determine the data separator format for CSV (Excel file) by opening the CSV file with note
pad
Determine if control file is present for other external data files
Determine if all InfoCubes relevant to this InfoSource will be updated or only selectively
updated
If Master upload is involved determine whether the presence of Master data is essential
Refer to BW Online documentation Maintain InfoPackages for the step by step instruction to
maintain InfoPackages
Result
InfoPackage or InfoPackage variant will be created and ready to schedule for data upload
Tools
A.18.32
Develop Transfer Techniques to Different Application Areas
Purpose
The purpose of this activity is to schedule a pre-defined InfoPackage for immediate or periodic
batch run to populate the data contents of the impacted InfoCubes.
Procedure
Review the Data Refresh frequency document

Review High-level Transformation Design document to determine the job dependencies
Reference to BW online documentation, Scheduling InfoPackages for the step by step
procedures
Result
Data transfer IDOC will be created along with Info IDOCs.

The selected InfoCubes will be populated with data in dimension tables and Fact table from
the InfoSources of the source systems.
A.18.33
Develop Rules with Formula Editor or ABAP Routine
Purpose
The purpose of this task is to develop batch transformation rules and routines, via the BW
workbench tool using the formula editor or ABAP routine and the InfoPackage batch Job
scheduling functions. Make sure to review all of the existing batch interfaces in the R/3 system,
before you start development. In addition, you should make sure documentation has been
created for all of your development activities. During development, you should consider Job
processing performance issues. Be aware that the process of creating and later testing of the
interface programs will very likely consume a significant amount of time.
Page 312

In addition, it is important to consider what sequence the batch InfoPackages and interface
programs will be running.
Procedure
From the basic methods of data transformation and transfer with R/3 systems and Non-R/3
systems, namely file access and program-to-program communication, both are suited for batch
interfaces and transformation rules discussed in this section. But because of the nature of
asynchronous data processing in batch interfaces and the development effort needed for
program-to-program communication, an online data transfer is probably not the first choice for
this kind of transformation rule interface.
Batch interfaces should be integrated into R/3 on the application server level NOT via front-ends.
An integration on database level could be also considered, but is highly dependent on the
database system and the techniques provided by the database vendor (e.g. Embedded SQL,
OBDB, etc.). Thus the focus in this task will be on SAP adopted techniques.
The R/3 and BW systems offer different methods for transformation and transfer of data into the
BW System from other SAP Systems and non-SAP Systems in a batch Job processing mode.
These methods are "Batch Input", "Call Transaction", "Direct Input", BAPI and IDOC interfaces
Batch Input (BI)
Call Transaction (CT)
Direct Input (DI)
BAPI
IDOC
BAPIs are normally used for online interfaces but could be used also for batch Job processes.
IDOC interfaces can be configured to send and receive IDOCs in bulks, i.e. collecting IDOCs
before sending and processing, thus forming a batch interface.
Steps
Review Data Flow document to determine the Job dependencies/sequences

Reference to BW online documentation, Scheduling InfoPackages for the step by step
procedures
Batch Input
In BI an ABAP program reads the external data to be entered in SAP and stores it in a "batchinput Job session". Such a Job session stores the actions that are required to enter data
using normal SAP transactions. When the program has finished generating the Job session,
you can run the session to execute the SAP transactions for posting.
You can both explicitly start and monitor a Job session with the batch-input management
function or have the Job session run in the background processing system, when the system
is less busy. This method uses the function modules BDC_OPEN, BDC_INSERT and
BDC_CLOSE to generate Job sessions. BI uses a common data structure BDC_DATA
defined in the SAP data dictionary for holding the instructions and data for SAP transactions.
Call Transaction
In the CT processing method, a program uses the ABAP CALL TRANSACTION USING
statement to post the transformed and transferred data. Batch-input data does not have to be
deposited in a Job session for later processing. Instead, the entire batch-input process takes
Page 313

place inline in the program.
Direct Input
This technique is an enhancement of the batch-input procedures. In contrast to batch input,
this technique does not create Job sessions nor does it process screens. It stores the data
read from a flat file directly into the SAP application tables. To do this the SAP system calls a
number of function modules provided by the applications out of several reports. These
function modules are carrying out the necessary business transformation rule checks. In case
of errors DI provides a restart mechanism. However, to be able to activate the restart
mechanism, DI programs must be executed in background.
BAPI and IDOC Interfaces

These techniques and their pros/cons are already discussed in the online section of this task.
Especially they could be also used in the context of batch interfaces.
Result
Batch interface InfoPackages, Transformation BW Programs and Procedures
A.18.34
Test Data Extraction
Purpose
The purpose of this task is to set up procedures for testing the InfoPackage Jobs and InfoSource
data extraction programs (i.e., R/3 system extraction programs or Non-R/3 extraction programs
from ETI or Informatica, etc.) User departments must be involved in testing to ensure data
integrity, accuracy, and completeness. Use a separate client in your QA environment for testing
your data extraction Jobs and programs.
Procedure
To perform test runs on a select number of data records in the R/3 and/or Legacy Source
Systems to allow for testing of all data values
The test plan must include a description of the test processes and of the data consistency
checks in the R/3 System and Legacy Source System
After data extraction, transformation and transfer process have completed, you should test all
related business processes, and check BW master data values for accuracy
The test plan must ensure that data is correct and imported into the BW System
A.18.35
Develop Transfer Procedure
Purpose
The purpose of this task is to develop data transfer procedures, which may involve exporting the
transport settings in the R/3 Repository and QA environment to the production environment.
Successful import of customizing settings and R/3 Repository objects is a prerequisite of the data
transformation and transfer process. The R/3 and BW systems provide tools for data
transportation.
Another purpose of this task is to identify all data transfer requirements, and to develop a
conceptual design. Data from existing legacy systems may also be required to be transferred into
the BW system, and you need to identify both manual and automated transfer procedures.
Page 314

Procedure
Determine if BW InfoPackage Job requires InfoSource data to be transferred from R/3 system
or Non-R/3 Legacy system
This data will eventually be loaded to a corresponding BW InfoCube.
Identify what InfoSource data needs to be transferred

Outline the conceptual design of InfoSource transfer procedure
Write a high-level specification of how to transfer the data from a functional or business point
of view
Be sure to document the following information for each InfoSource and InfoPackage Job
Process
Expected Number of Files
Expected Sequence of File Processing, Data Flow Diagram for end-to-end process
Expected Quality of Data
Expected Complexity of Data
Expected Time and Cost Estimate
A.18.36
Monitor Log Files from InfoPackage
Purpose
The purpose of this activity is to monitor and review the result of the InfoPackage execution, take
corrective action based on the status and information provided by the log file.
Prerequisites
Post InfoPackage scheduling.

Upon receiving "Data Request executed" message on the message line.
Input
BW monitor status display screen.

Refer to BW Online document: Monitor for detailed screen presentation and procedures.
Page 315

A.19 BW Business Explorer Construction

BW Business Explorer Construction Task Relationships
A u t h o r iz a t io n D e s ig n
P r e s e n ta tio n S y s t e m D e s ig n
S1
Im p le m e n t
A u th o r iz a t io n C o n c e p t
P r o f ile s
A u th o r iz a t io n O b je c t s
U p d a te d U s e r M a s te r
S2
V a lid a t e A u t h o r iz a tio n
C oncept
V a lid a t e d a u t h o r iz a t io n p r o f ile s a n d o b je c t s
S3
C o n s tr u c t B u s in e s s
E x p lo r e r P r e s e n ta tio n
S y s te m
Q u e ry
W o rk b o o k
S tru c tu re
R e s t r ic t e d K e y F ig u r e s
C a lc u la te d K e y F ig u r e s
V a r ia b le s
Page 316

A.19.1Implement Authorization Concept

Purpose
The purpose of this activity is to implement the authorization concept for productive operation.
This task includes creating activity groups, generating profiles, developing test user master
records, and testing authorizations.
Tasks
Create Activity Groups

Generate Authorization Profiles
Create User Master Models for Job Roles
Test User Master
Create Authorization Profiles and Job Roles Document
A.19.2Create Activity Groups

Purpose
The purpose of this task is to create activity groups.
Activity Groups contain data (transactions, reports selected from the company menu) used by the
Profile Generator to generate an authorization profile.
The Profile Generator simplifies setting up the authorization environment. The authorization
administrator configures company-specific settings. The Profile Generator does all other tasks,
including selecting the relevant authorization objects.
Procedure
Provide basic information to identify the activity group. This task is mandatory.
Select the reports and transactions from the R/3 Company Menu to include in the activity
group. This task is not mandatory, but is recommended (95% of the time).
Choose the tasks to include in the activity group. This task is not mandatory, but is
recommended if you use SAP Workflow.
A.19.3Generate Authorization Profiles

Purpose
To generate an authorization profile, you must first create an activity group.
When you have defined an activity group, you can use the Profile Generator to generate an
authorization profile. The Profile Generator uses defined activity groups to determine the affected
authorization objects. To simplify the creation of authorization profiles, authorizations generated
for activity groups use data supplied by SAP. Most fields have values.
The Profile Generator identifies the organizational levels that have a role in the extracted
authorization objects, and displays them for the administrator.
In some cases you can insert authorizations, or choose them from templates manually. Therefore,
you need to understand the authorization components in BW.
Page 317

Procedure
Choose Authorizations in the Activity group maintenance screen in transaction PFCG.

Maintain organizational levels.
Edit the authorizations and organizational levels.
Generate the authorization profiles.
A.19.4Create User Master Models for Job Roles

Purpose
The purpose of this task is to develop test user master records for all job descriptions associated
with all business processes. In addition to the assignment of activity groups, user profile data,
such as hold data, set data, user defaults, user parameters, user menus, and start menus must
be defined.
User master records are the model user master records for validating that every job role defined
in a business process fulfills the job functions. Therefore, you do not have to create all named
users at this time.
Procedure
Before testing the generated authorization profiles, you must first create test users for each job
description.
Create a new user master record using transaction SU01. Then assign required activity
groups to this test user based on the information in the enterprise-wide job role matrix.
Update the user master manually to transfer the automatically generated authorization
profiles to the corresponding user master record.
User master data, such as hold data, set data, user defaults, user parameters, user menus,
and start menus must be defined.
A.19.5Test User Masters

Purpose
The purpose of this task is to test user master models. The goal of these tests is for every job
associated with a business process to be performed with maximum data security.
Procedure
In conjunction with application area representatives, perform security unit testing for each
sample user created. The enterprise-wide Job Role Matrix can be the basis for this test plan.
Each Role (activity group and generated authorization profiles) must be tested before you golive.
Test Roles in user training. If a user authorization is missing, your training schedule can be
delayed.
A.19.6Create Authorization Profiles and Job Roles Document

Purpose
Develop detailed authorization profiles and job roles document.
Procedure
Meet with application teams to develop roles and profiles

Sign-off by application teams
Page 318

A.19.7Validate Authorization Concept

Purpose
The purpose of this activity is to create user master records for users, and validate that each user
can perform the required processes, transactions, and reports. This includes identifying activity
groups and profiles for accounts, setting up user master records for validation, verifying
associated business processes for job functions, resolving discrepancies, and refining
authorization design.
Tasks
Identify Activity Groups for Individual Users

Create All User Masters
Validate User Masters for Job Functions
Refine Authorization Design
Approve Authorization Design Documents
A.19.8Identify Activity Groups for Individual Users

Purpose
The purpose of this task is to identify job descriptions and related profiles for each user. A named
user can have several jobs to perform.
Procedure
Work with people responsible for each application area to create a list of users in each
department.
Group employees of the same department into user groups.
Create a list (spreadsheet) of job descriptions, and related activity groups and profiles for
each user.
A.19.9Create All User Masters

Purpose
The purpose of this task is to create user master records based on the job specifications of each
employee. The validated user master models are copied to the end user master records. Assign
users or PD objects to activity groups and update the user master records. Assign additional
authorizations via activity groups for access to general data, and a user address for each user.
The user administrator sets initial passwords, and communicates them to users.
Procedure
When activity groups and authorization profiles are tested in QAS, they are moved to PRD.
Before moving them to PRD, user or project team acceptance is required.
A.19.10
Validate User Masters for Job Function
Purpose
The purpose of this task is for users to perform testing to ensure they can perform necessary
activities and transactions in the system in total security.
Page 319

A.19.11
Refine Authorization Design
Purpose
The purpose of this task to refine user authorizations. Refine user authorizations, for example,
when new employees join the organization, employees change job responsibilities, and so on. Do
this task with the task of validating user masters for job functions.
Page 320

A.19.12
Create Reports
The purpose of this task is to identify and develop company specific or user favorite reports.
Activities
Create Baseline Queries/Reports with Business Explorer Analyzer

Define Enterprise Channel, and User (Enterprise InfoCatalog, User Channel InfoCatalog
Levels)
Organize Query/Reports InfoCatalog for User/Channel
Configure Business Explorer
Assign Authorizations
Test Reports and User Favorites
Variables and Re-usable InfoCube components (restricted/calculated key figures, templates)
A.19.13
Create Baseline Components with Business Explorer Analyzer
Purpose
The purpose of this activity is to create the base line Business Explorer objects for query analysis
and evaluation.
This involves creation of the following components:
Query
Workbook
Structures
Restricted Key Figures
Calculated Key Figures
Variables
A.19.14
Define Company, Channel, and User (Enterprise InfoCatalog,
User Channel InfoCatalog Levels)
Purpose
The purpose of this activity is to provide an organized structure to group query workbooks for
display and management which offers as a framework for authorization to subscribe and publish
reports.
Prerequisites
Assess query subscription and publication strategy document.

Review the security authorization document for query access.
Input
InfoCatalog organization strategy document.

Query Subscription and publication strategy document.
Categorization of query users, by roles and functions.
Result
A directory of hierarchical tree structure to store query workbooks in an organized manner at

enterprise and user grouping levels is established.
Page 321

The Enterprise and User Channel InfoCatalogs are structured.
Tips
The enterprise and user channel InfoCatalog offer great flexibility on how a company may
organize how queries are access and by whom. A well-structured set of InfoCatalogs makes
query distribution and authorization easier. It is worth to invest time up front to determine a
strategy.
Typically, Channel InfoCatalog reflects the roles and functions of the query users.
A.19.15
Organize Reports InfoCatalog for User/Channel
Purpose
The purpose of this activity is to organize the pre-defined queries (reports) into Channel
InfoCatalog and assign users to subscribe to the appropriate Channel or Sub-Channels.
Prerequisites
Upon completion of Enterprise and Channel InfoCatalog structure definition that is specifically
designed for your company.
Input
Pre-defined Enterprise and Channel InfoCatalog directory structure.

Authorized users list by Channels.
Pre-defined queries (reports) in the Enterprise InfoCatalog that are ready to be transferred to
Channel InfoCatalog.
Result
Available queries (reports) are grouped under appropriate Channel InfoCatalog.

Users are assigned to the appropriate Channel InfoCatalog.
A.19.16
Configure Business Explorer Browser Defaults
Purpose
The purpose of this task is to configure the BW Business Explorer browser defaults.
The BW Business Explorer is the OLAP Front-end PC Software component, which allows End
-Users view and analyze decision support data within the BW warehouse.
Prerequisites
Purchase of BW Software
Defined Data Access Paths by User Group and Organization
Result
BW Business Explorer Browser default settings configured for each desktop identified (i.e.,
End-User, Project Team Members).
A.19.17
Assign Authorizations
Purpose
The purpose of this activity is to assign user authorizations for working with queries.
Page 322

Prerequisites
Trigger
Assess the User access authorization documentation
Input
User access authorization document from business requirement perspective.

User profiles for query users established by BW security administrator.
User profiles for working with the InfoCatalog established by BW security administrator.
Result
The appropriate user profile will be assigned to each user id of the BW system.
A.19.18
Test Reports and User Favorites
Purpose
The purpose of this activity is to execute the query from Business Explorer Analyzer and Browser
to insure the delivery of expected results.
Prerequisites
Upon completion of creating query.
Input
Query workbook in the InfoCatalog

Query workbook in the User Favorites
Result
Query display and navigation with slice and dice as well as all other functionality.
Page 323

A.20 System and Integration Testing

Purpose
To verify that the overall system performs as expected and as specified in the design specification
documentation.
Overview
During system testing, the System Test Team combines all parts of the system and exercises
them in varied combinations. These combinations are built through incremental integration of
system components verified through the use of test conditions and System Test Data
Specifications. This approach is used to ensure thorough testing before live production.
The objectives of the System and Integration Testing Phase are to:
Discover and correct errors before implementation;
Document the system test results in accordance with a written System Test Plan;
Verify the program and BW component logic path test results of the unit testing;
Expand on the unit tests by using a combination of unit test data and additional test data
not processed during unit testing;
Exercise all functional processing capabilities defined in the program and BW Component
design specifications;
Identify errors in linked units of a system that exist as a result of the integration of the
units beyond;
Determine if a program, tested as a unit, works effectively as a component of a
progressively larger whole;
Establish the validity of all program-to-program interfaces;
Establish the validity of all sub-system data interfaces by testing user and automated
procedures;
Establish the accuracy and efficiency of any command language sets (e.g., JCL, shell
scripts) associated with all programs;
Test the accuracy of the data entry, transaction processing and run-to-run controls;
Exercise and validate security, back-up, recovery and restart procedures;
Establish the validity of all user procedures;
Confirm the successful processing of business transactions between applications;
Ensure that acceptance criteria are met;
Exercise the system in a high-volume test where the maximum estimated transaction
arrival and data extraction rates are applied in a simulated production environment;
Establish the performance limits of the system; and
Complete initial system tuning to ensure the system operates efficiently.
At the conclusion of the Business Blueprint Stage, the cumulative deliverables form the basis for
developing all of the levels of testing required to prove closure of implemented solutions to stated
needs.
The System Test Strategy should have been prepared by the Business Blueprint Checkpoint
Phase and should address all levels of testing. For the testing activities to run in parallel with the
Construction Phases, the test plans should be used to drive the Realization Stage work plan.
Page 324

System and Integration Testing Task Relationships

S y s te m te s t s tra te g y
P r o g r a m / C o m p o n e n t s p e c ific a t io n s
R e c o v e r/R e s ta rt p ro c e d u re s
T1
P re p a re S y s te m T e s t
S tra te g y
N e w o r u p d a te d S y s te m T e s t S tra te g y
S y s t e m T e s t W o r k P la n
S y s t e m T e s t t e a m r e s p o n s ib ilitie s
C r it ic a l S u c c e s s F a c t o r s
A c c e p ta n c e te s t p la n
H ig h - le v e l a r c h it e c t u r e d ia g r a m
T2
D e v e lo p S y s t e m T e s t
P la n
S y s t e m t e s t o b je c t iv e s
S y s t e m t e s t d a t a s p e c ific a t io n s
S y s t e m t e s t p la n
C r it ic a l S u c c e s s F a c t o r s
A c c e p ta n c e te s t p la n
H ig h - le v e l a r c h it e c t u r e d ia g r a m
T3
C o n d u c t S tru c tu re d
S y s t e m T e s t P la n
S y s t e m T e s t E n v ir o n m e n t
T5
E x e c u te S y s te m T e s t
I n t e g r a t io n te s t p la n
I n t e g r a t io n te s t d a t a
H ig h - v o lu m e t e s t s t r a t e g y
H ig h - v o lu m e t e s t p la n
H ig h - v o lu m e t e s t d a t a
C S F s /P e rfo rm a n c e M e a s u re s
A c c e p ta n c e c r ite r ia
S y s t e m t u n in g a p p r o a c h
T4
P re p a re S y s te m T e s t
E n v iro n m e n t( s )
R e v is e d S y s te m T e s t P la n
R e v is e d S y s te m T e s t W o r k P la n
U p d a te d S y s te m a n d U s e r D o c u m e n ts
S y s te m C h a n g e R e q u e s ts
C o m p le t e S y s te m te s t p la n s
T6
E x e c u te In te g r a tio n
Test
T7
E x e c u te H ig h - V o lu m e
T e s t in g
T8
C o n d u c t S y s te m
T u n in g
Page 325
U p d a te s y s te m t e s t p la n s
O n g o in g s y s te m tu n in g p r o c e s s

A.20.1Prepare System Test Strategy

Purpose
To ensure that a foundation has been developed for system testing that demonstrates that the
system as designed operates successfully, according to the design specifications. This foundation
enables consistent and controlled testing of manageable parts of the system.
Overview
The foundation of the System Test Strategy is built by:
Identifying each functional test area within the system;
Defining test objectives;
Determining the personnel and machine resources required for system testing;
Outlining the System Test Plan; and
Defining the approach to integration and high-volume tests.
The System Test Strategy should have been prepared at the same time as the tasks that were
conducted in the Business Blueprint Checkpoint Phase. If this has taken place, this task is
principally to ensure that the strategy is still current. If not previously developed, a System Test
Strategy should be prepared by following the steps defined below.
In this task, the System Test Team is introduced to the concepts of System Testing through an
orientation meeting. Team members are introduced to each other and a common understanding
of the software testing hierarchy should be discussed, along with the Test Problem Report and
System Change Request procedures to be followed.
A.20.2Define scope of the system test.

Identify the overall set of business events that the system is intended to support and that the
system test is intended to verify. The system test criteria should address the functions and
facilities of the system based upon the Business Blueprint Stage deliverables. The user
acceptance criteria should be reviewed to ensure compatibility and completeness of the system
test in that all of the acceptance criteria are included within the system test and are fully tested.
There should be no surprises in the user acceptance tests.
The system test should include items for:
Demonstrating the system's adherence to the specifications defined during the Business
Blueprint Stage. The processes to be tested include:
processing features,
user interface,
operational data store creation and maintenance,
control features such as security, audit, recovery and reconciliation, and/or
manual procedures,
Set-up and initialization - to test the system's ability to successfully operate on all
components of the production environment configuration;
Restart - to test the system's ability to restart after software failure, including checking for
transaction and database integrity;
Restore - to test the system's ability to be restored to a known state at some previous
time;
Database update - to test the system's ability to successfully update the database(s) online without interruption to other processing; and
Page 326

Security testing - to demonstrate the system's ability to prevent or detect and isolate
improper access and unplanned activity.
Depending upon the project scope, the system testing may also include the testing of disaster
recovery procedures to determine the system's ability to switch-over to a parallel machine or to
execute a recovery after hardware failure, as per the contingency plan. Generally, this is
completed as a separate sub-project by a separate Disaster Contingency Planning project team.
Additional testing may be completed at the system level to address:
Integration testing - to test that business events and their responses can be traced and
reconciled across application boundaries and across technology platforms, from their
initiation into the business until their exit from the business; and
High-volume testing - to test that the system meets the required level of performance with
respect to such items as throughput, delay or simultaneous transactions in a simulated
production environment.
The need for both integration testing and high-volume testing as well as a recommended
approach to executing the tests should be included in the System Test Strategy.
A.20.3Define test objectives.

For each event or set of events, define the test objectives.
The objectives typically relate to the testing as reflected in the design specifications, which in turn
should reflect the system requirements as specified in the functional specifications defined during
the Business Blueprint Stage.
The test objectives serve the following purposes:
They verify that the acceptance criteria will be met by the completed system;
They verify that the complete set of system functions perform as specified;
They verify the accuracy of the system including:
information capture,
editing and validation,
error processing,
information retrieval and reporting,
data conversion and reconciliation,
program interfaces,
external interfaces,
control balancing and reconciliation, and
security, back-up and recovery processing;
They verify the accuracy of the User Procedures; and
They assure any agreed system performance measures with regard to volumes and time
frames (e.g., response times, turnaround times and processing windows).
A.20.4Outline system test work plan.

When creating the system test work plan consider:
All acceptance criteria (user and system test) must be tested in the system test;
Overall implementation strategy with particular attention to the reusability of unit test data;
Required level of effort and staffing based on the number and complexity of processes
and objectives;
Required level of effort and staffing anticipated to investigate and re-test Test Problem
Reports; and
Scheduling of system test tasks, particularly:
Page 327

relationships among test tasks,

program coding schedule,
available personnel (development team and business partners) and machine
resources, and
availability of other application team members.
A.20.5Determine System Test Team members and responsibilities.

Define System Test Team responsibilities to include:
Definition of test conditions;
Test data set preparation and retention;
Test cycle execution and documentation of results;
Verification of system test results;
Error identification;
Control of error correction and program revisions; and
Migration of programs and jobs to and from the system test environment.
Define the training needs for System Test Team members, especially users as it is most important
that the members not only understand how to interact with the system but also what their testing
responsibilities are.
Assess the need for an orientation session to explain the purpose of system testing and the roles
of the individual members of the System Test Team. Prepare appropriate orientation materials to
ensure that responsibilities are clearly understood.
A.20.6Confirm required physical computer resources.

The need for a dedicated system testing environment or environments (e.g., functional testing,
quality assurance, high-volume and stress testing) should have been identified in the Technology
Planning, Support and Cutover Phase. Confirm in this step that all of the necessary work has
been completed and that the specified environments have all been created.
A.20.7Define/select any test tools.

Define and select any test tools that are to be used as part of the system testing process. This
may include tools for test data generation, system performance monitoring or terminal usage
emulation.
A.20.8Prepare System Test Strategy document.

Document the System Test Strategy. Include such items as:
System test approach and rationale;
Summary of test data set generation approach;
System test work plan;
System Test Team members and their responsibilities;
Test objectives for each process; and
Details of the test procedures.
A.20.9Discuss and obtain formal written approval of System Test Strategy

document from the project manager.
Ensure that the System Test Strategy is appropriately focused and addresses all of the necessary
areas.
Obtain formal written approval of the System Test Strategy.
Page 328

A.20.10
Complete the System Test Team training and orientation.
Ensure that all members of the System Test Team have received the orientation materials and
have attended the prerequisite training and that roles and responsibilities are clearly defined.
Page 329

A.20.11
Develop System Test Plan
Purpose
To provide instructions for the execution of system tests, to define the scope of the tests and to
ensure that all required testing will be completed.
Overview
A System Test Plan is created for a comprehensive test of the developed system. Individual test
conditions are developed to satisfy each test objective as specified in the System Test Strategy.
Test steps and associated test data sets are put together and defined as a system. Before
execution, the System Test Plans are reviewed and approved.
A.20.12
Define test objectives and related test conditions.
Each objective encompasses the processing activities within one or more program specifications
that are invoked to execute a system process. The objectives must also include the interfaces to
other automated systems because with some projects there are a large number of these
interfaces to test, each with their own complexity.
For each test objective, define the test conditions that should be tested. When all of an objective's
test conditions are executed properly, the test objective should be satisfied. The types of test
conditions that should be considered include:
Valid data conditions;
Invalid data conditions;
Pathing logic determination conditions;
Exception path execution conditions;
Output conditions;
Control total accumulation conditions;
Program interface conditions;
System interfaces;
System, power and communications failures; and
Back-up or alternate configurations and systems.
A.20.13
Identify system interfaces.
Identify all instances of the systems interface to other systems within its environment. Sources for
identifying external interfaces include:
The Management Overview Diagram (defined in the Process Abstract), the Source
System Abstract and the Data Conversion Abstract indicate the scope of the system and
show the system's boundaries and interactions with other systems;
The intersection of entities used by individual systems data models when overlaid on the
enterprise data model;
The external call sequences documented in the program design specifications; and
The local and remote networks documented in the system distribution strategy.
External interfaces are those instances where the system:
Receives data from another system (e.g., source data systems);
Sends data to another system (e.g., BW); or
Uses shared resources (e.g., network).
Page 330

All interfaces identified must be fully tested in the system and integration testing process,
including multiple cycles, as appropriate.
A.20.14
Define test conditions.
Develop a set of test cases that will execute all of the system's functionality. Test cases should
include conditions such as:
Errors in passed data as a result of residues (e.g., uncleared buffers or registers), file
incompatibility, connection failures, invalid timing and sequencing;
Interface errors as a result of passing corrupt or incorrect data with insufficient tolerance
to receipt of bad data and/or insufficient checks on sent data;
Access and security controls;
Data corruption, destroyed values and residues remaining within a common database as
a result of interface via the database;
Unacceptable levels of performance degradation of any system using shared resources
as a result of resource sharing;
fall back procedures such as the use of magnetic media in place of communications or
dial-up communications lines that typically run at a slower speed than leased lines;
Recovery of data corrupted during transfer or as a result of a system interface;
Recovery of transferred data and re-establishing connections after system failure; and
Re-run of interfaces caused by other system failures.
A.20.15
Define test data sets.
For each test condition, define sets of data required to execute the test conditions. Identify:
Data record(s) and/or screen/window(s) to be constructed to test the condition;
Job(s) (e.g., program processing sequence) and required command language sets;
Key data element value(s); and
Unique sets of data element value(s) that were already defined for unit testing and can be
used again and that include:
ranges below, above and at value limits,
valid or invalid values,
invalid types,
invalid value formats, and
invalid combinations of values.
Where appropriate, multiple test data sets should be defined for each test condition. All processes
need to be tested by the use of "cascades" of test data sets containing at least three transactions
to determine the integrity of program pathing logic setting, e.g., testing for invalid data entry
should include test data sets for different invalid values and for various combinations of invalid
data.
Cycles of test data should be created so that the tests replicate normal use of the system or
logical flows, e.g., master file data can be created, manipulated and deleted in successive test
jobs.
Test data generation tools may also be used in this step to prepare some of the test data set
information.
A.20.16
Define expected results.
Specify the expected status and format of the data, screens/windows and/or reports for every
major automated processing point during the execution of programs for a test condition. For
instance, a test of the interface between two programs should include expected results that show:
Page 331

The status and format of any passed data just before program control transfer by the first
program;
Expected results as determined by the specifications that have been developed during
the phases preceding testing;
The status and format of any passed data upon transfer of program control to the second
program;
Any reports created (error, activity listings or control).
A.20.17
Define test steps.
For each test condition, define the test steps necessary to execute the test condition and verify
the expected results. These test steps become a script for each test condition of the manual test
steps required to execute the program(s) and process the test data set.
The test steps should be defined by referencing the detailed sections of the user procedures
required to execute the test condition and should include (in the appropriate sequence) any test
steps that are specific to the testing (e.g., printing of test data sets for verification, invocation of an
on-line debugger to verify status). The test steps should include:
Input data preparation and entry instructions;
Input balancing procedures;
Expected results verification instructions;
Output selection and verification instructions;
Verification enabling instructions (e.g., setting interest break-points for CICS programs);
and
Output data balancing/reconciliation and report balancing/reconciliation procedures.
Ensure that a final set of conditions are defined with all break-points and other temporary items
removed from the application.
A.20.18
Define test cycles.
Each test cycle is a consecutive set of ordered test conditions and associated test data sets that
will test a logical and complete portion of the system. The test cycles are defined such that
successive test cycles are built by combining the test condition strings of previous test cycles.
By building subsequent test cycles from previous test cycles, each successive test cycle:
Tests a larger or more complex portion of the system;
Allows data processed in one cycle to be input for further processing, e.g., master file
data creation, modification and reporting; and
Creates a discrete unit of work (i.e., inclusion of test conditions from early test cycles into
later test cycles will obviate the need to re-execute the complete test cycles when
problems arise in the later test cycle).
A.20.19
Define the test condition strings for the test cycles.
Identify the number of test cycles required for each major process in the system.
Identify the test conditions and associated test data sets that will be used for each test cycle.
Define the order in which the test conditions will be executed. The sequence of test conditions
within a string should follow a logical progression. When sequencing test condition strings,
consider:
Valid data is the simplest test condition and should be entered first;
Page 332

The complexity of test conditions (e.g., less complex test conditions should go before
more complex test conditions);
Documented procedural flow of work;
Logical processing order (e.g., changes or additions executed after deletions);
Reusability of test data sets such that the successful completion of one string will
properly initialize the database for a subsequent string;
Criticality of functions (e.g., the more critical functions and the more frequently used
functions need to be tested more thoroughly), including fall back procedures, especially
for time critical or operational dependent procedures for a business; and
Association of functions (e.g., for an interface function, it is not necessary to include
conditions that do not affect the transferred data in either of the interfaced processes).
A.20.20
Define test cycles for access and security controls.
Identify the test cycles required to test compliance with the appropriate Access Control Matrices.
Identify the test cycles required to test compliance with all of the defined security controls from
the processing controls and security strategy.
A.20.21
Define test cycles to address the Acceptance Test Plan.
Review the acceptance test plan and confirm that the types of tests included in the Acceptance
Test Plan are also included in a System Test Plan cycle and ensure that the acceptance criteria
can be met.
The acceptance test should be a confidence test for the system users to demonstrate the
effective working of the system. It should not result in Test Problem Reports as any potential
problems should be identified and resolved as part of the System Test.
Page 333

A.20.22
Conduct Structured Walk-through of System Test Plan
Purpose
To ensure that the System Test Plan, when executed, will adequately test the system.
Overview
The structured walk-through process helps to ensure that a complete set of conditions and steps
has been defined.
A.20.23
Conduct structured walk-through of System Test Plan.
Conduct a structured walk-through of the System Test Plan with the System Test Team.
During the walk-through, the System Test Plan is compared to the business events and Business
Scenarios, not to the source code. A correct System Test Plan is one that addresses all the
defined events and scenarios.
A.20.24
Update System Test Plan as needed.
Update the System Test Plan with any additional test conditions and related documentation
identified from the structured walk-through.
Ensure the System Test Plan adequately addresses not only typical business scenarios but also
invalid and atypical scenarios to fully test issues such as:
No records;
System security;
Back-up and recovery;
Contingency planning;
Interfaces;
Performance measures; and
System upgrades.
A.20.25
Obtain approval of System Test Plan.
Discuss the contents of the System Test Plan with the project team, management and the
business users who are part of the System Test Team and obtain formal written approval of the
contents.
A.20.26
Revise system test work plan.
Revise the system test work plan following the structured walk-throughs to reflect any changes
caused through:
The number and complexity of test conditions;
Level of effort required in preparation of test data sets;
The complexity of procedures required to verify expected results; and
The number and complexity of test cycles.
A.20.27
Submit System Test Plan to management and obtain formal
written approval.
Page 334

A.20.28
Prepare System Test Environment(s)
Purpose
To set-up all supporting environments, including data file initialization and job execution streams
in preparation for the execution of the System Test Plans.
Overview
The preparation of the system test environment includes:
The creation of the system test environments (e.g., functional, integration, high-volume
and acceptance test environments);
Loading utility software such as performance monitors or background load simulators;
The initialization of all required test data sets;
The modification of all command language sets (e.g., shell scripts) and utilities such as
copies, back-ups and restores for compatibility with the system test environment; and
Preparation of programs for execution.
A.20.29
Confirm required physical resources.
Confirm that all physical resources identified in the System Test Strategy are available and ready
for use.
A.20.30
Initialize access and security mechanisms.
Define and generate all required sign-on identification codes and security control tables to:
Enable access to the system test environment by system test personnel; and
Prevent access to the system test environment by non-system test personnel.
A.20.31
Initialize master data files.
Where applicable, initialize data files and databases with any control, header and/or trailer
records required. Utility programs may be required for this step. This should be completed after
test conditions that are related to null data sets are executed.
Create input transaction data sets, if any, required for each test cycle.
For batch update processes and on-line processes, prepare and/or generate input transaction
data.
A.20.32
Alter command language sets and utilities as required for the
system test environment.
Alter command language sets and utilities required for the system test environment when it is
unable to achieve a 100% emulation of the production environment.
For instance, for an UNIX environment, test data sets may require different names than the
production data sets and any utilities used in the test streams may need to be set-up differently.
A.20.33
Identify and create required diagnostic command language
steps.
Identify and create required diagnostic command language steps. Command language steps may
need to be added to command language sets to enable the verification of test results. These may
include:
Data file copy/store steps;
Page 335

Data file dump steps;

Data file delete steps; or
System catalogue entry create/delete steps.
Code these steps with comments, merge them into the command language set and review the
set for errors.
A.20.34
Assign distinguishing job IDs to each test.
The IDs should enable precise identification of the results of each test condition, test cycle and
test step execution. Inappropriate identification will result in confusion regarding the source of the
final results and will make verification of expected results difficult, if not impossible. Follow.
installation standards, if applicable.
A.20.35
Prepare programs for execution.
Move the source code modules to program library catalogues controlled by the System Test
Team.
Compile and link all catalogued modules according to instructions provided at hand over.
Complete all program migration or movement instructions signifying that programs are ready to
be tested.
Move all data necessary to conduct the test to the test execution catalogue including command
languages, copybooks and utilities.
A.20.36
Confirm from the work plan and the check lists that all items
have been completed.
Page 336

A.20.37
Execute System Test
Purpose
To test the functionality of the developed system according to the designed System Test Plan.
Overview
All test cycles are executed until successfully completed.
Successful completion is annotated on the hard copy output of the test. System test results are
reconciled with expected results and all errors are documented and corrected. Final system test
results are cross-referenced by page and/or line number to the appropriate System Test Plan
step.
Successfully executed System Test Plans are reviewed before acceptance testing.
The Test Problem Report and System Change Request processes are used throughout the
system test.
A.20.38
Execute and log test cycles.
Execute the test cycles by following the test steps associated with each test condition in the
cycle's test condition string. The logging of each test cycle should include the recording of:
Execution or submission date and time;
System test results; and
Final test cycle sign-off.
User personnel should be heavily involved in the execution of the test cycles. This will serve as
preliminary verification of the effectiveness of the user procedures, provide input to the training
needs analysis and should prepare the user for implementation and system acceptance.
A.20.39
Reconcile execution results with expected results.
At each processing point in the System Test Plan for which expected results have been specified,
the tester should visually compare all parts of the system test results with the expected results or
through the use of file compare utilities. A hard copy of the system test results should be
produced and attached to the expected results.
The person verifying the system test results should initial the system test log as evidence of
completing the review and should cross-reference on the log the filing location of the system test
results.
A.20.40
Document and log all errors.
Document any discrepancies between the system test results and the expected results and
highlight them on the hard copy of the system test results. Attach any comments that may be
helpful in identifying the cause of the discrepancy.
The error documentation should then be passed to the appropriate personnel for error correction.
The System Test Team leader should determine if the execution of the test is to be suspended
because of the encountered errors. Errors that are of sufficient magnitude will affect all
subsequent test steps, so continuing the system testing in such an instance may be meaningless.
Page 337

A.20.41
Correct errors and log error corrections.
Correct errors and log error corrections. Include a description of the resolution, identification of
the error correction and date of correction.
The corrected program(s) should then follow the defined procedures for re-submission to system
testing including notifying the System Test Team when the correction has been completed and
notifying the documentation team of the program change(s). Depending on the type of error,
regression testing may be necessary to verify that the fix to the problem has not adversely
affected other successfully tested components of the system.
A.20.42
Modify system documentation as required and log changes.
Modify system documentation as required and log changes.

Throughout the system testing process, it may be necessary to modify system documentation,
user procedures and/or program documentation due to:
Design specification changes identified in the error correction process; and
Documentation deficiencies/inconsistencies highlighted by exercising the user procedures.
Document all system changes on a System Change Request. All user documentation changes
should follow the change procedures defined during the User Documentation Phase.
A.20.43
File all system test results for completed test cycles.
Annotate all of the documentation associated with the completed and approved test cycles and
file as part of the system test documentation.
This should include the System Test Plan, system test results, any error corrections and system
test logs.
A.20.44
Submit system test results to management and obtain formal
written approval.
Page 338

A.20.45
Execute Integration Test
Purpose
To ensure the delivery of complete DW system functionality and system performance, across
application boundaries and across technology platforms.
Overview
Integration testing will:
Test that business events supported by multiple applications adhere to the performance
criteria and functional specifications agreed with the business users;
Ensure external interfaces of the DW system have been adequately tested; and
Ensure the co-existence of applications as they work in conjunction with each other does
not have adverse effects upon the operating environment.
Integration testing focuses on testing the "full life cycle" business event and verifies an event
through its entire life cycle, from its initiation through to the termination of that event across all
systems affected by it.
The System Test Team must conduct an integration test that provides a level of assurance that
the systems implemented are reliable and meet business requirements without excessive
preparation and testing of functions that have not changed.
The integration test focuses on those actions that minimize exposure to failure, minimize cost and
maximize coverage of business requirements and conditions through testing:
All processes that have been modified or created as new across application boundaries
(including data conversion for each application). e.g., for a new general ledger
implementation, testing that a journal entry is created in the source system, added to a
sub-ledger that creates a journal entry to the corporate general ledger, that adds the
journal entry and outputs an extract file to a financial data warehouse);
All system procedures and reconciliation processes related to the conditions being
tested;
Control balance processing (control totals between applications) to ensure processing
through existing application systems is accurate and meets functional requirements
defined by the business;
By use of a standard "base case" of test data and conditions to allow each application
system to ensure the application accurately processes data; and
Any transaction that crosses three or more application boundaries. Transactions crossing
less than three application boundaries may still be tested during integration testing if
considered necessary to mitigate an unacceptable level of risk.
The integration test work plans contain contingency to allow for problem resolution, unplanned
conditions and technical breakdowns. However, integration test will not test processing within an
application system that has not been modified as a result of the application development effort.
Integration testing will also not be a complete re-execution of the application system test.
A.20.46
Prepare integration test strategy.
Prepare an integration test strategy to ensure that the delivery of complete business functionality
can be achieved. The integration test strategy structures and formalizes the approach to
conducting the integration test activities.
Prepare a brief strategy document containing the following sections:
Page 339

Purpose;
Scope and approach;
Timing;
Team roles and responsibilities;
Planning technique;
Execution technique;
Key assumptions;
Risk assessment; and
Data generation.
The integration tests must also address test conformance to standards. Interface standards must
exist for transfer of information between systems. Each external interface must follow established
standards. Review the interfaces identified in the System Test and reject any programs that do
not follow documented standards. Standards should exist for explicit interfaces and interfaces
implicit in the database.
A.20.47
Develop integration test plan.
Develop integration test plans. The integration test plan is at a higher functional level than a
system test plan.
Condition coverage includes both valid and invalid cases. Conditions focus on the business event
being performed, often involving multiple types of data at a time.
Each test step walks-through the execution and checkout process for each individual application
system involved with a business event. Create expected results for each test step, documenting
the outputs of each test step at an integration level (i.e., expected results should not duplicate the
system test results but should focus on results that demonstrate successful/unsuccessful
integration of applications and/or systems).
Utilize user management as the key resources for the planning activities and validate the
integration test plans by conducting structured walk-throughs including sign-offs with the
appropriate user management and project management from the application teams.
A.20.48
Develop integration test work plan.
Create a schedule to address the appropriate sequencing of the integration tests contained in the
integration test plan and document in an integration test work plan.
When creating the integration test work plan consider:
The scope and approach and timing sections of the integration test strategy, to identify
potential timing constraints and/or windows of opportunity for conducting the tests;
Sequencing of and dependencies between integration tests;
Resource availability for both conducting the tests and researching and correcting Test
Problem Reports; and
The impact of the tests on other systems.
A.20.49
Develop integration test data.
Data is required to be generated, allowing specific conditions to be confirmed and that can be
used to conduct high-volume testing of the applications.
Generate test data for the integration tests. Production data can also be converted for this same
purpose. Each set of test data will contain both valid and invalid test data.
Page 340

The integration test will ultimately utilize production data to exercise the integration test. The data
will be formulated in the "originating system" and sent via interfaces to each of the target
applications. Testing will be conducted in test cycles defined to test specific business functionality.
Test cycles primarily involve three categories of test data - base case, low-volume and highvolume data. Each category of data must be able to be successfully processed for each event
before the next category of data may be processed. As a new category is processed, the prior
categories are also executed in combination with the new category to build up a progressively
larger test data set.
A.20.50
Establish technical environment.
Confirm that the appropriate test environment has been created as part of the Technology
Planning, Support and Cutover Phase.
Integration tests should be conducted in a technical environment that mirrors the production
environment. Using a production grade environment allows the technical performance of the
integrated system to be monitored and tuned, as necessary, to meet the system's performance
and cost requirements. Representative operating cost estimates can be derived from the highvolume integration test runs.
Key interface systems that currently exist in production may not have a test environment available
for use. Identify these applications as soon as possible and make arrangements for environments
to be made available or additionally recognize opportunities to satisfy the integration testing
needs.
A.20.51
Execute integration test.
Complete the integration test. The execution of the integration test requires a coordinated effort
between the application teams. Experience has shown that the use of a common work area for
the Test Team is essential for effective communications.
Each application team is responsible for performing the necessary "due diligence" to ensure the
accuracy of their application as it processes integration data.
Confirmation of the test execution includes ensuring that:
The data that was processed can be viewed and manipulated successfully using on-line
screens/windows;
The data can be successfully processed by subsequent batch programs; and
The data is able to be printed via existing report programs.
Use a three step process (base case data, then low-volume data followed by high-volume data)
to qualify the applications being tested. Each application must verify control balances before
initiating the next application's processing. Otherwise, all the teams waste time processing
incomplete or erroneous data.
The results of the execution should be documented by each application team in the same way
system test documentation is completed.
The successful execution of an integration test includes:
Coordination of back-ups and data synchronization points to ensure that all databases
are the current version. Strict program version control and change management must be
in effect;
Page 341

Execute in test cycles starting with base case data. The base case data will be used
repeatedly until it successfully completes processing for all applications. All anticipated
business functionality must be included in the base case data set. At the end of base
case data testing, the focus turns from one of functional verification to one of application
integration;
If errors or program problems are identified, the integration test activities in this area
cease until the program is repaired, unit tested and system tested. Any problems are the
responsibility of the System Test Team to resolve and migrate the corrected program;
Once application functionality is stabilized (the base case data successfully executes),
execute low-volume data test cycles including base case data. Now that functional
capacity is established, begin growing the amount of records and throughput processed
by the applications. Iterations of this test cycle are executed until processing successfully
completes for all application systems. The System Test Team must have confidence that
the applications are functionally stable and have the operational capacity to process highvolumes of data successfully; and
Execute high-volume test cycles including the base case and low-volume test data.
Volumes executed should be greater than the expected production work load. Recognize
that additional time will be spent completing execution, back-ups, restores and other
load-impacted tasks. Complete performance tuning and re-execute the test cycles until
satisfactory performance is delivered by the application systems. The project teams can
derive representative operating cost estimates from the high-volume integration test runs.
A.20.52
Document test results.
Document each test when executed so that the test results can be verified and duplicated.
Documentation should include:
Execution date and time;
System conditions at the time of testing;
The test case executed and the data used; and
Test results (e.g., output generated, data passed/received, errors logged, database
updates).
A.20.53
Document and resolve errors and issues.
Where errors are identified in the integration tested programs, these errors are documented and
returned with the test log to the project manager for implementation of debugging procedures.
Errors that require changes to the original specification or design should proceed through the
issue resolution process.
All of the documentation associated with the completed and approved test cycle is annotated and
filed as part of the integration test documentation. This should include the Test Plan, test results,
any error corrections and test logs.
A.20.54
Submit system test results to management and obtain formal
written approval.
Page 342

A.20.55
Execute High-Volume Testing
Purpose
To confirm that the system operates within acceptable performance guidelines, when processing
the agreed upper limit loadings in a production or simulated production environment.
Overview
High-volume testing confirms that the system meets the required level of performance with
respect to throughput, delay and simultaneous transaction processing while operating at the
planned maximum load in a production environment.
Scripts are defined to outline how the tests will be conducted and to cross-reference the expected
results. After execution of the high-volume tests, the results are analyzed and the system tuned
as needed.
Note: High-volume tests should be run in a production environment with other systems running or
simulated to provide an operational load on the machine and network environments.
A.20.56
Define test cycles that establish system performance
boundaries.
This step requires that concurrent execution of similar and dissimilar programs be planned. The
intent is to incrementally increase the load on the system and by so doing establish the point at
which it fails to complete processing within the desired response/turnaround time. Sensitivity
analysis of these results is used to identify which transactions or combination of transactions
affect the system performance most.
When planning high-volume tests and high-volume test cycles, take into consideration:
High-volume tests are not often concerned with the correctness of process, i.e., expected
results are often physical and not logical. Also, high-volume test cycles may not follow a
specific transaction all of the way through its life cycle if the transaction is only of interest
to the high-volume test at certain points;
As high-volume tests are particularly interested in CPU and network loading, control over
other concurrent use of the system is important. High-volume tests are often conducted
at the same time as data conversion and the competition for system resources should be
planned for; and
High-volume tests can result in as many database changes as program logic changes. All
data model documentation must be updated with these changes.
A.20.57
Identify transaction mix for high-volume testing.
The high-volume test process ensures programs and components operate effectively under
greater than normal volume levels. Testing using high-volumes of records also reveals program
inefficiencies and tuning opportunities that may be leveraged to increase performance.
Determine which system components should be high-volume tested. Identify such items as:
Key business functionality;
Specific types of reporting or retrieval/scanning of data for reporting;
All interface points to or from external systems;
Internal system linkages between sub-systems;
Inquiries that must process a large input or scan large amounts of data;
Processing complexity that causes slow response times; and
Page 343

Transactions having high risk attributes.
The identified transactions should represent the majority the BW system, including extract and
transformation jobs. Review the list with project management and the construction managers for
accuracy and completeness.
A.20.58
Determine target volumes for high-volume tests.
Determine the expected production volumes for each group of items identified. Consider:
Month-end, period-end and year-end;
Seasonality, holidays or other volume-changing variables;
Daily use curves (e.g., does the majority of activity occur in the morning or in two hours in
the afternoon);
Load variability, is the volume of records processed dynamic (increase/decrease over
time) or static (remains constant over time)
Process results in inserts, updates or deletes of records; and
Expected record retention levels.
Once peak volume levels have been defined for each item to be tested, assess the load
variability.
If the load is static, increase the peak number by 20% (e.g., if the volume for a program is always
10,000 records, test the program with 12,000 records). The static load test confirms the program
can perform at expected production levels as long as the load is static.
Programs with dynamic loads incur greater risk of failure and therefore must be tested with higher
volume levels than the expected production loads. If the load is dynamic, multiply the peak
volume number times three (e.g., if the volume for a program can be up to 10,000 records, test
the program with 30,000 records).
A.20.59
Define and build high-volume test data for high-volume tests.
Batch high-volume testing uses a variety of methods for synthesizing test data.
The primary purpose of the test data is to provide a mechanism for verifying that the program will
perform to expectations during production level (or greater) volume loads. Test data for a program
should exercise a proportionate subset of the overall functionality. Create an initial subset of data
(10 to 30 records) that reflects a majority of system functions, containing both valid and invalid
conditions, that is replicated to the target transaction volume.
System test data may be used to provide the initial "base" of data. Replication or cloning methods
for the data may employ a variety of techniques to create test data including manual input,
keystroke macros, utility jobs, special tools, conversion programs, actual production data or
special programs built to create data. Where possible, chaining the output from one process to
another provides the most effective test.
The overhead of synchronizing the efforts of two processes is generally worth the investment.
A.20.60
Execute high-volume test.
Before executing the high-volume test, ensure appropriate coordination has occurred with the IT
technical support organization. Performance measurement tools and expected measured outputs
should be identified before the test is conducted. Usually a two month lead time is recommended
for beginning and conducting a dialogue with the technical organization to enable the most
effective use of the test execution time.
Page 344

Benchmarking information for similar systems can be prepared at the site that assists in
recognizing acceptable performance of the tested system. System processing statistics,
transaction rates and throughput levels of existing systems help refine expectations by
demonstrating the new system is within "normal" performance ranges.
If possible, the testing should be incremental, building up to the highest load level. Iterations of
each load level are run until acceptable performance is demonstrated. Coordination with the IT
technical support staff facilitates thorough measurement and helps to identify tuning opportunities
during the test periods. Testing must often be scheduled during off-peak hours. Failures and
tuning opportunities are captured on TPR forms and are logged and tracked in the same fashion
as other program problems.
Once a program or report is run, the performance results are analyzed and tuning measures are
identified. Expect multiple runs and tuning opportunities of each load until the results are
favorable. Increasing space allocations and memory work sizes often provides favorable
performance adjustments to the jobs.
A sample execution process may be as follows:
Prepare input (25% of maximum volume level);
Take a full back-up of the system (or affected databases/files/tables) if the test will modify
data;
Execute program job stream;
Evaluate results, if satisfied take a back-up (if required) and continue to next volume
level, else apply tuning measures or program fixes, restore to prior back-up if required
and re-execute test until successful completion;
Add next increment of volume (50% of maximum volume level) and execute the test
steps above;
Engage the system monitoring tools (for preliminary measurements);
Add final increment of volume (100% of maximum volume level);
Engage the system monitoring tools (for final measurements);
Execute the test steps above;
Complete final performance tuning measures; and
Confirm (or develop) operating cost estimates based on actual performance data.
Once a script is run, the performance results are analyzed and tuning measures are identified.
Expect multiple runs and tuning opportunities of each load until the results are favorable.
System tuning often requires resetting machine parameters that can not be completed "on-the-fly"
and must be reset at a later date.
A.20.61
Submit high-volume test results to management and obtain
formal written agreement.
Page 345

A.20.62
Conduct System Tuning
Purpose
To ensure that the system that has been constructed operates efficiently on the target hardware
and software platforms.
Overview
The new system once installed and tested, may need to be tuned to ensure that the system runs
at an agreed level of performance. Optimum performance can often only be achieved once the
system has been built and has been tested in the production system environment.
This task may only be partially completed before live processing commences. The steps defined
should also be included as part of ongoing system maintenance.
Note: This area is highly technical in that it requires deep expertise in all of the different components of
the BW environment to complete the system tuning. The steps in this task are thus only an indicative
outline of the work to be completed and will need to be supplemented with the detailed tasks and steps
required for each environment.
A.20.63
Review any performance-related criteria.
Identify if any performance-related criteria have been specified in the following documents:
CSFs/Events list;
Contract;
Agreed system acceptance criteria; or
System Test Strategy.
A.20.64
Review test performance results.
Review the results of the system, integration and high-volume tests against the expected
performance levels and identify any performance levels not achieved.
A.20.65
Identify environmental tuning options.
Determine the possibility of tuning the system to address the problems. In the operations area,
consider alternatives such as:
Hardware upgrades (e.g., more processing power, more memory, more disk drives, more
communications bandwidth, etc.);
Software upgrades (e.g., different or additional utilities such as for sorts or back-ups);
Operational tuning (e.g., revision of job schedules to reduce the possibility of system
response degradation due to competition for resources with other systems, improved job
submission systems);
Network configuration tuning (e.g., upgrades to communications protocols, faster line
speeds, front-end processor upgrades, reduced encryption and increased compression);
and
General tuning (e.g., use of disk caching or other technologies, file placement, moving
critical programs directly into resident memory).
Page 346

A.20.66
Identify application tuning options.
Determine the prospect of re-designing the programs to improve the performance of the system
for critical transactions. Program requirements tend to change more readily than data structures,
so modifying the programs to improve performance may provide long-term benefits.
Identify any changes in the daily, weekly or period-end processing streams which may improve
overall performance or capacity utilization.
A.20.67
Identify database tuning options.
Determine the potential for tuning and denormalizing the database(s). Consider that modifying the
database to improve program performance may only provide short-term benefits and in the longer
term only complicate the maintenance of the system. Options include:
Tune for non-index accesses;
Validate clustering and sequences;
Add indices; and
Allow redundant data.
A.20.68
Complete system tuning and re-test.
Create a record to define the performance level of the system before any tuning.
Identify, from the system tuning plan, tuning that may potentially improve the performance of the
software and therefore lead to improvements in the overall system performance.
Conduct the appropriate system tuning techniques and compare the performance results with
those already obtained. Compare the test performance results with the required results and if the
results are still unsatisfactory continue with system tuning. Decide if the results are significant
enough to warrant making the change permanent and, if so, update all relevant documentation to
reflect the change.
Repeat any of the system tests considered appropriate to ensure that making changes in one part
of the system does not have an adverse effect in other areas.
A.20.69
Update system documentation.
Ensure that any changes made to data models, networks or other items as part of the system
tuning process, are reflected in the maintained system documentation and operations
instructions.
A.20.70
Establish ongoing system tuning process.
Ensure that the responsibilities for all areas of systems performance are clearly defined.
Ensure that performance and capacity measurement data is collected and regularly reviewed.
Ensure that housekeeping routines are included as part of the operations instructions to maintain
performance levels, e.g., regular running of database file reorganization utilities.
Page 347

A.21 Realization Checkpoint

Purpose
To confirm the results of the Realization Stage of the BW project with management.
Overview
Reviews.
However, at specific points in the life cycle, additional tasks will have to be completed. One of
these points is the completion of the Realization Stage and these additional tasks are described
in the Construction Checkpoint Phase.
assessment needs to be reviewed to reflect changed risks in construction, the baseline for the
project will change from the Realization Stage to the Implementation Stage deliverables and
estimates should be reviewed to reflect this. There is likely to be a change in scope and to the
contractual conditions regarding deliverables and sign-off.
Page 348

Realization Checkpoint Task Relationships

S y s te m t e s t w o r k p la n
I n t e g r a t io n t e s t w o r k p la n
U s e r d o c u m e n ta tio n
T r a in in g m a t e r ia ls a n d a p p r o a c h
T r a n s it io n s u p p o r t a n d m ig r a tio n d e liv e r a b le
A c c e p ta n c e t e s t d o c u m e n t a t o in
U1
C o n f ir m C o m p le te n e s s
o f t h e R e a liz a t o in
S ta g e
C o n f ir m e d R e a liz a t io n S t a g e D e liv e r a b le s
O p e n Is s u e s
U2
U3
Q u a lit y P la n
U4
U5
O b ta in A p p r o v a l o f
R e a liz a t io n S ta g e
D e liv e r a b le s
R e a liz a t io n S t a g e D e liv e r a b le s
Page 349
Is s u e r e s o lu t io n s

A.21.1Confirm Completeness of the Realization Stage

Purpose
To complete an integrity check of the Realization Stage deliverables.
Overview
Throughout the project, progress against work plans is monitored continually. At the checkpoint,
the full completion of all planned work in the parallel phases needs to be checked (e.g., CrossLife Cycle Phases). It is essential that all work has been completed or is included in the work
plans for the forthcoming Implementation Stage.
The end of construction is quite often not clear-cut. Frequently, there will be overlaps between
construction and implementation because of phasing, because an overlap can ease smoothing of
staffing levels or because time constraints make it impossible to complete construction before
starting implementation. It is important to recognize the unique nature of each project and ensure
that all tasks will be completed in sufficient time to enable all pieces of the work to come together
at implementation.
The appropriate approval authority for each of the deliverables discussed below should have
been identified in the Project Charter.
A.21.2Check completeness of all Program Control Checklists.

In design, Program Control Checklists were prepared for each identified program within the
proposed system.
Prepare a list of all programs from design and ensure that checklists for each program were
prepared. This list is prepared from the design document and should be updated throughout the
Realization Stage to reflect changes in program boundaries or specifications as they occur.
Ensure that this list is complete. Any discrepancies should be addressed immediately and
appropriate action taken.
A.21.3Check completion of the system test work plan.

Check that the work plan prepared for system testing has been completed which should include a
review of the TPR log.
Ensure that all TPRs raised have been completed or that appropriate action is being taken to
complete resolution in sufficient time. This may include the delay of certain functionality in a
subsequent phase, subject to approval. In this event, make certain that any stub programs used
for testing around missing functionality are available for integration testing and communicate this
accordingly.
Any discrepancies should be addressed immediately and appropriate action taken.
A.21.4Check completion of the integration test work plan.

Check that the work plan prepared for integration testing has been completed which should
include a review of the TPR log.
Ensure all TPRs raised have been completed or that appropriate action is being taken to
complete resolution in sufficient time. This may include the delay of certain functionality in a
subsequent phase, subject to approval.
Page 350

Any discrepancies should be addressed immediately and appropriate action taken.
A.21.5Confirm formal written sign-off on system test results.

Check that the system test conditions and results have been reviewed and formal written
approval has been obtained.
Ensure that any outstanding TPRs are addressed and any related issues have an appropriate
resolution or action accordingly.
A.21.6Confirm formal written sign-off on integration test results.

Check that the integration test conditions and results have been reviewed and formal written
approval obtained.
Ensure that any outstanding TPRs are addressed and any related issues have an appropriate
resolution or action accordingly.
A.21.7Confirm formal written sign-off on the user documentation.

All User Documentation tasks should be completed and should have been subject to system
testing. Check that the documentation has been properly completed and formal written approval
has been obtained. If there are any discrepancies, issues should be raised accordingly.
Deliverables include:
User documentation standards;
Documentation (on-line and non-automated);
Supplementary documentation; and
Documentation distribution list.
A.21.8Confirm formal written sign-off on training materials.

Training materials have been produced during a parallel phase and should be complete. Check
this is so and that formal written approval has been obtained.
If there are any materials yet to be developed, the impact should be assessed and any issues
raised.
Training scope and strategy;
Training course plan and schedule;
Training materials;
Instructor materials; and
Training course maintenance plan.
At this point in the project, the only remaining task in the Training Phase yet to be completed
should be Conduct Training Session(s). Ensure that the effort involved in conducting the training
session(s) is addressed in the Implementation Stage Work Plan.
A.21.9Confirm formal written sign-off on data conversion programs and

manual procedures.
Data conversion programs and procedures have been produced and should be complete. Check
that these have been completed and that formal written approval has been obtained.
Page 351

If any of these programs and procedures have yet to be developed or finalized, the impact should
be addressed and an issue raised.
Data conversion strategy;
Data conversion requirements;
Data conversion plan;
Data conversion system design;
Data conversion programs and procedures;
Data cleansing programs and procedures; and
Data conversion reconciliation procedures.
Ensure that tasks are included in the Implementation Stage Work Plan to address the final
execution of the data conversion programs.
A.21.10
Check progress of any data conversion already undertaken.
Data conversion may already have been started at this point. e.g., data cleansing and purging
may have commenced or external information may already have been obtained. Check that any
data conversion tasks that were planned for completion by this point have been completed. If
there are any discrepancies, assess the impact on the overall data conversion estimates and
schedule.
Converted data;
Created data;
Purged data;
Reconciliation results; and
Approach used and program documentation for any clean-up, creation or conversion
programs.
A.21.11
Confirm formal written sign-off on transition support and
migration deliverables.
Examine the Project Charter and the work plan for transition support and migration for a definition
of the deliverables to be produced and the appropriate approval authority. Check these
deliverables have been completed and that formal written approval has been obtained.
Confirm that all tasks in the Technology Planning, Support and Cutover Phase related to the
implementation of the production technology environment have been completed and ensure that
the final Task M5 - Support Technology Environments is included in the Implementation Stage
Work Plan.
The impact of any discrepancies should be assessed and appropriate issues raised.
A.21.12
Check formal written sign-off on user acceptance test.
User acceptance testing is primarily a client responsibility. Within the methodology, formal
acceptance testing takes place during the Implementation Stage. At the Construction Checkpoint
Phase, the user acceptance test plans are checked for completeness against the defined
acceptance criteria to ensure that the testing includes all of the acceptance criteria.
If there are any discrepancies, issues should be raised and action taken accordingly.
Page 352

A.21.13
Check progress of any acceptance test work already
undertaken.
In certain projects, acceptance testing, although formally scheduled for completion during
implementation, may be started during the Realization Stage. Although formal completion is not
expected until later, progress should be checked at this time as any problems with acceptance
testing may have an impact on the overall schedule and issues should be addressed as early as
possible.
Some of the acceptance tests may take place in an environment other than the planned
production environment. e.g., it may be necessary to establish a controlled network with a limited
number of machines of specified power to undertake some of these performance tests. The
Methodology assumes acceptance testing is performed in implementation in the full production
environment. If this is not the case, ensure that this environment is checked at the appropriate
point.
Raise any issues as appropriate and take corresponding action.
Page 353

A.21.14
Review Issues
Purpose
Overview
A.21.15
Review and resolve any outstanding issues.
Ideally, no issues should remain outstanding at the end of the Realization Stage. In practice, not
all issues will need to be fully resolved before progressing to the Realization Stage. The decision
on the importance of resolving an issue should be made by the project manager in conjunction
with senior management.
next stage.
A.21.16
Agree approach to outstanding issues.
Page 354

A.21.17
Update Project Plans
Purpose
To review the approach for the implementation of the system and to confirm the approach for the
warranty and maintenance period.
Overview
At the Business Blueprint Checkpoint, an approach for the Construction and Implementation
Stages was developed and an approach to the ongoing support of the implemented system was
prepared.
The estimates for the remainder of the project are reviewed using the actual results from
construction, together with any implementation and parallel phase work already completed.
Fully detailed work plans are produced which address the overall project and resources available.
Full costs and time estimates are derived.
Both the detailed implementation plans and the approach to warranty and maintenance are
reviewed including the impact of any ongoing parallel phases. These changes are then reflected
in the overall work plan.
A.21.18
Review implementation plans in relation to progress to date.
At the end of design, an implementation plan was developed. This should be reviewed at the
completion of the Realization Stage and adjusted accordingly. Considerations include:
Changes to sub-system boundaries made during construction;
Changes to implementation mechanisms made during construction;
Work brought forward or postponed to earlier/later phases;
Changes in internal or external dependencies;
Staffing requirements and availability; and
Changes in milestones or financial constraints.
Revise the implementation plan accordingly.
A.21.19
Validate decisions based on sequencing of deliverables with
other Realization Stage deliverables.
Review complementary Realization Stage plans for other items from the Cross-Life Cycle Phases
which may still be in progress including:
User Documentation;
Training; and
Acceptance Testing.
Consider the impact of these plans on the approaches envisioned for implementation and
ongoing support. Correct any inconsistencies by revising the appropriate plans.
A.21.20
Consolidate plans into the project work plan.
Ensure that all plans are included in the project work plan which combines all tasks,
dependencies and milestones for the remaining stage of the project.
Page 355

A.21.21
Revise estimates in light of previous experience.
Estimates for implementation were made in the Business Blueprint Checkpoint Phase based on
the best knowledge at that time. Experience gained during the Realization Stage may indicate
variances from these original estimates and the implementation estimates should be revised
accordingly.
Many of the parallel phase activities should be almost complete and should provide information
about appropriate estimates for the remainder of this work. Estimates should be revised
accordingly.
A.21.22
Produce detailed work plans for the Final Preparation Stage
and Go Live and Support Stage.
Based on the project work plan and the revised estimates, develop detailed work plans for the
remaining work to be undertaken to complete the system implementation and to support the
system.
Reflect any changes to the overall work plan necessitated by resource or other constraints.
A.21.23
Validate overall project cost and time estimate.
Develop final cost and timing plans for implementation and support. Compare these with the
originally agreed figures. Review any discrepancies and take appropriate action including:
Re-phasing of the implementation to ensure that time scales are met;
Agreeing a revised cost for the project;
Formal written approval should be sought for any actions to be taken and plans revised
accordingly.
Page 356

A.21.24
Update Project Charter
Purpose
Overview
To this point, the Construction Checkpoint Phase has largely been concerned with work planning.
Many issues are addressed in the Project Charter that go hand-in-hand with the work plans.
These are reviewed and appropriate amendments made to reflect the end of this stage and the
start of the next.
Those sections of the Project Charter that need to be updated for Construction are reviewed and
revisited.
A.21.25
Review and revise Project Risk Assessment.
Review the risk assessment as a result of the Realization Stage experience and the updated
project plans for the Final Preparation Stage. Consider:
before?
assumptions?
project?
A.21.26
Review project risk dimensions.
Identify where the risk ratings described in the risk assessment are higher than expected or are
greater than originally. Obtain agreement with management on the appropriate actions to take.
A.21.27
Revise risk management approach.
For identified threats, document:

Page 357


A.21.28
Revise the Project Charter.
they primarily affect the Implementation Stage. Ensure that all these areas have been properly
addressed before progressing to the Implementation Stage.
A.21.29
Seek independent approval for the revised Project Charter.
Approval for the revised Project Charter should be sought and the plan should be reviewed for
completeness and correctness including:
Any issues should be discussed between project management and the independent
assessor;
Corrective actions to be taken should be agreed by all parties and documented. Such
actions should have clear time scales and responsibilities assigned; and
Further reviews should be scheduled to ensure corrective action is undertaken.
Page 358

A.21.30
Obtain Approval of Realization Stage Deliverables
Purpose
To seek final review and formal written approval of the Realization Stage deliverables.
Overview
Throughout the Realization Stage, formal written approval should be sought for deliverables on
an ongoing basis. At the close of this stage, a final review of deliverables is undertaken and
formal written approval obtained for all of the Realization Stage deliverables.
A.21.31
Submit and discuss Realization Stage deliverables.
Discuss the Realization Stage deliverables with management and resolve any questions and
issues.
and the project contract.
issues.
A.21.32
Obtain formal written approval of the Realization Stage
deliverables.
Obtain formal written approval of the Realization Stage deliverables as defined in the Project
Charter and the project contract.
Page 359

Final Preparation Stage

During the Final Preparation Stage, the composite parts of the project are brought together and
assembled into a working system. While there will have been points during the development
when work products from different phases have been cross-checked, this is the first time that all
of the work deliverables are combined and tested as a whole.
The purpose of this stage is to complete the final preparation, including QA testing, user training,
system management and cut over activities, to finalize your readiness to go live. This final
preparation phase also serves to resolve all crucial open issues.
Key Deliverables:
1) Jobstream documentation for monitoring of scheduled jobs and eventual turnover to Internal
Process Coordination team
a) InfoPackage
b) Event Chain processing
c) Other batch jobs
2) Training
3) Acceptance Test Sign-off
System Implementation
This phase controls the final aspects of the project using the Implementation Plan and the Project
Charter to validate that tasks have been completed and that responsibilities have been assigned
for the transition into the production environment and for ongoing maintenance of the system. The
Implementation Plan should take into consideration:
Implementation approach (i.e., direct, parallel, phased and/or staged). The most effective
and practical approach should have been determined by considering factors such as the
degree of system complexity, magnitude of organizational change, technical
sophistication of the users, geographic dispersion of user sites, timing constraints such
as year-end closing or volumes of data;
Implementation schedule, which gives priority to the critical path activities of the
implementation in addition to the standard tasks included on the Final Preparation Stage
work plan;
Conversion efforts to finalize the creation of the data needed to commence use of the
system including the balancing of the source system with BW and formal approval of the
conversion results. These efforts will vary in complexity in step with the selected
implementation approach and also apply to the efforts needed to put into place the
system for the continual refreshing and management of the data in the warehouse; and
The Project Charter should consider roles and responsibilities for the conduct of the Final
Preparation Stage work plan activities and any ongoing tasks needed to support the
application.
In addition to validating that all of the earlier work has been completed, specific tasks establish
the production environment to facilitate the transition from the development or test environments
to operational use and to obtain final sign-off on the project.
Although there is only one phase shown in the Final Preparation Stage, it is at this point in the
project that all of the Cross-Life Cycle Phases are finalized and the deliverables from these
phases need to be accommodated as part of the final implementation activities.
Page 360

The Cross-Life Cycle Phases, that are completed in the Final Preparation Stage include:
Change Integration (completion of all organizational changes and facilities planning and
changes);
Prototyping;
User Documentation (hand over of manual procedures/on-line document sub-systems);
Training (execution of the training and hand over of training plan and training course
materials for ongoing system support);
Acceptance Testing (successful completion of the user acceptance test and sign-off on
the operational system); and
Technology Planning, Support and Cutover (final set-up of the production environment
and confirmation of roles and responsibilities to support the technical IT environment).
Page 361

A.22 System Implementation

Purpose
To ensure that the transfer of the new system from a test environment to a production
environment is completed in a controlled and secure manner and to finalize readiness to go live.
Additionally, in this Phase, the CPDEP Phase 4 task of Execute is completed.
Overview
The intent of the phase is to ensure that:
All implementation activities are completed satisfactorily; and
The system is ready to go live.
To complete the implementation tasks, the following activities should be undertaken:
Complete the preparation of system operations instructions;
Finalize the establishment of the production operations environment;
Complete the final data conversion steps including the reconciliation of the old and new
systems; and
Commence live processing.
It is important to ensure that the acceptance tests completed to this point are suitable for
management, users of the system and computer operations, so that only one set of acceptance
tests are needed.
Even though the system has been transferred to a production environment, there may be further
support roles required for the project team such as for:
Parallel, phased or staged processing commencement;
First end-of-period processing;
First month-end processing; or
First end-of-year processing.
Page 362

System Implementation Task Relationships

P r o je c t s ta n d a r d s
C u to v e r w o r k p la n
P r o je c t s ta n d a r d s
V1
P re p a re S y s te m
O p e r a t io n s
In s t r u c tio n s
V2
E s ta b lis h P r o d u c t io n
O p e r a t io n s
R e v is e d c u t o v e r p la n
P r o d u c tio n jo b s t r e a m s
L iv e p r o c e s s in g c h e c k lis t
S y s te m o p e r a tio n in s tr u c tio n s
D a t a c o n v e r s io n r e c o n c ilia t io n p r o c e d u r e s
U s e r d o c u m e n t a t io n
V3
Im p le m e n t a n d
T ra n s fe r T e s te d
S y s te m
Page 363
Y
S
S
O
e a r - e n d p r o c e s s in g m a n u a l
y s te m tra n s fe r
y s t e m c o n v e r s io n r e c o n c ilia t io n
n g o in g s u p p o r t r e s p o n s ib ilit ie s

A.22.1Prepare System Operations Instructions

Purpose
To prepare execution instructions for the computer operations staff.
Overview
System operations instructions for each job are developed. These are for the use of computer
operations personnel and are to specify the procedures for which they are responsible to ensure
proper commencement and daily running of the system.
Note: If the system operations instructions have been prepared earlier in the project, the work in
this task should address confirmation that they are complete and will function in all areas of the
planned production environment. These also become a part of the THE SERVICE ARM OF THE
FIRM BW Cookbook.
A.22.2Define scope of system operations instructions.

System operations instructions should address, at a minimum, all batch job streams of the system
and the housekeeping and utility procedures such as data file reorganization, back-up, recovery
and re-runs.
The instructions should include control, access and security issues for the new system.
Special circumstances such as month- or year-end processing may require separate procedures.
A.22.3Prepare system operations instructions.

Supervise the preparation of the system operations instructions that should normally be prepared
by the computer operations personnel following the agreed standards.
The system operations instructions should provide specific step-by-step narratives that explain
the activities to be completed by computer operations personnel for all jobs in the new system.
A.22.4Submit system operations instructions to computer operations

management for approval.
This step may also include execution of any additional explanation or training for computer
operations personnel. In some installations, a separate group of personnel that is responsible for
quality control, change management and/or the transfer of systems from test to production may
need to be intimately involved in this task.
Where any aspects of the day-to-day operations are to be completed by third parties (e.g.,
network management), ensure that the appropriate systems operations instructions have been
prepared and agreed and the different responsibilities are clearly stated in signed contracts
before live production commences.
Obtain formal written acceptance of all of the completed instructions.
Page 364

A.22.5Establish Production Operations Environment

Purpose
To ensure that the transition from a test environment to a production operations environment is
completed in a controlled and secure manner and that all key operations decisions are
adequately reviewed before implementation.
Overview
Final preparations for the implementation of the data warehouse system are made in this task.
The implementation plan/schedule is finalized and all system components are prepared for the
production operations environment in conjunction with the operations personnel.
Note: The steps in this task should have been completed as part of the Technology Planning,
Support and Cutover Phase. This task is included to address situations where all steps have not
been completed earlier or where some minor adjustments have to be made.
A.22.6Finalize implementation plan.

Review the implementation plan to ensure that all target dates will be met and revise, where
necessary. Update the implementation plan with any additional information such as:
Scheduled dates for data conversion completion and first month of operation; and
Estimated staff resources to cover both implementation and subsequent operations.
These steps will require close liaison with computer operations management. In addition, if the
organization has a separate group with responsibility for transfers of systems from test to
production, additional steps may be required to meet their specific transfer process or transfer
methods.
A.22.7Finalize production job streams.

Set up production job streams for live running.
In addition, several other job stream areas need to be addressed in a production environment
such as security access and utility access.
A.22.8Finalize and walk-through the live processing checklist.

As there are generally hundreds of different tasks that must be completed to commence live
processing, it is mandatory that a critical path-based checklist is prepared, discussed, agreed and
followed to ensure a successful and smooth system commencement.
This checklist should contain:
All of the various tasks to be completed;
The time frame and responsibility for each task; and
Any alternative or contingency plans.
Some form of critical path software, if not already in use, should be used to facilitate this planning
process.
A structured walk-through of the checklist should be completed before it is finalized to ensure that
it is relevant and complete.
Page 365

A.22.9Reserve production library and data space.

Ensure that sufficient hardware space allowances are made to accommodate the new application
system programs and data files. Include appropriate allowances for the generation of data file
catalogue entries and any generations of archived data to be maintained on-line.
A.22.10
Obtain formal written approval that the production
environment creation meets installation standards.
Page 366

A.22.11
Implement and Transfer Tested System
Purpose
To transfer the new system to both the user and computer operations areas in a controlled
manner.
Overview
The implemented system, including all documentation, is transferred to the appropriate personnel
responsible for its ongoing management, maintenance and support.
A.22.12
Transport to Production Environment
Purpose
The purpose of this task is to transport customizing settings and BW Repository objects from the
QA environment to the production environment. Successful import of customizing settings and
BW Repository objects is the main objective of this task. The BW system provides tools for
transportation of customizing settings and BW Repository objects.
Procedure
The customizing settings created in the development system, as well as development objects, are
transported. In this and subsequent activities, observe the transport time windows in the project.
Before exporting, check dependencies and links to other development objects
After you export, review BW export logs
If required, import the enhancement into the PRD system
Check the import in the PRD system using the BW import log
Test the enhancement with reference to a data model in the PRD system
Log the results
A.22.13
Execute programs to finalize data conversion to the
production BW environment.
Execute programs to convert and load both master and transaction data into the production BW
system.
Depending on the means of live processing commencement, ensure that the data conversion is
reconciled and formal written approval is obtained as being completed.
A.22.14
Initialize security profiles.
Initialize both the system and user security profiles. Provide all personnel that need access to the
system their assigned security level. This process may need to be supervised by or completed in
conjunction with, internal or external audit personnel.
A.22.15
Conduct system transfer according to installation change
control procedures.
Formally transfer the new system and all of its supporting documentation including:
Program listings (including conversion programs, where relevant);
Program and system documentation;
Data conversion;
User documentation; and
Page 367

System operations instructions.
A.22.16
Complete reconciliation of the source and BW system.
Once the new system has been initialized and is ready to commence production, it is imperative
that the source and Business Information Warehouse systems are reconciled and balanced.
Depending on the means of live production commencement (e.g., a staged implementation or
parallel processing), this reconciliation process may have to be completed on more than one
occasion.
In addition, in some case this reconciliation of balances may occur after processing has
commenced. The reconciliation must be:
Properly documented - suggest putting in a separately bound volume;
Formally approved with written approval obtained from the appropriate person(s)
responsible; and
Available for subsequent post-reconciliation checks (e.g., by internal/external audit).
A.22.17
Confirm any ongoing system support responsibilities.
Establish the Help Desk support function. Ensure that the Help Desk staff are properly trained
and all users are aware of the Help Desk availability.
Ensure that the users and computer operations are aware of their support responsibilities.
Confirm any continuing maintenance role that may be fulfilled by the development team for a
specified time period.
A.22.18
Establish service level agreements.
If a service level agreement is to be put in place for the new systems implementation, finalize the
details at this time.
A.22.19
Address outstanding system items.
The various items that have been defined during design and implementation and that are not met
during the initial implementation of the system, must be addressed.
Prepare detailed plans to address implementation of these items and which forms part of the
ongoing maintenance and development of the system. These may include:
The introduction of additional system features that were not used during the
commencement of the system;
Subsequent organizational structure changes;
Subsequent changes to the existing workflows; and
Development and implementation of additional sub-systems.
A.22.20
Prepare year-end processing plan and instruction manual
(optional).
Year-end processing is generally a significant event because of such items as year-end
accounting pressures, changes to or purging of master file data, production of year-end reporting,
transfer of history data, loading of data for the new year and sub-system year-end reconciliations.
Depending upon the project scope, prepare an initial plan for the first year-end processing of the
new system.
Page 368

Depending upon the project scope, prepare a year-end processing instruction manual containing
all of the steps (including clerical tasks) necessary at year-end. This manual will require
maintenance each year as part of the annual year-end planning process to reflect any changes
that have occurred in the interim.
A.22.21
Ensure that all Disaster Contingency items are in place.
If the implementation of the new system has also included changes or additions to the
organization's Disaster Contingency/Recovery Plans, ensure that all of the appropriate items and
services are in place, have been fully tested and that the plan has been formally approved.
A.22.22
Commence use of the new system using the agreed definition
of "live processing."
Commence live production of the new system using the definition of live processing derived for
the project. It is mandatory that the project team continue its involvement past "day one" and
address such areas in the live production environment as:
The first period-end and month-end processing;
The reconciliation of sub-systems and interfaces;
The production of the first set of cyclical reporting;
Monitoring of service levels and performance;
Any quarterly, half-yearly or year-end processing; or
Completion of parallel processing.
Where a staged implementation (e.g., by location or by division) is to occur, live processing may
be commenced on more than one occasion and this should be addressed in the different work
plans.
A.22.23
Obtain formal written sign-off of completed system transfer.
Obtain a formal written system transfer sign-off that the system was successfully transferred.
Complete the necessary approval procedures to complete CPDEP Phase 4 Execute.
Page 369

Go Live and Support

The completion of the project needs to be addressed in a systematic and controlled manner.
The purpose of this phase is to move from a pre-production environment to a live productive
operation. You must set up a support organization for users, not just for the first critical days of
your productive operations but also to provide long term support.
During this phase, users of the BW System have many questions. There must be a solid user
support organization easily accessible to all users. This phase is also used to monitor system
transactions and to optimize overall system performance. Finally, the completed project is closed.
Post-Implementation Review
At a predetermined point after the implementation of the project, a formal review of the BW
system is recommended to identify areas where additional benefits can be gained by fine tuning
the application. For many projects, a lot of information concerning how the application will be
used may not really be known until after it has gone live and the users have the opportunity to
become familiar with all of its functionality. This is particularly the case where significant changes
to business processes have occurred as a result of the new system implementation.
The Post-Implementation Review (PIR) Phase uses this concept to consider ways in which the
application can be modified to provide even greater benefits to the end-users. The key to a
successful PIR is to complete the review within three to six months of the original live production
commencement date, using a mixture of reviewers who were involved in the development and
resources that can provide a fresh perspective. Three to six months is generally the right period
of time to allow the organization to become familiar with an application but not long enough for
"work around" solutions to any problems to be developed.
Another effective use of the phase is where a staged or phased commencement of the system is
to occur. The PIR tasks and steps can be tailored to review the first implementation of the system,
to take advantage of the knowledge gained and enable the subsequent implementations to be
completed more effectively.
Key Deliverables:
4) Roll-out of training and user documentation
5) Project sign-off
Page 370

A.23 Production Support

The purpose of this phase is to provide support to users and to optimize system performance.
During the first weeks of live operation, you will have questions. Timely support is critical to your
success. In addition, it is important to monitor system transactions and overall performance.
During the process of going live, there are two critical periods. In the first few days, you must
execute the production support plan and check the results. Any issues or problems that occur in
this period must be resolved as quickly as possible.
Following the first few days of live operation, you must then address monitoring issues in the
long-term, particularly with reference to system performance, capacity, and functionality.
Activities
Provide Production Support

Validate Live Business Process Results
Optimize System Use
Production Support Task Relationships
O n g o in g S u p p o r t R e s p o n s ib ilit ie s
W 1
P r o v id e P r o d u c tio n
S u p p o rt
P ro d u c tio n s u p p o rt
R e c o n c ilia t io n P r o c e d u r e s
W 2
V a lid a t e L iv e B u s in e s s
P r o c e s s R e s u lts
V a lid a te d s y s t e m
C
S
B
C
W 3
O p t im iz e S y s te m U s e
T u n e d s y s te m
SFs
e r v ic e L e v e l A g r e e m e n t
W S ta tis tic s
C M S S t a t is t ic s
Page 371

A.23.1Provide Production Support

Purpose
The purpose of this activity is to provide support for BW users. This includes short term support
during the transition to live operation, as well as ongoing long-term support.
During the move to live operation, there are two periods that must be carefully planned and
monitored. In the first few days, you must execute the production support plan and check the
results. Any problems must be resolved as quickly as possible.
In addition, key users must be trained in using SAPs Online System Support (OSS).
Tasks
Direct Problems and Issues

Manage and Resolve Problems
A.23.2Direct Problems and Issues

Purpose
The purpose of this task is to establish procedures for handling questions from users
Procedure
Develop, document and distribute procedures for handling internal problems both during the
period of going live and for the long-term.
Define the roles and responsibilities of project team members during the immediate period of
going live. End users may require increased support during the early production period.
Supply end users with the names of support personnel.
Document and distribute procedures for directing problems to SAP.
Verify that all SAP contact lists contain the correct names. Also, verify that end users have
internal contacts through whom they can channel issues to SAP.
A.23.3Manage and Resolve Problems

Purpose
The purpose of this task is to establish a process for resolving user problems. Support will be
required immediately following the move to live production, as well as in the long term. The
success of your implementation requires a well-managed user support function.
During the period immediately after moving to live production, special support is required. You
must make sure you have properly executed your plans particularly for the transition to live
production and for long term production support.
Procedure
Execute the production support plan.

Support users in the initial period after going live - the project staff must be on hand to answer
questions.
Ensure the Help Desk is adequately staffed and organize the support team for ongoing
operations.
On the first day of live operation, the Power User and project team members must be
Page 372

available to users to monitor activity and to ensure that the process works smoothly. The
project support team must be in place to work with users and follow up on all issues.
Page 373

A.23.4Validate Live Business Process Results

Purpose
The purpose of this activity is to confirm that the BW system is functioning correctly. For example,
check that master records, attributes, hierarchies and compound characteristic records are being
properly updated. These tasks are a form of quality check on the system.
Tasks
Monitor Daily and Weekly Transactions

Resolve Issues
Confirm Live Environment
A.23.5Monitor Daily and Weekly Transactions

Purpose
The purpose of this task is to review initial transactions in the productive system, and verify
processing. Both master data objects and transactional documents should be included in this
review. You must look at different periods of time (for example, daily, weekly, monthly) to validate
results from transactions.
Procedure
Verify First Day Business

Using specific measurements, check the planned business results of the first few days of
operation. These measurements can be based on shipments, billings, internal production
schedules, and other business operations. If some business results are not met, reschedule
them for the next business day and make provision to handle the workload.
Verify First Month-end

Check the planned business results for month-end processing. A proactive measurement is
required.
Verify First Quarter-end

Check the planned business results for quarter-end processing. A proactive measurement is
required. This is especially important for public companies because they must publish
financial information for shareholders.
Verify First Year-end

Check the planned business results for year-end processing. A proactive measurement is
required. This is especially important for public companies since they must publish financial
information for shareholders.
If possible, use the testing plans designed Acceptance Testing. Otherwise design plans to monitor
and verify the transactions processed. Execute the plan and prepare a written report on the
issues that arise during production.
It is important to document and resolve all issues. This gives users confidence that no matter how
small or insignificant the problem may be, it is still important to resolve it.
Page 374

A.23.6Resolve Issues
Purpose
The purpose of this task is to resolve issues and ensure that corrective action is taken. Examples
of some corrective actions include:
Changes in Business Processes
Corrective Code Changes in BW System
Configuration Changes
Additional User Training
Any code or configuration changes must first be tested and verified in your development or QA
systems and moved to your production system only after testing.
Procedure
Follow up each issue recorded until it is closed.

It is managements responsibility to record, assign, and track open issues until they are
successfully resolved. Issues should be categorized by type and priority, and estimates
should be made as to what time and resources they require. The issue is then assigned to
the support team for resolution.
The person assigned to the issue is accountable until the issue is resolved. Timeliness is
critically important since users need problems resolved so that they may do their jobs
properly. The resolution may result in, for example, changes to the system, follow up training,
new documentation. If training is not required, the person assigned the issue informs all
relevant personnel that the problem is resolved and the issue closed.
A.23.7Confirm Live Environment

Purpose
The purpose of this task is to confirm and approve live BW productive environment. Approval
takes place after business processing results have been validated. This sign off typically occurs
within a few weeks after going live; actual approval times vary. As a guide, official approval of the
live BW environment should be completed by the Guidance Review Team or senior company
management.
Page 375

A.23.8Optimize System Use

Purpose
The purpose of this activity is to improve system performance. This involves monitoring system
loads and data volumes. Estimates made before the system goes live may change in the
productive system. Monitor the system and do any tuning required.
A.23.9Optimize Technical Environment

Purpose
The purpose of this task is to monitor the BW system and implement improvements. To optimize
the technical environment, you monitor technical elements, such as the database, applications,
configurations, servers, and system load. The System Monitoring course provides training in
monitoring.
A.23.10
Optimize Business Transactions
Purpose
The purpose of this task is to optimize system performance for the most frequent critical
transactions.
Procedure
The starting point for analysis can be system performance. The following BW standard system
utilities can be used to monitor system performance:
SAP SQL trace
SAP workload analysis (statistical records)
SAP technical applications monitors
SAP monitors for applications server, database, and operating system
SAP BW/CCMS
Additionally, the BW Statistics InfoCube provides information on query execution and data
loading. This data can be used to fine-tune, create, or drop InfoCube aggregates.
Page 376

A.24 Post-Implementation Review

Purpose
To review the implemented system and determine if there is a potential for changes or
enhancements that could be made to improve the effectiveness of the system. Additionally, in this
Phase, the CPDEP Phase 5 task of Operate and Evaluate is completed.
Overview
The implemented system is reviewed to determine if it is performing satisfactorily, if it is effective
in serving the organization's needs and if it meets the original requirements. Based on this
assessment, problem areas are evaluated and potential improvements are recommended.
Each review will have its own unique scope. As a result, the review requirements to be met and
the specific work tasks to be completed will need tailoring for each project.
The following system areas may be included in the review:
Data transformation system and operational data store;
System features usage including input documents/screens/windows and output
screens/windows/reports/files;
Processing schedule;
System performance, e.g., system availability, response times, capacity utilization;
Documentation quality and comprehensiveness;
Information accuracy and/or degree of user demand for additional information or reduced
data content;
Security;
System support;
Training;
Benefits achieved (expected and actual); and
Costs (expected and actual).
Staged or Phased Implementations
As an alternative, this phase can also be used to review the first implementation site for a staged
or phased system roll-out.
To assist in the preparation of the detailed planning for the next (and subsequent) system
commencements and to take advantage of the knowledge and experience gained from this initial
implementation, post-implementation review tasks and steps should be defined that capture this
information.
Page 377

Post-Implementation Review Task Relationships

P
Q
P
S
C
O
S
Q u a lity P la n
H e lp D e s k P r o c e d u r e s
O n g o in g S y s t e m T u n in g P r o c e s s
S y s t e m R e q u ir e m e n ts
N a m in d a n d C o d in g S t a n d a r d s
O p e r a tio n a l S ta tis tic s
F u n c t io n a l R e q u ir e m e n ts
r o je c t W o r k P la n
u a lit y P la n
r o c e s s in g S c h e d u le s
e r v ic e L e v e l A g r e e m e n t
o s t / B e n e f it A n a ly s is
p e r a tin g C o s t s
y s te m D o c u m e n ta t io n
X2
E v a lu a t e S y s t e m 's
C o m p lia n c e w ith
X1
E v a lu a t e S y s t e m 's
E ff e c tiv e n e s s
A p p r o v e d P r o je c t S c o p e a n d
In fra s tru c tu re
R e q u ir e m e n t s C o m p lia n c e F in d in g s
X3
D e t e r m in e P o t e n t ia l
Changes and
E n h a n c e m e n ts
L is t o f P o t e n tia l C h a n g e s a n d E n h a n c e m e n t s
C o s t S u m m a r y M a t r ix
X4
S u b m it P o s t Im p le m e n ta t io n
R e v ie w D e liv e r a b le
P o s t - I m p le m e n t a t io n R e v ie w D e liv e r a b le
Page 378

A.24.1Evaluate System's Effectiveness

Purpose
To establish the scope of the review, to determine the degree of satisfaction with the installed
system and to assess the overall reliability of the system.
Overview
The scope, project staffing and management of the review are established.
The implemented system is reviewed to determine how satisfied the organization is with the
system and whether the system is operating reliably.
The reliability of the system is determined not just by its accuracy but by its effectiveness in
supporting the users. This reliability cannot be determined by user satisfaction alone, e.g., if users
are totally unaware of a system feature, they will not express any satisfaction or dissatisfaction
with that feature.
Other clues are sought out to determine the reliability, e.g., if data available in the system is being
manually maintained, this may be an indication that there is lack of awareness of particular
processing features. This lack of awareness may be caused by some incomplete aspect of
system implementation such as a design oversight or by incomplete user documentation or
inadequate training.
A.24.2Establish review scope and infrastructure.

The objectives and the scope of the review are discussed and the detailed work tasks and steps
to meet these objectives are derived, discussed, documented and agreed.
The review project management reporting structure is established.
The staff resources required by discipline, number and duration are defined and the project team
is formed.
The housekeeping needs for the review such as document management procedures, project
management software, administration tools and the Project Charter are defined and formally
agreed and a detailed review work plan is prepared.
Formal written approval is gained of the project scope and infrastructure.
A.24.3Evaluate the effectiveness of the system features.

Evaluate the way in which the system's available functionality is being used:
Determine the satisfaction and degree of use and understanding of:
output screens/windows,
reports,
interfaces/data transformation,
operational data store,
the sequence of processing or flow of work required, and
processing controls and security;
Determine the use of any DW tools;
Determine the extent of reliance on the system to provide the information needed for
performance measurement, quantitative analysis, decision making, planning and other
management activities;
Page 379

Determine the use of supplementary procedures to support the needs for organizing the
information; and
Determine whether the installed system features are being fully used or not.
A.24.4Evaluate the effectiveness of processing schedules.

To determine whether the present methods of accessing and running the system are appropriate,
activities to be evaluated include:
Determine the level of satisfaction with the timeliness of information;
Determine the level of satisfaction with turnaround scheduling;
Identify where overtime is regularly required to meet operation schedules;
Identify where bottlenecks occur due to an inadequate number of staff, input peaks, disk
space or other hardware shortages, network problems or insufficient time; and
Identify where there is a high level of user department staffing relative to the work
completed.
A.24.5Evaluate the effectiveness of on-line response times.

Evaluate the level of satisfaction with on-line response times and, where appropriate, develop
charts to represent actual response times to avoid "subjective" criticism that the system "feels"
slow. The analysis may also indicate potential resolutions to response time problems by indicating
when or where the problems occur.
Review the on-line performance statistics for:
Slow on-line response times for significant or high usage inquiries;
Traffic patterns and peaks including hardware and network traffic analysis;
Capacity utilization;
High transaction volumes; and
Downtime of any components of the system.
A.24.6Evaluate the accuracy of data.

To ensure that the system allows only valid data to be input and that the whole system is regularly
reconciled and balanced, evaluate such items as:
Determine the level of satisfaction with the accuracy of data;
Determine error statistics and error correction steps;
Determine whether sufficient controls/totals are included on all reports from the DW to
ensure data completeness and accuracy;
Determine whether the system is balanced and reconciled with the frequency stated in
the user documentation (e.g., interfaces, data transformation system);
Determine if duplicate data is being manually maintained that may be the result of
unreliable system data or alternatively inadequate training; and
Determine the number and extent of program problem reports and/or requests for
program maintenance.
A.24.7Evaluate the effectiveness of system support services.

If a Help Desk is provided, determine its usage and effectiveness.
Determine if user system services requests are implemented quickly and accurately. System
services requests include program change requests, on-request processing and report
distribution service levels.
Page 380

If a service-level agreement is in place, measure the degree of compliance with the agreed
service levels.
Analyze the program and system maintenance. Some indications of maintenance levels include:
Maintenance budget (e.g., current maintenance budget amount, maintenance budget as
a percentage of total IS department budget, growth rate of the maintenance budget);
Types of maintenance (e.g., corrective maintenance, adaptive maintenance or perfective
maintenance); and
Sources of the maintenance problems (e.g., lack of user understanding of the application
systems, software (system or application) unreliability, processing errors).
A.24.8Evaluate the effectiveness of program documentation, system

operations instructions and user documentation.
Determine the level of satisfaction with the user documentation format, organization and content.
Determine the program documentation and system operations instructions status (i.e., up-to-date,
outdated). Make sure the documentation reflects system changes installed after execution of
acceptance tests.
Evaluate the level of awareness and use of features within the system.
A.24.9Evaluate effectiveness of controls and security.

Evaluate the effectiveness of system controls and security that prevent and/or detect errors or
irregularities in the system.
Determine whether the system has been appropriately included in the organization's Disaster
Contingency Plan. Consider:
Access controls to prevent unauthorized users from accessing, reading or changing the
system or its data;
Back-up, recovery and restore routines;
Physical security control compliance;
Data validation routines are always used to ensure that only valid data is entered into the
system;
DBMS housekeeping routines are regularly applied to ensure DBMS integrity;
Security tracking software and control logs are regularly used to monitor system usage;
Report and output balancing requirements to ensure that the results are consistent and
that reconciliation procedures are completed; and
Output distribution controls to ensure that the correct personnel receive the output and
unauthorized personnel are prevented from receiving the output.
A.24.10
Evaluate the effectiveness of operating costs as related to the
system.
Analyze and evaluate the operating costs as related to the system in a production environment.
Compare the actual costs against the expected costs. Check to ensure that the cost basis is
consistent between the original estimates and the current figures as, for instance, changes may
have occurred in the hardware configuration, systems software or networks being used.
Compare the system costs with other application costs to determine if the costs are appropriate
and equitable.
Page 381

A.24.11
Discuss the findings and consider alternative
recommendations to address any anomalies discovered.
Page 382

A.24.12
Evaluate System's Compliance With Requirements
Purpose
To identify areas of the system that do not meet the stated requirements.
Overview
The implemented system is reviewed to determine if the requirements have been satisfied. The
requirements of the implemented system are measured against the original requirements from
the Business Blueprint Stage, the amendments to those requirements as specified in
scope/contract amendments and accepted issue resolutions and any subsequent changes to the
system since commencement of live processing.
A.24.13
Determine if the processing capabilities of the implemented
system comply with the original requirements.
Review the original or modified requirements for the system. Consider specifically the data
handling capabilities and functionality of the system. Identify:
The individual processes and their estimated volumes;
The availability of the specified processes and functionality in the implemented system;
and
If all processes are being used.
A.24.14
Determine if the processing schedules comply with the
original requirements.
Compare the original scheduling and frequency requirements with the actual operational statistics
maintained within computer operations, adjusted where necessary by any changes, e.g., changes
in the technology environment.
A.24.15
Determine if the response times comply with the original
requirements.
Review the on-line performance statistics for on-line response times, volumes and downtime.
Compare the original response times requirements with the actual statistics. Compare the
estimated volumes of data against the data volumes currently being processed by the system.
When completing this task, determine the present hardware configuration, network configuration,
capacity utilization and systems software modules to determine whether any changes have
occurred in the interim period that may have affected the performance of the system, e.g., other
new systems have been added or volumes have been increased in other existing systems.
A.24.16
Determine compliance with standards intended to prevent
information inaccuracies.
Determine compliance with installation standards for:
Programming and design standards;
Testing standards;
Maintenance;
Service levels;
Development methodology usage;
Operations housekeeping;
Page 383

User document utilization and maintenance;

Training completed;
Program change control procedures;
Control, balancing and reconciliation procedures; and
Tools usage.
A.24.17
Determine compliance with system support service standards.
Determine compliance with installation standards for:

Programming and design standards;
Testing standards;
Maintenance;
Service levels;
Development methodology usage;
Operations housekeeping;
User document utilization and maintenance;
Training completed;
Program change control procedures;
Control, balancing and reconciliation procedures; and
Tools usage.
A.24.18
Determine compliance with documentation standards.
Determine if user documentation and system operations instructions are:

Updated when system or business changes are implemented;
Changed to conform to the installation standards for the format and organization of the
documentation; and
Distributed to the appropriate personnel in a timely manner.
A.24.19
Determine compliance with service-level agreements.
If service-level agreements exist between the users and computer operations, review the planned
and actual levels of service. If any external services are used (e.g., network management), review
their compliance with the appropriate contracts.
A.24.20
Compare estimated versus actual costs and benefits.
Summarize the detailed review point findings.

Assess the impact on the organization from the implementation of the new system. Care should
be taken with this step as the review scope (as defined in the initial review project scope) must be
carefully managed to keep within the prescribed boundaries.
Analyze current processing costs and benefits against the original estimates after revalidating the
original assumptions.
A.24.21
recommendations to address any anomalies discovered.
Page 384

A.24.22
Determine Potential Changes and Enhancements
Purpose
To recommend change or enhancements to the system based upon the review findings.
Overview
Potential areas for improvement are identified and a determination is made regarding whether
changes or enhancements should be made to the system.
A.24.23
Identify areas for potential improvement.
Identify areas for potential improvement by reviewing:

Items where the implemented system does not meet the requirements and the users are
dissatisfied and/or claim ineffectiveness. These areas may require correction to satisfy
the original requirements; and
Items where the implemented system does meet the requirements but as users will by
this time be familiar with the system features and the way that it functions, they may wish
to alter some of the component parts. In many cases, these areas may require
enhancements that are outside the scope of the original development project.
A.24.24
Evaluate potential system features improvements.
Determine if there are features of the system not being used that the users should incorporate or
whether existing features could be used in a different fashion.
Determine if the reporting, screen/window inquiry, interfaces or data input can be improved.
A.24.25
Evaluate potential scheduling improvements.
Determine if system tuning is completed on a regular basis.

Determine if processing time can be improved. Consider:
Additional hardware, peripherals, software or tools;
Placement of major file disk volumes;
Network traffic monitoring and tuning;
Regular re-indexing or file reorganization; and
Analysis of current schedules, e.g., determine if the scheduling frequency can be reduced
based upon the use or criticality of the scheduled processing inputs and outputs.
A.24.26
Evaluate potential response time improvements.
Evaluate such items as:

Input/output wait and application processing time;
The memory utilization by the on-line system's program modules;
The multi-programming level for on-line transaction processing;
Changing processing times and frequency;
Additional hardware and use of different systems software (e.g., for sorts, back-up or
recovery);
Communications line(s) utilization;
Use of archiving routines to remove historical data records from file(s); and
Database tuning or file placement.
Page 385

A.24.27
Evaluate potential accuracy improvements.
Evaluate the effectiveness of:

Design, programming and testing procedures;
Access, security and back-up procedures; and
Controls relating to information accuracy and timeliness such as data collection, data
validation, error correction procedures and sub-system balancing and reconciliation.
Compare the planned standards and procedures with the actual procedures being exercised.
Determine the effect of the actual practices on the accuracy and timeliness of the information
produced by the system.
A.24.28
Evaluate potential system support services improvements.
Evaluate such items as:

The effectiveness of programming practices regarding ease of maintenance and
operational efficiency;
The change control practices that are being used;
The Help Desk;
Third-party service providers;
The effectiveness of the hardware and software supplier support;
The effectiveness of training; and
The effectiveness of user Help Desks.
A.24.29
Evaluate potential user and computer operations
documentation improvements.
Potential documentation improvements may include:
Improving training and education;
Changing the level of procedure detail;
Changing the scope of procedural overviews;
Improving the level of indexing and/or cross-referencing;
Improving the format and/or organization of the documentation; or
Changing the style or target level of the textual or on-line material.
A.24.30
Determine cost effectiveness of suggested enhancements.
Determine if the benefits derived by a change in processing mode justify additional operational
and/or systems development expenditures. Benefit and expenditure assessment should include:
Present operating costs;
Projected operating costs under changed system processing mode;
Tangible benefits such as reduced staff costs;
Intangible benefits of proposed improvements;
Development costs for proposed improvements; and
Implementation costs and time required for proposed improvements.
A.24.31
recommendations for changes and enhancements.
Page 386

A.24.32
Submit Post-Implementation Review Deliverable
Purpose
To formally prepare and present the Post-Implementation Review findings and recommendations
to management.
Overview
The outputs from the individual tasks are consolidated into a post-implementation review
deliverable. This document is reviewed for content and clarity and presented to management.
Traditionally, results of reviews such as this have used reports containing only text to describe
and present information. The use of some different graphical techniques may dramatically
improve and simplify the review outputs. For example:
A simple graphing of response times as shown may quickly and effectively describe and
dispel issues related to response times;
The "barometer" technique may be appropriate in some circumstances; or
Overhead slides and graphics can be created to show summary results to support the
detailed report.
A.24.33
Prepare and review post-implementation review deliverable.
Prepare the post-implementation review deliverable.

Consolidate the individual parts of the post-implementation review deliverable by packaging
together the interim work products into a formal deliverable. Review this deliverable on the basis
of content and clarity of presentation.
Prepare a draft implementation plan that suggests how the recommendations should be
introduced as part of the report.
A.24.34
Submit and discuss post-implementation review deliverable
with management.
Discuss the post-implementation review with management and resolve any questions and issues.
If necessary, prepare an action list of items to modify in the post-implementation review
deliverable. In practice, this step may involve more than one meeting to resolve the outstanding
issues.
A.24.35
Obtain formal written approval of post-implementation review
deliverable and formally close the project.
Obtain formal written approval of the post-implementation review deliverable. Complete the
necessary approval procedures to complete CPDEP Phase 5 Operate and Evaluate.
Complete all of the tasks necessary to formally close the project as stated in the Project Charter
and the project proposal.
Page 387

Sap BW Project Plan Methodology

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sap BW Project Plan Methodology

Uploaded by

Copyright:

Available Formats

Excerpt from

Data Warehousing and Reporting

BW Project Plan Methodology

Data Warehousing and Reporting

BW Project Plan Methodology

Analysis and Decision Process Definition..................................................................................................113

Custom Extract System Construction.........................................................................................................264

FINAL PREPARATION STAGE............................................................................................................................358

GO LIVE AND SUPPORT.......................................................................................................................................368

Data Warehousing and Reporting

BW Project Plan Methodology

Data Warehousing and Reporting

BW Project Plan Methodology

Data Warehousing and Reporting

BW Project Plan Methodology

Business Information Warehouse Development Life Cycle

T System and Integration

E Technology Planning, Support and

Cross-Life Cycle Phases

Formal Approval Points

Data Warehousing and Reporting

BW Project Plan Methodology

Data Warehousing and Reporting

BW Project Plan Methodology

Data Warehousing and Reporting

BW Project Plan Methodology

Technology Planning, Support and Cutover

Data Warehousing and Reporting

BW Project Plan Methodology

Data Warehousing and Reporting

BW Project Plan Methodology

Data Warehousing and Reporting

BW Project Plan Methodology

A.1.1 Confirm and Agree Project Objective

A.1.2 Define Project Mission Statement

A.1.3 Determine the business drivers for the DW project

Data Warehousing and Reporting

BW Project Plan Methodology

Data Warehousing and Reporting

BW Project Plan Methodology

A.1.4 Define Project Management Organization Structure and Standards

A.1.5 Agree project management structure.

Data Warehousing and Reporting

BW Project Plan Methodology

If the steering committee is functioning in an approval mode, define the procedures by

Alternatively, if the project is to be managed through a senior management organization position,

A.1.6 Confirm approach to be used for scope management and project

A.1.7 Define frequency, dates and formats for progress reporting.

Data Warehousing and Reporting

BW Project Plan Methodology

A.1.8 Develop Detailed Work Plans and Schedules

A.1.9 Evaluate risks associated with project size.

A.1.10Evaluate risks associated with experience with the technology.

Data Warehousing and Reporting

BW Project Plan Methodology

A.1.11Evaluate risks associated with the project structure.

A.1.12Summarize the risk assessment.

A.1.13Determine what methodology tailoring is required.

A.1.14Identify project planning assumptions, constraints and risks.

Data Warehousing and Reporting

BW Project Plan Methodology

A.1.15Develop overall project work plan.

A.1.16Develop detailed project work plan(s) for the Project Preparation