Realization

Purpose
The purpose of the realization phase is to implement the business scenario and process requirements based on the business blueprint completed in the previous phase.

Objectives of this phase include: Establishment of the solution landscape Implementation of the final solution in the development environment Overall testing of the solution within the quality environment

Release of the solution for production (live) operations Delivery of training materials Preparation for data migration and data archiving Identification of value delivery concepts Performance testing

Work Streams
The major work streams that are developed for the realization phase are: Project management Review of project management plans for revision, adjustment, and execution of the plans Organizational change management (OCM) Completion of OCM deliverables and activities for readiness and contingency Training Completion of end-user training materials, trainer preparation, the training environment, and data to support training Data management Preparation for legacy data migration and plans for data archiving Business process management Configured processes and monitoring to ensure consistency and continuity in the solution Technical solution management Design, setup, and strategies for enablement of an ongoing robust environment to support the final solution Integrated solution management Completion of functional testing, performance testing, user acceptance testing, regression testing, and preparation for production cutover

Project Management
Purpose
The purpose of the project management phase is to provide essential methodology for the requirements planning for and execution/controlling of an SAP software implementation project.

Team Identification, Allocation, and Coordination

During subsequent phase start-up activities, the project manager coordinates the allocation of resources identified for the project phase using the project schedule and the resource plan. This ensures the proper timing of resource assignments needed to complete project work. The project manager validates the participation and ongoing commitment of the steering committee members at the phase start-up.

Kickoff Meeting The scale of this task varies with project size and complexity. For small, low-risk projects, the kickoff meeting may be an informal review of the process by the project sponsor and the program or project manager. For larger projects, you should consider a formal kickoff of the project to achieve a common understanding of the objectives of the planning process and to clarify t he various participants roles. The project manager clearly defines the objectives of each phase kickoff meeting and designs the agenda to achieve that objective. Consider conducting the following types of meetings: Team-focused meetings should be focused on the team to ensure alignment around the work (definition and approach for outputs) to be performed during the phase. Communications-focused meetings should be focused more on communications across the organization, bringing the project sponsor and key stakeholders together to reinforce commitment to the project and raise awareness across the organization. This type of kickoff could be an important part of the projects organizational change management approach.

The project manager balances these different types of kickoff meetings to ensure that stakeholder time is optimized and project communications needs are met both at a team level and an organizational level.

Project Schedule

The project manager expands and updates the project schedule. At a minimum, the schedule should include the following components: Phase deliverables and tasks Estimated effort (work) and duration Task dependencies such as predecessors and successors Scheduled start and finish dates for each task, based on dependencies Task constraints such as must-start-on date, must-finish-on date, and so on Resources assigned to each task

The project manager uses a rolling wave approach to schedule development to allow the completion of the schedule for the entire project.

Inputs
Project management is relevant to the entire phase and should start only when the previous phase has been signed off.

Deliverables
Deliverables of this deliverable group are: Phase start-up Executing, monitoring, and controlling of results Project management plan completion Phase sign-off

Phase Start-Up
Purpose
The purpose of the phase start-up deliverable is to coordinate the setup of an appropriately sized team and to prepare the team for the activities within the phase. This deliverable ensures the involvement and commitment of the team and other key resources to the project schedule. It also examines the approach for the specific project phase.

Note: The phase start-up for the project preparation phase also includes a handover of information gathered in the pre-implementation project activities.

The phase start-up involves:

Identifying, allocating, and coordinating resources for the team and phase activities Creating, expanding, and updating the project schedule for the phase (consider using a rolling wave approach to schedule development) Preparing for and conducting a phase kickoff meeting and starting the phase project work

Inputs
The inputs for the phase start-up include information from any previous phase sign-offs.

Deliverables
The project management phase start-up generates these deliverables: Allocation of resources to the project team for the specific phase Updated detailed phase schedule Completed phase kickoff meeting

Phase Resources Allocation

Purpose
The purpose of phase resources allocation is a confirmation of resource availability for the particular phase. The resource plan and schedule detail the resource requirements, but in the start of each phase you need to ensure the proper timing of resource assignments needed to complete project work.

Detailed Phase Schedule

Purpose
The Phase Schedule must be defined for the key deliverables of the phase. At minimum, the schedule should include the following components:

Deliverables and tasks for the current phase Estimated effort (work) and duration

Task dependencies (for example, predecessors and successors) Scheduled start and finish dates for each task, based on dependencies Task constraints (for example, must start on date, must finish on date, and so on) Resources assigned to each task High-level schedule for subsequent phases

The project manager builds on this schedule during subsequent planning activities, using a rolling wave approach.

Additional Information
Please Note: Schedule Development (Rolling Wave) During the project preparation phase, the team details the schedule that takes team members through to the end of the business blueprint phase (that is, the planning phase approval checkpoint) only. Activities in later phases are defined and scheduled during the business blueprint phase, using a rolling wave approach, which enables the completion of the schedule for the entire project. Using this approach, the planning team develops schedule details for the next phase (for example, the realization phase) and schedules subsequent phases at a higher level. Re-planning points are scheduled toward the end of each phase (as detailed information for the next phase becomes available) to update the schedule in preparation for the next phase.

Phase Kickoff Meeting

Purpose
The phase kickoff meeting helps ensure the involvement of the team and other key resources and their commitment to the project schedule. The meeting is also used to examine the approach for the specific project phase.

The scale of this activity varies with project size and complexity. For small, low-risk projects, this may be an informal review of the process by the project sponsor and the program or project manager. For larger projects, consider a formal kickoff of the project to achieve a common understanding of the objectives of the planning process and to clarify the various participants roles.

The project manager must clearly define the objectives of each phase kickoff meeting and design the agenda to achieve that objective. Consider conducting the following types of meetings:

Team-focused meetings should be focused on team members to ensure alignment around the work (definition and approach for outputs) to be performed during the phase.

Communications-focused meetings should be focused more on communications across the organization, bringing the project sponsor and key stakeholders together to reinforce commitment to the project and to raise awareness. This type of kickoff could be an important part of the projects organizational change management approach.

The project manager balances these different types of kickoff meetings to ensure that stakeholder time is optimized and project communications needs are met -- both at a team level and an organizational level.

Inputs
The inputs for the phase kickoff meeting include information from any previous phase sign-offs.

Subdeliverables
This step generates:

Project team ramp-up training (ideally conducted before the blueprint phase) Allocation of resources to the project team for the specific phase Updated detailed phase schedule Completed phase kickoff meeting

Phase Closure and Sign-Off

Purpose
The purpose of the phase closure and sign-off deliverable is to: Ensure that all required deliverables from this phase and the project are complete and accurate, and close any outstanding issues Identify lessons learned during the phase to prepare for formal project closure Capture customer feedback and potential Customer References

When sign-off is obtained, the project can be closed.

Inputs
This deliverable has the following inputs: Project documentation including status reports, risk and change logs and schedule for the phase Phase-specific deliverables - Project deliverables are the key tangible products of the project. The team must complete these deliverables, and the customer must approve and accept the deliverables prior to closing. The deliverables acceptance is the deliverable that documents the customers acceptance of the projects deliverables. Lessons learned - As part of each project management process (or life-cycle phase), the project manager should capture lessons learned. They should review lessons learned from previous processes and phases, as well as lessons learned from similar projects.

This deliverable is triggered by the completion of the project.

Deliverables
This deliverable generates: Lessons-learned log Project Quality Gate scorecard

Project Management Review report

Phase acceptance and project closure report

Lessons-Learned Log Updates

Purpose
It is good project and knowledge management practice to collect knowledge assets and lessons learned at the end of each phase of the project. Collecting documents, experiences, project highlights and lessons learned throughout the duration of the project can help to facilitate the project by providing quick access and insights into key deliverables from earlier stages of the project. The quality of the information collected will be higher if collected while the project team is still focused on what happened during a particular project phase because information will be fresh in the minds of the project team. This knowledge will then continue to live on past the projects completion, helping us to ensure we can expedite delivery of future projects more successfully.

Deliverables
Lessons Learned Template

The project team collects and documents the lessons learned in the lessons-learned template that is made available to the project team and shared with other projects in the organization. During the process of collecting lessons-learned, remember to engage SAP (PMO, Consultants, GDC, AGS, Sales, etc.), customers, partners, and any other third party resources who may have been involved with the project. Accurately tracking all resources who work on a project will help greatly in this process

Project Quality Gate

Purpose
The purpose of the Project Quality Gate is to provide a quality check at critical stages of the project. Project Quality Gates are an integral part of SAPs Quality Built In approach for SAP primed, partner or client led projects. The objectives of the Project Quality Gate are: To assure that all key deliverables and actions of the gate have been completed in compliance with recommended practices and to the customers satisfaction To enable project management to continuously communicate the process and build quality directly into the project

To provide a tool to effectively manage project expectations and monitor customer satisfaction

Project Quality Gates are defined in the Project Management Plan and are set at critical stages in the project lifecycle. Four quality gates are mandatory and the other three quality gates are optional as agreed with the customer: Project Preparation Phase - mandatory Business Blueprint Phase - mandatory Baseline Configuration - optional Final Configuration (Solution Built) - optional Realization Phase (Integration Tests of Realization Completed) - mandatory Final Preparation Completed (Go Live Readiness) - mandatory Completed Project (Project Closure) - optional

Inputs
The inputs to this deliverable are the completion of all documents, activities and WBS elements to the satisfaction of the client as identified in the project WBS.

Expected results
The Project Quality Gate delivers a scorecard that records the results of the quality review of each individual key deliverable. Quality gate is passed. There may be some action items in place in order to complete or improve certain deliverables. Quality gate is not passed. Action items are defined for follow-up by the project team. Project Manager requests a second assessment to re-evaluate the deliverables with action items.

Project Management Review

Purpose
The purpose of Project Management Review is to provide a proactive quality assurance review, with an impartial analysis of all aspects of the project across all project management disciplines, enabling early detection of project issues with actionable recommendations.

The Review of Project Management Service is intended for customers implementing SAP solutions. These projects may have SAP as the prime integrator, SAP playing a support role, or no direct SAP implementation involvement. Review of Project Management Service is an integral part of Quality Built In and provides the following business benefits: Fast identification of implementation risks early in the process to accelerate project delivery Validation that appropriate goals, timelines, and milestones are being met Effective sharing of best practices and recommendations for needed improvements to keep the project on-time and within budget Identification of business opportunities resulting from effective monitoring of the project's progress

The project review service provides consistent quality assurance to protect customer software investment throughout the implementation lifecycle. The service is composed of five logically-sequenced and interrelated reviews performed at different phases in the implementation roadmap: Project Preparation at the end of phase Business Blueprint at the end of phase Realization during configuration cycle, before integration testing. Final Preparation 2-4 weeks before going live Go-live and Support approximately 4 weeks after going live

Inputs
The review involves a structured approach in assessing the project implementation process. The review consultant plans the on-site review based on a series of scheduled interviews with key stakeholders, project team leads and team members and reviews a list of requested project management documents that is specific to each project phase. In addition, the Review of Project Management Methodology provides structured content, guidelines and questionnaires used as input to the interviews.

Deliverables
The Project Management Review delivers the following results: Report Executive Summary Summarizes the Key Findings Report for management. Report Customer Report Highlights risk related findings and recommendations for what needs to be done to keep a project on-track. Detailed Report Comprehensive risk related detailed findings and detailed recommendations for what needs to be done to keep a project on-track.

Phase Acceptance and Closure

Purpose
The purpose of phase acceptance and closure is to formally accept completeness and correctness of all phase deliverables before starting the next project phase.

Inputs
The inputs to phase acceptance and closure include: Project management plan Project executing, monitoring, and controlling of results Lessons-learned log updates Project Quality Gate scorecard Project Management Review report

Subdeliverables
The outputs of phase acceptance and closure include: Performance of the administrative phase closure process needed to: Collect project phase deliverables Analyze phase success or failure Collect and communicate project phase performance metrics (that is, open risks and issues, approved change requests, and deliverable metrics by team) Summarize lessons learned Prepare a phase closure presentation to obtain phase approval and sign-off to proceed to next phase

Phase closure document: formal acceptance and confirmation from the customer and sponsor that project phase requirements and specifications for the project have been met. This document formally indicates that the customer or sponsor has officially accepted the deliverables. The list of parties required to sign off is governed by the project organizational structure. Typically, sign-off is required from project managers and the project sponsor or steering committee. Project debriefing via tool or template

If it is Not Done
Skipping this step means the customer has not accepted project phase deliverables. The project manager will not be able to successfully manage project scope, the related integrated change control process for the project work to be accomplished, and the deliverables that need to be executed in the next phase of the project.

Organizational Change Management

Purpose
Organizational change management (OCM) is a structured approach to transitioning individuals, teams, and organizations from a current state to a desired future state. The current definition of OCM includes both OCM processes and individual change management models, which together are used to manage the people side of change. Research continues to show that OCM contributes significantly to the overall project success. OCM is one of the primary success factors in SAP projects. Implementing SAP software typically involves numerous organizational, technological, and social changes. OCM focuses on the effects these changes have on managers and employees. This particularly concerns new ways of thinking or behaving but also deals with new competencies and skills required.

The following Global OCM Framework shows the major OCM work streams that are active during a project.

The following figure provides the details for each of these framework elements for the Realization Phase. Not all the elements shown represent key deliverables. A number of the items are activities that support the development of the key deliverables or support the development of key deliverable in future phases.

Key Inputs
The inputs required for OCM are: OCM Strategy & Roadmap / Plan Stakeholder Analysis Communication Plan Performance Management Activities from Blueprint Monitoring Activities from Blueprint

Deliverables
The major deliverables generated from OCM in the Realization phase (shown in orange) are: Stakeholder Analysis Communication Activities / Plan Update Role Mapping Sounding Boards

Key Activities to Support Deliverables

There are several key activities that are conducted in the Realization Phase to support the development of the deliverables for this phase, future phases, or other project roles (shown in blue). Guides for these activities have been included in the Accelerators:

Setup & Governance Workstream Continuing OCM Roadmap / Plan Updates

Stakeholder Management Workstream Continuing to Manage Change Agent Network

Communication Workstream Communication Strategy Continuing to Update Communication Plan

Organizational Alignment Change Impact Analysis Detailed Level Business Validation / Readiness / Transition Planning

Performance Management Workstream Continuing Project Team Building & Recognition Continuing Project Team Internal & External Knowledge Transfer

Monitoring Workstream Project Status

Stakeholder Management Communication Effectiveness Project Team Checks

Role Mapping
Purpose
Most SAP software implementations significantly change the skills and behaviors of individuals who use the system, even those who are indirectly affected. Role mapping will guide teams through the process of linking structural concepts and organizational principles with the roles defined through the scripting process.

Typical impacts for users in an SAP software implementation include:

Changes to positions and responsibilities, due to redesigned business processes Changing nature of relationships with other business units, due to integration Changes in the organizational culture or behavior (such as right first time" attitude to data entry and independence through reporting) New skills, not only in SAP technology but also in general computer literacy

Critical Success Factors Ensure involvement, ownership, and accuracy: The involvement of business and line management in completing role mapping is critical to the success and ownership of the new processes. Line managers are responsible for the allocation of work and have a clear idea of the current job content of their workforce. Inadequate involvement will limit the business capacity to own the change.

Ensure that role mapping is a priority throughout the project: In a changing environment, the user base impacted by the SAP software implementation is continually changing. This, coupled with system development changes, requires that a dedicated group manage the process throughout the various phases of the project.

Inputs
The inputs required for role mapping are: User role documents from the business blueprint Knowledge about the current customer organizational structure Knowledge about the current job descriptions To-be processes from the business blueprint Knowledge about organizational restrictions on the customer side (not all roles and jobs are able to implement, because of, for example, provisos from workers' council or HR policies)

Deliverables
The major deliverables of role mapping are: Description of the necessary roles on the customer side (including new roles) Mapping of roles to positions to support the new processes (position mapping) Creation of a matrix to link positions to deployed business-specific jobs (to include current and new roles from current, new, and eliminated positions) Transition matrix for people to positions and new jobs Creation of a recommended organizational chart to reflect the logical groupings of jobs and new reporting relationships

Sounding Board
Purpose
A sounding board is a two- to three-hour workshop with at least 20 people from the customer organization to get complex organizational feedback regarding the progress and acceptance of the project from the customers view. The main objectives of the sounding board are to:

Gather feedback from the inside about spirit within the organization and perceived progress of a change process Use participants to funnel feedback from employees to management and from management to employees Be able to proactively react to concerns within the organization before escalation Identify key topics for the change process (successes, pain points, and so on) Validate planned communication and change activities

Goals of the Sounding Board A fixed set of participants meets on a regular basis (such as quarterly or according to project milestones) for open dialogue. Participants collect feedback from their colleagues and act as spokespersons for their respective units and teams, as well communicate discussed points and action steps back into the organization. A neutral facilitator leads throughout meeting (two to three hours), using a question catalog. Participants should be from all affected units and teams Results and comments are made anonymous and are reported in a consolidated way back to the management team. The time period between two sounding boards should be long enough to be able to react to feedback and to implement required action items (feel the change).

Inputs
The inputs for the sounding board are: Organizational change management roadmap Organizational roles and responsibilities

Deliverables
The major deliverables of the sounding board are: Updated communication plan and activities Updated stakeholder plan and activities

Communication Activities

Purpose
The communication activities deliverable is the doing element of the communications plan and results in the development and publication of the messages and vehicles described in the plan. The main activities are as follows: Confirm the messages to be delivered and the target audiences Agree on the measures of success Create the message and vehicle for communication (such as newsletter, intranet, speech, and memo) Gain approval, and sign off the message and vehicle Publish and announce

Tools typically used to support and deliver this include:

Newsletter Glossary

FAQ One-page document Intranet

Communication as Strategic Weapon A core element of the communication strategy is communication planning. It identifies key stakeholder groups and the required communication intervention to ensure the desired impact. The output is the communication plan.

Inputs
The input for communication activities is the communication management plan (a subdeliverable from the project preparation phase, the project management work stream).

Deliverables
The major deliverable of communication activities is a communication plan in which all planned communication activities are included.

Training
Purpose

The purpose of the training work stream is to conduct level 3 project team training and finalize the enduser training materials and documentations. The other main purpose of training in the realization phase is the development of end-user training guides and the training documentation.

Inputs
Project team training (levels 1 and 2) has been conducted in the project preparation phase and the business blueprint phase so that team members can obtain an overview of the business processes or technical features in their area. This level 3 training, with a focus on detailed business process courses and detailed technical courses, enables the project team to start to match the company requirements with SAP software functions.

Deliverables
The major deliverables that should be generated as a result of the training work stream are the definition, development, and finalization of end-user training documentation. Important tasks during this work stream include the following: Level 3 project team training Creation of end-user materials or deployment of prebuilt content Preparation and conducting of a course to train the trainers Finalization of the training environment and systems, and a refresh of the training strategy (reset of training systems)

During this work stream, the standards and review processes for training content and training documentation development are set and an evaluation and improvement process is defined. This information is communicated to the course developers, and the course outlines are developed. Level 3 project team training is conducted so that team members can obtain an overview of the business processes or technical features in their area. This training shows the business and technical options available to the company and how to configure the system to meet company needs.

Within the project team, the person responsible for these tasks is the training documentation coordinator.

This work stream includes the following deliverables: End-user training documentation

End-user training curriculum

Integration
After completing this training, the main purpose of the final preparation phase is to ensure that all end users are adequately trained (general SAP software training, as well as company-specific SAP software training) before the SAP software go-live date.

In the go-live support phase, post-go-live end-user training is provided. Also, the evaluation of ongoing performance is completed, as well as the determination of the additional training support needed.

Project Team Level 3 Skills Development

Purpose
The purpose of the project team level 3 skills development deliverable is to educate core project team members on how to configure the SAP solution within each members respective functional or technical area of responsibility.

Inputs
The input for project team level 3 skills development is the project

team training strategy deliverable

of the project preparation phase.

Deliverables
The deliverable for project team level 3 skills development is, as in earlier phases, a cross-reference of the project team members roles and responsibilities and the SAP course curric ulum. The cross-reference activity determines which courses each team member should attend. Level 3 training should focus on acquiring the detailed knowledge necessary to complete the implementation and configuration.

If It Is Not Done

If project team level 3 skills development is not completed, project team members do not receive adequate level 3 training or they receive no training at all prior to the commencement of configuration; knowledge of SAP software configuration will not be properly transferred to the customer project team. This results in a higher total cost of ownership.

In most cases, it is a sound IT and business practice for companies implementing SAP software to cultivate configuration knowledge to reduce the total cost of ownership and to support the system once it is live. Thus, level 3 training has a direct impact on the success of the project.

Additional Information
When possible, level 3 training courses should occur prior to the scheduled configuration of a given functional or technical area of the SAP software system. The registration of these courses should be filtered through one person in order to control costs, avoid confusion, and avoid double bookings. The project team training plan and budget should be updated once the team members are registered.

End-User Training and Documentation Development

Purpose
The purpose of the end-user training and documentation development deliverable is to ensure a consistent appearance of the training materials and documentation by providing the development team with standard templates. This deliverable also includes training course outlines, which identify the training topics in each course, the training data-collection process, and the training content creation and review processes.

Inputs
The inputs for end-user training and documentation development are: Learning needs analysis (business blueprint phase) Learning and deployment strategy (business blueprint phase) Content development (business blueprint phase) Approved business blueprint Subject matter experts

Deliverables

The main deliverable for end-user training and documentation is a set of working templates and content that adhere to standards, encourage uniformity, and map to the learning paths for end users as defined by the training needs analysis.

Before content creation can begin, template creation, based on the types of end-user training and documentation planned, must occur. For example, if end-user training will be delivered via instructor-led training, it is then essential to create presentation, instructor guide, exercise, and solution templates; if the content is to be Web-based, then storyboards and tool-recording and design standards must be created. When creating templates, take into consideration any corporate training material, documentation, and ISO standards.

The standardized templates for preparation of the course contents should be finalized. These templates are standardized across all courses to be covered for end-user training.

For end-user documentation, the layout, headings, project details, module information templates, and basic information about the business process should be finalized. This documentation should also contain the details of individual transactions and step-by-step instructions on how to execute the transactions.

Training course outlines are developed with the help of a detailed scope document, usually in the form of a business process hierarchy within the SAP Solution Manager application management solution. This provides the necessary transactional detail that should be included in the courses. It is also helpful to refer to the enterprise-wide role matrix (if available at the time), as this tells you what the end users will ultimately have access to in the production system.

The training data collection and review procedures should include information about the overall process and who is involved. These procedures should include input from the business process team leads and owners, power users, and content developers. The procedures should be developed by the end-user training lead and communicated by the overall project manager in order to establish the commitment of team members outside of the training team.

If It Is Not Done
If templates are not created, the training and documentation materials will not have a consistent look and feel, and they will be disorganized. They will require additional, redundant work to make them consistent, which will cost time and money. If training course outlines are not developed prior to commencing the development of training materials and documentation, there will be a lack of direction. Also, there will not be any assurance that all of the necessary in-scope business processes and transactions are accounted for, and there will be potential for overlap or gaps between training courses.

If the data-collection and review process is not clearly defined up-front and early, little guidance can be provided. Moreover, there can be no assurance that the materials are being properly reviewed. Finally, there will be a lack of commitment from the project teams outside of training.

Training Master Data Requirements

Purpose
The purpose of the training master data requirements subdeliverable is to provide a process for gathering the key information that will serve as the raw content of the training materials and training documentation.

Inputs
The inputs for training master data requirements are: Business process procedures (BPPs) Business blueprint content Business process models Interviews with subject matter experts (SMEs) Current and redesigned supporting business processes Information on transactions per user role

Subdeliverables
The subdeliverable for training master data requirements is a list of sample transactions and data that can be used to build scenarios during the creation of content.

If It Is Not Done
The training-content developers must have access to the training system and client that should be set up by a client copy of the latest development environment. If the training master data requirements deliverable is not done, the development of proper end-user training material and training documentation cannot succeed or even be started.

Expected Results
By completing training master data requirements correctly, the project team can start the development of training materials. The training-content developers must have access to the training system and client that should be set up by a client copy of the latest development environment. It is helpful for the training materials to contain organizational change impacts, where appropriate and applicable, in order to explain an overall business process. However, there should also be an opportunity for presentations of change information, prior to end-user training rollout, which specifically address organizational changes.

Courseware Developers Workshop

Purpose
The purpose of the courseware developers workshop subdeliverable is to familiarize the courseware developers responsible for content creation and customization with the way to use the content roadmap, development standards, instructional design standards, and the authoring environment.

Inputs
The inputs for the content developers workshop are: Training project plan (detailed) (business blueprint phase) Content development (business blueprint phase) Content development standards (business blueprint phase)

Subdeliverables
The subdeliverable for the content developers workshop is a half-day to full-day workshop covering all aspects of the courseware development process and standards.

If It Is Not Done
By not completing the content developers workshop correctly, the project team runs the risk of not having the training content be created or customized in a standard and streamlined fashion.

Curriculum Development and Customization

Purpose
The purpose of the curriculum development and customization subdeliverable is to develop the curriculum content that needs to be created or customized (if content was purchased) in order to serve end users. This subdeliverable also shows, for each end-user role, which course is necessary and what dependencies exist between the different courses. It also provides a learning map that shows in which order the courses should be attended or taken.

Inputs
The inputs for curriculum development and customization are: Learning needs analysis (business blueprint phase) Training project plan (detailed) (business blueprint phase) Authoring tool environment (business blueprint phase)

Subdeliverables
The subdeliverable for curriculum development and customization is a uniformly created or customized set of end-user content that adheres to the training strategy and to defined creation guidelines.

Expected Results
By completing the subdeliverable correctly, the project team gains a library of end-user content that can be used to efficiently train end users during the final preparation phase.

Training Environment Population and Testing

Purpose
The purpose of the training environment population and testing deliverable is to ensure that the training environment is correctly populated with correct data for training. Additionally, this deliverable should also verify that the refresh strategy proposed is working properly.

Inputs
The inputs for training environment population and testing are:

Training environment strategy (business blueprint phase) Master data requirements (business blueprint phase)

Deliverables

The deliverable for training environment population and testing is a completed checklist that demonstrates that the environment is being populated and refreshing correctly.

Expected Results

Completing the deliverable correctly ensures that the training environment is ready for the final preparation phase.

Training Roles Security Mapping

Purpose
The purpose of the training roles security mapping deliverable is to ensure that the training roles are correctly mapped to the security profiles for the training environment. After mapping is complete, the security configuration should be tested to ensure it is working properly.

Inputs
Inputs for training roles security mapping include: Role mapping (business blueprint phase) Training environment strategy (business blueprint phase)

Deliverables
The deliverable for training roles security mapping is a completed security configuration to support the user roles required for training.

If It Is Not Done
By not completing the deliverable correctly, the project team will find it very difficult to ensure that the training environment will work correctly for all users. This step is imperative for seamless training delivery.

Training of the Trainers

Purpose
The purpose of the training of the trainers deliverable is to provide a detailed outline of presentations and activities that serve to educate and prepare the trainers scheduled to instruct end-user training classes.

Inputs
Inputs for the deliverable include: Curriculum development (realization phase) Training environment strategy (business blueprint phase) List of identified trainers

Deliverables
The deliverable for training of the trainers is a portfolio or course manual that includes the following: Presentations of associated training documents, instructor guides, and exercises Assignment of data for practice and for the course Adult learning theory and styles Contact list for questions and training emergencies Instruction on how to reset passwords and unlock users Procedures for submitting course evaluations

The course to train the trainers is led by the end-user training lead, with presentations of the training materials provided by the content developers. It is good practice to have business process team members and owners present or on call to answer specific content questions.

Expected Results

By completing the deliverable correctly, the project team assures that the trainers are well-prepared and ready to conduct end-user training. If the course does not occur, trainers will lack the knowledge to pass on to their colleagues, and end users will not be prepared for the new solution.

End-User Training Schedule and Logistics

Purpose
The purpose of the end-user training schedule and logistics deliverable is to prepare the rollout of end-user training by mapping end users to appropriate training courses, developing a training schedule and logistics plan, and inviting end users to courses.

Inputs
The inputs for end-user training schedule and logistics are: List of end users to be trained and their profiles and skill levels Learning needs analysis (business blueprint phase) List of trainers who have completed the training of the trainers deliverable Training infrastructure checklist (business blueprint phase) Training environment strategy (business blueprint phase) Training location checklist (realization phase, this deliverable)

Deliverables
The deliverables for end-user training schedule and logistics are: Matrix of training locations, delivery dates, and courses or topics to be taught Communication to end users regarding enrollment and other procedures for attending class Checklist of system accessibility, PC requirements, and testing of roles by location

Expected Results

The expected result of building a training schedule is that the training phase of the project is delivered in a systematic and organized manner with all responsible parties aware of what training is occurring. It also ensures the readiness of all locations to conduct training.

Additional Information
Training courses are scheduled with consideration given to the number of available training resources and facilities. Trainers are committed to specific training classes and complete the course to train the trainers prior to the commencement of end-user training.

The end-user training lead requires the names of all end users affected by the implementation and their roles in the organization. The lead obtains the names from HR, company department managers, or the authorizations team. On the basis of each role, users are assigned to training courses. Consideration is given to work shifts and to the need to ensure adequate coverage in the office while end users are attending courses.

The training system is tested by either the content developers or the trainers. It is good practice to have trainers test the data in the training system to increase their proficiency in the system and build confidence.

Education Readiness Review

Purpose
The purpose of education readiness review is to determine the potential issues with the SAP education strategy and solution before they impact the quality of the SAP software deployment.

Inputs
The inputs for education readiness review are: Learning and deployment strategy (business blueprint phase) End-user training and documentation development (realization phase) Status reports or updates from education deliverables

Deliverables
The deliverable for education readiness review is a complete report that identifies the outstanding issues and the activities required to resolve those issues.

Expected Results

Completing the deliverable correctly ensures that the education team is aware of the remaining activities that must be completed to deliver a successful education solution.

Data Management

Purpose
The purpose of the data management work stream is to develop manual or automatic procedures and programs to migrate data from a legacy environment into the SAP software system prior to integration testing and going live. At the same time, this data is cleansed, and SAP software fields are automatically populated. This data can be new transactional or master data. In addition, the data management work stream establishes the procedures and test plans as defined in the business blueprint phase and in accordance with the IT data archiving standards, to keep the volume of system data under long-term control. The primary function of data archiving is to remove data that is not required in the SAP software system but that can become accessible by the SAP software in the future.

Inputs
The inputs for data management are: Data quality assessment Data migration design Manual data migration procedures Data quality plan Data security design Testing strategy Business requirements for data archiving Enterprise IT strategy IT requirements for data archiving Stipulations for data retention

Deliverables
The deliverables that should be generated as a result of the data management work stream are: Legacy data migration Data archiving

Integration
The integration point for the data management work stream is integrated solution management in the preliminary cutover plan. The preliminary cutover plan includes the timing, steps, and logistics for moving from the as-is solution to the to-be solution. Important components of the preliminary cutover plan are the details around data migration.

Legacy Data Migration

Purpose
The purpose of the legacy data migration deliverable is to develop, implement, and test the data migration programs and processes defined in the business blueprint phase. This activity consists of iterative development and testing cycles focused on the analysis of data, refinement of business rules, and deployment of migration programs and processes designed to move, cleanse, transform, and enrich legacy data required to support the various test cycles and ultimately the production cutover. The test cycles enable the migration team to improve data quality to an acceptable production level, develop a detailed cutover sequencing plan, and exercise data reconciliation and validation processes required to support the production cutover.

Inputs
The inputs for legacy data migration are: Data quality assessment Data migration design Manual data migration procedures Data quality plan Data security design Testing strategy Configured SAP software conversion environment

Deliverables

The deliverables for legacy data migration are: Data profiling scripts Final data quality assessment Data migration program units Manual data migration Data quality reports Delivery of SAP software load-ready data Data migration test results

Expected Results
By completing the deliverable, the project team deploys and validates a data migration solution required to deliver the legacy data to support go-live.

Data Profiling Scripts

Purpose
The purpose of the data profiling scripts subdeliverable is to establish a repeatable set of programs or processes that will interrogate the data and provide insight into the quality of legacy data to support data analysis and the design and development of business, transformation, enrichment, and cleansing rules for the data migration solution. Legacy or source data is not static, so establishing a structured approach for continuous monitoring is essential to ensure that the migration solution addresses data anomalies and quality issues over time.

Inputs
The inputs for data profiling scripts are: Data quality assessment Data migration design Data migration scope and requirements

Subdeliverables
The subdeliverables for data profiling scripts are the development and the delivery of the final profiling scripts that support the migration analysis, design, and development activities. The scripts should have the ability to analyze data at the summary or table level and at the data element level. The scripts should generate statistical reports describing the quality of the data sets. The common data profiling logic or rules include existence, uniqueness, range, frequency, pattern, format, occurrence, and referential integrity.

Expected Results
By completing the subdeliverable, the migration team deploys an effective and efficient approach to accurately assess the quality of the legacy data for planning, developing, and managing the deployment of the data migration solution. Since legacy or source data can change as a result of business or technology initiatives, the profiling scripts provide the migration team with a repeatable solution to monitor and react to change throughout the realization phase.

Final Data Quality Assessment

Purpose
The purpose of the final data quality assessment subdeliverable is to provide one final assessment at the end of the realization phase to report on the quality of the converted legacy data before moving into the final preparation phase. The tasks involved in the assessment include: Updating the data mappings and business rules on the basis of discoveries found during the iterative executions of the data migration program and processes Performing data profiling on a subset of the SAP software load-ready data to validate the results shown in the data quality reports (During the execution of the data migration program and processes, new data anomalies could emerge, and the goal of data profiling is to mitigate the risk of false positives.) Summarizing the results from the data quality reports into a final data quality report

Inputs
The inputs for final data quality assessment include: Data quality assessment Data quality plan

Subdeliverables
The subdeliverable of final data quality assessment is a final data quality report. Once all tests and queries have been conducted, the data migration team compiles the results and requests a preliminary review by the data owners and subject matter experts (SMEs). Once the data owners and SMEs have provided feedback, the team prepares the final findings as a written report or verbal presentations to be delivered to key stakeholders. Depending on the requirements, the final data quality report includes topics such as: Updated data mappings and business rules Summary of data quality metrics for all the business objects Data profiling results of selected data Any outstanding data quality issues that need to be resolved

Expected Results

By completing the subdeliverable, the data migration team can move into the final preparation phase with the confidence that the vast majority of data quality issues and migration issues have been resolved and mitigated.

Data Migration Program Units

Purpose
The purpose of the data migration program units subdeliverable is to develop the specific architecture, programs, and processes that support the extraction, validation, harmonization, enrichment, and cleansing of the legacy data. The actual programs and processes directly depend on the tools and utilities deployed and available for the engagement. These deliverables can range from fully automated programs based on an extract, transform, and load (ETL) software platform to a series of manual processes based on tools such as Microsoft Excel and Microsoft SQL Server.

Inputs
The inputs for data migration program units are: Data migration designs

Data quality assessment

Subdeliverables
The subdeliverables for data migration program units are the individual programs and processes that make up the data migration solution. For a solution based on a tools platform, the typical architecture and programs include: Data repository to store raw legacy data, SAP software configuration or reference data, data quality metrics, and load-ready data ETL programs for moving, harmonizing, enriching, and validating the source and SAP software configuration data Data quality programs for cleansing source data

Expected Results
By completing the subdeliverable correctly, the project team establishes the program and processes that make up the data migration solution. The migration solution enables the project team to accurately and efficiently migrate the legacy data for the new application implementation.

Manual Data Migration

Purpose
The purpose of the manual data migration subdeliverable is to execute and validate the manual conversion as described in the manual data migration plan subdeliverable in the business blueprint phase. The delivery of the manual conversion data is required to support the testing cycles, application configuration, RICEFW objects, and automated data migration. Through the testing process, the migration and test teams establish the validation and reconciliation process to ensure quality for manually entered data.

Inputs
The input for manual data migration is the manual data migration plan.

Subdeliverables
The subdeliverable for manual data migration is the validated execution plan and the manually converted data required to support the realization phase.

Expected Results
By completing the subdeliverable correctly, the project team populates the new application environment with the necessary data to support the other work streams that have dependencies to the data, as well as establishes the plan and procedures to support the production cutover.

Data Quality Reports

Purpose
The purpose of the data quality reports subdeliverable is to visualize the data quality metrics defined in the data quality plan subdeliverable in the business blueprint phase and provide the project team with a data governance process to monitor and manage the data quality of the converted legacy data throughout the development, testing, and execution of the data migration program jobs. During the execution of the data migration programs and processes, the data quality metrics need to be captured to provide visibility to data accuracy and progress throughout the testing cycles.

Inputs
The input for data quality reports is the data quality plan.

Subdeliverables
The subdeliverables for data quality reports are reports that are manually or automatically generated to track the progress of data quality throughout the various test cycles. The report generator method and formats vary by engagement and directly depend on the tools and utilities that are deployed and available for the engagement. The key metrics include: Execution load date Business object name Number of records processed Number of error records encountered Description of error conditions

Expected Results
By completing the subdeliverable correctly, the project team can effectively monitor and track the progress of data quality through the realization and final preparation phases. Data quality is considered one of the biggest risks for any data migration project.

SAP Load-Ready Data

Purpose
The purpose of the SAP load-ready data subdeliverable is to provide migrated legacy data in a format that supports the standard SAP load utilities. The load-ready data is used to support the various test cycles, production cutover simulation, and eventual go-live activities. The data is produced through the data migration framework and is generated multiple times to support the specific milestones.

Inputs
The input for the subdeliverable is legacy data.

Subdeliverables
The subdeliverable for SAP load-ready data is the delivery of migrated legacy data in the format to support the standard SAP load utilities. This data is cleansed, and harmonized data is generated through the data migration framework. The data will be used to support the testing cycles and eventual production cutover.

Expected Results
By completing the subdeliverable correctly, the project team delivers the data required by the load utilities to populate the SAP application. The population of master and transaction data enables the project team to complete the testing cycles and determine production readiness.

SAP Target Load

Purpose
The purpose of the SAP target load subdeliverable is to load the cleansed legacy data into the SAP software target structures using a standard SAP load utility such as LSMW. Cleansed legacy data is produced by the data migration program units subdeliverable as an intermediate step before final

loading into SAP software. Once the cleansed data is pushed into the SAP software target structures using the SAP load utility, production cutover simulation can proceed.

Inputs
The inputs for the subdeliverable are: Cleansed legacy data Data migration program units

Subdeliverables
The subdeliverable for SAP target load is the delivery of cleansed legacy data in the SAP software target structures. The data is used to support the testing cycles and eventual production cutover.

Expected Results
By completing the subdeliverable correctly, the project team delivers the master and transactional data required by the SAP application to run transactions. The population of master and transaction data enables the project team to complete the testing cycles and determine production readiness.

Data Migration Test Results

Purpose
The purpose of the data migration test results subdeliverable is to report the results of the various test cycles so the team can monitor the accuracy and efficiency of the data migration solution. The test results provide visibility into the data quality throughout the multiple test iterations to show results for a specific migration run and progress over time. The test results for the legacy data migration deliverable are input to the overall test reporting process.

Inputs
The inputs for the subdeliverable are: Testing strategy Execution of test cycles

Subdeliverables
The subdeliverables for data migration test results are statistics that provide a detailed account of data quality issues and successfully loaded data. The test results may be stored in a data repository or through a manual method, depending on the tools and utilities deployed and available for the engagement. The metrics should be available at summary and detailed levels. The test results for the legacy data migration deliverable are a subcomponent of the overall test reporting process.

Expected Results
By completing the subdeliverable correctly, the project team gains visibility into the progress for each of the data migration iterations and gains the information to determine the level of readiness of the data. The reports also identify trends in data quality that may indicate changes to source data over time as a result of business or technology initiatives within the customers legacy environments.

SAP Data Archiving

Purpose
The purpose of the SAP data archiving deliverable is to provide a method to check, remove, and store data that has completed its lifecycle within the solution. Data that meets the check criteria of data retention rules and is no longer actively used in the system can be archived and deleted. Storage of the data is a secondary process to enable data that has been archived and deleted to still be viewed and reported on even though the data is no longer stored on the transactional system.

Inputs
The inputs for the deliverable are: The processes to perform data archiving on the solution Data retention rule checking Extracting and writing of the data and related indexes for the archived data after the data has met the solutions standard data archive check requirements to determine that the data is not longer active Standard functionality to populate data in archive compressed format and store the data in files outside the core solution

Deliverables
The deliverable for SAP data archiving is the archiving of data storage and removal of redundant system data.

Expected Results
By completing the deliverable correctly, the project team has provided the customer with stored businesscompleted data. The customers database growth will be slowed by the archiving and deletion of business-completed data.

Legal and Business Retention Requirements

Purpose
Legal and business retention requirements for the data archive are developed based on customer requirements dictated by evaluation of the companys legal, statutory, and business process requirements. A customers local and country requirements are evaluat ed, along with corporate retention policies.

Inputs

Each data archive object has specific selection criteria that are considered when you are planning data archive, data legal, and business retention requirements configuration rules with the business application teams at the customer site. The legal and business retention requirements rules are significant inputs to the execution of each data archive run and guideline retention times. The retention dates configured for each application and object are verified during data archiving, and these schedule requirements must be met before data can be considered for data archiving.

If It Is Not Done
The legal data retention policy establishes the baseline data archive and removal plan. If this subdeliverable is not done, the customers legal and business requirement s may not be met. The risk is that data archive execution runs will archive and delete some objects that should still be retained in the enterprise solution.

Data Archive Plan

Purpose
The data archive plan is developed on the basis of customer requirements and is dictated by data growth, performance issues, and data retention and destruction requirements. These process steps provide a clear list of business objects candidates for data archiving. The process steps also provide a means of estimating how effective this data archiving will be in removing data from the database. The archive process itself can be run in test mode to more accurately measure how many objects are likely to be archived on the basis of rules and configured retention policies.

Inputs
The data archive plan subdeliverable has specific steps that guide the planning for data archiving of the business objects at the customer site. The data archive plan and the data retention and destruction policies must be defined as the foundations for the execution of each data archive run and the guideline retention times. Individual object archiving can be planned as phased implementations tailored to a customers specific requirements.

Expected Results
The expected results of the data archive plan are long- and short-term data archive plans that successfully support the customers current as well as planned data archiving requirements. These plans include what should be archived from the solution as well as what should be archived in long-term storage after the objects have been archived from the customers solution in way that fulfills the customer's stated archive requirements.

Data Archive Storage Plan

Purpose
The data archive storage plan is developed on the basis of customer data storage requirements. Partner storage servers are often employed, and these will require specific partner storage configuration elements usually configured in the content server definition. The data archive storage plan is usually dictated by customer storage requirements. For example, magnetic storage may be required on the basis of corporate policy, data growth, performance issues, and data retention and destruction requirements. Once configured, the archive will store the archived data objects and index them according to the configuration of the SAP ArchiveLink software. The content server part of the configuration of SAP ArchiveLink guides this process.

Inputs
The data archive object is linked to the storage server in configuration of the tables of SAP ArchiveLink. The software provides the storage plan for the execution of each data archive run and creates the indexes for each archive execution.

Expected Results
The expected results of the data archive storage plan subdeliverable are long- and short-term data archive storage plans for data archive objects. The plans successfully support the customers current as well as planned storage requirements.

Data Archive Implementation Testing

Purpose
The data archive implementation testing subdeliverable yields sample test results of individual data archive executions on the quality assurance system.

Inputs

The data archive objects are tested for the entire process, from selection and qualification through the storage, deletion, and retrieval from the storage server. This verifies that the data archive run has successfully created the indexes for each archive execution.

Expected Results
The expected results of the data archive implementation testing are data archive and storage test results and validations. Reporting on archived data and the storage solution verifies the data archive process and the subsequent storage solution as successful.

Business Process Management

Purpose
The purpose of the business process management during realization work stream is to build the solution that was defined during the business blueprint phase. This includes baseline and final configuration, service-oriented architecture (SOA) and composition application development, and enhancement (RICEFW objects) development, including creation of test documentation and business process procedures. It is recommended that you start value audits to monitor whether the project is on track to realize the expected benefits.

Inputs
The inputs for business process management are: Value realization deliverables, such as refinement of value maps and the association of key performance indicators (KPIs) and project performance indicators (PPIs) on the process level Business object modeling (including organizational structures, master data, and user roles) Scenario solution design

Business process and process step design documents Business process design detail map to: 1. Core configuration 2. Core enhancement (RICEFW list and functional specifications) 3. SOA and composite 4. Third-party solutions Cross-functional process requirements and design Initial functional specification, detailed enough to produce estimated for follow-up phase Transferred process structure and blueprinting document management in SAP Solution Manager

Deliverables
The deliverables that should be generated as a result of this work stream are: Configured general settings and organizational structures Configured scenarios and processes Configuration documentation Implementation of development objects RICEFW Development objects documentation (functional specifications) Implementation of enterprise services and composition application Enterprise and composition documentation Manual and automatic test cases Completed test cycles Business process procedure

Integration
The integration points for business process management are: Predecessor: process and solution design from blueprinting, including gap identification Predecessor: business requirements for the design of test cases Data management Technical solution management Integration solution management Training

Value Audit

Purpose
The purpose of the value audit deliverable during the realization phase is to monitor and control the implementation of key process changes and value enablers, as well as to ensure the design and implementation of the Value Dashboard for KPI tracking purposes. The business case and value maps are the prerequisite to execute value audits. The business case is the starting point for value determination and value mapping. The value map associates pain points, key process changes, value enablers and performance indicators. The key process changes need to be controlled during value audit to ensure they are embedded in the solution design, if they are not implemented identify the cause and take actions if necessary. The value enablers need to be put into action before go-live to ensure that the organization will be prepared to maximize the value attainment from the new solution. A value management dashboard needs to be created at this step of the process to secure the transparency of the value management process through the whole project lifecycle, even after the implementation has been completed. The result of a value audit is the mitigation of risks that could jeopardize the value identified during the business case development. The following figure illustrates the value-related activities (outlined in an orange line) associated with value audits. The activities are as follows: Maintain the link between the solution and identified process changes Update business case if there are scope changes Track the adoption of Value Enablers Develop the Value Dashboard based on Financial and Operational KPIs identified during the value determination/ value mapping

Inputs
The inputs for value audit are: Statement of work scope determination Business case Value-based solution design, such as value map, value association, KPIs (financial KPIs) and PPIs Initiative roadmap, as applicable High-level to-be solution design, as it exists As-is analysis, as scoped

Deliverables
The deliverables for value audit are: Mapping of key process changes with final solution design and scope

Updated Business Case (alignment with scope changes, new cost information, etc.) Tracking of value enablers adoption Value Dashboard

A value audit should be executed in addition to the quality gates, since the quality gates only check for the completeness of the deliverables and not the actual status of the value management process.

Expected Results
The value audit deliverable enhances the capabilities of the project team to: Manage expectations and focus on key deliverables Achieve transparency of value delivery during the project

Track progress of key process changes and value enablers adoption Assist in managing scope Improve readiness for value delivery after go-live

Value audit is a key component of realization and subsequent phases.

Configured General Settings and Organizational Structure

Purpose
The purpose of the configured general settings and organizational structure deliverable is to complete and document the initial configuration of the system on the basis of the enterprise system design decisions made in the business blueprint phase. The general settings and organizational structure are utilized by multiple modules as the project moves forward in baseline configuration. General settings are delivered with the initial installation. General settings, such as calendar, units of measure, countries, currencies, and so on, comply with ISO standards and generally do not need to be changed. Data exchange with external systems is sensitive to alterations in compliant international settings. General settings affect all business processes supported by the SAP software system. The organizational structure is the preparation of the technical representation of organizational units in an enterprise arranged in a hierarchy, according to tasks and functions. Organizational units are objects that form the basis of an organizational plan. An organizational unit represents any type of organizational

entity found within a company. When building up the organizational structure, build it from the root organization down. A root organizational unit is at the highest level of an organizational structure.

Inputs
The inputs for the deliverable are: Organizational units of an enterprise Documentation of the business process requirements from the business blueprint phase Software system configuration standards

Deliverables
The deliverable for configured general settings and organizational structure is the completed initial configuration and documentation of general settings and organizational structure to start baseline configuration.

Expected Results
By completing the deliverable correctly, the project team has documentation of the configuration and is prepared to move to the baseline configuration step in the realization phase.

Configured Master Data Objects 1-n

Purpose
The purpose of the configured master data objects 1-n deliverable is to configure the master data in the SAP software system according to the business process requirements specified in the business blueprint phase. This configuration includes both the baseline and final configuration as needed to meet the documented business needs. Documentation is required for all configuration activities.

Inputs
The inputs for configured master data objects are: Business blueprint requirements detailing master data requirements

Software system configuration standards Project standards for documentation of configuration Master data testing and user acceptance testing standards

Deliverables
The deliverable for configured master data objects 1-n is configured master data in the SAP software system as required in the business blueprint to allow business processes to be performed, including: Completed master data baseline configuration and validated and documented testing Completed master data final configuration and validated and documented testing

Expected Results

By completing the deliverable correctly, the project team has configured, tested, and documented the SAP software master data to meet the business processes specified in the business blueprint phase.

Master Data Baseline Configuration

Purpose
The purpose of the master data baseline configuration subdeliverable is to configure the SAP software system according to the business process requirements specified in the business blueprint phase and document all configuration activities. In baseline configuration, all priority business requirements are realized, ensuring that they can be implemented quickly without programming or enhancements. Requirements that need programming or enhancements are addressed in later deliverables in this phase. Baseline configuration is considered anything that is needed to successfully complete a transaction by using basic, standard functionality. Some examples would be fiscal calendar, company code, and basic account assignments. Because master data is used across multiple applications areas, the documentation of configuration is essential project documentation.

Inputs
The inputs for master data baseline configuration are: The software configuration standards

The project standards for approved documentation of configuration The business requirements specified in the business blueprint documents

Subdeliverables
The subdeliverable for master data baseline configuration is configured master data in the SAP software system as required in the business blueprint to allow the completion of the specified business processes. The required documentation stands as a record of the configuration that is performed, to be used as input for the final configuration that may need to be done and other project activities (such as testing) where the baseline configuration will be validated.

Expected Results
By completing the subdeliverable correctly, the project team has configured the system to meet the business processes specified in the business blueprint phase, has a record of the configuration, and has readied the configuration for testing.

Master Data Final Configuration

Purpose
The purpose of the master data final configuration subdeliverable is to configure the solution according to the business process requirements specified in the business blueprint phase. In baseline configuration, all priority business requirements are realized, ensuring that they can be implemented quickly without programming or enhancements. Final configuration adds more options, functionality, and variations to meet specific customer requirements. Examples include additional order types, full costcenter hierarchy, and complex bills of material. Final configuration requires that baseline configuration has been completed. Documentation is required for configuration. Master data is used across multiple applications and is essential project documentation.

Inputs
The inputs for master data final configuration are: The business requirements specified in the business blueprint documents Master data baseline configuration that was performed in the solution The project standards for approved documentation for configuration

Subdeliverables
The subdeliverable for master data final configuration is additional configured master data in the solution as required in the business blueprint to allow the completion of the required business processes. The required documentation stands as a record of the configuration that is performed, to be used as input for other project activities (such as testing) where the final configuration will be validated. Approved changes are incorporated into the business blueprint document.

Expected Results
By completing the subdeliverable correctly, the project team has completed the configuration of the master data above the baseline configuration in the system to meet all business processes specified in the business blueprint phase and has readied the configuration for testing. The record of the master data final configuration changes that were made as part of required project documentation are available for use in future project phase and future upgrade projects.

Master Data Validation Test Cases

Purpose
The purpose of the master data validation test cases subdeliverable is to create the documentation to execute the testing of conversion programs to load production data from existing legacy systems and to drive test scenarios that define entities of information that are required to support manual and automation testing. Also, the test cases verify that the data is correctly converted into the SAP application and is ready to be used for production cutover.

Inputs
The input for master data validation test cases is master data testing and user acceptance testing standards.

Subdeliverables
The subdeliverables for master data validation test cases are the master data test case test results.

If It Is Not Done
By not completing master data validation test cases correctly, the project team will not have documented test cases and data to provide to project management and the customer for sign-off.

Core Configuration
Purpose
The purpose of the core configuration deliverable is to configure the SAP software system according to the business process requirements specified in the business blueprint phase. Core configuration is split into: Business process baseline configuration, in which all priority business requirements are realized, ensuring that they can be implemented quickly without programming or enhancements

Business process final configuration, in which all business processes and business requirements are included in the scope of the final configuration cycle (This activity builds on the previous activities performed in the baseline configuration.)

Core configuration also includes configuration documentation, which ensures that the documentation for configuration is consistent and complete.

Inputs
The inputs of core configuration are: The baseline configuration schedule (part of the overall project schedule) Activated business configuration sets (BC sets), if using support for scenarios in SAP Best Practices packages

Deliverables
The deliverables generated as a result of core configuration are: A configured process within the SAP software system, ready for testing Configuration documentation

Additional Information

If you are using support for scenarios in SAP Best Practices, baseline configuration is mostly covered through preconfigured BC sets and may need only fine-tuning.

Scenario Configuration Documentation

Purpose
The purpose of the scenario configuration documentation subdeliverable is to ensure that the documentation for configuration is consistent and complete.

Inputs
The input for scenario configuration documentation is the configuration of the scenario.

Subdeliverables
The subdeliverable for scenario configuration documentation enables proper preparation for process configuration and scenario testing.

If It Is Not Done
By not completing scenario configuration documentation correctly, the project team will not be able to completely account for the scenario configuration. The project will not be consistent in managing testing defects for scenario configuration if the documentation does not exist.

Business Process Baseline Configuration

Purpose
The purpose of the business process baseline configuration subdeliverable is to configure the SAP software system according to the business process requirements specified in the business blueprint phase. In business process baseline configuration, all priority business requirements are realized, ensuring that they can be implemented quickly without programming or enhancements.

Inputs
The inputs for business process baseline configuration are:

The baseline configuration schedule (part of the overall project schedule) Activated BC sets, if using support for scenarios in SAP Best Practices

Subdeliverables
The subdeliverable for business process baseline configuration is an SAP software system ready for programming and enhancements to finish the solution.

Expected Results
By completing the deliverable correctly, the project team gains: Configured SAP software system (baseline scope) Documented configuration results Updated or created business procedures Updated case procedures (optional) Refined business blueprint

Additional Information

If you are using support for scenarios in SAP Best Practices, baseline configuration is mostly covered through preconfigured BC sets and may need only fine-tuning.

Business Process Final Configuration

Purpose
The purpose of the business process final configuration subdeliverable is to perform configuration of business processes that are included in the cope of the final configuration cycle. This activity builds on the previous activities performed in the baseline configuration.

Inputs

The inputs for business process final configuration are the configured business process and approval of the final configuration cycle.

Subdeliverables
The subdeliverable for business process final configuration is the completion of final configuration and readiness for the final configuration cycle testing.

If It Is Not Done
By not completing the deliverable correctly, the project team will not have final configuration in the solution.

Solution Gaps and Core Enhancements

Purpose
The purpose of the solution gaps and core enhancements deliverable is to develop the RICEFW objects. These objects can be classified as Reports that have to be designed or adjusted Interfaces that need to be developed Conversions (mostly master data related) Enhancements that need to be done Forms for printout or other needs Workflows that need to be implemented or designed

RICEFW objects are based on business process requirements, and they are specified in functional specifications during the business blueprint phase. Each RICEFW object needs to be documented via a technical specification before the object can be built. Test documentation must be included.

Inputs
The input for solution gaps and core enhancements is the functional specification.

Deliverables
The deliverables for solution gaps and core enhancements are as follows: RICEFW objects Technical specifications and test documentation

Templates for technical specification might vary, depending on the engaged development parties. It is recommended to associate technical specification in SAP Solution Manager at the process level, or process step level, as appropriate. Technical specification can be consolidated under a dedicated node in the process hierarchy of SAP Solution Manager.

Expected Results
By completing the deliverable correctly, the project team develops all RICEFW objects.

Additional Information
For larger development projects, and especially development of new applications that go beyond the scope of typical RICEFW work, initiating a custom development project (CDP) with involvement of the SAP Custom Development organization should be considered. Optionally, global delivery can be engaged for the solution development.

Business Process Report Development

Purpose
The purposes of the business process report development subdeliverable are to: For a specific selection criteria, print all the records or specific output fields, based on those criteria, in a report format (for example, report to print all the overdue invoices for a specific customer based on the company code) On the basis of the reviewed functional specification requirement, create the technical specification document and complete the development of the report

Inputs
The inputs for business process report development are: Functional specification document Report technical specification Issue log Defect log

Subdeliverables
The subdeliverables of business process report development include: Business process report technical specification Business process report object Business process report unit test results

Expected Results
By completing the subdeliverable correctly, the project team ensures that: The report developed and delivered is in accordance with the original functional requirement as per the functional specification document received The report has addressed approved changes in requirements after review of the functional specification document and approved change requests The defects at every interim deliverable (as mentioned in the Inputs section) have been closed

The rework has been completed on the interim deliverables to prevent slippage of defects to the customer The unit test results are well-documented with screen shots and actual results based on the data and the scenarios available The delivery document is complete and contains the latest baselined versions of all the interim deliverables

Business Process Interface Development

Purpose
The purposes of the business process interface development subdeliverable are to: Ensure that communication of information with external systems can be carried out by passing data from one system to another via files or through techniques such as IDocs, remote RFC calls, and proxy programs (Interfaces can be asynchronous or synchronous, depending on the availability of the remote system for example, sending customer data from the SAP CRM application to a loyalty management system.) On the basis of the reviewed functional specification requirement, create the technical specification document and complete the development of the interface

Inputs
The inputs for business process interface development are: Functional specification document Interface technical specification Issue log Defect log

Subdeliverables
The subdeliverables for business process interface development are: Business process interface technical specification Business process interface object Business process interface unit test results

Expected Results
By completing the subdeliverable correctly, the project team ensures that: The interface developed and delivered is in accordance with the original functional requirement as per the functional specification document received The interface addressed approved changes in requirements after review of the functional specification document and approved change requests The defects at every interim deliverable (as mentioned in the Inputs section) have been closed The rework has been completed on the interim deliverables to prevent slippage of defects to the customer The unit test results are well-documented with screen shots and actual results based on the data and the scenarios available The delivery document is complete and contains the latest baselined versions of all the interim deliverables

Business Process Enhancement Development

Purpose
The purposes of the business process enhancement development subdeliverable are to: Ensure that the stack for the SAP NetWeaver technology platform for the ABAP programming language provides multiple ways via user exits or BAdIs that allow the users to write their own piece of code to achieve a requirement that is not fulfilled by the standard solution for example, carrying out a customized available-to-promise check before confirmed delivery dates in a sales order On the basis of the reviewed functional specification requirement, create the technical specification document and complete the development of the enhancement

Inputs
The inputs for business process enhancement development are: Functional specification document

Enhancement technical specification Issue log Defect log

Subdeliverables
The subdeliverables for business process enhancement development are: Business process enhancement technical specification Business process enhancement object Business process enhancement unit test results

Expected Results
By completing the subdeliverable correctly, the project team ensures that: The enhancement developed and delivered is in accordance with the original functional requirement as per the functional specification document received The enhancement has addressed approved changes in requirements after review of the functional specification document and approved change requests The defects at every interim deliverable (as mentioned in the Inputs section) have been closed The rework has been completed on the interim deliverables to prevent slippage of defects to the customer The unit test results are well-documented with screen shots and actual results based on the data and the scenarios available The delivery document is complete and contains the latest baselined versions of all the interim deliverables

Business Process Form Development

Purpose

The purposes of the business process form development subdeliverable are to: Display structured information in a particular layout, generally for preprinted stationery (Because of its ability to display bitmap images, its enhanced programming functionalities, and its ability to serve as a good toolkit for development, structured information can be used for complex and precise printing and display of data, such as invoices sent to customers for gas and electricity bills during a billing run.) On the basis of the reviewed functional specification requirement, create the technical specification document and complete the development of the form

Inputs
The inputs for business process form development are: Functional specification document Form technical specification Issue log Defect log

Subdeliverables
The subdeliverables for business process form development are: Business process form technical specification Business process form object Business process form unit test results

Expected Results
By completing the subdeliverable correctly, the project team ensures that: The form developed and delivered is in accordance with the original functional requirement as per the functional specification document received The form has addressed approved changes in requirements after review of the functional specification document and approved change requests The defects at every interim deliverable (as mentioned in the Inputs section) have been closed The rework has been completed on the interim deliverables to prevent slippage of defects to the customer

The unit test results are well-documented with screen shots and actual results based on the data and the scenarios available The delivery document is complete and contains the latest baselined versions of all the interim deliverables

Business Process Workflow Development

Purpose
The purposes of the business process workflow development subdeliverable are to: Develop the workflow A workflow is a sequence of operations that have to be performed by different members with varying roles. These are normally used to approve a particular request or to complete tasks handled by different people at different stages of a process cycle. The workflow objects can have sequential (dependent) tasks or tasks that can be completed in parallel for example, budget approval for a purchase order over a certain price limit has to be approved by a purchasing manager before being released. On the basis of the reviewed functional specification requirement, create the technical specification document and complete the development of the workflow

Inputs
The inputs for business process workflow development are: Functional specification document Workflow technical specification Issue log Defect log

Subdeliverables
The subdeliverables for business process workflow development are: Business process workflow technical specification Business process workflow object Business process workflow unit test results

Expected Results
By completing the subdeliverable correctly, the project team ensures that: The workflow developed and delivered is in accordance with the original functional requirement as per the functional specification document received The workflow has addressed approved changes in requirements after review of the functional specification document and approved change requests The defects at every interim deliverable (as mentioned in the Inputs section) have been closed The rework has been completed on the interim deliverables to prevent slippage of defects to the customer The unit test results are well-documented with screen shots and actual results based on the data and the scenarios available The delivery document is complete and contains the latest baselined versions of all the interim deliverables

Final Code Review

Purpose
The purposes of the final code review subdeliverable are to ensure that the: Technical consultant or developer initiates a formal code review after completion of coding and unit testing on the object for example, RICEFW Designated reviewer (quality control) performs the formal review of the code and the unit test results and logs the defects into the defect log Technical consultant or developer completes the rework on the object, posts the formal review, and closes all the logged defects in the defect log Reviewer verifies the changes and confirms that the object is ready to be delivered

Inputs
The inputs for final code review are:

Coding standards and naming conventions Technical specifications document Functional specifications document Issue log, if any

Subdeliverables
The subdeliverables for final code review are: Reviewed object ready for delivery Delivery document: latest reviewed and baselined documents such as review checklists, technical specifications, and so on

Expected Results
By completing the subdeliverable correctly, the project team ensures that: The object (for example, RICEFW) developed is in accordance with the original functional requirement as per the functional specification document received and the technical specification The object has addressed approved changes in requirements after review of the functional specification document and approved change requests The defects have been closed after completion of the code review The delivery document contains all the latest reviewed documents and the object is ready for delivery

Business Process Technical Specifications Completion

Purpose
The purposes of the business process technical specifications completion subdeliverable is to: Provide the technical design on the basis of the functional requirements that are a part of the reviewed and approved functional specification document

On the basis of the reviewed functional specification requirement, ensure the creation of the technical specification document by the technical consultant responsible for the development of that object and ensure the review of that document by a reviewer before starting the development on any of the objects

Inputs
The inputs for business process technical specifications completion are: Functional specification document Issue log

Subdeliverables
The subdeliverable of business process technical specifications completion is the reviewed and signed-off business process technical specification (depending on the type of object, such as RICEFW).

Expected Results
By completing the subdeliverable correctly, the project team ensures that: The rework has been completed on the functional specification on the basis of the issue log, if required, and similarly on the technical specification on the basis of the defects logged by the reviewer in the defect log The reviewed technical specification is accepted (based on acceptance criteria set in the project) and baselined to enable the technical developer to start developing the object (for example, RICEFW) The defects and issues at every interim deliverable have been closed

SOA and Composition

Purpose
The purpose of the SOA and composition deliverable is to implement and document the enterprise services, including developing and realizing the composite application. The technical design and specifications from the business blueprint phase serve as input.

Inputs and Deliverables for Composition

Deliverables
Developed solution

Inputs
Development specification Development process Development guidelines Logging guidelines Exception handling

Techniques and Accelerators

How-to's Developers cookbook

Outputs

Deployable solutio

Implementation gu (documentation on deploy the separat Development documentation

Inputs and Deliverables for Enterprise Services Development

Deliverables
Implemented enterprise services

Inputs
Service definition from Enterprise Services Repository (ES Repository) that is, Web service definition language (WSDL)

Techniques and Accelerators

Guidance for new enterprise services, including: Import of WSDL in the back end Proxy generation Service implementation (glue code)

Outputs
Implemented enterprise services

Enterprise services enhancement Enterprise services enhancement guide import of WSDL in the back end Documentation of enterprise services (compare Enterprise Services Workplace [ES Workplace] and WIKI)

Documented enterprise services

Enterprise services models in ES Repository (portal content model [PCM] and others)

Enterprise services documentation

Enterprise Services Development

Purpose
The purpose of the enterprise services development subdeliverable is to implement and document the enterprise services modeled in the business blueprint phase.

Inputs and Deliverables

Deliverables Inputs
Service definition from ES Repository (WSDL)

Techniques and Accelerators

Outputs

Implemented enterprise services

Guidance for new enterprise services, including: Import of WSDL in the back end
Proxy generation Service implementation (glue code)

Implemented enterprise services

Enterprise services enhancement Enterprise services enhancement guide,

including import of WSDL in the back end

Documented enterprise services

Enterprise services models in ES Repository (PCM and others)

Documentation of enterprise services (compare ES Workplace and WIKI)

Enterprise services documentation

The starting point for the implementation of enterprise services is the service model, which is the output of the business blueprint phase. The enterprise services modeled can be exported in WSDL format from the ES Repository. These can, in turn, be imported into the back end, and the corresponding implementation proxies (or stubs) can be generated. The necessary service logic must be coded in the generated implementation proxy to complete the service implementation. For more details about implementing enterprise services and enhancements, refer to the accelerator area. Documentation of enterprise services is an important activity for SOA-based solutions. Since the reuse of enterprise services is one of the cornerstones of a successful service-oriented architecture, even services that are modeled in the best way possible need to be accompanied by thorough documentation to ensure widespread reusability. Enterprise services documentation should describe the technical contract between the service provider and consumer. This is required to understand the services' behavior in detail. Typically, these contracts group the service description documents and technical diagrams and may be supplemented by other, nontechnical documents. The service models in ES Repository, which are created in the design activity, are a binding contract between the consumer and the service provider. These models therefore provide a very good starting point for documenting enterprise services. Ensure that the service models in ES Repository include the following: Process component models Integration scenario models Process component interaction models Signature definition (contract)

To complete the services documentation, you can add any other semantic or technical information that the service owner wants to publicize. This documentation can also be enriched by service-level agreements (SLA) for the specific enterprise services.

Additional Information

Governance plays a central role in the implementation of services. Governance of SOA implementation must include standardizing the general runtime behavior of enterprise services as well as their static models by establishing clear design and programming paradigms and guidelines. For example, the exception reporting and handling strategy should be similar across the various service implementations. This kind of governance is a prerequisite for ensuring easy-to-use, reusable services and achieving higher productivity during implementation. The general service programming paradigms and guidelines should define the following:
When to use synchronous or asynchronous enterprise services Service cut and granularity (through patterns) Service-oriented implementation: implementing for reuse (follow the design by contract principle and balance simplicity against flexibility) How to handle conversions, transaction control, reliability and data consistency, exceptions compared with errors, change versus update services, and so on

Developed Composition Application

Purpose
The purpose of the developed composition application subdeliverable is to develop and realize the composite application. The technical design and specifications from the business blueprint phase serve as input.

Inputs
The inputs for the developed composition application are: Solution design Development specification Solution architecture Development process

Development guidelines Logging guidelines Exception handling guidelines

Subdeliverables
The subdeliverables for the developed composition application are: Deployable solution Implementation guide (documentation of how to deploy the separate parts) Development documentation

Expected Results
Composite applications are typical consumers within an enterprise SOA system landscape and are usually built on existing services and infrastructure. They combine these services into user-centric processes and views, supported by their own business logic and specific user interfaces. These typically span several application areas and may even cross enterprise boundaries. Composite applications are loosely coupled with the back-end systems on which they are based, resulting in a new logical application tier, which can be deployed and upgraded independent of the back-end infrastructure. In many cases, composite applications are combined with business integration scenarios to establish corresponding business network solutions.

A human-centric composite scenario typically consists of the following: User interface: This is typically created with a graphical modeling approach (the SAP NetWeaver Visual Composer tool, the Web Dynpro development environment, Adobe Forms, and so on) and is therefore easily adjusted to specific needs. Composite process: Process flow is modeled with graphical tools, and workflows can be assembled from reusable blocks. Business objects and local services: Composite logic is implemented on modeled business objects, based on imported enterprise services.

Additional Information

In some cases, primarily human-centric composite scenarios are combined with system-centric integration scenarios. This means that the overall composite process comprises both human-centric and system-centric parts.

Business Process Procedures

Purpose
The purpose of the business process procedures deliverable is to provide the basis for end-user training and end-user training documentation. The procedures may also be used by security to develop roles and authorizations, and they can be used as instructions in testing.

Inputs
The inputs for business process procedures are: Completion of final configuration Identified document type or documentation process for creating the business process procedures

Deliverables
The deliverable for business process procedures is an end-user training document.

If It Is Not Done
By not completing the deliverable correctly, the project team will not be able to provide end-user training documentation for the configured SAP software system.

Additional Information
The business process procedures documents are reviewed and approved by key stakeholders.

Scenario Test Cases and Results

Purpose
The purpose of the scenario test cases and results deliverable is to create the documentation to execute the testing scenario (integrated testing) and to report the summarized results of test case execution during the scenario (integrated) testing cycle to determine the progress of the testing cycle and the coverage of test requirement. Included in the test results are the defect tracking reports. Scenario testing validates a set of business processes that define a business scenario in a comprehensive and self-contained manner on a macro level. There will be <XX> number of test cycles during the integration testing. Integration testing is recommended to be done in multiple iterations. The initial iteration of integration testing concentrates on testing all important business processes within the SAP components of the implemented solution, starting with touch-point scenarios and ending with end-toend scenarios. The final iteration of integration testing focuses on cross-functional business scenarios with non-SAP software systems and applications, custom development objects, converted data, and solution security. Scenario testing includes testing with roles and authorizations defined, as well as negative testing. Incorporating both of these as requirements now minimizes issues within integration and user acceptance testing.

Inputs
The inputs for scenario test cases and results include the completion of the scenario configuration and scenario documentation, which identifies the test cases. Other inputs are: Scenario test case pass or fail results Defects discovered during the test cycle

Deliverables
The deliverables for scenario test cases and results are the scenario test results. Other deliverables are: Test cases Integrated test cycle summary Test execution status Defect trending

Test defects report

Scenario (integrated) test results document the test results for the project that validate the correctness of the configuration and provide the information needed for sign-off of this realization phase.

If It Is Not Done
By not completing the deliverable correctly, the project team will have no documented test cases and no test results.

Business Process Unit and String Test Cases

Purpose
The purpose of the business process unit and string test cases subdeliverable is to create the documentation to execute the testing of business process unit and string test cases. This testing validates the full operability of interconnected functions, methods, or objects within the functional areas of an SAP solution (for example, sales), including: A set of logically related activities or business process steps to achieve a defined business process Business processes that cross functional areas (for example, sales and finance)

During subsequent integration testing activities, these business process (string) tests are combined to build end-to-end integration test scenarios. The summarized results of test case execution are reported during the unit and business process (string) testing to determine the progress of the testing cycle and the coverage of test requirements. Included in the test results are the defect tracking reports.

Inputs
The inputs for business process unit and string test cases are detailed steps to test the process after completion of the baseline configuration and initial unit testing. Other inputs are: Unit and business process (string) test case pass or fail results Defects discovered during the test cycle

Subdeliverables
The subdeliverables for business process unit and string test cases are the business process unit and string test case test results. Other subdeliverables are: Unit and business process (string) test cycle summary Test execution status Defect trending Test defects report

Test results document the test results for the project, validate the correctness of the configuration, and provide the information needed to enter into scenario (integration) testing.

If It Is Not Done
By not completing business process unit and string test cases correctly, the project team will have no documented test cases to execute.

Business Process Monitoring

Purpose
The business process monitoring deliverable describes the considerations that are required to recognize and solve critical situations during business process operation. The goal is to minimize the impact of these critical situations on the business process execution and, by this, to guarantee a smooth and reliable flow of the core business processes. Business process monitoring includes monitoring activities, alert and problem detection, notification of experts, error-handling procedures, and interfaces to root cause analysis. Business process monitoring contains the following steps: Technical and integration design

Technical and operational implementations Cutover and start of production Operation and continuous improvements

Business process monitoring should be considered and initiated during the realization phase. The monitoring and exception handling can be productive after the installation and configuration of a system and is relevant during the whole lifecycle of a solution landscape.

Inputs
In order to begin consideration for business process monitoring, knowledge of the following is needed: Business requirements for performance and throughput of the involved business processes Technical details for the business process steps and interfaces involved and possible error situations Affected organizations Possible dependencies

Deliverables
Business process monitoring enables early identification of potentially critical situations. Monitoring provides time to solve these situations and consequently reduces the risk for business process downtime, thereby reducing costs. In addition, establishing one central, proactive, and process-oriented strategy for business process monitoring reduces costs for solution operations by avoiding organizational redundancies.

Technical Solution Management

Purpose
The purpose of the Technical Solution Management work stream is to outline essential technical and infrastructure deliverables that are appropriate to an SAP implementation project. In the context of the Realization phase of the ASAP Implementation Roadmap, the overall objective of Technical Solution Management is to prepare for the Final Preparation, Go-Live, and Run phases by completing key technical deliverables that are necessary to meet the needs of other work streams of the project.

Inputs
The inputs required for Technical Solution Management are the deliverables from the Business Blueprint phase: A technical requirements and design specification, mapping business processes in the solution to SAP applications and system instances. Installation and provision of the development environment to the project team. Definition of system administration procedures and processes for ensuring the operation and availability of the development environment to the project team. Definition and documentation of technical support procedures, guidelines, and standards for incident reporting and resolution in the context of the project. Setup of the project Implementation Guide (IMG) in the SAP Solution Manager. Definition of system security and user authentication requirements for the target solution.

Deliverables
The major deliverables of Technical Solution Management in the Realization phase are: Design, installation and provision of the quality assurance and production environments to the project team. Definition of system administration standards for productive operations, and a handover strategy to prepare the IT organization to support the solution after go-live. Design, installation, and testing of the failover environment (if deployed as a separate environment)

Implementation of system security and user authentication requirements for the target solution. Scheduling of applicable SAP Active Global Support services to help prepare for the go-live.

Quality Assurance Infrastructure and Environment Design and Setup

Purpose
The purpose of the quality assurance infrastructure and environment design and setup deliverable is to install a viable, correctly configured technical QA environment that is available for use by the project team to perform QA testing. This environment includes not only the installed QA systems, but also the initial technical configuration, such as project team user IDs needed for that environment, and configured change and transport settings to ensure this environment is recognized in the overall transport system.

Inputs
The inputs for quality assurance environment are: Technical requirements specification Technical infrastructure specification SAP Installation Guides Technical installation procedures, which includes project-specific instructions to ensure the QA environment is installed in a manner consistent with the development environment Project standards and procedures, including team authorization standards

Deliverable
The deliverables for a viable, properly configured quality assurance environment are: Installation of hardware required for the systems in this environment. Installation of SAP software specified for use in this environment, according to the procedures specified in the SAP Installation Guides for the applicable solutions. Installation and activation of optional SAP software components that are required to support the project, such as Extensions, Add-Ons, and components of Enhancement Package. Installation of non-SAP software solutions that are included in the scope of the project. Configuration and testing of the required CTS/CTS+ environment within this environment. Creation of all user IDs, roles, authorizations, and role assignments necessary to accommodate the necessary access to this environment by the appropriate members of the project team.

Definition and configuration of output devices for the QA environment.

A quality assurance environment specification should be created and completed throughout the course of the installation process. The purpose of this document is to capture the specific configuration of this environment, including software components installed and activated, documentation of the clients created in each system and the purpose of each, and any other details that are unique to this environment; a similar specification is to be created for each environment as it is installed and the handoff to the project team is completed.

Expected results
By completing the deliverable quality assurance environment correctly the project will gain a working and functional environment to support Realization activities that has been installed according to previously-agreed upon specifications.

Production Infrastructure and Environment Design and Setup

Purpose
The purpose of the production infrastructure and environment design and setup deliverable is to install a viable, correctly configured technical production environment to support productive operations of the delivered solution. This environment includes not only the installed production systems, but also the initial technical configuration, such as project team user IDs needed for that environment, and configured change and transport settings to ensure this environment is recognized in the overall transport system.

Before the hardware infrastructure for the production environment is finalized, special care should be taken to ensure that sizing models are up to date and reflect the most recent available information about expected usage patterns and volumes.

Inputs

The inputs for production environment are: Technical requirements specification Technical infrastructure specification Technical infrastructure capacity plan SAP Installation Guides Technical installation procedures, which includes project-specific instructions to ensure the QA environment is installed in a manner consistent with the development environment

Deliverable
The deliverables for a viable, properly configured production environment are: Installation of hardware required for the systems in this environment. Installation of SAP software specified for use in this environment, according to the procedures specified in the SAP Installation Guides for the applicable solutions. Installation and activation of optional SAP software components that are required to support the project, such as Extensions, Add-Ons, and components of Enhancement Package. Installation of non-SAP software solutions that are included in the scope of the project. Configuration and testing of the required CTS/CTS+ environment within this environment. Creation of all user IDs, roles, authorizations, and role assignments necessary to accommodate the necessary access to this environment by the appropriate members of the project team. Definition and configuration of output devices for the production environment.

A production environment specification should be created and completed throughout the course of the installation process. The purpose of this document is to capture the specific configuration of this environment, including software components installed and activated, documentation of the clients created in each system and the purpose of each, and any other details that are unique to this environment; a similar specification is to be created for each environment as it is installed and the handoff to the project team is completed.

Expected results
By completing the deliverable production environment correctly the project will gain a working and functional environment to support Realization and Go-Live activities that has been installed according to previously-agreed upon specifications.

Technical Operations and Handover Strategy

Purpose
The purpose of the technical operations and handover strategy deliverable is to update refine two prior deliverables from the Business Blueprint phase, and prepare a strategy to hand off operations of the solution landscape to the post-production support organization.

Inputs
The primary inputs for the technical operations and handover strategy deliverable include the two deliverables to be updated: System administration procedures Support strategy and procedures

In addition, it is recommended to reference the Run SAP methodology for guidelines in establishing a complete, end-to-end solution operations function. The Run SAP roadmap provides detailed assistance through the following phases: Assessment and scoping Design of operations Setup of operations Handover to production support Conducting operations and optimization

Deliverable
The deliverables of the technical operations and handover strategy deliverable are as follows:

Updated system administration procedures document. Updated support strategy and procedures document.

 Completed handover plan, including formal technical training plans of customer IT support staff and internal knowledge transfer sessions from project technical staff.

Expected results
By completing a successful handover to the post-production support organization, the project can ensure full operation and availability of the solution after go-live.

Failover Environment Design and Setup

Purpose
As most business processes today rely on a technical IT environment, it is important to ensure the availability of these IT services. Availability and continuity management (ACM) helps you identify the most critical business processes, assess their damage potential in case of failure, and detect technical insufficiencies due to the possibility of failure. As the name indicates, ACM combines both availability and continuity measures, to ensure the reliability of SAP solutions and, thus, of the business processes that are executed on them. During the realization phase, the failover environment design and setup, or the design and setup of ACM, should be executed. The following actions have to be done during design as a prerequisite for a successful implementation of this deliverable: Define availability requirements: Define the availability requirements for each analyzed business process. You can do this by involving corresponding business parties (for example, business process champions), who will answer the questions on the required availability of the business process. Perform a risk analysis: There are several methods to evaluate the impact of possible failure of a component or business process as well as potential threats and risks to the companys business. This step includes the business impact analysis, the component failure impact analysis, and the determination of a single point of failure.

Define the ACM strategy: The ACM strategy covers aspects of, for instance, unplanned and planned downtime issues as part of corporate policy. Additionally, the ACM strategy defines monitoring and reporting objectivities to be measured during the daily operations to ensure the reliability of the analyzed services.

To successfully implement the process, the following activities have to be performed: Set up IT infrastructure and operational procedure: Implement the ACM strategy resulting from design technically and operationally Realize the defined risk-reductive measures, using technological solutions such as clustering or mirroring Use further system and service management processes that may also help you ensure an efficient and durable implementation of ACM

Establish and monitor service-level agreements and operational-level agreements (OLAs): To ensure the reliability of ACM, establish the defined KPIs for monitoring the availability Set up the reporting functionalities on these values, or add them to existing SLA reporting concepts

Establish a recovery plan and workaround scenarios: Ensure that the defined recovery options are available to be invoked in case of a disaster (For this reason, the technical implementation of the recovery plan is essential.) Create workaround scenarios to keep the business going if the recovery measures are not sufficient

Document refused implementations: Document the nonimplementations (During design, you may have decided to leave some contingencies out of scope of the ACM strategy because of minor impact expected, for example. It is also possible that you, for some reason such as extended financial need or limited staff resources deviate from an already defined measure of the ACM strategy. In this case, the documentation of the nonimplementations is required: name the remaining risks and threats, including their potential cost of failure.)

During a later optimization of the strategy, analyze or reimplement these refused implementations

Make an initial test of the implemented ACM measures (Before starting the daily operations, you must test all implementations to ensure the ACM readiness of the company. Stress and load tests furthermore indicate whether bottleneck situations occur and might give hints on possible future behavior.)

When you have finished the test step successfully, the company is ready to handle any upcoming disaster event, and the implemented ACM measures will ensure business continuity.

Inputs
Before starting design of ACM, you must have the following inputs: Involvement of other relevant stakeholders such as those involved in incident management or change management Documentation of business processes and the technical landscape

Deliverables
As a result of design, all critical business processes are identified and must have measures assigned to ensure availability and avoid business interruption by any outage. Furthermore, different analyses give hints on technical insufficiencies as well as possible bottlenecks that need to be covered by further arrangements. The following deliverables should be available when the deliverable is complete: SLAs and OLAs that agree with the internal stakeholders concerning the service availability and continuity Business impact analysis, a single point of failure, and component failure impact analysis ACM strategy Monitoring and reporting objectives

After design is finished and all deliverables are available, the implementation procedure of setup should be started. After the completion of setup, the following deliverables should be available:

Implementation of measures regarding risk reduction, recovery options, and workarounds Further test planning schedules and initial test results Documentation of remaining risks due to refused implementation Further SLA arrangements with external suppliers KPIs to be monitored and reported

After the initial tests within the setup have passed successfully, the next step is to bring the process into the daily operations and optimization.

Expected Results
The result of the deliverable is the finalization of the implementation of ACM, which is ready to go productive when the solution goes live. Even when ACM has started to work within the daily operational business, it is essential to establish regular tests to ensure the process actuality. With the collected test results, it is also possible to estimate trends and possible future behavior to ensure that the implemented process still meets the defined availability requirements. In case of an unforeseen outage of a component or process, you have to perform a service outage analysis to define the root cause for this unplanned event and possibly adjust the current processes to prevent a recurrence. Furthermore, the integration of ACM into the companys continuous improvement cycle is fundamental to keeping the ACM process up to date.

Additional Information
For design, setup, and operation, follow the guidelines provided in the relevant implementation methodologies for the availability and continuity management deliverable from the run phase. These guides can be accessed via the linked nodes referring to the applicable deliverable of the run phase. Documentation from SAP Best Practices are also available and can be also found in the run phase as accelerators: "Best Practice: Business Continuity Management" and "Best Practice: Business Availability & Continuity Management."

Failover Environment Test Results

Purpose

During setup, the appropriate defined measures that were analyzed during the preceding design are established and set up. This results in the technical implementation of the ACM strategy by establishing risk reduction measures, such as using redundancy of a mirrored or clustered solution, as well as creating recovery plans to be able to react quickly in case of a disaster situation. In order to meet the defined business availability, it might be necessary to sign or adjust further SLAs with external suppliers such as Internet service providers or hardware distributors. At the end, you will have to set up SLA monitoring to ensure that the defined availability can be measured. Furthermore, you have to regularly perform KPI reporting in order to get early warnings and react to possible bottleneck situations. To ensure the successful completion of setup, initial testing is essential. If the company passes this test, it is ready to tackle the challenges of ACM. The test should be executed in the realization phase and should cover the results of the following setup activities: Set up IT infrastructure and operational procedure: Implement the ACM strategy resulting from design technically and operationally Realize the defined risk-reductive measures, using technological solutions such as clustering or mirroring Use further system and service management processes that may help you ensure an efficient and durable implementation of ACM

Establish and monitor SLAs and OLAs: To ensure the reliability of ACM, establish the defined KPIs for monitoring the availability Set up the reporting functionalities on these values, or add them to existing SLA reporting concepts

Establish a recovery plan and workaround scenarios: Ensure that the defined recovery options are available to be invoked in case of a disaster (For this reason, the technical implementation of the recovery plan is essential.) Create workaround scenarios to keep the business going if the recovery measures are not sufficient

Document refused implementations:

Document the nonimplementations (During design, you may have decided to leave some contingencies out of scope of the ACM strategy because of minor impact expected, for example. It is also possible that you, for some reason such as extended financial need or limited staff resources deviate from an already defined measure of the ACM strategy. In this case, the documentation of the nonimplementations is required: name the remaining risks and threats, including their potential cost of failure.) During a later optimization of the strategy, analyze or reimplement these refused implementations

Make an initial test of the implemented ACM measures (Before starting the daily operations, you must test all implementations to ensure the ACM readiness of the company. Stress and load tests furthermore indicate whether bottleneck situations occur and might give hints on possible future behavior.)

When you have finished the test step successfully, the project team is ready to handle any upcoming disaster event, and the implemented ACM measures will ensure business continuity.

Inputs
The inputs of the deliverable are: Completed design and setup and documented results Responsible staff who are well-trained to manage the process Documentation of all refused implementations, which have been related to potential impacts and risks

Deliverables
After the completion of failover environment test results, the following deliverables should be available: Implementation of measures regarding risk reduction, recovery options, and workarounds Documentation of remaining risks due to refused implementation Further SLA arrangements with external suppliers

KPIs to be monitored and reported

Based on the setup deliverables, a test planning schedule has to be built up and executed. After the tests have been passed successfully, the next step is to bring the process into the daily operations and optimization.

Expected Results
The result of the deliverable is the finalization of the implementation of ACM, which is ready to go productive when the solution goes live. Even when ACM has started to work within the daily operational business, it is essential to establish regular tests to ensure the process actuality. With the collected test results, it is also possible to estimate trends and possible future behavior to ensure that the implemented process still meets the defined availability requirements. In case of an unforeseen outage of a component or process, you have to perform a service outage analysis to define the root cause for this unplanned event and possibly adjust the current processes to prevent a recurrence. Furthermore, the integration of ACM into the companys continuous improvement cycle is fundamental to keeping the ACM process up to date.

Additional Information
For design, setup, and operation, follow the guidelines provided in the relevant implementation methodologies for the availability and continuity management deliverable from the run phase. These guides can be accessed via the linked nodes referring to the applicable deliverable of the run phase. Documentation from SAP Best Practices are also available and can be found in the run phase as accelerators: "Best Practice: Business Continuity Management" and "Best Practice: Business Availability & Continuity Management."

System User Roles and Authorization Administration

Purpose
The standard for security from SAP standards for solution operations distinguishes 10 security topics. Activities during operation ensure and verify that previously implemented security measures and the achieved security level in the 10 secure operations tracks are kept and dont degrade as a result of ongoing changes during operations. This goal is primarily achieved by well-defined and documented workflows performed by the respective administrators as well as the related review and monitoring processes.

Activities during operations and optimization comprise the execution of various operational workflows for the 10 secure operations tracks by the respective administrative staff. This includes, for example, user provisioning (identity and access management track), support package updates (software lifecycle security track), and the addition or removal of new systems to and from the system landscape (infrastructure security track).

Secure Operations Map The 10 secure operations tracks cover the following topics: 1. Audit: Ensure and verify the compliance of a companys IT infrastructure and operations with internal and external guidelines 2. Outsourcing: Ensure secure operations in IT outsourcing scenarios 3. Emergency concept: Prepare for and react to emergency situations 4. Secure process and people collaboration: Maintain security of process and people collaboration by means of automated business processes or document exchanges 5. User and authorization management: Manage users, authorizations, and authentication of IT users 6. Administration concept: Securely administer all aspects of solutions operation 7. Network, system, database, and workstation security: Establish and maintain the security of all infrastructure components 8. Secure application lifecycle: Securely develop and maintain the code base of standard and custom business applications

9. Secure configuration: Establish and maintain a secure configuration of standard and custom business applications 10. Secure support: Resolve software incidents in a secure manner Dedicated review processes conducted by administrative roles verify the successful enforcement of the companys security policy and ensure that the correct implementation of security measures is not harmed by changes to systems and applications. Audit processes conducted by internal or external auditors check the compliance of IT operations with internal and external requirements. External auditors must be provided with relevant protocols, data, and access to audit facilities. All defined security-related KPIs have to be continuously measured during operations and evaluated by IT and security management in order to improve the operational processes.

Inputs
An effective and efficient operation requires the correct implementation and test of all security controls described in the security concepts of the 10 secure operations tracks. This includes support for all operational workflows (in terms of tools, templates, and guidelines), clear responsibilities, and well-prepared personnel and proper budgeting.

Deliverables
In the realization phase, the security requirements have to be defined in a design phase and result in design of relevant processes to be set up for operations after go-live, including consideration of ongoing changes to business processes, system and application landscapes, users, and the companys environment. Furthermore, the fulfillment of these security requirements is documented and auditable. This documentation can be categorized into two areas: Documents and logs that are produced during various operational processes and activities Reliable and documented ratings of the companys security level as a result of assessment activities

Operational activities (including formalized maintenance and review processes) are documented and logged according to the companys needs and legal regulations. These can be evaluated to prove the fulfillment of internal and external requirements: Process and review documentation (user provisioning, root cause analysis of security incidents, checklists, and so on)

Technical logs Publication of policies to relevant stakeholders (such as a company security policy for the entire personnel and selected policies for collaboration partners) Schedule and scope of performed trainings and awareness campaigns

Internal and external audits as well as security assessments performed by internal security analysts or third parties provide a reliable and documented rating of the companys security level. Eventually, certification programs can additionally certify that the companys security concept complies with common standards and best practices. Deliverables produced in the context of audit and assessment activities are: Audit reports Security assessments of single entities (systems, applications, and so on) or secure operations tracks Certificates (for example, ISO 27001) Rating of the companys security level

Expected Results
Establishing effective operation processes for security ensures that regulatory requirements are met by IT operations, thereby addressing, for instance, data protection laws or requirements of the Sarbanes -Oxley Act.

Additional Information
For design, setup, and operation, follow the guidelines provided by the SAP standards for solution operations in the Security section, as well as the relevant implementation methodologies from the run phase. These guides can be accessed via the linked nodes referring to the applicable deliverable of t

SAP Technical Integration Check Service

Purpose
The primary goal of the SAP Technical Integration Check service is to identify technical integration issues related to the core business processes, the solution landscape, and the interfaces to SAP and non-SAP software systems. The check assesses your project from the technical perspective and generates a list of actions that you should take to ensure maximum availability and performance as well as smooth operations with your solution after going live.

Inputs
The input for SAP Technical Integration Check is at least one completed cycle of integration testing.

Deliverables
The deliverables are the results of SAP Technical Integration Check. This is provided as a management presentation and report.

Expected Results
By completing SAP Technical Integration Check, the project team provides an analysis of core business processes and their critical issues, the solution landscape and critical issues, and interfaces (SAP and non-SAP). An action plan and a service plan are also provided to address business processes and the solution landscape, application and system integration, and business process and system management.

SAP GoingLive Check

Purpose
The SAP GoingLive Check guides your implementation of an SAP solution to a smooth start of production and technically robust operations. During these services, certified SAP consultants

check the solution in a standardized procedure and give recommendations to ensure optimal performance and system availability for the core business processes.

Inputs
The inputs for SAP Going Live Check are: Implemented business processes Implemented production environment Implemented operations (business processes and systems) Completed functional testing Beginning of code freeze and integration testing

Deliverables
The SAP GoingLive Check consists of three service sessions analysis, optimization, and verification that are delivered by certified consultants through a remote connection. The delivery of the individual sessions takes place at key points in the implementation project, as follows: Analysis session Checks the configuration of the SAP software system, operating system, and database and is scheduled a minimum of four weeks before the start of production Optimization session Optimizes the response times of the core business transactions and is normally scheduled two weeks before the start of production, depending on the availability of the productive environment Verification session Verifies the smooth operation and performance of the productive environment and is scheduled six to eight weeks after the start of production (see the go-live support phase)

For complex projects, SAP offers an on-site optimization session; this is charged as a consulting service.

Expected Results
The SAP GoingLive Check delivers numerous benefits that help speed up the return on investment for your SAP solution: Preparing your SAP solution so that at the start of the production date, it runs with optimal performance, availability, and maintainability by: o Providing recommendations for optimal configuration o Examining performance-critical business processes

o Generating extensive reports with action lists and detailed suggestions for improvement Providing technical guidelines to minimize unnecessary work and to avoid complication

Integrated Solution Management

Purpose
The purpose of the integrated solution management work stream is to complete the test plans for the solution, begin preparation for data migration and cutover, and achieve user acceptance of the solution. Many activities support the deliverables of this work stream.

Inputs
The inputs for integrated solution management are: Requirements for test acceptance Data converted into a production-like environment Test strategy and approach document that was completed in the business blueprint phase

Test plan that was completed in the business blueprint phase

Deliverables
The major deliverables that should be generated as a result of integrated solution management are: Preliminary cutover plan Functional test results Performance test results User acceptance test results

Integration
The integration points for integrated solution management are: Data management Technical solution management Integration solution management Cutover

Preliminary Cutover Plan

Purpose
The purpose of the preliminary cutover plan deliverable is to begin documenting the timing, steps, and logistics for moving from the as-is solution to the to-be solution and the hypercare period immediately following go-live. This includes documenting activities such as the transfer of data from the legacy systems to the SAP software production system, setting up and initializing the production system, closing the legacy systems, and manually entering certain data in the new system. This deliverable documents the cutover strategy. Beginning with this high-level plan, add details as the logistics of its execution are considered, and end with the detailed plan needed for a cutover kickoff. Similarly, beginning with a high-level cutover schedule, you can add details as the team cutover plans and other inputs are considered, and end with the final cutover schedule. The cutover schedule is tested

and improved during the simulated cutovers. However, if the schedule is prepared early enough, it may also be tested when building the QA or training environment.

Inputs
The inputs for the preliminary cutover plan are: Team cutover plans Automated and manual execution sequence, dependencies, and timings Data migration quality tracking Legacy inventory and changes required Go-live requirements Business shutdown

Deliverables
The deliverables for the preliminary cutover plan are: Cutover strategy, comprising: o Strategy o Timeline o Go-live acceptance criteria o Cutover organization and responsibilities for the following: Legacy team Data migration team Business team o Cutover schedule o Data migration checklist o Cutover simulations o Cutover communications o Contingency plan

o Implementation support o Logistics Preliminary cutover schedule

Expected Results
By completing the deliverable correctly, the project team realizes the following results: Is organized in advance Has sufficient time to address any cutover issues discovered in the process of planning Is able to add the necessary detail to refine the plan, as the details become known Is able to test and update the plan during simulated cutovers May be able to test the plan when building the QA or training environment

Functional Test
Purpose
The purpose of the functional test deliverable is to perform functional tests of the solution throughout the Realization phase. The functional test is conducted in the following stages that build on top of each other. Unit test / test of custom developments initial tests conducted early during in the Phase Functional / String test conducted over chains of functionality after unit testing Scenario test conducted in later stages of Realization phase to validate complete business scenarios End to end integration test final stage of testing to ensure full integration of the solution

The individual tests were defined earlier in the project and outlined in the test plan document. Each testing cycle includes preparation tasks such as creating test cases, selecting test cases for a specific test cycle and setting up test status reporting including defect management typically involves implementing a test management tool.

Each cycle consists of following tasks: Create manual and automated test cases according to test strategy and test plan Prepare individual test cycles / test stages Execute test cycles Monitor test status and defect messages with defined metrics Resolve identified issues Re-rest and confirm issues resolution

Inputs
The inputs for the functional test are: Test strategy and approach document from the Business Blueprint phase Test plan / test concept document Existing approach and tool functionality for the following: Types of functional testing (e.g. unit test / test of custom developments, functional test, scenario test, end to end integration test) Decision on test coverage, e.g. utilizing risk analysis Methods of testing - manual and automated

Testing toolset including test management, defect management and test automation tools Requirements traceability Standards on test case development (content, detail level, reusability) Test data Test resources Defect management processes Test coordination Test metrics Test reporting and analysis Change control process Test / QA systems

Deliverables
The deliverables for each of the Functional test are: A. Test preparation Test landscape including test / QA systems and test tools Test tool setup according to test strategy and test plan / test concept Test cases for all relevant test stages

Test automation scripts (if in scope) Appropriate test data on test / QA systems to conduct test activities Detailed test planning for individual test stages / test cycles, including test resources assignment of testers to test cases test sequences

Training for testers on the testing tools including access to test cases and test data access to test systems documentation of test results test status maintenance documentation of defects and escalation paths point of contact for test related issues

B. Test execution results Documentation of test results Test status maintained Documentation of defects

C. Test results evaluation and resolution of issues Test status reports including pass / error rate Plan to address identified issues Re-testing plans

Expected results
The deliverable functional test is completed in several stages during the Realization phase. It provides reusable (manual and automated) test cases for execution of various functional tests (unit / scenario / integration) and detailed plans for execution of every functional test cycle.

The execution of test cycles during the course of the project provides test result documentation and an overview on the overall quality of tested objects. Defect management keeps track of errors and changes that were discovered during all test phases. It allows a structured approach to bug fixing. Test monitoring and reporting allow project stakeholders to make decisions based on solution quality.

User Acceptance Test

Purpose

User acceptance test (UAT) is the last test cycle of an SAP solution implementation and is an essential part of gaining end-user acceptance of the software system. This cycle normally occurs at the end of the realization phase of the implementation, subsequent to integration testing cycles, to ensure that the system has been tested thoroughly by the project team and is ready to be released to the end-user community. The emphasis of UAT is to demonstrate that the system functions as designed and that critical end users have received hands-on experience with the new system.

Inputs
The inputs required for the user acceptance test are: Test strategy and approach document from the Business Blueprint phase Test plan / test concept document Test / QA systems end-to-end business process test cases exit criteria for the selected scenarios Identified test data

Deliverables
The deliverables for the user acceptance test include: UAT cycle summary Test execution status Defect trending

Test defects report

Expected Results
UAT results document the project test results that validate the correctness of the configuration and provide the information needed for sign-off of this realization phase. When there is a formal contractual agreement as to the business case targets that are to be achieved, the user acknowledges through acceptance of the business processes that the implemented solution supports the users objectives.

Performance Test
Purpose
A test that takes into account the behavior of several transactions taking place in the system at the same time is referred to as a performance test. Depending on the size of the load a distinction between load and stress test is necessary. Although these tests reveal a number of critical risks for the productive use, they are in practice often neglected - sometimes with fatal consequences.

A performance test project is subdivided into five phases: Planning Performing a single user performance test Performing the load test Performing the stress test (optional) Completing

The planning phase consists of analyzing the processes to be mapped and the required data and selecting the load test tool. During this planning phase, a load profile (see load profile template) is created that serves as a basis for all other activities once it has been formally approved. The goal of the single-user measurement is to obtain a "best case" impression of the system performance, because it can be assumed that the response times in parallel operation can never be better than with a single user. If the system behavior observed is "too poor" alreadythat is, it doesn't meet the defined key performance indicators (KPIs)the system must be optimized before a load test is implemented. The execution of the load test comprises the provision of data and system as well as test runs with different system loads. The tests are followed by an analysis of the results and, if necessary, an

optimization phase. This means that it may be necessary to run through the execution analysis optimization cycle several times. Optionally, a stress test can be carried out after the load test. The stress test is used to further measure the system in order to obtain information on system reserves and boundaries. Comprehensive documentation in the form of a detailed report is created within the completion phase of the performance test project. The documentation ensures that the test can be repeated and contains a catalog of recommendations for actions to be taken based on the test results.

Inputs

The inputs for this subdeliverable are: Test strategy and approach document from the business blueprint phase Performance test plan from the business blueprint phase Business process description with test data relevant for performance testing Performance Test management artifacts and processes: Performance test plan and schedule Performance testing tool set Performance test data Performance test automations (scripting) Defect management for performance testing Performance test coordination Performance test reporting and analysis Performance test metrics (KPIs = Key performance indicators)

Expected Results

The final phase of the performance test project consists of creating a final report. This report is usually created by the persons who execute the test (load test coordinator and monitoring expert), and it should be formally approved by the customer. According to SAP Best Practices, the performance test report is divided into the following parts.

Executive Summary Action Plan Description of the Test Structure Description of Test Goals Documentation of the Test Execution Lessons learned