Asap methodology 1st phase- project preparation

ASAP Methodology for Implementation 7.2
Purpose
The ASAP methodology for implementation is a phased, deliverable-oriented methodology that streamlines implementation projects, minimizes
risk, and reduces total cost of implementation. ASAP takes a disciplined approach to project management, organizational change management,
solution management, and other disciplines applied in the implementation of SAP solutions. The methodology supports project teams with
templates, tools, questionnaires, and checklists, including guidebooks and accelerators. ASAP empowers companies to exploit the power of the
accelerated features and tools already built into SAP solutions.
Benefits of ASAP include:
 Faster implementations with streamlined and focused methodology
 More reliable projects, thanks to proven tools, accelerators, and best practices
 Lower risk
 More efficient use of resources
 Reduced costs
 Effective project management based on Project Management Institute standards
Phases
The ASAP methodology delivers the following phases:
1. Project preparation In the project preparation phase, the project team defines project goals, a high-level scope, and a project plan.
Executive sponsorship is secured, and the project standards and organization are set up. The implementation strategy
is defined and approved. At the same time, the project procedures, standards, organization, and staffing are finalized.
Roles and responsibilities of the entire project team are agreed upon and documented. The objectives of the project are
validated, and all initiation activities are documented in the project charter.
2. Business blueprint During this business blueprint phase, solution and technical designs are documented in the business blueprint. Lead
by solution and industry experts from the SAP Consulting organization, a series of structured process workshops are
planned and executed to arrive at the “to-be delivered" SAP enterprise solution. All available documentation for
standard, delivered support for SAP business scenarios and all relevant preconfigured support for best practices are
reviewed and discussed with SAP experts. All functional and technical requirements, coupled with project issues and
gaps, are documented in the SAP Solution Manager application management solution.
3. Realization In the realization phase, the SAP software system is configured and tested in a number of cycles. Initially, the baseline
configuration, which represents the core business process settings, is performed, tested, and confirmed. This is
followed with a series of configuration and development cycles, to implement the entire end-to-end solution. The
solution is tested in a number of cycle tests and in a focused end-to-end integration test. Configuration is documented in
SAP Solution Manager. All development such as enterprise services, interfaces, data conversion programs, reports, and
any required enhancements are built and documented in SAP Solution Manager. Legacy data conversion programs are
created and tested. The production system is installed during realization.
4. Final preparation Within the final preparation phase, all systems are known to function correctly following the approved integration test.
Technically, all integration issues should now be resolved. Detailed transition and cutover plans are created. The
customer support organization is put in place. The production system is set up with transports and customer data. At the
end of this phase, the production system is switched on and business operations start in the new environment.
5. Go-live support The purpose of the go-live support phase is to move from a preproduction environment to live production operation. An
easily accessible production support organization must be in place to support the end-user community, not just for the
first critical days of production operations, but also for long-term support.
6. Run The primary goal of the run phase is to ensure the operability of the solution. Operability is the ability to maintain IT
solutions in a functioning and operating condition, guaranteeing systems availability and required performance levels to
support the execution of the enterprise’s business operations. The recommended starting point of the phase is an
assessment of solution operation after the go-live support phase to identify the relevant SAP standards for solution
operations to be established or improved in the phase. The central operation platform is SAP Solution Manager, with the
documented solution based on the transferred project documentation.

Work Streams
The ASAP methodology is structured around the key project work streams that are outlined in the picture below. For each work stream, the
methodology lists the number of deliverables that are to be produced in each phase of the project.
The deliverables in later phases leverage or build upon deliverables completed in earlier stages. The roadmap is structured as a work breakdown
structure (WBS) that represents a complete list of deliverables that need to be completed by the project team.
The ASAP methodology for implementation projects represents a standardized work breakdown structure that provides the foundation for defining
implementation project work in a deliverable-oriented, hierarchical manner and managing the project work to completion.
ASAP methodology contains a standard set of templates, samples, accelerators, guidelines, and checklists for use by project teams in effectively
managing and completing SAP solution implementation projects.
SAP – Copyrights and Trademarks
© 2010 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the
express permission of SAP AG. The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries,
pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power
Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS,
HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and
Informix are trademarks or registered trademarks of IBM Corporation.Linux is the registered trademark of Linus Torvalds in the U.S. and other
countries.Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated
in the United States and/or other countries.Oracle is a registered trademark of Oracle Corporation.UNIX, X/Open, OSF/1, and Motif are registered
trademarks of the Open Group.Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or
registered trademarks of Citrix Systems, Inc.HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web
Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.
SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, Clear Enterprise, SAP BusinessObjects Explorer and other SAP products and services
mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries.
Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other
Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP
France in the United States and in other countries. All other product and service names mentioned are the trademarks of their respective
companies. Data contained in this document serves informational purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for
informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect
to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

PHASE – 1 : PROJECT PREPARATION
1. Project Preparation
Purpose
The project preparation phase provides initial planning and preparation for the project. Although each project has its own unique objectives,
scope, and priorities, the deliverables outlined below assist in completing the initiation and planning steps in an efficient and effective manner.
Work Streams
The major work streams for this preparation are:
 Project management
 Organizational change management (OCM)
 Training
 Data management
 Business process management
 Technical solution management
 Integrated solution readiness
1.1 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 the 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 project’s 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
1.1.1 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
1.1.1.2 Definition of Project Organization, Roles, and Responsibilities
Purpose
The purpose of this activity is to define the organizational structure, roles, and responsibilities of the project team. To complete this activity:
 Review the project charter and scope
 Identify the project and business process areas to be addressed as part of the project and get a feel for the size of the team
 Determine the project team structure
 Review the project team structure with the program manager for approval
 Define roles and skills required for team members
Inputs
The inputs to this task are:
 Handover information from the opportunity management phase
 Work breakdown structure with role assignments from the ASAP methodology roadmap
Subdeliverables
The deliverables from this task are defined project organization, roles, and responsibilities.
Additional Information
If the project scope includes applications based on service-oriented architecture (SOA), ensure in an early stage of the project that the customer
prepares for SOA readiness. Further guidance on this topic is provided in Run >> Governance Model for Organization – Optimization >> SOA
Readiness (see also the linked node).

1.1.1.3 Phase Resources Allocation
Purpose
The purpose of phase resources allocation is a confirmation of resource availability for the particular phase. The resource plan and
scheduledetail 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.
1.1.1.4 Assignment of Roles and Responsibilities
Purpose
The purpose of this deliverable is to identify and select global company and external resources for the project in accordance with the required
roles, skills, and responsibilities specified in the preceding task. The assignment of people to roles should also take into account their qualifications
and availability for the whole project time frame.
Care should be taken to fill these positions with the most capable people in the company.
To assign roles and responsibilities:
 Match company and consulting resources to roles
Company personnel need to fill roles on business process teams. The ratio of company staff to consultants used will vary depending on the
availability of company resources, program management’s strategy on the use of consultants, and funding considerations. During a start-up
phase of a global program, the development project typically employs one consultant for every three to four company resources. As the
program progresses and knowledge transfer occurs, fewer external resources should be required.
External resources are ideally suited to functions that need specialized business process and configuration skills for short durations.
Unless IT management is outsourced for strategic reasons, it is advisable to have client IT personnel in the SAP project (see also SAP
Customer Competence Center). Otherwise, it is difficult for the corporate enterprise to properly evaluate different IT strategies and
technologies.
 Assign resources to roles
Inputs
The inputs to this deliverable are the defined project organization, roles, and responsibilities.
Subdeliverables
The subdeliverables are:
 The project team organizational chart with assigned people
 Resources assigned to roles and responsibilities
1.1.1.5 Team Onboarding
Purpose
The purpose of this activity is to prepare the onboarding package for external consultants from SAP and partner companies.
The triggers for this activity are:
 Defined milestone plan
 High-level project schedule
 Organizational chart for the project, showing both internal and external resources
 Definition of the existing SAP landscape
 Determination of possible premises for the consultants
 Travel policies and other project guidelines, if available
Inputs
The inputs to this activity are assigned roles and responsibilities.
Subdeliverables
The subdeliverables from this activity are:
 Handover project guidelines (company overview, consultants guidelines, project timeline, and project scope, for example)
 Onboarding package
1.1.1.6 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 project’s 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
1.1.2 Project Initiation
Purpose
The purpose of this project initiation deliverable is to formally recognize that a new project exists. It supports the decision to accept the project,
align stakeholders – such as clients, customers, and SAP management – around a project and its scope, provide updated information for planning,
and obtain a commitment to proceed. It ensures alignment between SAP, the customer’s strategic direction, and the satisfaction of operational
requirements.
Inputs
The inputs to this activity are:
 Implementation project phases and deliverables
 SAP solution map and/or SAP business scenario map (output from Solution Composer)
 Implementation effort estimates based on work packages
 Final project calculation (PPM)
 Results of risk assessment in the form of a risk profile statement
 Definite staffing assumed and availability verified
 Proposal documents
 Value-based solution scope
 High-level technical architecture
 Delivery model drafted according to ISD guidelines
 Business case and/or CVA (optional)
Deliverables
The deliverables generated from this activity are:
 Project charter
 Scope statement
 Business case
 Schedule for project planning
 Project manager agreement
1.1.2.1 Business Case
Purpose
The business case identifies expected benefits and balances them against the strategic direction and costs. It provides the economic justification
for the proposed project and documents how and when the investment will be profitable for the customer. Information included in the business
case is the essential business reason for this project, the costs, and the benefits. The business case is a key input for the Value Roadmap.
Inputs
In creating the business case, consider the following inputs:
Section Key Content Inputs
Objective What business need the project is
solving
 Customer business case
 SAP business case, value
assessment, orbusiness assessment
 SAP collaborative value assessment
Problem and
Opportunity
“As-is” situation
Proposed
Resolution
“To-be” situation  Statement of work (SOW)
 Proposal

Strategic Alignment Customer business strategy and
technical strategy
Benefits Tangible and intangible benefits  Customer business case
 SAP value map from the SAP Value
Delivery Management portfolio of services

Investment
Appraisal
 Cash inflows
 Cash outflows
 Discount rate
Dependencies Geographic and organizational
scope – people, associated
locations, languages, and
organizations affected or impacted
by the proposed solution
 SAP value map
 SOW
 Proposal
Affected Systems System scope – systems and
associated locations affected or
impacted by proposed solution
 SOW
 Proposal
Stakeholders Starting with C-Level management  Company fact sheet
 SAP value map
SAP has developed two platforms to accelerate the creation and development of project business cases: SAP Value Lifecycle Manager and SAP
Benchmarking program.
SAP’s Value Lifecycle Manager (VLM) is an online business-case building platform with over one million datapoints (best practices and value
drivers) covering more than 70 sub-industries. VLM has industry and solution specific Business Case templates that can significantly reduce the
effort required to complete the analysis and produce a deliverable.
SAP’s Business Performance Benchmarking was developed in conjunction with users groups and industry associations, the program identifies
KPIs and best practices that can be deployed to help companies diagnose business performance and to develop high-impact recommendations
for improvement. Established in 2004, SAP’s initiative is now one of the largest benchmarking programs in the industry, including more than
10,000 participants from more than 3,000 companies.
Subdeliverables
This activity generates a reviewed and approved project business case that is documented and communicated to the project team. It also provides
the foundation for value based scoping or value roadmap. A Value Roadmap aligns the project scope and implementation sequence to operational
and strategic goals optimizing time-to-value.
If It Is Not Done
The business case is the central controlling instrument for value delivery during the project. If this step is skipped, the primary business objectives
and customer expectations cannot be measured at the end of each project phase. It is important for customers to assess their business objectives
during the review of project deliverables at the end of each phase closure and realize that their expectations are being met. Without a business
case there would not be a record if the project was successful based on the value dimension and there is a high risk that the full value potential of
the project cannot be reached.
For further information, refer to:
 Business Transformation Services group services: business case, value assessment, and business assessment service; collaborative value
realization service; and value roadmap
 SAP value engineering tools and services: SAP Value Lifecycle Manager, SAP Benchmarking Program and collaborative value assessment
service
 PMBOK
®
Fourth Edition, Chapter 4, Project Integration Management
Adapted from PMBOK
®
Fourth Edition, Chapter 4, Project Integration Management © 2008 Project Management Institute

1.1.2.2 Project Charter
Purpose
The project charter is developed by reviewing documents from the pre-project negotiation process and through interactive meetings with the
customer to facilitate an understanding of the project’s goals, business case, external assumptions, and constraints. The project charter clearly
and explicitly defines the objectives of the proposed project, analyzes all possible benefits, and quantifies benefits in financial terms. This
information and supporting documents align key stakeholders around the strategic intent of the project.
Inputs
When creating the project charter, consider the following inputs:
Project Overview  Current, “as-is” situation and business needs
 Proposed resolution, “to-be” situation, and high-
level summary of what the project will deliver
from an organizational, functional, technical, and
geographic point of view
 Project business case
 Statement of work (SOW)
Project Scope  Characteristics of the solution or service that the
project was undertaken to create; note out-of-
scope organizational, functional, process, and
development objects (such as data cleansing),
and technical applications
 Overall project goal
 SOW
 Proposal
Project Objectives SMART (specific, measurable, attainable, relevant,
and time-bound) aims of the project derived from
requirements, benefits, project needs, and measures
of success aligned to corporate and organizational
strategies and the project goal
 SOW
 Proposal
Deliverables Produced by the team to ensure project success  SOW
 Proposal
Business Case
Summary
Summary of justification for project, return on
investment (ROI) and related key performance
indicators (KPIs)
Value Based
Roadmap
Proposed sequence of projects and programs that is
required to achieve strategic and operational goals
and optimize the time to value
 On-going initiatives
Total Estimated
Project Costs
Estimated total project costs through closing  SOW
 Proposal
Implementation
Strategy
The approach selected for the project based on the
analysis of solution options during the evaluation
phase
 Proposal
 Prestudy
Project Planning A summary level schedule (chart or graph) with high-
level dates that identifies the major ASAP
methodology milestones related to phases and value
delivery
 SOW
 Proposal
Project
Stakeholders
Persons or organizations actively involved in the
project or whose interests may be positively or
negatively affected by execution or completion of the
project
 SAP value map from the
SAP Value Delivery
Management portfolio of
services
Assumptions Factors that are considered to be true, real, or
certain without proof of demonstration and project
limits
 SOW
 Proposal
 SAP value map
Constraints Factors that limit options and are beyond the control
of the project team, resulting in a state, quality, or
sense of being restricted to a given course of action
or inaction
 SOW
 Proposal
 SAP value map
Risk Assessment Factors that may have a negative impact on the
project
 Proposal
 SAP risk assessment
Approval Approval from the program sponsor – the key
individual, person, or group that provides financial
resources to the project
 Signatory authorization
Subdeliverables
This activity generates a reviewed and approved project charter that is documented and communicated to the project team.
If It Is Not Done
If you skip this step, the project is not formally approved by the customer sponsor and the project manager is not authorized to apply
organizational resources to project activities.

Assess whether the customer has existing:
 Organizational policies and procedures, standard product and project lifecycles, and quality policies
 Standardized guidelines, work instructions, and proposal evaluation criteria
 Guidelines and criteria for tailoring the organization’s set of standard processes to satisfy the specific needs of the project
 Organizational communication requirements, such as record retention and security requirements
 Procedures for issue and defect management, including controls, identification and resolution, and action item tracking
 Change control procedures, including the steps by which the company modifies, approves, and validates official company standards, policies,
plans, and procedures as well as project documents
 Risk control procedures, including risk categories, probability definition and impact, and probability and impact matrix
For further information, refer to PMBOK
®
Fourth Edition, Chapter 4, Project Integration Management.
Adapted from PMBOK
®
1.1.2.3 Scope Statement
Purpose
The scope statement facilitates an initial understanding of the project scope and associated project-related assumptions and constraints. The
project scope statement evolves through the initiation and planning of the project and clearly and explicitly defines the deliverables of the proposed
project. This information and supporting documents align key stakeholders around what the project is going to deliver.
Inputs
In completing the scope statement, consider the following inputs:
Project Goal “To-be” process – describing the overall
goal to be achieved by the project
 Project charter
Solution or Service
Description
Detailed summary of organizational,
functional, development, technical,
geographic, and language scope
 Statement of work
(SOW)
Project Requirements Documentation of the capabilities or
conditions that must be met by the project
 SOW
 Proposal
Project Objectives Customer strategies (corporate and
organizational) aligned with project goals
 Validated Business Case
 Proposal
Deliverables Key deliverables produced by the team to
ensure success
 SOW
 WBS
Project Boundaries List of specific systems (SAP and
customer applications) within the project
scope
 SOW
Out of Scope Notation of out-of-scope organizational,
functional, process, and development
objects (such as data cleansing for
conversions), and technical applications
 SOW
 Proposal
Project Assumptions Items or factors that are considered to be
true, real, or certain without proof of
demonstration and project limits
 SOW
 Proposal
Project Constraints Factors that limit options and that are
beyond the control of the project team,
resulting in the state, quality, or sense of
being restricted to a given course of action
or inaction
 SOW
 Proposal
Project Risk
Assessment
Risks that may have a negative or positive
impact on the project
 SOW
 Risk register
Implementation
Strategy
Description of the ASAP methodology and
approach for implementation
 SOW
 ASAP methodology
description
Initial Work Breakdown
Structure (WBS)
Decomposition of deliverables  WBS
Project Organization Project organizational chart of individuals
and organizations that have specific roles
in the project team
 Human resource
management plan
Acceptance Criteria Scope verification process  Scope management plan
Schedule Milestones Key project milestones and dates  SOW
Order of Magnitude
Project Costs
Estimated total project costs through
closing
 SOW
Business Benefits Validated business benefits associated
with the implementation program
 Validated Business Case
(including Value Maps,
Value Enablers, KPIs,
PPIs)
Configuration The approach for documenting product  Integrated change
control plan

Management
Requirements
characteristics and integrated change
control
Project Costs Needed
to Proceed
Estimated project costs required to move
to the next phase
 Project cost and effort
estimate
Approval Approval from customer project sponsor,
customer key stakeholders (if applicable),
customer and SAP project management
team, and customer and SAP team leads
to manage organizational, functional,
development, technical, and geographic
scope in the next phase of the project
implementation
 Signatory authorization
Deliverables
This step generates a reviewed and approved scope statement that is documented and communicated to the project team, enabling integrated
change control.
1.1.2.4 Schedule for Project Planning
Purpose
The schedule for project planning covers all project planning activities for the entire project, including identification of milestones, quality gates,
and end dates, as well as estimated costs and budgets. The schedule for project planning includes all scheduled tasks, resources, and start and
end dates for all activities that will be performed during the planning of the project.
The project manager builds on this schedule during subsequent planning activities, using a “rolling wave” approach.
Schedule Development (Rolling Wave)
During the project preparation phase, the team details the schedule that takes team members through to the end of
thebusiness blueprint phase only (that is, the planning phase approval checkpoint). 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. Replanning 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.
Inputs
The inputs to the schedule for project planning are:
 Project charter
 Scope statement
Subdeliverables
This step generates the detailed project schedule.
1.1.3 Project Management Plan
Purpose
The purpose of the project management plan definition deliverable is to develop the project management plan and the subsidiary plans on the
basis of the project scope defined in the project charter. This includes the development of the project schedule, the budget, and appropriate
updates to the business case.
The project management plan is a comprehensive document (or collection of documents) that includes the schedule, cost information,
monitoring/controlling plans for each of the nine knowledge areas of the project management body of knowledge (PMBOK), and other information,
as appropriate.
The subsidiary management plans developed for each of these areas provide the foundation to support the consistent application of project
management practice:
Integrated change control provides a method of controlling and monitoring project changes. Change is defined as any activity that alters the
scope, schedule, deliverables, value, or costs of the project.
The issue management procedure provides a method of managing and resolving project issues. An issue is a situation, action, problem, or
question arising during the project, that the project team cannot resolve efficiently or effectively.
The scope management plan outlines the processes required to ensure that the project includes all of the work required, and only the work
required, to complete the project. The scope management plan elaborates on sections of the project management plan that pertain to the
functions of scope management.
The time management plan outlines the processes required to ensure timely completion of the project. It elaborates on sections from the project
management plan that pertain to the functions of time management.
The cost management plan outlines the processes required to plan, estimate, budget, and control project costs. It elaborates on sections of the
project management plan that pertain to cost management.

The quality management plan outlines the specific organization, processes, and services needed to ensure quality on the project. It elaborates
on sections of the project management plan that pertain to quality management.
The human resource management plan outlines the processes required to staff, organize, and manage the project team. It elaborates on
sections of the project management plan that pertain to human resource management.
The communication management plan outlines the processes required to ensure timely generation, distribution, storage, and retrieval of project
information. It elaborates on sections from the project management plan that pertain to communication management.
The risk management plan defines how risks are identified, analyzed, review, and managed. It describes how often risk reviews are conducted.
The project contract inventory contains all contractual agreements with product and service providers for the project. For an implementation
project, this may include contractual arrangements with hardware providers, organizational change management, training, hosting, off-shore
delivery, and application management service providers, for example.
Inputs
This deliverable includes the following inputs:
 Project charter
 Handover from proposal or preproject activities
 Statement of Work (SoW)
 Customer policies, procedures and guidelines
 Assigned roles and responsibilities
 Stakeholder Analysis
 Applicable templates
Deliverables
This deliverable generates the following outputs:
 Project management plan and subsidiary plans
 Project schedule
 Project budget
®
Fourth Edition, © 2008 Project Management Institute
1.1.4 Executing, Monitoring, and Controlling of Results
Purpose
In directing and managing project execution, the project managers and the project team perform multiple actions to execute the project
management plans to accomplish the work defined in the project scope statement.
In executing project work, the project team:
 Performs activities to accomplish project objectives
 Expends effort and funds to accomplish project objectives
 Staffs, trains, and manages the project team members assigned to the project
 Obtains, manages, and uses resources
 Implements and executes the planned methods and standards
 Creates, controls, verifies, and validates project deliverables
 Manages the scope of the approved work
 Manages risks and implements risk response activities
 Manages issues to closure
 Adapts approved changes to the scope, plans, and project environment
 Establishes and manages internal and external communications
 Collects project data and reports progress and performance
In monitoring and controlling project work, the project team:
 Compares actual project performance against the project management plan
 Assesses performance to determine whether corrective or preventative actions are needed
 Monitors and controls project risks
 Provides metrics to support progress and performance reporting and forecasting
 Monitors implementation of approved changes
Management plans developed during the project preparation phase (see “Project Management Plan Definition”) guide the team's approach to
management, execution, and control of project activities. The project manager is responsible for ensuring that management plans are applied at
the appropriate level of control.
Inputs
The inputs to the executing, monitoring, and controlling of results are:
 Project initiation documents
The project initiation documents (business case, project charter, project scope statement) describe the project in terms of objectives,
scope, stakeholders, and project influences (risks, assumptions, and constraints).
 Management plans
The management plans detail specific activities for each of the nine project management body of knowledge (PMBOK) areas. These plans
provide the foundation to support the consistent application of project management methods across the SAP project organization based
on the project scope.
The detailed project schedule defines the work to be performed, what resources and associated time commitments are required for the

project, and its phases. The work breakdown structure (WBS) is the foundation for the schedule and documents the deliverables to be
produced as part of the project. The resource and time commitment estimates can be used to calculate end dates and costs.
 Project budget
The project budget outlines all of the costs associated with the project, including labor, hardware, software, contracting fees, and facilities.
 Project charter
Deliverables
The outputs of this deliverable are:
 Project performance reports, including:
 Team member status reports
 Project status reports
 Executive status reports
 Quarterly operations reviews
 Project budget updates
 Approved change requests
 Change control log updates
 Issue log updates
 Refined WBS and WBS dictionary
 Project schedule and blueprint workshop schedule
 Requests for change
 Scope statement updates
 Scope verification matrix updates
 Project schedule updates
 Risk register updates
 Communication matrix updates
 Team member evaluations (non-SAP resources)
 Team member appraisals (SAP resources)
®
Fourth Edition, Chapter 4, Project Integration Management.
Adapted from PMBOK
®
1.1.4.1 Project Performance Reports
Purpose
Throughout the project, a number of project performance reports need to be produced for different purposes and audiences, as defined in
theproject communication plan.
Inputs
The inputs to project performance reports are:
 Communication management plan
 Interim team member status reports
 Interim project team status reports
 Interim project status reports
 Interim executive status reports
Subdeliverables
 Team status reports, using the team status report template
 Project status reports, using the project status report template
 Program status reports, using the status report program template
1.1.4.2 Project Budget
Purpose
The project budget, including monitoring and control, outlines all costs associated with the project, including labor, hardware, software,
contracting fees, and facilities.
Inputs
The inputs to the project budget are:
 Project charter
 Cost management plan
Subdeliverables
The outputs of a project financial management tool are:
 Detailed information on contracting fees and associated travel expenses
 Approved project budget baseline

1.1.4.3 Change Request Log Updates
Purpose
A consistent, comprehensive approach to managing the lifecycle of a potential change is a critical component of an integrated change control
system. The change request form enabling the change control procedure must support the multiple levels of analysis and approval required to
deal with a requested change. For tracking purposes, all change requests are logged in a change request list.
Inputs
The change request form supports the execution of the integrated change control procedure.
Subdeliverables
 Disposition of change requests in accordance with the integrated change control process.
 Updated change request list
When dealing with change request management for the implementation project, it is recommended that you define operational change
management procedures. Further guidance on this topic is provided in Run >> Change Management >> Change Request Management/Change
Control Management (see also linked nodes).
1.1.4.4 Issue Log Updates
Purpose
A consistent, comprehensive approach to managing project issues is a critical component of an effective project management system. The SAP
Solution Manager application management solution (or an issue log, if SAP Solution Manager is not available in your project) supports the issue
management procedure by enabling the multiple levels of analysis and decision making required to deal with an issue. The issue report in SAP
Solution Manager (or issue log) is a formal record of all issues raised for the project. Effective issue management involves the appropriate level of
management making decisions on issues and tracking progress on issue resolution in accordance with the project issue management
procedure. The issue log is formally closed out with other project controlling documentation during project completion activities.
Inputs
The SAP Solution Manager or issue log supports the execution of the issue management procedure.
Subdeliverables
This step results in the disposition of project issues in accordance with the issue management procedure.
1.1.4.5 Work Breakdown Structure and Dictionary
Purpose
The work breakdown structure (WBS) is a deliverable-oriented, hierarchical decomposition of the work to be executed by the project team to
complete the project. It is the basis for the organization and coordination of the project. A WBS consists of WBS elements that describe project
tasks and subtasks to perform within a defined time period.
Inputs
The inputs to the WBS are:
 Project charter
 Statement of work
 Business case and value map (if available)
 Scope management plan template
 WBS template (from the opportunity management phase)
Subdeliverables
This step generates a reviewed and approved first WBS as well as a WBS dictionary, which are documented and communicated to the project
team.
If It Is Not Done
Skipping this step limits visibility and control in managing scope and integrated changes; this can adversely impact the schedule, budget, value,
and quality of the project.
®
Fourth Edition, Chapter 5, Project Scope Management.
Adapted from PMBOK
®
Fourth Edition, Chapter 5, Project Scope Management © 2004 Project Management Institute

1.1.4.6 Project Schedule and Blueprint Workshop Schedule
Purpose
The detailed project schedule defines the work to be performed, the resources and associated time commitments required for the project, and
the phases of the project. The work breakdown structure (WBS) serves as the foundation for the schedule and deliverables to be produced as
part of the project.
At a minimum, the schedule should include:
 Deliverables and tasks for the current phase
 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 and must-finish-on date)
 Resources assigned to each task
 High-level schedule for subsequent phases
The project manager further elaborates this schedule during subsequent planning activities, using a “rolling wave” approach.
Use the time management plan template, in consultation with the customer project manager, to define an appropriate time management plan for
the project.
Inputs
The inputs to the project schedule are:
 Time management plan template
 Project charter
 Project scope statement
 WBS template (from the opportunity management phase)
 Customer policies, procedures, and guidelines
Subdeliverables
This step generates a refined time management plan with a blueprint workshop schedule.
®
Fourth Edition, Chapter 6, Project Time Management.
Adapted from PMBOK
®
Fourth Edition, Chapter 6, Project Time Management © 2004 Project Management Institute
1.1.4.7 Project Risk Register Updates
Purpose
The purpose of the project risk register is to document the risks affecting a project and the strategies chosen by the project team to manage
them. The project risk register details the following information (note that this is not an exhaustive list of all project risk data types):
 Basic project information including project name, customer name, project purpose, and key participants
 Risk title (name)
 Condition
 Indicator
 Consequence
 Impact
 Owner
 Expected loss
 Response type etc.
Inputs
The inputs to the project risk register update are:
 Project management plan
 Risk management plan
 Project risk list with identification of risk management roles (responsible, accountable, consulted, informed)
Subdeliverables
This step generates the project risk register update, a comprehensive view of project risk, impact, and response strategies adopted by the project
team.
If It Is Not Done
If the project risk list is not created and managed, the project team will not have a complete picture of project risks, impacts, and response
strategies. The lack of this important document will likely result in cost overruns, project delays, and customer dissatisfaction due to ineffective
responses to risks.
1.1.4.8 Communication Matrix
Purpose
Throughout the project, as more is known, the communication matrix should be reviewed and updated. The communication matrix documents
the project team’s approach to communication. It captures the analysis completed as part of communications planning and serves as a tool to
guide the project team throughout the project.
The matrix holds the following information for each communication:
 Communication reference number
 Target audience (stakeholder) analysis, including:
o Audience
o How the audience is impacted
o How the audience will be engaged

 Communications planning, development, and delivery, including:
o Communication event
o Message intent
o Timing
o Vehicles
o Sender
o Feedback mechanism
o Comments
Project communication typically falls into one of two primary categories: internal project communications or stakeholder communications.
Inputs
The inputs to the communication matrix are:
 Communication management plan
 Stakeholder analysis
Subdeliverables
This step generates a reviewed and updated communication matrix.
1.1.4.9 Team Member Evaluations and Appraisals
Purpose
As part of the human resources management of the project, the project manager manages and develops the team, including evaluating
performance. You should introduce the concept of team member evaluations and appraisals when new members join the team, to discuss
performance development opportunities and objectives for the individual while on the project. This information needs to be recorded for reference
and reviewed during a final meeting before the team member leaves the project.
Inputs
The inputs to team member evaluations and appraisals are:
 Additional appraiser template
 Feedback from the customer program manager, project manager, and subproject manager
Subdeliverables
This step generates internal and external appraisals.
1.1.5 Project Standards
Purpose
Project standards provide a consistent means of executing and governing project work in an efficient and effective manner. Their key objective is
to identify, define, approve, and communicate standards related to project execution.
Project standards are elaborated throughout the project initiation and planning phases. During the project preparation phase a subset of the
project standards must be defined, approved, and communicated to the project team. Communication of project standards should be included in
project onboarding communications and phase start-up meetings. Given the integrated nature of project standards, changes must be managed in
accordance with the integrated change control procedure.
Inputs
The inputs to project standards are:
 SAP Solution Manager usage guidelines
 Business process modeling standards
 Initial development management standards
 SAP Services deployment plan
 Software system configuration standards
 Enhancement and modification standards
 Support package and upgrade standards
 Change request and transport management standards
 Test management standards
 Postimplementation service and support standards
 Enterprise service standards
 Composite application design and development standards
Subdeliverables
This step generates documented, approved, and communicated project standards in accordance with the integration management plan.

SAP has defined the following ALM processes. More information on these processes can be found at SAP Service Marketplace
(http://service.sap.com/ALM).
Find below a high level mapping of ALM phases and SAP Standards for Solution Operations.
ITIL ALM Phase SAP ALM Process SAP Standard for Solution Operations
Requirements Solution Documentation Solution Documentation
Design
Solution Implementation Test Management
Template Management
Build & Test
Test Management Test Management
Change Control Management
Change Management (Change Request
Management, Change Control
Management)
Deploy Application Incident Management
Incident Management
Remote Supportability
Root Cause Analysis
Operate
Technical Operations
System Administration
System Monitoring
Root Cause Analysis
Business Process Operations
Exeption Handling & Business Process &
Interface Monitoring
Job Scheduling Management
Data Integrity and Transactional
Correctness
Data Volume Management
Optimize
Maintenance Management Change Management
Landscape Transformation
Upgrade Management
Change Management
Upgrade
Data Volume Management
Not assigned Security
1.1.5.1 SAP Solution Manager Usage Guidelines
Purpose
The purpose of the SAP Solution Manager usage guidelines deliverable is to define and set up a structured way for the SAP Solution Manager
application management solution to support a standard SAP implementation project to the best effect in the preparation phase. The SAP Solution
Manager usage guidelines include the setup of a project in SAP Solution Manager and provide the project team with the definition of fundamental
project standards including naming conventions, document types, status values, and authorization concepts.
Inputs
The inputs for the SAP Solution Manager usage guidelines are:
 Project team organization
 Project standards
 System landscape
Subdeliverables
This step sets up the project in SAP Solution Manager, including a definition of project standards.
Expected Results
By completing the SAP Solution Manager usage guidelines subdeliverable correctly, the project will gain a fundamental basis for standards in the
project and align them to SAP Solution Manager.
The SAP Solution Manager usage guidelines refers to document types and corresponding templates to be used in SAP Solution Manager. These
can be found in an attached accelerator.
When defining documentation standards for various documentation needs during the implementation project (for example, project documentation,
configuration documentation, enhancement and modification documentation) it is recommended that you define and prepare for as well as cross-
check the SAP standards for solution operations. Further guidance on this topic is provided in Run >> SAP Application Management >>
Solution Documentation (see also linked nodes).
Furthermore you find one service link to “Expert Guided Implementation.” Expert-guided implementation is a new optimized, short-term setup
service to configure basic settings for SAP Solution Manager without long-term, in-house consulting. This service balances the combination of
training, practical experience, and expertise on demand and allows customer to create ready-to-use baseline functionality for implementation of
end-to-end solution operations.
1.1.5.2 Business Process Modeling Standards
Purpose
The purpose of business process modeling standards is to have a standard approach for executing process modeling. SAP provides a
standardmodeling handbook, which delivers the rules for process-oriented analysis and design. This handbook is meant as a general
guideline for everybody who does work on either:
 Process modeling
 Service modeling

The modeling handbook also gives information about the integration between:
 ARIS software and SAP Solution Manager
 ARIS and the Enterprise Services Repository (ES Repository)
The handbook provides comprehensive definitions and is strictly focused to deliver process modeling guidelines that are clear and directly
applicable in project work.
The process modeling tool used for the modeling guidelines is ARIS; it should be seen as an example. Thus, the definitions, shapes, and stencils
provided can be transferred to any other process modeling tool easily; an example is given for Visio. Please view the SAP Modeling Handbook on
the Business Process Expert (BPX) community Wiki site.
Inputs
The inputs to the business process modeling standards are:
 Project scope
 Basic business scenario
 Process inventory
Subdeliverables
 Business scenario documents
 Business process documents
 Process flow diagrams
By completing the business process modeling framework deliverable correctly, the project gains a fundamental basis for process modeling and
service modeling standards.
When defining business process modeling standards, it is recommended that you define and prepare for as well as cross-check the SAP solution
documentation: SAP standards for solution operations with respect to business process modeling. Further guidance on this topic is provided in
Run >> SAP Application Management >> Solution Documentation (see also linked nodes).
1.1.5.3 Initial Development Management Standards
Purpose
With the increasing number of systems and technologies, the complexity of IT solutions is rising. The key to successful landscape planning and
operation is an accurate and complete description of the solution landscape itself with all business processes. All reporting is based on this
fundamental information.
As part of SAP’s standards for end-to-end solution operations, the standard for solution documentation describes in general how customers
achieve the required transparency of their SAP solution. On one hand, minimal documentation as described in this subdeliverable lays the ground
for leveraging many operations support functions offered via SAP Solution Manager (for example, identifying affected custom business processes
or customizing change requests). On the other hand, it is important to have the documentation in a standardized location and format to ensure the
optimal delivery of SAP support services. To enable SAP to deliver services for custom projects especially, a minimum amount of documentation
is required. This subdeliverable describes the required content of this documentation as well as the tools and formats to be used to deliver it.
Inputs
The input to initial development management standards are the best practices and recommendations for SAP custom development standards.
Subdeliverables
This step generates customer-agreed standards for custom development. By completing the deliverable correctly, the project gains guidelines for
creating custom development documentation, enabling future services and upgrades.
When defining documentation standards for various documentation needs during the implementation project (such as project documentation,
configuration documentation, and enhancement and modification documentation), it is recommended that you define and prepare for as well as
cross-check the SAP solution documentation: SAP standards for solution operations. Further guidance on this topic is provided in Run >> SAP
Application Management >> Solution Documentation (see also linked nodes).
1.1.5.4 SAP Services Deployment Plan
Purpose
Managing complexity, risk, and costs as well as skills and resources is at the heart of implementing mission-critical support for SAP-centric
solutions. The complexity rises even further with the trend of out-tasking and outsourcing process components. To help customers manage their
SAP-centric solutions, SAP provides a comprehensive set of standards for solution operations.
Out of this set of standards, the system administration standard describes processes for the administration of SAP-centric solutions. The term
“system administration” encompasses all activities that ensure the successful, long-term operation of a solution from a technical perspective. The
range of activities that can be included in the broadest sense of system administration is therefore very extensive. As usual in this context, the
main areas of system administration are treated separately. Procedures for data management, change management, and incident management,
for example, are explained in separate documents. This document provides an overview of the various regularly-occurring standard system
administration tasks and associated tools.
Over the course of evolving to service-oriented architecture (SOA) solutions, vertical system administration based on a technical system gives way
to horizontal system administration based on processes. Consequently, the different subject areas in system landscape administration must be
combined and provided in a central location. The platform for this is SAP Solution Manager.
Inputs
The input to the SAP Services deployment plan is the SAP Services deployment process.

Subdeliverables
 SAP Services deployment plan
 System administration guidelines
By completing the SAP Services deployment plan correctly, the project gains guidelines for deploying system administration services.
1.1.5.5 Software System Configuration Standards
Purpose
The purpose of the software system configuration standards subdeliverable is to establish standards for SAP software system configuration for
those who perform initial configuration setup. The system configuration is a crucial part of SAP software implementation, so only selected
groups should have access and authority to make any changes to the SAP software configuration. The defined standards must follow the SAP
installation guides and best practices but should also take into account already established principles for existing systems.
Software system configuration standards must provide guidelines for software installation as well as specifications for the initial system
administration and system monitoring configurations.
Inputs
The inputs to the software system configuration standards from the project are:
 Project standards guide
 Standard installation guides and best practices guides
An overview of the standards and naming convention in the existing infrastructure is required to adapt the project landscape to the existing
landscape:
 Naming conventions for systems and software
 Customer-specific standards for system configuration (hardware, operating system, and software)
 Documentation requirements
Subdeliverables
The software system configuration standards generate:
 Naming conventions for operating system setup
 Documentation of standards for hardware and operating system setup
 Naming conventions for software installations
 Documentation of standards for software installation
 Specification of configuration requirements for system monitoring
 Specification of standard configurations for system administration
Accelerators giving guidance on how SAP system configuration standards are applied using SAP Solution Manager can be found via the linked
nodes.
When defining documentation standards during the implementation project – including project, configuration, and enhancement and modification
documentation – it is recommended that you define, prepare for, and cross-check the SAP solution documentation: SAP standards for solution
operations. Further guidance on this topic is provided in Run >> SAP Application Management >> Solution Documentation (see also linked
nodes).
1.1.5.6 Enhancement and Modification Standards
Purpose
Custom development, enhancements, and even modifications of SAP software are not rare at companies today. They are implemented to extend
the functionality of SAP standard software and to adjust it to the company-specific needs and business processes. This is often needed and
legitimate.
But over time, such changes often become major cost drivers and performance bottlenecks. Additionally, custom code is developed despite the
potential for standard enhancements, often due to insufficient information about standard functionality provided by SAP. In addition, custom code
can become obsolete over time though still maintained. And finally, poor software quality often causes problems in production environments and
drives costs for improvement and adaptation.
All these are reasons for implementing sustainable custom code management in your organization. Custom code management is the process
of constant examination and optimization of the four dimensions of custom code: quantity, quality, technical severity, and business criticality, as
well as the preparation and adoption of SAP custom development for daily operations and support. Thus, enhancement and modification
standardsprovide a holistic view of custom development from the operations perspective, not from the development itself. The topics and
methodology described in this subdeliverable are oriented purely to the ABAP programming language.
Inputs
The inputs to enhancement and modification standards are best practices and recommendations for enhancement and modification standards.
Subdeliverables
 Customer-agreed enhancement and modification standards
 SAP custom code management procedures
If the project scope includes custom code development, it is recommended that you ensure in an early stage of the project that the customer
defines and prepares for custom code management. Further guidance on this topic is provided in Run >> Custom Code Operations >> Custom
Code Management (see also linked nodes).

1.1.5.7 Support Package and Upgrade Standards
Purpose
Managing complexity, risk, and costs as well as skills and resources is at the heart of implementing mission-critical support for SAP-centric
solutions.The complexity rises even further with the trend of outsourcing process components. To help customers manage their SAP-centric
solutions, SAP provides a comprehensive set of standards for solution operations.
In this set of standards, the upgrade standard provides guidance for holistic and effective quality management of an upgrade project end to end,
from its earliest stages of evaluation until after a successful cutover of the productive system. The standard defines the key focus areas, provides
guidance, and explains best practices for the management of upgrade projects. All this helps customers better understand and manage the major
technical risks and challenges of an upgrade project and to make it a non-event for the business.
This subdeliverable provides details regarding the upgrade standard. It explains the basic concept of the standards, describes the seven key focus
areas of upgrade projects, and lists and explains the activities within the different phases of a standard SAP upgrade project.
Inputs
The inputs to this subdeliverable are the SAP support package and upgrade standards.
1.1.5.8 Change Request and Transport Management Standards
Purpose
The purpose of change request and transport management standards is to set up and configure the change and transport system (CTS)
scenario within fully-controlled change request management. This subdeliverable gives the customer a method for monitoring change requests
that are in progress or completed in an implementation project and in a production system. It also helps the customer manage and control the
transports that belong to the change request. A controlled change request management process using functionality of SAP Solution Manager
controls the integrated change and transport lifecycle of an implementation project and of a production system landscape.
Inputs
The inputs for the change request and transport management standards are:
 CTS standards and procedures for project members
 SAP Solution Manager technical configuration and setup of the system landscape
Subdeliverables
 Setup and configuration of an enhanced CTS using the change request management functionality of SAP Solution Manager
 An integrated change request and transport management approach using SAP Solution Manager
By completing this subdeliverable correctly, the project gains an integrated approach to controlling and handling change requests and transports
within the implementation project and in a productive system landscape by:
 Documenting and monitoring all relevant change requests
 Reducing the number of uncontrolled transports
 Documenting all transports
When dealing with change request management for the implementation project, it is recommended that you define and prepare for operational
change management procedures. Further guidance on this topic is provided in Run >> Change Management >> Change Request
Management/Change Control Management (see also linked nodes).
1.1.5.9 Test Management Standards
Purpose
Quality assurance and testing are an integral part of the project and application lifecycle. Within an implementation project, testing follows a
structured approach consisting of functional and non- functional test stages.
Functional tests ensure the functional correctness of test objects (Question: Does the system act as expected and according to requirements?)
and are typically conducted in multiple stages for every deliverable within the project lifecycle (e.g. unit test, scenario test, end-to-end integration
test).
Non-functional tests deal with a system’s run time behavior, e.g. with defined performance parameters.
After the successful go-live, testing still remains a central element of the application lifecycle: SAP solutions are changed on a regular basis
through SAP enhancement packages, support packages, SAP notes or customer-triggered change events, which require customers to test their
business processes thoroughly. Each change has to be tested to ensure that there are no negative side effects.
This subdeliverable describes the SAP standards for test management, which provides SAP’s best-practice approach for end-to-end test
management. During project preparation, the high-level test strategy for the project should be defined. If possible, the currently employed test
management approach should be assessed and adapted for the project.

Inputs
The inputs to test management standards are:
 Operational guideline: test management
 Test Theory
 Best practices and recommendations for test management for solution operations
 Current test strategy / test management approach
Subdeliverables
This step generates a customer-agreed high level test strategy and test management standards.
See linked nodes for a guideline to assess the current test approach and for further details on setting up the test strategy.
1.1.5.10 Postimplementation Service and Support Standards
Purpose
Companies may recognize that their current IT support organization is not adequate to support an SAP platform. They first need to calibrate their
overall operational maturity and then develop and execute a plan for a support model at the lowest total cost of ownership (TCO) for the customer
satisfaction level defined. For that, SAP offers guidance through support services and defined support standards. The purpose of this
subdeliverable is to start defining the services and standards for the time after the implementation project closes and operational activities become
the main tasks.
Implementation Standards
The SAP Active Global Support organization provides SAP Enterprise Support services that are a key enabler for integrated, standardized,
end-to-end solution operations. The key focus of SAP Enterprise Support is the holistic application lifecycle management of customers’ software
landscapes and applications. In addition, more customer-tailored support is offered through the SAP MaxAttention support option and SAP
Safeguarding services.
Support Standards
Companies expect high availability and continuity of their solutions, flexibility to quickly implement changes, and low TCO. Additionally, they need
to be able to manage out-tasking and outsourcing relationships across different time and geographical zones and to control and monitor service-
level agreements. To achieve this, IT governance is key. Companies need an IT strategy that focuses on the management of complexity, risks,
and costs as well as skills and resources. Standardized procedures that leverage the experience of the organization and the software supplier are
a key prerequisite for the optimization of application management.
Inputs
The inputs to postimplementation service and support standards are:
 SAP standards for solution operations
 Current IT support organization capabilities and maturity
 Business-user service levels and budgetary constraints
 SAP support services
Subdeliverables
Output for this step includes:
 Results of SAP operation planning assessment (for companies new to SAP)
 Results of operations maturity assessment (for SAP customers)
 Roadmap for conducting support operations design and implementation
1.1.5.11 Enterprise Service Design Standards
Purpose
A governance process for enterprise service design and development must be in place before the modeling, definition, and development of
enterprise services can begin. This enterprise services design governance process ensures that all enterprise services are defined according to
certain rules that ensure consistency, standards compliance, harmonization of business semantics, and reuse across all SAP solutions. Each
enterprise service is subject to a harmonized service cut, aligned naming conventions, consistent documentation, a shared service description,

and service orchestration. As a result, the enterprise services modeled represent a “common language for the business” with an optimal level of
granularity.
Subdeliverables
This step generates enterprise services design standards that include the definition of governance rules and a framework for developing
enterprise services (design time governance). Key aspects to be considered are:
 Service modeling and implementation guidelines
 Service development rules (for example, how to ensure item potential)
 Service documentation rules
 Service versioning and publication process
 Service change management (for example, when and how to update clients when the interface of a service changes)
To set up a framework, you need to define processes, roles, and responsibilities for the above topics. The processes should be supported by
appropriate tools, templates, and guidelines.
A key tool for supporting the governance of enterprise service modeling and implementation is the central Enterprise Services Repository.
SAP has developed an advanced metamodel and governance process for defining and modeling its ready-to-use enterprise services. The key
concept in this metamodel is the business object model. Each enterprise service is assigned to a business object that represents a well-defined
business entity or document. Each business object is, in turn, assigned to a process component. Process components are units of software that
cover a well-defined set of business tasks that logically belong together and are usually executed in the same department.
When the project scope includes SOA-based applications, it is recommended that you ensure in an early stage of the project that the customer
prepares for SOA readiness. Further guidance on this topic is provided in Run >> Governance Model for Organization – Optimization >> SOA
Readiness (see also linked nodes).
1.1.5.12 Composite Application Design and Development Standards
Purpose
The purpose of the composite application design and development standards is to set up the standards to be followed when designing,
developing, and deploying composite applications.
Subdeliverables
 Development process for the project
o Project development guidelines
o Naming conventions (for development components, packages, and so on): The naming conventions are aligned with the enterprise’s
naming guidelines for software development. This avoids naming conflicts and ensures clarity.
o Logging: This document describes what is to be logged, how it is to be logged (framework/tool to be used), and where the logging data
is to be stored.
o Exception architecture: This designates how the application will handle errors. Are the components that cause the error supposed to try
to solve the problem or is the error delegated to the caller? This architecture is closely correlated with the logging concept for
persistent data relating to problems that occur.
 Documentation: How is development to be documented? For example, are various document templates or metadata in the code to be
used?
 Infrastructure list:
o VC/Web Dynpro/CAF/Plain J2EE/GP/SAP Interactive Forms software by Adobe
o SAP NetWeaver Portal component or other central portal
o SAP NetWeaver or third-party development infrastructure
o SAP NetWeaver Business Process Management (SAP NetWeaver BPM) component
When the project scope includes SOA-based applications it is recommended that you ensure in an early stage of the project that the customer
prepare for SOA readiness. Further guidance on this topic is provided in Run >> Governance Model for Organization – Optimization >> SOA
Development Processes
Greenfield projects are not the norm. It is therefore important to consider guidelines that are already in place and project constraints that are
determined at enterprise level or by predecessor projects. This ensures consistency with existing projects and processes. Requirements such as
those determined by the Sarbanes-Oxley Act should also be considered.
Organizational Structures
After the toolset has been selected, the next step is to organize the development team and, if necessary, to identify and fill in the gaps on their
learning map for the composite development process. Ordering hardware, scheduling training, and building up skills can be a rather time-
consuming task (with project-external dependencies), which is why it is important to start early in the project.

1.1.6 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 customer’s acceptance of the project’s 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
1.1.6.1 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 project’s
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
1.1.6.2 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
SAP’s 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
customer’s 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.
1.1.6.3 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.
1.1.6.4 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.
1.2 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 Project Preparation 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:
 Statement of work (preparation phase)
 Review handoff – validation checklist (preparation phase)
 Development of the project office (optional)
Deliverables
The major deliverables generated from OCM in the Project Preparation phase (shown in orange) are:
 OCM Charter
 OCM roadmap / Plan
 Stakeholder Identification
 Project Team Building & Recognition
Key Activities to Support Deliverables
There are several key activities that are conducted in the Project Preparation 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
 Initial Assessment
 OCM Strategy
 OCM Team Selection
 OCM Team Training
 Stakeholder Management Workstream
 Stakeholder Analysis
 High Level Change Impact Analysis
 Communication Workstream
 Communication Needs Analysis
 Communication Channel Analysis
 Communication Strategy
 Project Kickoff
 Starting the development of the Communication Plan
 Performance Management Workstream
 Define Project Related Objectives
 Review & Align Goals and Incentives
 Project Team Internal & External Knowledge Transfer
 Monitoring Workstream
 Baseline Current State
 Project OCM Risk Assessment
Integration points for OCM are:
 Project management
 Risk management
 Resource management
More than half of the top issues in SAP implementation are related to people. The following diagram illustrates these issues:

The purpose and focus of Organizational Change Management is to systematically reduce or minimize the impact of change on the organization.
1.2.1 Organizational Change Management Charter
Purpose
The OCM charter outlines the change team’s mission for the SAP software implementation, including goals, objectives, and critical success
factors. This document sets the overall direction for the members of the change team as they plan and implement the change processes that
address the human resource and organizational aspects of the implementation. It is focused on minimizing project risk, accelerating project
benefits, and optimizing current and future processes and structures.
The OCM charter defines how the change team works within the project and the organization. Specifically, it:
 Defines the change team’s mission and rationale for the duration of the project
 Defines the key relationships with the business and the project
 Defines the mission, guiding principles, objectives and goals, and critical success factors for:
o Organizational optimization activities
o Communication activities
o Sponsorship and leadership activities
Inputs
The input required for the OCM charter is the general project charter.
Deliverables
The major deliverable generated from the OCM charter is the project charter updated with OCM inputs.
1.2.2 Stakeholder Identification
Purpose
The purpose of this activity is to ensure that the correct groupings of stakeholders have been identified for the project. The following questions
help identify an initial list of stakeholder groups:
• What are the user groups by process area or department?
• Which groups of people do the users interact with and so will need to know about changes?
• Who in the organization needs to commit resources and take ownership during the project?
• Who in the organization needs to provide specialist support in aligning the organization or its facilities?
• Who in the organization do the users report to? Who needs to approve or provide resources for realizing the new way of doing business,
such as training business users?
• Who are the key external customers, suppliers, and other third parties (for example, unions) and how are they affected?

During the stakeholder identification process all relevant stakeholders for the opportunity are identified. Process steps include:
1. Identification of stakeholders, which lists relevant stakeholders and groups, both internal and external, according to their relevance (such
as key players)
2. Classification of stakeholders, which classifies the stakeholders according to their position towards the program (pro or con) and their
area of influence
3. Relationships between stakeholders, which analyzes the relationships between stakeholders and their positions
Inputs
The inputs required for the stakeholder identification are:
 Stakeholder analysis
 Knowledge about stakeholders by interviewing project members who are adept with the customer situation and the customer organization
Deliverables
The major deliverables generated from stakeholder identification are:
 Complete stakeholder list
 Stakeholder register for every stakeholder group (to be filled out completely after stakeholder analysis
1.2.3 Organizational Change Management Roadmap
Purpose
The organizational change management (OCM) roadmap or plan presents an overview of all planned change management activities. It
guarantees that all activities are related to each other as well as to the overall project plan and ensures the “checkability” of OCM activities. It
includes the following activity types:
 Setup
 Stakeholder management
 Communication
 Organizational alignment
 Human resources performance management
 Skills and competencies (if not organized as an autonomous part of the project)
 OCM monitoring
A special part of the roadmap is the communication plan. It outlines the detailed approach and plan for
communication to all audiences within the project and customer organization. It describes the audience, timing,
responsibility, media, messaging, and status for all communication activities. This dynamic document helps
ensure that timely messages are provided to key audiences to move them along their adoption curve in
alignment with the OCM implementation schedule.
Inputs
The inputs required for the OCM roadmap are:
 Project charter, updated with OCM inputs
 Results of stakeholder analysis
Deliverables
The major deliverables generated from the OCM roadmap are:
 OCM roadmap
 Communication plan update
1.2.4 Project Team Building
Purpose
Team building activities include workshops or off-site meetings for the entire project team and other teams, aimed at reviewing project procedures,
goals, and activities and building or improving ways of working together towards a common goal. Team building also includes the celebration of
accomplishments. Celebration communicates a clear message to the team and the organization and its value should not be underestimated.
A good project kickoff has a teambuilding component. In the project input session, you have a chance to form
the team by using some of the exercises stored as accelerators.
Inputs
The inputs required for project team building are:
 Availability of team members
 Human resource management plan
 Project charter
Deliverables
 The major deliverable generated from team building is better working relationships among project team members.

1.3 Training
Purpose
The purpose of training in the project preparation phase is to ensure that the identified project team has the skills and knowledge required to
actively participate in the implementation from start to finish.
Inputs
Inputs for this work stream consist of a list of project team members to be trained, along with their roles and responsibilities within the project.
Budget, timing and preexisting knowledge may also factor in.
Deliverables
The major deliverable generated from this work stream is an executable project team training strategy that outlines three different levels of
training for the project team, as shown in the figure above. The strategy sets all members on a path to certification on the SAP applications they
are responsible for.
While the project preparation phase is generally a short one with regards to training, it is essential that the project team training strategy is
comprehensive.
1.3.1 Project Team Training Strategy
Purpose
The project team training strategy creates a comprehensive training strategy that provides all team members with a phase-based learning path
for acquiring the skills and knowledge needed to complete the project successfully. This learning path leads to project readiness as well as
certification on the specific applications the team members will be using.
Inputs
The inputs for the project team training strategy are:
 List of client project team members and individual responsibilities
 List of prerequisite knowledge brought to the project
 Location and other logistics for the client project team
Deliverables
The deliverable for the project team training strategy is a matrix of the project team members’ roles and responsibilities and the SAP course
curriculum. The strategy should also contain budgetary and logistical information about the attendance and delivery of the training.
If It Is Not Done
If project team training strategy is not completed, the project team members will not gain the knowledge they need to effectively participate in the
project and will not be in a position to benefit from the certification paths.
In most cases, it is sound IT and business practice for companies implementing SAP software to cultivate knowledge to reduce the total cost of
ownership and to support the system once it is live. Thus, a defined project team training strategy has a direct impact on the success of the
project.

1.3.2 Project Team Level 1 Skills Development
Purpose
Project team level 1 skills development provides an overview of the SAP software to be implemented so that all project team members have an
understanding of the SAP solution for their areas of responsibility. Level 1 training is the first in a series of three project team training sessions
designed to equip the project team with required skills and knowledge. Together, these three sessions should also ensure that the project team
members are certified on the SAP application.
Inputs
The input for the project team level 1 skills development is the project team training strategy.
Deliverables
The project team level 1 skills development generates a cross-reference of the project team members’ roles and responsibilities and the SAP
course curriculum. The cross-reference shows which courses each team member should attend. Level 1 training should focus on providing an
overview of the SAP solution.
If It Is Not Done
If project team level 1 skills development is not completed, the project team members will not receive adequate knowledge to effectively participate
in the critical realization phase of the project. This results in a higher total cost of ownership. In most cases, it is sound IT and business practice
for companies implementing SAP software to cultivate knowledge to reduce the total cost of ownership and to support the system once it is live.
Thus, level 1 training has a direct impact on the success of the project.
When possible, level 1 training courses should occur before the blueprint phase starts.
Registration for these courses should be filtered through one person 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.
1.4 Data Management
Purpose
The purpose of the data management work stream is to support two distinct data management activities for an SAP implementation: legacy data
migration and data archiving. Tasks and deliverables for data archiving begin during the blueprint phase but planning should be started in
theproject preparation phase. Legacy data migration is concerned with moving data from the legacy source systems into the SAP target
structures required for a successful go live. For legacy data migration, the project preparation phase is focused on the discovery, planning, and
customer education for the overall migration strategy and approach. Tasks are performed to capture a preliminary assessment of the source data
and to create planning documents to formally establish migration scope, requirements, approach, and strategy.
Inputs
The inputs required for the data management are:
 Relevant documentation from the opportunity management phase
Deliverables
The major deliverables generated from the data management work stream are:
 Data migration workshop
 Data audit
 Data migration scope and requirement
 Data migration approach and strategy
 The integration point for the data management work stream is project management. The information discovered and captured during
this phase provides preliminary input to the overall project planning effort.
1.4.1 Data Migration Workshop
Purpose
The purpose of the data migration workshop deliverable is to perform a two-day scoping workshop to explain the SAP data migration approach
and to understand the customer’s legacy data systems, business priorities, and technical infrastructure. This workshop is meant to be a two-way
knowledge exchange where data migration team members share their approach and project experiences and customer team members share their
business objectives, constraints, and concerns.
Inputs
The input to the data migration workshop is documentation from the sales cycle and opportunity management phase.
Deliverables
The data migration workshop deliverable generates the data migration workshop findings report, which outlines recommendations and next
steps for the project.

Expected Results
By completing the data migration workshop deliverable correctly, the data migration team gains an understanding of the customer’s objectives and
challenges in terms of migrating data. The team can then recommend an appropriate strategy to assess the quality of the legacy data. Customers
gain an understanding of the complexities and challenges of data migration and how to manage the associated risks.
1.4.2 Data Audit
Purpose
The purpose of the data audit is to identify the legacy systems that will supply data for the SAP applications and to profile the quality of the legacy
data. Data profiling is the process of analyzing the legacy source data to detect anomalies in the data and of validating the business rules. In the
data audit, the focus is on conducting a high-level summary analysis, looking for typical problems such as missing data and column names that
are inconsistent with content. The data audit involves working with the business users to help map out the gap between the existing and required
levels of data quality.
Inputs
The inputs to the data audit are:
 Findings document from the data migration workshop or any other documentation available from the sales cycle
 List of SAP software components or business objects in the data migration scope
Deliverables
The output from the data migration data audit includes:
 Legacy system identification, listing all the legacy systems from which the data will be converted into the new SAP solution
 Data profiling results for subject areas or business objects to be migrated – that is, customer, vendor, and materials
 Gap analysis, a high-level assessment of data gaps between the legacy systems and SAP solution
If It Is Not Done
This is a key deliverable needed to assess the scope and effort of data cleansing for the entire implementation project. Failure to properly and
thoroughly examine the data could result in work stoppage during the testing phase if the data migration programs have to be rewritten. It could
also lead to significant budget overruns as data migration activities tend to be costly.
By completing this deliverable, the data migration team is able to identify the project risks and define the scope and effort required for the
conversion to SAP. Further downstream in the project, the results of the data audit will allow the development of extraction, transformation, and
loading (ETL) jobs to correct any inconsistencies, redundancies, and inaccuracies in the data.
1.4.3 Data Migration Scope and Requirements Document
Purpose
The purpose of the data migration scope and requirements document is to capture the overall scope and requirements of the data migration
effort. Due to the complex nature of data migrations, many of the details are not fully discovered during the sales cycle. The creation of this
deliverable establishes the baseline for the project team to plan future activities and manage change throughout the blueprint phase.
Inputs
The inputs to the data migration scope and requirements document are:
 Data audit
Deliverables
The deliverable for the data migration scope and requirements document establishes the scope and requirements for the data migration effort. The
discovery performed during this step is not intended to identify all the detailed data requirements, but it sets the boundaries for the blueprint phase
where further analysis is performed. The document is intended to capture:
 Inventory of legacy applications (location, business objects and purpose, platform, and application solution)
 Inventory of business objects (volumes, merge requirements, and dependencies)
 SAP application footprint
 Migration methods (automated or manual)
 Connectivity to legacy systems
 Data retention requirements (open, historical, or inactive)
 Customer resources (locations, business owners, data owners, and data analysts)
 Language requirements
 Currency requirements
 Security requirements
 Established data governance standards and policies
 Cutover strategy (phased, big bang, or time constraints)
Expected Results
By completing the data migration scope and requirements document deliverable correctly, the project team captures the information needed to
effectively plan and manage future data migration tasks and activities. Change is common within data migration projects due to business decisions
and data quality discovery. This deliverable enables the project team to establish the foundation for managing change throughout the future
phases of the project.

1.4.4 Data Migration Approach and Strategy Document
Purpose
The purpose of the data migration approach and strategy document is to capture and communicate the approach and strategy for the legacy
data migration. This deliverable is intended to educate the SAP and customer project team members on the SAP data migration framework and
methodology used to support the data migration project.
Inputs
The inputs to the data migration approach and strategy document are:
 Data audit
Deliverables
The data migration approach and strategy document describes the SAP data migration framework and methodology used to support the data
migration project. The primary purpose of this deliverable is to educate the project team to ensure that everyone understands the tools and
methods being deployed to deliver the data migration solution. The document contains both static information that is common across projects and
customer- or project-specific information to describe how this framework applies to the customer’s environment.
The data migration approach and strategy document includes:
 The underlying technology platform and tools
 Data migration framework
 Data quality management and reporting
 Load methods
 Data migration methodology
 Resource roles and responsibilities
 Key risks and mitigation strategies
 Architectural diagram describing the customer’s environment
Expected Results
By completing the data migration approach and strategy document deliverable correctly, the project team gains a common understanding of the
tools and methods being deployed as well as an understanding of their roles and responsibilities within the project.
1.4.5 Test Data Management
Purpose
The purpose of the test data management deliverable is to support test data management activities for an SAP implementation. This is part of
thedata management with focus on the data to be created in development and quality assurance systems. The different characteristics and
requirements of the test data should be weighted, in order to choose the proper method and tool for data creation. Besides, one should also take
into consideration that certain data, particularly business-critical and personal data, should be kept protected, before it enters development and
quality assurance systems.
Inputs
The inputs required for the test data management are:
 Relevant documentation from the opportunity management phase
Deliverables
The primary purpose of this deliverable is to understand the different requirements of the test data and find a proper approach for test data
management. By choosing the method and tool for data creation, some other aspects such as data privacy should also be taken into
consideration.
The major deliverables generated from the test data management deliverable are:
 Requirements of test data
 Relevant data privacy for test data collection
 Methods and tools for test data generation

1.5 Business Process Management
Purpose
The purpose of the business process management (BPM) work stream in project preparation is to work with value determination, build a high-level
to-be business process map, and deliver the business scenario design. Work is structured according to the following deliverables:
 Value determination
 Business process map
 Business scenario design
The folowing figure illustrates the BPM-focus areas by implementation phase:
 Project preparation focuses on the determination of value drivers and the process and solution design on process level (PL) 1-2, which corresponds
to the scenario level in the SAP Solution Manager application management solution.
 Blueprint focuses on the refinement and associationof value drivers to the process hierarchies and the solution design on process level
3-5, which corresponds to process and process step level in SAP Solution Manager.
 During realization the solution design is finalized and built. Configuration rationales and technical specification capture the final design. It
is recommended that you start value audits to monitor whether the project is on track to realize the expected benefits.
Inputs
The inputs required for business process management during project preparation are
 Project scope as specified in the statement of wrk
 Catalog of as-is business process documents, as appropriate
 Value assessment results (including pain point analysis, value map, and identification of key process changes)
Deliverables
Business process management during project preparation focuses primarily on business scenario level/process hierarchies level 1-2. The major
deliverables are:
 Value determination, pain points, process weaknesses (process flow, organizational structure, system support, and data structure),
baseline as-is process performance indicators (PPIs), and improvement areas and financial key performance indicators (KPIs) by
scenario
 Refined business process map, an overview of the busiess process to be implemented (refer to the business process map section on
the Business Process Expert (BPX) community Wiki page, ¡§SAP Modeling Standards¡¨)
 Business scenario description (business scenario requirements documents) ¡V optionally this deliverable can be produced during
blueprinting
 Scenario-level requirements
 Scenario models a value-added chain diagrams (refer to the Guideline for Business Process Modeling section on the Business Process Expert
(BPX) community Wiki page, ¡§SAP Modeling Standards¡¨)
 High-level function and solution considerations
 High-level organizational impact
 Setup of SAP Solution Manager for the implementation project and start of the SAP Solutin Manager document repository
(SOLAR01), as the system is available
Integration
The integration points for business process management are:
 Predecessor: value proposition, collaborative value realization (CVR) deliverables, as applicable
 Predecessor: BPM deiverables, as applicable
 Successor: business process management in blueprinting
For SAP Solution Manager usage, refer to the operational guidelines on project preparation.
Optionally, a customer might chose to execute CVR or BPM initiatives before the implementation project. Deliverables from CVR and BPM will
then either be an input for business process management or they will replace ASAP methodology BPM deliverables.
For modeling notations, refer to the BPX Wiki page: ¡§SAP Modeling Standards:¡¨
 Overview for process level mapping
 Business process maps
 Business scenario level models and value-added chain diagrams
If the project scope includes SOA-based applications it is recommended that you ensure in an early stage of the project that the customer
prepares for SOA readiness. Further guidance on this topic is provided in Run >> Governance Model for Organization ¡V Optimization >> SOA

1.5.1 Value Determination
Purpose
Value-based solution design is centered on the alignment and tracking of the business case value drivers with key process changes and
functionality.
Value determination or value mapping should be executed during the project preparation phase, or at the latest it can be performed at the
beginning of the blueprint phase. The business case is the starting point for value determination, the pain-point analysis and identification of value
drivers serve as inputs to the determination and documentation of key process changes.
The value map associates the business drivers with key process changes and their process performance indicators (PPIs), PPIs serve to
measure the successful implementation of process changes. The results from value determination should be then fully embedded in the blueprint
process and solution design. Value maps ensure the alignment of business value drivers with the process changes and its tracking mechanisms.
The following figure illustrates the value management activities across the ASAP methodology, the activities executed during the project
preparation phase are highlighted in orange.
The following figure illustrates the process of value-based blueprinting with value deliverables (orange) and process management/technical
solution design deliverables (blue).
Inputs
The inputs for value determination or value mapping are:
 Statement of work – scope determination
 Business case
 Value roadmap
 High-level solution design
 As-is analysis, if available
Deliverables
The deliverables from value determination are:
 Value maps
 Key process changes
 Financial KPIs with ownership, accountability, baseline and target
 Process performance indicators (PPIs) with ownership, accountability, baseline and target
 Value enablers (policy changes, compensation plans, data quality plans, etc)
 Clear link from business value drivers to process changes to measurable KPIs and PPIs

Expected Results
Value determination enhances the ability of the project team to:
 Manage expectations and focus on key deliverables
 Manage scope
 Track progress of key process changes
 Demonstrate value achievement
Value determination is part of the value management work stream during project preparation and it serves as basis for value based blueprint
and subsequent phases.
For further information, refer to:
 Business Transformation Services group service: collaborative value realization or value mapping
1.5.2 Business Process Map
Purpose
The purpose of the business process map is to derive and agree on the scope for the start of the business blueprint phase. During
blueprinting, the process map builds the foundation for the process hierarchy ¡V a decomposition of the process design ¡V which is reflected as
scenarios, processes, and process steps in SAP Solution Manager.
Inputs
The inputs for the process map are:
 Process scope, as defined in the statement of work
 Solution Composer tool, SAP Solution Manager, SAP Best Practces packages (SAP¡¦s process content)
 Customer reference content
 Interviews with business-responsible customer employees
Deliverables
The deliverables for the process landscape are:
 A process map based on the defined high-level process scope
 High-level process landscape (process level 1-2)
Expected Results
The process map serves as a framework for process modeling and therefore helps to manage process scope. It also serves as an important point
of reference for further process modeling and deep-dive sessions.
For business process modeling, refer to the SAP Process Modeling Handbook on the BPX community Wiki site. As an additional reference, SAP
offers the business process repository.
1.5.3 ?Business Scenario Design
Purpose
The purpose of business scenario design is to provide an understanding of the essential processes at the scenario level (process level 1-2). It
builds the foundation for the business blueprint phase where process levels 3-5 are defined.
Inputs
The inputs for the business scenario design include:
 Project scope (statement of work)
Catalog of as-is business process documentation, as appropriate
< style='margin-top:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:36.0pt; margin-bottom:.0001pt;text-
indent:-18.0pt;mso-list:l0 level1 lfo2'>Value realization deliverables (including pain-point analysis, value map, and identification of key
process changes)
 Solution map,? from Solution Composer for example, as available
Business process repository for SAP Solution Manager
 Ready-to-run end-to-end process content
Deliverables
The deliverables for the business scenario design are:
 Business scenario design document, which includes:
o Business requirements
o Level 2 process design (value-added chain diagrams)
o Level 2 solution gap analysis
o Level 2 functional solution design
o Value drivers and financial KPIs
o Level 2 organizational impact analysis
o Level 2 data impact analysis
o Level 2 system impact analysis
 Revised project scope (if applicable)
 Setup of SAP Solution Manager for the implementation project and start of the document repository (SOLAR01), as the system is
available

Expected Results
For business process modeling, refer to the SAP Process Modeling Handbook on the BPX community Wiki site. See the BPX community site for
details on SAP¡¦s business process repository as well.
1.6 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 Project Preparation phase of the ASAP Implementation Roadmap, the overall objective of Technical Solution Management is
to prepare for the Business Blueprint phase by completing key technical deliverables that will serve as reference points for the other work streams
of the project.
Inputs
No prior project deliverables are assumed to exist at the beginning of this phase. However, documents generated during the process of evaluating
and selecting SAP as the software solution, or during the project scope definition and approval process, can be valuable inputs for Technical
Solution Management in this phase. Examples of such documents are:
 Overall project charters and statements of project scope for the SAP implementation
 Business case studies or value propositions that were developed during the evaluation and selection of SAP as the software solution
Other useful documents from the existing IT architecture repository that may be relevant include:
 The customer’s existing overall software solution architecture, including detailed specifications of the solution(s) that will be replaced as
part of the SAP implementation
 Lists of approved or preferred technology vendors
 Technical support tools, standards, policies, and organization
 Project governance and release strategies
Deliverables
The major deliverables of Technical Solution Management in the Project Preparation phase are:
 Preliminary inventory of external systems that may be required to interface with the SAP solution.
 Preliminary definition of the target solution landscape and the overall system landscape strategy for supporting the implementation.
 Formulation of a preliminary hardware sizing model for the production environment.
 Definition of tools and standards for providing technical support to the project itself.
1.6.1 Interface Inventory
Purpose
The purpose of the interface inventory deliverable is to preliminarily identify the external systems, applications, and business objects or
transactions that must be integrated with the SAP solution to realize the objectives of the project.
Inputs
The inputs to the interface inventory are:
 Overall project charters and statements of project scope for the SAP implementation.
 Business case studies or value propositions that were developed during the evaluation and selection of SAP as the software solution.
 The customer’s existing overall software solution architecture, including detailed specifications of the solution(s) that will be replaced as
part of the SAP implementation.
 Documentation of the existing or planned Enterprise Application Integration (EAI) Architecture, or of integration technologies or methods
that are currently in use.
Deliverables
The interface inventory deliverable serves as a preliminary statement of the integration scope and requirements for the project. The goal of this
deliverable is to identify and capture the integration landscape to identify the external systems and transactions to be integrated with the SAP
application after go live. It is expected that this document will be updated as the solution is more fully defined in the Business Blueprint phase.
The document should capture the following information:
 Inventory of legacy applications (location, business objects and purpose, platform, and application solution)
 Business objects and transactions (type, volume, and frequency)
 Communication requirements (batch or real-time)
 Direction (inbound, outbound, or bidirectional)
 Connectivity to legacy systems
 Customer resources (locations, business owners, data owners, and data analysts)
 Language requirements
 Currency requirements
 Security requirements
 Established communication and data governance standards and policies
Expected Results
By completing the interface inventory deliverable correctly, the project team captures the information needed to effectively plan and manage future
integration tasks and activities.

1.6.2 Technical Requirements and Design and Solution Landscape
Deployment Plan
Purpose
The purpose of the technical requirements and design deliverable is to provide the project with a specification of the target solution from a
software component standpoint. This document is intended to serve as a reference for the rest of the project team during the Business Blueprint
phase.
Included in this deliverable is the solution landscape deployment plan, which is a high level description of the overall system landscape
approach to be used for the implementation project. This plan should identify the various non-production systems that will be used throughout the
course of the project, and the roles of each.
Inputs
The inputs for the technical requirements and design and solution landscape deployment plan are:
 SAP Scenario & Process Component List (SCL). The SCL is an online tool in the SAP Service Marketplace that maps business scenarios
(sets of related business processes) to the specific SAP software components that are required to realize them.
 SAP Master Guides. Master Guides are planning documents that provide a comprehensive view of the business scenarios of a specific
SAP solution & version, and the realization alternatives for each. Master Guides are available for download in the Installation and
Upgrade Documentation repository in the SAP Service Marketplace.
Deliverable
The deliverable for the technical requirements and design and solution landscape deployment plan is the Technical Requirements
Specification document. This document describes the software components of the target solution and the overall system landscape plan.
Expected results
By completing this deliverable correctly, all members of the project will gain visibility into the basic technical assumptions on which the project is
based. Making this information available to the project team will help correct misunderstandings that potentially affect Business Blueprint
decisions, for example as to whether certain functionality can be implemented given the software components in the landscape.
It is important to keep in mind that this deliverable is primarily intended to be a high-level reference for the project in support of Business Blueprint
activities. While it is possible to describe the software components of an SAP system at a very detailed level (for example, by listing the contents
of table CVERS in an ABAP-based SAP system), such detail is not warranted or even known in this phase of a project. Third-party applications
that are expected to be part of the target solution should also be included in the Technical Requirements Specification if they may have an effect
on business process designs.
1.6.3 Initial Hardware Sizing Proposal
Purpose
The purpose of the initial hardware sizing proposal is to begin the process of assessing your hardware infrastructure requirements.
Sizing is the process of determining the hardware requirements of an SAP system, including CPU processing capability, physical memory, disk
storage, and network bandwidth. The size of the hardware and database are influenced by technology factors and also by how the systems are
configured and used from a business process standpoint.
SAP has developed a comprehensive sizing process that involves the collaboration of three parties: SAP, the customer, and the customer’s
selected hardware partner. SAP provides a sizing utility called the Quick Sizer that assists in translating customer-specific business requirements
to a platform-independent unit of measurement of processing power called SAPS. Hardware vendors conduct SAP-certified benchmark tests on
their product offerings to produce a SAPS rating of a given server configuration. Once a customer has used the Quick Sizer to generate an
estimate of their SAPS requirement, the hardware partner can then propose a suitable hardware environment using the benchmark tests as a
guideline. The whitepaper Sizing Guide – Theory and Practice of Sizing SAP Software offers a detailed description of SAP’s approach to system
sizing.
The Quick Sizer offers two basic methods of sizing an SAP system:
 User-based sizing, which is simply factors the number of low-, medium-, and high-volume users of a given application. This method can
be conducted quickly, but yields less accurate results.
 Throughput-based sizing, which is based on modeling the transactional throughput of a given system. This method can produce much
more accurate results, but is significantly more time-consuming to perform and requires a solid understanding of how the target solution
will be configured.
It is important that sizing is viewed as an iterative process, where the sizing estimate and the assumptions contained within it are regularly
revisited and confirmed throughout the project. It is basically impossible to conduct an accurate production sizing during the Project Preparation
phase of a project, as many decisions that affect sizing will have not yet been made.
Inputs
The inputs for the initial hardware sizing proposal are:
 Preliminary estimates of the total number of end users.
 Technical Requirements Specification document
Deliverable
The deliverables for the initial hardware sizing proposal is:
 Completed sizing estimates for the Solution Manager system and non-Production environments such as Sandbox and Development that
will be delivered in the Business Blueprint phase.
 Completed sizing estimate for the Solution Manager system and other essential project support systems.
 An initial version of the Technology Infrastructure Capacity Plan.
Expected results
By completing this deliverable correctly, the project will be able to begin the procurement process for the necessary systems to support the project,
and will also begin an ongoing process of modelling the eventual requirements of the production environment.

1.6.4 Project Support Tools and System Setup
Purpose
The purpose of the project support tools and system setup deliverable is to establish the basic tools and processes necessary to support the
project.
One of the most vital project tools is the SAP Solution Manager, the centerpiece of SAP’s Application Lifecycle Management tools. The SAP
Solution Manager provides a central point of access for a variety of essential project support functions, including:
 Solution Implementation – the identification, adaptation, and implementation of new and enhanced business scenarios.
 Solution Documentation – centralized documentation repository ensuring the relationship of business process definitions with technical
configuration decisions.
 Change Control Management – synchronized deployment of application configuration with integrated project control and quality
management.
In addition, customer-specific project management and documentation tools may require installation and distribution to project team members.
Finally, access to the online SAP Support Portal should be established for all project team members. This will allow team members to utilize the
up-to-date content available at this site, such as SAP product information, software downloads, and SAP notes. To register for a user ID, it is
necessary to provide an SAP customer number and an e-mail address at a domain associated with that customer. It is also possible to designate
a super-administrator on the project to create IDs in the SAP Support Portal for all project team members.
Inputs
The inputs for the project support tools and system setup are:
 Project management and documentation standards
Deliverable
The deliverables for the project support tools and system setup are:
 SAP Solution Manager system installed
 Customer specific project management and documentation tools installed and set up
 SAP Support Portal user IDs established for key project team members
Expected results
By completing this deliverable, the project team will be provided with the necessary resources to begin the Business Blueprint phase.
1.7 Integrated Solution Management
The purpose of the integrated solution management work stream is to outline essential solution testing deliverables, processes, and procedures
appropriate to an SAP implementation project. This work stream organizes testing of individual processes, process steps, and scenarios to
prepare for the move to a productive SAP solution.
Inputs
The inputs to integrated solution management are:
 Project scope
 Business requirements
 Functional requirements
Deliverables
 This work stream generates the testing assessment.

1.7.1 Testing Assessment
Purpose
The purpose of the testing assessment deliverable is to assess the customer’s existing testing process, methodology, and tool sets and to initial
the project plans. This deliverable provides insight into the customer’s as-is skill at conducting tests of enterprise systems. As the test strategy
and approach is completed during the business blueprint phase, the test assessment will highlight the work needed to bring the customer’s
testing skills up to the level needed to successfully test the SAP solution.
Inputs
The inputs for the testing assessment are:
 Existing test management artifacts and processes, including:
o Methods of testing, both manual and automated
o Testing tool set
o Requirements traceability tool set
o Test data management functionality
o Test execution
o Test resources
o Defect management
o Test coordination
o Test reporting and analysis
o Test metrics
 Change control process
Deliverables
The deliverables for the testing assessment report include:
 Summary
 Findings and recommendations
 Recommendation for an implementation timeline
 Future roadmap in various phases
 Reference slides to support recommendations
Expected Results
By implementing the recommendations from the testing assessment, the project team will:
 Eliminate testing issues and challenges
 Accomplish successful testing
 Successfully complete the project
o On time
o Within scope
o Within budget
 Establish a testing center of excellence

Asap methodology 1st phase- project preparation

More Related Content

What's hot (20)

Similar to Asap methodology 1st phase- project preparation (20)

Recently uploaded (20)

Asap methodology 1st phase- project preparation