BW Project Plan Methodology | Project Management | Data Warehouse

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.

Data Warehousing and Reporting

BW Project Plan Methodology

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 Administrator’s 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

Data Warehousing and Reporting

BW Project Plan Methodology

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

Data Warehousing and Reporting

BW Project Plan Methodology

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 SAP’s Business Information Warehouse product. The objectives of the BW Methodology include: • To develop a business-driven knowledge management solution in meeting The firm’s 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

Data Warehousing and Reporting

BW Project Plan Methodology

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 Administrator’s 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

Data Warehousing and Reporting

BW Project Plan Methodology

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

Prototyping The Prototyping Phase stretches across the DW life cycle. potentially many times. Cross-Life Cycle Phases During the Project Preparation Stage. 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. 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. These include: Change Integration. several Cross-Life Cycle Phases may be started. Data Warehousing Project Abstract The DW Project Abstract provides a high-level summary of the purpose. • An initial assessment of the project risk is also completed. • 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. A Project Charter for the project is also established and agreed between the business users and the project team. separate change integration projects may be initiated or the scope of the DW project may be expanded to address these change issues. where this is appropriate. In certain cases. prototyping may be: • Performed exclusively in one phase. Depending on the development strategy identified and adopted in the Project Start-up Phase. and • Data Conversion Abstract which provides an overview of the scope and complexity of the data conversion effort for the project. Change Integration Change Integration is a Cross-Life Cycle Phase that spans all stages of the DW life cycle. a technology or "proof-of-concept" pilot will be required and. Additional deliverables: • Alternative development options are identified and evaluated. and Technology Planning. requirements prototypes). Opportunities for performance improvement may also be identified in the course of analyzing and developing the DW. As appropriate. • Technology Abstract which provides an overview of the relevant current and target technology environments for the planned DW system. Page 8 . • 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. or • Repeated across the life cycle. • Source System Abstract which provides an overview of the source systems providing inputs to the DW system. a clear agreement on the scope of the project between management and the project team is obtained. All standards. These phases are briefly described in the paragraphs below. Support and Cutover. it may be completed as part of the Technology Abstract definition.Data Warehousing and Reporting BW Project Plan Methodology Project Start-up During Project Start-up. 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.e.. Prototyping. Prototyping may be used in various ways on a DW project such as: • Defining user requirements for the presentation systems (i. A project risk assessment is completed. function and overall structure of the DW system to be developed.

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 .Data Warehousing and Reporting • • BW Project Plan Methodology Proving the viability of a particular technology or suite of technologies (i. Technology Planning. evolutionary prototypes). Support and Cutover Phase identifies support roles and responsibilities for the new system and planning for the procurement.. 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. Support and Cutover The Technology Planning.e. 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. project management and quality management activities are also ongoing for the duration of the project. development and production environments.e. installation and transitioning between the legacy. proof-ofconcept prototypes). Project Management In addition to the Cross-Life Cycle Phases. or Incrementally developing the DW system (i.

Data Warehousing and Reporting BW Project Plan Methodology A. 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. responsibilities. misunderstandings and cost overruns. At the end of each stage. to identify and address scope issues and to conduct appropriate Quality Management Reviews. can benefit from an appropriate degree of preliminary planning. 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. Some sections of the document. Revisions to the plan fall into three broad categories: • Minor changes to static information. The Project Charter is a living document that will be continually updated throughout the life cycle of the project. a major revision of the Project Charter is required and this is the main focus of the Checkpoint Phases. 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 standard contents of the Project Charter include: • Project background • Scope of the project • Project risk assessment and management approach • Project organization and staffing • Roles. The structure established in the Project Start-up Phase is maintained during the Checkpoint Page 10 . there will be a continual need to monitor and report on project status.1 Project Start-Up Purpose To plan for the effective and efficient conduct of the project. 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. The tasks and steps are intended to reduce the risk of unplanned scope adjustments. Overview All of the different tasks necessary to formally begin the project are completed in this phase. The Project Charter is prepared and agreed. All projects. • Major revisions to existing sections. skills required. significantly revised work products. and • The addition of new information not previously recorded. As the project progresses. no matter how small or unique. The scope definition as defined in the proposal and any other contractual documents are formally agreed. Amendments will be made during each stage as changes are identified and the results of quality reviews are included.

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 .Data Warehousing and Reporting BW Project Plan Methodology Phases and the deliverables initiated in this phase are refined as the project moves towards completion.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 t 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 e A 3 v e l o p D l a n s a n d e 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 e n t R o l e s a n d R e s p o n 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 a m o r g a n i z a t i o n D 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 C h a r t e r Page 11 .

2 Determine the business drivers for the DW project Determine the underlying business reasons (i. 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. The mission statement should be clear and concise. • Reactive response to competitive pressure. • Cost reduction focus. • An organizational initiative to gain and sustain competitive advantage through improved management and control of The firm's data resource (e. A.Data Warehousing and Reporting BW Project Plan Methodology A.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. • Supplier performance focus.g. • Customer service focus.. or Page 12 . Overview Effectively managing a project requires a clear.1. false starts and rework of project deliverables. Use Mission statements can: • Focus attention on purpose . or • Integral part of an organizational transformation program.e. For instance. making data more accessible to management or business analysts).. 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).what the project team exists to do. • Convey top management's vision about the purpose of the BW project.1. 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. business drivers) for developing the DW such as: • Proactive action to gain competitive advantage. This step may be accomplished in a workshop or in one-on-one interviews with senior management. • Taxation management/reduction focus. • The move to an e-business model.1. • Provide a foundation upon which strategic plans can be built.1 Define Project Mission Statement Definition A mission statement defines the overall purpose of the project. A. • Profitability focus. inspiring and motivating the team.

and • Driven top-down by senior management or proposed by lower level functional or operational managers. In determining the project drivers.g. it is also useful to determine whether the DW project is: • An organization-wide effort or focused on selected business segments..Data Warehousing and Reporting • BW Project Plan Methodology An organizational effort to integrate and share disparate data (e. as the result of a business merger). Understanding the business drivers helps in defining and focusing the objectives and scope of the DW project. Page 13 .

individuals with key understanding of the business.  project personnel assignments. • Ongoing. • Information systems personnel . and • Technology personnel . Consider the following types of personnel for membership of the GRT: • Senior management . • Project coordinator (e.1.depends upon whether management wishes to delegate steering committee roles or function in a "hands-on" mode. 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. • Establish the checkpoints at which the GRT should review deliverables.representing database administration.Data Warehousing and Reporting BW Project Plan Methodology A.3 Agree project management structure. • 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.with detailed understanding of the new technology and its impact on The firm.representing major functional areas. and  project deliverables. In addition to defining the management structure of the project. and • Identify and assign any key user contacts for the project. • Key end-users . operating and setting policy for the proposed DW system. Management roles will vary by project and as such need to be clearly defined at the outset of the project. especially for:  project schedule.1. If the project is to be directed or guided by a Guidance Review Team.g. Ensure that the GRT has representation from all of the business functions involved in using.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. • Guidance Review Team (GRT) members.. and Page 14 . project producer and director roles). assist management in establishing the committee. this task addresses the creation of project management standards and working procedures needed to support the agreed structure.  project standards. A. data administration. Identify key individuals to fill roles within the project management structure including: • System/application owners. • Establish the mechanisms by which the steering committee communicates to senior management and to the project members. operations management and applications development. day-to-day maintainer(s) of the system.

Identify all of the appropriate techniques and forms to be used including: • Issue Resolution. Agree any variations with management. • Test Problem Report. Define the scope control methods for the project. Identify and agree the key user contacts in the organization. Include: • Internal reporting to the project manager and within the project team.g.4 Confirm approach to be used for scope management and project issue resolution. and they should be included on any project-wide communication or e-mail group lists. if the project is to be managed through a senior management organization position. Page 15 . Define expected reporting periods and report contents for the project team. define the procedures by which it provides approval.1. This contact is critical in order to ensure a smooth cutover.5 Define frequency.Data Warehousing and Reporting • BW Project Plan Methodology If the steering committee is functioning in an approval mode. • RFC (Requests For Change). • Reporting to the Guidance Review Team. Define procedures for managing System Change Requests and Issue Resolutions. • System Change Request Log. Alternatively. and • Walk-through Worksheet. and • Formal approval points. Define the roles which any third-parties will play (e. • Issue Resolution Log..1. Define the different types and levels of severity for Test Problem Reports and how each level will be addressed and managed. suppliers or contractors) and the appropriate responsibilities for their liaison and their management. A. • System Change Request. A. Initiate and maintain communications with the Functional Analysts and the Production Support Lead. • Test Problem Report Log. • Reporting to senior management. • CAB Process. this reporting line and accountability is established and agreed. dates and formats for progress reporting. the role they are expected to play and the amount of time their expected involvement in the project will require.

3 Develop Detailed Work Plans and Schedules Purpose To identify the phases. the higher the risk. Also assess whether the organization is used to managing projects of a similar size or whether the project represents a significant increase in size.1. Additional schedules may need to be developed to identify other items such as deliverable dates. A risk assessment is completed if one has not been completed earlier. to assist in estimating the project duration and to determine the resources needed. A. tasks and steps to be used to successfully complete the project and the degree of risk associated with the project.1. will have a ripple effect on the overall project duration or scope. data modeling.7 Evaluate risks associated with experience with the technology. milestones. the more new items that will form part of the development. test and production IT environments. A. Consider the risks that may arise due to unfamiliarity with new technology. • Length of the payback period. The database technology knowledge of The firm's IT and non-IT staff (e. Notes Application • Common Design Page 16 . the categories of risk remain reasonably constant. which may then increase the project risk. acceptance and success of the DW project deliverables. • Number of sub-projects..1. Support Packages. and • Number of geographic locations involved.g. • Number of user departments affected. Identify the components of size that are appropriate for the project. • Time-oriented business constraints. concepts of data administration. however. Generally. if delayed.6 Evaluate risks associated with project size. Overview This task is concerned with defining the detailed activities to be completed to provide a framework for confirming project scope. project review meetings and quality review meetings. 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). data replication and data warehousing) may hinder the development work. • Project team size. 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. • Total anticipated elapsed time. then consider the following integration points: • BW Environment Management • BW OSS. The definition of what constitutes a high risk will vary with the technical sophistication of the organization.Data Warehousing and Reporting BW Project Plan Methodology A. Potential components to assess may include: • Total budgeted hours. A critical path schedule should be developed to highlight tasks upon which other tasks are dependent and.

During the process of developing project work plans. Risk increases on projects where the system requirements cannot easily be defined or validated at the commencement of the project.1. Where tailoring of the Page 17 . A. 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.Data Warehousing and Reporting • • • • • • • • • • • • • • BW Project Plan Methodology 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 .Testing Strategies Performance Testing Integration Testing Training Development / Documentation Standards BW Project Unique Training Consistency of Deliverables Ownership of Common Data . A. This type of risk relates to the structure of the project and can be assessed by considering: • Degree of organizational change involved. A. • Increasing the project resources and/or budget. • Reducing the project scope.1. constraints are enforced and risks are identified along the critical path.9 Summarize the risk assessment. constraints and risks. • Reliance of the DW system on other feeder or support systems. and • The general attitude of the users.12Develop overall project work plan. A.Short-term / Long Term .1. or • Providing more resources from the organization. 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.1. Compare the figures for each component to the average size of projects undertaken by The firm and/or by the system developers. Determine which of the detailed work tasks and steps will be required for the project. The validity of the work plan is governed by these boundaries. • Senior management commitment.10Determine what methodology tailoring is required. • Impact on existing methods or procedures. Identify and document these items as support for the work plan. Alternatives may include: • Extending the project time frame. Discuss any alternative suggestions with management and agree on the approach to adopt. assumptions are made.1.8 Evaluate risks associated with the project structure.CC/WBS Hierarchies BW Design Architecture A.11 Identify project planning assumptions.

Identify the need for supporting schedules such as: • Project team staffing plan.16Conduct quality review of the work plan.1.Data Warehousing and Reporting BW Project Plan Methodology standard BW Baseline is required. discuss and agree and then incorporate the changes in the project work plan. Page 18 . Develop detailed work plan(s) for the Project Preparation Stage. external supplier staff and other third-parties. project critical path activities. • Sub-project work schedules.13Develop detailed project work plan(s) for the Project Preparation Stage.15Develop supporting project schedules. the User Documentation Phase. Address such issues as: • Identify work products related to each task/step.1. the development of the strategies and plans should be completed in the specific phases listed above and consolidated in the Checkpoint Phases. • Prototyping. A. In practice.14Develop approaches for Cross-Life Cycle Phases. A. • Highlight on a separate schedule or as part of the work plan. Define the content and completeness requirements for each deliverable where they differ from the Baseline deliverables. • Identify critical path activities. Approaches should be specific for the following phases: • Technology Planning.1.1. • Identify dates for status meetings. • Third-party resource and work schedule. • Identify dates for review and acceptance of work products.. tasks and steps as defined in the Baseline. these approaches will be refined into strategies and plans for implementation. • Change Integration. A.g. Complete a quality review of the work plan and make any adjustments where necessary. 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. and • Balance the resources and project schedule so that the completion date is acceptable and the required resources are within the staffing capacity. e. • Calculate level of effort by task and/or time period for all resources including contractor staff. • Arrange for an independent review of estimates. Adjust the scope of the project to meet these requirements as necessary. and • Contractor resource and work schedule. Support and Cutover. During the subsequent stages of the project. A. Derive and present the work products in a hierarchical task structure within phases. • Resource use schedule. 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.

Submit the plan to the Guidance Review Team and/or management and discuss the contents.17Review and agree work plan with management. Resolve any questions and issues and. This step may involve more than one meeting. Page 19 . if necessary.Data Warehousing and Reporting BW Project Plan Methodology A. modify the plan.1.

The staffing requirements for a BW project varies based on which stage the project is currently in.g. Staffing and Logistics Purpose To identify suitable staff to undertake the project.Data Warehousing and Reporting BW Project Plan Methodology A. Project team facilities are defined and obtained..1. The following exhibit shows a recommended approach: Page 20 . to identify project team training requirements and to ensure that all logistical arrangements for the project resources have been defined. 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. e.4 Finalize Project Team Organization. Overview Staff with appropriate skills are identified and assigned to the project and the training requirements for each project team member are defined.

Data Warehousing and Reporting BW Project Plan Methodology 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 Administrator’s Workbench Specialist ABAP (custom SAP extracts. routines) Page 21 .

• Clerical/administration support. • Confirm the need for any specialist skills. and • Determine availability of staff. • Security access. both by discipline and number. hardware or software suppliers).1.18Confirm project team organization and staffing commitments. • Determine staffing to be provided by contractors and other third-parties (e. A. furniture.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. Carefully define the skills and resources required.19Prepare individual work plans for each project team member. Derive the team organizational structure and staffing requirements: • Develop a project organization chart defining the lines of responsibility and the roles of all participants. Determine which additional facilities will be required by the project team including: • Office space/supplies. • Telephones/telephone lists/electronic mail/voice mail/video conferencing. where relevant. Page 22 .g. A.1. • Assign the tasks and deliverables to specific personnel and publish job assignment lists. for each member of the project team ensuring that the skill mix is carefully matched to the project needs.1. • Identify training needs for project staff. No work step should be greater than 80 hours in duration for each team member. storage. photocopiers and facsimile machines.. Prepare individual work plans for each project team member. and • Computer equipment including networking needs and access.20Arrange for facilities and resources required by the project team.

• Scope management definition. • Project standards cross-reference.22Confirm completeness of the Project Charter.1. • Schedule and deliverable samples for reporting progress. 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.21Create Project Charter for the project. Obtain approval and distribute the Project Charter.g. implement any corrective action required and agree the quality assessment schedule. • Defines the standards.1. discuss and agree a Project Charter. • Project work plan. • Staff assignments. • Defines the management procedures under which the project will operate. Submit the Project Charter for assessment. • Assigns roles and responsibilities to specific individuals.1. A. critical path schedule). The work plans are reviewed at this point to confirm that the quality review points identified are sufficient. methods and tools the project will use. • Project team organizational structure. • Project management organizational structure. • Detailed work plans. Page 23 . before approval of the Project Charter is obtained.. • Project schedules (e.5 Develop Project Charter Purpose To develop. 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. Include in the Project Charter such items as: • Scope document.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. A. Overview This task is largely one of collating the earlier task deliverables and checking them for internal consistency. • Organization quality measures. • Work product and pro forma schedule. The aim is to provide a single source plan that: • Incorporates a work breakdown structure for the project. and • Project quality review checklist(s).

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. • Balancing/reconciling existing data. This may include: • Purging/cleansing existing data. 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). customer systems. The project requirements are captured in a Data Warehousing Project Abstract consisting of the following major components: • Data Abstract. and • Converting existing data. Page 24 . and • Data Conversion Abstract. In these interviews. It is derived primarily from an understanding of the existing system and from interviews with users concerning the proposed system.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. • Source System Abstract.2 Data Warehousing Project Abstract Purpose To scope the BW project based on a high-level understanding of the data. The Management Overview Diagram is the technique used for this graphical description together with some narrative describing the processes. the functions of the proposed DW system and provides an initial boundary for the scope of the project. The Technology Abstract documents the current technology environment as well as the proposed technology environments for the new system. • Creating new data. Overview The Data Warehousing Project Abstract provides a high-level summary of the purpose. any existing or new areas for which data will need to be recorded should be defined. The proposed environment will often be based on the current environment supplemented with the planned implementation of any new technologies. The Process Abstract graphically describes the potential key processes of the system and clearly identifies the scope of the project. function and overall structure of the potential business analytical processes to be investigated. 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. 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 Data Abstract is a high-level overview of the key data and system relationships. The Source System Abstract provides an overview of the source systems relevant to the scope of the DW project. The focus is to align the DW system development effort with The firm’s business objectives. • Technology Abstract. • Process Abstract. process and technology requirements of the proposed data warehousing system. syndicated data systems or business partner systems. It defines in general terms. 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 systems include not just internal systems but also any relevant external supplier systems.

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. • To demonstrate the connectivity and compatibility of the proposed hardware and software components. The completed Data Warehousing Project Abstract is presented.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology Depending on the specific project circumstances. Page 25 . discussed and formally approved by senior management. Alternative approaches to developing the DW system should be identified and evaluated to select or confirm the most appropriate development approach to use. high-level Cost/Benefit analyses for the alternative approaches may be completed to support the evaluation process. • To simulate performance/capacity definition before embarking on a major project. 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. As needed.

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 a n c e M e a s u r e s 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 o 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 a n l a a g t i o e n m e n t O v e r v i e o l f S w o D u i a g r a S m 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 D 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 u P r o j e c t R i s k A 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 .THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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 .

current business practices and how the proposed system will fit into the operations of the business process. at the business process level. 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.1.2. if necessary. A.24Identify CSFs.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. the following steps may be sequential or may be accomplished in parallel. and • Scope of the project. • Performance measures for the eventual system. all of the steps may be able to be completed in one meeting. 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. The CSFs are essential circumstances or conditions that have a major influence on whether a particular business objective is achieved. define the objectives and goals of the area of the business under investigation. A. Depending on the scope of the system and the number of senior management executives to interview. Gain an understanding of the organization. they should be developed by the organization's management.23Interview senior management. CSFs assist in defining the: • Factors in the business that the eventual system must support. 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. 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. Page 27 . Discuss and confirm with the users those problems they anticipate will be resolved by the introduction of the new system.1. Specify how the proposed application is expected to assist in achieving these business objectives in the form of CSFs for the application. Document what the users expect of the new system. If CSFs do not exist within the organization. For a small system.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. Document current system problems by producing a list of the problems and deficiencies with the current system. Overview CSFs are the essential circumstances or conditions that have a major influence on whether a particular business objective is achieved. Review and. • Events that the eventual system must support. as well as any indication of budget constraints for the project.

e. Additional details useful to capture include any constraints related to the implementation of the CSF. The performance measures should specify "what" needs to be measured and the targets should define the acceptable range of results for the CSF. A. Associate with each business process CSF one or more performance measures that can be used to identify constraints and/or targets to be achieved. A.. Page 28 . although this could also be specified as a performance target such as staff size 10-25. modify the CSFs.26Discuss and obtain approval of the CSFs.1. they must be capable of measurement. i.25Define performance measures and targets for the CSFs.g.. Review the CSFs with senior management and confirm that they are correct and that the performance measures and targets are appropriate. if necessary.e.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. This step may require more than one meeting.1. the number of staff involved in a particular process cannot exceed 25. Resolve any questions and issues and.

THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A.e.. the Management Overview Diagram). • Ensuring that each entity is clearly distinct and different from other entities.e. Define potential kernel entities through interviews or reviews of current systems documentation. each of which has schedule dates attributes. it is not dependent on any other entities). A. computer reports. paper forms or documents or other output-related objects are usually not entities. modeling and managing the scope of the DW project. and • Data modeling approach.. The primary uses of a Data Abstract or an ERM on a DW project include: • Project scope definition. 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. things of significant interest to the business). Page 29 . • Management communications. the Logical Data Model (LDM) and the Multidimensional Data Model (MDM). if the entity ORDER LINE depends on the entity ORDER. they may be included on the ERM. unique and logically describe the object in accordance with established data naming standards and conventions. and • Removing from consideration any entities that do not clearly have many occurrences (e. consider: • Differentiating between entities which are dependent on other entities and kernel entities which must be able to stand alone (e. the Source System Abstract and the Data Conversion Abstract in defining the scope of the DW project. An ERM may be used in conjunction with the Process Abstract (i. at a high-level.. A kernel entity is a primary business object or concept that can stand alone (i. credit agency). e. Some typical examples of kernel entities include CUSTOMER. the accounting department. An ERM provides a business focus in developing the DW as it reflects the significant data entities and their relationships from a business perspective.2. business-oriented data model. and • Relationships among these entities. • Removing any entities which do not represent business objects or concepts. SUPPLIER and PART. The name of each entity should be singular.g..g.. an organization's business rules in terms of: • Kernel entities (i. Assign a descriptive name to each entity.g. It provides a foundation for developing other lower level data models such as the Conceptual Data Model (CDM). 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. An ERM is the highest level data model that may be developed on a DW project.. An ERM is a high-level definition of an organization's data resource from a business perspective and captures. it provides an effective vehicle for communicating with management various project issues such as project scope and business understanding.e.27Define kernel entities. If the non-kernel entities are of significant interest to the business. • Business foundation. it is not a kernel entity).1. Things such as listings. In defining the kernel entities.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. Because an ERM is a high-level.

28Establish relationships between entities. a PURCHASE ORDER is placed with a SUPPLIER. Thus. formal business rule analysis is not completed until the development of the CDM. organization... A relationship name should be an action verb depicting the role of the relationship. the relationship should be read as "a PERSON drives a CAR" and in Exhibit B-1b. 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. • {relationship name} (e. The sentence structure formalism may be used to describe a relationship as follows: • Each {first entity name} {must/may} (e. use the clockwise convention to indicate the direction the relationship on the ERM.g.g.g. "terminates at"). "Each FLIGHT may"). Determine the relationships between the entities. names should be given to relationships on the ERM in only one direction. kernel entities and their relationships are determined simultaneously as an integral process. Model each entity as a rectangular or oval box containing the entity name on the ERM." In general.. Considering entities as nouns. in Exhibit B-1a. In practice. project name and date of preparation.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. this step is completed concurrently with the steps discussed above in identifying kernel entities.29Model the entities and entity relationships on an ERM diagram.1. While the definition of an entity relationship is a form of business rule representation. Include appropriate administrative information such as title.1. If the entity relationships are named. Prepare a textual description of the relationship as needed to further explain the meaning of the relationship.g. and • {one/many} {second entity name} (e.. Page 30 . Add the identified relationships to the ERM by connecting the rectangular boxes representing the related entities. A business rule sentence structure may be used in guiding the identification of entity relationships.g.. A. e. the relationship should be read as "a CAR is driven by a PERSON. Name and describe the identified relationships. PURCHASE ORDER and SUPPLIER are the entities and is placed with is the relationship). "many AIRPORTS").

Based on the knowledge of the organization's business gathered on the project. Page 31 . • Include other entities and relationships associated with a particular kernel entity in the corresponding subject area. identify initial subject areas as natural divisions of an enterprise focusing on the major resources or activities of the enterprise. The definition of the subject areas should be completed using business terms familiar to users and management. and • Review and refine the subject areas. Document and define each subject area identified. modify the contents. A. Resolve any questions or issues and.30Identify the subject areas.31Discuss and agree the Data Abstract.1. if necessary. Discuss and agree the content of the Data Abstract.1.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. Starting with the ERM: • Identify the kernel entities as the initial subject areas.

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 list should be small and should focus on the departmental heads of those business units addressed by the CSFs. Prepare a list of management and selected key users and schedule interviews with them to gain an overall understanding of the proposed system.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. A.34Confirm discussion results. 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. 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. This is particularly useful when some interviews have to be conducted by telephone. Confirm the interview results in meetings.32Prepare for user discussions. Develop a standard interview questionnaire to ensure a common approach to the interview process. To develop this understanding quickly.33Conduct user discussions and summarize results.1. and • A list of excluded processes. A. Organize and document the information obtained at the interviews. This should be a very brief process because the primary feedback mechanism will be the Process Abstract. A project scope definition is derived that provides both a framework for assessing the development options and for determining the development workload. Complete the discussions with the appropriate user representatives to ascertain the essential processes of the system.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.1. 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. Page 32 . discussions or documents to help ensure that they accurately reflect the processes of the current system and those required in the new system. not the interview results. 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. A.2.1. At this point.

if necessary. modify the contents. Discuss and agree the content of the Process Abstract.1. Assemble the results of this task into a Process Abstract document in both graphical and narrative form. Page 33 .35Discuss and agree the Process Abstract.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. Resolve any questions or issues and.

THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. For each of these systems. • System/data distribution characteristics. Develop a list of the internal and external systems that are outside the scope of the project. A. Identify the relevant SAP and non-SAP source systems that provide inputs to the proposed DW system. • An Interface Abstract which shows further levels of details for the different interfaces shown on the MOD(s) e..g. In addition to the internal source systems. Develop an overview of the source systems capturing such characteristics as: • Ownership of the systems. • Customer data/systems. • Source system technology.2.. both internal and external.36Identify the source systems relevant to the scope of the proposed DW system. or • Business partner data/systems. • Media of the source data. relevant to the scope of the DW system to be developed. • Volumes. through the use of software reengineering tools) and/or co-exist with the different legacy systems (in modified or unmodified form) after implementation.37Identify the systems that are outside the scope of the project.1. A. 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. 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. Develop Management Overview Diagrams of the relevant source systems and interfaces. as appropriate. the relevant external data/systems should also be determined such as: • Forecast data/systems.4 Prepare Source System Abstract Purpose To identify and provide an overview of the source systems.1. and • Costs of capturing and transferring data to the data warehouse.g.1. A. • Supplier data/systems. an interface may be shown as a single item on the MOD but may be composed of different sub-systems and programs. 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. and Page 34 . These relationships and boundaries should form part of the Source System Abstract together with brief narrative describing the intended approach to the legacy systems.38Develop an overview of the source systems. The DW may use existing legacy system components (e.

g. It is important that the estimated volumes of data to be processed are also included as part of this Abstract.39Assess the impact of the source systems on the DW system. where additional software or processing is required to generate outputs from the BW system via ODBO or downloaded from the InfoCube. A. Review the Abstract with management.. Assess the impact of the source systems on the DW system. statements of items/areas that are specifically excluded from scope may also need to be prepared.40Review Source System Abstract with management.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology • A 3rd Party Report Tool Abstract which shows details of report production at a high level e. Obtain formal written management approval of any changes in the original project scope. As well as what is included within the project scope. Assemble the source system descriptions into a Source System Abstract in both graphical and narrative form. Revise the Abstract as appropriate. Discuss and resolve any outstanding issues. Revise the project plan as necessary based on the review of the source systems and their assessed impact on the project. A. Page 35 .1.1.

Web servers. This task provides an understanding of the level of effort required to conduct the detailed technology tasks in the Technology Planning. network and tool compatibility). Application servers. detailed study of all of the technology components of the new system. legacy systems. • Data communications protocols.2.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. relational OLAP or multidimensional OLAP). A. 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. 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. Produce a current system technology schematic showing the main technology components included in the current system (e. processing timetable and frequency and response times. • Hardware platform. Database servers.1. • Determine whether all components as defined in the Technology Abstract will work in conjunction with one another (e. OLTP systems. Overview The Technology Abstract documents the desired technology components and describes the technology environments for the new BW system that. 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. Page 36 . staging and production environments. state. or new supporting technology components are incorporated into the architecture environment. A. building. If a new version of BW is to be implemented. Note: The Technology Abstract is a high-level view of a proposed technical architecture.41Analyze the existing systems. floor) and any interconnectivity between platforms. back-office systems such as financial applications. These characteristics may include: • Software/application class (e. Indicate on the schematic where the various components currently reside (e. nation. 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. • Begin the organizational training in the use of different components of the proposed technology architecture including any new or emerging technologies.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.... • DBMS/file organization.g.g.g.g. operating system.42Determine the need for a Technology Pilot. 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. hardware. region. • Begin the definition of technical support resources required. should include development. at a minimum. and client machines).1.. Support and Cutover Phases.

g.g. and Organizational unit (responsible for the respective DW level/layer). A. This may also include some discussion of any items/areas that are specifically excluded from the project scope. Discuss and resolve any outstanding issues. Name of application system (e. it may be useful to treat the pilot as a distinct sub-project that is proposed for and managed separately from the main project.. determine the need to test and validate the proposed environment through a Technology Pilot. LAN/WAN or Internet/Web).THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology • • • • Information delivery channel (e. Revise the Abstract as appropriate. the reasons for the decision and a work plan for conducting the Technology Pilot. Review the Abstract with management. Assemble the technology information into a Technology Abstract in both graphical and narrative form. Page 37 . With an understanding of the proposed technology environment.. 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. Review with management any open issues such as obtaining agreement for an appropriate technology infrastructure and/or the need for a Technology Pilot. Location (where the respective DW level/layer resides).43Discuss and confirm the Technology Abstract.1. Document the decision. SAP package).

Ensure that further investigations are included within the scope of the Project Preparation Stage. Page 38 .THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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.

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.2.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. and • may be run multiple times until reconciliation shows a valid conversion. 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. e.. 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. • Current data may need to be purged. Data Conversion Management There are a number of management issues to address for data conversion projects. data cleansing or creation may precede other tasks by several months. automated or both: • Logically. phased or staged implementation where progressive data conversion is required. and Page 39 . The conversion of data from a source system usually requires the creation of a conversion system.g. Overview Data conversion is accomplished through manual and/or automated means and includes the creation of any data needed for new data records. • Creation of new/additional data. • 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. conversion is taking data from one system and moving it to another system at a point in time. and • Conversion programs may be run more than once: • may be run multiple times with each execution converting a subset of data. corrected or verified. Depending upon the size. It enables the new system to accurately reflect the current status of organizational data at the start of production.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. In addition to the normal problems of system development. and • Timing of the data conversion process may vary. This is typically the one-time data load of legacy system data that will not be converted to the BW system. • may be run multiple times for parallel running. This may require specific detailed IS technical knowledge of the current system and will certainly require input from experienced business users. • Reconciliation/balancing of the old data and the old system/new system. • Conversion may translate the format of the data but not update it. • The existing system (manual or automated) may need to be corrected or balanced within itself before conversion can be commenced or completed. data conversion has several unique requirements: • Data may need to be created if it does not exist. scope and duration. • Specific programs may need to be written to either identify missing or invalid data in the existing systems or to correct data. The conversion system can be manual. such as one calendar month.

• The capabilities of the source systems in generating the conversion data. determine the appropriate methods and approaches for converting data in multiple cycles (and in multiple locations) over extended time frames. manual conversion methods may be appropriate. Validate any assumptions made in estimating the scope and level of complexity of the data conversion effort. signed-off by senior management. "dead" system data).46Determine the scope and complexity of the data conversion effort. 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. During data conversion clean-up. Review the existing data to determine the condition of the data.45Determine conversion method and approach. Alternatives may include: • For simplistic. Page 40 . whether it has been regularly reconciled and balanced. • For conversions requiring source data from multiple production or legacy systems.44Determine the condition of the existing data. data may be found that is incomplete or incorrect. A. Based on the understanding of the source systems.. This has even greater significance where these adjustments affect statutory financial statements. determine the scope and complexity of the data conversion effort considering factors such as: • The source data that requires a one-time conversion (e.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology • The timing and duration of the project may differ (as discussed above). Determine the appropriate methods for converting the data. 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.g. • The quality of the source data to be converted. Discuss with IS management and staff to clarify or resolve any outstanding issues. 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. At the conclusion of a data conversion project. or • If a staged conversion process is an option.1. • The manual data entry requirements. A. • The current data needs to be corrected or its quality improved. low-volume record conversions. 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. a more complex automated conversion approach may be derived. This then may require adjustments or write-offs that need senior management and internal/external audit approval. complex and involve large volumes of data. and • A separate project team is required to address the data conversion management. A. there must be formally approved documents. and • The capabilities of the data transformation system that could be used for one-time data conversion purpose.1.1.

Revise the Abstract as appropriate.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. Discuss and resolve any outstanding issues. Review the Abstract with management.47Discuss and confirm the Data Conversion Abstract. Page 41 .1. 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.

DW development often follows an iterative and incremental approach. Examine the information collected to this point.starting by developing a high-level enterprise or subject area DW framework to guide the incremental development of the data marts or DW.1.. • Technology Pilot(s). on a DW program where there may be multiple DW projects. multiple development options may need to be defined. Financial and Non-Financial Performance Measurement. • proving the viability of a particular technology or suite of technologies (i. This task may be completed to define one development option for a DW project or. This approach may encounter difficulties in integrating data from an enterprise perspective.starting by building an enterprise DW from a subject area perspective and then gradually moving subsets of data to data marts. Product/Volume Reporting.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A.2. For example. Data marts contain subsets of informational data of interest to users in certain organizational units or geographical locations. In a BW environment. • Bottom-up .e. Overview The various approaches to developing the proposed DW system are determined and evaluated. Product/Volume Analysis. or • incrementally developing the DW system (i. The results of this evaluation are reviewed with management and the most appropriate course of action is selected.e. or • Bottom-up development with a top-down framework ..what technology components to include.e. This approach may take a longer time to implement. As illustrated in Exhibit B-3.starting by building data marts to quickly provide data to users.. proof-ofconcept prototypes). a Product DW program may include several DW applications such as Product/Promotion Planning. which subject areas to address and within what time frames Page 42 . 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 . 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. iterative development should be planned along three major dimensions .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. these may consist of more specialized InfoCubes. evolutionary prototypes).48Define the system development options. Prototyping as an approach for: • defining user requirements for the presentation systems (i. A. requirements prototypes). A high-level Cost/Benefit Analysis is completed for each option considered feasible.

49Refine the system development options. 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.51Prepare a Class 1 Estimate. as appropriate. implementation time scales or support levels. Document the rationale for this exclusion. For the remaining options.. Provide an initial estimate for each viable system development option that defines the potential development. A. implementation and maintenance costs. Page 43 . Refine the options as necessary to obtain a better fit of requirements and expectations.g.. e.50Define the system development approach.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A.1. Document the rationale for the selection. a custom development may fully meet the defined requirements but may be totally unacceptable in terms of cost.g. Define the system development strategy to be adopted. Prepare a high-level Class 1 Estimate of either the chosen alternative or several of the alternatives. e.1. estimate the degree to which the approach would both fulfill the requirements and meet expectations.1. A. Discuss the different system development options and exclude options that are unacceptable or inappropriate.

make any changes. A.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology Compare these estimates against the anticipated benefits from implementing the new system. Page 44 .53Discuss and confirm the recommended system development option. Discuss each alternative system development option to ensure that the evaluation process has been thorough and includes all pertinent facts.1. This step may require more than one meeting. following the agreed option. 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. 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. Wherever possible.1. if necessary.52Recommend a system development option. Agree the selected option and obtain formal written approval from management to continue the project. the users of the system should be assigned responsibility for providing details of the anticipated benefits from the proposed system. Resolve any questions and issues and. A. Review the analysis of the recommended system development option with management.

Complete an initial risk assessment if one has not already been completed. synchronization and update processes.g. 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.  need to procure additional technical architecture components adding risk to project cost. A. false starts and rework of project deliverables.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. precise understanding of the scope and objectives of the project. The Data Warehousing Project Abstract deliverable provides the high-level understanding of the system.54Assess project risk. • Data issues/risks such as:  general level of data quality. and • Technology issues/risks such as:  learning curve of the project team in using the data warehousing toolsets.1. 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. either some functions may be deleted or the Page 45 .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. Where the project risk is perceived to be inappropriate. it is essential to confirm the project scope and deliverables with senior management before commencing the detailed analysis.  impact of the DW on organizational communications and decision making processes.. it cannot compensate for missing controls in source operational systems.2. if the project is too large. or  availability and accuracy of documentation of required source data and reporting systems. or  ability of the architecture to accommodate update cycles and incremental requirements of the data warehouse.  data ownership and distribution issues.  inconsistent codes or abbreviations across data sources. convert and standardize inconsistent codes or abbreviations across data sources. Consider: • Business/organizational issues/risks such as:  availability and accessibility of data. A standard codes repository and decode procedures may need to be developed to decode.  non-uniformity of data maintenance and update. As there may be a period of time between proposal submission and agreement to proceed with the project. 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. changes may need to be made to the original project scope. This may potentially add complexity to the data integration. Effectively managing a project requires a clear. or  staff training issues. While a DW system may augment and format data for analysis. effectiveness and schedule. e.  adequacy of initial analysis of end-user tool requirements and impact on flexibility and overall applicability of the toolset.

1. Using a structured walk-through or presentation approach. A.55Assemble and review Data Warehousing Project Abstract deliverables. A.56Submit and walk-through the scope deliverables with management. Alternatively.57Obtain formal written approval of scope document.1. *** FORMAL APPROVAL POINT *** Page 46 .1. Document any assumptions made during the preparation of the Data Warehousing Project Abstract. project sponsors. Resolve any questions or issues. including project team members. A. steering committee members and some key stakeholders must understand the scope document and agree to its components. 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. The initial scope document is critical to define the boundaries of the project for level of effort analysis purposes and project scope control. present the scope deliverable to management for review. Ensure that interim work products have been approved by the appropriate stakeholders and any updates incorporated.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology project broken into several smaller projects. project staffing or funding may require changes. 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. All key personnel.

THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. must align technology with the organizational structures and business processes. These are the strategic changes associated with the management of knowledge and business information across organizational boundaries addressing issues such as competitive drivers. many of the change integration tasks discussed in this phase may themselves be separate organizational initiatives or projects. the project team must bring to the attention of management any significant change integration issues identified. Thus. As an organizational initiative. an organization's data resource is often not managed from an enterprise-wide. more importantly. While. There are many areas within an organization that can benefit from sharing the same piece of data. The scope of a typical DW project often does not include addressing change integration issues. the focus of this phase is on determining the impact of implementing a DW on the organizational structure. to truly manage data resource as an organizational asset. rather it is maintained by individual organizational units to meet local business needs. However. in practice. procedural and cultural changes. and • Changes at the organization's tactical level. information or knowledge. knowledge transfer. Page 47 . separate change integration projects may be initiated or the scope of the DW project may be expanded to address these issues. 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. However. responsibility and technology of the data resource management program. To obtain the greatest value from a DW development initiative.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. These are the changes associated with developing an information architecture that promotes and facilitates information sharing within an organization. Furthermore. authority. 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. Any scope changes must be discussed with management and formal written approval of the changes obtained before any work commences. strategic perspective. it must be an integral part of a broader organizational knowledge management program which does not only address technology matters but. additional improvement opportunities may be identified in the course of analyzing or developing the DW. Many change issues must be addressed at the tactical level such as the organizational structure. As appropriate. the roll-out of a data warehousing program must be carefully planned addressing various organizational issues such as stakeholder interest. Thus. training and technical support. these issues are often critical for the ultimate success of a DW program. strategic opportunities and organizational structural. business processes and other technologies and the improvement opportunities which a DW offers.

THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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 D e C 2 v e l o p ( o p t i o C n a h l ) a n 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 n s t r a t e g y C I n t e g 3 r a t e C h a I m p l e n g e s m e n t e d c h a n g e s Page 48 .

. selling "data" as a product). and • New business opportunities (e.e. sharing inventory data with a primary supplier to facilitate replenishment of inventory stock). i. improving the organization's business analytical capabilities) enabled by making data accessible and shareable by the organization's information users. Page 49 . and • To identify business opportunities (e. 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. and • Interorganizational alliance opportunities (e.1 Assess Data Warehouse Impact on Organization Purpose To assess the impact of the DW system being developed on the organization.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. Overview This task determines the impact of implementing the DW on the organization. organizational delayering as a result of more timely availability of management or performance measurement information). Assess the impact of implementing the DW on the organization's current or target business processes..g..1.g. Focus on improvement opportunities enabled by the DW such as: • Business process reengineering. The facilities may be impacted by the organization structure changes such as the physical relocation of personnel. A.g. the impact of the implementation of the DW on different individual jobs and positions including changes to existing positions. There are two primary objectives of this task: • To ensure the success of the implementation and roll-out of the DW program.60Assess data warehouse impact on technology and facilities infrastructure.1..1. Assess the impact of implementing the DW program on the organizational structure considering issues or opportunities such as: • Organizational job changes. addition of new positions and the deletion of existing positions.. • Organizational restructuring (e.. 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. • Workflow integration. new switchboard/telephone system).58Assess data warehouse impact on business processes. customer relationship banking enabled by the availability of a centralized DW to show all of the relationships which a customer has with the bank. redesign of office layout or acquisition of new equipment (e.59Assess data warehouse impact on organizational structure.g. A. • Organizational changes to implement a centralized data resource management program in support of the DW initiative. • Changes to physical locations of employees.3.g.

Evaluate the impact findings and identify any significant issues or opportunities.1.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. Page 50 . 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.61Evaluate the impact findings. Determine what actions need to be taken to remove any barriers and to ensure the successful and effective implementation of the DW systems.

Determine the feasibility of each of the potential change actions.1. A.1.66Develop change plan.64Analyze feasibility of change actions.1.2 Develop Change Plan (Optional) Purpose To develop the change implementation strategy and an integrated change plan.62Develop implementation strategy. A.3. Identify the changes that will need to take place to achieve the target environment. A. A.1. A.1.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. 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.65Integrate change actions into projects. Integrate project descriptions into a change plan. Develop an integrated implementation strategy to guide detailed change planning and implementation efforts and decision making. Page 51 .63Identify change actions. Integrate individual change actions into a prioritized list of projects.

Page 52 .e. and • Developing a roll-out plan for the new DW program. Implement the DW change integration activities as described in the plan.. • Developing a facilities plan to enable changes in personnel and equipment.3 Integrate Changes Purpose To coordinate and integrate various change actions taking place on the project. the Human Resource department may be responsible for staff hiring).3. • Establishing new or modified organizational or business processes (e. coordinating the data. A.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. • Developing an education/training program (including logistics and scheduling). If a broader change integration task is within the scope of the DW project. The coordination of the technical tasks (e. • Developing plans for knowledge transfer (i. Overview Many change activities are taking place on a typical DW project .68Implement the DW change integration activities. A.1.67Develop a DW change integration plan. these various DW change integration activities in the DW project detailed work plans.g.g. the focus of this task is on the organizational activities that need to take place in support of the DW program being developed.both technical and organizational. • Developing a hiring plan to staff the new DW-enabled business and technology environments.1. to align with a new performance measurement or decision support system enabled by the planned DW program). providing user or knowledge transfer training sessions) and others may be completed by various organizational units (e.. Thus. the DW change integration plan could be an integral part of this plan.g. process and technology design activities) is the responsibility of project management.. as appropriate.g. Some of the activities may be completed by the project team (e. 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.. 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. leadership and management of the DW program). positioning the user organization for ownership.. It is important to coordinate and integrate. These activities may occur at various points during the DW development life cycle and may continue subsequent to the project completion.

these tasks are still relevant to help define how the users will ultimately interact with the system being built. • Proving the viability of a particular technology or suite of technologies (i. However. For instance. For example. The goal of these tasks would be to use the prototype to identify and confirm the organization's DW requirements.. even if a traditional prototype is not going to be developed. development and navigation strategies and building the preliminary prototype would all be Business Blueprint tasks. specific tools selected for the project may either constrain or direct the developer towards appropriate standards and development techniques. standards. Page 53 . proof-ofconcept prototypes). Depending on the development strategy identified and adopted in the Project Start-up Phase. as would the walk-through of the prototype with the users. 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. Overview Prototyping may be completed on a DW project as an approach for: • Defining user requirements for the presentation systems (i.e. evolutionary prototypes). The tasks defined in this phase will also be influenced by decisions made in the technologybased phases of the life.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. or • Incrementally developing the DW system (i. The key activity of this phase is the analysis and design of the user interface. all of the tasks may be completed for each iteration of the life cycle. However. the outputs from the Prototyping Phase should drive the technical design of the application instead of vice versa. Prototyping is a technique often used to assist in the development and approval of the user interface but. if a waterfall development approach is 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. the initial set of tasks for defining acceptance criteria. If a spiral development strategy was to be adopted. requirements prototypes).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. where the actual interaction with the application system would be designed and documented. If an iterative approach was adopted.e. The Prototyping Phase stretches across the DW life cycle.e. or • Repeated across the life cycle. the tasks in this phase may be: • Completed exclusively in one phase. potentially many times... The further revisions and development of the prototype would also potentially be Business Blueprint tasks.

U s e r P r e s e n t a t i o n P r o t o t y p e R e D 5 v i e w P r o t o a n d P t y p e s r e s e n t P r o t o t y p e p r e s e n t a t i o n E 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 e D e l i v e r a b l e Page 54 .THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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 A 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 A r e q P 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 e d a t a D 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 n 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 T r a n s f o r m a t i o n P r o t o t y p e R e D 6 f i n e P r o t o t y p e A n a D l y s i s a n d e f i n i t i o n D e 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 r d .

naming and numbering conventions. security and documentation. Prepare a clear articulation of the prototype purpose and what it is intended to achieve. If standards are not in place or if the organization decides not to use them.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. to validate that the prototype supports the way in which the organization wishes to work and to support testing in later phases. the prototype developer must have a set of conceptual guidelines. languages. by definition. workbooks. 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. The format should be the same for the entire system. A Business Scenario represents any of several realistic sequences of activities from the user's point of view. Business Scenarios are created and used to help guide prototype development. 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.1 Define Prototype Purpose To define the objectives.. at minimum. The user metaphor and the navigation strategy are developed to ensure that user-oriented systems are understandable and easy to use. Page 55 .69Define prototype acceptance criteria. scope and approach for the prototype. These criteria must be established before the prototyping effort can begin. number of iterations to be performed or the length of time the prototyping process will last). The Business Scenarios may also be used to describe the system to the nontechnical user or senior management. Any acceptance criteria defined must be precise and measurable.. These criteria should include the duration of the process (e. tools. 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. Scenarios. If standards are already in place or industry standards exist.4. it has to process certain transactions or data. the prototype should conform to those standards. The common format for each query and query definition is identified. expected response times and form of interface In addition.g. 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. e. Some customization will probably be required. In addition to practical standards. web pages. These guidelines help determine how to aggregate data and functions as well as how to have the user move through the system. A.g.1. a minimum statement of functionality may be stated. like a script. approved and documented. 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. new standards must be defined. reports.

a requirements only prototype would not.72Assign authorization and responsibility. • Is it a proof-of-concept prototype? Sometimes a prototype is developed to prove whether or not a particular technology. • Is it a disposable prototype? The future of the prototype must be established. The IT infrastructure components and environment necessary to develop the prototype must be in place and functioning satisfactorily before the prototype commences. • Efficiency of the system once learned (ease of use). controlled installation or a functioning system. the team must determine if it will be evolved into the production system or not. and • User satisfaction. Before the prototyping begins. suite of technologies or application design idea can be realized..g. system abstract or technology definition). This distinction is important to understand so that the appropriate prototyping tools are used. 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. In addition to these strategy questions. Document the strategy to be used and any considerations of the alternatives considered. this must be specified. Page 56 . While a functional prototype might evolve into a pilot. or • Is it clearly a prototype and not a pilot? A pilot is usually a small. those that help define user requirements for the system interface. test or production IT environments or give unrealistic expectations for the system.71Determine user interface prototype strategy. Determine who can authorize changes to the prototype and who is responsible for acceptance of the prototype. an explicit policy for what should be done with it should be devised. are not used to elicit user requirements and have very strict hardware and software requirements.1. decisions may need to be made and documented about which items are specifically excluded from the prototype such as year-end processing features. If the prototype is a requirements prototype and will not be developed further.1. 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 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. Define precise and measurable goals for assessing the usability of the prototype. A. • Ability of infrequent users to return to the system without having to learn it all over again. Determine the best strategy for modeling the user interface as a part of the overall development strategy. A. proposal. Proof-of-concept prototypes are usually developed in the very early phases of a project (e.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. Consider: • Ease of learning (amount of training required to learn the system). Be certain that the approach used does not conflict with the ultimate development. • Is it a requirements-only prototype? Some prototypes deal exclusively with "look and feel" issues.1.70Define usability goals. this will have a definite impact on the prototyping tool selected. The prototyping software and hardware to be used and type of interface environment should be selected here if not already identified.

languages or the prototyping techniques and approach to be used) and complete any necessary training.1. e.75Review Business Scenarios.. 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 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. Redefine the skill and resource needs together with any training requirements for the prototyping team (e. Also. The Business Scenario for this particular example requires that the BW system contain the necessary data to support the analysis needs of this scenario. A Business Scenario is a narrative. 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. A.. This person needs to be able to resolve conflicts between competing requirements or expectations. 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. create a Business Scenario. Complete a structured walk-through of the Business Scenarios for validity and completeness.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology While many users may be involved in the development of the prototype.74Create Business Scenarios. For each business event identified. Page 57 . The user simply would remain within the particular query/workbook already opened.73Confirm resources and skills to conduct the prototype. Ensure that each common contingency is covered by at least one of the Business Scenarios.1. A.g. For example. one person should be the ultimate authority. A. The definition of the prototype strategy may result in changes to the original planned resources and skills needed for the completion of the prototype. script-like document that represents a realistic scenario for the user. This is triggered by the sales revenue shortfalls in two particular locations during a specified period of time. Each scenario should have as much detail as possible.1.g. for prototyping tools. some scenarios will require no system action. Make corrections where required.

and • Creating mock data. Revise the strategy as appropriate. Review the objectives. Develop a strategy for capturing or developing data for the planned prototype effort considering alternatives such as: • Converting subsets of real source data. quality or user inputs. strategies.1.78Develop prototype data. • Analytical Processing Data Definition.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A.77Develop prototype data capture strategy.76Determine prototype data requirements.4. Document any assumptions made in developing the prototype such as those regarding completeness. A. Develop or capture the prototype data based on the established strategy or approach. Page 58 . A. refer to and tailor the tasks and steps in the following phases in completing this step: • Analysis and Decision Process Definition.1. As appropriate. The work to be completed in this task may vary depending on the objectives and scope of the prototyping project.1. Overview This task prepares the data to be used in the prototyping effort. and • Data Design. Review the prototype data capture strategy with relevant management and users.2 Prepare Prototype Data Purpose To prepare source data for the prototype. business events and business scenarios relevant to the prototype effort to determine data requirements. A.

• Assess the quality and completeness of the source data. Develop the prototype data transformation system based on the defined requirements.4. This includes building new InfoSources or utilizing existing Business Content extractors and InfoSources. As appropriate. Review the prototype objectives and strategies. or • Develop prototype InfoCubes. and • Analytical Processing Data Definition. A.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. • Evaluate the data transformation architecture. Page 59 .1.79Determine the functional requirements for the prototype data transformation system. A. this task may be completed to: • Evaluate existing InfoSources or new ones that need to be developed. Overview This task develops a prototype data transformation system.80Develop the prototype data transformation system. refer to and tailor the tasks and steps in the following phases in completing this step: • Analysis and Decision Process Definition.3 Prototype Data Transformation Purpose To develop a prototype data transformation system.1. • Assess the volumes and capacity needs for the data transformation system. Depending on the objectives of the prototyping effort. business events and business scenarios to determine the functional requirements for the data transformation system.

81Refine and incorporate all required queries/workbooks.. all designated queries. Detail formatting is added and system flow is refined. navigation options and drill paths have been defined.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A.4.1. A.83Finalize data content.1. filters. Ensure that all calculated key figures and selections are correct and have been incorporated appropriately. Ensure that any user-requested changes not specified earlier support the CSFs and are not an expansion of scope. The level of detail and amount of work necessary is dependent on the requirements stated in the prototype acceptance criteria. A. • Mathematical consistency and precision. workbooks. Be certain that the prototype uses data as defined in the LDM or that is consistent with any denormalization decisions made during Data Design.1. web views and processes are refined and may incorporate prompts. Designated queries may be only risky (high security access only).. The difference is significant in terms of the development effort and needs to be clearly specified as part of the prototyping scope definition. This phase leads to finalized detail design for each query. and/or web views are incorporated within the prototype. and conditional logic where appropriate. restrictions. workbook and web view.4 Prototype End-User Presentation Purpose To develop a prototype presentation system. Refine any existing reports and prepare any remaining or additional reports. Overview During the Realization Stage. A. Queries. A.84Define and incorporate required calculated key figures and selections. high use or those deemed important to the business as defined by the Business Scenarios or may be all queries in the application.1. Pay special attention to any calculations or formulae requiring correct interpretation of: • Organizational policy or procedures. At this point. These should include additional details such as filters and all navigation actions. Calculated and restricted key figure structures are defined and incorporated. Based on the requirements established in the prototype acceptance criteria and walk-through. Modifications requested and agreed with the users are added to the preliminary prototype. build and incorporate all remaining queries and workbooks into the prototype.g. the queries in the interface have been identified and prototyped and the main information content. Page 60 . taxation rules). workbooks.82Refine or prepare all Report Layouts and Definitions. Compare the prototype with the Logical Data Model (LDM) to ensure that all required data is available on the query views. and • Statutory or other external requirements (e.

86Define and incorporate interfaces. A. Details of the format. define and incorporate input and output transfer files containing data that will be needed to interface with other current or future systems. Code. restrictions. A.85Define and incorporate system/program alert/exception messages. Where applicable. Where applicable.1. Page 61 . and formula path variables. Include: • Range checks. • Numeric checks. test and link any necessary prompts. and • Code validations.1. define and incorporate required prompts and variables. 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.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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.

user interface metaphor. A. Resolve the issues with the user designated to authorize changes to the prototype. Confirm the contents of the preliminary prototype with the process and data models. navigation strategy and preliminary prototype. user interface metaphor. Produce a work plan to document tasks to be completed and resources required to complete the remaining tasks in this phase. Identify any outstanding issues and assign responsibilities for resolving them. Page 62 .1. The strategy is composed of the prototype acceptance criteria. Determine the extent to which the prototype can be considered complete.5 Review and Present Prototypes Purpose To review the preliminary prototype.88Evaluate preliminary prototype and decide next tasks. A. omissions. Overview The prototype acceptance criteria.1. prototype development standards.4. checking for consistency or conflicts. Compare the preliminary prototype with the prototype acceptance criteria.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. prototype development standards. A walk-through of the strategy and the prototype itself is necessary to obtain user approval and acceptance. modifications and any additional processes that need to be added.87Walk-through preliminary prototype and prototype strategy with system users. navigation strategy and preliminary prototype (queries and workbooks) make up the prototype strategy. Review with the system users and application developers exactly how the prototype is to be used during the Realization Stage of the project. Conduct a structured walk-through of the preliminary prototype and strategy to identify errors. 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.

6 Refine Prototype Purpose To iteratively refine the prototype. A.89Revise Business Scenarios. A.90Obtain approval for Business Scenarios. Review. They are developed in narrative form so that non-technical users may read and understand them.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. Page 63 . Obtain formal written sign-off from management on the content of the Business Scenarios. A.91Apply Business Scenarios to the prototype.1.4. If the differences are significant. typical business situations. Develop test scripts for the Business Scenarios and apply against the prototype. Check off the expected results for each scenario. 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. Delete scenarios that are redundant or obsolete. document them using the issue resolution process. document any variations and discuss the differences with users and the prototype developers. Ensure that the scenarios reflect. Discuss the content and coverage of the Business Scenarios with management. Overview The Business Scenarios created earlier in this phase represent realistic depictions of the business world. Revise all scenarios for clarity and content. revise and finalize the Business Scenarios created earlier in this phase.1.1. Ensure that the expected results of each scenario are clearly documented. Add new scenarios if omissions are found.1. 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.92Document the final set of Business Scenarios for use in user acceptance and system testing. at minimum.

There are a number of other variables.1. 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. that is a viable solution for the selected technology environment and that reflects the way in which the business intends to work. that need to be addressed in an application design. A. Identify any external factors that help to shape the final look and feel of the prototype.96Finalize Report Layouts and Definitions. obtain formal written approval.1.99Obtain formal written approval of the prototype deliverable. Once the prototype has been reviewed and necessary changes made. A.1. 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. 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. distribution strategies and potential reuse. prepare an action item list of items to modify in the prototype. 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. Page 64 . If necessary.1.1. standards. This may involve more than one meeting. Ideally these decisions need to be made before starting the Prototyping Phase. A. A.7 Evaluate and Submit the Prototype Deliverable Purpose To complete a user interface prototype that is supportive of the functional requirements of the application. A. use of technology.95Finalize Query/Workbook Layouts and Definitions. as necessary.97Assemble and review prototype deliverable.98Submit and discuss prototype deliverable with management. Make any adjustments. Discuss the prototype deliverable with management and resolve any questions and issues.4. maintainability. Based on the windows developed for the prototype.93Apply external factors to the prototype design.1. although there will be situations where alternative approaches are evaluated through the use of the prototype. however. Package together the components of the prototype and review them for completeness and consistency. ease of use. The prototype also may be used to validate and refine the Business Scenarios. A. A. Compare the prototype to the Business Scenarios to ensure that all appropriate activities have been included. to finalize the Report Layouts/Definitions for the prototype.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A.1.94Validate prototype against Business Scenarios. finalize the Query/Workbook Layouts and Definitions.

g. features of the development environment may influence the requirements for the test environment. identifying a set of IT infrastructure alternatives and selecting the desired alternative. Furthermore. Support and Cutover Purpose To define.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. Strategies and standards are developed to guide the definition. staging and production environments. These separate environments are built by analyzing the technology determining factors of the desired (production) system. design and implementation of the different IT environments to be developed for the DW system. There is also a continual information exchange between the life cycle of each environment. The IT infrastructure support requirements for the target DW system are defined based on an understanding of:  the current IT environment. There are a number of distinct environments created during the implementation of a DW project including development. and  the technology infrastructure requirements for the DW system addressing not just technology issues but also organizational and business. e.g. 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. IT infrastructure and product selection criteria are also determined. 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. The IT infrastructure consists of hardware. Analyzing the requirements for the test environment may begin concurrently with the requirements for the development environment. Overview Using the Technology Abstract as input... The creation of each of the environments follows a set of steps. establish. in concurrence with the selection of primary suppliers. the creation of each environment can occur concurrently with respect to the other environments. e. software and communications components that may be transitioned and/or migrated from the existing environment and/or procured from hardware and software suppliers. The work in this phase can be discussed in terms of three areas: • Technology definition. the design of the development environment can proceed before analyzing all of the requirements. Many of these steps occur concurrently within the creation of each environment. although the emphasis and the content of the steps may differ from environment to environment.5 Technology Planning. peripherals. The choice of the infrastructure components. Page 65 . the IT infrastructure necessary to support the new DW system is defined and designed in this phase. 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. will drive the requirements for the different environments. tested and implemented. and maintain the detailed IT environments in which the proposed Business Information Warehouse system will be developed. The IT environment is often characterized as a complex integration of heterogeneous hardware.

• Technology Pilot. While the methodology discusses only the design of the development.g.g. the development. and • Technology design. 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. test and production environments.g. or  where there is a large technology training need or culture adjustment to be made (e. prototyping or training environments). The completed IT environment designs are then assembled into a Technology Design Deliverable for management approval. test and production environments are designed.. In general. Based on the approved technology definition. The selected infrastructure is defined in the IT infrastructure abstract which is submitted to management for approval in the Select IT Infrastructure Alternative task. the Technology Pilot.. the organization is a slow adopter of new technologies).g.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 work steps may be adopted to design other IT environments as required by a particular project (e. Page 66 .. a Technology Pilot may be considered in project situations:  where the IT infrastructure will form a significant component of the project (e.  where there is a need to prove the effectiveness or compatibility of different IT components or explore their function/use/applicability (e.  where there are a large number of IT components that are new to an organization. a high proportion of the total project cost). adoption of new peripheral components such as hand-held data input or recording devices)..

THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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 g y I m p l e m e n t a t i o n 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 R e q u i r e m 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 W E n v i r o n m e n t L a n d s c a p e D 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 D    e R S D v e e t r e l q a s o 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 n e n E I n s t a T e C o m 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 e n t n t 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 o l o g y D e s i g n D e l i v e r a S 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 u r e s r o c e d u r e s P 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 u p p o r t T e a m Page 67 .

1. • Payment and funding policies and alternatives for equipment (e. network maintenance). • Purchasing Agent. Careful attention should be paid to the project scope boundaries and task allocations during this step.1. A. Page 68 . lease or rent). Based on the required tasks. 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. • Application Developer.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. 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. Define skills matrices. Roles and responsibilities should be established for all tasks necessary to create the development. • The organization's formal budget and approval process for capital equipment and staff recruiting. purchase.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. safety and ergonomics.g. and • Compliance with any statutes or rules for items such as health.100 Create technology implementation work plan.101 Identify required organization skills and roles. Use the Technology Implementation Strategy and the details of the target IT environments from the Technology Planning... 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. • Network Administrator.g. A.5. • Outsourcing issues for some components and services (e. Support and Cutover Phase to develop a work plan for the evaluation. test. • Configuration Control Librarian. • Hardware and software support Technician for each environment. selection and implementation of the DW IT architecture. and • Help Desk staff. production and any other IT environments. New or changed roles may include: • Database Administrator. Data Administrator and Data Security Administrator. 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. job descriptions and organizational reporting lines for any new or amended positions.

104 Discuss and confirm the work plan and staffing plans.1. Page 69 .103 Derive training needs. Resolve any questions or issues and make changes as necessary. Once all required roles have been identified.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. Obtain formal written approval. computer-based training). Define any skill gaps that may require the use of external resources on a short or medium term basis. Cross-reference personnel to required roles. A. or • Apprenticeships (working closely with relevant experienced personnel). 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. derive training plans. Where necessary. A.g. • Internal courses. Determine the means by which the training will be completed such as through: • Self-teach (e.1. commence the formal recruitment cycle following the organization's recruitment process including approvals. Refer to the Training Phase for further information.102 Assess existing personnel. Consideration should be given to skills of the individuals as well as available time to be devoted to the required tasks. Discuss the technology implementation work plan and staffing plans. • External courses.. consider existing personnel for assignment to these areas.1. From the individual training requirements.

data transformation and calculations. A.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. access statistics and capacity utilization data). Test Plans and Test Data for system and acceptance testing).THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. and • Implementing new systems will usually require some amount of conversion of current and historical data structures. Page 70 .1. Process Descriptions).g. This does not mean however. • Outstanding System Change Requests. This may mean that the work in this task focuses on adding any missing information or verifying collected information. • Technology documentation (e. file record counts. Logical Data Model. • Test documentation (e. technical subject matter experts and operations staff are critical to successfully complete this task.. and • Volume information (e.g. • Source program listings... 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. support and cooperation from IS management. A thorough understanding of existing systems is essential as: • Existing systems frequently perform important functions that users may not be aware of.g. • Sample input forms and outputs. Establish working relationships with the Information Systems department and related departments to gain access to the corporate knowledge associated with the legacy systems. 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. • Operations manuals.. System Distribution Strategy. These departments are critical sources that can be used to develop required models of the system..105 Establish liaison with Information Systems and related departments.e. 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. • Existing data structures and program code may be the only sources of information about detailed business data. existing systems often do not perform according to their documentation.5. Information to be gathered may include items such as: • Process documentation (i.g. It may provide the necessary "missing link" that permits the project team to discover mandatory functionality of a system. Commitment. that the documentation is of no use. Data Communications Network Design and/or Inventories of Hardware and Software). Conceptual Data Model. In many cases. • User documentation. file size statistics. • Data documentation (e. Physical Data Storage Characteristics and/or Record Definitions). Overview Depending on the project scope.

• The extent to which the organization is committed to in-place technologies. production). development. and • Any ongoing or planned projects to change or upgrade any other applications or technologies. • The IT skill level and experience of personnel. • The extent to which the organization as a whole is committed to specific products or suppliers for any hardware.g.106 Evaluate existing environments. Include: • An identification of the different environments used to support information systems development and processing (e. test. prototype.1. Gather and evaluate information related to the current systems. software or services. in both the IS department and in end-user departments. Page 71 .THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A.. • The location and physical condition of facilities for equipment and personnel. organization and policies. environments.

Some examples of information sources may include: syndicated. Some of the requirements. Review the deliverables from Phase A . may add stress to the infrastructure. Overview Multiple IT environments (e..107 Identify the target IT environments. development. This is a critical step in managing scope and user expectations for a DW project.1. In general. private networks or information sharing consortiums. Some examples of alternative categories of information access may include: WWW/Internet.g. Selected tasks in this phase may need to be completed for each of the different IT environments to be developed. 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. • Development environment (including unit test). 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.5.  analysis and decision processes. or  quantitative analysis including data mining or profiling applications. • Staging environment (including system test or acceptance test environments).Data Warehousing Project Abstract to determine the requirements and timing for each environment. Page 72 .Project Start-up and Phase B . A. standards/strategies and IT decisions may apply to multiple target environments while others may only be relevant to certain specific environments. • Prototype environment. and therefore.108 Analyze the business issues that may impact upon the technology infrastructure. • Determine the types of analytical/decision processes supported by the DW system including:  performance measurement. • Production environment. These information/data sources should be viewed with the understanding that they may be integrated into the warehouse at a later time. staging and production environments should be defined at a minimum. staging or production environments) may be created on a DW project. and • Training environment.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A.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. The potential environments may include: • Technology Pilot environment. A. the development.1. Identify the target IT environments and their required components to be developed for the DW project. public domain or other corporate/internal information.

110 Analyze the external factors that may impact upon the technology infrastructure. It is imperative to determine the organization's perception of an "acceptable" amount of risk. Assess existing methods and procedures that will impact upon the DW IT infrastructure.g. This provides input to the analysis and design of both the IT environments and the new methods and procedures needed to support them. the business environment should be assessed on a continuous basis to determine the impact of any changes on the DW technology infrastructure. When considering IT infrastructure alternatives. A. • Industry standards that may have an impact on the design of the technology infrastructure either currently or in the anticipated future. Analyze impact of any strategic imperatives such as:  impact of collaborative decision making. the scope and complexity of the DW environments will also change.g.. Analyze impact of regulatory requirements.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology • • • • • 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. supplier preferences) or agreements (e.1. Identify issues that may suggest a change in the centralization of the infrastructure. e. compliance with industryestablished data standards is important in conducting electronic data interchange (EDI) or electronic commerce (EC) transactions with an organization's trading partners.. Document the amount of risk that the organization is willing to take with regard to new technologies.1. Consider the costs or benefits that will result from these established decisions. and Analyze impact of competitive environment or major industry trends. Page 73 .  requirements and value of data visualization techniques. Determine whether any of these decisions will present constraints or limitations on the new IT infrastructure. financial reporting compliance. product development regulatory controls or privacy considerations).. merger or acquisition.  impact of infrastructure centralization. Thus. lease agreements or contracts for supply) that the organization has already made.. Assess organizational issues that may hinder or facilitate the use of certain technologies. Document any decisions.g. A. 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. New technologies may promise significant benefits to the organization but may also present a greater risk. management issues that determine the size of development efforts and pre-existing team structures may affect the choice of technology. existing standards (e. As the business environments evolves.109 Analyze the management issues that may impact upon the technology infrastructure. or  requirements and value of intelligent agents.  impact of strategic partnership.  impact of decentralization of decision making. Training of personnel in specific technologies. the distribution of the environments and the management of the systems.g. include the current methods and procedures in the current IT infrastructure profile. Analyze functional requirements with respect to the technical infrastructure of the data warehouse. and  impact of change integration/business process transformation.

. copyright issues.. both locally and remotely and the type of information that will be accessed (i.  data sources. line types. and  amount of stored data required for both system management software (such as security.g.1. • Data mining applications. DSS. and • Opportunities of selling the organization's data as a "product" (e. data mining applications. Analyze the characteristics of the user base in terms of: • Number of users by management level.  data synchronization requirements (for both internal and external data). Internet/intranet connectivity and the system distribution strategy.  number of modules to be created.g. security issues. frequencies and growth in terms of:  data storage volumes (for both live and archival data). data definition) is becoming an important business requirement. unstructured data access.. • Quantitative decision analysis. and  frequency of data update.  number and size of outputs.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology With the increasing use of inter-enterprise systems (electronic partnering). • Planned data access and sharing requirements.112 Analyze the technology infrastructure stress factors.  number and size of input transactions. refresh and access.1. • Expected current or anticipated data characteristics of the DW environment such as:  data integration requirements (for both internal and external data). WAN or dial-up connections. Estimate the growth rate of the user base.  data granularity requirements. Determine the maturity/sophistication of the user base with activities such as: • Performance measurement analysis. • Expected data volumes. customer mailing list) and their impact on the design of the technology infrastructure (e.. privacy law compliance. or • IT applications.111 Analyze user base. and • Types of analytical processing performed by user/location (e.  number of users.g. • Roles of users in the organization. A. network management) and user applications.. • Any potential or pending mergers or acquisitions and their impact on the design of the technology infrastructure.  data periodicity requirements.g.  data distribution requirements. 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. A. intellectual property issues). back-up/recovery. the compliance with industry standards in managing an organization's data resource (e. • Business modeling and analysis. Page 74 . • Geographic locations of the users and number of users at each location. EIS. Determine the access that developers and users will need to data and applications.e. Analyze the impact of the technology infrastructure factors on the DW technology infrastructure such as: • Expected life of technology infrastructure components. ad hoc queries).

• Business process transformation changes. A. • Disaster contingency/recovery issues. the scope and complexity of the DW environments will change. products and services.g. 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. and • Expected change in geographic distribution and networking requirements. enough capacity and scalability must be provided to ensure that the IT infrastructure effectively supports the anticipated business requirements for the desired time horizon.. Specifically. • Expected data storage volumes. • Tax considerations. data and the user community of the DW system. Page 75 . locations and roles. Identify aspects of the business that require specific placement of hardware. • Security issues. and Current and forecast network. Analyze the expected growth in processing. A. Back-up could be full (where all data is backedup).1. Internet and intranet requirements. In such cases. The above stress factors should be assessed on a continuous basis to determine their impact on the DW technology infrastructure. As the technology factors evolve.. • Availability of appropriately skilled personnel in certain areas.g. and • Distributed work force.113 Analyze business requirements driving the distribution of the IT infrastructure. e.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology • • Current and forecast geographic distribution requirements. In the growth forecast. there will be a need for a weekly full network back-up and a daily full data back-up. the extent of recovery that is necessary and what constitutes an acceptable loss. consider that the new systems or applications may affect the organization's growth. • Business expansion .new ventures. The expected growth must be considered in the design of the new IT infrastructure.115 Determine back-up/recovery requirements. • Expected lifetime of the system. 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). Business aspects to consider include: • Pre-existing processing sites. if the entire system goes down. existing growth projections may be understated. document expansion requirements and assumptions. if the system is supposed to improve productivity. Consider the following areas: • Growth of the user base .number. In the analysis of growth expectations. e.1. processing or data storage. • Future processing needs.1. A. • Technological resource availability and levels in certain areas.114 Analyze IT infrastructure growth requirements. Consider how much downtime is acceptable in the event of a system failure. Determine the frequency and type of back-ups required for system recovery. • Legal requirements. • Logistics and distribution channels.

116 Determine security requirements.. it may be necessary to include disk mirroring in the configuration). This information will impact upon the identification of back-up and recovery standards. frequency and media for purging and archiving data. hardware and tools (e. Determine the criteria. A. Business and legal issues may require a certain level of security to be maintained by the IT infrastructure.g.1..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. Determine the requirements for access and data security. remote hot-site or cold-site facilities). Page 76 .g. strategies.

2. Page 77 .2B. 2. 3. 3. detailing:  BW Environments  Web Technologies (ITS.e. 3.1C. 2.1C) • Document estimated sizing requirements when known A.5.com.0B.6.. 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.5a.)  Version of the Component (BW 1..1. at what patch level will be required? • Version of the Software Highlighted  Basis (4.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.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. 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.118 Submit Landscape Submit the Environmental Landscape for approval to the Environment Management group and the Technical Team.. 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.0A. Cognos)  Multiple R/3 Environments A.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.0B.1. 4. Mysap.0A. They work together on changes needed for the environment from the application standpoint and the technical infrastructure.

Determine what data and files will need to be shared among developers. based on inputs such as the number of users. staging and production . memory and storage required for each development platform. 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. Determine the development network needs: • Determine type of network traffic. the development environment requires ongoing support and this must be in place from the commencement of use of the environment.5. The scope of the development environment includes the Business Blueprint and Realization Stages.g. the number of modules being created and the amount of development data. if a particular infrastructure component or application is simulated.119 Analyze development environment requirements Estimate development platform capacity requirements. Implementing components in the development environment will provide more time to overcome or compensate for the challenges inherent with new technologies. e. This may be achieved by using physically separate platforms or security mechanisms that enforce separation on a single platform. For example. Overview Three discrete environments are addressed . Determine whether network-intensive applications (e.5 Design and Establish the Development Environment Purpose To create the environment that will support the design and construction of the target applications. A.g. Isolation of Environments It is important to maintain complete logical separation between the different environments. the possibility exists that the applications being tested may rely on some development resource that may not be present in the production environment. imaging or large file transfers) will operate over the network during Page 78 . Risk Factors Differences between the development environment and the test environment shift the risk associated with different components into the testing phase. This invalidates the testing and could lead to application failures during production. problems relating to the component or service may not be discovered until they are migrated to the test environment.. This requirement impacts the need for network connections and access and the number.in technology infrastructure design. Once operational.1. This discipline is required to prevent applications from accessing resources that are only intended to be present in a particular environment.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. However. Project managers must decide which components will be implemented in the development environment and which components will be introduced in the test environment. Many of the steps for each environment are the same. if development resources are available in the test environment..development. the focus when performing these steps may differ from environment to environment and this difference is reflected in the details of the steps. This risk can be mitigated to an extent by adding a string test step which follows unit test and precedes system test. configuration and connectivity of common file servers and databases. multimedia. in terms of the amount of processing power. these steps have been repeated in the methodology so that the steps for creating each environment can be found in one place.

If remote access is needed. This information is a key input into the selection of networking technology and capacity for the development environment.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology application development. disk space)  Possible migration paths to more powerful database servers from the same hardware vendor • • • • Page 79 .1. Using inputs such as type and frequency of network traffic and the number of users. allowing for future network requirements and office products Applications Server Level:  Memory sizing. access methods must be provided such as WAN connections or dial-up access. 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. • • A. backup media. reflecting BW sizing model  Disk distribution on the application server  Scalability of the application server (memory. recovery. 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. CPU. Estimate volume of network traffic. This type of network traffic can increase the network bandwidth requirements during the development effort. reflecting BW sizing model  Database disk distribution  Growth path for the database server  Delivery lead times for additional disks. Local access requirements will help to determine LAN configuration and may affect platform and environment decisions. Determine developer access requirements.120 Estimate BW data volume Purpose The purpose of this task is to develop specific sizing proposals for your initial BW hardware. and similar  Scalability of the database server (memory. 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. estimate the volume requirements for network traffic. both locally and remotely. and reset of the development system Consider the following:  What hardware platform will you use later for quality assurance. CPU. with assistance from your hardware partner. Determine what access developers will need to data and applications. disk space) Database Server Level:  Memory sizing.

Early planning enables the scheduling of the non-BW software installs to be performed at the most suitable point in the BW installation timetable. Page 80 . All the systems throughout the BW environment are on supported and fully functional software profiles.1.1. order any additional dependent hardware required for the development. Also.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. place the purchase order for the initial BW development system hardware. 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. the information can be channeled into the flowchart available in the installation manual. and subject to the external hardware partner Service Level Agreements. Procedure • • On the basis of the internal project Service Level Agreements. the other project leaders and the project steering committee should be kept informed of the status of the BW system installation.123 Order Software Purpose The purpose of this task is to place the initial software order with the appropriate vendor. Also. determine the expected delivery date of the software. A.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. Inform the project steering committee Where required by the internal service level description. Procedure • • Determine the start and target configuration for each of the necessary software profiles Once these tasks have been established.1. to determine at which point during the process the software should be installed. and to determine the expected lead-time needed to procure the productive system hardware. and to determine the expected lead-time needed to procure the productive system software.122 Order Hardware Purpose The purpose of this task is to place the initial hardware order with the appropriate vendor. order any additional dependent software required for the development. determine the expected delivery date of the hardware. A.

1. the other project leaders and the project steering committee should be kept informed of the status of the BW system installation.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.1. place the purchase order for the initial BW development system software. Page 81 . and subject to the external software partner Service Level Agreements.124 Order Network Facilities Purpose The purpose of this task is to order and install the network connection to the BW system environment. Inform the project steering committee Where required by the internal service level description.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology Procedure • • On the basis of the internal project Service Level Agreements. A. 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.

technology components and operations tools and procedures. e. 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. so as to accurately test the functionality and interactions of all applications. network services and tools to simulate the production environment. integration and user acceptance testing of the target applications and infrastructure systems.5.. The construction of the test environment requires the selection and integration of hardware. Determine the network requirements for testing: Page 82 . the test may be invalidated because the applications may rely on some development resource (e. The isolation of the staging environment from the production environment also offers migration safeguards. a different code library or development data) that may not be present in the production environment.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A.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. if the development resources are available in the test environment. For instance.g. Isolation of Environments It is important to maintain complete logical separation between the different environments.. This control is most easily implemented with a distinct division between environments. The necessary environment may include special products to test particular features of the applications to be developed. Test resources should not be available in the production environment and migration between the test and production environments must be tightly controlled. 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 staging environment should be isolated from the development environment so that development resources are not available in the test environment. a testing strategy must be devised. The overall objective of the staging environment is to closely simulate the production environment. required skill sets and their physical locations. This information will impact upon the configuration of the test team workstations and the test network topology. configuration and connectivity of common file servers and databases. it moves into the staging environment for the other remaining tests. Determine data sharing requirements.6 Design and Establish the Staging Environment Purpose To design an environment that will support the systems.1.126 Analyze staging environment requirements Analyze staging environment requirements as follows: Determine the number of testers. Determine what data and files will need to be shared among the test team. A. It should be noted that the specific tests performed in the development versus the staging environment may vary from project to project. This requirement impacts the need for network connections and access and the number. a particular configuration. Overview After each application software module is unit tested in the development environment. Once it is determined how to meet testing-support requirements.

and reset of the test system Desktop Level:  Standard PCs available. Determine security requirements. If remote access is needed. A. disk space)  Possible migration paths to more powerful database servers from the same hardware vendor • Page 83 . multimedia. CPU. Determine what access testers will need to data and applications. Determine who will have access to the staging environment and the responsibility for maintaining the security of the staging environment. with assistance from your hardware partner. Using inputs such as type and frequency of network traffic and the number of users. and Determine the platforms and network protocols that must be accessible from end-user machines. both locally and remotely. disk space) Database Server Level:  Memory sizing. Determine whether network-intensive traffic (e.1. user and support personnel remote access requirements. access methods must be provided such as WAN connections or dial-up access. CPU. estimate the volume of network traffic during the testing effort. Members of the test teams may also require education in the use of the security system.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology • • • • Determine type of network traffic. Obtain formal written approval of the staging environment requirements. recovery.. reflecting BW sizing model  Disk distribution on the application server  Scalability of the application server (memory.g. 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. Estimate volume of network traffic. Determine test team. reflecting BW sizing model  Database disk distribution  Growth path for the database server  Delivery lead times for additional disks. imaging or large data file transfers) will be sent over the network during the testing effort which can significantly increase the network bandwidth requirements. backup media. Determine the necessary security for the testing effort. Procedure • • • • • Do initial hardware sizing for the staging environment Determine how many applications go live at the same time Determine the requirements for backup. Determine tester/developer access requirements. allowing for future network requirements and office products Applications Server Level:  Memory sizing. Local access requirements will help to determine the LAN configuration and may affect platform and environment decisions. and similar  Scalability of the database server (memory. This information is a key input into the selection of network technology for the staging environment.127 Estimate BW data volume Purpose The purpose of this task is to develop specific sizing proposals for your initial BW hardware. 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.

129 Order Hardware Purpose The purpose of this task is to place the initial hardware order with the appropriate vendor. place the purchase order for the initial BW development system hardware.1. the other project leaders and the project steering committee should be kept informed of the status of the BW system installation. Also. determine the expected delivery date of the hardware. to determine at which point during the process the software should be installed. and to determine the expected lead-time needed to procure the productive system software.128 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. All the systems throughout the BW environment are on supported and fully functional software profiles.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. Also. Procedure • • On the basis of the internal project Service Level Agreements. the information can be channeled into the flowchart available in the installation manual.1. Page 84 . determine the expected delivery date of the software. order any additional dependent software required for the development. A. and to determine the expected lead-time needed to procure the productive system hardware. Early planning enables the scheduling of the non-BW software installs to be performed at the most suitable point in the BW installation timetable. 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.1. Procedure • • Determine the start and target configuration for each of the necessary software profiles Once these tasks have been established. order any additional dependent hardware required for the development. A.130 Order Software Purpose The purpose of this task is to place the initial software order with the appropriate vendor. Inform the project steering committee Where required by the internal service level description. and subject to the external hardware partner Service Level Agreements.

and subject to the external software partner Service Level Agreements. and other project members comprise the bulk of the BW users most of this users will need access to the Staging Environment also.1.1. The project team must be permitted to perform business application functions in the development environment Customizing client (DEV). These profiles must be created in the SAP master Client to propagate them to other clients. Inform the project steering committee Where required by the internal service level description.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. 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). A. Page 85 . Configurators/customizers. the need to limit user access increases. or they may have been transported from the development environment.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology Procedure • • On the basis of the internal project Service Level Agreements.1. the other project leaders and the project steering committee should be kept informed of the status of the BW system installation. and also has access to check their environment as it gets transported into the Staging Environment (SAS). A. In general. Developers. users in the DEV system have more access than users in the Test (QAS) or Production (PRD) system.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. As the BW project progresses. place the purchase order for the initial BW development system software. 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. recent trainees. This profile allows a user to perform all tasks in an BW system. System Administrators. Procedure In order to complete this task you must do the following: • When the Development (DEV) system is first installed. This ensures the team can model business processes in your BW (DEV) System without restriction. • Most users in a newly installed BW system begin with the SAP_ALL authorization profile in their user master record.131 Order Network Facilities Purpose The purpose of this task is to order and install the network connection to the BW system environment. but a restricted subset of this activities should only be allowed in the Staging Environment (SAS).

Determine from this the reports and interfaces requiring operating system and database access. Install. modeled after the profiles in the Development environment. interfaces. • 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. Determine from this the reports and interfaces requiring operating system and database access. Change the password. Please refer to "The SAP BW Authorization made Easy – Guidebook.1. Provide security to ensure the integrity of the SAP technical environment and data. 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. and customizing that is projected. Page 86 . A.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology • At this time. and test printing services for each printer. configure. Changes to access rights of project members must be documented. ora<SID>.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. we recommend creating a new profile.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. Provide security to ensure the integrity of the BW technical environment and data. Access to these users must only be given to key members of the technical project team. and at what level. the Security Administrator should know the BW Authorization Concept. Determine a procedure for requesting operating system and database access for the staging environment. Procedure • Create Operating System and Database Level Access for Project Team Members Analyze the types of reports. Chapter 7 Special Cases. and provide security for the following users:  SAP users: SAP* and DDIC  Operating system users: <SID>adm. Provide and ensure security for the BW operating system and database users. Create operating system and database level access for project team members. A. data feeds. and customizing that is projected.1. 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. Initially. Analyze the types of reports. interfaces. and at what level. Verify that each printer is installed and accessible by the local PC client or the operating system of the development system. Setting Up Authorization Profile. data feeds.

136 Set Up Client Management and Transport System Purpose The purpose of this task is to install and configure development system clients. and the roles of each client system in a BW implementation. Change Country Specific Settings. Procedure • • • • Install and Configure Development System Clients. Set up client management for the functions of your clients.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A.1. and Cross-Client maintenance. Configure Workbench Organizer. Page 87 . See the documentation on the BW client structure. Consider Automatic Transport. Client Roles. Initial Test of Transport System. During this activity you must define client management.

How much earlier the construction starts will depend upon such items as the project timeline. Slow. the applications may rely on some development resource (e. they must now be deployed and formal responsibility taken for them. medium-quality printers Page 88 . e. volume and print quality of the output of the applications will determine the choice of printers for the environment.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. is staggered so that the staging environment begins before the production environment. Users and support personnel may require access to the system.g. The type and placement of particular network components (such as hubs and routers) are determined at this time. if development resources are available in the staging environment. Confirm and refine printing requirements.7 Design and Establish the Production Environment Purpose To create the production environment that will support the target applications.. The speed. however.5. 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. Although all of the operations and management tools and procedures have been tested during the system and integration tests.137 Confirm and refine production environment requirements. Confirm and refine remote access requirements. Confirm and refine network requirements. 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. lead times for purchasing components. 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. because of changes made during development and testing. Operations and management is the area of greatest complexity. set-up times and training for operations personnel. a particular configuration. some changes in supplier and product selection may be necessary. Timing The creation of the production environment begins concurrently with the construction of the staging environment. A. 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.1. a different code library or development data) that may not be present in the production environment. Implementation of the environments. This may be achieved by using physically separate platforms or security mechanisms that enforce separation on a single platform. Maintaining integrity of the environments insures that the applications will still function even if the environment is completely rebuilt and the applications reloaded. However. This would invalidate the testing and could lead to application failures during production.g.. Determine the needs and evaluate the impact on system performance and security. Fast. 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. high-quality printers such as high-speed laser printers may be necessary for reports.

memory and storage requirements for all of the different types of application servers. Refine production operations and management roles and responsibilities. Confirm and refine the processor. Page 89 . Consider the difficulty of managing the configurations of production hardware. may be adequate for administrative needs. All the systems throughout the BW environment are on supported and fully functional software profiles. memory and storage requirements for the client machines. Confirm and refine the processor. Confirm and refine the processor. There may also be special printer requirements such as for special stationery. Confirm and refine client machine requirements. memory and storage requirements for the database servers. A. Procedure • • Determine the start and target configuration for each of the necessary software profiles Once these tasks have been established. remote printing or special fonts. Confirm and refine configuration management/change control requirements.1. A. the information can be channeled into the flowchart available in the installation manual. with assistance from your hardware partner. 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.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology such as ink jet printers.1.138 Estimate BW data volume Purpose The purpose of this task is to develop specific sizing proposals for the production environment. to determine at which point during the process the software should be installed. Confirm and refine database server requirements. 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.139 Define Software Environment Purpose The purpose of this task is to define the BW software environment required for the Production system. Confirm and refine application server requirements. Early planning enables the scheduling of the non-BW software installs to be performed at the most suitable point in the BW installation timetable. software and network devices. Large or distributed production environments complicate the task of managing configurations and may require more sophisticated tools and/or processes.

place the purchase order for the initial BW development system software. and subject to the external software partner Service Level Agreements.1. determine the expected delivery date of the hardware.140 Order Hardware Purpose The purpose of this task is to place the initial hardware order with the appropriate vendor.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A.1. determine the expected delivery date of the software. Procedure • • On the basis of the internal project Service Level Agreements.1. the other project leaders and the project steering committee should be kept informed of the status of the BW system installation. Also. A. A. place the purchase order for the initial BW development system hardware. and to determine the expected lead-time needed to procure the productive system software. order any additional dependent hardware required for the development.142 Order Network Facilities Purpose The purpose of this task is to order and install the network connection to the BW system environment. and to determine the expected lead-time needed to procure the productive system hardware. Also. order any additional dependent software required for the development. the other project leaders and the project steering committee should be kept informed of the status of the BW system installation. 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 Page 90 . and subject to the external hardware partner Service Level Agreements. Procedure • • On the basis of the internal project Service Level Agreements. Inform the project steering committee Where required by the internal service level description.141 Order Software Purpose The purpose of this task is to place the initial software order with the appropriate vendor. Inform the project steering committee Where required by the internal service level description.

ora<SID>.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. Access for these users must only be given to key members of the technical project team. Provide security to ensure the integrity of the BW SAP technical environment and data. • 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. Define a procedure for requesting operating system and database access for the production system.1. interfaces. 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. Procedure • Implement appropriate operating system and database level access security Analyze the types of reports.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. Provide and ensure security for BW SAP operating system and database users. Every change of the access rights owned by the project members has to be well documented. Provide sufficient security to insure the integrity of the BW SAP system. that is projected. Create operating system and database level access for users. A. Determine from this the reports and interfaces requiring operating system and database access. and at what level.144 Secure Operating System and Database Purpose The purpose of this task is to determine operating system and database security for users. data feeds. Page 91 .1.

routers).8 Install and Configure Technology Components Purpose To install the different environments necessary to support the entire DW system development effort. It is important to request that the hardware vendor perform appropriate post-installation hardware exercises (for example.145 Coordinate with network and communications personnel. 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 . network devices. Overview The steps in this task will be repeated for each of the different IT environments to be created. A. verify tape device. and connect the hardware to the existing network.1.5. Depending upon the complexity of the different environments. additional servers. Standards may include: • Node naming conventions.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. A. it is important to approach the task in a structured manner to reduce rework and to ensure a high quality installation. Regardless of the size of the effort. verify disk devices). A.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. printers. 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.146 Install Initial Hardware Purpose The purpose of this task is to engage the services of the hardware vendor to install the appropriate hardware. Alternatively.1. it may be accomplished in one day by one person. this task may be extremely complex taking months to complete and much effort to accomplish.1. and • Server naming and configuration conventions. install any additional dependent hardware defined during identification of BW technical requirements (for example.

THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. The purpose of this activity is to define the process of installing Business Information Warehouse Extractor Add-on to the R/3 OLTP System.    • • Page 93 . Procedure • Preparation Review OSS notes. 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.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. Create an installation directory. These extraction programs will be installed on an R/3 development box. 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.148 Install Business Information Warehouse Software Purpose The purpose of this activity is to demonstrate the installation of Business Information Warehouse Software. there are the extractors on the R/3 side and in the BW. An integrated R/3 and BW environment consists of a BW instance and a R/3 instance with BW Extractor. When install BW.1.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. Procedure • • • Install the required desktop components on a PC configured to meet the SAP BW PC standard.150 Establish ALE System Connectivity Purpose The purpose of this activity is to establish ALE system connectivity. otherwise the BW Business Explorer component will not work) • Coexistence with external client software Page 94 . 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. Verify the user can perform the activities with the hardware. 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. The required PC components are shipped with the installation package.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. The software component utilizes Microsoft Excel to access and view BW reports.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. The Business Explorer allows users to display existing reports.1. Configure and install the front-end hardware for the user. A. Install and configure the SAP GUI on each client. train the Help Desk staff. If necessary. Determine a flexible initial installation procedure.1. review the Help Desk procedure you defined in the Determine System Problems and Error Handling task. In parallel. or modify existing BW reports.1. This task specifically addresses the installation and configuration of the BW OLAP Business Explorer software component. create new BW reports. Test the SAP GUI capabilities for each client’s configurations.

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 .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.

For example: allocating the scores ranging from zero at the low end (i. Obtain formal written approval of the Technology Design deliverable.1. or using a scale such as: Point Level 5 Exceeds 4 Fully meets 3 Partly meets 1 Ineffective 0 Does not have Page 96 .154 Submit the Technology Design deliverable to management for approval. 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. Submit the Technology Design deliverable to management or the steering committee. The requirements are then "scored" by measuring the degree of compliance to a standard. Overview The findings and issues from this phase are assembled into the Technology Design deliverable for presentation to management for review and approval.. feature does not exist/requirement not met) to five at the high end (i. requirement fully met/exceeded).153 Assemble and review the Technology Design deliverable. This may take more than one meeting. A. • The results of the evaluation process and any relevant supporting documentation. 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.e. • Selected primary suppliers (if applicable). • The specification of the selected technology design.5. Establishing a WRA evaluation process consists of the following basic steps: Assign appropriate weightings to each of the requirements to reflect its relative importance. and • Technology Pilot results (if applicable).THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A..9 Submit Technology Design Deliverable Purpose To assemble and submit the Technology Design deliverable for management review and approval. A. Package the work products from this phase into a deliverable document to include: • The Technology Infrastructure Alternatives. Discuss the key findings of the significant sections and resolve any questions or issues.e.1.

Validate the weights and score system. Page 97 .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.

The frequency of back-ups must also be determined.1.g. These procedures may include establishing a formal Help Desk facility but. Providing technical support for the different environments is an ongoing process and includes all members of the project team. Overview The steps in this task will be repeated for each of the different IT environments to be created. Maintenance should also be proactive. recovery and restore procedures. or • Application support. • Poor performance. e. Support issues may include: • Development tool problem reports. A. Accordingly. Regardless of the size of the development team and accompanying environment. Establish back-up. should identify technical support personnel responsible for specific support issues.156 Establish back-up/archive procedures. Any changes or upgrades should be tested thoroughly before deployment.. Although there are a number of back-up rotation alternatives. 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. each project should have established procedures for reporting problems and resolving hardware and software issues. On a large project in the middle of design and construction. consideration needs to be given to on-line back-up procedures and technologies as appropriate.155 Establish Help Desk procedures.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A.1. • Hardware failures. A. Page 98 .10Support Technology Environments Purpose To ensure that a stable environment is available at all times and. at minimum. Establish the Help Desk procedures. • Network errors. the primary objective is to identify what data needs to be backed-up and procedures put in place. in the event of system problems. • Software problems. to minimize any down time.5. developers should be discouraged from modifying their workstation configurations.

The Cutover Plan focuses on the activities. The Cutover Plan includes a checklist that reviews points of readiness. Page 99 . and provides the basis for approval to progress. Engaging part of the support team as testers after the system and integration tests can help their training efforts.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A.5. The main benefit is a plan to ensure a smooth transition to production. A strategy for providing support should also be determined. The planning should include any personnel considerations (availability. The Production Support Team can be called upon for assistance with technical issues. tasks.1. Tasks • • Determine Production Support Plan Determine Cutover Plan A. The plan must cover application data. The Cutover Plan covers activities for setting up and initializing the production environment. transaction data. master data. power-users or functional analysts will provide the first level of support. and basic BW-related questions and issues (Level 1 Support). appropriate procedures. Problems requiring advanced knowledge of the warehouse or BW should be referred to a Level 2 Support team. etc. such as. Procedure • Create Cutover Plan Prepare a plan for migrating the system and organization to a production system. Referring to this plan if difficulties arise can serve as a guide to action when issues arise. ongoing communications with Production Support should be maintained. Throwing support “over the fence” can result in unpleasant experiences for your users as they begin using the production system. The process of integrating with Production Support should begin as early as possible. In some cases. A. and customizing and repository objects. particularly for business-related issues.157 Coordinate with the Production Support Team Project communications with the Production Support Team Leads ideally should begin during the Project Start-Up stage. adequate coverage) along with infrastructure issues (problem tracking system in place. or as soon thereafter as possible. The plan is called a Cutover Plan. along with providing more ‘real-world’ testing conditions for the system.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.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. As the project progresses through the Business Blueprint and Realization stages. training.). which can typically be comprised of the implementation project team members.1. and timing of the final days of effort.

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. users. ensure that transactions are working. power users. Estimate how long it can take for each type of conversion (master data and transaction data) including executing the data conversion programs. and users have appropriate Page 100 . it is important to consider this option. Consider operations in other time zones. • Create a Contingency Plan The Cutover Plan must include a contingency plan for delays. and key company senior management. • Create a Final Checklist This final checklist reviews points of readiness and provides the signal to progress. 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.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. and time for manual data conversion. it may not be possible to convert the business operations back to the legacy system. However. The contingency plan must address how long (in hours or days) the new production system cutover can progress but be stopped. 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. Determine how much time is required to rerun programs if programs abort. When must the data be backed up? Determine who reconciles the data and when. It is standard practice to have a point of no return for making the new system operative. and legacy systems restored. • Determine Conversion Timing and Schedule Determine the timing and schedule of the final data transfer (conversion). 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. The plan must be presented in summary form to the Steering Committee. core project team leaders. After a few hours or days.

or ‘live’ transactions. The Cutover Plan can provide for an initial start up of the new system before most users sign on. This can be done through display transactions and reports. a Power User can enter the first transactions to ensure that everything is operating as designed. Page 101 . For example.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology system access.

However. Overview Throughout all of the stages of the DW life cycle. to identify and address scope issues and to conduct appropriate Quality Management Reviews. there is a need to monitor and report project status. the CPDEP Phase 1 task of “Identify and Assess Opportunities” is completed. Revisions to the plan fall into three broad categories: • Minor changes to static information. additional tasks will have to be completed. Amendments will be made during each stage as changes are identified and the results of quality reviews are included. One of these points is the completion of the Project Preparation Stage and these additional tasks are described in the Project Preparation Checkpoint Phase. in this Phase. Page 102 . the risk assessment needs to be reviewed to reflect changed risks in construction. At the end of each stage. a major revision of the Project Charter occurs and this is the main focus of the checkpoints. at specific points in the life cycle. and • The addition of new information not previously recorded. and a recommendation and Class 1 Estimate provided for the DRB/GRT. change and issue resolution procedures and project organization will generally change little on transition from Project Preparation to the Business Blueprint.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. Additionally. 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. 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. In the Project Preparation Checkpoint.6 Project Preparation Checkpoint Purpose To confirm the results of the Project Preparation Stage of the DW project with management. • Major revisions to existing sections. Revisions may be needed to the project work plan and the detailed work plans. many of the items fall into the first category. Items such as project background. The Project Charter is a living document that will be continually updated throughout the life cycle of the project.

THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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 D a t a w a r e h o u s i n g p r Co d P r o j e c t P r e p a r a t i O p e n I s s u e s R e F 2 v i e w I s s u I s s u e s e r e s o l u t i o n s P r o j e c t p l a n s U p d F 3 a t e P r o j e c U t pP d l a a n t e s d p r o j e c t p l a n s Q u a l i t y P l a n U p d F 4 a t e Q u a U l i t y p P d a l a t e n d Q u a l i t y P l a n 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 P r e p a r a t i o n S t a g e D F o r m a l A p p r o v a l P o i n t Page 103 .

Overview The data.1. obtain formal written approval of the change from management. Resolve the issues as possible and document any outstanding issues to be addressed by the Issue Resolution Process.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. process and technology abstracts with management. Discuss and confirm with management the completeness and accuracy of the data. Page 104 . Determine the impact of the findings or issues on the project. The focus is on confirming the completeness of the results and findings and determining their impact on the project. process and technology definition work products developed during the Project Preparation Stage are discussed with management. If a project scope change is needed.1 Confirm Completeness of the Project Preparation Stage Purpose To complete an integrity check of the Project Preparation Stage deliverables.159 Confirm the completeness of the data. process and technology abstracts. A.6.

Review all open issues contained in the Issue Resolution Log.2 Review Issues Purpose To identify all outstanding issues and either resolve or agree future actions. an agreed approach to resolving all outstanding issues. Ideally.1. an approach describing how these will be resolved should be developed and agreed. no issues should remain outstanding at the end of the Project Preparation Stage. The decision on the importance of resolving an issue should be made by the project manager in conjunction with senior management. Page 105 .THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. A. Overview All issues must be reviewed and appropriate action agreed/taken. In practice. Identify possible resolutions and initiate appropriate corrective action. The cost of investigating outstanding issues may need to be split between both parties. A.6. it turns out to be an expansion of scope or an error in information provided by the user. not all issues will need to be fully resolved before progressing to the Business Blueprint Stage. For any issues that will not be resolved immediately. if after investigating an issue. Ensure that procedures for investigating outstanding issues are fully understood by both developers and system users.1. the cost of the investigation as well as the resolution of the error should be borne largely by the system users.160 Review and resolve any outstanding issues. Document on the Issue Resolution Form or cross-reference to the Issue Resolution Form. e.161 Agree approach to outstanding issues. Assess the impact of any outstanding issues and reflect in the plans and risk assessment for the next stage..g.

1.165 Produce detailed work plans for the Business Blueprint Stage. • Change Integration. update the project plans for the following Cross-Life Cycle Phases as appropriate: • User Documentation. Use the plans currently contained in the project work plan and the revised estimates.163 Consolidate plans into the project work plan.162 Develop plans for the Business Blueprint Stage.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. Page 106 . The standard tasks may. Overview This task updates the project plans to reflect the impact of the findings obtained in the Project Preparation Stage. • Technology Planning. Review the original estimates for the Business Blueprint Stage which were made based on the best knowledge at the time. In addition. however. and • Technology Planning. • Data Transformation System Design. The Business Blueprint Stage consists of the following main phases: • Analysis and Decision Process Definitions. Support and Cutover (begun or continued).1. Support and Cutover. A. 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. • Training.164 Revise estimates in light of previous experience. findings and issues relating to the DW project gathered during the Project Preparation Stage. Develop detailed work plans for the Business Blueprint Stage. taking into account the available staff and skills. need some tailoring for the particular project. 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. Develop plans for the Business Blueprint Stage considering the understanding.6.1. and • Data Design. A. • Analytical Processing Data Definition. Identify the tasks needed to complete these stages. A.3 Update Project Plans Purpose To update the project plans based on the findings and information obtained during the Project Preparation Stage. A. • Acceptance Testing.1. • Prototyping. • Presentation System Design. 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. For each task estimate: • Number of project staff.

A. Seek formal written approval for any actions to be taken and revise plans accordingly.166 Validate overall project cost and time estimate. • Re-phasing of the work to ensure that time scales are met. Develop final cost and timing plans. Any changes to the project work plan necessitated by resource or other constraints should be reflected accordingly. Some of the data needed to prepare an estimate may not be available. • Scheduling. For these situations. For each subsequent phase. Duration and scheduled completion of each task. This may include: • A negotiated reduction in scope based on changed costs. Compare the final cost and timing plans with the originally agreed figures. review any discrepancies and take appropriate action.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology • • Amount of time each person is allocated to a task. Page 107 . or • Reducing the staff complement to reduce cost but increase time scales. determine and document the assumptions used to prepare the estimates. • Agreeing a revised cost of the project. • Revisiting the original scope to see if scope has changed over the lifetime of the project. • Amount of time estimated to complete a phase. based on the detailed work plans.1. The estimates should include the amount of time and effort required from the users. • Increasing the staff complement in an attempt to reduce time scales at increased cost. prepare a high-level estimate including: • Staffing resources by skill level.

as appropriate. Identify where the risk ratings described in the Project Risk Assessment are higher than expected or are greater than originally.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A.6.168 Review project risk dimensions. the Project Preparation Checkpoint Phase has largely been concerned with work planning. 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.4 Update Project Charter Purpose To ensure that all aspects of planning and quality have been properly addressed.167 Review and revise Project Risk Assessment. Page 108 . the Project Risk Assessment needs to be revisited. In this latter instance. 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. Those sections of the Project Charter that need to be updated for design are reviewed and amended or created. A. Update the implementation strategy. These are reviewed and appropriate amendments made to reflect the end of this stage and the start of the next. Obtain agreement with management on the appropriate actions to take. assess the impact of making changes to the project plan on the associated strategy documents developed in this stage. In particular. 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.1. data conversion strategy and appropriate testing strategies as necessary.. Many issues are addressed in the Project Charter that go hand-in-hand with the work plans. Overview To this point. 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.g.

document: • The likelihood of impact on the project. avoidance. For identified threats. assumption or transfer). A. Page 109 .THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A.1. Revise the Project Charter as appropriate. • The severity of the risk.169 Revise risk management approach. • How will the fact that the risk factor has come to fruition be recognized.1.. Review the Project Risk Assessment to identify any changes from the initial assessment.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. control.g. and • How will the situation be addressed (e.

THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. A. the deliverables and a Class 1 estimate are provided for approval to the GRT/DRB as per CPDEP. Complete the necessary approval procedures to complete CPDEP Phase 1 “Identify and Assess Opportunities”. formal written approval should be sought for deliverables on an ongoing basis. *** FORMAL APPROVAL POINT *** Page 110 .1. At the close of the stage.171 A. At this point. Submit and discuss Project Preparation Stage deliverables. a final review of deliverables is undertaken and formal written approval obtained for all of the Project Preparation Stage deliverables. Combine the findings of this stage into a Project Preparation Stage document. Obtain formal written approval of the Project Preparation Stage deliverables as defined in the Project Charter and the project contract. Review the work deliverables and address any outstanding sign-off issues. Many of the deliverables should have already been subject to review and formal written sign-off by user representatives.172 Summarize findings of the Project Preparation Stage. Responsibility and time scales for formal sign-off should have been defined in the Project Charter and project contract. Discuss the Project Preparation Stage deliverables with management and resolve any questions and issues. A.1.1. Overview Throughout the Project Preparation Stage.6.173 Obtain formal written approval of the Project Preparation Stage deliverables.5 Obtain Approval of Project Preparation Stage Deliverables Purpose To seek final review and formal written approval of the Project Preparation Stage deliverables.

MDM) 3) High-level Design 4) Data Conversion Specification 5) Data Transformation System design a) InfoObject Characteristic. During this stage.0B/3. 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. 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. LDM. texts. including master data. and the presentation system. the data warehouse database (InfoCubes).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 . In design.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology Business Blueprint The Business Blueprint Stage derives a design for the DW system including the data transformation system. an integrated model is developed to depict "how" the requirements are to be implemented in the new system from a business and technical perspective.

Presentation System Design The data access and presentation requirements are translated into a set of technical specifications for the DW presentation system. • Data cleansing/scrubbing (Transfer rules/routines). and • Data presentation layer is concerned with the media used in presenting the analysis results to the end-users such as visualization. Based on an analysis of the organization's business events. data mining. data source and its media. the analysis and decision processes including the performance measurement processes. [duplicate from a few paragraphs above] Page 112 . such as multimedia data. The source data and the derivation or transformation rules are also determined. data definition on a DW project focuses on determining the information needs of the various user views including performance measurement and quantitative analysis. The data transformation requirements provide the key inputs to the development of the data transformation system.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. in the form of a Conceptual Data Model (CDM) with the associated performance measurement. To support the analysis and decision processes. 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. • Data refreshing. Data Design The data requirements defined during the Analytical Processing Data Definition Phase. Data transformation is the process of transforming source data to target DW data. The key components of a DT system include: • Data extracting. • Data transforming (InfoSource integration). The data access requirements provide the key inputs to the development of the DW presentation system. update and maintenance. quantitative analysis processes and ad-hoc analytical processes are identified. required to support business processes are also identified. Unstructured data entities. and • InfoCube monitoring. 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. format of data. are translated into a DW database design consisting of a Logical Data Model (LDM) and a Multi-Dimensional Data Model (MDM). 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. audio presentation. graphical presentation or other forms of presentation media. • Data analysis layer is concerned with the core analysis tasks such as performance measurement. Analytical Processing Data Definition The requirements for the data warehouse are defined in the form of a Conceptual Data Model. if applicable. quantitative measurement and unstructured data entities. DT system design must be completed within a relevant overall BW architecture. statistical analysis and decision analysis. • Data transfer. level of data aggregation.

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

THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology

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

THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology

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

G

A P

d h o c r o c e s s e

s

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

t

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

e

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

n

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

d

e

f i i n

i t i o

n

d

e

l i v e

r a

b

l

Page 115

THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology

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

1993]) may be used as a framework for business event analysis. the business events may be further decomposed to lower level events to meet the needs of a specific analysis or objective. By capturing data about underlying business events. while an acquisition/payment process may involve a wide variety of goods and services (e. Thus. the relationship between the two is that . human resources.176 Identify the essential characteristics of the business events.g.. maintain the reference data about business events and report the information to authorized users. human resource view. REAL is an acronym for: • Resources . 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. Cherrington. As needed. • Select a supplier. marketing view and production view) can be supported. A.g. • Order the goods or services.Organizational resources used by the business event either directly or indirectly. supplies or inventories). • Inspect the goods or services. a wide variety of information user views (e. paying for only that which is received and making sure that the resources acquired are available when needed. Document the business events including their characteristics and the information used by the business event. Andros and Sawyer Hollander. • Receive the goods or services.1. the basic types of business events may include: • Request the goods or services. the event is probably Page 120 . executive view. Review with management to identify the essential characteristics of each business event. The latter are the activities that record business event data. Event-Driven Business Solutions: Today's Revolution in Business and Information Technology [Irwin Professional Publishing. accounting view.177 Analyze the characteristics of the business events. A. Analyze the characteristics of the identified business events.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. 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.business events trigger information processes.. it is important to distinguish between business events and information processes. financial resources. receiving only what is ordered. If it is difficult to identify a resource for a business event. Thus. and • Pay for the goods or services. The REAL business modeling technique (discussed in Denna. In determining business events.1.

g. inventories) or conceptual (e. Event .. equipment. Roles may sometimes be performed by machines (e. the information needs (or views) of the various information users can be supported. Thus. robots). By capturing the essential characteristics of an organization's business events. engineers. cashiers. Resources and locations are typically placed on the left side of events and agents are placed on the right side. and Locations .. Resources may be physical (e. • • • In REAL modeling.g.g. agent and location boxes. Discuss the business events and their characteristics with knowledgeable users. in a structured walk-through format. production workers) or external (e.The business event being modeled. suppliers). business events and the associated resources.. agents and locations are represented in rectangular boxes with lines connecting the event box with the associated resource..178 Discuss and confirm the business event analysis results with management. customers. Page 121 .People or machines that execute the business event (i. employee skills.1. financial resources). Agents . Alternatively. patents.Places where the business event took place. Resolve any questions or issues and make any changes as necessary. analyzing business events facilitates the integration and sharing of data within the organization. "time" is an attribute of a business event.g. buildings.e.g. Agents could be internal (e.. Analyzing business events provides a process perspective in determining the information content of the data models. a "time" dimension may be explicitly modeled. play roles or perform responsibilities with respect to the business event). Using the REAL business event modeling formalism. A. as appropriate. ATM machines. supplies.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology unnecessary or adds little value..

and  external and internal business perspectives. 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.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. the data required to support these processes is defined and modeled in the Analytical Processing Data Definition phase. Overview Identifying and understanding performance measures helps in determining the information content and data access requirements of the DW system. In addition. If required. Page 122 . • Performance measures must have measurable goals.  cost and non-cost measures.  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). An organization's performance measurement set must: • Align with the organization's business strategy. 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. and • The performance measurement set should encompass all business processes of an organization and present a comprehensive and integrated view of the business. Based on an understanding of these processes.7. • Performance measures should constitute a balanced set consisting of both:  result measures (usually financial in nature) and process measures (about the underlying business processes). 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. This task focuses on identifying the organization's performance measurement processes which are to be supported by the DW system being developed. the scope of a DW project may be expanded or a separate performance measurement project may be initiated to define the performance measures. It is beyond the scope of a typical DW project to develop an organization's performance measures. Measurement feedback should indicate whether these strategies are being achieved. and • Include all relevant aspects of the business processes as reflected in the organization's value chain. 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.2 Identify Performance Measurement Processes Purpose To identify the performance measurement processes to be supported by the proposed DW system.

customer order entry. minutes and other relevant information presented or discussed during these meetings. (Optional) Determine the need to develop a new performance measurement system based on the findings of the review of the current performance measures. It is. This information should also include cyclical or annual events such as the budget creation and review process and the capital expenditure budgeting process.179 Gather information on the current performance measurement system. focus on understanding the: • Objectives of each measure. In reviewing the current performance measurement data (e. if separately derived. A.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A.g.. management/performance meeting documentation). define and document the measures as discussed in the Identify Performance Measurement Entities task of the Analytical Processing Data Definition phase.. For some information systems. If the performance measures are of interest to the project. A. • Performance measurement goal setting mechanisms.1. performance measurement reports. receive or present.1.181 Develop a balanced set of performance measures. 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. human resources. • Obtain copies of reports prepared by the IS Department and a list of recipients of each report. and • Reporting and usage of performance measurement data. In proposing to develop a new performance measurement system: Page 123 . data obtained from performance review reports or management meeting documentation). therefore. While some of the performance measurement data may be clearly stated or presented (e. marketing and sales. • Data collection and/or generation processes together with timing and frequency. materials management and information management and the major operating units of The firm.1.g. • Data sources including both internal and external sources. data may only be available as screen formats or output files. Review and refine the list of information needs as appropriate based on the findings of the analysis of the current performance measures. Analyze the current performance measurement data gathered that relates to the project scope and identify the current performance measures. Functional and operations managers should represent the organization's key functional areas such as finance. reports and performance measures that they create. necessary to analyze the current performance measurement data gathered from various sources and organize it into individual performance measures. 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. other data may be hidden in various management or operation reports/information presented or used by functional/operational managers or senior executives.180 Identify the current performance measures.

Determine the data access characteristics of the performance measurement processes considering: • Volume of data required for analysis. the granularity of data requirements). and • Integration or interoperability requirements. 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. • Data sources (internal or external sources). Determine the distribution characteristics of the end-user data accesses including areas such as: • Geographical distribution of users. and • Obtain formal written approval of the changes before proceeding. • Source data media (e. structured versus unstructured data). A.. skill sets) required to develop a performance measurement system must be identified. • Divisional/functional organization of users. • Priorities of performance measurement reports. and • Vertical/horizontal organization of users.. • Organizational distribution of users. • Standard performance measurement reports. If the scope of the DW project is to change: • Formally document the amended scope. • Determine the resource requirements. It may be appropriate to prepare presentations for management on the concepts and benefits of a new performance measurement system.g.e. • Prepare an amended work plan and timing and cost estimates.g. • Continuous improvement analysis. Senior management commitment and support is critical for the success of a performance measurement project.. and The project resources (e.1. 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 additional work required to develop a new performance measurement system must be determined. • Data "drill-through" requirements. • Level of information required (i. The scope impact on the current DW project must be assessed and discussed with management.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology • • • The justification for developing a new performance measurement system must be developed. Page 124 . region and time)..g.182 Determine the data presentation characteristics of the performance measurement processes. 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. Determine the data analysis characteristics of the performance measurement processes considering: • User analysis perspectives of data (e. analysis dimensions such as product. • Top line/exception reporting.

• Audio presentation. resulting performance measures). Resolve any questions or issues and make any changes as necessary.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology • • Any new information created as a result of the analysis processes (e. and Determine the presentation media characteristics of the performance measurement processes such as: • Visualization. Discuss the identified performance measurement processes and their data presentation characteristics with management.1.183 Discuss with management the identified performance measurement processes. and • Other forms of presentation media. Whether the analyses are currently performed or are planned in anticipation of the availability of the DW data. • Graphical presentation.g. Page 125 .. A.

1.184 Analyze the information infrastructure supporting the organization's decision process structure.. Based on an understanding of these processes.e. the intelligence. In addition to raw transaction processing data.g. 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. A. design and choice phases discussed in the Task Overview): • Intelligence Phase: Information required to proactively anticipate problem or opportunity situations before they occur (e.3 Identify Quantitative Analysis Processes Purpose To identify the quantitative analysis processes to be supported by the proposed DW system. 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..7. • Analyze each major decision process to determine the information required to support each phase of the decision process (i. 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. and • Bottom-up approach based on interviewing management and reviewing current quantitative analysis data usage. Page 126 . 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. • Review the understanding of the organization's current business environment focusing on the key decision processes. Unlike transaction processing. scanning internal and external databases for opportunities and problems and generating performance measurement exception reports).g. completing "what if" type sensitivity analysis).THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. • Design Phase: Information required to generate alternative courses of action. Overview This task identifies the quantitative analysis processes supporting management decision making in the organization within the scope of the DW project. In addition. 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.. the data required to support these processes is defined and modeled in the Analytical Processing Data Definition phase. management decision making is not as well defined and is typically ad hoc in nature. 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.

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

A.187 Determine the data presentation characteristics of the quantitative analysis processes.. the granularity of data requirements).g. • Priorities of quantitative analysis reports. • Data sources (internal or external sources).188 Discuss with management the identified quantitative processes. Resolve any questions or issues and make any changes as necessary. • Audio presentation.g. structured versus unstructured data).1. Determine: • Whether the analyses are currently performed or are planned in anticipation of the availability of the DW data. Determine the presentation media characteristics of the quantitative analysis processes such as: • Visualization. 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..g. Page 128 . Define the QM data describing: • The business objectives supported by the QM data.1. • Source data media (e. • Data "drill-through" requirements. Summarize the data access characteristics of the quantitative analysis processes as determined earlier including: • Volumes of data required for analysis. Summarize the data analysis characteristics of the quantitative analysis processes including: • User analysis perspectives of data (e. Determine the distribution characteristics of the end-user data accesses including areas such as: • Geographical distribution of users.. • The quantitative analysis process that uses or creates the data. • Standard performance measurement reports. and • Integration or interoperability requirements. • Organizational distribution of users. • Divisional/functional organization of users. • The quantitative analysis techniques used in deriving the QM data.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology • The results of the quantitative analysis processes as a source of data for the DW. and • Other forms of presentation media. Identify the relevant quantitative measurement (QM) data either as DW input to or as DW source data from the quantitative processes. • Level of information required (i. region and time).e. analysis dimensions such as product. • Graphical presentation. and • The interpretation of the resultant QM values focusing on their business implications.. and • Whether any analysis tools (e. and • Vertical/horizontal organization of users. A. • Continuous improvement analysis. Discuss with management the identified quantitative analysis processes and their presentation characteristics. • Top line/exception reporting. • Any new information created as a result of the quantitative analysis.

By definition. and • Vertical/horizontal organization of users. Determine. The performance measurement and quantitative analysis frameworks discussed in Tasks G2 and G3 may also provide a context for identifying ad hoc processes.1. • Data sources (internal or external sources). structured versus unstructured data).g. Purpose To determine the characteristics of the ad hoc analysis processes to be supported by the proposed DW system. • Organizational distribution of users. Determine the distribution characteristics of the end-user data accesses including areas such as: • Geographical distribution of users. A. the data required to support these processes is defined and modeled in the Analytical Processing Data Definition phase. the types of data accesses and the access paths). or • Reviewing the performance measurement and quantitative analysis frameworks and processes. Identify the types of ad hoc analysis processes to be supported through: • Analyzing past ad hoc data usage patterns (e.. A. and • Integration or interoperability requirements. Overview This task focuses on identifying the organization's ad hoc analysis processes which are to be supported by the DW system being developed.4 Identify Ad hoc Analysis Processes. • Level of information required (i..7. if possible. • Divisional/functional organization of users.e. Page 129 . ad hoc analysis processes cannot be predetermined. Determine the types of data required to support the identified ad hoc analysis processes.190 Determine the data presentation characteristics of the ad hoc analysis processes. 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.1. • Discussing with management or business analysts to determine their ad hoc analysis information needs..THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. quantitative analysis or other analysis processes.g. Based on an understanding of these processes. • Source data media (e. Determine the data analysis characteristics of the ad hoc analysis processes considering whether: • The analyses are performance measurement. However. the granularity of data requirements). the data access characteristics of the ad hoc analysis processes considering: • Volume of data required for analysis. • Data "drill-through" requirements.189 Identify the types of ad hoc analysis processes to be supported by the DW system.

Discuss with management the types of ad hoc analysis processes to be supported and their data presentation characteristics. and • Other forms of presentation media. 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. • Graphical presentation. A. • Audio presentation.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology • • • Any new information created as a result of the analysis processes.191 Discuss with management the data presentation characteristics of the ad hoc processes. The analyses are currently performed or are planned in anticipation of the availability of the DW data. Page 130 .1. Determine the presentation media characteristics such as: • Visualization. Resolve any questions or issues and make any changes as necessary.

192 Develop high-level descriptions for each of the analysis and decision processes. and • Reporting frequency and distribution requirements. • customer analysis and reporting. • The type of analysis performed: • compliance analysis and reporting. Review standard reports used/created/distributed from the R/3 system Page 131 .. A.193 Define reporting requirements for the analysis and decision processes. A. Develop high-level descriptions for each of the analysis and decision processes identified including items such as: • A description of analytical process.. A. Define the reporting requirements as appropriate for the analysis and decision processes considering items such as: • Reporting data elements and their sources.1. • The organizational units or users performing the process. Overview Process Descriptions are prepared for each of the analysis and decision processes identified in the previous tasks including the performance measurement processes. • Data "drill-down" requirements.1.5 Document Analysis and Decision Processes Purpose To document the analysis and decision processes to be supported by the proposed DW system.g. external or internal sourced data). • supplier analysis and reporting. • Data aggregation requirements. • Summarization levels. and • The sources of the data (i. • The type of data required to support the process (e. or • financial analysis and reporting.194 Procedure • Determine and document Operational Reporting Requirements The purpose of this task is to determine and document operational reporting requirements.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A.1. • Unstructured data requirements. 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. quantitative analysis processes and ad hoc analysis processes. • management decision analysis and reporting. performance measures or quantitative analysis data).e.7.

Present the unified model integrating the transaction and analytical processes as appropriate. Discuss and confirm the identified analysis and decision processes with management.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. Resolve any questions or issues and make any changes as necessary. Page 132 .195 Discuss and confirm the required system models with management.1.

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. Reconcile the analytical processes with the associated internal source transaction processes to obtain a consistent. timeliness.199 Discuss and confirm the reconciliations with management. • Quality of data (e.. suppliers.1.198 Reconcile the analytical processes with the CDM.1. • Data communications/access infrastructure (e.g. and • Unstructured data entities. A. via network connections or the Internet). • Quantitative measurement entities. numerical.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. For external source processes or systems.1.. Page 133 . customers or government agencies). specifically focusing on the definitions of the: • Performance measurement entities. document their characteristics such as: • Ownership of the external systems (e. 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.g.6 Confirm Related Process Models Purpose To reconcile and validate the analytical processes against the CSFs (business focus) and the related transaction processes.7. and • Data availability (e.197 Reconcile the analytical processes with the source processes. Resolve any questions or issues and make any changes as necessary. textual. Identify the source processes or systems providing inputs to the identified analytical processes. A. Prepare an Analytical Process/CSF Matrix indicating which CSFs are supported by which analysis and decision processes defined in Process Descriptions..g. Confirm with management the accuracy of the support relationships between the analytical processes and the organization's CSFs as depicted in the Matrix. cleanliness). whether data is in the public domain or is available only with specific data sharing agreements such as those with customers or suppliers). unified process view for the purposes of: • Understanding and validating the flow of data between the transaction processing and analytical processes.. audio or video).g. Discuss and confirm the reconciliations with management.. A.196 Confirm support of the Critical Success Factors. • Data media (e.1. and • Confirming the sources of data for the analytical processes provided by the associated transaction processing processes.g. A.

Review the Process Descriptions for the analysis and decision processes for completeness and accuracy.200 Assemble process definition deliverable.1.202 Submit and discuss process definition deliverable with management. If necessary prepare an action list of items to modify. Overview The outputs from the individual tasks are consolidated into a process definition deliverable.1. A. Make any amendments as necessary. Confirm that the process definition deliverable accurately reflects the functionality needed by management and the users and obtain formal written approval. 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. Include the associated Process Descriptions in the structured walk-through. A.1.7.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A.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. The formal written approval of all of the analysis activities will be addressed as part of the Analysis Checkpoint Phase. 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. This step may involve more than one meeting. Approval at this point consists only of confirmation of the processes. Discuss the process definition deliverable with management and resolve any questions and issues. A.201 Conduct structured walk-through of the analysis and decision processes. Page 134 .203 Obtain formal written approval of process definition deliverable.1. A.

• The analytical processing data requirements are then determined in the form of performance measurement entities. 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. calculation and derivation algorithms. While the DW system (and its database) may be developed on an incremental basis (e.g. and • The data transformation requirements for the analytical data elements are determined in terms of data sources. The analytical processing data definition is validated against the corresponding process definition completed concurrently in the Analysis and Decision Process Definition phase. The data sources may be either internal or external sources. • The Analytical Processing/OLAP Data Model in the form of performance measurement (PM) entities. and • The Transaction Processing/OLTP CDM. Page 135 . Overview This phase determines the requirements for the DW database being developed.. cleansing. on a subject area by subject area basis). quantitative measurement (QM) entities and unstructured data entities. As illustrated in Exhibit E-1. quantitative analysis entities and unstructured data entities. Otherwise. the various DW databases developed over time may become "islands of information" with data that may be inconsistent or redundant. an organization's enterprise data model environment can be viewed as consisting of three data model types: • The Enterprise CDM. the development should be guided by an enterprise Conceptual Data Model (CDM).THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A.8 Analytical Processing Data Definition Purpose To determine the data requirements for the proposed DW. 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. These requirements provide the major inputs for the design of the data transformation system and possibly also the presentation system.

THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology 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 a l D a t a M o d e l 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 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 d P e r f o r m e n t i t i e s a n c e m e a s u m r e e m a e s u n r e t m e n t U n s t r u c t u r e d a t a e n 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 S A P S 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 u 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 D a t a S A P N o D n d a t a M a D e n p a t p i n t a g M d o c u 8 m e n t M a s t e r D a t a r e q u i r e m .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 n s f o r m a t i o n r e q u i r e m V a 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 d a t a d e f i n i t i o n s S u D b 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 n d e l i v e r a b l e Page 136 .

Each component CDM is built from a copy of the ERM. defining dimensions and their measures) on a DW project. 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. 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. quantitative measurement entities and unstructured data entities provide the direct inputs to the multidimensional modeling process. Page 137 . The CDM reflects the structure of the business functions rather than the processing flow or physical arrangement of data.e. the process of building the CDM may be easier by building separate. Multidimensional data modeling is discussed as an integral part of logical and physical data modeling in Data Design. Overview A CDM depicts the structure of an organization's data resource at a conceptual level in terms of data entities and their relationships. For large complex data models.1 Develop Conceptual Data Model Purpose To determine the data requirements for the proposed DW in the form of a Conceptual Data Model. • A CDM helps in understanding an organization's data resources and identifying data sources for the DW. It is the second data model in the top-down progression of data models as discussed in the Methodology Overview. • The entities and entity relationships defined in a CDM provide useful inputs for multidimensional data modeling (i. smaller CDM pieces. The purpose of this task is to create a structured business view of the data required to support current business processes.8..204 Develop CDM. While the CDM is a key part of data modeling in developing a transaction processing database. and • The performance measurement entities.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. business events.1. and related performance measurement and analysis efforts.

Page 138 . A. The identified performance measures are grouped into "entities" or "categories" for documentation purposes.1. A. Overview This task defines the selected performance measures identified during the development of the CDM. Document the performance measures as a part of business analytical information requirements which are an integral part of the CDM. derived attributes). they represent a major part of an organization's business analytical processing information requirements and thus should be formally defined and documented. A..206 Categorize the performance measures.8.2 Identify Performance Measurement Entities Purpose To define performance measurement data identified during information content analysis. The main purpose of categorizing measures into entities is to facilitate understanding and documentation of the performance measures. the measures may be captured in one of the following ways: • As attributes (i. These measures may be current measures or new measures identified in an expanded DW project or a separate performance measurement project. • As information facts in Business Analytical Information Tables.208 Discuss and confirm with management the performance measurement entities.205 Review the performance measures identified to be of relevance to the organization. Group the performance measures into their respective categories which may be referred to as performance measurement entities. The documentation of performance measures provides a key input to multidimensional data modeling .207 Document the performance measures.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. Depending on the nature of the performance measures and project standards. However. A. The performance measures are typically derived data that do not normally form part of the CDM. or • As entries in a Performance Measurement Documentation Database. 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.1. 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. Resolve any questions or issues and make any changes as necessary.1.1.the definition of dimension and fact tables in Data Design.e. 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.

Although quantitative measures are not traditionally part of the CDM..THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. However. How the data is categorized is sometimes an arbitrary decision. The main purpose of the CDM is to define the information content requirements for the databases being developed.g.1. outputs and attributes of the quantitative measurement entities that support an organization's business analytical processing requirements. and • Data purchased or gathered specifically to support quantitative analysis processes such as:  purchased demographics data of customers or prospects. they often represent an important part of an organization's business analytical information and processing requirements and thus should be formally defined and documented. 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. Quantitative analysis processes and models are documented in this task in the form of quantitative measurement (QM) entities.3 Identify Quantitative Measurement Entities Purpose To define the data inputs. 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. One QM process can correspond to many QM entities. it should be cross-referenced and defined in only one place to ensure data definition consistency. 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.  survey research data. e. and  competitor pricing data. and  advertising expenditures by market and channel.209 Identify and define the quantitative measurement data. in the standard CDM entity. performance measurement entity and/or QM entity).. A. which correspond to particular quantitative analysis models.  census data. Each QM entity requires specific data inputs and produces specific data outputs.8. Page 139 . each QM entity has particular characteristics or attributes that should be captured. data outputs and relevant entity attributes. For each QM entity. These quantitative processes were first identified in the Analyze Business Environment task and further refined in the Identify Quantitative Analysis Processes task.  product defect data from the quality control process. the process of sales forecasting can generate a different quantitative forecasting model for each product or product class. define: • Its data inputs.  product cost data. Overview This task defines both the data required and the data generated by the organization's quantitative analysis processes within the project scope.g. • The business objectives supported by the entity. whenever data is referred to in different types of entities in the CDM (e. In addition.

THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology The data outputs of QM entities are also of various types and some examples include: • Estimated probabilities of default for individual bank loans. the scope of QM data is broad and may overlap that of other entities. • Sales forecasts for individual products in specific markets. Resolve any questions or issues and make any changes as necessary. Document the quantitative measurement data as a part of business analytical information requirements which are an integral part of the CDM. 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.. The definition of the QM entities should include information such as: • The knowledge worker(s) or analyst(s) responsible for the entity.g. regression coefficients).. neural networks. In particular. Thus. 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. optimization algorithms). • Vehicle routing schedules that minimize total transportation costs. and • The quantitative techniques used (e.1.g.211 Complete a structured walk-through of the quantitative measurement entities.1. A. statistical confidence measures). • The model parameters (e. • The model performance measures (e.. and • Targeted lists of prospects for direct marketing campaigns.g. A. Page 140 .210 Document the quantitative measurement data.

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

Determine the requirements for the output data to meet the identified user business needs considering issues such as: • Format of output data (e.g. Data storage issues are addressed in Data Design as appropriate. generating an individual summary for each data item or a global summary for a collection). how important it is that everything in the resulting information be extracted and classified correctly). the extraction requirements and the output requirements. determine the needs for preparing summary data for the collections (e. Identify the input sources for the unstructured data such as: • Internal source systems.g. .1. competitor financial results. A. customers. and • Any additional requirements e.g.. Page 142 .214 Identify the input sources for the unstructured data.e. Review the data requirements to identify any data sources which are unstructured in nature.. and • Data to be viewed by users one data item at a time or as collections of data items. government. . Determine the properties of the data sources considering: • Availability of access mechanisms (e.. 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. suppliers. if any). classification or relevance ranking that must be included in the presentation of query results to users.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. customer complaints or external news of business event).1. • The required level of completeness (i. industry or competitor publications)..g.213 Determine the output requirements for the unstructured data.. • The maximum time available to process a query. how important it is that nothing in the original data source be missed)..XLS or other application format.g. • 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.g.. . • Data that needs to be converted from data in another medium (e. If data is going to be viewed as collections of data items. • Customer source systems. • Quantitative data that must be extracted from other sources. • Attributes to be used as keys for data retrieval. availability of API's. and • Public data (e...g. 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. A.1. • Qualitative data that may be available as an individual field or record or which may have to be extracted.e.WAV file or video clip). • External syndicated data sources. text. A. • Supplier source systems. scanning paper documents into document images).GIF file.. syndicated third-party data providers or the Internet).212 Identify the unstructured data elements to be supported by the DW system. data obtained from external sources such as users. • The required level of accuracy or precision (i.g.

• Impact of storage constraints on: • pre-extract.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology • • • • Restrictions on data redistribution (e. copyright and security).215 Determine processing resource constraints. to achieve complete accuracy in working with unstructured data. Substantial human involvement is often required if a high degree of accuracy is needed. Dialog. • index. The difficulties in working with unstructured data dictate that trade-offs may need to be made in the design process. • Industry databases.g. or • extract on demand. or • Diskettes.1. Timeliness. • CD-ROM's. • Possibilities for different points on the resource/quality spectrum. 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. or The frequency with which new data is added or existing data updated. A. • World Wide Web (WWW). • Arithmetic relationships.. Page 143 .g.. titles and headings).g. • Numbering of items or cross-references. Bloomberg). 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. • Formatting. Determine the input media format such as: • On-line service suppliers (e. abstract versus text body.. Determine the availability of alternate data sources with different properties such as: • Possibilities for filling in gaps in individual sources. • Budget constraints. It is expensive. • The availability of development resources for building custom data extraction and transformation software. • Logical structure of the document (e. • The availability of an appropriate software environment for running the custom or package software. • Tapes. and • Fields in semi-structured data. and • Development timing constraints. or • Necessity of merging multiple sources. The following exhibit illustrates the levels of effort for data transformation based on a paradigm of internal/external and structured/unstructured dimensions. • The availability of software tools for data extraction and transformation. if not impossible. the availability of the appropriate decompression and decryption tools and facilities. • If the data is compressed or encrypted. Cost.

THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology Page 144 .

. data types. type conversion needs.e.1. The primary objectives of Data Mapping are listed below: • For each dimension attribute and fact attribute. monthly. 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.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. report mockups and query samples) A. Steps • Collect data samples from Source System. • 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. Source to Target Mapping) Review all documentation for new BW queries and reports (i.217 Create SAP Data Mapping Document The purpose of this task is to create the SAP R/3 Data Mapping document. These tasks try to identify the source to target mapping from the R/3 to the BW systems. This document will be developed using the source system details gathered earlier in the requirement gathering process.1.e. which could satisfy unique BW analysis and reporting requirements Review potential R/3 data sources with Power User.5 Identify SAP Sources The purpose of this activity is to identify the required fields from the R/3 system. etc. Study current data collection field formats.. daily.e. identify the source element(s) that make up the target data item. Procedure • • • • • Identify potential SAP R/3 source system data at the functional module level. one sample for each data frequency (i. scrubbed information for populating the BW system. FI.8. and determine reformatting. Data Architect/Modeler. A.. weekly.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. etc. SD.) The data contained in the various sources may vary per frequency. and BW Analysis/Extraction Developer team members Identify the GOLDEN Source of R/3 system data Capture Data Mapping and Transformation Rules (i. and update data mapping document • • Page 145 . Review Source data collections for data availability and determine GOLDEN Source of data Update data mapping document with actual file or database names. etc. 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.) necessary to satisfy the BW data content requirements.

before/after images be compared.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology • • Identify different methods of moving data from the source systems to the BW system. time-stamped data or log/audit files be used Update data mapping document. and update data mapping document Define extract processing frequency. 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 . will full updates or delta file updates (data changes only) be performed.

1.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.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. Procedure • • Create a plan for each source system Document a flat file layout for source system A.1.8.1. A. 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 .220 Assign Resources to Obtain the Data Purpose The purpose of this task is to assign resources to obtain the data. 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. Consider utilization of 3rd party Extract and Transform tools (see ETL Strategy Document).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. A.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.

type conversion needs. and determine reformatting. Steps • Collect data samples from Source System. etc. and update data mapping document Define extract processing frequency. This document will be developed using the source system details gathered earlier in the requirement gathering process . before/after images be compared.1. Study current data collection field formats. • 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.e. Page 148 . weekly. data types. 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. 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. The primary objectives of Data Mapping are listed below: • For each dimension attribute and fact attribute.221 Create Non-SAP Data Mapping Document Purpose The purpose of this task is to create the Non-SAP Data Mapping document.. 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.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology Result Flat files will be generated to load into BW A. one sample for each data frequency (i. Review Source data collections for data availability and determine GOLDEN Source of data Update data mapping document with actual file or database names. etc. will full updates or delta file updates (data changes only) be performed. and update data mapping document Identify different methods of moving data from the source systems to the BW system. identify the source element(s) that make up the target data item.. monthly.) The data contained in the various sources may vary per frequency. daily. scrubbed information for populating the BW system.

THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology Page 149 .

namely time. 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. 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. Shared master data tables allow for easy handling of "slowly changing dimensions". each unique requirement for access must be defined within the requirements document. A master data table normally exists for each characteristic in a dimension table. unit. such as drill-down. The attributes in a master data table may be referred to as navigational attributes. Data is stored in BW Master Data tables to reduce data redundancy. and packet. or within. across. Also. except for some characteristics in the required dimensions. and InfoCube-independent attributes that are primarily stored in the Master Data tables.8. This is a definite advantage in integration and architecture. they behave like characteristics. up. and packet. A master data table is not required for each characteristic. resources are identified to obtain master data. attributes are separated into InfoCube-dependent attributes called characteristics that are assigned to the dimension tables. Result A clearly defined Master Data Requirements Document Page 150 . 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. There are various ways of accessing Master Table data. Master data can be sources from multiple R/3 and Non-R/3 systems.222 Create Master Data Requirements Document Purpose The purpose of this task is to create Master data requirements document.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. Procedure • • Define Master Data Table Requirements End User Requirements Document It is important to define the End User requirements for NAVIGATION. unit. using master data tables. The master data sources fields and the master data merging strategy should be clearly defined. • • BW Data Mapping Document Modeling Master Data Issues to consider In the BW star schema.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. A. This applies for the characteristics belonging to the required dimensions for time.1. From a reporting point of view.

Master data can be sources from multiple R/3 and Non-R/3 systems. Page 151 .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.

• The derivation rules used in creating the target data.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. maintenance or refresh requirements.’ • The relevant data transformations. characteristics. aggregations. weekly. and • The update. and • The relevant analysis reports. whether data is captured daily. • The analytical data of interest. 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. Overview Summarize the analytical processing information needs determined in the previous tasks.. In fact.223 Define Transformation Rules Purpose The purpose of this task is to identify the transformation rules to be used for key figure (facts).e. The information needs may be clustered.g. • The rules for mapping the source data to the target analytical data (e. how often the event occurs). • The target performance measures or their components. Review the definitions of the analytical data. the information needs may be common to many different user groups within an organization through the required levels of summarization or aggregation may vary.g.. quantitative measurement and unstructured data entities. The data cleansing can be performed by developing transformations. Determine the derivation rules for each of the analytical data elements identified for inclusion in BW. • Periodicity (e. • The different user views of the analytical data. calculation or aggregation). In particular. There may not be a one for one correlation between clusters and particular analysis functions.1.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. focus on the definitions of the performance measurement. quarterly). for presentation purposes. monthly. • The source data providers (from both business and technical perspectives). filtering and identifying the grain of extracted data. A. and Page 152 . based on similarity of need or type of analysis. and • Source(s) of data.8. 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). specifying such information as: • The source data (including the source systems generating the data). Consider the following as appropriate in defining the business events: • Frequency(i.. master data and hierarchies.

All aspects of the of this data for end users should be reviewed and clearly documented in the Data Conversion Document. Aggregate tables can be created to speed up end user access to BW Work Books. 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 . Cleansing is considered as the process of normalizing the data entering BW.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology • The strategies for resolving conflicts between different data sources regarding data definitions or values.226 Define Granularity Rules Purpose The purpose of this task is to identify the granularity rules to be used for key figure (facts). Procedure • Identify how the pre-staging process can be accomplished. 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. characteristics. master data and hierarchies. and more. master data and hierarchies in BW. A. completing the Unit of measure conversion.  Store the data in an database and cleanse the data using programs A.1. smoothing out currency anomalies.1. characteristics and hierarchies that can benefit from adding aggregate tables Review all combinations of key figures.1. master data and hierarchies from the source system to an InfoObject in a report is clearly defined. Some pre-staging methods are:  Loading data into flat files and using utilities to cleanse the data.224 Define Aggregation Rules Purpose The purpose of this activity is to identify the aggregation rules to be used in BW. characteristics.225 Define Prestaging Requirements Purpose The purpose of this activity is to identify the Pre-staging requirements for key figure (facts). Result The exact flow of key figures. Procedure • • Review all key figures. A. characteristics.

THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology  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. year 2 through year 5 data is lightly summarized.230 Discuss and confirm the data transformation requirements with management. Procedure • Identify filtering rules for all InfoObjects entering BW The exact filtering rules for each InfoObject is clearly defined. issues and recommendations for the data transformation requirements to ensure their relevance and completeness. • 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. Procedure • • Identify the disk space required for each InfoObject Identify the disk space required for aggregates. Discuss the data transformation requirements with management.227 Estimate Volume Purpose The purpose of this task is to identify the size and growth estimates of the target production database. A. A.1.228 Define Filtering Rules Purpose The purpose of this task is to identify the filtering rules to be used for all InfoObjects.  How do we roll off data? There are 2 options: delete or archive the data to be rolled off A. Resolve any questions or issues and make any changes as necessary. Resolve any questions or issues and make any changes as necessary.1. Complete structured walk-throughs of the findings.229 Complete structured walk-throughs of the data transformation requirements. ODS and all other non-InfoObjects A.1. it is stored at the monthly level.1. All aspects filtering rules for this data should be reviewed and clearly documented in the Data Conversion Document. Ensure that the requirements are in a format suitable for input to the Data Transformation System Design and the Presentation System Design Phases. But. year1 through year 2 hold monthly granularity data. Therefore. Page 154 .

THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A..1.1. Completeness of relationship identification may be independently confirmed by considering the contents and structure of the DW system outputs. The structure of the groupings of data should be demonstrative of relationships in the CDM. 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. Ensure that the information needs of the performance measurement.231 Confirm the consistency and completeness of the process and data models. conduct further analysis to reconcile the two views and modify the process descriptions and/or the analytical processing data definition as appropriate. Confirm the completeness and consistency of entity and attribute identification in the CDM through: • Cross-checking the data view. consistent and supportive of the business objectives of the organization. For each of the major system outputs.g.232 Confirm the data transformation requirements. access and presentation requirements of the analytical processes against the entities and assigned attributes in the CDM. in terms of any prototyped screens and reports and interface requirements) against the entities and assigned attributes in the CDM. A. identify which data element(s) represent the "key" to each grouping of data required by the output. Page 155 . Make any adjustments as necessary. If the relationships between the data and process models are inconsistent.9 Validate Process/Data Definitions Purpose To ensure that the deliverables produced during the Analysis and Decision Process Definition Phase are complete. quantitative analysis and/or ad hoc analysis processes are properly supported by the data definition.8. and • Cross-checking the output views of the DW system (e. Review and confirm the data transformation requirements following the reconciliation.

Note: The CDM does not require complete attribute definitions.1.1. Review the model to reflect any problems identified in the walk-through. Each process is assigned to one and only one component CDM. A.1. Page 156 . it may be necessary to test the data design through a proof-of-concept test. complete the partitioning of the CDM. The processes can be partitioned based on their logical relationships such as common activities and transaction types of common subsystems. Conduct a peer group review of the CDM including the performance measurement. For large complex data models.234 Consider ramifications of large volumes of data.233 Partition the development of the CDM (only for large complex data models). These deliverables are reviewed for content and clarity and presented to management for confirmation and formal written approval. The number of processes determines the number of component CDMs that need to be created. A. • Use of specific tools/approaches. Determine whether additional steps will be required to address the volumes of data to be used in the new system.8. consistency and adherence to standards. cardinality and optionality notation and check for invalid relationships. This partitioning process is not necessary for simpler data models as all entities can be accommodated on one CDM. If not already addressed in a Technology Pilot. Where necessary. The identification of data elements is achieved by review of the processes. Ensure that the model contains complete entity definitions. or • Use of different types of storage devices. • Use of compression techniques. Overview The outputs from the individual tasks are consolidated into an analytical processing data definition deliverable.10Submit Data Definition Deliverable Purpose To provide a checkpoint where the analytical processing data definition deliverable can be reviewed and verified. Issues that arise and are unresolved should be routed through the issue resolution process. quantitative measurement and unstructured data entities to check the model for logic.235 Conduct structured walk-through of the CDM. A.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. 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. Where there will be large volumes of data in the DW system. this test may need to address such issues as: • Use of parallel processing architectures.

1. A. If necessary. Review the analytical processing data definition deliverable focusing on content of the CDM and clarity of presentation. Package the various components of the analytical processing data definition deliverable. Page 157 .1.238 Submit and discuss the analytical processing data definition deliverable with management. prepare an action list of items to modify.1. Further definition of data to the physical implementation should not be completed for entities which are outside of the DW system. Entities which are excluded should be listed or a scope boundary should be shown on the model. A.237 Assemble and review analytical processing data definition deliverable. Discuss the analytical processing data definition deliverable with management and resolve any questions and issues. Specify the scope of the data to be included in the system.236 Specify the database scope. This procedure is important when the CDM is derived from an Enterprise Data Model.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A.1. A. This step may involve more than one meeting.239 Obtain formal written approval of the analytical processing data definition deliverable.

The primary objective of this phase is to check progress against the Project Charter and to update the plan with any required modifications. to identify and address scope issues and to conduct appropriate Quality Management Reviews. Analytical Processing Data Definition. Items such as project background. in this Phase. Overview Throughout all of the stages of the DW life cycle.9 Business Blueprint Definition Checkpoint Purpose To confirm the results of the Business Blueprint Definition stages (Analysis and Decision Process Definition. In the Design Checkpoint. there is a need to monitor and report project status. Revisions to the plan fall into three broad categories: • Minor changes to static information.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. project organization and much of the contractual information will generally change little. and a recommendation and Class 2 Estimate provided for the DRB/GRT. change and issue resolution procedures. 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 O p e n I s s u e s R e I 2 v i e w I s s u I s s u e s e r e s o l u t i o n s P r o j e c t p l a n s U Q p 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 d p r o j e c t a n d q u a l i t y Page 158 . and the Technology Definition) with management. Additionally. many of the items fall into the first category. the CPDEP Phase 2 task of “Generate and Select Alternative(s)” is completed. • Major revisions to existing sections. and • The addition of new information not previously recorded.

and • The technology definition (including the IT infrastructure requirements. • The data access requirements of the analysis and decision processes.1 Confirm Completeness of the Business Blueprint Definition Purpose To complete an integrity check of the Business Blueprint Definition deliverables.1. • The data requirements in supporting the analysis and decision processes (including the CDM and analytical processing data entities). Page 159 . selected IT infrastructure and Technology Pilot requirements.9. A. strategies and standards. quantitative analysis and any ad hoc analytical processes). obtain formal written approval of the change from management. If a project scope change is needed.240 Confirm the completeness of the data. Resolve the issues as possible and document any outstanding issues to be addressed by the Issue Resolution Process. The focus is on confirming the completeness of the results and findings and determining their impact on the project. process and technology definitions including: • The descriptions of the analysis and decision processes (including the performance measurement. Discuss and confirm with management the completeness and accuracy of the data. IT infrastructure alternatives. process and technology definitions with management. Determine the impact of the findings or issues on the project.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. process and technology definition work products developed during the Business Blueprint Stage are discussed with management. Overview The data. as applicable).

it turns out to be an expansion of scope or an error in information provided by the user. an approach describing how these will be resolved should be developed and agreed. e. Overview All issues must be reviewed and appropriate action agreed/taken. Document on the Issue Resolution Form or cross-reference to the Issue Resolution Form. A. Review all open issues contained in the Issue Resolution Log. if after investigating an issue.241 Review and resolve any outstanding issues.9.g. 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 SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. For any issues that will not be resolved immediately. Identify possible resolutions and initiate appropriate corrective action.1. Page 160 .1.2 Review Issues Purpose To identify all outstanding issues and either resolve or agree future actions. Assess the impact of any outstanding issues and reflect in the plans and risk assessment.. the cost of the investigation as well as the resolution of the error should be borne largely by the system users. The cost of investigating outstanding issues may need to be split between both parties. A.242 Agree approach to outstanding issues.

A. 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.244 Review and revise Project Risk Assessment. 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.9. • Increasing the staff complement in an attempt to reduce time scales at increased cost. Overview This task updates the Project Charter and Project Plan to reflect the impact of the findings obtained in the Business Blueprint Definition Checkpoint. Compare the final cost and timing plans with the originally agreed figures. Identify where the risk ratings described in the Project Risk Assessment are higher than expected or are greater than originally anticipated. Seek formal written approval for any actions to be taken and revise plans accordingly.1. • Revisiting the original scope to see if scope has changed over the lifetime of the project. Page 161 .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..245 Review project risk dimensions.THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A.g. 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.243 Validate overall project cost and time estimate. Review the Project Risk Assessment documentation that has been maintained throughout the project. • Re-phasing of the work to ensure that time scales are met. or • Reducing the staff complement to reduce cost but increase time scales.1. review any discrepancies and take appropriate action. • Agreeing a revised cost of the project. A. new versions of software) significantly affected the project? A.1.g. This may include: • A negotiated reduction in scope based on changed costs..

avoidance. A. Review the Project Risk Assessment to identify any changes from the initial assessment.1.. • The severity of the risk.246 Revise risk management approach. Update the implementation strategy.g. and • How will the situation be addressed (e. document: • The likelihood of impact on the project. control. For identified threats. • How will the fact that the risk factor has come to fruition be recognized. Page 162 . assess the impact of making changes to the project plan on the associated strategy documents developed in this stage. assumption or transfer).THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology In this latter instance. data conversion strategy and appropriate testing strategies as necessary.

and • InfoCube monitoring. • Data refreshing. • Data transforming (InfoSource integration). • Data cleansing/scrubbing (Transfer rules/routines).THE SERVICE ARM OF THE FIRM Data Warehousing BW Project Plan Methodology A. The key components of a DT system include: • Data extracting. Data transformation is the process of transforming source data to target DW data. defined during the Analytical Processing Data Definition phase. • Data transfer. Overview This phase translates the data transformation requirements. update and maintenance.l ei g v h e .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.l l e n s f o r m a t i o n D e s i g n v e l D a t a T r a n s f o r m D S e 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 n 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 ) m D i a n s 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 n s 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 T r a n s f o r m a t i o n S y s t e Page 163 . into a set of technical specifications for the DT system. 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.

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

BW High Level Architecture Diagram High Level Transformation Design (DWA) Data Data Transformation System Design (ET/DT/DWA) Design (DWA) Custom BW Administrator’s 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 .

 develop a processing model for extract system. • Analyze data sources. and • Assemble and document the extract system processing requirements. Page 166 . • The interfaces between the DT system and its internal/external source feeder systems. • What role the data staging area (if one is used) plays in the DT process. • Define/refine common extract structure. A. formatting. and  identify and document data gaps with Business Content extractors. and • The interfaces among the components within the DT system. cleansing issues/formatting. and  the current system data extract processing model will be ongoing. and • What role the ODS (if one is used) plays in the DT process. Analyze data extract processing requirements: • Review Conceptual Data Model (CDM).247 Develop a System Architecture Diagram for the broader system environment. 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 System Architecture Diagram for the broader system environment showing: • The interfaces between the DT system and other components of the DW system.  data cleansing and quality assurance of external source data is part of the data extraction function.248 Design data extract system component. • Confirm data required is available or can be created from data sources:  select inclusion/exclusion criteria.1. business rule processing and logic distribution guidelines).THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A..249 Determine Uses of Pre-Configured InfoSources. • 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.  historical data may require a one time stand alone extract conversion process.1. • Resolve data integrity.g. • Analyze data source cleansing requirements. Purpose The purpose of this activity is to determine uses of SAP pre-configured InfoSources. • Develop resolution strategy for data integrity/cleansing/formatting issues. • Develop algorithms for cleansing. A. integrity checking. If not already prepared earlier.1. The DT system architecture should depict key design characteristics such as: • What types of transformation processing are occurring where (e. • Map data elements from the source systems to the common extract output format.

• Calculation of derived business InfoObjects. • Review the transform system process model with respect to data destination platform for processing:  volumes.  capacity. The new InfoSource can also be the master data from Non-R/3 system. • Translation of source data.  capacity.1. Procedure • • • Identify information in Non-R/3 sources necessary to satisfy requirements Create user defined InfoObjects. • Attribution of master data. and • Indexing or parsing mechanisms for accessing unstructured data. and  geographic distribution.252 Design data transfer system component.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. Purpose The purpose of this activity is to identify new InfoSources from Non-R/3 system. • Analyze DW physical data distribution requirements.1. Characteristics and Key Figures Create data mapping document A. and  geographic distribution.  timing. • Review potential physical data distribution requirements and target data destination platform for access. Analyze the data transfer processing requirements: • Review the extract system process model with respect to source system:  volumes. A.  technology. • Synchronization for currency or update. Page 167 .  technology. Analyze data transform processing requirements including: • Integration DataSources to InfoSources.1. • Aggregation of summary data.  timing.250 Identify New InfoSources to be Created. • Analyze data transfer requirements for DW processing architecture.251 Design data transform 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.  extract system conversion requirements for audit/control reports including control totals (e. modularity. and  management approval of the extract system audit processing model. and master data. processing resource requirements and administration/maintenance requirements of the transfer model. • Replicating data.1. • Availability of data.253 Design data refresh/update system component. • Loosely coupled synchronous replication where DW data should be updated by the same transaction but. cleansing errors. 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.255 Determine the audit and monitoring requirements of the data transformation system. • Archiving data. record totals. and • Completing period-end closing processes including:  tax year-end. and • Asynchronous replication where DW data is updated off-line. rolling year considerations). and Analyze volumes. range checking.g.  mapping selected data elements to audit/control requirements/formats.1.  calendar or fiscal year-end (e. Integrate data transfer processing model with DW processing models. usually in batch processing at night. • Volumes of data. Some of the factors affecting end-of-period update processes include: • Data dependencies.g. integrity errors..  high-level audit and control requirements and generalized format. Determine the end-of-period updating requirements for the DW including: • Adding/changing/deleting data to InfoCubes. and  quarter or month-end. A. hash totals. A. the update is left pending on a log for later processing. due to some constraints. • Completing audit procedures.  recommended model for the actionable extract system audit processing.1.  requirement rules for audit processing including selection/creation/conversions to common extract output requirements/format. data change reporting. and • Balancing requirements. • Refreshing data. value totals.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology • • • Develop model for data transfer processes. ODS. • Data transform audit requirements: Page 168 . complexity. A.254 Design end-of-period update system component. file control record comparisons). Determine the audit and monitoring requirements of the DT 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..

Some of the alternatives include: • Correcting the source data directly in the source data system.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.  • Determine whether any encryption or other protection is required for sensitive or confidential data which is contained within the transformation process. A. define the selected approach. and Data transfer audit requirements:  audit and control points based on the data transfer process model.  mapping of selected data elements to audit/control requirements format. • Correcting the source data through normal operational transactions (e.  data transfer audit and control reports detail. data transform sub-processing errors and data change reporting. and  management approval of the transfer system audit process model. Develop an approach for providing feedback to the source data provider concerning the usability and quality of the source data.  data transform conversion requirements to define audit reports including control totals. complexity. Correcting source data is often a sensitive organizational issue. integrity errors. maintenance and performance characteristics.1. and  management approval of the transform system audit processing model. processing resource requirements and administration/maintenance requirements of the transfer module. modularity.  high-level audit and control requirements.  high-level audit and control requirements and generalized format.  recommended model for the actionable transform system audit processing. or • Not responsible for correcting the source data but maintaining a cleansed and integrated operational data store.. the use of the structured walk-through technique may be applicable. If required. In some circumstances. Evaluate design integration. 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. Page 169 . Discuss and agree the high-level DT system design with management. using a reversing/correcting transaction pair).  rules for audit/control processing including selection/creation/conversion from common extract formats to data transform output formats. Different approaches may be appropriate for different source data systems.256 Evaluate data transformation system design.  mapping selected data elements to audit/control requirements and formats. modularity. Obtain formal written approval.g. Modify any deliverables that have changed as a result of the technical design.  recommended model for the actionable transfer system audit processing. Ensure that potential changes do not alter the scope of the application.  generalized format for audit/control data.  volumes.

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. Identify the data elements that will be extracted. • Information availability . both for reconciliation purposes and for error correction if the systems do not balance..10. does a payroll system provide pay information at a departmental total level. Review the Management Overview Diagram(s) or other Abstract diagrams/documentation to confirm which interfaces are required.e.adjustments = closing balance or with an accounts payable system for each check run: opening balance value .g.invoices paid + credit notes adjusted +/.2Develop Data Extract System Interface Design Purpose To identify and specify the interface requirements for data extraction from the source systems. the system that will provide the interface input)..THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. • Internal integrity .257 Refine the interface requirements for data extraction from the source systems.258 Review interface source systems. for an inventory system: opening balances + receipts .g.. Page 170 .. or at an individual employee pay level sub-divided by job).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 existing and proposed.1.issues +/.. for an interface to a general ledger system.whether the source system is properly maintained to ensure data integrity (e. A. DBMS integrity utilities are regularly run to ensure that any corrupted data is corrected).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. it is imperative that a careful review of each source system is completed (i.1. does the source system provide records or data for each type of financial transaction completed or are some transaction types ignored?). • System maintenance . When designing interfaces. Include also the refresh/update interface requirements. at an individual employee pay level.whether the source system balances within itself (e. These requirements will need to include a provision for any ongoing balancing procedures that may be required. Obtain and review any requirement or design specifications that have been prepared as outputs from the Prototyping Phase. A. Overview This task develops the specification for data extraction from the source feeder systems. The review should address: • Level of detail .whether all of the data required for input is able to be generated and in the appropriate format (e. Define the file layouts or extract structures for each interface required as input to and output from the new system.g.g.

and • The cost of communications between the DT system and the data warehouse (e.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. they should be checked to ensure that they are complete. • Validation required and provided. Review each source system.259 Determine system interface approaches. if so. For instance. as will the technical specialist skill mix required. A. and • Documentation accurate and sufficient. 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. • Testing issues. • Job control language provided or not.g. this may require considerable effort or an alternative approach (e. if the interfaces are acquired from a software supplier.1.. • Recovery/restart routines. • Speed of processing. • Receiving system requirements to be created. a temporary data store may be used as a staging area to synchronize and simplify the process of aggregating data from multiple sources). and Currency/timing ..THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology • • Validation/error checking . 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. The work effort and tasks to create the various interfaces will vary by the type of interface to be used. • Whether any options are provided.g. Where current systems are either old or poorly documented. • Control totals provided or not. or • Translation software packages. Page 171 . use of software reengineering tools to re-document the system).g. • Audit trails provided and. instead of sending bulk data directly from the source systems to the data warehouse.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. • Interfaces that receive data from subsidiary systems. what data is included. 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. 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. • Micro-host links that can be a proprietary third-party product. only smaller amounts of aggregated data may need to be communicated if a temporary data store is used to stage the "raw" source data). that are then reformatted using online editors or utilities and then input to the system using the normal input transaction processing routines.. • Source system reconciliation/output of data issues.

and  physical record numbers through such means as run activity control numbers for both the source and receiver systems. and can depend primarily on the nature of data transformation requirements and source data analysis: • Utilize standard Business Content extractors: In this case. interface designs can follow one of the following approaches.  monthly. Determine the volumes of records for each interface and also the timing and availability of the data (e. total opening balance plus receipts minus issues plus/minus transfers plus/minus adjustments equals closing balance).THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. The extractors should already have been installed previously during the Technology Planning.260 Design each interface. define the clerical procedures to ensure that the system is continually reconciled. 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. prepare program design specifications. daily. The volumes may also impact upon the timing of the interfaces (e..g.g. peaks (e.. Design and document each interface including the access and security definitions and Unit and Component Test Plans. Define the interface program/procedure specifications.. 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). 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. and  year-end.g.g.  internal data completeness of the new system application itself (e. Consider:  interface sub-system balancing (e. month-end or year-end.g. Also determine whether there are variations in volumes caused by such items as holidays. develop specifications that define which new data fields to add to the extractors.. This should include the responsibilities and tasks that must be completed:  daily. Also include the design for the data refresh/update interface. The extractors may not always be extendable. and • In addition to the technical design. 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. summer).1. This can depend on if the new fields come • Page 172 . the integrity of the source system before the interface data is presented). weekly or monthly).  weekly. and Cutover phase. • Ensure that the ongoing integrity of the system is maintained by establishing and documenting the procedures for reconciliation and balancing of the interface data. Support. no extra design work is necessary apart from the previously mentioned interface system balancing concerns and reconciliation procedures.. For BW. 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.

the Generic Data Extractor should instead be used. If the new fields come from different tables.g. The "lead" system maintaining the business objects data and triggering the data exchange has to be determined. This could drastically increase the complexity of an interface considering the implementation logic and error handling. In certain cases it may be beneficial to use a newly defined data structure. and an ETL tool has been selected and chosen. Standard structuring becomes more important when many different systems interact with each other. and new source system data modeling must be considered. • Generic Data Extractor: Using the source system analysis from the Data Definition and the high level designs. Custom ABAP extraction: The following steps represent standard interface design considerations from an R/3 system. Both types of request could be addressed by one single interface. 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"). crash recovery or Page 173 . 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. when the lead system repeats transfers in case of restart. follow the specific tool guidelines and approaches in developing or generating extraction programs. Follow any standards in place for non-R/3 systems being interfaced from: • • 1. The data transfer for requests processing data in a distributed transaction has to keep the data consistent. 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. If there is no business scenario that was used. The use of standard formats and structures is recommended (e.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. Depending on the business needs the serialization of the transferred data packets and their processing has to be implemented. develop specifications for building DB views or ABAP/4 Query specifications as sources for the Generic Data Extractor. There are certain vendors for conversion software offering various interfacing techniques and arbitrary formats for data exchange with external systems. The received data has to be processed only once in the receiving system. sending back the acknowledgement and setting the transmission status. in the receiving system update the application data and processing status. the SAP IDOC container structure). ETL tool: If none of the above meets the project requirements for source data extraction. This is especially of importance. sending data and setting the status of the transmission. an own structuring of the data could be used filled from specifically identified data sources in SAP (outbound) or for SAP (inbound). Several processing issues have to be considered on this subject.

g. 3. the technical infrastructure and the interfacing capabilities of the application systems a basic transfer method must be selected. Discuss and confirm each interface's (input and output) detailed design by completing a structured walk-through of each design. There are two basic methods of transferring data from and to SAP systems: (1) file access (2) program-to-program communication. This transfer method only allows data transfer asynchronously (also often referred to as "batch" interfaces). 4. Resolve any questions and issues. The program-to-program communication requires for each communication partner an interface program. Consider the time frame of the data transmission (synchronous/asynchronous): Based on the business needs. After the file is accessible to the partner system the data processing is triggered or the partner system polls for further processing. error handling and restart ability for the interfaces. Obtain formal written approval of the design of each different interface. The files access method uses file systems to create. The connection is established by the client (the source of the data) and accepted by the server (the processing side of the data). Such situations can also be implemented through manual procedures supported by tools (e.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology loss of communication connections.1. Define clear responsibilities for these maintenance activities. A. These methods allow synchronous data transfer and processing. Page 174 . Technical and application based logging functionality is essential for both the monitoring of an interface and the ability to identify and resolve error situation.g. This feature could range from a simple log writing process to a complicated monitoring tool for several interfaces. so that the sending and receiving systems can be brought to a synchronous processing state after back out and recovery situations.261 Complete a structured walk-through of the extract system interface design. by a tool like "ftp") or the use of share file systems. re-scheduling jobs). 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. The file is then "somehow" transferred to the other application system (e. write and close a file. Resynchronize of the interfacing systems must be implemented. the time frame of a transmission. Submit and discuss each interface design with management. Plan for error handling and maintenance: Consider already from the beginning of the project the monitoring.

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

error or warning message) for each edit and validation. 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. Help message. They are small utility data files for look-up or data validation purposes. Each must be developed in terms of structure and. Table Definitions relate to code/decode definitions. This provides valuable input for the BW developer. Review and cross-reference the InfoSource design specifications against the application level documentation as confirmed in the Analysis Checkpoint Phase. where appropriate. as part of the Data Dictionary. Develop test objectives. During this step. to confirm the completeness and consistency of each design specification and to ensure compliance with both quality and development standards. This will help in preparation of test data. A.g.1. identify all known tables and gather documentation regarding valid values for codes/decodes.266 Develop Monitor Response for Edits/Validations.1.269 Evaluate and resolve issues as required. A. within the project team. detail test steps and data conversion activities. A. Page 176 .268 Conduct a structured walk-through of the InfoSource design specifications.267 Prepare initial test plans for each InfoSource and component grouping. Specify the associated action (e. data content.1.1. A. Any shortcomings in the design should be resolved through the formal issue resolution process and changes made. Decisions on whether the table should be physically maintained as part of a InfoSource. 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.265 Develop Table Definitions. Conduct a structured walk-through.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A..1. test conditions and general expected results at the InfoSource level. if reasonably small.

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

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. and • Any translation of data formats is required. purge criteria specify what to exclude. • Computer software bulk or mass maintenance routines. • Any purge criteria are necessary. • Custom programs. Select from the alternative methods to create the new master file data and table files including: • Keying the data. Initial estimates may need to be further subdivided. Select the most appropriate method to create the new system's opening balances and history files where needed. Generally. the method of conversion may be decided. a combination of these different alternatives are used to create the data. determine the volumes of data for creation and conversion for these types of records. Selection criteria specify what to include. it may all have to be created. The purge criteria are basically the opposite of the selection criteria. Initial estimates may need to be adjusted following purging/cleansing. Determine the volumes of each file to be converted. purge and translation rules may not be all encompassing. The data requirements must be reviewed to determine if: • Any limiting selection criteria are necessary (i. depending upon the various means of creation determined in subsequent steps. • File conversion software. the source for each data element must be identified. In most instances.1. Page 178 . Once the source and the format are determined. A.273 Determine the source data for conversion and the conversion method.1. only source data after a certain date will be converted). • Scanners to scan data. These data elements may be currently maintained on an existing computerized system or on paper documents or for some new systems. Once the required conversion data has been identified. Note the source of the input for each data field in the new system.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.1. • Service bureau (keying). and • External databases (buy data). The source of each data element and the means should be noted on the Data Conversion Map. If opening balances are to be created in the new system. • Utilities. creation and translation rules. derive their volumes.e.274 Define required selection and purge criteria.272 Determine volumes of all data for conversion. Determine volumes of data that need to be created. A. If tables have to be created or converted. It should be noted that selection..

• An auditable trail of the changes applied is produced for management review and sign-off by the data owner or nominated deputies. Identify data cleansing strategies and document the data cleansing procedures. measurable and verifiable. The criteria must be clear. The data conversion requirements are reviewed to determine edit and validation requirements and to determine error handling procedures. 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. and • Changes are never applied directly to production data.1. A. • Converted data files shown as program outputs.278 Develop a System Diagram for the conversion sub-system.1. • Criteria have been agreed for determining the data conversion rules. This step may result in the identification of additional purge criteria that should be added to the purge criteria specified in the previous step. The Edit/Validation Specifications defined for the application system being developed should assist in determining the error identification requirements. • Data items to be amended and enhanced have been identified.277 Develop data conversion acceptance criteria and acceptance test strategy. If this leads to an impact on the organization's financial statements and/or the need for formal management approval is required. In addition. Derive the conditions that will determine that the data conversion has been successfully completed and documented. 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. After the data conversion acceptance criteria are defined and agreed.276 Develop a strategy for reconciling converted data. • All changes applied are reversible or can be backed out using back-up copies of the data.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. Create a detailed System Diagram of the conversion system that includes: • The sequence and interrelationships among conversion job steps. develop a strategy for conducting the acceptance testing of the data conversion process. 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.1. and • Interface requirements for sending/receiving data to/from other system(s). • All input and output data files required. Page 179 . explicit. 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. agreement must be reached on the responsibility and the methods used to make these adjustments.1. these may need to be written off. A.275 Review data conversion requirements to determine error identification and cleansing strategies. • Audit trail and reconciliation reports shown as program outputs. A.

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

A. If necessary.1. Obtain formal written approval of the data conversion plan including agreement of the responsibility for the sign-off of the completed data conversion reconciliations.282 Obtain formal written approval of the data conversion plan.281 Submit and discuss the data conversion plan with management. This step may require more than one meeting. Submit the Data Conversion Plan to management and resolve any questions and issues.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. prepare an action list of items to modify.1. Page 181 .

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology

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

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology

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

l

P

r e

s e

n

t a

t i o

n

D

e

s i g

n

C

h

e

v r o

n

S

e

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

n

D

e

s i g

n

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

u

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

y

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 )

S

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

n

D

e

s i g

n

D

e

l i v e

r a

b

l e

Page 183

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology

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 organization’s 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

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology •

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 organization’s 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

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology • • • •

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

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology

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 Organization’s 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 Organization’s 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

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology • •

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

Procedure • Identify access rights or service use users need for their job functions.296 Identify Information Access and Service Use Purpose The purpose of this task is to identify the needs of users to access information. Such access rights can be to SAPoffice. Determine the security options (authorization object options) for each job role. and so on) with each application area (data owner).1. Determine the need for access to BW System services. • Review Review the enterprise-wide job role matrix before you build the activity groups. basis services permissions. excessive accesses) that result from their decisions.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. Online Service System access. Application data owners must be aware of the potential risks (such as. such as printing and faxing. access to online documentation. and how it impacts data owners. and SAPoffice for each user. Explain the implementation framework. based on the security options you have concerning the automatically generated – and. therefore. faxing. • Discuss Security Options Discuss the security options (for example. necessary – authorization objects. Other types of access include access to SAPoffice and online documentation. Page 189 . setting up authorization groups. Then interview each application area. You can do this by creating a sample activity group for a job role and generating its authorization profile. A. such as printing. reporting. such as business data not directly related to job functions.

Procedure The procedure describes how to create Layout Set definition.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. 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. • Determine Information Access and Presentation Requirements This task involves the End Users doing a serious review of how they currently use information. and obtain sample layout sets from the system.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.3Develop Presentation System Interface Design Purpose To design the presentation system interface both with the users and the other components of the BW system.11. The need for canned static reports versus the capability to do "active analysis" (OLAP) is also explored along with expected response times. This step results in determining BW system usage characteristics and presentation requirements. Determine how documents must be formatted to reflect the corporate standards. The output of this activity forms the foundation for determining the End Users front-end decision support requirements. • Define Detail Specification The task develops the technical specification for creating a layout set Page 190 . They frequently do not have a clear knowledge of just what is available to them in a Decision Support environment. Obtain the information needed to develop standard company reports and forms.1. • Determine Layout Requirements Determine what new or changed sets are needed. Identify the processes and functions where layout sets must be used. Users often have difficulty expressing data and functional requirements since their process is intuitive. A.

Prepare Restricted Key Figure specifications. Prepare Key Figure Structure and Selection specifications. Prepare Calculated Key Figure specifications. and Prepare Variable specifications. Procedure • • Review the end user requirements Identify Reports  Maintain/Execute Query A. to confirm the completeness and consistency of each design specification and to ensure compliance with both quality and development standards. within the project team.301 Conduct a structured walk-through of the Business Explorer Object specifications. Any shortcomings in the design should be resolved through the formal issue resolution process and changes made.298 Determine Uses of Pre-Configured Reports Purpose The purpose of this activity is to determine uses of SAP pre-configured Reports.300 Assemble Business Explorer Object specifications.1. A.299 Prepare Query Specifications. where appropriate.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.1. Conduct a structured walk-through. Review and cross-reference the program design specifications. A.1.302 Evaluate and resolve issues as required. In addition to the preparation of standard query definition templates.1. the following should also be performed: • • • • • Prepare Workbook specifications.1. Assemble the components of the Business Explorer Object specifications. A. Page 191 .

This step may require more than one meeting. If necessary. In some circumstances.305 Document and resolve issues as required.1.4Submit Presentation System Design Deliverable Purpose To assemble the various presentation system design deliverables.1. Any problems in the design should be resolved through the formal issue resolution process.11. Discuss the presentation system design deliverable with management and resolve any questions and issues. Review all of the documentation for each design specification and ensure that all of the relevant work products are present. within the project team.303 Assemble presentation system design deliverable.306 Submit and discuss the presentation system design deliverable.1.307 Obtain formal written approval of the presentation system design deliverable.1. All open system design issues should be resolved before the completion of this phase.1. to confirm the completeness of each design specification and to ensure compliance with both quality and development standards. A. The presentation system design deliverable is discussed with management and approved. A. A. Ensure the consistency and completeness between individual program specification packages. this task may be delayed and completed as part of the Business Blueprint Checkpoint Phase. A. Overview When approved by management. A.304 Conduct a structured walk-through of the design specification. prepare an action list of items to modify. Page 192 . 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.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. Conduct a structured walk-through. the design specification assembled in this task will be refined and coded in the Realization Stage.

integrated data from which summarized or segmented data stores can be derived. Depending on the DW architecture. A DW may contain both granular and summarized data to support the identified management analytical processing information needs. 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. integrated. data profiling and other decision support applications.12 Data Design Purpose To develop a data design in support of the identified data requirements for the DW environment. An ODS provides the granular data required to support various analytical processing applications such as data mining. Specifically. Tasks • • • Develop Logical Data Model Develop Multidimensional Data Model Design InfoCube Page 193 . the source of data for a DW may come from an ODS or directly from the source databases. The data design exercise can be performed by reviewing the user requirement for analysis. • Data Warehouse (InfoCubes) – a subject-oriented.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. ODS is also the source of clean. time-variant and non-volatile collection of information designed to support an organization’s management analytical and decision making processes. 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. each type of InfoObject required for analysis must be identified and reviewed. With the data models defined.

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 s S u D b 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 e s i g n d e l i v e r a b l e Page 194 .THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology Data Design Task Relationships C o n c e p t u a l D a t a M o d D e e l L 1 v e l o p M o d e L l o g L o g i c a l i c a l D a t a D a t a M o d e l M 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 e n s i o n a l D a t a M o d e H D M i g h .

The CDM is then transformed into a preliminary LDM to provide a starting basis for logical database design. In addition. 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. Foreign keys are also determined for implementing the identified entity relationships. determining the primary and foreign keys and finalizing the definition of the attributes. e.. When an entity has several candidate keys. • determining entity relationship cardinalities. New entities and attributes may be identified during the Data Transformation System Design and Presentation System Design Phases.g. placing each entity into third normal form. The data volumes for the implementation of the database environment are estimated considering: • volumes of all data for conversion.1Develop Logical Data Model Purpose To develop an LDM for the data warehouse. a primary key is selected. and Page 195 . 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. • historical data requirements.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. LDM(s) or PDM(s).. some new attributes may have been created to manage and/or control application processes or to reduce redundant processing (e.g. and • defining referential integrity requirements. • interface data volumes. Each entity is placed into third normal form. 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. The inputs to the LDM development process also include application design documentation and existing system documentation. and • Estimating the data volumes for use in determining data storage requirements. if an LDM is to be developed based on existing or previously completed CDM(s). storing totals to eliminate frequent recalculation of those totals). 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. Some entities or attributes may simply have been overlooked in developing the CDM. resolving many-to-many relationships).12. the completeness of these models in supporting the development of the LDM should be examined. • Refining the definitions of attributes including defining any new design or overlooked business entities and attributes.g. • Refining the entity relationships from a logical design perspective. • refining subtyping hierarchy structures..

or • Previously completed or partially completed CDM(s). Any changes to the CDM should be completed following the established change control process of the DW project. LDM(s) or PDMs. 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. • Logical segmentation requirements (if available). • Entity definitions. • Definition of subject areas. and • LDM development considerations. 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. • Critical business data (for business continuation or survival). Determine the completeness of the inputs for the development of the LDM including: • Scope statement and interface definitions. A. 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. • CDM(s). including the lookup tables. • Data conversion strategy.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology • all of the defined data entities. • Existing Business Content InfoCubes. Page 196 . • Existing data structures. Review any relevant data models including as appropriate: • The CDM developed on the same DW project. Discuss with management the impact of the missing or incomplete inputs and any assumptions or planned actions. For instance. • Attribute definitions (optional). Determine the impact of any missing or incomplete inputs on the development of the LDM. • Business rules (including any relevant data security rules). Gather further inputs as needed based on the approved actions determined in the previous step. some tasks/steps may need to be completed to fill in any missing elements.1. for the production environment. if an LDM is to be developed based on existing CDMs or LDMs. Review any relevant application (or process) design documentation.308 Review the completeness of the inputs. • CDM diagram. Review any relevant existing system documentation. • Relationship definitions. LDM(s) or PDM(s) developed for the existing databases. Obtain the required inputs from the appropriate DW staff or application development team(s). Obtain formal written management approval of any project scope changes before work commences.

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

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology • • Determine whether the code set is extensible (i.g. all entities will be in first normal form. Typically. and Determine the ownership of the code sets (i. Typically. and • Third normal form. the Country Code Table consists of COUNTRY CODE and COUNTRY NAME.g.) The primary key for a code table is the attribute representing the data code value.1.e. Add a one-to-many relationship between the new entity and the original entity with the "many" on the original entity end.. the attributes which describe a fact about a part of the entity's key). Once all repeating groups of attributes have been eliminated. Remove any attributes which are dependent on only part of the key (i. Remove any attributes within the entity that describe a fact about another attribute that is not part of the key.. The CDM is in second normal form once all partial dependencies have been removed from the model. there is no transitive dependency). Create a new entity for these attributes.the data code value and the data code name (e. 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.310 • Place each entity into third normal form. A code table may be associated with one or more entities to characterize the occurrences of the related entity. this new entity will be an associative or characteristic entity and inherit the primary key of the original entity. A.. Create a new entity for these attributes which has the non-key attribute they describe as the key for the new entity.e. the user groups responsible for defining and maintaining the code sets). Remove any repeating attributes from the entity and create a new entity for the repeating attributes. COUNTRY CODE) in the related entity is the foreign key for accessing the Country Code Table entity. Review each entity and verify that it is in: First normal form. this new entity will be an associative or characteristic entity and will include part of the primary key of the original entity.. • Second normal form. This new entity should have a one-to-many relationship back to the original entity. whether the code values are static or dynamic).. 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. Thus. A code set is defined as a code table entity consisting of at least two attributes . 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. the data code attribute (e..e.e. Page 198 .

1. if both PART-NUMBER and PART-NAME are candidate keys for an entity. For instance. Name.311 Finalize the selection of primary and foreign keys. foreign keys are used to support relationships in a relational data model. This rule ensures that every occurrence of an entity has a complete identifier. or • Select one as the primary key if an entity has multiple candidate keys.g. define and add to the InfoObject catalog new entities created as a result of the normalization process. 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. Identify foreign keys in selected entities to support the relevant entity relationships. A. 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. and  attribute Y values or attribute Z values or both are large. 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. Often. 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. Data usage should be considered in choosing between the two normalized designs.No part of the primary key may have a null value. Y and Z together without requiring a "join" operation. 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. but • The two-entity normalized design may be better if:  user accesses tend to partition between the two sets most of the time. degree and maximum cardinality any new relationships. During normalization. a database designer sometimes needs to choose among different normalized designs. The two-entity normalized design will identify where compound InfoObjects are required.. assign ID numbers. if necessary and mark with optionality. consider: • The basic requirements of uniqueness.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"). minimality and stability as discussed in the Analytical Processing Data Definition Phase. Thus. 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). applicability. the model is in third normal form and can be considered fully normalized.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. the driving factor in making the decision is the patterns of data usage. Page 199 . and • The appropriateness of the selected primary key as a foreign key in the related entities (e. Label. Entity integrity rule . In reviewing and selecting a primary key for an entity. For example. Once all transitive dependencies have been removed. as illustrated in Exhibit P-1. consider two normalized designs .

. numeric.. Refine the entity relationships defined in the CDM using as appropriate: • Associative entities to resolve the many-to-many relationships.g. number of display decimals). 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. calculations or algorithms. the '/' in dates. NO DUPLICATE). and • Subtyping to enhance database design and to facilitate implementation of the data model. thousands comma separators.  syntax and edit/validation values (e. Associative entities.g. • Identify and resolve any attribute naming conflicts such as aliases. The review team should include representatives from appropriate user and system development groups.  data type (e.g.  presentation formats (e.  internal storage format. STREET.1. • Define any important computed data including their derivation formulae. • Define logical attribute concatenations (e. NO NULL.. ADDRESS consisting of NUMBER. due to overlooked information requirements). range limits). the number of decimal or binary positions.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.g.312 Finalize the definitions of attributes. and • Finalize the characteristics of the attributes to include information such as:  relative positioning within an entity where relevant.  for numeric elements.  the number of storage positions occupied. Other refinements may be identified subsequent to the completion of the CDM (e. alphabetic). date as yy/mm/dd or mm/dd/yy or dd/mm/yy). CITY) as needed.. Complete a structured walk-through of the refined attribute definitions to ensure completeness and correctness.. particularly for links based on foreign keys or internal sort keys.. 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.g.1.313 Refine entity relationships.. Page 200 . characteristic entities and subtyping are discussed in detail during the development of the CDM. A.  default display formats (e. • Determine column constraints (e. and  whether negative values are allowed.g. homonyms and synonyms.  whether zero suppression is to be used. • Characteristic entities to describe further selected entities.g.

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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. • Lightly summarized.g. if suppliers are sometimes inactive. Current and old detail data represents the highest data volumes and the richest information sources. maintained on tape or other low-cost storage devices. • Old detail. over 60% of the purchase orders may be placed with only 10% of the suppliers). or • Defining separate supertype and subtype entities each with the relevant identifier and attributes. Old detail is roughly assumed to be up to 10 years of history. Estimate. the minimum would be zero. This results in a large table that will have null values for inapplicable attributes.g. in a SUPPLIER-PURCHASE ORDER relationship. Consider the following four main categories of data in estimating. If the most frequently used supplier has no more than 50 purchase orders active at any one time. Complete a structured walk-through of the refined entity relationship definitions to ensure completeness and correctness. nature of the business and size of the enterprise. The review team should include representatives from appropriate user and system development groups. Storage space requirements can range from tens of gigabytes to terabytes. Define global field-level constraints (e. A. for each relationship. the maximum would be 50. This option may be preferable if the majority of queries refer to a single subtype. Estimate the data volumes for the databases to be developed. While dependent of the application's scope. A join operation is required whenever information from the supertype and subtype entities is needed. • Including the supertype identifier and attributes in each of the subtype entities. Identify any special situations such as skewness of the cardinalities if known (e. volumes in the multi-million/multi-billion record range should be anticipated for annual additions to enterprisewide detail data. 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). as appropriate: • Current detail. 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. The estimates should be captured in terms of the minimum. This option minimizes redundancy and null-valued attributes at the cost of query complexity.1. typically maintained on magnetic disk devices. maximum and modal average For instance. values and ranges). valid codes..314 Estimate data volumes. This option may be preferable if the dominant query load relates to the supertype or to several subtypes simultaneously. Current detail generally involves roughly two years of history. It may be desirable to add a type classification attribute to indicate subtype membership for each entity occurrence. It Page 201 .. the modal average of the relationship would be 10. These constraints represent business rules to be implemented. If most suppliers have 10 purchase orders active at any given time. and • Highly summarized. 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.

determine how that data is to be kept. add. daily.. • The expected number of data accesses to each entity required by each event for each use.g. seasonal peaks (e. store. depending upon the various means of creation. Consider alternatives such as: • Imaging. Determine the volumes of records for each interface and also the timing and availability of the data (e.g. 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. or • Retaining the old system for historical data usage only.g.. Some applications may require reprocessing of large subsets of the detail (e. for enquiry..g. once per hour. Also determine whether there are variations in volumes caused by such items as holidays. • The response time requirement or allowable duration for each event. week or month). the largest impact on cost . Initial estimates may need to be further sub-divided. On the other hand. financial year-end). weekly or monthly).e. many applications can be satisfied with a very small subset of the data.or cost avoidance . legal or statutory purposes). • Compact disc. state or product group).. • Tape. summarized at one or two orders of magnitude of reduction (e.. update. What constitutes lightly summarized or highly summarized data regarding the degree of volume reduction from the corresponding detail can vary greatly. delete or read-only). summer). Estimate the data volumes for the specific database being designed considering: • The volumes of each file to be converted.is achieved by making the right technology platform choices in this area. the data volumes derived based on the staged implementation schedule. • Microfilm. • The nature of each entity access required by each event (i.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology corresponds most closely to the detailed transaction-level data from operational systems.g. Lightly summarized data is a reduction to the level of detail appropriate for the general requirements of a departmental decision making application. If historical data is not to be converted but is to be retained (e. 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). Highly summarized data is a further reduction for specific decision-support modeling requirements. day... the volumes of data for creation and conversion for these types of records. • The volumes of tables to be created or converted. customer scoring applications)..g.g. Because the volume of detail data is the primary cost driver for DWs. The volumes may also impact upon the timing of the interfaces (e. modeling financial performance for products or product categories over time). • If a staged implementation is to occur (e. • If opening balances are to be created for the DW system. by location.g. and • The expected volumes of data to be stored for each entity. and • The timing for conversion as some data may only be available after specific processing (e. Initial estimates may need to be adjusted following purging/cleansing. month-end or year-end.g. • The volumes of data that need to be created. Page 202 ...

the data storage configurations and the capability of the DBMS supporting the multimedia data must be considered as appropriate. • Back-up data. Page 203 . refine the high-level database design for performance considerations. Discuss and confirm with management and appropriate user groups the data volume estimates including any assumptions used in making those estimates. and • Index tables. historical data and interface data requirements as determined in the previous steps. multimedia may be stored directly in a database as Binary Large Objects (BLOBs) or long fields or in a separate mass storage device. • At the end of first year of production.. Refer to the Analysis Performance Efficiencies task for a detailed discussion of performance efficiency analysis. audio or video data). Estimate the data volumes in terms of: • At the beginning of production. Multimedia data is space intensive (e. In estimating the data volumes for multimedia. • Code tables. • Work space tables. (Optional) Complete a preliminary analysis of the high-level database design with consideration of data volume estimates.g. Revise the estimates and/or assumptions as appropriate. Document any assumptions used in determining the various data volume estimates and the data volume growth rates. A. For example. and • The projected annual growth rates of the data volumes.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology Estimate the data volumes for the production environment including as appropriate: • The conversion data. • Transaction master data. As appropriate.1.315 Complete a preliminary analysis of performance efficiencies.

Multidimensional data modeling organizes the data into two types of entities . The primary inputs to multidimensional data modeling in this task come from various sources including: • The Conceptual Data Model. The multidimensional data model is flexible and more easily manages reorganizations. including the performance measurement entities. new products and different types and levels of analysis. 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. quantitative measurement entities and unstructured data entities. the Distribution Channels dimension)? • Where does the organization serve the customers (i. As illustrated in the exhibit. during a particular month (time period dimension) in all markets (market dimension).e.12.. and • The understanding of the organization's business events and processes obtained in the Analysis and Decision Process Definition phase. organization or time.e. 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...g. 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.2Develop Multidimensional Data Model Purpose To model the business analytical processing information requirements in the form of a multidimensional data design. productivity or compliance relating to the dimensions of customer.e. Data may be analyzed at various aggregation levels (e. product. For example. 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. Fact entities contain key numerical measurements of business performance and the dimension entities contain the description information about the performance indicators. delivery channel. quality. the Customer dimension)? • How does the organization serve the customers (i. In particular. the Markets dimension)? • What does the organization provide to its customers (i. risk. Page 204 .e. developed in the Analytical Processing Data Definition phase. for a particular product (product dimension). an analyst may be interested in knowing about the facts of sales and marketing. the dimensions of analysis are generally rather stable. market. While the specific information that a user needs in business or decision analysis may be ad hoc in nature and difficult to predefine.e. It makes it easier and more efficient for the end-users to access the critical business information.. at the national. 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. division or region levels) or may be "drilled down" to examine the underlying detail data..THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. profitability. an analyst may be interested in the total dollar sales amount (a sales fact).. the Products/Services dimension)? • How is the organization performing through time (i. service.facts and dimensions.

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

They could be composed. Define a dimension table for each dimension identified in terms of: • A key that uniquely identifies the dimension. • Region. In BW. however. Page 206 . 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 • One or more attributes that describe the dimension. dimensions of an InfoCube are likely to represent master data and their associated attributes. and • Market Level.1.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.317 Define dimension tables. • Division. and • The following attribute data elements to describe the MARKET dimension: • Market Description. of related characteristics.

e. • The dimension tables should be easy to understand. They define a user perspective of data of interest to his/her business analytical activities. 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). These could also be compound InfoObjects. For very large dimension tables (e...THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology Some of the characteristics or considerations in defining dimension tables include: • Dimension tables provide the basis for multi-data source integration. the TIME Dimension). 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. and • a new key structure is necessary to store multiple summary levels of data in one dimension table. Business language should be used in designing attributes and attribute values to facilitate enduser access to data in the dimension table. • it may be necessary to integrate with external data or non-key file structures. This new key structure will then define the keys of the InfoObject characteristic included in InfoCube dimensions. an intelligent key structure should be considered to facilitate database partitioning or fragmentation. 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 . • the source system keys are often concatenated keys. In general. e. The data to be retrieved may come from different physical databases or database environments..g. 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.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. 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.g.

g. or long text descriptions instead of just using code values. the MARKET LEVEL attribute indicates that facts relevant to the "market dimension" may be retrieved at the "national". "regional" or "market" (atomic) levels. "division".. 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. An effective-date and/or currency indicator attributes will be required if source system data changes need to be stored in the dimension tables.. These are known as “internal” hierarchies in BW.. Mary Jones is still her current name. 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.g. whose name was Mary Smith up until December 1994.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology • • • 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. • • Default or unknown values may be allowed in a dimension table especially when the corresponding source data for the attribute is not mandatory. These will determine if time-dependent characteristics are to be included in InfoCubes. Other concepts to be considered in defining dimension tables include: Page 208 . a "MONTH ORDER" attribute may be defined to facilitate displaying data in month name order. e. e. In general. GENDER is often not a mandatory attribute and thus should allow for an unknown attribute value. changed her name to Mary Jones since then. the following exhibit reflects the fact that a customer. e.g. in the MARKET Dimension Table example..g. External hierarchies may also be defined for dimension keys or attributes of a dimension that define additional ways a given characteristic’s values can be aggregated. Query processing will have to take this into consideration when returning the current information. Denormalization may also simplify end-user access by providing short. medium. A dimension table may also be denormalized for technical design considerations such as improving performance by reducing the number of joins required. Denormalized dimension tables may be defined to enhance their understandability.

e. or Page 209 . and • A fact component containing attribute data elements representing the facts of interest. 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.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology • • A TIME PERIOD dimension table is almost always required to facilitate the historical or trending aspect of a DW.. and • Fact tables are frequently designed to support "drill-down" analysis of detailed measures underlying an aggregation measure.. and • Categorize these information needs into the respective dimensions or dimension combinations.e. and • Providing a starting basis for user prototyping in validating or elaborating the analytical processing requirements (i.. MARKET and PERIOD dimensions. • Aggregation measures (i.1. • Capturing any known facts of interest to the users in business or decision analysis. a specific PRODUCT/MARKET/PERIOD combination).e... the facts serve to describe the related dimensions)..318 Define fact tables. Dollar Sales or Unit Sales) from the fact table based on the dimension values of interest (i. Facts represent the InfoObject key figures to be populated in the InfoCube. • The measures generally involve time series data or may be appropriately cast into a time series format to support trending. performance measures or quantitative measures). • Adding to the understanding of the related dimensions (i. the greater the number of rows is required in the fact tables. • "Drill-down" into the underlying detail data supporting an aggregate measure (e.e. 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. average price or average cost). 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. gross margin amount). 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. an analyst may: • Request information (i. and The more dimension tables.g. the underlying detail "market level" measures supporting the aggregate measure at the "region" level as defined in the MARKET dimension). A. and • derived or calculated information (e. The primary key of a fact table is generally a concatenation of the foreign keys of the related dimension tables. the identified dimensions and facts).g. Using this fact table. • non-additive information (e...g. 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. Thus. cost or distribution metrics. 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. revenue.g. a fact table often includes a time dimension as one of its key data elements..e.

Page 210 . Revise or refine the tables as needed.320 Develop a physical multidimensional data design. 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. and • Performance considerations. Develop a physical database structure supporting the dimension and fact tables defined in the previous steps considering factors such as: • Denormalization requirements.1. A.319 Validate the dimension and fact tables.1. • Design parameters or BW InfoCubes and InfoObjects. Cross-check the dimension and fact tables to ensure their consistency. A.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology • Perform calculations involving specific "cells" of the fact tables to meet the information needs of a particular business or decision analysis situation.

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology Page 211 .

 the selected tools do not facilitate fast and easy aggregation.  there is a need to standardize the calculation to avoid incorrect values. L3 – InfoCube Design. such as the aggregation strategy. The trade-off is between increased data storage and faster query times. should be re-evaluated on a regular basis. using the BW Statistics InfoCube.It relates to the issue of whether summary data should be stored or calculated as needed. In general. The query activities of the DW environment should be monitored and the design parameters.  the queries against the calculated data are run frequently. The next task. summary data should be physically stored when:  many rows are involved in the calculations. If the end-user access or middleware tools used provide very fast and efficient aggregation processing. addresses the physical InfoCube design parameters that must be addressed Page 212 . or  adequate storage capacity is available.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A major design consideration in developing a multidimensional physical data model includes: • Aggregation strategy . the amount of stored summary information may be able to be reduced.  the calculation requirements frequently change.

Page 213 .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.1.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.

All aspects of the transport and presentation of the key figures for end users should be reviewed and clearly documented.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 .1. Templates. 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.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. Channels.1. 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.12. 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. A.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. 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. shown in thousands.3InfoCube Design A.

Templates. Excel Work Books  Currency or unit of measure requirements for these dimension  Cross modular integration and cleansing requirements each cross modular dimension Page 215 . Channels.1. A.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. All aspects of the transport and presentation of the characteristics for end users should be reviewed and clearly documented. 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. Channels.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology •  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. 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. Templates. 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.

All aspects of the transport and presentation of the Compound characteristics for end users should be reviewed and clearly documented. Page 216 . A.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. 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. Channels. 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. 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.1. All aspects of the presentation of the dimension for end users should be reviewed and clearly documented. Templates.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.

shown in thousands.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. etc.1. All aspects of the presentation of the calculated key figures for end users should be reviewed and clearly documented.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.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.)  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.1. 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 . A. 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. 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. 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.

A. 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. A. review and document business rules for the following:  For each Characteristic  For each Key Figure Page 218 .1. 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.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. Excel Work Books  Delta versus full update implications for each Aggregates Result The identification and documentation of the exact aggregate required . 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.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. All aspects of the presentation of the hierarchies for end users should be reviewed and clearly documented. 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.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.

Identify the processes and functions where InfoSources and InfoCubes are updated and/or archived.1. determine the need for a detail sample (living sample) of the summarized data. • 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. Determine how long data should be stored on-line and how long data should be archived according to defined corporate standards. and validating archiving?  Does the IT department provides the system support. Identify the amount of historical data that will ideally be required and how much is actually available that is accurate.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. performing. • Work with the business process owners to supply missing details Page 219 . When it is defined. scheduling. 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. Procedure • Determine Data Retention Requirements Define levels at which the data will be stored and the retention period for each level.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. 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. A. Based on how the data will be used. processes and reports in BW. the Business Process Master List must be updated with the new set. • Define Detail Specification The task develops the technical specification for creating a layout set. The Application Architect and Technical Architect define the specification. and mapped to the business process that triggers it.

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology Results Create an archiving manual. to record standard procedures and schedules. and what to do in exceptional circumstances Page 220 . based on the information gathered.

The data design deliverable is discussed with management and approved.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. This step may require more than one meeting.1.333 Document and resolve issues as required. All open data design issues should be resolved before the completion of this phase.12. A. A.1. A.332 Conduct a structured walk-through of the design specification. within the project team.335 Obtain formal written approval of the data design deliverable.331 Assemble data design deliverable. Page 221 . If necessary. Conduct a structured walk-through.1. A.1. Ensure the consistency and completeness between individual specification packages. 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. this task may be delayed and completed as part of the Business Blueprint Checkpoint Phase. to confirm the completeness of each design specification and to ensure compliance with both quality and development standards. Any problems in the design should be resolved through the formal issue resolution process. Discuss the data design deliverable with management and resolve any questions and issues.1. A.4Submit Data Design Deliverable Purpose To assemble the various data design deliverables. Review all of the documentation for each design specification and ensure that all of the relevant work products are present.334 Submit and discuss the data design deliverable. In some circumstances. prepare an action list of items to modify.

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). the approach used in this phase is that the paper-based documentation consists of three main parts: • Introduction . greater detail may be required. Page 222 . standards must be defined or adopted from existing standards for all components. on specific occasions. 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. The contents of the different items are then derived together with any supporting information. then further customization of the work tasks and steps will be required. Overview This phase addresses the development of all types of user documentation and because of the inter-linkages.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. However. 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. 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. and • User Procedures . It also describes what procedures are documented and their interrelationships. should be considered together with the Training Phase. Once the different types and media have been determined.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. Paper-based Documentation Where paper-based documentation is to be prepared. Careful attention has been paid in this phase to the level of detail at which the paper-based documentation is prepared. If the approach to be used for preparation of the paper-based documentation is different. • Procedures Summary . The bulk of the user documentation is written at a medium level of detail while recognizing that.13 User Documentation Purpose To create a set of descriptions and instructions to guide the user in operating and managing the system. some of the detailed steps should have been completed at earlier points in the methodology.describes the system's purpose and what the system does. If the proposed system involves a significant amount of organizational change. a summary-level description of the system and interfaces to and from the system. The project team must first determine which types of information must be produced.describes the organization and format of the document.

b c u m e n t a t i o n a s e d U s e r D o c u m e n t a t i o n D Page 223 .l i n e U s e r D D o c u m e n t a t i o n C M 3 oP n r et e p n a t r e D o c u m e P n t a p e Dr .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 O n .b S a es ec ud r i t y ..THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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 R o l e s a n d R e s p o 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.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 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.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 n i n t r o d u c t i o n 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 u 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 e r v i e w M a n a g e m e n t O v e P 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 .

1. e. As requirements and the "look and feel" of the application evolve during analysis and design. Overview Before this phase may proceed. unless it is clearly not going to change.337 Identify target audiences for documentation.13. Identify the target audience for the user documentation and determine their characteristics. Define the specialist skills needed to develop the paper-based or on-line documents. this approach can result in a high degree of re-work. the system's intended user community must be determined.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.1Determine User Documentation Strategy and Work Plan(s) Purpose To determine the target user audience and their particular documentation needs. their documentation needs can be defined.g. The training needs analysis may also form useful input to this task. 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.338 Determine documentation need by target audience(s). 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. Once the users are identified. Ensure that the User Documentation work plan is fully integrated with the overall project work plan. Select and create the project team. Each project has its own special needs and project teams must be careful not to overlook important aspects of each user community. both automated and manual are then derived. A. care needs to be taken not to stray too far in front of the application in developing User Documentation. Once the target audiences have been identified. to define the types of documentation to be developed and to produce a work plan for the development of the appropriate user documentation.1.. A. their needs for documentation. This should also include management's needs. Page 224 .336 Create project team and detailed work plan. 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. Develop a detailed work plan for all of the tasks necessary to create fully tested and working User Documentation.

Page 225 . define the types of documents to be developed that are appropriate for the target audience. • User procedures. Discuss the proposed user documentation strategy and detailed work plans with management and obtain approval.1. • Systems procedures.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. • User manuals or guides.1. Paper-based document types may include: • System overview/summary.339 Define types of documentation to be developed.electronic versions of user manuals that can be referenced with differing degrees of sophistication depending upon the functionality of the access software used. Once the user levels and document needs have been identified for the target audience.electronic files that form an integral part of the application.340 Review and obtain approval of the user documentation strategy and work plans. and • Supplementary documents such as Help Desk procedures. and • Information . Automated document types may include: • On-line Help . A.

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. These should address: • Numbering and naming conventions.. stationery sizes and types and binding.342 Determine media to be used. Define documentation standards. Page 226 .341 Define or confirm use of user documentation standards. A. A. chapters v.13.1. • Word processing/graphics/desktop publishing software to be used for initial preparation and ongoing maintenance.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. A.343 Determine responsibilities. they should be adhered to or altered accordingly. • Ongoing maintenance/updates. on compact disk or by e-mail. A. • Organization issues (e.1. archiving and distribution policies.1. When the organization has existing user documentation standards in use. modules). • Style (language and text format). and • Production. • Format. and • Training linkages. Overview User documentation standards are required to address how the documents should be prepared and how they should look.g. on diskettes.344 Discuss and obtain formal written approval of the paper-based documentation standards. Establish the responsibilities for: • Initial publishing. bound volumes. • Storage/distribution.1. • Change control. Determine how the documents are to be distributed such as in three-ring notebooks. They define a format that allows for consistency across documents and for future document maintenance.

e. Overview Each document should have an introductory chapter or module that describes the format and organization of the volume. A. a catalogue and description of icons (symbols) used and a list and definition of any reserved words. This should describe the organization and medium of the document and include sample forms. full-time users).13. prepare an introduction for each document.346 Prepare document usage instructions. • The intended use of the document. the audience for whom it is intended and instructions for its use.g.g. • Which users the particular document addresses (e..1. system operations manuals).THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. casual users.g. user guides. A.347 Discuss and confirm the paper-based document introductions. This task should also indicate how the materials are to be used. and • Related documents. This should describe: • What aspect of the system the document addresses (e.345 Prepare document introduction.. Prepare a narrative that describes the format of the document.. should the user read it. A. Page 227 .1.1. Using the definition of types of documentation to be developed produced earlier in the phase.3Prepare Paper-based Document Introduction Purpose To provide an introduction for each paper-based document. use it in concert with the application or use it as a training reference.

• Key features of the system.349 Prepare table of contents. • What the system does. 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. and • Major inputs and outputs of the system. Develop a structure to incorporate all user procedures identified into groups of logically related processes. Page 228 .Who completes the action. The main components of each User Procedure are: • Responsibility .THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.1.13. 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. and • The person(s) responsible for completing the steps.351 Prepare management summary. A.1. • The steps to be completed. Key considerations are who will use the information and how much detail is required.1. A. Determine what user documentation is required.1. A. A. Each logical grouping of user procedures is defined in the table of contents for the documents. Define a numbering scheme for the user procedures and assign a number to each user procedure. • The sequence of the steps.350 Prepare User Documentation Overview. It shows the user's interactions with the system and defines the scope of the system to the user. Prepare the management summary which is a general description of the system. All user procedures identified are placed into groups of logically related processes.348 Identify user documentation requirements. A.1. • Primary users of the system.352 Prepare User Procedures. 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. Prepare the User Procedures which form the main body of the document.4Develop Paper-based User Documentation Purpose To create the main section of each document to be produced. The User Documentation Overview provides a visual representation of the system and the procedures needed to support the system.

356 Discuss and confirm the content of the draft User Documentation content. Assemble samples of each report for inclusion with the User Procedures. 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. A.1.1. A.354 Assemble and cross-reference Report Layouts. Page 229 . Each procedure step should begin with a strong action verb telling the person responsible what to do. Cross-reference the Report Layouts to the procedures they relate to for ease of use.Which things (e. which details work steps for a single individual.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology • • Procedure steps . complex or detailed.1. sequentially numbered. A. Where the responsibility for a set of procedure steps is long. The procedure steps are described in order of occurrence and sequentially numbered. if necessary.. Prepare any Detail Task Descriptions. A. then it may be easier to document these steps as a Detail Task Description.355 Document System Responsibilities. These provide a visual representation of the information produced by the system. reports. Document the System Responsibilities which define the roles of the users as they relate to the system.353 Prepare Detail Task Descriptions.1.g. 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. and Supporting documents . as necessary. They define the title of the user and the types of procedures for which the user is responsible.What action to take presented in a logical time sequence and any dependencies on other User Procedures. input forms or control logs) are related to and needed to complete the procedure step. 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.

when they are executed. A. A. Also include definitions of key data elements and their relationship to other data elements used in the system. Overview To make it easier for users to navigate through a particular document. Alternatively. Page 230 . in what order they are executed and any cut-off dates that must be met. and • Balancing and reconciliation procedures necessary to keep all of the various systems in balance. A. The schedule should include references to the User Procedures covered by the schedule.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. The data transformation systems are documented in the Management Overview Diagram and should include: • Information received from other systems. as necessary. 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.1. Develop a glossary of key terms in simple and clear language and terminology with which the users are familiar. 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.5Prepare Paper-based Appendices Purpose To create any supporting paper-based appendices.357 Prepare glossary.1.359 Document processing schedules.361 Discuss and confirm the draft paper-based appendices content.1.13. the names of the User Procedures. Document the system interfaces and the data transformation flows. Create any other appendix items.358 Document system interfaces and data transformation. • Method used to exchange information. • Controls used to ensure the accuracy of all the information exchanged.360 Document other appendix items. information that is useful but not appropriate to place in the body of the document should be included as an appendix.1. A. A.1.

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

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

the development process should largely follow the steps described above for the development of the Help system. 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. A. Discuss the on-line documentation content with management and resolve any questions and issues. Change control steps necessary to update the Help text with amendments derived from system testing need to be created.372 Develop on-line information. A. A. In practice.1.1. The responsibilities/resources necessary to complete the maintenance should be determined and agreed.1. To ensure that whenever any subsequent changes are made to the system once it has commenced live processing.369 Load and test Help text at the program level. There is always difficulty in loading and testing the Help text during a project. the Help text should form part of the Unit and Component Testing of each program in the system that contains Help text. As each component of the Help system is developed. Load and test the Help text at the program level.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology • • • • All input/output/inquiry/interface processing.1. Page 233 . this step may involve more than one meeting to resolve outstanding issues. This will necessitate careful consultation with the application development group to minimize duplication in the testing process.1. Security and controls including housekeeping and system balancing. complete structured walk-throughs to ensure that the contents are of the requisite quality and accurately support and reflect the system's functionality. The Help system should form an integral part of the overall System Integration and Testing and not be treated separately.373 Submit and discuss the on-line documents with management. prepare a list of items to be modified. A. All file maintenance. and Glossary/explanation of terms and acronyms. If necessary. define the tasks necessary to maintain the Help system in synchronization with the changed functionality. Ideally. as it is rare that the final system is completed and time is available for separate addition of the Help system.370 System testing of Help text.371 Develop ongoing maintenance procedures for the Help system. A. Ensure that all of the unit/component tested text is included within the system testing process. Develop the on-line information where the User Documentation is presented as an electronic form of paper-based documents. If this is not possible.

This should also include definition and approval of the responsibilities for: • Ongoing maintenance/updates.1. Obtain formal written approval of the completed on-line documents sub-system.374 Obtain formal written approval of the completed on-line documents sub-system.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. Page 234 . • Distribution of changes and additional access to the sub-system. and • Training linkages.

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. The training needs assessment occurs throughout the DW project and training needs are defined and actioned progressively throughout the project. Page 235 . This should ensure that there is full participation and involvement. 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. Although the emphasis in this phase is on user training. For instance. then a pilot training session can be run to validate the training. 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. course materials are developed with the approach and content of each course module being determined by its learning objective. If the course is to be repeated several times. Instructors are trained to ensure that they are able to convey the course content using the prescribed approach.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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. Training should be tailored to management and groups of users based on their position in the organization and their expected use of the system. it may be necessary to have team members attend specific tool training in the Prototyping Phase before the Realization Stage activities. For each of these groups. if necessary. before the main training sessions are scheduled and conducted. The pilot training session is evaluated and the training approach and materials modified. which should result in a seamless hand over of all items.

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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 n P n ee l r s t oo n n e l r e q u i r i n g t r a i n i n g 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 g S c o p e a n d S t r a t e g y 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- T a i C L T Tg l Cs I n P n 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 D 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 g M a t e r i a l s C S o e n 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 T r a i n i n g M a t e r i a l s a n d A p C 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 e d P e r s o n n e l Page 236 .

g. size and type of training courses to be developed.378 Determine the numbers and locations of personnel to be trained in each group.14.376 Identify target audiences. Present the potential trainee list to management to verify the assessment of who must be trained and their relationships with the system. A.. • System responsibilities (e.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. number of training sessions scheduled and/or required training time needed. the target audiences.g. A. A.377 Determine how each of the personnel within a group will interact with the new system.1. Page 237 . management. Overview To build an effective training program.1. A. e. while data entry staff may be on-line maintenance users only. Each group will interact with the system differently.375 Confirm application and automation boundaries.1. their levels and their work activities. Assess: • Level within the organization (e. clerical. training resources required. information must be gathered regarding the needs of each group of potential training students.1. The numbers and locations of personnel to be trained in each group may affect the instructional method chosen.. and • Experience level and skill base of identified personnel.1.380 Obtain formal written approval of the personnel training profile. Each of these different groups may require separate training courses that should be tailored to that group's specific needs. their levels and work activities all must be identified. management may be enquiry only users. A. This information must be as accurate as possible as it will have an effect on the number.g.379 Confirm with management the personnel to be trained. system maintenance operations). This initial analysis provides the basis for developing appropriate courses to meet the specific requirements of each group.. operational). To develop appropriate training programs. users.1Identify Personnel to be Trained Purpose To identify the target audiences. A. 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.1.

2Determine Training Scope and Strategy Purpose To determine the training needs and the type of training to be conducted. • Estimated number of sessions. • Sub-system interface issues. Some high-level and specific training in the management issues of the system should also be created. and • Optimum class size. Define the training courses needed based upon individual requirements. 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.1. 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.381 Identify training courses. and • Organizational structure issues. specific training for the Help Desk support personnel may be required. • Balancing/reconciliation for daily processing and period-end and year-end processing. In assessing the training courses required. • Target audience. • Course purpose and prerequisites. Include: • Course title. Page 238 . 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. management training in the system should not be ignored. Courses may be required in areas such as: • System features and overview. In addition to the detailed aspects of the day-to-day operation of the system. The strategy determines whether training will be completed by a group of teachers or by a nucleus of trained staff.14. then the training scope and strategy can be defined. Based on the types of courses needed and the levels of the target activities and their activities. If a Help Desk support function is to be provided. identify each of the training classes to be prepared. The scope defines the number of courses to be developed.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. • Estimated number of students for each session. Overview Once the personnel to be trained are identified. A. their purpose and number of training sessions.

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

decide what should be accomplished. Training approaches and supplemental training techniques are selected for each course module. For each course. Consider and determine the different delivery approaches. Information giving (telling and showing) Involves verbal or visual presentation of material to the trainee.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. Describe the content and flow for each module. A. Overview The content of each course module is determined by considering the course learning objectives and the level of target audience(s). Objectives are written from the learner's perspective. Examples include lectures. This approach uses hands-on problem solving or interactive techniques to add reinforcement and understanding to the learning experience. For each course. divide the training course into logical.388 Divide training course into modules. manageable modules.1.1. A. 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.390 Determine training course plan and schedule.14. Use key words to identify major concepts. The course modules are sequenced and course materials are developed. Each module's content should be able to be presented in no more than one-and-a-half hours. each representing one training session. A.1. The learning objectives describe the purpose of the course module. and • Anticipated time frame for executing training courses. Derive the following for each different course: • Sequence of course module presentation. techniques or information that must be included. reading materials and demonstrations. A.387 Determine desirable training methods to be employed.1.1.386 Determine learning objectives for each course and course module. They emerge from the training needs analysis and by assessing how the users will execute the different tasks to maintain the system. There should be no more than two procedural tasks included in a course module. Discovery learning (exchanging and doing) Involves a high degree of trainee participation.389 Determine sequence and content of each course module. A. • Estimated length of course by module.3Develop Training Course Materials Purpose To prepare course materials for each course module based on the specific method of delivery. Page 240 .

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

399 Prepare instructor materials.1. Consider: • Orientation for those who are technically competent and are experienced in using the educational method chosen.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. • Course material preparation and distribution. In these cases.398 A. A. prepare the schedule and arrange for: • A location for the course. Complete appropriate individual training for each instructor to ensure that they have the appropriate teaching skills before they begin to provide tuition. computer or other equipment availability. Page 242 . For the course content training. Schedule and conduct instructor training.14.1. Prepare the audio-visual or other materials needed to conduct the instructor training sessions. The mix and experience of instructors will determine the depth and type of instructor training required before teaching commences. and • Instructor training for those who are technically competent but not experienced in either teaching or using the educational method chosen. Prepare a detailed instructor guide for each course.g.396 Determine the instructors and define their individual training needs.1.1. and • Establish test training technology environment (e..400 Evaluate and modify instructor training. A. A. Complete the pilot course. Determine each instructor's individual training needs. detailed content of each course module and exercises and answers. components such as LAN.1. Overview Instructor materials are prepared and instructor training is completed. Allow adequate time to "fine tune" the environment. A.397 Prepare instructor guide.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.1. database and application). an instructor guide helps to explain course timing. An instructor guide is needed in cases where the training will be given multiple times and given by others besides the course developers.401 Discuss and obtain formal written approval of instructor training materials and course. Evaluate the pilot instructor training course and modify the training approach/materials as required based on the evaluation. A. Determine who will fill the training instructor roles. • Audio-visual. course objectives.

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.405 Hand over training materials to internal training group.1. A. • Instructor evaluation. and • Establish test training environment (LAN.402 Schedule and conduct pilot training session(s). relevant and wellreceived by students. documents or programs. A.1. database and application). Modification of the training approach and materials may be required as a result of feedback from the pilot training session(s). approach and techniques. Overview Pilot training session(s) are scheduled and conducted to enable the course designers and instructors to evaluate the course content. • Course material preparation and distribution. Prepare schedule and arrange for: • A location for the course. Evaluate the training session in relation to objectives. • Audio-visual. Allow adequate time to "fine tune" the environment. A. Observe student reaction to the course and request student evaluation(s) of the course presentation. • Student evaluation. exercises and test results based on: • Student reaction.1. Provide copies of all training materials developed for the project and any other developmental data. Ensure that responsibility for ongoing maintenance and updating of the materials has been assigned to the appropriate personnel. Present the revised materials for review and obtain formal written approval.5Conduct Pilot Training Sessions (Optional) Purpose To test the training to ensure that all training courses are understandable.14. presentation. content. computer or other equipment availability. materials. Define which students will attend the pilot course and which instructors will teach.403 Evaluate and modify training materials and approach.404 Discuss and obtain formal written approval of final training materials and approach.1. Page 243 . A. and • Observer evaluation. materials and exercises. Modify training approach/materials as required based on the evaluation.

Page 244 . LAN. additional planning and resources and increased project management responsibilities. • Audio-visual. Depending upon the specific project. initial sessions should be evaluated and appropriate modifications included in subsequent sessions.1. Allow adequate time to "fine tune" the environment. A. In these circumstances. students notified and the courses are conducted.14. this step may need to be supplemented with additional work tasks.1. time and any required preparation. and • Establish test training computer environment (e. Complete the schedule of training sessions. If a pilot training session is to be conducted.6Conduct Training Sessions Purpose To train the management and users on how to use the new system in an efficient manner. If a Help Desk support function is to be provided to support the new system. computer or other equipment availability. early training of the Help Desk personnel may be required before the bulk of the user training occurs. If a course is to be offered more than once.408 Conduct training session(s). Ongoing course maintenance and subsequent training responsibilities are established. If necessary. A. it may be appropriate to conduct a pilot session for the specific purpose of evaluation and modification.1. Observe student reaction to the courses and request student and instructor evaluation(s) on the course presentation and materials. Course evaluations should be included in all courses presentations. Overview The training session(s) are scheduled.406 Prepare for training sessions. new hires and other ongoing training needs. modify the training courses based upon the evaluations. Arrange for the following: • A location for the course. Notify the personnel who will attend each training session of the location.1. A. completion of the training to begin the implementation of the new DW system may take some considerable time.g. 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. if there is a staged or phased implementation). date.407 Schedule personnel to attend training session(s). identify students representative of those attending the subsequent training sessions. Any required pre-course materials should be distributed to the students. If many sessions are to be offered.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.409 Evaluate and modify training approach/materials as required. A. database and application). • Course material preparation and distribution. particularly if there is a wide or dispersed audience for the training (e..g.

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.1.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. Page 245 .410 Define and approve responsibilities for ongoing maintenance and presentation of training courses and materials.

the acceptance testing may form part of the integration testing. 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. This document should contain the agreed upon user acceptance criteria related to functional and data integrity. It is important to ensure that the acceptance tests are suitable for management. 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. e. as the combination of technology components will impact significantly on the test itself.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. Although the acceptance test is executed during the Final Preparation Stage. Overview The intent of the phase is to ensure that: • A formal acceptance sign-off document is prepared and agreed.. if the acceptance test is not using the final production environment and configuration. and • A complete and detailed test is completed and results verified by both the management and users. On some projects.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. 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. the acceptance test criteria should form part of the system and integration tests to ensure early testing of the acceptance process. the planning and criteria for the acceptance should be defined before the design is completed. end-users of the system and computer operations. Page 246 . so that only one set of acceptance tests is needed. An Acceptance Test Team must be formally created and be composed of the correct skill mix with each member having defined tasks and responsibilities. The sign-off document is then used to confirm acceptance. wherever possible. The technology environment to be used for acceptance testing must be discussed and agreed.g. In addition. A project manager with relevant skills and experience must also be selected and be responsible for all of the different acceptance test components.

o a t a f f Page 247 .THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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 g y 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 n a 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 o 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 S y s t e m T e s t e d A p Cp O 3 ol i cn a d t u o c i n t T e s t A 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 .

The criteria should state.411 Select the staff and assign responsibilities. Overview A statement of quantifiable acceptance criteria will need to be derived by the end of the Business Blueprint Stage. • A representative from each of the user departments affected by the new system.1.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. The criteria must be clear. say "retrieve journal entries for the month and verify the results against Page 248 . • Test data preparation. Based on the acceptance criteria. an acceptance test strategy should then be developed. a back-up person for each representative. Select a project manager and assign the responsibility of supervising the team and managing all aspects of the acceptance test definition and execution. the sign-off for this task will not occur until the Business Blueprint Checkpoint Phase. 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. Assign responsibilities to each member of the team which should include: • Test planning and scheduling. In addition.1. • Where viable. quantifiable and accurately reflect the agreed scope of the system. • Test execution and result verification.15. However. where possible every effort should be made to start this activity as early as practicable. Select a team to work on the development and execution of the acceptance test. and • System owner input where required. For example "meeting user needs" is too vague. This should form part of the establishment tasks for the acceptance test. to deal with queries from the user team. one or two members of the development team should be assigned.1Agree Acceptance Criteria and Test Strategy Purpose To ensure that acceptance criteria and an acceptance test strategy are developed which are comprehensive. On many projects. This contains testing procedures for verifying the acceptance criteria and/or identifying critical deficiencies in meeting them. Derive acceptance criteria from the agreed requirements system models developed in the Business Blueprint Stage. and • Error identification and problem resolution. The acceptance criteria and acceptance test strategy will need to be reviewed by the development team before they are agreed and signed-off. A. 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. explicit and verifiable. The Acceptance Test Team may require some education or training in the tasks that they are required to complete. as a focal point. • Definition of acceptance criteria. 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. A. • Resource allocation and acquisition. creation and storage.412 Prepare a statement of acceptance criteria.

space has been used in optimal fashion yet data is still readable. A. Review the acceptance test strategy with the user test team to check for completeness and appropriateness. A. Specify the technology environment in which the acceptance testing will be completed. System performance criteria should only be specified where they are a critical factor for system acceptance. Service levels must always be clearly stated and the means of measurement documented (e. Page 249 .g.1. The strategy should contain an outline of the type of testing required to verify each of the acceptance criteria. 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. This is particularly important if the tests do not use the final production environment. For example: • Criterion . and • Test . 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. Vague or unmeasurable items should be returned to the user test team to be fully defined. develop and document a strategy for conducting the acceptance testing. as the acceptance testing may need to be repeated several times in different locations (e. a staged implementation by location... Vague or inexplicit acceptance criteria can lead to the risk of "defining" a system that the developers can never complete. hardware capacity and the load under which this performance is required must also be carefully specified. revisiting previous accesses and changing the values for the rows and/or columns works. rows and columns can be accessed as appropriate.1. parallel.413 Review and confirm acceptance criteria. The impact of the means of commencing live processing must also be addressed (e. 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. A.all dimensions values fit in dimension selectors. office or state). Any problems and issues identified should be resolved and if necessary routed through the issue resolution process. Where performance criteria are specified the system conditions. timing. locations.g.1. However.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology the current production system". After the criteria have been defined and agreed.g. staged or phased). for those to be included in a Service Level Agreement)..414 Define acceptance test strategy. The responsibility for producing the acceptance criteria and for conducting the acceptance test must be with the system users and appropriate management.415 Review and agree acceptance test strategy.verifying each data table in the DW.

Review. agree and obtain formal written approval from management. Page 250 .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.

g. Development of acceptance test cases is the responsibility of the system users and the Acceptance Test Team. • Adequacy of security. From a developer's perspective.416 Review the acceptance criteria. • Adequacy of system processing efficiency. development. their impact on the acceptance test should have been assessed. • Data conversion quality and accuracy. production). the contents of the acceptance test cases should be fully understood.15. A. consider whether any design changes are significant enough to require changes in the methods to assess: • Number of successful production cycles. In particular. and • Completion of any specified acceptance test cases. • Data transformation quality and accuracy.1. • Verification of system output. • Adequacy of processing under peak load (volume testing). The technology environment warrants special attention.. the acceptance criteria may also change and should only be modified when agreed by both the developers and the business users. Determine the implications of any changes made to the system design since the acceptance criteria were originally defined. Overview The acceptance test strategy and agreed upon acceptance criteria are reviewed for completeness and accuracy. test. and • The contents of the user acceptance test can be included in the System Test Plans as one potential test cycle. • Guidance can be provided to the users on the type of tests to be executed and potential sources of data. so that: • A check can be executed to ensure that the acceptance test cases are within the agreed scope of the project.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. The acceptance criteria are subject to the same degree of change control as the original requirements. 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. particularly if the project is using a new configuration. As the different environments have been created during the project (e. • Adequacy of User Procedures and system operations instructions. Monitoring the acceptance test criteria and strategy should continue throughout the development life cycle. Page 251 .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. Acceptance criteria should have been defined based on the Business Blueprint Stage deliverables but as requirements change during a project.

Make any adjustments as necessary. as a substitute for specifically designed acceptance tests. Complete a structured walk-through of the acceptance test script and test cases with the Acceptance Test Team.1.417 Review the acceptance test strategy. Review the acceptance test cases developed by the system users. To effectively assess the validity and the comprehensiveness of the proposed acceptance test cases. a series of test steps for each acceptance test condition). or • The execution of parallel processing for a specified period or number of processing cycles. 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. the overall acceptance test strategy must first be understood including: • An acceptance test script (i.420 Obtain formal approval of the acceptance criteria and approach.418 Confirm contents of acceptance test cases.1. A. 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.1. If necessary. Obtain formal written approval of the acceptance criteria.1. the acceptance test cases and the responsibilities for management and execution of the acceptance test. assist them in building appropriate test cases.e. etc. Suggest the use of Business Scenarios developed jointly with the users in the Prototyping Phase as useful starting points. under user and computer operations control. Because of the time scales involved in producing this type of test data and associated expected results. A. Test Data Specification.. 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. A. it is more likely to be generated in parallel with system testing. In practice.419 Discuss and confirm acceptance criteria with management. the approach to be used. prepare a list of items to be modified. Provide the system users with copies of the generic test forms (Test Plan. Review the acceptance test strategy.) and the appropriate phases of the methodology to give them a framework for developing acceptance test cases. If they have not been developed at this point.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. this step may involve more than one meeting to resolve outstanding issues. Page 252 .

In the event of the acceptance criteria not being met.3Conduct Acceptance Test Purpose To confirm that the completed system meets the agreed requirements.1. Page 253 . if applicable. Archive the acceptance test results with the project working papers.421 Execute and verify acceptance test.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. At the completion of all tests.15. Depending on the degree of involvement in the acceptance test process. 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. this should not involve the same personnel that have been responsible for system testing). Cross-reference to the Project Charter. The outcome of this process will either be that the problem is successfully resolved. the individual results may need to be aggregated. complete either of the following: • Provide support to both the users of the system and the staff operating the system during the acceptance tests. A. Confirm that the DW system meets the user acceptance criteria and obtain a formal written approval and acceptance sign-off from all parties concerned. The reasons for non-acceptance should be documented and the issues investigated further.1. 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. depending upon the means of system implementation. A.423 Obtain formal written acceptance sign-off of the operational system. A. along with the formal sign-off.422 Document compliance with acceptance criteria. or • Direct the acceptance test on behalf of the users with users and operations staff (if possible. Overview The acceptance test(s) is completed and results verified. especially the identified system owner. Based upon successful completion of the test.1. the operational system is approved as ready for production. to avoid potential conflicts of interest. 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. the standard issue resolution procedures should be invoked. The acceptance test may have to be completed more than once.

Page 254 . details of testing environments and new staff members on the project. change and issue resolution procedures. 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 SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. Additionally.16 Business Blueprint Checkpoint Purpose To confirm the results of the business Blueprint Stage of the DW project with management. at specific points in the life cycle. in this Phase. Revisions may be needed to the project work plan and the detailed work plans. there is a need to monitor and report project status. additional tasks will have to be completed. and • The addition of new information not previously recorded. a major revision of the Project Charter occurs and this is the main focus of the checkpoints. the risk assessment needs to be reviewed to reflect changed risks in Realization. Overview Throughout all of the stages of the DW life cycle. and project organization will generally change little on transition from Business Blueprint to Realization. • Revisions to the plan fall into three broad categories: • Minor changes to static information. 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. 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. Amendments will be made during each stage as changes are identified and the results of quality reviews are included. However. Items such as project background. One of these points is the completion of the Business Blueprint Stage and these additional tasks are described in the Business Blueprint Checkpoint Phase. New information may include details of the development environment. 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. many of the items fall into the first category. the CPDEP Phase 3 task of “Develop Preferred Alternative(s)” is completed. At the end of each stage. The Project Charter is a living document that will be continually updated throughout the life cycle of the project. • Major revisions to existing sections. and a recommendation and Class 3 Estimate provided for the DRB/GRT. In the Business Blueprint Checkpoint. to identify and address scope issues and to conduct appropriate Quality Management Reviews.

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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 O p e n I s s u e s P R e 2 v i e w I s s u I s s u e s e r e s o l u t i o n s P r o j e c t p l a n s U p d P 3 a t e P r o j e c U t pP d l a a n t e s d p r o j e c t p l a n s Q u a l i t y P l a n P U p d a 4 t e Q u a U l i t y p P d a l a t e n d Q u a l i t y P l a n 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 B l u e p r i n t S t a g e D e F o r m a l A p p r o v a l P o i n t Page 255 .

• Data transformation system design. Resolve the issues as soon as possible and document any outstanding issues to be addressed by the Issue Resolution Process.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. If a project scope change is needed.1. Discuss and confirm with management the completeness of the data transformation system design. Ensure that the presentation system design is consistent with: • Data 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. A. and • IT infrastructure 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. Resolve the issues as soon as possible and document any outstanding issues to be addressed by the Issue Resolution Process. If a project scope change is needed.1. Ensure that the data transformation system design is consistent with: • Data design.425 Confirm the completeness of the presentation system design with management.16. and • Analytical Processing Data Definition.1Confirm Completeness of the Business Blueprint Stage Purpose To complete an integrity check of the Business Blueprint Stage deliverables. A. and • IT infrastructure design. Overview The DW system design completed during the Business Blueprint Stage is discussed with management. obtain formal written approval of the change from management. obtain formal written approval of the change from management. Determine the impact of the findings or issues on the project. Page 256 . Determine the impact of the findings or issues on the project. and • Analytical Processing Data Definition. The focus is on confirming the completeness of these results and determining their impact on the project. Discuss and confirm with management the completeness of the presentation system design.424 Confirm the completeness of the data transformation system design with management. • Presentation system design.

If a project scope change is needed. and • IT infrastructure design. • Data Transformation system design. Determine the impact of the findings or issues on the project. obtain formal written approval of the change from management. Ensure that the IT infrastructure design adequately supports the: • Data Design. Page 257 . Discuss and confirm with management the completeness of the data design. and • Analytical Processing Data Definition. A.1. Resolve the issues as soon as possible and document any outstanding issues to be addressed by the Issue Resolution Process. If a project scope change is needed. 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. 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.426 Confirm the completeness of the data design with management. Discuss and confirm with management the completeness of the IT infrastructure design. obtain formal written approval of the change from management. Resolve the issues as soon as possible and document any outstanding issues to be addressed by the Issue Resolution Process. • Data transformation system design. and • Technology Definition completed in the Technology Definition and Design phase.427 Confirm the completeness of the IT infrastructure design with management. and • Presentation system design. Ensure that the data design is consistent with: • Presentation system design. Determine the impact of the findings or issues on the project.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.1.

not all issues will need to be fully resolved before progressing to the Realization Stage.. Review all open issues contained in the Issue Resolution Log. e. Assess the impact of any outstanding issues and reflect in the plans and risk assessment for the next stage.2Review Issues Purpose To identify all outstanding issues and either resolve or agree future actions. Document on the Issue Resolution Form or cross-reference to the Issue Resolution Form. Ideally.429 Agree approach to outstanding issues. The decision on the importance of resolving an issue should be made by the project manager in conjunction with senior management or the GRT.1.428 Review and resolve any outstanding issues. For any issues that will not be resolved immediately. if after investigating an issue.g. Overview All issues must be reviewed and appropriate action agreed/taken. it turns out to be an expansion of scope or an error in information provided by the user. Ensure that procedures for investigating outstanding issues are fully understood by both developers and system users. Identify possible resolutions and initiate appropriate corrective action. A. The cost of investigating outstanding issues may need to be split between both parties. the cost of the investigation as well as the resolution of the error should be borne largely by the system users. an agreed approach to resolving all outstanding issues. no issues should remain outstanding at the end of the Business Blueprint Stage. an approach describing how these will be resolved should be developed and agreed. In practice.16. Page 258 .THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. A.1.

dependencies and milestones for the remaining stages of the project. A. and • Cost of system and administrative support staff time. Develop plans for the Realization Stage considering the understanding. A.16. • Scheduling. based on the detailed work plans.431 Consolidate plans into the project work plan. taking into account the available staff and skills. • Cost of staff time and expenses. Use the plans currently contained in the project work plan and the revised estimates. and Page 259 .1. Identify the tasks needed to complete these stages.434 Validate overall project cost and time estimate. The standard tasks may. Develop final cost and timing plans.1. • Cost of staff time. Ensure that all plans are included in the project work plan that combines all tasks.1.3Update Project Plans Purpose To update the project plans based on the findings and information obtained during the Business Blueprint Stage. however. 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. Develop detailed work plans for the Realization Stage. For each task estimate: • Number of project staff. A.433 Produce detailed work plans for the Realization Stage. findings and issues relating to the DW project gathered 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.1.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. prepare a high-level estimate including: • Staffing resources by skill level. • Duration and scheduled completion of each task. For each subsequent phase.1. • Amount of time estimated to complete a phase.432 Revise estimates in light of previous experience. Review the original estimates for the Realization Stage which were made based on the best knowledge at the time. Experience gained during execution of the Business Blueprint Stage may indicate variances from these estimates that will need to be reflected in the estimates for the next stages. need some tailoring for the particular project. A. A. • Amount of time each person is allocated to a task. 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.430 Develop plans for the Realization Stage.

review any discrepancies and take appropriate action. Some of the data needed to prepare an estimate may not be available. • Increasing the staff complement in an attempt to reduce time scales at increased cost. determine and document the assumptions used to prepare the estimates. For these situations. Compare the final cost and timing plans with the originally agreed figures. Page 260 . • Revisiting the original scope to see if scope has changed over the lifetime of the project.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology • Cost of additional hardware and software. Formal written approval should be sought for any actions to be taken and plans revised accordingly. This may include: • A negotiated reduction in scope based on changed costs. • Re-phasing of the work to ensure that time scales are met. • Agreeing a revised cost of the project. or • Reducing the staff complement to reduce cost but increase time scales.

436 Review project risk dimensions. Obtain agreement with management on the appropriate actions to take. Those sections of the Project Charter that need to be updated for Construction are reviewed and amended or created. A. These are reviewed and appropriate amendments made to reflect the end of this stage and the start of the next. the Business Blueprint Checkpoint Phase has largely been concerned with work planning. Update the implementation strategy.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.435 Review and revise Project Risk Assessment. In this latter instance. new versions of software) significantly affected the project? A. the Project Risk Assessment needs to be revisited. Overview To this point. Review the risk assessment as a result of the Business Blueprint Stage experience and the updated project plans for the Realization Stage..1.1. Many issues are addressed in the Project Charter that go hand-in-hand with the work plans. 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. Identify where the risk ratings described in the risk assessment are higher than expected or are greater than originally anticipated. data conversion strategy and appropriate testing strategies as necessary. 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.g. In particular. 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.. as appropriate. assess the impact of making changes to the project plan on the associated strategy documents developed in this stage.16.4Update Project Charter Purpose To ensure that all aspects of planning and quality have been properly addressed. Page 261 .

Page 262 . • Corrective actions to be taken should be agreed by all parties and documented. Review the Project Risk Assessment completed earlier to identify any changes from the initial assessment. • How will the fact that the risk factor has come to fruition be recognized. For identified threats.. A. and • How will the situation be addressed (e.1. Revise the Project Charter as appropriate.439 Seek independent approval for the revised Project Charter.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. • The severity of the risk. Such actions should have clear time scales and responsibilities assigned. Ensure that all these areas have been properly addressed before progressing to the Realization Stage. 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. A. avoidance.1. document: • The likelihood of impact on the project. control. assumption or transfer).438 Revise the Project Charter.437 Revise risk management approach.g. and • Further reviews should be scheduled to ensure corrective action is undertaken. Many areas within the Project Charter may not have been completed in full until this point since they primarily affect the Realization Stage.1.

a final review of deliverables is undertaken and formal written approval obtained for all of the Business Blueprint Stage deliverables. formal written approval should be sought for deliverables on an ongoing basis.442 Obtain formal written approval of the Business Blueprint Stage deliverables. Overview Throughout the Business Blueprint Stage. Obtain formal written approval of the Business Blueprint Stage deliverables as defined in the Project Charter and the project contract. At this point. At the close of the stage.1. . A.440 Submit and discuss Business Blueprint Stage deliverables.441 Discuss process for approving changes to confirmed design.1. Responsibility and time scales for formal sign-off should have been defined in the Project Charter and project contract. Discuss the Business Blueprint Stage deliverables with management and resolve any questions and issues.5Obtain Approval of Business Blueprint Stage Deliverables Purpose To seek final review and formal written approval of the Business Blueprint Stage deliverables.1. It is extremely important that the design of the DW system and its surrounding components to be approved and "frozen".THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. 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. This could include formal change requests with justification and cost estimates. the deliverables and a Class 3 estimate are provided for approval to the GRT/DRB as per CPDEP. However. *** FORMAL APPROVAL POINT *** Page 263 . throughout the Realization and Final Preparation Stages.16. changes may need to be made to the design. Complete the necessary approval procedures to complete CPDEP Phase 3 “Develop Preferred Alternative(s)”. A. Ensure that project management and senior management agree on a process to manage these proposed design changes. A.

and documentation a) Data extract programs – Extractors. • Stress Testing.g. constructed BW components. 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. 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. • System Testing. Certain of the types of testing listed are described as discrete phases of work within the methodology. or ETL Generated Components b) Data transformation and DB components – InfoSources. test and document the individual components. Others are combined with tasks with which they are tightly coupled (e. • String Testing. component development and unit testing) and still others are defined as tasks or even steps within a phase (e.. and BW Explorer Construction These three phases develop detailed specifications from the design documentation and then construct. • Integration Testing. stress testing is considered to be a form of system testing). Update Rules c) Presentation components – Queries/Workbooks. The decision on the relative importance of the different types of testing will Page 264 . a comprehensive set of testing tasks are described that span the Construction and Final Preparation Stages of the development life cycle.g. Key Deliverables: 1) Program code. • Back-up/Recovery Testing.g. Custom ABAP. and • User Acceptance Testing. Testing in these phases consists of: • Unit testing. stress testing may be referenced implicitly within system testing but if it is a critical part of a project. The main testing activities are: • Unit Testing. e. Types of Testing The purpose of software testing is to identify and correct errors before implementation. InfoCubes. The objectives are final construction and testing of the system. it may be elevated to a separate set of tasks on a project plan.. Transfer Rules. Web components. In the methodology. and • Preparing the Unit to System Test Migration Plan. BW Administrator’s Workbench Construction..THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology Realization Stage The purpose of this stage is to construct system components based on the Business Blueprint. • String testing.

variances will need to be recorded on a Test Problem Report (TPR). When all TPRs have been resolved and successfully re-tested. 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. system testing looks at the entire application from a business perspective to ensure that the application functions as designed. System Testing Unlike unit and string testing. The test planning process is modified in the system test to reflect the business emphasis by adding the concept of test cycles. and • Verify data edit. program operation instructions and expected results) are defined for each condition. Like unit testing. Working from the design specifications. which all take a technical view at the program level.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology reside with the project team. the TPRs associated with each program and component are returned to the developer for resolution.. the program or component is declared ready for string testing. Some of the unit test objectives are to: • Verify that the program and component modules perform functions as specified in the design. validation and cross-field validation logic. a test plan is developed for each program and component. Page 265 . 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. test steps (input data. menus and security) Again. the test is executed by following the test plan in a step-by-step fashion. the following paragraphs provide guidance in understanding the intent of each of the types. program or component operation and expected results. After the test plan has been reviewed in a walk-through and approved by the team leader. At their lowest level. 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. If a separate unit test team is employed. however.g. a detailed test plan is developed which specifies testing steps that include input data. It focuses on the sub-system to sub-system interfaces within the application not tested in previous testing tasks. Test objectives and conditions are then defined for each cycle. and • Control structures (e. 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. At the conclusion of the test run. operation instructions and expected results. Destructive testing techniques are used to try to "break" the program or component. • Exercise program and component branch decisions (including exceptions and errors). Finally. 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. Test cycles act as placeholders for the higher-level business processes automated by the application. The TPR process is again used to resolve discrepancies between expected and actual results. test plans consist of a series of testing steps which include input data. Specific focus areas for string testing include: • Program to program interfaces and communications.

Integration testing ensures that interface standards are met and that no errors are encountered as information is passed from one system to another. Therefore. and • Correctness of processing at load. Overall acceptability is based on the following criteria: • Overall throughput. and/or • Insufficient tolerance to bad input data. • Misunderstanding of external input and output formats. • Resource utilization. application testing is not complete until the external interfaces are tested. If not specifically addressed as part of a contingency planning assignment. Back-up/Recovery Testing Back-up and recovery testing should be completed in the context of the larger contingency planning effort. Rigorous integration testing reveals problems before an application goes into production and provides the opportunity to address potentially damaging system outages. Most interface errors are caused by: • Invalid timing or sequence assumptions related to external signals (incorrect sequence of jobs or data). Acceptance Testing User acceptance testing is executed just before the system goes live and it is the final testing component in the methodology. integration testing checks the effect on the performance and capacity of co-existent systems to ensure that shared resources are not overburdened. 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. 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.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. • Table validations which were not established correctly. Actual practitioner findings have included: • Redundant fields that are stored on separate databases are out-of-sync. causing data integrity issues across applications and across validation tables. • System-to-system control totals and balances do not reconcile. the expected maximum workloads must be tested in a production environment to ensure that the required performance criteria can be met. 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. In particular. In addition. Few systems operate in isolation. • Response times. • Run time. and • Expected data content and format of transaction data was not consistent across applications. • Poor design which does not allow proper system balancing to be completed or confirmed. 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 .

a formal confirmation of progress against the Project Charter is completed and plans are developed for the Final Preparation Stage.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology plan. include: • Change Integration. all started during the Project Preparation Stage and continue beyond the Realization Stage. and • Technology Planning. This initial tuning then forms part of the normal ongoing management and operation of the system after live production commences. it is ultimately the users' responsibility to complete the task and to gain the confidence that the system performs as expected. • Acceptance Testing. • User Documentation. Cross-Life Cycle Phases The Cross-Life Cycle Phases. Support and Cutover. • Training. in the Realization Checkpoint Phase. each of these Phases may have specific tasks and steps to be completed during the Realization Stage. Depending upon the specific project requirements. initial tuning of the system is completed to ensure that the system operates as effectively and efficiently as possible. Project Management Although project management activities are ongoing throughout the project life cycle. Page 267 . Initial System Tuning As part of the system and integration testing. • Prototyping.

and • Confirm the completeness and the quality of the programs and the program documentation before the transition to system testing. all module interfaces and inter-module relationships and the data content of parameters passed between modules. code and test programs for any custom system components in accordance with the Business Blueprint Stage specifications. The Program Structure Chart is an hierarchical representation of the modules in a program. Each program to be developed in a procedural language is documented as a Program Structure Chart. the development team will: • Design programs. • Verify that each program executes the functions as outlined in the associated program specifications including those pertaining to exception and/or error processing. and  all programs and components are fully unit tested.  access to all program/component logic paths and program module interfaces are working. algorithms) performed by a program module that cannot be succinctly described on a Program Structure Chart. 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.. • Design. that are structured. • Tool-generated code or components for data extract functions. tightly cohesive and minimally coupled. and • Ensure that:  all functions work according to program/component specifications. • Develop Unit Test Plans and unit test data under the guidance of a planned test strategy. before handing over to system testing. References to Detail Logic Charts are added to the final program Page 268 . In this phase. • Produce a complete set of executable programs and components that perform the procedures. Program modules follow a standard naming convention. 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.  program/component edit/validation logic successfully protects the integrity of each data element. • Produce a complete set of executable programs that perform all tasks necessary to support the application design. elementary processes and common routines necessary to support the application design.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. Complex actions may be described further using Detail Logic Charts that describe complex logical processes (e. which may vary with the development language.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. in appropriate development environments and languages. including Business Extractors. its basic control logic.g. Action Diagram notation may be used to create the Detail Logic Charts.

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

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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 P d P r o g r a m s p e 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 f r a m C o d e d p r o g r a m c o d e 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 g B u s i n e s s S c e n a r i o s E x e Q 7 c u t e S 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 g 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 .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 o n v e r t e d D P e 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 m e n t a t i o n C W P o 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 .

display/report) into the required "mainline" processing modules.1Prepare Program Structure Charts Purpose To decompose each program into independent program modules.g. update.1.445 Identify data access strategy. Include definitions of parameters for called subroutines.1. A. A. 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. A.. Define the data elements needed to access the record (e..444 Identify common logic modules and their interface requirements.446 Prepare Program Structure Charts of program modules. edit/validate.1. 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 . record processing logic and termination logic. Program Structure Charts are created by further decomposition of the Interaction Models created in the Business Blueprint Stage. keys). The Program Structure Chart should be defined to the level of detail such that decision logic associated with all program paths are clearly presented. Program functions are defined using a set of standard verbs. A. The framework of each program is constructed by decomposing each module contained within the Program Logic Specification prepared in the Business Blueprint Stage (e. Define data to be passed to and from the shared program modules (e.443 Identify mainline program modules. passed status codes). Identify those program modules representing sub-programs that may be accessed by several different program modules. Identify the techniques to be employed for data access.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. Identify all of the mainline program modules. This will require detail to the degree(s) described as follows: Page 271 .a high degree of module binding or cohesion can minimize the relationships between modules.it is desirable to have modules that are as loosely coupled as possible.g. and • Cohesion is the measure of the relationships among code structures contained in the same module . Overview Each program module should execute only one process since it should be constructed to have a single entry and a single exit. 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. This composite of program modules defines the program functions and the overall program structure.g..1. 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.17. These mainline program modules comprise the highest control level of the program and address initialization logic.

(i. data initialization and error processing). each DLC should fit on one page providing this does not contradict the rules of keeping modules highly cohesive. GET and PUT). CLOSE). As a general rule. respectively and decomposes the central transform into modules of manageable size while maintaining high cohesion and low coupling within the modules.g. EDIT. These rules are subject to change depending on the standards established earlier in the phase.e.. For instance. data set input and output. UPDATE. In general. The majority of the program specification will be contained in Detail Logic Charts.. execution of subroutines).. Address the definition as appropriate: • Database manipulation functions (e.1. OPEN.g. For COBOL programming. Subordinate functions (e.g. and Page 272 .e. A. • Table/string manipulation processes. data manipulation at the segment or record level. A.1. OPEN. • Data manipulation processes (e.e.. should be depicted using only the three constructs of structured programming: sequence. This final factoring of the Program Structure Chart takes the input and output modules to their external entry and exit points. VALIDATE and COMPUTE). specify the lower level modules to be invoked and specify under which conditions this takes place. Called program interfaces (i..THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology • • • • Major function (e. the definition of all control levels). the start of each program path). A. in a Program Structure Chart: • Input modules should break down into input and transform modules. Review the Program Structure Chart using the concepts of coupling and cohesion to improve the structure of the program. Select program modules that would be better decomposed as Detail Logic Charts (DLC). The control levels should depict all program linkages.448 Select program modules within Program Structure Charts that require Detail Logic Charts for further definition. if programming in C. The selection of appropriate program modules to decompose as DLCs will vary with the standards established for a particular language. including the lower level modules. CLOSE. subroutine) to support any DLCs that will exceed one page.. sufficient to identify the functions to be programmed.g. 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. PROCESS. SORT. and • Transform modules should break down only into smaller transform modules.. • Output modules should break down into output and transform modules.449 Refine Program Structure Chart.447 Decompose program modules. selection and iteration.g. Each of the program modules. the Program Structure Charts should be kept at a high level. Use the action diagram decomposition notation (i. and • Conditional logic processes.. All process related specifications should depict the possible program pathing decisions. 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 Execution sequence of the modules (e.1. FORMAT. The inter-module interface indicates the data to be passed and/or the parameters. Take care not to decompose too far in the Structure Chart format.

• Process while .depicts a single operation or statement. These Detail Logic Charts provide a diagram of the detailed processing logic required within a program module.depicts an iterative process preceded by a decision. A. The intent is to have a module with high cohesion and groups of modules to have loose coupling. • Decision .THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology • Cohesion is the measure of the relationships among code structures contained in the same module. the degree of cohesion is enhanced.depicts a group of operations and decisions to be executed in sequence and defined in a separate Detail Logic Chart. for selected program modules. • Decomposition .1. Page 273 . and • Process until . Where a module is limited to dealing with one data entity. Prepare a Detail Logic Chart for each selected program module. as required.depicts a choice to be made and the alternative logic paths that may be taken.450 Prepare Detail Logic Charts.depicts an iterative process followed by a decision. They normally include a series comprised of the following program logic structures: • Operation .

input specifications. • Prepare the source code from the generator and the custom-produced code for unit testing. 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.17. 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. store and document program specification contents. report formatting and edits and validations. whereas others require it. References to Detail Logic Charts are added to the design as part of finalizing the program specifications.  Program Logic Specifications.  System Messages. The work steps are based upon the use of a modified program specification that consists of three categories of components . processing specifications and output specifications.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. transaction processing. as they will be used to develop customized program code rather than being generated.  Process Descriptions. • Generate the program code. each component will consist of: • Input record definitions • Output record definitions • Processing specifications:  Structure Charts. Overview The objectives of this task are to: • Employ the program generator in an efficient and effective manner. and • Use the available facilities of the generator to capture. and  Detail Logic Charts.  Edit/Validation Specifications. Typically. 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. 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. Page 274 . The input.  Table Definitions. or • An automated interface exists between the automated tool used and a program generator. • Select the functions of a program that will be produced via custom coding and the functions that will be generated.2Prepare Program Generation Specifications Purpose To prepare program specifications in the appropriate format for all programs that are to use a program generator. • Provide a set of program documentation in accordance with defined standards. • Modify the program specifications for submission to the program generator.

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

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology Identify and define tables to be used in each program. Develop this logic according to the rules for the appropriate program development path. 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. Establish table numbers/names and confirm adherence to standards. Page 276 .

17. as required. 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. Page 277 .1. Adherence to standards and conventions as well as structured design techniques should be monitored.455 Ensure that the program specifications deliverable is complete. Review and cross-reference the program specifications against the Program Control Checklist. subjected to a structured walk-through and finally approved. This process enables the project team to identify and resolve any discrepancies.457 Obtain team leader or equivalent approval of the program specifications. testing and maintenance activities. For each program. Conduct a structured walk-through of the program specifications. A. reviewed.1. The issue resolution process provides a formal reporting mechanism for documenting and resolving major decisions/problems. a program specification is assembled. Other necessary documentation not produced by the development tool may need to be developed or modified from documentation developed during the Business Blueprint Stage.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. A. omissions and logic errors. Changes to program specifications should be documented and approved using the System Change Request form.1. Document and resolve issue resolutions.456 Conduct structured walk-through of the program specifications. cross-referenced against the Program Control Checklist. A.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.

A. Resolve all syntax and diagnostic program errors. 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.. Code all input/output program 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.1. where reusable modules and programs are the first to be created so they may be prepared for general access in a protected library. A.459 Code programs and/or modules not generated. The program module should always execute the same function and not execute different functions dependent on the setting of an internal flag.1. e. Overview All programs are coded from the final program specifications using established language-specific program coding standards and conventions. If syntax errors are found. Code programs in accordance with standard structured programming techniques. they would include the stored procedures and the API library(ies) accessed by remote procedure calls (RPCs). • Will be reflected in the structure of the program.1. support and/or utility programs and modules. The result will either be program code (from a parametric code generator. 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.460 Generate program code using the development tool. Code all shared.461 Resolve all syntax and diagnostic program compile errors.1. A. naming conventions and program specifications. 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. they need to be corrected and the program code generated again until no errors are found. This is an iterative step. Each program module should ideally consist of one function that has one entry point and one exit point.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. Because all program specifications to this point have addressed logical data entities. Page 278 . Execute the program generation software.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. and • Will be needed wherever the same data is accessed. In a client/server environment.g.458 Code input/output program modules. A.17. common. Coding proceeds in a "bottom-up" fashion. TELON) or a ready-to-run program (using 4GLs such as PowerBuilder).

Ensure that the coding adheres to the previously defined program coding standards and conventions. copy and restore. • Back-up. A. Changes to program specifications must be documented and approved through the System Change Request process.1.463 Verify command language and utility execution.g.462 Code command language and utility parameters.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology All program code should comply with the program specifications.1. The program code is then recompiled until no syntax or diagnostic errors are found. as well as structured programming techniques and any exceptions should be justified in the documentation for the module or program. Page 279 .1. Ensure that all of the program documentation is complete using the Program Control Checklist..464 Complete all program documentation. A. Code any command language and utility parameters including: • Command language (e. or • Sorts. Enforce adherence to approved program coding standards and naming conventions. A. JCL). Compile the program code and command language code and identify and correct any syntax and diagnostic errors.

Overview Each program is submitted to a structured walk-through and approval process to ensure that only standardized code is produced. Add any missing items. A. as well as structured programming techniques. should be stressed for custom-coded modules. A. deviations from prescribed specifications and the proper adherence to established program coding standards and naming conventions. It is essential that all program specification change requests be adequately researched to determine any possible side effects.467 Conduct a structured walk-through of the clean-compiled program code. A. Program specification changes are documented and approved and the program code is submitted to the project team leader for formal written approval.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.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. All programs should comply with the set of program specifications produced during program design. Page 280 .1. Review and cross-reference the documentation against the Program Control Checklist. Any modification of program specifications can potentially impact other programs that access the same data. the complexity of the processing and the skill and experience of the programmer(s).1. Document any changes to program specifications that may be required to achieve the desired system processing. 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. Conduct a structured walk-through of the clean-compiled program code.17.466 Document any required changes to the program specifications. Adherence to approved program coding standards and conventions.1. All program specification change requests must be fully documented and approved through the System Change Request process.465 Ensure that program documentation is complete.1. Correct any errors and omissions identified and recompile the program code. A.468 Submit program code and System Change Requests to the project team leader and obtain formal written approval. All program code should comply with the program specifications.

lowerlevel modules will be added to the current set of test modules and tested with the appropriate test data or scripts.g. In a bottom-up unit test strategy.1.469 Develop unit test plans. Note: In accordance with the design techniques. A unit may consist of a menu program and a related program or it may consist of a single program. Special utility steps to facilitate review and verification of unit test results may be included as needed. a unit should be identified as corresponding to one program. the successfully tested program will be moved into the system test library. displays. Changes to the command language instructions may be necessary to execute specific modules at the appropriate times. All conditions. All test steps and/or data files required to complete the unit tests are created in this task. If necessary. A. To some extent.  edit/validation logic within the program including table look-ups. test step(s) and test data scripts or data file(s) to be prepared including expected results.6Develop/Execute Unit Test Purpose To complete unit testing of the program code.  program logic paths including loop control.g. define specific test objective(s) to determine the test condition(s). Actual results are reconciled with the expected results and all program logic errors are corrected. • Define unit test objective(s). The unit to be tested can be a CALLed program module or any processing module that has testable stimulus and response characteristics. Successfully conducted Unit Test Plans are reviewed by the team leader. this will depend on whether the changes made are modifications to existing programs or the addition/deletion of programs. The structured walk-through process is used to ensure that a complete set of conditions and steps has been defined. stored procedure or a logical subset of objects (e. Final test results are attached to the Unit Test Plan for each test condition/step.. A test data generator can be used to prepare the unit test data. The expected results are derived from the program specifications to ensure that the program performs as specified. required unit test data and expected results of each test step are defined. command language instructions are prepared for each program.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. The recommended approach is to develop ONE common set of test data to be used in all of the various test steps. Hard copies of unit test transactions are attached to each Unit Test Plan. The plans are reviewed and approved by the team leader before execution. For each Unit Test Plan. a unit will relate to a single window.a table window) on a single window. reports. If a top-down unit test strategy has been adopted. The test steps and data files are made up of multiple transactions with variations of data. exception and/or error processing.. Definition of the unit boundaries helps to ensure that all program modules are tested. error messages). both valid and invalid. • Establish test conditions to address the verification of:  output conditions (e. updates. Examples of invalid data are included to test edit/validation and error management routines. Overview A Unit Test Plan is developed for each program. Basically. Develop unit test plans: • Define the unit that is to be tested. Specify the program boundaries.17. All unit tests are conducted until each test has been successfully completed. Page 281 . steps to be executed to test each condition.

For each test condition. Unit test steps are required to create the appropriate settings for the test condition to be effectively tested. Update Unit Test Plans as needed with changes resulting from the structured walkthrough. 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. e. and • Conduct a structured walk-through of the Unit Test Plans by comparing them with the program specifications (not the source code). define sets of data required to execute the test conditions. • Define individual unit test steps for each test condition. They will occasionally require data to be available that is referenced rather than directly used by the test condition. reading of specified input files. • Define the expected results of each test step.1. production of specified output files. use of "called" modules. module to module interfaces within the program.470 Generate unit test data. control and security conditions. Add test steps for successive modules until all components of each program path (series of modules) have been tested. Include:  output to be generated (screen.          • Where appropriate. and utilities. 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. Wherever possible.  status of applicable data file values upon completion. testing for invalid data entry should include Test Data Specifications for different invalid values and for various combinations of invalid data. command language instructions for the program.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology error management routines.g. processing algorithms. A correct Unit Test Plan is one that addresses all processing contained within the program specification. Expand the test conditions to form the test steps.. and  unique sets of data element values. multiple Test Data Specifications should be defined for each test condition. 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. The test steps represent the different program paths that may be executed to accomplish the same overall test condition. Generate unit test data: Page 282 . Obtain project team leader formal written approval of Unit Test Plans.  unique program paths to be executed. A. data file and report). Progress to more complex conditions. Identify:  data record(s) and/or screen(s)/window(s) to be constructed to test the condition. include a member of the System Test Team in the Unit Test Plan walkthrough. and  status of control totals upon completion.  status of interim data element values.  key data element value(s). Begin at the module level and define unit test steps for simple test conditions.

Typically.472 Establish unit test environment. conditions and steps. interface data files will be created by the higher-level module. A stubbed module is used to substitute for a lower-level module that is not ready to be tested. 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. and • During the course of testing. A. • Identify and code any utility step instructions to assist in confirming that the tests have been successfully executed or to assist in debugging. This step should be executed or supervised by the Database Administrator to ensure that database integrity is maintained. it will include an entry point and an exit point and may set-up a return value(s). For on-line processing. Test data transactions should be sufficient in detail and number to satisfy all test objectives. valid data should be tested first. When testing called modules this way. utility steps will aid in analyzing the execution of the test conditions. to return properly from "stubbed" modules. • Provide external storage space to store the current and/or previous unit test version of each executable program. Command language instructions must also be coded for loading data files and interface data files in the proper sequence. where applicable.1. • Ensure that a hard copy of the unit test data is produced and attached to each applicable Unit Test Plan. • Generate module interface test data. Allocate enough space to permit multiple generations of unit test data to be stored. Module interface test data is required to test a "called" module before integrating it with the "calling" module in a bottom-up testing strategy. • Provide physical space to store the unit test data files. it may be necessary to generate separate interface data files. interpreting data file dumps. additional test data and conditions may be required. • 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. Test steps and data files may be created directly from the Unit Test Plan if the test conditions and steps are defined clearly. The documentation required consists of screen/window printouts or data file dumps of the actual data used. Regardless of whether a topdown or bottom-up unit testing strategy has been adopted. To facilitate this update process. A. executing sort/merge functions and creating/deleting data file catalogue entries. followed by exception conditions.471 Prepare unit test job steps. In general. When a top-down strategy is employed. Physical data files containing the records required to meet the unit test steps are created. Utilities are desirable for reviewing or comparing updated files. where appropriate. unit test data is a predefined series of screens/windows. Page 283 .1.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology • Generate the unit test steps and data files. For both on-line and batch processing. it will be necessary to prepare the computer environment to accept the program being tested and. Prepare unit test job steps: • Change or code required command language instructions. and • Review command language instructions for errors. the means to control the maintenance and distribution of the common test data set must be established and agreed.

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. If not already specified. Analyst and/or team leader approval is required before the change is made. • Document program specification changes. • Restrict access to unit test libraries and test data to the responsible developer and/or project team leader. and • Tools exist for the generation of test data. logging and correcting program errors should be controlled through the Test Problem Reporting (TPR) process. test conditions. Support and Cutover. Test results should indicate the submission and completion of the unit tests with the date and name of the person conducting the test.473 Execute unit tests.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology The definition and development of a testing environment should have been initiated in the Technology Planning.. If a separate Unit Test Team has been identified. Attach interim screen/window prints as appropriate to confirm the success of specific unit tests as deemed necessary by the project manager.g. • Complete the Program Control Checklist by including Unit Test Plan and output listings as appropriate. if the programmer is responsible for unit testing. a scope change or a policy change). A..1. and • The documentation from the completed and approved unit test is annotated and filed as part of the unit test documentation. • Correct all outstanding errors.. During the test.g. test objectives. This will ensure that multiple programs are referencing the same items. Automated testing tools may be employed during re-test. this degree of formality may not be required. the issues resolution process should be used. Attach a hard copy of final unit test results annotated with the test step reference from the Unit Test Plan. • Document both deviations from the expected results and successfully completed test conditions.e. hardware. • Submit program documentation with unit test results to the team leader and obtain formal written approval. configuration management) should have been defined and implemented for the environment. Ensure adequate back-up and restore procedures are in place. unit test Page 284 . document the resolutions and conduct the appropriate unit test(s) again. the repetition of regression tests and the emulation of concurrent on-line sessions. Execute unit tests: • Complete the unit tests following the Unit Test Plans. This should include the full Unit Test Plan (i. automated tools specified earlier may be employed. At that time. which is documented on a System Change Request. However. Carefully examine the impact of these side effects before recommending the program specification change. Load source programs and copybooks into the library and include record and/or segment descriptions and common processing routines. Testing may reveal errors or omissions in program specifications. test data files and expected results). Changes to specifications may produce side effects outside of the current program/module. 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. test steps. • Where program changes have a wider impact (e. software and operational requirements (e.

Magnetic media versions of these items should be maintained in a secure environment. Page 285 .THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology results and unit test logs.

Identify all internal interface standards and check that they have been adhered to rigorously. and • Call syntax. • Rules for call by value and by name. Any interface not within standards should be documented as a failed test and be returned for redevelopment. A. String testing checks for compliance with the program specification and the intended design structure. Overview String testing is an extension of unit testing that tests the linkages between structurally connected units and is completed at several levels. string testing attempts to identify errors caused by linking the units and in the interfaces themselves.1. A. Specify test conditions to be developed to satisfy the test objectives and list the job steps to be followed in creating the test conditions.476 Conduct string tests.475 Develop Test Plan for string tests. • Linked programs of a functional sub-system. testing can be completed by a dedicated tester. and • Linked sub-systems of a complete system. program level testing must be complete before sub-system level testing can be completed.1.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.1. at what point calling or called. • The order of objects by type within a call.474 Check interface standards. Testing on the appropriate technology platforms will be completed during. Standards should exist that determine the rules for interfaces between the components of a functional group. • Indirect reference calls.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. Document the test data needed to exercise the test conditions and indicate where "stub" programs are to be used to test the string. Unit testing must be complete for each module of a program before the program level string testing can be completed.17. • Validation. These standards should include: • Those that are implicit in database and calling sequence. • Format of the calling element. Once each component of a program has been fully unit tested. A. which includes testing: • Linked modules of a program. Execute and log the string tests using one or a combination of: Page 286 . and so on. 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. As several programmers may be involved in the construction of various units of the string.

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

1. As a final step. A. updated. where necessary. a migration plan to the system test environment is completed to prepare for the System and Integration Testing Phase. Overview This task provides a formal program hand over checkpoint. Review the Unit Test Plans and the expected results to confirm that all of the tests have been executed successfully and verified. 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.1. Ensure that test utilities have been removed. Review the program specifications for all programs and confirm that all of the supporting documentation has been provided and is complete. A. Edit/Validation Specifications. • Recording the software configuration components of the unit test environment • Migrating the unit tested programs to the system test environment.484 Review program documentation. Check specifically for Unit Test Plans and expected results.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.1. Report Definitions. Confirm that all of the necessary program documentation has been provided including any job control statements and library management documentation. Confirm that all string tests have been successfully executed. Program Structure Charts and program code. 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.1.1. Check for such items as Program Logic Specifications.485 Develop unit to system testing migration plan. A. Review all programs. A. System Messages. unit test data and system change requests. Page 288 .8Develop Unit to System Test Migration Plan Purpose To execute a quantitative and qualitative check on the unit test deliverables.481 Validate program specifications. A. to ensure completeness and compatibility with standards and to develop a plan for the controlled transition from a unit to a system test environment. Review for completeness and accuracy.483 Validate unit and string test results.482 Conduct quality review of the program specifications. Ensure that all of the documentation needed to re-create the tests has been retained in a secure form. as appropriate and confirm consistency of style and programming practices as well as compliance with standards for coding and quality control. Use the Program Control Checklist as a means of checking that all documentation has been completed and approved.17.

487 Obtain formal written sign-off from the System Test Manager that the migration has been successful.1. A. Establishing a software configuration system test baseline. Testing the results of migration programs before the start of the system tests to ensure that the migrated data is correct.1. 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. and Confirming that the responsibilities of the System Test Team and the Project Team for system and integration testing are clearly defined and understood. Follow the procedures outlined in the previous step and record any problems using the issue resolution process.486 Conduct unit to system test migration. A.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology • • • • Recovering the transferred programs to a stable base in the event of problems during the migration process. Page 289 .

depending upon which technique or mixture of techniques is being used to create the master file and opening balance data. If an external service bureau is to create the data. very complex programs. This is particularly significant if there is a large amount of data to be created using this means.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. A. detailed instructions. training must be given in the use of these features.489 Key the data to be created in-house or through an external service bureau.1. If programs need to be written. error checking and timing should be finalized. Overview The data conversion system design is reviewed and. • Code the data conversion programs using the structured coding techniques described in earlier tasks in this phase.1.488 Allocate work tasks and responsibilities. the conversion programs or methods are constructed.17. If custom programs are to be written.1. A. these programs may be created using a program generator or file utility.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.1.491 Design and create custom data conversion programs. they are written and tested. data input operators have the appropriate training and the necessary hardware is available and functioning correctly. 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. The degree of effort required for these programs should not be underestimated as the conversion sub-system may contain numerous. Depending on which methods of conversion are being used. media.490 Use computer software bulk or mass maintenance routines. the different detailed work tasks will vary. Alternatively. and Page 290 . The various work tasks are allocated to the project team members together with the responsibilities for management of the process. then the following steps should be completed: • Design the data conversion programs using the programming techniques described in earlier tasks in this phase. If program routines or utilities exist that enable mass creation and replication of data. Conversion input data must be closely aligned with the format required of historical data sources identified and constructed in those tasks. If data is to be keyed using the new system's standard input routines. A. delivery and receipt of data. A. The data conversion task interfaces with BW Administrator’s Workbench construction tasks. the contractual issues. ensure that any batch input needs are met.

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

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

17.e. Any adjustments.. if there is no existing system.502 Prepare for data conversion execution. Corrections. resulting from the cleansing should be completed and properly authorized. a week may be scheduled for entry of data. e. The steps will also vary if there is parallel running or a staged or phased implementation.504 Execute data conversion. Complete the acceptance testing according to the defined data conversion acceptance criteria. A. and • The conversion process has sole access to the information during execution. 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. 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). internal audit).g. Prepare documentation and audit trails of the actual conversion process and ensure that the conversion results are properly checked by the appropriate resource (e.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. deletions and additions should be made to the conversion data. Generally. The creation or storage of the appropriate historical data is included as part of this conversion process. A. The entire data conversion execution may be a multi-step operation completed over a length of time (i.503 Finalize conversion data cleansing. Complete the data cleansing procedures of the source conversion data.1. Prepare for data conversion execution. create the new data to initialize the DW system.1. 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.g. 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. Page 293 . This impact must be assessed as part of the preparation process.1.10 Execute Data Conversion Purpose To convert data from the current system to the new system format or. To enable early commencement of data creation because of the volume of records or the extended duration necessary. the database or master files need to be created as input to the system testing process. write-offs. Create additional data as necessary and execute the data conversion programs and procedures according to the Data Conversion Plan. the data creation of the master files in a skeletal format may begin well before the system acceptance testing and commencement of live processing..

506 Retain source data. A. If parallel running is to take place.1. Maintain copies of the signed-off and authorized balancing procedures.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. ensure that the old system data is maintained along with the new data to allow periodic comparisons between the old and new systems. Ensure that the reconciliation process is clearly documented and supporting information for each reconciliation item is prepared and maintained. documents and supporting detail and ensure that these working papers for the actual system balancing are archived in a secure location.1. Agree on the length of time with management for which the data should be retained. 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. as they may need to be referred to at a later date for a variety of reasons such as the annual audit. After the conversion and reconciliation of data has taken place. Page 294 .507 Sign-off on converted data and file conversion reconciliation worksheets.1. Reconcile the results of the conversion execution with the original source data. reconciliation of the results of some conversion processes may be completed before execution of other processes. Enter details on a data conversion reconciliation worksheet. progressive reconciliations should be completed together with an overall reconciliation when all areas are implemented.505 Reconcile converted data with existing data. As mentioned above. 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. If a staged or phased implementation is to occur. 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. Appropriate formal written approvals must be obtained that the reconciliation has been properly completed.

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. In addition. Global Configuration settings are finalized. Overview The BW components will be constructed and tested. Page 295 .18 BW Administrator’s Workbench Construction Purpose To construct the Business Information Warehouse system based on the Business Blueprint design specifications.

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology BW Administrator’s Workbench Construction Task Relationships I n s t a l l e d B W 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 u rP c r e e p a r e d s o u r c e s y s t e m s D a t a T r a n s f o r m a t i o n 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 e D a t a D e s i g n R C r e a 3 t e I n f o C I n f o C u b e s uA b g e g s r e g a t e s D a t a T r a n s f o r m a t i o n 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 S o u r c e C o m m u n i c a t i o n S D a t a T r a n s f o r m a t i o n 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 A r e a ( P S D a t a T r a n s f o r m a t i o n 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 a t e r u l e s S I n R 7 c h e d u l e f o P a c k a g e I n s f o P a c k a g e s / G r o u p s Page 296 .

Once the connection is established data can begin to migrate between the two systems.Program RMCSBIWC  CO-PA . that may not always necessary. In this step we are referring to the source system preparation of data. 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. Once the ALE connection is established between the source system (R/3. Each of the standard InfoSources has assigned extraction tables and programs within the source system.Custom developed extraction Programs  Informatica .18.R/3 or non-R/3 sources and the BW server. which will be loaded to the BW system. Depending on the extraction application steps involved. there are sometimes different types of setup and configuration activities.Custom developed extraction Programs Page 297 .1Prepare Source Systems The purpose of this task is to maintain the proper BW environment after the BW installation has taken place. 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 . Because the BW is fed externally the task involved with the Production System Environment is done in two systems . To make the extraction functionality active certain configuration steps must be executed. An InfoSource is derived by incorporating several different components.Program RKEBIW01 • For some applications 3rd Party OLTP extraction utility programs will be used to prepare and extract data for the BW environment  ETI . preparation of the InfoSources in source system is necessary for some applications. The following section will outline the necessary steps for establishing the connection and data migration. Non-R/3 or BW systems). Before the design and build stage of the implementation can begin the connection between the R/3 and BW system must be established.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. An InfoSource is used to supply the BW with data from an OLTP R/3 System or Non-R/3 System.

0A onwards or external systems. • 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. The name of the RFC destination must correspond to the logical system field in the table T000. Profit Center Accounting. S012.  Maintain logical system. In another example: Accounts Receivable.  Save your entries.  Enter the communication parameters (IP address). by using the name of the RFC destination that you created in the prior steps. In addition. in order to verify the workflow of the run time. For example. These can be either SAP BW systems from Release 2.  Assign logical system to the client. by using the name of the RFC destination that you created before. A. Accounts Payable.  Select the client and maintain the logical system. S013 and S015 should be maintained using RMCSBIWC. and Cost Center Accounting InfoSources do not require additional configuration. Please read Creating Remote-Function-Call-Destination Parameters for more information. Page 298 .THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.  Undertake workflow basic settings.  Select the function Automatic customizing.1.509 Implement Using Standard Delivery Purpose In this section the standard delivered InfoSources should be maintained. Setup for several of these objects is required in the R/3 or Source System environment.  Set up ALE users. After the BW installation on the (R/3 or Source System) server several new objects will exist. which provide the Business Information Warehouse with data. If this step has been successfully concluded then the traffic light should be at least yellow. 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.1. 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. the purchasing module’s InfoSources for S011.  Identify your system.  Test the RFC destination with the corresponding function.508 Confirm RFC Destination and Basic ALE Settings Purpose Source systems are all systems. If this is not the case then you have to install both APIs on the BW system using the Business Information CD. 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. in the Sales and Distribution module the InfoSources for S001-S006 and S260S263 should be maintained using program RMCSBIWC.

Using program RKEBIW01. the Operating Concern data will appear as an InfoSource in the BW. These structures are known as Operating Concerns.512 Implement Using Flat File Structures Purpose Data can be transferred to the Business Warehouse using flat files (sequential files). Using the utility program RMCSBIWC the proper BW environment can be installed for any self-defined information structure. and hierarchies.1. These are not considered to be standard SAP InfoSources. any Operating Concerns can be configured within the program to migrate data to the BW system.1. but still can migrate data to the BW if the proper configuration steps are executed.510 Implement Using LIS Structures Purpose Often SAP customers are concerned about the data migration for self-defined InfoStructures in LIS. To migrate data the InfoSources communication structure and transfer rules should be maintained. many SAP customers have developed their own reporting structures in the COPA module. A. A. 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. 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.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.511 Implement Using COPA Structures Purpose In addition to LIS. Flat files are useful for loading external transactional data.1. master data. Page 299 .

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. for external systems. an MS excel format) Page 300 . transactional data.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology The following section explains how flat files can be uploaded. The determination of the data type (Meta Data or data) is important in the global InfoSource. • • • • • • Create the application components for the source system file Decide what type of flat file is being loaded. i.e. The Business Warehouse can process the following formats: • Fixed data record length • Variable data record length • CSV format (colon separated variables. You can fall back on various formats. Steps • • Review the documents on Flat File Uploads Define the source system in the BW Admin Workbench Flat files are considered source systems. Prerequisites: The data must be in the given format of the current valid transfer structure for the transfer from files. which are displayed as ASCII flat file. The scheduler falls back on these formats with an external data request.

the meta data update will capture the necessary information to be updated in the BW. text relationships. • Use of the BAPI interface with a third party tool (external system). Prerequisites Before the meta data refresh is executed. Steps • • Review what InfoSources are contained in the BW Decide the frequency of how often the meta data refresh should be done A.513 Maintain Meta data on InfoObjects Purpose Each InfoObject is stored in the BW’s InfoObject Catalog.1. • The manual maintenance allows you to insert and delete fields for the local InfoSource and to change the length of fields. Here.18. For example field lengths. For example. the local InfoSource belonging to the source system requests meta data. the InfoSource must be properly maintained in the source system. • Going from the InfoSource catalog. 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. 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.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. If a field definition changes.2Change/Update Meta Data Purpose Meta data is often referred to as "Data about Data". navigation and reporting attributes can be influenced by the maintenance of meta data. Page 301 . 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. the table storage for all valid values can be updated into the BW via the Change/Update meta data feature. technical aspects like the field length. in the source system or a new field is assigned to an InfoSource for data migration. For each of the InfoObjects (field elements) in the BW there is underlying information that can be of a technical or business nature. which is a repository of meta data. • The BAPI interface offers the same functionality as the manual maintenance and is subject to the same restrictions. This type of information can be defined as meta data. This is a special case of the use of the BAPI interface of the Business Information Warehouse. master data attributes. • Use of the BAPI interface for manipulating the meta data in the Business Warehouse (external system). The system automatically integrates the newly created fields in the global InfoSource. text descriptions. • Manual maintenance of the meta data using the path Administrator workbench -> InfoSources.

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 BW’s 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 BW’s 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 BW’s 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 BW’s 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

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology

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

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology

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-user’s 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

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology

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 BW’s Administration Workbench.

Page 306

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology

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 BW’s 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 API’s 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 Data Load Monitor and the Data Access Monitor to control and supervise the ongoing operation of BW.527 Implement Logic for Transfer Rules The Staging Engine is employed to implement data mapping and transformation. When staging transactional it is important to implement a strategy that clearly outlines the business rules utilized when the data is being transformed.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 data’s integrality ensuring that all transformations worked Compare the queries results to the expected results A.g. Once the source and target structures and mapping rules are set up. master data and hierarchies all can be "staged" within the BW’s staging engine. 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 data’s InfoSource Page 309 .526 Develop Transfer Schedule Purpose BW ensures the consistency of the load process. it is important to define what data should be extracted from the source. once daily). Transactional data.1. This is especially important if the transactional data is fed from multiple systems. The transmission of the extract data is performed in an asynchronous fashion. The frequency of the data extracts for transactional data.1. at the same or independent times. giving the administrator the flexibility to run the multiple different tasks for building the extract. which typically run at recurrent time intervals (e. master data and hierarchies should coincide with the business’s need for data. 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. In addition. transferring it to BW and updating the InfoCubes. the administrator uses the Scheduler. The Scheduler maintains extract and load jobs. 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.

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 .

This includes maintain the transfer structure. • The InfoSource maintenance must have been successfully completed. Tips Successful maintenance of communication structures of the target InfoSources must be completed prior create InfoCube update rules. Data definition. 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 . System generated data transfer ABAP module with direct data mapping for InfoObjects. data condensing and data transformation logic from InfoSources to an InfoCube Prerequisites • Completion of InfoCube definition.1. ABAP routines consist of the logic to transform data from communication structure to the InfoCube.18. SAP and non-SAP Data mapping documents.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. A.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.6Create/Maintain Update Rules Purpose The purpose of this activity is to define the data mapping. Input • • • Result • • • Established the connection between InfoSources and the InfoCube. The communication structure of the target InfoSources must have been maintained. characteristics and the time characteristics. communication structure and transfer rules in Administrator Workbench.

A. 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.1.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. 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. Page 312 .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. Meta data upload to the InfoCube is ready to proceed.

R/3 and Non-R/3 Data Mapping Documents.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.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.7Schedule InfoPackages Purpose The purpose of this activity is to create InfoPackages to request data (transaction data. High-level Transformation Design. Outcome InfoCubes connected to the InfoSources and the defined Source systems will be updated according to the selection parameters. 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 . Data Selection parameters for each InfoObject and/or the whole package.18. attributes or hierarchies) from a source system according to the selection parameters.1. InfoSources and Source system names. IDOC will be created. Prerequisites • Input • • • • Result • • A new InfoPackage or InfoPackage variant will be created and scheduled. A. Upon completion of InfoCube and Update Rule creation. master data. either immediately or through batch process.

In addition. via the BW workbench tool using the formula editor or ABAP routine and the InfoPackage batch Job scheduling functions.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 the Data Refresh frequency document Review High-level Transformation Design document to determine the job dependencies Reference to BW online documentation.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.533 Develop Rules with Formula Editor or ABAP Routine Purpose The purpose of this task is to develop batch transformation rules and routines. Make sure to review all of the existing batch interfaces in the R/3 system.1. you should consider Job processing performance issues. 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. Scheduling InfoPackages for the step by step procedures Result • • Data transfer IDOC will be created along with Info IDOCs. you should make sure documentation has been created for all of your development activities.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. Be aware that the process of creating and later testing of the interface programs will very likely consume a significant amount of time. A. During development. before you start development.1. The selected InfoCubes will be populated with data in dimension tables and Fact table from the InfoSources of the source systems. Page 314 .

An integration on database level could be also considered. BI uses a common data structure BDC_DATA defined in the SAP data dictionary for holding the instructions and data for SAP transactions. Such a Job session stores the actions that are required to enter data using normal SAP transactions. 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. BDC_INSERT and BDC_CLOSE to generate Job sessions. 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.g. This method uses the function modules BDC_OPEN. • Call Transaction In the CT processing method. Batch interfaces should be integrated into R/3 on the application server level NOT via front-ends. namely file access and program-to-program communication. etc. Thus the focus in this task will be on SAP adopted techniques. "Call Transaction". the entire batch-input process takes Page 315 . IDOC interfaces can be configured to send and receive IDOCs in bulks. These methods are "Batch Input". but is highly dependent on the database system and the techniques provided by the database vendor (e. collecting IDOCs before sending and processing. When the program has finished generating the Job session. 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".THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology In addition. "Direct Input". Steps • • • Review Data Flow document to determine the Job dependencies/sequences Reference to BW online documentation. an online data transfer is probably not the first choice for this kind of transformation rule interface. OBDB. Batch-input data does not have to be deposited in a Job session for later processing. Procedure From the basic methods of data transformation and transfer with R/3 systems and Non-R/3 systems.e. thus forming a batch interface. Embedded SQL.). you can run the session to execute the SAP transactions for posting. i. But because of the nature of asynchronous data processing in batch interfaces and the development effort needed for program-to-program communication. Instead. both are suited for batch interfaces and transformation rules discussed in this section. 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. a program uses the ABAP CALL TRANSACTION USING statement to post the transformed and transferred data. it is important to consider what sequence the batch InfoPackages and interface programs will be running.

and check BW master data values for accuracy The test plan must ensure that data is correct and imported into the BW System A. and to develop a conceptual design. R/3 system extraction programs or Non-R/3 extraction programs from ETI or Informatica. In contrast to batch input. Page 316 .535 Develop Transfer Procedure Purpose The purpose of this task is to develop data transfer procedures. To do this the SAP system calls a number of function modules provided by the applications out of several reports. transformation and transfer process have completed. Successful import of customizing settings and R/3 Repository objects is a prerequisite of the data transformation and transfer process. However. 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. you should test all related business processes. In case of errors DI provides a restart mechanism. Use a separate client in your QA environment for testing your data extraction Jobs and programs. These function modules are carrying out the necessary business transformation rule checks. The R/3 and BW systems provide tools for data transportation.e. Transformation BW Programs and Procedures A. etc. to be able to activate the restart mechanism. which may involve exporting the transport settings in the R/3 Repository and QA environment to the production environment. • BAPI and IDOC Interfaces These techniques and their pros/cons are already discussed in the online section of this task. DI programs must be executed in background.) User departments must be involved in testing to ensure data integrity. and completeness.1. Result Batch interface InfoPackages. Another purpose of this task is to identify all data transfer requirements.1. accuracy. It stores the data read from a flat file directly into the SAP application tables.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology place inline in the program. this technique does not create Job sessions nor does it process screens. and you need to identify both manual and automated transfer procedures. Especially they could be also used in the context of batch interfaces.. Data from existing legacy systems may also be required to be transferred into the BW system. • Direct Input This technique is an enhancement of the batch-input procedures.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.

536 Monitor Log Files from InfoPackage Purpose The purpose of this activity is to monitor and review the result of the InfoPackage execution. Prerequisites • • Input • • BW monitor status display screen. take corrective action based on the status and information provided by the log file.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. Data Flow Diagram for end-to-end process  Expected Quality of Data  Expected Complexity of Data  Expected Time and Cost Estimate A. Page 317 . Post InfoPackage scheduling. • • • • 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. Upon receiving "Data Request executed" message on the message line.1. Refer to BW Online document: Monitor for detailed screen presentation and procedures.

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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 A u t h o r i z a t i o n D e s i g I nm A u t h O r M b a j e c t s s t e r V a 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 d a u t h o r i z a t i o n p r o f i l e s a P r e s e n t a t i o n S 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 .

Therefore. generating profiles.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. A.1. The authorization administrator configures company-specific settings. or choose them from templates manually. and testing authorizations. including selecting the relevant authorization objects. The Profile Generator uses defined activity groups to determine the affected authorization objects. authorizations generated for activity groups use data supplied by SAP.537 Create Activity Groups Purpose The purpose of this task is to create activity groups. This task includes creating activity groups. reports selected from the company menu) used by the Profile Generator to generate an authorization profile. Procedure • • • Provide basic information to identify the activity group.1. Select the reports and transactions from the R/3 Company Menu to include in the activity group. The Profile Generator does all other tasks. but is recommended if you use SAP Workflow. The Profile Generator identifies the organizational levels that have a role in the extracted authorization objects. In some cases you can insert authorizations. you need to understand the authorization components in BW. and displays them for the administrator.19. This task is mandatory. you can use the Profile Generator to generate an authorization profile. To simplify the creation of authorization profiles. 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. This task is not mandatory. Choose the tasks to include in the activity group.538 Generate Authorization Profiles Purpose To generate an authorization profile. Activity Groups contain data (transactions. but is recommended (95% of the time). When you have defined an activity group. Page 319 .1Implement Authorization Concept Purpose The purpose of this activity is to implement the authorization concept for productive operation. developing test user master records. Most fields have values. The Profile Generator simplifies setting up the authorization environment. you must first create an activity group. This task is not mandatory.

541 Create Authorization Profiles and Job Roles Document Purpose Develop detailed authorization profiles and job roles document. The enterprise-wide Job Role Matrix can be the basis for this test plan. Therefore. you must first create test users for each job description. set data.1. • User master data. Then assign required activity groups to this test user based on the information in the enterprise-wide job role matrix.1. • Update the user master manually to transfer the automatically generated authorization profiles to the corresponding user master record. A. such as hold data. Procedure • • Meet with application teams to develop roles and profiles Sign-off by application teams Page 320 . perform security unit testing for each sample user created. user menus. and start menus must be defined. and start menus must be defined. Maintain organizational levels. User master records are the model user master records for validating that every job role defined in a business process fulfills the job functions. set data. such as hold data. Test Roles in user training. your training schedule can be delayed. user parameters. user parameters. • Create a new user master record using transaction SU01. user defaults.540 Test User Masters Purpose The purpose of this task is to test user master models. In addition to the assignment of activity groups. • A. Procedure • In conjunction with application area representatives. Generate the authorization profiles. user defaults.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. If a user authorization is missing. user menus. Edit the authorizations and organizational levels. user profile data.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. Each Role (activity group and generated authorization profiles) must be tested before you golive.1. A. Procedure Before testing the generated authorization profiles. The goal of these tests is for every job associated with a business process to be performed with maximum data security. you do not have to create all named users at this time.

Procedure When activity groups and authorization profiles are tested in QAS. Procedure • • • Work with people responsible for each application area to create a list of users in each department.2Validate Authorization Concept Purpose The purpose of this activity is to create user master records for users. they are moved to PRD.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. transactions. This includes identifying activity groups and profiles for accounts. and related activity groups and profiles for each user.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. Group employees of the same department into user groups. Page 321 . Before moving them to PRD. Assign additional authorizations via activity groups for access to general data. The user administrator sets initial passwords. The validated user master models are copied to the end user master records. A. Assign users or PD objects to activity groups and update the user master records. setting up user master records for validation. and a user address for each user.19.1. Create a list (spreadsheet) of job descriptions. user or project team acceptance is required. 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. and reports.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.1. and communicates them to users. and validate that each user can perform the required processes. resolving discrepancies.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. and refining authorization design. verifying associated business processes for job functions.1. A.

for example. employees change job responsibilities. Page 322 . when new employees join the organization.545 Refine Authorization Design Purpose The purpose of this task to refine user authorizations. and so on. Refine user authorizations.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.1. Do this task with the task of validating user masters for job functions.

Channel. Assess query subscription and publication strategy document. and User (Enterprise InfoCatalog. This involves creation of the following components: • Query • Workbook • Structures • Restricted Key Figures • Calculated Key Figures • Variables A.3Create Reports The purpose of this task is to identify and develop company specific or user favorite reports. 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. 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. InfoCatalog organization strategy document. Activities • • • • • • • Create Baseline Queries/Reports with Business Explorer Analyzer Define Enterprise Channel. Query Subscription and publication strategy document. 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. by roles and functions. Review the security authorization document for query access. Page 323 . 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 SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.19.547 Define Company.1. The Enterprise and User Channel InfoCatalogs are structured. Categorization of query users.

1. End-User.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. Prerequisites • • Result • BW Business Explorer Browser default settings configured for each desktop identified (i.550 Assign Authorizations Purpose The purpose of this activity is to assign user authorizations for working with queries.. The BW Business Explorer is the OLAP Front-end PC Software component.1. A well-structured set of InfoCatalogs makes query distribution and authorization easier.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. Typically. Channel InfoCatalog reflects the roles and functions of the query users.549 Configure Business Explorer Browser Defaults Purpose The purpose of this task is to configure the BW Business Explorer browser defaults. Purchase of BW Software Defined Data Access Paths by User Group and Organization A. 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. which allows End -Users view and analyze decision support data within the BW warehouse. • A. Prerequisites Page 324 . A. • Authorized users list by Channels.e.1. It is worth to invest time up front to determine a strategy. • Pre-defined queries (reports) in the Enterprise InfoCatalog that are ready to be transferred to Channel InfoCatalog. Project Team Members). Users are assigned to the appropriate Channel InfoCatalog. Result • • Available queries (reports) are grouped under appropriate Channel InfoCatalog.

Page 325 . User profiles for working with the InfoCatalog established by BW security administrator. 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. User profiles for query users established by BW security administrator.1.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.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. User access authorization document from business requirement perspective. Assess the User access authorization documentation A.

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

l e i c a l f o r m i n e e p t a n a g i g h .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 h T e s t p .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 m T P e l a s t n l a n o r k E x e T 5 c u t e S 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 o c u m 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 E 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 g H H H i g i g i g h h h .v o .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 .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 g 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 S U p d a t e y s t e m O n g o i n g 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 .THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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 .v o .

the System Test Team is introduced to the concepts of System Testing through an orientation meeting. If not previously developed. along with the Test Problem Report and System Change Request procedures to be followed. and • Defining the approach to integration and high-volume tests. • Restart .20. There should be no surprises in the user acceptance tests. • Outlining the System Test Plan.1. • Restore .552 Define scope of the system test.  operational data store creation and maintenance. including checking for transaction and database integrity. The system test should include items for: • Demonstrating the system's adherence to the specifications defined during the Business Blueprint Stage. • Defining test objectives. • Determining the personnel and machine resources required for system testing. Identify the overall set of business events that the system is intended to support and that the system test is intended to verify. The processes to be tested include:  processing features.  control features such as security. Team members are introduced to each other and a common understanding of the software testing hierarchy should be discussed.to demonstrate the system's ability to prevent or detect and isolate improper access and unplanned activity. 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. The System Test Strategy should have been prepared at the same time as the tasks that were conducted in the Business Blueprint Checkpoint Phase.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. according to the design specifications.to test the system's ability to be restored to a known state at some previous time. a System Test Strategy should be prepared by following the steps defined below.to test the system's ability to successfully operate on all components of the production environment configuration. A. In this task.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. Page 328 . audit. This foundation enables consistent and controlled testing of manageable parts of the system. and/or  manual procedures. and • Security testing . • Database update .  user interface. recovery and reconciliation. Overview The foundation of the System Test Strategy is built by: • Identifying each functional test area within the system. • Set-up and initialization .to test the system's ability to successfully update the database(s) online without interruption to other processing.to test the system's ability to restart after software failure. The system test criteria should address the functions and facilities of the system based upon the Business Blueprint Stage deliverables. this task is principally to ensure that the strategy is still current. If this has taken place.

this is completed as a separate sub-project by a separate Disaster Contingency Planning project team. A.  error processing. which in turn should reflect the system requirements as specified in the functional specifications defined during the Business Blueprint Stage. When creating the system test work plan consider: • All acceptance criteria (user and system test) must be tested in the system test.553 Define test objectives. and  security.to test that business events and their responses can be traced and reconciled across application boundaries and across technology platforms..554 Outline system test work plan.  control balancing and reconciliation. • They verify the accuracy of the User Procedures. • They verify the accuracy of the system including:  information capture. delay or simultaneous transactions in a simulated production environment. and • High-volume testing . Page 329 .THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology Depending upon the project scope. • Required level of effort and staffing anticipated to investigate and re-test Test Problem Reports. back-up and recovery processing. The test objectives serve the following purposes: • They verify that the acceptance criteria will be met by the completed system.1.  information retrieval and reporting.1. 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. define the test objectives. 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. particularly:  relationships among test tasks. Generally.  program coding schedule. from their initiation into the business until their exit from the business. • They verify that the complete set of system functions perform as specified. The objectives typically relate to the testing as reflected in the design specifications. • Required level of effort and staffing based on the number and complexity of processes and objectives.  external interfaces. response times. as per the contingency plan.  program interfaces.  editing and validation. Additional testing may be completed at the system level to address: • Integration testing . A. For each event or set of events.to test that the system meets the required level of performance with respect to such items as throughput.g. turnaround times and processing windows). and • Scheduling of system test tasks. and • They assure any agreed system performance measures with regard to volumes and time frames (e. • Overall implementation strategy with particular attention to the reusability of unit test data.  data conversion and reconciliation.

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. Ensure that the System Test Strategy is appropriately focused and addresses all of the necessary areas. system performance monitoring or terminal usage emulation. • Verification of system test results. • System Test Team members and their responsibilities. Document the System Test Strategy. • Error identification. • Test data set preparation and retention.557 Define/select any test tools. Page 330 . • Test cycle execution and documentation of results. A. • Summary of test data set generation approach.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology available personnel (development team and business partners) and machine resources.1. high-volume and stress testing) should have been identified in the Technology Planning.1. The need for a dedicated system testing environment or environments (e. • System test work plan.1.555 Determine System Test Team members and responsibilities. Include such items as: • System test approach and rationale.1.559 Discuss and obtain formal written approval of System Test Strategy document from the project manager. Confirm in this step that all of the necessary work has been completed and that the specified environments have all been created. Prepare appropriate orientation materials to ensure that responsibilities are clearly understood.1. • Control of error correction and program revisions.558 Prepare System Test Strategy document. and • Migration of programs and jobs to and from the system test environment. A. Define System Test Team responsibilities to include: • Definition of test conditions.. and • Details of the test procedures. Support and Cutover Phase. Obtain formal written approval of the System Test Strategy. • Test objectives for each process. and  availability of other application 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. Define and select any test tools that are to be used as part of the system testing process. A. functional testing. This may include tools for test data generation. quality assurance.g. Define the training needs for System Test Team members.  A. A.556 Confirm required physical computer resources.

1. Page 331 . 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.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.560 Complete the System Test Team training and orientation.

• Control total accumulation conditions.. to define the scope of the tests and to ensure that all required testing will be completed. • Sends data to another system (e. as appropriate. each with their own complexity. A.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. Each objective encompasses the processing activities within one or more program specifications that are invoked to execute a system process.. • System interfaces. BW). 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. define the test conditions that should be tested. power and communications failures. 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. • Program interface conditions. and • Back-up or alternate configurations and systems. Overview A System Test Plan is created for a comprehensive test of the developed system.2Develop System Test Plan Purpose To provide instructions for the execution of system tests..562 Identify system interfaces. • Output conditions. The types of test conditions that should be considered include: • Valid data conditions. source data systems).g. • Pathing logic determination conditions.g. All interfaces identified must be fully tested in the system and integration testing process. and • The local and remote networks documented in the system distribution strategy. the test objective should be satisfied.1. • The intersection of entities used by individual systems data models when overlaid on the enterprise data model. network). • Exception path execution conditions.561 Define test objectives and related test conditions. When all of an objective's test conditions are executed properly. • Invalid data conditions. • The external call sequences documented in the program design specifications. • System. External interfaces are those instances where the system: • Receives data from another system (e. including multiple cycles. Before execution.1. Sources for identifying external interfaces include: • The Management Overview Diagram (defined in the Process Abstract). For each test objective.20. Test steps and associated test data sets are put together and defined as a system.g. or • Uses shared resources (e. Page 332 . the System Test Plans are reviewed and approved. Individual test conditions are developed to satisfy each test objective as specified in the System Test Strategy. Identify all instances of the systems interface to other systems within its environment. A.

565 Define expected results. • 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. For each test condition.g.g. invalid timing and sequencing. Specify the expected status and format of the data. define sets of data required to execute the test conditions. Test data generation tools may also be used in this step to prepare some of the test data set information. and  invalid combinations of values.g. file incompatibility.  invalid types. • Recovery of transferred data and re-establishing connections after system failure.563 Define test conditions. connection failures. A.1..  valid or invalid values. program processing sequence) and required command language sets. Page 333 . • Job(s) (e.g. • Recovery of data corrupted during transfer or as a result of a system interface. 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.564 Define test data sets. 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. • Data corruption. Test cases should include conditions such as: • Errors in passed data as a result of residues (e.. • Unacceptable levels of performance degradation of any system using shared resources as a result of resource sharing. Develop a set of test cases that will execute all of the system's functionality. and • Re-run of interfaces caused by other system failures.. uncleared buffers or registers). • Expected results as determined by the specifications that have been developed during the phases preceding testing. multiple test data sets should be defined for each test condition. • Access and security controls. • Key data element value(s). • 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. above and at value limits. e.1. destroyed values and residues remaining within a common database as a result of interface via the database.  invalid value formats. master file data can be created. 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.1. testing for invalid data entry should include test data sets for different invalid values and for various combinations of invalid data. manipulated and deleted in successive test jobs. Identify: • Data record(s) and/or screen/window(s) to be constructed to test the condition. e.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. A. Cycles of test data should be created so that the tests replicate normal use of the system or logical flows. screens/windows and/or reports for every major automated processing point during the execution of programs for a test condition. For instance.. Where appropriate.

.1. • Output selection and verification instructions. • Reusability of test data sets such that the successful completion of one string will properly initialize the database for a subsequent string.e. 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. A.1.567 Define test cycles. and • Output data balancing/reconciliation and report balancing/reconciliation procedures. When sequencing test condition strings. • Expected results verification instructions. The test cycles are defined such that successive test cycles are built by combining the test condition strings of previous test cycles. invocation of an on-line debugger to verify status). • Logical processing order (e. Define the order in which the test conditions will be executed. Identify the number of test cycles required for each major process in the system. activity listings or control). less complex test conditions should go before more complex test conditions)..g.g. and • Creates a discrete unit of work (i. • Documented procedural flow of work. 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). Identify the test conditions and associated test data sets that will be used for each test cycle. • Verification enabling instructions (e. printing of test data sets for verification.g..568 Define the test condition strings for the test cycles. • The complexity of test conditions (e. The test steps should include: • Input data preparation and entry instructions.1. For each test condition. e. 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. consider: • Valid data is the simplest test condition and should be entered first. 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 SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology • • The status and format of any passed data upon transfer of program control to the second program.g.. A. The sequence of test conditions within a string should follow a logical progression. • Input balancing procedures. define the test steps necessary to execute the test condition and verify the expected results. each successive test cycle: • Tests a larger or more complex portion of the system. modification and reporting. By building subsequent test cycles from previous test cycles. A.. Page 334 .. setting interest break-points for CICS programs). Any reports created (error. • Allows data processed in one cycle to be input for further processing.g. changes or additions executed after deletions). Ensure that a final set of conditions are defined with all break-points and other temporary items removed from the application. master file data creation.566 Define test steps.

Identify the test cycles required to test compliance with all of the defined security controls from the processing controls and security strategy. The acceptance test should be a confidence test for the system users to demonstrate the effective working of the system. for an interface function.569 Define test cycles for access and security controls.1. it is not necessary to include conditions that do not affect the transferred data in either of the interfaced processes).. including fall back procedures. A. 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. especially for time critical or operational dependent procedures for a business. and Association of functions (e.1. the more critical functions and the more frequently used functions need to be tested more thoroughly).. Page 335 .g.570 Define test cycles to address the Acceptance Test Plan. It should not result in Test Problem Reports as any potential problems should be identified and resolved as part of the System Test. A.g.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology • • Criticality of functions (e. Identify the test cycles required to test compliance with the appropriate Access Control Matrices.

the System Test Plan is compared to the business events and Business Scenarios.575 Submit System Test Plan to management and obtain formal written approval. • Back-up and recovery. 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.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. and • The number and complexity of test cycles. Update the System Test Plan with any additional test conditions and related documentation identified from the structured walk-through. A.3Conduct Structured Walk-through of System Test Plan Purpose To ensure that the System Test Plan.1. • Contingency planning.572 Update System Test Plan as needed.1. Overview The structured walk-through process helps to ensure that a complete set of conditions and steps has been defined.1. when executed. A. and • System upgrades.1.574 Revise system test work plan. A correct System Test Plan is one that addresses all the defined events and scenarios. • System security.1. A. • The complexity of procedures required to verify expected results. Revise the system test work plan following the structured walk-throughs to reflect any changes caused through: • The number and complexity of test conditions. will adequately test the system. • Level of effort required in preparation of test data sets. A.573 Obtain approval of System Test Plan. • Interfaces. Page 336 . management and the business users who are part of the System Test Team and obtain formal written approval of the contents. Conduct a structured walk-through of the System Test Plan with the System Test Team. not to the source code.571 Conduct structured walk-through of System Test Plan. During the walk-through. Discuss the contents of the System Test Plan with the project team. • Performance measures.20. A.

. Overview The preparation of the system test environment includes: • The creation of the system test environments (e.20. These may include: • Data file copy/store steps. and • Preparation of programs for execution. 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. A.1. including data file initialization and job execution streams in preparation for the execution of the System Test Plans. Where applicable.580 Identify and create required diagnostic command language steps.576 Confirm required physical resources. Page 337 . if any. A. For instance..577 Initialize access and security mechanisms.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. high-volume and acceptance test environments).578 Initialize master data files. Utility programs may be required for this step. initialize data files and databases with any control. • The initialization of all required test data sets. 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.1. functional.4Prepare System Test Environment(s) Purpose To set-up all supporting environments. shell scripts) and utilities such as copies. • The modification of all command language sets (e. A. prepare and/or generate input transaction data. back-ups and restores for compatibility with the system test environment.1. • Loading utility software such as performance monitors or background load simulators. This should be completed after test conditions that are related to null data sets are executed.579 Alter command language sets and utilities as required for the system test environment. for an UNIX environment. A. 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. and • Prevent access to the system test environment by non-system test personnel. Command language steps may need to be added to command language sets to enable the verification of test results. For batch update processes and on-line processes. header and/or trailer records required. integration. Identify and create required diagnostic command language steps.1.g.g. Create input transaction data sets. A. required for each test cycle. Confirm that all physical resources identified in the System Test Strategy are available and ready for use.1.

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

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

Annotate all of the documentation associated with the completed and approved test cycles and file as part of the system test documentation.1. Modify system documentation as required and log changes.1. Include a description of the resolution. system test results. user procedures and/or program documentation due to: • Design specification changes identified in the error correction process. it may be necessary to modify system documentation. Document all system changes on a System Change Request.588 Modify system documentation as required and log changes.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.589 File all system test results for completed test cycles. Page 340 . This should include the System Test Plan. Depending on the type of error.590 Submit system test results to management and obtain formal written approval. A. and • Documentation deficiencies/inconsistencies highlighted by exercising the user procedures.1. any error corrections and system test logs. 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). A. Correct errors and log error corrections.1. identification of the error correction and date of correction.587 Correct errors and log error corrections. Throughout the system testing process. 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. All user documentation changes should follow the change procedures defined during the User Documentation Phase.

Transactions crossing less than three application boundaries may still be tested during integration testing if considered necessary to mitigate an unacceptable level of risk. However. and • Any transaction that crosses three or more application boundaries. Integration testing focuses on testing the "full life cycle" business event and verifies an event through its entire life cycle. 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. e.. for a new general ledger implementation.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. testing that a journal entry is created in the source system.20.6Execute Integration Test Purpose To ensure the delivery of complete DW system functionality and system performance. Prepare an integration test strategy to ensure that the delivery of complete business functionality can be achieved. The integration test work plans contain contingency to allow for problem resolution. that adds the journal entry and outputs an extract file to a financial data warehouse). across application boundaries and across technology platforms. from its initiation through to the termination of that event across all systems affected by it. Integration testing will also not be a complete re-execution of the application system test.1. • Control balance processing (control totals between applications) to ensure processing through existing application systems is accurate and meets functional requirements defined by the business. • Ensure external interfaces of the DW system have been adequately tested. The integration test strategy structures and formalizes the approach to conducting the integration test activities.g.591 Prepare integration test strategy. unplanned conditions and technical breakdowns. 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). integration test will not test processing within an application system that has not been modified as a result of the application development effort. 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. A. and • Ensure the co-existence of applications as they work in conjunction with each other does not have adverse effects upon the operating environment. • All system procedures and reconciliation processes related to the conditions being tested. Prepare a brief strategy document containing the following sections: Page 341 . added to a sub-ledger that creates a journal entry to the corporate general ledger. • By use of a standard "base case" of test data and conditions to allow each application system to ensure the application accurately processes data. The integration test focuses on those actions that minimize exposure to failure.

Production data can also be converted for this same purpose. Each external interface must follow established standards. • Resource availability for both conducting the tests and researching and correcting Test Problem Reports. A.594 Develop integration test data. A. and Data generation. documenting the outputs of each test step at an integration level (i. Standards should exist for explicit interfaces and interfaces implicit in the database. Scope and approach. Planning technique. The integration test plan is at a higher functional level than a system test plan. often involving multiple types of data at a time. When creating the integration test work plan consider: • The scope and approach and timing sections of the integration test strategy.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology • • • • • • • • • Purpose. and • The impact of the tests on other systems. Key assumptions. Review the interfaces identified in the System Test and reject any programs that do not follow documented standards. • Sequencing of and dependencies between integration tests. allowing specific conditions to be confirmed and that can be used to conduct high-volume testing of the applications. Create expected results for each test step. Data is required to be generated. Timing. Each test step walks-through the execution and checkout process for each individual application system involved with a business event. Conditions focus on the business event being performed.1.593 Develop integration test work plan. Develop integration test plans.e. Team roles and responsibilities.592 Develop integration test plan. A. Page 342 . Execution technique. to identify potential timing constraints and/or windows of opportunity for conducting the tests. Generate test data for the integration tests. Each set of test data will contain both valid and invalid test data. Interface standards must exist for transfer of information between systems. Risk assessment. 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.1. Condition coverage includes both valid and invalid cases. 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.1. expected results should not duplicate the system test results but should focus on results that demonstrate successful/unsuccessful integration of applications and/or systems). The integration tests must also address test conformance to standards..

the prior categories are also executed in combination with the new category to build up a progressively larger test data set. Strict program version control and change management must be in effect. 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. to meet the system's performance and cost requirements. • The data can be successfully processed by subsequent batch programs. The execution of the integration test requires a coordinated effort between the application teams. Using a production grade environment allows the technical performance of the integrated system to be monitored and tuned. A. Each application must verify control balances before initiating the next application's processing. as necessary. Testing will be conducted in test cycles defined to test specific business functionality. Page 343 . Key interface systems that currently exist in production may not have a test environment available for use. The data will be formulated in the "originating system" and sent via interfaces to each of the target applications. Each application team is responsible for performing the necessary "due diligence" to ensure the accuracy of their application as it processes integration data.596 Execute integration test. Support and Cutover Phase. and • The data is able to be printed via existing report programs. Representative operating cost estimates can be derived from the highvolume integration test runs.595 Establish technical environment.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. Experience has shown that the use of a common work area for the Test Team is essential for effective communications.1. A. Confirm that the appropriate test environment has been created as part of the Technology Planning. 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. Test cycles primarily involve three categories of test data .base case.1. Complete the integration test. Use a three step process (base case data. then low-volume data followed by high-volume data) to qualify the applications being tested. Integration tests should be conducted in a technical environment that mirrors the production environment. As a new category is processed. Otherwise. 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. 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. Confirmation of the test execution includes ensuring that: • The data that was processed can be viewed and manipulated successfully using on-line screens/windows.

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

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. • All interface points to or from external systems. Identify such items as: • Key business functionality. The high-volume test process ensures programs and components operate effectively under greater than normal volume levels. and • High-volume tests can result in as many database changes as program logic changes.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.7Execute High-Volume Testing Purpose To confirm that the system operates within acceptable performance guidelines. Page 345 . control over other concurrent use of the system is important. and • Transactions having high risk attributes. delay and simultaneous transaction processing while operating at the planned maximum load in a production environment. Sensitivity analysis of these results is used to identify which transactions or combination of transactions affect the system performance most..20. 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. Scripts are defined to outline how the tests will be conducted and to cross-reference the expected results. • Processing complexity that causes slow response times. Also. the results are analyzed and the system tuned as needed. take into consideration: • High-volume tests are not often concerned with the correctness of process. This step requires that concurrent execution of similar and dissimilar programs be planned. • Specific types of reporting or retrieval/scanning of data for reporting. • As high-volume tests are particularly interested in CPU and network loading.1. • Inquiries that must process a large input or scan large amounts of data. 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. expected results are often physical and not logical. All data model documentation must be updated with these changes. A. High-volume tests are often conducted at the same time as data conversion and the competition for system resources should be planned for. After execution of the high-volume tests. When planning high-volume tests and high-volume test cycles.600 Define test cycles that establish system performance boundaries.e. Overview High-volume testing confirms that the system meets the required level of performance with respect to throughput. • Internal system linkages between sub-systems. A. when processing the agreed upper limit loadings in a production or simulated production environment. 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. i.1.601 Identify transaction mix for high-volume testing.

if the volume for a program is always 10. Replication or cloning methods for the data may employ a variety of techniques to create test data including manual input. A. Benchmarking information for similar systems can be prepared at the site that assists in recognizing acceptable performance of the tested system. assess the load variability.000 records.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology The identified transactions should represent the majority the BW system.602 Determine target volumes for high-volume tests. ensure appropriate coordination has occurred with the IT technical support organization.604 Execute high-volume test. utility jobs. • Daily use curves (e. System test data may be used to provide the initial "base" of data. 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. and • Expected record retention levels. Consider: • Month-end. conversion programs.g. Review the list with project management and the construction managers for accuracy and completeness. updates or deletes of records.603 Define and build high-volume test data for high-volume tests.000 records. System processing statistics. increase the peak number by 20% (e. keystroke macros. including extract and transformation jobs. A. actual production data or special programs built to create data.1.1. Performance measurement tools and expected measured outputs should be identified before the test is conducted. • Seasonality... Create an initial subset of data (10 to 30 records) that reflects a majority of system functions. containing both valid and invalid conditions. Page 346 . Batch high-volume testing uses a variety of methods for synthesizing test data.. If the load is static. is the volume of records processed dynamic (increase/decrease over time) or static (remains constant over time) • Process results in inserts. Programs with dynamic loads incur greater risk of failure and therefore must be tested with higher volume levels than the expected production loads. Before executing the high-volume test. period-end and year-end. holidays or other volume-changing variables. that is replicated to the target transaction volume.g.000 records). special tools. A. does the majority of activity occur in the morning or in two hours in the afternoon).1. 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. if the volume for a program can be up to 10. Determine the expected production volumes for each group of items identified.g. If the load is dynamic. multiply the peak volume number times three (e. test the program with 30. Where possible. Test data for a program should exercise a proportionate subset of the overall functionality. test the program with 12. The static load test confirms the program can perform at expected production levels as long as the load is static. chaining the output from one process to another provides the most effective test. • Load variability. The overhead of synchronizing the efforts of two processes is generally worth the investment. Once peak volume levels have been defined for each item to be tested.000 records).

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

1. moving critical programs directly into resident memory).20. A. and • General tuning (e.g.8Conduct System Tuning Purpose To ensure that the system that has been constructed operates efficiently on the target hardware and software platforms. or • System Test Strategy.g. 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. A. revision of job schedules to reduce the possibility of system response degradation due to competition for resources with other systems. • Operational tuning (e. Identify if any performance-related criteria have been specified in the following documents: • CSFs/Events list. etc. so modifying the programs to improve performance may provide long-term benefits. A. more memory. may need to be tuned to ensure that the system runs at an agreed level of performance. different or additional utilities such as for sorts or back-ups).607 Review test performance results. faster line speeds. • Contract. Overview The new system once installed and tested. • Agreed system acceptance criteria.1. This task may only be partially completed before live processing commences.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. Optimum performance can often only be achieved once the system has been built and has been tested in the production system environment.g. reduced encryption and increased compression)...1. front-end processor upgrades. In the operations area. A. • Network configuration tuning (e.g. more processing power. use of disk caching or other technologies.609 Identify application tuning options. Page 348 . improved job submission systems).608 Identify environmental tuning options. • Software upgrades (e. upgrades to communications protocols. Determine the possibility of tuning the system to address the problems.. more communications bandwidth. Program requirements tend to change more readily than data structures. The steps defined should also be included as part of ongoing system maintenance. integration and high-volume tests against the expected performance levels and identify any performance levels not achieved. 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.1. Determine the prospect of re-designing the programs to improve the performance of the system for critical transactions..). more disk drives. Review the results of the system. consider alternatives such as: • Hardware upgrades (e. file placement.g..606 Review any performance-related criteria.

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology Identify any changes in the daily.g. Compare the test performance results with the required results and if the results are still unsatisfactory continue with system tuning.612 Update system documentation. Ensure that any changes made to data models. if so. Determine the potential for tuning and denormalizing the database(s).613 Establish ongoing system tuning process. 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. 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. Create a record to define the performance level of the system before any tuning. A. Page 349 . • Add indices.1. weekly or period-end processing streams which may improve overall performance or capacity utilization. A. Identify. Decide if the results are significant enough to warrant making the change permanent and.1. e. regular running of database file reorganization utilities. A.1..1. update all relevant documentation to reflect the change. A. networks or other items as part of the system tuning process. from the system tuning plan. Ensure that housekeeping routines are included as part of the operations instructions to maintain performance levels. are reflected in the maintained system documentation and operations instructions.611 Complete system tuning and re-test. Conduct the appropriate system tuning techniques and compare the performance results with those already obtained. tuning that may potentially improve the performance of the software and therefore lead to improvements in the overall system performance. Ensure that performance and capacity measurement data is collected and regularly reviewed. • Validate clustering and sequences. and • Allow redundant data. Ensure that the responsibilities for all areas of systems performance are clearly defined. Options include: • Tune for non-index accesses.610 Identify database tuning options.

However. Revisions may be needed to the project work plan and the detailed work plans. 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. One of these points is the completion of the Realization Stage and these additional tasks are described in the Construction Checkpoint Phase. the risk assessment needs to be reviewed to reflect changed risks in construction. to identify and address scope issues and to conduct appropriate Quality Management Reviews. Overview Throughout all of the stages of the DW life cycle.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.21 Realization Checkpoint Purpose To confirm the results of the Realization Stage of the BW project with management. the baseline for the project will change from the Realization Stage to the Implementation Stage deliverables and estimates should be reviewed to reflect this. Page 350 . there is a need to monitor and report project status. There is likely to be a change in scope and to the contractual conditions regarding deliverables and sign-off. at specific points in the life cycle. additional tasks will have to be completed.

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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 d R e a l i z a t i o n S t a g e O p e n I s s u e s U R e 2 v i e w I s s u e I s s u s e r e s o l u t i o n s P r o j e c t p l a n s U p d U a 3 t e P r o j e c Ut pP d l a a n t es d p r o j e c t p l a n s Q u a l i t y P l a n U U p d a 4 t e Q u a U l i t y p P d a t e l a n d Q u a l i t y P l a n 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 n S t a g e D e l i v e r a b l F o r m a l A p p r o v a l P o i n t Page 351 .

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. make certain that any stub programs used for testing around missing functionality are available for integration testing and communicate this accordingly. A. Page 352 .THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. It is essential that all work has been completed or is included in the work plans for the forthcoming Implementation Stage.615 Check completion of the system test work plan. subject to approval. Frequently. Prepare a list of all programs from design and ensure that checklists for each program were prepared.1. Check that the work plan prepared for integration testing has been completed which should include a review of the TPR log.616 Check completion of the integration test work plan.g. Program Control Checklists were prepared for each identified program within the proposed system.21. A. At the checkpoint. Overview Throughout the project. The appropriate approval authority for each of the deliverables discussed below should have been identified in the Project Charter. CrossLife Cycle Phases). subject to approval. Any discrepancies should be addressed immediately and appropriate action taken.. Any discrepancies should be addressed immediately and appropriate action taken. A. Ensure that all TPRs raised have been completed or that appropriate action is being taken to complete resolution in sufficient time. progress against work plans is monitored continually. because an overlap can ease smoothing of staffing levels or because time constraints make it impossible to complete construction before starting implementation.1.1. This may include the delay of certain functionality in a subsequent phase. Check that the work plan prepared for system 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. Ensure that this list is complete. In this event. 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. In design. The end of construction is quite often not clear-cut.1Confirm Completeness of the Realization Stage Purpose To complete an integrity check of the Realization Stage deliverables.614 Check completeness of all Program Control Checklists. the full completion of all planned work in the parallel phases needs to be checked (e. This may include the delay of certain functionality in a subsequent phase. there will be overlaps between construction and implementation because of phasing.

Ensure that any outstanding TPRs are addressed and any related issues have an appropriate resolution or action accordingly. Check that the system test conditions and results have been reviewed and formal written approval has been obtained.1. • Training course plan and schedule.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology Any discrepancies should be addressed immediately and appropriate action taken. • Training materials.1. Deliverables include: • User documentation standards. Check that the documentation has been properly completed and formal written approval has been obtained. A. and • Training course maintenance plan. Ensure that the effort involved in conducting the training session(s) is addressed in the Implementation Stage Work Plan.1. issues should be raised accordingly.617 Confirm formal written sign-off on system test results. All User Documentation tasks should be completed and should have been subject to system testing. A. Ensure that any outstanding TPRs are addressed and any related issues have an appropriate resolution or action accordingly. the only remaining task in the Training Phase yet to be completed should be Conduct Training Session(s). Data conversion programs and procedures have been produced and should be complete.621 Confirm formal written sign-off on data conversion programs and manual procedures. • Documentation (on-line and non-automated). • Supplementary documentation. Deliverables include: • Training scope and strategy.1. A. At this point in the project. and • Documentation distribution list. Check that the integration test conditions and results have been reviewed and formal written approval obtained. Check that these have been completed and that formal written approval has been obtained. • Instructor materials. the impact should be assessed and any issues raised. If there are any materials yet to be developed. Page 353 . Training materials have been produced during a parallel phase and should be complete. A. A. Check this is so and that formal written approval has been obtained.620 Confirm formal written sign-off on training materials.619 Confirm formal written sign-off on the user documentation.1. If there are any discrepancies.618 Confirm formal written sign-off on integration test results.

Check these deliverables have been completed and that formal written approval has been obtained. Check that any data conversion tasks that were planned for completion by this point have been completed. If there are any discrepancies. Deliverables include: • Data conversion strategy. • Created data. The impact of any discrepancies should be assessed and appropriate issues raised.1. the impact should be addressed and an issue raised. issues should be raised and action taken accordingly.624 Check formal written sign-off on user acceptance test. and • Data conversion reconciliation procedures. 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. • Reconciliation results.. A. • Data conversion programs and procedures. • Purged data. • Data conversion system design. • Data cleansing programs and procedures.g. • Data conversion requirements. If there are any discrepancies.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. User acceptance testing is primarily a client responsibility. data cleansing and purging may have commenced or external information may already have been obtained.1. A. Deliverables include: • Converted data. Data conversion may already have been started at this point. 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. Confirm that all tasks in the Technology Planning. A. • Data conversion plan. Within the methodology. Ensure that tasks are included in the Implementation Stage Work Plan to address the final execution of the data conversion programs. formal acceptance testing takes place during the Implementation Stage. e. and • Approach used and program documentation for any clean-up.622 Check progress of any data conversion already undertaken. creation or conversion programs. At the Construction Checkpoint Phase.1. 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. assess the impact on the overall data conversion estimates and schedule. Page 354 .623 Confirm formal written sign-off on transition support and migration deliverables.

. may be started during the Realization Stage. Page 355 . 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.1.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. In certain projects. acceptance testing. Raise any issues as appropriate and take corresponding action.625 Check progress of any acceptance test work already undertaken.g. The Methodology assumes acceptance testing is performed in implementation in the full production environment. If this is not the case. 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. e. ensure that this environment is checked at the appropriate point. Although formal completion is not expected until later. although formally scheduled for completion during implementation. Some of the acceptance tests may take place in an environment other than the planned production environment.

an approach describing how these will be resolved should be developed and agreed. Review all open issues contained in the Issue Resolution Log. In practice. an agreed approach to resolving all outstanding issues. The decision on the importance of resolving an issue should be made by the project manager in conjunction with senior management.1. Assess the impact of any outstanding issues and reflect in the plans and risk assessment for the next stage.. not all issues will need to be fully resolved before progressing to the Realization Stage. it turns out to be an expansion of scope or an error in information provided by the user.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. Ensure that procedures for investigating outstanding issues are fully understood by both developers and system users.626 Review and resolve any outstanding issues. A. Overview All issues must be reviewed and appropriate action agreed/taken. Identify possible resolutions and initiate appropriate corrective action.1. The cost of investigating outstanding issues may need to be split between both parties. Document on the Issue Resolution Form or cross-reference to the Issue Resolution Form. e.2Review Issues Purpose To identify all outstanding issues and either resolve or agree future actions. no issues should remain outstanding at the end of the Realization Stage. Page 356 .21. the cost of the investigation as well as the resolution of the error should be borne largely by the system users. A. For any issues that will not be resolved immediately.627 Agree approach to outstanding issues.g. if after investigating an issue. Ideally.

630 Consolidate plans into the project work plan. Consider the impact of these plans on the approaches envisioned for implementation and ongoing support. A. These changes are then reflected in the overall work plan.629 Validate decisions based on sequencing of deliverables with other Realization Stage deliverables. Page 357 . At the end of design. Overview At the Business Blueprint Checkpoint. Correct any inconsistencies by revising the appropriate plans. and • Acceptance Testing.628 Review implementation plans in relation to progress to date. • Changes to implementation mechanisms made during construction.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. • Staffing requirements and availability. The estimates for the remainder of the project are reviewed using the actual results from construction. Fully detailed work plans are produced which address the overall project and resources available. Revise the implementation plan accordingly. • Work brought forward or postponed to earlier/later phases.1. Full costs and time estimates are derived. an implementation plan was developed. This should be reviewed at the completion of the Realization Stage and adjusted accordingly. Both the detailed implementation plans and the approach to warranty and maintenance are reviewed including the impact of any ongoing parallel phases. Considerations include: • Changes to sub-system boundaries made during construction. Ensure that all plans are included in the project work plan which combines all tasks. • Changes in internal or external dependencies.1. together with any implementation and parallel phase work already completed. A. • Training.21. dependencies and milestones for the remaining stage of the project. and • Changes in milestones or financial constraints.1. A.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. Review complementary Realization Stage plans for other items from the Cross-Life Cycle Phases which may still be in progress including: • User Documentation. an approach for the Construction and Implementation Stages was developed and an approach to the ongoing support of the implemented system was prepared.

631 Revise estimates in light of previous experience. Review any discrepancies and take appropriate action including: • Re-phasing of the implementation to ensure that time scales are met. Formal written approval should be sought for any actions to be taken and plans revised accordingly. or • Reducing the staff complement to reduce cost but increase time scales.1. • Agreeing a revised cost for the project. Based on the project work plan and the revised estimates. Develop final cost and timing plans for implementation and support. Estimates for implementation were made in the Business Blueprint Checkpoint Phase based on the best knowledge at that time. Page 358 . A.633 Validate overall project cost and time estimate. Reflect any changes to the overall work plan necessitated by resource or other constraints. • Increasing the staff complement in an attempt to reduce time scales at increased cost. develop detailed work plans for the remaining work to be undertaken to complete the system implementation and to support the system.632 Produce detailed work plans for the Final Preparation Stage and Go Live and Support Stage. Experience gained during the Realization Stage may indicate variances from these original estimates and the implementation estimates should be revised accordingly. A. Compare these with the originally agreed figures.1. • Revisiting the original scope to see if scope has changed over the lifetime of the project. Estimates should be revised accordingly.1. Many of the parallel phase activities should be almost complete and should provide information about appropriate estimates for the remainder of this work.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.

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. document: • The likelihood of impact on the project. 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.21. A. Overview To this point. Page 359 . Obtain agreement with management on the appropriate actions to take. Update the implementation strategy. as appropriate. the Project Risk Assessment needs to be revisited. • The severity of the risk. These are reviewed and appropriate amendments made to reflect the end of this stage and the start of the next.636 Revise risk management approach.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A.1.g. Identify where the risk ratings described in the risk assessment are higher than expected or are greater than originally. Those sections of the Project Charter that need to be updated for Construction are reviewed and amended or created. In particular.4Update Project Charter Purpose To ensure that all aspects of planning and quality have been properly addressed. data conversion strategy and appropriate testing strategies as necessary.1. A. assess the impact of making changes to the project plan on the associated strategy documents developed in this stage..634 Review and revise Project Risk Assessment. In this latter instance. Review the risk assessment as a result of the Realization Stage experience and the updated project plans for the Final Preparation Stage.635 Review project risk dimensions. the Construction Checkpoint Phase has largely been concerned with work planning. 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. For identified threats. Many issues are addressed in the Project Charter that go hand-in-hand with the work plans.1.

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology • •

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

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 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

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology

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

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology

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

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology

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

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology

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

n

S

y s t e

m

o

p

e

r a

t i o

n

i n

s t r u

c t i o

n

s

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

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

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology

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

This checklist should contain: • All of the various tasks to be completed. • The time frame and responsibility for each task. agreed and followed to ensure a successful and smooth system commencement. In addition. Set up production job streams for live running. several other job stream areas need to be addressed in a production environment such as security access and utility access. if the organization has a separate group with responsibility for transfers of systems from test to production. Review the implementation plan to ensure that all target dates will be met and revise. This task is included to address situations where all steps have not been completed earlier or where some minor adjustments have to be made.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. should be used to facilitate this planning process.1. A. A. it is mandatory that a critical path-based checklist is prepared. In addition. The implementation plan/schedule is finalized and all system components are prepared for the production operations environment in conjunction with the operations personnel.645 Finalize production job streams. A structured walk-through of the checklist should be completed before it is finalized to ensure that it is relevant and complete. Some form of critical path software. These steps will require close liaison with computer operations management.22.1. Update the implementation plan with any additional information such as: • Scheduled dates for data conversion completion and first month of operation. Note: The steps in this task should have been completed as part of the Technology Planning. where necessary. and • Estimated staff resources to cover both implementation and subsequent operations.646 Finalize and walk-through the live processing checklist. if not already in use. and • Any alternative or contingency plans.1. As there are generally hundreds of different tasks that must be completed to commence live processing. A. Support and Cutover Phase. Page 367 . Overview Final preparations for the implementation of the data warehouse system are made in this task.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. discussed. additional steps may be required to meet their specific transfer process or transfer methods.644 Finalize implementation plan.

Include appropriate allowances for the generation of data file catalogue entries and any generations of archived data to be maintained on-line. Page 368 .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.1.1.648 Obtain formal written approval that the production environment creation meets installation standards.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. A.

check dependencies and links to other development objects • After you export. are transported.1. Overview The implemented system. • Before exporting. ensure that the data conversion is reconciled and formal written approval is obtained as being completed. • Data conversion.652 Conduct system transfer according to installation change control procedures. In this and subsequent activities. Depending on the means of live processing commencement.22. is transferred to the appropriate personnel responsible for its ongoing management. including all documentation. This process may need to be supervised by or completed in conjunction with. Formally transfer the new system and all of its supporting documentation including: • Program listings (including conversion programs. Provide all personnel that need access to the system their assigned security level.651 Initialize security profiles.650 Execute programs to finalize data conversion to the production BW environment.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.1. • User documentation. A. 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. The BW system provides tools for transportation of customizing settings and BW Repository objects.1. Execute programs to convert and load both master and transaction data into the production BW system. internal or external audit personnel.3Implement and Transfer Tested System Purpose To transfer the new system to both the user and computer operations areas in a controlled manner. review BW export logs • If required. A. Page 369 . and • System operations instructions. Initialize both the system and user security profiles.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. as well as development objects. • Program and system documentation. A. Successful import of customizing settings and BW Repository objects is the main objective of this task. Procedure The customizing settings created in the development system. observe the transport time windows in the project. maintenance and support.1. where relevant).

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

If the implementation of the new system has also included changes or additions to the organization's Disaster Contingency/Recovery Plans.g. • Any quarterly. 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 production of the first set of cyclical reporting. or • Completion of parallel processing. A. by location or by division) is to occur. • The reconciliation of sub-systems and interfaces. Where a staged implementation (e. live processing may be commenced on more than one occasion and this should be addressed in the different work plans.658 Ensure that all Disaster Contingency items are in place.1. half-yearly or year-end processing.1.659 Commence use of the new system using the agreed definition of "live processing. • Monitoring of service levels and performance. A..1. Page 371 . Obtain a formal written system transfer sign-off that the system was successfully transferred.660 Obtain formal written sign-off of completed system transfer.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. Complete the necessary approval procedures to complete CPDEP Phase 4 “Execute”. have been fully tested and that the plan has been formally approved. ensure that all of the appropriate items and services are in place." Commence live production of the new system using the definition of live processing derived for the project.

The key to a successful PIR is to complete the review within three to six months of the original live production commencement date. 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. Post-Implementation Review At a predetermined point after the implementation of the project. 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. This phase is also used to monitor system transactions and to optimize overall system performance. For many projects.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology Go Live and Support The completion of the project needs to be addressed in a systematic and controlled manner. 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. using a mixture of reviewers who were involved in the development and resources that can provide a fresh perspective. This is particularly the case where significant changes to business processes have occurred as a result of the new system implementation. Another effective use of the phase is where a staged or phased commencement of the system is to occur. Key Deliverables: 4) Roll-out of training and user documentation 5) Project sign-off Page 372 . not just for the first critical days of your productive operations but also to provide long term support. There must be a solid user support organization easily accessible to all users. a formal review of the BW system is recommended to identify areas where additional benefits can be gained by fine tuning the application. The PIR tasks and steps can be tailored to review the first implementation of the system. You must set up a support organization for users. The purpose of this phase is to move from a pre-production environment to a live productive operation. the completed project is closed. Finally. users of the BW System have many questions. to take advantage of the knowledge gained and enable the subsequent implementations to be completed more effectively. During this phase.

In addition. Following the first few days of live operation. particularly with reference to system performance. Any issues or problems that occur in this period must be resolved as quickly as possible. you will have questions. it is important to monitor system transactions and overall performance. capacity. During the first weeks of live operation. During the process of going live. In the first few days. and functionality.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. 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 O n g o i n g S u p p o r t R e s p P u P c r t o i o d nu c t i o n s u p p o r t R e c o n c i l i a t i o n P 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 m 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 e m O e p n tW t i m 3 i z e S T u y s t e m n e U d s e s y s t e m Page 373 .23 Production Support The purpose of this phase is to provide support to users and to optimize system performance. there are two critical periods. you must then address monitoring issues in the long-term. you must execute the production support plan and check the results. Timely support is critical to your success.

Procedure • • • Execute the production support plan. End users may require increased support during the early production period.662 Manage and Resolve Problems Purpose The purpose of this task is to establish a process for resolving user problems. as well as in the long term.1.1Provide Production Support Purpose The purpose of this activity is to provide support for BW users. During the period immediately after moving to live production. Any problems must be resolved as quickly as possible. there are two periods that must be carefully planned and monitored. In the first few days. document and distribute procedures for handling internal problems both during the period of going live and for the long-term. key users must be trained in using SAP’s Online System Support (OSS).1. In addition. Verify that all SAP contact lists contain the correct names. Also. Supply end users with the names of support personnel. Define the roles and responsibilities of project team members during the immediate period of going live. You must make sure you have properly executed your plans particularly for the transition to live production and for long term production support.23. special support is required. Support will be required immediately following the move to live production. as well as ongoing long-term support. On the first day of live operation. you must execute the production support plan and check the results. A.661 Direct Problems and Issues Purpose The purpose of this task is to establish procedures for handling questions from users Procedure • • • • • Develop.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. Support users in the initial period after going live . During the move to live operation. Document and distribute procedures for directing problems to SAP. the Power User and project team members must be Page 374 . The success of your implementation requires a well-managed user support function.the project staff must be on hand to answer questions. verify that end users have internal contacts through whom they can channel issues to SAP. This includes short term support during the transition to live operation. Tasks • • Direct Problems and Issues Manage and Resolve Problems A. Ensure the Help Desk is adequately staffed and organize the support team for ongoing operations.

Page 375 .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.

attributes.2Validate Live Business Process Results Purpose The purpose of this activity is to confirm that the BW system is functioning correctly. These measurements can be based on shipments.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. weekly. Procedure • Verify First Day Business Using specific measurements. For example. • Verify First Month-end Check the planned business results for month-end processing. use the testing plans designed Acceptance Testing. daily. check that master records.1. If some business results are not met.23. internal production schedules. Page 376 . This is especially important for public companies because they must publish financial information for shareholders. A proactive measurement is required. and other business operations. • Verify First Year-end Check the planned business results for year-end processing. This is especially important for public companies since they must publish financial information for shareholders.663 Monitor Daily and Weekly Transactions Purpose The purpose of this task is to review initial transactions in the productive system. check the planned business results of the first few days of operation. These tasks are a form of quality check on the system. billings. it is still important to resolve it. monthly) to validate results from transactions. This gives users confidence that no matter how small or insignificant the problem may be. Otherwise design plans to monitor and verify the transactions processed. and verify processing. If possible. reschedule them for the next business day and make provision to handle the workload. Both master data objects and transactional documents should be included in this review. A proactive measurement is required. • Verify First Quarter-end Check the planned business results for quarter-end processing. Execute the plan and prepare a written report on the issues that arise during production. A proactive measurement is required. Tasks • • • Monitor Daily and Weekly Transactions Resolve Issues Confirm Live Environment A. hierarchies and compound characteristic records are being properly updated. It is important to document and resolve all issues. You must look at different periods of time (for example.

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.664 Resolve Issues Purpose The purpose of this task is to resolve issues and ensure that corrective action is taken. Timeliness is critically important since users need problems resolved so that they may do their jobs properly. changes to the system. assign.665 Confirm Live Environment Purpose The purpose of this task is to confirm and approve live BW productive environment. new documentation.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. for example. Approval takes place after business processing results have been validated. the person assigned the issue informs all relevant personnel that the problem is resolved and the issue closed. The resolution may result in. actual approval times vary. follow up training. Procedure • • Follow up each issue recorded until it is closed. Issues should be categorized by type and priority.1. The issue is then assigned to the support team for resolution. official approval of the live BW environment should be completed by the Guidance Review Team or senior company management. Page 377 . and track open issues until they are successfully resolved.1. and estimates should be made as to what time and resources they require. The person assigned to the issue is accountable until the issue is resolved. It is management’s responsibility to record. This sign off typically occurs within a few weeks after going live. If training is not required. • A. As a guide.

3Optimize System Use Purpose The purpose of this activity is to improve system performance. database. create.1. To optimize the technical environment. such as the database.1.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. The System Monitoring course provides training in monitoring. A.23. Procedure The starting point for analysis can be system performance.666 Optimize Technical Environment Purpose The purpose of this task is to monitor the BW system and implement improvements. Page 378 . This data can be used to fine-tune. This involves monitoring system loads and data volumes. Estimates made before the system goes live may change in the productive system. applications. or drop InfoCube aggregates.667 Optimize Business Transactions Purpose The purpose of this task is to optimize system performance for the most frequent critical transactions. and system load. configurations. you monitor technical elements. A. the BW Statistics InfoCube provides information on query execution and data loading. and operating system • SAP BW/CCMS Additionally. Monitor the system and do any tuning required. servers. 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.

capacity utilization.g. Based on this assessment. Additionally. • Information accuracy and/or degree of user demand for additional information or reduced data content. Staged or Phased Implementations As an alternative. in this Phase. • Training. 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. • System features usage including input documents/screens/windows and output screens/windows/reports/files. the review requirements to be met and the specific work tasks to be completed will need tailoring for each project. • Processing schedule. e. • System support. • Documentation quality and comprehensiveness.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.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. Page 379 . As a result. post-implementation review tasks and steps should be defined that capture this information. • Benefits achieved (expected and actual). • System performance.. response times. the CPDEP Phase 5 task of “Operate and Evaluate” is completed. if it is effective in serving the organization's needs and if it meets the original requirements. system availability. and • Costs (expected and actual). this phase can also be used to review the first implementation site for a staged or phased system roll-out. • Security. The following system areas may be included in the review: • Data transformation system and operational data store. problem areas are evaluated and potential improvements are recommended. Each review will have its own unique scope. Overview The implemented system is reviewed to determine if it is performing satisfactorily.

I m n v i e w D e l i v e r a b l e Page 380 .THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology 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 E 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 A p 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 S c o p e a n d R e q u i r e m e n t s C o m p l i a n 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 e s a n d E 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 .

to determine the degree of satisfaction with the installed system and to assess the overall reliability of the system. e. project management software. 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. • Determine the use of any DW tools. The objectives and the scope of the review are discussed and the detailed work tasks and steps to meet these objectives are derived.1Evaluate System's Effectiveness Purpose To establish the scope of the review.  the sequence of processing or flow of work required. Page 381 . • Determine the extent of reliance on the system to provide the information needed for performance measurement. The housekeeping needs for the review such as document management procedures.  interfaces/data transformation. A.  operational data store.669 Evaluate the effectiveness of the system features. if users are totally unaware of a system feature. this may be an indication that there is lack of awareness of particular processing features.1. Other clues are sought out to determine the reliability. decision making. administration tools and the Project Charter are defined and formally agreed and a detailed review work plan is prepared. number and duration are defined and the project team is formed.668 Establish review scope and infrastructure. planning and other management activities.  reports. e. discussed. and  processing controls and security. The staff resources required by discipline..1.24.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. Overview The scope. This reliability cannot be determined by user satisfaction alone. they will not express any satisfaction or dissatisfaction with that feature. The implemented system is reviewed to determine how satisfied the organization is with the system and whether the system is operating reliably. if data available in the system is being manually maintained. A. 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. quantitative analysis.g. The reliability of the system is determined not just by its accuracy but by its effectiveness in supporting the users. documented and agreed.g.. The review project management reporting structure is established. project staffing and management of the review are established. Formal written approval is gained of the project scope and infrastructure.

Evaluate the level of satisfaction with on-line response times and. Review the on-line performance statistics for: • Slow on-line response times for significant or high usage inquiries. develop charts to represent actual response times to avoid "subjective" criticism that the system "feels" slow.671 Evaluate the effectiveness of on-line response times. and • Identify where there is a high level of user department staffing relative to the work completed. activities to be evaluated include: • Determine the level of satisfaction with the timeliness of information. where appropriate. A. measure the degree of compliance with the agreed service levels. • Identify where overtime is regularly required to meet operation schedules.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology • • Determine the use of supplementary procedures to support the needs for organizing the information. • Determine the level of satisfaction with turnaround scheduling. If a Help Desk is provided. A. and Determine whether the installed system features are being fully used or not. Page 382 . • Identify where bottlenecks occur due to an inadequate number of staff. data transformation system). determine its usage and effectiveness.673 Evaluate the effectiveness of system support services. and • Determine the number and extent of program problem reports and/or requests for program maintenance. interfaces.672 Evaluate the accuracy of data.1. The analysis may also indicate potential resolutions to response time problems by indicating when or where the problems occur. System services requests include program change requests.g..670 Evaluate the effectiveness of processing schedules. and • Downtime of any components of the system. A. • Determine error statistics and error correction steps. A. disk space or other hardware shortages.1.1. • Determine whether the system is balanced and reconciled with the frequency stated in the user documentation (e. • Capacity utilization. on-request processing and report distribution service levels. evaluate such items as: • Determine the level of satisfaction with the accuracy of data. • Traffic patterns and peaks including hardware and network traffic analysis. input peaks.1. • High transaction volumes. To ensure that the system allows only valid data to be input and that the whole system is regularly reconciled and balanced. To determine whether the present methods of accessing and running the system are appropriate. • Determine whether sufficient controls/totals are included on all reports from the DW to ensure data completeness and accuracy. If a service-level agreement is in place. network problems or insufficient time. Determine if user system services requests are implemented quickly and accurately. • Determine if duplicate data is being manually maintained that may be the result of unreliable system data or alternatively inadequate training.

for instance. organization and content. adaptive maintenance or perfective maintenance).g. growth rate of the maintenance budget). • Report and output balancing requirements to ensure that the results are consistent and that reconciliation procedures are completed. maintenance budget as a percentage of total IS department budget. recovery and restore routines. systems software or networks being used. A. system operations instructions and user documentation. Determine whether the system has been appropriately included in the organization's Disaster Contingency Plan.g.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology Analyze the program and system maintenance.1. A. • Security tracking software and control logs are regularly used to monitor system usage. Some indications of maintenance levels include: • Maintenance budget (e. Analyze and evaluate the operating costs as related to the system in a production environment. Evaluate the level of awareness and use of features within the system.675 Evaluate effectiveness of controls and security...1. Page 383 . processing errors). up-to-date. • Physical security control compliance..676 Evaluate the effectiveness of operating costs as related to the system. Consider: • Access controls to prevent unauthorized users from accessing. Compare the system costs with other application costs to determine if the costs are appropriate and equitable.674 Evaluate the effectiveness of program documentation. Compare the actual costs against the expected costs. lack of user understanding of the application systems. • DBMS housekeeping routines are regularly applied to ensure DBMS integrity. Determine the level of satisfaction with the user documentation format. Make sure the documentation reflects system changes installed after execution of acceptance tests. • Data validation routines are always used to ensure that only valid data is entered into the system.e. Evaluate the effectiveness of system controls and security that prevent and/or detect errors or irregularities in the system.1. A. • Back-up. and • Output distribution controls to ensure that the correct personnel receive the output and unauthorized personnel are prevented from receiving the output. changes may have occurred in the hardware configuration. Determine the program documentation and system operations instructions status (i. • Types of maintenance (e.g. software (system or application) unreliability.1. Check to ensure that the cost basis is consistent between the original estimates and the current figures as.677 Discuss the findings and consider alternative recommendations to address any anomalies discovered. current maintenance budget amount. A. corrective maintenance. and Sources of the maintenance problems (e. reading or changing the system or its data. outdated)..

Page 384 .24. Identify: • The individual processes and their estimated volumes. • The availability of the specified processes and functionality in the implemented system. Compare the original scheduling and frequency requirements with the actual operational statistics maintained within computer operations.g. changes in the technology environment. e. volumes and downtime. Compare the original response times requirements with the actual statistics. When completing this task. • Development methodology usage.1.1. Compare the estimated volumes of data against the data volumes currently being processed by the system. Overview The implemented system is reviewed to determine if the requirements have been satisfied. • Service levels. e.. adjusted where necessary by any changes. • Operations housekeeping. • Maintenance. Determine compliance with installation standards for: • Programming and design standards. 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.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. A.681 Determine compliance with standards intended to prevent information inaccuracies.678 Determine if the processing capabilities of the implemented system comply with the original requirements.. A. A.680 Determine if the response times comply with the original requirements. The requirements of the implemented system are measured against the original requirements from the Business Blueprint Stage. other new systems have been added or volumes have been increased in other existing systems. determine the present hardware configuration.679 Determine if the processing schedules comply with the original requirements. Review the original or modified requirements for the system.2Evaluate System's Compliance With Requirements Purpose To identify areas of the system that do not meet the stated requirements.1. and • If all processes are being used. • Testing standards. A. • User document utilization and maintenance. 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.1. Consider specifically the data handling capabilities and functionality of the system. Review the on-line performance statistics for on-line response times. • Numbering and naming conventions. network configuration.g.

balancing and reconciliation procedures. and Tools usage. Analyze current processing costs and benefits against the original estimates after revalidating the original assumptions.1. review their compliance with the appropriate contracts. and • Tools usage. • Development methodology usage. • Program change control procedures..1. Summarize the detailed review point findings. • Changed to conform to the installation standards for the format and organization of the documentation. Determine if user documentation and system operations instructions are: • Updated when system or business changes are implemented. • Control.1. Page 385 .THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology • • • • Training completed. Assess the impact on the organization from the implementation of the new system. Program change control procedures. • Service levels. • Testing standards.1.1.683 Determine compliance with documentation standards. A.g. A. • Numbering and naming conventions. • Maintenance.682 Determine compliance with system support service standards. • User document utilization and maintenance. balancing and reconciliation procedures.686 Discuss the findings and consider alternative recommendations to address any anomalies discovered. If any external services are used (e.685 Compare estimated versus actual costs and benefits. Determine compliance with installation standards for: • Programming and design standards. A. A. Control. review the planned and actual levels of service. A. If service-level agreements exist between the users and computer operations.684 Determine compliance with service-level agreements. 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. • Training completed. network management). • Operations housekeeping. and • Distributed to the appropriate personnel in a timely manner.

Determine if the reporting.688 Evaluate potential system features improvements. and • Analysis of current schedules.1.. • Additional hardware and use of different systems software (e. determine if the scheduling frequency can be reduced based upon the use or criticality of the scheduled processing inputs and outputs.. • Communications line(s) utilization.687 Identify areas for potential improvement. • The memory utilization by the on-line system's program modules. screen/window inquiry. 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. these areas may require enhancements that are outside the scope of the original development project. A. • Placement of major file disk volumes. 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. and • Database tuning or file placement. they may wish to alter some of the component parts. Consider: • Additional hardware.3Determine Potential Changes and Enhancements Purpose To recommend change or enhancements to the system based upon the review findings. software or tools.689 Evaluate potential scheduling improvements.1. • Changing processing times and frequency. 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. • Network traffic monitoring and tuning.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. A. Overview Potential areas for improvement are identified and a determination is made regarding whether changes or enhancements should be made to the system. • Use of archiving routines to remove historical data records from file(s).690 Evaluate potential response time improvements. Determine if processing time can be improved. for sorts. • The multi-programming level for on-line transaction processing.g. Page 386 .g. back-up or recovery).1. A. In many cases.1. interfaces or data input can be improved. A. e. • Regular re-indexing or file reorganization. peripherals. Determine if system tuning is completed on a regular basis.24. Evaluate such items as: • Input/output wait and application processing time. These areas may require correction to satisfy the original requirements.

THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. • The effectiveness of the hardware and software supplier support.1. A. • Projected operating costs under changed system processing mode. • Improving the level of indexing and/or cross-referencing. Determine if the benefits derived by a change in processing mode justify additional operational and/or systems development expenditures. programming and testing procedures. A. and • Controls relating to information accuracy and timeliness such as data collection. or • Changing the style or target level of the textual or on-line material. • Improving the format and/or organization of the documentation.693 Evaluate potential user and computer operations documentation improvements.1. Determine the effect of the actual practices on the accuracy and timeliness of the information produced by the system. data validation.1. Evaluate such items as: • The effectiveness of programming practices regarding ease of maintenance and operational efficiency. • Access. • Third-party service providers. error correction procedures and sub-system balancing and reconciliation. A. • Tangible benefits such as reduced staff costs. A. Evaluate the effectiveness of: • Design. Potential documentation improvements may include: • Improving training and education. security and back-up procedures.695 Discuss the findings and consider alternative recommendations for changes and enhancements. • Development costs for proposed improvements. • Changing the level of procedure detail.691 Evaluate potential accuracy improvements. • Intangible benefits of proposed improvements. Compare the planned standards and procedures with the actual procedures being exercised. Page 387 .692 Evaluate potential system support services improvements. Benefit and expenditure assessment should include: • Present operating costs. • The Help Desk. • The effectiveness of training. • The change control practices that are being used.1.694 Determine cost effectiveness of suggested enhancements. and • The effectiveness of user Help Desks. and • Implementation costs and time required for proposed improvements.1. • Changing the scope of procedural overviews.

1. Review this deliverable on the basis of content and clarity of presentation.24. prepare an action list of items to modify in the post-implementation review deliverable. or • Overhead slides and graphics can be created to show summary results to support the detailed report. In practice. If necessary. Consolidate the individual parts of the post-implementation review deliverable by packaging together the interim work products into a formal deliverable. Complete the necessary approval procedures to complete CPDEP Phase 5 “Operate and Evaluate”. Traditionally.698 Obtain formal written approval of post-implementation review deliverable and formally close the project. Prepare the post-implementation review deliverable. this step may involve more than one meeting to resolve the outstanding issues.4Submit Post-Implementation Review Deliverable Purpose To formally prepare and present the Post-Implementation Review findings and recommendations to management. This document is reviewed for content and clarity and presented to management. • The "barometer" technique may be appropriate in some circumstances.696 Prepare and review post-implementation review deliverable. A. results of reviews such as this have used reports containing only text to describe and present information. Page 388 .1. A. Complete all of the tasks necessary to formally close the project as stated in the Project Charter and the project proposal. Discuss the post-implementation review with management and resolve any questions and issues. A. Obtain formal written approval of the post-implementation review deliverable.697 Submit and discuss post-implementation review deliverable with management.1. Prepare a draft implementation plan that suggests how the recommendations should be introduced as part of the report. The use of some different graphical techniques may dramatically improve and simplify the review outputs. Overview The outputs from the individual tasks are consolidated into a post-implementation review deliverable.THE SERVICE ARM OF THE FIRM Data Warehousing and Reporting BW Project Plan Methodology A. For example: • A simple graphing of response times as shown may quickly and effectively describe and dispel issues related to response times.

Sign up to vote on this title
UsefulNot useful