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.1Project Start-Up..............................................................................................................................................10 A.2Data Warehousing Project Abstract...............................................................................................................24 A.3Change Integration ........................................................................................................................................47 A.4Prototyping .....................................................................................................................................................53 A.5Technology Planning, Support and Cutover...................................................................................................65 A.6Project Preparation Checkpoint...................................................................................................................102 BUSINESS BLUEPRINT.........................................................................................................................................111 A.7Analysis and Decision Process Definition....................................................................................................114 A.8Analytical Processing Data Definition ........................................................................................................135 A.9Business Blueprint Definition Checkpoint....................................................................................................158 A.10Data Transformation System Design..........................................................................................................163 A.11Presentation System Design .......................................................................................................................183 A.12Data Design.................................................................................................................................................193 A.13User Documentation...................................................................................................................................222 A.14Training ......................................................................................................................................................235 A.15Acceptance Testing......................................................................................................................................246 A.16Business Blueprint Checkpoint....................................................................................................................254 REALIZATION STAGE..........................................................................................................................................264 A.17Custom Extract System Construction..........................................................................................................268 A.18BW Administrators Workbench Construction ...........................................................................................295 A.19BW Business Explorer Construction...........................................................................................................318 A.20System and Integration Testing...................................................................................................................326 A.21Realization Checkpoint...............................................................................................................................350 FINAL PREPARATION STAGE...........................................................................................................................362 A.22System Implementation................................................................................................................................364 GO LIVE AND SUPPORT......................................................................................................................................372 A.23Production Support.....................................................................................................................................373 A.24Post-Implementation Review.......................................................................................................................379
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 CPDEP Phase 3 CPDEP Phase 4 CPDEP Phase 5
Project Preparation
Business Blueprint
Realization
Final Preparation Support
Go Live &
A Project Start-up
G Analysis and Decision Process Definitions
J Data Transformation System Design K Presentation System Design L Data Design
Q Custom Extract System Construction W Production Support
R BW Administrators Workbench Construction S BW Business Explorer Construction
V System Implementati on
B DW Project Abstract
H Analytical Processing Data Definition
X PostImplementation Review
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 U Realization Checkpoint
Project Management
Cross-Life Cycle Phases
Formal Approval Points
Page 6
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. Cross-Life Cycle Phases 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. The structure established in the Project Start-up Phase is maintained during the Checkpoint
Page 10
Phases and the deliverables initiated in this phase are refined as the project moves towards completion. Project Start-Up Task Relationships
A P r o j e c t O p p o r t u n i t y C P o r o n
1 f i r m j e c t
a O
n b
d j e
P r o j e c t M AB g u r s e i ne e s s c H t i i vg e h - l e v e
i s s i o n S t a t e m e n D r i v e r s l P r o j e c t S c o p e
D O
A 2 P r o j e c t M a n a g e m e n t S t r u c t u e f i n e P r o j M I sg s m u t e r e s o l u t i o n a n d s c o p e c r g a n i z a t i o n S P t rr ou jc e t cu t r e s t a t u s r e p o r t i n g p r o c a n d S t a n d a r d s
D P
A 3 v e l o p D l a n s a n d
P r o j e c t r i s k a t a i l e d W o r k P r o j e c t w o r k S c h e d u l e s
s s e s s m p l a n
l e
s p
s i b
A 4 F i n a l i z e P r o j e i l i t i e s O r g a n i z a t i o n , a n d L o g i s t i c
c t T e a m P r o j e c t S t a f f i n g s
t e
r g
i z a
t i o
A 5 e v e l o p C h a r t e
P r
r o
j P e rc o t j e
c t
r t e
Page 11
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.1 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.2 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.2 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.3 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.4 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.5 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.3 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.6 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.7 Evaluate 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 Common Design
Page 16
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.8 Evaluate 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.9 Summarize 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.10Determine what methodology tailoring is required.

Determine which of the detailed work tasks and steps will be required for the project.
A.1.11 Identify 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.
A.1.12Develop 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
Page 17
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.13Develop 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.14Develop 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.15Develop 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.
A.1.16Conduct quality review of the work plan.

Complete a quality review of the work plan and make any adjustments where necessary.
Page 18
A.1.17Review 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.4 Finalize 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
Go Live & Support
Project Management DW Architecture Business Design Team Business Analysts Training SAP Process 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
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology
A.1.18Confirm 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.19Prepare 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.20Arrange 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.5 Develop 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.21Create 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.22Confirm 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
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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 C H
r o j e c t O p p o r t u n i t y B h e v r o n I n f o r m a t i o n A D ce e f c i g h - l e v e l P r o j e c t S c o Sp eu c
1 si n s e S C t r r a i t t i ec c e s s F a c
C S F s Pag lye r f o r m t o r s
c e
s u
r e
B P r e p a
2 r e D a t a
P A
B 3 r e p a r e P r o b s t r a c t A b s t r a c t
B 4 c e s r es p a r e P S y s t e m
S A b
B 5 B 6 u P r cr ee p a r e T e c h n P o rl oe gp ya r e s t r a cA t b s t r a c t C o n v e r s i o
D n
a A
t a b s t r
M E n t i t y R e
n l a
g t i o
e n
v e
r v i e o l f S
w o
D u
i a
r a S
s O h vi p e
r M v i oe dw e
r c e
I n v T e T e y s t e
e n t o r y o f c h n o l o g y c h n o l o g y m s
c u r r e A r c h i P i l o t D a
n t t e c R e t a
s y s t e m s t u r e D i a g r a q u i r e m e n t s C o n v e r s i o
B 7 E v a l u a t e D a W a r e h o u s i n e v e l o p m e n t
C t a D g R O
o a e
s t / t a c o p t i o
B e n e f i t A n a l y s i s W a r e h o u s i n g D e v e l o p m m m e n d e d D a t a W a r e h o n s
r o
j e
c t
i s k
s s e
B 8 S u b m i t D a t a s s m W e na t r e h o u s i n g UP D A b s t r a c t D e l i v e
p d a t e d r o j e c t a t a W a r a b l e
P r o je c t R i s k A s s e r e h o u s i n g P r o j e c t
s s m A b
Page 26
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.1.23Interview 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.1.24Identify 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
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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.1.25Define 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.1.26Discuss 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.2 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.1.27Define 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.1.28Establish 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.1.29Model 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.1.30Identify 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.1.31Discuss 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.3 Prepare 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.1.32Prepare 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.1.33Conduct 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.1.34Confirm 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.1.35Discuss 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.4 Prepare 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.1.36Identify 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.1.37Identify 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.1.38Develop 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; 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
Page 34
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.1.39Assess 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.1.40Review 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.5 Prepare 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.1.41Analyze 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.1.42Determine 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.1.43Discuss 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.6 Prepare 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 knowledge of the current system and will certainly require input from experienced business users; and
Page 39
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.1.44Determine 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.1.45Determine 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.1.46Determine 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.1.47Discuss 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.7 Evaluate 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.1.48Define 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.1.49Refine 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.1.50Define 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.1.51Prepare 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
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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.1.52Recommend 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.1.53Discuss 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.8 Submit 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.1.54Assess 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
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology project broken into several smaller projects. Alternatively, project staffing or funding may require changes.
A.1.55Assemble 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.1.56Submit 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.1.57Obtain 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 K D n o w n o w a t a l e l e W d g e o f c u r r e n d g e o f t a r g e t a r e h o u s i n g P t e ( B W r o C 1 n v i r o n m A s s e s s W ) e n v i a r e h o u s j e c t A b s O r g a n i z e D r o e t r a n t O r g a t a n m B eu ns I m p a a c tT e c t i o n a n i z a t i o n a l I m p a c t P r o c e s s I m p a ti n e s s c t o n h n o l o g y I m p a c t
c t
C 2 v e l o p ( o p t i o
C n a
h l )
I m p l e m e n g e P l a n C h a n g e P
t a t i o l a n
s t r a
t e
C I n t e g
3 r a
t e
I m p l e n g e s
t e
c h
Page 48
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.1.58Assess 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.1.59Assess 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.1.60Assess 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.1.61Evaluate 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.2 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.1.62Develop implementation strategy.

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

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

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

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

Integrate project descriptions into a change plan.
Page 51
A.3.3 Integrate 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.1.67Develop 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.1.68Implement 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
C P T
S F s r o j e c t e c h n o
b s t r a c t l o g y P i l o t
r e
D 1 q D u ei r f e i n m e e P n rt o s
t o
P r o t o t y p e B u s i n e s s t Py pr o e t o t y p e
s t r a t e g y s c e n a r i o s a c c e p t a n c e
c r
C P T
S F s r o j e c t e c h n o
b s t r a c t l o g y P i l o t
r e
D 2 r e p a r e P r o u i r D e am t ae n t s
t o P t yr o p t e o
t y p
t a
t a T R e q
r a n s f o r m a u i r e m e n t s
t i o
P T
D 3 r o t o t y p e r a n s f o r m
D a D t aa a t i o n
t a
r a
s f o
r m
t i o
r o
t o
t y p
D 6 f i n e
r o
t o
t y p
a D
l y s i s a n d e f i n i t i o n
c i s i o P
n PD r 4 o c e s s r o t o t y p e E n d P r e s e n t a t i o n E n
- U
s e
- U
s e
r e
s e
t a
t i o
r o
t o
t y p
D 5 v i e w P r o t o
a n d P t y p e s
r e
s e
r o
t o
t y p
r e
s e
t a
t i o
D 7 v a l u a t e a n d t h e P r o t o t y p D e l i v e r a b l e
S P e
u ob t m r o
t iy t p
l i v e
r a
l e
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.1.69Define 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.1.70Define 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.1.71Determine 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.1.72Assign authorization and responsibility.

Determine who can authorize changes to the prototype and who is responsible for acceptance of the prototype.
Page 56
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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.1.73Confirm 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.1.74Create 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.1.75Review Business Scenarios.

Complete a structured walk-through of the Business Scenarios for validity and completeness. Make corrections where required.
Page 57
A.4.2 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.1.76Determine 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.1.77Develop 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.1.78Develop 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.3 Prototype 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.1.79Determine 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.1.80Develop 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.4 Prototype 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.1.81Refine 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.1.82Refine or prepare all Report Layouts and Definitions.

Refine any existing reports and prepare any remaining or additional reports.
A.1.83Finalize 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.1.84Define 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.1.85Define 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.1.86Define 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.5 Review 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.1.87Walk-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.1.88Evaluate 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.6 Refine 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.1.89Revise 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.1.90Obtain 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.1.91Apply 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.1.92Document 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.7 Evaluate 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.1.93Apply 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.1.94Validate 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.1.95Finalize Query/Workbook Layouts and Definitions.

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

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

Package together the components of the prototype and review them for completeness and consistency.
A.1.98Submit 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.1.99Obtain 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
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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 T
v e r a l l w e c h n o l o
o r k p g y A
l a n r c h
E 1 D e v e l o p T e c h Tn e c o h g n y o l o o l e n t a t i o n W o r k i t e Ic m t u p r le e m a n d S t a f f i n g P l a n s
I m
l e
t a
t i o
T E E
e c h n o l o g y A b s t r a x i s t i n g B W B a s i s x i s t i n g H a r d w a r e /
c t R S t e a f ni oS f o t f h t
E 2 n d e a rU d ns d e r s t a n d i n g we a C r eu r cr eo nm t p S o y n s e t en m s s t
P T P D
r o j e c t w e c h n o l o r o c e s s a t a D e f
r k p l a n y A b s t r a D e f i n i t i o n i n i t i o n
o g
c t
E 3 A n a l y z e I T I T I n f r a s t r u c t u r e R e q u i r e m e n t s
I n
f r a
s t r u
c t u
r e
i r e
D E
E 4 e v e l o p B W n v i r o n m e n L a n d s c a p e
B t
v i r o
s c a
E 5 e s i g n a n d E s t aD b e l si s t h e D e v e l o p m e n tt h E n v i r o n m e n t E n
E 6 E 7 P r o d u i g n h a n d E s t aD b e l si s i g n h a n d E s t Ra be lq i e S t a g i n g t h e P r o d u c t i o nS t r a v i r o n m e n t E n v i r o n m e n t D e s
c t i o n E n su h i r e m e n t e g y i g n
e R S D
v e e t r e
l q a s
p m e n t E n u i r e m e n t s t e g y i g n
v i r o
e n E I n s t a T e C o
S t a g i t 8 R e l l a n d C o n f Si g t ur c h n o l o g y D e m p o n e n t s T e s t e
n q ar s d
g E n v i r o n m u i r e m e n t s et e g y i g n E n v i r o n m e
S D
E 9 u b m i t e s i g n
T D
e e
c h n T o el o c gh y n l i v e r a b l e
l o
s i g
l i v e
r a
u E
E 1 0 l p r o c e p p o r t T e c h nH o e l o p g D e s k y n v i r o n m e n t Bs a c k - u p / A r c h i v e
d p
r e s r o c e
r e
E 1 1 P l a n n i n g r o d u c t i o n
f o C
P r o d u c t i o n S r C u t o v e r p l a n u t o v e r
r t
Page 67
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.1.100
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.1.101
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.1.102
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.1.103
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.1.104
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.2 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.1.105 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.1.106
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.3 Analyze 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.1.107
Identify 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.1.108 Analyze 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.1.109 Analyze 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.1.110 Analyze 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
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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.1.111
Analyze 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.1.112
Analyze 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, WAN or dial-up connections, line types, Internet/intranet connectivity and the system distribution strategy;
Page 74
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.1.113 Analyze 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.1.114
Analyze 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.1.115
Determine 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 backedup), 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).
Page 75
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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.1.116
Determine 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.4 Develop 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.1.117
Develop 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.1.118
Submit Landscape
Submit the Environmental Landscape for approval to the Environment Management group and the Technical Team.
Page 77
A.5.5 Design 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.1.119
Analyze 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
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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.1.120
Estimate 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: Memory sizing, reflecting BW sizing model 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.1.121
Define 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.1.122
Order 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.1.123
Order 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
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology Procedure On the basis of the internal project Service Level Agreements, and subject to the external software partner Service Level Agreements, place the purchase order for the initial BW development system software. Inform the project steering committee
A.1.124
Order 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.1.125
Install 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.6 Design 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. Isolation of Environments 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.1.126
Analyze 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.
A.1.127
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: Memory sizing, reflecting BW sizing model Disk distribution on the application server Scalability of the application server (memory, CPU, disk space) Database Server Level: Memory sizing, reflecting BW sizing model 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
A.1.128
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.
A.1.129
Order Hardware
A.1.130
Order 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 84
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology Procedure On the basis of the internal project Service Level Agreements, and subject to the external software partner Service Level Agreements, place the purchase order for the initial BW development system software. Inform the project steering committee
A.1.131
A.1.132
Install Staging environment
Refer to Task E8 Install and Configure Technology Components for a summary of the steps involved in installing the Staging environment.
A.1.133
Set 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.1.134
Secure 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.1.135
Set 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.1.136
Set 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.7 Design 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. Isolation of Environments 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.1.137
Confirm 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
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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.
A.1.138
Purpose The purpose of this task is to develop specific sizing proposals for the production environment, with assistance from your hardware partner.
A.1.139
Purpose The purpose of this task is to define the BW software environment required for the Production 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.
Page 89
A.1.140
Order Hardware
A.1.141
Order 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. Procedure On the basis of the internal project Service Level Agreements, and subject to the external software partner Service Level Agreements, place the purchase order for the initial BW development system software. Inform the project steering committee
A.1.142
Page 90
A.1.143
Install Production environment
Refer to Task E8 Install and Configure Technology Components for a summary of the steps involved in installing the Staging environment.
A.1.144
Secure 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.8 Install 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.1.145
Coordinate 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.1.146
Install 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.1.147 Install 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.1.148
Install 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.1.149 Install 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.

Page 93
A.1.150
Establish ALE System Connectivity
Purpose The purpose of this activity is to establish ALE system connectivity. 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.1.151
Install 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.1.152
Install 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
Page 94
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology Procedure Review the defined standard PC for the BW System for: Availability Maintenance availability, maintenance procedure, and upgrade procedure Components required 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.9 Submit 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.1.153
Assemble 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.1.154 Submit 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 SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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.10Support 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.1.155
Establish 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.1.156
Establish 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.11Planning 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.1.157
Coordinate 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.1.158
Determine 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 SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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
Page 100
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology system access. This can be done through display transactions and reports, or live transactions. 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. 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 occurs and this is the main focus of the checkpoints. 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. 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

F j o e nc f t i o f t P r e p 1 r a m b s C t r o a mc t p C l e o t n n i re m s se e f h e P r o j e c t a r a t i o n S t a g e
t a
r e
s i n
r Co
r o
j e
c t
r e
r a
t i
I s s u
F 2 v i e
I s s u
I s s u e s
r e
s o
l u
t i o
r o
j e
c t
l a
F 3 a t e
r o
j e
c U t pP d l a a n t e s d
r o
j e
c t
l a
l i t y
l a
F 4 a t e
U l i t y
a l a
t e n
l i t y
l a
O P S
F 5 t a i n A p p r o v a l o f j r o j e c t P r e p a P r a r ot i o e n c t t a g e D e l i v e r a b l e s b
r e
r a
t i o
t a
r m
r o
v a
i n
Page 103
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.1.159 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.2 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.1.160
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.1.161
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.3 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.1.162
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.1.163
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.1.164
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.1.165
Produce 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: Number of project staff; Page 106
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.1.166
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; 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.4 Update 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.1.167
Review 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.1.168
Review 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.1.169
Revise 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.1.170
Revise 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.5 Obtain 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.1.171 A.1.172
Summarize findings of the Project Preparation Stage. Submit and discuss Project Preparation Stage deliverables.
Combine the findings of this stage into a Project Preparation Stage document.
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.1.173 Obtain 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. *** FORMAL APPROVAL POINT ***
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
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology Cross-Life Cycle Phases 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 Technology Planning, Support and Cutover. 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 D P u s i n e s s d r i v e r s G 1 a t a a b s t r a c t A n a l y z e r o c e s s a b s t r P cr ot c e s s e a B s i B n n d u s i n e s s eu ss si n e s s E v e n t s p e r o c e s s e v e n t s s
B s
u a
I d
2 G 3 G 4 t i f y P e r f o r m a n c e I d e n t i f y Q u a n t i t a I t di v e e n t i f y M e a s u r e m e n t A n a l y s i s P r o c e sA s ne as l y s i s P r o c e s s e s e n
A P
d h o c r o c e s s e
P e r f o r m a n c e m e a s u r e m e n p r o c e s s e s a n d d a t a p r e s e n t a t i o n c h a r a c t e r i s t i c G D o c u Q u a n t i t a t i v e a n a l y s i as n p d r a n d d a t a p r e s e n t a t i o Pn r o c h a r a c t e r i s t i c s
s 5 m e n t A n A a nl y a s l i y s s i s o D c e e c s i ss ei o s np r o c e s s c e s s e s
A d h o c a n a l y s i s d a t a p r e s e n t a t i o c h a r a c t e r i s t i c s a d e n d d e c i s i o n s c r i p t i o n s
p n
r o
c e
C P
G 6 o n f i r m r o c e s s
R M
C o n f i r m e d a n a l y s i s a n d l a d t ee dc i s i o n p r o c e s s d e s c r i p o d e l s
t i o
S D
G 7 u b m i t P r o c e P s r so c e e f i n i t i o n D e l i v e r a b
s s l e
f i i n
i t i o
l i v e
r a
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
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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: Sales forecasting for: Supply chain management, or
Page 118
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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.1.174
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.1.175 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. 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/
Page 119
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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.1.176
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.1.177
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 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
Page 120
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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.1.178 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.2 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.1.179 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.1.180
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.1.181
Develop 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.1.182 Determine 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.1.183 Discuss 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.3 Identify 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.1.184 Analyze 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.1.185
Analyze 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.1.186 Determine the implications of the quantitative analysis processes on the DW.
Determine the implications of the quantitative analysis processes on the DW in terms of: The DW as a source of input data to the quantitative analysis processes; or
Page 127
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.1.187 Determine the data presentation characteristics of the quantitative analysis 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. Summarize the data access characteristics of the quantitative analysis processes as determined earlier including: Volumes 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. 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; Graphical presentation; and Other forms of presentation media.
A.1.188 Discuss 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.4 Identify 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.1.189 Identify 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.1.190 Determine the data presentation characteristics of the ad hoc analysis 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, if possible, the data access characteristics of the ad hoc analysis 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 ad hoc analysis processes considering whether: The analyses are performance measurement, quantitative analysis or other analysis processes;
Page 129
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; Graphical presentation; and Other forms of presentation media.
A.1.191 Discuss 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.5 Document 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.1.192 Develop 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.1.193 Define 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.1.194
Procedure
Determine and document Operational Reporting Requirements
The purpose of this task is to determine and document operational reporting requirements.
Review standard reports used/created/distributed from the R/3 system
Page 131
A.1.195 Discuss 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.6 Confirm 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.1.196
Confirm 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.1.197
Reconcile 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.1.198
Reconcile 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.1.199
Discuss 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.7 Submit 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.1.200
Assemble 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.1.201 Conduct 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.1.202 Submit 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.1.203 Obtain 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

H 1 r o c e s s a b s t r a c t a t a a b s t r a c t D e v e l o D a t a
P D
p M
C o
C o n c e p o n c e p t u a l d e l
t u
t a
H 2 H 3 I d e n t i f y P e r f o r m I ad n e c n e t i f y Q M e a s u r e m e n t E M n t e i t a i e s su r e m
u e
a n
H 4 t i tI ad te i vn e t i f y U n s t r u c t u t E n Dt i ta i et a s E n t i t i e s
r e
P e r f o r m e n t i t i e s
c e
s u m
r e e
m a
e s u
n r e
t m e n t
s t r u
c t u
r e
t a
t i t
Q u a n t i t a e n t i t i e s
t i v e
H I d e n
5 t i f y
A o u
H 6 s s e s s r c e s S A P D
R a
e t a
q S
H 7 i r e I d e n n o t in f yM a o u r c R e es q u i r e m
s t e r e n t s
t a
P N o
D n d
t a
a D e n
p a t
i n t a
g M
c u 8
s t e
t a
r e
i r e
- S A P o c u m
H a p p D e t e T r a n R e q
i n g r m i n e D Da t a a t a s f o r m a t i o n u i r e m e n t s
t r a
s f o
r m
t i o
r e
i r e
H 9 l i d a t e P r o D e f i n i t i o n
c e V s a s l / i Dd
aa t t ea d
t a
f i n
i t i o
u D
H 1 0 m i t D a t a D D e a f i t n a i t di o e n f i i n e l i v e r a b l e
i t i o
l i v e
r a
l e
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.1.204
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.2 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.1.205 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.1.206
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.1.207
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.1.208 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.3 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.1.209
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 competitor pricing data;
Page 139
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.1.210
Document 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.1.211 Complete 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.4 Identify 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
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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.1.212 Identify 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.1.213
Determine 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.1.214
Identify 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: Availability of access mechanisms (e.g., availability of API's, if any);
Page 142
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.1.215
Determine 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. The following exhibit illustrates the levels of effort for data transformation based on a paradigm of internal/external and structured/unstructured dimensions.
Page 143
Page 144
A.8.5 Identify 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.1.216 Identify 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.1.217
Create 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.6 Assess 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.1.218 Identify 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.1.219 Develop 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.1.220
Assign 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
Page 147
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology Result Flat files will be generated to load into BW
A.1.221
Create 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
Page 149
A.8.7 Identify 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.1.222
Create 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 drill-down, 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 150
THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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 151
A.8.8 Determine 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.1.223
Define 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); The rules for mapping the source data to the target analytical data (e.g., calculation or aggregation); and
Page 152
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.1.224
Define 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.1.225
Define 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.1.226
Define 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 SAP Data Mapping Document Non-SAP Data Mapping Document
Page 153
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.1.227
Estimate 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.1.228
Define 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.1.229 Complete 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.1.230 Discuss 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 154
A.8.9 Validate 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.1.231 Confirm 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.1.232
Confirm 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 155
A.8.10Submit 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.1.233 Partition 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.1.234
Consider 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.1.235
Conduct 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 156
A.1.236
Specify 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.1.237 Assemble 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.1.238 Submit 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.1.239 Obtain formal written approval of the analytical processing data definition deliverable.
Page 157
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 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. The primary objective of this phase is to check progress against the Project Charter and to update the plan with any required modifications. 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. 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 D I 1 C o r o c e s s d e f i n i t i o n d e l i v e r a b l e C o n f i r m C o m p l e t D e a t a d e f i n i t i o n d e l i v e r a b l e o f t h e B u s i n e s s B l u e p r i n t D e f i n i t n f i r m e d B e n e s s l i v e r a b l e s i o n u s i n e s s B l u e p r i
I s s u
I 2 v i e
I s s u
I s s u e s
r e
s o
l u
t i o
r o
j e
c t
l a
U Q
I 3 d a t e P r o j e cU t p a d n a d t e u a l i t y P l a n s
r o
j e
c t
l i t y
Page 158
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.1.240 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. 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 159
A.9.2 Review Issues

A.1.241
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. Assess the impact of any outstanding issues and reflect in the plans and risk assessment.
A.1.242
Page 160
A.9.3 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.1.243
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.
A.1.244
Review the Project Risk Assessment documentation that has been maintained throughout the project. 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? Have advances in the marketplace (e.g., new versions of software) significantly affected the project?
A.1.245
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. 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.
Page 161
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.
A.1.246
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).
Page 162
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 M U m m o n D e s i g n s t a n d a J r 1d s e n a g e m e n t O v e r v i De w v De l i oa pg T r a s e r I n t e r f a c e P r o t o Dt ya p t a e S y s t e m o a
i r Ha m g h H- l ei g v h e - l l e n s f o r m a t i o n D e s i g n
v e
t a
r a
s f o
r m
D S
J v e y s D
2 l o p t e m e s i g
D a t a E x I n t e r f a c S n D
J 3 D e v e l o p D a t a t r a c t T r a n s f o r m a t i o e y s t e m I n f o S o e s i g n S p e c i f i c
J 4 e v e lo p D a t a n C o n v e r s i o n D e s i g u r c e S p e c i f i c a t i o n s a t i o n s D
S y I n t C u I n t M a ( u p
s t e e r f s t o e r f n a d a
g r a m e f i n i t i o n s m E x t r a c t P r o g r a m L o g i c S p e c s a c e A c c e s s a n d S e c u r i t y D e f i n i t i o g e m e n t O v e r v i e w D i a g r a m t e d ) a c e D I n f o S o u r c e S p e T r a n s f e r R o u t i n U n i t T e s t P l a n s c i f i c a t i o n s e S p e c i f i c a ( I n i t i a l )
i a
D D D
a a a
t a t a t a
C C C
o o o
n n n
v e v e v e
r s i o r s i o r s i o
n n n
D P U
e r n
t i o
J 5 u b m i t D a t a T r a n s f o r m a t i Do S y s t e m D e s i g D e l i v e r a b l e S
na n
t a
r a
s f o
r m
t i o
y s t e
Page 163
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 164
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) Presentation System Design (PT/DWA)
BW Business Explorer Construction (PT)
InfoObjects SAP R/3 Non R/3
Legacy System Legacy System Legacy System Legacy System Source Systems
E xt ra ct
Legacy System
PSA
Scheduler/Monitor(InfoPackage) Users
Business Information Warehouse

Page 165
BEx Anal yzer
Inf o C ub es
In te rf ac e E nv ir o n m en t Pr ot oc ol
Non R/3
Transfer Rules/ Routines
Update Rules/ Routines
O L A P E ng in e
BAPI/3rd Party
BEx Bro wser
Tr an sf er St ru ct ur e (D at a S ou rc e)
tRFC
C o m m un ic ati on St ru ct ur e (In fo S ou rc e)
Queries/ Reports/ HTML
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 BW Project Plan Methodology
A.1.247 Develop 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.1.248
Design 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.1.249
Determine Uses of Pre-Configured InfoSources.
Purpose The purpose of this activity is to determine uses of SAP pre-configured InfoSources.
Page 166
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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.1.250
Identify 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.1.251
Design 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.1.252
Design 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; Analyze DW physical data distribution requirements;
Page 167
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.1.253
Design 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.1.254
Design 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.1.255 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, recommended model for the actionable extract system audit processing, and management approval of the extract system audit processing model; Data transform audit requirements:
Page 168
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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.1.256
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 169
A.10.2Develop 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.1.257 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.1.258
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 170
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.1.259
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 171
A.1.260
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. The extractors may not always be extendable. This can depend on if the new fields come
Page 172
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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 of importance, when the lead system repeats transfers in case of restart, crash recovery or
Page 173
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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.1.261 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 174
A.10.3Develop 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.1.262
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.1.263
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.1.264 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 175
A.1.265
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.1.266
Develop Monitor Response for Edits/Validations.
Specify the associated action (e.g., Help message, error or warning message) for each edit and validation.
A.1.267 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.1.268 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.1.269
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 176
A.10.4Develop 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.1.270
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.1.271
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 177
A.1.272
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.1.273 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.1.274 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 178
A.1.275 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.1.276
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.1.277 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.1.278
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 179
A.1.279 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.1.280 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 180
A.1.281 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.1.282
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 181
A.10.5Submit 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.1.283
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.1.284
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.1.285
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.1.286 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.1.287 Obtain formal written approval of the data transformation system design deliverable.
Page 182
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
K 1 D e f i n i t i o n D e v e l o f i n i t i o n P r e s e n
P D
r o c e s s a t a D e
p t a
H i g h H- L i g v e- L l e e h t i o n D e s i g n
v e
r e
s e
t a
t i o
s i g
v r o
c u
r i t Cy D
r Pe
K 2 o lt i e c y A u t h o r A i z u a t th i oo nr i z a a e t a i l e d D e s i g n
t i o
s i g
K 3 D e v e l o p S y s t e m D e s i g
Q W S P r e s e n R I n t e r f a C n V U
e o r t r u t a e s c e a l c a r i n i t
s p b o o t u r e i o n t r i c t e u l a t e a b l e T e s t
r k c t
c i f i c s p e s p e c d K e y d K e s p e c i P l a n
e k
a t i o n s c i f i c a t i o n s i f i c a t i o n s F i g u r e s p e c i f i c a t i o y F i g u r e s p e c i f i c a t i o f i c a t i o n s ( I n i t i a l )
K 4 b m i t P r e s e P t r a e t s i oe nn n S y s t e m D e s i g n D e l i v e r a b l e u
t a
t i o
s i g
l i v e
r a
l e
Page 183
A.11.1Develop 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.1.288 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.1.289 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:
Page 184
Information access requirements including: 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.1.290 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.1.291
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 185
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.1.292 Discuss and obtain formal written approval for the high-level presentation system design.
Page 186
A.11.2Create 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.1.293
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)? Can users in the department execute all relevant transactions (DO ALL), and have they 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: Can users in the department execute all relevant transactions (DO ALL), and have they access to data across the organization (SEE ALL)? Can users in the department execute all relevant transactions (DO ALL), and have they access to only specific data across the organization (SEE SOME)?
Page 187
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.1.294
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.1.295
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 188
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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.1.296
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 189
A.11.3Develop 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.1.297
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 190
A.1.298
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.1.299
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.1.300
Assemble Business Explorer Object specifications.
Assemble the components of the Business Explorer Object specifications.
A.1.301 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.1.302
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 191
A.11.4Submit 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.1.303
Assemble presentation 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 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.1.304
A.1.305
Any problems in the design should be resolved through the formal issue resolution process. All open system design issues should be resolved before the completion of this phase.
A.1.306 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.1.307 Obtain formal written approval of the presentation system design deliverable.
Page 192
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 193
Data Design Task Relationships
c e
t u
t a
L 1 v e l o p M o d e
L l
L o g i c a l i c a l D a t a
t a
L 2 D e v e l o p u l t i d i m e n s i o M o d e l
M u l t i d i m n a l D a t a
s i o
t a
H D M
i g h - l e v e l D a t a T r a n s f o r m a t i o n I n f o C u b e s a t a T r a n s f o r m a t i o n S y s tL e 3 m D e s ig n D e sA i gg gn r e g a t e a s t e r D a t a r e q u i r e m eI n n f t o s C u b e
u D
L 4 m i t D a t a D D e a s t ai g e l i v e r a b l e
D n
s i g
l i v e
r a
l e
Page 194
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, interface data volumes, and
Page 195
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.1.308
Review 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 196
A.1.309
Transform 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 197
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.1.310
Place 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 198
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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.1.311
Finalize 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 199
A.1.312
Finalize 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.1.313
Refine 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 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).
Page 200
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.1.314
Estimate 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 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
Page 201
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; 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.
Page 202
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.1.315 Complete 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 203
A.12.2Develop 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 204
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.1.316
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 205
A.1.317
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 206
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 207
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 208
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.1.318
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 209
Perform calculations involving specific "cells" of the fact tables to meet the information needs of a particular business or decision analysis situation.
A.1.319
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.1.320
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 210
Page 211
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
Page 212
A.1.321 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 213
A.12.3InfoCube Design A.1.322 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.1.323
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: Information Access Environment Document
Page 214
Data Definition Multi-Dimensional Data Model High-level Design Identify, review and document the following: 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.1.324
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: Information Access Environment Document Data Definition Multi-Dimensional Data Model High-level Design Identify, review and document the following: 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
Page 215
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology Presentation characteristics of each dimension (using a hierarchy)
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.1.325 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: Information Access Environment Document Data Definition Multi-Dimensional Data Model High-level Design Identify, review and document the following: 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 216
A.1.326 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: Information Access Environment Document Data Definition Multi-Dimensional Data Model High-level Design Identify, review and document the following: 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.1.327
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: Information Access Environment Document Data Definition Multi-Dimensional Data Model High-level Design Identify, review and document the following: 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 Conversion Routine user exit requirements for these Hierarchies in BW
Page 217
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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.1.328
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: Information Access Environment Document Data Definition Multi-Dimensional Data Model High-level Design Identify, review and document the following: 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.1.329
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: Information Access Environment Document Data Definition Multi-Dimensional Data Model High-level Design Identify, review and document business rules for the following: For each Characteristic For each Key Figure
Page 218
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology Result The identification and documentation of the exact business rule required for all objects, processes and reports in BW.
A.1.330
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? 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
Page 219
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology Results Create an archiving manual, based on the information gathered, to record standard procedures and schedules, and what to do in exceptional circumstances
Page 220
A.12.4Submit 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.1.331
Assemble data 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 specification packages.
A.1.332
A.1.333
Any problems in the design should be resolved through the formal issue resolution process. All open data design issues should be resolved before the completion of this phase.
A.1.334
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.1.335
Obtain formal written approval of the data design deliverable.
Page 221
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 222
User Documentation Task Relationships

D D S M e t e o c t r a t P l U s e r m i n e U sU e s r e u m e n t a t i D no c o D e g y a n d W oo c D o c a n s 1 r D r D u m r uk m u m o c u m e n t a t i o n o c u m e n t a t i o n e n t a t i o n A u d e n t a t i o n D i s t e n t a t i o n C o n
l e
s p
M nE s s i t b a i bl i D o c S t a
2 s P a p t l i e hs u m e n t a t n d a r d s
D o eD r o iD o o n
c bc c
u m e n au sm e e d n u m e n
t a t a t a
t i o t i o t i o
n n n
s t a n d a d e l i v eDr r e s p o Dn
r dM s 7 ye v m e el o c p h aO n n i s- l mi n os ci b u i lm i t i ee ns t s S u b S y s t e m
- l i n
s e
c u
t a
t i o
M 3 oP n r et e p n a t r e D o c u m e
P n t
p e Dr - ob ca us m d e n e I n t r o d u c t i o n
t a
t i o
i n
t r o
c t i o
P A M
r o c e s s D e f i n i t i o n D e Ml i p p l i c a t i o n D e s i g D eD v e e l n a n a g e m e n t O v e Ur v s i ee w r
D v4 e r a b l e a li ov ep r P ba l p e e r D D o i ca ug mr a e m n
o --b -t a -
c U Ma Ut S
m s e sa e n i so en y s
n t B o d y D o c u m e n t a t i o n O v e a g e m e n t S u m m a r y d r P r o c e d u r e s t e m R e s p o n s i b i l i t i e s r
r v i e
v e
D o c u m e n t A p p e n d i c e s M 5 r v i e w D i a g r a m P r o f i l e s r e p a r e P a p e r - - b S a es ec ud r i t y - P r o c e s s i n g S c h e d u l e A p p e n d i c e s
S U
u b s e
M m r
6 i t D o P
a p e r P- b a a p s e e r d- b c u m e n t a t i o n
s e
s e
c u
t a
t i o
Page 223
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.1.336
Create 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.1.337
Identify 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.1.338
Determine 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 224
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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.1.339
Define 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.1.340 Review 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 225
A.13.2Establish 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.1.341
Define 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.1.342
Determine 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.1.343
Determine responsibilities.
Establish the responsibilities for: Initial publishing; Ongoing maintenance/updates; Change control; Storage/distribution; and Training linkages.
A.1.344 Discuss and obtain formal written approval of the paper-based documentation standards.
Page 226
A.13.3Prepare 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.1.345
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.1.346
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.1.347
Discuss and confirm the paper-based document introductions.
Page 227
A.13.4Develop 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.1.348
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.1.349
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.1.350
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.1.351
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.1.352
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 228
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.1.353
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.1.354
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.1.355
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.1.356 Discuss and confirm the content of the draft User Documentation content.
Page 229
A.13.5Prepare 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.1.357
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.1.358
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.1.359
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.1.360
Document other appendix items.
Create any other appendix items, as necessary.
A.1.361 Discuss and confirm the draft paper-based appendices content.
Page 230
A.13.6Submit 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.1.362
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.1.363
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.1.364
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.1.365 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 231
A.13.7Develop 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.1.366
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.1.367 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.1.368
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: System introduction and overview;
Page 232
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.1.369
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.1.370
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.1.371 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.1.372
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.1.373
Submit and discuss the on-line documents with management.
Discuss the on-line documentation content 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.
Page 233
A.1.374 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 234
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 235
Training Task Relationships

1 t i f y P e r s o e T r a i n e d N
P T
e r s o n n r a i n i n g
e n
l e
d e
e d
t a s
i l s I d
e b
n P n
ee l r s t oo
r e
i r i n
t r a
i n
i n
D S
N 2 t e r m c o p e e
i n a
e n d
T r aT i rn a i ni n g i n S t r a t e g y
c o
t r a
t e
D C
e o
r N 3 v e l o p T r a i n i-n u r s e M a t e r i a-
i C L T Tg l Cs I n P
i n g u r s e a r n r a i n i r a i n i o u r s s r u c a r t i c o
c o u r s e m a t e r i a l s e M o d u l e i n g O b j e c t i v e s n g M e t h o d s n g T e c h n i q u e s e P l a n / S c h e d u l e s t o r M a n u a l i p a n t W o r k b o o k
N 4 e v e l o p a n d C I no sn t d r uu cc tt o I n s t r u c t o r T r a Ii nn is n t gr u c t o ( o p t i o n a l )
r r
G T
u i d e r a i n i n
t e
r i a
l s
C S
o e
N 5 d u c t P s s i o n s
R e v i s e i l o t T r a i n i n ( o p t i o n a l )
d g
r a
i n
i n
t e
r i a
l s
N 6 o n d u c t T r a S e s s i o n s
i nT i r n a g i n
r s o
Page 236
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.1.375
Confirm 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.1.376
Identify 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.1.377 Determine 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.1.378 Determine 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.1.379
Confirm 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.1.380 Obtain formal written approval of the personnel training profile.
Page 237
A.14.2Determine 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.1.381
Identify 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 238
A.1.382
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.1.383
Develop standards for each type of training.
If standards do not exist, they should be created for such items as: Numbering and naming conventions; 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.1.384
Create training development work plan.
Construct a comprehensive training development work plan, based on the training strategy,
A.1.385 Discuss and obtain formal written approval of the training scope and strategy.
Page 239
A.14.3Develop 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.1.386 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.1.387
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.1.388
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.1.389
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.1.390
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 240
A.1.391
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.1.392 A.1.393
Prepare or acquire other training materials. Determine training delivery computer equipment needs.
Dependent upon the different delivery approach, create or acquire the training materials.
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.1.394
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.1.395 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 241
A.14.4Develop 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.1.396 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.1.397
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.1.398 A.1.399
Prepare instructor materials. Schedule and conduct instructor training.
Prepare the audio-visual or other materials needed to conduct the instructor training sessions.
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.1.400
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.1.401 Discuss and obtain formal written approval of instructor training materials and course.
Page 242
A.14.5Conduct 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.1.402
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: A location for the course; Audio-visual, computer or other equipment availability; Course material preparation and distribution; and 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.1.403
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.1.404 Discuss and obtain formal written approval of final training materials and approach.
Present the revised materials for review and obtain formal written approval.
A.1.405
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 243
A.14.6Conduct 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.1.406
Prepare for training sessions.
Arrange for the following: A location for the course; Audio-visual, computer or other equipment availability; Course material preparation and distribution; and 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.1.407
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.1.408
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.1.409
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 244
A.1.410 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 245
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 246
Acceptance Testing Task Relationships

S P D T y s t e m a b s t r a c t O r o c e s s d e f i n i t i o n A g r e a t a d e f i n i t i o n C r i t e e c h n o l o g y d e f i n i t i o n S t r 1 S t a f f r e s p o n e A c c e p t Aa nc cc e p t a n c e e r i a a n d T A e cs ct e p t a n c e a t e g y
s i b i l i t i e s c r i t i e r i a t e s t s t r a
t e
T P B
e s t C a s e s r o t o t y p e u s i n e s s S c e
O 2 D e v e l o r i o s T e s t
p C
A p p r A c c e A p ct a c ne a s e s A c c e
v e d A p et a n c e c p t a n c e
c c e p t a n c e C r i t e T e s t P l a n T e s t S t r a t e g y
r i a
y s t e
s t e
p Cp
O 3 ol i cn a d t u o c i n t T e s t
A c c e p t a c c e A p c t ac ne cp et a
n n
c e c e
T S
e s t D i g n - o
a t a f f
Page 247
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.1.411
Select 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.1.412
Prepare 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. 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
Page 248
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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.1.413
Review 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.1.414
Define 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.1.415
Review 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 249
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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 250
A.15.2Develop 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.1.416
Review 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 251
A.1.417
Review 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.1.418
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.1.419
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. 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.1.420 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 252
A.15.3Conduct 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.1.421
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.1.422
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.1.423 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 253
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 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 Business Blueprint Stage and these additional tasks are described in the Business Blueprint 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. 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. 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 occurs and this is the main focus of the checkpoints. 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. 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. 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 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 254
Business Blueprint Checkpoint Task Relationships

D P D a t a t r a n s f o r m a t i o n r e s e n t a t i o n s y s t e m a t a d e s i g n s y s t eP m1 C d oe ns fi gi r nm o f t h e B l u e p s i g o m B u s i n r i n t S t C d e n p Cl e o t n e e s s a g e fn i re m s se d B u s i n e s s B l u e p r i
I s s u
P R e
2 v i e
I s s u
I s s u e s
r e
s o
l u
t i o
r o
j e
c t
l a
P 3 a t e
r o
j e
c U t pP d l a a n t e s d
r o
j e
c t
l a
l i t y
l a
P U p d a
4 t e Q u a
U l i t y
a l a
t e n
l i t y
l a
O B S
P t a u s i t a g b
5 i n A p p r o v a l o f n e s s B l u eB p u r s i n i n t e e D e l i v e r a b l e s
s s
l u
r i n
t a
r m
r o
v a
i n
Page 255
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.1.424 Confirm 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: Analysis and Decision Process Definition; and Analytical Processing Data Definition. 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. 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.
A.1.425 Confirm 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: Analysis and Decision Process Definition; and Analytical Processing Data Definition. Ensure that the presentation system design is consistent with: Data design; Data transformation 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. 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 256
A.1.426 Confirm 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: Analysis and Decision Process Definition; and Analytical Processing Data Definition. Ensure that the data design is consistent with: Presentation system design; Data transformation 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. 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.
A.1.427 Confirm 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. Resolve the issues as soon 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 257
A.16.2Review Issues
A.1.428
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 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. Assess the impact of any outstanding issues and reflect in the plans and risk assessment for the next stage.
A.1.429
Page 258
A.16.3Update 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.1.430
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.1.431
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.1.432
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.1.433
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.1.434
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 259
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. 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. Formal written approval should be sought for any actions to be taken and plans revised accordingly.
Page 260
A.16.4Update Project Charter

Purpose To ensure that all aspects of planning and quality have been properly addressed. 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 amended or created, as appropriate. In particular, the Project Risk Assessment needs to be revisited.
A.1.435
Review the risk assessment as a result of the Business Blueprint Stage experience and the updated project plans for the Realization 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? Have advances in the marketplace (e.g., new versions of software) significantly affected the project?
A.1.436
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. 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 261
A.1.437
Review the Project Risk Assessment completed earlier 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.1.438
Many areas within the Project Charter may not have been completed in full until this point since they primarily affect the Realization Stage. Ensure that all these areas have been properly addressed before progressing to the Realization Stage. Revise the Project Charter as appropriate.
A.1.439
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 262
A.16.5Obtain 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.1.440
Submit and discuss Business Blueprint Stage deliverables.
Discuss the Business Blueprint 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.1.441
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.1.442 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). *** FORMAL APPROVAL POINT ***
Page 263
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 264
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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 265
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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. 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
Page 266
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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. Cross-Life Cycle Phases 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 Technology Planning, Support and Cutover. 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 267
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 Detail Logic Charts. References to Detail Logic Charts are added to the final program
Page 268
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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 269
Custom Extract System Construction Task Relationships

1 r e p a r e P t r u c t u r e Q Q 2 r e p a r e P r o Fg ir n a a m l i z e G e n e r a t i o n S p e c i f i c a t i o n s C D e t a i l l o g i c c h a r t s C P o C o o n
P S
r o g r a m C h a r t s
r o
r a
s p
c i f i c a
t i
Q n
9 C o n s t r u c t D a C t ao n v e r s i o n S y s t e
s t r u c t e v e r s i o n m
Q 3 p r o g r a m m p l e t e S t r u A c pt up r r eo dv e d sf p e c i f i c a t i o n s W a l k - t h r o u g h o Q 1 0 r o g r a m S p e c i f i c a t i o n s E x e c u t e D a t C a C o n v e r s i o n
v e
r t e
D P
Q 4 v e l o p E r o g r a m
x e c Pu rt ao bg lr e a C o dP e r o g r a
m m
c o d e d o c u
t a
t i o
C W P
Q m p a l k r o g
5 l e t e S t r u A c pt up r r eo dv e - t h r o u g h o f r a m C o d e d p r o g r a m c o d e
Q 6 v e l o p / E T e s t
x e
U n i t U n i t U n i t c uU t ne i t U U n i t T e s t T e s t S t S t S t g T Te T e r i n r i n r i n es st s t
t t t t t
e s e s e s n is t e e s p r o p r o e e e og o
t t t t t
o b j e c c o n d p l a n s d a t a e n v i r b l e m b l e m s s s b b
t i v e s i t i o n s o n e m n t r e p o r t s r e p o r t l o
s i n
s s
c e
r i o s E x e
Q 7 c u t e
t r i n
g t g t g t tp i nr p r
t s t r a t e g y t p l a n t d a t a l e m r e p o r t s l e m r e p o r t l o
P P
r o r o
g g
r a r a
m m
Q 8 U n i t R t oe v i s e d s p e c i f i c a tD i o e n v s e l o p p r o g r a m T e s t M U i gn r i ta tt o o ns y s t e m i d o c u m e S n y t as t ei o m n t e P l a n
d o c u m e n t a s t m i g r a t i o n
t i o n p l a n
Page 270
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.1.443
Identify 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.1.444 Identify 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.1.445
Identify 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.1.446
Prepare 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 271
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.1.447
Decompose 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.1.448 Select 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.1.449
Refine 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 272
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.1.450 Prepare 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 273
A.17.2Prepare 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 An automated interface exists between the automated tool used and a program generator.
Page 274
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.1.451 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.1.452
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.1.453
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.1.454
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). 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.
Page 275
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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 276
A.17.3Complete 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.1.455 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.1.456 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.1.457 Obtain team leader or equivalent approval of the program specifications.
Page 277
A.17.4Develop 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.1.458
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.1.459
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.1.460
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.1.461
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 278
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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.1.462
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.1.463
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.1.464
Complete all program documentation.
Ensure that all of the program documentation is complete using the Program Control Checklist.
Page 279
A.17.5Complete 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.1.465
Ensure that program documentation is complete.
Review and cross-reference the documentation against the Program Control Checklist. Add any missing items.
A.1.466 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.1.467 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.1.468 Submit program code and System Change Requests to the project team leader and obtain formal written approval.
Page 280
A.17.6Develop/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.1.469
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 281
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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.1.470
Generate unit test data.
Generate unit test data:
Page 282
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.1.471
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.1.472
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 283
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.1.473
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 objectives, test conditions, test steps, test data files and expected results), unit test
Page 284
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology results and unit test logs. Magnetic media versions of these items should be maintained in a secure environment.
Page 285
A.17.7Execute 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.1.474
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.1.475
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.1.476
Conduct string tests.
Execute and log the string tests using one or a combination of:
Page 286
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.1.477
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.1.478
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.1.479 Submit program documentation with string test results to the team leader and obtain formal written approval. A.1.480 File all string test results.
Page 287
A.17.8Develop 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.1.481
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.1.482
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.1.483
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.1.484
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.1.485
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 288
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.1.486
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.1.487 Obtain formal written sign-off from the System Test Manager that the migration has been successful.
Page 289
A.17.9Construct 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.1.488
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.1.489 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.1.490
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.1.491
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 290
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.1.492
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.1.493
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.1.494
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.1.495
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.1.496
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 291
A detailed structure and sequence of the creation process tasks must be prepared.
A.1.497
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.1.498 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.1.499
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.1.500 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.1.501
Obtain formal written approval from management.
Page 292
A.17.10
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.1.502
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.1.503
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.1.504
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 293
A.1.505
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.1.506
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.1.507 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 294
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 295
BW Administrators Workbench Construction Task Relationships
I n
s t a
l l e
x t r a
c t i o
nP
R 1 r P e r po ag r r ea m S o s S y s t e m s
rP c r e e
r e
s o
r c e
s y s t e
t a
r a
s f o
r m
t i o
C S
R 2 h s a t ne gm e / D U e p s d i g a y D a t a
M I n tn e I n
a i n t a i n f M O e bt a j e o f o O b j e
e d D a t a S o u r c e M c t C h a r a c t e r i s t i c s c t K e y F i g u r e s
t a
s i g
R C r e a
3 t e
I n
f o
I n f o C u b e s uA b g e g s r e g a t e
t a
r a
s f o
r m
t i o
R 4 M a i n t a i n I S y s t e m D e s i g n n f o C o m m u n i c a t i o n S t r u c t u r e
r c e
i c a
t i o
t a
r a
s f o
r m
t i o
R 5 S M y sa t i en m a i D t n R u l e s
T r a T e T s r ia g n n s r f a e P e r D a t
n s f e r r u l e s n s f e r s t r u c t u r e sr i s t e n t S t a g i n g a s o u r c e s
r e
( P
t a
r a
s f o
r m
t i o
R 6 S Cy s r et e a m t e / D M e a s i i n g t n a i p n d U U p d a t e R u l e s
t e
r u
l e
S I n
R 7 c h e d u l e f o P a c k a g
I n s
f o
c k a
s / G
r o
Page 296
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 297
A.1.508
Confirm 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 Remote-Function-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.1.509
Implement 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 298
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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.1.510
Implement 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.1.511
Implement 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.1.512
Implement 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 299
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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 300
A.18.2Change/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.1.513
Maintain 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 301
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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.1.514
Create 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.1.515
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 302
A.1.516
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 303
A.18.3Create 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.1.517
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.1.518
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.1.519
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 304
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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.1.520
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 305
A.18.4Maintain 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 306
A.18.5Maintain 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.1.521
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.1.522
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 307
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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.1.523
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.1.524
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.1.525
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 308
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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.1.526
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.1.527
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 Identify what type of transactional data is contained in the datas InfoSource
Page 309
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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 310
A.18.6Create/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 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. SAP and non-SAP Data mapping documents. Data definition. The communication structure of the target InfoSources must have been maintained.
Tips Successful maintenance of communication structures of the target InfoSources must be completed prior create InfoCube update rules.
A.1.528
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 311
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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.1.529
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 312
A.18.7Schedule 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 Input Result A new InfoPackage or InfoPackage variant will be created and scheduled, either immediately or through batch process. IDOC will be created. 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. Upon completion of InfoCube and Update Rule creation.
Outcome InfoCubes connected to the InfoSources and the defined Source systems will be updated according to the selection parameters.
A.1.530
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 313
A.1.531
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.1.532
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.1.533
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 314
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 "batch-input 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 315
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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.1.534
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.1.535
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 316
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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.1.536
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 Input BW monitor status display screen. Refer to BW Online document: Monitor for detailed screen presentation and procedures. Post InfoPackage scheduling. Upon receiving "Data Request executed" message on the message line.
Page 317
A.19 BW Business Explorer Construction

BW Business Explorer Construction Task Relationships
S p o 1 l e m r i z a e n t t i o n P A U C r o f i l e s u t h o r i z a t i o n op nd ca et e p d t U s e
t h
r i z a
t i o
s i g I nm A u t h
O r M
b a
j e
c t s s t e r
S 2 l i d a t e A u t h C o n c e p t
o V r ai z l ai d t ai o t ne
t h
r i z a
t i o
r o
f i l e
r e
s e
t a
t i o
S 3 y s C e om n s D t t E x p l o r S y s
Q u e r y W o r k b o o k r e u s c i g n u s S i nt r e u s c s t u r e t B e r P r e s e R n e t as tt ri oi c n t e d C a l c u l a t e d t e m V a r i a b l e s
K K
e e
y y
F F
i g u r e s i g u r e s
Page 318
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.1.537
Create 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.1.538
Generate 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 319
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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.1.539
Create 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.1.540
Test 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.1.541
Create 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 320
A.19.2Validate 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.1.542
Identify 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.1.543
Create 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.1.544
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 321
A.1.545
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 322
A.19.3Create 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.1.546
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.1.547 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 Input Result A directory of hierarchical tree structure to store query workbooks in an organized manner at enterprise and user grouping levels is established. The Enterprise and User Channel InfoCatalogs are structured. InfoCatalog organization strategy document. Query Subscription and publication strategy document. Categorization of query users, by roles and functions. Assess query subscription and publication strategy document. Review the security authorization document for query access.
Page 323
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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.1.548
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.1.549
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 Result BW Business Explorer Browser default settings configured for each desktop identified (i.e., End-User, Project Team Members). Purchase of BW Software Defined Data Access Paths by User Group and Organization
A.1.550
Assign Authorizations
Purpose The purpose of this activity is to assign user authorizations for working with queries. Prerequisites
Page 324
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology Trigger Input Result The appropriate user profile will be assigned to each user id of the BW system. 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. Assess the User access authorization documentation
A.1.551
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 Input Result Query display and navigation with slice and dice as well as all other functionality. Query workbook in the InfoCatalog Query workbook in the User Favorites Upon completion of creating query.
Page 325
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 326
System and Integration Testing Task Relationships

S P R y s t e m t e s t s t r a t e g y N e w o r u p d a t e d S y s t e m T 1 r o g r a m / C o m p o n e n t P s rp e e p c a i f r i ec a S t i y o s n t se S m y s T t ee m t T e s t W o r k P l a n s e c o v e r / R e s t a r t p r o c e d u r t er a s t e g y S y s t e m T e s t t e a m r e s p o S T n e s t S t r
s i b
i l i t i e
C P B A M H C P B A M H
r e u c
i c a l f o r m i n e e p t a n a g i g h - l e i c a l f o r m i n e e p t a n a g i g h - l e i t r s c
i t r s c
S s a e v S s a e v
u c c e s s F a n c e M e a s s c e n a r i o n c e t e s t p m e n t O v e e l a r c h i t e c u c c e s s F a n c e M e a s s c e n a r i o n c e t e s t p m e n t O v e e l a r c h i t e c
a c s u s la n r v i t u a c s u s la n r v i t u
t o r e D e w r e t o r e
r s s e
T v e P D i d i a
S y s t e m 2 l o p S y s t e S m y s T t e e ms t S y s t e m l a n a g r a m g r a m
t e t e t e
s t s t s t
o d p
b j e c t i v e s a t a s p e c T i f 4i c a t i o n s P r e p a r e S y s t e m l a n E n v i r o n m e n t (
r e u c
r s s C o W e wS y r e d
S T 3 n d u c t S t r u a l k - t h r o u g D s it ae gm r a T m e s t i a g r a m cR t ue rv e i s d e h R oe f v i s e P l a n d d S S y s t e y s t e m m T T e e s t s t
y s t e P W
T P
e l a
s t n
l a n o r k
x e
T 5 c u t e
U p d a t e d S y s t e m a S y s t e m C h a n g e R S y s t e m y s t e C m o mT ep sl e t t e T e s t p r o b l e m r e p o T e s t p r o b l e m r e p o
n d U s e r e q u e s t s t e s t p l a n r t s r t l o g
D s
c u
I n I n
t e t e
g g
r a r a
t i o t i o
n n
t e t e
s t s t
p d
l a n a t a
x e
T 6 c u t e T e s t
I n
t e
T e s t p g T r ae t s i ot np
r o r o
b b
l e l e
m m
r e r e
p p
o o
r t s r t l o
H H H
i g i g i g
h h h
- v o - v o - v o
l u l u l u
m m m
e e e
t e t e t e
s t s t s t
s t r a t e g yT 7 p l a nE x e c u t e H i g d a t a T e s t i n g
T e s t p - V o l u m T e s t p
r o e r o
b b
l e l e
m m
r e r e
p p
o o
r t s r t l o
C A S
S F s / P e r f o r m a n c e M e a s Tu 8r e s c c e p t a n c e c r i t e r i a C o n d u c t y s t e m t u n i n g a p p r o a c h T u n i n g
U p d a t e y s t e m O n g o i n
s y s t e m t e s t p l a n s s y s t e m t u n i n g p r o
c e
s s
Page 327
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.1.552
Define 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 Security testing - to demonstrate the system's ability to prevent or detect and isolate improper access and unplanned activity.
Page 328
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.1.553
Define 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.1.554
Outline 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: relationships among test tasks, program coding schedule,
Page 329
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology available personnel (development team and business partners) and machine resources, and availability of other application team members.
A.1.555
Determine 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.1.556
Confirm 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.1.557
Define/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.1.558
Prepare 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.1.559 Discuss 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 330
A.1.560
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 331
A.20.2Develop 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.1.561
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.1.562
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). All interfaces identified must be fully tested in the system and integration testing process, including multiple cycles, as appropriate.
Page 332
A.1.563
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.1.564
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.1.565
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: 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;
Page 333
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.1.566
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.1.567
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.1.568
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; 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;
Page 334
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.1.569
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.1.570
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 335
A.20.3Conduct 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.1.571
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.1.572
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.1.573
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.1.574
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.1.575 Submit System Test Plan to management and obtain formal written approval.
Page 336
A.20.4Prepare 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.1.576
Confirm required physical resources.
Confirm that all physical resources identified in the System Test Strategy are available and ready for use.
A.1.577
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.1.578
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.1.579 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.1.580 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 337
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.1.581
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.1.582
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.1.583 Confirm from the work plan and the check lists that all items have been completed.
Page 338
A.20.5Execute 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.1.584
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; Completion 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.1.585
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.1.586
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 339
A.1.587
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.1.588
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.1.589
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.1.590 Submit system test results to management and obtain formal written approval.
Page 340
A.20.6Execute 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.1.591
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 341
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.1.592
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.1.593
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.1.594
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 342
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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.1.595
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.1.596
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 343
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.1.597
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; Completion 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.1.598
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.1.599 Submit system test results to management and obtain formal written approval.
Page 344
A.20.7Execute 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.1.600 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.1.601
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 Transactions having high risk attributes.
Page 345
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.1.602
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.1.603
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.1.604
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. Benchmarking information for similar systems can be prepared at the site that assists in recognizing acceptable performance of the tested system. System processing statistics,
Page 346
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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.1.605 Submit high-volume test results to management and obtain formal written agreement.
Page 347
A.20.8Conduct 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.1.606
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.1.607
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.1.608
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).
A.1.609
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.
Page 348
Identify any changes in the daily, weekly or period-end processing streams which may improve overall performance or capacity utilization.
A.1.610
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.1.611
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.1.612
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.1.613
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 349
A.21 Realization Checkpoint

Purpose To confirm the results of the Realization Stage of the BW project with management. 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 Realization Stage and these additional tasks are described in the Construction 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. 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 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 350
Realization Checkpoint Task Relationships

S y s I n t e U s e T r a T r a A c c t e m t e g r a t i o n r d o c u i n i n g m n s i t i o n e p t a n c s t m a s e w o t e s t e n t t e r i u p p t e s r k p w o a t i o a l s o r t t d o l a r k n a n a n c u n p l a n
Cd o a n d o mf m e
U 1 p f pi r rm t i hg er S t a n t a
o aCc a R t i oe g e t o i n
oh m p Cl e o t en nf i er m s s e a l id z e a l t i ov ei n r a b l e n
l i z a
t i o
t a
I s s u
U R e
2 v i e
I s s u
I s s u s
r e
s o
l u
t i o
r o
j e
c t
l a
U a
3 t e
r o
j e
c Ut
pP d l a a n t es d
r o
j e
c t
l a
l i t y
l a
U U p d a
4 t e
U l i t y
a t e l a n
l i t y
l a
O R
U 5 b t a i n A p p r o v a l o f e a l i z a t i o n S Rt a e g a e l i z a D e l i v e r a b l e s
t i o
t a
l i v e
r a
r m
r o
v a
i n
Page 351
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.1.614
Check 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.1.615
Check 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.1.616
Check 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 352
Any discrepancies should be addressed immediately and appropriate action taken.
A.1.617
Confirm 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.1.618
Confirm 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.1.619
Confirm 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.1.620
Confirm 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. Deliverables include: 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.1.621 Confirm 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 353
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology If any of these programs and procedures have yet to be developed or finalized, the impact should be addressed and an issue raised. Deliverables include: 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.1.622
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. Deliverables include: Converted data; Created data; Purged data; Reconciliation results; and Approach used and program documentation for any clean-up, creation or conversion programs.
A.1.623 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.1.624
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 354
A.1.625 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 355
A.21.2Review Issues
A.1.626
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 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. Assess the impact of any outstanding issues and reflect in the plans and risk assessment for the next stage.
A.1.627
Page 356
A.21.3Update 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.1.628
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.1.629 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.1.630
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 357
A.1.631
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.1.632 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.1.633
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; Revisiting the original scope to see if scope has changed over the lifetime of the project; Agreeing a revised cost for 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. Formal written approval should be sought for any actions to be taken and plans revised accordingly.
Page 358
A.21.4Update Project Charter

Purpose To ensure that all aspects of planning and quality have been properly addressed. 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 amended or created, as appropriate. In particular, the Project Risk Assessment needs to be revisited.
A.1.634
Review the risk assessment as a result of the Realization Stage experience and the updated project plans for the Final Preparation 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.1.635
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. 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.
A.1.636
For identified threats, document: The likelihood of impact on the project; The severity of the risk;
Page 359
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.1.637
Many areas within the Project Charter may not have been completed in full until this point since they primarily affect the Implementation Stage. Ensure that all these areas have been properly addressed before progressing to the Implementation Stage. Revise the Project Charter as appropriate.
A.1.638
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 360
A.21.5Obtain 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.1.639
Submit and discuss Realization Stage deliverables.
Discuss the Realization 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 the 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.1.640 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. *** FORMAL APPROVAL POINT ***
Page 361
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. Cross-Life Cycle Phases 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 362
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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 363
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 364
System Implementation Task Relationships

P r o j e c t s t a n d a r d s P C r o j e c t s t a n d a r d s u t o v e r w o r k p l a n
V P r e O I n p
1 a m E
r e S y s t e p e r a t i o n s s t r u c t i o n s
V 2 s t a b l i s h P r o d u O p e r a t i o n s E n v i r o n m e n t
c t i o
y s t e
r a
t i o
i n
s t r u
c t i o
R e v i s e d c u t o v e r p l a n P r o d u c t i o n j o b s t r e a m s L i v e p r o c e s s i n g c h e c k l i s
D U
a t a s e r
c o n v e r s i o n d o c u m e n t a
r e t i o
c o n
V c I i ml i a p t T r a n S y
3 il oe s s
Y e a r - e n d p r o nm pe rn o t c a e n d d u r S e y s s t e m t r a n s c o n v f e r T e s t e d S y s t e m O n g o i n g s u p t e m
c e s s i n g m a f e r e r s i o n r e c o p o r t r e s p o n
Page 365
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.1.641
Define 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.1.642
Prepare 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.1.643 Submit 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 366
A.22.2Establish 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.1.644
Finalize 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.1.645
Finalize 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.1.646
Finalize 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 367
A.1.647
Reserve 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.1.648 Obtain formal written approval that the production environment creation meets installation standards.
Page 368
A.22.3Implement 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.1.649
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.1.650 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.1.651
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.1.652 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 System operations instructions.
Page 369
A.1.653
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.1.654
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.1.655
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.1.656
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.1.657 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. 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
Page 370
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology maintenance each year as part of the annual year-end planning process to reflect any changes that have occurred in the interim.
A.1.658
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.1.659 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.1.660
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 371
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 372
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

W 1 o n s i b i l i t i e s r o v i d e P r o d S u p p o r t
i n
r t
s p P
u P c r t o i o d nu
c t i o
s u
r t
c o
c i l i a
t i o
r o
c e
W 2 dV u a r l ei d s a t e L P r o c e s s
i v e R e
B V u a s l ii d a ts e s d n e s u l t s
s y s t e
C S B C
S F s e r v i c e L e v e l A g W S t a t i s t i c s C M S S t a t i s t i c s
r e
m O
e p
tW t i m
3 i z e
T u y s t e m
e U
s e
s y s t e
Page 373
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.1.661
Direct 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.1.662
Manage 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 374
THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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 375
A.23.2Validate 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.1.663
Monitor 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 376
A.1.664
Resolve 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.1.665
Confirm 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 377
A.23.3Optimize 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.1.666
Optimize 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.1.667
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 378
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 379
Post-Implementation Review Task Relationships

P Q P S C O S r o j e c t W o u a l i t y P l a r o c e s s i n g e r v i c e L e o s t / B e n e p e r a t i n g y s t e m D o r k n S v e f i t C o c u P c h l A A n s t m l a n n t Q H P O S N O F u e e n y a p u a l i t y P l a l p D e s k r f o r m a n g o i n g S s t e m R e m i n d a n e r a t i o n a n c t i o n a l n P c e y s q d l R
e d u l e s g r e e m e a l y s i s s e n t a t io n
c e d u r M e a s u t e m T u u i r e m e n C o d i n g S t a t i s t i c e q u i r e m
r o
e s r e s n i n g P r t s S t a n d s e n t s
X E E
1 m 's
v a l u a t e S y s t e f f e c t i v e n e s s
X 2 v a l u a t e S y s t e m 's C o m p l i a n c e w i t h R e q u i r e m e n t s
p r o v e d I n f r a s t r u
P r o j e c t u r e
c t
c o
i r e
t s
l i a
c e
D E
e C
X 3 t e r m i n e P o Lt e i s n t t i o a f l P h a n g e s a n dC o s t S u n h a n c e m e n t s
o m
t e m
n a
t i a l C r y M
h a
a n g t r i x
X S I m R e u b p
4 p l e m e n t a t i o n R e v i e w D
m i t P o s t l e m e n t a t i Po o s t - I m n v i e w D e l i v e r a b l e
Page 380
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.1.668
Establish 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.1.669
Evaluate 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 381
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.1.670
Evaluate 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.1.671
Evaluate 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.1.672
Evaluate 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.1.673
Evaluate 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. If a service-level agreement is in place, measure the degree of compliance with the agreed service levels.
Page 382
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.1.674 Evaluate 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.1.675
Evaluate 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.1.676 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.
A.1.677 Discuss the findings and consider alternative recommendations to address any anomalies discovered.
Page 383
A.24.2Evaluate 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.1.678 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.1.679 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.1.680 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.1.681 Determine compliance with standards intended to prevent information inaccuracies.

Determine compliance with installation standards for: Programming and design standards; Testing standards; Numbering and naming conventions; Maintenance; Service levels; Development methodology usage; Operations housekeeping; User document utilization and maintenance;
Page 384
Training completed; Program change control procedures; Control, balancing and reconciliation procedures; and Tools usage.
A.1.682
Determine compliance with system support service standards.
Determine compliance with installation standards for: Programming and design standards; Testing standards; Numbering and naming conventions; 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.1.683
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.1.684
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.1.685
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.1.686 Discuss the findings and consider alternative recommendations to address any anomalies discovered.
Page 385
A.24.3Determine 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.1.687
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.1.688
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.1.689
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.1.690
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 386
A.1.691
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.1.692
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.1.693 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.1.694
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.1.695 Discuss the findings and consider alternative recommendations for changes and enhancements.
Page 387
A.24.4Submit 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.1.696
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.1.697 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.1.698 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 388

BW Project Plan Methodology

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

BW Project Plan Methodology

Hochgeladen von

Copyright:

Verfügbare Formate

Excerpt from Project Methodology for SAP BW

Data Warehousing and Reporting