Project-Plan en 18Q3-Activity and Task-Level

ID Active Task Mode Name
1 Yes Auto Scheduled S/4HANA Sample Project

1
Yes Auto Scheduled Discover

1.1
Yes Auto Scheduled Strategic Planning

1.1.1
Yes Auto Scheduled Create an Innovation Strat

1.1.2
Yes Auto Scheduled Accelerate Your Innovation

1.1.3
Yes Auto Scheduled Create a 360-Degree View

1.1.4
Yes Auto Scheduled Define the Analytics Archit

1.2
Yes Auto Scheduled Application Value and Scop

1.2.1
Yes Auto Scheduled Discover the Value of SAP

1.2.2
Yes Auto Scheduled Identify the impact of SAP

1.2.3
Yes Auto Scheduled Check the Conversion Read

1.2.4
Yes Auto Scheduled Perform a Business Scenar

1.2.5
Yes Auto Scheduled Define the Implementation

1.2.6
Yes Auto Scheduled Create a Strategic Road Ma

1.3
Yes Auto Scheduled Trial System Provisioning

1.3.1
Yes Auto Scheduled Provide a Trial System

2
Yes Auto Scheduled Prepare

2.1
Yes Auto Scheduled Project Team Enablement

2.1.1
Yes Auto Scheduled Conduct Agile Training for
2.1.2
Yes Auto Scheduled Conduct SAP Solution Mana

2.1.3
Yes Auto Scheduled Perform Mobilization Traini

2.1.4
Yes Auto Scheduled Conduct Project Team Enabl

2.1.5Yes Auto Scheduled Conduct Key User Training
2.2
Yes Auto Scheduled Prototype

2.2.1
Yes Auto Scheduled Run Prototyping

2.3
Yes Auto Scheduled Transition Planning

2.3.1
Yes Auto Scheduled Check the Conversion Read

2.3.2
Yes Auto Scheduled SAP S/4HANA Transition Pro

2.3.3
Yes Auto Scheduled Define Cutover Approach

2.3.4
Yes Auto Scheduled Clarify Custom Code Adapt

2.3.5
Yes Auto Scheduled Clarify Operational Readin

2.3.6
Yes Auto Scheduled Define Technical Architectu

2.3.7
Yes Auto Scheduled Define the Data Migration

2.3.8
Yes Auto Scheduled Prepare Interface Register

2.3.9
Yes Auto Scheduled Run a Legacy Impact Analys

2.3.1
Yes Auto Scheduled Run a first Assessment o

2.3.1
Yes Auto Scheduled Run a first Assessment on

2.3.1
Yes Auto Scheduled Optional: Run a Technical S

2.4
Yes Auto Scheduled Transition Preparation

2.4.1
Yes Auto Scheduled Execute on Follow-Ups from

2.5
Yes Auto Scheduled Custom Code Cleanup and

2.5.1
Yes Auto Scheduled Cleanup Unused Code (Opti

2.5.2
Yes Auto Scheduled Improve Custom Code Quali

2.6
Yes Auto Scheduled Project Delivery Platform S

2.6.1
Yes Auto Scheduled Set up and configure SAP

2.6.2
Yes Auto Scheduled Import the Best Practices

2.7
Yes Auto Scheduled Project Initiation

2.7.1
Yes Auto Scheduled Conduct Handover Meeting

2.7.2
Yes Auto Scheduled Review Order Form with C

2.7.3
Yes Auto Scheduled Identify Stakeholders, Sta

2.7.4
Yes Auto Scheduled Set Stakeholder Expectation

2.7.5
Yes Auto Scheduled Create Project Charter

2.7.6
Yes Auto Scheduled Create Project Managemen

2.8
Yes Auto Scheduled Establish Project Governan

2.8.1
Yes Auto Scheduled Define Roles and Responsibi

2.8.2Yes Auto Scheduled Define Project Organizatio
2.8.3
Yes Auto Scheduled Review Project Managemen
2.9
Yes Auto Scheduled Plan Project
2.9.1
Yes Auto Scheduled Create Scope Statement

2.9.2
Yes Auto Scheduled Create WBS

2.9.3
Yes Auto Scheduled Create Project Schedule

2.9.4
Yes Auto Scheduled Create Budget

2.9.5
Yes Auto Scheduled Plan Quality
2.9.6
Yes Auto Scheduled Plan Communications
2.9.7
Yes Auto Scheduled Plan Risks

2.9.8
Yes Auto Scheduled Plan Procurement

2.9.9
Yes Auto Scheduled Plan Stakeholders Manage
2.10
Yes Auto Scheduled Project Kick-Off and On-Bo

2.10.
Yes Auto Scheduled Prepare for Kick-off Meetin
2.10.
Yes Auto Scheduled Conduct Kick-off Meeting

2.10.
Yes Auto Scheduled Prepare Team On-boardin
2.10.
Yes Auto Scheduled On-board Project Team

2.11
Yes Auto Scheduled Project Standards and Infra

2.11.
Yes Auto Scheduled Define Project Standards

2.11.
Yes Auto Scheduled Determine Operational Sta

2.11.
Yes Auto Scheduled Define and Set Up Agile Pr

2.11.
Yes Auto Scheduled Check Availability of SAP

2.11.
Yes Auto Scheduled Set up Project Team Logisti

2.11.
Yes Auto Scheduled Setup and Test Remote Sup

2.12
Yes Auto Scheduled Execution, Monitoring, and

2.12.
Yes Auto Scheduled Direct and Manage Project
2.12.
Yes Auto Scheduled Monitor and Control Project
2.12.
Yes Auto Scheduled Manage Issues, Risks and
2.12.
Yes Auto Scheduled Communicate Status and Pro
2.13
Yes Auto Scheduled Organizational Change M

2.13.
Yes Auto Scheduled Prepare Organizational
2.13.
Yes Auto Scheduled Conduct OCM Workshop wit

2.14
Yes Auto Scheduled Phase Closure and Sign-Off

2.14.
Yes Auto Scheduled Conduct Knowledge Manag

2.14.
Yes Auto Scheduled Conduct Project Quality Ga

2.14.
Yes Auto Scheduled Conduct Project Manageme

2.14.Yes Auto Scheduled Obtain Customer Sign-Off
3
Yes Auto Scheduled Explore

3.1 Yes Auto Scheduled Phase Initiation
3.1.1Yes Auto Scheduled Review Deliverables of Exp
3.1.2Yes Auto Scheduled Review Acceptance Criteria
3.1.3Yes Auto Scheduled Review RACI Chart for Expl
3.2
Yes Auto Scheduled Learning Design

3.2.1
Yes Auto Scheduled Develop a Training Concept

3.3
Yes Auto Scheduled Activate Solution

3.3.1
Yes Auto Scheduled Finalize Mandatory System

3.3.2
Yes Auto Scheduled Reconfirmation of Scope fo

3.3.3
Yes Auto Scheduled Activation of Best Practic

3.4
Yes Auto Scheduled Fit-Gap / Delta Design: Int

3.5
Yes Auto Scheduled Fit-Gap / Delta Design: Fin

3.5.1
Yes Auto Scheduled Prepare sample data

3.5.2
Yes Auto Scheduled Enhance system setup with

3.6
Yes Auto Scheduled Fit-Gap / Delta Design: Fit/

3.6.1
Yes Auto Scheduled Run Fit Gap Workshops

3.7
Yes Auto Scheduled Fit-Gap / Delta Design: Gap

3.7.1
Yes Auto Scheduled GAP Documentation / Speci

3.8
Yes Auto Scheduled Fit-Gap / Delta Design: Delt

3.8.1
Yes Auto Scheduled Prioritize Delta Scope

3.9
Yes Auto Scheduled GAP Validation

3.9.1
Yes Auto Scheduled Validate Gaps

3.10
Yes Auto Scheduled Fit-Gap / Delta Design: Del

3.10.
Yes Auto Scheduled Finalize Delta Design

3.11
Yes Auto Scheduled Design Review

3.11.
Yes Auto Scheduled Perform Design Review

3.12
Yes Auto Scheduled Fit-Gap / Delta Design: Ver
3.12.
Yes Auto Scheduled Perform Validation and App

3.13
Yes Auto Scheduled UX Activation and Design

3.13.
Yes Auto Scheduled UX Activation

3.13.
Yes Auto Scheduled UX Design

3.14
Yes Auto Scheduled Fit-Gap / Delta Design- Cen

3.14.
Yes Auto Scheduled Run Central Finance Design

3.15
Yes Auto Scheduled Data Volume Planning

3.15.
Yes Auto Scheduled Perform Data Volume Plan

3.16
Yes Auto Scheduled Data Volume Design

3.16.
Yes Auto Scheduled Get Transparency on the

3.16.
Yes Auto Scheduled Optional: Set Up a DVM St

3.16.
Yes Auto Scheduled Get Transparency on Open

3.16.
Yes Auto Scheduled Adapt Data Aging in your

3.17
Yes Auto Scheduled Security Design

3.17.
Yes Auto Scheduled Define Security Infrastruct

3.18
Yes Auto Scheduled Analytics Design

3.18.
Yes Auto Scheduled Design the Analytics Archit

3.19
Yes Auto Scheduled Custom Code Impact Analys

3.19.
Yes Auto Scheduled Empowering on Custom Co

3.19.
Yes Auto Scheduled Create a Custom Code Work

3.20
Yes Auto Scheduled Test Planning

3.20.
Yes Auto Scheduled Make yourself Familiar wi

3.20.
Yes Auto Scheduled Test Scope Determination

3.20.
Yes Auto Scheduled Detailed Test Planning

3.21
Yes Auto Scheduled Integration Setup

3.21.
Yes Auto Scheduled Setup B2B Integration

3.21.
Yes Auto Scheduled Setup A2A Integration (On

3.21.
Yes Auto Scheduled Setup Solution Manager Int

3.21.
Yes Auto Scheduled Setup Output Managemen

3.21.
Yes Auto Scheduled Setup User Interface (UI) I

3.21.
Yes Auto Scheduled Setup Internet of Things (Io

3.21.
Yes Auto Scheduled Setup Integration to Mobile

3.22
Yes Auto Scheduled Integration Design

3.22.
Yes Auto Scheduled Define Interface Architectu

3.22.
Yes Auto Scheduled Prepare Integration Design

3.23
Yes Auto Scheduled Project Delivery Platform S

3.23.
Yes Auto Scheduled Set up Landscape Transform

3.23.
Yes Auto Scheduled Set up Data Migration Servi

3.24
Yes Auto Scheduled Sandbox System Setup

3.24.
Yes Auto Scheduled Set Up SANDBOX (System Co

3.24.
Yes Auto Scheduled Downtime Optimization Pre

3.24.
Yes Auto Scheduled Set Up SANDBOX (New Instal

3.25
Yes Auto Scheduled Data Migration Design

3.25.
Yes Auto Scheduled Prepare and Conduct Data

3.25.
Yes Auto Scheduled Data Audit

3.25.
Yes Auto Scheduled Prepare and Present Data

3.25.
Yes Auto Scheduled Data Migration Approach

3.25.
Yes Auto Scheduled Test Data Management

3.25.
Yes Auto Scheduled Define Specifications for D

3.25.
Yes Auto Scheduled Run a Landscape Transforma

3.26
Yes Auto Scheduled DEV Setup

3.26.
Yes Auto Scheduled DEV Setup (New Implement

3.26.
Yes Auto Scheduled DEV Setup (System Convers

3.27
Yes Auto Scheduled Sizing

3.27.
Yes Auto Scheduled Perform / Check Sizing

3.28
Yes Auto Scheduled Technical Architecture Defi

3.28.
Yes Auto Scheduled Discover Technical Boundar

3.28.
Yes Auto Scheduled Create Technical Solution

3.29
Yes Auto Scheduled IT Infrastructure Definition

3.29.
Yes Auto Scheduled Decide on Integration with

3.29.
Yes Auto Scheduled Hardware Selection and Uti

3.29.
Yes Auto Scheduled Develop Virtualization Stra

3.29.
Yes Auto Scheduled Design Network

3.29.
Yes Auto Scheduled Test Preparation

3.30
Yes Auto Scheduled Technical Design

3.30.
Yes Auto Scheduled Create a Technical Soluti

3.31
Yes Auto Scheduled Operations Impact Evaluat

3.31.
Yes Auto Scheduled Operations Impact Evaluat

3.32
Yes Auto Scheduled Execution / Monitoring / Co

3.32.
Yes Auto Scheduled Update Project Managemen
3.32.
3.32.
Yes Auto Scheduled Conduct SCRUM Meetings

3.32.
3.32.
3.32.
3.33
Yes Auto Scheduled Release and Sprint Plan

3.33.
Yes Auto Scheduled Update and Prioritize Back

3.33.
Yes Auto Scheduled Estimate Backlog Items Effo

3.33.
Yes Auto Scheduled Conduct Release and Sprin

3.33.
Yes Auto Scheduled Validate Release and Sprin

3.34
Yes Auto Scheduled Change Impact Analysis

3.34.
Yes Auto Scheduled Validate Organizational Al
3.34.
Yes Auto Scheduled Establish Baseline of Curre
3.35

3.35.

3.35.

3.35.
Yes Auto Scheduled Execute Baseline Retrospec

3.35.

3.35.
Yes Auto Scheduled Manage Fulfilled Contracts
4
Yes Auto Scheduled Realize

4.1.1Yes Auto Scheduled Review Deliverables of Rea
4.1.2Yes Auto Scheduled Review Acceptance Criteria
4.1.3
Yes Auto Scheduled Review RACI Chart for Real

4.2
Yes Auto Scheduled Plan Realize Phase
4.2.1Yes Auto Scheduled Plan Sprints and Solution
4.2.2
Yes Auto Scheduled Plan Testing

4.3
Yes Auto Scheduled Learning Realization

4.3.1
Yes Auto Scheduled Create Training Material fo

4.3.2
Yes Auto Scheduled Train your Key User

4.4 Yes Auto Scheduled Sprint Initiation (Iterative)
4.4.1
Yes Auto Scheduled Conduct Sprint Planning Mee

4.5
Yes Auto Scheduled Execution Plan for Realize

4.5.1Yes Auto Scheduled Manage Sprints
4.5.2
Yes Auto Scheduled Manage Unit/String Tests
4.5.3
Yes Auto Scheduled Manage Integration Test
4.5.4
Yes Auto Scheduled Manage Security Test
4.5.5
Yes Auto Scheduled Manage User Acceptance T
4.6
Yes Auto Scheduled Configuration: Introduction

4.7
Yes Auto Scheduled Configuration: Handover

4.7.1
Yes Auto Scheduled Run Handover Session

4.8
Yes Auto Scheduled Configuration: Main Config

4.8.1
Yes Auto Scheduled Perform Main Configuratio

4.9
Yes Auto Scheduled Configuration: Unit Test
4.9.1
Yes Auto Scheduled Run Unit Test

4.10
Yes Auto Scheduled Configuration: String Test

4.10.
Yes Auto Scheduled Run String Test

4.11
Yes Auto Scheduled Configuration: Solution Wa

4.11.
Yes Auto Scheduled Run Solution Walk-Through

4.12
Yes Auto Scheduled Configuration: Bug Fixing

4.12.
Yes Auto Scheduled Resolve Identified Issues

4.13
Yes Auto Scheduled Configuration: Documentat

4.13.
Yes Auto Scheduled Document Configured Set

4.14
Yes Auto Scheduled Configuration- Central Fin

4.15
Yes Auto Scheduled Product Enhancements

4.15.
Yes Auto Scheduled Adjust Affected Existing C

4.15.
Yes Auto Scheduled Development of WRICEF ob

4.15.
Yes Auto Scheduled Enhancement and developmen

4.15.
Yes Auto Scheduled Custom Development

4.16
Yes Auto Scheduled Sprint Closing

4.16.
Yes Auto Scheduled Conduct Sprint Review Mee

4.16.
Yes Auto Scheduled Signoff Sprint Results

4.16.
Yes Auto Scheduled Conduct Sprint Retrospecti

4.17
Yes Auto Scheduled Cleanup / Archive

4.17.
Yes Auto Scheduled Cleanup or Archive Data

4.18
Yes Auto Scheduled Data Aging Configuration

4.18.
Yes Auto Scheduled Configure Data Aging (Desi

4.18.
Yes Auto Scheduled Test execution of Data Agi

4.19
Yes Auto Scheduled Security Implementation

4.20
Yes Auto Scheduled Integration Validation

4.20.
Yes Auto Scheduled Identify the IV Scope

4.20.
Yes Auto Scheduled Initiate the Corresponding

4.20.
Yes Auto Scheduled Initiate SAP Going-Live Che

4.21
Yes Auto Scheduled Analytics Configuration

4.21.
Yes Auto Scheduled Configure Analytics and Di

4.21.
Yes Auto Scheduled Knowledge Transfer

4.22
Yes Auto Scheduled Test Preparation

4.22.
Yes Auto Scheduled Prepare Tests

4.23
Yes Auto Scheduled Test Execution

4.23.
Yes Auto Scheduled Perform Integration / Regr

4.24
Yes Auto Scheduled Integration Implementatio

4.24.
Yes Auto Scheduled Implement Integration Des

4.24.
Yes Auto Scheduled Validate Integration Imple

4.25
Yes Auto Scheduled QAS Setup

4.25.
Yes Auto Scheduled QAS Setup (New Implement

4.25.
Yes Auto Scheduled QAS Setup (System Convers

4.26
Yes Auto Scheduled Data Migration and Verifica

4.26.
Yes Auto Scheduled Legacy Data Migration (Ne

4.26.
Yes Auto Scheduled Perform Load and Verificat

4.26.
Yes Auto Scheduled Perform Client Transfer (LT

4.26.
Yes Auto Scheduled Perform System Merge (LT

4.26.
Yes Auto Scheduled Perform Company Code Tran

4.27
Yes Auto Scheduled Cutover Preparation

4.27.
Yes Auto Scheduled Production System Setup

4.27.
Yes Auto Scheduled Create Cutover Plan (New

4.27.
Yes Auto Scheduled Create Cutover Plan (Syste

4.27.
Yes Auto Scheduled Create Cutover Plan (Lands

4.28
Yes Auto Scheduled Sizing and Scalability Verifi

4.28.
Yes Auto Scheduled Optional: Perform Sizing Ve

4.28.
Yes Auto Scheduled Optional: Perform Scalabilit

4.29
Yes Auto Scheduled IT Infrastructure Setup and

4.29.
Yes Auto Scheduled Set Up IT Infrastructure

4.29.
Yes Auto Scheduled Test IT Infrastructure

4.30
Yes Auto Scheduled Operations Implementatio

4.30.
Yes Auto Scheduled Collect detailed Operation

4.30.
Yes Auto Scheduled Roles and Responsibilities

4.30.
Yes Auto Scheduled Support Processes and Pro

4.30.
Yes Auto Scheduled Operations Support Tools

4.30.
Yes Auto Scheduled Operations Documentation

4.30.
Yes Auto Scheduled Knowledge Transfer

4.31
Yes Auto Scheduled Execution, Monitoring and

4.31.

4.31.
Yes Auto Scheduled Update Project Manageme

4.31.
Yes Auto Scheduled Manage Project Issues, Ris

4.31.
Yes Auto Scheduled Communicate Project Statu

4.31.
Yes Auto Scheduled Plan and Execute Agile Spri

4.31.
Yes Auto Scheduled Perform Scrum-Of-Scrums M

4.32 Yes Auto Scheduled OCM Alignment activities
4.32.
Yes Auto Scheduled OCM and Testing alignmen

4.32.
Yes Auto Scheduled OCM and Data Migration a

4.33

4.33.

4.33.

4.33.
Yes Auto Scheduled Execute Baseline Retrospec

4.33.

4.33.
Yes Auto Scheduled Manage Fulfilled Contracts
5
Yes Auto Scheduled Deploy

5.1.1Yes Auto Scheduled Allocate Resources and Up
5.1.2
Yes Auto Scheduled Perform Kick-off Meeting

5.2
Yes Auto Scheduled Learning Realization

5.2.1
Yes Auto Scheduled Create Training Execution P

5.2.2
Yes Auto Scheduled Execute End User Training

5.3
Yes Auto Scheduled Integration Validation

5.3.1
Yes Auto Scheduled Finalize Integration Validat

5.4
Yes Auto Scheduled Dress Rehearsal

5.4.1
Yes Auto Scheduled Perform Cut-Over Rehearsa

5.5
Yes Auto Scheduled IT Infrastructure Service Fi

5.5.1
Yes Auto Scheduled Finalize IT Infrastructure S

5.6
Yes Auto Scheduled Operations Readiness

5.6.1
Yes Auto Scheduled Operational Readiness (Sy

5.6.2
Yes Auto Scheduled Operational Readiness (Ne

5.7
Yes Auto Scheduled Execution, Monitoring and

5.7.1
Yes Auto Scheduled Update Project Managemen
5.7.2
5.7.3
5.7.4
5.7.5

5.7.6
5.8
Yes Auto Scheduled Release Closing
5.8.1
Yes Auto Scheduled Prepare Product Backlog fo

5.8.2
Yes Auto Scheduled Conduct Release Retrospec

5.8.3
Yes Auto Scheduled Update the Release and Spr

5.9
Yes Auto Scheduled Production Cutover

5.9.1
Yes Auto Scheduled Convert Productive System

5.9.2
Yes Auto Scheduled Production Cutover (New I

5.9.3
Yes Auto Scheduled Production Cutover (Lands

5.10
Yes Auto Scheduled Hyper Care Support

5.10.
Yes Auto Scheduled Monitor Resource Consump

5.10.
Yes Auto Scheduled Analyze Workload

5.10.
Yes Auto Scheduled Check System Scalability

5.10.
Yes Auto Scheduled Follow-up on Going-Live Ser

5.11
Yes Auto Scheduled Post Go-Live End User Trai
5.11.Yes Auto Scheduled Prepare End-User Training
5.11.
Yes Auto Scheduled Deliver End-User Training
5.11.
Yes Auto Scheduled Collect Training Evaluation
5.11.
Yes Auto Scheduled Perform People Readiness
5.12
Yes Auto Scheduled Handover to Support Organ

5.12.
Yes Auto Scheduled Resolve and Close Open Is

5.12.
Yes Auto Scheduled Handover Operations Respo

5.13
Yes Auto Scheduled Project Closure and Sign-Of

5.13.

5.13.

5.13.
Yes Auto Scheduled Manage fulfilled Contracts
5.13.
Yes Auto Scheduled Resolve and close open Iss
5.13.
Yes Auto Scheduled Finalize Project Closeout R
5.13.
Yes Auto Scheduled Obtain Sign-off for Project
6
Yes Auto Scheduled Run

6.1
Yes Auto Scheduled Operate Solution

6.1.1
Yes Auto Scheduled Safely and Efficiently Oper

6.1.2
Yes Auto Scheduled Continuously Optimize IT O

6.2
Yes Auto Scheduled Improve and Innovate Solu

6.2.1
Yes Auto Scheduled Periodically Update your S

6.2.2
Yes Auto Scheduled Initiate a new Innovation C

Description
In the Discover phase, customers become familiar with the benefits of SAP HANA and SAP S/4HANA, and
the benefits it can bring to customers’ business. As depicted in the picture below, the phase
is structured as follows: In a first step customers should create an overall company strategy on their
digital transformation. This includes SAP S/4HANA as the digital core, but looks from a broader perspective.
Key topics like Internet of Things , Big Data / Smart Data , Omnichannel, or Business Networks can be
included into the strategy as well. In a next step customers should become familiar with the value of SAP
S/4HANA in general (e.g. the new and simplified functionality in SAP S/4HANA, the new User Interface
based on FIORI, agile customer innovations using SAP Cloud Platform etc.). A trial system in the cloud could
support this. In the third step, a decision on the implementation scenario, and a comprehensive
implementation strategy for SAP S/4HANA should be created. In case of system conversion, the conversion
readiness of the existing SAP ERP system should be checked as well. A Learning Needs Analysis for the
project team should be performed as well. Figure: Activities in the Discover phase The outcome of these
steps can be leveraged within a company to build a business case for an SAP S/4HANA implementation
project. To prepare this phase, customers should take use of the valuable information sources on SAP
S/4HANA listed in the accelerators section: The SAP S/4HANA Flipbook at SAP.com lists general
information on SAP S/4HANA – ideal for customers who are not familiar with SAP S/4HANA. The SAP
S/4HANA Journeymap is on the same level, and lists five simple steps to drive quick time-to-value. There
is a vibrant community on SAP S/4HANA at the SAP Community Network. Customers who are interested in
SAP Fiori should visit the SAP User Experience (Fiori) Community. The Innovation Discovery Finder is a
tool that helps customers to identify new and improved functionality for SAP S/4HANA based on selection
criteria such as Industry, or Solution Area. There is also good information available in the print media,
for instance "Migrating to SAP S/4HANA" by Frank Densborn. Customers and partners,
who want to build de-coupled extensions for SAP S/4HANA using the SAP Cloud Platform find very helpful
information at SCN (see "Extensibility if SAP S/4HANA" in the accelerator section).
Regarding SAP S/4HANA releases: SAP plans to ship a new release of SAP S/4HANA on premise once per
year. In between, innovations are shipped via feature packs. Information (like the “Simplification
List” explained later in the road map) is often release or feature pack dependent. This is the reason
why the SAP Online Help portal for SAP S/4HANA is structured according to the feature pack level (actually
0, 1, and 2). You will need to decide on the correct release level of your to-be SAP S/4HANA solution, and
select the appropriate release dependent information accordingly. This road map usually links to the most
current version of release dependent documents (at the time of writing). To learn about the current SAP
S/4HANA release, it is also recommended to look at the central release information note of SAP S/4HANA
covering all feature packs of a certain release, and the release restriction note. Both are given for SAP
S/4HANA 1709 FPS02 in the accelerator section. To learn about SAP’s future plans on SAP S/4HANA,
please look at the product road map for SAP S/4HANA (accelerator section), which you will find at sap.com
under “Cross Topics”> “Cross Products”.
Due to changing business models customers are in need of developing a digital transformation strategy.
The digital transformation strategy should cover the whole SAP IT environment as displayed on the
following picture. The enterprise software like ERP or CRM to the left is the stable core (referenced as
“mode 1”) whereas the innovate part like SAP Cloud Platform is displayed to the right
(referenced as “mode 2”). Figure: SAP products grouped in “Mode 1” and
“Mode 2” Industry trends and Best Practices need to be analyzed in the context of
customer’s business area. The aim is to define a comprehensive innovation strategy and road map
based on new or enhanced business capabilities. Once the innovation strategy has been defined a target
enterprise architecture for processes, data, application and integration needs to be developed to support
the strategic needs. The road map may include but is not limited to SAP S/4HANA. Requirements and
Constraints This activity is not scenario specific. This activity does not have any requirements or constraints,
and can run any time. However it is recommended to run this activity upfront of an SAP S/4HANA
implementation project. Procedure The procedure depends on the level of detail innovation options should
be created and evaluated upfront. The task “Create an Innovation Strategy and a High-Level Road
Map” describes a straight-forward way to document a company specific innovation strategy and
road map within a short period of time. A jump start towards innovation is described in task
“Accelerate Your Innovations with the help of the SAP Leonardo Innovation Services. This brand-new
approach supports customers in executing a first innovation cycle within a few. Strategic planning is an
ideal point in time to also re-think your security strategy, because the transformation project in
combination with innovations may significantly change your security requirements. The task “Create
a 360-Degree View on Security” is a first step towards creation transparency on future security
needs. The task “Define the Analytics Architecture” clarifies how SAP S/4HANA fits best
into the analytics strategy of the customer. Results As a result, there is a high-level multi-year road map
which describes the main change activities (including business driver), and sequences them on a time-line.
The objective of this task is to create a company specific innovation strategy, and to derive a high-level
multi-year road map from there. Procedure To come to an innovation strategy, SAP Best Practice is to start
with an identification of strategic business and IT objectives, including current pain areas. Those objectives
need to be clustered to “benefit areas”. For each benefit area, enablers (like SAP S/4HANA,
but also other solution or platform components) need to be identified, prioritized, and benchmarked with
respect to the industry reference architecture. The target enterprise architecture (business / application,
and IT) can be derived in a next step. You will need to clarify questions like How many SAP S/4HANA
systems are ideal for the to-be business scenarios? Is Co-Deployment preferred, or should I deploy
standalone? What about IT-Security Requirements? The strategic road map finally documents the main
transition steps from as-is to the to-be architecture, by clarifying: System Conversion, or New
Implementation? One-step conversion, or transformation via multiple steps? Sequence of co-
deployment? The following picture gives an example of a high-level implementation road map. The
illustrative picture is structured into three phases (2018, 2020, and beyond), and shows individual projects
structured per business area (e.g. Financials). Figure: Example of a multi-year road map (high-level)
Results As a result, there is a high-level multi-year road map which describes the main change activities
(including business driver), and sequences them on a time line. How SAP Can Support SAP supports the
initial creation of a digital transformation road map with a set of newly created or enhanced tools:
The SAP Innovation and Optimization Pathfinder is a free of charge tool from SAP, which– based on
your current system usage statistics - answers questions like: "Of all the innovations from SAP
– SAP Fiori apps, SAP Business Suite enhancements, SAP S/4HANA scenarios or Cloud extensions
– which ones are the most relevant for your business?" Figure: Entry screen of the
SAP Innovation and Optimization Pathfinder SAP S/4HANA on premise is one innovation option out of
many which is analyzed by this tool. The SAP Enterprise Architecture Explorer focuses on specific
IT areas such as user experience, landscape architecture or Internet of Things and provides valuable
insights for enterprise architects and others interested in driving IT decisions and improving their
enterprise. Figure: Entry screen of the SAP Enterprise Architecture Explorer The SAP
Transformation Navigator is a new self-service tool. Starting from your current product map, and your
current and planned business capabilities, the SAP Transformation Navigator determines a high-level future
product map which lists the strategic SAP go-to products and solutions including details on the
transformation scenarios. The tool lists the value drivers influenced by the SAP products which can help
you with the business case. The results are compiled in three documents with different focus on business,
IT, and transformation. Figure: Entry screen of the SAP Transformation Navigator The SAP
Transformation Navigator should be the first preparatory step for the creation of your digital transformation
road map. Please see accelerator section on how to access the tools listed above. SAP has documented
aspects and decision criteria which should be clarified as part of an innovation strategy and road map. The
Best-Practice Document "Elements for Designing a Transition Roadmap to SAP S/4HANA" is
available for all customers (see accelerator section). In addition, SAP offers an "Innovation Strategy
and
MostRoadmap" servicestrategy
likely your innovation component, where
created SAPhas
before canidentified
bring in the
the development
need to furtherroad map, industry
evaluate the valueBest
of
advanced digital technology (e.g. the use of IoT (Internet of Things) in your industry area). This task
describes how the “SAP Leonardo Innovation Services” can help you speeding up your
innovation. Requirements and Constraints This task is optional. However, an SAP S/4HANA implementation
project is an ideal point in time to think about innovation in a broader context. You can do this fast, with
the help of the “SAP Leonardo Innovation Services”. How SAP Can Support The new
SAP Leonardo Innovation Services combine the tools, technology, and expertise of value to Business and IT,
to kick-start your innovation journey. There are currently three editions: SAP Leonardo Innovation
Services, express edition SAP delivers thoughtfully packaged innovative capabilities and services
– by industry – to engage with new customers in the context of their business.
SAP Leonardo Innovation Services, open innovation edition Starting from the individual customer
challenge SAP provides an innovation sprint from ideation to proof-of-concept based on the specific
challenge within 9 weeks by using comprehensive methodology based on the Design-to-Innovate
approach. SAP Leonardo Innovation Services, enterprise edition SAP offers a holistic
innovation approach based on the open innovation edition plus further services like a showroom and
empowerment to ramp-up customer skills. Please see SAP Leonardo landing page in the accelerator
section for details and differences. The section also includes a link to a detailed presentation.
The goal of this task is to make you familiar with all SAP Security & GRC relevant topics, and to collect
security relevant information, which serves as a foundation for a scoping on security. Procedure Please
listen to recording which is linked from the accelerator section, and get informed about security topics.
After watching the recording take the opportunity to fill out the questionnaire concerning your current
security situation, to identify the gaps you may have and to prioritize your next steps on the way to a
secured SAP landscape. The “How-To” document (accelerator) explains the procedure in
more detail. Results Once completed you will have a good general overview of the relevant SAP Security
& GRC topics, and a recognition of the own security situation. How SAP Can Support The
questionnaire should be filled out after listening of the recording. It is required to determine where your
security issues are, and how SAP can assist you most efficiently. The answers can be used to bring in
additional SAP Value Assurance services, or services from SAP Professional Services during project
implementation. This allows you together with SAP to build a secure and compliant SAP S/4HANA
landscape that best meets your needs and requirements. In May 2016, the European Union (EU) adopted a
newly harmonized data protection law called the General Data Protection Regulation (GDPR). The transition
period ends on May 25, 2018, from this day on will GDPR be a directly applicable law in all member states
within the EU and the European Economic Area (EEA). All organizations that offer goods or services to, or
monitor the behavior of, EU data subjects and those that process or hold the personal data of EU residents
are impacted. The EU-GDPR has different aspects for a legal basis as the consent, legal obligation, protect
of vital interests, contract, legitimate interest and the public interest. There are also different rights that the
data subject gets through the EU-GDPR: The right of information access, information to be provided,
restriction of processing, notification, correction, portability, erasure and automated decision. The EU-
GDPR is a legal requirement. SAP does not provide legal advice. SAP provides functions / products which
support customers on the way to compliance.
The purpose of this task is to evaluate the impact of SAP S/4HANA on the company’s analytics
architecture. The aim is to create a specific roadmap for analytics protecting past investments and
innovating via new platform capabilities. Requirements and Constraints This activity is optional. However,
SAP recommends to take the opportunity to adjust your company’s analytics strategy by considering
the analytics capabilities of SAP S/4HANA. Procedure The introduction of SAP S/4HANA into your solution
landscape is an ideal opportunity to review and potentially adjust your company’s analytics
architecture. There are many reasons why: SAP S/4HANA and SAP BW/4HANA bring new analytics
capabilities. The business data structure significantly changes with SAP S/4HANA. There are many
new analytic products from SAP which perfectly integrate with SAP S/4HANA. To review and potentially
adjust the analytics architecture you should look from a holistic perspective taking SAP and non-SAP
components into account. The strategy should consider: Product options like: Embedded
Analytics Stand-alone SAP BW and SAP BW/4HANA SAP Digital Boardroom
Front-end options like: SAP BusinessObjects BI Suite SAP Analytics Cloud
Data model and access method changes like: CDS (Core Data Services) Embedded
Analytics Options with respect to data persistence The accelerator section lists many
information sources for both the tools and strategy, to make you familiar with the options you have. The
analytics road maps for “Solutions” and “Products” are located in the general
SAP Road Maps space at sap.com, under “Platform & Technology”. The ideal analytics
strategy should be based on a customer specific set of decision criteria like: Functional analytics
requirements, e.g. for Operational Reporting and real-time Reporting Handling of historical data
Maintenance Schedule Data responsibility and ownership Complexity and number of data sources
How SAP Can Support With SAP S/4HANA system as the source, there are two source types for data
provisioning. Read the SCN Blog “Data Provisioning Supportability of SAP S/4HANA On-Premise
Edition 1709” from the SAP RIG team. SAP offers the “Analytics Strategy Workshop”
service component as part of the “Planning the Digital Transformation ” service to:
Assess the as-is analytics infrastructure, including SAP and non-SAP solutions for Enterprise Data
Warehousing (e.g. SAP Business Warehouse) and Analytics (front-end tools such as BI platform)
Understand the customer’s mid- and long-term EDW and analytics requirements and strategy
Analyze the customer’s most important reporting business cases, data management policies and
relevant boundary conditions Build a decision tree/matrix to support the customer’s roadmap
based on technical and customer requirement criteria Define a target analytics solution based on the
information gathered and SAP’s strategic product roadmap, and especially considering new
analytics options with S/4HANA Create a project plan for the implementation of the target
architecture (which might include implementation and migration activities). See accelerator section for
details. In addition to that, SAP Enterprise Support customers can listen to the Meet the Experts recording
“Analytics for SAP S/4HANA ”. The session covers: Overview: How SAP S/4HANA
integrates with SAP's business intelligence solutions Concept, strategy, architecture, and use cases
for
OnceSAP
theS/4HANA embedded strategy
general innovation analyticsand
in SAP S/4HANA
high-level (using
road mapVDMs withdefined,
has been Core DatayouServices)
will need to Concept,
become
familiar with SAP S/4HANA as such, and with the value it brings for your company's business.
Furthermore, the impact on existing business processes need to be analyzing in more details. This may
influence the implementation strategy for SAP S/4HANA. Finally, a customer specific application scoping
should be created. This includes a decision on the implementation scenario, and the mandatory and
optional / desired adoptions. Requirements and Constraints This activity is recommended for all scenarios.
There is an innovation strategy and a high-level road map available, which lists the implementation of SAP
S/4HANA as an upcoming major change event. Access to an SAP S/4HANA trial system (one activity later in
this phase) may be beneficial. Procedure Discover and document the value of SAP S/4HANA for your
company. Identify the impact of an SAP S/4HANA implementation on your existing business processes.
Analyze the relevance for Fiori apps based on the usage of the existing system (for System Conversion
scenario only) Validate the conversion readiness of your existing SAP ERP system (for System
Conversion scenario only) Perform a business scenario and solution mapping Define the
implementation strategy by considering the target architecture Create a strategic road map based on the
target architecture and implementation strategy Results As a result, there will be a plan what to
implement when in SAP S/4HANA; and why. This information serves as key input into the customer
business case. Furthermore, a first impact analysis may have identified show stoppers or road blocks, which
could affect the implementation strategy, and which need to be addressed in additional planning and
preparation activities.
The objective of this task is to become familiar with SAP S/4HANA, and to discover the value SAP S/4HANA
may bring to your company. Procedure To become familiar with SAP S/4HANA proceed as follows (all links
can be found in the accelerator section): Start with a study of the information resources in the public web.
See accelerator section for details. A good information source is the central landing page of the SAP Online
Help portal which contains for instance: Aa “Feature Scope Description” which
shows all features provided with a certain release of SAP S/4HANA. A “What’s New?
” document focusing on new features coming with this release. The “Simplification
List” focusing on what needs to be considered in case of a migration project from SAP ERP.
All relevant guides like the “Installation Guide” for new implementation, or the
“Conversion Guide” for system conversion. A list of training offerings on SAP
S/4HANA. Enterprise Support customers may look at the SAP S/4HANA Value Maps and
related Enterprise Support service offerings. The Business Scenario Recommendations Report lists SAP
S/4HANA innovations that might help based on current usage patterns of the business users. It’s
tailored to your specific system and free of charge. You can browse through the results report by Line of
Business and review individual business scenario details that include: business context, value, business
drivers, SAP S/4HANA and Fiori innovation, improved transactions, and more. SAP has recently created a
dedicated Quick Start Page on the digital transformation. Explore SAP S/4HANA yourself by using a trial
system in the public cloud (see activity Trial System Provisioning later in this phase). Regarding planning
and consolidation, look up the SAP Blog “Planning and Consolidation Options in S/4HANA”
from the SAP RIG team. A transition to SAP S/4HANA is a perfect opportunity to check if home grown
applications can be replaced by new functionality coming with SAP S/4HANA, to move closer to the SAP
standard (and to avoid maintenance efforts in future). This initiative is often called “Back to
Standard”. Explore options for efficient custom code management and agile customer
innovations using the extensibility capabilites of SAP S/4HANA and SAP Cloud Platform. Examples are SAP
Fiori and Mobile scenarios in the SAP Cloud Platform decoupling custom user interface development from a
stable SAP S/4HANA core, or consuming innovations without upgrades (e.g. LoB Finance innovations
delivered via SAP Cloud Platform applications). You will find helpful information and further links in the SCN
blog “Extensibility of S/4HANA – Helpful Links” (accelerator section). Results As a
result you should have a good overview about the value SAP S/4HANA may bring to your company. How
SAP Can Support SAP offers a “ Discovery Workshop for SAP S/4HANA” . The objective
of the workshop is to: Provide an understanding of SAP S/4HANA – the new digital core Identify
the most beneficial scenarios of SAP S/4HANA of a customer Evaluate the readiness of business and IT
Explain the migration paths and necessary IT landscape adjustments Jointly define a high-level
roadmap and next steps The workshop gathers customer’s business situation with relevant system
information in an up-front validation by automated assessment tools. A 2-3 days onsite workshop provides
a framework to understand SAP S/4HANA scope tailored to customer’s enterprise and to discover
beneficial business scenarios enabled by SAP S/4HANA. Finally, a discussion yields a high-level heat map for
relevant scope of SAP S/4HANA. The incremental benefits of SAP S/4HANA are matched to relevant
The implementation of SAP S/4HANA may have significant impact on existing business processes. This is
obvious for new implementation scenarios, and depends on the application design. However especially for
system conversion scenarios, the functional impact needs to be analyzed, because SAP has simplified
functionality, and partly removed redundant functionality in SAP S/4HANA (“Principle of
One”). To properly plan the implementation strategy, at least the major impact items should be
known as early as possible. Prerequisites This task is in particular important for System Conversion
scenarios. Procedure Proceed as follows: Study the Simplification List for SAP S/4HANA, on-premise
edition 1610 (accelerator section) with focus on functional / strategic changes. In this list SAP describes in
detail on a functional level what happens in SAP S/4HANA to individual transactions and solution
capabilities. In some cases, SAP has merged certain functionality with other elements or reflected it within
a new solution / architecture compared to the SAP Business Suite products. Compare these items with
functionality which is in use today. Study the alternatives and recommendations, given by SAP as part of
the list, The Simplification List for SAP S/4HANA also lists replaced transactions in SAP S/4HANA. Check
about usage today (e.g. by comparing with usage statistics in transaction ST03). Analyze the relevance
for Fiori apps based on the usage of the existing system (for System Conversion scenario only) Document
your findings. Please note : There is strong tool support for identifying impacted custom objects and
transitioning them to SAP S/4HANA. While the vast majority of custom objects will easily be transferred to
SAP S/4HANA, you may also consider candidates for re-engineering using advanced SAP HANA capabilities
and even a de-coupling of custom objects (e.g., UI’s) using Web IDE and SAP Cloud Platform. Details
will be given in the Explore and Realize phase of the roadmap. Please note : The simplification list will be
updated with new SAP S/4HANA releases or Feature Packs. You should retrieve the version of the
simplification list which fits to your “go-to version” of SAP S/4HANA. You will find them in the
SAP Online Help Portal for SAP S/4HANA (accelerator section). Then, select the right version of the on-
premise edition. Alternatively, you can always find the newest version of the simplification list as an
attachment of SAP note 2313884. Results There is a document available which documents the major
impact items for SAP S/4HANA. How SAP Can Support The impact of SAP S/4HANA is analyzed in the SAP
Readiness Check for SAP S/4HANA (see activity Implementation Strategy later in this phase). Furthermore,
impacted reports and transactions can be discussed in the Value and Implementation Strategy service
component. A description of all services and service components can be found in the accelerator section.
(see again activity Implementation Strategy later in this phase).
There could be show stoppers (e.g. incompatible Add-On’s installed in the existing SAP ERP system)
or requirements (e.g. version dependency issues with SAP NetWeaver hub system) that could have impact
on your conversion project. The objective of this task is to identify all items that could have a major project
impact as early as possible, to be able to adapt the overall project plan accordingly. Prerequisites This task
is in particular important for System Conversion and Landscape Transformation (in case they start with a
system conversion) scenarios. Procedure SAP recommends to check the following areas, and to document
the results: Is today’s functional scope in SAP ERP supported in SAP S/4HANA (e.g. Industry
Solutions, Enterprise Extensions, 3 rd party add-ons, etc…)? Is there functionality used today
that will need to be replaced with the conversion to SAP S/4HANA (e.g. Cash Management)? You will
need to compare the functionality in use in the current SAP ERP with the Simplification List from SAP:
Are all technical system requirements fulfilled (e.g. software levels, single stack system, Unicode,
etc…)? Otherwise they will need to be planned as part of the conversion. Are all dependent
SAP NetWeaver hub systems on the required release? How many custom objects are impacted by the
DB migration to SAP HANA? How many custom objects are impacted by the simplification of the financial
data model? How many custom objects are impacted by the change in SAP software? Which
business critical reports and transactions are in use today, which will be replaced / removed in SAP
S/4HANA? Which configuration needs to be adjusted? What is the estimated SAP S/4HANA
system size? Are there options to reduce the size before the conversion? Results The results
document of this task describes the implications of SAP S/4HANA; which need to be addressed either
before starting the transition project, or as part of the transition project. How SAP Can Support To provide
customers a better view on the implications of a transition to SAP S/4HANA for their specific system
constellation, SAP has created a SAP Readiness Check for SAP S/4HANA self-service. It is
basically a filter on the “Simplification List for SAP S/4HANA” based on usage of the
individual system. I.e. the SAP Readiness Check for SAP S/4HANA performs a remote analysis of the
setngs, configuration, transactional data and transactions/reports used in the production system (or
recent copy of production), derives the functional usage of the system and then lists all simplification items
relevant for this system. The SAP Readiness Check for SAP S/4HANA focuses on: Functional show
stoppers, restrictions and application requirements System and landscape requirements Custom
code implications Once you have prepared the source SAP ERP system, you can execute the SAP Readiness
Check for SAP S/4HANA yourself, either via SAP Solution Manager (recommended) or via upload of the
relevant data into the SAP cloud. Once the data has been analyzed by SAP, you can access the results
conveniently in a dashboard running in a web browser. Based on the results you can initiate the
recommended activities yourself, or with the help of SAP. The following picture shows the results
dashboard of the SAP Readiness Check for SAP S/4HANA, with dedicated sections for custom code analysis,
add-on compatibility, active business functions, and so on. Figure: Entry screen of the SAP Readiness Check
for SAP S/4HANA dashboard Please see the accelerator section for the landing page of the SAP Readiness
Check for SAP S/4HANA, which contains all important information on preparation, execution, and analysis.
See also the SAP Enterprise Support session on this topic. Please note that the SAP Readiness Check for SAP
Business Scenario & Solution Mapping establishes the business process scope and relevant
adjustments for the S/4HANA system conversion, with a focus on S/4HANA. Prerequisites The business
areas in scope for mapping has been identified already. This could have been done by gathering input from
the Lines of Businesses, or by requesting a Business Scenario Recommendation (BSR) report. The BSR is
part of the Discovery Workshop for SAP S/4HANA , or can be ordered separately (see accelerator section)
Procedure Proceed as follows: Set up a workshop together with process experts from the Lines of
Businesses Analyze each business priority in scope for innovation. Run a business scenario fit analysis, by
clarifying: It this innovation item relevant for me? Information source can be for instance the
Best Practice information which has been uploaded into SAP Solution Manager, the simplification list, and
the Business Scenario Recommendation report (BSR). Quantify and describe the value in case of
relevance. Upload all documents to the SAP Solution Manager so information can be shared
across the project team. Results As a result you have a documented list of innovation items, which are in
scope for implementation. This information if also valuable input for the business case. How SAP Can
Support The Value and Implementation Strategy service component provides a comprehensive SAP
S/4HANA migration analysis down to proposed implementation strategy and supporting value case as
depicted in the picture below. Starting from business priorities, it identifies key innovations and mandatory
changes applicable to the specific customer situation, along with the impact on the overall target
architecture, thereby highlighting the customer specific value chain built on SAP S/4HANA. Figure:
Structure of the “Value and Implementation Strategy” service component The following
inputs are used SAP S/4 HANA Discovery Workshop (optional); SAP Readiness Check for SAP
S/4HANA results SAP Fiori App Recommendations results (for System Conversion only) Customer high
level pain points and challenges with today’s implementation Overview of current and planned
initiatives, projects, extensions, and rollouts Comprehensive documentation of S/4HANA EM
simplifications provided by the service delivery team The service component follows a multi-step approach
with scope options to define the adoption strategy and program plan: Business scenario & value
mapping on selected solution capabilities SAP S/4HANA architecture adjustments and implementation
strategy Program plan and business case Delivery approach: Remote preparation combined with onsite
workshops and final results presentation What the workshop delivers: Identified benefits for selected
scenarios and solution capabilities incl. defined implementation scope (e.g. SAP Fiori front-end usage,
relevant dependencies/pre-requisites) Information on major functional gaps (if existing) Adjusted target
architecture, implementation strategy and high level program plan for adopting SAP S/4HANA Minimized
risks and uncertainties related to the business transformation Value case The Value and Implementation
Strategy service component is part of the Planning the Digital Transformation service. See accelerator
section for more details. In case there is the need to develop a more detailed UX strategy, SAP can offer an
additional “UX Advisory Service (SAP Professional Service; not part of SAP Value Assurance). This
service identifies UX related issues,and defines the prerequisites for a successful implementation and usage
of Fiori apps.
The objective of this task is to define an implementation strategy, based on the “to-be state”
of the business architecture. Prerequisites There is a draft version of the “to-be” state of the
business architecture available already. Procedure There are often multiple “Business Application to-
be states’” possible and different paths on how to get there. Functional capabilities,
landscape aspects, and technology capabilities need to be taken into consideration, and there might be
dependencies between these three aspects. The definition of the implementation strategy should cover
aspects like: What are the implications of the SAP S/4HANA to the current landscape? What is my
productive system strategy? Scenario Decision: new implementation versus system conversion or
landscape transformation. Should I re-shape the existing landscape when introducing SAP S/4HANA?
Deployment Option: Cloud versus On Premise Is it a “Big Bang”, or a multi-year
transition? What are intermediate architectures? Is SAP S/4HANA a good opportunity to go
“Back to SAP Standard”? How can I use “Best Practice” content from SAP
Activate? What are dependencies, and what is the ideal sequence in the context of the overall release
plan? What is the strategy for custom development of SAP Fiori UI’s (e.g., using Web IDE on SAP
Cloud Platform) and other custom objects? What is the security strategy? (e.g.
authorization;authentication; technical security; Governance Risk and Compliance; User
management) What about Data Privacy? Those questions can be addressed jointly with SAP, by
using a structured Best Practice approach: Limit the options according to boundary conditions
Define the right set of decision criteria, and rank the options according to these criteria The strategy in
general should be driven by business needs. The more business critical a system is, the more serious to
take the IT constraints. Document the results. Upload all documents to the SAP Solution Manager so
information can be shared across the project team. Results There is a document available which documents
and explains the customer specific implementation strategy. How SAP Can Support Regarding SAP Activate:
SAP Activate is covered holistically in one sub area of the SAP S/4HANA Cookbook. Here you will find
detailed information and links to all relevant tools and services. Aspects to consider when using Best
Practice content from SAP Activate are discussed there as well. The “Best Practices Reference
Guide” describes how SAP Activate and SAP Solution Manager 7.2 are used together to implement
SAP S/4HANA. See accelerator section for links. The Value and Implementation Strategy service component
can address the following aspects of the implementation strategy: Identification of the functional impact
and opportunities Landscape and application platform considerations (e.g. cloud versus on-premise)
Technology impact Scenario decision and transition path. Regarding SAP Security Strategy: SAP
offers best practices for thesecurity of your SAP system landscape in the SAP Security OptimizationServices.
In the SAP Support Portal on the SAP Security Optimization ServicesPortfolio page you can navigate from
three entry points depending on your requirements: Security Overview Security Topic Areas
Security Services, Tools and Information In the security map on that page you find a holistic view on
different areas of SAP security and can navigate tothe single topics with detailed information. See
accelerator section for more details. Regarding SAP Enterprise Support : SAP Enterprise Support customers
can
The look up the
objective ofMeet the isExperts
this task recording
to derive “
the road map forOverview of the SAP
implementing transition of SAP
S/4 HANA Business Suite
considering the to
findings from previous tasks. Prerequisites The definition of the road map is based on: Key findings from
previous tasks Identified architecture impact Consideration of parallel initiatives and projects Procedure In
case this task is executed as part of the Value and Implementation Strategy service component , the
recommended step sequence is as follows. Develop the building blocks (such as functional, organizational
or technical steps) required to reach the defined target architecture Perform a transformation maturity
assessment to identify the ability of the customer to execute the transformation e.g. related to
organizational change, budget, technical capabilities and project experiences Determine the risks of
transformation Agree on business transformation initiatives, and map the value contribution to the
segmented areas Compose a consolidated road map of building blocks to implement the target solution
landscape Agree on requirements & conditions for the business case calculation Define KPIs, and link
them to the identified value drivers Determine the value driver Determine the cost driver The value case is
based on identified business benefits leveraging SAP S/4HANA. Upload all documents to the SAP Solution
Manager so information can be shared across the project team. Results There is a documented
implementation road map available. How SAP Can Support See information on the Value and
Implementation Strategy service component from the tasks before.
To support the value identification, and the impact evaluation in the Discover phase, it could be beneficial
to have access to a trial system. At this point in time in the project, there is no hardware available to
run a new SAP system on premise,therefore installing a pre-configured appliance (“Blu-
Ray, see activity Define Cutover Approach in the Prepare phase) is not possible. A cloud trial system
is the preferred option in most cases. Requirements and Constraints User account at cloud provide required
(e.g. Amazon Web Services (AWS). Procedure Provide a Trial System Results As a result, project
members have access to the trial system for demoing, value identification, and impact evaluation. How SAP
Can Support SAP provides the cloud image of a pre-configured SAP system, which runs at the cloud
provider. See the landing page for a Quick Start and Demo Guide.
Request an SAP Trial system in the cloud, and provide it to your project team. Prerequisites User account at
cloud provide required (e.g. Amazon Web Services (AWS)). Procedure You can access the SAP cloud
appliance via the SAP Cloud Appliance Library (SAP CAL, https://cal.sap.com ). It is a pay-per-use
model hosted on Amazon Web Services (AWS). When using the SAP CAL option, you can choose between
a 30-day trial , or a longer-lasting engagement. With the trial, only AWS hosting fees need to
be paid by the customer . If you opt to go beyond the 30-day limit , an SAP CAL subscription
license and a regular SAP license is required . Besides the SAP back end, you also receive access to a MS
Windows Terminal Server (WTS) with the pre-configured Fiori Launchpad URL (if appropriate), SAP GUI
logon, and other useful front end software. Go to the SAP Trial landing page at SAP.COM Inform yourself
about the Cloud Appliance Library, and the different options you have Click “Start your trial
now” Accept terms and conditions Select the right trial image (e.g. “SAP S/4HANA, on
premise edition 1709 Fully Activated”) Click “Try now” Accept terms and
conditions Maintain cloud provider account information Click “Create Instance”
Results Once the trial image has been started by the cloud provider (the instance is up and running
within 15 - 60 minutes depending on the complexity of the solution), you have access to the trial system.
How SAP Can Support SAP provides the cloud image of a pre-configured SAP system, which runs at the
cloud provider.
Once the business case has been approved, the project is initiated in the Prepare Phase as depicted in the
picture below. Figure: Activities in the Prepare phase The formal setup of the project needs to be aligned
with the customer project manager. In general, each company or implementation partner has a
methodology to plan and execute projects. SAP’s implementation methodology is called
“SAP Activate”. See Accelerator’s section for more details. Yet, some tasks are still
relevant for SAP, like the availability of the SAP Solution Manager as the project delivery platform, or a
continuous project reporting (e.g. during Quality Gates) to the SAP Mission Control Center. SAP experts can
help quicker in case of problems. Project Team Enablement, and Organizational Change Management also
start now. If not already done in the Discover Phase, an SAP S/4HANA readiness assessment is performed
on the SAP ERP system to identify aspects that could have a major impact on the system conversion project
(see task “ Check the Conversion Readiness of SAP ERP ” for details). The project itself is
planned at a high-level in a “Migration Planning Workshop” for the conversion case, or in a
“Transition Planning for New Implementation”. Results from the Discover Phase – in
particular the functional implementation road map - need to be considered.as well. The project plan will be
further detailed out in the Explore Phase. The planning workshops often reveal preparation activity (e.g.
the “Customer Vender Integration” in case of a system conversion), which could be done
before the Explore phase starts. Those larger preparation activities need to be planned in detail in the
Project Management work stream. Two additional activities could start early: For conversion projects: The
cleanup of custom code which is not in use, and which could be decommissioned before the conversion
starts. The installation and configuration of SAP Solution Manager, to support the build, and later on the
productive use of SAP S/4HANA. The Prepare Phase ends with a first Quality Gate to ensure proper project
preparation.
The purpose of this deliverable is to ensure that the project team is informed about the way of working
during the Explore phase including usage of Solution Manager for Solution Documentation. Organize self-
learning possibilities for IT professional to understand the new solution with digital learning environments
(e.g. Learning Hub). This may include: Grant project team member access to the SAP Support Portal
Ensure that all team members can access the Best Practices documentation (see accelerator section) at the
SAP Support Portal. The SAP Support Portal can be access via the URL: https://support.sap.com . First time
users must register. The customer or installation number is required and can be provided by the
customer's IT Contact or SAP account team. The SAP Support Portal allows access to various SAP
content and resources used during and after an implementation project. Ensure project team member
access to the SAP Learning Hub Ensure that all project team members can access the SAP Learning Hub.
The Learning Hub is central location which allows access to different SAP Learning Rooms. SAP Learning
Rooms are interactive social learning environments. Available online 24/7, they facilitate informal learning
and knowledge sharing as well as expert-hosted live sessions, videos, quizzes, and postings on a wide range
of SAP topics. To access the learning hub, read the blog in the accelerator section. Review training material
on SAP Solution Manager Ensure the project team is properly trained on the usage of SAP Solution
Manager. SAP Solution Manager provides a central point of access for a variety of essential project support
functions. The reference materials provide more details about available Solution Manager trainings,
Focused Build for SAP Solution Manager , and a video describing how SAP Solution Manager is perfect for
SAP implementation. SAP provides customers with a SAP Solution Manager tool set that supports
customers in implementation of the project standards for the purposes of the project or operations. It is
highly recommended to use the SAP Solution Manager Focused Build service solution. Additional details
can be found in the accelerator section. Review training material on SAP Activate SAP Enterprise
Support Customers can: Join the session “ SAP S/4HANA Implementation with SAP Activate
” This Expert Guided Implementation service will guide you through the SAP S/4HANA
Implementation with SAP Activate, introducing the SAP Activate methodology and its key pillars: SAP Best
Practices and Guided Configuration. The goal is to give the attendee the experience of using the SAP
S/4HANA system and knowledge of the deployment methods and configuration available for SAP S/4HANA.
Join the session “SAP S/4HANA: Solution Activation with SAP Best Practices” This Expert
Guided Implementation(EGI) service will explain the general concepts of Best Practices and implementation
of a Business Solution such as Finance using the standard Solution Builder to setup a sandbox system. This
EGI will also talk about concepts of importing Best Practices using SAP Solution Manager 7.2 to accelerate
your S/4HANA implementation journey.
The purpose of this task is to educate project team on Agile implementation approach, principles and
techniques.
The purpose of this task is to help the team understand the concept of SAP Solution Manager with the
focus on supporting implementation (and upgrade) projects based on SAP Best Practices. SAP Training
platform provides Virtual Live Classroom "Implementation Projects with SAP Solution
Manager". The goal of the training is to: Explore tools, services, and methods in detail to
successfully and efficiently implement complete software solutions Learn how to create a structured,
comprehensive and standardized project during the entire the lifecycle of the implementation and the
solution
The purpose of this task is to educate the project team on Agile implementation approach, principles and
techniques. The training will focus on Agile Project Delivery to enable Project Manager and team leads to
effectively embed and execute Agile Project Delivery approach via SAP Activate Implementation
Methodology. Project Management will provide additional project learning enablement and approach
where appropriate.
The purpose of this task is to clarify deliverables and expectations, methodology, and tools. Typically, two
to three days should be reserved for this enablement. Once the team members or at minimum the team
leads are identified, they will be brought on board with this enablement session before the phase kickoff
meeting. The enablement deliverable: Sets project team expectations and delta design deliverables
Provides guidance for delta design workshops and relevant enabling tools Introduces quality assurance
and its acceptance criteria Prepares for essential skills, such as workshop facilitation, requirements
gathering, and process modeling Fosters teamwork within project teams
The purpose of this task is to train the key users for the solution in scope (pre-defined content).
To properly plan and prepare for the transition, it is key to understand the value of the innovations
delivered by the new system for customer business solutions. Prototyping enables the
customer to evaluate the value addition with real business scenarios using real data. Prototyping is an
optional small project by its own. It requires dedicated planning, execution and final evaluation, thus is
always driven by business or IT requirements. Procedure The main steps of a prototyping project are as
follows (see picture below): Run a scoping workshop for prototyping Set up the prototyping system
(either new installation, or system conversion) Conduct a data migration (in case of a new
implementation) Activate the solution in scope Run Fit-Gap workshops, and finalize the setup of the
prototype Validate the prototype Run a final results workshop Figure: Structure of the “Plan
& Prototype” approach Results The result of a prototype usually has significant influence to
the main project (e.g. Go / No-Go decision, learnings on how to prepare the main project, or what
functionality to set up).
The goal of this task is to run a prototype. Procedure The prototyping project is usually run in the discovery,
prepare, and explore phases of the overall implementation road map. In the discovery phase, the customer
and SAP agree on the detailed prototyping scope. In the prepare phase, the project responsibilities and
schedule are finalized, and the team conducts the necessary steps to set up and prepare the prototyping
system landscape. In the explore phase, the agreed scope of the prototyping project is implemented and
validated. How SAP Can Support SAP’ “SAP Value Assurance plan and safeguard”
service package provides the “Plan & Prototype (PLPT)” option. The prototyping
approach enables you to evaluate the solution in a short time frame with your real business scenarios using
your real data, thereby enabling you to quickly validate the value addition, identify and mitigate risks, if any,
at an early stage and efficiently plan your IT investments. The “Plan & Prototype” option
can be used for both system conversion and new implementation projects. The included components are
as follows: The “SAP Readiness Check” summarizes the most important aspects of the
conversion project in an easily consumable way. After the initial planning has been finished, a
“Scoping Workshop for Prototyping” (service component) defines the boundaries of the
prototype. Parts from the “Platform Execution” professional service are used to
technically set up the prototype system. In the case of a system conversion, the “Custom Code
Impact Analysis” service component helps to analyze and offer transparency on the existing custom
code situation, including a customer’s own objects and modifications. The purpose of the service
component “Mandatory Preparations for System Conversion” is to support all activities
required to meet the functional prerequisites of the prototype (system conversion only). During the
service component “Activate Solution” , SAP assists in the activation of preconfigured
content, best practices, and test-activated processes associated with the SAP Activate innovation adoption
framework in the prototyping system landscape for the defined functional scope. The service component
“UX Activation and Design” supports the PLPT project in terms of activation of Fioris that
have been defined in scope for the project. The objective of the service component “Fit Gap and
Delta Design” is to support customers in designing, building, and evaluating customer-specific
processes, applications, or functions in the prototyping project. During the service component
“Result Workshop for Prototyping” , SAP guides the customer to leverage the learning and
documentation from the prototyping project to realize the value during project implementation for
production use. The service component structure described before is displayed in the following picture.
Depending on the requirements of the specific customer case, further services and service components
can be added. Figure: Service structure of the “Plan & Prototype” option Further details
on the delivery of the prototyping service and the involved services and service components, see
accelerator section. SAP Enterprise Support customers can join the Expert Guided Implementation session
“Set up Prototype” . This 4-days session explains the main steps required to set up a
prototype in the CAL. Also, SAP Enterprise Support customers can join the session “ SAP Fiori
Configuration on SAP S/4HANA ”, which shows how to configure SAP Fiori UX for a Proof of Concept
project.
The planning of the transition project helps to properly define the scope and execution plan for the
upcoming SAP S/4HANA transition project. The result is a first version of an action plan, which can serve as
the basis for a project plan. The project plan will be constantly refined throughout the project (in particular
during the Prepare and the Explore phase) as part of the project management work stream. Requirements
and Constraints Proper transition planning is required for all scenarios. However, the conversion readiness
only needs to be checked in case of a system conversion or landscape transformation scenario. Procedure
Check the conversion readiness of the current SAP ERP (system conversion scenarios only) Define the
scope and the objectives of the transition Define the cutover approach (high-level) Clarify the
adaption of existing custom code, and the development of new custom code (if required) Clarify
operational readiness Define the technical architecture (if not already done in the Discover phase)
Define the data migration architecture (important for new implementation and landscape transformation)
Prepare interface register Run a legacy impact analysis on interface inventory and data integration
Run a first assessment on Output Management Run a first assessment on training requirements
Optional: Run a Technical Security Self Check Results As a result, a first version of an action plan has been
documented which could serve as the basis for a project plan. How SAP Can Support The conversion
readiness can be checked with the SAP Readiness Check for SAP S/4HANA . See activity Implementation
Strategy task Check the Conversion Readiness of SAP ERP for details. For conversion projects, SAP offers the
Migration Planning Workshop (MPW). The MPW helps to define the scope and execution plan for the
customer’s conversion project to SAP S/4HANA. Figure: Structure of the “Migration
Planning Workshop” (MPW) Main objectives / deliverables of the workshop are (see picture above):
The MPW helps customers who may be considering or planning the transition to S/4HANA, Suite on
HANA, and/or BW on HANA. The service provides a holistic overview of the topics required for
consideration during the planning phase of a project, including: transition approaches and tools, technical
architecture, sizing, performance and scalability, operational readiness, testing, and quality management.
A remote assessment of the customer system(s) is conducted in preparation of the onsite workshop in
order to help determine additional scope items. The onsite portion of the service includes knowledge
transfer of key concepts and consideration, as a means to ensure that the customer is making informed
decisions. The outcome of the workshop includes the development of a system-level transition road
map and a customer tailored high-level milestone project plan . The MPW covers many of the tasks
described before, and summarizes the results in a service report. This consolidated view of critical project
planning decisions is why SAP considers the Migration Planning Workshop as a “mandatory
service”, which is part of the “Planning the Digital Transformation” service. Details on
the MPW can be found in the accelerator section. Please also look up the SAP Blog “System
Conversion: news since 1610”. For new implementation scenarios, SAP offers a Transition
Planning for New Implementation (service component) . This workshop provides a substantial knowledge
package, essential to create the planning deliverables of the SAP Activate Prepare phase. The customer is
supported on developing respectively reviewing the planning documents. The following picture illustrates
what areas of the transition road map are considered in the “Transition Planning for New
In case the conversion readiness has not been checked already in the Discover phase of the project: There
could be show stoppers (e.g. incompatible Add-On’s installed in the existing SAP ERP system) or
requirements (e.g. version dependency issues with SAP NetWeaver hub system) that could have impact on
your conversion project. The objective of this task is to identify all items that could have a major project
impact as early as possible, to be able to adapt the overall project plan accordingly. Prerequisites This task
is in particular important for System Conversion and Landscape Transformation (in case they start with a
system conversion) scenarios. Procedure SAP recommends to check the following areas, and to document
the results: Is today’s functional scope in SAP ERP supported in SAP S/4HANA (e.g. Industry
Solutions, Enterprise Extensions, 3 rd party add-ons, etc…)? Is there functionality used today that will
need to be replaced with the conversion to SAP S/4HANA (e.g. Cash Management)? You will need to
compare the functionality in use in the current SAP ERP with the Simplification List from SAP:
Are all technical system requirements fulfilled (e.g. software levels, single stack system, Unicode,
etc…)? Otherwise they will need to be planned as part of the conversion. Are all dependent
SAP NetWeaver hub systems on the required release? How many custom objects are impacted by the
DB migration to SAP HANA? How many custom objects are impacted by the simplification of the financial
data model? How many custom objects are impacted by the change in SAP software? Which
business critical reports and transactions are in use today, which will be replaced / removed in SAP
S/4HANA? Which configuration needs to be adjusted? What is the estimated SAP S/4HANA
system size? Are there options to reduce the size before the conversion? To do so, SAP recommends
to: Study the Simplification List for SAP S/4HANA 1610. Run the Maintenance Planner tool. The
Maintenance Planner: Checks the compatibility of existing add-on products. Checks the
compatibility of active business functions. Checks the compatibility of industry solutions.
Checks the compatibility of systems with dependencies. Allows to generate the required stack xml
as well as packages. The stack xml is mandatory precondition for using the SAP conversion tools afterwards.
The Maintenance Planner is a tool you can launch from the public web (S-user credentials
required), and which runs in a browser. Figure: How customer landscape data is transferred
to the Maintenance Planner As shown in the picture above, the Maintenance Planner retrieves
information about your SAP landscape via SAP Solution Manager. Based on this information, you can plan
your change event. See accelerator section on how to start the Maintenance Planner, and where to find
documentation in the SAP Online Help Portal. SAP also offers the training “Upgrade of Systems
Based on SAP NetWeaver – Advanced Topics” at openSAP learning platform. Run the
application pre-checks as documented in the in the Conversion Guide (see section “Pre-
Checks”). You will need to install and run the ABAP report R_S4_PRE_TRANSITION_CHECKS, and
follow up on error messages. Please note that Asset Accounting (FI-AA) requires an additional check report
(SAP note 2333236 - Composite SAP Notes: Enhancements and message texts for the program
RASFIN_MIGR_PRECHECK). A system conversion is executed by the Software Update Manager (SUM),
in a so-called “load procedure”. In the load procedure, the new repository is built up from a
DVD containing the repository of the new release. Here SUM needs to rescue all objects not belonging to
To define and document the objectives of the transition project, you should create a scope document. The
scope documentation serves as a general guideline for the transition project. It has to describe the starting
point of the project as well as the project objectives. This information is necessary to develop the target
solution landscape, define the transition approach and to finally verify the success of the overall project.
The starting point typically describes the SAP solution in focus, the transition target product and the
systems in scope (either to be converted, or to be replaced by a new installation). In addition, already
planned changes to the SAP solution and further boundary conditions have to be determined. The
objectives comprise the business and IT requirements related to the new functionality and technology
available with SAP S/4HANA, e.g. Provision of new functionality in Finance and Logistics Reduction
of costs or complexity Performance improvements for specific business functions Improvement of
User Experience Landscape adaptations to comply with changing market and business requirements
Ideally, the objectives are defined in a way that they can serve as success criteria for the transition project.
Further success criteria can be derived from boundary conditions, e.g. business downtime requirements for
the transition project. Requirements and Constraints There is an implementation strategy and road map
already available as input for the scope document. Procedure Document the scope of the SAP S/4HANA
transition project. Clarify and describe following general aspects: Expectations from the business
Expectations from IT Conversion target product including anticipated functional quick wins SAP
solution in scope for the conversion Related SAP systems (name, SAP products, release, database size, and
business criticality) Process the subsequent tasks in the road map to enhance the scoping document with
boundary conditions and requirements from the business, as well as requirements and prerequisites from
target product perspective. The SAP S/4HANA transition project can be combined with already planned
infrastructure changes, e.g. the replacement of server hardware or the introduction of a virtualization
solution for the application server layer. This can help to reduce the overall effort for all change activities.
Consequently, further limitations or opportunities might exist, which need to be incorporated. These
boundary conditions need to be known to the transition project to integrate them in the planning and
execution. Document already planned software or hardware changes in the SAP solution landscape, which
are to be synchronized with the transition project. Examples are: OS upgrades and/or, -patches SAP
support package updates, enhancement package upgrades, release upgrades, patches Unicode
conversions Virtualization solution changes HA/DR solution changes Server hardware changes
Storage infrastructure changes Backup tool or hardware changes Document further infrastructure
changes or limitations, which can affect the transition project timeframe, e.g. data center moves or data
center limitations. Document planned landscape changes, e.g. system splits, consolidations or moves.
Document maintenance windows that could be utilized by the transition project. Document release plans
or calendars of development projects in the target SAP solution. Before planning more detailed transition
steps, the current SAP solution needs to be described in detail, so that the required target SAP solution
architecture and related transition steps could be derived (“Inventory”). So if for example the
server hardware needs to be changed, the capabilities of the current server hardware and the related
technical architecture of the SAP systems need to be understood in detail to design the future technical
A good starting point to become familiar with system cutover is the “Administration Guide for the
Implementation of SAP S/4HANA” which covers both the new installation of a system, and the
system conversion. As always administration, implementation and conversion guides are release and
feature pack specific. You can find all guides for all releases and feature packs in the SAP Online help portal
for SAP S/4HANA. The cutover approach for system conversion and new implementation differs. Procedure
Proceed as follows: Results There is a first version of a cut-over document available in SAP Solution
Manager. How SAP Can Support For system conversion scenarios, see the description of the Migration
Planning Workshop in the activity Transition Planning. Similarly, for new implementations, see the
Transition Planning for New Implementation in the activity Transition Planning . System conversion:
Please note: The picture below presents the transition paths ´to the SAP S/4HANA family.
This road map documents the system conversion to the newest release of SAP S/4HANA. Figure:
Transition path to SAP S/4HANA System conversion to older releases are documented in former road
map versions which are available as PDF documents on request. Please also note that this road map does
not cover upgrade procedures (e.g. the upgrade from SAP S/4HANA 1511 to SAP S/4HANA 1709). See SAP
note 2426277 “Add. info. on converting to SAP S/4HANA using SUM 2.0 SP00” for details.
Please check the landing page of the SL Toolset (accelerator section) to find the latest appropriate SUM
version, and the respective SAP Note for more information. A cutover planning starts from a system-
level transition road map which documents the conversion sequence, and the creation of temporary
systems to keep up a production support track. The following picture shows an example
of such a transition road map in six cycles. Figure: System-level transition road map for system
conversion (Example) 1) References the creation of the sandbox from a copy from production.
2) References the conversion of the development system D01 while keeping DT1 as a temporary
production support system. 3) References the conversion of the quality assurance system Q01
while keeping QT1 as a temporary production support system. 4) And 5) References cutover
preparation and dress rehearsal runs. 5) References the final cutover of the production system P01.
Once converted successfully, DT1 and QT1 can be decommissioned. The implementation and
conversion tools are documented in the Conversion Guide for SAP S/4HANA. In case of system conversion,
and depending on the DB and start release of your SAP ERP, you either use Software Update Manager
(SUM), or the database migration option (DMO) of SUM. DMO of SUM allows you to:
Update SAP software Migrate from AnyDB to SAP HANA Convert data to the new
data model of SAP S/4HANA . For the conversion to SAP S/4HANA, you have two options
depending on the source database: SAP HANA database to SAP HANA database: If you
run a system already on an SAP HANA database, you carry out the conversion using SUM without the
database migration option. Any database to SAP HANA database: If you run a system on a
database other than SAP HANA, you carry out the conversion using SUM with the database migration
option. By consolidating the scope into a single change event, it helps to keep the overall
project costs low (cost reduction by having only one large change event test leading to only one test
round). SUM, and DMO of SUM are documented in great detail in the SAP Help Portal (see
Custom code may need to be adapted to work properly with SAP HANA and SAP S/4HANA. This is
important: In case of a system conversion : Details on the identification of affected code will be given
later in the Explore Phase (“ Plan Custom Code Adaption in Detail ”), or see Accelerator.
In case of a new implementation , and the old system is an SAP system where custom code should be
transferred over. The new implementation of an SAP S/4HANA system is an opportunity to re-evaluate
custom coding and SAP modifications, that were required in the past, but that can be decommissioned
now, and replaced by new SAP standard code. Requirements and Constraints This task is relevant in case of
a system conversion. It can be relevant for new implementation scenarios, where custom code should be
taken over from an old SAP ERP system. Procedure For system conversion: The 4-step sequence to
adapt custom code with respect to a system conversion to SAP S/4HANA is shown in the next picture.
Figure: Preparatory and adjustment steps for custom code in the context of a system conversion
Either executed continuously, or in front of a SAP S/4HANA conversion project: Step 1: Get
transparency on your custom code situation – The SAP Readiness Check for SAP S/4HANA should
have performed an early effort estimation on custom code adjustment, which is sufficient for the high level
conversion plan at this point in time. Step 2: Remove waste (custom code that is no longer used)
– This is covered by activity Custom Code Cleanup & Improve . As part of the SAP S/4HANA
conversion project: Step 3: Identify the impact of the DB migration to SAP HANA, and the conversion to
SAP S/4HANA, and create an adaption plan - This is covered by activity Custom Code Impact Analysis .
Step 4: Adapt your code by either going back to the SAP Standard, or by adjusting the custom coding
– This activity happens later on in the Realize phase. For new implementation: In case custom
code should be transferred from an old SAP ERP system, check if the custom code can be replaced by SAP
standard code instead. Results There is a first estimation on custom code which needs to be considered as
part of the SAP S/4HANA implementation. How SAP Can Support SAP has published excellent blogs on
custom code management in the context of a system conversion: To learn about the challenge, start
with the SAP Blog “SAP S/4HANA System Conversion – Challenge for your custom
code” . To understand the necessary adaption process for your custom code, look at:
The SAP Blog “SAP S/4HANA System Conversion – Custom code adaptation process”
The SAP Blog “ABAP custom code adaptation for SAP HANA – The efficient
way” The video on YouTube: “ Custom Code Adaptation for SAP S/4HANA ”
What you can (or better: should) do well upfront of a planned system conversion is documented
in the SAP Blog “What can you do today to prepare your custom code for SAP S/4HANA” .
Finally, there is a blog series describing all relevant expert tools required for analysis. The first issue is the
SAP Blog “Remote Code Analysis in ATC – One central check system for multiple systems on
various releases” . You will find all links in the accelerator section. This is how SAP supports
customers with Custom Code Management in the system conversion case: Assessment service : The
“ Custom Code Management Architecture ” service component (part of the “ Code
Code Management ” service) is to facilitate efficient and effective Custom Code Management. It is
necessary to formalizeof
With the introduction the strategy
a new for management
solution of Custom
like SAP S/4HANA, yourCode across
current their whole
IT support lifecycle
framework willfrom
change.
For this, many aspects need to be considered. SAP provides guidance on the target IT support process
activities, tools and resources required for you to safely and efficiently operate the new SAP solutions in its
environment. SAP provides, for example, Best Practices on daily DB administration procedures,
troubleshooting procedures, monitoring tools, knowledge content for the resources to be ramped up for
the post go live operation… Clarification on the steps required to ensure the IT Operational Readiness
will be given later in the Explore Phase (see activity Operations Impact Evaluation ). As a result, a
number of tasks will be defined and included in the conversion plan. Procedure Customers who are new to
SAP should look at SAP’s general recommendations to set up a Customer Center of Expertise. At
least a primary CCOE certification should be gained. SAP has also published SAP Support Standards which
should be implemented as part of the standard IT support processes. See accelerator section for guidance.
How SAP Can Support See Primary CCOE Certification program in the accelerators section.
With the introduction of the first productive SAP component running on SAP HANA, the IT architecture will
change (e.g. new HW, new OS, new HA/DR setup options…). Requirements and Constraints There is
an implementation road map (high level) available describing the “to-be” business
architecture of SAP S/4HANA. Invite your hardware provider to join this task. Procedure Collect information
for the following topics (as far as already available): Future and existing technical platform (hardware
platform, virtualization solution, OS) General SAP application server architecture Availability SLAs for
unplanned downtimes Data center strategy HA architecture and DR strategy and architecture Non-
production and production landscape System to data center mapping Planned server hardware
(application servers and SAP HANA) and storage hardware Integration with cloud services (e.g. with SAP
Cloud Platform for side-by-side extensions of S/4HANA) Backup solution Clarify and document the
following topics: What is the “to-be” SAP Landscape? What is the anticipated SAP
architecture (main technical components)? What is the sizing relevant information (SAPS, memory, disk
space) of all SAP components? What technical options are in scope (e.g. Tailored Data Center Integration
(TDI))? What frontend components are required for FIORI? What is the required HA / DR strategy,
based on availability requirements, business downtime SLAs and the existing data center strategy? What
is the ideal backup strategy? What is the strategy for the non-production landscape based on change
management requirements? Based on the results, create a first sketch of a technical deployment plan, by
mapping the systems and technical components to the hardware. The technical deployment plan
documents which system runs on which server. This deployment plan is the basis for ordering the hardware
at your hardware provider. The plan is constantly refined throughout the project. Please note : Customers
who do not have any experience with SAP, or with SAP HANA should study the existing material on SAP
HANA and SAP S/4HANA before starting this task, because the definition of the technical architecture
requires sound knowledge on many technical aspects. A good entry point to get this knowledge is the Value
Map on SAP S/4HANA for SAP Enterprise Support customers. The procedure on how to define the technical
architecture differs depending on the scenario: For instance, customers converting their existing SAP ERP to
SAP S/4HANA can do the sizing based on their existing SAP ERP. Customers installing a new SAP S/4HANA
system replacing a legacy system need to do the sizing based on business document volumes using
“Quick Sizer” tool. Alternatively, customers can ask their hardware provider to make a first
proposal for a technical deployment plan. Finally, you should make yourself familiar with SAP’s
revision and maintenance strategy for SAP HANA because administrative functionality provided by SAP
HANA could be release-dependent. See SAP note 2021789 – “SAP HANA Revision and
Maintenance Strategy” for details. Results As a result of this task, a technical deployment plan
exists. How SAP Can Support The “Technical Architecture and Infrastructure” service
component supports customers in the creation of a technical architecture. As depicted in the picture
below, it starts with an estimation of the required hardware capacity, and goes on to the mapping of the
various technical components to the hardware, including influencing factors, such as data-center strategies,
high availability and disaster recovery requirements, preferred deployment models and similar. Compared
to an SAP Suite on HANA scenario, an additional focus is on SAP Fiori and its technical requirements.
The purpose of this task is to prepare a high level assessment of the source systems and necessary data
objects as well as for methods to extract / transform / load the source data from legacy systems and or SAP
systems. Requirements and Constraints This activity is required for new implementation and landscape
transformation scenarios in case of complex data operations which require a guidance for data objects and
data migration technologies. Procedure The procedure differs depending on the implementation scenario.
How SAP Can Support Look up the SAP Blog “Migrating data to your (new) SAP S/4HANA” to
learn about the ways in which your business data can be migrated to your newly deployed SAP S/4HANA
system (on premise or cloud). A first definition of the data migration architecture is discussed in the service
component Transition Planning for New Implementation which belongs to the
Planning the Digital Transformation service . See also activity Transition
Planning for details. The data migration architecture is further detailed out in the Explore phase of
the project (see activity Data Migration Design ). SAP also offers a dedicated assessment called
“Data Migration Architecture” as part of the “Planning the Digital
Transformation” service, to identify the required scenarios. The Data Migration Architecture
assessment for technical landscape transformations is conducted on a high-level basis to identify the most
suitable data migration execution services, such as client transfer, consolidation of SAP ERP systems to one
target system for SAP S/4HANA, company code transfer, or data migrations based on preconfigured objects.
SAP experts lead you through discussions to specify on a high level your requirements for the selection of
data, and tailor the scope of a subsequent Data Migration Design service. SAP Enterprise Support
customers can join the session Data Migration Strategy and Tools for SAP S/4HANA . The 5-days Expert
Guided Implementation explains the data migration tools per transition scenario, and how to define a data
migration strategy.
The purpose of the interface register task is to preliminarily identify the external systems, applications, and
business objects or transactions that must be integrated with the SAP S/4HANA system to realize the
objectives of the project. Requirements and Constraints The interface register contains all interfaces and
allows therefore to scope and plan the implementation project. The customer must have a clear vision of
the to-be system & solution architecture with interfaces. Procedure All interfaces are documented
within a central document (called “interface register”). By specifying the interfaces in
predefined attributes a clear grouping into technology and interface types is possible, which allows to
integrate the corresponding requirements into the project scoping and planning structures. Once an
interface scope has been agreed, the interface register is updated using a change control process. The
interface register template is initially pre-populated by the customer with legacy interfaces, that are in
scope for re-implementation against the new SAP S/4HANA system. New to-be implemented interfaces
are included into the interface register. In case SAP Solution Manager 7.2 is available, it is recommended to
document interfaces directly there as part of the overall solution documentation. Concentrating interface
and business process information centrally in SAP Solution Manager has a couple of advantages: Increased
visibility and avoidance of duplicate maintenance of interface data in different tools. The effect of planned
downtimes in your solution landscape can be judged more easily, especially in case the interfaces are
assigned to business processes. In case a system has stopped unexpectedly, or a particular interface has
become stuck due to technical errors, you can identify the affected business processes directly in SAP
Solution Manager. Finally, there is an integration with the interface & connection monitoring
application. Interface attribute data maintained in interface documentation can be used to configure
interface channels for monitoring & alerting. See accelerator section for a setup and end user guide
on interface documentation in SAP Solution Manager. Results Populated interface register How SAP Can
Support SAP supports this activity with the “SAP S/4HANA Transition to New Implementation
(TNI)” service component as part of the service “Planning the Digital
Transformation”. The creation or review of the to-be system & solution architecture
with Interfaces is part of this service component. This service component includes the determination of the
interface scope. See also activity Transition Planning” in this phase, for more
information on this service component.
The objective of this task is to assess the impact on interfaces when moving over from SAP ECC to SAP
S/4HANA via system conversion or new implementation. In both cases, interfaces can be affected by
technology changes (i.e. field changes). General remarks: In a hybrid cloud and on premise landscape,
different integration capabilities are key. Those integration capabilities may change over the time, or have
been developed further. Integration capabilities from a current to a successor product are generally
preserved (e.g. when moving from SAP ERP to SAP S/4HANA). SAP Cloud Platform Integration offers rich
“Integration as a Service” capabilities. SAP Cloud Platform delivers preconfigured
integration models for SAPs most important cloud solutions. Integration capabilities are typically
preserved when moving to a recommended successor product. To make the SAP S/4HANA adoption easy
for all existing SAP customers, SAP has kept most of the official interfaces to and from SAP
ERP stable when simplifying the applications in SAP S/4HANA. This is not necessarily the case for non-
official interfaces (e.g. usage of ODBC on DB level). Prerequisites An initial interface register must be
already available. Procedure As a first step you should analyze your existing interfaces, and categorize
them according to complexity, technology and custom development. Potentially some interfaces can be
retired as well. As a second step check the compatibility with SAP S/4HANA and other new SAP
products (on-premise or cloud-based solutions) that you would like to introduce. For cloud integration
“SAP Cloud Platform Integration” offers a rich preconfigured integration and API discovery.
See “API Discovery” in the accelerator section for details. Further information and links can
be found on the landing page of SAPs Technical Integration and Orchestration Group. The functional
work stream needs to check on interfaces that are in scope (interface register) for technology changes.
Document necessary interface adjustments in the backlog as gap. Results The transition impact on
interfaces has been made transparent. Necessary changes are specified and added to the project backlog
as gap. How SAP Can Support SAP supports this activity with the “SAP S/4HANA Transition to
New Implementation (TNI)” service component as part of the service
“Planning the Digital Transformation”. This service component includes the
determination of the interface scope. See also activity Transition Planning” in this
phase, for more information on this service component.
SAP S/4HANA introduces a new style of output management (OM). The output management for SAP
S/4HANA comprises all functionalities and processes that are related to the output of documents. This
includes the integration of output management functions into the business applications, the reuse
component output control, as well as the SAP NetWeaver technologies and the technical infrastructure.
The new output management is going to be the successor of all other output management frameworks (SD
Output Control, FI Correspondence, FI-CA Print Workbench, CRM Post-Processing). However, all other
frameworks are still available and can be used. It is not mandatory to use the new output management.
Business applications that have already adopted the new output management use it by default.
Nonetheless, customers can always revert to the other supported framework. How this reversion is realized
depends on the business application (for example via SAP Note or by implementation of an enhancement
point). It is also possible to re-enable the new output management again at a later point in time. Hence,
the new output management for SAP S/4HANA coexists with other frameworks. Customers can decide on
business application level which framework supports their output scenarios best. The objective of this task
is to determine and to document the impact of the new output management on your existing output
management configuration. Requirements and Constraints This task in of particular interest for system
conversion scenarios, and for landscape transformations which start with a system conversion. New
implementations will always start with the new output management. Procedure In the SAP ECC Business
Suite, different output frameworks are used in different applications (SD Output Control, FI
Correspondence, FI-CA Print Workbench, CRM Post-Processing Framework). Considering the conversion of
an existing system to SAP S/4HANA, it becomes evident that there cannot be one generic approach to
cover the conversion of all other OM frameworks. Looking further into the most prominent existing OM
framework SD Output control (NAST), it becomes clear that: 100% feature parity is not a given (and,
most likely, is not wanted). Migration of data cannot be performed because even the NAST is highly
generic. Therefore, the recommendation is not to carry out a conversion, but to establish a coexistence of
old and new output management. This means: For existing customers who are using the old output
management: Data from the old OM is kept. Customizing for the old OM is kept. Customers need to
customize the new OM. Documents that were processed in the old OM will still be processed using the
old OM. New documents will only use the new OM (if the corresponding application has already adopted
this framework). Proceed as follows: Make yourself familiar with the new output management in SAP
S/4HANA, by reading SAP note 2228611. By looking at the simplification list, determine and document
how your existing output management is impacted by a system conversion. Develop a general strategy
how to adopt the new output management midterm / long term.
The objective of this task is to identify the enablement scope for end user training. Procedure Run a first
assessment on the training requirements which arises from the SAP transition project: Gather information
about the SAP transition project, and identify affected organizational units Conduct interviews
regarding training strategy elements Identify training relevant user groups (Project Team, Key User,
End User) Evaluate the high-level enablement scope for End User Training How SAP Can Support SAP
offers the “Initial Enablement Assessment”. It is part of the “Enablement
Charter” service component (Planning the Digital Transformation service). The Initial Enablement
Assessment is the analysis of learning and enablement related aspects of Digital Learning in general and
with respect to your actual situation. The assessment helps to get an understanding of the general learning
management situation, your enablement capabilities to support the digital transformation process and the
alignment with the project scope and timeline. Based on the results of the assessment, specific training
management activities will be identified and recommendations will be provided to enable a successful
enablement delivery. It is particularly relevant at the beginning of a project. See accelerator section for
details.
With the conversion to SAP S/4HANA, new technical and functional security requirements may come up.
The technical security requirements are related to new components that are part of SAP S/4HANA (e.g.
new security setngs, and security role changes related to SAP HANA, or related to HANA Live). The
Accelerators section contains links to detailed Security Guides. The SAP ERP Central Component Security
Guide for instance covers both technical and functional security aspects. However, this activity focuses on
basic technical security checks customers can execute themselves. The recommendations arising from
these self-checks can then be implemented in the Realize Phase as part of the conversion project.
Requirements and Constraints This task is of particular interest for system conversion. However, customers
who would like to replace an existing SAP ERP by a new implementation of SAP S/4HANA should be aware
of significant security changes (technical and functional). Procedure To get a status on the technical
security in your SAP system, proceed as follows: Have a look at the Security chapter of the Early
Watch Alert (EWA) report of your SAP ERP system and analyze the root cause of the findings. See
also SAP Note 863362 for a complete list of security checks as part of EWA. Run a Security Optimization
Service SOS. Enterprise Support customers can order an EGI which runs them through the SOS Self Service.
See SAP Enterprise Support Academy for details. With Configuration Validation, you can benchmark
system configuration setngs against SAP Best Practice setngs. Configuration Validation can also be used
to check your security setngs (in front of a system conversion, and later on continuously to support IT
security in your support environment). Configuration Validation, in general, can be easily set up by joining
an EGI. Security relevant checks as part of Configuration can be found in the SAP WIKI on Technical
Operations (see Accelerators section for details). Fill out an SAP Security Baseline Template: The SAP
Security Baseline Template document provided by SAP on how an organization-specific SAP Security
Baseline could be structured. It is pre-filled with selected baseline-relevant requirements and
corresponding concrete values as recommended by SAP. In a first step, you should focus on chapter 2 -
Regulations of the document. The latest version of the SAP Security Baseline Template can be found
on the SAP Support Portal (see accelerator section). See also SAP note 2253549 - The SAP Security Baseline
Template for details. Results With the help of EWA, Security Optimization Service, and Configuration
Validation, create a list of technical security changes you would like to implement in the Realize Phase as
part of the system conversion project. How SAP Can Support SAP can support this activity by either running
a Security Assessment as part of SAP Premium Engagement, or by setng up and executing a holistic
Security Engagement that can be tailored to your business and IT requirements. SAP Enterprise Support
customers can book Expert Guided Implementations on the Security Optimization Service (SOS), or on
Configuration Validation (see accelerator section).
This activity covers all preparation work which happens before the project starts. The intention to exclude
the preparation work in an extra activity is also to keep the business downtime small during cut-
over weekend. However, each significant preparation item should have been discussed in the
appropriate planning workshops in the Transition Planning activity upfront. Examples for transition
preparation activities could be: For system conversion: Customer/Vendor Integration(see also the SAP Blog
“Business Partner – Customer-Vendor Integration S/4HANA” from the Regional
Implementation Group (RIG) on this topic) Replacement of Foreign Trade by SAP Global Trade Services
(GTS) New Asset Accounting (see also the SAP Blog “S/4 HANA- New Asset Accounting –
Considering Key Aspects” from the Regional Implementation Group (RIG) on this topic) Upgrade
of depending hub systems Analysis and close of open business to make those documents available for
archiving. This activity can be time consuming because you will need to identify open business documents
first before clarifying the root cause with the process champions from the business units – therefore
SAP recommends to start early. SAP supports this preparation activity with a service component called
“Business Process Improvement” as part of the “Safeguarding the Digital
Transformation” service. For details, see task Get Transparency on Open Business Documents in the
Explore phase), and the accelerator section. Those preparation activities are often related to items from the
simplification list. See simplification list for all details, and check both the output of the SAP Readiness
Check for SAP S/4HANA and the SI-Check for relevant simplification items (see also task Check the
Conversion Readiness of SAP ERP in this phase). For a compressed view to the most important preparation
activities you can also look at the “Top simplification list items” including further explanation
in the accelerator section, or the chapter “List of Application-Specific Preparations” in the
Conversion guide. For new implementation: Cleanup of source data Upgrade of depending hub
systems A detailed description of new implementation projects including preparation work can be retrieved
from the SAP Best Practices Explorer (see accelerator section). Look up: SAP Best Practices for SAP
S/4HANA, on-premise edition for new implementation Requirements and Constraints The activity is
recommended for all scenarios. It relies on findings from the Transition Planning activity. Procedure
Execute on Follow-Ups from Transition Planning
The goal of this task is to plan and execute all preparation activities which should happen before the
transition project starts. Prerequisites There is a high-level transition planning document stored in SAP
Solution Manager. This preparation activity is of particular relevance in case of a system conversion.
Procedure Properly analyze all preparation items which have been identified in the Transition
Planning This could be for instance the Customer/Vendor Integration (CVI), or the use of SAP GTS
instead of Foreign Trade. Plan in detail the execution of these items. This could result in own projects
depending on the scope of the item. It is in the responsibility of the Project Management work stream to
take care of proper project planning. Execute the item according to the plan. How SAP Can Support
SAP provides additional information for typical preparation activities in case of a system conversion, for
instance: The TOP Simplification List Items including further explanation A Best Practice Guide on the
Business Partner Approach (Customer Vendor Integration) – see attachments of SAP Note 2265093
SAP expert blogs from the Regional Implementation Group (RIG) SAP also offers the “
Mandatory Preparation for System Conversion ” service component as part of the “ Build
Design ” service described later in this road map. The “Mandatory Preparation for System
Conversion” supports necessary preparation work (like Customer Vendor Integration) in system
conversion projects, which needs to be executed as part of the sandbox system setup.
Custom Code Cleanup & Improve is a preparatory step, which should help bringing the custom code in
your system into an optimal state or reducing the footprint even before a system conversion starts (this
activity may happen long time upfront of a conversion project). This will significantly reduce the
adjustment efforts within the project. Requirements and Constraints Custom code cleanup is of relevance
for system conversion. Custom code quality improvement is relevant for all scenarios. Procedure
Cleanup Unused Code: Unused custom code should be decommissioned before conversion starts, to
reduce the adjustment efforts in the conversion project. Moreover, ongoing operations efforts, and
maintenance efforts in future upgrade projects are reduced as well. Implement Custom Code Quality
Measures: Establish quality management for custom code in your company. This touches IT processes,
tools, and teams. Ideally you run a custom code quality improvement project upfront to test the new
quality measures, and to improve the custom code (e.g. avoiding bad programming styles). Results Custom
code is in a well state before conversion starts, or is at best quality at the design time for new code. How
SAP Can Support SAP has published excellent blogs on custom code management in the context of a system
conversion: To learn about the challenge, start with the SAP Blog “SAP S/4HANA System
Conversion – Challenge for your custom code” . To understand the necessary adaption
process for your custom code, look at: The SAP Blog “SAP S/4HANA System Conversion
– Custom code adaptation process” The SAP Blog “ABAP custom code
adaptation for SAP HANA – The efficient way” What you can (or better: should)
do well upfront of a planned system conversion is documented in the SAP Blog “What can you do
today to prepare your custom code for SAP S/4HANA” . This blog addresses both the cleanup as well
as the improvement of custom code quality. Finally, there is a blog series describing all relevant expert
tools required for analysis. The first issue is the SAP Blog “Remote Code Analysis in ATC – One
central check system for multiple systems on various releases” . You will find all links in the
accelerator section.
The objective of this task is to decommission custom code which is not in use upfront of a system
conversion. Although this task is optional, it is highly recommended to avoid adjustment efforts for coding
which is not required. Procedure Proceed as follows: Set up the Decommissioning Cockpit in SAP
Solution Manager. Decommission unused custom code as documented in the accelerator section.
Compare the list of used code (identified via UPL or business process documentation), with the custom
code inventory list. This helps you to identify code that is not in use. Results Unused custom code has been
decommissioned from the SAP system, and does not need to be adjusted in future. How SAP Can Support
In a first step and if not already done, SAP can help you setng up the required tools for custom code
management, and making you familiar with these. This service component is called “ Custom Code
Management Tools Enablement”: The Custom Code Management Tools Enablement service
component is to perform the CCM tools initialization and configuration in the customer’s SAP
environment and to facilitate the knowledge transfer about the tools operation to the customer’s
organization. Per default the project scope includes the implementation of Custom Code Lifecycle
Management and activation of Usage and Procedure Logging tool. Depending on the customer’s
requirements, the project scope can be extended to facilitate the configuration of other tools as well, e.g.
ABAP Test Cockpit, Clone Finder or Decommissioning Cockpit. The empowering part of the project includes
the knowledge transfer about the tools which are included in the scope. In a next step, SAP can help you
creating a tailored retirement strategy. This service component is called “ Custom Code
Retirement”: The Custom Code Retirement service component offers a customer-tailored strategy
for identification and decommissioning of unused custom code. Custom code retirement is one of the
important innovation readiness aspects, which allows the customers to reduce maintenance cost and free
up resources for innovative new projects. The purpose of proof of the concept for a custom code
retirement project is to set up a continuously running project for identification of custom code objects
which according to statistics collected in the production system are not being used. It helps the customer to
define the customer-tailored approach for the analysis of the objects - candidates for retirement, their
monitoring and decommissioning from the system(s) of the customer’s landscape. See accelerator
section for details.
The objective of this task is to improve the software quality of your custom code upfront of a system
conversion. It also seeks for quality improvement within the development process in general (thus relevant
for all scenarios). Please note: This task does not directly address the code adjustment necessary due to
the upcoming system conversion to SAP S/4HANA. Those will be in later project phases. Procedure Proceed
as follows: Set up an efficient custom code quality management process and project Implement the
corresponding Software Quality check tools, like SAP ABAP Test cockpit or SAP Code Inspector
Incorporate them in the development process Identify opportunities for side-by-side extensions with
SAP Cloud Platform, e.g., using Web IDE for Fiori UI’s. Test your newly implemented quality
measures by running a code quality improvement project. Results Quality measures for high code quality
have been established, and tested in a code quality improvement project. From now on custom code will
be will be created with the necessary quality level. How SAP Can Support In a first step and if not already
done, SAP can help you setng up the required tools for custom code management, and making you
familiar with these. This service component is called “ Custom Code Management Tools
Enablement”: The Custom Code Management Tools Enablement service component is to perform
the CCM tools initialization and configuration in the customer’s SAP environment and to facilitate
the knowledge transfer about the tools operation to the customer’s organization. Per default the
project scope includes the implementation of Custom Code Lifecycle Management and activation of Usage
and Procedure Logging tool. Depending on the customer’s requirements, the project scope can be
extended to facilitate the configuration of other tools as well, e.g. ABAP Test Cockpit, Clone Finder or
Decommissioning Cockpit. The empowering part of the project includes the knowledge transfer about the
tools which are included in the scope. In a next step, SAP can review your strategy on custom code quality,
and help you with a code quality improvement project. This service component is called Custom Code
Quality Improvement ”: The Custom Code Management Quality Improvement service component
offers a customer-tailored approach for an efficient custom code quality management. The purpose of a
custom code quality optimization project is to describe the overall quality management approach, the
related tools and necessary steps required to be performed in order to continuously monitor and improve
the quality of custom code objects in customer’s solution. In the project, current customer’s
quality improvement project is reviewed. An efficient customer tailored quality management for
identification of custom code objects with potential for code quality improvement is set up. SAP also offers
to check the security of your custom code. It can be done within the “ Custom Code Quality
Management ”service. This service helps to analyze and offer transparency on the security situation
of the existing custom code, including customer own objects and modifications. It identifies security
vulnerabilities in customer own ABAP code and provides the up-to-date know-how and best practices of
code security enabled by the SAP NetWeaver Application Server add-on for Code Vulnerability Analysis
(CVA). With the results of the analysis, the adjustments on custom code and security vulnerabilities can be
reviewed and mitigated in an early stage. This helps customer reduce efforts for change adoptions and
facilitates a smooth completion of the identified adjustments and vulnerabilities. SAP Enterprise Support
customers can:
In the activity Listen to the
Project Meet Platform
Delivery the Expert recording
Setup “ Guided
, all additional Custom
software which Code Management
is required to for
implement SAP S/4HANA is going to be set up or updated. Requirements and Constraints It depends on the
scenario what additional software is required: SAP Solution Manager is required for all scenarios. SAP
Solution Manager does both support project execution (e.g. scoping business processes together with SAP
Activate), as well as support operations of the new SAP S/4HANA system after Go-Live (e.g. via system
monitoring and root cause analysis). SAP recommends at least SAP Solution Manager 7.1 SP12. However,
end of mainstream maintenance for SAP Solution Manager 7.1 is set to December 31, 2017. SAP
recommends to enter release 7.2 as soon as possible. This road map considers SAP Solution Manager 7.2 as
available. In case this release level is not available on premise, SAP offers SAP Solution Manager also via
Cloud Appliance Library (CAL). Landscape Transformation Software is required for LT scenarios. Data
Migration Services is one option for new installations where business data needs to be transferred from
legacy systems into the newly created SAP S/4HANA system. Procedure In the Prepare phase SAP Solution
Manager is set up and configured. The tools for Landscape Transformation and Data Services need
additional planning activity, and are configured later in the Explore phase. Set up and configure SAP
Solution Manager Import the Best Practices content to SAP Solution Manager Results SAP Solution
Manager has been set up for project work.
There should be at least an SAP Solution Manager 7.2 already set up and configured on premise. See
Accelerator’s section for more details how to set up SAP Solution Manager. Procedure In case
there is an SAP Solution Manager 7.2 available on premise, update to the latest support pack. In case
this release level is not available on premise, SAP offers SAP Solution Manager also via Cloud Appliance
Library (CAL), and use this SAP Solution Manager for project support. The general sequence for the
implementation of an SAP Solution Manager system is as follows: You plan the implementation
(such as scope, hardware and software requirements, and release restrictions). You plan the system
landscape for your use cases. You install the components of your SAP Solution Manager system.
You configure your system. You set up the connection to the managed systems.
Once SAP Solution Manager is set up, the following areas are key for project support: Solution
Implementation – the identification, adaptation, and implementation of new and enhanced
business scenarios. Solution Documentation – centralized documentation repository
ensuring the relationship of business process definitions with technical configuration decisions.
Change Control Management – synchronized deployment of application configuration with
integrated project control and quality management. SAP provides customers with a SAP
Solution Manager toolset that supports customers in implementation of the project standards for the
purposes of the project or operations. It is highly recommended for new implementation scenarios to use
the SAP Solution Manager Focused Build solution. Additional details can be found in the
accelerator section. It also contains a link to an overview presentation which documents how
Focused Build and SAP Activate nicely fit together. Results You have set up SAP Solution Manager, and
configured for project support. How SAP Can Support SAP install SAP Solution Manager for you. The
corresponding service offer is called “ Implementation of SAP Solution Manager for IT Operations
”. Please ask your SAP contact (e.g. SAP Client Partner) for more information. Alternatively consider
using SAP Solution Manager from the Cloud Appliance Library (CAL). Finally, SAP offers an “ Agile
Methodology and Tool Coach ” service component as part of the “ Safeguarding the Digital
Transformation ”. SAP Enterprise Support customers can listen to the Meet the Expert recording
“ SAP Solution Manager 7.2 for SAP S/4HANA ”. The session: Explains how to plan, build,
and run SAP S/4HANA with SAP Solution Manager 7.2 Provides an overview of SAP S/4HANA strategy and
planning services delivered via SAP Solution Manager Explains how to use SAP Activate content for SAP
S/4HANA in SAP Solution Manager.
The purpose of this task is to import the SAP Activate Best Practices content into SAP Solution Manager.
Prerequisites SAP Solution Manager 7.2 is available for project support. Procedure The following screen
shot shows a Best Practices business process diagram in SAP Solution Manager. Figure: Process diagram in
SAP Solution Manager 7.2 Follow the detailed instructions given in chapter “Identify, select and load
SAP Best Practices content into SAP Solution Manager 7.2” in the Best Practice Reference Guide, to
import SAP Activate Best Practice content into SAP Solution Manager 7.2. After import, the Best Practice
process diagrams including documentation and test scripts are available in SAP Solution Manager, and can
be used and tailored in the sub sequent Fit / Gap workshops with the business process champions. Results
The newest Best Practices content is available in SAP Solution Manager for the project team. How SAP Can
Support See service component “ Agile Methodology and Tool Coach ”, which consists
of a single point of contact, who is responsible for all activities around the implementation and operation of
focused build. The focused build coach is your contact to discuss all topics related to implementation
methodology. He or she makes sure all issues are resolved and that you receive the included configuration
services and trainings at the right point in time with the right skills from SAP.
An important part of the Prepare Phase of a project is the formal setup of the project. This needs to be
aligned between SAP and the customer. The assumptions with respect to Project Management are
as follows: The customer has bought one of the four SAP Value Assurance service packages.
The Safeguarding the Digital Transformation is part of each and every Value Assurance
package. The Safeguarding the Digital Transformation consists of the SAP Technical Quality Manager
( TQM ), the access to SAP’s Mission Control Center and Premium Mission Critical Support.
The SAP TQM is your contact partner to discuss all topics related to your transition project. The TQM makes
sure that all issues are resolved and you receive the services and support activities at the right point in time
with the right skills from SAP. SAP TQM tasks and deliverables: Setup of the governance
structure for your project Leadership for scope definition and execution of all tasks done by SAP
Definition and review of quality gates SAP Mission Control Center : Access to
the whole SAP back office organization including SAP Development Verification of engagement plans
Access to premium mission critical support Support for gap clarifications There
is a project manager from the customer and/or implementation partner , and the SAP TQM who
supports to run this project. The roles and responsibilities in the project, especially those that are leading
the project (customer or partner) are defined. The customer is managing the project by either using a
3 rd party software (e.g. Microsoft MS Project), or SAP IT Portfolio & Project
Management. SAP provides project templates for download as a starting point, which need to be
adapted to the customer project specifics . The Quality Gates are managed in SAP
Solution Manager by the SAP TQM. All important documents and Quality Gate check lists are
stored there. There are several applications in SAP Solution Manager to service this aim: IT
Portfolio & Project Management (ITPPM; formerly known as cProjects) Project road map
(transaction RMMAIN) Project Management (transactions SOLAR*) As of SAP Solution
Manager 7.2 ITPPM should be used for managing Quality Gates. Documents that need to be shared
across the project team (e.g. Risk-Response-Log), are stored in SAP Solution Manager , e.g. by attaching
them to the corresponding activity and/or task in SAP ITPPM. Alternatively, in case of SAP Value Assurance,
SAP JAM could be used for sharing documents across the project teams. Quality Gate check lists can be
sent to SAP for reporting and safeguarding reasons . Project management in the context of an SAP
implementation has been documented in detail in SAP Activate road maps (e.g. “SAP Activate
methodology for Business Suite and On-Premise – Agile”). See accelerator section for
a link. All general project management activities, tasks, and accelerators can be taken from there, by
filtering on the Project Management work stream. This road map focuses on additional project tasks which
are owned by the SAP Technical Quality Manager (TQM). Requirements and Constraints This activity is
required for all scenarios. Procedure Conduct Handover Meeting(s) from Opportunity Phase
Review Order Form with Customer Identify Stakeholders, Stakeholders’ Requirements and
Expectations and Project/Deliverable Acceptance Criteria Set Stakeholder Expectations for Agile Project
Create Project Charter Create Project Management Plan Results Once this activity has been
completed, the transition project has been
The purpose of this task is to efficiently successfully
transition initiated.
the project fromHow
theSAP Can Support
opportunity teamSAP supports
to the this
delivery
team. During this task the project manager schedules and conducts internal meetings to transfer key
information from the opportunity phase into the project. Procedure Typically, during these calls the
account team and project team review the following areas: project background, business case, business
drivers, customer goals, scope, RACI, success metrics for the project, customer expectations, delivery
model, Statement of Work, Order Form, assumptions.
The purpose of this task is to clarify any questions in regard to the Signed SAP Contract (SOW), Order
Form, confirm scope, RACI and resolve any issues. This includes review of the delivery model. Procedure
Review Order Form Assumptions Review Order Form Scope Review Order Form RACI Review Order
Form Resources & Budget Review Order Form Customer Staffing Review Order Form Solution
Scope
The stakeholder identification process is a critical process of initiating the project and aligning the project
objectives with the expectations and requirements of the stakeholders. It is critical for the success of the
project to identify, involve stakeholders and keep them engaged throughout the project.
The purpose of this task is to build agile awareness of key stakeholders, secure commitment to adopt
standard SAP functionality where possible. It is recommended to conduct informal and formal meetings to
set the expectations and confirm the project approach with key project stakeholders.
The Project Charter formally document the business needs and benefits of the project to confirm
alignment with customer key stakeholders. It authorizes the project and is based on the Order Form(s) and
Business Case. This document outlines the purpose, high level approach and key characteristics that define
the project. The key benefit of creating the Project Charter is a well-defined project start and boundaries,
and a direct way for senior management to accept and commit to the project. Project Charter Contents
Current Situation Proposed Resolution Solution Description Project Goal Project Objectives
Business Case Summary Total Estimated Project Costs Key Dates Project Stakeholders Critical
Success Factors Risk Assessment Procedure Define Project Purpose or Project Justification and
measurable Project Objectives High-Level Project Description and Boundaries Project Success and
Approval Criteria Assumptions and Constraints High-Level Requirements High-Level Solution and
Project Scope Summary Milestone Schedule Summary Budget Stakeholder Group and Key
Names Stakeholders High-Level Risks
The Project Management Plan is the document that describes how the project will be executed, monitored
and controlled. It integrates and consolidates all subsidiary plans and baselines from the planning process.
Procedures Establish Scope Baseline Establish Schedule Baseline Establish Cost Baseline
Establish Quality Baseline Define Scope Management Plan Define Requirements Management Plan
Define Schedule Management Plan Define Cost Management Plan Define Quality Management Plan
Define Process Improvement Plan Define Human Resources Management Plan Define Communications
Management Plan and Project Reporting Standards Define Risk Management Process Define
Procurement Management Plan Define Stakeholder Management Plan Define Change Management
Process Define Issue Management Process Define Project Constraints Define Project Standards
Obtain Project Management Plan Sign-Off
Project Governance is an oversight function that is critical to the success of the project. It provides the
project manager(s) with a framework for consistently managing and controlling the project which includes
tools for decision making, role definition, responsibilities, accountability and the alignment of stakeholders
around the purpose of the project.
The purpose of this task is to determine the structure and composition of the team and to ensure that roles
and responsibilities are clearly defined. The assignment of people to roles should also take into account
their qualifications and availability for the whole project time frame.
The purpose of this task is to define the organizational structure of the project team.
The purpose of this deliverable is to review the project management plan and the subsidiary plans on the
basis of the project scope defined in the project charter.
The purpose of this deliverable is to properly plan the project to guide both project execution and project
control.
The purpose of this task is to prepare the scope document with the pre-defined content according to the
Statement of Work (SOW) and solution documentation.The project scope statement evolves through the
initiation and planning of the project and clearly and explicitly defines the deliverables of the proposed
project. This information and supporting documents align key stakeholders around what the project is
going to deliver.
The purpose of this task is to create the work breakdown structure (WBS) for the project, which is a
deliverable-oriented, hierarchical decomposition of the work to be executed by the project team to
complete the project. It is the basis for the organization and coordination of the project. A WBS consists of
WBS elements that describe project tasks and subtasks to perform within a defined time period. Top-
down view of how activities fit into the overall project structure Defines the total scope of the project
(specified in the approved scope statement) Work packages at lowest level can be subdivided into
activtities/tasks
The purpose of this task is to create a project schedule. The detailed project schedule defines the work to
be performed, the resources and associated time commitments required for the project, and the individual
phases of the project. The work breakdown structure (WBS) serves as the foundation for the project
schedule and deliverables to be produced as part of the project. Procedures: Define Activities Sequence
Activities Estimate Activity Resources Estimate Activity Durations Develop Schedule
The purpose of this task is to create a project budget, that outlines all the costs associated with the
project, including labor, hardware, software, cloud provisioning, contracting fees, and facilities. The project
budget is a living document that the project manager maintains. At this stage the project manager sets the
budget baseline and will manage the budget according to the cost management plan that is developed as
part of the Project Management Plans task. Procedures: Estimate costs Determine Budget
The purpose of this task is to identify the standards of the project and how the quality will be managed and
valided throughout the implementiation of the project.
The purpose of this task is plan the commincation Management plan and define the communication
requirements for the project.
The purpose of this task is to plan and define the project risks. Procedures: Identify Risks
Assess Risks : Estimating and Evaluating Risk Create Risk Register ( refer to the "Risk Register
Template" provided ) Define Risk Responses
The purpose of this task is to plan and prepare the guidelines for all the procurement activities on the
project. This includes materials, products or services identified for outside
procurement.
The purpose of this task is to plan the appropriate management strategies to identify and engage
stakeholders.
The purpose of this deliverable is to kick-off the project and ensure that all needed information is shared
with the project team resources, key stakeholders, and anybody involved in the project. The goal of the
kickoff meeting is to ensure that everybody involved in the project understands the goals and objectives of
the project, as well as the schedule that the project team will follow, which is one of the key ingredients for
a successful project execution.
The purpose of this task is to prepare the kick-off meeting which will help ensure the involvement of the
team and other key resources and their commitment to the project schedule.
The purpose of this task is to schedule and prepare the project kick-off meeting. The kick-off meeting
includes discussion of project objectives, organizational structure, roles and responsibilities, project
governance, schedule, scope, communication standards, change request process, and decision-making
process. The kick-off meeting is attended by the project team, key stakeholders, project sponsor and
company executives. Some resources may attend the kick-off meeting remotely. In such cases it is
important to ensure good audio and video infrastructure so the remote participants can take full part in the
kickoff meeting session. Use the attached accelerator as a template to prepare kick-off meeting materials
specific to your project
The purpose of this activity is to prepare the onboarding package for external consultants from SAP and
partner companies.
The purpose of this activity is to prepare the on-boarding package for external consultants and new project
team members from SAP and partner companies coming to the project. The on-boarding package contains
the essential information that each new team member needs to understand, which is the purpose of the
project, goals, operating procedures, and other key information. The on-boarding package typically
contains the following information: Project objectives, scope, and goals including SAP solutions being
implemented Project schedule including milestones Project governance including key project
stakeholders Organizational chart for the project-showing both internal and external resources Overview
of the existing SAP landscape Outline of regular project meetings Travel policies, dress code, project
location, and other project guidelines as needed.
The purpose of this deliverable is to provide consistent means of executing and governing project work in
an efficient and effective manner. The key objective of Project Standards is to identify, define, approve, and
communicate standards related to project execution. Where and when applicable, the current customer
processes and procedures, related to the project standards should be taken into account when defining the
most suitable standards for the project. Project team needs to setup tools like SAP Solution Manager to
enable execution of specific project standards. The SAP Solution Manager application management
solution is included in customer’s SAP maintenance agreement, and provides all integrated content,
processes, tools, and methodologies you need to efficiently implement, operate, monitor, and support all
your SAP and non-SAP applications. SAP Solution Manager is also the hub for collaboration within the SAP
ecosystem, to ensure delivery of high-quality services and support for your mission-critical business
processes. This enables better operations and faster implementation at lower costs. Procedure: Install and
Setup SAP Solution Manager Setup Project Team Logistics and Infrastructure Setup and Test Remote
Support
The purpose of this task is to identify, define, approve, and communicate standards related to project
execution. Project standards provide a consistent means of executing and governing project work in
an efficient and effective manner. Project standards are elaborated throughout the Prepare phase (some
may be fine-tuned in a later stage of the project). During the Prepare phase the foundational project
standards must be defined, approved, and communicated to the project team. Communication of project
standards should be included in project on-boarding communications for project team members. Given the
integrated nature of project standards, changes must be managed in accordance with the integrated
change control procedure. The project team needs to establish, at minimum, the project standards for the
following areas: Requirements Management Business Process Modeling Solution
Configuration and Documentation Custom Code / Development Authorizations /
Security Test Planning and Execution Change and Release Management Post-
implementation Support and Operations.
The purpose of the Operational Standards task is to provide consistent means of executing and governing
project work in an efficient and effective manner. The key objective of Project Standards is to identify,
define, approve, and communicate standards related to project execution. Where and when applicable, the
current customer processes and procedures, related to the project standards should be taken into account
when defining the most suitable standards for the project. Determine Solution Documentation Procedure
The purpose of this task is to determine the customers framework to centrally document and relate
business processes and technical information of SAP and non-SAP Solutions in Solution Manager, ensuring
transparency, efficient maintenance and collaboration. Determine Solution Implementation Procedure The
purpose of this task, also known as Innovation Management, is to determine the customers approach for
the identification, adaptation and implementation of new and enhanced business and technical scenarios.
It is part of the application lifecycle and designed to decouple technical installation from business
innovation using SAP Solution Manager to implement the innovation in the system landscape. Determine
Template Management Procedure The purpose of this task is to determine the customers template
management approach that allows customers with multi-site SAP installations to efficiently manage their
business processes across geographical distances - from initial template definition to template
implementation and template optimization, for example as part of a global rollout. Determine Test
Management Procedure The purpose of this task is to determine the customers approach for managing
functional and performance testing of SAP-centric business processes to ensure validated system behavior
after software change events. Determine Change Control Management Procedure The purpose of this task
is to determine the customers approach of handling business and technology-driven changes, using a
standardized process leading to improved reliability of solution and minimized risk through segregation of
duties and transparency of changes. Determine Application Incident Management Procedure The purpose
of this task is to determine the customers approach of a centralized and common incident and issue
message processing for multiple organization levels. The process offers a communication channel with all
relevant stakeholders of an incident, including business user, customer-side SAP experts, SAP Service
& Support and Partner Support employees. The Application incident Management is integrated in all
ALM processes of SAP Solution Manager, in any SAP Business Suite solution and can be connected to an
Non-SAP Help Desk application Determine Technical Operations The purpose of this task is to determine
the customers approach of monitoring, alerting, analyzing and administrating of SAP solutions. It allows
customers to reduce TCO by predefined content and centralized tools for all aspects of operations in SAP
Solution Manager, including End-to-End reporting functionality either out-of-the-box or individually created
by customers. Determine Business Process Operations This task uses SAP Business Process Integration
& Automation Management (BPIAM) to cover the most important application related operations
topics necessary to ensure the smooth and reliable flow of the core business processes to meet a
company's business requirements. Determine Maintenance Management The purpose of this task is
to determine the customers approach of Maintenance Management, how SAP Notes are handled and how
they are applied (upon request e.g. current incident in productive environment, information from SAP
about potential
The purpose issuetask
of this (Hot
is News, Security
to define Notes).
and set Determine
up SCRUM Upgrade
standards Management
and tools, such as SCRUMThe purpose
board, burn-of
down chart, product backlog template and retrospective template. Organization of daily stand-up
meetings, scrum-of-scrum-, release/sprint planning and retrospective meetings. At this time the project
also needs to prepare definition of Ready and definition of Done for each critical step in the iteration. At
minimum the team needs to prepare and agree on definition of Ready and Done for following: Ready for
Build (e.g. backlog item has proper size, it is clearly defined and understood, test procedure is defined, etc.)
Ready for Demo (e.g. backlog item is fully developed and unit tested) Ready for Integration Test
(e.g. backlog item integration test is defined (automated), test data is ready) Ready for Release (e.g.
backlog item user level documentation is complete, ALM Solution Documentation is ready, Feature passed
Integration Test) Note that definition of Ready for one step in the implementation process == definition of
done of the previous step. Using clear definition of Ready and Done is critical for SCRUM based
implementations.
SAP Solution Manager supports heterogeneous system environments. Its functions cover all aspects of
implementation, deployment, operation, and continuous improvement of solutions. As a centralized,
robust solution, SAP Solution Manager combines tools, content, and direct access to SAP, to increase the
reliability of solutions and lower total cost of ownership. SAP Solution Manager is the pivotal hub for
collaboration in the ecosystem, as it empowers communication between all the stakeholders in a solution,
including project teams, SAP partners, consulting and SAP Active Global Support. SAP recommends
customers to utilize the pre-configured environment for SAP Solution Manager Focused Build that will
provide ready-to-run SAP Solution Manager environment. Alternatively, the customer may decide to install
and setup the SAP Solution Manager following the installation guide, that provides step-by-step process for
installation and setup of SAP Solution Manager. The general sequence for the implementation of an SAP
Solution Manager system is as follows: You plan the implementation (such as scope, hardware and software
requirements, release restrictions). You plan the system landscape for your use cases. You install the
components of your SAP Solution Manager system. You configure your system. You set up the connection
to the managed systems. The objective of this task is to check availability of SAP Solution Manager
environment for the project team. This should be validated early in the project, if not before the project
starts. If there are no setup activity needed to be planned to install Solution Manager, ensure that the
technical team has completed the general Solution Manager set-up and then has covered the process
specific configuration in the following areas: Process Documentation ITSM Project Management
and Requirements and activities scheduled to include the set up of: Test Management Change
Control Management Application Operations Please ensure the following has been completed by the
technical team: customer specific access roles have been created access roles created to provide digital
signature approvals to documents users created in the system (with appropriate access roles) and
Business Partners created and connected to users for all project team members users can all access SAP
Solution Manager and there is an appropriate schedule of project team training for each project phase /
key activity using SAP Solution Manager. the procedure for requesting access to SAP Solution Manager and
other systems and tools is agreed, setup and communicated
The objective of this task is to setup physical project team environment and ensure that the project team
members have appropriate level of access to the customer facility, project room and the project systems.
This activity also involves the setup of project team work stations/computers and/or mobile devices (as
necessary for the project support). The project manager together with the technical team works on setup
of following (the questions in each area are geared to help provide guidance): Project Equipment Is
there a requirement for hardware (e.g. servers,laptops, etc.)? Are there any additional software licenses
required? Are the software licenses purchased? Was the software installed for the project team
members? Is there an area planned for the project equipment? Is there project equipment located in
different geographical sites? Is there any computer lab required for the project? Physical Project
Environment Has the required work space been arranged at all project sites? Are there sufficient
conference rooms planned for the project team? Has multimedia equipment been planned for all
conference rooms (e.g. video conferencing, projectors, etc.)? Has physical access been granted for all
project team members in different geographical sites? Is there a working area assigned to the project
members? IT Infrastructure and Access Is the LAN access available to the Project Team? Has the LAN
access been tested? Do the Project Team Members have the necessary printer drivers installed? Have
IT access been granted for the following: E-mail servers Internet access, Intranet access
Team collaboration space like SAP Jam MS-Office Project team specific applications
like modeling tool, test management tools, etc. Customer Policies Is there a specific project
policy applicable (communication, confidentiality, back-up, etc.)? Has the project policy been
communicated? Physical Security Has all necessary access been granted indifferent project sites? Have
all sites policies been communicated (e.g.security, safety, emergency exits and etc.)?
Telephone/Voice Mail Is there a telephone number issued to project team members? Has the
Project Team Member been told how to set-up the voice mail? Is there a central phone book for the
project team members? Project Team Member Equipment Is the required equipment (computer, laptops,
mobile and etc.) available to all project team members? Are office supplies available to the project
member? Are the required software licenses purchased? (if needed)
SAP customers are advised to set up remote access to SAP Support to ensure timely response to incidents
and support tickets. Set up remote access so that support can quickly diagnose and solve incidents you
report, without needing to be at your desk or on the phone. This is especially helpful when dealing with
different time zones. In addition to solving your incidents faster, setng up a remote connection between
your company and SAP will also allow you to receive services, such as Early Watch, and Continuous Quality
Checks, that you may be entitled to through the Support Programs your company has purchased. Follow
the guidance on SAP Support Portal linked from the accelerators page to setup the remote access.
The purpose of this deliverable is to execute the project management plan and control and monitor the
work defined in the project scope statement. Management plans developed during the project preparation
phase (see deliverable "Project Management Plan") guide the approach to management,
execution, and control of project activities. The project manager is responsible for ensuring that the
management plans are applied at the appropriate level of control.
The purpose of this activity is to assure that the project is executed according to what was agreed to in
project charter, scope statement and project management plan.
The purpose of this activity is to assure that resources are assigned to all scheduled project activities (and
tasks) and that work is progressing and deliverables are produced as expected.
The purpose of this activity is to capture and manage project issues and risks and changes related to those
e.g. changes of project scope, timelines, costs etc.
The purpose of this activity to make sure that project stakeholders are aware of status and progress of the
project including potential disturbances due to existing risks and issues.
The purpose of this deliverable is to present an overview of all planned change management activities. It
guarantees that all activities are related to each other as well as to the overall project plan and ensures the
"checkability" of OCM activities.
The purpose of this activity is to collect all required input for the OCM roadmap and document it in a
format suitable for communication and inclusion into the project management plan.
The purpose of this workshop is to align with the entire project management team regarding OCM
activities to be conducted. The OCM roadmap, along with the stakeholder analysis on hand at this stage
should be shared. An initial communication strategy should be drafted as part of this workshop.
The purpose of the phase closure and sign-off deliverable is to: Ensure that all required deliverables from
this phase and the project are complete and accurate, and close any outstanding issues Identify
lessons learned during the phase to prepare for formal phase closure Capture customer feedback and
potential Customer References
The purpose of this task is to collect knowledge assets and lessons learned at the end of each phase of the
project that can be reused later by other projects. Collecting documents, experiences, project highlights
and lessons learned throughout the duration of the project can help to facilitate the project by providing
quick access and insights into key deliverables from earlier stages of the project.
The purpose of this task is to conduct regular quality checks at defined or critical stages of the project
lifecycle to assess the health of the project: Specifically checking deliverables been completed with
recommended practices Assuring project planning Validating open risks and issues, and measuring
customer satisfaction The deliverables assessed at each quality gate will be performed using the quality
gate checklist /PtD System with defined expectations to the maturity of particular project deliverables
/aspects. Note(s): New additional key deliverables need to be added in the quality gate checklist
by the Project Manager to the different project types.
The purpose of this task is to execute a Project Management Review that provides a proactive quality
assurance review, with an impartial analysis of all aspects of the project - across all project management
disciplines, enabling early detection of project issues with actionable recommendations.
Purpose of this task is to obtain customer approval (sign-off).
Once the prepare phase has been finalized considering a detailed planning for the functional and technical
work streams the Explore phase will be kicked off. The activities of the Explore phase are displayed in the
following picture. Figure: Activities in the Explore phase In the Application: Solution
Adoption work stream, the training strategy is developed for the end users. In the Application: Design
& Configuration work stream, the results from the SAP S/4HANA Value & Impact Strategy will
feed into the fit / gap analysis and delta design workshops (per business priority in scope). Gap validation
and a final design review support this activity which is usually executed in an agile manner. SAP S/4HANA
keeps the business data in main memory. To minimize the resource requirements for the new hardware
and reduce the time for the conversion, you may want to reduce the size of the productive database before
conversion. Additional SAP S/4HANA applications, like the setup of Central Finance in a landscape
transformation scenario, or the setup of an SAP Digital Boardroom, are planned in this phase as well. In this
step the detailed security status overview is to be planned. The SAP S/4HANA specific security strategy and
high-level road map is to be defined. The conversion to SAP S/4HANA may impact your custom code. A first
list of impacted custom objects has been identified in the SAP Readiness Check for SAP S/4HANA. In the
Custom Code Extensions work stream, you will need to identify and prioritize affected custom objects that
are used productively, and that have to be adjusted as part of the system conversion project. Based on the
anticipated application changes customers should also start creating a strategy for testing and end user
training ( Application: Testing work stream). In the Application: Integration work stream , integration design
work starts in proper alignment with the to-be application design, to properly integrate the SAP S/4HANA
system in the solution landscape. First basic integration setup activities are performed for the sandbox (if
required) and for the development system. In the System & Data Migration work stream , customers
will need to further prepare the platform for project delivery. This touches SAP Solution Manager, and
additional components depending on the implementation scenario. A sandbox is created for technical and
functional experience gathering. Of course it depends on the scenario how the sandbox is created. In case
of a new implementation or a landscape transformation, data load needs to be prepared and planned in
the Data Migration Design service. At the end of the Explore phase the DEV environment needs to be set
up (again scenario specific). The technical design document is created in the Technical Architecture &
Infrastructure work stream . Transition to Operations runs an Operations Impact Analysis, to identify IT
Support operational areas that require adjustment to safely and efficiently operate SAP S/4HANA as of Go-
Live. The actions taken here depend on the SAP operational experience of the customer. Please note : The
order activities are explained in this document / road map viewer, is not necessarily the order how they are
later executed in the project! However, there can be dependencies between activities. For example, the
technical setup of a sandbox system (activity Sandbox System Setup ) must be finished first before the
functional preparation and finalization of the sandbox can take place (activity Activate Solution ). In case
you are interested in time dependencies / relationships between activities, consider the project file
template of this road map.
The purpose of the phase initiation deliverable is to formally recognize that a new project phase starts.
The purpose of this task is to review all Deliverables of the Explore Phase with the Customer.
The purpose of this task is to review the acceptance criteria with the Customer.
The purpose of this task is to review the RACI Chart for the Explore Phase with the Customer.
In this activity, the training requirements for key user and end users are analyzed and documented. Based
on the analysis, a training plan will be designed, and executed in the following project phases.
Requirements and Constraints This activity is required for all activities. It is based on an initial assessment
processed in the Prepare phase of the project (see activity Transition Planning) . The project team has been
enabled already, and is not in scope of this activity. Procedure Develop a Training Concept Results A
training concept has been developed for key users and end users.
The objective of this task is to develop a training concept for key users and end users based on
planned applications, existing skills levels, knowledge gaps, and locations of training requirements.
Procedure A first assessment on training requirements has been performed in the Prepare phase of the
project (see activity Transition Planning , task Run a first Assessment on Training
Requirements for details). This task should further refine this assessment, and develop a training
concept for key users and end users on top. Proceed as follows: Further re-evaluate the business processes
(including user interfaces) in scope for implementation, and analyze the required skills. Evaluate SAP
individual standard training from SAP Education courses (Classroom and Web-based Trainings) Develop
and document a training concept including obligatory and recommended training per user role, mentoring,
coaching, and in alignment with the project plan Per future role, assign users to trainings. Please keep in
mind: Skills levels, knowledge gaps, and training requirements could depend on the location of end
users. Special care needs to be taken for key users: Key users are often involved in various
implementation activities throughout the project (e.g. testing the newly implemented functionality).
Therefore, they need to be trained early. Key users could potentially support and run in end-user
trainings. After Go-Live, key users play an important role in customer’s incident
management process. In case of issues or questions, end users can contact their local key users first, before
filing an incident. SAP recommends establishing a network of well-trained key users as part of the
transition project. Results A training concept has been developed and documented. How SAP Can Support
SAP can support this task with the “ Enablement Analysis ” service component as part of the
“ Build Design ” s ervice . The service component can address three aspects: Enablement
Concept The enablement concept analyzes the current end user situation and clearly defines the high-level
training strategy. It is important to first understand the customer digital learning context and to define
methods to identify and create the learning content. The concept defines the scope, objectives,
deliverables, schedule, and benefits of the Solution Adoption work stream. Moreover, it includes the
process of identifying, developing and maintaining the required skills and Performance Support Materials.
The Enablement Analysis service component clarifies if current training capabilities are sufficient for an
effective training delivery, and makes necessary investment decisions transparent as early as possible.
Key User Network A key user network is an essential method of knowledge transfer in digital
transformations. Building and managing a key user network will help to enable end users. In addition, the
network may take part in other important activities such as testing, change request management, and first
level support. The Enablement Analysis service component helps to establish a well-performing key user
network. Learning Needs Analysis for Key and End User The essential step for creating knowledge
transfer in transformation projects is the identification of the learning requirements and the analysis of the
digital learning opportunities for key user & end user. Matching the results of the change impact
analysis with the training needs will identify skill-gaps for specific groups. The LNA as part of the Enabling
Analysis identifies learning needs for the two groups, and comes up with the required enablement
portfolio. Please note that the training of the key users and end users is not included in SAP Value
Assurance, but is handled separately by SAP Education. See accelerator section for details.
The purpose of this activity is to ensure that a functional system is available to be used for demonstration
and visualization purposes during fit gap sessions. This is an essential part of the overall implementation
strategy as this is the foundation to start with a pre-configured solution already during the explore phase.
The scope for the activation should be reconfirmed, based on the results out of the discovery and
preparation phase. For new implementations, the activation of the best-practice content, or the
implementation of an SAP Model Company (see task Define Cutover Approach in the Prepare phase ) will
be provided. For system conversions, the provisioning of the sandbox system is in scope. This is the
baseline for exploring the solution functionality that has been included in scope and for confirming that the
business needs are addressed. Activated content will be presented during fit-gap sessions per solution
capability in order to determine relevant deltas so that the solution matches the business needs.
Requirements and Constraints This activity is required for all scenarios. Precondition is that the technical
SANDBOX system has been set up already but without further configuration – see activity
Sandbox System Setup in this phase. If not already done in the Project Delivery Platform Setup
activity (Explore phase), SAP recommends to install or update SAP Solution Manager to the latest version.
This includes: The technical installation of SAP Solution Manager on one client The
implementation of the technical baseline of SAP Solution Manager to use basic functions:
Connection of SAP Solution Manager using the Managed Systems Configuration Wizard to the three system
landscape Connection of the three system landscape to the Monitoring and Alerting Infrastructure
(MAI) Setup of basic functions like Early watch Alert, Diagnostics and the collaboration platform
with SAP. Procedure The procedure differs depending on your scenario: In case of system conversion,
mandatory system preparation needs to be finalized. In case of a new implementation, the
activation scope should be reconfirmed. Content activation should happen accordingly. Either
way, make sure that SAP Fiori is properly configured in the sandbox. How SAP Can Support SAP Enterprise
Support customers can join the Expert Guided Implementation for “SAP Fiori Configuration on SAP
S/4HANA” in case SAP Fiori has not been properly set up in the sandbox already. The goals of this 4-
days training are: Basic SAP Gateway Configuration SAP Fiori Launchpad initial setup SAP Fiori UX
configuration and Administration Embedded Search setup Me Area, App Finder, SAP Easy Access
Menu configuration Notifications and Notification Channel setup Development Overview Theme
Designer See accelerator section for more details.
In case of a system conversion it might be required to run post-conversion activities e.g. in finance area.
Procedure Run post-conversion activities according to the Conversion guide, and depending on the
functional area in scope. Typical post-conversion activities are posting activities in MM, or customizing and
data migration activities in FI-AA. Properly document your activities in the conversion cookbook (see
activity Sandbox System Setup in this project phase). A relevance analysis for Fiori apps based on the usage
of the existing system allows a first UI scoping. Using a list of transaction codes uploaded to the SAP Fiori
apps reference library, the “Relevance and Readiness Analysis” (open the SAP Fiori App
Reference Library, and click on “Learn more” on the left side of the screen; see accelerator
section) provides a list of SAP Fiori apps that fit the business processes in scope. The Fiori apps have to be
installed separately. The whole installation process can be simplified by using the SAP Maintenance
Planner. More details are given in the activity UX Activation and Design . All app-specific prerequisites need
to be available according to the information in the Fiori App Reference Library before carrying out the
following; Creating Fiori Users Connecting SAP Gateway to SAP S/4 HANA System Configuring
SAP Web Dispatcher (Fact sheets only) Setng up the Fiori Launchpad and Launchpad Designer
Generic Configuration for Fact Sheet Generic Configuration for Analytical App Review basic
security set-up and configuration. Note that some of the configuration differs between an embedded
landscape (backend and frontend in the same machine) and a Central Hub set-up (having frontend and
backend separated). SAP recommends a Central Hub deployment. In case the sandbox has been derived
from the production system it is also recommended to run the data consistency check reports listed in the
Conversion guide, to identify data inconsistencies which need to be tackled in production.Please also see
the lessons-learned document on finance in the accelerator section for more details How SAP Can Support
SAP supports this activity with the “ Mandatory Preparation for System Conversion ” service
component is part of the “ Build Design ” service – see the description of services and
service components in the accelerator section. SAP also offers an integrity check of FIN master data and
transactional data. This offering from the SAP support if offered to SAP Premium Engagement customers,
and is called “ Financial Data Consistency Check ” (FDCC). FDCC is a remote service with
focus on the detection, analysis, root cause identification and documentation of inconsistencies. The error
correction needs to be handled separately. Please contact your SAP TQM for more information.
In this task the business process scope of the sandbox system is reconfirmed, to avoid a mismatch in
process configuration. Procedure Based on the results of the discovery and preparation phase, the best
practices scope must be confirmed, as this will be the baseline for the relevant content structure of the
project and the activation of the respective best practices. In case of best practices content from SAP
Activate, please look up the individual scope items in the SAP Best Practices Explorer. Alternatively, study
the best practices content of SAP Activate in SAP Solution Manager 7.2 after successful import. In case
you take use of an SAP Model Company, see the detailed process description which is part of the package.
The objective of this task is to activate / validate the Best Practices configuration. Procedure The general
activation procedures have been already described in the activity Sandbox System Setup in this phase.
In case of using a software appliance (either in cloud, or on premise), the sandbox is already preconfigured.
The appliance comes with four clients: 100: Fully activated trial client 200: Best Practices
ready-to-activate client 300: Best Practices fully-activated (white list) 400 Best Practices fully
activated (merged with client 000). Either you can use one of the fully activated clients 300 or
400 – in this case there is no additional activation required – or you start from client 200, and
selectively activate the best practice content depending on your functional scope, by using the Solution
Builder. In case you have installed a fresh SAP S/4HANA system, you will need to import the newest best
practice content (if not already done as part of the activity Sandbox System Setup ), and select and
activate the content based on your functional scope, by using the Solution Builder. See the Administration
Guide for details. Please note, that in this case, the Fiori apps have to be installed separately. The whole
installation process can be simplified using the SAP Maintenance Planner. The Maintenance Planner helps
to plan the installation and to easily generate and download a consolidated “stack.xml”.
In case you are using an SAP Model Company, the technical activation of the SAP Model Company is
explained in a handover workshop which is part of the model company package. The procedures differ per
SAP Model Company. Please look at the info sheets you will find for all Model Companies on the landing
page at SAP.com (accelerator section). How SAP Can Support In case SAP Activate can be used, SAP
supports this activity with the “ Activate Solution ” service component as part of the
Build Design service. In case of an SAP Model Company, content activation and hand-over is part of
the SAP Model Company package. SAP Value Assurance and SAP Model Company nicely fit to each other.
The service component “ Activate SAP Model Company ” is part of the Build Design
service, and acts as a placeholder which links to the individual SAP Model Company. See accelerator
section for details.
The purpose of Fit-Gap / Delta Design is to validate the predefined scenarios and enhancements in scope
for implementation (based on the sandbox; see activity Activate Solution ), and identify potential gaps
between the delivered product and customer’s requirements. Three significant steps will be the
baseline for the deliverablesout of the activity Fit-Gap / Delta Design: Fit Gap Analysis / Solution
Validation GAP Validation Delta Design / Solution Design The following picture shows the Fip-Gap
activities for a new implementation. For conversion scenarios, the sequence of steps is the same –
however, the ain of certain steps differ. For instance, step #6 – Delta Design – also documents
the configuration “must-do’s” which need to be performed due to the
business processes which are already in use in the source system. Figure: Individual activities of Fit
Gap / Delta Design Key objective of this phase is to gather all relevant information in order to be sufficiently
prepared to move ahead with configuration afterwards. Requirements and Constraints This activity is
required for all scenarios. Procedure Fit-Gap / Delta Design is a “summary node” in the road
map picture. It splits into the following activities according to the sequence given in the picture
above: Fit-Gap / Delta Design - Finalize System Setup Fit-Gap / Delta Design - Fit/Gap Analysis
– Solution Validation Fit-Gap / Delta Design - Gap Identification Fit-Gap / Delta Design - Delta
Scope Prioritization GAP Validation Fit-Gap / Delta Design - Delta Design Design Review Fit-
Gap / Delta Design - Verify and Accept Steps 1-3 as lined out above include Fiori as an integrated part of
the workshops taking place. Starting with the prioritization (step 4) it becomes a separate activity with
dedicated UX/UI focus. For more details see also activity UX Activation and Design. The workshops are
conducted, depending on the customer’s selected application scope. Recommendation is to structure the
solution validation workshops along the Line of Business areas and End-to End Solutions which are shown
in the SAP Solution Explorer (accelerator section). The Line of Business (LoB) areas are structured into:
Asset Management Commerce Finance Human Resources Manufacturing Marketing R&D / Engineering
Sales Services Sourcing and Procurement Supply Chain Sustainability Each LoB area is structured into end-
to-end solutions. For example, Finance is structured into: Financial Planning and Analysis Accounting and
Financial Close Finance Operations Treasury Management Enterprise, Risk and Compliance Cybersecurity
and Data Protection Please note: In case an SAP Model Company is used to support the Fit / Gap activities
additional pre-configured scenarios are already available. For example, the SAP Model Company
“Automotive Suppliers” comes with additional end-to-end solutions in the area of Manufacturing, like (list
is not complete): Tool Production Handling Unit Management Co-Product Manufacturing … The eight-steps
activity sequence from above should be executed per end-to-end solution in scope for implementation. Of
course, this structure could be used for the design of additional functionality as well. How SAP Can Support
SAP supports this activity with the “ Fit Gap Analysis and Delta Design ” service component
as part of the Build Design service. This service component follows the 8-step-sequence
listed above. See accelerator section for details.
In this activity, the SANDBOX system setup is finalized. Requirements and Constraints This activity is
required for all scenarios. Procedure Prepare sample data Enhance system setup with additional
configuration
Based on the installed sandbox or the activated best practices focus of this task is to setup project specific
sample data, which will be used during the Fit GAP Workshops to present project specific data for each
relevant line of business (e.g. Material Master Data, Business Partner Master Data, etc.). Please note: The
accelerator section of the SAP Best Practices Explorer contains many accelerators like: A list of SAP
S/4HANA standard reports Organizational data overview List of master data objects, e.g. for CO and FI
Account Determination A list of roles delivered with SAP S/4HANA SAP Best Practice content
library The Prerequisites Matrix You need to register to get access to these accelerators (S-User
required). See the accelerator section for a direct link to the SAP S/4HANA Best Practices within the SAP
Best Practice Explorer. You will need to scroll down within the tool to the accelerator section. Please note
that the accelerators are independent of the chosen localization.
Especially in a new implementation scenario some process areas might not fully fit to the expected
business scope. Examples for that might be a specific country version. One of the key aspects of a
successful explore phase is to have a pre-defined and system based solution available, and to start the fit
gap workshops always with a system based initial setup. For those areas, where no Best Practice content is
available, relevant customizing has to be enhanced and extended (e.g. by using transaction SPRO). Input for
this task is the detailed scoping document where the elements need to be marked, which are not covered
by Best-Practices. It also requires clear guidance from scoping and planning, which level of detail needs to
be pre-configured for the respective areas. Procedure For new implementation projects follow the
procedures described in the Administration Guide (accelerator section). For conversion projects you will
need to follow the preparation and post-installation activities documented for instance in the conversion
guide.
The aim of this activity is to present and discuss SAP Best Practices processes and design elements, and to
identify gaps which arise from business requirements. Fit Gap Analysis / Solution Validation is executed via
on-site workshops involving the project team from the respective business areas. Requirements and
Constraints This activity is required for all scenarios. Procedure During each solution validation workshop,
the target solution will be presented toward the dedicated key users. For a newly implemented scenario
the following approach could be followed during a solution validation workshop: Presentation of the
process flow diagram out of the Best Practice Presentation of relevant transactions for each process
step Presentation of the UIs along the process Solution validation workshops for one topic could run in
different cycles (sprints) in order to detail the solution systematically. Focus is to get key decisions clarified
first (like organizational units or master data concepts) and become more detailed with each cycle (sprint).
The result of the fit-gap analysis will be an initial gap list with an indication for a potential solution. Within
each area (e.g. solution capability or Best Practice scope item), the following requirements need to be
documented within the delta backlog initially: Defined organizational units Defined Master Data
Objects, including e.g. chart of account Defined configuration values based on business drivers
Technical deltas leading into reports, interface, conversion, enhancements, forms, and workflow (RICEFW)
objects Deltas leading to changes in the UIs Business roles assigned to transactions and
requirements for authorizations and training Relevant KPIs for data volume management and system
monitoring Organizational or process changes A critical review of the identified initial backlog follows in
the activity GAP Validation.
The objective of this task is to run the Fit Gap Workshop for your business priorities, end-to-end solutions,
and other functionality to be implemented. Procedure For each Line of Business, end-to-end solution, and
application in scope for implementation, schedule Fit Gap workshops and document the results. The
workshop schedule should follow the SAP product road map along with the respective available Best
Practice scope. A complete list of scope items per end-to-end solution can be found in the
“SAP Best Practices for SAP S/4HANA 1709 - Customer scope presentation” (accelerator
section). Besides the topics specific to the business priorities it is important to define one area, where
general setngs that might be even client independent will be discussed, described and agreed (e.g. factory
calendar). The accelerator links are leading to the following information for each Best Practice:
General Description of the Best Practice and key process steps Process Diagram Test script How SAP Can
Support SAP supports this activity with the “Fit Gap Analysis and Delta Design” service
component as part of the Build Design service. This service component follows the 8-step activity sequence
listed above. See accelerator section for details.
Gaps identified during the fit gap workshops (see chapter Fit Gap-Analysis – Solution Validation) often
require an initial classification with important criteria. This initial classification and documentation will be
performed by the responsible lead for the respective area (for example: An organizational change
management issue identified in core finance usually would be described from the business key user for
Core Finance). Requirements and Constraints This activity is required for all scenarios. Procedure GAP
Documentation / Specification
The goal of this task is to have an initial classified backlog available as input for the next step
(prioritization). Procedure The following aspects should be classified and documented for each gap: Short
and Long Description Reason, what would happen, if this will not be realized Numbering logic
Priority, e.g.: Must have (e.g. mandatory changes from simplification list) Must have
after go-live (e.g. for the first month end closure) Important but not mandatory Nice to have
Gap Type, e.g.: Configuration Requirements Gaps that can be realized
leveraging SAP Standard Customizing. Configuration Gaps will consider the following aspects:
Documentation of the complete organizational structure according to the enterprise structure
Documentation of customizing required to configure all master data aspects
Documentation of customizing required, which is not pre-configured by SAP Best Practice
WRICEF Gap All adjustments or extensions on workflows, reports, interfaces, conversions,
enhancements and forms. Those gaps require specific development knowledge for realizing them. In some
projects, a specific governance / approval procedure is required to approve those types of gaps as a huge
number of those gaps might affect implementation effort as well as maintenance effort afterwards.
Development Gap Significant new developments for functionality that might not be available
within SAP standard - we recommend to leverage specific teams like SAP Custom Development to execute
those. UX Gap The minimal information required for the UX gaps are the name of the app
(according the naming in the App Library) and a short description of the detected gap. Organizational
Change Management Gap Ownership Assignment to respective scope item or solution capability Initial
complexity judgment
Before moving ahead specifying the solution within the delta design documents, it is important to sort out,
which gaps are relevant to fulfill the project objectives, and to perform a dedicated quality review. This is
presented in “Step B” of the picture below which again shows the complete Fit-Gap / Delta
Design procedure. Figure: Individual activities of Fit Gap / Delta Design A specific UI session
(Deep Dive) needs to be scheduled to further validate and qualify any Fiori and/or SAP GUI related gaps.
Extend and scope of the session depends upon the UI gaps on the backlog list. Requirements and
Constraints This activity is required for all scenarios. Procedure Prioritize Delta Scope
Based on the initial backlog and the classification, quality checks are required with respect to
completeness. Procedure This step should be performed by a project role that has the customer SAP
S/4HANA solution architecture overall in mind, and a common understanding of the project objectives
(Solution Architect and Project Management Team). Gaps might be also reviewed critically from that team.
Complexity parameters (very high, high, medium, low) can be assigned to each identified gap, which
enables the project management team to get an initial effort estimate based on T-Shirt sizes. The
combination of priorities, complexity and other parameters helps to cluster the gaps into different sprints.
In some cases, a governance body, like a steering committee will be involved for decision making
procedure.
This activity performs a quality review of identified gaps by a project independent instance. Requirements
and Constraints This activity is required for all scenarios. Gaps have been identified and documented before
as a result from the Fit Gap workshops. Procedure Validate identified and documented gaps
The objective of this task is the validation of the identified gaps. Procedure Validation of gaps should
consider the aspect of keeping the SAP standard as closely as possible: Manage all deviations from SAP
standard Keep the number of modifications and custom code to a minimum Communicate with
experts at SAP to identify the bestpossible functionality in SAP standard software for the project and to
suggestbest practices and architectural guidance for custom enhancements. This task can be supported by
SAP Custom Development. How SAP Can Support Innovation Control Center During the execution of
implementation projects for SAP Premium Engagement customers, an Innovation Control Center (ICC)
focuses on designing and creating solutions as close to the standard as possible. An innovation control
center is responsible for managing any deviations from standard SAP software. SAP experts, both on site
and at SAP, work together to show how solutions to perceived functional gaps can be implemented. As part
of the “Zero Modification” service available to SAP Premium Engagement customers, SAP
validates all modifications that are required to fill functional gaps. An ICC uses SAP Solution Manager to
evaluate functional gaps and monitor project status. Specifically, an ICC uses the SAP Solution Manager
functional gap (SMFG) transaction type to collect requirements. The ICC and SAP Global Backbone use SAP
Solution Manager to work seamlessly together. The IT Service Management WebClient UI is enhanced by
an add-on to process the functional gap transaction type , which is based on the incident transaction type,
and dashboards display the relevant information. SAP further supports this activity with the “Gap
Validation ” service component as part of the Safeguarding the Digital Transformation service. See
accelerator section for details.
The purpose of delta design is to detail and document solutions for those gaps that were identified and
prioritized during the fit-gap session. This leads to finalizing the respective delta design documents in a
format suitable for communication as well as for formal sign-off. Procedure For each relevant solution
capability (or scope item) the following criteria should be described in a delta design document:
Short description of the process (project and SAP S/4HANA specific) General business
requirements Process flow diagram Baseline is always the Best Practices process
flow chart. Only the adjustments should be documented in SAP Solution Manager User roles
Requirements for the authorization concept Necessary IT systems, e.g. interfaced
systems to SAP S/4HANA Identification of gaps Solution for gaps Important
customizing Developments Organizational aspects Process quantification (data
volume) Besides topics mentioned above, that need to be covered on solution capability level, it is
mandatory to describe general setngs, organizational units and master data requirements. The level of
detail of each delta design document should be in a way, that configuration can start based on the
description.
The purpose of this task is to continue collecting input and finalize the delta design document for your
business priorities, end-to-end solutions, and functionality in scope for implementation, in a format
suitable for both communication as well as for formal sign-off purpose. The documented delta design
provides an understanding of the essential processes at the end-to-end solution (level 2) and provides all
requirements on solution capability level. Procedure The structure of the delta design document depends
on the application in scope for implementation. For example, the structure for Core Finance can look like
this: E2E Solution:    Accounting and Financial Close General Ledger
Asset Accounting Inventory Accounting …. Financial Reporting E2E
Solution:    Cost Management and Profitability Analysis Cost Management
…. Depending on the complexity of the project, it is recommended to have
individual delta design documents on Level 2 (end-to-end solution). Finalize the delta design
documents of your business priorities and applications in scope for implementation.
This activity performs a quality review of delta design documents from a project independent instance.
How SAP Can Support SAP supports this activity with the “ Design Evaluation ” service
component as part of the Safeguarding the Digital Transformation service. See accelerator section
for details.
This task performs a quality review of delta design documents from a project independent instance.
Procedure The design review should include criteria like: Completeness of design documents
Quality sufficient to start configuration afterwards Management of solution integration Leverage
the SAP standard as closely as possible: Manage all deviations from SAP standard Keep
the number of modifications and custom code to a minimum Communicate with experts at SAP to
identify the best possible functionality in SAP standard software for the project and to suggest best
practices and architectural guidance for custom enhancements How SAP Can Support SAP supports
this activity with the “ Design Evaluation ” service component as part of the
Safeguarding the Digital Transformation service. In case there is uncertainty on the design of
complex processes at net new or existing customers, or there are concerns on robustness, operability and
sustainability of a process and solution design for a new or already implemented SAP solution, SAP offers
the “ Application Architecture Evaluation ” as an additional service component, and as part
of the Safeguarding the Digital Transformation service. Industry experienced solution
architects review the core business processes and supporting master data, identified gaps and planned
development requirements. The solution landscape is analyzed on a high level including interfaces, data
volume and custom development aspects. The business blueprint is evaluated, and SAP portfolio
alternatives are presented under consideration of latest product road maps. A final report summarizes the
covered areas, core processes and the SAP recommendations. See accelerator section for details.
The purpose of verify and accept is to obtain a form approval for all created documents during fit gap /
delta design.
The goal of this task is to perform validation and approval sessions. Procedure All relevant stakeholders
from business and IT departments are signing off the respective document. With the sign off, all
stakeholder agree, that completeness is given, the solution proposals for respective requirements are
understood and accepted. Issues identified during acceptance need to be documented and classified.
Based on the approved design documents, the backlog will be updated and represents now the product
backlog for realization phase. The updated product backlog is the baseline for the sprint planning for
realization phase. As this is usually one of the last activities within the explore phase, it is
highly recommended to perform a lessons learned session.
The objective of this activity is to determine the difference between the SAP standard configuration for
Fiori and customer specific requirements. A sandbox with standard Fiori configuration will be set-up as the
basis for comparison. A series of workshops allows the identification and validation of customer specific
requirements (”gaps”), hence the deviation from the standard. Potential solution approaches
will be drafted and prioritized as input for later development. Requirements and Constraints Transition
planning and phase preparation is done UX Readiness analysis is done Relevant scope of Fiori is
available from the planning service upfront UX responsible from the customer is determined Sandbox
with SAP S/4HANA is available SAP Solution Manager 7.2 Results Fiori's within scope are activated
in the sandbox according to the SAP standard Gaps and requirements are confirmed and described
and confirmed Topics per gap are determined: Theming / branding, personalization, adaptation, UI
extensibility, new app (HTML5, Screen Personas) Mock-up of the solution(s) is drafted Prioritization is
established How SAP Can Support SAP offers the “ UX Activation and UX Design ” service
component as part of the Build Design service. This service component covers all the activities described in
this activity. Alternatively, the SAP service “ Implementation of User Experience in SAP S/4HANA
” can be used. This service consists of various scope options that allow to tailor to the required
scope. This service also covers the UX activities that follow the steps described in this activity. It especially
covers the detailed specification of the UX enhancements and its implementation, the UX set-up in
development, and the move to quality assurance and production. The “ UX Advisory Service for
Business Value ” complements planning and design activities for User Experience. It also allows to
address strategic aspects related to User Experience. Also, it is highly recommended to make yourself
familiar with SAP Fiori, e.g. by studying the expert SAP Blogs from the Regional Implementation Group
(RIG): SAP Blog “Essential Roles for S/4HANA Fiori Projects” introduces the roles &
associated responsibilities of S/4HANA projects implementing Fiori user experiences SAP S/4HANA
– How to Create and Generate Backend Security Authorizations for SAP Fiori 2.0” which
provides a step-by-step instruction on how to create and generate SAP Backend authorizations for a SAP
S/4HANA system based on SAP Fiori 2.0 Frontend Server Catalog information. SAP Blog series
“Leading S/4HANA UX” and “Fiori for S/4HANA” on SAP Fiori in general.
SAP Blog series “Fiori elements” on design elements. SAP Blog and guide on “Fiori
In-App Extensibility”. SAP Blog on “Configure Fiori with Multi-Clients”. Another
great information source is on SAP Fiori is the “SAP Fiori for SAP S/4HANA” WIKI. The WIKI is for customers
who are starting with SAP Fiori in a new SAP S/4HANA system, or want to gain more knowledge about
operating or developing SAP Fiori in an existing SAP S/4HANA system. See accelerator section for links.
The objective of this task is the preparation of the sandbox with Fiori apps to assure readiness for Fit / Gap
workshops: The sandbox can be based on an appliance (CAL, BluRay), on an SAP Model Company, or on
activation using SAP Best Practices. For new implementation: Appliance or SAP Model Company set-up;
Fiori check to assure readiness for workshops System Conversion: Activation of SAP Best Practices.
App-specific configuration for the in-scope Fiori and setng up Fiori Roles and Users for System Conversion
Procedure (for System Conversion) First of all, become familiar with the Fiori Apps Reference Library, by
reading the SAP blog “How To Explore “Fiori Apps Reference Library” For SAP S/4 HANA Apps” from the SAP
RIG team. A relevance analysis for Fiori apps based on the usage of the existing system allows a first UI
scoping. Using a list of transaction codes uploaded to the SAP Fiori apps reference library, the
“Relevance and Readiness Analysis” (open the SAP Fiori App Reference Library, and click on
“Learn more” on the left side of the screen; see accelerator section) provides a list of SAP
Fiori apps that fit the business processes in scope. All app-specific prerequisites need to be available
according to the information in the Fiori App Reference Library before carrying out the following;
Creating Fiori Users Connecting SAP Gateway to SAP S/4 HANA System Configuring SAP Web
Dispatcher (Fact sheets only) Setng up the Fiori Launchpad and Launchpad Designer Generic
Configuration for Fact Sheet Generic Configuration for Analytical App Review basic security set-up
and configuration. Note that some of the configuration differs between an embedded landscape (backend
and frontend in the same machine) and a Central Hub set-up (having frontend and backend separated). SAP
recommends a Central Hub deployment.
The following applies to both scenarios, new implementation and system conversion. The objective of this
task is: The identification of customer specific requirements that cannot be solved with an SAP standard
configuration for Fiori. The review of these customer specific UX requirements in more detail. The
drafting of potential solutions (mock-ups). The Qualification and prioritization of the solution. An
initial effort estimation for design and development as a basis for planning and decision making. Procedure
The Fit Gap / Delta Design Phase is divided into two steps: Fit Gap Analysis and Solution Validation The
Fit-Gap workshops are conducted to validate the predefined scenarios and processes and to identify
deviations from the standard configuration. The Fiori apps that fit the customer business processes will be
selected. These are not specific UX workshops but generic fit-gap workshops covering all potential
deviations. Delta Design The UX gaps will be validated in specific UX sessions followed by a high-level
solution design. This assures that the identified gaps get addressed properly in detail and that the required
knowledge is present in the workshops. To prepare the UX specific validation sessions the following
activities need to be carried if not already done previously. A series of activities Initial
categorizing of the gaps according to complexity Workshops and/or discussions depending upon
complexity Effort estimates for UX enhancements; definition of enhancements that need additional
evaluation to come up with effort estimates (custom specific development, effort estimate is not part of
this deep-dive session) Capture UI information in a tool for complex gaps (Build is recommended)
For process/screen optimization: requirements defined, prioritization, initial high-level effort
estimate, low-fidelity mock-ups Additional tasks depending upon the project planning Identification
of End-User Roles and their tasks in order to design the Fiori Launchpad Role-based Experience
Identification of set-up of tiles (Launchpad Home Page vs. relegated to the App Finder; grouping, naming,
roles) Draft design for Analytical tiles Based on the categorization and defined priorities, Design and
Development activities have to be set up as a next step.
A special case of SAP S/4HANA is the implementation of Central Finance. With Central Finance, customers
can transition to SAP S/4HANA Finance, on-premise edition without disruption to their current system
landscape, which can be made up of a combination of SAP systems of different releases and accounting
approaches and non-SAP systems. Central Finance allows customers to create a common reporting
structure. See accelerator section for more details. Requirements and Constraints This activity is only
relevant in case you would like to set up Central Finance (Landscape Transformation Scenario). Procedure
Run Central Finance Design
The objective of this task is to design Central Finance. How SAP Can Support SAP helps customers to deep
dive into the topic of Central Finance with the ‘Central Finance Design’ service component,
which is part of the Build Design service. The following service components are available:
Central Finance Overview Discover the innovative features and key benefits of SAP S/4HANA for central
finance foundation and its universal journal. Explore the benefits of a non-disruptive digital transformation
by offering a harmonized common reporting structure on real-time data across the numerous systems
within the organization. Gain insight into various use cases and implementation options and learn more
about all available central finance capabilities. This service component complements the “Value and
Implementation Strategy” service component. Central Finance Evaluation The
Central Finance Evaluation service enables customers to assess and examine Central Finance as a potential
deployment option for SAP S/4HANA Finance. Before investing in a proof of value or starting an
implementation, customers can explore and select specific business processes and value scenarios to
address their specific needs and determine how to proceed regarding the creation of technical design and
business case. This service component complements the “Transition Planning for New
Implementation” service component. Central Finance Design The Central Finance
Design service supports preparations for the follow-on implementation of SAP S/4HANA for central finance
foundation. It integrates the SAP Landscape Transformation Replication Server, the accounting interface
framework, and the connection of source systems to enable real-time reposting of defined financial
transactions into the central finance instance. For detailed information, see accelerator section and
talk to your SAP contact.
Data Volume Management should be considered prior to a system conversion, reduce the amount of data
to be converted (this has implications on duration / downtime of the cutover) as well as to reduce the
amount of data in memory (has implications of hardware costs). It is also recommended in an up and
running SAP HANA environment develop a common DVM Strategy including several systems, common
retention management and storage requirements. Data Volume Planning is the first step in the Data
Volume Management lifecycle. Requirements and Constraints Data Volume Management Planning should
be considered specifically in the following cases: Sizing results indicate the need for an SAP HANA server
larger than the expected DVM Alerts from the SAP Early Watch Alert report indicate a need for DVM
Data archiving is already actively used. This indicates the need to adjust the archiving strategy according to
the new data models and technology (i.e. data aging) The system is older than 5 years and no significant
data archiving has been scheduled, there is a high probability that data is on the system that is no longer
relevant for daily business processes. Customer requires a roadmap to support his SAP HANA
conversion proactively. In those cases, SAP recommends to further analyze, if there should be additional
DVM activities included in the SAP S/4HANA implementation project. Procedure Perform Data Volume
Planning Results Go or No-Go decision for future DVM activities in the scope of the S/4HANA conversion
project. In case of Go, the result will be a road map that defines the exact scope of the data volume
management activities.
Analyze the current database and determine how much data can be archived or deleted upfront of an SAP
S/4HANA implementation. Procedure Use common analysis tools like DVM Workcenter in SAP Solution
Manager, transactions DB02, TAANA, and SE12. However, in case you have not archived before, it could be
challenging to identify the key archiving objects and their saving potential. Results A decision and road map
on how to proceed with DVM prior to a transition to SAP S/4HANA. How SAP Can Support SAP can
perform this task with the “Data Volume Planning ” service component, which is part of the
“ Build Design ” service. Based on a detailed analysis of the database the amount of
data (in GB) is determined, that can either be archived or deleted according to SAP’s best practices.
Based on this analysis possible follow-up activities are identified. In a workshop these activities (data
archiving or deletion) are discussed and prioritized considering aspects like: Expected savings.
Complexity (i.e. the extent of how business processes may be effected by the activities). Considering the
usually limited amount of time and resources, it should be focused on so called quick-wins, i.e. data that
can be considered as basis and cross-application data and that can be removed from the database without
having too intensive and difficult discussions with the business owners. SAP S/4HANA relevance (i.e. are
these business objects that are simplified and therefore undergo specific conversion routines which will
affect the downtime). The workshop also includes knowledge transfer on discussions about the
infrastructure requirements for data archiving and a suitable project setup for the implementation. Data
Volume Planning Outcome: Go or No-Go decision for future DVM activities in the scope of the
S/4HANA conversion project. In case of Go, the result will be a road map that defines the exact scope of
the data volume management activities including timelines, estimated effort, required teams and resources
for the individual data archiving and deletion activities. Based on this road map the next step of
defining a Data Volume Management strategy will be performed. SAP Enterprise Support customers can
request a Continuous Quality Check “ CQC for Data Volume Management ” which provides a
general view of the DVM situation in your system. Contact your Enterprise Support Advisor for details.
The purpose of this activity is to agree on a data volume management strategy that defines
which data is stored in which storage location for how long (i.e. defining the residence and
retention time). This considers and includes aspects of the data owners like: External reporting
requirements (tax audits, product liability) Internal reporting requirements, i.e. fraud detection
Business process requirements Data Privacy Dependencies between data archiving and document
management …but also defines more IT-organization related aspects such as: Operation and
Monitoring of data archiving and deletion jobs, i.e. in which sequence data archiving objects should best be
scheduled related to other archiving objects Infrastructure, e.g. Content Server to store the archive files
As data avoidance (i.e. deactivating the creation of data by customizing changes) and data summarization
(i.e. aggregating data at higher level) will only have future effects, in a conversion scenario you should focus
on the following techniques. Data Deletion Deleting out-of-date records from the online database that
are no longer used by the business nor required for legal compliance (e.g. spool data) Data Archiving
Transferring data with a long retention period (e.g. legal compliance, product liability data, etc.) from the
online database to an alternative storage medium, which provides display access to the transferred data
For those customers that have already set up DVM they need to look into this activity for these reasons:
With SAP Simple Finance SAP has introduced a new concept called Data Aging (see Accelerators section for
details) for finance data replacing the Data Archiving concept in this space. Data Aging offers you the
option of moving large amounts of data from working memory to disk within SAP HANA so as to gain more
working memory. You use the relevant SAP application to move data from the current area to the historical
area on disk. You control the move by specifying a “data temperature” for the data. The
move influences the visibility when data is accessed. Due to the massive change of the FIN data model
with SAP Simple Finance reload of accounting data that has been archived with archiving
object FI_DOCUMNT prior to the conversion is no longer possible after conversion.
(See SAP Note 53064 - which clearly states: “Reloading data across releases is generally not
allowed”) Also existing archiving strategies need to be checked. E.g. in future, table COEP entries
will be saved partly in table ACDOCA and / or in table COEP depending on the value type. Hence future
table growth needs to be examined carefully and existing archiving strategies need to be adapted. In
case there are customer specific requirements to access archived or historical (cold) data, custom code
adoptions need to be considered. Data Aging is available as an additional option for work items, Idocs,
change documents, application logs as well as for material documents (S/4HANA edition 1511). Data Aging
is also available for Sales documents, Deliveries and Invoices, as well as for Purchase orders as of SAP
S/4HANA edition 1610. So there may be a benefit of integrating Data Aging in your existing DVM strategy.
In the context of the system conversion project you will need to do the following: For large systems, set up
and execute a DVM strategy focusing on quick-win objects (i.e. temporary, basis and cross-application
tables) to reduce the size of the database before system conversion starts. Sanity check the results of the
DVM activities (e.g. by using the DVM work center in SAP Solution Manager). In case time permits also
consider a broader approach that also includes data archiving of business documents. Especially consider
archiving of accounting
The objective of this taskdocuments as this
is to identify data,will no longer
which be easily
could be possible on SAP S/4HANA
reorganized up because
or deleted to editionthey
1605.
are
temporary or basis table data. Prerequisites This task is only relevant for system conversion. Procedure
There is a Guided Self Service available in the DVM Work Center of SAP Solution Manager to provide
detailed analysis of your data and useful background information on the most commonly growing tables. In
case the possible quick-win tables have been identified already in the DVM Planning phase, you can run the
Guided Self Service specifically focusing on those manually entered and selected tables. Alternatively there
is an option to schedule the Guided Self Service automatically focusing on Basis and temporary tables that
could be subject for archiving or deletion without effecting business processes (i.e. DVM quick wins). Based
on the analysis results and the recommendations, define and agree with all stakeholders on
your own residence time . See also SAP note 706478 – “Preventing Basis tables from
increasing considerably” for options to reduce the size of Basis tables. The DVM work center also
offers beneficial insights and transparency when finally executing the archiving and deletion jobs and
allows the monitoring and tracking of success. Results There is now transparency on the DVM quick wins of
SAP HANA.
Setng up and executing a DVM strategy is often time-consuming. One reason is that data residence time
(i.e. time the data resides on the database before archiving) and the retention time (i.e. total lifetime of the
data before its destruction) need to be defined based on legal and business requirements together with the
Business Owners from the Lines of Businesses. Prerequisites This task is of particular interest for system
conversion. Procedure In the context of a system conversion project, SAP recommends to at least discuss
SAP note 2154712 – “Archive transaction data of deactivated company codes” to shut
down and archive inactive company codes before conversion starts. You as an SAP Enterprise Support
customer, can run the DVM Guided Self-Service focusing on the largest 30 tables in your system and by
doing so you can gain also get insights on reduction potentials calculated based on SAP’s best
practice recommendations and background information for business documents, e.g. material documents,
CO line items, … These best practice recommendations on the residence times from the service
report can be used as a starting point when starting the discussions with the business owners. The business
owners are more willing to agree on a residence time for data archiving if they feel they have a good
understanding on the consequences and are informed about the options of accessing archived data. To
support this understanding it is useful to run test archiving before the discussions so that you can do
a demo on the archive access capabilities of the system. Results You have started with the execution of a
DVM strategy to reduce system size and required downtime during system conversion. How SAP Can
Support SAP offers holistic support to create and execute a DVM strategy. In particular SAP offers the
“Data Volume Design” service component which is part of the " Build Design"
service. Customers can either contact the SAP Technical Quality Manager or Client Partner for
ordering details. Alternatively, customers can use the contact form to request an SAP Value Assurance
service package offer.
Open business documents cannot be archived from the SAP system. In order to reveal additional reduction
potential, you need to get insights into the current status of open business documents. Prerequisites This
task is of particular interest for system conversion. Procedure It is difficult to collect the open
business documents yourself with acceptable efforts. SAP recommends to order a Business Process
Analysis service that provides a snapshot for business metrics. Once you have gained transparency on the
number of open business documents, you can start clarifying the status together with the Business Data
Owners from the Lines of Businesses. The aim is to close as many open business documents as possible,
and have them archived before the system conversion. Please note that the Business Process Analysis is a
one-time health check only. For a continuous root cause analysis and improvement of business processes,
Business Process Analytics in SAP Solution Manager can be used. This tool provides benchmarking,
advanced benchmarking, value benchmarking, age analysis as well as trend reporting. For more
information, please see Accelerator’s section. Results You have gained transparency on open
business documents. How SAP Can Support SAP offers a Business Process Analysis service that provides a
snapshot for business metrics like: ”Sales orders overdue for delivery“ “Outbound
deliveries overdue for GI posting” “Deliveries overdue for billing”
“Open & overdue items in Accounts Receivables” “Open & overdue
purchase requisitions” “Open & overdue purchase order items”
“MM invoices blocked for payment” “Open & overdue items in Accounts
Payable” “Production/Process orders overdue for deletion flag”
“Inbound deliveries overdue for GR posting” All available metrics are documented in a KPI
catalog. For details, see Accelerator’s section. As a much more comprehensive approach, SAP offers
a “Business Process Improvement” service component as part of the “Safeguarding
the Digital Transformation” service. The service component typically starts with a remote Business
Process Analysis in order to learn fact based about the current status quo, and to have a baseline
measurement from where to start the improvement activities. Selected out-of-the-box key figures, which
support the respective anticipated target, are activated in the customer SAP Solution Manager and
Business Process Analytics is used for root cause analysis. Several root cause analysis and tool empowering
sessions are conducted with the customer process experts from business and IT. Management UIs
(Dependency Diagrams, Progress Management Board, Business Process Operations Dashboards) are
configured in SAP Solution Manager based on Business Process Analytics data in order to track the progress
made. For SAP Enterprise Support customers, an EGI session is available with focus on Business Process
Improvement (BPImp) that shows Best Practices to support the identification of possible root causes of
open business documents as well as a continuous improvement of the business processes. See
Accelerator’s section for details on service all offerings.
With SAP S/4HANA a new DVM concept named “Data Aging” has been introduced. The
objective of this task is to adjust the DVM strategy accordingly. Prerequisites This task is important for all
scenarios. Procedure Proceed as follows: Inform yourself. SAP Note 2190848 –
“FAQ - Aging for Journal Entry in SAP Simple Finance” gives you a lot of information on
the Data Aging concept, and its impact on DVM as such. SAP Note 2190137 – “sFIN: Reduce
memory footprint of obsolete tables” gives you an overview about obsolete tables in SP Simple
Finance area and how you can reduce the data footprint after successful transition; it also indicates what
kind of data are still required after transition and might be reduced already in old system environment /
before transition. There are already books available on this new topic (e.g. from SAP Press, see accelerator
section). For material documents you should look at SAP note 2224147 – “Re-enablement:
Archiving of material documents”. For all available Data Aging objects please look at the
collective SAP note 2315141 – “Collective note for Data Aging Framework”. This SAP
Note is regularly updated when new information becomes available. Together with your Data Volume
Management head, and the Business Data Owner from the FIN Lines of Businesses, clarify which data
should be archived before the system conversion, and how Data Aging should be configured as part of the
conversion. As mentioned in the SAP note, please make sure to properly adapt custom code that accesses
archived FIN data, or in future FIN data from the history space. Results The DVM strategy has been adjusted
with respect to Data Aging. How SAP Can Support SAP supports you with respect to Data Volume
Management. In particular SAP offers the “Define Data Volume Design”
service component which is part of the “ Build Design” service.
In the security design phase you will create a specific road map for the security topics that have to be
covered during the transition to SAP S/4HANA according to the customer requirements. Requirements and
Constraints Mandatory requirements : User management has to be implemented (see
chapter 4 of the SAP Security Guide, and “Assigning business roles to a user” in the
Administration Guides for details) Authorization management has to be implemented
(authorization management for application users and database users). Look up the following information:
“Creating basic setngs for using SAP Fiori Launchpad” in the
Administration Guide “Creating back-end authorization roles” in the
Administration Guide Chapter 4 of the SAP Security Guide Upgrade
of the authorizations according to the SAP S/4HANA technology (see “Configuring Roles with
Launchpad Start Authorizations” in the SAP Online Help Portal. Recommended:
Redesign of authorization management Redesign of authorization concept Mitigate risks
in the current concept and implement proper Segregation of Duty (SoD) rules (GRC) (see “The
Segregation of Duties Concept” in the SAP Online Help Portal) Definition of processes for
SAP Auditing, Logging, and Monitoring (see “Auditing and Logging” in the SAP Online Help
Portal) RFC-Security Service (see SAP Thought Leadership Paper on “Securing Remote
Function Calls” for details) Procedure Planning/Scoping of the activities
as prioritized by the customer (mandatory/recommended/optional) to create a detailed security road map
within the overall transition project. Results “Go” or “No-Go” decision for
security activities in the scope of the transition project. In case of “Go”, the result will be a
road map that defines the exact scope of the security design activities. How SAP Can Support SAP supports
this activity with the “Security Design” service component as part
of the Build Design service . Security Design consists of two parts: The “SU25
Authorization Upgrade” part executes the mandatory adjustments of existing roles during. It
is required for SAP S/4HANA system conversion and landscape transformation projects (which start with a
system conversion). Moreover this part is also required for subsequent upgrades. The “ S/4HANA
Authorization” part supports customers in quickly establishing roles and authorizations for
an SAP S/4HANA implementation. It is required for all SAP S/4HANA transition scenarios. An initial scoping
determines the required parts and effort with respect to your SAP S/4HANA transition project. “
SU25 Authorization Upgrade” The “SU25 Authorization Upgrade ” service
supports you to post process your PFCG authorizations for ABAP applications as part of SAP upgrade. For
planned “System Conversion” or “Landscape Transformation” scenarios these
steps are required. Within the “ SU25 Authorization Upgrade ” service the customer will
be enabled to understand the required technical basics and methodology which is needed to come to a
successful go-live with appropriate PFCG ABAP role content. After an assessment and discussion of your
situation you will get customer specific action instructions for updating of your SU24 tables. These tables
build the foundation of the PFCG role generator which is used to build and adapt PFCG roles. Delivery
Approach and Scope: This service will be delivered as a coaching approach, starting with an
Define all required security topics concerning infrastructure security, covering network security, operation
system and database security; and frontend security. Requirements and Constraints Required:
Define communication security Plan the implementation of SAP HANA Security following the
SAP HANA Security Guide Define authentication mechanisms Recommended :
Adapt authorizations to user requirements and roles Plan the implementation of Single Sign-On
Define processes for SAP Auditing, Logging, and Monitoring Plan security of IT Infrastructure
RFC-Security Service; Gateway Security; Patching Services Sec Notes Advisory;
Custom Code Security Service Procedure Define the security infrastructure that will be setup
and configured in the security implementation activities during the realize phase. Results Definition of
Security activities in the scope of the S/4HANA conversion project which will be implemented during the
realize phase.
Within the Analytics Design activity customers can further enhance their analytics
infrastructure with regards to new reporting options that have been introduced with SAP S/4HANA. New
operational reporting methods can be added to the existing analytics solutions, and data from SAP
S/4HANA can be provisioned to existing Enterprise Data Warehouses for further analysis. All available SAP
analytics solutions should be discussed for strategic and business value. This activity follows up and
integrate with the “Define the Analytics Architecture” task from the Discover Phase of the
road map, with the objective to provide a more detailed analysis of the most important analytics business
cases and further detail out the target analytics architecture and define a transition project plan.
Requirements and Constraints This activity is optional, but highly recommended. If you could not take the
opportunity to review your company’s analytics strategy in the discovery phase of the road map,
you can start it here or alternatively evaluate and plan the identified options in more detail.
Procedure Please refer to the task “Define the Analytics Architecture” (activity
"Strategic Planning" in the discover phase) for information about the procedure. This activity
will be similar in terms of procedure and content, however it will focus only on the relevant solution
components (potentially identified in the earlier activity) and create a more concrete target architecture
and migration path based on the most important analytic business processes, requirements and influencing
factors, such as: Real-time reporting, data retention policies, data governance and ownership, new
technologies and options Please check the Accelerators section for further information about SAP’s
roadmaps for the strategic solutions and details about the product options, especially: SAP S/4HANA
Embedded Analytics SAP BW/4HANA and SAP BW SAP Analytics Cloud and Digital Boardroom
SAP BusinessObjects BI Suite See also the tasks for designing analytics architecture (recommended),
and designing a SAP Digital Boardroom (optional).
The objective of this task is to fine-plan the analytics architecture. How SAP Can Support To support the
analytics design activity, SAP offers an “ Analytics Design Workshop” as part of
the Analytics Design service: As a follow-up or deep dive on the “Analytics Strategy
Service”, this service component should help defining the actual implementation aspects for the
analytics infrastructure, depending on what components for analytics will be used. The service
component provides guidance for SAP BW/Mixed/HANA modelling. It identifies the ideal choice for data
modeling in an SAP Enterprise Data Warehouse (BW / HANA), which is either SAP BW-centric, mixed or SAP
HANA centric. The decision is based on the customer infrastructure (e.g. data sources, or ETL tools etc.),
and business requirements (e.g. with respect to real time). The service component empowers on the
practical use of CDS views in SAP S/4HANA. Prototyping can be provided for reporting applications for
analytical Fiori apps, or SAP S/4HANA Embedded Analytics. The service component provides guidance
on embedded BW usage, and how LSA++ should be applied to the customer EDW model in SAP S/4HANA
(for both, SAP BW and HANA native). See accelerator section for details.
As part of the transition to SAP S/4HANA, customers need to identify code, that has to be
adjusted (“must-do’s”), and those that should be adjusted
(“should-do’s”). Requirements and Constraints This activity is relevant in case own
code needs to be made ready for SAP S/4HANA (e.g. the system conversion case). A first analysis of the
custom code situation should have been done in the Prepare phase already. Procedure
Empowering on Custom Code Management Tools Create a Custom Code Work List Results
There is a documented work list of custom objects which are subject for adjustment stored centrally in SAP
Solution Manager. How SAP Can Support SAP has published excellent blogs on custom code management
in the context of a system conversion: To learn about the challenge, start with the SAP Blog “SAP
S/4HANA System Conversion – Challenge for your custom code” . To understand the
necessary adaption process for your custom code, look at: The SAP Blog “SAP S/4HANA
System Conversion – Custom code adaptation process” The SAP Blog “ABAP
custom code adaptation for SAP HANA – The efficient way” What you can (or
better: should) do well upfront of a planned system conversion is documented in the SAP Blog
“What can you do today to prepare your custom code for SAP S/4HANA” . Finally, there is
a blog series describing all relevant expert tools required for analysis. The first issue is the SAP Blog
“Remote Code Analysis in ATC – One central check system for multiple systems on various
releases” . You will find all links in the accelerator section. Customers can order a “C ustom
Code Impact Analysis ” service component as part of the “Custom Code
Management” service. The Custom Code Management Impact Analysis offers
transparency on the existing custom code situation including customer objects and modifications. It helps
to evaluate the impact of changes on custom code. With the results of the analysis the adjustments on
custom code can be reviewed and mitigated in an early stage. It helps customers to reduce efforts for
change adoptions and facilitates a smooth completion of the identified adjustments.The “Custom
Code Impact Analysis” is also available for SAP Enterprise Support customers.
The goal of this task is to make you familiar with the tools for custom code management. Procedure
Relevant expert tools around custom code management are documented in a blog series. The first issue is
the SAP Blog “Remote Code Analysis in ATC – One central check system for multiple systems
on various releases” (ATC, SCI…), and “What can you do today to prepare your custom
code for SAP S/4HANA” (SCMON, SQLM). Read the blogs and make yourself familiar with the tools.
How to use the expert tools is documented in: The SAP Blog “SAP S/4HANA System Conversion
– Custom code adaptation process” The SAP Blog “ABAP custom code adaptation
for SAP HANA – The efficient way” In addition, there are even more tools and transactions
you should be familiar with: Depending on start release, customers may have to upgrade your SAP
system first, or may have to install some additional EHP’s. In case customers modified an SAP
program, and SAP comes with a new version of this program as part of the upgrade or EHP , they will need
to adjust their custom code and their modifications . Once customers have done the upgrade or the EHP
installation, they will see all modified objects that need to be technically adjusted in the transactions SPDD,
SPAU or SPAU_ENH . There are two additional interesting options they should be aware of: The
Upgrade / Change Impact Analysis as part of CDMC is a way to estimate and manage the technical
adjustment effort by comparing systems before & after upgrade, and analyzing the corresponding
objects (e.g. referred SAP objects in custom code). The Scope and Effort Analyzer (SEA) in SAP
Solution Manager is also estimating the technical adjustment effort caused by EHP installation, by
comparing the custom object and modified object list with the Technical Bill of Material (TBOM) of an EHP
(thus this is doable in front of the EHP installation), and evaluating the adjustment costs and effort with
information provided by SAP’s backend. There is the growing area of truly simplified
and optimized business processes, where SAP has completely changed the way of processing business data
(e.g. from a batch driven long running report that has been enhanced to a new transaction that can run in
dialog mode). Here, a simple adjustment of some SQL statements within a custom program may fall short.
Instead, customers should proceed as follows: Customers can consider using SAP’s
new way of processing data, by going back to the SAP standard . This kind of transformation is supported by
SAP via concepts like the Innovation Control Center (ICC) . Or customers can think about a complete
re-design of your custom code in this space, leveraging the new business functionality offered by SAP.
There are many options to become informed about what has changed with SAP S/4HANA. In case this ends
up in a software project, customers, of course, can rely on SAP as a trusted advisor. Check the
information given in the accelerator section, and make yourself familiar with the tools and usage. Results
You are now familiar with the main tools required to analyze the custom code situation in your SAP system.
How SAP Can Support See C ustom Code Impact Analysis service component in the activity description.
Create a list of custom objects which are candidates for adjustment. Prerequisites You are familiar with the
SAP tool set on custom code. Procedure Use all tools listed in the task before, and create a list of custom
objects which are affected: Modifications affected by upgrade or enhancement pack installation
Custom code affected by the database change to SAP HANA Custom code affected by the change of
the simplified data model coming with SAP S/4HANA Custom code affected by the simplification of
business processes and applications coming with SAP S/4HANA Analyze all custom objects from the list,
and prioritize with respect to business criticality and urgency. Results There is a documented and prioritized
list of custom code objects which need to be adjusted as part of the transition project.This also includes
custom code objects which should be re-implemented on SAP Cloud Platform (e.g. SAP Fiori UI’s or
for integration with other SAP and non-SAP systems). How SAP Can Support See Custom Code
Impact Analysis service component in the activity description.
To minimize the number of issues during or after Go-Live, it is critical to manage the quality of the solution.
As a part of any scheduled maintenance event, it is necessary to consider and plan the testing cycles
required to mitigate production support issues. At this phase of a system conversion project, it is necessary
to evaluate the existing test and quality management processes and procedures that could be leveraged to
support the project. The following key elements of the test planning must be documented in the test
strategy: Project Testing Objectives & Assumptions, e.g. Unit Testing is only required
for delta functionality Unit Testing is complete before Integration Testing Test Scope
Types of Testing, e.g. Unit Testing Business Process (String) Testing Integration
testing Data Conversion Testing User Acceptance Testing Testing Approach
Description, how different test types relate to each other, e.g. successful unit test is a pre-requisite for
doing a string test or migration test results might lead into a pre-requisite for a user acceptance testing
Testing Deliverables, e.g. Test processes per phase, test environment, test tools
Test Automation Testing Tools Which tools will be used to perform different tests (e.g. SAP
Solution Manager) Defect Management Description of how defects will be
documented (e.g. Test Workbench in SAP Solution Manager) Roles and Responsibilities
Description of required test roles and responsibilities, e.g. Test Lead and responsibilities of individual
project team members related to testing Requirements and Constraints This activity is required for all
scenarios. Procedure Make yourself Familiar with the Tools in Test Management, and Set Up Test
Management in SAP Solution Manager Test Scope Determination Detailed Test Planning How SAP Can
Support SAP's strategy for test management is guided by establishing SAP Solution Manager as the
central platform for E2E process testing. SAP Solution Manager delivers all major functions to handle all
aspects of test management for SAP-centric solutions. This can be using either its own tools or those of
integrated partner solutions. SAP’s Support Standard for Test Management describes tools and
scenarios in Test Management with SAP Solution Manager. Furthermore SAP can offer advice on how to
improve the overall test management approach as part of Premium Engagement: Increased transparency
Estimation of expected test effort and custom code adjustments for SP or EhP upgrade Optimize
test effort Reliable traceable test results Risk based testing SAP can help you getng your SAP
Solution Manager configured and the Test Management process ready to run. See the accelerator section
for more details on the test suite in SAP Solution Manager. SAP can help you getng your SAP Solution
Manager configured and the Test Management process ready to run. Finally SAP supports this activity with
the “ Test Planning ” service component as part of the Build Design service. See
The goal of this task is to make you familiar with the test tools in SAP Solution Manager, and their setup.
How SAP Can Support SAP offers Expert Guided Implementation (EGI) sessions to Enterprise Support
customers. See the SAP Enterprise Support Academy for getng a complete overview. Some EGI sessions
that help you set up Test Management in SAP Solution Manager are listed in the accelerator section.
The scope of testing for a project, regardless if the project is executed independently or as part of a release,
needs to be determined early in order to ensure the testing environments and materials are available for
execution. With such a variety of testing cycles (e.g. integration, regression, performance, cutover, user
acceptance, etc.) available, it is important to define the cycles that are required to support the planned
conversion event. Prerequisites Prerequisite is here that test and quality management processes and
procedures are already in place. Procedure Evaluate the existing process and procedures to determine
the different testing cycles required to support the project. Utilize the existing process and procedures to
guide the decision making process on how to determine the applicable test cases and test scripts. The
results from the Delta Design activity serves as the input. As a best practice to compile test cases and test
scripts, it is recommended to define business critical transactions/reports, evaluate most frequently used
transactions/reports, and analyze prior productions support issues. With the scope of the transition
project, it’s important to identify test cases and scripts related to the financial solution, however
it’s also important not to neglect or underestimate the testing requirements in other parts of the
solution. This holds true especially with the migration from any DB to SAP HANA and/or the inclusion of
changes to the software levels. In particular for new implementation: Determine the overall test data
approach by aligning with the overall data migration approach. The test data approach will be documented
as part of the testing strategy. Document your findings in a test strategy document, and store it centrally
in SAP Solution Manager Results As a result, a test strategy, and a defined set of test cycles, test
cases, and test scripts in scope to support the conversion project are created.
Scoping and planning the tests required for the transition project is a requirement regardless if the project
is executed as a “pure” technical conversion, or as a combined conversion project with the
enablement of new functionality, or as a new implementation project. The focus is to determine which of
the required testing cycles (e.g. functional, scenario, integration, regression, user acceptance, performance,
and/or cutover) are required to fulfill the quality gate criteria of the Realize phase. Furthermore the start
date, duration, criteria, and resources for each of the required testing cycles needs to be planned.
Procedure Evaluate and enable test management and test automation tools to support the testing
cycles. Execute the tasks within this activity utilizing the SAP Application Lifecycle Management Best
Practices for Test Management. Tailor the templates for Test Strategy, and the high-level Functional Test
Plan to your needs. A detailed testing plan that is integrated with the project plan and aligned with the
overall SAP Software Change Management strategy. The plan should support the objective of mitigating risk
both to the end-state solution and the cutover process required to position the end-state.
The purpose of this activity is to setup the integration of the affected landscape components into the
development, quality assurance and production SAP S/4HANA system. The following picture displays the
integration in general for cloud and on-premise, between applications, business partners, real world
objects, and end users. This activity focuses on the integration (blue arrows) of SAP S/4HANA on-premise.
Requirements and Constraints This activity is recommended for all scenarios. In order to be able to conduct
the setup properly, the integration was scoped (i.e. in form of a system & solution architecture with
interfaces, and a mapping of functional requirements onto SAP solutions) and planned within the Prepare
phase of the transition project. The corresponding bordering systems are available. Procedure Implement
the listed tasks to integrate the bordering systems. Setup B2B Integration Setup A2A Integration
(On-Premise & Cloud) Setup Solution Manager Integration Setup Output Management
Setup User Interface (UI) Integration Setup Internet of Things (IoT) Integration Setup Integration to
Mobile Solutions Results As a results the corresponding systems have been integrated successfully. How
SAP Can Support SAP supports this activity with the “SAP S/4HANA Transition to New
Implementation (TNI)” service component as part of the service “Planning the
Digital Transformation” . The determination of a project scope and the creation of an initial project
schedule is part of this service component. See also activity Transition Planning in the
Prepare phase, for more information on this service component.
Business to Business (B2B) Integration describes the chaining of processes between business partners. In
addition to the requirements of the A2A integration, this scenario requires support of a variety of industry
standards (for example, EDI, AS2) and management of a potentially large number of business partners. Like
in the A2A scenario, business users have to be able to handle failed messages in their application context.
Prerequisites The integration infrastructure (network, firewall configuration, router) has been setup by the
local IT personnel, and connection between business parties A and B is possible. The affected systems (SAP
S/4HANA, SAP XI/PI, middleware, 3 rd party ERP) of the involved business parties A and B are
completely setup by the corresponding basis resources. Procedure This section provides an overview of the
most important concepts related to the configuration of cross-company processes (orbusiness-to-business
(B2B) processes) in the Integration Directory. Please note: This section merely contains an overview of the
most important concepts. Details of the configuration depend on the underlying business process and the
specific system landscape, and are much more extensive than described here. The procedure for
configuring business-to-business processes is essentially the same as the procedure for configuring
application-to-application processes. You also use the same types of configuration objects. However, when
configuring business-to-business processes you can apply additional concepts. One special aspect of B2B
configuration is that the business partners involved in B2B processes do not usually share information
about their own internal system landscape. You configure a B2B process in the Integration Directories of
the involved company. If you use process integration scenarios as the basis for the configuration, the
different business partners use the appropriate “Component Views”. Each company just
configures their part of the system landscape that is relevant to them. This is done in the Integration
Directory. The process can only be executed when all business partners involved have fully completed their
configuration. On top of this, integration experts finalize – per involved business pratner - the
configuration setngs for their local part of the system landscape. Depending on the protocol used, all data
(including passwords) is usually transmitted through the network (intranet or Internet) in plain text. To
maintain the confidentiality of this data, you should apply transport-layer encryption (e.g. HTTPS / SSL) for
both internal communication and message exchange. Results Once setup has been completed the business
partners are able to exchange and share defined business data in a secured way. How SAP Can Support SAP
has plans to offer services to support the B2B integration setup in future. Once set up, SAP recommends to
use the “B2B Integration Cockpit” for monitoring and administration. See
Application to Application (A2A) integration covers the chaining of processes between applications. For
example, the integration of SAP Hybris C4C with SAP S/4HANA to enable the opportunity-to-order process.
Particularly important for this kind of integration is to ensure transactional process integrity, as well as
monitoring and tracing on single business object level. In this context A2A integration is not limited only to
SAP systems but also include integration of third party SaaS providers. Orchestration capabilities are used
to manage the message choreography between applications (for example, pull/push interactions). A further
characteristic of this scenario is that business users typically handle errors derived from failed messages in
their application context (for example, processing of failed invoices in financial transactions). SAP offers
integration best practice content to customers and partners, to set up integration very quickly and
efficiently while still having the flexibility to adapt customer specific requirements. Best practice content
can be accessed in the SAP Best Practices Explorer (see accelerator section). For SAP S/4HANA, on-premise
edition 1610 the following SAP Best Practices are available: SAP S/4HANA integration with SAP
SuccessFactors Employee Central Employee Integration: S/4HANA on-premise with Employee Central
(1HW) SAP S/4HANA integration with SAP Financial Services Network Bank Integration with Financial
Services Network (16R) SAP S/4HANA integration with SAP Hybris Cloud for Customer SAP Extended
Warehouse Management integration with SAP S/4HANA rapid-deployment solution (15 scope
items) SAP S/4HANA integration with SAP Fieldglass solutions Fieldglass - Contingent labour and
Invoice integration with Finance (19W) SAP S/4HANA integration with SAP Ariba solutions (3
scope items) SAP Hybris Marketing Cloud integration with SAP Hybris Cloud for Customer SAP Hybris
Marketing Cloud integration with SAP Hybris Cloud for Customer (1J9) SAP S/4HANA Enterprise
Management integration with SAP Hybris Commerce (2 scope items) SAP Customer Activity
Repository for SAP S/4HANA Retail rapid-deployment solution (POS Data Transfer & Audit -
R72) SAP S/4HANA integration with Concur solutions (Concur - Financial Integration - 1M1)
Please see SAP Best Practices Explorer to get the most current list of integration best practices (click
SAP S/4HANA >> Integration ). Prerequisites See sections “Software Requirements”,
“Software and delivery requirements” and “SAP Note” in the corresponding
best practice package in the SAP Best Practices Explorer (accelerator section). Procedure See section
“Implementation” in the corresponding best practice package in the SAP Best Practices
Explorer (accelerator section). Results The integration to the corresponding cloud solution is available. How
SAP Can Support SAP supports this activity with several integration best practices to implement the
corresponding integration package.Integration best practices can be found in the SAP Best Practices
Explorer . You should also look up the SAP API Business Hub where you can discover and consume digital
content packages with APIs, pre-packaged integrations, and sample apps from SAP and select partners. See
In case you would like to use SAP Solution Manager on-premise to support your transition project, or to
operate the SAP S/4HANA solution after Go-Live, a basic integration of SAP Solution Manager is required.
SAP Solution Manager supports: Portfolio to Project (P2P) to drive the portfolio of projects and
balance business initiatives and their business value against IT capacity, skills and timelines Requirement
to Deploy (R2D) to build what the business needs, when it needs it with measured business
outcome Detect to Correct (D2C) to anticipate and resolve production problems Request to
Fulfill (R2F) to catalog, request and fulfill services See accelerator section for more details. Please
note: Alternatively, you can also use a pre-configured SAP Solution Manager 7.2 CAL image which is hosted
by your cloud provider, to support project management and functional design. In this case, no integration
with the on-premise landscape is done. Prerequisites SAP Solution Manager 7.2 on-premise is already set
up (see activity Project Delivery and Platform Setup in the Prepare phase). Basic
configuration (SOLMAN_SETUP transaction) has been finished. Procedure Register all newly created SAP
S/4HANA systems in SAP Solution Manager using the “Managed System Configuration” in
transaction SOLMAN_SETUP. Once the registration has been completed, configure your additional SAP
Solution Manager capabilities, such as process management, or change control management. See various
information sources in the accelerator section for details. Results Your SAP S/4HANA landscape has been
successfully integrated with SAP Solution Manager 7.2. How SAP Can Support SAP supports this activity
with the “Implementation of SAP Solution Manager for IT Operations” service . Please ask
your SAP contact (e.g. SAP Client Partner) for more information. In addition, SAP supports this activity with
the “SAP Solution Manager Starter Pack” service. The SAP Solution Manager
Starter Pack is applicable when you need direct assistance with the basic configuration and use of the SAP
Solution Manager.
SAP S/4HANA introduces a new style of output management (OM). See task Run a first Assessment
on Output Management in the Prepare phase for more details. The objective of this task is to setup
output management. Procedure Study SAP note 2228611 on the new output management for SAP
S/4HANA, if not already done in the Prepare phase of the project. For those applications, which have
already adopted the new framework: Customize the new output management as lined out in the SAP notes
listed in the accelerator section. Results After conducting the outlined steps the output control for SAP
S/4HANA is configured.
SAP S/4HANA comes with a great user experience based on SAP Fiori. The objective of this task is to
integrate the user layer in such a way that Fiori UIs run stable, secure and with best performance. Please
note: Integration with standard SAP UI technology (SAPGUI, SAP Business Client) is not further explained in
this task. See SAP Online Help Portal for details. Prerequisites See pre-requisites documented for
“SAP Best Practices for user experience in S/4HANA”. Procedure SAP offers a best practices
documentation named “Best Practices for user experience in SAP S/4HANA”, that covers key
UI integration aspects like: Create Fiori Users Connect SAP Gateway to SAP S/4HANA Configuring
SAP Web Dispatcher Configure SAP Fiori in a multi-tier landscape using transports Check and Activate
HTTP Service in SAP Gateway System Set up of SSO SAML 2.0 (Single Sign On); See also the SAP Blog
“SAP Cloud Identity SAML 2.0 Authentication with SAP S/4HANA Fiori Launchpad” from the
SAP RIG team Enablement of the HTTPS for Apache Reverse (Optional) Enable SAP JAM Integration.
This SAP Best Practices can be retrieved in the SAP Best Practices Explorer (accelerator section). Review and
identify the scope items and building blocks that are relevant for your project. Activate the selected scope
item, by following the instructions given in the configuration guides. Please take care of properly aligning
the UI integration task with the UI activities in the Application: Design and Configuration work stream.
Results After using information & instruction within the scoping items the UI integration is
setup. How SAP Can Support SAP provides the “SAP Best Practices for user experience in
S/4HANA”. SAP further supports the design of Fiori UIs in the “Build Design”
service.
The Internet of Things (IoT) Integration refers to the integration of data from real world objects (for
example, machines, sensors, assets) with transactional and/or analytical applications. Typical
characteristics of this use case are the management and integration of IoT devices, as well as capabilities to
handle massive data traffic through high-performance message pipelines. Furthermore, IoT connectivity
capabilities and merging IoT industry standards like MQTT need to be supported. Optionally, complex event
stream processing to filter, aggregate, and enrich raw IoT data before persisting it in the database might be
required. Note: This task currently contains only general aspects on this topic but will be detailed
out in one of the next roadmap releases. Procedure IoT integration in the context of SAP S/4HANA is always
related to the SAP Cloud Platform, and with IoT services running on the SAP Cloud Platform. Proceed as
follows: Make yourself familiar with the SAP Cloud Platform , by checking out the landing page in
the SAP Online Help Portal. This information source contains getng-started material, online training at
openSAP, and the integration between SAP S/4HANA and the SAP Cloud Platform. As a next step, make
yourself familiar with the SAP Cloud Platform Internet of Things for the Cloud Foundry
Environment, by checking out the landing page in the SAP Online Help Portal. This page describes
core IoT services, and how to configure them. Finally make yourself familiar with the SAP IoT
Application Enablement solution which is a collection of services, apps, and UI templates that help
you modeling digital twins of real-world objects. The landing page in the SAP Online Help Portal contains a
getng-started material with the most important configuration information. Follow the instructions given
in the corresponding configuration guides. How SAP Can Support IoT scenarios belong to the SAP Leonardo
portfolio – which integrates breakthrough technologies like IoT, Blockchain and Machine Learning,
and runs them seamlessly in the cloud. See accelerator section for details. From the main page, you can
easily navigate down to the SAP Leonardo innovation services, which help you setng up an example of
your first IoT scenario.
Mobile Integration refers to mobile apps consuming backend services by using native or hybrid device
capabilities. Typical characteristics of this scenario pattern are online/offline support, data security and
protection, as well as device and application lifecycle management. Offline support enables client
applications to access back end data without requiring a connection to the back end. You might want to run
applications offline to: Improve performance by accessing offline data instead of sending data requests to
SAP Mobile Platform Server. Enable users to continue to use applications when there is intermittent
network coverage. Support business processes that must be executed by a user while the application is
offline. Note: This task currently contains only general aspects on this topic but will be detailed out
in one of the next roadmap releases. Procedure As a first step make yourself familiar with the options you
have to integrate mobile solutions (for instance the SAP Mobile Platform Server, or the SAP Cloud Platform
Mobile Services). In case you are starting fresh with mobile applications the right option for you may also
be influenced by your UX strategy you have with SAP S/4HANA (see activities for Fit / Gap in
this phase of the project). Please note that Fiori UIs can easily ported to mobile devices. Please see the SAP
Mobile Platform Community (accelerator section) for more information. In case you use the SAP Mobile
Platform Server, you need to perform post installation tasks before performing any server or application
administration tasks. The post installation tasks you need to perform depend on the landscape you need to
support: Configure reverse proxies and load balancers for managing in-bound application requests to SAP
Mobile Platform Server. Configure communications between the server and your supported back end
systems. Set up communications between the server and the Apple Push Notification Service (APNS).
Set up the security landscape for the server. You can also look at the scope item Sample Mobile App
Creation for SAP S/4HANA (MEO) of SAP Best Practices for user experience in SAP S/4HANA
( accelerator section): Here you can validate the configuration with an SFLIGHT sample app, which includes
offline OData support, push and barcode reader features so that you can test the end-to-end configuration
of either SAP Mobile Platform or SAP Cloud Platform Mobile Services. Results After successful setup of the
integration for the mobile solution the solution can be used within the project (i.e. FIT/GAP workshop,
enhancing, testing, Go-Live). How SAP Can Support See accelerator section.
The purpose of the integration design activity is to detail and document all integration aspects of the
project, that have been identified in the Prepare phase. Important topics for the integration design are i.e.:
Design of the to-be system & solution landscape with interfaces (scoped i.e. in the SAP S/4HANA
Transition to New Implementation (TNI) workshop – see activity Transition Planning in
the Prepare phase for details). All other technical, non-business priority specific topics. This leads to
finalizing the respective design document in a format suitable for communication as well as for formal sign-
off. Requirements and Constraints This activity is recommended for all scenarios. Further requirements:
To-be system and solution architecture with interfaces has been defined and fixed. Interface
architecture has been defined as scope and fixed. All other integration aspects and requirements have
been discussed. Procedure The level of detail in integration design specification should be in such a way,
that configuration and development can start based on the description. This activity should be executed in
close cooperation with the Fit Gap / Delta Design activities of the Application: Design
& Configuration work stream. This activity is structured into two tasks: Define Interface
Architecture Prepare Integration Design Results The result is a finalized, reviewed and singed integration
design.
SAP and non-SAP systems use interfaces to communicate to other system in the solution landscape.
The interface architecture displays the interfaces and indicates additional attributes i.e. the used
technology (i.e. middleware), protocol type, frequency- and direction of communication. The objective of
this task is to prepare a system & solution architecture with interfaces. Prerequisites As a
prerequisite, the customer needs to have a clear vision of his to-be system and solution architecture.
An interface register that represents the current interface scope needs to be defined (see activity Transition
Planning in the Prepare phase) If the interface scope or the system and solution architecture changes it
might be necessary to adapt the interface architecture. Procedure Define initial interface register to fix
scope Define to-be system and solution architecture Create to-be system and solution architecture
with interfaces Results The result of this task is a to-be system and solution architecture with interfaces,
which is referenced in the scope statement. How SAP Can Support SAP supports this activity with
the “SAP S/4HANA Transition for New Implementation (TNI)” service
component as part of the service “Planning the Digital Transformation” . The service
components provide a system & solution architecture with interfaces as one of its deliverables. The
SAP S/4HANA Value Assurance service package component “Technical Architecture &
Infrastructure (TAI)” provides as main deliverable a design of a new – or review of an already
existing – technical architecture for an SAP solution. See accelerator section for details.
The purpose of the integration design activity is to detail and document the different integration aspects,
that were identified during the preparation of the to-be system & solution Landscape with interfaces
and the interface architecture. This leads to finalizing the respective design documents in a format suitable
for communication as well as for formal sign-off. Prerequisites To-be system and solution architecture
with interfaces has been defined in scope and singed-off. Interface architecture has been defined in
scope and singed-off. Procedure For each relevant integration aspect, the following criteria should be
described in one overall integration delta design document: Short description of the integration aspect
(project and SAP S/4HANA specific) General business requirements (i.e. frequency of replication, required
fields) Necessary IT systems e.g. interfaced systems to SAP S/4HANA Identification of integration gaps
(i.e. reference to gap backlog) Solution for gaps (used middleware, field mapping, required configuration,
used best practices) Important customizing Developments Organizational aspects Process
quantification (e.g. expected data volume) The level of detail of each integration design document should
be in a way, that configuration can start based on the description. Results The result is a finalized, reviewed
and signed integration design. How SAP Can Support SAP supports this activity with the “SAP
Interface Management” service (IFM)” service for Premium Engagement customers.
The SAP Interface Management service analyzes and optimizes the design, configuration, and operation of
interfaces that are essential to your core business processes. The analysis of the interface design and
configuration in the context of a core business process is also covered by the SAP Value Assurance service
component “ S/4 HANA Business Process Technical Validation ” (service “Safeguarding
the Digital transformation”). SAP supports this activity with the “SAP S/4HANA
Transition to New Implementation (TNI)” service component as part of the service
“Planning the Digital Transformation”. The creation or review of the to-be system
& solution architecture with Interfaces is part of this service component. This service component
includes the determination of the interface scope. You should also look up the SAP API Business Hub where
you can discover and consume digital content packages with APIs, pre-packaged integrations, and sample
apps from SAP and select partners. When it comes to integration via the SAP Cloud Platform, SAP has
launched the Integration Content Advisor (ICA, formerly named Integration Advisor). The ICA now supports
creating and maintaining B2B integration content much faster and more efficiently. The ICA follows a
revolutionary crowd-based machine learning approach, which enables a user to define, maintain, share,
and deploy B2B integration content based on a completely new paradigm. The newest release of the ICA is
available to all SAP Cloud Platform Integration Enterprise Edition licensees. See the SAP Blog
“Announcement: New integration content advisor for SAP Cloud Platform Integration” for more details
(accelerator section).
In the activity Project Delivery Platform Setup , all additional software which is required to implement SAP
S/4HANA is going to be set up or updated. Requirements and Constraints SAP Solution Manager has been
set up in the activity Project Delivery Platform Setup in the Prepare phase already. This activity is required
for landscape transformation and new implementation scenarios which are not limited to the use of
the SAP S/4HANA Migration Cockpit and SAP S/4HANA Migration Object Modeler. Procedure Set up
Landscape Transformation Software (LT scenarios only) or Set up Data Migration Services (New
Installation scenario only)
Depending on the scenario additional SAP LT software needs to be installed. Prerequisites The Data
Migration Design service has been delivered already (initial planning part). Procedure Details
on what needs to be installed and when, are defined in the activity Data Migration Design in
this phase of the project. Please note that additional license costs may apply. General information on the
SAP LT software can be found in the Accelerator’s section.
In case of a new installation scenario critical master and transactional data objects like material master,
profit center group, business partner and sales orders, purchase orders, contracts and more need to be
transferred from the legacy system to SAP S/4HANA. If the migration objects are limited to the listed 32
objects of the picture below, and no data cleansing/data quality checks are required, you can use the built-
in SAP S/4HANA Migration Cockpit out of the box. Required changes, for example adding fields, can be
managed by the SAP S/4HANA Migration Object Modeler. Figure: Preconfigured Business Objects (SAP
S/4HANA Cloud 1708 / On-Premise 1709) In all other cases, make use of the Data Migration Services.
Procedure The rapid data migration to SAP S/4HANA, on-premise edition allows you to extract and analyze
selected data from virtually any source system. By cleansing, validating, transforming, and migrating your
data from any system to SAP S/4HANA, on-premise edition, you will have high quality legacy data in your
SAP solution. See Accelerators section for more information, what additional software needs to be installed
to transfer the data. The RDM package contains detailed information, and a quick guide which explains
installation and configuration of the required software. Please note that additional license costs may apply.
The purpose of this activity is to technically set up a sandbox environment. The sandbox is later on
finalized by functional experts (see activity Activate Solution) to serve for Fit/Gap activities. The procedure
to create a sandbox depends on the scenario. Procedure Set Up SANDBOX (System Conversion scenario
only) Downtime Optimization Preparation (System Conversion scenario only) or Set Up SANDBOX
(New Installation scenario only) Please note: Before converting an SAP system, or installing a fresh one, you
will need to download SAP software from SAP Service Marketplace. The planning of such a change event is
done in the Maintenance Planner. After entering the required data, the Maintenance Planner fills your
download basket, and creates a control file (“stack-xml”), which is later on required for the
conversion and installation tools. The Maintenance Planner has been described in the activity Transition
Planning of the Explore phase - Please make yourself familiar with the tool, enter the required information,
and download the corresponding software including stack-xml. See accelerator section for details.
This task covers the provisioning of a sandbox environment in a conversion scenario. It is important to
migrate and convert sandbox copies of production early in the project. The migration and conversion of the
sandbox systems will provide valuable insights including confirmation of the planned conversion approach,
potential business downtime, required prerequisites, and experience in the nuances and the functionality
of each system. Prerequisites Prerequisite is that you have defined the conversion scope in the planning
phase and that you fulfilled all application prerequisites identified in the SAP Readiness Check for SAP
S/4HANA. Additionally you have already set up the required technical infrastructure. Procedure This is how
you should perform SANDBOX migrations and conversions as copies from production: Evaluate the
conversion approach, the conversion guide and heterogeneous system copy guides (if required) to
determine the necessary steps to achieve the end-state. Review related SAP Notes for the migration to
the target platform. Perform homogeneous system copies to establish the environment that represents
the initial-state. Dependent upon the scope of the project, the system sequence, and the high-level plan;
the initial sandbox migration could include the full scope or just the first system planned for migration.
Execute the mandatory preparation steps which have not been done already upfront. Typically, many SI-
checks executed by SUM will report issues, which needs to be addressed (partly in the production system)
before the system conversion can start – so the first sandbox run will take longer. See activity Transition
Preparation in the Prepare phase of the project. Establish a software repository on a file server to create
a central location for all files used in the migration process. Execute the conversion of the sandbox
system(s) using the process intended for the production systems. Document what preparatory steps still
need to be done in production, before the conversion of the supporting system starts. Document every
step of the conversion to build a cookbook specific to the environment in scope. The intent of such a
document is the make the process resource independent. For contingency purposes, all knowledge
required for the conversion should be captured in the cookbook. The document should be validated, and
extended, in further test conversion. The cookbook should include every step in the process including, but
not limited to prerequisites, file names, patch levels, parameters, inputs to selection screens and duration
for each step. Besides the pure technical aspects of the conversion application aspects should be taken
into account as well. This can be specific activities from a business process level that have to be executed as
part of the system ramp-down before the migration or the ramp-up after the conversion. It can be related
as well to data consistency checks (reconciliation reports run before and after conversion to compare e.g.
summary of ledgers, checks for duplicate records and others). There are also mandatory post-
processing’s in the finance area. Record the anticipated business downtime(s) for the overall
migration and conversion process. Utilize prior maintenance activities to estimate the ramp-down and
ramp-up activities that would precede and follow the technical steps of the conversion. The time should be
captured at a detailed level in order to find opportunities for optimization. Please note: A conversion run
may identify business date inconsistencies which need to be corrected in both sandbox and the productive
SAP ECC source system. Depending on the inconsistencies the sandbox conversion run needs to be
repeated until all business data inconsistencies have been cleaned up (or marked as irrelevant). Please see
the lessons-learned document on finance in the accelerator section for more details. The more important
Depending upon the downtime requirements of the business and the downtimes already achieved during
the test migrations, there may be the need to execute iterative testing cycles to optimize the migration and
conversion procedures. The time required for this task should be planned for as a contingency when
building the project plan, but in a best case never utilized. In that best case scenario, where the downtime
meets the downtime requirements of the business, this time can be reallocated to other aspects of the
project. During this task the timings of each part of the migration and conversion needs to be carefully
evaluated to determine opportunities for optimization. As the overall duration has many influencing factors
(e.g. database size, network throughput, CPU speed, disk IO, etc…), there are some constraints on
what can be done to reduce the downtime. Therefore it is important to manage the expectations of the
downtime, with the business early in the project. If the business offers only a limited downtime window,
this should be discussed early in the project planning phase with a contact from SAP The conversion for
SAP S/4HANA requires additional downtime for the application data model conversion, in addition to the
downtime for the system ramp-down, S/4HANA software implementation, HANA migration, and ramp-up).
Data volume in conversion relevant tables Data quality - specifically the data
consistency and data diversity of the financial tables BSEG and COEP Memory capacity for data
migration Number of parallel jobs (option to split into smaller packages based on company code
and fiscal year) Overall system performance (I/O, CPU, memory, tuning, etc…) For systems
larger than 2 Terabyte, a downtime minimized approach may be required to support the data model
conversion within the permitted business downtime. A good general overview of the Downtime
Optimization options can be retrieved from SAP SCN (see Accelerator’s section). Their availability
depends on various factors (e.g. do you start from SAP ERP, or SAP Suite on HANA? Is SAP executing the
conversion or not?). Ask your SAP TQM for more information in case there are indications for additional
downtime optimization. Procedure To optimize migration and conversion downtime, proceed as follows:
Analyze the conversion logs (e.g. from sandbox migration and conversion) to determine the long running
phases. Identify bottlenecks and evaluate opportunities to reduce the runtime of the long running
phases. For MaxAttention and ActiveEmbedded customers, if necessary, engage the
embedded support team to provide expert analysis of the end-to-end business downtime. Execute the
conversion following the adoption of the recommendations. There may be the need to perform multiple
iterations in order to achieve the required business downtime. Results As a result, you will get an optimized
conversion process, to help meeting the downtime requirements set by the business. How SAP Can
Support SAP can support the downtime optimization in system conversion scenarios. The “ Business
Downtime Optimization ” service component is part of the Safeguarding the Digital
Transformation service. By analyzing each business step and its dependencies within the affected
system landscape, this service supports efficient downtime planning and a reduction of the business impact
during cutover. Each step which is scheduled to be executed during the business downtime will be analyzed
and optimized to reduce the overall downtime as much as possible. The design of the technical procedure
of the system conversion will be analyzed and simplified if possible. The SAP service team will review and if
possible optimize the tools, methods and technologies that you have chosen. See accelerator section for
The purpose of this task is to setup the sandbox system – ideally with all the capabilities that are
delivered by either Best Practices, Model Company or RDS package(s) – to start with a system which
is already pre-configured. In case this is not possible (e.g. because no best practice content is available for
the functionality in scope), a new (and empty) SAP S/4HANA system needs to be installed. Once the
Sandbox environment is setup, the project team will prepare it for the fit/gap analysis workshops. This
typically includes the adjustments to organizational structure, changes to the master data and potential
configuration of additional functionality that is critical to be included in the fit/gap analysis. Procedure
There are several cases to distinguish. A software appliance can be used, because SAP best practice
content may fit to the functional scope Using a software appliance for sandbox is the fastest way to
provide a pre-configured environment to the functional project team. The appliance can be consumed
in three ways: Hosted in the cloud Customers can access the appliance via the SAP Cloud
Appliance Library (SAP CAL, https://cal.sap.com) in a pay-per-use model hosted on a cloud provider (for
instance Amazon Web Services (AWS)). When using the SAP CAL option, the customer can choose between
a 30-day trial and a longer-lasting engagement. With the trial, only AWS hosting fees need to be paid by the
customer (exact costs to be determined, should be in the range of 3-5 USD per uptime hour). If the
customer opts to go beyond the 30-day limit, an SAP CAL subscription license and a regular SAP S/4HANA
license is required. Besides the SAP S/4HANA backend, the customer also receives access to a MS Remote
Terminal Server (WTS) with the pre-configured Fiori Launchpad URL, SAP GUI logon, and other useful
frontend software. Installed on-premise: If customers/partners prefer an on-site installation on their
own hardware, they can order a Blu-Ray disc from SAP and unpack the appliance from the Blu-Ray (in this
case, an SAP HANA and a Linux platform are required on-site). In addition, a service relationship with SAP
and a regular SAP S/4HANA license is required. Details can be found in SAP notes 2041140 (for partners)
and 2202234 (for customers). In case of an on-premise installation, customers can also decide to install an
empty SAP S/4HANA system, without pre-configuration. The SAP Model Company is the third way to
start with a pre-configured system It depends on the SAP Model Company itself, how installation and
content activation is done. See also activity Provide a Trial System in the Discover phase, and the task
Define Cutover Approach in the Prepare phase. However, please note that SAP does not recommend to use
a software appliance as a regular DEV system later in the project. Instead, the DEV system needs to be
installed fresh. Best practice content may fit to the functional scope, but the sandbox is installed fresh
(without using a software appliance) A fresh installation of SAP S/4HANA offers more options to configure
the technical architecture of the system, and to activate content selectively. In this case, you install a new
and empty SAP S/4HANA system, by following “Installation Guide for SAP S/4HANA”.
Afterwards, you create a new best practice client by selectively copying customizing content from client
000. Then you import the newest best practice content into the newly created client, and selectively
activate content depending on your functional scope. This is done by the functional project team, by using
the Solution Builder (transaction SMB/BBI). See activity Activate Solution for details. All steps for handling
best practice content are described in great detail in the “Administration Guide for the
Implementation
In this activity theoftransfer
SAP S/4HANA”.
of business dataPlease remember:
from legacy If the
systems set-up
to the of the
newly sandbox is SAP
implemented doneS/4HANA
via
system is designed. This activity covers both the simple scenario, where standard tools or best practices
concepts are sufficient, and the complex LT scenario. Requirements and Constraints This activity is required
for new implementation and landscape transformation scenarios in case data needs to be transferred from
legacy systems. Procedure The procedure differs depending on the implementation scenario. For
new implementations , the procedure during the explore phase is as follows: Prepare and conduct data
migration Assessment Data audit Prepare and present data migration scope and requirements
document Data migration approach and strategy document Test data management Define
specifications for data migration Look up the SAP Blog “Migrating data to your (new) SAP
S/4HANA” to learn about the ways in which your business data can be migrated to your newly
deployed SAP S/4HANA system (on premise or cloud). For landscape transformation scenarios
(client transfer, system merge, company code transfer, and Rapid Data Migration to SAP S/4HANA),
the procedure is as follows: Run a landscape transformation assessment for the specific scenario
together with your LT implementation partner or SAP Ideally a first assessment on data migration design
has been performed in the Prepare phase of the project already (e.g. as part of the “Transition
Planning for New Implementation” service component, or as a dedicated “Data Migration
Architecture” assessment; see Transition Planning service component for more details).
The purpose of this task is to explain the typical SAP data migration approach and tools available and to
understand the customer’s legacy data systems, business priorities, and technical infrastructure.
The outcome should be a definition of the relevant data objects required in the new solution in this phase.
Procedure During the Fit/Gap analysis, the project team validated the predefined scenario provided by the
S/4HANA solution. The documented fits and gaps between out-of-the-box S/4 HANA Best Practices and
customer's business requirements will dictate what kind of data objects will be migrated to the new
system. Scenario 1a: Fit – use of SAP S/4HANA Migration Cockpit and SAP S/4HANA
Migration Object Modeler In the SAP S/4HANA Migration Cockpit, templates are available that specify the
relevant data for each migration object. SAP provide templates (Microsoft Excel XML files) that can be used
for each migration object. If a template does not meet the business requirement (for example if the
relevant Microsoft Excel XML file does not contain all the fields that are needed for the target structure),
the SAP S/4HANA Migration Object Modeler can be used to adjust the relevant migration object.
Scenario 1b: Fit – use of Rapid Data Migration to SAP S/4HANA, on premise edition Rapid
Data Migration to SAP S/4HANA, on-premise edition is a SAP Best Practices package that offers out-
of-the-box solution to migrate 40+ data objects. In the Content Library, the project team members can
select from a list of pre-defined scope options to filter the data objects for their project. Please note, such
Rapid Data Migration package is designed to load only limited types of legacy data that are required to
support a SAP Rapid Data Migration to SAP S/4HANA deployment. Please see accelerator section for
details. Scenario 2: Gap In case the data migration targets on the types of legacy data that are not
covered by the Rapid Data Migration package, it is necessary to document such data objects and their
elements in detail. In either scenario, the deliverable of this task is a Data Migration Workshop Findings
document (link below) that typically covers the following: High Level Project Description
Go-Live Strategy Data Governance (Roles, Responsibilities) Source Systems, Data Objects
and Mapping Source System Data Demographics and Volume High Level Project Plan (a
section designated to data migration including risks identified and mitigation plan) How SAP Can
Support As mentioned above: A first assessment on data migration design can be supported by a “
Transition Planning for New Implementation ” service component, or as a dedicated “ Data
Migration Architecture ” assessment; see Transition Planning service component for
more details). For the “Fit” case the “ Rapid Data Migration to SAP S/4HANA on
Premise” scope option of the Data Migration Execution service helps you to migrate your
data from any system to SAP S/4HANA on premise. It accelerates the data migration process by using
prebuilt SAP Best Practices content for over 40 critical master and transactional data. Please contact your
SAP Client Partner for more information. SAP Enterprise Support customers can also listen to the Meet the
Expert recording “ Rapid Data Migration to SAP Business Suite 4 SAP HANA, on-premise ”
which explains how to accelerate your data migration project with pre-built best-practices content for over
40 critical master and transactional data objects. For the “Gap“ case (and also in case
“Fit” and “Gap” are not clear yet), SAP offers a “Data Migration
Assessment“,
The purpose of the datawhere data
audit migration
is to identify can be planned
the legacy in detail,
systems andsupply
that will wheredata
all important aspects
for the SAP are
applications
and to profile the quality of the legacy data. Data profiling is the process of analyzing the legacy source
data to detect anomalies and of validating the business rules. Procedure In the data audit, the focus is on
conducting a high-level summary analysis, looking for typical problems such as missing data and column
names that are inconsistent with content. The data audit involves working with the business users to help
map out the gap between the existing and required levels of data quality. The Rapid Data Migration
package provides two tools to assist with data profiling on some master data objects (e.g. customer,
vendor, business partner, etc.): Data Services - provides a basic profiling capability Information
Steward - provides different types of profiling Columns Address Dependency Redundancy Uniqueness SAP
Best Practice Data Quality for Data Migration (listed in accelerator) provides more details. The project team
can use below accelerators to capture data profiling information on all needed data objects whether they
are covered by the Rapid Data Migration package or not. How SAP Can Support SAP offers a “Data
Migration Assessment“, where data auditing is discussed.
The purpose of this task is to prepare the data migration scope document, risk and issue document.
Procedure The content of this document should be based on findings from the data migration workshop
and data audit. The project team can use below accelerators as a starting template. How SAP Can Support
SAP offers a “Data Migration Assessment“, where major aspects of a data migration scope
and requirements document are discussed. The creation of the document is not part of the service, but in
the responsibility of the customer or implementation partner.
The purpose of the data migration approach and strategy document is to capture and communicate the
approach and strategy for the legacy data migration. Procedure This deliverable is intended to align all
project team members and obtain customer sign-off on the data migration framework and methodology.
Some of the most important parts of this document are listed below. Strategy and Approach: it
describes priorities and timescales of the achievable goals of data migration Data Assessment: this
section builds on top of the data migration scope and requirements document. It should contain
specification of the data to be migrated and a data dictionary that describes all the details of the data
objects. Data Quality and Cleansing: this part contains an abstraction of data audit's findings and
extend it to capture the appropriate data cleansing plan ETL Methodology: it describes an iterative four-
stage approach - analyzing the data, extracting and transforming the data, validating the data, and loading
it into targets with testing. The Data Migration Strategy and Approach Sample document below is a good
demonstration of how these parts can be laid out. How SAP Can Support SAP offers a “Data
Migration Assessment“, where major aspects of a data migration approach and strategy document
are discussed. The creation of the document is not part of the service, but in the responsibility of the
customer or implementation partner.
This is part of the data management that focuses on the data to be created in development and quality
assurance systems. Procedure The different characteristics and requirements of the test data should be
weighted, in order to choose the proper method and tool for data creation. Besides, one should also take
into consideration that certain data, particularly business-critical and personal data, should be kept
protected, before entering it in development and quality assurance systems.
The purpose of this task is to define the specifications (functional, technical) for data migration (extraction,
transformation, validation, load, etc.) for both automated process and manual process. Procedure The
overall objective of the automated data migration design is to deliver clean, load-ready data as input to the
standard SAP load utilities. However, there are cases that the automated programs are not available or the
data volume does not justify the investment in developing such programs. For example, due to the low data
volumes, it is quicker to convert certain types of master data (bank, cost center, and profit center) through
a manual process. Certain types of transactional data, such as open orders (sales, service) need to be
manually created by running SAP transactions in the target system. In many cases legacy data may include
sensitive or classified information that requires special handling procedures. The project team must identify
the data sets, determine the customer’s security policies and develop a solution that will isolate this
information from the non-secured data sets. For automated migrations, the security requirements can be
met through techniques or methods, such as file and database privileges or the deployment of an isolated
migration environment. For manual migrations, the recommended solution is to have the business owners
that have access to that data perform the manual migration. The end deliverable is a Data Security Design
document. The project team also needs to construct a Testing Strategy document detailing information
such as Test Cycle Definition, Roles and Responsibilities, etc. How SAP Can Support SAP offers a
“Data Migration Assessment“, where major aspects of a data migration approach and
strategy document are discussed. The creation of the document is not part of the service, but in the
responsibility of the customer or implementation partner.
Changing business requirements continuously drive organizations to realign and restructure their business.
As a consequence, the transformation of SAP landscapes has become an ongoing business for SAP
customers with a strategic importance to stay agile and competitive. Instead of replacing legacy
environments by using generic or self-made tools and technologies, SAP customers can use SAP Landscape
Transformation as a cost-efficient and secure alternative. SAP customers can manage their SAP-related
transformation requirements in a holistic manner - reflecting organizational changes, acquisitions of
companies, divestitures, or the harmonization of processes and data in their existing SAP system landscape.
The objective of this task is to run a landscape transformation assessment together with SAP. The scenarios
in scope are: Client transfer Consolidation of several ERP systems into one S/4HANA target system
(System merge) Company code transfer to S/4HANA target systems Data migrations based on
preconfigured objects How SAP Can Support The “ Data Migration Assessment ” service
component is part of the “ Data Migration Design ” service. It helps customers during the
preparation of the transformation to the SAP S/4HANA environment, and as such complements the SAP
S/4HANA migration options “New Implementation” and “System Conversion”.
The Data Migration Assessment service component provides assessments for the execution of the technical
landscape transformation scenarios listed above (more information provided in the Realize phase of this
road map):
Before configuration and development work starts in the Realize phase, the development system (DEV)
needs to be set up. It depends on the scenario how this is done. Please note: This road map documents the
setup of a DEV and a QAS system. Of course, the design of the production support landscape depends on
customer requirements for change management. Maybe additional supporting systems need to be set up
(e.g. pre-production or training). In those cases the project plan template needs to be adjusted accordingly.
Requirements and Constraints This activity is required for all scenarios. There is a technical design
document stored in SAP Solution Manager which includes the technical deployment plan, and the software
components which need to be installed / updated. Procedure DEV Setup (New Implementation) or
DEV Setup (System Conversion) Please note: Before converting an SAP system, or installing a fresh one, you
will need to download SAP software from SAP Service Marketplace. The planning of such a change event is
done in the Maintenance Planner. After entering the required data, the Maintenance Planner fills your
download basket, and creates a control file (“stack-xml”), which is later on required for the
conversion and installation tools. The Maintenance Planner has been described in the activity Transition
Planning of the Explore phase - Please make yourself familiar with the tool, enter the required information,
and download the corresponding software including stack-xml. See accelerator section for details. How SAP
Can Support SAP offers the provisioning of the DEV environment for both scenarios as part of the “
Platform Execution” service.Please ask your SAP contact (e.g. SAP Client Partner) for more
information. This is a dedicated scope option ( System Conversion for SAP S/4HANA
and System Installation for SAP S/4HAHA ). The setup of the technical Fiori components is
covered by scope option SAP Fiori Platform Setup . However, the configuration of the Fiori UIs is not
included in this scope option. See accelerator section for more information. SAP also offers to coach the
customer with respect to system setup tasks: Either via monitoring while the customer is executing the
setup. Or via shadowing with demo execution by SAP. This offering is part of SAP Value Assurance. It is
called “ Platform Execution Enablement ” (service component), and part of the “
Platform Design ” service. See accelerator section for details.
The goal of this task is to provide a viable, correctly configured technical development environment that is
available for use by the project team to begin the realize phase. Procedure Proceed as follows: Decide if
the sandbox environment should be re-used as the DEV environment. In this case no additional system
installation is required. Please note: A sandbox which has been set up by using a software appliance on
premise, and which is used as a DEV system afterwards may have activated business functionality which is
subject to additional licensing. In addition, the SAP BluRay comes with an embedded landscape for Fiori
(backend and frontend in the same machine) whereas SAP recommends a Central Hub set-up (having
frontend and backend separated) for productive systems. Therefore, SAP recommends to not use an SAP
appliance as a DEV system, but do a fresh SAP S/4HANA installation. Execute the technical installation
of the required SAP Products for DEV environment as documented in the technical design document. See
the “Installation Guide for SAP S/4HANA” how to install the components. Based on the
outcome the decision has been taken to either use SAP Best Practice content or not: In case to
not use SAP Best Practice content: Create a new client, and start configuration from scratch using
transaction SPRO. In case to use SAP Best Practice content: Follow the instructions given in the
“Administration Guide for the Implementation of SAP S/4HANA”. This will guide you through
the technical setup and the configuration process on top of the newest SAP Best Practice content. The
technical setup consists of three main steps: Import newest reference content into your
newly created development client Select the scope Activate the scope
The picture below shows these three steps in sequence. Figure: The three steps required to
activate best practices content This activity is done by the functional project team members. Results Finally,
the DEV environment is ready for configuration. How SAP Can Support SAP offers the installation of a
sandbox as part of the Platform Execution service. Please ask your SAP contact (e.g. SAP
Client Partner) for more information. This scope option is called “ System Installation for SAP
S/4HANA” – see accelerator section for more information. The setup of the Fiori
platform can be supported as well (scope option “ SAP Fiori Platform Setup
”). However, the configuration of the Fiori UIs is not included in this scope option but is
part of the functional setup. SAP also offers to coach the customer with respect to system setup tasks:
Either via monitoring while the customer is executing the setup. Or via shadowing with demo
execution by SAP. This offering is part of SAP Value Assurance. It is called “ Platform Execution
Enablement ” (service component), and part of the “ Platform Design ” service. See
accelerator section for details. Also, it is highly recommended to study the SAP Blog series “New
Installation of S/4HANA” from the Regional Implementation Group (RIG).
The goal of this task is to provide a viable, correctly configured technical development environment that is
available for use by the project team to begin the realize phase. DEV is not installed newly – instead,
the old DEV system is converted to SAP S/4HANA. Prerequisites Prerequisite is that the migration approach
that has been validated in a sandbox environment (see activity SANDBOX System Setup in
the Explore phase ) , a detailed migration plan is in place, and the required hardware for hosting the SAP
S/4HANA DEV system is already available and set up. Procedure Convert the DEV system according to the
migration plan (which is based on the “Conversion Guide for SAP S/4HANA”). Depending on
the transport landscape configuration, there may be a need to perform multiple iterations of the
conversion in order to solidify and finalize the cutover plan. Executing test migrations will validate the end-
state of the conversion, as well as provide the figures for expected system downtime (see activity
Downtime Optimization Preparation for details). Depending on the approach and the
transport landscape configuration, there may be a requirement to execute additional sandbox conversions
in order to optimize the cutover procedure. Please note: In case of a system conversion, the old DEV
system will stay for production support of PRD as long as PRD is not converted. Take care to properly
retrofit changes performed in the production support landscape to the new DEV system to ensure
the latest business requirements are accounted for within the project landscape. Depending on the
changes, those retrofit activities may require special attention, because transports between classic SAP ERP
and SAP S/4HANA may cause inconsistencies (see SAP Note 2192251 in the accelerator section) Results
Finally the DEV environment has been converted to SAP S/4HANA. It is ready for further configuration. How
SAP Can Support SAP offers the DEV conversion as part of the “ Platform Execution”
service. Please ask your SAP contact (e.g. SAP Client Partner) for more information. This scope
option is called “ System Conversion to SAP S/4HANA” – see accelerator
section for more information. The setup of the Fiori platform can be supported as well (scope option
“ SAP Fiori Platform Setup ”). However, the configuration of the Fiori UIs is not
included in this scope option, but is part of the functional setup. SAP also offers to coach the customer with
respect to system setup tasks: Either via monitoring while the customer is executing the setup. Or via
shadowing with demo execution by SAP. This offering is part of SAP Value Assurance. It is called “
Platform Execution Enablement ” (service component), and part of the “ Platform Design
” service. See accelerator section for details. Also, it is highly recommended to study the SAP Blog
series “System Conversion to S/4HANA” from the Regional Implementation Group (RIG).
Run a capacity estimation on the required hardware for application server and databases (CPU, RAM,
storage, network). There are several levels for sizing: Budget sizing for smaller companies, using very
simple algorithms. Advanced sizing for medium to large companies, using throughput estimates,
questionnaires, formulas. Advanced sizing uses standard tools (e.g. Quick Sizer) and focus on core business
processes. Expert sizing is based on a custom capacity model which for instance may also include custom
coding. Timing: Explore phase (non-production systems), realize phase (production and production-like
systems) Requirements and Constraints This activity is required for all scenarios. There is an
implementation plan available which provides first information about the target solution. Procedure
Perform / Check Initial Sizing Results There is a documented estimate on the required hardware, which can
be discussed with the hardware vendor.
The objective of this task is to either perform a sizing, or in case a first estimate has been provided already
check the initial sizing. Procedure An initial sizing should have been provided either as part of the
“Technical Architecture Workshop", or as part of the “Migration Planning
Workshop” in the Prepare phase. Both service components can be ordered as part of the
“Planning the Digital Transformation” service. In case initial sizing has not been done so
far or needs to be updated, you should follow the sizing procedures documented in the SAP note 1793345
“Sizing for SAP Suite on HANA” (accelerator section). For new implementation, initial sizing
is performed in the Quicksizer tool in SAP Service Marketplace (see “General Information on
Sizing” in the accelerator section). Run this activity for all related infrastructure components
(e.g. including Front End Server). In case of a system conversion, the sizing report should be executed
periodically in the productive system throughout the project to check on the growth of the source system.
Results A sizing has been performed and is documented. How SAP Can Support SAP can perform this task
with the “ Advanced Sizing ” service component, which is part of the “ Platform
Design” service. The service component fits to all three on-premise transition scenarios, and can be
also extended to capacity management requirements of very large systems including aspects like data
avoidance strategies, data tiering, or landscape scalability. SAP Enterprise Support customers can also listen
to the Meet the Expert recording “ Guided Sizing for SAP HANA ”. This session gives an
overview about the current knowledge on SAP HANA sizing and the principles on how to size SAP HANA in
a Greenfield and migration situation.
To be able to provide a detailed definition of the technical target architecture and infrastructure, you will
first need to clarify the technical boundary conditions. This is the basis for the creation of the Technical
Solution Blueprint. Requirements and Constraints This activity is required for all scenarios. There is an
implementation plan available which provides first information about the target solution. Procedure
Discover Technical Boundary Conditions Create Technical Solution Map Results As a result, there is a
documented technical solution map available in SAP Solution Manager. How SAP Can Support To minimize
the effects of unplanned down times, a comprehensive High Availability and Disaster Recovery architecture
is essential, as well as reliable backup and recovery procedures,considerations about tools available, and
test procedures. The “ Technical Platform Definition ” service component is part of the
“ Platform Design” service, and supports in these tasks. Moreover, the selection and proper
configuration of the technical platform is the foundation to achieve a flexible and scalable execution
environment for the new system. The “ Technical Platform Definition ” service component
also supports in the selection of the right IT infrastructure which is the basis for the vendor-selection
process, and provides Best Practices formapping the SAP software components on it.
The technical boundary conditions are input into the technical design document, which is the basis for the
subsequent Data Center service setup. In many cases these conditions are already defined by the customer.
Procedure The Technical Boundary Conditions in scope are: Technical solution map Non-
production system landscape Sizing DC strategy Availability requirements All information needs to
be stored in the Project Management space of SAP Solution Manager for central access. Non-production
System Landscape Collect the amount, size and purpose of the planned non-production systems per
SAP system. Align the plan with the implemented software change management strategy. The
information can be derived from the existing software change management model. Alternatively, design a
new software change management model according to SAP Best Practices. Timing: Explore phase or
early realize phase. DC Strategy Collect initial assumptions of the DC provider, topology, and DC roles.
The information can be derived from the existing DCs. Alternatively run a design workshop for a new DC
strategy. Timing: Explore phase (non-production systems), realize phase (production and
production-like systems) DC Strategy - Example The picture below shows as an example four options for a
DC strategy. They distinguish in setup, which leads to differences in risk mitigation, operational complexity,
and IT costs. Figure: Different options for the data center setup (example only) Availability
Requirements Collect availability information on: SLAs for unplanned downtimes (HA/DR).
SLAs for planned downtimes (maintenance). Classification of systems according the SLA.
The information can often be derived by using existingSLAs in the context of the new
solution. Alternatively run aworkshop for a high-level SLA definition (as part of the “Technical
Architecture” workshop and the “ Technical Platform Definition ”service component).
Timing: Realize phase. Availability Requirements – Example The following picture shows
exemplarily different definitions of “Mission Critical”, “Business Critical”, and
“Less Critical” applications. Figure: Different availability requirements (example only) Results
The technical boundary conditions are documented and stored in SAP Solution Manager. How SAP Can
Support As an introductory document, look up the SAP Blog “SAP S/4HANA On-Premisse Global
Deployment Options” from the SAP RIG team. With respect to service support from SAP, see
Technical Platform Definition service components in the activity description.
The objective of this task is to create a technical solution map of the target architecture. Prerequisites The
technical boundary conditions have been documented. Procedure Proceed as follows: Collect information
on installable technical components, required integration technology between them, and non-
functional req. of the integration technology. Collect information on the component deployment model (on
premise, cloud / SaaS). The information is usually provided by architects of the application work
stream. The Technical Solution Map should also cover: Minimum release levels
Dependencies between software releases / SAP Support Package Stacks Minimal Browser versions
If required: the outline that a Dual Stack split needs to be included in the conversion project If
required: List dependent SAP NetWeaver Hub systems, and their minimal release (See “Version
Interoperability” at the Accelerators section) Create a technical solution map (see
accelerator section for a template) and store it centrally in SAP Solution Manager. Results There is a
technical solution map of the target architecture available in SAP Solution Manager. How SAP Can Support
See Technical Platform Definition service components in the activity description.
Within the IT Infrastructure definition phase customers need to create a detailed technical platform design.
This includes the selection of hardware vendors for servers and storage, mapping of technical components,
network design and also the definition of cloud integration options. Requirements and Constraints
This activity is required for all on-premise scenarios. Procedure Decide on Integration with Cloud
Applications Hardware Selection and Utilization Develop Virtualization Strategy Design Network Test
Preparation Results As a result, there is a documented IT infrastructure definition available in SAP Solution
Manager. How SAP Can Support SAP can support all tasks of this activity with the “Technical
Platform Definition” service component, which is part of the “Platform Design”
service
The objective of this task is to decide on the integration with cloud applications. Procedure In case cloud
applications are in scope as well for the implementation project, backend integration with
these have to be discussed. For instance, available bandwidth, peak times, availability requirements and
recovery procedures might be a limiting factor here. Cloud applications could also be FIORI UIs running in
the SAP Cloud Platform which are connected to the SAP backend landscape via the SAP Cloud Connector.
Results As a result, a technical architecture for the integration of on-premise and cloud-solutions have to be
created
Within this task, customers decide on server and storage hardware. Prerequisites As a prerequisite, the
sizing results including the software change management landscape has to be mapped to possible
hardware and/ or virtual container sizes. Procedure An assessment of different hardware vendors and
products is recommended. For instance, different server models might be extendable or not which could
be an important factor depending on the capacity growth requirements. The hardware requirements have
to be mapped to project phases afterwards and planned together with the hardware vendor. Results As a
result, there is a documented deployment plan which includes the definition of the hardware.
The objective of this task is to develop a virtualization strategy. Procedure Especially for the SAP application
layer, virtualization is an interesting option to enhance agility and adaptability and to provide a
“cloud-like” behavior. For instance, virtual instances of additional application servers can be
created on the fly to overcome temporary load peaks, system images can be moved to a more powerful
hardware dynamically and so on. To fulfill this task, an overview about available virtualization products and
the respective capabilities is required. Boundary conditions, limitations, typical use cases and similar should
be collected to check if these are matching the requirements. In addition, tools like the SAP Landscape
Virtualization Management (LVM) should be evaluated. Results As a result, a general technical architecture
of the new systems in virtualized environments has to be created/adapted. In addition, general
technical configuration rules for the SAP S/4 HANA have to be considered.
A network design for the new system has to be created Procedure The network design needs
to include data center inter connectivity as well as network zones. For instance, isolation of different
network zones from a performance perspective is crucial to rely on system replication for high availability.
The picture below shows some examples of requirements and network segments. Figure: Bandwidth
requirements per network type (example only) Sizing rules for LAN and WAN segments have to be applied.
In case of limited bandwidth or high latency, WAN acceleration solutions have to be considered. Results As
a result there is a network design document stored in SAP Solution Manager.
After the clarification of the target technical architecture including hardware and virtualization platform,
meaningful test cases have to be created. Prerequisites The target technical architecture has been designed
and documented. Procedure Prepare test cases for: Landscape flexibility and workload management
Technical configuration verification HA / DR Backup and restore Results As a result, as test plan including
a timeline and test case description has been created.
This activity creates a technical design document. Requirements and Constraints This task is recommended
for all implementation scenarios. The technical architecture, and the IT infrastructure has been designed
and documented. Procedure The technical design is documented in a technical solution design document.
It is usually developed in a series of workshops and post-processing work, and covers the following aspects:
Technical components Scalability and load balancing concept Backup concept HA/DR concept
Technical architecture for non-production systems Production system deployment plan
Expert sizing & scalability verification Technical architecture for production systems Technical
infrastructure Deployment patterns and deployment plans DC integration 3rd party integration
The aspects have dependencies to each other, and to the boundary conditions. Some of them need to be
considered iteratively. The Technical Architecture Workshop (see activity Technical
Architecture in the Discover phase ) should have touched many of the aspects from above).
The technical solution design is created in this activity, and continuously updated in later phases of the
project (e.g. Sizing Verification in the Realize phase). Results A technical solution design document is
available in SAP Solution Manager for central access.
The objective of this task is the creation of a technical solution blueprint. Procedure Take the appropriate
“Technical Solution Blueprint Template” from the accelerator section, and tailor it to your
project requirements. Define & document the following areas: Technical components:
Determination of required technical components for the SAP solution, and their deployment
options. Procedure Based on the technical applications specified in the Technical Solution Map,
document which installable technical components are required. Distinguish non-production and
production systems, as well as required and optional components. Timing: Explore phase (non-prod),
realize phase (prod). Scalability and load balancing concept: Determine how applications in the SAP
solution can grow from workload & data footprint perspective. Procedure Document how each
technical component can scale (scale up and/or scale out via multiple instances). Document data
scalability solutions (for large systems). Document how to balance workload between multiple instances
of the same technical component. Timing: Realize phase (since typically required for production).
Backup concept: Definition of the backup infrastructure and backup
execution strategy for each persistency type. Backup concept - Example The picture below
shows an example for a backup concept of DB data files, log, files, and configuration files. Figure: Backup
concept (example only) Procedure Clarify available backup methods per storage type. Determine
appropriate backup types (full, incremental, differential) for each component type. Determine
retention times. Design the technical architecture for the backups. Timing: Discovery phase (non-
prod), realize phase (prod). HA/DR concept: Definition of the technical architecture for high
availability (SPOF protection) and disaster recovery (data protection, recovery procedures). HA/DR Concept
- Example The picture below shows the exemplary HA / DR setup with two DCs. Figure: HA / DR concept for
a “Two Data Center Setup” (example only) Procedure For each “availability
class” in the SLA, determine the required technical architecture for each technical component.
Describe related IT infrastructure requirements. Describe assumptions & boundary conditions.
Timing: Realize phase. See also the Best Practice “Building High Availability for SAP NetWeaver and
SAP HANA on Linux” for more information (accelerator section). Technical architecture for non-
production systems : Determination of technical deployment and setup of non-production systems
(DEV, QAS; Typically simpler architecture than PRD). Procedure Determine the deployment type, e.g.
central system. Determine specific infrastructure requirements, e.g. HA test systems. Determine the
size, especially for the database. Timing: Explore phase. Production system deployment plan:
Determine the amount and, for global customers and complex solutions, regional distribution of systems.
Procedure Number of production systems (SIDs): Is more than one production system required (per
component)? Options to co-deploy applications: Can/should certain applications be co-deployed on
one platform? Timing: Realize phase. Sizing and Scalability Verification will be covered in the
Realize Phase. Technical architecture for production systems: Determination of technical
deployment and setup of production and production-like systems. Technical architecture - Example The
picture below shows one example of a production system setup. Figure: Technical architecture for a
productive system (example only) Procedure Determine the deployment types and required technical
With the introduction of a new solution like SAP S/4HANA, the current IT support framework will
change. The impact of the new solution on the support framework varies based on customers'
current support framework and on the way how customers plan to use the new solution. Example
scenarios include the following: On-premise solution IT is responsible for the entire solution
and needs to learn about the technical and functional specifications of the solution. Hosted
solution IT is responsible for monitoring application performance, troubleshooting, and all application
support activities. Cloud-based solution IT is responsible for security and user administration,
software logistics, development, and testing of solution changes. The IT team therefore requires the
necessary knowledge and skills to complete these tasks. If the solution is the first to be implemented in the
cloud, the current support operations need to be reviewed to include, for example, communication with
the provider of the cloud-based services. Third-party support When application support is
handled by a third party, knowledge about the solution must be transferred from the project team to the
third party. Business process owners, business relationship managers, and service desk agents within
customer’s organization still need to learn about the solution, and they should also consider
changes in the incident or change management support processes. Greenfield customers All the
topics mentioned in this activity are relevant for “Greenfield” customers. The effort to
prepare for the support of SAP S/4HANA will depend on many factors like the current support model, the
maturity of the organization, the future support strategy and deployment, like hosting hardware, cloud
deployment. SAP provides optional support to “Greenfield” customers to help them with
every aspect of the implementation of the future support framework. The extent of this optional support
varies according to the support framework currently in place for running and operating the legacy systems
that are replaced by SAP S/4HANA. The technical solution design document (see activity
Technical Design in the Explore phase) provides a list of technical components that needs to be
operated after the project go-live. Many other tasks mentioned in this road map are an important source of
information on how and what needs to be supported by IT once the new solution is live. This includes the
Technical Architecture, the Delta Design and Configuration, Product Enhancements. The goal of this activity
is to review the list of potentially affected IT operational activities and to evaluate the exact changes
required in the current customer IT support framework based on the project scope. Requirements and
Constraints This activity is recommended for all scenarios. Procedure SAP provides information on the
recommended IT Support framework to safely and efficiently operate SAP S/4HANA after Go-Live. This
includes: Identifying the target IT support framework for the future customer operations where
the support processes, people and tools will ensure efficient operations of the migrated and converted
solution. Recommending Best Practices for the support tools in the areas of monitoring,
troubleshooting and software logistics Defining the changes to the current support framework
required to support the future solution, and their respective severity/priority Adding Activities to
the project plan to implement those changes Additional SAP IT operational support in the Realize
Phase of the project to help ramp-up support resources and improve their knowledge transfer, to prototype
or implement required tools, and to further adapt process and procedures. Executing technical
The objective of this task is to evaluate the impact on IT operations when implementing SAP S/4HANA.
Procedure During the Operations Impact Evaluation activity, the SAP S/4HANA project scope is analyzed to
evaluate potential operational risks and areas in the support framework that need to be looked at and
modified/implemented prior to the go-live. The aim is to define the list of operational activities which:
Need to be newly set up. For example, in case SAP Fiori Apps are newly introduced, the administration and
operation of the Frontend Server needs to be defined and set up, and resources need to be trained on the
systems involved and their configuration. In addition, support processes like incident management need to
be able to handle the new component. Are existing, but have to be modified. For example, daily backup
routines need to be adjusted to properly fit the new SAP S/4HANA solution. Support tools like monitoring,
troubleshooting or software logistics tools need to be in place. Processes like Master Data management
need to be revisited to define new policies required by the major changes in the Master Data structure.
Can be retired. For example, DB routines and scripts for AnyDB can be retired. AnyDB monitoring set up
should be retired as well. All the relevant support areas need to be analyzed in a comprehensive manner
that is analyzing all the roles and skills required for the support of the SAP S/4HANA solution, the
processes/procedures, the operations documentation and the enabling support tools. SAP can support you
in all these activities with a systematic approach to operational activities will ensure you
analyze all the changes in IT operational activities caused by the new solution. Once the affected support
areas are analyzed in a systematic way, a road map is defined that includes the key activities for IT to fill the
gaps and prepare the future IT support framework. The key activities required are many and include:
Defining the sourcing strategy for a new role: project resource moving to operations, ramp up of a current
resource to support the new solution, hiring or handover of activity to partner Setng up and
configuring tools and where SAP will be engaged to support Documenting operating procedures by
project resources or by operational resources Organizing for knowledge transfer to ensure the future
operational resources have the required knowledge and skills – this includes formal education of
current operational resources, training, hands on and shadowing on new solution. It includes as well
training of all the IT support resources involved in the support of the new solution like the service desk
Operations cut-over activities (e.g. team access, roll over of open defects…) Retirement of some
part of the current support framework An SAP engagement model should be created to support
you where your knowledge is minimum or where your resources are busy on operational topics. The
possible services include for example: SAP Solution Manager prototyping or implementation services
EGIs on how to use SAP Solution Manager SAP trainings … Based on the road map, you will
then be able to define the detailed activities to be added to the project plan and align it with the SAP
Engagement Model specific to your needs together with the SAP TQM. Results There is a plan
documented and stored in SAP Solution Manager how to adjust IT operations to be ready to safely and
efficiently operate SAP S/4HANA as of Go-Live. How SAP Can Support See Operations Impact Evaluation in
the activity description.
work defined in the project scope statement. Management plans developed during the project prepare
phase guide the approach to management, execution, and control of project activities. The project
manager is responsible for ensuring that the management plans are applied at the appropriate level of
control.
The purpose of this task is to update the project management plan and the subsidiary plans based on the
changes agreed during the projects change management process.
The purpose of this task is to assure that the project is executed according to what was agreed to in project
charter, scope statement and project management plan.
The purpose of this task is to plan, setup and conduct various SCRUM meetings in order to keep the project
teams aligned around common vision, share information amongst the SCRUM teams and align individuals
within each team. The purpose of these standard meetings is to inform others about work that individual
team members do on given day and surface any blockers that team members need help addressing . In
Agile implementation project the teams conduct following meetings: 1. Daily SCRUM meeting short
(about 15 minutes) session within each SCRUM team facing the SCRUM board team members report to the
team about what they work on and whether they are encountering any issues that they need help with.
Objective of this session is to inform and align the team work. 2. Regular SCRUM of SCRUMs meeting
session in which SCRUM Masters from individual SCRUM teams share information about what each SCRUM
team works on, surface any cross team alignment topics and resolve any issues that arise between the
teams. The session is very similar to integration team meetings conducted in traditional projects. Note:
Cadence of these sessions needs to be calibrated, but they should be done on at least bi-weekly basis. The
more often they are done the shorter they can be. 3. Sprint Demo the purpose of this meeting is to
demonstrate the results of the sprint to customer and obtain acceptance to release the features developed
during the sprint. The meeting is attended by Product Owner team, End users and SCRUM team. It is
conducted at the end of sprint. 4. Sprint Retrospective or process improvement meeting is conducted right
after Sprint Demo meeting prior to closing the sprint. The objective of this meeting is for the SCRUM team
to conduct retrospective of the sprint, identify potential improvements of the process, prioritize and select
top improvements to implement in the next sprint.
The purpose of this activity is to capture and manage project issues and risks and changes related to those
e.g. changes of project scope, timeline, costs etc.
The purpose of this task is to ensure that each contract is closed by verifying that all work specified in the
contractual arrangement was completed, and that all defined deliverables were accepted.
The purpose of this deliverable is to refine the Initial Release Plan that was defined earlier. At this time the
team also defined sprint plan for the first few iterations. SAP provides customers with a SAP Solution
Manager tool set that supports customers in implementation of the project standards for the purposes of
the project or operations. It is highly recommended to use the SAP Solution Manager Focused Build service
solution. Additional details can be found in the SAP Solution Manager Focused Build accelerator. The
Focused Build material currently relates to SAP Solution Manager 7.1 functionality and the above training
materials will be updated for SAP Solution Manager 7.2. In this update step there will be
opportunity to create greater alignment with existing WBS. Project Managers may also want to consider
more significant updates to the WBS to align with the project approach of the Focused Build approach.
The purpose of this task is to update the backlog with delta requirements / gaps and to prioritize the
backlog items by business importance. The SAP Activate Methodology recommends to use the MSCW
prioritization framework (e.g. the Must-Have, Should-Have, Could-Have, Would-Have) for an initial grouping
of the backlog requirements. The business process owner is responsible for determining the relative
priority of each requirement. Once the requirements are assigned to the appropriate group, the business
owner needs to determine a sequence of requirements in each of those groups. This will help project team
to understand the relative priority of items in each group and this will facilitate selection of the high priority
items during the sprint planning in Realize phase. During prioritization the following dimensions need to be
considered: Dependencies and Integration    The project team will help business owner
assess the impact of the requirement on other requirements (technical risk, dependencies, integration
points); Scale The desirability of the feature to a broad base of users (business impact, acceptance);
Importance    The desirability of the requirement to a small number of important users or
customers (influencing key stakeholders, business value). How to establish clear priorities: In agile projects
the Process Owner must prioritize and force rank list of all requirements in project backlog. No two items
can end up being ‘equal’ on the list (e.g. have the same priority and ranking). Main reason
for this is to prevent that everything is rated as a “Must Have”. The MSCW prioritization
(Must-Have, Should-Have, Could-Have, Would-Have) is used for an initial grouping of requirements.
Secondary step is to rank items within the same priority group.
The objective of this task is to estimate effort for the backlog items. This activity is done by the project
team that has the expertise to estimate the effort required to complete the backlog items (requirements)
from the backlog.   For the project team it is critical to understand when we consider the
backlog item done. Definition of done must be clearly understood by everybody involved in the project.
See examples below for recommended definitions. The project team needs to ensure that the estimates in
the backlog include all activities required for completion of the item in the sprint and for completion of the
item in the release. Project team should follow these guidelines during the estimation
process:   Estimates are done by the experts in the team who are implementing the
functionality and have experience from similar projects More expert opinions lead to better the
estimation results   Everybody on the team participates in the estimation
process   Verbal communication is preferred over detailed written specs   It is
possible to use Planning Poker especially for estimates where experts disagree widely (see next
slide)   Clear the assumptions of estimates prior to estimating - e.g. what is the definition
of done for sprint and for the release   Avoid anchoring, it invalidates estimates –
e.g. “I would say this is easy so it should be X ideal person days”   Estimate
in the same unit of measure for the entire project (e.g. Ideal Person Days / Story Points)   If
consensus cannot be reached defer the estimate of requirement to later time.
The objective of this task is to prepare release and sprint plan that will guide the project team in building
the requirements in the backlog into a fully functional and integrated solution that supports
customer’s business. The starting point for the release and sprint planning is the prioritized and
estimated backlog (activities covered in the previous tasks). The image below shows an example of the
iterative agile approach to build functionality for one release. Release represents functionality that is
deployed to production system and rolled out to the end users. Each release is built in sequence of time-
boxed sprints in which the project team develops the highest priority capabilities as determined by the
business owners. One or multiple sprints may be needed to finalize functionality for end-to-end scenario
(or Epic as it is known in agile projects) During each sprint the project team conducts following activities:
Sprint Planning Meeting Sprint Execution Activities Daily Stand-up Meeting Sprint Demo Sprint
Retrospective During the project the team will run two types of sprints: Build sprints - the goal of these
sprints is to build and unit test the new capabilities Firm-up sprints - the goal of these sprints is to
conduct testing of strings of process steps to continuously ensure integration. During this sprint the team
also develops solution documentation
The purpose of this task is to review the release and sprint plans against the statement of work(SoW). The
objective of this task is to identify any new features that have been surfaced during the baseline build that
may not be part of the original scope and may require amendment of the SoW or Change Request. It is
important to ensure that the project manager validates that the requirements and user stories in the
backlog document are in alignment with the scope of the project as it is reflected in the SoW and other
contractual documents. The Project Manager (PM) should also ensure the alignment of the release and
sprint plan with the high level plan covered in the SoW. In case any discrepancies are discovered the PM
needs to take appropriate corrective action, like raising a change request according to the integrated
change request management plan defined in the Prepare phase.
The purpose of the Change impact analysis deliverable is to ensure that the organizational and technical
changes in business processes have been identified and documented by comparing the as-is and the to-be
business processes.
The purpose of this task is to validate the chosen approach with key stakeholders for the continued project
execution.
The purpose of this task is to define the baseline for where organizational change management starts and
against which progress and success of the OCM-activities are measured.
The purpose of the phase closure and sign-off deliverable is to: Ensure that all required deliverables from
quick access and insights into key deliverables from earlier stages of the project .
The purpose of the Quality Gate is to ensure that both compliance and project management standards are
being upheld within projects. A Quality Gate is a checklist milestone at the end of a project phase. Prior to
moving into the next phase each project manager demonstrates that they have been compliant with the
mandatory deliverables associated with a methodology while ensuring best practice standards have been
applied to ensure quality. A Quality Gate looks at the following topics in detail: Conduct regular quality
checks at defined or critical stages of the project lifecycle to assess the health of the project. Ensure
that all key deliverables and actions of the gate have been completed in compliance with recommended
practices and to the customer’s satisfaction. Enable project management to continuously
communicate the process and build quality directly into the project. Provide a tool to effectively manage
project expectations and monitor customer satisfaction. The deliverables assessed at each quality gate will
be performed using the quality gate checklist with defined expectations to the maturity of particular
project deliverables. Note: New additional key deliverables need to be added in the quality gate checklist
The purpose of this task is to conduct retrospective meeting with the SCRUM team to identify potential
improvements of the SCRUM process. The objective of this task is to serve as continuous improvement
mechanism for the team to adjust to changing project environment and needs. The team will select one or
two key improvements to implement in the next iteration and handles them as user stories that are added
to the product backlog, prioritized and tracked along with other user stories.
Once Quality Gate 2 (i.e. Q2) – Explore-to-Realize has been passed successfully, the functional and
technical implementation takes place in the Realize Phase. The activities of the Realize phase are displayed
in the following picture. Figure: Activities in the Realize phase In the Application: Solution Adoption
work stream, the training for the end users is prepared. In the Application: Design &
Configuration work stream, the functional changes (general configuration, master data, and core /
delta) are implemented as defined in the delta design document. Program enhancement like reports, or
Fiori User Interfaces, are developed accordingly. SAP can safeguard the activities via the “Integration
Validation” offering, which covers key aspects like Business Data Consistency, Exception
Management, Integration, and Performance and Scalability. Data aging is configured for business objects
according to the DVM strategy. Additional applications, like Central Finance in a landscape transformation
scenario, or the SAP Digital Boardroom, are set up as planned. In this step the S/4HANA specific security
strategy which was planned and defined in the previous project phase “Security Design” is
implemented. In the Custom Code Extensions work stream, impacted custom code is
adjusted and tested as well. Application changes are thoroughly tested in the Application: Testing
work stream. In the Application: Integration work stream, all required interfaces are implemented as
designed in the Explore phase. Further integration setup is done for the quality assurance system, and for
the production system (if already available, and new implementation only). In the System &
Data Migration work stream, the transition of the quality assurance system takes place according to
the detailed transition plan. Technical adjustments may be implemented as part of the activity. Load and
verification runs ensure business data can be migrated with acceptable time and quality. At the end of the
Realize phase, the preparation for cutover starts, which for instance includes the setup of the new
productive system in case of a new installation. The technical infrastructure is set up in the Technical
Architecture and Infrastructure work stream, according to the technical design document. In
parallel, the sizing of the productive instance is verified. According to the Operations Impact Evaluation, the
operations implementation (people, processes tools) takes place in the Transition to
Operations work stream. Please note : The order activities are explained in this document / road
map viewer, is not necessarily the order how they are later executed in the project! However, there can be
dependencies between activities. In case you are interested in time dependencies / relationships between
activities, look into the project file template of this road map.
The purpose of this deliverable is to formally recognize that a new project phase starts.
The purpose of this task is to review all Deliverables of the Realize Phase with the customer.
The purpose of this task is to review the acceptance criteria with the customer.
The purpose of this task is to review the R.A.C.I Chart for the Explore Phase with the Customer. It is
important to clarify roles and responsibilities in completing tasks and deliverables during this phase
The purpose of this activity is to define plans for Sprints, Solution Reviews and prepare all business-
process-related tests according to customer- specific configurations.
The purpose of this task is to plan Sprints and prepare to evaluate the proposed solution.
The purpose of this task is to plan the test sessions from a Project Management point of view. Procedures:
Review Test entry and exit criteria with customer Schedule Test Sessions and Plan Resources
In this activity the training material for end user will be created. Requirements and Constraints This activity
is required for all scenarios. The following preconditions are required before end user training material
creation can start: End user training material, a training environment, logistics, and infrastructure is
available. Skilled instructors are available based on the framework defined in the training strategy
document from activity. Procedure Train your Key User Create Training Material for End User Results At
the end of this activity, the training for the end user is ready to be delivered (including systems, demo data
etc.).
The goal of this task is to create the required training material according to the training concept (see
activity Learning Design in the Explore phase). Procedure Based on the training concept the
usage of a recording and authoring tool for creating the end user training material needs to be discussed
and decided. SAP recommends the SAP Enable Now (successor of the SAP Workforce Performance Builder
(WPB)) as the tool for creating the training material, supporting translations, developing e-learning with
or/and without audio voice description. The SAP Enable Now can be used for SAP and Non-SAP
applications and is therefore suitable for a seamless recording and documentation process for the end user
in one tool. The final documents can be exported in standard formats as PDF, MS Word, and PowerPoint.
Furthermore SAP Enable Now can also support the test phase with documentation of test cases and
results. You can find all important documents on SAP Enable Now in the SAP Online Help Portal (e.g.
“What’s New in SAP Enable Now”, “Master Guide”, or “Creating
Documents for HP Quality Center”) – see accelerator section. SAP is following the approach
to enable the customer key users to develop the end user training material mainly themselves. SAP can
coach the key users in developing the right structure and in reviewing the documents. The goal is to
transfer the knowledge as much as possible to the key users to enable them for the end user training. As a
prerequisite the key users should already be trained didactically, methodically, and for using the tool
appropriately during the Explore phase and the key user training work package. The following list describes
possible end user training documents required to be developed for every training: Course Concept For
each training event (classroom training), a course concept is created together with the customer. The
course concept defines the required content to be communicated. The course concept is converted it into
an appropriate structure and recorded in a template for training delivery. Training Manual The training
manual contains instructions, notes, and references to important points during the training. They explain
the processes, and provide the trainer with the structure, times, and procedures for the courses (up to
max. one page per content day). Conceptual Design Slides Conceptual design slides are created for the
training events as a visual aid, and a guideline during training. They provide not only a general overview of
the course but also the main procedures as well as role-specific and process-specific information. The slides
have a modular structure and are discussed during training (up to max. five concept slides per content day).
Work Instructions for Transaction Steps The work instructions contain not only step-by-step
explanations for the relevant transactions, but also screenshots from the customers SAP system as well as
explanations of screens and input fields. Exercises, Including Data Exercises are an integral part of each
training measure. Active processing phases within a training event help participants to understand and
learn about sub-processes and functions relating to their new system. The exercises are carried out in a
customer SAP system during the training event to ensure that the training includes a large proportion of
practical applications. Up to four exercise scenarios are generally needed for each training day. Training
data needs to be available early, so that the key user can already try out during training material creation.
Simulations Simulations help to visualize operating steps in the SAP system. They enable end users to
practice in an environment that is separate from a genuine SAP system and thus allow them to acquire the
necessary
The goal ofexperience. Simulations
this task is to canuser
train the key onlyas
beplanned
created in
once
theaactivity
suitable authoring tool Design
Learning is available (e.g. SAP
in the
Explore phase. Procedure Train your key user as planned in the Explore phase. Training could happen e.g.
via class room training, or on the sandbox system. Please note: Key users should be trained in such a way
that they can support the creation of training material for end users, or the test of newly implemented
functionality. Results Key users are trained. How SAP Can Support SAP can support the training of key user
as part of an individual offer from SAP Education. See accelerator section for details.
The purpose of this task is to initiate sprint in a formal Sprint Planning Meeting.
The purpose of this task is to initiate sprint by selecting the set of user stories that will be implemented in
the sprint (scope of the sprint). During the sprint planning meeting the SCRUM team estimates the stories
and clarifies with product owner team any questions that may still remain open. The team commits to
deliver set of highest priority stories from the backlog. This meeting formally sets the scope for the sprint.
This meeting is conducted in the beginning of each sprint.
The purpose of this deliverable is to execute the work defined in the Realize Phase and manage the Sprints
and Testing according to previously defined plans. During test execution all issues must be logged and
documented in the system for traceability purpose.
The purpose of this task is to ensure consistent execution and monitoring of sprint activities.
The purpose of this task is to properly manage the Unit/Spring Test. During the test all issues must be
logged and documented in the system for traceability purpose.
The purpose of this task is to properly manage the integration test. During the test all issues must be
logged and documented in the system for traceability purpose.
The purpose of this task is to properly manage the security test. During the test all issues must be logged
and documented in the system for traceability purpose.
The purpose of this task is to properly manage the User Acceptance test (UAT). During the test all issues
must be logged and documented in the system for traceability purpose.
The purpose of this activity is to configure the mandatory setngs, according to the delta design defined
and agreed during the Explore phase (see activities Fit Gap / Delta Design / Backlog for details). The delta
design documents contain changes related to both the implementation of new functionality, and the
mandatory configuration adjustments. Procedure This road map describes the execution of configuration
work in an agile implementation model. However, customers who prefer the classic water fall
implementation model can follow the same approach, by assuming the number of sprints equals 1. The
purpose of the configuration activities is to use a series of iterations to incrementally build and test an
integrated business and system environment that is based on the business scenarios and process
requirements identified in the previous phase. Accordingly, configuration steps will be executed in different
iterations (sprints) starting from general setngs per Line of Business up to detailed configuration for each
area. For each cycle the following steps will apply (example for configuration in six business priorities is
shown in the picture below): Figure: Individual steps within each configuration cycle (sprint) Sprints
are time boxed two-week cycles. Each sprint will consider system configuration, documentation and unit
testing based on the delta backlog identified during explore phase. Sprint 1 considers the finalization of the
core configuration. For example, during design only one legal entity was activated – however,
according to the design in total 5 legal entities might be activated. For System Conversion scenarios,
mandatory changes must be finalized according to the prioritized backlog. All general setngs and
organizational structures need to be configured. Master data setngs are prepared, and core processes are
configured. Sprint 2 considers the realization of gaps maintained in the delta backlog. Further sprints may
follow based on customer requirements. In case of a newly implemented business process, configuration
data will be taken from Best Practices content from SAP Activate (if available, and if appropriate). In case of
a system conversion existing customizing will be taken over during technical conversion, but of course will
need to be adjusted per newly introduced or changed functionality. Document the configuration setngs
and changes, and collect related customizing transports. Mandatory configuration activities are well
documented in the SAP Reference Implementation Guide (SAP IMG in transaction SPRO). Unless stated
otherwise, the corresponding actions should be initiated from there. SAP Solution Manager
'Configuration Library' can hold links to the configuration tasks and documents to capture a
living record of setng changes made (including the reason for each decision). A configuration object can
also be linked to the relevant process structure. How SAP Can Support SAP supports this activity with the
“Configuration ” scope option as part of the Build Execution service. Please ask your SAP
contact (e.g. SAP Client Partner) for more information.
Purpose of this activity is a structured handover from the design team (in charge of the delta design
documents) to the configuration team. Procedure This activity is executed per Line of Business / end-to-
end solution and sprint. Run Handover Session
The objective of this task is to properly hand over all required material from the design team to the
configuration team. Prerequisite The solution design is properly documented and approved. Procedure Run
a hand-over workshop to pass all important design documents for a business priority / end-to-end solution
from the design team to the configuration team. Required documents are for instance: To-Be Design
Role Mapping to Security Important Customizing Master Data Specifications Organizational
Structure Specification Functional Specification per WRICEF Object Solution Manager usage
guideline (if appropriate) Configuration guideline How SAP Can Support SAP supports this task with the
“Configuration” scope option as part of the Build Execution service. Please ask your SAP
The purpose of this activity is to perform the necessary customizing in the Development system according
to the agreed business process scope. Procedure This activity is executed per Line of Business / end-to-end
solution and sprint. Perform Main Configuration
The objective of this task is to perform the main configuration of the Line of Business / end-to-end solution.
In case of an agile implementation, the first sprint usually focuses at the core configuration whereas
subsequent sprints provide the delta configuration. Prerequisite Design documents have been handed over
to the configuration team. Procedure The main configuration is structured into: Configuration of general
setngs and organizational structure As an example, for Core Finance, typical
entities are (besides others): Chart of Account VAT Numbers Company codes Controlling area
Configuration of master data As an example, for Core Finance, this covers
(besides others): Profit center Cost center Bank directory SAP Business Partner Core / Delta
configuration of the application Typical configuration items for Core Finance
are (besides others): Document types Localization setngs (e.g withholding tax) Correspondence
Document splitng Statistical key figures Payments (ingoing / outgoing) Clearing Dunning
Month end closure procedures (periodical processing) See the SAP Best Practice Explorer for configuration
items structured by Line of Business / end-to-end solution. Also, the Product Assistance section in the SAP
Online Help Portal describes application specific configuration in detail. Properly record configuration
changes in transport requests. How SAP Can Support SAP supports this task with the
The purpose of this activity is to unit test the newly configured functions in the Development system.
Procedure This activity is executed per Line of Business / end-to-end solution and sprint. Run Unit Test
The objective of this task is to properly unit test the newly implemented functions in the Development
system, and to properly log issues in the project issue list. Prerequisite Functionality has been implemented
and configured in the Development system. Procedure Run unit tests on the newly implemented
configuration and functionality in the Development system. Document test execution properly. Issues
should be corrected either directly (same day), or in case this is not possible logged in the project issue list.
See SAP Best Practice Explorer for test script examples. How SAP Can Support SAP supports this task with
the “Configuration” scope option as part of the Build Execution service. Please ask your SAP
The purpose of this activity is to test an initial solution integration within the business priorities / end-to-
end solutions in scope. This is not a fully loaded integration test (see activity Test Execution later in this
phase). Procedure This activity is executed per Line of Business / end-to-end solution and sprint. Run
String Test
The objective of this task is to run a first test on solution integration within the business priorities / end-to-
end solutions in scope. Prerequisite Unit tests have been completed. Procedure Run an initial test on
solution integration within the business priorities / end-to-end solutions in scope. Since the full integration
test is executed later in this phase, recommendation is to test only with manually created test data, and to
focus on SAP functionality only (no testing of customer specific WRICEF objects). Test execution and results
should be properly documented and stored in SAP Solution Manager. Issues should be corrected either
directly (same day), or in case this is not possible logged in the project issue list. See SAP Best Practice
Explorer for test script examples. How SAP Can Support SAP supports this task with the
The purpose of this activity is to have an early knowledge transfer from the configuration team. Procedure
This activity is executed per Line of Business / end-to-end solution and sprint. Run Solution Walk-
Through
The aim of this task is to present the new solution capability to the corresponding project team members
for early knowledge transfer. Prerequisite String tests have been completed. Procedure Proceed as follows:
Run a session per Line of Business / end-to-end solution, and present the new functionality from an
application perspective. Explain the required configuration from an IT perspective. Log issues in the
project issue list, which have been identified during solution walk-through. How SAP Can Support SAP
supports this task with the “Configuration” scope option as part of the Build Execution
service. Please ask your SAP contact (e.g. SAP Client Partner) for more information.
The purpose of this activity is to resolve issues identified during the unit and string test or solution walk-
through. Procedure This activity is executed per Line of Business / end-to-end solution and sprint. Resolve
Identified Issues
The aim of this task is to resolve and correct issues which have been identified during tests and solution
walk-through. Prerequisite Solution walk-through has been completed. Procedure Resolve issues which
have been identified in the unit / string test and solution walk-through, and which have been documented
in the project issue list. Properly record corrections in transport requests. How SAP Can Support SAP
supports this task with the “Configuration” scope option as part of the Build Execution
service. Please ask your SAP contact (e.g. SAP Client Partner) for more information.
The purpose of this activity is to document the configured setngs and upload the results in SAP Solution
Manager. Procedure This activity is executed per Line of Business / end-to-end solution and sprint.
Document Configured Setngs
The objective of this task is to properly document the configuration setngs. Prerequisite Bug fixing has
been completed. Procedure Extend the design documents, by properly documenting the configuration
setngs in SAP Solution Manager. Add further information on detailings and agreed changes How SAP Can
Support SAP supports this task with the “Configuration” scope option as part of the Build
Execution service. Please ask your SAP contact (e.g. SAP Client Partner) for more information.
With Central Finance, customers can transition to SAP S/4HANA Finance, on-premise edition without
disruption to their current system landscape, which can be made up of a combination of SAP systems of
different releases and accounting approaches and non-SAP systems. Central Finance allows customers to
create a common reporting structure. See accelerator section for more details. Requirements and
Constraints This activity is only relevant in case you would like to set up Central Finance (Landscape
Transformation Scenario).
The activity Product Enhancements covers the development of custom code to close the
gaps identified in the Fit / Gap activities in the Explore phase. It further covers the
adjustment of already existing custom code identified in the activity Custom Code Impact Analysis.
Procedure Adjust affected existing custom code Development of WRICEF objects Development
of user interfaces (e.g. FIORI) Custom Development How SAP Can Support Before developing new code
in SAP S/4HANA your developers should be aware of programming best practices coming with new SAP
NetWeaver releases. Look for instance at the SAP Blog “Best Practices for ABAP Development on
SAP Netweaver 7.5x” from the SAP RIG team. However, SAP recommends to explore the options for
the agile creation of customer innovations using the extensibility capabilites of SAP S/4HANA and SAP
Cloud Platform. This is of particular interest for : SAP Fiori and the mobile journey in the SAP Cloud
Platform (decoupling custom user interface development from the stable SAP S/4HANA core, when
developing mobile apps for B2B, B2C, C2B) Agile data mart: Running SAP BI and Predictive Self-Services
in an SAP Cloud Platform sidecar The usage of the SAP Cloud Platform has two additional benefits: You
can run innovations in parallel to the S/4HANA conversion project You can consume innovations without
upgrading the stable SAP S/4HANA core (e.g. LoB Finance innovations delivered via SAP Cloud Platform
applications). You will find helpful information resources at SAP SCN (see “Extensibility
of SAP S/4HANA – Helpful Links” in the accelerator section). Look up also training courses on
SAP Cloud Platform at openSAP. See the accelerator section for more information.
The goal of this task is to adjust custom code, and make it ready for SAP S/4HANA. Requirements and
Constraints This activity is relevant in case own code needs to be made ready for SAP S/4HANA (e.g. the
system conversion case). In case of a new implementation, or a landscape transformation, some custom
code from an old SAP ERP system might be in scope to be used in the new SAP S/4HANA system. The
custom code work list of affected objects has been created (see activity Custom Code Impact
Analysis). The development system has been converted to SAP S/4HANA. Procedure To adjust custom code
that is affected by the conversion to SAP S/4HANA project, proceed as follows: Make sure your
developers have the required skill set to adjust your custom code for SAP S/4HANA. There are multiple
options for developer training (e-learnings, classroom). Please see accelerator section for more
information. Make sure you have the prioritized list of custom objects requiring adjustment (see
activity Custom Code Impact Analysis for details). Wait until your DEV system has been
converted to SAP S/4HANA. Adjust custom code objects in the converted DEV system according to the
prioritized custom object list. Log all changes in transport requests. Transport your changes to QAS, once
it has been converted to SAP S/4HANA. Test your changes in QAS. In case corrections are required, perform
the corrections in DEV and transport to QAS again. All transport requests should then be populated in
the PRD buffer, ready for import during the Go-Live. Please note: In case of a system conversion, the
old DEV system will stay for production support of PRD as long as PRD is not converted. Take care to
properly retrofit changes performed in the production support landscape to the new DEV
system to ensure the latest business requirements are accounted for within the project landscape. Results
All custom code is adjusted to function properly with SAP S/4HANA. How SAP Can Support SAP has several
offerings to support this task: In case your development is in charge to adjust the affected custom code,
SAP offers a “Custom Code Remediation Support” service component (part of the
“Custom Code Management” service). This service component helps to organize and
empower the customer development team. It further helps to evaluate the impact of changes on custom
code development process. With the results of the “Custom Code Impact Analysis” from the
Explore phase, the adjustments on custom code will be discussed and integrated into the development
process to reduce the time to get your development team to the same efficiency level as before. The
transition to SAP S/4HANA includes new data models and new processes for quality management where
your development team has to get familiar with. In case you would like to involve SAP with the
identification and the adjustment of your custom code, SAP offers the “Custom Code Management
Execution Support” scope option (part of the “Build Execution” service). SAP also
offers to check the security of your custom code (service Custom Code Quality Management ). Please see
task Improve Custom Code Quality Measures from the Explore phase for more details.
The purpose of this task is to provide coded enhancements within the defined project scope and specified
from a functional perspective during the Explore phase. WRICEF is defined as follows: W = workflow R
= reports I = interfaces C = conversions E = enhancements F = forms Procedure
Development of WRICEF objects is following the procedure: Step 1: Technical Design Based on the
functional requirements described in the delta design document, the purpose of this task is to specify the
WRICEF object from a technical perspective. A detailed technical specification will be provided. This
comprises in case of ABAP developments development details like entry point in the system, enhancement
logic, process flow diagram, data model and required authorizations. WRICEF objects are new objects or
objects to be adjusted, identified during the explore phase, e.g. a requirement for a new workflow or form
identified. All information will be documented in a technical specification document (see
Accelerator’s section for details). For each enhancement, the appropriate test case(s) will be
defined and documented. The final documents will be stored in SAP Solution Manager for shared access.
Step 2: Development of WRICEF objects The developer is in charge to realize the requirement, which
includes the development itself but for sure also documentation and unit testing. Step 3: Unit testing for all
developed objects The purpose of this task is to perform a unit test of the developments. The objective is
to resolve any issues identified during the WRICEF object(s) test. It is crucial that the issues are solved, and
re-tested by users that reported them (or designated re-testers) and that they are confirmed. Additionally,
during this task, a final code review of the development objects will be performed and readiness for
transport into QAS has to be confirmed. How SAP Can Support SAP supports this activity with the “
WRICEF Developments ” service as part of SAP Professional Services. SAP also offers to check the
security of your custom code (service Custom Code Quality Management). Please see task Improve Custom
Code Quality Measures from the Explore phase for more details.
The purpose of this task is to provide UI enhancements within the defined project scope and specified from
a functional perspective during the Explore phase. Procedure Configuration and development of customer-
specific user interfaces, such as SAP Fiori UX or Screen Personas. Development of user interfaces follows in
general the procedure described in the task before: Technical Design Development Unit Test
Examples: Extend an existing SAP Fiori App Configuration, hide / add fields by use of
configuration framework, UI enhancements using backend configuration Enhancements through Fiori
extension points UI changes & backend extensions; change of "look & feel"
and backend functionality of a standard application Full screen modifications UI
enhancements using functional customizations Development of new Fiori Apps Create new FIORI
launch pads and catalogues How SAP Can Support SAP supports this activity with the “ Fiori
Enhancement Pack ” service or with SAP Custom Development. These services are not part of the
SAP Value Assurance, but are available as an SAP Professional Service offering. Look up the SAP Blog
“ SAP S/4HANA – How to Create and Generate Back-end Security Authorizations for SAP Fiori
2.0 ” which provides a step-by-step instruction on how to create and generate SAP Back-end
authorizations for a SAP S/4HANA system based on SAP Fiori 2.0 Front-end Server Catalog information. In
the accelerator section, you will also find an SAP Blog series from the SAP RIG team on how to deal with
user default values in the context of SAP Fiori apps, and how to troubleshoot SAP Fiori apps.
For development requirements exceeding a certain threshold (which is project specific) or considering
those as critical for the project, it is recommended to manage those as custom developments. Procedure
Custom development follows in general the same procedure as described in the task Development
of WRICEF objects : Technical Design Development Unit Test How SAP Can Support With
SAP’s Custom Application Development Services SAP is able to develop one-of-a-kind solutions that
help you thrive in the digital economy -- with SAP’s application development team. Conceptualize,
design, build, and maintain custom applications that run on any device – and in on premise, cloud,
or hybrid environments – with help from the SAP Application Services team. Speed mission-
critical app development with agile development methods and by reusing existing software Develop
on a variety of SAP platforms, including those from SAP companies Hybris, Ariba, and SuccessFactors
Be a leader in your industry with individualized solutions that support innovation and the continuous
transformation of your business See accelerator section for details.
The purpose of this deliverable is to formally close the sprint by conducting the Sprint Review Meeting with
key users, product owner group and key stakeholders; formally sign-off the results and conduct sprint
retrospective.
The purpose of this task is to demonstrate the results of the sprint to product owner team, key users and
key project stakeholders. The results of the demo is either acceptance of backlog item or in cases the
feature is not accepted the user story is amended by the product owner team, prioritized and remains in
the product backlog ready for next sprint planning meeting. The demo in sprint review meeting serves as
an input to formal sign-off for the sprint.
The purpose of this task is to obtain formal acceptance and signoff of the sprint results following the sprint
review meeting. The product owner team is the party that provides the sign-off to the project team. In case
some features are not accepted they are brought back into the product backlog as requirement, properly
prioritized and included in planning for next sprint.
Based on the residence time definition (i.e. when the business data can either be deleted from the
database or moved to an archive file) and the corresponding customizing setngs, the deletion and archive
jobs have to be scheduled partly massively parallel to achieve that the data is really removed from the
database before the conversion starts. This job scheduling can only partly be automated and requires
manual interaction and monitoring by a basis administrator. Requirements and Constraints This task is of
particular interest in case of a system conversion scenario. There is a documented strategy on DVM, which
besides (others) defines the residence time definition of business data. Procedure Cleanup or
Archive Data Results The SAP system has been cleaned from data which can be either removed, or
archived. The used space in the database has been reduced.
In this task you clean up or archive data in the SAP system. See the accelerator section for a procedure
description. Procedure Proceed as follows: Archive business data as defined in the DVM strategy.
Set up the write and delete jobs as described in the DVM Best Practice Guide (accelerator section).
Run housekeeping jobs e.g. on the SAP Spool environment as described in the DVM Best Practice
Guide (accelerator section). Results The SAP system has been cleaned from data which can be either
removed, or archived. The used space in the database has been reduced. How SAP Can Support SAP can
support this task with the “ Cleanup / Archive ” scope option, which is part of the “
Build Execution ” service. Please ask your SAP contact (e.g. SAP Client Partner) for
more information. SAP Enterprise Support customers can also listen to the Meet the Experts recording
“ System Clean-Up Prior to Migration to SAP S/4HANA ” that explains why system clean-up is
important before migrating to SAP S/4HANA.
Based on the analysis conducted in the Explore phase of the project (see activity Data Volume Design ),
Data Aging is configured in the Realize phase of the project. Requirements and Constraints This activity is
required for all scenarios. Prerequisites for Data Aging are as follows: The DVM strategy has been
adapted in agreement with the business, to include the Data Aging concept for those areas supported by
the solution. The system is already converted to SAP S/4HANA. You have switched on the Data Aging
(DAAG_DATA_AGING) business function. You have entered profile parameter abap/data_aging . You
are familiar with Data Aging procedure, and the limitations around Data Aging. The following list gives an
overview on available data aging objects. Aging Object
Availability Application Logs SAP NetWeaver 7.40 SPS 08
Intermediate Documents (IDocs) SAP NetWeaver 7.40 SPS 08
Change Documents SAP NetWeaver 7.40 SPS 12
Workflow SAP NetWeaver 7.40 SPS 12 FI
Documents SAP Simple Finance add-on 1.0 Unified Journal
Entry SAP S/4HANA Finance 1503 SPS 03 SAP S/4HANA – 1511 update
Material Documents SAP S/4HANA - 1511 update
Purchase Order SAP S/4HANA – 1610 Sales
Documents SAP S/4HANA – 1610 Deliveries
SAP S/4HANA – 1610 SD Invoices SAP S/4HANA –
1610 Procedure The configuration of Data Aging is divided into “design
time” and “runtime”. Configure Data Aging (Design Time) Test execution
of Data Aging (Runtime) Results Data Aging has been configured and tested successfully.
The setngs can be taken over into the productive system once transferred to SAP S/4HANA.
The goal of this task is to configure Data Aging as described in the SAP Help Portal. Procedure Configure
Data Aging as described in the SAP Help Portal (see accelerator section). Results Data Aging has been
configured for the business objects in scope. How SAP Can Support SAP can perform this task with the
“ Data Aging Configuration ” scope option, which is part of the “
Build Execution” service. The scope option provides knowledge transfer, and data
aging is configured and executed in a test or QA system. Based on this task the application team can agree
on residence times, (i.e. at which point in time can business data be aged). The outcome of the service
component is an agreed configuration ready to be transferred to production, and a skilled customer team.
Please ask your SAP contact (e.g. SAP Client Partner) for more information.
After you have defined how you want to partition the tables during design time, you can start to run and
test Data Aging as described in the SAP Help Portal. Prerequisites Configuration of Data Aging has finished.
Procedure Test Data Aging as described in the SAP Help Portal (see accelerator section). Results Data Aging
has been configured and tested successfully for the business objects in scope.
In the Security Implementation activity the customer specific results from the Security Design phase are
implemented. All required and planned security tasks are now initiated. Requirements and Constraints This
activity is recommended for all scenarios. Procedure Define the Security Activities Prepare the Project
Plan per Security Service Realize the Security Services Document the results of the Security Activities
(e.g. S/4HANA Authorization Concept) See “SAP Security Products” road map for details.
Results As the result of the Security Implementation Phase all the planned and defined Security Activities
are initiated and in realization. They will continue across the Deploy phase.
When implementing and running Solution Landscapes that drive mission-critical business processes, the
integration of solutions can be complex and challenging. The implementation work is typically distributed
across many teams and in most cases many stakeholders, including custom-built and third-party software.
Integration Validation helps to introduce solutions into a production environment smoothly, while
maintaining ongoing operations with minimal disruption. This offering from SAP combines tried-and-tested
processes and tools, such as the SAP Solution Manager Application Management solution, with a clear
governance model and holistic, one-issue tracking methodology (“single source of the
truth”). The organizational framework for each Integration Validation project is provided by the
Innovation Control Center (ICC), which is formed from the Customer Center of Expertise (CCOE) location. It
unites customer experts, partners, and SAP staff as one team in one room and works in principle like a
NASA control room. Every mission-critical application and technology component is represented as well as
every implementation and operation services provider. Besides others, IV addresses the following aspects:
Data consistency: All data integration is posted automatically, for example, from sales and
distribution and materials management to financials and controlling. In distributed solution landscapes, the
consistency of the data across software systems must be subject to checks and validations at any time. Data
passed via interfaces between software systems must be consistent. This requires transactional security of
the interface technology (end-to-end transactional consistency). All integration queues and interfaces have
to be monitored. Business process monitoring and exception management: There must be 100%
transparency of status and completion of business processes. The continuous flow of documents
throughout the business process must be monitored. This includes backlogs of business processes and
indicators for throughput, as well as alerts indicating business exceptions, for example, out-of-stock
situations. There must be 100% transparency of exceptions and backlogs. Performance and
scalability: Response time for defined critical transactions should be lower or equal to what was
specified in the business requirements. Batch runtime for defined critical batch jobs should be lower or
equal to what was specified in the business requirements. Batch processing for critical jobs that are part of
the core business process should fit in the given batch-processing window. Volume growth and resource
consumption must have a linear relationship. Adequate load balancing must be in place to support
throughput of performance-critical business processes. Requirements and Constraints This activity is
recommended for all scenarios. Procedure Identify the IV Scope Initiate the Corresponding IV Support
Activities Initiate SAP Going-Live Check Results As the result of this activity, integration validation
activities have been planned, documented and initiated. They will continue across the Deploy phase.
The goal of this task is to identify the scope of Integration Validation in the context of the transition project.
Procedure Validating the integration of a complex solution is a challenging and extensive task. To improve
the efficiency and effectiveness of the task, a collaborative approach should be employed. This makes
knowledge transfer an integral part of Integration Validation, enabling all parties involved – the
customer, the system integrator, and SAP experts – to work together to validate the solution. The
final cross-check is led by SAP, with support from the customer and system integrator. The check results
documented in SAP Solution Manager provide the basis for this cross-check. To determine jointly the scope
of Integration Validation and to develop a detailed plan of how to validate the solution, product and
operations standards, the following information is required: The critical core business processes,
including all relevant interfaces and the underlying software landscape Volumes of data to be processed
for the critical business process, including peak volume Performance KPIs (transactional, batch, and
batch window) In close cooperation with the customer and partner, SAP drives the validation of the
customer’s Solution Landscape based on the scope defined. Throughout the process of validation,
SAP provides knowledge transfer on an on-going basis and supports the customer and partner as they
validate all related core business process steps and interfaces. See accelerator section for more details. For
complex scenarios, Integration Validation can be very detailed, and possibly structured as a project on its
own. The concept needs to be tailored to the project scope. See the road map “ESRV Integration
Validation (V2.2)” in transaction RMMAIN in SAP Solution Manager for details. However, in the
context of an implementation project, Integration Validation is usually focusing on performance related
aspects of newly implemented core business functionality. Results The scope of Integration Validation in
the context of the transition project has been documented and stored in SAP Solution Manager.
Based on the IV scope which has been defined before, the goal of this task is to initiate the corresponding
support activities. Prerequisites The scope of IV has been defined. How SAP Can Support IV is usually
executed with SAP participating. The SAP TQM will initiate the right IV support activities from SAP:
Technical Feasibility Check service component (TFC): Assess the technical feasibility of the transition project
with focus on compatibility, business continuity, performance and consistency. Technical Integration
Check service component (TIC): The TIC is an assessment service and aims to verify that the built solution
supports the integration test with focus on consistency, performance and stability across systems.
Interfaces integration, Data Volume and Business Process Management are assessed. Integration
Validation service component: This service component provides technical validation of core
business processes with respect to non-functional requirements, identification and addressing of technical
risks prior to Go-Live and during the production cutover including hyper-care phase. A comprehensive
status of technical Go-Live readiness for core business processes (Integration Validation matrix) is part of
the service component. Business Process Technical Validation service component: This service
component ensures technical readiness of the core business process for Go-Live. It addresses areas like
data consistency, exception management, performance and scalability, system integration, batch and
volume processing. In the focus is the technical validation of the core business processes and preparation
for the subsequent efficient operation of the software solution. Technical Performance Optimization
service component: The technical performance optimization service component improves your SAP
solution by helping you to configure your SAP S/4HANA system in an optimal way. The identification and
elimination of costly performance bottlenecks optimizes the response times and throughput of your SAP
solution. All service components are part of the “ Safeguarding the Digital Transformation ”
service. See accelerator section for details. SAP Enterprise Support Customers can order the CQC for
TechnicalPerformance Optimization (TPO).
The SAP GoingLive Check safeguards your SAP solution to a smooth start of production, which is the final
milestone of a successful implementation project. The goal of this task is to request the right SAP GoingLive
Check. Prerequisites The SAP GoingLive Check is recommended for all scenarios. Procedure There are three
different SAP GoingLive Checks available: SAP OS/DB Migration Check This check is for system
conversion scenarios, where the start database is on any database except SAP HANA. SAP Enterprise
Support customers can use the Continuous Quality Check (CQC) OS/DB Migration Check instead.
SAP GoingLive Functional Upgrade Check This check is for system conversion scenarios, where the
start database is on SAP HANA. SAP Enterprise Support customers can use the Continuous Quality Check
(CQC) for Upgrade instead. SAP Going Live Check This check is suitable for new installations.
SAP Enterprise Support customers can use the Continuous Quality Check (CQC) for Implementation instead.
All services are delivered remotely. An analysis session should be performed 6 weeks in front of
the Go-Live date, to have sufficient time to fix identified issues. The verification session runs some weeks
after Go-Live, to check the system in its productive use. See accelerator section for detailed service
information. Schedule the appropriate service for the SAP system, and additionally for the SAP Gateway in
case it runs as a separate instance. Results You have successfully requested the correct SAP GoingLive
Check. How SAP Can Support In case the transition project is supported by a premium engagement, the
SAP TQM will order the correct check for you.
This activity implements and configures the analytics architecture as part of the transition project. SAP has
plans describe this activity in detail in future. Furthermore SAP has plans to support this activity with an
“Analytics Execution” service. Within this activity, this version of the road map describes the
implementation of the SAP Digital Boardroom. Requirements and Constraints The configuration of SAP
Analytics Cloud SAP Digital Boardroom is based on SAP Best Practices packages, and on results of
other service components like “Content Orchestration for SAP Digital Boardroom” in the
Explore phase. Procedure Configure Analytics & Digital Boardroom
The objective of this task is to configure analytics and the SAP Digital Boardroom. Procedure Configure
analytics functionality as designed in the Explore phase. In case of the SAP Digital Boardroom, SAP
recommends to implement this product together with SAP (see section How SAP Can Support ).
How SAP Can Support SAP offers two “Quick-start services” from SAP Professional Services:
Quick-start service for SAP Analytics Cloud: This service helps our customers to have a quick
implementation for using SAP Analytics Cloud. Quick-Start Service for SAP Digital Boardroom: This
service helps customers to have a fast start for using SAP Digital Boardroom based on SAP Analytics Cloud.
The “ Implementation of Analytics with SAP S/4HANA ” service is also from SAP Professional
Services. The service enables customers to get started with SAP S/4HANA embedded analytics, and
integrate with best in class analytical platform and solutions from SAP (like SAP BI platform, SAP HANA
Cloud Platform, SAP BW and SAP Analytics Cloud). The service component: Identifies any major
prerequisites Defines project phases to be used Validates and demonstrates the solution in a workshop
Provides an implementation example Provide knowledge transfer to key users for the SAP Best
Practice processes. In case customers are interested in setng up a digital boardroom, SAP recommends to
study the information on the SAP Digital Boardroom which is available in the Public Web as a first step. See
Accelerator’s section for details. In particular, and highly recommended, SAP has provided an
“Implementation Check List” for the SAP Digital Boardroom, which provides information on
the general concept, SAP Digital Boardroom content and the setup. SAP offers a “ Content
Orchestration for SAP Digital Boardroom ” service which is delivered by SAP Professional
Services. This service helps customers to identify and harmonize the KPIs and master data that are
relevant for a successful implementation of SAP Digital Boardroom. Customers can contact the Client
Partner for ordering details. Through it SAP provides recommendations to customers to: Run a real-time
analytics scenario during board meetings to understand company-wide business situations and make
decisions based on facts. Visualize the top KPIs, the details of the top KPIs, and the context of the top
KPIs in one view (deployed on three screens). Start collaboration and planning scenarios immediately
after the board meeting. Provide guidance for an analytics competence center and analytics governance.
Mandatory scope options for Content Orchestration of SAP Digital Boardroom, including foundational
activities like: Deliver scoping workshop to Identify Digital Boardroom scenarios, KPIs and Data
Sources. Conduct blueprint workshops to identify master data which will be used for digital boardroom
reporting. Define data architecture & master data harmonization approach and best practice
recommendations to build C4A data foundation. Deliver Customer specific reference architecture based
on the SAP Analytics Cloud Reference Architecture. Create Digital Boardroom implementation road
map & Project Plan. Deliver Final Presentation and Sign-off. To achieve this goal, SAP holds
workshops to: Derive and define KPIs that will be visualized with SAP Analytics Cloud and SAP Digital
Boardroom. Identify master data that will be used for reporting with SAP Digital Boardroom and prepare
a recommendation where harmonization is needed. On-site workshops to get an overview of existing
system landscape and the as-is architecture. Remote activities to create the deliverables. As a result of
the
The workshops,
objective ofcustomers
this task iswill receive:
to train Business
business blueprint
analysts and endfor all KPIs
users thatSAP
on the should be visualized
Analytics forSAP
Cloud and SAP
Digital Boardroom. Prerequisites The SAP Digital Boardroom has been set up and configured. Procedure
The SAP Digital Boardroom is a new product. SAP recommends to implement this product together with
SAP (see section How SAP Can Support ). How SAP Can Support SAP offers the “ Enablement
service for SAP Analytics Cloud and & SAP Digital Boardroom ” service from the SAP
Professional Services organization. The intent of this service is to: Support project team members with
the required knowledge of SAP Analytics Cloud and SAP Digital Boardroom. Familiarize key users with
SAP Analytics Cloud and SAP Digital Boardroom functionalities. In sum this service component is a
five day engagement. 3 days thereof are being used to work with the customer onsite on their SAP
Analytics Cloud System. The remaining 2 days are being delivered remotely to answer questions from
customers related to the training exercises. The onsite part is structured into: A hands-on training session
for data loading and connecting to one SAP HANA database. A hands-on training session to create
models, visualizations, and stories for SAP Analytics Cloud. A hands-on training session to create agendas
for SAP Digital Boardroom.
The purpose of this activity is to prepare all business-process-related tests according to customer- specific
configurations. Requirements and Constraints This activity is required for all scenarios. Procedure
Prepare Tests How SAP Can Support SAP supports this activity with the “ Test Preparation
” scope option as part of the Build Execution service. This scope
option component assists the preparation and planning of the Integration and User Acceptance tests
for all business areas based on the customer specific configurations. The test framework, defined in the test
planning service during Build Design phase, determines the scope for this service component. Please ask
your SAP contact (e.g. SAP Client Partner) for more information.
As determined in the evaluation of the existing test materials and documented within the testing plan,
additional assets may need to be developed to support the execution of the testing cycles. Develop the
missing test materials and test scripts in accordance with the detailed test plan. Procedure Within in each
implemented solution scope, the following steps need to be executed: Extend best-practice test cases
Develop delta process test cases Finalize integration and user-acceptance test cases and plan
Prepare approval procedure Prepare tool adaption and delta user acceptance test training The best-
practice test scripts are part of the solution scope description, and can be found in SAP Best Practices
Explorer. See a screen shot for an example. Please note that test scripts – together with a process
flow diagram – are provided per scope item. See accelerator section for the link to the screen above.
In this activity, integration test, regression test and user acceptance test takes place. Requirements and
Constraints This activity is required for all scenarios. The unit test has been done as part of the
development process in the DEV system already. Procedure Prepare a test environment with the required
test data as defined in the activity Test Planning . Once the tests have been planned and test data is
available on the test systems, testing can begin. The typical basic process for the Realize phase is as follows:
Software developers perform unit tests in the DEV systems. Depending on the type and scope of the
test cycle, various functional tests are performed. Manual testers are provided with the tester handout
document and receive details regarding their test package by e-mail. Automated tests are scheduled
or started directly. Every test that is executed is logged and documented with test notes and a test
status is set manually or automatically. If the system responds in an unexpected way during manual
testing, for example, if an error message appears, the tester records the incident in the corresponding ITSM
system, attaching screenshots, log messages, and so on. Usually, this also has to be done manually even for
automated tests. The incident is sent to the persons responsible for the analysis and categorization of
defects, who then correct the defect in the development system. The correction is transported to the
test system according to the existing arrangements and timelines, where it is then retested. Given the
complexity and heterogeneity of modern software solutions, SAP recommends performing the activity
Integration Validation , especially for important business processes. This involves gathering and
subsequently evaluating a substantial amount of data from the software applications that are active while a
given business process is being executed. This type of validation also allows you to identify the hidden
warnings and error messages that frequently occur at the interfaces between applications. Furthermore,
the operations team should monitor the testing system as if it were production in order to gain early
visibility and hands-on experience to possible production issues. If large-scale changes are made or new
software solutions are implemented, load tests should be performed before these are used in production.
These tests simulate a situation in which the expected load (known number of users and background load
in a load-peak situation) is simulated. While doing so, system behavior in handling large data volumes can
be inspected. Throughout the entire test cycle, test coordinators monitor the test status and progress, as
well as the processing status of incidents that have been reported. The quality of the test data and test
scripts directly affect the stability of the productive system following the Go-Live of the change event.
Consider an array of representative variances when preparing for the execution of the regression test cycle.
It is important to execute realistic data sets that representative production operations of critical business
process. How SAP Can Support SAP supports this activity with the “Test Execution” scope
option as part of the Build Execution service. Various functional and business process tests are necessary to
get the new system in a solid condition. This scope option helps to manage the execution, tracking and
documentation of the different tests. Please ask your SAP contact (e.g. SAP Client Partner) for more
information.
The goal of this task is to perform integration test, regression test and user acceptance test. Procedure
Integration Testing is performed to verify proper execution of the entire application including interfaces to
external applications. This ensures that the integrated components are functioning properly according to
the requirements and specifications. The objective is to perform the end-to-end process integration
between all SAP and non-SAP components of the Solution Landscape to validate that all application
systems are functioning properly. Integration testing in combination with Regression Testing ensures that all
business scenarios have been tested prior to the User Acceptance Testing. How to proceed for Integration
Test: Prepare Integration Test plan: Define and document integration test cases, end-to-end customer
business process scenarios, according to the test plan. Test plans and test case documentation is stored in
Solution Manager. Prepare and document Integration Test Case #1 – n: The purpose of this task
is to document the integration test cases outlined in the integration test plan. This activity contains also
aligned setup of relevant test data that will be commonly used. Execute Integration Test Case #1 –
n: Perform the Integration test according to previously defined plan. During test execution all issues must
be logged and documented in the system for traceability purpose. Perform defect resolution for
Integration Test: Resolve any issues identified during the Integration Test. It is crucial that the issues are re-
tested by the users that reported them (or designated re-testers) and that they are confirmed. Obtain
Integration Test Sign Off: Obtain customer approval (sign-off) of the integration test.
The transition to the new system may impact productive business processes following even a
successful cutover. In order to mitigate the risks and issues to those business processes, it is necessary to
regression test them as a part of the project or Release. How to proceed for Regression Test: Prepare a
detailed regression test plan with test cases and test scripts. Set up test management procedures to
track the progress of the test execution. Set up defect tracking to ensure all identified issues are addressed.
Execute the regression test scripts based on the test plan and test cases. Document any anomalies or
defects. Monitor the test system as if it were production, as this will provide an indication of end-state
operations. For example, errors in the system log, which may not be noticed by testers, could cause
instability in the production system. Therefore it is important to leverage the regression testing cycle to
proactively address such issues. Resolve any defects, and retest to ensure all identified issues are
closed. How to proceed for User Acceptance (UA) Test: Prepare User Acceptance Test plan:
Update the existing integration test cases, end-to-end customer business process scenarios, based on the
learnings from previous test phase. UA test plans and test case documentation is stored in Solution
Manager. Prepare and document User Acceptance Test Case #1 – n: The purpose of this task is
to document the UA test case outlined in the UA test plan. This activity contains also aligned setup of
relevant test data that will be commonly used. Execute User Acceptance Test Case #1 – n:
Perform the test according to previously defined plan. During the test all issues must be logged and
documented in the system for traceability purpose. Perform defect resolution for User Acceptance Test:
Resolve any issues identified during testing. It is crucial that the issues are re-tested by the users that
reported them (or designated re-testers) and that they are confirmed. Obtain User Acceptance Test Sign
Off: Obtain customer approval (sign-off) of the User Acceptance test.
In the activity integration implementation, the customer specific integration design from the Explore phase
is implemented. Requirements and Constraints This activity is recommended for all scenarios. Procedure
This activity should be executed in close cooperation with the Configuration and
Product Enhancement activities of the Application: Design & Configuration work
stream. The activity is structured into two tasks: Implement the integration design Validate integration
implementation Results As the result of the integration implementation the integration design has been
fully implemented and validated.
The integration design documents the planned concept in order to realize the integration architecture
requested by the customer. This may require the following types of activities: Configure and customize SAP
standard integration Implement existing best practice scoping items for specific integration scenarios
Develop new or enhance existing development objects (i.e. interfaces) as defined in the integration design
Prerequisites This activity is recommended for all scenarios. The integration activities have been fully
defined and documented (i.e. write technical design/WRICEF). See activity Integration Design
in the Explore phase. All required activities have been included in the project schedule. Procedure
Realize the integration activities as planned Unit testing of implemented integration activities
Document the results of the integration activities implementation Results As the result of the integration
implementation all the planned and defined integration activities are initiated and in realization. How SAP
Can Support SAP supports this activity with the “WRICEF Developments” service as part of
SAP Professional Services.
The objective of integration validation is to ensure technical readiness of the entire solution for Go-Live. It
includes analysis of critical business processes and interfaces validating scalability, performance, data
consistency and exception management. A comprehensive status (at least on monthly basis) of technical
go-live readiness for core business processes (integration validation matrix) is recommended. This topic is
already handled in detail in this road map in the activity Integration Validation . Prerequisites See
activity Integration Validation in the Realize and Deploy phase. Procedure See activity
Integration Validation in the Realize and Deploy phase. Results As the result of this activity,
integration validation activities have been planned, documented and initiated. They will continue across
the Deploy phase. How SAP Can Support SAP supports this activity with the “Integration
Validation” service component as part of the “Safeguarding the Digital
Transformation” service.
This activity sets up a quality assurance environment (QAS). It depends on the scenario how this is done.
Please note: This road map documents the setup of a DEV and a QAS system. Of course, the design of the
production support landscape depends on customer requirements for change management. Maybe
additional supporting systems need to be set up (e.g. pre-production or training). In those cases the project
plan template needs to be adjusted accordingly. Requirements and Constraints This activity is required for
all scenarios. There is a technical design document stored in SAP Solution Manager which includes the
technical deployment plan, and the software components which need to be installed / updated. The DEV
environment has been set up successfully. Procedure QAS Setup (New Implementation) or QAS Setup
(System Conversion) Please note: Before converting an SAP system, or installing a fresh one, you will need
to download SAP software from SAP Service Marketplace. The planning of such a change event is done in
the Maintenance Planner. After entering the required data, the Maintenance Planner fills your download
basket, and creates a control file (“stack-xml”), which is later on required for the conversion
and installation tools. The Maintenance Planner has been described in the activity Transition Planning of
the Explore phase - Please make yourself familiar with the tool, enter the required information, and
download the corresponding software including stack-xml. See accelerator section for details. How SAP Can
Support SAP offers the provisioning of the QAS environment for both scenarios as part of the
“Platform Execution” service. Please ask your SAP contact (e.g. SAP Client Partner) for
more information. This is a dedicated scope option (System Conversion for SAP S/4HANA
and System Installation for SAP S/4HAHA ). The setup of the technical Fiori components is
covered by scope option SAP Fiori Platform Setup . See accelerator section for more information.
However, the configuration of the Fiori UIs is not included in this scope option but is part of the
functional setup.
The goal of this task is to provide a viable, correctly configured technical quality assurance environment
that is available for use by the project team to test configuration and development in a “production
like” environment. Procedure Proceed as follows: Execute the technical installation of the
required SAP Products for QAS environment as documented in the technical design document. See the
“Installation Guide for SAP S/4HANA” how to install the components. Run the technical
system setup as documented in the “Administration Guide for the Implementation of SAP
S/4HANA”. Transport development and configuration changes from DEV to QAS. Consider also
the manual rework activities as described in the “Administration Guide for the Implementation of
SAP S/4HANA”. Check to what degree the Fiori apps require additional configuration in QAS.
Results Finally, the QAS environment is ready for testing. How SAP Can Support SAP offers the installation
of a QAS as part of the Platform Execution service. Please ask your SAP contact (e.g. SAP
Client Partner) for more information. This scope option is called “ System Installation for SAP
S/4HANA ” – see accelerator section for more information. The setup of the Fiori
platform can be supported as well (scope option “ SAP Fiori Platform Setup ”).
However, the configuration of the Fiori UIs is not included in this scope option but is part of the
functional setup.
The goal of this task is to provide a viable, correctly configured quality assurance environment that is
available for use by the project team to test configuration and development in a “production
like” environment. QAS is not installed newly – instead, the old QAS system is converted to
SAP S/4HANA. Prerequisites Prerequisite is that the migration approach that has been validated in a
sandbox environment (see activity SANDBOX System Setup in the Explore phase ) , a detailed migration
plan is in place, and the required hardware for hosting the SAP S/4HANA DEV system is already available
and set up. Furthermore the cleanup of the productive system is already underway or has been finished
(see activity Cleanup / Archive in the Realize phase for details). Procedure Convert the QAS system
according to the migration plan (which is based on the “Conversion Guide for SAP
S/4HANA”). Depending on the transport landscape configuration, there may be a need to perform
multiple iterations of the conversion in order to solidify and finalize the cutover plan. Executing test
migrations will validate the end-state of the conversion, as well as provide the figures for expected system
downtime (see activity Downtime Optimization Preparation for details). Depending on the approach and
the transport landscape configuration, there may be a requirement to execute additional sandbox
conversions in order to optimize the cutover procedure. Transport development and configuration changes
from the new DEV to QAS. Check to what degree the Fiori apps require additional configuration in QAS.
Results Finally, the QAS environment has been converted to SAP S/4HANA. It is ready for further
configuration. How SAP Can Support SAP offers the QAS conversion as part of the “ Platform
Execution” service. Please ask your SAP contact (e.g. SAP Client Partner) for more information. This
scope option is called “ System Conversion to SAPS/4HANA” – see accelerator
section for more information. The setup of the Fiori platform can be supported as well (scope
option “ SAP Fiori Platform Setup ”). However, the configuration of the Fiori UIs is not
included in this scope option but is part of the functional setup.
For large systems, the conversion using standard tools may exceed the available downtime window. In this
case the " Minimized Downtime Service (MDS)" supports performing the
conversion within the given constraints. This method uses a clone of the production system for performing
the conversion activities outside of the production and in parallel records the changes on the production
system. These changes are replicated to the target system after the completion of the conversion on the
clone system. An appropriate preparation of this method for the production cut-over requires the
corresponding verification of the end-to-end procedure in so called Load & Verification runs. These
activities are planned along the project and using data from the production system, they are mocking the
cut-over steps. During these runs the validation of the procedure is done and the final timings for the
production cut-over are determined. For new implementations this activity is to develop, implement, and
test the data migration programs and processes defined in the Explore phase. This activity consists of
iterative development and testing cycles focused on the analysis of data, refinement of business rules, and
deployment of migration programs and processes designed to move, cleanse, transform, and enrich legacy
data required to support the various test cycles and ultimately the production cutover. The test cycles
enable the migration team to improve data quality to an acceptable production level, develop a detailed
cutover sequencing plan, and exercise data reconciliation and validation processes required to support the
production cutover. In case of landscape transformation, the tasks within this activity largely depends on
the scenario. In case of client transfer, system merge, and company code transfer harmonization and
adjustment tasks (e.g. for customizing and repository objects) need to be performed before data can be
successfully transferred. Test runs ensure that the target state is consistent. Requirements and Constraints
This activity is required for all scenarios. Procedure Legacy Data Migration (New Implementation) or
Perform Load & Verification Runs (System Conversion) or Perform Client Transfer (LT Scenario
– Client Transfer) Perform System Merge (LT Scenario – System Merge) Perform
Company Code Transfer (LT Scenario – Company Code Transfer)
The purpose of this task is to develop, implement, and test the data migration programs and processes
defined in the Explore phase. This task consists of iterative development and testing cycles focused on the
analysis of data, refinement of business rules, and deployment of migration programs and processes
designed to move, cleanse, transform, and enrich legacy data required to support the various test cycles
and ultimately the production cutover. The test cycles enable the migration team to improve data quality to
an acceptable production level, develop a detailed cutover sequencing plan, and exercise data
reconciliation and validation processes required to support the production cutover. Procedure Proceed as
follows: Develop the specific architecture, programs, and processes that support the extraction,
validation, harmonization, enrichment, and cleansing of the legacy data based on the data migration
specifications from the Explore phase (see activity Data Migration Design). The programs and processes
directly depend on the tools and utilities deployed and available for the engagement. These deliverables
can range from fully automated programs based on an extract, transform, and load (ETL) software platform
to a series of manual processes based on tools such as Microsoft Excel and Microsoft SQL Server.
Provide source legacy data in a format that supports the standard SAP load utilities or data readily available
for manual creation in the new system Also provide templates and instruction for data loads. Execute
multiple test rounds of data migration. Obtain data migration test results (see accelerator section): The
purpose is to obtain the results of the various test cycles so the team can monitor the accuracy and
efficiency of the data migration solution. The data migration test results are statistics that provide a
detailed account of data load issues and successfully loaded data. The metrics should be available at
summary and detailed levels. The test results are a subcomponent of the overall test reporting process. By
completing this task, the project team gains visibility into the progress for each of the data migration
iterations and gains the information to determine the level of readiness of the data. The test results can be
stored in SAP Solution Manager to track the issues history and progress. Conduct final data quality
assessment: The purpose is to provide one final assessment at the end of the Realize phase to report on
the quality of the loaded data. Once all tests and queries have been conducted, the data migration team
compiles the results and requests a preliminary review by the data owners and subject matter experts
(SMEs). Once the data owners and SMEs have provided feedback, the team prepares the final
findings as a written report or verbal presentations to be delivered to key stakeholders. Depending on the
requirements, the final data quality report includes topics such as: Updated data mappings and business
rules Summary of data quality metrics for all the business objects Data profiling results of selected
data Any outstanding data quality issues that need to be resolved At the end of this task, the data
migration team can move into the next phase with the confidence that the vast majority of data quality
issues and migration issues have been resolved and mitigated.
The Load & Verification Run is a task, which belongs to the best practice of the SAP Downtime
Minimization Service. Prerequisites This task is always planned in projects using the clone based Near-Zero
Downtime method. How SAP Can Support In general, two Load & Verification Runs are performed
within the “ Minimized Downtime Service ”: Run 1: During this run, the correctness of the
conversion procedure is verified based on the data from the production system. Therefore, it is a very
realistic simulation of the actual cut-over. It includes: efficient creation of the production clone
correct conversion of the system to SAP S/4HANA on the clone appropriate recording of
changes on the production system correct and efficient synchronization of the recorded data
detailed verification of the final conversion result This run offers an opportunity to create the detailed
and realistic step description (runbook) including actual system names and timings for the execution of the
procedure in the production cut-over. Run 2: This run is the second iteration of the Load &
Verification Run. It belongs to the best practice of the SAP Downtime Minimization Service. This task is
always planned in projects using the clone based Near-Zero Downtime method. This is the final end-to-end
verification of the cut-over procedure including the technical and human aspects. In this run all parties
planned for the production cut-over are involved. The dress rehearsal is executed based on the runbook
finalized in the Load & Verification Run 1. Beside of the confirmation of items verified in the first run it
provides information about: detailed timing of the individual steps finalization of the
required hand-over procedures The findings of this run provide information for the fine tuning of the
runbook. Based on the both Load & Verification Runs the risks in the production cut-over can be
considerably reduced. Results As the result the production cut-over is executed according to the well
described and practiced procedure.
The “ Client Transfer ” service component as part of the “ Data Migration Execution
” service helps customers to move clients from one SAP instance to an SAP S/4HANA system. The
SAP Landscape Transformation client transfer functionality used in this service component moves one or
more complete clients (including customizing, master,and transactional data) from one or more sender
systems to a single SAP S/4HANA receiver system. It allows customers to combine consolidation, upgrade,
Unicode conversion and database change to HANA in one step. In addition, it ensures process continuity
and can consolidate data from more than one sender system in the SAP S/4HANA system. However,
because a client transfer affects many areas in your system landscape, it can be realized only if the
repository and client-independent customizing and setngs are compatible at system level. The client
transfer analysis which is part of the Landscape Transformation Assessment service component (see
Explore phase) reveals any data conflicts and determines all data that requires harmonization at system
level. The activity is only relevant in case for landscape transformation scenarios, where clients need to be
transferred across systems. Procedure Proceed as follows: 1.Perform Cross-Client Customizing
Harmonization In this task, customers harmonize the cross-client customizing for the following
areas: Basis, cross application and additional topics Logistics Accounting 2.Perform
Repository Harmonization The goal of this task is the harmonization of the sender system and the SAP
S/4HANA receiver system repositories: Use the repository comparison results from the Data Migration
Design service to define the repository harmonization activities.Note that additional harmonization
activities are necessary if a Unicode conversion is required. Business process requirements of the sender
and SAPS/4HANA receiver systems, as well as any redesigned business processes can be relevant for
harmonization. Determine the required harmonization strategy for the relevant objects, and also define
the technical procedure for the harmonization strategy (the steps involved). For complex conflicts
without a standard harmonization strategy, also create specifications. Create design documents for the
specifications, if required. Plan the necessary activities for implementing the harmonization. Take into
account the required resources (for example developers and systems), the migration schedule and the
synchronization strategy with ongoing development and maintenance activities. 3.Perform Test
Cycles Before the conflict-free client migration can become live in the productive SAP S/4HANA
environment, customers must test the following several times in the new landscape: The data migration
process,   Harmonized and adapted customizing setngs, and The adjustment of
repository and the business processes. This usually involves three test cycles. A test cycle involves the
following activities: Refreshing temporary test migration landscape Build new temporary test SAP
S/4HANA receiver system and test sender system using an up-to-date copy of the productive systems.
Executing the client migration with SAP LT Client Transfer The data migration copies all client-specific data
from test sender system client to the assigned client of the test receiver system. Executing the upgrade
procedure If migration involves an upgrade SAP LT Client Transfer has to adapt the migrated data records to
the release ofthe new environment. The SAP LT Client Transfer Upgrade adds SAP template customizing
– as shipped with upgrade transports – to the migrated client. In addition, the necessary
logical adaptation of the data is executed by the means of XPRA programs. Validating Blueprint /
The SAP Landscape Transformation system merge methodology used in this service merges business data
of two or more clients from one or more sender systems to a single, empty SAP S/4HANA receiver system.
It allows you to combine consolidation, data model conversion, Unicode conversion, and database changes
to HANA in one step. In addition, it ensures process continuity and can consolidate data from more than
one sender system in the SAP S/4HANA system. However, because a system merge affects many areas in
your system landscape, it can be realized only if the repository, client-independent and client dependent
customizing and setngs are compatible at system level and at client level. The system merge analysis
carried out during the data migration Design reveals any data conflicts and determines all data that
requires harmonization at system and at client level. Prerequisites This chapter describes only the tasks
relevant for the execution of the tasks specific for the LT scenario. Other tasks relevant for moving to SAP
S/4HANA are still relevant, such as topics to be addressed as outcome of the SAP Readiness Check for SAP
S/4HANA. Procedure Proceed as follows: Create future development and production systems
The future development system for the SAP S/4HANA or S/4HANA Finance landscape can be created in two
ways: Installation from scratch LT shell creation as a copy of repository and Customizing
out of one of the existing systems The missing Customizing and repository from the additional
source systems and also the future Customizing resulting out of the harmonization blueprint, need to be
implemented manually in the target development system. The target test systems and future production
can either be created out of the development box. Alternatively it can be created in the same way as
described above and then supplied with the customizing and repository delta by transports.
Perform cross-client customizing harmonization The objective is to harmonize the cross-client
customizing for the following areas: Basis, cross application, and additional topics
Logistics Accounting Use the Customizing comparison results from the Data Migration Design
service to define the repository harmonization activities. Note that additional harmonization activities are
necessary if a Unicode conversion is required. Business process requirements of the sender and SAP
S/4HANA receiver systems as well as any redesigned business processes can be relevant for harmonization.
The comparison is executed between the affected source systems. The solution of the conflicts
identified between the sources have to be projected to the future target system and maintained there.
For more information, see the ‘Client Transfer’ Product road map of SAP Landscape
Transformation software, for example in the accelerator ‘General Rules for Cross-Client Customizing
Conflicts’ in activity 1.4.1 ‘Cross-Client Customizing Analysis’. Perform
repository harmonization The objective is to harmonize the sender systems and SAP S/4HANA receiver
system repositories. Use the repository comparison results from the Data Migration Design service to
define the repository harmonization activities. Note that additional harmonization activities are necessary
if a Unicode conversion is required. Business process requirements of the sender and SAP S/4HANA
receiver systems as well as any redesigned business processes can be relevant for harmonization. The
comparison is executed between the affected source systems. The solution of the conflicts identified
between the sources have to be projected to the future target system and maintained there. Determine
the required harmonization strategy for the relevant objects, and also define the technical procedure for
The Company Code Transfer service helps you to transfer company code related data from the ECC 6.0
system in use to a new, empty SAP S/4HANA system. It is a service covering a selective migration of
company codes. The following use cases can be differentiated: Company Code Transfer (Complete
History): The data migration covers master data and transactional data, optional also Customizing
Full data history will be migrated Customer-specific tables can be handled as well
Company Code Transfer (Shell): Company code Customizing is covered, and optional
master data Customer-specific tables can be handled as well Procedure Proceed as follows:
Check tables in use Especially customer-specific tables have to be evaluated and discussed in
regards to selection and migration rules. Afterwards they have to be added to the tool to make sure they
are in scope of the data migration. This task will be supported by analysis tools provided by SAP.
Alignment of Target Organizational Structure (only Relevant for Company Code Transfer Shell) The
objective is to align the organizational structure in the target. The full history company code transfer
migrates data without any changes. If only a shell of a company code has to be moved, the target
organizational structure has to be defined. Example:Source system: Company code 1000 has two plants:
1100 and 1200. In the target system it should look like: Company code 1000 with three plants: 1500,
1600,and 1700. Perform dictionary and repository harmonization during the project The
objective is to harmonize dictionary and repository between source and target. Company code transfer
projects last several months. In this time frame changes are usually applied to the source system. To make
sure that all relevant data will be moved during the different test cycles and especially during go-live, it is
essential to keep dictionary and repository of source and target system in sync. Example: A customer-
specific table will be imported into the source production system after test cycle 1. This table definition has
also to be transported to the target system to make sure it can be migrated as of test cycle 2. The
harmonization of the sender system and SAP S/4HANA receiver system is a prerequisite for a company code
transfer. Determine the required harmonization strategy for the relevant objects, and also define the
technical procedure for the harmonization strategy (the steps involved). For complex conflicts
without a standard harmonization strategy, also create specifications. Create design documents for the
specifications, if required. Plan the necessary activities for implementing the harmonization. Take into
account the required resources (for example, developers and systems), the migration schedule, and the
synchronization strategy with ongoing development and maintenance activities.
Perform Test Cycles A company code transfer project is not done in a single shot. Usually 3 test cycles
are performed before the migration of production data during go-live can take place. The different test
cycles cover the following activities: Source system refresh Target system creation and
harmonization of source and target environment Data migration preparation and execution
Data migration post processing, for example, integrated upgrade Data model conversion
Test ingand issue handling Preparation of next cycle This usually involves three test cycles.
While the first and second test usually focus on functional correctness, the third test focuses on
performance and execution according to the cut-over plan. How SAP Can Support SAP supports
this
The task withof
purpose the scope
this option “
activity Company
is to perform the final Code Transfer
preparation steps foras Shell ”
cutover. and “
The cutover plan will be
tested in the Dress Rehearsal activity in the Deploy phase. Requirements and Constraints
This activity is required for all activities. However, preparation steps are scenario specific. There is a
technical design document stored in SAP Solution Manager which includes the technical deployment plan,
and the software components which need to be installed / updated. Procedure Production System
Setup Create Cutover Plan (New Implementation) or Create Cutover Plan (System Conversion) or
Create Cutover Plan (Landscape Transformation (Example: Client Transfer)
The goal of this task is to provide a viable, correctly configured production environment that is available for
use by the project team to execute final Go-Live simulations. This environment will be used as the future
production system (PRD) as of Go-Live. Prerequisites This task is required for those scenarios which set up a
new production system. Prerequisite is that the productive hardware is already available and set up.
Procedure Execute the technical installation of the required SAP Products for PRD environment
as documented in the technical design document. See the insalltion guide for how to install the
components. Run the technical system setup as documented in the administration guide.
Transport development and configuration changes from the new QAS to PRD. Consider also the
manual rework activities as described in the administration guide. Results Finally, the PRD environment is
ready for final Go-Live simulations. How SAP Can Support SAP offers the installation of a PRD as part of the
Platform Execution service. Please ask your SAP contact (e.g. SAP Client Partner) for more information. See
accelerator section for more information. The setup of the Fiori platform can be supported as well (service
component SAP Fiori Platform Setup ”).
The objective of this task is to create the cutover plan. The plan is based on the learnings from the legacy
data migration runs which have been performed so far. Procedure Execute Go Live Simulations 1 – n
The purpose of this task is to rehearse or simulate the cutover activities. During simulation, the main
objective is to validate and document the tasks, sequence, and duration of items on the cutover plan.
These simulations help determine data load efficiency, timing, and sequencing and foster an understanding
of requirements for the detailed cutover schedule. The number of simulations varies from project to
project, so do the objectives for each simulation. Rehearsals are repeated until go-live risk is minimized.
Load simulations give the project team a chance to review the data for errors and data cleansing issues. A
new implementation may require three simulations: Technical – Project team participation only
for the purpose of validating steps Dry run – Full execution of the cutover schedule with the
entire team for the purpose of validating steps and data Final – Full execution of the entire
cutover schedule for the purpose of flawless execution to obtain exact timings Results After completing the
simulations, the project team has very good understanding of the potential issues as well as timing and
sequence of the final production system data load. The project team is able to refine the cutover schedule
and make sure that it realistically reflects the time and effort required for all activities during cutover.
Equally important, is a contingency plan in the event there is an unforeseen issue that is unable to be
resolved within the planned business downtime.
The objective of this task is to create the cutover plan. The plan is based on the learnings from the load
& verification runs which have been performed so far. Procedure The conversion of the production
system requires a clearly defined cutover plan and will typically be controlled by a cutover manager. You
can look up a sample cutover plan for system conversion in the accelerator section for getng insight into
the level of detail the cutover plan should have. A cutover plan documents the end-to-end activities of the
cutover; from the steps leading up to the event, through to the end of the conversion. High-level tasks
commonly found in cutover plans include: Prerequisite steps for the production conversion Ramp-
down activities (e.g. batch jobs, interfaces, etc.) Pre-conversion validation reports End-user lockout
Technical migration and business data conversion Post conversion changes (e.g. transports, parameter
changes, etc.) Technical post conversion validation reports (e.g. checking for business data consistency)
Business driven system validation and comparison of the pre and post conversion reports Go/No-Go
decision Ramp-Up activities (e.g. batch jobs, interfaces, etc.) User unlock The next picture sequences
cut-over activities for a multi-TB SAP ERP system on a time line (example only, not complete, needs to be
adjusted to the customer specific situation). Figure: General sequence of activities for a multi-TB SAP ERP
system during cut-over weekend Please note: The SUM should start preparation days in front of the real
system conversion. Please make sure mandatory preparation activities like CVI (see activity Transition
Preparation in the Prepare phase for details) which are check via SI-Checks by SUM have been finished.
Otherwise SUM will stop. SAP’s recommendation is having those activities finished not later than
two weeks before cutover weekend. The cutover plan does not detail the technical conversion to the level
that is captured in the cookbook. It is common to highlight specific tasks from the cookbook within the
cutover plan to ensure the process is on schedule. Every task within the cutover plan should have an
assigned owner, estimated duration, and identified dependencies. Whenever possible, assign a name to the
owner of the task, and not a team or group of resources. The owner of each task should validate and
approve the task to ensure they understand their responsibilities. If there are any tasks required to
specifically enable the conversion activities, the cutover plan should include related tasks to reset the
values to the intended productive state. The cutover plan should also include a contingency plan to revert
the changes in the event there is a No-Go decision. If the contingency plan does not exist within the actual
cutover plan, the cutover plan should have reference to the location of the fallback plan. Based on the
additional conversion runs, proceed as follows: Document key steps of the migration and conversion
activities. Assign owners to all tasks. Review the tasks with the owners to confirm ownership and
document the estimated duration. Conduct at least one full walk-through of the plan as an entire team.
Document the fallback or contingency plan to safely return production operations in the event of a
No-Go. Work with the business process owners and the batch schedule owners to document the steps
required to safely and quickly ramp-down and ramp-up production operations. Long running batch jobs
should be identified so they can be rescheduled ahead of time. In the event a batch job needs to be
manually terminated at the time of the cutover, it is important to have the termination procedures, or the
owners, documented and readily available. Results As a result, you will get a validated cutover plan, which
documents all the steps leading up to and through a successful Go-Live. Equally important, is a contingency
The purpose of the “Productive Migration Plan” is to schedule the main steps for the
productive migration as well as to ensure the logistics and the communication for the productive migration.
In addition, a period of hyper care that follows the go live needs to be planned as well. Prerequisites The
activity is only relevant in case for landscape transformation scenarios, where clients need to be transferred
across systems. Procedure It is important to plan the sequence and the dependencies of all technical steps
to be taken for the productive migration. This starts with the closure of the system for users, the stop of all
batch-programs and ends by releasing the new system. It is also important to plan back-up and recovery
strategies. The necessary technical steps vary depending on the project. Therefore this document does not
cover every possible step, but focus on these most important steps: Closing the sender and S/4HANA
receiver system, and stopping interfaces Performing a backup of the receiver system (this creates a fall-
back solution in case the project fails) Preparing final test cases Activating table count for the sender
and receiver system Executing the migration (details see the task Perform Technical Migration
in the Productive Cutover) Executing post-processing programs Executing the table counter
for the sender and receiver systems again to verify completeness of the migration Testing Obtaining final
approval from the test team in order to release the system Restarting the interfaces from the receiver
system Redirecting interfaces from the sender system Releasing system to end users, and
communicating the Go Live status Customers can find further information about the cutover
preparation in the ‘Client Transfer’ Product Road Map of SAP Landscape Transformation
software, Refer to phase ‘4 Final Preparation for Productive Migration’. Results Finally the
PRD environment is ready for final Go-Live simulations. How SAP Can Support SAP supports the creation of
a cutover plan as part of the Data Migration Execution service. Please ask your SAP contact
(e.g. SAP Client Partner) for more information.
In this activity, the sizing estimation performed in the Explore phase (see activity Sizing in the Explore
phase) is further detailed out and verified afterwards. The initial assumptions made are now challenged
with KPIs from reality. Requirements and Constraints This activity is optional for all scenarios. There is a
documented sizing estimation from the Explore phase stored in SAP Solution Manager. Procedure Optional:
Perform Sizing Verification Optional: Perform Scalability Verification
The goal of this task is to validate the sizing estimation from the Explore phase based on the planned
application design. Prerequisites There is a documented sizing estimation from the Explore phase stored in
SAP Solution Manager. There is a pre-production system already available. Procedure To validate the sizing
projections, SAP proposes a two-fold approach: Load testing of the pre-production system Workload
analyses across all systems on the critical path in production. The latter is based on technical resource
consumption monitoring, the sizing report and application workload analysis. Results The sizing estimation
for the productive system has been validated. How SAP Can Support SAP can perform this task with the
“ Advanced Sizing ” service component, which is part of the “ Platform Design”
service.
To guarantee the success of the smooth processing of core business processes, these processes need to be
measured, tested and compared between the source and target systems. As a goal the converted SAP
system shall deliver the same or better performance indicators as compared to before the conversion.
Therefore the results have to be compared against the predefined performance baseline. Prerequisites
There is a test system available which has comparable hardware than the future productive system.
Procedure For the proper verification a test conversion will be performed on comparable hardware
containing the representative data volume. The different scenarios for single and mass load testing and
verification are set up and processed. Define the success factor for the load tests Perform mass load
testing Report and review process Optimization, Re-design and Re-test identified components according
to the predefined performance baseline Communication of the results and possible changes in the
production environment The results will be measured over the defined timeframe and compared to the
baseline. Results The performance gain has been properly measured and documented in SAP Solution
Manager. How SAP Can Support SAP can provide support for the test and optimization of the Volume Test,
and/or provide specific business case optimization where required. Please contact the embedded support
team for more details.
In the Realize phase the technical infrastructure has to be installed and configured as required for the Go-
Live. Prior to the Go-Live, a technical verification is proposed to ensure that SAP Best Practices are
followed. The technical infrastructure follows the technical design document created in activity Technical
Design . Requirements and Constraints This activity is recommended for all scenarios. A technical design
document has been created and stored in SAP Solution Manager. Procedure Set Up IT Infrastructure Test IT
Infrastructure Results The technical infrastructure has been properly tested.
The goal of this task is to set up the IT infrastructure. It covers (besides others): The setup of the
server hardware, OS and (optional) virtualization platform: In the event SAP HANA is delivered as an
appliance, only sizing, floor space, power, cooling, and network need to be considered. Keep additional
setup activities for the SAP application server, or the storage layer in case of TDI (Tailored Datacenter
Integration) in mind. The setup of the storage solution: The physical setup of the storage infrastructure
– storage systems, storage network, connecting host systems to the storage network –
requires comprehensive knowledge of the selected components, and is usually done by system engineers
of the storage supplier. Integration of the new components into the existing IT environment (e.g.
integration into the existing backup or monitoring solution, network). Setup of High Availability,
Disaster Recovery, and Backup. Prerequisites The IT infrastructure components are available and
ready for setup. Procedure Proceed as follows: Install the IT infrastructure as designed in the
technical design document, and dictated by the conversion method and related conversion guides.
Document or enhance the installation process in a cookbook for use with future builds. The IT
infrastructure is often setup by the hardware partner. Results The IT infrastructure is set up.
Once set up, the IT Infrastructure should be tested thoroughly. Prerequisites The IT infrastructure has been
set up. Procedure Proceed as follows: Execute the infrastructure tests based on the test cases and test
plan. This should include the following scenarios: Performance Flexibility procedures
(e.g. by moving system load to other hosts (e.g. by using virtualization technics), adding instances, changing
instances) High Availability Disaster Recovery Backup and Restore
Infrastructure Security Document any anomalies or defects. Monitor the test system as if
it were production, as this will provide an indication of end-state operations. It is important to leverage this
testing cycle to proactively address issues that could arise in production. Measure the performance
against the defined key performance indicators to ensure the infrastructure operates within the boundary
conditions of the business (see activity performance verification). If already available, test the
productive hardware as well at this point in time, in order to validate the configuration. Otherwise, the
productive hardware is tested in the Deploy phase. Resolve any defects, and retest to ensure all
identified issues are closed. Results The IT infrastructure has been tested properly.
Based on the outcome of the Operations Impact Evaluation in the Explore phase, support
operations need to be implemented or adjusted. This may affect the IT support staff (their roles and
responsibilities; knowledge transfer), support processes and procedures (including proper documentation),
and the setup and configuration of support tools. Requirements and Constraints This activity is
recommended for all scenarios. The documented results of the Operations Impact Evaluation (Explore
phase) are stored in SAP Solution Manager. Procedure Collect detailed Operations Requirements Roles
and Responsibilities Support Processes and Procedures Operations Support Tools Operations
Documentation Knowledge Transfer Results IT support operations has been prepared to operate SAP
S/4HANA as of Go-Live. How SAP can Support SAP has multiple offerings to SAP Enterprise Support
customers with respect to operations implementation: SAP strongly recommends to configure SAP
EarlyWatch Alert, which provides a comprehensive monitoring report. Listen to the Meet the Expert
recording “ SAP EarlyWatch Alert for SAP HANA “ which explains how to set up SAP
EarlyWatch Alert for SAP HANA. Moreover the report content is explained. Join the Expert Guided
Implementation “ SAP HANA (1 of 6) - Monitoring and Troubleshooting ”. This 3-days training
explains how to connect the customers SAP HANA to SAP Solution Manager. In addition it covers the
configuration of Root Cause Analysis and Technical Monitoring for SAP HANA. Join the Expert Guided
Implementation “ SAP HANA (2 of 6) - Database Administration and Operations ”. This 5-days
training demonstrates the tools necessary for the administration and operation of the SAP HANA database.
Join the Expert Guided Implementation “ SAP HANA (3 of 6) - Advanced Database Monitoring
”. This 5-days training explains how you analyze, diagnose and resolve common issues found in SAP
HANA. Listen to the Meet the Expert recording “ SAP HANA Security Overview “ which
provides an overview of SAP HANA security functions and their use in different SAP HANA scenarios As the
SAP Enterprise Support Academy always keeps its offerings up to date, it is always worthwhile to check out
the latest offerings on a regular basis to have chance to learn about the latest offerings in the area of HANA
Operations.
The Operations Impact Evaluation main outcome is the definition of a list of relevant changes to the current
support framework with the corresponding project activities that will support the implementation of those
changes. This list is based on the future customer support strategy and deployment model, as well as on
the current support framework and the solution that is implemented. In other words, it works like the
software change management process and a list of change requests to the IT support framework has been
defined. Those have severities and priorities based on the customer management decisions. This activity
takes place during the Explore phase with the primary goal to raise the awareness of IT upper management
on how the current IT support framework will be impacted. New project activities will be defined to fill the
gaps and this will mean changes in the project plan, potentially additional cost and resource conflicts that
will have to be addressed. Analyzing the necessary changes to the IT support framework later in the project
will make it more and more difficult to manage these conflicts. Not planning the future support framework
will increase the risks of issues in operations after go-live and can be the cause of poor customer
satisfaction and increased project costs as often project resources end up with extensions in their
involvement to support the new solution. The downside of having the Operations Impact Evaluation take
place early in the project is that a lot of details are not yet known, and the specific requirements for the
changes to the support framework cannot be always gathered. This needs to happen later in the project.
During the Operations Implementation, the project activities defined and prioritized during the Operations
Impact Evaluation need to be executed, in other words all the IT related change requests need to be
implemented. The first step will be to define the detailed information required for their implementation,
their detailed specifications like which interfaces need to be monitored, key objects to be monitored to
ensure data consistency or which access needs to be granted to the future support team members. For this
to happen a coordination task needs to take place where the detailed information is gathered from other
project activities. Prerequisites The Operations Impact Evaluation has taken place and the detailed
activities necessary to ready the future IT support framework for the operations of the SAP S/4HANA
solution have been added to the project plan. Procedure The detailed information required to
prepare the future IT Support Framework is well known from other project tracks, for example: The
Business Process priorities are defined during the Application Design which includes the critical processes,
interfaces, and jobs. This will serve as a direct input to the monitoring setup with information on the
underlying systems and the solution components. The new/modified roles and authorization objects will
be defined during Application Design, as well as and during the Technical Architecture. This will bring input
to finalizing the new Access Management process with the differences in roles assignments, and this for
business users as well as for the support resources. The inventory of modifications to non-standard SAP
code will be defined during Development. This will be a critical input to Knowledge Transfer for the new
technical support resources. During the Operations Impact Evaluation, activities related to gathering
detailed information will be defined for each area of the support framework that needs to be modified. The
way to gather the related information will depend on the project structure and responsibilities. Note:
Defining a transition manager to manage all the Operations Implementation activities will make it more
efficient
Whateverthanthe having
currenteach activityframework
IT support responsibleis:go to the project
Operational resource
activities are having
handledthe
byknowledge required for
support personnel
organized in roles. These personnel belong to different groups and even different companies when a
service provider is engaged, with responsibilities and skill levels that help them in the execution of their
activities. When you implement SAP S/4HANA, there are changes in the roles and responsibilities of some
of these resources. These changes will highly depend on your current solution (if you already have SAP
implemented), on your support strategy (if you engage a Service Provider to support your SAP S/4HANA
solution), and on your deployment strategy (cloud vs on-premise). How SAP Can Support SAP has a lot of
experience and recommendations on the roles and responsibilities design including all steps required to
define in detail the roles and responsibilities of the different support resources that are required for the
efficient support of the new solution. Please contact SAP for a tailored offering in case you need support.
With the implementation of SAP S/4HANA, the IT support processes may need to be modified to reflect
new operational requirements. The changed IT support processes need to be documented and tested.
Prerequisites The documented results of the Operations Impact Evaluation (Explore phase) are stored in
SAP Solution Manager. Procedure The following IT support processes are potentially affected with the
implementation of SAP S/4HANA: Event Management : Analyze process change in event management
caused by new/modified/retired monitors Retire obsolete monitors, and monitor templates (in SAP
Solution Manager) Retire obsolete manual monitoring procedures Incident Management : Update
assignment groups, review incident triage (e.g. for Fiori support) Update support resources Update incident
categorization Process flow and escalation management including partners and SAP Remove obsolete
incident attributes Problem Management: Update problem management process to include new analysis
tools Service Level Management : Update SLAs if required (due to changed business KPIs) Update SLA
reporting Access Management: Access for new solution / tools granted to new support team members
including partner resources New/changed access management process for new/changed solution items
(e.g. SAP HANA database, Fiori) Change Management: Update support resources including requesters and
new approvers Update categorization, if required Process flow including partners and escalation
management Include project defects in incident database Remove obsolete change attributes Evaluate
current change process to include Fiori and SAP HANA changes Test Management: Test library should
include new test plans/scripts Job Management: Adapt job schedule caused by the new, modified and
retired jobs (certain batch jobs may no longer be required, as a result of some reports being able to execute
in dialog) Data Volume Management: Changed tools and activities due to new concepts in data volume
management (e.g. data aging) Adapt process in those areas where classic data archiving is no longer
available System Recovery: Adapt system recovery process to reflect the changed HA/DR architecture IT
support processes need to be tested, and access to the new support tools need to be considered. Training
on the IT support process changes needs to be in place (or communication in case of small changes). How
SAP Can Support SAP has created Best Practice documents for IT support standards (see accelerator
section). These documents give first guidance how IT support processes should be set up. SAP has a lot of
experience and additional recommendations on IT support process design that are required for the
efficient support of the new SAP S/4HANA. Please contact SAP for a tailored offering in case you need
support. Please also remember the Primary CCOE Certification which need to be in place for Enterprise
Support customers.
Based on the results of the Operations Impact Evaluation , requirements on IT operational support tools
need to be finalized to safely operate the new solution (this may also include surrounding components like
the Fiori Front End Server). The tools need to be adjusted or newly set up. Deprecated IT operational tools
need to be carved out, and IT operational procedures have to be adjusted accordingly. For
“Greenfield” customers, the effort required to implement the tools will be much higher. This
will require additional effort for the support resources to learn how to use the tools, especially
SAP Solution Manager. Prerequisites The documented results of the Operations Impact Evaluation (Explore
phase) are stored in SAP Solution Manager. Procedure With the introduction of SAP S/4HANA, it may be
required to adjust existing IT operational support tools (e.g. adjust change management tools to be able to
handle Fiori objects for the first time), or to set up new tools (e.g. SAP HANA cockpit in case this is the first
system on top of SAP HANA). The following list gives you some common examples where adjustment
activity may take place. The main list should have been created in the Operations Impact Evaluation (see
activity Operations Impact Evaluation in the Explore phase for details). See the Accelerators section for
more information on how to execute the necessary adjustments. SAP has dedicated offerings to support
this task. Adjust SAP Solution Manager configuration with respect to: General system
management (“Managed System Setup”) Monitoring elements (e.g. critical
interfaces, critical batch jobs, End-User-Experience, SAP HANA DB), and monitoring customizing (e.g. alert
thresholds) Change Request Management and CTS+ (e.g. to be able to handle SAP HANA and/or
Fiori objects in a synchronized way) Adjust SAP HANA tools: HANA Cockpit to
manage the SAP HANA database SAP HANA Studio e.g. for HANA programming, or HANA
dictionary SAP DB Control Center for central & aggregated DB monitoring DBA Cockpit
e.g. for running DB administration activities Plan to ramp down support tools (e.g. DB specific scripts
your database administrators used in the past), which are no longer required, and adjust IT support
procedure descriptions accordingly.
IT operations documentation should be stored centrally in an operations documentation repository, which
is then shared across all operational support teams. Prerequisites The documented results of the
Operations Impact Evaluation (Explore phase) are stored in SAP Solution Manager. Procedure Adapt all
operational documentation that changes with SAP S/4HANA. The content needs to be provided by the
project team, based on SAP standard documentation that is modified with respect to customer solution
specific information. Store the updated operations handbook centrally, either in a company Content
Management System, or in SAP Solution Manager. Based on activity Operations Impact Evaluation , and on
activity Operations Support Tools , the operational procedures are updated in the operations handbook.
The following areas are typically included in the operations handbook (besides others): System
Description : Outlines new functions and capabilities, high level architecture, integration details, number of
users, expected volumes, use cases, priorities, etc. System Architecture : Architecture, sizing and
technical setup information of Solution Manager and other operations tools. Access, Roles and Profiles :
Identifies user groups, roles and role approval list Restart and Recovery Procedures : Outlines how to
restart or recover from process failures and clearly describes error messages and conditions. Backup /
Recovery : Documented process of the backup / recovery methodology; includes standard and emergency
backup scheduling and approval process. Batch Scheduling : Documents and presents the batch job
schedule. Includes details on the jobs (e.g. stop, restart, criticality, owner, failure procedure), and the batch
scheduling tools (if applicable). Run Books : A collection of routinely executed procedures either
performed through automated means or manual execution by system administrators (example: system stop
and start procedures). Storage Management : Provides technical information on the storage and when to
add storage; may also contain instructions on data volume management. Disaster Recovery : Documented
process of the recovery steps in case of a disaster (and the disaster declaration procedure itself).
Maintenance Management Strategy : Documents the process to implement patches and upgrades (in
alignment with the change management strategy). Network Management : Maintenance instructions
for the network, network setngs and parameters. If applicable, also contains vendor contact information.
Non-Functional Requirements : The requirements that do not affect the solution but affect the
behavior of the system. It includes availability, maintainability, performance, scalability, security, and
system usability. Output Management : Defines the setngs and management for all output mechanisms
such as printers, fax machines, emails, etc. OS & DB parameters : Defines the operating system and
database parameters (and a procedure description how change parameters according to the change
management process). Vendor Information : Vendor contact information for operations support, and
the minimum set of information which needs to be provided. IT Calendar : Identifies agreed
maintenance windows, backups and additional technology/infrastructure activities in calendar format.
Furthermore, the Administration Guide, the Technical Operations Guide and the Master Guide for SAP
HANA (Accelerators section) list the required periodic and ad-hoc administrational procedures. How SAP
Can Support SAP has a lot of experience in creating a tailored operations handbook. Please contact SAP for
a tailored offering in case you need support.
The primary goal of this activity is to analyze all the aspects of the knowledge required to sustain the
implementation of the SAP solution, and to ‘grow and groom’ the future SAP IT support
resources to effectively and efficiently support the solution. Additional goals of the strategy are to:
Define a repetitive process that can be applied for each release and to new hires Reduce or mitigate risk
through ownership and accountability Develop metrics to capture and assess performance for
knowledge transfer capabilities The objectives of the knowledge transfer are to: Identify roles and
responsibilities involved in the knowledge transfer process Transfer knowledge, skills and abilities required
to provide solution life cycle support Develop a formal process for monitoring and evaluating the
effectiveness of the knowledge transfer process based on objectives and performance metrics Prerequisites
The documented results of the Operations Impact Evaluation (Explore phase) are stored in SAP Solution
Manager. Procedure To define the Knowledge Transfer Approach for a new solution Go-Live, you will need
to take many aspects into account including: The alignment of the knowledge transfer with the overall
system conversion project plan The project scope and initial definition of all the knowledge transfer areas
to be planned: the functional areas are to be defined, and all technical areas (especially the new ones like
Fiori) as well as new support tools The project methodology and documentation The future support
organization The availability of the project support resources now and in future (workload and time)
The hyper care phase exit criteria as per contract The sponsorship for the knowledge transfer activities,
both for the project and the future IT support operations team The following criteria could be considered
to decide when knowledge transfer to the IT support operations team is complete: All high-priority
failures resolved All high-priority gaps implemented All deferred requirements fully documented and
specified All deferred requirements development planning completed All deferred requirements
testing planned All deferred requirements release scheduling planned Master Data is operational and
no critical issues exist Interfaces are running stable All business critical reports are available
Knowledge transfer is documented Service Desk call level is manageable with the team in place, to
conduct Level-1 support immediately There are different types of knowledge transfer activities: Formal
Training: Standard training as per the SAP Education Catalog Formal Session: T2O/Project trainer
provides initial KT session Self-Study: KT Recipient reads documentation provided by T2O/Project team if
no other type of training is provided. On the job training: T2O/Project trainer executes an activity with
KT Recipient overseeing the execution; KT Recipient participates to testing activities Shadow support /
activities: T2O/Project trainer assigns a specific task to a KT Recipient, KT Recipient executes and
documents execution.
The purpose of this deliverable is for the project the team to carry out the planned and
approved project work and measures project performance to identify variances from the plan. Executing
manages the scope of the work to be done, while monitoring the execution, identifies variances from the
plan, monitors quality results, controls progress against the plan, controls changes throughout the project,
assesses and responds to risks, and communicates project status. The Project Management Plan
developed during the Prepare phase for each of the PM knowledge areas guides the team's approach
to management, execution, monitoring, and control of project activities. This methodology provides steps
to be considered when each activity is engaged and supported by the team's monitoring/controlling
plans. The project manager is responsible for ensuring that the monitoring/controlling plans developed in
the planning phase are applied at the appropriate level of control.
The purpose of this task is for the project manager and the project team to execute the project
management plan and to accomplish the work defined in the project scope statement .In executing the
project work, the project team will perform the following types of activities: Perform project tasks to
reach project objectives Expend effort and funds to accomplish project objectives Staff, train, and
manage the project team members assigned to the project Obtain, manage, and utilize resources
Implement and execute the planned methods and standards Create, control, verify, and validate project
deliverables Manage the scope of the approved work Manage risks and implement risk response
activities Manage issues to closure Adapt approved changes into the scope, plans, and project
environment Establish and manage internal and external communications Collect project data and
report on progress and performance In monitoring/controlling work results, the project team performs
the following types of activities: Compare actual project performance to the project management plan
Assess performance to determine whether corrective or preventive actions are necessary Monitor
and control project risks Provide metrics to support progress and performance reporting and forecasting
Monitor implementation of approved changes Take corrective action as needed Management
plans developed during the Prepare phase guide the team's approach to management, execution,
and control of project activities. See “Prepare Project Management Plan” task in the Prepare
phase for details. The project manager is responsible for ensuring that the management plans are applied
at the appropriate level of control.
The purpose of this task is to ensure that the project manager keeps the key project management
documents up-to-date. This task includes refinement of the project schedule, refinement of the project
budget, and appropriate updates to the management plans, scope document and business case to reflect
the detailed scope information created during the project. The project management documents are,
together, a comprehensive body of project documents that includes the project schedule, budget/cost
information, monitoring/controlling plans for each of the nine knowledge areas of the Project Management
Body of Knowledge (PMBOK), and other information as appropriate. The project management plan
document developed for each of the knowledge areas provide the foundation for the consistent application
of project management practices. This task includes updates to: Project management plan Project
WBS Project schedule Project budget Business case Scope document Backlog document
(created in Explore phase)
The purpose of the Manage Project Issues, Risks, and Changes task is to have a consistent, comprehensive
approach to managing project issues is a critical component of an effective project management system.
Effective issue management involves the appropriate level of management making decisions on issues and
tracking progress on issue resolution in accordance with the project issue management procedure.
Identified issues are maintained in one, central environment. In on-premise projects, this environment is
the SAP Solution Manager, and depending on the type and status, it may be directly transferred over to SAP
for resolution. In cloud projects, teams are advised to use a dedicated issue tracking document based on
the Open Issue List Template in the SAP Activate methodology. The Issue Management handling involves
the following steps: An issue is raised and properly classified as it is related to the system conversion,
solution implementation, or solution operations of an SAP solution or technology. It is created in the issue
tracking tool, either by SAP, a customer or a system integrator. During the issue creation, the person
raising the issues assigns the priority and the responsible person for resolution of the issue. The
Project Manager follows up on issues on a regular basis in addition to the standard issue management
process defined for the project (part of the management plans) Critical issues will be reviewed as an input
for each Quality Gate review meeting. Open issues are reviewed and updated on a regular basis and
communicated to the appropriate stakeholder groups as part of the regular project reporting and
communication. From SAP's perspective, issue tracking allows for better visibility and transparency of
open issues, problems, action items, and associated action plans to the project management team. A
central issue tracking system (e.g. a support or an incident ticket system) allows stakeholders to manage
and maintain lists of issues that require action and resolution to ensure the success of the project.
The purpose of this task is to communicate project status and progress. Throughout the project, a number
of project performance reports need to be produced for different purposes and audiences, as defined in
the project communication plan . The project manager and project team are responsible for clearly
communicating the progress of the key activities, completion of the deliverables, and status against the
schedule and budget. The project teams typically prepare: Team member status update produced
typically weekly and shared with the team lead. It is recommended that this report is kept very lightweight
and provided to the team lead via e-mail or in a team meeting. Team status reports on regular cadence,
typically weekly. The team status reports are prepared by the team leads and are delivered to the project
manager as an input for the project status report. The team status report may be reviewed in regular team
review with the Project Manager or provided in a predefined format. Project status report , using the
project status report template. The project status report is created weekly, based on the input from
individual teams and additional information like issues list, risk list, etc. Executive status report is
typically prepared on monthly or quarterly cadence and is provided to the project executive steering group.
Generally, this report re-uses the key information from the weekly project status report, expands on the
value and benefits of the program, and includes discussion of the decisions that are needed from the
executive steering group. Additionally, throughout the project, as more is known, the project
communication matrix should be reviewed and updated. The communication matrix documents the project
team’s approach to communication (including status reporting). It captures the analysis completed
as part of communications planning and serves as a tool to guide the project team throughout the project.
The purpose of this task is for the project team to plan and execute agile sprints. The project team runs the
Realize phase in sequence of sprints in which the project team follows the process outlined below. The goal
of these sprints is to incrementally and iteratively build the solution capabilities captured in the backlog,
test them and review their completion with the customer process owners (product owner in agile
terminology). During each sprint the project team conducts following activities: Sprint Planning Meeting At
the beginning of the sprint the project team runs a planning meeting during which the team (jointly with
the process owner) select the highest priority items from the backlog and conducts detailed planning for
the execution activities in the sprint. Each backlog item is further decomposed to tasks that need to be
completed during the sprint. These tasks may be configuration, coding, unit testing, data preparation,
documentation and others. These tasks are then captured in the sprint backlog and estimated to validate
the original estimates for each backlog item. As a result of this planning the team has clarity on what needs
to be completed for each backlog item included in the sprint and has confidence that the team has
sufficient capacity to complete the work. Sprint Execution Activities During the sprint the team members
execute the tasks that have been planned and the team keeps track of the progress on the team board. The
team board contains swim lanes showing the status of each backlog item and each task. Teams are
encouraged to use boards on the wall and use the post-it notes to keep visual track of their progress. The
team also regularly updates the burn-down chart that is used to track the progress of completing the
individual tasks and backlog items. The team reviews the progress on a daily basis in the daily stand-up
meeting. Daily Stand-up Meeting During the daily stand-up meeting the team members review the (a)
progress they have made since last meeting; (b) plans for activities and tasks until the next meeting; and (c)
any issues of blockers that may prevent them from completing the tasks they are working on. The daily
stand-up meeting is not a project status meeting, but rather a session designed to help the team
communicate the progress with each other. Sprint Demo Towards the end of the sprint the team conducts
the sprint demo meeting during which the team demonstrates to the business owners (product owner in
agile projects) the completed functionality. The project team seeks acceptance of the completed features.
During this meeting the business owner may request additional items to be added to the backlog (or items
to be removed from the backlog). It is recommended that the team previews the functionality with process
owners prior to this meeting. Many projects had great experience with having the business process owners
demo the completed functionality to the rest of the business users and decisions makers (instead of the
project team members). Sprint Retrospective SCRUM Master organizes and facilitates the retrospective
meeting for the team. The meeting is typically scheduled shortly after the sprint demo meeting. Purpose of
the meeting is to continuously improve the Scrum process using lessons learned from the sprint execution.
Meeting participants answer the following questions: What went well during the sprint? What do we
want to preserve? What can be improved for the next sprint and how? The team selects one or two
improvement opportunities and puts it into the backlog for the next sprint. This way the agile process gets
improved in an incremental way and remains responsive to the changing environment of the project.
SCRUM of SCRUMs Meeting is conducted to coordinate the work between different project SCRUM teams.
SCRUM of SCRUMs meetings allow teams to discuss their work, focusing especially on areas of overlap and
integration. The meeting cadence is defined for the entire project and follows the same structure. Some
teams conduct daily SCRUM of SCRUMs meeting while others consider weekly meeting sufficient. The main
driver for the meeting cadence is the level of collaboration between the individual SCRUM teams and level
of dependencies between the features built in each SCRUM team.
The purpose of this deliverable is to identify and assess other OCM relevant areas.
The purpose of this task is to understand the testing strategy, validate its alignment with the project
charter, and to identify any potential roadblocks or risks associated with functionality not working as
expected. Any deviation from expectations should be communicated to project management and project
sponsors. Procedure : Perform Assessment of Testing Strategy and Execution Capture Feedback from
Testing Team
The purpose of this task is to understand the data migration strategy, validate its alignment with the project
charter, and to identify any potential roadblocks or risks associated with data quality or availability not as
expected. Any deviation from expectations should be communicated to project management and project
sponsors. Procedure: Perform Assessment of Data Migration Strategy and Execution Capture
Feedback of Data Migration Team
The purpose of the phase closure and sign-off deliverable is to. Ensure that all required deliverables from
being upheld within projects. A Quality Gate is a checklist milestone at the end of a project phase. Prior to
moving into the next phase each project manager demonstrates that they have been compliant with the
applied to ensure quality. A Quality Gate includes the following topics in detail: Conduct regular quality
checks at defined or critical stages of the project lifecycle to assess the health of the project Ensure
project deliverables. Note(s): New additional key deliverables need to be added in the
quality gate checklist by the Project Manager to the different project types.
Once Q3 – Realize-to-Deploy has been passed successfully, the final preparation for Go-Live starts in
the Deploy Phase. The activities of the Deploy phase are displayed in the following picture.
End users are trained for the new SAP S/4HANA solution in the Application: Solution
Adoption work stream. In the Application: Design & Configuration work stream,
the implementation activities will come to an end. Integration validations ensures the required
performance. Testing (in particular regression and user acceptance testing) is taken care of in the
Application: Testing work stream. All affected custom code should have been adapted and tested in
the Realize phase already. Overall there is nothing to do in the Custom Code Extensions work
stream in the Deploy phase. In System & Data Migration , the final rehearsal of the cut-over
procedure will take place. Most importantly, this work stream processes the implementation of the
productive SAP S/4HANA which will be finalized at the Go-Live weekend. In the Technical
Architecture and Infrastructure work stream, final IT service setup activities will take place.
Transition to Operations ensures the IT operations team is ready to operate the new SAP S/4HANA
environment safely and securely. Of course the IT operations team will continue to gain real-life operational
experience in the hyper care phase after Go-Live. Quality gate “Q4 Deploy-to-Run” will
ensure that everything is ready for Go-Live. The final “Go” decision is the start for the
implementation of the productive SAP S/4HANA system with the production cutover at the Go-Live
weekend. The weeks after Go-Live are called “Hyper Care”, where the new system is further
stabilized and optimized. When finished, the Deploy phase ends. The transition project comes to an end
when finally, operational responsibility has been handed over to the production support team. Please
note : The order activities are explained in this document / road map viewer, is not necessarily the order
how they are later executed in the project! However, there can be dependencies between activities. In case
you are interested in time dependencies / relationships between activities, look into the project file
template of this road map.
The purpose of the phase initiation deliverable is to formally recognize that a new project phase starts.
The purpose of this task is to confirm resource availability for the particular phase.
The purpose of this task is to ensure the involvement of the team and other key resources and their
commitment to the project schedule. The meeting is also used to examine the approach for the specific
project phase.
This activity continues from the Realization phase. Based on the learning material which has been created
there, end user training takes place in this phase. Requirements and Constraints This activity is
recommended for all scenarios. The development of learning material has finished. Procedure Create
Training Execution Plan Execute End User Training Results The end users have been trained. They are
enabled to use the new system.
Create a training execution plan. Procedure The training execution plan is based on the results as of the
training concept, the Learning Needs Analysis, and the end user assignment. The training execution plan
should include: The scheduling of the trainings The training approach and method (as of the concept)
The assigned participants (Key / End Users) Trainer, location, date and time Required training
material (content) Training system information (access information, exercises, etc.) The training
execution plan should include all planned trainings and courses across the project phases, roles, functions
and processes for a complete overview of all training course activities.
Based on the results of the Learning Needs Analysis and the training concept, the end user training covers
the training needs for all end users. Prerequisites A training execution plan has been created before.
Procedure The training will be performed either by the customer key user in a tandem approach with SAP
trainers, or by SAP trainers only. Assumptions and/or pre-requisites for the trainings are described in the
training concept prior to the end user trainings. Examples are: Language of the trainings (i.e. English).
Maximum number of participants per training course (i.e. max. 12-15 participants). Training location of
the training course. Customer SAP training system Results As a result, end users are trained. SAP
recommends issuing participation certifications, and collecting end user feedback.
The Integration Validation activities initiated in the Realize phase, are continued and finalized in this
activity. Requirements and Constraints This activity is recommended for all scenarios. Procedure Finalize
the Integration Validation activities which have started in the Realize phase (see activity Integration
Validation ). Results As the result of this activity, integration validation has been finished.
The goal of this task is to finish IV activities before Go-Live. Prerequisites Integration Validation has started
in the Realize phase. How SAP Can Support IV is usually executed with SAP participating. The SAP TQM will
initiate the right IV support activities from SAP: Integration Validation service component: This
service component provides technical validation of core business processes with respect to non-functional
requirements, identification and addressing of technical risks prior to Go-Live and during the production
cutover including hyper-care phase. A comprehensive status of technical Go-Live readiness for core
business processes (Integration Validation matrix) is part of the service component. Business Process
Technical Validation service component: This service component ensures technical readiness of the
core business process for Go-Live. It addresses areas like data consistency, exception management,
performance and scalability, system integration, batch and volume processing. In the focus is the technical
validation of the core business processes and preparation for the subsequent efficient operation of the
software solution. Technical Performance Optimization service component: The technical
performance optimization service component improves your SAP solution by helping you to configure your
SAP S/4HANA system in an optimal way. The identification and elimination of costly performance
bottlenecks optimizes the response times and throughput of your SAP solution. All service components are
part of the “ Safeguarding the Digital Transformation ” service. See accelerator section for
details. SAP Enterprise Support Customers can order the CQC for Technical Performance Optimization
(TPO).
In preparation for the Go-Live of the transition project, it is imperative to execute an end-to-end dress
rehearsal of the cutover procedures. The rehearsal should be executed about two to four weeks prior to
the Go-Live. All changes intended to be included in the cutover should be available for the dress rehearsal.
This includes any changes that result from the testing cycles, as even a single transport could greatly impact
the duration of the process. From this point forward, changes to production should be restricted in order to
mitigate risks to the cutover procedures (system conversion only). If there is a need to make a change to
production after this point, it should be carefully evaluated and the impact should be fully understood. In
some cases, there may be a requirement to postpone the Go-Live and re-execute the dress rehearsal in
order to accommodate intrusive changes. Requirements and Constraints This activity is recommended for
all scenarios. Prerequisite for this activity is: The detailed cutover plan with owners, dependencies
and durations fully documented. The involvement of all task owners. A test
environment representative of the source and target platforms for production. The technical
cookbook, which details all of the required technical migration steps. Procedure Perform Cut-
Over Rehearsal How SAP Can Support SAP offers the provisioning of a dress rehearsal as part of the
“ Platform Execution” service – Please ask your SAP contact (e.g. SAP Client
Partner) for more information.
The goal of this task is to execute an end-to-end dress rehearsal of the cutover procedures. Procedure
Execute the cutover plan in its entirety in a non-productive environment, which is representative of the
current state and end-state of production. The dress rehearsal is intended to be used to confirm the
ownership, sequence, and duration of the cutover procedures. If significant changes to the process are
required as a result of the dress rehearsal, there may be a need to postpone the Go-Live. It is also very
critical to communicate the latest plan to related parties to ensure a smooth Production Cutover for the last
time.
Due to cost saving reasons the hardware for production is set up just in front of Go-Live (system conversion
case). In case of new implementation, it might be required to have the hardware ready by the end of the
Realize phase (see activity Cutover Preparation ). In this activity all remaining tasks required to finalize the
IT infrastructure need to be completed.
The goal of this task is the completion of the IT infrastructure setup. Procedure Proceed as follows:
Complete the setup of the IT infrastructure hosting production (e.g. hardware setup, network connections,
etc…). Correct all critical open items which have been detected in the IT infrastructure test (see activity IT
Infrastructure Setup and Test in the Realize phase for details). Finalize IT infrastructure service definition
and documentation as part of the IT service catalog (properly explaining for instance what SLAs IT is
offering to the Lines of Business for a particular IT infrastructure service). Results As a result, the IT
infrastructure is ready for hosting production.
This activity checks the customer’s ability to operate SAP HANA and SAP S/4HANA as of Go-Live.
Requirements and Constraints This activity is required for all scenarios. Procedure Operational Readiness
(System Conversion) or Operational Readiness (New
Implementation)
In case of a system conversion, the customer operated a productive SAP ERP system over a longer period of
time. Standard IT support processes (e.g. change management, event management) have been designed
and operated for SAP already. The customer knows already how to operate SAP. Only the delta to safely
operate SAP S/4HANA needs to be checked. Procedure Check if all operational aspects have been
implemented as planned (see Operations Implementation activity in the Realize phase). This covers: Roles
and Responsibilities Support Processes and Procedures Operations Support Tools Operations
Documentation Knowledge Transfer Results The IT support organization is ready to operate SAP S/4HANA
as of Go-Live. How SAP Can Support SAP offers an “ Operations Readiness ” check as part of the “ Transition
to Operations ” service. The scope covers tools for monitoring, troubleshooting, and software logistics. It
includes as well a status review of the IT Operations changes defined during the Operations Impact
Evaluation. Ideally the check is performed a couple of weeks before Go-Live. See accelerator section for
details.
In case the customer knows already how to operate SAP ERP, then again only the delta to safely operate
SAP S/4HANA needs to be checked in this task. However, in case of a new SAP customer, all core IT support
processes (as documented in the SAP Support standards) need to be checked with respect to SAP
S/4HANA. Procedure For customers who know how to operate SAP ERP already: Check if all operational
aspects have been implemented as planned (see Operations Implementation activity in the Realize
phase). This covers: Roles and Responsibilities Support Processes and Procedures Operations Support
Tools Operations Documentation Knowledge Transfer For new SAP customers: Check if all
operational aspects have been implemented as planned (see Operations Implementation
activity in the Realize phase). Check if all IT Support Processes have been implemented /
adjusted with respect to SAP S/4HANA operations (see SAP Support Standards). Check if primary CCOE
certification has been gained. How SAP Can Support SAP offers an “ Operations Readiness ”
check as part of the “ Transition to Operations ” service. The scope covers tools for
monitoring, troubleshooting, and software logistics. It includes as well a status review of the IT Operations
changes defined during the Operations Impact Evaluation. Ideally the check is performed a couple of weeks
before Go-Live. See accelerator section for details. For new SAP customers, SAP offers additional expertise
and help to check and ensure operational readiness before Go-Live. See also the Organizational and
Production Support Readiness Check as part of OCM in this phase. Please contact SAP for a
tailored offering in case you need support.
work defined in the project scope statement. Management plans developed during the project preparation
phase guide the approach to management, execution, and control of project activities. The project
manager is responsible for ensuring that the management plans are applied at the appropriate level of
control.
The purpose of this task is to update the project management plan and the subsidiary plans based on the
changes agreed during the projects change management process.
The purpose of this activity is to assure that the project is executed according to what was agreed to in
project charter, scope statement and project management plan.
The purpose of this task is to capture and manage project issues and risks and changes related to those e.g.
changes of project scope, timeline, costs etc.
This is the final Quality Gate in front of the cutover. The purpose of this Quality Gate is to ensure that the
project is ready for Go-Live (“Go / No-Go decision”). A Quality Gate is a checklist milestone.
Prior to Go-Live each project manager demonstrates that they have been compliant with the mandatory
deliverables associated with a methodology while ensuring best practice standards have been applied to
ensure quality. A Quality Gate looks at the following topics in detail: Conduct regular quality checks at
defined or critical stages of the project lifecycle to assess the health of the project. Ensure that all key
deliverables and actions of the gate have been completed in compliance with recommended practices and
to the customer’s satisfaction. Enable project management to continuously communicate the
process and build quality directly into the project. Provide a tool to effectively manage project
expectations and monitor customer satisfaction. The deliverables assessed at each quality gate will be
performed using the quality gate checklist with defined expectations to the maturity of particular project
deliverables. Note: New additional key deliverables need to be added in the quality gate checklist by the
Project Manager to the different project types.
The purpose of this task is to make sure that project stakeholders are aware of status and progress of the
project including potential disturbances due to existing risks and issues.
The purpose of this deliverable is to formally close the release and prepare for next release and/or sprint
planning meeting.
The purpose of this task is to 'groom' the product backlog. Product Owner Team needs to detail
the user stories to ready them for next release/sprint planning meeting. The stories need to meet definition
of Ready for Build so they are understood by the SCRUM team and can be estimated during the sprint
planning meeting.
The purpose of this task is to conduct retrospective meetings with the project team to identify potential
The purpose of this task is to update the Release and Sprint Plan according to changed priorities and focus
of the team. It is accountability of Product Owner to maintain the Release and Sprint plan and keep it
current during the project.
The purpose of this deliverable is to perform the cutover to the production software and go live.
Requirements and Constraints At this point, the organizational, business, functional, technical, and system
aspects of the project are ready to be used in production. This activity is mandatory for all scenarios. The
steps being performed are of course scenario specific. Procedure Convert Productive System
(System Conversion) or Production Cutover (New Implementation) or Production
Cutover (Landscape Transformation) Results After completion of this activity, the productive SAP S/4HANA
system is available for the end users. How SAP Can Support The “ SAP Going Live Support
” service component is part of the “ Safeguarding the Digital Transformation ” service.
It is based on a standardized method to support critical situations during production cutover. SAP experts
contribute their knowledge and expertise remotely to minimize the risks for the Go-Live. Sudden slowly
running applications in the new productive SAP S/4HANA system are addressed by a Technical
Performance Optimization service component (SAP Enterprise Support order the CQC for
Technica lPerformance Optimization (TPO) instead): The technical performance optimization service
component improves your SAP solution by helping you to configure your SAP S/4HANA system in an
optimal way. The identification and elimination of costly performance bottlenecks optimizes the response
times and throughput of your SAP solution. SAP Enterprise Support customers can request a Continuous
Quality Check (CQC) for “Going-Live Support”. Ask your SAP Enterprise Support
Adviser for details.
The goal of this task is to convert the productive system. Procedure Proceed as follows: Request
Restore Point of Production System Prior to Final Cutover Activities Execute the conversion of the
production system following the tasks defined in the cutover plan. Document the actual duration
of each step to support future projects. Capture any variances to the plan along with decision
maker who approved the change. The cutover manager(s) should proactively notify task owners
of upcoming tasks, to ensure their availability. Regularly communicate status to stakeholders.
After conversion has finished (including mandatory post-processing activities), the system has to be
tested and validated Obtain system sign-off Results The customer approval (sign-off) documents
the agreement with the stakeholders that cutover tasks have been executed, the go-live acceptance criteria
have been met, and the cutover is finished. It indicates formal approval to end the cutover activities. At this
point, the solution is live in production. How SAP Can Support SAP offers the PRD conversion as part of the
“Platform Execution” service. Please ask your SAP contact (e.g. SAP Client Partner) for more
information. The setup of the Fiori platform can be supported as well (scope option “SAP Fiori
Platform Setup” ).
The goal of this task is to cut over production. Procedure Execute the cutover following the tasks defined
in the cutover plan. This includes the final production data load. Document the actual duration of each
step to support future projects. Capture any variances to the plan along with decision maker who
approved the change. The cutover manager(s) should proactively notify task owners of upcoming tasks, to
ensure their availability. Regularly communicate status to stakeholders. After the data is loaded,
testing and data reconciliation must be completed. Obtain system sign-off Results The customer
approval (sign-off) documents the agreement with the stakeholders that cutover tasks have been executed,
the go-live acceptance criteria have been met, and the cutover is finished. It indicates formal approval to
end the cutover activities. At this point, the solution is live How SAP Can Support SAP offers the PRD
installation as part of the “ Platform Execution ” service. Please ask your SAP contact
(e.g. SAP Client Partner) for more information.
In accordance with the productive cut-over plan, the migration and upgrade process begins. Procedure The
production cutover procedure depends on the landscape transformation scenario. For Client Transfer,
proceed as follows: A copy of the SAP LT Client Transfer package is created from the dress rehearsal to
take over all the setngs from the previous package. Examples of these setngs include table and field
mappings, exclusion of table entries, domains, rules, and mapping values. It is important to remember that
a lot of the SAP LT Client Transfer activities can be executed well in advance of the actual downtime, which
gives customers some more flexibility. All users beside the technical migration and upgrade team are
locked, when the downtime period starts. This also includes stopping all interfaces, as defined. Reschedule
any batch jobs that are scheduled for the downtime period. Customers need to ensure that they can
restore the system status of the S/4HANA receiver system to the status at the start of the downtime period,
in case the migration fails. The system setngs of the receiver system are changed as required. Customers
need to consider the following: Archive logging Dropping indexes Parameterization of the
database The required delta customizing need to be identified during the various project phases and
implemented in the target system. Continuation of the migration and upgrade process, in accordance
with the Productive Migration Plan. Monitoring of the migration and upgrade process in SAP LT Client
Transfer - If problems occur during the migration and upgrade process that a customer cannot resolve
(problems that would result in an inconsistent receiver system), the original receiver system state must be
restored. Once the migration upgrade is complete, the log files in SAP LT Client Transfer should be
checked. Customers can find further information about the productive migration in the ‘Client
Transfer’ Product Road Map of SAP Landscape Transformation software, Refer to phase ‘5
Productive Migration and Upgrade’. For System Merge, proceed as follows: A copy of the SAP
LT system merge package is created from the last test cycle to take over all the setngs from the previous
package. It is important to remember that a lot of the SAP LT system merge activities can be executed
well in advance of the actual downtime, which gives customers some more flexibility. All users beside the
technical migration and upgrade team are locked when the downtime period starts. This also includes
stopping all interfaces as defined. Reschedule any batch jobs that are scheduled for the downtime period.
Customers need to ensure that they can restore the system status of the S/4HANA receiver system to
the status at the start of the downtime period in case the migration fails. The system setngs of the
receiver system are changed as required, customers need to consider the following: Backup,
switch log to overwrite mode Parameterization of the database The required delta
Customizing needs to be identified during the various project phases and implemented in the target
system. Continuation of the migration and upgrade process in accordance with the productive
migration plan Monitoring the migration and upgrade process from transfer (SAP LT) side and from
system side. If problems occur during the migration and upgrade process that a customer cannot
resolve(problems that would result in an inconsistent receiver system), the original receiver state must be
restored. Once the migration is complete, the log files in SAP LT system merge should be checked.
Customers can find more information about the productive migration in the ‘Client
Transfer’ product road map of SAP Landscape Transformation software, see phase‘5
After the Go-Live it is important to verify how the new workload behaves as opposed to the old system,
and to use the Hyper Care phase in particular to improve system performance. Workload analysis With the
analysis of the current hardware consumption, the load distribution across the different applications and
task types, as well as average response times you establish a kind of benchmark to measure the success of
the conversion. As response times are very sensitive KPIs it makes sense to capture its data over a long
period of time, ideally more than six months (this can be established by collecting monitoring data long
term in SAP Solution Manager). Health check and scalability analysis The scalability analysis contains
system health checks (DB buffer, wait time, etc.) as well as the identification of statements that cause
bottleneck situations. Sizing verification Customers should monitor the technical KPIs in terms of CPU and
memory consumption to assess the actual usage vs. the deployed hardware. Requirements and Constraints
This activity is required for all scenarios. Precondition is that the Monitoring Infrastructure (SAP Solution
Manager preferred) is already set up. Procedure Monitor Resource Consumption Analyze Workload
Check System Scalability Run Going-Live Service (Verification Session) Security Activities All the
required Security Activities have to be finalized.The Status Check is supported by: Go-Live Checks SAP
Go-Live Support The Security Procedures have to be established to stay“Clean”. These
procedures can be achieved by: Security Monitoring Security Incident Management How SAP Can
Support SAP can join the hyper care phase by continuing the ” SAP Going Live Support ” and
the “ Technical Performance Optimization ” service components, which are part of the
“ Safeguarding ” service. With the monitoring of the core business processes and the system
environment of the new SAP S/4HANA system, SAP experts contribute their knowledge remotely to
minimize the risk for instable operations and performance. SAP experts will also work on open issues and
can address them to the SAP development directly if necessary. To re-evaluate and to continue the process
improvement activities you have started in the Explore phase of the project (see activity Data Volume
Design, task Get Transparency on Open Business Documents), SAP offers a “Business Process
Improvement” service component as part of the “Safeguarding the Digital
Transformation” service. The service component typically starts with a remote Business Process
Analysis in order to learn fact based about the current status quo, and to have a baseline measurement
from where to start the improvement activities. Selected out-of-the-box key figures, which support the
respective anticipated target, are activated in the customer SAP Solution Manager and Business Process
Analytics is used for root cause analysis. Several root cause analysis and tool empowering sessions are
conducted with the customer process experts from business and IT. Management UIs (Dependency
Diagrams, Progress Management Board, Business Process Operations Dashboards) are configured in SAP
Solution Manager based on Business Process Analytics data in order to track the progress made.
The objective of this task is to identify the resource consumption after Go-Live and to manage it
permanently to answer questions like: What is the current workload profile? Is the resource
consumption in a reasonable ratio to the business logic and value? Is the resource consumption stable or
does it increase even though there is no additional functional or business load in the system? Procedure
The following KPIs are to be measured: Physical CPU consumption over time (SAP application and DB
server): [average per month / week / day] Workload profile (SAP application and DB server): [peaks,
averages, load balancing] Consider seasonal fluctuations: [e.g. period end closing] Memory
consumption (SAP application and DB server): [buffer setngs and usage
Workload analysis first has the goal to provide information which applications, transactions, jobs, processes
dominate the workload consumption. Then, in the second step, candidates for performance optimization
will get identified and prioritized. Procedure You measure the following KPIs Resource consumption per
task type: [#steps * (CPU time + DB time)] Resource consumption per transaction/process:[#steps *
(CPU time + DB time)] Duration of background jobs: [seconds] Response time per dialog transaction:
[average time, time distribution] Most expensive SQL statements : [#executions, elapse time] Create a
list of the top consumers and the most important SQL statements. Decide which item should be checked
and further optimized. How SAP Can Support SAP can support both the code analysis and the optimization.
A system scalability check has the goal to understand the top resource consumers with respect to:
Adequacy and optimization potential on technical level Adequacy and optimization potential on service
level Adequacy and optimization potential on business level The scalability check focuses on identifying the
resources that form the bottleneck for a further increase of the load. It helps to guarantee that the system
is not laid out for irrelevant tasks and to identify the load drivers from the business. Procedure Proceed as
follows: Sort the list of top consumers by the consumption of the resource that is the largest bottleneck.
Check, starting with the largest resource consumer: Whether it is possible to reduce the resource
consumption by optimizing the database or the coding that is responsible for the resource consumption.
Whether it is possible to avoid the bottleneck by optimizing load balancing and scheduling of services.
Whether the business value obtained from the service justifies the resource consumption. As a result, the
load drivers on your system are thoroughly understood. The top resource consumers are well optimized
and their business relevance is known. Optimal support for the business can be provided, even for
changing business requirements. Knowing the load drivers for the top resource consumers allows to predict
the effect of changing business beforehand.
Depending on the project scope, you have either ordered the analysis session of a Going-Live OS/DB
Migration Check, or a Going-Live Functional Upgrade Check, or a SAP Going-Live Check for Implementation
(see activity Integration Validation in the Realize phase for details). Four to six weeks after
Go-Live the verification session of this service should take place. This session analyzes the converted
system, and provides corrective measures to avoid potential bottlenecks. See accelerator section for
details. Procedure Proceed as follows: SAP runs the Going-Live Check. Follow up and solve all
yellow and red issues identified in the service report. How SAP Can Support SAP delivers the SAP Going-Live
Check ( verification session) in this task.
The purpose of EU training is to ensure that end users have adopted the solution, knowledge resources are
maintained, and responses to the end-user acceptance survey are positive
This purpose of this task is to adapt available training material and make it suitable for End User training
This task executes the delivery of EU training as well as capturing feedback on both the training session and
the trainer.
The purpose of this task is to capture feedback on both the training session and the trainer delivering the
material.
This task checks how prepared the people in the organization are with regards to the identified changes
and received EU training.
Once the hyper care phase ends it is important to fully enable the regular support organization at customer
site to safely and securely operate the new SAP system. This includes (but is not limited to): The
finalization of system documentation The finalization of operational procedures as part of the
operations handbook The check of the customer support organization. Procedure Resolve and Close
Open Issues Handover Operations Responsibility How SAP Can Support SAP supports this activity with the
“ Handover to Support ” scope option as part of the Build Execution service. The Handover
to Support scope option: Evaluates process management framework quality like
documentation, configuration, testing validation, or authorization management Evaluates process
management knowledge transfer and IT support team capabilities for future maintenance Evaluates
handover protocol procedures Builds handover conditions, recommendations, and supports
customer adoption activities The Handover to Support scope option builds on top of deliverables
created in the Build Design and Build Execution services. Please ask your SAP contact (e.g. SAP Client
Partner) for more information.
The purpose of this task is to achieve a closure of all open project issues which is a prerequisite for the final
project closure. Procedure The purpose of this task is to achieve a closure of all open project issues. In case
this is not possible within acceptable time, prepare for an agreement with the IT operations team to take
responsibility to resolve and close the issue. Hand over the current analysis and correction state to the IT
operations team.
In this task, operations responsibility is formally handed over from the team who operated the new SAP
S/4HANA system (usually a mix of resources from the project team and IT support) to the IT support
operations team. Prerequisites System documentation is complete and available.
Operations procedures are fully documented in the operations handbook. The IT support
operations team is set up and trained to safely and securely operate and troubleshoot the new SAP
S/4HANA system. The top issues and priority incidents identified during hyper care, are either
solved, or there is a documented work around and move-forward plan available. Procedure Hand
over operations responsibility to the IT support operations team.
The purpose of the phase closure and sign-off deliverable is to: Ensure that all required
deliverables from this phase and the project are complete and accurate, and close any outstanding issues
Identify lessons learned during the phase to prepare for formal phase closure Capture customer
feedback and potential Customer References
being upheld within our projects. A Quality Gate is a checklist milestone at the end of a project phase. Prior
to moving into the next phase each project manager must demonstrate that they have complied with the
applied to ensure quality. A Quality Gate looks at the following topics in detail: Conduct regular quality
checks at defined or critical stages of the project lifecycle to assess the health of the project. Ensure
project deliverables. Note: New additional key deliverables need to be added in the quality gate checklist
The purpose of this task is to achieve a closure of all open project issues which is a prerequisite for the final
project closure.
The purpose of this task is to document the results of the project, both regarding achieved objectives,
deliverables as well as adherence to schedule, costs and delivered value.
The purpose of this activity is to formally close the project by obtaining customer signatures on dedicated
deliverables/documents e.g. Project Quality Gate, Project Closeout Report.
The transition project has ended with the Deploy phase. The activities of the Run phase are displayed in
the following picture. In the Run phase, the aim is to establish a safe and efficient operations of the newly
created solution. This includes the operations platform, core IT support processes, the setup / fine tune of
new / additional operations tools, and the enablement of the operational support team. Moreover, a
continuous operations improvement should be established to improve IT operations based on newly gained
experience. In addition, this is the right time to plan for further innovations which could be implemented
according to the overall implementation strategy, which has been created in the Discover phase of the
project (or separately, as part of a business transformation work stream). The implementation strategy can
now be reviewed and enriched based on system usage experience which has been gained in the first weeks
after Go-Live.
With project end, the customer support organization is responsible to operate the new solution. The aim of
this activity is to ensure efficient daily operations. This affects IT support people, IT support processes, and
tools. In addition, the customer support organization should seek for continuous improvement.
Requirements and Constraints Go-Live and hyper care has finished successfully. The customer support
organization is responsible for operating the new solution. Procedure IT is in charge to ensure business
continuity on the one hand. On the other hand, IT needs to enable business change at the required speed
and with no disruption. IT support should not be organized in a way to only “keep the lights
on” – instead, safe and efficient IT support guarantees business continuity AND continuous
improvement. Both aspects are covered in this activity. Safely and Efficiently Operate the new Solution
Continuously Optimize IT Operations Note that this activity deals with the organization of IT support
and improvement. Business improvement will be covered in the activity Improve and Innovate Solution .
The purpose of this task is to safely and efficiently ensure business continuity and the operability of the
solution. Operability is the ability to maintain IT systems in a functioning and operating condition,
guaranteeing systems availability and required performance levels to support the execution of the
enterprise’s business operations. Procedure Operating an SAP solution can easily fill an own road
map. Therefore, this task can only list the most important aspects to consider: Install and configure the
solution operation platform if not already done. In case you have used a cloud image for your
implementation project, now it is time to set up and configure SAP Solution Manager 7.2 on premise to
support most of your core IT support processes. Although there are many partner products in the market,
SAP recommends to use SAP Solution Manager If not yet done configure core IT support processes like:
Incident and Problem Management Change Management SAP has
documented IT support standards which describe these support processes in the SAP context. See
accelerator section for details. In addition, in case of SAP Enterprise Support, you COE needs to be
“Primary Certified”. Configure efficient system management - SAP has developed a
concept called “Run SAP like a Factory”. Core elements are: Application
Operations Business Process Operations See SAP Support Portal (accelerator section) for
getng an overview about all capabilities including offline demos. Operations Control Center (OCC)
One approach to efficiently operate IT operations is to implement an OCC, which collects all critical
alerts centrally, and pro-actively reacts before issues turn into problems. The OCC is tightly integrated with
the Mission Control Center (MCC) at SAP. Based on the alert information, the OCC can establish a
continuous improvement process to avoid critical alerts in future. This could feed into the next task
Continuously Optimize IT Operations. How SAP Can Support SAP has a large set of offerings to SAP
Premium Support customers with respect to both configuration and enablement of operations functionality
in SAP Solution Manager. For example SAP can configure Application Operations in your environment, and
trains your IT support experts in daily using the tools. Ask your TQM for more details. In case you want SAP
to execute IT operational tasks, then SAP Application Management Services can help you. SAP Application
Management Services act as your extended team, run your SAP solutions, provide an end-to-end
application management to you for all their specific SAP solutions. SAP Applications Management offers
services in 3 value generating layers. The first layer is the basis for application support, monitoring and
change management, which is provided through: Incident Management & Request Fulfillment
Change Management Problem Management and Reactive Event Management based on monitoring
alerting mechanisms Security Operations all under guaranteed SLA’s and with 24/7 support
available in multiple languages. In effect of these, customers will see an increased solution stability and
reduced number of incidents. At the same time customers do have permanent service available to address
required changes and execution of service requests. In case customer wants to hand-over the complete
system landscape operation to SAP, then SAP HANA Enterprise Cloud would be the applicable offer. SAP
HANA Enterprise Cloud is a fully scalable and secure private cloud offering available only from SAP. It gives
you the full power of SAP solutions in a private, managed cloud environment that is supported by the most
knowledgeable resources
The purpose of this task isintothe industry –
continuously improvefrom infrastructure
IT operations (e.g. to
viaapplications.
automation,See accelerator
or switching from a
re-active to a pro-active operations approach). Procedure This task can only name some out of many
improvement options: Advanced Customer Center of Expertise (aCCOE) An alternative approach to
improve IT operations is to set up an aCCOE. The advanced certification for Customer COEs covers the full
spectrum of SAP solution operations. Based on the SAP standards for solution operations and the Run SAP
methodology, a team with advanced certification has integrated quality management in place, bringing
transparency to the challenges and issues faced by the organization as a whole. This is paramount for
mission critical operations. Visibility, alignment, and a common understanding of those top issues are
enabled through the center's ability to maintain a single source of truth - one central area where
everything is tracked and from which all information flows. See accelerator section for details.
Regular assessments of IT operations Run regular assessments and review on IT operations efficiency.
How SAP Can Support SAP supports a tailored creation of an OCC for SAP Premium Engagement customers,
and the advanced certification for customer COE’s. Contact your TQM for details. The regular
assessment and review of IT operations efficiency is offered by SAP Application Management Services to all
customers. Moreover, SAP offers to run the Operations Control Center for you (Managed OCC).
The aim of this activity is to further improve and simplify your new solution to realize maximum benefit. On
the one hand, this requires the periodic update, by implementing feature and support packs, to bring the
latest innovations from SAP into your solution. On the other hand, a new planning cycle needs to be
initiated together with your peers from the business units, to identify innovations which are mostly
required. Procedure Periodically update your SAP system Initiate a new innovation cycle
The goal of this task is to keep the SAP current, by implementing innovations and corrections from SAP in a
timely manner. This is handled by an efficient maintenance management process. Procedure Implement a
maintenance management process for your SAP system, and implement feature and support packs from
SAP in a timely manner: For SAP S/4HANA on premise edition, SAP is currently delivering 1 new key
release per year, and some successive Feature Pack Stacks (FPS). Then comes the next key release, followed
by several FPSs. An FPS may contain non-disruptive, non-mandatory features. Support Pack Stacks (SPS)
are shipped for a given release once the N+1 release is made available, until the end of the mainstream
maintenance. Please note: The maintenance of SAP S/4HANA will be handled in a dedicated road map.
How SAP Can Support Please make yourself familiar with the SAP Release and Maintenance Strategy
(accelerator section). SAP offers the planning and execution of SAP maintenance via Proactive Solution
Maintenance as part of SAP Application Management Services. See accelerator section for details.
The goal of this task is to close the loop, but initiating a new innovation cycle. Procedure Innovation is not a
one-step-process, but a continuous journey. Your SAP system runs stable, and is updated with latest
innovations from SAP. Now it is time to review the innovation and implementation strategy you have
created at the beginning of the project. Business requirements may have changed meanwhile, and your
company may have gained experience on what is possible with the new solutions from SAP. Adjust your
innovation strategy accordingly, and start the next round by entering the Design phase of the next
innovation project. How SAP Can Support There are multiple options how SAP can support your innovation
and improvement journey, for instance: SAP offers “ Business Transformation Services ”, to
create and update your transformation and innovation journey. They can help align your people, processes,
and technology to your corporate goals using industry-specific best practices and expertise. Take advantage
of proven innovation management methodology and services, quickly deploy the latest digital business
technologies, and keep your company on the very cutng edge. Core areas are business innovation, digital
transformation, and value optimization. Business Process Improvement is a methodology to identify
weaknesses in existing business processes in order to make them more efficient and effective. The
methodology is supported by Business Process Analytics, which is a problem oriented tool in SAP Solution
Manager providing fast root cause analysis capabilities. Moreover, Business Process Analytics monitors how
the current solution is being used. Business Improvement offering by SAP Application Management
Services is a collaboration between SAP and you. An SAP Solution Architect will work with you to define
service plans, execution timelines and effort estimations. This also includes regular proactive planning
sessions for improvement driven by business demand. Finally, SAP will be responsible of the execution of
the agreed business improvement, while working in conjunction with the Change/Release Manager to
inject new solutions or enhancements into your SAP solution. See accelerator section for details on all
items listed above. You can also contact your SAP lead (e.g. Client Partner, TQM) for more information.
Duration Start Finish PredecessorOutline Level
632 days 03 September 2018 08:00 02 February 2021 17:00 1
70 days 03 September 2018 08:00 07 December 2018 17:00 2

60 days 03 September 2018 08:00 23 November 2018 17:00 3
20 days 03 September 2018 08:00 28 September 2018 17:00 4
40 days 01 October 2018 08:00 23 November 2018 17:00 4 4

5 days 01 October 2018 08:00 05 October 2018 17:00 4 4
50 days 01 October 2018 08:00 07 December 2018 17:00 3

10 days 12 November 2018 08:00 23 November 2018 17:00 12 4
10 days 26 November 2018 08:00 07 December 2018 17:00 13 4

30 days 22 October 2018 08:00 30 November 2018 17:00 3

93 days 10 December 2018 08:00 17 April 2019 17:00 2
13 days 25 December 2018 08:00 10 January 2019 17:00 3
1 day 25 December 2018 08:00 25 December 2018 17:00 72 4
1 day 10 January 2019 08:00 10 January 2019 17:00 72;46 4

5 days 27 December 2018 08:00 02 January 2019 17:00 21;72 4
5 days 03 January 2019 08:00 09 January 2019 17:00 22 4

90 days 10 December 2018 08:00 12 April 2019 17:00 14 4
5 days 25 December 2018 08:00 31 December 2018 17:00 72 4


60 days 22 January 2019 08:00 15 April 2019 17:00 26 3
60 days 22 January 2019 08:00 15 April 2019 17:00 31;30;29;284

30 days 25 December 2018 08:00 04 February 2019 17:00 3
20 days 25 December 2018 08:00 21 January 2019 17:00 72 4
10 days 22 January 2019 08:00 04 February 2019 17:00 42 4


5 days 10 December 2018 08:00 14 December 2018 17:00 3


1 day 18 December 2018 08:00 18 December 2018 17:00 3

1 day 19 December 2018 08:00 19 December 2018 17:00 67;66;65;644




1 day 11 January 2019 08:00 11 January 2019 17:00 19;20;22;234
1 day 16 April 2019 08:00 16 April 2019 17:00 26;40;42;464
1 day 26 December 2018 08:00 26 December 2018 17:00 47;54;58;684

1 day 17 April 2019 08:00 17 April 2019 17:00 91;90;89 4
239 days 18 April 2019 08:00 17 March 2020 17:00 2
3 days 18 April 2019 08:00 22 April 2019 17:00 3
1 day 18 April 2019 08:00 18 April 2019 17:00 92 4
1 day 19 April 2019 08:00 19 April 2019 17:00 95 4
1 day 22 April 2019 08:00 22 April 2019 17:00 96 4
20 days 18 April 2019 08:00 15 May 2019 17:00 3

20 days 18 April 2019 08:00 15 May 2019 17:00 92 4
35 days 25 April 2019 08:00 12 June 2019 17:00 3
20 days 16 May 2019 08:00 12 June 2019 17:00 160 4
1 day 25 April 2019 08:00 25 April 2019 17:00 162 4

5 days 26 April 2019 08:00 02 May 2019 17:00 102 4
0 days 12 June 2019 17:00 12 June 2019 17:00 100 3
30 days 13 June 2019 08:00 24 July 2019 17:00 3
10 days 13 June 2019 08:00 26 June 2019 17:00 100 4

20 days 27 June 2019 08:00 24 July 2019 17:00 106 4
30 days 25 July 2019 08:00 04 September 2019 17:00 3
30 days 25 July 2019 08:00 04 September 2019 17:00 107 4

5 days 05 September 2019 08:00 11 September 2019 17:00 109 4

30 days 26 September 2019 08:00 06 November 2019 17:00 3
30 days 26 September 2019 08:00 06 November 2019 17:00 113;115 4

1 day 07 November 2019 08:00 07 November 2019 17:00 3
1 day 07 November 2019 08:00 07 November 2019 17:00 117 4
10 days 08 November 2019 08:00 21 November 2019 17:00 3

30 days 05 September 2019 08:00 16 October 2019 17:00 3

20 days 19 September 2019 08:00 16 October 2019 17:00 123 4

0 days 25 September 2019 17:00 25 September 2019 17:00 113;115 4
5 days 18 April 2019 08:00 24 April 2019 17:00 3

5 days 18 April 2019 08:00 24 April 2019 17:00 92 4
166 days 18 April 2019 08:00 05 December 2019 17:00 3
5 days 25 April 2019 08:00 01 May 2019 17:00 128 4

20 days 08 November 2019 08:00 05 December 2019 17:00 92;119 4
10 days 18 April 2019 08:00 01 May 2019 17:00 92 4
30 days 08 November 2019 08:00 19 December 2019 17:00 3


25 days 18 April 2019 08:00 22 May 2019 17:00 3
5 days 18 April 2019 08:00 24 April 2019 17:00 30;92 4
20 days 25 April 2019 08:00 22 May 2019 17:00 139;42 4

10 days 08 November 2019 08:00 21 November 2019 17:00 92;119 4





40 days 08 November 2019 08:00 02 January 2020 17:00 3


25 days 18 April 2019 08:00 22 May 2019 17:00 3

20 days 18 April 2019 08:00 15 May 2019 17:00 92 4
5 days 16 May 2019 08:00 22 May 2019 17:00 160 4
5 days 18 April 2019 08:00 24 April 2019 17:00 92 4
90 days 05 September 2019 08:00 08 January 2020 17:00 3

20 days 05 September 2019 08:00 02 October 2019 17:00 109 4


60 days 05 September 2019 08:00 27 November 2019 17:00 109 4


10 days 20 December 2019 08:00 02 January 2020 17:00 121;178;32 4


70 days 08 November 2019 08:00 13 February 2020 17:00 3
10 days 31 January 2020 08:00 13 February 2020 17:00 180;183;18 4

20 days 31 January 2020 08:00 27 February 2020 17:00 3
20 days 31 January 2020 08:00 27 February 2020 17:00 182;183;18 4

10 days 28 February 2020 08:00 12 March 2020 17:00 3
10 days 28 February 2020 08:00 12 March 2020 17:00 121;31;186 4
5 days 23 April 2019 08:00 29 April 2019 17:00 3
5 days 23 April 2019 08:00 29 April 2019 17:00 94 4
5 days 23 April 2019 08:00 29 April 2019 17:00 94 4

5 days 23 April 2019 08:00 29 April 2019 17:00 94 4
5 days 23 April 2019 08:00 29 April 2019 17:00 94 4
5 days 23 April 2019 08:00 29 April 2019 17:00 94 4
5 days 23 April 2019 08:00 29 April 2019 17:00 94 4


231 days 30 April 2019 08:00 17 March 2020 17:00 3
1 day 13 March 2020 08:00 13 March 2020 17:00 119;123;1334

1 day 13 March 2020 08:00 13 March 2020 17:00 119;123;1334
1 day 30 April 2019 08:00 30 April 2019 17:00 192 4
1 day 04 December 2019 08:00 04 December 2019 17:00 189;196 4
1 day 16 March 2020 08:00 16 March 2020 17:00 206 4

1 day 17 March 2020 08:00 17 March 2020 17:00 209;208;20 4
145 days 18 March 2020 08:00 06 October 2020 17:00 2
4 days 18 March 2020 08:00 23 March 2020 17:00 3
2 days 18 March 2020 08:00 19 March 2020 17:00 210 4
1 day 20 March 2020 08:00 20 March 2020 17:00 213 4
1 day 23 March 2020 08:00 23 March 2020 17:00 214 4
6 days 24 March 2020 08:00 31 March 2020 17:00 3

3 days 24 March 2020 08:00 26 March 2020 17:00 215 4
3 days 27 March 2020 08:00 31 March 2020 17:00 217 4
30 days 18 March 2020 08:00 28 April 2020 17:00 3

30 days 18 March 2020 08:00 28 April 2020 17:00 210;99;121 4
20 days 18 March 2020 08:00 14 April 2020 17:00 121;210 4

5 days 27 March 2020 08:00 02 April 2020 17:00 3
5 days 27 March 2020 08:00 02 April 2020 17:00 217 4
5 days 03 April 2020 08:00 09 April 2020 17:00 3

1 day 03 April 2020 08:00 03 April 2020 17:00 223 4
1 day 06 April 2020 08:00 06 April 2020 17:00 225 4

1 day 07 April 2020 08:00 07 April 2020 17:00 226 4
1 day 08 April 2020 08:00 08 April 2020 17:00 227 4
1 day 09 April 2020 08:00 09 April 2020 17:00 228 4
0 days 09 April 2020 17:00 09 April 2020 17:00 224 3
5 days 10 April 2020 08:00 16 April 2020 17:00 3
5 days 10 April 2020 08:00 16 April 2020 17:00 224 4

50 days 17 April 2020 08:00 25 June 2020 17:00 3
50 days 17 April 2020 08:00 25 June 2020 17:00 232 4
15 days 26 June 2020 08:00 16 July 2020 17:00 3
15 days 26 June 2020 08:00 16 July 2020 17:00 234 4
15 days 17 July 2020 08:00 06 August 2020 17:00 3
15 days 17 July 2020 08:00 06 August 2020 17:00 236 4

5 days 07 August 2020 08:00 13 August 2020 17:00 3
5 days 07 August 2020 08:00 13 August 2020 17:00 238 4
15 days 14 August 2020 08:00 03 September 2020 17:00 3
15 days 14 August 2020 08:00 03 September 2020 17:00 240 4
5 days 04 September 2020 08:00 10 September 2020 17:00 240;242;23 4
0 days 25 June 2020 17:00 25 June 2020 17:00 234 3

20 days 09 April 2020 17:00 07 May 2020 17:00 3
20 days 10 April 2020 08:00 07 May 2020 17:00 140;224 4

20 days 10 April 2020 08:00 07 May 2020 17:00 224;121 4
20 days 10 April 2020 08:00 07 May 2020 17:00 224;124 4

0 days 09 April 2020 17:00 09 April 2020 17:00 224;121 4
1 day 11 September 2020 08:00 11 September 2020 17:00 234;236;23 4
1 day 14 September 2020 08:00 14 September 2020 17:00 252 4
20 days 18 March 2020 08:00 14 April 2020 17:00 3

20 days 18 March 2020 08:00 14 April 2020 17:00 128;210 4
20 days 18 March 2020 08:00 14 April 2020 17:00 3
10 days 18 March 2020 08:00 31 March 2020 17:00 133;210 4
10 days 01 April 2020 08:00 14 April 2020 17:00 258 4

45 days 18 March 2020 08:00 19 May 2020 17:00 135;210 3
45 days 18 March 2020 08:00 19 May 2020 17:00 3

10 days 18 March 2020 08:00 31 March 2020 17:00 121;210 4
30 days 01 April 2020 08:00 12 May 2020 17:00 262 4

5 days 13 May 2020 08:00 19 May 2020 17:00 263 4
35 days 18 March 2020 08:00 05 May 2020 17:00 3

30 days 18 March 2020 08:00 28 April 2020 17:00 137;210 4
5 days 29 April 2020 08:00 05 May 2020 17:00 266 4

20 days 29 April 2020 08:00 26 May 2020 17:00 3
20 days 29 April 2020 08:00 26 May 2020 17:00 266;144;12 4
40 days 27 May 2020 08:00 21 July 2020 17:00 3

40 days 27 May 2020 08:00 21 July 2020 17:00 269 4
40 days 18 March 2020 08:00 12 May 2020 17:00 3
20 days 18 March 2020 08:00 14 April 2020 17:00 121;155;21 4

20 days 15 April 2020 08:00 12 May 2020 17:00 273 4
10 days 18 March 2020 08:00 31 March 2020 17:00 3

5 days 18 March 2020 08:00 24 March 2020 17:00 172;210 4
10 days 18 March 2020 08:00 31 March 2020 17:00 173;210 4

45 days 25 March 2020 08:00 26 May 2020 17:00 3
40 days 25 March 2020 08:00 19 May 2020 17:00 276;169 4
40 days 01 April 2020 08:00 26 May 2020 17:00 277;161 4
40 days 01 April 2020 08:00 26 May 2020 17:00 170;275 4
40 days 01 April 2020 08:00 26 May 2020 17:00 170;275 4
40 days 01 April 2020 08:00 26 May 2020 17:00 170;275 4
13 days 15 September 2020 08:00 01 October 2020 17:00 3

10 days 18 September 2020 08:00 01 October 2020 17:00 294;290;27 4


30 days 26 June 2020 08:00 06 August 2020 17:00 3
20 days 26 June 2020 08:00 23 July 2020 17:00 233;183;18 4

10 days 24 July 2020 08:00 06 August 2020 17:00 184;293 4
30 days 18 March 2020 08:00 28 April 2020 17:00 3

10 days 18 March 2020 08:00 31 March 2020 17:00 188;121;21 4
10 days 01 April 2020 08:00 14 April 2020 17:00 296 4

10 days 01 April 2020 08:00 14 April 2020 17:00 296 4
10 days 01 April 2020 08:00 14 April 2020 17:00 296 4
10 days 01 April 2020 08:00 14 April 2020 17:00 296 4
10 days 15 April 2020 08:00 28 April 2020 17:00 297;300;29 4
1 day 23 March 2020 17:00 24 March 2020 17:00 3

1 day 24 March 2020 08:00 24 March 2020 17:00 212 4
1 day 24 March 2020 08:00 24 March 2020 17:00 212 4

0 days 23 March 2020 17:00 23 March 2020 17:00 212 4
1 day 24 March 2020 08:00 24 March 2020 17:00 212 4

1 day 24 March 2020 08:00 24 March 2020 17:00 212 4
1 day 24 March 2020 08:00 24 March 2020 17:00 212 4

3 days 27 May 2020 08:00 29 May 2020 17:00 3
3 days 27 May 2020 08:00 29 May 2020 17:00 202;203;26 4
3 days 27 May 2020 08:00 29 May 2020 17:00 202;203;27 4

140 days 25 March 2020 08:00 06 October 2020 17:00 3
1 day 02 October 2020 08:00 02 October 2020 17:00 234;244;24 4
1 day 25 March 2020 08:00 25 March 2020 17:00 302 4
1 day 05 October 2020 08:00 05 October 2020 17:00 314 4

84 days 07 October 2020 08:00 01 February 2021 17:00 2
2 days 07 October 2020 08:00 08 October 2020 17:00 3
10 days 07 October 2020 08:00 20 October 2020 17:00 220;318 4


10 days 21 October 2020 08:00 03 November 2020 17:00 288;287;28 4

1 day 04 November 2020 08:00 04 November 2020 17:00 327;329;33 4
1 day 05 November 2020 08:00 05 November 2020 17:00 340 4

2 days 07 October 2020 08:00 08 October 2020 17:00 307;308;31 4




40 days 08 December 2020 08:00 01 February 2021 17:00 3

30 days 08 December 2020 08:00 18 January 2021 17:00 346;350 4
10 days 19 January 2021 08:00 01 February 2021 17:00 361 4
6 days 19 January 2021 08:00 26 January 2021 17:00 3
1 day 19 January 2021 08:00 19 January 2021 17:00 361;346 4
1 day 19 January 2021 08:00 19 January 2021 17:00 361;346;35 4
1 day 19 January 2021 08:00 19 January 2021 17:00 361;346;35 4
1 day 26 January 2021 08:00 26 January 2021 17:00 368 4

1 day 02 February 2021 08:00 02 February 2021 17:00 2

1 day 02 February 2021 08:00 02 February 2021 17:00 362;369 4


Work Stream
Application: Design & Configuration

Analytics

System & Data Migration


Application: Solution Adoption
Project Management
Project Management
Project Management
Project Management
Project Management
Custom Code Extensions
Transition to Operations
Technical Architecture & Infrastructure
Application: Integration




Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management











Analytics
Analytics

Application: Testing










Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management




Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management

Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management





Project Management
Project Management
Project Management
Project Management




Analytics
Analytics
Analytics






Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management


Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management


Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management


Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management

Activity Group
Planning the Digital Transformation




Custom Code Management
Platform Execution
Platform Execution
Platform Execution
Safeguarding the Digital Transformation
Build Design
Build Design
Build Design
Build Design Support
Build Design
Build Design
Build Design
Build Design
Build Design
Build Design
Build Design
Build Design

Build Design
Build Design
Build Design
Build Design
Build Design
Build Design
Build Design
Build Design
Build Design
Build Design
Build Design
Build Design
Build Design
Analytics Design
Analytics Design

Build Design
Build Design
Build Design
Platform Execution
Platform Execution
Platform Execution
Platform Execution
Platform Execution
Platform Execution
Platform Execution
Data Migration Design

Data Migration Execution


Platform Execution
Platform Execution
Platform Execution
Platform Design
Platform Design
Platform Design
Platform Design
Platform Design
Platform Design
Platform Design
Platform Design
Platform Design
Platform Design
Platform Design
Platform Design
Platform Design
Build Execution
Build Execution
Build Execution
Build Execution
Build Execution
Build Execution
Build Execution
Build Execution
Build Execution
Build Execution
Build Execution
Build Execution
Build Execution
Build Execution
Build Execution
Build Execution
Build Execution
Build Execution
Build Execution
Build Execution
Build Execution
Build Execution
Build Execution
Build Execution

Analytics Execution
Analytics Execution
Analytics Execution
Build Execution
Build Execution
Build Execution
Build Execution
Platform Execution
Platform Execution
Platform Execution
Platform Execution
Platform Execution
Platform Execution
Platform Execution
Platform Execution
Platform Design
Platform Design
Platform Design
Platform Execution
Platform Execution


Safeguarding


Project-Plan en 18Q3-Activity and Task-Level

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Project-Plan en 18Q3-Activity and Task-Level

Enviado por

Direitos autorais:

Formatos disponíveis

ID Active Task Mode Name

1 Yes Auto Scheduled S/4HANA Sample Project

Yes Auto Scheduled Discover

Yes Auto Scheduled Strategic Planning

Yes Auto Scheduled Create an Innovation Strat

Yes Auto Scheduled Accelerate Your Innovation

Yes Auto Scheduled Create a 360-Degree View

Yes Auto Scheduled Define the Analytics Archit

Yes Auto Scheduled Application Value and Scop

Yes Auto Scheduled Discover the Value of SAP

Yes Auto Scheduled Identify the impact of SAP

Yes Auto Scheduled Check the Conversion Read

Yes Auto Scheduled Perform a Business Scenar

Yes Auto Scheduled Define the Implementation

Yes Auto Scheduled Create a Strategic Road Ma

Yes Auto Scheduled Trial System Provisioning

Yes Auto Scheduled Provide a Trial System

Yes Auto Scheduled Prepare

Yes Auto Scheduled Project Team Enablement

Yes Auto Scheduled Conduct SAP Solution Mana

Yes Auto Scheduled Perform Mobilization Traini

Yes Auto Scheduled Conduct Project Team Enabl

Yes Auto Scheduled Prototype

Yes Auto Scheduled Run Prototyping

Yes Auto Scheduled Transition Planning

Yes Auto Scheduled Check the Conversion Read

Yes Auto Scheduled SAP S/4HANA Transition Pro

Yes Auto Scheduled Define Cutover Approach

Yes Auto Scheduled Clarify Custom Code Adapt

Yes Auto Scheduled Clarify Operational Readin

Yes Auto Scheduled Define Technical Architectu

Yes Auto Scheduled Define the Data Migration

Yes Auto Scheduled Prepare Interface Register

Yes Auto Scheduled Run a Legacy Impact Analys

Yes Auto Scheduled Run a first Assessment o

Yes Auto Scheduled Run a first Assessment on

Yes Auto Scheduled Optional: Run a Technical S

Yes Auto Scheduled Transition Preparation

Yes Auto Scheduled Execute on Follow-Ups from

Yes Auto Scheduled Custom Code Cleanup and

Yes Auto Scheduled Cleanup Unused Code (Opti

Yes Auto Scheduled Improve Custom Code Quali

Yes Auto Scheduled Project Delivery Platform S

Yes Auto Scheduled Set up and configure SAP

Yes Auto Scheduled Import the Best Practices

Yes Auto Scheduled Project Initiation

Yes Auto Scheduled Conduct Handover Meeting

Yes Auto Scheduled Review Order Form with C

Yes Auto Scheduled Identify Stakeholders, Sta

Yes Auto Scheduled Set Stakeholder Expectation

Yes Auto Scheduled Create Project Charter

Yes Auto Scheduled Create Project Managemen

Yes Auto Scheduled Establish Project Governan

Yes Auto Scheduled Define Roles and Responsibi

Yes Auto Scheduled Create Scope Statement

Yes Auto Scheduled Create WBS

Yes Auto Scheduled Create Project Schedule

Yes Auto Scheduled Create Budget

Yes Auto Scheduled Plan Risks

Yes Auto Scheduled Plan Procurement

Yes Auto Scheduled Project Kick-Off and On-Bo

Yes Auto Scheduled Conduct Kick-off Meeting

Yes Auto Scheduled On-board Project Team

Yes Auto Scheduled Project Standards and Infra