Project Preparation - ASAP

ASAP Methodology for Implementation
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.
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 handoff of information
gathered in the preimplementation 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
Completing the handoff of information gathered in preimplementation project activities (only
applicable to the project preparation phase start-up)
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
Handoff of the checklist from preproject activities (only applicable to the project preparation
phase)
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
Sub deliverables
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 schedule detail the resource requirements, but in the start of each phase
you need to ensure the proper timing of resource assignments needed to complete project work.
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.
Sub deliverables
The sub deliverables are:

The project team organizational chart with assigned people
Resources assigned to roles and responsibilities
1.1.1.5 Setup of Project Logistics and Infrastructure
Purpose
The setup of project logistics and infrastructure activity ensures that the physical project environment
is in place before you begin the project. It provides suitable physical (work), technical, and administrative
environments including IT access, telephones, voice mail configuration, and physical security. It clearly
defines the procedures for conducting project administration operations. At project start, you must
complete the project logistics and environment checklist.
In addition, in the case of a virtual project team, best practices for working remotely should be reviewed
and included in the project logistics and infrastructure.
Inputs
The inputs to this activity are:
Resource assignments to roles and responsibilities

SAP best practices for virtual teams
Sub deliverables
This activity generates a defined project logistics and infrastructure
1.1.1.6 Team On boarding
Purpose
The purpose of this activity is to prepare the on boarding 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.

Sub deliverables
The sub deliverables from this activity are:
Handover project guidelines (company overview, consultants guidelines, project timeline, and
project scope, for example)
On boarding package
1.1.1.7 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.
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:
Handover information from OMP

Value-based solution scope
High-level technical architecture
Delivery model drafted according to ISD guidelines
Implementation project phases and deliverables
SAP solution map and/or SAP business scenario map (output from Solution Composer)
Business case and/or CVA (optional)
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
Deliverables
The deliverables generated from this activity are:
Project charter
Scope statement
Business case (optional)
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.
Inputs
In creating the business case, consider the following inputs:
Section Key Content Inputs
Objective What business need the project is Customer business case

solving SAP business case, value assessment, or
business assessment
Problem and “As-is” situation
Opportunity SAP collaborative value assessment
Proposed “To-be” situation Statement of work (SOW)

Resolution Proposal
Strategic Alignment Customer business strategy and Customer business case
technical strategy SAP business case, value assessment, or
business assessment
SAP collaborative value assessment
Benefits Tangible and intangible benefits Customer business case

SAP business case, value assessment, or
business assessment
SAP value map from the SAP Value Delivery
Management portfolio of services
Investment Cash inflows Customer business case

SAP business case, value assessment, or
Appraisal Cash outflows business assessment
Discount rate SAP collaborative value assessment
Dependencies Geographic and organizational Customer business case

scope – people, associated SAP business case, value assessment, or
locations, languages, and business assessment
organizations affected or impacted SAP collaborative value assessment
by the proposed solution SAP value map
SOW
Proposal
Affected Systems System scope – systems and Customer business case
associated locations affected or SAP business case, value assessment, or
impacted by proposed solution business assessment
SOW
Proposal
Stakeholders Starting with C-Level management Company fact sheet
SAP value map
Sub deliverables
This activity generates a reviewed and approved project business case that is documented and
communicated to the project team.
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.
For further information, refer to:

Business Transformation Consulting group services: business case, value assessment, or business
assessment service; collaborative value realization service
SAP value engineering services: collaborative value assessment service
PMBOK® Fourth Edition, Chapter 4, Project Integration Management
Adapted from PMBOK® Fourth Edition, Chapter 4, Project Integration Management © 2004 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 Project business case
Proposed resolution, “to-be” situation, and high- Statement of work (SOW)
level summary of what the project will deliver
from an organizational, functional, technical, and
geographic point of view
Project Scope Characteristics of the solution or service that the SOW
project was undertaken to create; note out-of- Proposal
scope organizational, functional, process, and
development objects (such as data cleansing),
and technical applications
Overall project goal
Project Objectives SMART (specific, measurable, attainable, relevant, SOW
and time-bound) aims of the project derived from Proposal
requirements, benefits, project needs, and measures
of success aligned to corporate and organizational
strategies and the project goal
Deliverables Produced by the team to ensure project success SOW

Proposal
Project business case
Business Case Summary of justification for project, return on Project business case
Summary investment (ROI) and related key performance
indicators (KPIs)
Total Estimated Estimated total project costs through closing SOW
Project Costs Proposal
Implementation The approach selected for the project based on the Proposal
Strategy analysis of solution options during the evaluation Prestudy
phase
Project Planning A summary level schedule (chart or graph) with high- SOW
level dates that identifies the major ASAP Proposal
methodology milestones related to phases and value
delivery
Project Persons or organizations actively involved in the Project business case
Stakeholders project or whose interests may be positively or SAP value map from the
negatively affected by execution or completion of the SAP Value Delivery
project Management portfolio of
services
Assumptions Factors that are considered to be true, real, or SOW
certain without proof of demonstration and project Proposal
limits
SAP value map
Constraints Factors that limit options and are beyond the control SOW
of the project team, resulting in a state, quality, or Proposal
sense of being restricted to a given course of action
or inaction Project business case
SAP value map
Risk Assessment Factors that may have a negative impact on the Proposal
project SAP risk assessment
Approval Approval from the program sponsor – the key Signatory authorization
individual, person, or group that provides financial
resources to the project
Sub deliverables
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.
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 Project business case
goal to be achieved by the project Project charter
Solution or Service Detailed summary of organizational, Statement of work (SOW)
Description functional, development, technical,
geographic, and language scope
Project Requirements Documentation of the capabilities or SOW
conditions that must be met by the project Proposal
Project Objectives Customer strategies (corporate and Project business case
organizational) aligned with project goals Proposal
Deliverables Key deliverables produced by the team to SOW
ensure success WBS
Project Boundaries List of specific systems (SAP and SOW
customer applications) within the project
scope
Out of Scope Notation of out-of-scope organizational, SOW
functional, process, and development Proposal
objects (such as data cleansing for
conversions), and technical applications
Project Assumptions Items or factors that are considered to be SOW
true, real, or certain without proof of Proposal
demonstration and project limits
Project Constraints Factors that limit options and that are SOW
beyond the control of the project team, Proposal
resulting in the state, quality, or sense of
being restricted to a given course of action
or inaction
Project Risk Risks that may have a negative or positive SOW
Assessment impact on the project Risk register
Implementation Description of the ASAP methodology and SOW
Strategy approach for implementation ASAP methodology
description
Initial Work Breakdown Decomposition of deliverables WBS
Structure (WBS)
Project Organization Project organizational chart of individuals Human resource
and organizations that have specific roles management plan
in the project team
Acceptance Criteria Scope verification process Scope management plan
Schedule Milestones Key project milestones and dates SOW
Order of Magnitude Estimated total project costs through SOW
Project Costs closing
Configuration The approach for documenting product Integrated change control
Management characteristics and integrated change plan
Requirements control
Project Costs Needed Estimated project costs required to move Project cost and effort
to Proceed to the next phase estimate
Approval Approval from customer project sponsor, Signatory authorization

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
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 the business 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
Sub deliverables
This step generates the detailed project schedule.
1.1.3 Project Management Plan Definition
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 the knowledge areas provide the foundation to
support the consistent application of project management practice.
Inputs
This deliverable includes the following inputs:
Project charter
Handoff checklist from preproject activities (optional)
Deliverables
This deliverable generates the following outputs:
Project management plan and subsidiary plans

Project schedule
Project budget
For further information, refer to PMBOK® Fourth Edition, © 2008 Project Management Institute
1.1.3.1 Integrated Change Control Procedure
Purpose
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 key objectives of integrated change control are to:
Identify changes in scope – or other unplanned activity – in advance and control them
Protect the integrity of deliverables that have been approved (signed off)
Ensure that new tasks and other requested changes are justified and cost justifiable, and that
affected deliverables are identified and modified accordingly (rebaselined)
Obtain authorization to proceed with the new tasks or changes and assign them to appropriate
individuals to be completed
Monitor the progress, cost, and value of approved changes
Integrated change control includes these components:
Defining an integrated change control procedure

Finalizing the project change request form
Finalizing the project change control log
The integrated change control procedure outlines the process for requesting, evaluating, deciding on,
and tracking possible changes to the project scope and all related activities and deliverables. The
procedure elaborates on sections from the project management plan that pertain to integration and
management change control. An effective change control system maintains control while allowing
flexibility.
The change request form and change request log enable the execution of the change control
procedure and must support the multiple levels of analysis and approval required to deal with a requested
change.
To produce the integrated change control procedure, use the integrated change control templates to
define an appropriate control system for the project. Consult with the customer project manager when
creating the procedure.
Inputs
The inputs to the integrated change control procedure are:
Integrated change control procedure template
Project management plan
Customer change control policies, procedures, and guidelines
Sub deliverables
This step generates a reviewed and approved integrated change control procedure that is documented
and communicated to the project team.
When dealing with integration change control and change request management for the implementation
project, it is recommended that you define and prepare for operational change management procedures
in parallel. Further guidance on this topic is provided in Run >> Change Management >> Change
Request Management/Change Control Management (see also linked nodes).
1.1.3.2 Issue Management Procedure
Purpose
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. Left unresolved, an issue will impede or prohibit project-related progress
or development by delaying or suspending a task or project.
The key objectives of issue management are to identify, track, and resolve issues related to project
activities and deliverables in a timely fashion.
Inputs
The inputs to the issue management procedure are:
Issue log template
Scope management plan
Integrated change control procedure
Customer issue management policies, procedures, and guidelines
Sub deliverables
This step generates a customer-reviewed and approved issue management procedure that is
documented and communicated to the project team.
1.1.3.3 Scope Management Plan
Purpose
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.
Inputs
The inputs to the scope management plan are:
Scope management plan template
Project charter
Customer scope management policies, procedures, and guidelines
Sub deliverables
This step generates a reviewed and approved scope management plan that is documented and
1.1.3.4. Time Management Plan
Purpose
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.
Inputs
The inputs to the time management plan are:
Time management plan template

Project charter
Project scope statement
WBS template (in the opportunity management phase)
Customer policies, procedures, and guidelines
Sub deliverables
This step generates a reviewed and approved time management plan that is documented and
1.1.3.5 Cost Management Plan
Purpose
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.
Inputs
The inputs to the cost management plan are:
Project charter
Cost management plan template
Sub deliverables
This step generates a reviewed and approved cost management plan that is documented and
1.1.3.6 Quality Management Plan
Purpose
The quality management plan outlines the specific organization, processes, and materials needed to
ensure quality on the project. It elaborates on sections of the project management plan that pertain to
quality management.
Inputs
The inputs to the quality management plan are:
Project charter
Quality management plan template
Scope management plan
Issue management plan
Customer quality policies, procedures, and guidelines
Sub deliverables
This step generates a reviewed and approved quality management plan that is documented and
1.1.3.7 Human Resource Management Plan
Purpose
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.
Inputs
The inputs to the human resource management plan are:
Human resource management plan template

Project charter
Assigned roles and responsibilities
Sub deliverables
This step generates a reviewed and approved human resource management plan that is documented and
1.1.3.8 Communication Management Plan
Purpose
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 project communication matrix outlines the project team’s approach to project-specific
communication. It captures the analysis completed as part of communication planning and serves as a
tool to guide the project team throughout the project.
Project performance report templates are produced for different purposes and target audience, as
defined in the project communication plan. Typically, project performance reports include:
Team member status reports

Project team status reports
Project status reports
Executive status reports
Project performance reports collect actual project progress and performance information and report it
against baseline information to the various project stakeholders. The reports capture the analysis of
completed project work in achieving project objectives. At a minimum, project performance reports should
provide information on scope, schedule, cost, resources, quality, and risk.
Inputs
The inputs to the communication management plan are:
Communication management plan template

Communication matrix template
Project charter
Stakeholder analysis
Customer communication management policies, procedures, and guidelines
Sub deliverables
This step generates a reviewed and approved communication management plan that is documented and
communicated to the project team. It consists of:
Communication plan
Decision making plan
Result protocol
1.1.3.9 Risk Management Plan
Purpose
The purpose of the risk management plan is to define how the risk process is structured and performed
throughout the ASAP methodology delivery phases. The risk management plan defines how risks are
discovered, defined, assessed (during risk reviews), and managed. It also describes how often risk
reviews are conducted.
To handle risks in a simple way within any customer project, you can use the project risk list.
Inputs
The inputs to the risk management plan are:
Global risk policy

Project characteristics (size, solution, markets, contract type) used in conjunction with the global
GRC risk policy to define how the risk plan will function
Project charter
Sub deliverables
This step generates:
Project risk management plan

Risk register
The expected output of the risk assessment is a comprehensive explanation (in a document) of how risk
discovery, definition, assessment, and management will take place throughout the project lifecycle.
1.1.3.10 Project Contract Inventory
Purpose
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
The inputs to the project contract inventory are:
Project charter
Change control procedure
Customer procurement management policies, procedures, and guidelines
Sub deliverables
This step generates inventoried project contracts stored within the project repository.
If It Is Not Done
Skipping this step limits visibility and control in managing the contractual factors that can adversely
impact the scope, schedule, budget, quality, and value of the project.
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.
Project schedule
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)
For further information, refer to PMBOK® Fourth Edition, Chapter 4, Project Integration Management.
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 the project 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
Sub deliverables
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
Sub deliverables
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.
Sub deliverables
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.
Sub deliverables
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)
Sub deliverables
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.
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
WBS template (from the opportunity management phase)
Sub deliverables
This step generates a refined time management plan with a blueprint workshop schedule.
For further information, refer to PMBOK® Fourth Edition, Chapter 6, Project Time Management.
Adapted from PMBOK® Fourth Edition, Chapter 6, Project Time Management © 2004 Project
1.1.4.7 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

Sub deliverables
This step generates a reviewed and updated communication matrix
1.1.4.8 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
Sub deliverables
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 on boarding
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
Post implementation service and support standards
Enterprise service standards
Composite application design and development standards
Sub deliverables
This step generates documented, approved, and communicated project standards in accordance with the
integration management plan.
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
Sub deliverables
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 sub deliverable 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 standard modeling 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
Sub deliverables
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 sub deliverable 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 sub deliverable 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.
Sub deliverables
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.
Sub deliverables

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 sub deliverable 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
Sub deliverables
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 standards provide a holistic view of custom development from the
operations perspective, not from the development itself. The topics and methodology described in this
sub deliverable 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.
Sub deliverables
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 sub deliverable 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 sub deliverable are the SAP support package and upgrade standards.
Sub deliverables
This step generates upgrade and support package standards for the project.
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
sub deliverable 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
Sub deliverables
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 sub deliverable 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 systems 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 sub deliverable 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

Best practices and recommendations for test management for solution operations
Current test strategy / test management approach
Sub deliverables
This step generates customer-agreed 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 Post implementation 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 sub deliverable 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 post implementation 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
Sub deliverables
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.
Sub deliverables
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.
Sub deliverables
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 Readiness (see also
linked nodes).
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:
Verify that deliverables from this phase are complete and accurate, and review any critical
outstanding issues
Identify lessons learned during the phase to incorporate into the next phase or to prepare for
formal project closure
When sign-off is obtained, the project can proceed to the next phase.
Inputs
This deliverable has the following inputs:
Project schedule for the phase
Phase-specific deliverables
This deliverable is triggered by the completion of the phase.
Deliverables
This deliverable generates:
Lessons-learned log
Project quality gate scorecard
Project review service reports
Phase closure document
1.1.6.1 Lessons-Learned Log Updates
Purpose
It is good project management practice to collect knowledge and lessons learned from the implementation
project for use in later stages of the project or in future projects. The project team collects and documents
the lessons learned in the lessons-learned log that is made available to the project team and shared
with other projects in the organization.
For projects that include global delivery, consider the following activities at the phase sign-off stage:
Review lessons learned while engaging global delivery team members in the phase
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.
Quality gates are an integral part of Quality Management of SAP, partner or client led projects with
Solution Manager.
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 Quality Management Plan and are set at critical stages in the
project lifecycle:
Project Preparation Phase Completed

Business Blueprint Phase Completed
Baseline Configuration of Realization Completed
Final Configuration of Realization Completed (Solution Built)
Realization Completed (Integration Tests of Realization Completed)
Final Preparation Completed (Go Live Readiness)
Project Complete (Project Closure)
Inputs
The inputs to this deliverable are the completion of all documents, activities and WBS elements to the
satisfaction of the client as required before each Gate.
Expected results
The Project Quality Gate delivers a scorecard that records the results of the quality assessment 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 Review Service Report

Purpose
The purpose of the project review service report 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.
Project review service is an integral part of project quality management 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 have been set and 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 the phase

Business blueprint, at the end of the phase
Realization, during the configuration cycle, before integration testing
Final preparation, two to four weeks before going live
Go-live support, approximately four 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 using a series of scheduled interviews with key project team
members and reviews a list of project documents specific to each project phase.
The SAP project review roadmap contains detailed information on the project management review
service, including templates, procedures, and guidelines.
Sub deliverables
The project review delivers:
Prescribed methodology – Provides an independent and objective management review of project

implementation practices to meet business objectives
Debriefing session – Provides an update on project issues at the end of the on-site survey
Recommendations for risk mitigation – Outlines high-level findings and recommendations for
managing risks
Key findings report – Highlights recommendations for what needs to be done to keep a project on
track
Management presentation – Enables you to gain executive support and stakeholder buy-in
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.
The following figure provides all OCM deliverables for the different phases. A deliverable in one phase
can be an input for another phase (for example, stakeholder identification in the project preparation
phase is input for stakeholder analysis and change impact in the business blueprint phase)
Project -
Phases Project Business Final Go-Live
Realization
Preparation Blueprint Preparation Support
OCM Charter
Launch & OCM Roadmap
Setup
Teambuilding
Stakeholder
Stakeholder Stakeholder Analysis
Management Identification
Change Impact
Communication
Plan Communication
Communication Road Shows
Value Activities
Argumentation
Role Mapping
Organization
Alignment Sounding Panel
Lessons Learned
Business
Monitoring Readiness User
Check Acceptance
Analysis
Note: 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.
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 are:

OCM roadmap
Stakeholder management
Communication plan and activities
OCM monitoring
Integration points for OCM are:

Project management
Risk management
Resource management
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 – Optimization >> SOA Readiness (see also linked nodes).
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:
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.
Education During ASAP Methodology
Roadmap Phases
Project- Project Final

Phases Opportunity Business Realiza- Go-Live
Prepara- Prepara- Run
Edu- Management Blueprint tion Support
Streams
tion tion
Business Education
vision
Input Case workshop
Project team
training Decide on
Project Education strategy Project team Project team knowledge
vision support for
Team workshop Project team
training training
project team
level 2 level 3
Training training and COE
level 1
Create
Perform content
Manage learning
business user needs Prepare
training analysis training Undertake
Business- Education strategy environment usage check
vision to gauge Perform routine
User Training user experience
workshop Refine delivery and user monitoring
Training Draft delivery monitoring adoption (UEM)
(conducted to mechanisms
learning and
define goals) deployment (trainers,on -
Add long- line etc.)
(L&D) Transfer
term needs
to strategy results to
Audit of knowledge
knowledge training
management management
readiness
Ensure L&D Draft Update
Knowledge strategy long- Knowledge
terms needs knowledge
Manage- support Support
are Strategy as
ment strategy
addressed needed
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.3.3 Management of End-User Training
Purpose
Management of end-user training provides a blended learning path for the user that includes e-learning
and training in business procedures and SAP processes. And it’s not just training but knowledge transfer
– which supports sustainment and manages the development and delivery process – that educates users
to optimize SAP implementations. Additionally, management of end-user training is designed to support
the SAP implementation lifecycle with faster implementation and knowledge retention.
Inputs
The inputs for the management of end-user training deliverable are:
Project overview and goals
End-user demographics
Deliverables
Management of end-user training generates an analysis and report that provides guidance on best
practices to ensure that education development, delivery, and sustainment are carried out correctly.
Typically, an SAP learning architect is involved in this deliverable. Additional guidance may also be
provided on end-user education facilitating the implementation and configuration of SAP software.
Expected Results
By completing the management of end-user training deliverable, the project team gains a head start on
defining the education requirements for the project. By having a recommended course of action ahead of
time, the project team will be able to quickly make decisions and prepare an executable education
strategy.
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 the project 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:
Statement of work (SOW)

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.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 following 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 association of 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 work

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 business 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) – optionally this
deliverable can be produced during blueprinting
Scenario-level requirements
Scenario models as 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 Solution
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 deliverables, 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 – Optimization >> SOA Readiness (see also linked nodes).
1.5.1 Value Determination
Purpose
The purpose of a value-based solution design is to determine value drivers and key process changes for
the implementation project.
Ideally, value determination is done before the project or as a “lite” version during project preparation.
At the latest this should be done at the beginning of the blueprint phase. A business case, if one exists,
is the starting point for value determination. Based on the input of process owners and business
stakeholders, a pain-point analysis is done and key process changes are determined. Thus, key process
changes drive the value of the project. The value map associates pain points, key process changes, and
performance indicators to measure success. Value maps, therefore, are the central deliverable for value
determination. Depending on the defined scope of the implementation, value determination is executed in
a “lite” version or comprehensive manner. The deliverables of the core ASAP methodology focuses on
the “lite” version.
The results from value determination are mapped to the process and solution design. A link is maintained
through value maps, KPIs, and PPIs. At the scenario level, financial KPIs are associated; at the process-
level, operational or process performance indicators are the link to the value drivers.
An as-is analysis is optional and intended to catalog existing process documentation that supports to-be
process modeling as reference materials. As-is process models are not being created or updated at this
point. Optionally, a solution transformation roadmap or landscape is being created. The solution
transformation roadmap illustrates how the overall solution is sequenced in implementation cycles; the
landscape illustrates the overall integration with the legacy environment.
The following figure illustrates the value-related activities across all ASAP methodology phases,
particularly the activities during the project preparation phase (highlighted in orange).
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 – a decomposition of the process design – 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 Practices 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.
Value Delivery (VD) in ASAP Roadmap Phases

Execute according to value targets and track value and
manage changes during the project
Project-
Phases Opportunity Project Business Final Go-Live
Realization Run
VD- Management Preparation Blueprint Preparation Support
Streams
Business Business
Input Case or
Case Value Map
Decide about Decide about Decide about

VD support VD support VD support
for for project after go live
opportunity and and
and communicate communicate
communicate
VD
Project Include value Include value Include value
Manage- expert in expert in expert in
project org. project org. project org.
ment
Integrate value Integrate Integrate
milestones in value value mile-
milestones stones in
opportunity with project project
schedule q -gates schedule
*
Derive VM Associa- Execute project according to BC/VM targets Monitor and
from BC** tion of VD Monitor and track value delivery based on BC/VM* track
VD Create value with proc.
based decom-
Execution Scope position Value audit of
storyline scope Update BC/VM*
project based in case of
on BC/VM* Update business case or value map in case of changes
Additional Execute SOA conceptual and implementation services, e.g. pulse check
value-based
VD elements blueprinting Execute value measurement and tracking service
*) BC/VM: business case or value map Mandatory Additional
**) BTC-service for value map creation during preparation phase VD activity VDDraft
activity-
or value map derivation during additional blueprint activities
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 are:
Statement of work – scope determination

Business case
Initiative roadmap, as applicable
High-level to-be solution design, as it exists
As-is analysis, if available
Deliverables
The deliverables from value determination are:
Value maps (optional), including:

Pain points
Process weaknesses (process glow, organizational structure, system support, and data
structure)
Key process changes
Financial KPIs (mandatory)
Value association and KPI on a scenario level (PL2) (mandatory)
PPIs: time, cost, and quality
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
Value determination is the predecessor for value realization during blueprinting and subsequent phases.
It is recommended that you consult the collaborative value realization and implement value audits. If a
comprehensive CVR has been executed, the outcome of the CVR might replace the deliverables from
this deliverable.
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 – a decomposition of the process design – 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 Practices 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.
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
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
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 the initial project planning of an SAP implementation
project. This also includes processes and procedures for basic administration of the infrastructure.
Inputs
The inputs required for technical solution management are:
Technical requirements as specified in the project preparation phase

Initial hardware sizing
Decisions about project support tools
Requirements for archiving as specified in the blueprint data management stream
Documentation of the technical environment
Deliverables
The major deliverables generated from technical solution management are:

Design of the future technical system landscape
Mapping of solutions from the business process model to SAP components
Setup of the development environment
Specification of administration procedures
Setup of the implementation guide (IMG) for the project and definition of customizing conventions
and standards
Setup of previously identified security measures
Setup of the composite application development environment
Setup of the enterprise services environment
The integration point for technical solution management is data management, which is also found in the
blueprint phase and is related to legacy data migration and data archiving. The concepts in that area have
a direct effect on the design and setup of the technical system landscape.
1.6.1 Interface Inventory

Purpose
The purpose of the interface inventory is to identify the external systems, applications, and business
objects or transactions that must be integrated with the SAP application after go live.
Inputs
The input to the interface inventory is the statement of work (SOW).
Deliverables
The interface inventory deliverable establishes 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. 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 define and document technical
requirements for the project and its eventual rollout and to create an initial technical design. The technical
requirements define all technical areas of the project and explain where they integrate with business
requirements, including any expected service-level agreements. Included in this deliverable is the
integration of the new solution with existing solutions and their future operation.
With the initial technical design, you determine how the technical infrastructure is to be implemented – for
example, global versus local infrastructure. The initial technical design also includes the solution
landscape, which is a description of all the technical systems in diagrammatic and textual form. It shows
the hardware, software, and connectivity between all components. It also describes the role of each
component or system.
Inputs
The stakeholders and experts within IT who focus on infrastructure and architecture must be identified to
get their input of the collection of the requirements.
The inputs for the technical requirements and design and solution landscape deployment plan are:
Project scope definition

Technical and functional project scope definition
Business requirements
High-level project plan
An overview of the existing infrastructure and architecture – including suppliers, releases, and versions of
the components – is required to understand the existing system landscape:
Current landscape analysis
Current system maintenance strategy
Current security philosophy
A company hardware catalog is helpful as well.
Deliverables
The deliverables for the technical requirements and design and solution landscape deployment plan are:
Definition of the solution landscape, describing all relevant technical systems in diagrams and text
and determining when they are to be deployed
Documentation of the interfaces between all components in the solution landscape, including the
connectivity between non-SAP components and the new landscape
Documentation of all required tools for implementation and operation and required licenses for
those tools
The solution landscape deployment plan defines the following activities:

What is to be deployed (development, quality assurance, training, and production)
How it is to be deployed
When it is to be deployed (estimation of when the components and environments are required)
If It Is Not Done
The technical requirements and design is a key deliverable. The implementation cannot proceed without
your defining and documenting all aspects of technical design. Technical scope, timeline, and budget
cannot be controlled if they are not clearly defined; without them, serious problems can result, with a
negative impact on the project.
It is critical to have a clear analysis of the current solution landscape before defining any technical
requirements. A careful examination of the existing infrastructure, the business processes it supports, and
integration details for the SAP software solution are necessary to complete the technical requirements.
SAP Solution Manager provides central access to tools, methods, and preconfigured content that can be
used during evaluation, implementation, and operational processing of the planned solution. Specification
of how SAP Solution Management will be used must be part of the technical design.
The major features covering the requirements are:

Solution monitoring, including:
Central system administration
Analysis of your system landscape with service-level reporting
Real-time system monitoring
Business process monitoring
Services and support – Access to programs and services to monitor and
optimize the performance and availability of your system landscapes and to minimize risks when
running your systems
Service desk – Solution support with workflow to create and process
problem messages
Change management – With workflow to trace and audit changes and
transports in your system landscape
Sizing and configuration of SAP Solution Manager – see the SAP
Service Marketplace extranet (links provided as accelerators
1.6.3 Initial Hardware Sizing Proposal
Purpose
The purpose of the initial hardware sizing proposal is to determine your hardware needs with
assistance from your hardware partner.
The following procedures are required:
Do initial hardware sizing separately for each system, such as the development system, the
quality assurance system, and the production system
Size other systems separately, such as template systems in a global environment, the
administration station and clients for mobile scenarios, or the Web server for Internet scenarios
Determine how many applications will go live at the same time
The sizing for each system (development, quality assurance, and production) has to be done several
weeks or even months before the corresponding project phase, as the delivery time for the hardware
must be considered in the project plan.
The first step is to determine the hardware requirements of your SAP software system, including network
bandwidth, physical memory, CPU power, and I/O capacity. The second step (done with the hardware
partner) is to map these hardware requirements to specific hardware.
Inputs
The inputs for the hardware sizing are:

Business requirements completed
Technical requirements completed
Solution landscape deployment plan completed
Long-term planning about which hardware platform will be used for quality assurance and for the
production system
What language and time-zone dependencies do you need to consider for the development
system?
What enhancements do you plan to make to the standard SAP software system?
What development system growth do you expect?
What are your requirements for backup, recovery, and reset of the different systems?
What time window do you expect for system recovery in the future?
Are you planning to use a high-availability solution or split-mirror technology?
The sizing questionnaire (see accelerators) might help to evaluate the business requirements.
Based on this information, you can calculate the required CPU and memory resources (calculated in
“SAPs”), using the sizing tools provided by SAP. The hardware partner then uses the calculated
resources as input to determine appropriate hardware.
For the initial hardware sizing during the preparation phase, you might not yet have all of the required
input. Nevertheless, a first rough estimate of hardware requirements is necessary for setting up the
development system and planning the technical infrastructure.
Deliverables
The deliverables for the initial hardware sizing are:
Rough estimate of the size of the complete landscape, to allow further planning steps
Specific sizing proposals for the systems required already during preparation and blueprint
phases (for example, SAP Solution Manager system or sandbox system)
This initial sizing is to be reviewed and refined several times during the project. You should do this in
collaboration with your hardware partner.
If It Is Not Done
If the initial hardware sizing is not completed correctly, the project might suffer from insufficient hardware
resources during the preparation and blueprint phases. Other infrastructure planning steps (such as data
center capacity and backup planning) might lead to wrong decisions if the initial hardware sizing is
skipped.
There are three different and independent sizing models with different advantages and disadvantages.
The first two, user-based sizing and throughput-based sizing, have been implemented in the Quick
Sizer.
User-based sizing – This model defines three types of active users who work with the system to
different degrees. Merely counting the users can be done quite easily. The disadvantage is that
this estimate is quite rough as it says very little about the actual throughput these users produce.
Throughput-based sizing – This model is quite thorough because it relies on actual or on
actually expected throughput. However, it relies on a number of assumptions in business terms
(such as the number of order line items per year) that must be cross-checked against the
individual installation.
Customer performance test – These tests are done in a customer system with customer data.
The disadvantage is that conducting these tests requires considerable time and money. For
further information, please refer to the white paper Carrying Out Customer Performance Tests.
Additional information for hardware sizing can be found at http://service.sap.com/sizing.
There you will also find a rough guide on using the Quick Sizer tool as well as a Quick Sizer Best
Practices guide.
With the help of standard application benchmark results at www.sap.com/benchmark, assumptions can
be made about CPU and memory consumption of particular software components as well as a mapping
of “SAPs” to specific hardware.
1.6.4 Project Support Tools and System Setup
Purpose
The purpose of the project support tools and system setup deliverable is to set up the project
environment and define and set up the support tools.
Inputs
The inputs for the project support tools and system setup are:
Project management plan definition

Organizational change management strategy (optional)
Definition of the dimension of the project team and agreements about the working environment
(such as location)
Deliverables
The deliverables for the project support tools and system setup are:
Project team environment set up, including:

o Rooms and access authorizations
o Equipment (including phones, PCs with all required tools installed, printers)
o Access to the customer network and file servers
Installed and setup SAP Solution Manager
Customer specific project management and documentation tools installed and set up
Network connection to the SAP Service Marketplace ordered
If It Is Not Done
If the project support tools and system setup delivery is not completed correctly, the project team cannot
work efficiently. Without this deliverable, it will be difficult for the project team to hand over its work in the
defined form and tools.
The SAP Solution Manager is SAP’s central solution operations platform and contains a lot of the
software tools and components needed for technical infrastructure requirements and design. Besides the
basic scenarios for service delivery and issue management that are used in later operational phases, the
project can benefit from the SAP Solution Manager during the early project phases as well. Do this by
using the basic business blueprint and configuration function to generate business blueprint
documents and configuration guides for your solution. In this way SAP Solution Manager can be become
the central storage place for landscape, customization, and business blueprint documentation.
SAP Solution Manager provides the following functionality for implementing and upgrading SAP solutions:
Central access to all tools for your project (project administration, business blueprint,
configuration, test workbench, creation of group rollout templates)
Central management of all information for your project (roadmaps, system landscape, project
documentation)
Comparison and synchronization of customization in different SAP components
For further Information, refer to http://service.sap.com/solutionmanager.
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
Project schedule
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

Project Preparation - ASAP

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Project Preparation - ASAP

Încărcat de

Drepturi de autor:

Formate disponibile

ASAP Methodology for Implementation

Benefits of ASAP include:

Faster implementations with streamlined and focused methodology

The major work streams for this preparation are:

Team Identification, Allocation, and Coordination

The phase start-up involves:

1.1.1.2 Definition of Project Organization, Roles, and Responsibilities

Review the project charter and scope

The inputs to this task are:

Handover information from the opportunity management phase

1.1.1.4 Assignment of Roles and Responsibilities

To assign roles and responsibilities:

Match company and consulting resources to roles

Assign resources to roles

The sub deliverables are:

1.1.1.5 Setup of Project Logistics and Infrastructure

Resource assignments to roles and responsibilities

The triggers for this activity are:

Defined milestone plan

The inputs to this activity are assigned roles and responsibilities.

The sub deliverables from this activity are:

1.1.2 Project Initiation

Handover information from OMP

1.1.2.1 Business Case

In creating the business case, consider the following inputs:

Section Key Content Inputs

Objective What business need the project is Customer business case

Proposed “To-be” situation Statement of work (SOW)

Benefits Tangible and intangible benefits Customer business case

Investment Cash inflows Customer business case

Dependencies Geographic and organizational Customer business case

For further information, refer to:

1.1.2.2 Project Charter

Section Key Content Inputs

Deliverables Produced by the team to ensure project success SOW

1.1.2.3 Scope Statement

Approval Approval from customer project sponsor, Signatory authorization

1.1.2.4 Schedule for Project Planning

Schedule Development (Rolling Wave)

Project management plan and subsidiary plans

The key objectives of integrated change control are to:

Integrated change control includes these components:

Defining an integrated change control procedure

1.1.3.2 Issue Management Procedure

1.1.3.4. Time Management Plan

Time management plan template

Human resource management plan template

Team member status reports

Communication management plan template

Global risk policy

Project risk management plan

1.1.4 Executing, Monitoring, and Controlling of Results

In executing project work, the project team:

Performs activities to accomplish project objectives

Implements and executes the planned methods and standards

In monitoring and controlling project work, the project team:

Compares actual project performance against the project management plan

The inputs to the executing, monitoring, and controlling of results are:

Project initiation documents

The outputs of this deliverable are:

Project performance reports, including:

Team member status reports

Project budget updates