Project on ASAP Implementation of Reliance Global Service

ASAP Methodology for Implementation

Purpose

The ASAP methodology for implementation is a phased, deliverable-oriented methodology thatstreamlines implementation projects, minimizes risk, and reduces total cost of implementation. ASAPtakes a disciplined approach to project management, organizational change management, solutionmanagement, and other disciplines applied in the implementation of SAP solutions. The methodologysupports project teams with templates, tools, questionnaires, and checklists, including guidebooks andaccelerators. ASAP empowers companies to exploit the power of the accelerated features and toolsalready 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, ahigh-level scope, and a project plan. Executive sponsorship is secured, and theproject standards and organization are set up. The implementation strategy isdefined and approved. At the same time, the project procedures, standards,organization, and staffing are finalized. Roles and responsibilities of the entireproject team are agreed upon and documented. The objectives of the projectare validated, and all initiation activities are documented in the project charter.

2. Business blueprint During this business blueprint phase, solution and technical designs aredocumented in the business blueprint. Lead by solution and industry expertsfrom the SAP Consulting organization, a series of structured processworkshops are planned and executed to arrive at the “to-be delivered" SAPenterprise solution. All available documentation for standard, delivered supportfor SAP business scenarios and all relevant preconfigured support for bestpractices are reviewed and discussed with SAP experts. All functional andtechnical requirements, coupled with project issues and gaps, are documentedin the SAP Solution Manager application management solution.

3. Realization In the realization phase, the SAP software system is configured and tested ina number of cycles. Initially, the baseline configuration, which represents thecore business process settings, is performed, tested, and confirmed. This isfollowed with a series of configuration and development cycles, to implementthe entire end-to-end solution. The solution is tested in a number of cycle testsand in a focused end-to-end integration test. Configuration is documented inSAP 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 conversionprograms are created and tested. The production system is installed duringrealization.

4. Final preparation Within the final preparation phase, all systems are known to function correctlyfollowing the approved integration test. Technically, all integration issuesshould now be resolved. Detailed transition and cutover plans are created. Thecustomer support organization is put in place. The production system is set upwith transports and customer data. At the end of this phase, the productionsystem 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 preproductionenvironment to live production operation. An easily accessible productionsupport organization must be in place to support the end-user community, notjust for the first critical days of production operations, but also for long-termsupport.

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 operatingcondition, guaranteeing systems availability and required performance levels tosupport the execution of the enterprise’s business operations. Therecommended starting point of the phase is an assessment of solutionoperation after the go-live support phase to identify the relevant SAP standardsfor solution operations to be established or improved in the phase. The centraloperation platform is SAP Solution Manager, with the documented solutionbased on the transferred project documentation.

Work Streams

The ASAP methodology is structured around the key project work streams that are outlined in thepicture below. For each work stream, the methodology lists the number of deliverables that are to beproduced in each phase of the project.

The deliverables in later phases leverage or build upon deliverables completed in earlier stages. Theroadmap is structured as a work breakdown structure (WBS) that represents a complete list ofdeliverables that need to be completed by the project team.

The ASAP methodology for implementation projects represents a standardized work breakdown structurethat 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, andchecklists for use by project teams in effectively managing and completing SAP solution implementationprojects.

1. Project Preparation

Purpose

The project preparation phase provides initial planning and preparation for the project. Although eachproject has its own unique objectives, scope, and priorities, the deliverables outlined below assist incompleting 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

PurposeThe purpose of the project management phase is to provide essential methodology for the requirementsplanning for and execution/controlling of an SAP software implementation project.

Team Identification, Allocation, and CoordinationDuring subsequent phase start-up activities, the project manager coordinates the allocation of resourcesidentified for the project phase using the project schedule and the resource plan. This ensures the propertiming of resource assignments needed to complete project work. The project manager validates theparticipation and ongoing commitment of the steering committee members at the phase start-up.

Kickoff MeetingThe scale of this task varies with project size and complexity. For small, low-risk projects, the kickoffmeeting may be an informal review of the process by the project sponsor and the program or projectmanager. For larger projects, you should consider a formal kickoff of the project to achieve a commonunderstanding of the objectives of the planning process and to clarify the various participants’ roles. Theproject manager clearly defines the objectives of each phase kickoff meeting and designs the agenda toachieve 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 theorganization, bringing the project sponsor and key stakeholders together to reinforce commitmentto the project and raise awareness across the organization. This type of kickoff could be animportant part of the project’s organizational change management approach.

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

Project ScheduleThe project manager expands and updates the project schedule. At a minimum, the schedule shouldinclude 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 ofthe schedule for the entire project.

Inputs

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

DeliverablesDeliverables 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

PurposeThe purpose of the phase start-up deliverable is to coordinate the setup of an appropriately sized teamand to prepare the team for the activities within the phase. This deliverable ensures the involvement andcommitment of the team and other key resources to the project schedule. It also examines the approachfor the specific project phase.

Note: The phase start-up for the project preparation phase also includes a handoff of informationgathered 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)

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

DeliverablesThe 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 theproject 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 anearly stage of the project that the customer prepares for SOA readiness. Further guidance on this topic isprovided in Run >> Governance Model for Organization – Optimization >> SOA Readiness (see also thelinked node).

1.1.1.3 Phase Resources Allocation

Purpose

The purpose of phase resources allocation is a confirmation of resource availability for the particularphase. The resource plan and schedule detail the resource requirements, but in the start of each phaseyou 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 theproject 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 thewhole 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 toconsultants used will vary depending on the availability of company resources, programmanagement’s strategy on the use of consultants, and funding considerations. During a start-upphase of a global program, the development project typically employs one consultant for every threeto four company resources. As the program progresses and knowledge transfer occurs, fewerexternal resources should be required.

External resources are ideally suited to functions that need specialized business process andconfiguration skills for short durations.

Unless IT management is outsourced for strategic reasons, it is advisable to have client IT personnelin the SAP project (see also SAP Customer Competence Center). Otherwise, it is difficult for thecorporate 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 environmentis in place before you begin the project. It provides suitable physical (work), technical, and administrativeenvironments including IT access, telephones, voice mail configuration, and physical security. It clearlydefines the procedures for conducting project administration operations. At project start, you mustcomplete the project logistics and environment checklist.

In addition, in the case of a virtual project team, best practices for working remotely should be reviewedand included in the project logistics and infrastructure.

InputsThe inputs to this activity are:

Resource assignments to roles and responsibilities

SAP best practices for virtual teams

Sub deliverablesThis 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 andpartner 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, andproject scope, for example)

On boarding package

1.1.1.7 Phase Kickoff Meeting

PurposeThe phase kickoff meeting helps ensure the involvement of the team and other key resources and theircommitment to the project schedule. The meeting is also used to examine the approach for the specificproject phase.

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

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

Team-focused meetings should be focused on team members to ensure alignment around thework (definition and approach for outputs) to be performed during the phase.Communications-focused meetings should be focused more on communications across theorganization, bringing the project sponsor and key stakeholders together to reinforce commitmentto the project and to raise awareness. This type of kickoff could be an important part of theproject’s organizational change management approach.

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

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

1.1.2 Project Initiation

PurposeThe purpose of this project initiation deliverable is to formally recognize that a new project exists. Itsupports the decision to accept the project, align stakeholders – such as clients, customers, and SAPmanagement – around a project and its scope, provide updated information for planning, and obtain acommitment to proceed. It ensures alignment between SAP, the customer’s strategic direction, and thesatisfaction of operational requirements.

InputsThe 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

DeliverablesThe 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 andcosts. It provides the economic justification for the proposed project and documents how and when theinvestment will be profitable for the customer. Information included in the business case is the essentialbusiness 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 issolving

Customer business case SAP business case, value assessment, or

business assessment SAP collaborative value assessment

Problem andOpportunity

“As-is” situation

ProposedResolution

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

Strategic Alignment Customer business strategy andtechnical strategy



Benefits Tangible and intangible benefits Customer business case SAP business case, value assessment, or

business assessment SAP collaborative value 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 Discount rate


Dependencies Geographic and organizationalscope – people, associatedlocations, languages, andorganizations affected or impactedby the proposed solution


business assessment SAP collaborative value assessment SAP value map SOW Proposal

Affected Systems System scope – systems andassociated locations affected orimpacted by proposed solution


business assessment SAP collaborative value assessment SOW Proposal

Stakeholders Starting with C-Level management Company fact sheet SAP value map

Sub deliverablesThis activity generates a reviewed and approved project business case that is documented andcommunicated to the project team.

If It Is Not DoneThe business case is the central controlling instrument for value delivery during the project. If this step isskipped, the primary business objectives and customer expectations cannot be measured at the end ofeach project phase. It is important for customers to assess their business objectives during the review ofproject 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 businessassessment service; collaborative value realization service

SAP value engineering services: collaborative value assessment servicePMBOK® Fourth Edition, Chapter 4, Project Integration Management

Adapted from PMBOK® Fourth Edition, Chapter 4, Project Integration Management © 2004 ProjectManagement Institute

1.1.2.2 Project CharterPurposeThe project charter is developed by reviewing documents from the pre-project negotiation process andthrough 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 definesthe 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 ofthe project.

InputsWhen creating the project charter, consider the following inputs:


Project Overview Current, “as-is” situation and business needs Proposed resolution, “to-be” situation, and high-

level summary of what the project will deliverfrom an organizational, functional, technical, andgeographic point of view

Project business case Statement of work (SOW)

Project Scope Characteristics of the solution or service that theproject was undertaken to create; note out-of-scope organizational, functional, process, anddevelopment objects (such as data cleansing),and technical applications

Overall project goal

SOW Proposal

Project Objectives SMART (specific, measurable, attainable, relevant,and time-bound) aims of the project derived fromrequirements, benefits, project needs, and measuresof success aligned to corporate and organizationalstrategies and the project goal

SOW Proposal

Deliverables Produced by the team to ensure project success SOW Proposal Project business case

Business CaseSummary

Summary of justification for project, return oninvestment (ROI) and related key performanceindicators (KPIs)

Project business case

Total EstimatedProject Costs

Estimated total project costs through closing SOW Proposal Project business case

ImplementationStrategy

The approach selected for the project based on theanalysis of solution options during the evaluationphase

Proposal Prestudy

Project Planning A summary level schedule (chart or graph) with high-level dates that identifies the major ASAPmethodology milestones related to phases and valuedelivery

SOW Proposal

ProjectStakeholders

Persons or organizations actively involved in theproject or whose interests may be positively ornegatively affected by execution or completion of theproject

Project business case SAP value map from the

SAP Value DeliveryManagement portfolio ofservices

Assumptions Factors that are considered to be true, real, orcertain without proof of demonstration and projectlimits

SOW Proposal

Project business case SAP value map

Constraints Factors that limit options and are beyond the controlof the project team, resulting in a state, quality, orsense of being restricted to a given course of actionor inaction

SOW Proposal Project business case SAP value map

Risk Assessment Factors that may have a negative impact on theproject

Proposal SAP risk assessment

Approval Approval from the program sponsor – the keyindividual, person, or group that provides financialresources to the project

Signatory authorization

Sub deliverablesThis activity generates a reviewed and approved project charter that is documented and communicated tothe project team.

If It Is Not DoneIf you skip this step, the project is not formally approved by the customer sponsor and the projectmanager is not authorized to apply organizational resources to project activities.

Additional InformationAssess whether the customer has existing:

Organizational policies and procedures, standard product and project lifecycles, and quality policies Standardized guidelines, work instructions, and proposal evaluation criteria Guidelines and criteria for tailoring the organization’s set of standard processes to satisfy the specific

needs of the project Organizational communication requirements, such as record retention and security requirements Procedures for issue and defect management, including controls, identification and resolution, and

action item tracking Change control procedures, including the steps by which the company modifies, approves, and

validates official company standards, policies, plans, and procedures as well as project documents Risk control procedures, including risk categories, probability definition and impact, and probability

and impact matrix

For further information, refer to PMBOK® Fourth Edition, Chapter 4, Project Integration Management.Adapted from PMBOK® Fourth Edition, Chapter 4, Project Integration Management © 2004 ProjectManagement Institute

1.1.2.3 Scope Statement

PurposeThe 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 andplanning of the project and clearly and explicitly defines the deliverables of the proposed project. Thisinformation and supporting documents align key stakeholders around what the project is going to deliver.

InputsIn completing the scope statement, consider the following inputs:


Project Goal “To-be” process – describing the overallgoal to be achieved by the project

Project business case Project charter

Solution or ServiceDescription

Detailed summary of organizational,functional, development, technical,geographic, and language scope

Statement of work (SOW)

Project Requirements Documentation of the capabilities orconditions that must be met by the project

SOW Proposal

Project Objectives Customer strategies (corporate andorganizational) aligned with project goals

Project business case Proposal

Deliverables Key deliverables produced by the team toensure success

SOW WBS

Project Boundaries List of specific systems (SAP andcustomer applications) within the projectscope

SOW

Out of Scope Notation of out-of-scope organizational,functional, process, and developmentobjects (such as data cleansing forconversions), and technical applications

SOW Proposal

Project Assumptions Items or factors that are considered to betrue, real, or certain without proof ofdemonstration and project limits

SOW Proposal

Project Constraints Factors that limit options and that arebeyond the control of the project team,resulting in the state, quality, or sense ofbeing restricted to a given course of actionor inaction

SOW Proposal

Project RiskAssessment

Risks that may have a negative or positiveimpact on the project

SOW Risk register

ImplementationStrategy

Description of the ASAP methodology andapproach for implementation

SOW ASAP methodology

description

Initial Work BreakdownStructure (WBS)

Decomposition of deliverables WBS

Project Organization Project organizational chart of individualsand organizations that have specific rolesin the project team

Human resourcemanagement plan

Acceptance Criteria Scope verification process Scope management plan

Schedule Milestones Key project milestones and dates SOW

Order of MagnitudeProject Costs

Estimated total project costs throughclosing

SOW

Configuration The approach for documenting product Integrated change control

ManagementRequirements

characteristics and integrated changecontrol

plan

Project Costs Neededto Proceed

Estimated project costs required to moveto the next phase

Project cost and effortestimate

Approval Approval from customer project sponsor,customer key stakeholders (if applicable),customer and SAP project managementteam, and customer and SAP team leadsto manage organizational, functional,development, technical, and geographicscope in the next phase of the projectimplementation

Signatory authorization

Deliverables

This step generates a reviewed and approved scope statement that is documented and communicated tothe 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, includingidentification of milestones, quality gates, and end dates, as well as estimated costs and budgets. Theschedule for project planning includes all scheduled tasks, resources, and start and end dates for allactivities 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 teammembers through to the end of the business blueprint phase only (that is, theplanning phase approval checkpoint). Activities in later phases are defined andscheduled during the business blueprint phase, using a rolling wave approach, whichenables the completion of the schedule for the entire project. Using this approach, theplanning team develops schedule details for the next phase (for example, therealization phase) and schedules subsequent phases. Replanning points arescheduled toward the end of each phase (as detailed information for the next phasebecomes 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 deliverablesThis 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 projectmanagement plan and the subsidiary plans on the basis of the project scope defined in the projectcharter. This includes the development of the project schedule, the budget, and appropriate updates tothe business case.

The project management plan is a comprehensive document (or collection of documents) that includesthe schedule, cost information, monitoring/controlling plans for each of the nine knowledge areas of theproject management body of knowledge (PMBOK), and other information, as appropriate.

The subsidiary management plans developed for each of the knowledge areas provide the foundation tosupport the consistent application of project management practice.

InputsThis deliverable includes the following inputs:

Project charter Handoff checklist from preproject activities (optional)

DeliverablesThis 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

PurposeIntegrated 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 ofthe 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. Theprocedure elaborates on sections from the project management plan that pertain to integration andmanagement change control. An effective change control system maintains control while allowingflexibility.

The change request form and change request log enable the execution of the change controlprocedure and must support the multiple levels of analysis and approval required to deal with a requestedchange.

To produce the integrated change control procedure, use the integrated change control templates todefine an appropriate control system for the project. Consult with the customer project manager whencreating the procedure.

InputsThe inputs to the integrated change control procedure are:

Integrated change control procedure template Project management plan Customer change control policies, procedures, and guidelines

Sub deliverablesThis step generates a reviewed and approved integrated change control procedure that is documentedand communicated to the project team.

Additional InformationWhen dealing with integration change control and change request management for the implementationproject, it is recommended that you define and prepare for operational change management proceduresin parallel. Further guidance on this topic is provided in Run >> Change Management >> ChangeRequest 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. Anissue is a situation, action, problem, or question arising during the project, that the project team cannotresolve efficiently or effectively. Left unresolved, an issue will impede or prohibit project-related progressor development by delaying or suspending a task or project.

The key objectives of issue management are to identify, track, and resolve issues related to projectactivities 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 isdocumented and communicated to the project team.

Additional InformationFor further information, refer to PMBOK® Fourth Edition, © 2008 Project Management Institute

1.1.3.3 Scope Management Plan

Purpose

The scope management plan outlines the processes required to ensure that the project includes all ofthe work required, and only the work required, to complete the project. The scope management planelaborates on sections of the project management plan that pertain to the functions of scopemanagement.

Inputs

The inputs to the scope management plan are: Scope management plan template Project charter Customer scope management policies, procedures, and guidelines

Sub deliverablesThis step generates a reviewed and approved scope management plan that is documented andcommunicated to the project team.


1.1.3.4. Time Management Plan

PurposeThe time management plan outlines the processes required to ensure timely completion of the project. Itelaborates on sections from the project management plan that pertain to the functions of timemanagement.

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 deliverablesThis step generates a reviewed and approved time management plan that is documented andcommunicated to the project team.


1.1.3.5 Cost Management Plan

PurposeThe cost management plan outlines the processes required to plan, estimate, budget, and controlproject costs. It elaborates on sections of the project management plan that pertain to cost management.

InputsThe inputs to the cost management plan are:

Project charter Cost management plan template Customer policies, procedures, and guidelines

Sub deliverablesThis step generates a reviewed and approved cost management plan that is documented andcommunicated to the project team.


1.1.3.6 Quality Management Plan

PurposeThe quality management plan outlines the specific organization, processes, and materials needed toensure quality on the project. It elaborates on sections of the project management plan that pertain toquality 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 andcommunicated to the project team.


1.1.3.7 Human Resource Management Plan

PurposeThe human resource management plan outlines the processes required to staff, organize, and managethe project team. It elaborates on sections of the project management plan that pertain to humanresource management.

Inputs

The inputs to the human resource management plan are:

Human resource management plan template Project charter Customer policies, procedures, and guidelines Assigned roles and responsibilities

Sub deliverablesThis step generates a reviewed and approved human resource management plan that is documented andcommunicated to the project team.


1.1.3.8 Communication Management Plan

PurposeThe communication management plan outlines the processes required to ensure timely generation,distribution, storage, and retrieval of project information. It elaborates on sections from the projectmanagement plan that pertain to communication management.

The project communication matrix outlines the project team’s approach to project-specificcommunication. It captures the analysis completed as part of communication planning and serves as atool to guide the project team throughout the project.

Project performance report templates are produced for different purposes and target audience, asdefined 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 itagainst baseline information to the various project stakeholders. The reports capture the analysis ofcompleted project work in achieving project objectives. At a minimum, project performance reports shouldprovide 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 Project scope statement Customer communication management policies, procedures, and guidelines

Sub deliverablesThis step generates a reviewed and approved communication management plan that is documented andcommunicated 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 performedthroughout the ASAP methodology delivery phases. The risk management plan defines how risks arediscovered, defined, assessed (during risk reviews), and managed. It also describes how often riskreviews are conducted.

To handle risks in a simple way within any customer project, you can use the project risk list.

InputsThe 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 deliverablesThis step generates:

Project risk management plan Risk register

The expected output of the risk assessment is a comprehensive explanation (in a document) of how riskdiscovery, definition, assessment, and management will take place throughout the project lifecycle.


1.1.3.10 Project Contract Inventory

PurposeThe project contract inventory contains all contractual agreements with product and service providersfor the project. For an implementation project, this may include contractual arrangements with hardwareproviders, organizational change management, training, hosting, off-shore delivery, and applicationmanagement 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 deliverablesThis 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 adverselyimpact 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 performmultiple actions to execute the project management plans to accomplish the work defined in the projectscope 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 PlanDefinition”) guide the team's approach to management, execution, and control of project activities. Theproject manager is responsible for ensuring that management plans are applied at the appropriate level ofcontrol.

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 ofknowledge (PMBOK) areas. These plans provide the foundation to support the consistentapplication of project management methods across the SAP project organization based on theproject scope.

Project schedule

The detailed project schedule defines the work to be performed, what resources and associatedtime 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 partof the project. The resource and time commitment estimates can be used to calculate end datesand 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)

Additional InformationFor further information, refer to PMBOK® Fourth Edition, Chapter 4, Project Integration Management.Adapted from PMBOK® Fourth Edition, Chapter 4, Project Integration Management © 2004 ProjectManagement Institute

1.1.4.1 Project Performance Reports

Purpose

Throughout the project, a number of project performance reports need to be produced for differentpurposes 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

This step generates:

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

PurposeThe 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 criticalcomponent of an integrated change control system. The change request form enabling the changecontrol procedure must support the multiple levels of analysis and approval required to deal with arequested 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 thatyou define operational change management procedures. Further guidance on this topic is provided inRun >> Change Management >> Change Request Management/Change Control Management (see alsolinked nodes).

1.1.4.4 Issue Log Updates

Purpose

A consistent, comprehensive approach to managing project issues is a critical component of an effectiveproject management system. The SAP Solution Manager application management solution (or an issuelog, if SAP Solution Manager is not available in your project) supports the issue managementprocedure 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 theproject. Effective issue management involves the appropriate level of management making decisions onissues and tracking progress on issue resolution in accordance with the project issue managementprocedure. The issue log is formally closed out with other project controlling documentation duringproject 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 workto be executed by the project team to complete the project. It is the basis for the organization andcoordination of the project. A WBS consists of WBS elements that describe project tasks and subtasks toperform within a defined time period.

InputsThe 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 aredocumented 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 canadversely 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 timecommitments 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 definean appropriate time management plan for the project.

Inputs

The inputs to the project schedule are:

Time management plan template Project charter Project scope statement WBS template (from the opportunity management phase) Customer policies, procedures, and guidelines

Sub deliverablesThis step generates a refined time management plan with a blueprint workshop schedule.

Additional InformationFor further information, refer to PMBOK® Fourth Edition, Chapter 6, Project Time Management.Adapted from PMBOK® Fourth Edition, Chapter 6, Project Time Management © 2004 ProjectManagement Institute

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 theanalysis completed as part of communications planning and serves as a tool to guide the project teamthroughout the project.

The matrix holds the following information for each communication:

Communication reference number Target audience (stakeholder) analysis, including:

o Audienceo How the audience is impactedo How the audience will be engaged

Communications planning, development, and delivery, including:

o Communication evento Message intento Timingo Vehicleso Sendero Feedback mechanismo Comments

Project communication typically falls into one of two primary categories: internal project communicationsor stakeholder communications.

Inputs

The inputs to the communication matrix are:

Communication management plan Stakeholder analysis

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 developsthe team, including evaluating performance. You should introduce the concept of team memberevaluations and appraisals when new members join the team, to discuss performance developmentopportunities and objectives for the individual while on the project. This information needs to be recordedfor 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 efficientand effective manner. Their key objective is to identify, define, approve, and communicate standardsrelated to project execution.

Project standards are elaborated throughout the project initiation and planning phases. During the projectpreparation phase a subset of the project standards must be defined, approved, and communicated tothe project team. Communication of project standards should be included in project on boardingcommunications and phase start-up meetings. Given the integrated nature of project standards, changesmust 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 theintegration 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 astructured way for the SAP Solution Manager application management solution to support a standardSAP implementation project to the best effect in the preparation phase. The SAP Solution Managerusage guidelines include the setup of a project in SAP Solution Manager and provide the project teamwith 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 gaina 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 tobe used in SAP Solution Manager. These can be found in an attached accelerator.

When defining documentation standards for various documentation needs during the implementationproject (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 SAPstandards for solution operations. Further guidance on this topic is provided in Run >> SAPApplication Management >> Solution Documentation (see also linked nodes).

Furthermore you find one service link to “Expert Guided Implementation.” Expert-guided implementationis a new optimized, short-term setup service to configure basic settings for SAP Solution Manager withoutlong-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 forimplementation 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 executingprocess 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 doeswork 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 modelingguidelines 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 tooleasily; an example is given for Visio. Please view the SAP Modeling Handbook on the Business ProcessExpert (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 afundamental basis for process modeling and service modeling standards.

When defining business process modeling standards, it is recommended that you define and prepare foras well as cross-check the SAP solution documentation: SAP standards for solution operations withrespect to business process modeling. Further guidance on this topic is provided in Run >> SAPApplication Management >> Solution Documentation (see also linked nodes).

1.1.5.3 Initial Development Management Standards

PurposeWith the increasing number of systems and technologies, the complexity of IT solutions is rising. The keyto successful landscape planning and operation is an accurate and complete description of the solutionlandscape 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 documentationdescribes in general how customers achieve the required transparency of their SAP solution. On onehand, minimal documentation as described in this sub deliverable lays the ground for leveraging manyoperations support functions offered via SAP Solution Manager (for example, identifying affected custombusiness processes or customizing change requests). On the other hand, it is important to have thedocumentation in a standardized location and format to ensure the optimal delivery of SAP supportservices. To enable SAP to deliver services for custom projects especially, a minimum amount ofdocumentation is required. This sub deliverable describes the required content of this documentation aswell as the tools and formats to be used to deliver it.

Inputs

The input to initial development management standards are the best practices and recommendationsfor SAP custom development standards.

Sub deliverables

This step generates customer-agreed standards for custom development. By completing the deliverablecorrectly, the project gains guidelines for creating custom development documentation, enabling futureservices and upgrades.


When defining documentation standards for various documentation needs during the implementationproject (such as project documentation, configuration documentation, and enhancement and modificationdocumentation), it is recommended that you define and prepare for as well as cross-check the SAPsolution documentation: SAP standards for solution operations. Further guidance on this topic is providedin Run >> SAP Application Management >> Solution Documentation (see also linked nodes).

1.1.5.4 SAP Services Deployment Plan

PurposeManaging complexity, risk, and costs as well as skills and resources is at the heart of implementingmission-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 theadministration of SAP-centric solutions. The term “system administration” encompasses all activities thatensure the successful, long-term operation of a solution from a technical perspective. The range ofactivities 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 fordata management, change management, and incident management, for example, are explained in

separate documents. This document provides an overview of the various regularly-occurring standardsystem administration tasks and associated tools.

Over the course of evolving to service-oriented architecture (SOA) solutions, vertical systemadministration based on a technical system gives way to horizontal system administration based onprocesses. Consequently, the different subject areas in system landscape administration must becombined 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 deployingsystem administration services.

1.1.5.5 Software System Configuration Standards

Purpose

The purpose of the software system configuration standards sub deliverable is to establish standardsfor SAP software system configuration for those who perform initial configuration setup. The systemconfiguration is a crucial part of SAP software implementation, so only selected groups should haveaccess and authority to make any changes to the SAP software configuration. The defined standardsmust follow the SAP installation guides and best practices but should also take into account alreadyestablished principles for existing systems.

Software system configuration standards must provide guidelines for software installation as well asspecifications for the initial system administration and system monitoring configurations.

Inputs

The inputs to the software system configuration standards from the project are:

Project standards guideStandard installation guides and best practices guides

An overview of the standards and naming convention in the existing infrastructure is required to adapt theproject landscape to the existing landscape:

Naming conventions for systems and softwareCustomer-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 setupDocumentation of standards for hardware and operating system setupNaming conventions for software installationsDocumentation of standards for software installationSpecification of configuration requirements for system monitoringSpecification of standard configurations for system administration


Accelerators giving guidance on how SAP system configuration standards are applied using SAP SolutionManager 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 >> SolutionDocumentation (see also linked nodes).

1.1.5.6. Enhancement and Modification Standards

PurposeCustom development, enhancements, and even modifications of SAP software are not rare at companiestoday. They are implemented to extend the functionality of SAP standard software and to adjust it to thecompany-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 insufficientinformation about standard functionality provided by SAP. In addition, custom code can become obsoleteover time though still maintained. And finally, poor software quality often causes problems in productionenvironments 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 fourdimensions of custom code: quantity, quality, technical severity, and business criticality, as well as thepreparation and adoption of SAP custom development for daily operations and support. Thus,enhancement and modification standards provide a holistic view of custom development from theoperations perspective, not from the development itself. The topics and methodology described in thissub deliverable are oriented purely to the ABAP programming language.

Inputs

The inputs to enhancement and modification standards are best practices and recommendations forenhancement 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 earlystage of the project that the customer defines and prepares for custom code management. Furtherguidance 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

PurposeManaging complexity, risk, and costs as well as skills and resources is at the heart of implementingmission-critical support for SAP-centric solutions. The complexity rises even further with the trend ofoutsourcing process components. To help customers manage their SAP-centric solutions, SAP providesa comprehensive set of standards for solution operations.

In this set of standards, the upgrade standard provides guidance for holistic and effective qualitymanagement of an upgrade project end to end, from its earliest stages of evaluation until after asuccessful cutover of the productive system. The standard defines the key focus areas, providesguidance, and explains best practices for the management of upgrade projects. All this helps customersbetter understand and manage the major technical risks and challenges of an upgrade project and tomake it a non-event for the business.

This sub deliverable provides details regarding the upgrade standard. It explains the basic concept of thestandards, describes the seven key focus areas of upgrade projects, and lists and explains the activitieswithin 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 thechange and transport system (CTS) scenario within fully-controlled change request management. Thissub deliverable gives the customer a method for monitoring change requests that are in progress orcompleted in an implementation project and in a production system. It also helps the customer manageand control the transports that belong to the change request. A controlled change request managementprocess using functionality of SAP Solution Manager controls the integrated change and transportlifecycle 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 functionalityof 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 andhandling change requests and transports within the implementation project and in a productive systemlandscape 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 thatyou define and prepare for operational change management procedures. Further guidance on this topic isprovided in Run >> Change Management >> Change Request Management/Change ControlManagement (see also linked nodes).

1.1.5.9 Test Management Standards

PurposeQuality assurance and testing are an integral part of the project and application lifecycle. Within animplementation project, testing follows a structured approach consisting of functional and non- functionaltest stages.

Functional tests ensure the functional correctness of test objects (Question: Does the system act asexpected and according to requirements?) and are typically conducted in multiple stages for everydeliverable 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: SAPsolutions are changed on a regular basis through SAP enhancement packages, support packages, SAPnotes or customer-triggered change events, which require customers to test their business processesthoroughly. 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 teststrategy for the project should be defined. If possible, the currently employed test management approachshould be assessed and adapted for the project.

InputsThe 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 deliverablesThis 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 upthe test strategy.

1.1.5.10 Post implementation Service and Support Standards

PurposeCompanies may recognize that their current IT support organization is not adequate to support an SAPplatform. They first need to calibrate their overall operational maturity and then develop and execute aplan for a support model at the lowest total cost of ownership (TCO) for the customer satisfaction leveldefined. For that, SAP offers guidance through support services and defined support standards. Thepurpose of this sub deliverable is to start defining the services and standards for the time after theimplementation project closes and operational activities become the main tasks.

Implementation Standards

The SAP Active Global Support organization provides SAP Enterprise Support services that are akey enabler for integrated, standardized, end-to-end solution operations. The key focus of SAP EnterpriseSupport is the holistic application lifecycle management of customers’ software landscapes andapplications. In addition, more customer-tailored support is offered through the SAP MaxAttentionsupport option and SAP Safeguarding services.

Support Standards

Companies expect high availability and continuity of their solutions, flexibility to quickly implementchanges, and low TCO. Additionally, they need to be able to manage out-tasking and outsourcingrelationships across different time and geographical zones and to control and monitor service-levelagreements. To achieve this, IT governance is key. Companies need an IT strategy that focuses on themanagement of complexity, risks, and costs as well as skills and resources. Standardized procedures thatleverage the experience of the organization and the software supplier are a key prerequisite for theoptimization of application management.

InputsThe 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 deliverablesOutput 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 themodeling, definition, and development of enterprise services can begin. This enterprise services designgovernance process ensures that all enterprise services are defined according to certain rules that ensureconsistency, standards compliance, harmonization of business semantics, and reuse across all SAPsolutions. 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, theenterprise services modeled represent a “common language for the business” with an optimal level ofgranularity.

Sub deliverablesThis step generates enterprise services design standards that include the definition of governancerules and a framework for developing enterprise services (design time governance). Key aspects to beconsidered are:

Service modeling and implementation guidelinesService development rules (for example, how to ensure item potential)

Service documentation rulesService versioning and publication processService 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. Theprocesses should be supported by appropriate tools, templates, and guidelines.

A key tool for supporting the governance of enterprise service modeling and implementation is the centralEnterprise Services Repository.


SAP has developed an advanced metamodel and governance process for defining and modeling itsready-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 ordocument. Each business object is, in turn, assigned to a process component. Process components areunits of software that cover a well-defined set of business tasks that logically belong together and areusually executed in the same department.

When the project scope includes SOA-based applications, it is recommended that you ensure in an earlystage of the project that the customer prepares for SOA readiness. Further guidance on this topic isprovided in Run >> Governance Model for Organization – Optimization >> SOA Readiness (see alsolinked nodes).

1.1.5.12 Composite Application Design and Development Standards

PurposeThe purpose of the composite application design and development standards is to set up thestandards to be followed when designing, developing, and deploying composite applications.

Sub deliverablesThis step generates:

Development process for the projecto Project development guidelineso 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 thecomponents that cause the error supposed to try to solve the problem or is the errordelegated to the caller? This architecture is closely correlated with the logging concept forpersistent data relating to problems that occur.

Documentation: How is development to be documented? For example, are various documenttemplates or metadata in the code to be used?Infrastructure list:o VC/Web Dynpro/CAF/Plain J2EE/GP/SAP Interactive Forms software by Adobeo SAP NetWeaver Portal component or other central portalo SAP NetWeaver or third-party development infrastructureo 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 earlystage of the project that the customer prepare for SOA readiness. Further guidance on this topic isprovided in Run >> Governance Model for Organization – Optimization >> SOA Readiness (see alsolinked nodes).

Development Processes

Greenfield projects are not the norm. It is therefore important to consider guidelines that are already inplace and project constraints that are determined at enterprise level or by predecessor projects. Thisensures consistency with existing projects and processes. Requirements such as those determined bythe 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. Orderinghardware, 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

PurposeThe purpose of the phase closure and sign-off deliverable is to:

Verify that deliverables from this phase are complete and accurate, and review any criticaloutstanding issues

Identify lessons learned during the phase to incorporate into the next phase or to prepare forformal project closure

When sign-off is obtained, the project can proceed to the next phase.

InputsThis deliverable has the following inputs:

Project schedule for the phase Phase-specific deliverables

This deliverable is triggered by the completion of the phase.

DeliverablesThis deliverable generates:

Lessons-learned log Project quality gate scorecard Project review service reports Phase closure document

1.1.6.1 Lessons-Learned Log Updates

PurposeIt is good project management practice to collect knowledge and lessons learned from the implementationproject for use in later stages of the project or in future projects. The project team collects and documentsthe lessons learned in the lessons-learned log that is made available to the project team and sharedwith 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

PurposeThe 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 withSolution 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 withrecommended practices and to the customer’s satisfaction

To enable project management to continuously communicate the process and build quality directlyinto 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 theproject 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)

InputsThe inputs to this deliverable are the completion of all documents, activities and WBS elements to thesatisfaction of the client as required before each Gate.

Expected resultsThe Project Quality Gate delivers a scorecard that records the results of the quality assessment of eachindividual key deliverable.

Quality gate is passed. There may be some action items in place in order to complete or improvecertain deliverables.

Quality gate is not passed. Action items are defined for follow-up by the project team. ProjectManager requests a second assessment to re-evaluate the deliverables with action items.

1.1.6.3 Project Review Service ReportPurpose

The purpose of the project review service report is to provide a proactive quality assurance review, withan impartial analysis of all aspects of the project – across all project management disciplines – enablingearly detection of project issues with actionable recommendations.

Project review service is an integral part of project quality management and provides the followingbusiness 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 investmentthroughout the implementation lifecycle. The service is composed of five logically-sequenced andinterrelated reviews performed at different phases in the implementation roadmap:

Project preparation, at the end of the phaseBusiness blueprint, at the end of the phaseRealization, during the configuration cycle, before integration testingFinal preparation, two to four weeks before going liveGo-live support, approximately four weeks after going live

Inputs

The review involves a structured approach in assessing the project implementation process. The reviewconsultant plans the on-site review using a series of scheduled interviews with key project teammembers and reviews a list of project documents specific to each project phase.

The SAP project review roadmap contains detailed information on the project management reviewservice, including templates, procedures, and guidelines.

Sub deliverables

The project review delivers:

Prescribed methodology – Provides an independent and objective management review of projectimplementation 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 includesboth OCM processes and individual change management models, which together are used to managethe people side of change.

The following figure provides all OCM deliverables for the different phases. A deliverable in one phasecan be an input for another phase (for example, stakeholder identification in the project preparationphase is input for stakeholder analysis and change impact in the business blueprint phase)

Note: OCM is one of the primary success factors in SAP projects. Implementing SAP software typicallyinvolves numerous organizational, technological, and social changes. OCM focuses on the effects thesechanges have on managers and employees. This particularly concerns new ways of thinking or behavingbut 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

ProjectPreparation

BusinessBlueprint Realization Final

PreparationGo-LiveSupport

Launch &Setup

OCM Charter

Project -Phases

Communication

OrganizationAlignment

MonitoringBusiness

ReadinessCheck

UserAcceptance

Analysis

StakeholderManagement

OCM Roadmap

StakeholderIdentification

Teambuilding

StakeholderAnalysis

Change Impact

CommunicationPlanValue

Argumentation

Role Mapping

CommunicationActivities

Sounding Panel

Road Shows

Lessons Learned


If the project scope includes SOA-based applications it is recommended that you ensure in an early stageof the project that the customer prepares for SOA readiness. Further guidance on this topic is provided inRun >> Governance Model for Organization – Optimization >> SOA Readiness (see also linked nodes).

1.2.1 Organizational Change Management Charter

PurposeThe OCM charter outlines the change team’s mission for the SAP software implementation, includinggoals, objectives, and critical success factors. This document sets the overall direction for the members ofthe change team as they plan and implement the change processes that address the human resourceand organizational aspects of the implementation. It is focused on minimizing project risk, acceleratingproject 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 theproject

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 activitieso Communication activitieso 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 forthe 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 itsfacilities?

• Who in the organization do the users report to? Who needs to approve or provide resources forrealizing 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) andhow 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 andexternal, according to their relevance (such as key players)

2. Classification of stakeholders, which classifies the stakeholders according to their positiontowards the program (pro or con) and their area of influence

3. Relationships between stakeholders, which analyzes the relationships between stakeholdersand their positions

Inputs

The inputs required for the stakeholder identification are:

Stakeholder analysis Knowledge about stakeholders by interviewing project members who are adept with the customer

situation and the customer organization

Deliverables

The major deliverables generated from stakeholder identification are:

Complete stakeholder list Stakeholder register for every stakeholder group (to be filled out completely after stakeholder

analysis

1.2.3 Organizational Change Management Roadmap

PurposeThe organizational change management (OCM) roadmap or plan presents an overview of all plannedchange management activities. It guarantees that all activities are related to each other as well as to theoverall project plan and ensures the “checkability” of OCM activities. It includes the following activitytypes:

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 thedetailed approach and plan for communication to all audiences within theproject 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 tokey 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 roadmapCommunication plan update

1.2.4 Project Team Building

PurposeTeam building activities include workshops or off-site meetings for the entire project team and otherteams, aimed at reviewing project procedures, goals, and activities and building or improving ways ofworking together towards a common goal. Team building also includes the celebration ofaccomplishments. Celebration communicates a clear message to the team and the organization and itsvalue should not be underestimated.

A good project kickoff has a teambuilding component. In the project inputsession, you have a chance to form the team by using some of the exercisesstored 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 projectteam members.

1.3 Training

Purpose

The purpose of training in the project preparation phase is to ensure that the identified project teamhas the skills and knowledge required to actively participate in the implementation from start to finish.

InputsInputs for this work stream consist of a list of project team members to be trained, along with their rolesand 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 strategythat outlines three different levels of training for the project team, as shown in the figure above. Thestrategy 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 theproject team training strategy is comprehensive

1.3.1 Project Team Training Strategy

PurposeThe project team training strategy creates a comprehensive training strategy that provides all teammembers with a phase-based learning path for acquiring the skills and knowledge needed to completethe project successfully. This learning path leads to project readiness as well as certification on thespecific applications the team members will be using.

UpdateKnowledge

SupportStrategy as

needed

Education During ASAP MethodologyRoadmap Phases

ProjectTeam

Training

Business-User

Training

OpportunityManagement

Realiza-tion

FinalPrepara-

tion

Go-LiveSupport RunBusiness

Blueprint

Educationvision

workshop(conducted todefine goals)

ProjectPrepara-

tion

KnowledgeManage-

ment

Decide onknowledgesupport forproject team

and COE

InputEducation

visionworkshop

Ensure L&Dstrategy long-terms needs

areaddressed

BusinessCase

Educationvision

workshop

Project teamtrainingstrategy

Project teamtraininglevel 1

Edu-Streams

Project-Phases

Managebusiness user

trainingstrategy

Perform routineuser experience

monitoring(UEM)

Createcontent

Undertakeusage check

to gaugeuser

adoption

Audit oftraining

readiness

Add long-term needs

toknowledge

management


Performlearning

needsanalysis

Draftlearning anddeployment

(L&D)strategy


Preparetraining

environment

Refinedelivery

mechanisms(trainers,on -

line etc.)

Trainingdelivery andmonitoring

Transferresults to

knowledgemanagement

Draftknowledge

supportstrategy

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 andresponsibilities and the SAP course curriculum. The strategy should also contain budgetary and logisticalinformation about the attendance and delivery of the training.

If It Is Not DoneIf project team training strategy is not completed, the project team members will not gain the knowledgethey need to effectively participate in the project and will not be in a position to benefit from thecertification paths.

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

1.3.2 Project Team Level 1 Skills Development

PurposeProject team level 1 skills development provides an overview of the SAP software to be implementedso that all project team members have an understanding of the SAP solution for their areas ofresponsibility. Level 1 training is the first in a series of three project team training sessions designed toequip the project team with required skills and knowledge. Together, these three sessions should alsoensure 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 eachteam member should attend. Level 1 training should focus on providing an overview of the SAP solution.

If It Is Not DoneIf project team level 1 skills development is not completed, the project team members will not receiveadequate knowledge to effectively participate in the critical realization phase of the project. This resultsin a higher total cost of ownership. In most cases, it is sound IT and business practice for companiesimplementing SAP software to cultivate knowledge to reduce the total cost of ownership and to supportthe 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 teammembers are registered.

1.3.3 Management of End-User Training

PurposeManagement of end-user training provides a blended learning path for the user that includes e-learningand 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 usersto optimize SAP implementations. Additionally, management of end-user training is designed to supportthe SAP implementation lifecycle with faster implementation and knowledge retention.

InputsThe inputs for the management of end-user training deliverable are:

Project overview and goals

End-user demographics

DeliverablesManagement of end-user training generates an analysis and report that provides guidance on bestpractices 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 beprovided on end-user education facilitating the implementation and configuration of SAP software.

Expected ResultsBy completing the management of end-user training deliverable, the project team gains a head start ondefining the education requirements for the project. By having a recommended course of action ahead oftime, the project team will be able to quickly make decisions and prepare an executable educationstrategy.

1.4 Data Management

Purpose

The purpose of the data management work stream is to support two distinct data management activitiesfor an SAP implementation: legacy data migration and data archiving. Tasks and deliverables for dataarchiving begin during the blueprint phase but planning should be started in the project preparationphase. Legacy data migration is concerned with moving data from the legacy source systems into theSAP target structures required for a successful go live. For legacy data migration, the project preparationphase is focused on the discovery, planning, and customer education for the overall migration strategyand approach. Tasks are performed to capture a preliminary assessment of the source data and to createplanning 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 informationdiscovered and captured during this phase provides preliminary input to the overall project planningeffort

1.4.1 Data Migration Workshop

Purpose

The purpose of the data migration workshop deliverable is to perform a two-day scoping workshop toexplain 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 knowledgeexchange where data migration team members share their approach and project experiences andcustomer team members share their business objectives, constraints, and concerns.

Inputs

The input to the data migration workshop is documentation from the sales cycle and opportunitymanagement phase.

DeliverablesThe data migration workshop deliverable generates the data migration workshop findings report, whichoutlines recommendations and next steps for the project.

Expected Results

By completing the data migration workshop deliverable correctly, the data migration team gains anunderstanding of the customer’s objectives and challenges in terms of migrating data. The team can thenrecommend an appropriate strategy to assess the quality of the legacy data. Customers gain anunderstanding of the complexities and challenges of data migration and how to manage the associatedrisks.

1.4.2 Data Audit

Purpose

The purpose of the data audit is to identify the legacy systems that will supply data for the SAPapplications and to profile the quality of the legacy data. Data profiling is the process of analyzing thelegacy 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 missingdata and column names that are inconsistent with content. The data audit involves working with thebusiness 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 fromthe 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 convertedinto 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 entireimplementation project. Failure to properly and thoroughly examine the data could result in work stoppageduring the testing phase if the data migration programs have to be rewritten. It could also lead tosignificant 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 thescope and effort required for the conversion to SAP. Further downstream in the project, the results of thedata audit will allow the development of extraction, transformation, and loading (ETL) jobs to correct anyinconsistencies, 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 scopeand requirements of the data migration effort. Due to the complex nature of data migrations, many of thedetails are not fully discovered during the sales cycle. The creation of this deliverable establishes thebaseline for the project team to plan future activities and manage change throughout the blueprintphase.

Inputs

The inputs to the data migration scope and requirements document are: Data audit Statement of work (SOW)

Deliverables

The deliverable for the data migration scope and requirements document establishes the scope andrequirements for the data migration effort. The discovery performed during this step is not intended toidentify all the detailed data requirements, but it sets the boundaries for the blueprint phase where furtheranalysis is performed. The document is intended to capture:

Inventory of legacy applications (location, business objects and purpose, platform, andapplication 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 projectteam captures the information needed to effectively plan and manage future data migration tasks andactivities. Change is common within data migration projects due to business decisions and data qualitydiscovery. This deliverable enables the project team to establish the foundation for managing changethroughout the future phases of the project.

1.4.4 Data Migration Approach and Strategy Document

PurposeThe purpose of the data migration approach and strategy document is to capture and communicatethe approach and strategy for the legacy data migration. This deliverable is intended to educate the SAPand customer project team members on the SAP data migration framework and methodology used tosupport the data migration project.

Inputs

The inputs to the data migration approach and strategy document are: Data audit Statement of work (SOW)

DeliverablesThe data migration approach and strategy document describes the SAP data migration framework andmethodology used to support the data migration project. The primary purpose of this deliverable is toeducate the project team to ensure that everyone understands the tools and methods being deployed todeliver the data migration solution. The document contains both static information that is common acrossprojects and customer- or project-specific information to describe how this framework applies to thecustomer’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 ResultsBy completing the data migration approach and strategy document deliverable correctly; the project teamgains a common understanding of the tools and methods being deployed as well as an understanding oftheir 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 workwith value determination, build a high-level to-be business process map, and deliver the businessscenario 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 solutiondesign on process level (PL) 1-2, which corresponds to the scenario level in the SAP SolutionManager Application management solution.

Blueprint focuses on the refinement and association of value drivers to the process hierarchiesand the solution design on process level 3-5, which corresponds to process and process steplevel in SAP Solution Manager.

During realization the solution design is finalized and built. Configuration rationales and technicalspecification capture the final design. It is recommended that you start value audits to monitorwhether 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 businessscenario level/process hierarchies level 1-2. The major deliverables are:

Value determination, pain points, process weaknesses (process flow, organizationalstructure, 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) communityWiki page, “SAP Modeling Standards”)

Business scenario description (business scenario requirements documents) – optionally thisdeliverable 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 SolutionManager 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 theywill 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 stageof the project that the customer prepares for SOA readiness. Further guidance on this topic is provided inRun >> Governance Model for Organization – Optimization >> SOA Readiness (see also linked nodes).

1.5.1 Value Determination

PurposeThe purpose of a value-based solution design is to determine value drivers and key process changes forthe 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 businessstakeholders, a pain-point analysis is done and key process changes are determined. Thus, key processchanges drive the value of the project. The value map associates pain points, key process changes, andperformance indicators to measure success. Value maps, therefore, are the central deliverable for valuedetermination. Depending on the defined scope of the implementation, value determination is executed ina “lite” version or comprehensive manner. The deliverables of the core ASAP methodology focuses onthe “lite” version.

The results from value determination are mapped to the process and solution design. A link is maintainedthrough 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-beprocess modeling as reference materials. As-is process models are not being created or updated at thispoint. Optionally, a solution transformation roadmap or landscape is being created. The solutiontransformation roadmap illustrates how the overall solution is sequenced in implementation cycles; thelandscape 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 MapPurpose

The purpose of the business process map is to derive and agree on the scope for the start of thebusiness blueprint phase. During blueprinting, the process map builds the foundation for the processhierarchy – a decomposition of the process design – which is reflected as scenarios, processes, andprocess 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 processscope. It also serves as an important point of reference for further process modeling and deep-divesessions.


For business process modeling, refer to the SAP Process Modeling Handbook on the BPX communityWiki site. As an additional reference, SAP offers the business process repository.

The following figure illustrates the process of value-based blueprinting with value deliverables (orange)and process management/technical solution design deliverables (blue).

Draft -

Value Delivery (VD) in ASAP Roadmap PhasesExecute according to value targets and track value andmanage changes during the project

VDProject

Manage-ment

VDExecution

OpportunityManagement Realization Final

PreparationGo-LiveSupport RunBusiness

Blueprint

Include valueexpert in

project org.

Integrate valuemilestones inopportunityschedule

ProjectPreparation

AdditionalVD elements

Monitor andtrack

Decide aboutVD supportafter go live

andcommunicate

InputBusinessCase or

Value Map

Executevalue-basedblueprinting

Update business case or value map in case of

BusinessCase

Decide aboutVD support

foropportunity

andcommunicate

Decide aboutVD supportfor project

andcommunicate

Create valuebased

storyline

VD-Streams

Project-Phases


project org.

Integratevalue

milestoneswith project

q-gates

Update BC/VM*in case ofchanges


project org.

Integratevalue mile-stones inproject

schedule

Value audit ofscope

Monitor and track value delivery based on BC/VM*Execute project according to BC/VM targets*

Scopeproject based

on BC/VM*

*) BC/VM: business case or value map**) BTC-service for value map creation during preparation phase

or value map derivation during additional blueprint activities

Derive VMfrom BC**

MandatoryVD activity

AdditionalVD activity

Execute value measurement and tracking service

Associa-tion of VDwith proc.

decom-position

SOA conceptual and implementation services, e.g. pulse check

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 pointsProcess 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 acomprehensive CVR has been executed, the outcome of the CVR might replace the deliverables fromthis 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 thebusiness blueprint phase. During blueprinting, the process map builds the foundation for the processhierarchy – a decomposition of the process design – which is reflected as scenarios, processes, andprocess 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 processscope. It also serves as an important point of reference for further process modeling and deep-divesessions.


For business process modeling, refer to the SAP Process Modeling Handbook on the BPX communityWiki site. As an additional reference, SAP offers the business process repository.

1.5.3 Business Scenario Design

PurposeThe purpose of business scenario design is to provide an understanding of the essential processes atthe scenario level (process level 1-2). It builds the foundation for the business blueprint phase whereprocess levels 3-5 are defined.

InputsThe 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

DeliverablesThe deliverables for the business scenario design are:

Business scenario design document, which includes:o Business requirementso Level 2 process design (value-added chain diagrams)o Level 2 solution gap analysiso Level 2 functional solution designo Value drivers and financial KPIso Level 2 organizational impact analysiso Level 2 data impact analysiso Level 2 system impact analysis

Revised project scope (if applicable) Setup of SAP Solution Manager for the implementation project and start of the document

repository (SOLAR01), as the system is available

Expected Results

For business process modeling, refer to the SAP Process Modeling Handbook on the BPX communityWiki 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 andinfrastructure deliverables that are appropriate to the initial project planning of an SAP implementationproject. 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 theblueprint phase and is related to legacy data migration and data archiving. The concepts in that area havea direct effect on the design and setup of the technical system landscape.

1.6.1 Interface Inventory

PurposeThe purpose of the interface inventory is to identify the external systems, applications, and businessobjects or transactions that must be integrated with the SAP application after go live.

InputsThe input to the interface inventory is the statement of work (SOW).

DeliverablesThe 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 externalsystems and transactions to be integrated with the SAP application after go live. The document shouldcapture the following information:

Inventory of legacy applications (location, business objects and purpose, platform, andapplication 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 ResultsBy completing the interface inventory deliverable correctly, the project team captures the informationneeded to effectively plan and manage future integration tasks and activities.

1.6.2 Technical Requirements and Design and Solution Landscape DeploymentPlan

Purpose

The purpose of the technical requirements and design deliverable is to define and document technicalrequirements for the project and its eventual rollout and to create an initial technical design. The technicalrequirements 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 theintegration 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 – forexample, global versus local infrastructure. The initial technical design also includes the solutionlandscape, which is a description of all the technical systems in diagrammatic and textual form. It showsthe hardware, software, and connectivity between all components. It also describes the role of eachcomponent or system.

Inputs

The stakeholders and experts within IT who focus on infrastructure and architecture must be identified toget 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 ofthe 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 textand determining when they are to be deployed

Documentation of the interfaces between all components in the solution landscape, including theconnectivity between non-SAP components and the new landscape

Documentation of all required tools for implementation and operation and required licenses forthose 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 withoutyour defining and documenting all aspects of technical design. Technical scope, timeline, and budgetcannot be controlled if they are not clearly defined; without them, serious problems can result, with anegative impact on the project.

Additional InformationIt is critical to have a clear analysis of the current solution landscape before defining any technicalrequirements. A careful examination of the existing infrastructure, the business processes it supports, andintegration 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 beused during evaluation, implementation, and operational processing of the planned solution. Specificationof 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 andoptimize the performance and availability of your system landscapes and to minimize risks whenrunning your systems

Service desk – Solution support with workflow to create and processproblem messages

Change management – With workflow to trace and audit changes andtransports in your system landscape

Sizing and configuration of SAP Solution Manager – see the SAPService 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 withassistance from your hardware partner.

The following procedures are required:

Do initial hardware sizing separately for each system, such as the development system, thequality assurance system, and the production system

Size other systems separately, such as template systems in a global environment, theadministration 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 severalweeks or even months before the corresponding project phase, as the delivery time for the hardwaremust be considered in the project plan.

The first step is to determine the hardware requirements of your SAP software system, including networkbandwidth, physical memory, CPU power, and I/O capacity. The second step (done with the hardwarepartner) is to map these hardware requirements to specific hardware.

Inputs

The inputs for the hardware sizing are:

http://help.sap.com/saphelp_sm40/helpdata/en/9f/a402138513490dac0ca08fab4aec72/frameset.htm

http://help.sap.com/saphelp_sm40/helpdata/en/c7/6b1ec041ae44e28df020b232cb5fb4/frameset.htm

http://help.sap.com/saphelp_sm40/helpdata/en/5b/0c9ccfd262427685c245d7ea85cd7a/frameset.htm

http://help.sap.com/saphelp_sm40/helpdata/en/9a/e435e7fa6f4e85a70885a36479be4e/frameset.htm

http://help.sap.com/saphelp_sm40/helpdata/en/46/400281765451ebe10000000a114a6b/frameset.htm

http://help.sap.com/saphelp_sm40/helpdata/en/ff/6ea7a870ac469ea54cedd12666cc5d/frameset.htm

http://help.sap.com/saphelp_sm40/helpdata/en/ff/6ea7a870ac469ea54cedd12666cc5d/frameset.htm

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 calculatedresources as input to determine appropriate hardware.

For the initial hardware sizing during the preparation phase, you might not yet have all of the requiredinput. Nevertheless, a first rough estimate of hardware requirements is necessary for setting up thedevelopment 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 incollaboration with your hardware partner.

If It Is Not Done

If the initial hardware sizing is not completed correctly, the project might suffer from insufficient hardwareresources during the preparation and blueprint phases. Other infrastructure planning steps (such as datacenter capacity and backup planning) might lead to wrong decisions if the initial hardware sizing isskipped.


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

User-based sizing – This model defines three types of active users who work with the system todifferent degrees. Merely counting the users can be done quite easily. The disadvantage is thatthis 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 onactually 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 theindividual 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. Forfurther 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 BestPractices guide.

With the help of standard application benchmark results at www.sap.com/benchmark, assumptions canbe made about CPU and memory consumption of particular software components as well as a mappingof “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 projectenvironment 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 authorizationso 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 cannotwork efficiently. Without this deliverable, it will be difficult for the project team to hand over its work in thedefined form and tools.


The SAP Solution Manager is SAP’s central solution operations platform and contains a lot of thesoftware tools and components needed for technical infrastructure requirements and design. Besides thebasic scenarios for service delivery and issue management that are used in later operational phases, the

https://websmp110.sap-ag.de/~sapidb/011000358700002408881998E

http://service.sap.com/sizing

project can benefit from the SAP Solution Manager during the early project phases as well. Do this byusing the basic business blueprint and configuration function to generate business blueprintdocuments and configuration guides for your solution. In this way SAP Solution Manager can be becomethe 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, projectdocumentation)

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 testingdeliverables, processes, and procedures appropriate to an SAP implementation project. This work streamorganizes testing of individual processes, process steps, and scenarios to prepare for the move to aproductive SAP solution.

Inputs

The inputs to integrated solution management are:

Project scope Project schedule Business requirements Functional requirements

http://help.sap.com/saphelp_sm40/helpdata/en/6a/bf1603d4f0944c81366cef7427bd12/frameset.htm

http://help.sap.com/saphelp_sm40/helpdata/en/9a/90b441b60e3331e10000000a155106/frameset.htm

Deliverables

This work stream generates the testing assessment.

1.7.1 Testing Assessment

PurposeThe 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 thecustomer’s as-is skill at conducting tests of enterprise systems. As the test strategy and approach iscompleted during the business blueprint phase, the test assessment will highlight the work needed tobring 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 automatedo Testing tool seto Requirements traceability tool seto Test data management functionalityo Test executiono Test resourceso Defect managemento Test coordinationo Test reporting and analysiso 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 timeo Within scopeo Within budget

Establish a testing center of excellence

Project on ASAP Implementation of Reliance Global Service

Documents

Transcript of Project on ASAP Implementation of Reliance Global Service