Transition to SAP BW/4HANA

Implementation road map for

• New Implementation
• In-Place System Conversion
• Remote Conversion
• Shell Conversion
• Integration of SAP BPC 11.0 in SAP BW/4HANA

Version 2 Published in Q3 2020

PUBLIC
Table of Contents
Preface ...................................................................................................................................................... 5
How SAP can Support ............................................................................................................................. 10
1. Discover ........................................................................................................................................... 14
Strategic Planning.................................................................................................................... 15
Trial System Provisioning ........................................................................................................ 28
2. Prepare Phase ................................................................................................................................. 32
Project Initiation ....................................................................................................................... 34
Establish Project Governance ................................................................................................. 37
Plan Project ............................................................................................................................. 38
Project Kick-off and On-Boarding ............................................................................................ 40
Project Team Enablement ....................................................................................................... 42
Project Standards & Infrastructure .......................................................................................... 45
Prototyping ............................................................................................................................... 51
Transition Planning .................................................................................................................. 53
Transition Preparation ............................................................................................................. 72
Execution, Monitoring, and Controlling of Results ............................................................... 78
Organizational Change Management Roadmap ................................................................. 79
Phase Closure and Sign-Off phase Deliverables ................................................................ 79
3. Explore Phase ................................................................................................................................. 81
Phase Initiation ........................................................................................................................ 83
Execution, Monitoring, and Controlling Results ....................................................................... 83
Planning ................................................................................................................................... 85
Learning Design....................................................................................................................... 86
Organizational Change Management (OCM) .......................................................................... 88
Prep Steps for Conversions ..................................................................................................... 89
Data Volume Design ................................................................................................................ 94
Security Design ........................................................................................................................ 96
Analytics Design ...................................................................................................................... 97
Custom Code Impact Analysis ............................................................................................ 98
Test Planning ..................................................................................................................... 100
Data Migration Design for Remote Conversion ................................................................. 103
Sandbox System Setup for Remote Conversion ............................................................... 106
DEV Setup for Remote Conversion ................................................................................... 107
Sizing ................................................................................................................................. 108
Technical Architecture and Infrastructure Definition .......................................................... 110
Technical Design ............................................................................................................... 116
Operations Impact Evaluation ........................................................................................... 120
 Release and Sprint Plan .................................................................................................... 124
Change Impact Analysis .................................................................................................... 127
Phase Closure and Sign-Off phase Deliverables .............................................................. 127
4. Realize Phase................................................................................................................................ 130
Phase Initiation ...................................................................................................................... 131
Plan Realize Phase ............................................................................................................... 131
Sprint Initiation (Iterative) ....................................................................................................... 132
Execution Plan for Realize Phase ......................................................................................... 132
Sprint Closing ........................................................................................................................ 133
Learning Realization .............................................................................................................. 134
Configuration ......................................................................................................................... 137
Realize the In-place Conversion ............................................................................................ 138
Data Volume Configuration & Execution ............................................................................... 145
Integration Validation ......................................................................................................... 149
Analytics Configuration ...................................................................................................... 153
Custom Code Management Execution .............................................................................. 157
Test Preparation ................................................................................................................ 159
Test Execution ................................................................................................................... 160
QAS Setup ......................................................................................................................... 163
Object and Data Transfer for Remote Conversion ............................................................ 163
Object transfer in a Shell Conversion ................................................................................ 166
Cutover Preparation........................................................................................................... 168
Sizing & Scalability Verification ......................................................................................... 170
IT Infrastructure Setup and Test ........................................................................................ 173
Operations Implementation ............................................................................................... 178
Execution, Monitoring and Controlling Results .................................................................. 186
OCM Alignment Activities .................................................................................................. 191
Phase Closure and Sign-Off phase Deliverables .............................................................. 191
5. Deploy Phase ................................................................................................................................ 194
Phase Initiation ...................................................................................................................... 195
Learning Realization .............................................................................................................. 195
Integration Validation ............................................................................................................. 197
Dress Rehearsal .................................................................................................................... 198
Operations Readiness ........................................................................................................... 200
Execution, Monitoring and Controlling Results ...................................................................... 201
Release Closing..................................................................................................................... 202
Production Cutover ................................................................................................................ 203
Post Go-Live Enduser Training ............................................................................................. 205
 Production Support after Go-Live ...................................................................................... 206
Hyper Care Support ........................................................................................................... 207
Handover to Support Organization .................................................................................... 210
Project Closure and Sign-Off Project Deliverables ............................................................ 211
QG5 – Transition to Support Organization ........................................................................ 213
6. Run Phase ..................................................................................................................................... 215
Operate Solution .................................................................................................................... 216
Improve and Innovate Solution .............................................................................................. 219
Preface
The Transition Road map for SAP BW/4HANA supports customers and the project team with descriptions
of all phases and activities in the transition project, and accelerators providing links to guides and
documentation, and listing the SAP service offering to support the transition to SAP BW/4HANA. The
Transition Road map to SAP BW/4HANA describes the different paths the customer can take to transition
his SAP BW system to SAP BW/4HANA.

The Transition to SAP BW/4HANA road map follows the SAP Activate methodology framework, the same
way as the Transition to SAP S/4HANA road map. They both use the same phases, activities and tasks
wherever possible to help users work with the content without significant re-learning effort.

Figure: The Transition to SAP BW/4HANA road map graphic

This road map describes SAP BW/4HANA implementations for on-premise only. SAP offers dedicated
road maps for cloud implementation projects (see accelerator section at the end of this chapter).

The structure of this road map is release independent. Release specific information is given explicitly
where a certain activity or task is required for a dedicated release.

There are three conversion paths/scenarios to SAP BW/4HANA:

• Path 1: New implementation: For those who would like to implement a new SAP BW/4HANA
system by either migrating a legacy system or by running a net-new installation of SAP BW/4HANA.
• Path 2: System conversion: For those who want to run a conversion of an existing SAP Business
Warehouse system to SAP BW/4HANA. There are three types available for this scenario:
▪ In-Place Conversion
▪ Remote Conversion with parallel operations
▪ Shell Conversion

For the in-place conversion and the remote conversion, classic BW objects (e.g. InfoCubes,
classic DSO, BEx Report) need to be migrated to the related new HANA-optimized object type.
If your current SAP landscape has been highly maintained (SAP BW powered by SAP HANA and
usage of mainly new HANA-optimized BW object types), you most likely can convert to SAP
BW/4HANA in just a few steps.
 For the shell conversion, neither master nor transaction data are transferred. Data models and flows
are transferred to target SAP BW/4HANA system using transports.
• Path 3: System Consolidation: For those who would like to consolidate their existing data
warehouse landscape or carve out selected data models or flows into an existing SAP BW/4HANA
system. System Consolidation includes a selective data migration, which could be conducted within
a customer-specific project with SAP.

Figure Preface 1: Paths to SAP BW/4HANA

In the road map all three transition paths are covered, however the focus is on path 1 and the different
types of path 2. Path 3 is by far the most complicated one and can be only partially standardized.

The “Transition to SAP BW/4HANA” implementation road map is structured in project phases (x-axis) and
work streams (y-axis). Each box represents an activity which should be executed in the project as part of a
certain work stream, and within a certain project phase. The position of the activities in the roadmap
picture and in the roadmap description only give an approximate indication of a chronological order!
Figure Preface 2: Explanation of Road map structure

The “Transition to SAP BW/4HANA” road map is structured into the following work streams (groups of
semantically related activities):

• Project management – Covers planning, scheduling, governance, controlling and monitoring the
execution of the project. Target group of this work stream are project managers.
• Solution adoption – This work stream covers the creation of the training strategy and the learning
paths, and the enablement of the end users to be ready for optimal use of the new SAP BW/4HANA
solution.
• Application Design and configuration – In this work stream the classic BW models are converted
to HANA-optimized data models and flows as a prerequisite for a conversion BW/4HANA.
• Data Management – Covers the discovery, planning and execution of moving legacy data to the
new system and archiving of legacy data. The workstream also includes all data volume
management activities.
• Extensibility – Your code may need adjusting to function properly with SAP BW/4HANA. You first
clean up unused custom code, then identify affected custom code, e.g. in transformations or user
exits, and finally plan and execute the necessary adjustments. You can also leverage the full power
of SAP HANA by an optimization of your ABAP custom code for SAP HANA in parallel to SAP’s
optimizations within SAP BW/4HANA by using new process types, such as HAP (HANA Analysis
Process) or HANA-optimized transformations.
• Analytics: This work stream covers the Analytics Design which takes care for the detailed analytics
architecture, the detailed transition project plan, and creation of a blueprint, and the analytics
configuration
• Testing – This work stream covers test planning and execution (integration, regression, user
acceptance).
• Technical architecture and infrastructure – Here you plan the implementation of all SAP
BW/4HANA systems (sandbox systems, support non-production system such as maintenance
development and test system). Depending on the scenario, this may include migrating from SAP
BW on any database to BW edition for SAP HANA and then upgrading to SAP BW/4HANA. You
may also include connectivity to SAP HANA Cloud Platform for integration or extension use cases.
 • Operations & Support – IT operational procedures and tools need to be adjusted before going live
to help ensure safe operations. IT support experts need to be trained as well.

Time wise, the SAP BW/4HANA road map is structured into six project phases. The phase names are
according to SAP’s implementation methodology SAP Activate (see accelerators section):

• “Discover phase”: Discover the value of SAP BW/4HANA

In this phase, you mainly create a high-level value-based road map with high level time-lines for
the transition to SAP BW/4HANA.
Additionally, sizing estimations based on the BW sizing report, if applicable, or SAP Quicksizer
results are required as input for the business case.
SAP is able to support you with an Analytics Strategy Workshop for making the right decisions
and defining a business case. An SAP BW/4HANA Discovery Workshop offers a functional and
technical overview of SAP BW/4HANA and helps to define a customer specific approach for new
implementation.
• “Prepare phase”: Plan, prepare and start the implementation project
Once the business case has been approved, the project is officially initiated in the “Prepare”
phase. A high-level project plan including the results from the “Discover” phase should be created
in this phase.
Many customers also set up a sandbox system to verify or test important and critical steps.
Depending on the scenario, there could be preparation activities (e. g. conversion of classic BW
objects into HANA-optimized objects), which already need to be planned in detail and ideally
completed at an early point in time, to keep the downtime during cutover short. Finally, general
project preparation, such as staffing, governance, and reporting requirements, is also carried out in
this phase.
• “Explore phase”: Define all details
The major goal of this phase is creating the technical and functional blueprint document and run
Proofs of Concept (PoCs) for crucial transition topics.
From the technical side the to-be infrastructure set-up including sizing needs to be designed and
documented for the production as well as for the non-productive and temporary system
components. This is the pre-condition for the technical setup of sandbox and the development
environment, which at the latest takes place in the subsequent phase.
From the application side the to-be data architecture, including simplification of the data model,
LSA++ definition and object conversion needs to be designed and documented.
By the end of the “Explore” phase, all technical and application aspects of the transition project
are fully planned, documented in detail, and ready to be executed.
• “Realize phase”: Implement technical and functional changes
In the “Realize” phase, you physically set up the technical architecture and infrastructure for the
SAP BW/4HANA conversion, including required temporary hardware, or prepare interface
components for Cloud solutions.
Depending on the scenario, either a data conversion and switch to SAP BW/4HANA takes place
or in case of a new SAP BW/4HANA implementation a data transfer and conversion between old
and new system is required.
The next step in this phase are various tests, e.g. regarding integration, user acceptance and
performance.
Finally, the detailed cut-over plan for the next phase needs to be prepared.
• “Deploy phase”: Prepare to go live
The purpose of this phase is the final rehearsal and the go-live with the new analytics solution in
the production system(s). At the end of this phase the productive instance of SAP BW/4HANA is
fully implemented or converted (depending on the scenario) and ready to be used by the end
users.
This includes in particular
o the cut-over testing or final rehearsal e.g. in the pre-production system,
 o final key user testing,
o infrastructure testing (e.g. HA/DR testing) and
o testing of the key operations and procedures (e.g. monitoring and alerting).
o Production set up and end-user cut-over from the old landscape to the new SAP
BW/4HANA system landscape
At the end of this phase the end-users are working with the new analytics solution.
• “Run phase”: Optimize the operability of SAP BW/4HANA
After going live, SAP BW/4HANA is available for business users to log in and for productive use.
IT operations are further optimized (for example, bug fixing, system availability, and performance)
with the help of the project team and SAP. This phase is referred to as “hyper care” and occurs
before operational responsibility is fully transferred to the customer support team.

The road map is first of all a structured documentation for customers. An “always up-to-date” version of
this road map is available to all customers in the SAP road map viewer in the Hana Cloud Platform HCP –
see accelerator section for a link. From the Solution Specific Roadmaps, select “SAP BW/4HANA”.

Figure Preface 3: Roadmap Viewer entry screen

The “Transition to SAP BW/4HANA” implementation road map is a superset of activities covering all
implementation scenarios. Some activities and tasks have been grouped to make reading more
convenient. The road map contains many accelerators helping you to execute a certain activity or task.
Accelerators may link to resources which require either upfront registration (e.g. SAPs online learning
platform OpenSAP) or require a certain support status. For instance, the access to documents and
trainings in the SAP Enterprise Support Academy requires SAP Enterprise Support status.
Once you have opened the road map Content tab in the Road Map Viewer, you should filter for your
scenario to hide all activities and tasks which are not relevant to you. The following scenarios are
available:

• New Implementation

• In-Place Conversion

• Remote Conversion

• Shell Conversion

• SAP BPC 11.0 conversion/implementation

To select, open the Content page and scroll down to the More section, in the left structure pane and
select the scenario in scope.

SAP intends to update this road map once per quarterto provide the latest information and include new
features and functions.

How SAP can Support

The business transformation agenda varies from customer to customer. Some would like to understand
their options first and the opportunities for benefits. Other customers have already decided to start the
transformation to SAP BW/4HANA. In every case, SAP does everything to ensure that your expectations
are properly addressed with a meaningful number of offerings that allow sufficient flexibility to support an
agile transformation, no matter if you come from SAP BW 7.5 powered by SAP HANA or an SAP BW on
any database.

To support customers executing the SAP BW/4HANA transition successfully, SAP has developed several
service offerings. The offerings are structured for:

• SAP Standard Support and PSLE

• SAP Enterprise Support
• Implementation Services: SAP Value Assurance and SAP Advanced Deployment
• Premium Engagements: SAP Active Attention and SAP MaxAttention

SAP Value Assurance supports customers on their own or partner-led projects with dedicated planning,
design support, and functional and technical safeguarding services orchestrated by the technical quality
management (TQM) approach and embedded in the service center concept but does not provide any
implementation or delivery services.

In addition, there are execution services available delivered by SAP Professional Services in case of SAP
prime projects.
Figure Preface 5: Service Plan transition to SAP BW/4HANA with SAP Value Assurance services and
additional offerings from SAP Professional Services

All service components from SAP Value Assurance are available to Premium Engagement customers as
well. However, in particular SAP MaxAttention customers do have access to a broader set of offerings like
enterprise architecture planning. Where appropriate, those services are listed in this road map as well.

SAP Value Assurance has been structured into three service packages:

• Plan and Safeguard: This package is for customers who would like to properly plan the digital
transformation together with SAP, and who would like to get safeguarding support throughout the
implementation phase until Go-Live. The project execution is supported by SAP but executed by
the customer or the implementation partner or both. A TQM supports the customer project manager
throughout the project and builds a bridge to the mission control center MCC at SAP. The technical
and functional implementation is done by the customer or the implementation partner or both.
Identified product gaps can be validation, and the functional design evaluated by SAP.
SAP has added a Plan and prototype option to this package. 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.

• Business-ready: On top of ”Plan and Safeguard”, SAP actively supports customers in the design of
a “close-to-standard” implementation. The implementation is done by the customer, the
implementation partner, or both.

• Business Optimization: On top of ”Business-ready”, SAP supports customers in the design of

optimized solutions adapted and custom-tailored to customer business requirements. The
 functional implementation itself is in the responsibility of the customer, the implementation partner,
or both.

Figure: Value Assurance Packages

All SAP Value Assurance service packages can be tailored to your requirements. A description can be
found in the “accelerators” section.

The SAP Value Assurance service packages help you to quick-start your transformation with a defined set
of services, and are pre-calculated based on minimum scope, requirements and SAP involvement. Further
characteristics are:

• The scope can be easily extended as required

• Further optional services can be added for a higher hands-on involvement of SAP
• The technical quality manager will manage the extension together with you.

The following services have been designed to support customers in an SAP S/4HANA
implementation:

• Planning the Digital Transformation

• Build Design
• Build Execution
• Data Migration Design
• Data Migration Execution
• Analytics Design
• Analytics Execution
• Custom Code Management
• Platform Design
• Platform Execution
• Transition to Operations
• Safeguarding the Digital Transformation
 • Value Assurance Foundation

A service consists of one to many service components (SAP Value Assurance), or scope options (SAP
Professional Services). For simplicity reasons, this road map uses the term “service component” only. This
road map provides information about how a certain service component supports the implementation of an
activity or task. See the accelerator section for a description of services and service components. If you
are interested in SAP Value Assurance service packages, you can either contact your main SAP contact
person (TQM i or client partner). Alternatively, you can also ask for a tailored offer based on a scenario-
specific scope (see accelerator section for contact form details).

Individual support offerings from SAP Enterprise Support are also mentioned in the section “How SAP can
Support” throughout the road map.

Accelerators:
• SAP Activate
o General Information
o Overview Presentation
o Solution Brief
o Methodology
o FAQ
• Roadmaps
o Road Map Viewer in SAP Solution Manager
1. Discover
In the Discover Phase, customers become familiar with the benefits of SAP HANA and SAP BW/4HANA,
and the benefits it can bring to customers’ business.

Figure: Activities in the Discover Phase

The phase is structured into two parts:

• In a first step many customers want to (re)define their analytics strategy, which includes the User
Experience component (‘frontend analysis tools’) as well as the backend part e.g. with a data
warehouse. In this step customers want to evaluate the role of SAP BW/4HANA in a newly redefined
analytics landscape. Customers who have already participated In the SAP BW/4HANA Discovery
Workshop already have a functional and technical overview and may have defined their specific
approach. The Analytics Strategy Workshop works out potential customer-specific road map
options.
 • In a second step a trial system could be provisioned to support the impact evaluation. For trial
systems there are 3 versions available in the SAP Cloud Appliance Library:
- SAP BW/4HANA 1.0
- SAP BW/4HANA SP03 including BW/4HANA Content SP01 XT
- SAP BW/4HANA 1.0 SP09 and BPC 11 SP05 including BW/4 Content SP06

To learn about the current SAP BW/4HANA release, it is recommended to look at the central release
information note of SAP BW/4HANA, and the release restriction note. Both are given for SAP BW/4HANA
1.0 in the accelerator section.

Regarding SAP BW/4HANA releases and the availability of landscape transformation tools supporting the
data transformation to SAP BW/4HANA, you may check the product road map listed in the accelerator
section.

Accelerators
• Innovation Discovery Finder
• Platform and Technology of SAP Road Maps
• SAP BW/4HANA Overview and Roadmap
• SAP BW/4HANA Community
• SAP Online Help Portal for SAP BW/4HANA
• Cloud Appliance Library
• Release Information SAP BW/4HANA 1.0
• SAP Note 2347382: General Information SAP BW/4HANA
• SAP Note 2347384: Important Information SAP BW/4HANA
• SAP Note 2383530: Conversion from SAP BW to SAP BW/4HANA
• Discovery Workshop for SAP BW/4HANA
• Service Information – Service Components for Planning
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions

Strategic Planning

Description
SAP BW/4HANA is a new product built to fully leverage the SAP HANA in-memory platform. It provides a
simple set of objects that is well suited for modelling an agile and flexible layered architecture of a modern
data warehouse. SAP BW/4HANA manages all sorts of data, whether from SAP applications or other
systems, structured or unstructured, and allows accessing of all models through an open SQL
interface. Now depending on the start position of the customer, if the customer is currently running SAP
BW on anyDB or already uses SAP BW powered by SAP HANA, the overall innovation strategy and road
map needs to be defined.

You may check the SAP Transformation Navigator starting from your current product map, and your
current and planned business capabilities, to determine 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.

Before starting concrete BW upgrade/conversion or transformation projects, customers want to (re)define

their analytics strategy due to the fact that there are several new aspects, which might not be considered
so far:

• New options exist for analytics from OLTP embedded analytics up to SAP HANA Data Warehouse
and cloud based solutions like SAP Digital Boardroom.
• SAP HANA provides advanced platform capabilities for your core analytical processes: Real-time
reporting, Analytical / predictive processing, Big Data / IoT integration
• SAP portfolio has been streamlined and simplified:
o SAP BW/4HANA is the new flagship in the EDW space. SAP BW/4HANA has been rebuilt
to fully leverage the SAP HANA in-memory platform and be more open, simpler, faster and
equipped with new interfaces.
o SAP BusinessObjects BI has been simplified and products are merged and functionally
extended.
o SAP BusinessObjects Cloud offers an alternative UX/frontend solution for customers, which
fully want to leverage cloud capabilities.

Available Paths/Scenarios to SAP BW/4HANA

There are three major paths/scenarios to SAP BW/4HANA:

• Path 1: New implementation: For those who would like to implement a new SAP BW/4HANA
system by either migrating a legacy system or by running a net-new installation of SAP BW/4HANA.
• Path 2: System conversion: For those who want to run a conversion of an existing SAP Business
Warehouse system to SAP BW/4HANA. There are three types available for this scenario:
▪ 2a: In-Place Conversion
▪ 2b: Remote Conversion with parallel operations
▪ 2c: Shell Conversion
 • For the In-Place Conversion and the Remote Conversion, classic BW objects (e.g. InfoCubes,
classic DSO, BEx Report) need to be migrated to the related new HANA-optimized object type.
If your current SAP landscape has been highly maintained (SAP BW powered by SAP HANA and
mainly usage of new HANA-optimized BW object types), you most likely can convert to SAP
BW/4HANA in just a few steps.
• For the Shell Conversion, neither master nor transaction data are transferred. This allows for
optimized modeling and a re-design of the data models. Only selected data models and flows are
transferred to target SAP BW/4HANA system using transports.
• Path 3: System Consolidation: For those who would like to consolidate their existing data
warehouse landscape or carve out selected data models or flows into an existing SAP BW/4HANA
system. System Consolidation can be conducted within a customer-specific project with SAP.

Figure: Transition paths to SAP BW/4HANA 2.0

 Figure: Available types of a system conversion (path 2) to SAP BW/4HANA

Challenges of a Remote Conversion

There are some challenges to be considered for creating a parallel productive SAP BW/4HANA
system:

Challenges

• SAP BW/4HANA system shall be used productively for system conversion (risk & runtime
mitigation)
• Both systems shall be operated in parallel temporarily, hence data supply must be synchronized
• Delta management in the source systems must be made aware of the new SAP BW/4HANA system
• Source systems must not have any downtime (data booking must not be interrupted)

Solution

Delta queue cloning and synchronizing

Requirements and Constraints

It is recommended to run this activity upfront of an SAP BW/4HANA implementation project and in
case customers want to rethink their analytics strategy.

Procedure
• Check the Conversion Readiness of the current SAP Business Warehouse
• Run an Analytics Strategy Workshop. This service component describes the main components
of the SAP Analytics strategy from UI as well as from a data warehousing perspective and works
out potential customer-specific road map options.
• Decide on the innovation strategy and a high-level analytics road map
• Define the strategic analytics road map and value case
Results
As a result, there should be

• A customer specific 3-5-year roadmap for analytics and/or data warehouse approach, which
has been commonly worked out and agreed in the workshop
• main change activities and sequences on the defined roadmap
• Key values from business as well as from IT perspective supporting this roadmap
• Demo scenarios for the one or other scenario in BW/4, SAP Lumira or other involved components.

How SAP can Support

SAP offers a “Discovery Workshop for SAP BW/4HANA”.

The discovery workshop for SAP BW/4HANA helps customers identify crucial benefits and suggested
approaches for their road to SAP BW/4HANA in order to leverage latest functional and technical
innovations and move forward to the future-proof, scalable and high-performance enterprise data
warehousing platform by SAP.
It helps to evaluate possible transition scenarios towards SAP BW/4HANA for increased predictability,
identify areas of added value due to functional and technical innovations and ensure security of
investment by planning the road to the future data warehousing platform.
During a preparation phase relevant customer information will be gathered. If applicable, SAP will not only
analyze the information gathered from the customer but also the existing system itself by conducting
various checks inside the customer system. After all relevant information is gathered and the customer
requirements have been identified the workshop material will be adjusted according to the outcome of the
preparation phase.
The 2-day on-site workshop itself will cover all of the topics of relevance that have been identified. Areas
of interest might be the following:
• SAP BW/4HANA Roadmap
• SAP BW/4HANA functional overview and technical innovations
• SAP BW/4HANA in combination with SAP S/4HANA
• Transition paths to SAP BW/4HANA and offered system conversion tools
• Prerequisites for SAP BW/4HANA and results of system analysis and pre-checks
• Business use cases and SAP BW/4HANA business content
• Analytics with SAP BW/4HANA using SAP BusinessObjects Cloud and SAP BusinessObjects
Design Studio
• Viable recommendation for the next steps on the road to SAP BW/4HANA
The Discovery Workshop for SAP BW/4HANA is not part of any SAP Value Assurance service
package, however it is not free of charge. Customers should contact the local SAP sales
representative for ordering details.

Accelerators
• Service Information – Service Components for Planning
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• Conversion Guide for SAP BW/4HANA 2.0
• SAP Note 2733740 - BW/4HANA – Information
• SAP Note 2347382 - BW/4HANA – Information
• SAP Note 2347384 - Important SAP Notes for SAPBW/4HANA
• SAP BW/4HANA Master Guide
 • SAP BW/4 HANA Planning Product Availability Matrix (Planning PAM)
• SAP BW/4HANA End of Mainstream Maintenance Key Dates
• Discovery Workshop for SAP BW/4HANA

1.1.1.Check the Conversion Readiness of the current SAP Business Warehouse

Objective
There could be show stoppers (e.g. incompatible Add-On’s installed in the existing SAP BW system) or
requirements that may 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, so as to be able to adapt the overall
project plan accordingly.

Prerequisites
This task is in particular important for System Conversion and Landscape Transformation scenarios (in
case they start with a system conversion).

Procedure
Check the required release levels and minimum Support Packages of the original system for the selected
conversion type:
Figure: Required release and minimum support package of the original system

SAP recommends checking the following areas, and to document the results:

• Are the technical requirements fulfilled (software levels, Unicode…)?

• Database migration to SAP HANA
• On what release levels are the source systems (connections with ODP 1.0 or ODP 2.0)
• How much custom code needs to be adapted?
• How many simplification items are relevant and have to be processed?

Results
The results document of this task describes the implications of SAP BW/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 BW/4HANA, SAP has
created an SAP Readiness Check for SAP BW/4HANA self-service.
SAP Readiness Check for SAP BW/4HANA supports customers who plan to convert existing SAP BW 7.x
systems to SAP BW/4HANA. It checks both the production systems (or copies thereof) and the
development systems for SAP BW/4HANA conversion compatibility and necessary conversion preparation
steps. The results are consolidated in an interactive dashboard for internal or for SAP communication.

It is basically a filter on the “Simplification List for SAP BW/4HANA” based on usage of the individual
system. I.e. the SAP Readiness Check for SAP BW/4HANA performs a remote analysis of the settings,
configuration, and object compatibility and then lists all simplification items relevant for this system.

The SAP Readiness Check for SAP BW/4HANA focuses on:

• Functional show stoppers, restrictions and application requirements

• System and landscape requirements
• Custom code implications

Once you have prepared the current SAP BW system, you can execute the SAP Readiness Check for
SAP BW/4HANA yourself, either via SAP Solution Manager (recommended) or in the current SAP BW
itself. When 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 BW/4HANA, with
dedicated sections for custom code analysis, add-on compatibility, relevance of the simplification items
and so on.

Figure: SAP Readiness Check Analysis Overview

From the results that are displayed on tiles in the dashboard you can navigate to the corresponding
detailed views.

In case you need further interpretation of the SAP Readiness Check results, SAP offers a “Readiness
Check Explained” service component, which explains the check results in general and puts them into
perspective with respect to conversion feasibility and complexity. See accelerator section “Service
Information – Service Components for Planning” for more details.
SAP BW/4HANA Simplification Items:

For a given customer, only a limited number of simplification items from this extensive list are applicable.
The list covers all system capabilities, to include industry solutions. In the detailed view, you see the
simplification items for your SAP BW 7.x system, ranked by assessed relevance. The detailed view also
includes a reference to each simplification item's group, application area, category, and SAP Note where
you can find additional information.

Object Compatibility with SAP BW/4HANA:

SAP BW objects are listed according to their compatibility with SAP BW/4HANA:

• Green Bar
The objects are compatible with SAP BW/4HANA and can be used without changes.
• Yellow Bar
The objects are not compatible with SAP BW/4HANA. They either have to be changed, replaced
or deleted. We have a tool available to automate this process (partially or fully). The to-do column
will give a bit of details about it.
• Red Bar
The objects are not compatible with SAP BW/4HANA. They either have to be changed, replaced
or deleted. However, there are no tools available and the re-design has to be done manually. In
most such cases, we offer an automated deletion for any objects the customer deems obsolete.

Add-on Compatibility with SAP BW/4HANA:

This check shows how many add-ons are installed in your system, and whether they are compatible with
SAP BW/4HANA. In the detail view, you find the names of the add-ons, the vendor (SAP, 3rd Party on
SAP pricelist, 3rd party unknown), and the compatibility status.

New Pre-Check Tool:

Implement the new Pre-Check Tool with SAP Note 2777672 – Pilot Release: New Check Tool.

Please see the accelerator section for the landing page of the SAP Readiness Check, which contains all
important information on preparation, execution, and analysis.

Accelerators
• SAP Readiness Check – Landing Page
• SAP Readiness Check – Central JAM (SAP internal link)
• Service Information – Service Components for Planning the Digital Transformation
• SAP Note 2777672 – Pilot Release: New Check Tool

1.1.2.Define an Innovation Strategy and a High-Level Analytics Road Map

Objective
The objective of this task is to create a company specific innovation strategy for analytics, and to derive
the high-level multi-year road map from there.
Analytics covers considerations about the Analytics Frontends, Data Warehousing and possible Cloud
scenarios for the one or the other component. Refer to the latest information sources (see accelerator
section for details):

• The current and future integration between SAP Data Warehouse Cloud and SAP Analytics Cloud
is described in the Product Integration Roadmap.

• Business cases show how customers have extended their SAP BW/4HANA to the Cloud creating
a hybrid data warehousing strategy. Watch the youtube video and read the blog “How companies extend
SAP BW/4HANA to the Cloud”
• The product plan for SAP BW/4HANA in combination with SAP Data Warehouse Cloud is listed in
the product update for SAP Data Warehouse Cloud

Figure: Data Warehousing architecture

Procedure
To define the analytics road map, you will need to clarify questions like:

• What are the business requirements for analytics?

• What are pain points in the current set-up for analytics?
• Are there foreseeable new analytics business scenarios, which need to be covered in the near
future?
• Which SAP components up to now are utilized for the analytics landscape?
• What is the maintenance level of the current landscape (outdated release versions of the involved
SAP products?)
• Are there major changes planned in the OLTP landscape or other analytics-related components,
which might influence the current analytics landscape (e.g. SAP S/4HANA implementation)?

Results
As a result, there is a high-level multi-year road map which describes the main change activities and
sequences them on a high-level time-line.

How SAP Can Support

SAP provides decision support with the Analytics Strategy Workshop, helps the customer to align with
SAP Strategy and helps to work out possible road map options.

The Analytics Strategy Workshop is available as a service component in the Value Assurance service
“Planning the Digital Transformation” and as a service component in the new SAP MaxAttention service
“Architecture Transformation”.

Accelerators
• Service Information – Service Components for Planning the Digital Transformation
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
 • Service Information – Architecture Transformation
• Blog “How companies extend SAP BW/4HANA to the Cloud”
• Youtube video “SAP Data Warehouse Cloud: How Companies Extend SAP BW/4HANA to the
Cloud”
• Use Case Hybrid: SAP BW/4HANA + SAP Data Warehouse Cloud - Extending Data Warehousing
to the Cloud
• Product Plan – DWC and SAP BW/4HANA

1.1.3. Run an Analytics Strategy Workshop

Objective
In the Analytics Strategy Workshop service component SAP supports customers who are considering
renewing their Analytical Frontend and Data Warehousing strategy to get a holistic overview of the topics
that are key in the decision process for a new Analytics setup. Key aspects of this workshop are:

• Provide comprehensive information about the SAP Analytics Strategy

• Assess the customer’s as-is data warehouse and BI frontend architecture, business requirements
and IT/Analytics strategy
• Work out together with the customer the SAP recommended target solutions from product
component perspective
• Define a high-level analytics road map for the next 1-3 years

A holistic overview of the main topics has to be considered for the transition, including a high-level
overview about the transition approaches, tools, sizing and technical dependencies.

Outcome of the workshop should be one or several roadmap options with a brief description of the key
mile-stones and high-level time-lines.

The workshop also gives an overview about possible conversion paths to SAP BW/4HANA, which is
usually part of the strategic Analytics road map discussion.

The delivery approach of the Analytics Strategy Workshop service component can be split into 4 major
steps:

Figure: Steps of the Analytics Strategy Workshop

Details on the Analytics Strategy Workshop service component can be found in the accelerators
section.
Accelerators
• Service Information – Service Components for Planning the Digital Transformation
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• Service Information – Architecture Transformation

1.1.4.Discover the Value of SAP Business Planning and Consolidation (BPC) version for SAP BW/4HANA
Description
The new release of SAP Business Planning and Consolidation (SAP BPC) is available since June 2017 –
SAP Business Planning and Consolidation 11.0, version for SAP BW/4HANA.

Some important points about this new release of SAP BPC:

SAP BPC 11.0 is a new release of SAP BPC, optimized for SAP BW/4HANA. it is not a successor to BPC
10.1, version for SAP NetWeaver or BPC 10.1, version for the Microsoft platform.

Figure: Paths to SAP BPC 11.0 on SAP BW/4HANA

The 11.0 release offers Planning and Consolidation capabilities via the standard and embedded model.
Much of it is based on functionality from BPC NW.

Due to the fact that its BW/4HANA platform which leverages the SAP HANA database, BW-IP is no longer
supported, and the BPC Standard model requires the SAP HANA platform.

SAP took the opportunity of BPC 11 development to redesign and improve the user experience believing
that better user experience makes users work more productive and life easier. SAP Fiori was chosen as
our design language for a harmonized SAP wide look and feel. We also made functional enhancements,
such as home page and search, for a better experience to all users.

SAP BPC 11.0 can be included in an in-place conversion or a remote conversion, following the
prerequisites listed in the figure below:
Figure: Available Conversion scenarios from SAP BPC standard to SAP BPC 11.0 version for SAP
BW/4HANA

How SAP can Support

In the Discovery phase, BPC 11.0 can be included in an Analytics Strategy Workshop (see task Run an
Analytics Strategy Workshop), including the following topics according to the customer’s needs:

- Overview of BPC 11.0; Delta against BPC 10.1

- BPC Standard versus Embedded Model
- BPC 11.0 versus BPC Optimized for S/4HANA
- Conversion Scenarios

Accelerators
• Service Information – Service Components for Planning the Digital Transformation
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• Service Information – Architecture Transformation

1.1.5. Check the value of available SAP BW/4HANA content add-ons

Objective

In addition to SAP Business Planning and Consolidation for SAP BW/4HANA, several other add-ons are
available which replace current add-on functionality in SAP BW:

• “SAP Strategic Enterprise Management – Consolidation” (SEM-BCS) can be converted to “SAP

BW/4HANA, Business Consolidation Add-on 1.0” (BCS4HANA). This is currently supported with an
in-place conversion only – see SAP Note 265241 – Conversion from SEM-BCS to BCS4HANA.
• “SAP Demand Signal Management” (DSIM) can be converted to SAP Demand Signal Management
1.0 version for SAP BW/4HANA (DSIM4H) – see SAP Note 2707571 – SAP Demand Signal
Management on BW/4HANA.

For an overview of the SAP NetWeaver add-ons which are supported by SAP BW/4HANA, refer to SAP
Note 2819708 – SAP BW/4HANA Add-on Handling and Usage.

Accelerators
• SAP Note 2651241 – Conversion from SEM-BCS to BCS4HANA
 • SAP Note 2707571 – SAP Demand Signal Management on BW/4HANA – Release Information
• SAP Note 2189708 – SAP BW/4HANA Add-on Handling and Usage

1.1.6.Create a Strategic Road Map & Value Case

Objective
The objective of this task is to derive the customer specific road map for implementing SAP BW/4HANA
considering the findings from previous tasks. This task may be covered in the Analytics Strategy
Workshop or in the post processing phase, depending on the complexity of the customer situation.

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
The following steps should be considered (recommended step sequence):

1. Develop the building blocks (such as functional, organizational or technical steps) required
to reach the defined target architecture
2. 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
3. Determine the risks of transformation
4. Compose a consolidated road map of building blocks to implement the target solution
landscape
5. Agree on requirements & conditions for the business case calculation
6. Define KPIs, and link them to the identified value drivers
7. Determine the value driver
8. Determine the cost driver

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 and a value case available.

How SAP Can Support

In the Analytics Strategy Workshop (described in the tasks before) a first decision should be made if the
customer proceeds with a new implementation of SAP BW/4HANA or a system conversion. Both cases
are covered in the Migration Planning Workshop in the Transition Planning activity. Valuable information
on the two types of system conversion are also given in the BW/4HANA blog listed in the accelerator
section.

Accelerators
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• Service Information – Service Components for Planning the Digital Transformation
• Service Information – Architecture Transformation

Trial System Provisioning

Description
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 may be no hardware available to
run the new solution on premise, therefore installing a pre-configured appliance is potentially not possible.
A cloud trial system is the preferred option in most cases.
Requirements and Constraints
User account at cloud provider 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 system, which runs at the cloud provider.

Accelerators
• SAP Cloud Appliance versus Blu-Ray Installation

1.2.1.Provide a Trial System

Objective
Request a Trial system in the cloud and provide it to your project team.

Prerequisites
User account at cloud provider required (e.g. Amazon Web Services (AWS)).

Procedure
You can access the cloud appliance via the SAP Cloud Appliance Library (SAP CAL, see link in the
accelerator section). 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.

Note: Check your cloud provider page for prices. You find the recommended VM sizes in the details
section of the selected image.

If you opt to go beyond the 30-day limit, an SAP CAL subscription license and a regular SAP license
for the product is required. Besides the SAP backend, you also receive access to a MS Windows
Terminal Server (WTS) with the pre-configured Fiori Launchpad URL, SAP GUI logon, and other useful
frontend software.

1. Go to the CAL landing page at SAP.COM

2. Inform yourself about the Cloud Appliance Library, and the different options you have
3. Click “Start your trial now”
4. Accept terms and conditions
5. Select the right trial image (SAP BW/4HANA XL, SAP BW/4HANA dev, or the SAP
BW/4HANA version with SAP BPC 11.0)
6. Click “Try now”
7. Accept terms and conditions
8. Maintain cloud provider account information
9. Click “Create Instance”
Figure 1.6: Relation of user, SAP Cloud Appliance Library and AWS Cloud
 Figure 1.7: SAP BW/4HANA 2.0 in the Cloud Appliance Library

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. You may
refer to the Getting Started Guide on the CAL page for details.

Accelerators
• SAP CAL
• SAP CAL at SAP SCN
• Getting Started Guide BW4HANA Trial
2. Prepare Phase
Once the business case has been approved, the project is initiated in the Prepare phase.

Figure 2.1: 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. Note
that currently the SAP Activate methodology is always described in the context of SAP S/4HANA, but a lot
of the SAP Activate content is generic and can help with the implementation of other SAP products, too.

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 quickly in case of problems.

Project team enablement also starts at this point in time.

If the customer wants to go for prototyping it takes place in the Prepare phase. Prototyping is an optional
small project on its own. It requires dedicated planning, execution and final evaluation.

The transition project itself is planned at a high-level in the Transition Planning activity in the Migration
Planning Workshop (conversion) or the Transition Planning Workshop (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. If not yet done in the Discover
phase, a readiness assessment is performed on the current SAP BW system to identify aspects that could
have a major impact on the system conversion project.

The planning workshops often reveal preparation activities (e.g. the database migration to SAP HANA),
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 and will be executed in the Transition
Preparation activity. These can be complete pre-projects which have to be performed before the actual
transition project can go into the Explore phase.

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

The Prepare phase ends with a first Quality Gate to ensure proper project preparation.

Accelerators
• SAP Activate
o General Information
o Solution Brief
o Methodology
o FAQ
 Project Initiation
Description
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 SAP Technical Quality Manager (TQM) and the access to SAP’s Mission Control Center
and Premium Mission Critical Support is part of each and every Value Assurance package. 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 3rd 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
• Project Initiation
• Project Planning

Results
Once this activity has been completed, the transition project has been successfully initiated.

How SAP Can Support

SAP Value Assurance supports this task with multiple service components, and offers the following
benefits:

• An established service plan complete with governance model

• A defined scope and approach for the digital journey
• Established quality gates for measurable, on-time results
• Access to deep, expert knowledge on a global level
• Alignment on Best Practices and gap verification to reduce overall complexity
• Timely scorecard-based measurement for success

The service always includes the Focus TQM described above. In addition, you may request additional
resources like the Project Manager / Project Lead, and Engagement Architect from SAP as part of this
service. See accelerator section for a service component description.

Accelerators
• Service Information - Value Assurance Foundation
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• SAP Digital Business Services (DBS) Delivery Infrastructure
• SAP Activate road map “SAP Activate methodology for Business Suite and On-Premise – Agile”
• SAP BW/4HANA_Project Plan Templates
• Classroom training: Implementation Projects with SAP Solution Manager

2.1.1.Conduct Handover Meeting(s) from Opportunity Phase

Objective
The purpose of this task is to efficiently transition the project from the opportunity team to the 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

2.1.2.Review Order Form with Customer

Objective
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

2.1.3.Identify Stakeholders, Stakeholders’ Requirements and Expectations and

Project/Deliverable Acceptance Criteria
Objective
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.

2.1.4.Set Stakeholder Expectations for Agile Project

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

2.1.5.Create Project Charter

Objective
The Project Charter formally documents 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

Accelerators
• Business Case Template (Customer)
• Project Charter Template (Customer)
• Scope Statement Template (Customer)

2.1.6.Create Project Management Plan

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

Procedure
• 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

Accelerators
• External Risk List Template (Customer)
• Focused Build for SAP Solution Manager (Customer)
• Project Management Plan Template (Customer)
• Resource Plan Template (Customer)
• Risk Identification Session Guide (Customer)
• Subsidiary Project Management Plans Guide (Customer)

Establish Project Governance

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

Tasks
• Define Roles and Responsibilities
• Define Project Organization
• Review Project Management Plan

2.2.1.Define Roles and Responsibilities

Objective
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 consider their
qualifications and availability for the whole project time frame.

Accelerators
• Agile Project Team Roles and Responsibilities (Customer)

2.2.2.Define Project Organization

Objective
The purpose of this task is to define the organizational structure of the project team.

2.2.3.Review Project Management Plan

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

Plan Project
Description
The purpose of this deliverable is to properly plan the project to guide both project execution and project
control.

Procedure
• Create Scope Statement
• Create WBS
• Create Project Schedule
• Create Budget
• Plan Quality
• Plan Communications
• Plan Risks
• Plan Procurement
• Plan Stakeholders Management

2.3.1.Create Scope Statement

Objective
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.
 2.3.2.Create WBS
Objective
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 the lowest level can be subdivided into activtities/tasks

2.3.3.Create Project Schedule

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

Procedure
1. Define Activities
2. Sequence Activities
3. Estimate Activity Resources
4. Estimate Activity Durations
5. Develop Schedule

2.3.4.Create Budget
Objective
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.

Procedure
• Estimate Costs
• Determine Budget

Accelerators
• Resource Plan Template (Customer)

2.3.5.Plan Quality
Objective
The purpose of this task is to identify the standards of the project and how the quality will be managed and
validated throughout the implementation of the project.

Accelerators
• QGateChecklist Concept SAP Activate
 • QGateChecklist Template Introduction
• Quality Built In New QGateChecklist

2.3.6.Plan Communications
Objective
The purpose of this task is to plan the communication management and define the communication
requirements for the project.

Accelerators
• Communication Plan Overview Template (Customer)

2.3.7.Plan Risks
Objective
The purpose of this task is to plan and define the project risks.

Procedure
1. Identify Risks
2. Assess Risks: Estimating and Evaluating Risk
3. Create Risk Register ( refer to the "Risk Register Template" provided )
4. Define Risk Responses

Accelerators
• External Risk List Template (Customer)
• Risk Identification Session Guide (Customer)

2.3.8.Plan Procurement
Objective
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.

2.3.9.Plan Stakeholders Management

Objective
The purpose of this task is to plan the appropriate management strategies to identify and engage
stakeholders.

Accelerators
• OCM Stakeholder Identification Guide (Customer)
• OCM Stakeholder Identification Template (Customer)

Project Kick-off and On-Boarding

Description
The purpose of this deliverable is to kick-off the project and ensure that all required 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.
Tasks
• Prepare for Kick-off Meeting
• Conduct Kick-off Meeting
• Prepare Team Onboarding Document
• On-board Project Team

2.4.1.Prepare for Kick-off Meeting

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

Accelerators
• Project Kick-off Template (Customer)

2.4.2.Conduct Kick-off Meeting

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

2.4.3.Prepare Team On-boarding Document

Objective
The purpose of this activity is to prepare the onboarding package for external consultants from SAP and
partner companies.

Accelerators
• Project Guideline Template (Customer)

2.4.4. On-board Project Team

Objective

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.
 Project Team Enablement
Description
The purpose of this task is to develop a comprehensive training strategy that provides all team members
with a learning path for acquiring the skills and knowledge needed to complete the project successfully.

Requirements and Constraints

The project has been initiated successfully.

Procedure
• Provide key self-learning material to the project team
• Train the customer project team.

Results
As a result, the project team has been trained successfully.

2.5.1.Provide Key Self-Learning Material to the Project Team

Objective
The purpose of this task is to make key self-learning material and information sources available to the
project team members.

Prerequisites
The project has been initiated.

Procedure
Organize self-learning possibilities for ITprofessional to understand the new solution with digital learning
environments (e.g. Learning Hub). This may include:

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

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

3. 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 an 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.
Results
Key learning resources are available to the project team for self-learning.

Accelerators
• Access to Best Practices
o SAP Best Practice Explorer
o How to Use SAP Activate Content in SAP Solution Manager 7.2
• Access to the SAP Learning Hub
o Create SAP Learning Hub Account, Join SAP Learning Rooms, and Troubleshoot
Issues (SAP Internal Link)
• Self-Enablement Materials
o Setup Access to SAP Learning Hub (SAP Internal Link)
• SAP Solution Manager Materials
o Classroom training: Implementation Projects with SAP Solution Manager
o Focused Build for SAP Solution Manager
o Best Practices Reference Guide
o SAP Solution Manager Landing Page in the SAP Support Portal
o SAP Value Assurance - Description of Services and Service Components
• Agile Implementation
o Agile Concept Presentation
o Agile Management Introduction
o Agile Project Team Roles and Responsibilities

2.5.2.Train the Customer Project Team

Objective
In case the self-learning material is not sufficient to train the project team, it is the purpose of this task to
further train the project team to ensure efficient design and implementation.

Prerequisites
The project has been initiated, and the project team has been set up.

Procedure
The starting point for creating knowledge transfer in transformation projects is the identification of the
learning requirements and the analysis of the digital learning opportunities for the professional IT team
members within the customer organization.

Matching the project scopes and objectives with the given resources and their requirements will identify
the skill-gaps for the project team members at the very first beginning of the project.

Proceed as follows:

• Identify the processes in scope and analyze the required skills together with the project team
• Evaluate SAP individual standard training from SAP Education courses (Classroom and Web-based
Trainings)
• Develop enablement plan including training, mentoring, coaching for individual project team
members / project team groups
• Organize and run system application training with individual learning methods

Results
The customer project team is ready for application design and implementation.

How SAP Can Support

SAP Education offers the “Learning Needs Analysis for the Project Team” (LNA). This is part of the
“Enablement Charter” service component (Planning the Digital Transformation service).
Based on the results of the LNA, SAP Education:

• Provides the project team with an individual training curriculum

• Organizes standard classroom trainings
• Delivers and sets up learning hub licenses for the project team members
• Coaches project team members

Please note that the training of the project team is not included in SAP Value Assurance but is handled
separately by SAP Education.

See accelerator section for details.

Accelerators
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• Service Information – Service Components for Planning the Digital Transformation
 Project Standards & Infrastructure
Description
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 considered when defining
the most suitable standards for the project. The 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
1. Install and Setup SAP Solution Manager

2. Setup Project Team Logistics and Infrastructure

3. Setup and Test Remote Support

2.6.1.Define Project Standards

Objective
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 at 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

2.6.2 Determine Operational Standards
Objective
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 considered
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 a 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 issue (Hot News, Security Notes).

Determine Upgrade Management

The purpose of this task is to determine the customers approach for the identification, adaptation and
implementation of new and enhanced business and technical scenarios. It uses Solution Manager to
manage the upgrade project holistically and effectively end-to-end and allows SAP customers to better
understand and manage the major technical risks and challenges in an upgrade project, and to make the
upgrade project a "non-event for the business".

Accelerators
• Best practices for Implementing CTS+

2.6.3. Define and Set Up Agile Project Standards and ALM Tools
Objective
The purpose of this task is to define and set up SCRUM standards and tools, such as SCRUM board,
burn-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 a 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.

Accelerators
• Agile Definition of Ready and Done (Customer)
• Agile Sprint Burndown and Task Board (Customer)

2.6.4. Check Availability of SAP Solution Manager

Objective
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 is 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 SolMan and there is an appropriate schedule of project team training for
each project phase / key activity using SolMan.

• the procedure for requesting access to SolMan and other systems and tools is agreed, setup and
communicated.

2.6.5. Set up Project Team Logistics and Infrastructure

Objective
The objective of this task is to setup a physical project team environment and ensure that the project
team members have an 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 the 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 in different 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)

2.6.6. Set up and Test Remote Support

Objective
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, setting 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.
 Prototyping
Description

Prototyping is an optional small project on 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:

1. Run a scoping workshop for prototyping

2. Set up the prototyping system (either new installation, or system conversion)
3. Activate the solution in scope
4. Finalize the setup of the prototype
5. Validate the prototype
6. Run a final results workshop

Figure 2.2: Main Steps in a Prototyping Project

Results

The result of a prototype usually has significant influence on the main project (e.g. Go / No-Go decision,
learnings on how to prepare the main project, or what functionality to set up).

How SAP Can Support

SAP offers a Plan and Prototyping service, providing rapid, tangible proof to the customer by building
customer-specific proof-of-concepts and solution prototypes.

Accelerators

• Service Information – Plan and Prototyping

• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions

2.7.1. Run Prototyping Workshop

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

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 and prototype” option can be used for both system conversion and new
implementation projects. The included components are as follows:

• 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” 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 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.

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.

Accelerators

• Service Information – Plan and Prototyping

 Transition Planning
Description
The planning of the transition project helps to properly define the scope and execution plan for the
upcoming 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.

As already highlighted in the preface, there are three conversion paths/scenarios to SAP BW4HANA:

• Path 1: New implementation: For those who would like to implement a new SAP BW/4HANA
system by either migrating a legacy system or by running a net-new installation of SAP BW/4HANA.
• Path 2: System conversion: For those who want to run a conversion of an existing SAP Business
Warehouse system to SAP BW/4HANA. There are three types planned for this scenario:
o in-place system conversion (via SAP BW7.5 powered by SAP HANA)
o Remote conversion
o Shell conversion
• Path 3: Selective Data Transition: For those who would like to consolidate their existing data
warehouse landscape or carve out selected data models or flows into an existing SAP BW/4HANA
system. Selective Data Transition can be conducted within a customer-specific project with SAP.

In the Transition Planning activity, the decision for one of the scenarios should already be clear.

Note: As Selective Data Transition is very customer-specific, this roadmap documentation focusses on the
New Implementation and the system conversion scenarios.

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 selective data transition scenario. See activity Strategic
Planning, task Check the Conversion Readiness of the current SAP Business Warehouse.

2.8.1. Transition Planning – New Implementation

Procedure
During an implementation project, you have to consider many aspects and to take various decisions. The
major planning steps of this process are outlined below:

• Scope and Requirements

o You determine the scope of your SAP BW/4HANA implementation
• Landscape Planning (will be detailed out in the Technical Architecture WS)
o You determine the system landscape and consider the landscape-relevant aspects
concerning your required use case
• Hardware & software Prerequisites (will be detailed out in the Technical Architecture WS)
o Use the Product Availability Matrix (PAM) to check which platforms (operating systems,
databases, browsers) are supported for your SAP BW/4HANA components
o Check the recommended minimum database versions (see SAP Note 2347382 – SAP
BW/4HANA information)
• Release Restrictions
o Check SAP Notes for any release restrictions (see SAP Note 2733740 – Release
Information/Restrictions Note for SAP BW/4HANA 2.0)
• SAP Solution Manager Prerequisites
o SAP always recommend using the latest SAP Solution Manager release.
o Make sure that your SAP Solution Manager system has the required support package level
and content.
 o Check if you need to do an update or upgrade of your SAP Solution Manager application
or content
o After an upgrade or update to the latest SAP Solution Manager release, you need to carry
out follow-up actions as described in the Solution Operations Guide in the section Software
Change Management. See under http://service.sap.com/instguides -> SAP Components -
> SAP Solution Manager -> (release) -> Operations

The following figure shows the software units that are used for data warehousing:

Figure 2.3: Software units for Data Warehousing

* Note that SAP BusinessObjects products require separate licenses.

• With SAP BW∕4HANA, SAP offers the SAP HANA database being the in-memory deployment option
for the data warehousing use case. In combination with SAP BW∕4HANA 2.0, it is necessary to use
SAP HANA 2 SPS03 Revision 36 or a higher revision.
• The Modeling Tools represent a modeling IDE (Integrated Development Environment) built on top
of the Eclipse platform, supporting SAP BW∕4HANA model with state-of-the-art modeling tools.
These tools include integration with SAP HANA modeling and the consumption of SAP HANA
elements in Open ODS Views or CompositeProviders with powerful UI (user interface) capabilities.

Results
The required implementation steps and preparatory steps should now be defined in an action plan.

How SAP Can Support

In case of a new implementation SAP covers the following scope in the Transition Planning Workshop:

• Customer specific information gathering

• Workshop Day 1: Functional and Technical Overview
• Workshop Day 2: Proposed Customer Specific Content and Approaches
• Readiness Report Creation and handover to Customer
• Feedback and Follow-Up

In addition, SAP offers a lot of information on the different paths to SAP BW/4HANA in the SAP
BW/4HANA Community. In the SAP Community for SAP BW/4HANA consultants report on their
experiences made during the early adoption phase and give a step-by-step description of the
implementation / conversion process which may be very informative for consultants as well as customers.

For customers who have a productive SAP BW but want a fresh start, SAP is planning to offer an option to
transport certain objects from their existing SAP BW system to a newly installed SAP BW/4HANA system.
For a tool to check the transports, see SAP Note 2361350.

Accelerators
• SAP Product Availability Matrix
• Service Information – Service Components for Planning
• Service Component Delivery Suitcase - Migration Planning Workshop (SAP internal link)
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• Installation Guides on SAP Service Marketplace
• SAP BW/4HANA Community
• OPEN SAP Training Class - SAP BW/4HANA in a Nutshell
• The Road to SAP BW/4HANA (document)
• Technical Presentation on BW/4HANA
• SAP First Guidance – BW/4HANA complete functional scope (CFS)
• SAP Note 2347382 – SAP BW/4HANA information
• SAP Note 2733740 – Release Information/Restrictions Note for SAP BW/4HANA 2.0
• SAP Note 2361350 – B4H mode: transport check for RS_B4HANA_CHECK_ENABLE

2.8.2.New Implementation of SAP BPC 11.0

Objective
All steps for the new BPC 11.0 implementation must be planned in this activity. The BPC project can
consist of either
- an implementation of a new planning or consolidation process,
- a migration of a non-SAP legacy solution,
- a migration of an SAP legacy solution (e.g. BPS, BCS)
- a re-implementation of BPC 11.0 Standard Model in BPC 11.0 Embedded Model

Procedure
Same as for BW/4HANA – see task “Transition Planning – New Implementation”.

Results
The required implementation steps and preparatory steps should now be defined in an action plan.

How SAP can Support

For migration projects, SAP offers the Migration Planning Workshop (MPW) for SAP BW/4HANA which
can be enhanced with BPC specific topics.

In case of a new implementation without any predecessor tool, SAP can support with a Technical
Architecture and Infrastructure service.

Accelerators

• Application help for BPC 11.0 Standard

• Application help for BPC 11.0 Embedded
• Master Guide
• Administration Guide
 • Security Guide
• Product Availability Matrix SAP BPC 11.0
• SAP Help Portal page
• SAP Note 2343286 - Planning on BW/4HANA
SAP Note 2463467 - SAP Business Planning and Consolidation 11.0 SP01, version for SAP
BW/4HANA Central Note
• Service Information – Service Components for Planning the Digital Transformation

2.8.3.Transition Planning – In-Place System Conversion

Objective

The In-place Conversion takes your existing SAP BW landscape through a transition process that
transfers step-by-step data models and flows to objects compatible with SAP BW/4HANA. Prerequisite is
SAP BW 7.5 powered by SAP HANA, the last major release of SAP BW.
During the preparation time, you will use the Pre-Check Tool to analyze the meta data repository of your
SAP BW system and lay out a to-do list for the transition process, run the Sizing Report to determine the
required size of hardware for SAP BW/4HANA, and use the Code Scan Tool to analyze your custom
developments – including code embedded in various SAP BW objects like transformations – for
compatibility with SAP BW/4HANA.

When you get to the realization phase, you will spend most time using the Scope Transfer Tool, which
allows you to create SAP HANA-optimized objects for all your classic SAP BW data models and flows.
Pick a data target, like a MultiProvider and the tool will determine all dependent object like InfoCubes,
classic DataStore Objects, transformations, and DTPs and allow you to quickly create equivalent
CompositeProviders and Advanced DataStore Ob-jects including matching transformations and DTPs.
During an In-place Conversion, the transfer happens inside your SAP BW on SAP HANA system.
For In-place Conversion, several sprints using the Scope Transfer Tool will lead to a system that runs only
data model and flows that are compatible with SAP BW/4HANA… but still in SAP BW (along the way you
use another cool tool to adjust user roles and authorizations, which will be much appreciated by your
security team). The ultimate step is therefore a technical system conversion that removes the old SAP BW
code and replaces it with SAP BW/4HANA. This is when you finally get to use the goodies like Data
Tiering Optimization and the SAP BW/4HANA Web Administration Cockpit.

Figure 2.4: Basic Sequence of in-place Conversion

Customers starting from BW on anyDB must start with a database migration to SAP HANA. This is a
separate project which should run during the Transition Preparation activity.
Procedure
1. Check the conversion readiness of the current SAP BW system (system conversion scenarios only)
2. Define the scope and the objectives of the transition
3. Define the cutover approach (high-level)
4. Clarify the custom code adaption
5. Clarify operational readiness
6. Define the technical architecture (high level)
7. Define the data migration architecture (important for new implementation and landscape
transformation)

Results
As a result, a first version of an action plan has been documented which could serve as the basis for a
project plan. A high-level transition planning document should be stored in SAP Solution Manager.

How SAP Can Support

Migration Planning Workshop

For conversion projects, SAP offers the Migration Planning Workshop (MPW) for SAP BW/4HANA. The
MPW helps to define the scope and execution plan for the customer’s conversion project.

Main objectives / deliverables of the workshop are:

• Decision or at least the decision support for the right transition approach to SAP BW/4HANA (in-
place or Remote conversion, system landscape transformation)
• Verification of the prerequisites for the chosen transition approach
• 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.
• In case customer decides to perform an In-Place system conversion, check the Prerequisites
Checklist for the In-Place Conversion and identify the required preparation steps to get the system
and data conversion-ready
• The outcome of the workshop includes
o development of a system-level transition road map
o a customer tailored high-level milestone project plan
o the Prerequisites Checklist with the identified preparation steps (if applicable)
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” for system conversion. Details on the MPW can be found in the
accelerator section.

Delivery approach and scope are:

• The business process streams are assessed in order to define the Best Practice scope, review
existing GAPs, collect information for data migration, quick-sizing and Interface-architecture.
• Create/review high-level architecture with Interfaces
• Create/review Quick-sizing
• Empower the customer for data migration respectively review existing data migration strategy
• (optional) Develop/review of high-level-scope statement and project schedule, project governance
and operational standards
• (optional) Provide substantial knowledge on SAP Activate Methodology, Data Migration Approach
and Strategy, SAP BW/4HANA Sizing
Note: The same sizing process used for SAP BW powered by SAP HANA applies to SAP BW/4HANA.
See SAP Note 2296290. For hardware sizing to run a BW/4HANA system, refer also to SAP Note
2363248 (see accelerator section).

If the customer has decided to perform an in-place system conversion, he may make use of the SAP Best
Practices for In-place system conversion to SAP BW/4HANA as a PS service for the Realize phase.
This PS service provides the customer with a proven project approach and configuration guides for the
conversion of an existing SAP BW to SAP BW/4HANA, without reimplementation and with minimal impact
on business operations. The tool-based conversion to SAP BW/4HANA includes step-by-step
documentation with project WBS structure, streamlined project methodology, and optimized project tools.
Best practices help to plan and convert the system, gaining all the benefits of BW/4HANA.

Note that filling the Prerequisites Checklist in the MPW is mandatory as a preparation for the in-place
conversion.

Accelerators
• Service Information – Service Components for Planning the Digital Transformation
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• SAP Note 2383530 - Conversion from SAP BW to SAP BW/4HANA
• SAP Note 2189708 -SAP BW/4HANA Add-On Handling and Usage
• SAP Note 2296290 - New Sizing Report for SAP BW/4HANA
• SAP Note 2363248 – BW/4HANA Hardware Sizing

2.8.4.In-Place Conversion with SAP BPC to SAP BPC 11.0

Objective
All steps for the system conversion must be planned in this activity, depending on the starting point of the
current BPC system.
An in-place conversion only supports conversion within the same BPC Model, i.e.
- BPC 10.1 Embedded Model can only be converted to BPC 11.0 Embedded Model
- BPC 10.1 Standard Model can only be converted to BPC 11.0 Standard Model

Figure: Paths to SAP BPC 11.0 version for SAP BW/4HANA

For a re-implementation of BPC 11.0 Standard model in BPC 11.0 Embedded Model, please refer to the
task New Implementation of BPC 11.0.

Procedure
The in-place conversion of BPC is supported by the Transfer Tool (version 1.5) for BPC Standard as well
as for BPC Embedded.

Note: The same sizing process used for SAP BPC powered by SAP HANA applies to BPC 11.0 and is
based on the sizing for BW/4HANA. See SAP Note 2296290. For hardware sizing to run a BW/4HANA
system, refer also to SAP Note 2363248 (see accelerator section).

Results
As a result, a first version of an action plan has been documented which could serve as the basis for a
project plan. A high-level transition planning document should be stored in SAP Solution Manager.

How SAP can Support

The Migration Planning Workshop for BW/4HANA (see task Transition Planning – In-Place Conversion)
can be enhanced with BPC-specific topics:
- Conversion steps
- Sizing approach

Accelerators
• Conversion Guide SAP BPC 11.0
• SAP Note 2383530 - Conversion from SAP BW to SAP BW/4HANA
• SAP Note 2531382 - BPC 11.0 version for SAP BW/4HANA - Installation and Conversion
Information
• SAP Note 2510414 - Conversion to SAP Business Planning and Consolidation 11.0, version for
SAP BW/4HANA Central Note
• SAP Note 2645732 – Conversion from SAP BPC NW to SAP BPC for BW/4HANA Central Note

2.8.5.Transition Planning – Remote Conversion

Objective
To perform a Remote Conversion, the first step is to install a brand-new SAP BW/4HANA system. A task
list is available that automates and therefore greatly simplifies the initial system setup.

The Remote Conversion approach enables you to move whole data flow or transfer only selected data
flows including the data from SAP BW 7.3 with any DB to a new installation of SAP BW/4HANA. You are
able to decide whether you want to build a clean system, leave old and unused objects behind, and
reduce unnecessary layers of your data warehouse. If applicable, the Remote Conversion process
includes a Unicode conversion. Carve-out scenarios are also supported.

Remote Conversions are based on new installations of SAP BW/4HANA. This approach is unique in that it
eliminates the need to convert an entire legacy system. No matter whether you run SAP BW on SAP
HANA or some other database, the Remote Conversion enables you to pinpoint the scenarios you want to
convert while still in an old system. These scenarios are then transferred into your fresh installation and
converted accordingly. You can then proceed with transferring data between your old and new installation.
The Remote Conversion is available for SAP BW 7.3 and later releases. Among other advantages, this
approach only includes objects that will remain relevant going forward and saves you the effort of
converting your database. It thus represents the chance to build a clean system, leave old and unused
objects behind while migrating to SAP BW/4HANA system.

Figure 2.5: Basic Sequence of the Remote Conversion

Benefits of Remote Conversion

• Efficient and lean transfer from SAP BW 7.3 or higher on anyDB to SAP BW/4HANA
• Tailors the scope of the migration to focus on relevant objects instead of converting the entire
system
• Leaves outdated and unused objects behind in the current data warehouse
• One-step approach for conversion as no prerequisites such as DB migration to SAP HANA or SAP
BW upgrade on the productive system are required
• Risk mitigation due to a parallel system. A copy of the data still remains in the source system during
conversion, hence the retrieval of original data is possible in case of errors
• Uses BW4/HANA Conversion Cockpit as a single point of control, monitoring, and documentation
• Retains business continuity during conversion

Procedure
For customers planning a Remote Conversion it is beneficial, too, to attend a Migration Planning
Workshop (MPW) to develop a customer-specific high-level project plan. See the detailed description of
the MPW in the task “Transition Planning – In-Place Conversion”.

How SAP Can Support

SAP offers the Migration Planning Workshop – see the task Transition Planning – In-Place Conversion.

In case the customer decides to perform Remote conversion, check the Prerequisites Checklist for the
Remote Conversion and identify the required preparation steps to get the system and data conversion-
ready.

Accelerators
• Technical Presentation on BW/4HANA
• Service Information – Service Components for Planning the Digital Transformation
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
 • Service Component Delivery Suitcase - Migration Planning Workshop for System Conversion (SAP
internal link)
• SAP Note 2383530 - Conversion from SAP BW to SAP BW/4HANA
• SAP Note 2296290 - New Sizing Report for SAP BW/4HANA
• SAP Note 2363248 – BW/4HANA Hardware Sizing
• SAP Note 2513088 – SAP BW/4HANA Conversion Cockpit – System Setup & Prerequisites

2.8.6.Remote Conversion with SAP BPC to SAP BPC 11.0

Objective
Remote conversion means that a completely new BPC 11.0 (on SAP BW/4HANA) system is installed next
to the productive BPC on anyDB system and all objects and data from BPC on anyDB are transferred into
the new BPC 11.0 (SAP BW/4HANA) system with on-the-fly transformation. As a consequence, there is
no need for a prior database migration or a BPC system upgrade.

Procedure
The Conversion Cockpit can be used for a remote conversion of BPC Embedded. However, this
procedure is currently only released in pilot mode.

Note: Please create an incident using the SAP Support Portal, component “EPM-BPC-BW4” with text
‘BPC 11.0 Embedded Remote Conversion’ in subject. SAP will process the ticket and guide you through
the steps to enable remote conversion.

Figure: Paths to SAP BPC 11.0 version for SAP BW/4HANA

The prerequisite for a remote conversion with the ConversionCockpit is that the following objects are not
in use:

▪ All ‘Local Objects’ (objects created directly in a system which can’t be transported),
including local InfoProviders, local models, local dimensions and master data, local
hierarchy and local queries

▪ BPC web templates, including reports and input forms

The remote conversion for BPC Standard is covered by the BPC-own “Backup and Restore Tool”
(transaction UJBR). An alternative remote conversion scenario for BPC Standard is not planned.

How SAP can Support

SAP offers the Migration Planning Workshop – see the task Transition Planning – In-Place Conversion.

The Remote conversion requires a Data Migration Assessment for Remote Conversion to SAP
BW/4HANA which has to take place in the Explore phase – see activity Data Migration Design.

Accelerators
• SAP Note 2531382 - BPC 11.0 version for SAP BW/4HANA - Installation and Conversion
Information
• SAP Note 2510414 - Conversion to SAP Business Planning and Consolidation 11.0, version for
SAP BW/4HANA Central Note
• SAP Note 2363248 – BW/4HANA Hardware Sizing (also relevant for BPC 11.0)
• Conversion Guide SAP BPC 11.0
• SAP Note 2602319 – Remote Conversion for BPC Embedded Model

2.8.7.Transition Planning – Shell Conversion

Objective
If you want a fresh start i.e. preferring a greenfield approach, a Shell Conversion might be what is best for
you. It is available for release 7.0 to 7.5 and works like a Remote Conversion using a parallel SAP
BW/4HANA landscape. Shell Conversion does not include the transfer and synchronization of existing
data sets. Instead at your convenience, you can choose to load data from original sources, load data from
original SAP BW system, or simply ignore historical data and start fresh.

Figure 2.6: Basic Sequence of Shell Conversion

Benefits of Shell Conversion compared to a Remote Conversion

The Shell conversion allows for a redesign in the target system as the objects initially are not filled in the
target. For the scope selection the shell conversion is more flexible compared to the remote conversion
because dependencies through request/transaction ID do not need to be considered

Requirements for original SAP BW system

 • SAP BW 7.0 to 7.5
• Any supported database platform
• Installation of SAP BW/4HANA Transfer Cockpit using support package or SAP Notes

Procedure
• New SAP BW/4HANA system is installed on additional hardware.
• Data models are transferred to target SAP BW/4HANA system using transports.

Neither master nor transaction data are transferred. Options at customer’s convenience:

• Reload data from original sources

• Load data from original SAP BW system
• Ignore historical data and start fresh

For customers planning a Shell Conversion it is beneficial, too, to attend a Migration Planning
Workshop (MPW) to develop a customer-specific high-level project plan. See the detailed description of
the MPW in the task Transition Planning – In-Place Conversion.

How SAP Can Support

SAP offers the Migration Planning Workshop – see the task Transition Planning – In-Place Conversion.

Accelerators
• Technical Presentation on BW/4HANA
• Service Information – Service Components for Planning the Digital Transformation
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• SAP Note 2383530 - Conversion from SAP BW to SAP BW/4HANA
• SAP Note 2296290 - New Sizing Report for SAP BW/4HANA
• SAP Note 2363248 – BW/4HANA Hardware Sizing

2.8.8. Transition Planning - System Consolidation

Procedure
System Consolidation to SAP BW/4HANA is ideal for SAP customers

• with multiple SAP BW, or SAP BW on SAP HANA systems, or hybrid cases, who want to perform
a consolidation into one global SAP BW/4HANA system or perform selective data migrations.

• who want to consolidate their landscape or carve out selected data models or flows into an
existing SAP BW/4HANA system

• who want to stay with their current data warehouse landscape and move gradually to SAP
BW/4HANA innovations

How SAP Can Support

System Consolidation is very customer-specific and can be conducted within a customer-specific project
with SAP.

2.8.9. Transition Project: Scope Definition & Objectives

Description
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 and the target solution landscape.
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,
e.g.

• Provision of new functionality

• Reduction of costs or complexity
• Performance improvements for specific business functions
• 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 transition project. Clarify and describe the 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 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 architecture and its mapping to the new hardware.

Additionally, components depending on the changed database or other changed components in the SAP
solution (e.g. the embedded Frontend Server for SAP Fiori) have to be detected to later verify how they
integrate with the future SAP solution.

Components in focus of the inventory are:

• SAP systems, both production and non-production

• Frontend infrastructure (server side)
• Operating systems
• Virtualization environments
• Server hardware
• File systems
• Storage infrastructures
• Software components directly interfacing with the source databases:
o High availability and disaster recovery solutions
o Backup solutions
o Monitoring solutions
o Software components accessing data within the target environment by direct access APIs
(libraries, ODBC, JDBC …), e.g. reporting, analytics or replication software.

Document the following findings:

• Components to be newly introduced

• Components, planned to be changed
• Components that interface with the components to be changed
For SAP systems and their databases document the following:

• Software compatibility statements / version requirements of the target environment database as

documented in the SAP Product Availability Matrix
• Current hardware, OS and virtualization platform versions
• Unicode enablement status of SAP systems
Verify and sign-off the scoping document. Upload all documents to the SAP Solution Manager so
information can be shared across the project team.
Results
As a result, there is a scope document available in SAP Solution Manager.
How SAP Can Support
Refer to the results of the workshops that have been performed (Migration Planning Workshop, SAP
BW/4HANA Discovery Workshop).

Accelerators
• SAP Product Availability Matrix
• SAP BW/4HANA Discovery Workshop

2.8.10. Clarify Operational Readiness

Description
With the introduction of a new solution like SAP BW/4HANA, your current IT support framework will
probably 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.

Accelerators
• Customer Center of Expertise
• Getting Started with Primary CCOE
• Primary CCOE Check List
• SAP Support Standards

2.8.11. Define Technical Architecture

Description
Depending on the SAP BW release and database at the beginning of the project, IT architecture will most
likely change (e.g. new HW, new OS, new HA/DR setup options…).

System Landscape of an In-Place Conversion

The system landscape for in-place conversion involves your original SAP BW system and one or more
source systems. The main activities performed in the system landscape during an in-place conversion
include scope transfers, which change selected objects to SAP HANA-optimized objects and might include
custom code adjustments, a technical system conversion to the target SAP BW/4HANA system, and some
post conversion tasks.
For an in-place conversion, the original SAP BW system needs to have a minimum release level. The
following start releases are supported:
 • SAP Business Warehouse 7.5 powered by SAP HANA (support package 5 or higher)
• An in-place conversion of SAP BW 7.51 or higher to SAP BW/4HANA is not possible (since SAP
BW/4HANA is based on SAP Basis 7.50)

Figure: System Landscape for In-Place Conversion

System Landscape of a Remote Conversion

The system landscape for the remote conversion typically involves an original (or sender) system, a target
(or receiver) system, and one or more source systems. The main activities performed in the system
landscape during a remote conversion include a scope selection, a transport handling and a data transfer.
Original (Sender) System
The original system is your existing SAP BW development (DEV), quality (QA) or production (PROD)
system. Original system must be set up as a control system for SAP Landscape Transformation.
Target (Receiver) System
The target system is the SAP BW/4HANA system, where the new and optimized SAP BW/4HANA objects
will reside.
The figure below shows a typical landscape and communication flow among the systems in a remote
conversion for transition SAP BW/4HANA.
Figure: System Landscape for Remote Conversion

For a remote conversion, the original SAP BW system needs to have a minimum release level. The
following start releases are supported:
• SAP Business Warehouse 7.3
• SAP Enhancement Package 1 for Business Warehouse 7.3
• SAP Business Warehouse 7.4
• SAP Business Warehouse 7.5

The remote conversion is independent of the database platform of your existing system (i.e. all supported
database platforms are allowed; see Product Availability Matrix). See the following table for minimum and
recommended support package level:

Figure 2.7: Release and Support Package Levels of the original SAP BW system

SAP BW/4HANA 2.0 exclusively runs on SAP HANA. It can be deployed on SAP HANA release 2.0 SPS
03 Revision 36.e

System Landscape for Shell Conversion

The system landscape for the shell conversion involves an original system, a target system, and one or
more source systems. The main activities performed in the system landscape during a shell conversion
include a scope selection, a transport handling, and optionally the load of historical data.

Original System
The original system is your existing SAP BW development (DEV), quality (QA) or production (PROD)
system.

Target System

The target system is the SAP BW/4HANA system, where the new and optimized SAP BW/4HANA objects
will reside.

The figure below shows a typical landscape and communication flow among the systems in a shell
conversion for transition SAP BW/4HANA.

Figure: System Landscape for Shell Conversion

Requirements and Constraints

There is an implementation road map (high level) available describing the “to-be” business architecture of
SAP BW/4HANA.

Invite your hardware provider to join this task.

Procedure
If not done in the Discover phase (activity Strategic Planning):

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

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 technical
design of a scalable, flexible, and maintainable SAP solution that fits to their specific requirements. Ideally,
the information described in the procedure (above) should be provided by the customer beforehand.

This is especially relevant when customers plan to migrate/transition to SAP HANA and SAP BW/4HANA
which introduces often new IT infrastructure platforms to an existing SAP environment. In case of such a
transition, the new sizing report for SAP BW/4HANA can be used – SAP Note 2296290. Here is an
example output of the report:
Figure 2.9: Output of a Sizing Report

In case of a new implementation a basic sizing will be done during the Technical Architecture and
Infrastructure service component with the SAP Quicksizer, see accelerator section:
 Figure 2.10: SAP BW/4HANA view in the SAP Quicksizer

The Quicksizer results are rough estimations which should be verified with the hardware partner. An
advanced sizing is recommended during the Explore phase.

Accelerators
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• SAP Note 2021789 - SAP HANA Revision and Maintenance Strategy
• SAP Note 2363248 - BW/4HANA Hardware Sizing
• SAP Note 2296290 - New Sizing Report for SAP BW/4HANA
• SAP Quicksizer

Transition Preparation
Description
This activity covers all preparation work which happens before the project starts. Depending on the type of
conversion (in-place or remote) there might be larger ‘pre’-projects required, which must be identified and
scheduled right before the SAP BW/4HANA transition project starts.

However, significant preparation items should have been discussed in the appropriate planning workshops
in the Transition Planning activity upfront.

Examples for in-place system conversion preparation activities could be:

• Migration from anyDB to SAP HANA

• Unicode Conversion
• Upgrade from an older SAP BW like SAP BW7.4 to SAP BW7.5

Examples for in-place and remote conversion preparation activities could be:

• Clean-up unused custom code

• Identify critical custom code

Requirements and Constraints

The transition preparation activity is mainly required for the in-place system conversion. It relies on
findings from the Transition Planning activity.

Procedure
• Execute on Follow-Ups from Transition Planning

2.9.1.Execute on Follow-Ups from Transition Planning

Objective
The goal of this task is to 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
activity.
 • 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 and services for typical preparation activities in case of a system
conversion, for instance: Migration of any database to SAP HANA, release upgrade of SAP BW, notes
implementation, Unicode conversion. For details of possible steps see also next task (Transition
Preparation for In-Place System Conversion).

2.9.2.Transition Preparation for In-Place System Conversion

Objective
Parts of the transition preparation can be:

• Migration from anyDB to SAP HANA

• Unicode Conversion
• Upgrade from an older SAP BW like SAP BW7.4 to SAP BW7.5
• Implementation of required SAP Notes
• Work through all gaps which have been identified in the readiness check

Procedure
These preparation steps differ very much in time and effort. Most of them like the database migration and
the SAP BW upgrade, but also the Unicode conversion should be set up as separate projects.

In the Migration Planning Workshop, a mandatory check has been performed to identify which
requirements are still open before the system conversion to SAP BW/4HANA can be performed. All these
identified steps should either be performed here or in the activity Prep Steps & Data Model Adjustment in
the Explore phase.

For a migration from anyDB to SAP HANA, you should run the HANA BW sizing report to get information
about the hardware resources required to migrate onto HANA. Refer to SAP Note 2296290 –New Sizing
Report for SAP BW/4HANA. See accelerator section for details.

Results
The system is now on release SAP BW7.5 on SAP HANA. As a next step, the BW/4HANA Starter Add-on
will be installed.

How SAP Can Support

On help.cap.com SAP offers the SAP BW/4HANA Master Guide as well as the Conversion Guide for SAP
BW/4HANA 2.0 (pdf) with detailed information on required preparation steps for the conversion to SAP
BW/4HANA and all required SAP notes. SAP supports customers with separate projects to run a database
migration or an SAP BW upgrade. These should be planned as sub projects to the transition to SAP
BW/4HANA.

Accelerators
• Conversion Guide for SAP BW/4HANA 2.0

• SAP Note 2296290 - New Sizing Report for SAP BW/4HANA

2.9.3.Cleanup Unused Custom Code
Objective
Unused or unnecessary custom code e.g. in transformations should be decommissioned to reduce
maintenance and adjustment efforts. This task goes along with a simplification of the data model by
removing persistency layers and the related transformations in DTPs.

An SAP BW/4HANA conversion also might require a significant amount of effort to adjust custom coding in
transformations, user exits and Z-Programs due to the following reasons:

• ABAP Syntax corrections in case involved data structures or function modules have changed
or were removed (user exit for authorization check has been converted into a BadI)
• Syntax corrections to avoid data inconsistencies (e.g. missing ‘order by’ with HANA DB could
cause unexpected results when data is processed in internal tables)
• HANA-optimized programming to achieve quick wins from performance perspective and to fulfill
performance KPIs.

SAP Standard tools like ATC (ABAP Test Cockpit or formerly known as ABAP Code Inspector) are not
able to identify all custom code in BW systems as some custom code (e.g. in BW transformations) is
generated in the development package SAP and not in the customer name space.

Due to this reason there are additional tools required for analyzing all custom code in BW systems, which
are described in the SAP Note 2462639 - BW4SL – Interfaces and Customer-Specific ABAP
Development.

The objective of this task is to decommission custom code which is not in use upfront of a system
conversion.

Procedure
Proceed as follows:

• Set up the Decommissioning Cockpit in SAP Solution Manager. Decommission unused

custom code as documented in the Accelerators 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.

How SAP Can Support

As part of the Migration Planning Workshop the procedures and tools for analyzing ABAP custom code
are introduced and described to the customer.

In case more help is required to interpret the results of the analysis tools and get help in transforming the
ABAP code properly to achieve maximum benefit, SAP provides a service component, which is called
Custom Code Impact Analysis. For details see the activity Custom Code Impact Analysis in the Explore
phase.

Accelerators
• SAP Note 2462639 - BW4SL - Interfaces and Customer-Specific ABAP Development
• ABAP custom code adaption for SAP HANA – the efficient way
• Decommissioning with CCLM in Solution Manager SP12
• ABAP Test Cockpit
• Setup of the Usage & Procedure Logging
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
2.9.4.Identify Critical Custom Code
Objective
The objective of this task is to improve the software quality of your custom code upfront of a system
conversion.

Procedure
Proceed as follows:

• Set up an efficient custom code quality management process and project

• Implement SAP Note 1847431 - SAP BW ABAP Routine Analyzer
• Implement general SAP Software Quality check tools, like SAP ABAP Test cockpit or SAP
Code Inspector

Results
Existing custom code will be adjusted or improved, and new ones will be created with the necessary
quality level.

How SAP Can Support

See SAP offering Migration Planning Workshop and Custom Code Impact Analysis to get help in
transforming the ABAP code properly to achieve maximum benefit.

Accelerators
• SAP Note 1847431 - SAP BW ABAP Routine Analyzer

2.9.5.Set up and configure SAP Solution Manager

Objective
SAP recommends using SAP Solution Manager 7.2 with latest support pack to support the project
execution. See the accelerator section for detailed information on the delivery infrastructure.

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:
o You plan the implementation (such as scope, hardware and software requirements,
and release restrictions).
o You plan the system landscape for your use cases.
o You install the components of your SAP Solution Manager system.
o You configure your system.
o You set up the connection to the managed systems.
• Once SAP Solution Manager is set up, the following areas are key for project support:
o Solution Implementation – the identification, adaptation, and implementation of
new and enhanced business scenarios.
o Solution Documentation – centralized documentation repository ensuring the
relationship of business process definitions with technical configuration decisions.
o 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 to use the SAP Solution Manager Focused Build service solution.
Additional details can be found in the accelerator section.

Results
You have set up SAP Solution Manager and have configured it for project support.

How SAP Can Support

SAP offers a workshop on Agile Implementation Methodology and Tool Coach.

SAP can 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).

In addition, SAP supports this activity with the “SAP Solution Manager Starter Pack” service
component. The SAP Solution Manager Starter Pack is applicable when you need direct assistance with
the basic configuration and use of the SAP Solution Manager.

Accelerators
• Service Information - Value Assurance Foundation
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• SAP Digital Business Services (DBS) Delivery Infrastructure
• SAP CAL
• SAP CAL at SAP SCN
• Focused Build for SAP Solution Manager
• Implementation of SAP Solution Manager for IT Operations
2.9.6.Perform Data Volume Planning
Objective
Data volume planning is the starting point of data volume management to analyze the current database
and determine how much data can be archived or deleted upfront of a conversion to SAP BW/4HANA.

Data Volume Management should be considered prior to a system conversion, in order to reduce the
amount of data to be converted (has implications on duration / downtime of the cutover) as well as to
reduce the amount of data in memory (has implications of hardware costs). The Data Volume Planning
service component is indicated especially if:

• The database size is greater than 500 GB and/or

• The database grows faster than 20 GB per month

Procedure
A detailed look at the system identifies the major pain points and gives an outlook on the most beneficial
measures to take (for example, deletion or data archiving) when implementing a data volume strategy. In
some cases, the implementation of an enhanced data volume reporting may be the most reasonable first
step to take in case the data on the system is still young and therefore the expected effect of a data
volume strategy may be small. One central tool supporting data volume reduction is the SAP DVM Work
center in SAP Solution Manager, including tools with a special focus on SAP HANA.

• Guided Self Service:

You can generate a best practice document to determine datathat can be reduced most efficiently
in an SAP system before the conversion. You can use the same tool after the conversion to develop
a blueprint for a DVM strategy.
• Reorganization and Compression: You can use this tool without an SAP HANA contextin order to
simulate the savings gained by reorganizing tables or databases or compressing the database.
• In addition, you can simulate the future system size of your system. This is useful fora forecast of
the impact any planned measures may cause.

Results
A decision and road map on how to proceed with DVM upfront of a transition to SAP BW/4HANA.

How SAP Can Support

In general, the service component starts with a detailed remote data analysis in order to determine the
most relevant business objects for data reduction with their available reduction methods, the distribution
across fiscal years (data growth) and dependencies on the service type status values as well as possible
dependencies to other documents. Based on such detailed analysis of data volume strategy a data
management and data archiving strategy will be developed, based on general SAP best practices.

Accelerators

• Service Information – Service Components for Safeguarding the Digital Transformation

• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
 Execution, Monitoring, and Controlling of Results
Description
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.

Tasks
• Direct and Manage Project Execution
• Monitor and Control Project Activities
• Manage Issues, Risks and Changes
• Communicate Status and Progress to Project Stakeholders

Accelerators
• Project status report for SAP Activate / S/4HANA

2.10.1. Direct and Manage Project Execution

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

Accelerators
• Backlog including Delta Requirements and Gaps.xlsx

2.10.2. Monitor and Control Project Activities

Objective
The purpose of this activity is to ensure that resources are assigned to all scheduled project activities (and
tasks) and that work is progressing, and deliverables are produced as expected.

Accelerators
• Backlog including Delta Requirements and Gaps.xlsx

2.10.3. Manage Issues, Risks, and Changes

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

Accelerators
• Change Request Log - template (Customer)
• Open Issues List Template.xls (Customer)

2.10.4. Communicate Status and Progress to Project Stakeholders

Objective
The purpose of this activity 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.
Accelerators
• Project status report for SAP Activate / S/4HANA
• Steering Committee Presentation Template (Customer)
• Team Status Report Template (Customer)

Organizational Change Management Roadmap

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

Tasks
• Prepare Organizational Change Management Roadmap
• Conduct OCM Workshop with Project Manager and all Project Workstreams Owners.

Accelerators
• Organizational Change Management Guide (Customer)

2.11.1. Prepare Organizational Change Management Roadmap

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

Accelerators
• OCM Roadmap Presentation Sample (Customer)

2.11.2. Conduct OCM Workshop with Project Manager and all Project Workstream Owners
Objective
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.

Phase Closure and Sign-Off phase Deliverables

Description
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

Tasks
• Conduct Knowledge Management Gate
• Conduct Project Quality Gate
• Conduct Project Management Review Service
• Obtain Customer Sign-Off for Phase Completion
2.12.1. Conduct Knowledge Management Gate
Objective
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.

Accelerators
• Lessons Learned Guide (Customer)
• Lessons Learned Template (Customer)

2.12.2. Conduct Project Quality Gate

Objective

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 that deliverables have 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: New additional key deliverables need to be added in the quality gate checklist by the Project
Manager to the different project types.

Accelerators
• QGateChecklist Concept SAP Activate
• QGateChecklist Template Introduction
• Quality Built In New QGate Checklist

2.12.3. Conduct Project Management Review Service

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

2.12.4. Obtain Customer Sign-Off for Phase Completion

Objective
Purpose of this task is to obtain customer approval (sign-off).

Accelerators
• Phase Sign-Off Template (Customer)
3. Explore Phase
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.

Figure 3.1: Activities in the Explore Phase

In the Solution Adoption work stream, the training strategy is developed for the end users.

In the Application Design & Configuration work stream, the Data Model Adjustment takes place and the
data/object transformation process coming in the Realize Phase is prepared. Especially for New
Implementation scenarios, customers should attend the BW/4HANA Enablement service to get familiar
with the BW/4HANA concept and functionality, but also for conversion scenarios to learn how to use the
conversion tools. Security Design should be done in this phase, too.

The conversion to SAP BW/4HANA may impact your custom code. In the Extensibility 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 (Testing work stream).

Analytics: The Analytics work stream contains the Analytics Design, offering the Analytics Design
Workshop which helps to create a detailed road map and blueprint, and explains the new data models in
BW/4HANA to enable the customer to start with the data model adjustment.

In the Data Management work stream, data load needs to be prepared and planned for the new
implementation or a selective data transition. In the Data Volume Design activities, a scoping for data
volume management (DVM) is defined and the strategy for DVM is developed which will be executed in
the Realize phase.

The technical design document is created in the Technical Architecture and Infrastructure 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 can be
created for technical and functional experience gathering. Of course, it depends on the scenario how the
sandbox is created. At the end of the Explore phase the DEV environment needs to be set up (again
scenario specific).

Operations & Support runs an Operations Impact Analysis, to identify IT Support operational areas that
require adjustment to safely and efficiently operate the new system as of Go-Live. The actions taken here
depend on the SAP operational experience of the customer.
 Phase Initiation
Description
The purpose of the phase initiation deliverable is to formally recognize that a new project phase starts.

Tasks
• Review Deliverables of Explore Phase

• Review Acceptance Criteria

• Review RACI Chart for Explore Phase

3.1.1. Review Deliverables of Explore Phase

Objective
The purpose of this task is to review all Deliverables of the Explore Phase with the Customer.

3.1.2. Review Acceptance Criteria

Objective
The purpose of this task is to review the acceptance criteria with the Customer.

3.1.3. Review RACI Chart for Explore Phase

Objective
The purpose of this task is to review the RACI Chart for the Explore Phase with the Customer.

Execution, Monitoring, and Controlling Results

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

Tasks
• Update Project Management Plan
• Direct and Manage Project Execution
• Conduct SCRUM Meetings
• Monitor and Control Project Activities
• Manage Issues, Risks and Changes
• Communicate Status and Progress to Project Stakeholders

3.2.1.Update Project Management Plan

Objective
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.
 3.2.2.Direct and Manage Project Execution
Objective
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.

Accelerators
• Backlog including Delta Requirements and Gaps.xlsx

3.2.3.Conduct SCRUM Meetings

Objective
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 the 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 the 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.

Accelerators
• Agile Scrum Meeting Guidelines (Customer)

3.2.4.Monitor and Control Project Activities

Objective
The purpose of this activity is to ensure that resources are assigned to all scheduled project activities (and
tasks) and that work is progressing, and deliverables are produced as expected.

3.2.5.Manage Issues, Risks and Changes

Objective
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.
Accelerators
• Change Request Log - template (Customer)
• Open Issues List Template.xls (Customer)

3.2.6.Communicate Status and Progress to Project Stakeholders

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

Accelerators
• Project status report for SAP Activate / S/4HANA

Planning
Description
The detailed project planning started in the Prepare phase and is continued across the Explore phase.

The aim is to constantly adapt and refine the initial plan from the Prepare phase. In particular, the
implications from the Fit / Gap workshops need to be included in the project plan.

Requirements and Constraints

This activity is required for all scenarios.

Procedure
• Refine Project Planning

3.3.1.Refine Project Planning

Objective
The goal of this task is to refine the project plan based on the learnings and decisions from the Explore
phase. This task continues throughout the Prepare and Explore phase.

Procedure
• 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 (see
accelerator section).

Please make sure to include the results from the ”Application: Design & Configuration” work stream so far.

Accelerators
• Explore phase of SAP Activate road map “SAP Activate methodology for Business Suite and On-
Premise – Agile”
 Learning Design
Description
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 scenarios. 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.

3.4.1.Develop a Training Concept

Objective
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
To develop a training concept for key users and end users, proceed as follows:

• 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 and coaching in alignment with the project plan
• Per future role, assign users to trainings.

Please keep in mind:

• Skill levels, knowledge gaps, and training requirements could depend on the location of end users.
• Special care needs to be taken for key users:
o 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.
o Key users could potentially support and run end-user trainings.
o 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 to 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.

Accelerators
• Service Information – Service Components for Functional Design
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• SAP BW/4HANA Learning Journey
 Organizational Change Management (OCM)
Description
The planning and execution of Organizational Change Management in the context of an SAP
implementation has been described in detail already. Most current information on Organizational Change
Management can be found in the road map “SAP Activate methodology for Business Suite and On-
Premise – Agile”. See the accelerator section for a link. In the context of SAP Activate, Organizational
Change Management is part of the “Solution Adoption” work stream (the Road Map Viewer offers to filter
on work stream names).

Procedure
• Execute Change Impact Analysis

Accelerators
• SAP Activate road map “SAP Activate methodology for Business Suite and On-Premise – Agile”
3.5.1.Execute Change Impact Analysis
Objective
The objective of this task is to execute an organizational change impact analysis.

Procedure
Execute a Change Impact Analysis as documented in SAP Activate.

Follow the link in the accelerator section, and run the analysis as described in the road map “SAP Activate
methodology for Business Suite and On-Premise – Agile”.

Accelerators
• Change Impact Analysis in the SAP Activate road map “SAP Activate methodology for Business
Suite and On-Premise – Agile”

Prep Steps for Conversions

Description
If you want to run an in-place conversion or a remote conversion you should perform the required
preparation steps as shown in the figure below.

Figure 3.2: Preparation Steps for the in-place and remote conversion

Procedure
• Use the Maintenance Planner to prepare the installation of the SAP BW/4HANA Starter Add-on (in-
place conversion)
• Run the “Pre-Checks” (program RS_B4HANA_CONVERSION_CONTROL and Simplification List
for SAP BW/4HANA)
• Install SAP Notes for the installation of SAP BW/4HANA Add-On (if required)
• Run the Custom Code Check (see Activity Custom Code Impact Analysis)

Make yourself familiar with the new data model and concept in SAP BW/4HANA and the conversion tools
offered by SAP. A good starting point is the SAP First Guidance – complete functional scope (CFS) for
SAP BW/4HANA (see accelerator section).

How SAP Can Support

SAP offers an Analytics Design Workshop (ADW) which helps in refining the implementation aspects
and creating a transition project plan for moving the existing Analytics solution landscape to SAP
BW/4HANA. The workshop offers empowerment options to better understand implementation aspects and
the new modelling concept and gives a good basis for the data model adjustment. For more information
on the ADW, see the activity Analytics Design.

In addition, SAP offers an Enablement Service for SAP BW/4HANA which is offered as SAP Professional
Service (CRM 50139425). It gives an introduction and enablement for the next generation data
warehousing with SAP BW/4HANA. The following topics can be covered (optionally):

• Modelling for BW/4HANA

• Query Building (Eclipse-based)
• ETL Processes
• Transporting
• SQL Based Data Warehousing
• Data Acquisition (SDI /SDQ)
• Data Management
• Reporting
• Conversion Tools
•

Accelerators
• Service Information – Service Components for Analytics Design
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• SAP First Guidance – complete functional scope (CFS) for SAP BW/4HANA
• SAP Note 2432247 – SAP Best Practices for in-place system conversion for SAP BW/4HANA
(attached: Configuration Guide – Getting Started with Implementing the SAP Best Practices for in-
place system conversion for SAP BW/4HANA V1.10)
• Enablement Service for SAP BW/4HANA

3.6.1.Prepare the Use of the Maintenance Planner

Objective
Besides the general preparation described in the Maintenance Planner User Guide, you have to make the
following preparatory steps specific to the conversion to SAP BW/4HANA 2.0:

Procedure
Setup the Maintenance Planner as described in the Maintenance Planner User Guide available at
help.sap.com/maintenanceplanner.

2. For in-place conversion, download the Software Update Manager (SUM 2.0 SP 05)

The following steps are only required, if you use SAP Solution Manager:

3. Apply SAP Note 2186164 to your SAP Solution Manager system.

4. Create an RFC-connection between your source release system and SAP Solution Manager:

a) In SAP Solution Manager, choose SOLMAN_WORKCENTER Solution Manager Administration

Landscape (Technical Systems).

b) Click RFC connections Start New Window.

c) Select client 000 and choose Advanced Mode.

d) Under Export Options, fill in the field SAP Solution Manager Host Name.

e) Under Communication RFCs, select Create SM_<SID>CLNT<CLNT>_READ.

f) Select Create New User.

g) Enter a password.

h) Enter a user and password under Managed System Setup Administrator and choose Test Login in the
group Administration Users to check that it works.

Results

Maintenance Planner is ready for the software downloads required for conversion.

Accelerators
• SAP Note 2383530 - Conversion from SAP BW to SAP BW/4HANA
• Maintenance Planner Information (Blogs.sap.com)
• Maintenance Planner (Support Portal)

3.6.2.Install and Run the Pre-Checks

Objective
SAP supports your conversion project by providing pre-checks that identify some important steps you need
to take to ensure your system is compatible with the conversion process.

Perform these checks before starting the realization phase, in order to have enough time to solve any issues
before starting the conversion processes.

Pre-checks are shipped to customers that want to convert to SAP BW/4HANA in the form of SAP Notes.
Customers can use these pre-checks to find out what mandatory steps they must carry out before
converting to SAP BW/4HANA. The results list the instances that need to be addressed before attempting
the conversion process.
Procedure
• Follow the instructions provided in SAP Note 2383530 and use the SAP BW Note Analyzer to install
the pre-check tools (see Appendix Landscape Preparation for more details). Make sure to use latest
version of this SAP Note and regularly check for updates of the attached XML files. Implement and
run the SAP BW Note Analyzer in your development system and transport the recorded changes to
the other systems in your landscape (quality assurance, consolidation, production). Then run the
SAP BW Note Analyzer again in the other systems to validate that all changes are applied correctly.
• After the installation, you can also check if the tools are up-to-date directly in the SAP BW/4HANA
Transfer Cockpit.
• You need authorization for authorization objects S_RS_B4H.
• Start the Transfer Cockpit (transaction RSB4HCONV) and execute the pre-check (this executes
program RS_B4HANA_CONVERSION_CONTROL).
•

Results
The pre-check program determines which objects are compatible with SAP BW/4HANA and which objects
are not available in SAP BW/4HANA and can be automatically converted, deleted, or need manual
adjustments. The pre-check then provides links to the documentation of the corresponding Simplification
Items (i.e. the matching SAP Notes). Refer to the Conversion Guide for SAP BW/4HANA 2.0, chapter 3.11,
for detailed documentation.

Accelerators
• SAP Note 2383530 - Conversion from SAP BW to SAP BW/4HANA
• Conversion Guide for SAP BW/4HANA 2.0
3.6.4. Prepare the Installation of the SAP BW/4HANA Starter Add-on
Objective
The SAP BW/4HANA Starter add-on is an SAP NetWeaver add-on that supports you when performing an
in-place conversion of an SAP BW 7.5 system running on an SAP HANA database as its primary
database. You can implement the SAP BW/4HANA Starter add-on as of SAP BW 7.5 Support Package
Stack 5 and use it to prepare a conversion of the system to SAP BW/4HANA.Before the Add-on can be
installed, it may be necessary to install corresponding SAP Notes,

Procedure

Follow the instructions for the preparation steps under “Installing the SAP BW/4HANA Starter Add-on”
in the Conversion Guide for SAP B/4HANA 2.0, chapter 4.2:

• Update Software Patch Manager and Add-on Installation Tool

• Download Software using Maintenance Planner

Results

The BW/4HANA Starter Add-on can be installed.

How SAP Can Support

SAP offers SAP Notes which give guidance for the handling and usage of the SAP BW/4HANA Starter
Add-on (SAP Note 2189708) and for prerequisites and installation (SAP Note 2246699). Refer to the
Accelerators section for details.

Accelerators

• SAP Note 2189708 – SAP BW/4HANA Starter Add-On -Handling and Usage
• SAP Note 2246699 – SAP BW/4HANA Starter Add-On – Pre-Req/Installation/De-
Installation/Update
• Conversion Guide for SAP BW/4HANA 2.0

3.6.5.General Application Preparations for in-place Conversion

Objective
Before starting in-place conversion activities, you need to do the preparatory activities described in this
section.

Procedure
Remove Client 066

Client 066 had been used to deliver services by SAP Active Global Support (SAP NetWeaver 7.4 and
older). This client is not used anymore, therefore you can safely remove the client 066 if available. The
client is not used in SAP BW/4HANA either. To prevent issues, for example, with job scheduling, you have
to remove it before starting the system conversion. To remove client 066, proceed as described in SAP
Note 1749142.

Uninstall Add-ons
If you have add-ons (from SAP or other vendors) installed on your SAP BW system that are not released
for SAP BW/4HANA 2.0, you need to uninstall them. If you do not uninstall these apps, the Maintenance
Planner will not allow a conversion of your system.

1. Check SAP Note 2189708 for a list of add-ons that are not compatible with SAP BW/4HANA 2.0 and
must be uninstalled.

2. If you have an add-on installed on your system which is not supported anymore on SAP BW/4HANA,
prior to the system conversion, the add-on must be uninstalled.

3. A list of add-ons which can be uninstalled is available in SAP Note 2011192.

4. If your add-on is not listed there, please open a customer incident on the component BW-B4H-LM.

Uninstall SAP Fiori Apps

If you have SAP Fiori apps installed locally on your SAP BW system, you need to uninstall them, if they
are not released for SAP User Interface Technology 7.50 or higher (SAP_UI 7.50, 7.51 or 7.52). If you do
not uninstall these apps, the Maintenance Planner will not allow a conversion for your system.

Check SAP Note 2034588 for a list of apps that you need to uninstall, and the steps required to do so.
Uninstall the apps using SAINT. For more information, see SAP Note 2011192.

Results
You have performed all preparatory steps for the in-place conversion.

Accelerators
• Conversion Guide for SAP BW/4HANA 2.0

3.6.6.General Application Preparations for Remote Conversion

Objective
Executing a scope transfer during a remote conversion will require additional disk space that you have to
provide.

Procedure
Provide enough free disk space in the original and target system to store about 20 percent of the expected
data volume to be transferred. If, for example, you want to transfer one terabyte of data from the original
system, to the target system, ensure that you have 200 GB of free disk space in the original system. SAP
BW/4HANA Conversion Cockpit compresses the data for transfer and uses the free space in the original
system to store the data in the table cluster CNVLTRL_BWCLU. You can reclaim the hard disk space after
the scope transfer is completed.

Results
There is enough disk space available for the scope transfer during the remote conversion.

Accelerators
• Conversion Guide for SAP BW/4HANA 2.0
3.6.7.Installation of SAP Landscape Transformation add-on for Remote Conversion
Objective
Carry out the following preparation in the sender, receiver and the ERP systems:

• Install the prepare package as described in SAP Note 2383530.

• Install the Landscape Transformation add-on on the original SAP BW system (sender), target SAP
BW/4HANA system (receiver) and control system (if one is available). (See SAP Notes 1577441,
1577503, 1648747)
• Install ODP-related notes in your source systems as described in SAP Note 2383530.
• Define authorization roles in the customer system.

Procedure
Follow the description on Installing SAP Landscape Transformation Add-on in the Conversion Guide for
SAP BW/4HANA 2.0.

Results
The system is now ready for Remote Conversion with the sender, receiver and control systems set up.
Accelerators
• Conversion Guide for SAP BW/4HANA 2.0
• SAP BW/4HANA Master Guide
• SAP Note 2383530: Conversion from SAP BW to SAP BW/4HANA

3.6.8.Check the list of object-specific Preparations

Objective
There may be also application-specific preparation steps you have to perform for an in-place, remote, or
shell conversion. These steps are all part of the Simplification List, the most important ones are also listed
in the Conversion Guide.

Procedure
Check the list of object specific preparations in the Conversion Guide and perform the mandatory steps
described in the corresponding SAP Notes.

Results
The application-specific preparation steps are performed.

Accelerators
• Simplification List
• Conversion Guide for SAP BW/4HANA 2.0

Data Volume Design

Description
Data volume design is the follow-up of data volume planning. It should support the implementation of a data
management and data archiving strategy or alternatively supports the assessment of existing strategies.
Requirements and Constraints
This activity is of general interest for all scenarios.

3.7.1 Define Data Volume Strategy

Objective
Based on the analysis results from the data volume planning, the blueprint of a data management and
archiving strategy is developed from a technical point of view and using general SAP best practices. In the
second phase, the data volume strategy is realized.

Procedure
• determine the type and amount of data that can be archived, as well as the corresponding archiving
objects
• reveal connections between tables and archiving objects
• provide information on which archiving objects should be used and in which order and frequency
• consider retention periods as well as the requirements of your business teams
• maintain the customizing for the archiving objects and the definition of archiving selection variants
• test archiving of some documents to demonstrate the retrieval of archived data

Results
There is a documented and implemented strategy on Data Volume Management.

How SAP Can Support

Data Volume Strategy is part of the Data Volume Management (DVM) service component. Data Volume
Strategy includes all necessary steps to prepare for the implementation and for the assessment of the
following methodologies:

• Data avoidance
• Data summarization
• Data deletion
• Data archiving

During the test archiving as preparation for Go-Live, the service also offers assistance, if help is required
on performing mass tests and performance tests.

Accelerators
• Service Information – Service Components for Safeguarding the Digital Transformation
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
 Security Design
Description
SAP BW/4HANA uses the user administration and authentication mechanisms from the Application Server
for ABAP. The security recommendations and guidelines for user administration and authentication
described in the Security Guide for SAP NetWeaver Application Server for ABAP therefore also apply
to SAP BW/4HANA. In addition to these guidelines, SAP provides information about user administration
and authentication that specifically applies to SAP BW/4HANA.

Requirements and Constraints

Security Design should be a part of every transition scenario.

The SAP BW/4HANA conversion project involves many areas of the SAP BW due to its technical
complexity. This results in a comparably large involvement of business users and IT users during the
project. IT users are responsible for all IT administration and remodeling tasks which will mainly arise
during the project and business users will be affected by necessary testing activities after changes
occurred. The use of the Transfer Cockpit in productive systems could require special alignment between
business users who are owners of business processes and their data and the IT users responsible for
transferring the data flow including the inherent data to new SAP BW/4HANA supported objects. During
the scope transfer of a dataflow/unsupported BW objects the data of the involved InfoProviders needs to
be accessed. For a period of time the authorizations to access the InfoProviders data must be assigned to
the executing user of the Transfer Cockpit.

Procedure
Supply the affected data owners with the authorization for the Transfer Cockpit and execute the tested
and prepared Transfer Cockpit scenario in the productive environment.

3.8.1. Run Authorization Concept Check and Adoption

Description
During a scope transfer with the Transfer Cockpit, legacy objects will be replaced by their HANA-optimized
counterparts (e.g. InfoCube by DataStore object (advanced ADSO)). After the transfer, the user needs a
proper authorization for the HANA-optimized object instead of the legacy object (e.g. InfoCube).

Procedure
After the SAP BW/4HANA Conversion authorization objects need to be adjusted, for more information
please check SAP Note 2468657 BW4SL Standard Authorizations which contains a list with SAP BW
authorization objects and their availability in SAP BW/4HANA.

Results
You are able to implement SAP BW analysis authorizations and SAP HANA analytics privileges.

How SAP Can Support

SAP supports the security design with a Security Design Workshop. With the SAP Security Design
Workshop for SAP BW/4HANA, customers who are implementing SAP BW/4HANA with or without mixed
modeling, get guidance, best practice information and knowledge transfer about SAP BW analysis
authorizations and SAP HANA analytical privileges.
Accelerators
• Service Information – Service Components for Functional Design
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• SAP BW/4HANA Security Guide
• SAP Support Portal – Security Page
• SAP WIKI: Security Relevant Checks in Configuration Validation
• SAP Note 2468657 – BW4SL Standard Authorizations
 Analytics Design
Description
Based on the findings from the Discover phase, which the customer typically has derived in an Analytics
Strategy Workshop, now the analytics design needs to be done in detail with a detailed roadmap and
project plan.

Requirements and Constraints

The high-level analytics architecture should have been defined in the Discover phase.

3.9.1 Run an Analytics Design Workshop

Objective
The customer needs to get an in-depth technical understanding of the new SAP Analytics technology
coming with SAP BW/4HANA and has to define all required steps in the detailed roadmap which are
necessary for the transition of the existing analytics landscape to SAP BW/4HANA.

Prerequisites
Ideally, an analytics strategy workshop has already been conducted to define the strategic SAP solution
components for analytics, resulting in a target analytics architecture. Alternatively, the customer has
already conducted similar activities to get familiar with strategic SAP analytics solution components
around SAP S/4HANA embedded analytics, enterprise data warehousing (SAP BW based, or SAP HANA
based), and the BI strategy (SAP Analytics Cloud, SAP Digital Boardroom, and SAP BusinessObjects BI
platform), and defined a strategic analytics infrastructure.

Procedure
• The outcome of the Analytics Strategy Workshop and the Migration Planning Workshop should
be a high-level architecture for the target solution landscape and a filled checklist of the mandatory
preparation steps for the system conversion. Based on these outcomes, the detailed roadmap and
the detailed project plan should be created.
• Customer should be empowered to understand all aspects of the data model transformation to SAP
BW/4HANA
• Model a blueprint for the target architecture with integration of BW and HANA models

Results
The target architecture has been defined and a detailed project plan is available. The customer is
prepared to perform the preparation steps and start the actual configuration of the data models for the
system conversion (activity Prep Steps and Data Model Adjustment).

How SAP Can Support

SAP offers the Analytics Design Workshop which covers

• Detailed design of the target architecture

• the creation of the detailed roadmap and project plan
• the Empowerment of the team to understand the implementation/conversion aspects
• modeling of a blueprint
Figure 3.7: Topics covered in the Analytics Design Workshop

The Analytics Design Workshop ideally refers to the results of the Analytics Strategy Workshop and a
Migration Planning Workshop. A scoping process prior to the workshop helps to tailor the service to the
customer requirements.

Accelerators
• Service Information – Service Components for Analytics Design
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions

Custom Code Impact Analysis

Description
As part of the transition or system conversion, customers need to identify code, that has to be adjusted
(“must-do’s”), and code 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 BW/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
1. Run a custom Code check an perform Adoption

Results
Custom code is checked, and issues are solved.

3.10.1. Perform Custom Code Check and Adoption

Objective
As documented in other simplification items, SAP BW/4HANA provides many simplifications of application
functionality compared to SAP BW. Therefore, many programs, function modules, and classes (millions of
lines of standard code) and thousands of standard dictionary objects of SAP BW are not available in SAP
BW/4HANA. Any use of such objects needs to be replaced in custom code. It's recommended to use only
documented standard interfaces (API).
SAP BW-specific customer enhancements (often called "customer exits", transaction CMOD) are not
available in SAP BW/4HANA. For several SAP BW releases, SAP has offered corresponding
enhancement spots. If customer enhancements are used in SAP BW, the code will have to be adjusted
and converted to enhancement spots in SAP BW/4HANA.

Procedure
Check SAP Note 2462639 BW4SL Interfaces and Customer-Specific ABAP Development and analyze
your custom coding with the according tools provided. Solve all issues identified by the analysis. The
Transfer Cockpit will later on again execute checks, offer support and prompt you to acknowledge that any
findings were adjusted accordingly.

How SAP Can Support

SAP offers a Custom Code Impact Analysis service component to help in transforming the ABAP code
properly to achieve maximum benefit. The main goal of this service offering is to evaluate the results of
the ABAP Analysis tools. Typically, the list of identified critical SAP ABAP custom objects is large and can
be categorized into 3 types of objects:

• which has to be adjusted (“must-do’s”)

• which should be adjusted (“should-do’s”)
• which can be adjusted (“nice-to-have”)

Accelerators
• Service Information – Service Components for Custom Code Management
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• ABAP custom code adaptation for SAP HANA – The efficient way
• SAP Note 2462639 – BW4SL – Interface and Customer-Specific ABAP Development
• SAP Note 1909597 - SAP BW Migration Cockpit for SAP HANA
 Test Planning
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.:

o Unit Testing is complete before Integration Testing
o Unit Testing is only required for delta functionality

• Test Scope
• Types of Testing, e.g.
o Unit Testing
o Business Process (String) Testing
o Integration testing
o Data Conversion Testing
o User Acceptance Testing

• Testing Approach
o 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.

o Test processes per phase, test environment, test tools

• Test Automation
• Testing Tools
o Which tools will be used to perform different tests (e.g. SAP Solution Manager)?

• Defect Management
o Description of how defects will be documented (e.g. Test Workbench in SAP Solution Manager)

• Roles and Responsibilities

o 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
1. Make yourself familiar with the tools in test management, and set up test management in SAP
Solution Manager
2. Test Scope Determination
3. Detailed Test Planning

Accelerators
• Service Information – Service Components for Functional Design
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• SAP Support Standard for Test Management
• SAP Solution Manager WIKI - Test Suite
• SAP Rapid Deployment for ALM Wave Test Management
3.11.1. Set Up Test Management in SAP Solution Manager
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 getting a complete overview.

Some EGI sessions that help you set up Test Management in SAP Solution Manager are listed in the
accelerator section.

Accelerators
• Test Management I: SAP Test Workbench
• Test Management II: Business Process Change Analyzer

3.11.2. Test Scope Determination

Objective
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
Test and quality management processes and procedures should already be 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. 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.
• 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.

3.11.3. Detailed Test Planning

Objective
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 new implementation project.

The focus is to determine which of the 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.
• Create 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.

Accelerators
• Test Strategy Template
• Functional Test Plan Template
• SAP Test Management Best Practice
 Data Migration Design for Remote Conversion
Description
As a preparation of the Remote Conversion Execution Service it is mandatory to run a Data Migration
Assessment (Remote Conversion Assessment) in the Explore phase to set the scene for the data
transfer from the old BW system to the SAP BW/4HANA which will be installed as new implementation.
The findings of the assessment have to be taken into consideration to close the gaps before the data
migration into the new system can take place.

The Assessment is the starting point for planning and preparing the Remote Conversion. The graphic
displays the detailed steps from planning to go-live of a Remote Conversion.

Figure 3.8: Remote Conversion Details

Requirements and Constraints

The Data Migration Assessment is only mandatory for conversion scenarios which issue the Remote
Conversion Execution Service offered by SAP.

Procedure
• Perform the Data Migration Assessment for the Remote conversion
• Perform the Preparation steps and prepare the data model adjustment for the Remote conversion
• In case of a remote conversion including SAP BPC, perform the migration of SAP BPC relevant
data

3.12.1. Perform the Data Migration Assessment

Objective
With the BW/4HANA Remote Conversion Assessment, SAP helps customers to prepare the landscape and
the project for a successful remote conversion with the Remote Conversion Execution Service. SAP experts
will assess your landscape transformation or data migration requirements in detail, performing technical
analysis on your SAP systems and leading you through a series of discussions that identify your detailed
transformation requirements. A tailor-made solution proposal for the remote conversion will be provided.
Procedure
The Remote Conversion Assessment service aims to provide information on the Remote Conversion and
supporting the customer in planning the preparation activities for the execution phase. The Assessment is
mandatory if the remote conversion is done with the Remote Conversion Execution Service.

Key Objectives of the Service: Helping in the preparation of the remote conversion with Remote
Conversion Execution for SAP BW/4HANAService

• Check of the sender system and preparation activities (like Transfer Cockpit and software
installation)
• Identify and tailor the scope
• Feasibility check of the planned transition
• Creation of a WBS and define responsibilities
• Project Planning: Planning of the execution cycles and Go-live
• Creation of an effort estimation

How SAP Can Support

SAP offers the Data Migration Assessment service component as a mandatory first step in a Remote
Conversion scenario in combination with the Remote Conversion Execution Service. The Data Migration
Assessment helps to identify all the steps which have to be taken in the task Perform the Preparation
Steps and prepare the Data Model Adjustment for the Remote Conversion and in the activity Data
Migration & Verification.

Preparation of the Data Migration Assessment service

• BW/4HANA Conversion Control Report

For Release BW 7.3 to 7.40: Implement Z_SAP_BW_Note_Analyzer, use xml template

SAP_BW4HANA_AddOn_Checks* and implement the identified Notes (SAP Note 2383530 -
Conversion from SAP BW to SAP BW/4HANA

For Release BW 7.50 : Implement Z_SAP_BW_Note_Analyzer, use xml template

SAP_BW4HANA_In-place_* and implement the identified Notes (SAP Note 2383530 - Conversion
from SAP BW to SAP BW/4HANA

→ Once the report RS_B4HANA_CONVERSION_CONTROL is available, execute it, and provide

the results.

• BW HANA Checklist

Implement (in development and transport up to production or a recent copy of production) SAP
Note 1729988 - SAP BW powered by SAP HANA and SAP BW/4HANA - Checklist Tool , execute
and provide the results of this Note

SAP Note 1909597 - SAP BW Migration Cockpit for SAP HANA

• Sizing Report

Implement (in development and transport up to production or a recent copy of production) the
latest version of
SAP Note 2296290 - New Sizing Report for BW/4HANA, execute and provide the results of this
note.

Accelerators
• Service Information – Service Components for Data Migration Design
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
 • SAP Note 2383530 - Conversion from SAP BW to BW/4HANA
• SAP Note 1729988 - SAP BW powered by SAP HANA and SAP BW/4HANA - Checklist Tool
• SAP Note 1909597 - SAP BW Migration Cockpit for SAP HANA
• Remote Conversion Execution for SAP BW/4HANA

3.12.2. Make yourself familiar with the SAP BW/4HANA Conversion Cockpit for the Remote Conversion
Objective
If the customer performs a remote conversion to SAP BW/4HANA, they may want to transport certain
configuration and data models from the existing landscape to SAP BW/4HANA

The SAP BW/4HANA Conversion Cockpit is used to convert from classic SAP BW to SAP BW/4HANA
system in a remote conversion and enables the migration of objects and dataflows on SAP BW7.3 or
higher (and not 3.x). It contains guided step-by-step activities and a status management and progress
tracking ensuring a good documentation of executed activities and prevention of manual errors.

Procedure
• Make use of the outcome of the Data Migration Assessment and define the steps which have to
be taken to fulfill all requirements for the data transfer.
• Make yourself familiar with the documentation of the SAP BW/4HANA Conversion Cockpit in the
Conversion Guide for SAP BW/4HANA 2.0, chapter 5.4

How SAP Can Support

The transfer of the objects is supported by the SAP Professional Service offering Remote System
Conversion to SAP BW/4HANA. For a detailed description refer to the activity Data Migration &
Verification in the Realize phase.

Accelerators
• 1909597 - SAP BW Migration Cockpit for SAP HANA
• SAP Note 2383530 - Conversion from SAP BW to SAP BW/4HANA
• Conversion Guide for SAP BW/4HANA 2.0

3.12.3. Perform the Migration of Data relevant for SAP BPC

Objective

If the customer performs a remote conversion to SAP BW/4HANA with SAP BPC 11.0, they may want to
transport certain configuration and data models from the existing landscape to SAP BW/4HANA.

Procedure

In case of a remote conversion of BPC Standard Model to BPC 11.0 powered by BW/4HANA, it is
necessary to use the backup & restore tool UJBR (see Conversion Guide SAP BPC 11.0).

In case of a remote conversion of BPC Embedded Model to BPC 11.0 powered by BW/4HANA, the
procedure is identical to the conversion of other BW objects.

How SAP can Support

See in task Perform the Preparation Steps and prepare the Data Model Adjustment for the Remote
Conversion, usage of the Transfer Cockpit.

Accelerators

• Conversion Guide SAP BPC 11.0

• SAP Note 2531382 - BPC 11.0 version for SAP BW/4HANA - Installation and Conversion
Information
• SAP Note 2510414 - Conversion to SAP Business Planning and Consolidation 11.0, version for
SAP BW/4HANA Central Note
• SAP Note 2363248 – BW/4HANA Hardware Sizing (also relevant for BPC 11.0)

Sandbox System Setup for Remote Conversion

Description

The purpose of this task is to set up the sandbox system either as an SAP Cloud Appliance installation or
on premise.

How SAP Can Support

SAP offers the installation of a sandbox (separate installation, or as part of the “Fast Start Bundle”) in the
service component System Installation.

3.13.1. Setup of the Sandbox System

The goal of this task is to provide a sandbox system that is available for testing purposes by the project
team to begin the Realize phase.

Procedure
Install a software appliance for project jump-starts.
The appliance can be consumed in two ways:
1. 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 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. If the customer opts to go beyond
the 30-day limit, an SAP CAL subscription license and a regular SAP BW/4HANA license is required.
2. 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. A regular SAP
BW/4HANA license is required. See also activity Provide a Trial System in the Discover phase, and the
task Define Cutover Approach in the Prepare phase.
3. Perform the following steps as described in “Provisioning SAP BW/4HANA System” in the Conversion
Guide for SAP S/4HANA 2.0, chapter 5.1:
• Installing SAP HANA
• Download Software using Maintenance Planner
• Installing SAP BW/4HANA
• Initial System Configuration
• Creating Source Systems
• Updating System Landscape using SAP BW Note Analyzer

Results
The sandbox system is set up.

Accelerators
• Conversion Guide for SAP BW/4HANA 2.0
 DEV Setup for Remote Conversion
Description
Before configuration and development work starts in the Realize phase, the development system (DEV)
needs to be set up.

Requirements and Constraints

This activity is required for New Implementation, Remote Conversion, and Shell Conversion.

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 or re-use of Sandbox environment
• Install the SAP BW/4HANA Basis Content Add-on and the SAP BW/4HANA Content Add-on

Results
The Dev system is installed and set up with the content add-ons.

3.14.1. Setup of the DEV System

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. When having used the virtual appliance as sandbox
environment, a client that is ”ready-to-activate” is already in place and can be used.
Please note: A sandbox which has been set up by using the SAP BluRays, and which is used as a
DEV system afterwards may have activated business functionality which is subject to additional
licensing.
• For a new installation, perform the following steps as described in “Provisioning SAP BW/4HANA
System” in the Conversion Guide for SAP S/4HANA 2.0, chapter 5.1:
o Installing SAP HANA
o Download Software using Maintenance Planner
o Installing SAP BW/4HANA
o Installing SAP Landscape Transformation 2.0 Add-on
o Initial System Configuration
o Creating Source Systems
o Updating System Landscape using SAP BW Note Analyzer

Results
Finally, the DEV environment is set up.

How SAP Can Support

SAP offers the (Greenfield) Implementation Service for SAP BW/4HANA on Premise which is offered as
an SAP Professional Service. This service contains a mandatory scope item, to install SAP HANA, SAP
BW/4HANA On-Premise and configure one source system (ECC) using ODP technology. In detail the
following steps are covered:

• Installation of an SAP HANA System and SAP BW/4HANA system in the development environment
• Basic configuration of SAP HANA and SAP BW/4HANA development system
• Replication of global settings and exchange rates
 • Implementation of ODP 2.0 if basis level component in ECC source system is appropriate
(SAP_BASIS >=730)
• Basic configuration in order to connect one SAP ECC source system

In addition, the service offers the following scope options:

• Activate FI or CP: Activation of one content area from FI or CO from the business content.
• Activate SD/MM (no Cockpit): Activation of one content area from MM or SD from the business
content, if LO Cockpit is already configured in source system.
• Activate SD/MM and LO Cockpit: Activation of one content area from MM or SD from the business
content. LO Cockpit configuration for one area from MM or SD.
• ODP 1.0 Framework: Implementation of ODP 1.0 if SAP BASIS level in source system is <730.

The activation of the business content can be done in the activity “Configuration” in the Realize phase.

Accelerators
• SAP Note 2393067 – Installation Note
• SAP Note 2400585 – Collective Note & FAQ: SAP BW/4HANA Content (BW4CONT &
BW4CONTB)
• Implementation Service for SAP BW/4HANA
• Conversion Guide for SAP BW/4HANA 2.0

Sizing
Description
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 Sizing

Results
There is a documented estimate on the required hardware, which can be discussed with the hardware
vendor.
3.15.1. Perform / Check Sizing
Objective
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.
• 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” (see 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 an in-place or remote conversion, the sizing report should be executed periodically in the
productive system throughout the project to check on the growth of the source system.
• For a Shell conversion it is mandatory to check the sizing report of the source system and manually
calculate the sizing considering the objects that will be transferred to the new 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. 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.

Accelerators
• Service Information – Service Components for Platform Design
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• General Information on Sizing
• Proactive Performance and Capacity Management - Best-Practice Document
• Sizing Approaches for SAP HANA (incl. SAP S/4HANA and Fiori) – Lessons Learned Document
• SAP ES - Guided Sizing for SAP HANA
3.15.2. Perform Sizing for SAP BPC 11.0
Objective
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
The sizing for BPC needs to be performed on top of the BW sizing. The approach is different depending
on the BPC Model and the conversion type.

For an initial sizing of BPC Standard Model, the paper-based sizing guide for BPC needs to be consulted.
An initial sizing for BPC Embedded model is performed with the help of the SAP Quicksizer for
BW/4HANA.

BPC sizing in case of system conversion is usually done with the help of the report
/SDF/HANA_BW_SIZING.

How SAP can Support

An initial sizing can be provided either as part of the “Technical Architecture Workshop”, or as part of the
“Migration Planning Workshop” in the Prepare phase.

SAP can perform this task with the “Advanced Sizing” service component.

Accelerators
• SAP Note 2296290 – New Sizing Report for SAP BW/4HANA
• Sizing guide for SAP BPC
• SAP Quicksizer
• SAP Note 2363248 - SAP BW/4HANA Hardware Sizing
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• Service Information – Service Components for Platform Design

Technical Architecture and Infrastructure Definition

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

Then you 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 scenarios.

There is an implementation plan available which provides first information about the target solution.

Procedure
• Discover Technical Boundary Conditions
• Create Technical Solution Map
• 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 technical solution map available in SAP Solution Manager.

How SAP Can Support

To minimize the effects of unplanned downtimes, 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 HA/DR Detailed Design Support service component
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. The Technical Platform Definition service component
supports in the selection of the right IT infrastructure which is the basis for the vendor-selection process
and provides Best Practices for mapping the SAP software components on it.

Accelerators
• Service Information – Service Components for Platform Design
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions

3.16.1. Discover Technical Boundary Conditions

Objective
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
• Initial 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)
Availability Requirements

• Collect availability information on:

o SLAs for unplanned downtimes (HA/DR).
o SLAs for planned downtimes (maintenance).
o Classification of systems according the SLA.
• The information can often be derived by using existing SLAs in the context of the new solution.
Alternatively run a workshop for a high-level SLA definition (as part of the Technical Architecture
workshop and the HA/DR Detailed Design Support service component).
• Timing: Realize phase.

Results
The technical boundary conditions are documented and stored in SAP Solution Manager.

How SAP Can Support

See HA/DR Detailed Design Support and Technical Platform Definition service components in the
activity description.

Accelerators
• Best Practice Document - Change Management: Elements of a Software Change Management
Strategy
• White Paper - Storage Architecture in SAP HANA Tailored Datacenter Integration (TDI) Landscapes
• Best Practice - Enterprise Storage Architecture
• Check List - Configuration and Maintenance of the Storage Infrastructure
• Maintenance Planner and Maintenance Optimizer

3.16.2. Create Technical Solution Map

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

Accelerators
• Technical Solution Map Template

3.16.3. Decide on Integration with Cloud Applications and SAP Analytics Cloud
Objective
The objective of this task is to decide on the integration with cloud applications and SAP Analytics Cloud.

SAP Analytics Cloud combines business intelligence, planning and predictive analytics into one cloud
solution that is entirely based on the SAP Cloud platform. The Software-as-a-Service (SaaS) solution
provides access to all the possible data so that the user can visualize, plan and predict using real-time
data. SAP Analytics Cloud is a foundation of a real-time steering in the digital age. It allows integration of
all internal and external data sources in only one solution.

Figure 3.9: Data Connections Environment

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.

Decide if SAP BW/4HANA should be connected to SAP Analytics Cloud via import data connection or live
data connection – refer to the guided playlist for SAP Analytics Cloud “Connections Overview” for details
(see accelerator section).
Results
As a result, a technical architecture for the integration of on-premise and cloud-solutions has to be
created.

Accelerators
• SAP Analytics Cloud (Public)
• SAP Analytics Cloud "Introduction to Connection" (Public)

3.16.4. Hardware Selection and Utilization

Objective
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

3.16.5. Develop Virtualization Strategy

Objective
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. The table below shows some examples of boundary conditions
for the SAP application server.
Figure 3.9: Boundary Conditions (example)

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.

3.16.6. Design Network

Objective
A network design for the new system has to be created

Procedure
The network design needs to include data center interconnectivity 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 table below shows some examples of requirements and network segments.

Figure 3.10: Requirements and network segments (example)

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.

3.16.7. Test Preparation

Objective
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, a test plan including a timeline and test case description has been created.

Technical Design
Description
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.

3.17.1. Create a Technical Solution Design Document

Objective
The objective of this task is the creation of a technical solution blueprint.

Procedure
Take the appropriate “Technical Solution Design 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.

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

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.

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.

Procedure

• Determine the deployment types and required technical components.

• Integrate the HA/DR concept.
• Integrate the scalability and load balancing concept.
• Timing: Realize phase.

Technical infrastructure: Description of hardware requirements and the selected hardware to implement
them.

Procedure

• Determine the selected technical server platform (server hardware, OS & virtualization type).
• Determine the storage infrastructure and its scalability concept.
• Determine the (high-level) network architecture.
• Timing: Explore phase (non-prod), Realize phase (prod)

Deployment patterns and deployment plans: Mapping of installable components to hardware.

Procedure

• Definition of standardized entities for technical deployment.

• Definition of technical co-deployments.
• Definition of the physical location for installable components / technical deployment entities.
• Timing: Explore phase (non-prod), Realize phase (prod)

DC integration: Specification of the integration of the SAP solution into data centers.

Procedure
 • Clarification of the DC provider, topology, and DC roles.
• Definition of required data center central services.
• Calculation of DC facility requirements with HW partners.
• Timing: Explore phase (non-prod), Realize phase (prod)

3rd party integration: Specification of the technical integration of the SAP solution with non-SAP / legacy
systems.

Procedure

• Description of the high-level technical integration architecture between the SAP solution and non-
SAP / legacy systems or components.
• Description of non-functional requirements (performance, availability) of the technical interfaces.
• Timing: Realize phase

Results
As a result, a technical solution design is documented and stored in SAP Solution Manager for central
access.

How SAP Can Support

SAP can optionally support the creation of the technical solution design with the Technical Design
Documentation service component.

Accelerators
• Service Information – Service Components for Platform Design
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• Best Practices - SAP Productive System Strategy for Large Enterprises
• Best Practices - Technical Deployment Options for SAP Systems with SAP HANA
• Check List - High Availability and Disaster Recovery Implementation for SAP Systems
• Best Practices - SAP System Landscapes on Virtualization and Cloud Infrastructures
• Technical Solution Blueprint – Template for Small Customer
• Technical Solution Blueprint – Template for Large Customer
 Operations Impact Evaluation
Description
With the introduction of a new product like SAP BW/4HANA, the current IT support framework will change.
The impact of the new product on the support framework may vary on the scenario. Example scenarios
include the following:

• On-premise solution
IT is responsible for the entire SAP BW/4HANA 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 BW/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 BW/4HANA.

The technical solution design document (see activity Technical Architecture Definition 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 BW/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 checks for the support tools mentioned above and ensuring that the changes
to the support framework with high priorities have been implemented and tested.

Please see the accelerator section for more information.

See also task Clarify on Operational Readiness as part of activity Transition Planning (Prepare phase).

Results
At the end of this activity the impact of SAP BW/4HANA on the existing support organization has been
documented and stored in SAP Solution Manager.

How SAP Can Support

SAP can support this task with the Operations Impact Evaluation service component which supports
customers in:

• Clarifying the impact of the SAP BW/4HANA on IT Operations by reviewing the target support
framework for the operations of the new solution: this includes the target support processes, support
tools, and support teams.
• Identifying the required support skills/roles and knowledge on SAP BW/4HANA for the support
resources.
• Defining what needs to change in the current support framework and the corresponding list of
operations implementations activities which need to be included into the overall project plan to
ensure the operational readiness of the support organization. The customer will be responsible for
managing those activities using SAP's recommendations, Best Practices, knowledge maps and
knowledge transfer plans.
• The Operations Impact Evaluation will specify further the SAP detailed involvement required to
support the customer if they themselves cannot implement the recommendations defined during
this activity (for lack of resources or lack of knowledge).
 • Figure 3.11: Example of an operations service plan created in an Operations Impact Evaluation
Workshop

The review of the recommended target support framework drives the definition of project activities that will
fill the gaps between the current IT support framework and the target support framework created by the
introduction of SAP BW/4HANA.

Accelerators
• Service Information – Service Components for the Transition to Operations
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• SAP HANA Technical Operations Manual

3.18.1. Run Operations Impact Evaluation

Objective
The objective of this task is to evaluate the impact on IT operations when implementing SAP BW/4HANA.

Procedure
During the Operations Impact Evaluation activity, the SAP BW/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: 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 BW/4HANA. Support tools like monitoring, troubleshooting or software
logistics tools need to be in place.
• 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 BW/4HANA, the processes/procedures, the operations
documentation and the enabling support tools.
SAP can support you in all these activities as part of the SAP BW/4HANA service packages where 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
• Setting 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 also includes 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 as part of an SAP BW/4HANA service package for SAP to
support you in 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 on how to adjust IT operations to be
ready to safely and efficiently operate SAP BW/4HANA as of Go-Live.

How SAP Can Support

See Operations Impact Evaluation in the activity description.
 Release and Sprint Plan
Description
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 SolMan 7.1 functionality and the above training materials
will be updated for SolMan 7.2. In this update step there will be an 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.

Tasks
• Update and Prioritize Backlog

• Estimate Backlog Items Effort

• Conduct Release and Sprint Planning Meeting

• Validate Release and Sprint Plan Against SoW

3.19.1. Update and Prioritize Backlog

Objective
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 using 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
the 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). The 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.

Accelerators
• Agile Definition of Ready and Done (Customer)
• Agile Release Planning (Customer)
• Backlog including Delta Requirements and Gaps.xlsx
 • Backlog Template

3.19.2. Estimate Backlog Items Effort

Objective
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. The 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 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.

Accelerators
• Agile Sprint Burndown and Task Board (Customer)
• Backlog Template

3.19.3. Conduct Release and Sprint Planning Meeting

Objective
The objective of this task is to prepare a 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 the 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:

1. Sprint Planning Meeting

2. Sprint Execution Activities

3. Daily Stand-up Meeting

4. Sprint Demo

5. Sprint Retrospective

During the project the team will run two types of sprints:

1. Build sprints - the goal of these sprints is to build, and unit test the new capabilities

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

Accelerators
• Agile Release Planning (Customer)

3.19.4. Validate Release and Sprint Plan Against SoW

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

Change Impact Analysis

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

Tasks
• Validate Organizational Alignment Approach
• Establish Baseline of Current State

Accelerators
• OCM Change Impact Analysis Guide (Customer)

3.20.1. Validate Organizational Alignment Approach

Objective
The purpose of this task is to validate the chosen approach with key stakeholders for the
continued project execution.

3.20.2. Establish Baseline of Current State

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

Phase Closure and Sign-Off phase Deliverables

Description
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

Tasks
• Conduct Knowledge Management Gate
• Conduct Project Quality Gate
• Execute Baseline Retrospective
• Conduct Project Management Review Service
• Conduct Design Review Service
• Manage Fulfilled Contracts
• Obtain Customer Sign-Off for Phase Completion
 3.21.1. Conduct Knowledge Management Gate
Objective
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.

Accelerators
• Lessons Learned Guide (Customer)
• Lessons Learned Template (Customer)

3.21.2. Conduct Project Quality Gate

Objective
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 by the Project Manager
to the different project types.

Accelerators
• QGateChecklist Concept SAP Activate
• QGateChecklist Template Introduction
• Quality Built In New QGate Checklist

3.21.3. Execute Baseline Retrospective

Objective
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.
Accelerators
• Agile Sprint Retrospective Template (Customer)

3.21.4. Conduct Project Management Review Service

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

3.21.5. Conduct Design Review Service

Objective
The purpose of this task is to execute a Design Review service that provides a proactive quality assurance
review of the design of the SAP solution which is being implemented. It delivers an impartial analysis of all
aspects of the solution design - across all relevant design perspectives - and leads to an early detection of
potential solution risks and offers actionable risk mitigation recommendations.

3.21.6. Manage Fulfilled Contracts

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

3.21.7. Obtain Customer Sign-Off for Phase Completion

Objective
Purpose of this task is to obtain customer approval (sign-off).

Accelerators
• Phase Sign-Off Template (Customer)
4. Realize Phase
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.

Figure 4.1: Activities in the Realize Phase

In the Solution Adoption work stream, the trainings for the end users start.

In the Application Design & Configuration work stream the SAP BW/4HANA Implementation Service or
the data and object transformation takes place according to the applied scenario. SAP can safeguard the
activities via the Integration Validation offering, which covers key aspects like Exception Management,
Integration, and Performance and Scalability.

In the Data Management work stream, Load and verification runs ensure business data can be migrated
with acceptable time and quality.

In the Extensibility work stream, impacted custom code is adjusted and testedl.

Application changes are thoroughly tested in the Testing work stream. 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. 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. 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.

According to the Operations Impact Evaluation, the operations implementation (people, processes tools)
takes place in the Operations & Support work stream.

Phase Initiation
Description
The purpose of this deliverable is to formally recognize that a new project phase starts.

Tasks
• Review Deliverables of Realize Phase

• Review Acceptance Criteria

• Review RACI Chart for Realize Phase with Customer

4.1.1. Review Deliverables of Realize Phase

Objective
The purpose of this task is to review all deliverables of the Realize Phase with the customer.

4.1.2.Review Acceptance Criteria

Objective
The purpose of this task is to review the acceptance criteria with the customer.

4.1.3. Review RACI Chart for Realize Phase

Objective
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

Plan Realize Phase

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

Tasks
• Plan Sprints and Solution Reviews

• Plan Testing

4.2.1. Plan Sprint and Solution Reviews

Objective
The purpose of this task is to plan Sprints and prepare to evaluate the proposed solution.
 4.2.2. Plan Testing
Objective
Procedures:

1. Review Test entry and exit criteria with customer

2. Schedule Test Sessions and Plan Resources

Sprint Initiation (Iterative)

Description
The purpose of this task is to initiate sprint in a formal Sprint Planning Meeting.

4.3.1. Conduct Sprint Planning Meeting (Iterative)

Objective
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 the product owner team any questions that may still remain open. The team commits to
deliver the 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.

Accelerators
• Agile Definition of Ready and Done (Customer)

Execution Plan for Realize Phase

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

Tasks
1. Manage Sprints

2. Manage Unit/String Tests

3. Manage Integration Test

4. Manage Security Test

5. Manage User Acceptance Test

4.4.1.Manage Sprints
Objective
The purpose of this task is to ensure consistent execution and monitoring of sprint activities.

4.4.2.Manage Unit/String Tests

Objective
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.
 4.4.3.Manage Integration Test
Objective
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.

4.4.4.Manage Security Test

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

4.4.5. Manage User Acceptance Test

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

Sprint Closing
Description
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.

Tasks
• Conduct Sprint Review Meeting

• Sign-off Sprint Results

• Conduct Sprint Retrospective

4.5.1.Conduct Sprint Review Meeting

Objective
The purpose of this task is to demonstrate the results of the sprint to the product owner team, key users
and key project stakeholders. The results of the demo are 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 the next sprint planning meeting. The demo in sprint review meeting
serves as an input to formal sign-off for the sprint.

Accelerators
• Agile Sprint Burndown and Task Board (Customer)

4.5.2.Sign-off Sprint Results

Objective
The purpose of this task is to obtain formal acceptance and sign-off 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.

4.5.3.Conduct Sprint Retrospective

Objective
The purpose of this task is to conduct a 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 a 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.

Accelerators
• Agile Release Planning (Customer)
• Agile Sprint Retrospective Template (Customer)

Learning Realization
Description
In this activity the training material for the 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.).

4.6.1.Train your Key Users

Objective
The goal of this task is to train the key user as planned in the activity Learning Design in the Explore
phase.

Procedure
Train your key user as planned in the Explore phase. Training could happen e.g. via classroom 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.

Accelerators
• SAP Education Consulting Services
4.6.2.Create Training Material for End User
Objective
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 experience. Simulations can only be created once a suitable authoring tool is available
(e.g. SAP Enable Now).

• E-Learning

E-Learning helps to reduce the effort for classroom training. As a self-learning offering, e-learning is
also available after the project has ended. This enables new employees to become acquainted with
topics independently. Trained employees can "refer back to" various topics or "take a look at" the
system simulations as required. Creating customer-specific e-learning content requires a stable and
fully developed / customized SAP system.
SAP assumes that e-learning will merely comprise of less complex and overview content such as
process overview per stream, main functional features, highlighting key changes and benefits. SAP
develops e-learning content comprising approximately 56 hours of net learning time. Net learning time
describes the amount of time that an average learner requires to work through the program without
any interruptions.
• Web Based Training (WBT)
Web based training is a reasonable addition to e-learning and has the advantage that a course can be
attended location-independently by one or more persons. Communication with the trainer via phone or
chat is feasible, during which all open questions resulting from previous self-learning experience can be
answered by an expert.

If possible, the course material and the exercises and solutions could be derived from the corresponding
classroom training courses. If not, a course concept, training manual, conceptual design slides, work
instructions for transaction steps, and exercises (including data and simulations) should be developed

Based on the end user training the customer training system need to be set up by the customer key users.
SAP can support this activity. The technical set up is finalized by the IT team.

In addition to the development of the end-user training material and the training system set up, the
customer key users should have a final workshop with SAP experts to finally prepare the end user
trainings, and to define the tandem approach for the first end user trainings. The tandem approach means
that the customer key user will be accompanied during the first training sessions by an experienced SAP
trainer to get confidence and safety in performing the trainings.

SAP expects DEV and QAS (or a dedicated training system) to be completely available during training
development period. SAP recommends a systematic buildup of the training client in the QAS test system
during the Realize phase. The training client should be available when training material creation starts
(e.g. processes, master and booking data).

Results
The training is ready to be delivered to the end user.

How SAP Can Support

SAP can support this activity as part of an individual education consulting offer from SAP Education. For
instance, SAP can:
 • Review the enablement concept
• Update the enablement plan to reflect specific project requirements
• Synchronize the enablement plan with the overall project plan

Accelerators
• SAP Education Consulting Services

Configuration
Description
After the setup of the Dev system, you need to run the post-installation steps and start with the
configuration of the system.

Requirements and Constraints

This activity is required for new implementation, remote conversion and shell conversion.

Procedure
• Run the post-installation steps as described in the Master Guide (see accelerator section).
• Activate the required business content.

Result
The basic configuration of the new SAP BW/4HANA system is done.

Accelerators
• SAP BW/4HANA Master Guide
• SAP BW/4HANA Content Add-on (online help)

4.7.1.Configure the new SAP BW/4HANA System

Objective
Configure the new SAP BW/4HANA system and connect the source systems. Activate the business
content.

Procedure
• Run tasklist SAP BW4_SETUP_SIMPLE in transaction STC01. The task list performs the basic
system setup tasks, like creating and configuring the SAP BW/4HANA background user, setting the
SAP BW/4HANA client and installing the essential technical content.
• Use the Implementation Guide (IMG) to add further settings
• Install the permanent SAP license.
• Install the SAP BW/4HANA Basis Content Add-on, if not yet done with the system setup. Refer to
SAP Note 2393067 – Installation Note
• Install the SAP BW/4HANA Content Add-on, if not yet done with the system setup
• Activate the content areas from the business content as required for your business.
• Configure the connection to your source systems. This may require the implementation of ODP 1.0
in case of source systems < 730 and the implementation of ODP 2.0 if the basis level component
SAP_BASIS is >= 730.

How SAP Can Support

SAP offers the (Greenfield) Implementation Service for SAP BW/4HANA on Premise as Professional
Service. This service contains a mandatory scope item, to install SAP HANA, SAP BW/4HANA On-
Premise and configure one source system (ECC) using ODP technology. The following steps are covered
in detail:
 • Installation of an SAP HANA system and SAP BW/4HANA system in the development environment
• Basic configuration of SAP HANA and SAP BW/4HANA development system
• Replication of global settings and exchange rates
• Implementation of ODP 2.0 if basis level component in ECC source system is appropriate
(SAP_BASIS >=730)
• Basic configuration in order to connect one SAP ECC source system

In addition, the service offers the following scope options:

• Activate FI or CP: Activation of one content area from FI or CO from the business content
• Activate SD/MM (no Cockpit): Activation of one content area from MM or SD from the business
content, if LO Cockpit is already configured in source system
• Activate SD/MM and LO Cockpit: Activation of one content area from MM or SD from the business
content. LO Cockpit configuration for one area from MM or SD.
• ODP 1.0 Framework: Implementation of ODP 1.0 if SAP BASIS level in source system is <730.

Accelerators
• SAP Note 2393067 – Installation Note
• SAP Note 2400585 – Collective Note & FAQ: SAP BW/4HANA Content (BW4CONT &
BW4CONTB)
• Implementation Service for SAP BW/4HANA

Realize the In-place Conversion

Description
This activity covers all steps in the project landscape that are displayed in the “in-place conversion” phase
(t5 phase) in the following graphic:

Figure 4.2: Detailed steps of the In-place Conversion

The SAP BW/4HANA Starter add-on makes it possible to transition from the existing object types,
processes and interfaces to the new and optimized ones in SAP BW/4HANA. To do this, you need to
perform the following steps in the SAP BW system after installing the add-on:
1. Run the Pre-Check to check whether the objects and processes that the system uses are compatible
with SAP BW/4HANA
2. Transfer incompatible objects and processes to compatible ones with the SAP BW/4HANA Transfer
Cockpit.
3. Switch the system to an operating mode that only allows objects and processes that are compatible
with SAP BW/4HANA. Switching the system to B4H mode prepares the SAP BW system for conversion to
SAP BW/4HANA.
4. Check whether all system-wide clean-up activities have been completed.
5. Switching the system to an operating mode from which the technical upgrade can be performed
Switching the system to ready-for-conversion mode completes preparation of the SAP BW system for
conversion to SAP BW/4HANA. It can be performed again with the SAP BW/4HANA Transfer Cockpit.

Procedure
• Install the SAP BW/4HANA Starter Add-on
• Update to the latest version of SAP BW/4HANA Transfer Cockpit
• Use the Authorization Transfer Tool of the SAP BW/4HANA Transfer Cockpit
• Perform the Object Transfer using the Scope Transfer Tool of the SAP BW/4HANA Transfer Cockpit
• Perform Custom Code Adjustments
• Execute the Transfer of Standard Authorizations with the SAP BW/4HANA Transfer Cockpit
• Transfer ADP Processes with the ADP Transfer Tool
• Clean-up Objects using the Cleanup Tool
• Switch to Ready for Conversion mode

Result
The system is ready for the technical conversion.

4.8.1.Install the SAP BW/4HANA Starter Add-on

The SAP BW/4HANA Starter add-on makes it possible to transition from the existing object types,
processes and interfaces to the new and optimized ones in SAP BW/4HANA.

Procedure
Download the software with Maintenance Planner and install the SAP BW/4HANA Starter Add-on with the
Add-on Installation tool as described in the Conversion Guide for SAP BW/4HANA 2.0, chapter 4.2.

Result
The SAP BW/4HANA Starter Add-on is installed.

Accelerators
• SAP Note 2426518 – BW/4HANA: Starter Add-on - corrections
• SAP Note 243833 – BW/4HANA: Starter Add-on – further corrections
• Conversion Guide for SAP BW/4HANA 2.0

4.8.2. Update to the latest version of the SAP BW/4HANA Transfer Cockpit
Objective
Most of the next steps of the in-place conversion are performed with the SAP BW/4HANA Transfer
Cockpit. Make sure to use the latest version of the Cockpit
Procedure
Use the SAP BW Note Analyzer with the XML files attached to SAP Note 2383530 to update the Transfer
Cockpit to the newest version as described in the Conversion Guide for SAP BW/4HANA 2.0, chapter 4.3.

Results
You can now start using the SAP BW/4HANA Transfer Cockpit.

How SAP Can Support

The task lists used in the SAP BW/4HANA Transfer Cockpit are documented in detail in the “Task Lists
Documentation for Conversion to SAP BW/4HANA” (see accelerator section).

Accelerators
• Task Lists Documentation for Conversion to SAP BW/4HANA
• Conversion Guide for SAP BW/4HANA 2.0

4.8.3. Prepare the Transfer of Standard Authorizations

Objective
Conversion from SAP BW to SAP BW/4HANA requires also conversion of authorization objects. There are
four types of actions that need to be applied for respective authorization objects:

• Assume – Nothing to do. Authorizations will continue to work after conversion

• Adjust – Check and adapt values of authorization objects

• Replace – Change authorization object and adapt its values

• Obsolete – Not needed/supported authorization object that should be removed

The assignment of actions to existing authorization objects can be found in SAP Note 2468657.

The SAP BW/4HANA Transfer Cockpit provides an Authorization Transfer Tool to automate the transfer of
existing security roles.

Procedure
Follow the procedure for authorization objects transfer described in the Conversion Guide for SAP
BW/4HANA 2.0, chapter 4.7.

Results
The transfer of standard authorizations is prepared.

Accelerators
• Conversion Guide for SAP BW/4HANA 2.0

4.8.4. Perform the Object Transfer using the Scope Transfer Tool of the SAP BW/4HANA Transfer Cockpit
Objective
Data models and data flows are converted to HANA-optimized objects that are compatible with SAP
BW/4HANA by using the Scope Transfer Tool of the SAP BW/4HANA Transfer Cockpit.. Object types that
are not available in SAP BW/4HANA are replaced by other object types or features. A “scope” is a
collection of objects that you want to convert together. The following table lists the object types that are
not available anymore and can be converted using the Transfer Cockpit, together with their successors
and the Simplification Item (see the corresponding SAP Notes for details and limitations regarding each
object type):

Figure: Object Types and Simplificaiton Items

The following object types will be automatically adjusted during a scope transfer:

Procedure
The Transfer Cockpit transfers the unsupported objects to new supported objects, copies the data to the
new objects and the old objects are deleted. You can find a detailed documentation of the tasks
performed during a scope transfer in the system (transaction STC01) or on the SAP Help Portal → Task
List Documentation for Conversion to SAP BW/4HANA.. The relevant objects are identified by the
readiness check report. The Transfer Cockpit activities are generally the most time-consuming activities in
this project phase. The activities must be performed in each system of the system landscape separately.
Generally, the changes cannot be transported.

How SAP can Support

For a complete and up-to-date list of unsupported objects, processes and functionalities, together with
their successors/replacements and the relevant conversion method, refer to the latest version of the SAP
Simplification List for SAP BW/4HANA. Tips and hints for troubleshooting scope transfers are available in
the Conversion Guide for SAP BW/4HANA 2.0, chapter 4.8.3.

Accelerators
• Task Lists Documentation for Conversion to SAP BW/4HANA
• Conversion Guide for SAP BW/4HANA 2.0

4.8.5. Perform Custom Code Adjustments

Objective
Custom coding has to be adjusted to be ready for the conversion.

Procedure
Follow up on the results from the Custom Code Impact Analysis and the findings from the Code Scan
Tool. Also refer to the activity “Custom Code Management Execution”.

4.8.6. Execute the Transfer of Standard Authorizations with the SAP BW/4HANA Transfer Cockpit
Objective
After the successful transfer of objects using the Scope Transfer Tool, the transfer of standard
authorizations must be completed using a delta run.

Procedure
Follow the description of the Transfer Process (Delta Run) in the Conversion Guide for SAP BW/4HANA
2.0.

Results
The system will generate the new roles and assign them to the same users as the corresponding original
roles.

4.8.7. Transfer ADP Processes with the ADP Transfer Tool

Objective
The APD Transfer Tool (transaction RSB4HAPD) converts APD processes into corresponding process
chains. The tool supports the most common elements of APD processes. However, there are restrictions
for some of the APD nodes and some types of nodes are not supported by the transfer tool at all.

Procedure
Refer to the description in the Conversion Guide for SAP BW/4HANA 2.0 for transferring the APD
processes, chapter 4.10..

Results
The APD processes are converted into process chains for SAP BW/4HANA.
Accelerators
• Conversion Guide for SAP BW/4HANA 2.0

4.8.8. Clean-up Objects using the Cleanup Tools

Objective
Objects that are not compatible with SAP BW/4HANA and are not required anymore, need to be deleted
from the system so they do not to block a system conversion (or switching of operating modes).

Procedure
Delete objects that are not required anymore as described in the Conversion Guide for SAP BW/4HANA
2.0, chapter 4.11. The following object types can be deleted:

• SAP BW Technical Content

• SAP BW Objects
• SAP BW Queries

Results
You have cleaned up the system from objects that are not required anymore.

Accelerators
• Conversion Guide for SAP BW/4HANA 2.0

4.8.9. Run the technical in-place conversion to SAP BW/4HANA

Objective
Before starting the technical system conversion in the project landscape, you have to download the
software using Maintenance Planner. The technical system conversion is performed using the Software
Update Manager (SUM) 2.0. The required version is SUM 2.0 SP05 or higher.

Procedure
1. Start the Maintenance Planner and select “Plan a Conversion to SAP BW/4HANA” and “SAP
BW/4HANA 2.0”. Select your target Support Package.
2. Download the Stack XML file
3. Run the technical system conversion with the SUM as described in the Conversion Guide for SAP
BW/4HANA 2.0, chapter 4.13.

Results
The implementation is finished now. Perform the follow-on activities of the task list
“SAP_BW4_AFTER_CONVERSION” in the SAP BW/4HANA Transfer Cockpit.

How SAP Can Support

SAP offers the service “In-Place system conversion for SAP BW/4HANA”. This service covers the
conversion of an existing SAP BW running on any database system to SAP BW/4HANA.

Accelerators
• Conversion Guide for SAP BW/4HANA 2.0
• In-place system conversion for SAP BW/4HANA Service
• SAP First Guidance – complete functional scope (CFS) for SAP BW/4HANA
• SAP Note 69455 – Servicetools for Applications ST-A/PI
• SAP Note 1815374 – Clean up entries in tables after delete source system
• SAP Note 2069865 – ITAB_DUPLICATE_KEY dump in program SAPLRSAODS during various
staging processes
• SAP Note 2214733 – SAPI: Inconsistent IDoc segments/transfer structures in source system
• SAP Note 2400086 – Myself-System not allowed in strict mode
• SAP Note 2719160 – Uninstallation of software component SAP_BW during the BW/4HANA 2.0
Conversion
 Data Volume Configuration & Execution
Description

In this activity the Data Volume Strategy that has been defined and (partly) implemented is further realized
(see description of activity Data Volume Design). Data Tiering can be part of the data volume strategy.

Data Tiering allows you to assign data to various storage areas and storage media. The criteria for this
decision are data type, operational considerations, performance requirements, frequency of access, and
security requirements.
Customers often employ a multi-temperature or data tiering storage strategy, with data classified
depending on frequency of access and certain other criteria as either hot, warm or cold. Depending on this
classification, the data is kept in different storage areas or media.

In addition to frequently accessed active data, large SAP BW∕4HANA systems also contain a large volume
of data that is only accessed rarely. The data is either never or rarely needed in Data Warehouse
processes or for analysis. The main challenge of implementing a data tiering strategy is to seamlessly
integrate the warm and cold memory areas and to make these areas invisible to the outside, in order to
ensure that all required functions are applied to this data. SAP provided data tiering solutions for this,
helping to reduce TCO thanks to optimized SAP HANA main memory resource management.

The following solutions are available in SAP BW∕4HANA for data tiering:

Figure: Data Tiering Options in SAP BW/4HANA

Data Tiering Optimization (DTO)

Data Tiering Optimization (DTO) is the strategic solution for data tiering in SAP BW∕4HANA. It offers the
following advantages:

• A single data tiering solution for hot data (hot store in SAP HANA), warm data (warm store in SAP
HANA) and cold data (cold store to SAP IQ, Hadoop, SAP Vora)
• Central definition of the data temperature based on partitions of the DataStore object (advanced)
• Moving data to the dedicated storage location as a simple and periodically performed housekeeping
activity (TCO reduction)
 • Smooth co-existence of Data Tiering Optimization and the existing near-line storage approach, as
the same technical concepts are used for the storage areas for cold data, such as locking archived
data

Note: Near-line storage with SAP IQ and Hadoop, a solution for the cold store, is still supported in SAP
BW∕4HANA and provides:

• Continuity for data archiving scenarios that are already implemented with near-line storage with
SAP IQ or Hadoop before SAP BW∕4HANA Data Tiering Optimization is introduced
• Support for more complex data archiving scenarios that are not covered by SAP BW∕4HANA Data
Tiering Optimization

For new DataStore objects however, you should use Data Tiering Optimization wherever possible.

The following graphic shows an SAP HANA Scale-out landscape with extension node:

Figure: SAP HANA Scale-out landscape with extension node

Tasks
• Configure SAP HANA Extension Node as a Warm Store
• Configure Hadoop or SAP Vora as Cold Store

Results
Data Tiering Optimization is prepared and the DataStore objects can be configured accordingly.
4.9.1.Configure SAP HANA Extension Node as a Warm Store
Objective
To implement a multi-temperature memory strategy in your SAP BW∕4HANA system, as of SAP HANA 1.0
SPS12 (DSP), you can use the extended node concept for warm data. The data (with no functional
restrictions) is saved in a dedicated SAP HANA scale-out node. This enables you to optimize usage of the
main memory in SAP HANA.

Based on typical data distribution in a SAP BW∕4HANA system, a single extension node is normally used.
Multiple extension nodes should only be used in exceptional circumstances. If you do use data tiering
optimization with multiple extension nodes, SAP HANA 2.0 is a prerequisite.
Procedure
• Configure SAP HANA for use with extension node (see SAP Note 2343647).
• Specify the data tiering properties (information about which temperatures or memory areas should
be supported by an object) in the modeling screen for the relevant DataStore objects. Use the
definition of an object temperature or partition temperature to specify which data is stored in which
memory area.
• Define a data tiering optimization job which regularly moves data to the extension nodes for the
corresponding configured DataStore objects.

Results
Performance and memory usage are increased as only hot data is stored on the standard node whereas
warm data is stored on the extension node.

Accelerators
• SAP Note 2343647: How to Configure SAP HANA for the BW extension node
• SAP Note 2317200: Data Lifecycle Management for BW on HANA and extension nodes
• Details on Data Lifecycle Management for BW on HANA (SCN blog)
• More details: HANA extension nodes for BW on HANA (SCN blog)
• FAQ: SAP BW/4HANA and SAP BW-On-HANA with SAP HANA Extension Nodes
• Data Tiering Optimization with SAP BW/4HANA

4.9.2.Configure Hadoop or SAP Vora as Cold Store

Objective
The goal of this task is to configure Hadoop or SAP Vora as cold store.

Procedure
• For Hadoop, all configuration steps are described in the online help “Configuring Hadoop as a cold
store/Neral-Line Storage Solution” (see accelerator section):
• Perform configuration steps for Hadoop
• Perform configuration steps on SAP HANA
• Perform configuration steps in SAP BW/4HANA

For SAP Vora, all configuration steps are described in the online help “SAP Vora as a Cold Store” (see
accelerator section):

• Create a connection to the SAP Vora cluster

• Create a remote source
 • Create a connection to the cold store. In Customizing, choose SAP BW/4HANA Customizing
Implementation Guide > SAP BW/4HANA < Information Lifecycle Management > Edit Cold Store
Connection
• Create a database schema in the Vora system
• Select the SAP Vora cold store connection as the default connection

For more information about using SAP Vora as a cold store, see SAP Note 2608405.

Results
Either Hadoop or SAP Vora has been configured as cold store.

How SAP Can Support

SAP offers a set of videos on how to deal with the partitions for hot, warm and cold data. The videos are
linked in the introduction blog “SAP BW/4HANA Data Tiering Optimization” (see accelerator section).

The BW near-line storage Empowering Service is a workshop that can be ordered as a follow-up to the
Data Volume Management service components. It includes a results presentation of the strategy service.
In addition, the workshop covers the following topics:

• Housekeeping for SAP NetWeaver BW: tasks to be performed on a regular basis

• Overview of near-line storage, including theoretical concepts and partner solutions
• The data archiving process in the context of near-line storage and all related technical details that
are required for a successful near-line storage implementation project
• Archiving, restoration, and reloading of DataStore objects
• Different locking mechanisms and data consistency (design time vs. runtime)
• Data access for reporting purposes or by means of the available lookup API for data staging
purposes Automating the archiving and data transfer via process chains
• Best practices with regards to modeling your enterprise data warehouse, DataStore objects, and
respective data archiving processes
• Important aspects during the life cycle of your near-line storage solution from a BW point of view

Accelerators
• SAP BW/4HANA Data Tiering Optimization
• SAP Empowering Service BW Near-line Storage (CRM 9500540)
• Help.sap.com: Configuring Hadoop as a Cold Store/Near-Line Storage Solution
• Help.sap.com: SAP Vora as a Cold Store
• SAP Note 2608405 – SAP Data Hub as Cold Store for BW/4HANA: Information, Recommendations and
Limitations
• SAP Note 1796393 – SAP BW near-line solution with SAP IQ
• SAP Note 2343647 – How-To: Configuring SAP HANA for the BW Extension Node
• SAP Note 2453736 - How-To: Configuring SAP HANA for SAP BW Extension Node in SAP HANA 2.0
• SAP Note 2415279 – How-To: Configuring SAP HANA for the SAP HANA Extension Node
• SAP Note 2165650 – FAQ: BW Near-Line Storage with HANA Smart Data Access
• SAP Note 2100962 – FAQ: BW Near-Line Storage with HANA Smart Data Access: Query Performance
• SAP Note 1999431 – SIQ: Setting up SSL for connections to IQ
• SAP Note 2133194 – Can SAP IQ run in a cloud environment?
• FAQ: SAP BW/4HANA and SAP BW-on-Hana with SAP HANA extension Nodes
• SAP Note 2486706 – FAQ: SAP BW/4HANA and SAP BW-on-HANA with Extension Nodes
• SAP Note 2643763 – FAQ: SAP HANA Extension Node for SAP HANA native applications
• SAP Note 2334091 – BW/4HANA: Table Placement and Landscape Redistribution
• SAP Note 2317200 – Data lifecycle management for BW on SAP HANA and extension nodes
 Integration Validation
Description
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
1. Identify the IV Scope
2. Initiate the Corresponding IV Support Activities
3. 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.
4.10.1. Identify the IV Scope
Objective
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 jointly determine
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.

Accelerators
• Innovation Control Center (White Paper)

4.10.2. Initiate the Corresponding IV Support Activities

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

See accelerator section for details.

SAP Enterprise Support Customers can order the CQC for Technical Performance Optimization (TPO).

Accelerators
• Service Information – Service Components for Safeguarding the Digital Transformation
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• CQC for Technical Performance Optimization (TPO)

4.10.3. Initiate SAP Going-Live Check

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

Accelerators
• SAP OS/DB Migration Check
• CQC OS/DB Migration Check
• SAP Going-Live Functional Upgrade Check
• CQC for Upgrade
• SAP Going-Live Check for Implementation
• CQC for Implementation
 Analytics Configuration
Description
With live data connection to SAP BW/4HANA, SAP Analytics Cloud and SAP Data Warehouse Cloud treat
the integration with BEx queries like an InfoProvider for data consumption purposes. Support on BEx
query consumption is focused on:

• Leveraging key metadata concepts

• Leveraging logic concepts like variable prompting, filtering
• Limited investments in presentation concepts. Expect equivalent or similar presentation concepts
as native functionality in SAP Analytics Cloud

BEx query consumption guidelines:

• Customers are recommended to create specific queries for compatible usage in SAP Analytics
Cloud
• Only queries configured with “Allow External Access to this Query” flag enabled, can be consumed
by SAP Analytics Cloud

Note:

Data import guidelines against BW queries are different:

• SAP Analytics Cloud and SAP Data Warehouse Cloud leverage selective BW query feature
concepts relevant to data import:
• Once the data is imported, the calculation engine will be HANA. The BW OLAP engine is no longer
tied to the imported data set
• Imported data can be kept up to date via scheduled refresh

Check the supported BW query concepts on the figures below:

Figure: Supported BW query concepts: Metadata support 1

Figure: Supported BW query concepts: Metadata support 2

Figure: Supported BW query concepts: Variable Processing Types and Presentation

Figure: Supported BW query concepts: Display Settings

Full documentation on BEx query consumption support and product limitations are available on the Help
Portal: https://help.sap.com/cloud4analytics.

Procedure
• Understand the benefits and functionality of SAP Analytics Cloud and SAP Data Warehouse Cloud
• Create Data Models in SAP Analytics Cloud and SAP Data Warehouse Cloud

Accelerators
• SAP Analytics Cloud integration with SAP BW
• Online help https://help.sap.com/cloud4analytics
• Online help “Live Data Connections to SAP Data Warehouse Cloud”

4.11.1. Understand the Benefits and Functionality of SAP Analytics Cloud

Objective
Understand the concept and how to work with SAP Analytics Cloud.

Procedure
Make yourself familiar with SAP Analytics Cloud with the help of the webinars and guided playlists on the
SAP Analytics Cloud homepage https://www.sapanalytics.cloud.

How SAP Can Support

SAP offers the Enablement Service for SAP Analytics Cloud and SAP Digital Boardroom, as a PS
service, including

• Overview and Architecture of SAP Analytics Cloud and SAP Digital Boardroom
• Data Connectivity
 • Data Load – Excel to SAP Analytics Cloud
• Modeling Management of SAP Analytics Cloud
• User Administration of SAP Analytics Cloud
• Visualization Creation and Atory Composition for SAP Digital Boardroom.

Accelerators
• Enablement Service for SAP Analytics Cloud and SAP Digital Boardroom (50124566)

4.11.2. Create Data Models in SAP Analytics Cloud

Objective
Data models are the foundation for data exploration and data visualizations in your SAP Analytics Cloud
stories. Learn how to create and work with data models.

Procedure
You can use the Guided Playlist “Introduction to Data Models” in the SAP Analytics Cloud Guided Playlists
(see accelerator section).

Note: Before designing your story, please check the help page “Supported Features and Known
Limitations to SAP BW Live Data Connections” (see accelerator section) to identify the limitations when
using a BW Live Data Connection:

Results
You have learned the fundamentals of data models.

Accelerators
• SAP Analytics Cloud Guided Playlist “Introduction to Data Models”
• Supported Features and Known Limitations to SAP BW Live Data Connections

4.1.1.3. Understand the Benefits of SAP Data Warehouse Cloud

For SAP BW/4HANA customers, SAP Data Warehouse Cloud is the perfect complement to the on-
premise investment. SAP BW/4HANA objects work in SAP Data Warehouse Cloud so that the existing
investment can be leveraged. Resources can be further optimized by empowering business users and
freeing up IT with SAP Data Warehouse Cloud’s self-service modeling.

For deeper understanding of the SAP Data Warehouse Cloud and SAP BW/4HANA integration, refer to
the blogs and articles on the SAP Data Warehouse Cloud webpage, like:

• Business cases show how customers have extended their SAP BW/4HANA to the Cloud creating
a hybrid data warehousing strategy. Watch the youtube video and read the blog “How companies
extend SAP BW/4HANA to the Cloud”
• The product plan for SAP BW/4HANA in combination with SAP Data Warehouse Cloud is listed in
the product update for SAP Data Warehouse Cloud

Accelerators
• Blog “How companies extend SAP BW/4HANA to the Cloud”
• Youtube video “SAP Data Warehouse Cloud: How Companies Extend SAP BW/4HANA to the
Cloud”
• Use Case Hybrid: SAP BW/4HANA + SAP Data Warehouse Cloud - Extending Data Warehousing
to the Cloud
• Product Plan – DWC and SAP BW/4HANA
4.11.4. Frequently Apply SAP Notes to SAP BW/4HANA
Objective
BW Backend and SAP Analytics Cloud should be technically in sync. For every new functionality delivered
bi-weekly in SAC the backend needs in most cases to also be updated, therefore it is important to
frequently apply SAP Notes to SAP BW/4HANA.

Procedure
SAP Note 2541557 will help you to have your Backend in sync.

Results
SAP B/4HANA and SAP Analytics Cloud are kept in sync.

Accelerators
• SAP Note 2541557 – Support further SAP Analytics Cloud BW Features

4.11.5. Replace SAP Business Explorer (BEx)

Objective
SAP Business Explorer (SAP BEx) tools are no longer available or supported with SAP BW/4HANA.
Customers moving to SAP BW/4HANA from SAP BW will need to transition their SAP BEx reports and
applications to SAP BusinessObjects.

Figure: Transition SAP BEx reports and applications to SAP Business Objects

Procedure
The transition from SAP Business Explorer to SAP BusinessObjects requires a manual migration
(currently no tools will perform the conversion automatically). SAP customers may need to purchase new
licenses to be able to deploy SAP BusinessObjects tools (SAP BusinessObjects is not a successor of SAP
Business Explorer). The “SAP BEx Query Designer” has transitioned to the BW Modeling Tools Query
Designer.

Custom Code Management Execution

Description
Leveraging the analysis conducted during the Explore phase of the project (see activity Custom Code
Impact Analysis), the list of mandatory changes is completed within the Realize phase of the project.
Custom code adjustment should take place in the already converted DEV system, and be transported to
QAS for testing, and then later into PRD. The transport of adjusted custom code objects to PRD takes
place as part of the system conversion Go-Live.
Requirements and Constraints
This activity is relevant in case own code needs to be made ready for SAP BW/4HANA (e.g. the system
conversion case). In case of a new implementation, or a landscape transformation, some custom code
from an old SAP BW system might be in scope to be used in the new SAP BW/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 BW/4HANA.

Procedure
1. Adjust Affected Custom Code
2. Test and Optimize Your Custom Code

Results
Custom code has been adjusted for SAP BW/4HANA.

Accelerators
• Service Information – Service Components for Custom Code Management
• ABAP custom code adaptation for SAP HANA – The efficient way
• SAP Note 1909597 - SAP BW Migration Cockpit for SAP HANA
4.12.1. Adjust Affected Custom Code
Objective
Adjust the custom code you have identified in the steps before and make it SAP BW/4HANA ready.

How SAP Can Support

SAP offers the Custom Code Management Tools enablement in which SAP helps to initialize and
configure the tools for custom code management. adjust the corresponding custom code.

Accelerators
• Custom Code Management Tools Enablement

Test Preparation
Description
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

The test framework, defined in the Test Preparation during the Explore phase, determines the scope for
the test preparation. See accelerator section for details.

Accelerators
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions

4.13.1. Prepare Tests

Objective
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 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 Service
Marketplace.

Accelerators
• SAP Best Practice Explorer
 Test Execution
Description
In this activity, integration test, regression test and user acceptance test take 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.
4.14.1. Perform Integration / Regression / User Acceptance Test
Objective
The goal of this task is to perform an 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 also contains aligned setup of relevant test data that will be commonly
used.

• Execute Integration Test Case #1 – n:

Perform the Integration test according to the 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 conversion to SAP BW/4HANA may impact productive business processes even following 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
are 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 also contains aligned setup of relevant test data that will be commonly used.

• Execute User Acceptance Test Case #1 – n:

Perform the test according to the 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.

 QAS Setup
Description
This activity sets up a quality assurance environment (QAS).

Requirements and Constraints

This activity is required for the New Implementation, Remote Conversion, and Shell Conversion scenario.

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 QAS environment has been set up successfully.

Tasks
• Perform QAS Setup

4.15.1. Perform QAS Setup

Objective
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 also activity “Dev Setup” in the Explore phase)
• Run the technical system setup.
• Transport development and configuration changes from DEV to QAS. Also onsider potential manual
rework activities.

Results
Finally, the QAS environment is ready for testing.

Object and Data Transfer for Remote Conversion

Description
Depending on the type of the remote scenario, data transfer takes place in one of the following ways:

• BW objects and data flows are transferred to the new BW/4HANA system (Remote Conversion)
• Only selected data models are transferred without data (Shell Conversion).

In the case of a Shell Conversion, historical data is ignored, and the system starts fresh. However,
you have the option to load data from the old BW system or from source systems. See separate
activity “Object transfer in a Shell conversion”.

The Planning and preparation of the Remote Conversion has taken place in the Explore phase with the
Assessment, followed by customer activities like system setup and software installation of the SAP
BW/4HANA system in QAS. In the Realize phase the first test cycle of the data migration can start.
 The SAP BW/4HANA Conversion Cockpit is used to convert from classic SAP BW data models
and data flows to HANA-optimized objects. The converted objects will be collected in SAP BW,
transported to and created in the new SAP BW/4HANA system.

Figure 4.7: Remote Conversion Details

The BW/4HANA Conversion Cockpit offers status management and progress tracking to ensure a
comprehensive documentation of the executed activities. All activities are performed from within the
BW/4HANA Conversion Cockpit with a step-by-step guidance. In case of issues, the data transfer activity
picks up the process from the latest state – re-execution of already performed steps is not required.

Prerequisites
The BW sender system and the BW/4HANA receiver system are set up and the necessary pre-checks are
done.
Tasks
• Perform Object Conversion Using SAP BW/4HANA Conversion Cockpit
• Transfer of ADP processes using the BW/4HANA Conversion Cockpit

4.16.1. Perform Object Conversion Using SAP BW/4HANA Conversion Cockpit

The Conversion Cockpit next transfers the cluster tables using RFC to the SAP BW/4HANA system,
including Unicode conversion, if required.

The BW/4HANA Conversion Cockpit picks up data from infoCubes, DataStore Objects, Characteristics
and Request Metadata from read reports in the sending SAP BW system into cluster tables in the sending
system.

Figure 4.8: Data Transfer in the Remote Conversion

The task lists used in the SAP BW/4HANA Transfer Cockpit are documented in detail in the “Task Lists
Documentation for Conversion to SAP BW/4HANA” (see accelerator section).

Procedure
To initiate the transfer of data models and data flows from SAP BW to SAP BW/4HANA and convert them
to HANA-optimized objects, log in to the original SAP BW system, start the SAP BW/4HANA Transfer
Cockpit (transaction RSB4HCONV) and select “Execute Scope Transfer” in the section “Realization
Phase”. To load a new scenario, choose “New”. After creating the package, the system automatically
navigates to the SAP BW/4HANA Conversion Cockpit.

Proceed in the SAP BW/4HANA Conversion Cockpit as described in the Conversion Guide for SAP
BW/4HANA 2.0, chapter 5.5.

Accelerators
• Task Lists Documentation for Conversion to SAP BW/4HANA
• Conversion Guide for SAP BW/4HANA 2.0
4.16.2. Transfer APD Processes using the BW/4HANA Conversion Cockpit
Objective
The APD Transfer Tool can be used to convert APD processes in SAP BW into process chains in SAP
BW/4HANA.

Procedure
Refer to the Conversion Guide for SAP BW/4HANA 2.0, chapter 5.6, for a detailed description of the APD
transfer.

Note: The APD Transfer Tool and SAP Notes related to remote conversion must be installed on the SAP
BW/4HANA system already.

How SAP Can Support

SAP offers the service Remote Conversion Execution for BW/4HANA with the following scope:

• SAP-led execution of data migrations and landscape transformations including tailored support for
going live and for a defined post-go-live period
• Procedure guidance for customer’s tasks in the transformation project
• Expert support, tailored to the customer‘s situation, to secure the success of the transformation
project, such as providing special expertise for performance optimization for landscape
transformation technology

Accelerators
• Conversion Guide for SAP BW/4HANA 2.0
• Remote Conversion Execution for SAP BW/4HANA

4.16.3. Object transfer in a Shell Conversion

Objective
In a Shell Conversion, only a set of selected objects is transferred to the target system. This is done with
the Scope Transfer Tool in the SAP BW/4HANA Transfer Cockpit of the original SAP BW system and in
transaction STC01 with the task list SAP_BW4_TRANSFER_REMOTE_SHELL.

Procedure
Open the SAP BW/4HANA Transfer Cockpit and click “Execute Scope Transfer”. Select “Remote
(Metadata only)”.
Figure 4.10: Select Transfer Scenario

Choose that you want to create a new conversion run. The task list
“SAP_BW4_TRANSFER_REMOTE_SHELL” opens.

Select the step “Collect scope for transfer (Data Flow)” - here you define which objects should be
converted - and execute the task list run.

Figure 4.11: Task List SAP_BW4_TRANSFER_REMOTE_SHELL

Note: To limit the scope to the least number of objects based on dependencies, you can select “Minimal
scope”. This option allows separating the transfer of the reporting layer from the transfer of the staging
layer. This way you can, for example, convert a MultiProvider to a CompositeProvider without selecting
the Part Providers of the MultiProvider.

As a next step, define the object mapping between the old objects and HANA-optimized objects.

Proceed with the task list until the end of the Prepare phase.

Results
The selected Data Models and data flows are transferred from SAP BW to SAP BW/4HANA and
converted to HANA-optimized objects.
Accelerators
• Conversion Guide for SAP BW/4HANA 2.0

Cutover Preparation
Description
The purpose of this activity is to perform the final preparation steps for cutover. The cutover plan will be
tested in the Dress Rehearsal activity in the Deploy phase.

Requirements and Constraints

This activity is required for all scenarios. 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)

4.17.1. Production System Setup

Objective
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 installation guide on 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.

4.17.2. Create Cutover Plan (New Implementation)

Objective
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:

o Technical – Project team participation only for the purpose of validating steps
o Dry run – Full execution of the cutover schedule with the entire team for the purpose of
validating steps and data
o 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 a 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 to handle issues that cannot be resolved within the planned
business downtime.

4.17.3. Create Cutover Plan (System Conversion)

Objective
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 in the SAP Best Practices for system conversion for SAP
S/4HANA (accelerator section) for getting 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:

1. Prerequisite steps for the production conversion

2. Ramp-down activities (e.g. batch jobs, interfaces, etc.)
3. Pre-conversion validation reports
4. End-user lockout
5. Technical migration and business data conversion
6. Post conversion changes (e.g. transports, parameter changes, etc.)
7. Technical post conversion validation reports (e.g. checking for business data consistency)
8. Business driven system validation and comparison of the pre and post conversion reports
9. Go/No-Go decision
 10. Ramp-Up activities (e.g. batch jobs, interfaces, etc.)
11. User unlock
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:

1. Document key steps of the migration and conversion activities.

2. Assign owners to all tasks.
3. Review the tasks with the owners to confirm ownership and document the estimated duration.
4. Conduct at least one full walk-through of the plan as an entire team.
5. Document the fallback or contingency plan to safely return production operations in the event of a
No-Go.
6. 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.
7. 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 plan in the event there is an unforeseen issue that is unable to be
resolved within the planned business downtime.

Accelerators
• Cutover Plan - Example

Sizing & Scalability Verification

Description
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
Accelerators
• General Information on Sizing
• Proactive Performance and Capacity Management - Best-Practice Document
• Sizing Approaches for SAP HANA (incl. SAP S/4HANA and Fiori) – Lessons Learned Document

4.18.1. Optional: Perform Sizing Verification

Objective
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:

1. Load testing of the pre-production system

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

Accelerators
• Service Information – Service Components for Platform Design
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions

4.18.2. Optional: Perform Scalability Verification

Objective
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 with 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

Accelerators
• Planning High Volume Load Tests – A Methodology
 IT Infrastructure Setup and Test
Description
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
1. Set Up IT Infrastructure
2. Set Up Integration with SAP Analytics Cloud
3. Test IT Infrastructure

Results
The technical infrastructure has been properly tested.

4.19.1. Set Up IT Infrastructure

Objective
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 set up by the hardware partner.

Results
The IT infrastructure is set up.
4.19.2. Set up Integration with SAP Analytics Cloud
Objective
Connect the SAP BW/4HANA to SAP Analytics Cloud.

There are two types of data connections possible: live data connections and import data connections.

Live Data Connections

• Are available for cloud and on-premise data sources

• Do not replicate your data in SAP Analytics Cloud
• Use existing data models for analysis
• Update your data visualizations and stories with new data in real-time

Import Data Connections

• Are available for cloud and on-premise data sources

• Replicate data within SAP Analytics Cloud
• Create new data models through the SAP Analytics Cloud Modeler
• Update your data visualizations and stories when refreshed

Prerequisite
The decision to connect SAP BW/4HANA to SAP Analytics Cloud with a Live Data Connection or an
Import Data Connection has been taken.

Procedure

Live Data Connection

A live connection to the SAP BW/4HANA from SAP Analytics Cloud means that queried data from SAP
BW/4HANA always remains behind the corporate firewall and does not enter the cloud. You can follow the
Guided Playlist to perform all required steps for setting up the Live Data Connection:
Figure 4.12: Guided Playlist for SAP BW Live Data Connection

In detail, the steps are:

• Configure CORS (Cross-Origin Resource Sharing) on your SAP NetWeaver system

• Add SAP Analytics Cloud to the http Whitelist
• Verify end-users‘ web browser configuration and access
• Add a remote system to SAP Analytics Cloud
• Configure SSO (single sign-on)
• Enable Browsers to Connect from the Internet without VPN

Import Data Connection

With the Import Data Connection, data is queried from SAP BW/4HANA and is imported to SAP Analytics
Cloud.

You can follow the Guided Playlist to perform all required steps for setting up the import data connection.
Figure 4.13: Guided Playlist for SAP BW Import Data Connection

In detail, the following setup steps must be performed, using the SAP Analytics Cloud Agent Simple
Deployment Kit (for more information, see „SAP Analytics Cloud Agent Simple Deployment Kit“ in the
accelerator section):

• Install the cloud connector. For more information, see „Installing the SAPCP Cloud Connector“.
• Install the SAP Analytics Cloud agent. For more information, see „Installing SAP Analytics Cloud
Agent“.
• Install the SAP Java Connector (must be installed using the instructions in the Post-Setup Guide
included in the kit - for more information, see „Installing the SAP Java Connector“).
• Configure the SAPCP cloud connector. For more information, see „Configuring the SAPCP Cloud
Connector“.
• Configure the SAP Analytics Cloud agent in SAP Analytics Cloud For more information, see
„Configuring SAP Analytics Cloud Agent“.

Accelerators
• SAP Analytics Cloud Guided Playlists
• SAP Analytics Cloud Agent Simple Deployment Kit
 • Installing the SAPCP Cloud Connector
• Installing SAP Analytics Cloud Agent
• Installing the SAP Java Connector (JCo)
• Configuring the SAPCP Cloud Connector
• Configuring SAP Analytics Cloud Agent
• https://blogs.sap.com/2017/11/28/sap-analytics-cloud-live-data-connection-to-sap-bw4hana-using-
cors-and-sso/
• SAP Analytics Cloud: Live Data Connection to SAP BW/4HANA using CORS and SSO

4.19.3. Test IT Infrastructure

Objective
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:
o Performance
o Flexibility procedures (e.g. by moving system load to other hosts (e.g. by using
virtualization technics), adding instances, changing instances)
o High Availability
o Disaster Recovery
o Backup and Restore
o 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.
 Operations Implementation
Description
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
1. Collect detailed Operations Requirements
2. Roles and Responsibilities
3. Support Processes and Procedures
4. Operations Support Tools
5. Operations Documentation
6. Knowledge Transfer

Results
IT support operations have been prepared to operate SAP BW/4HANA as of Go-Live.

How SAP can Support

SAP has multiple offerings to SAP Enterprise Support customers with respect to operations
implementation:

• SAP ESRV System Monitoring: System, Database and Host Monitoring – empowering and
knowledge transfer are the main goals of this service
• SAP ESRV Integration Management: Empowerment and knowledge transfer on interface and
connection monitoring are the main goals of this service
• SAP ESRV Root Cause Analysis and Exception Management: Empowerment and knowledge
transfer
• SAP ESRV Data Volume Management (see Activity Data Volume Planning)
• SAP ESRV Test Management: This service is used to implement the ALM process “Test
Management” on a pilot basis at a customer. The pilot implementation addresses the processes of
User Acceptance-, Functional-, integration-, and Regression Testing (including Test Scope
Identification and Test Automation)
• SAP ESRV Security Engagement: This service will help the customer on tuning their operations on
different aspects based on the needs of the customer, for example:
o Identify the key security topics of interest
o Complement the view by a high level 360-degree review on potentially relevant security
areas and by recent security news
o Define the focus spots to be addressed and set up a project plan
o Define Improvements of the customer’s security situation
• System Administration Workshop: update for SAP BW/4HANA will be available in Q2/2017
• SAP Solution Manager Starter Pack: Guidance for the customer on the initial configuration of SAP
Solution Manager
• SAP Empowering Services: Empowering IT resources to maintain, operate, administer an SAP
component

Accelerators
• Service Information – Service Components for the Transition to Operations
• SAP System Monitoring Service
 • SAP Integration Monitoring Service
• SAP Root Cause Analysis and Exception Management Service
• SAP Data Volume Management Service
• SAP Change Control Management
• SAP Test Management
• SAP Security Management
• SAP System Administration Workshop
• SAP Solution Manager Starter Pack
• SAP Empowering Service BW

4.20.1. Collect detailed Operations Requirements

Objective
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 such as 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 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 as well during Application Design
and during the Technical Architecture. This will bring input to finalizing the new Access Management
 process with the differences in role 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 than having each activity responsible go to the project resource having the knowledge
required for his activity. The transition manager can regroup the detailed information required for the
different activities and gather the corresponding details from the best project resources at once.

How SAP Can Support

When SAP is engaged in a Premium Engagement including other services included in this road map, the
gathering of detailed information will be eased. For example, Integration Validation will be a very valuable
source of detailed information on the monitoring setup and the critical areas to be supported. Custom
Code will be a key source of information for the application support knowledge transfer.

4.20.2. Roles and Responsibilities

Objective
Whatever the current IT support framework is: Operational activities are handled by 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 BW/4HANA, there are changes in the roles and responsibilities of some of
these resources. These changes will depend highly on your current solution (if you already have SAP
implemented), on your support strategy (if you engage a Service Provider to support your SAP
BW/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.

4.20.3. Support Processes and Procedures

Objective
With the implementation of SAP BW/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 BW/4HANA:

• Event Management:
o Analyze process change in event management caused by new/modified/retired
monitors
 o Retire obsolete monitors, and monitor templates (in SAP Solution Manager)
o Retire obsolete manual monitoring procedures
• Incident Management:
o Update assignment groups, review incident triage
o Update support resources
o Update incident categorization
o Process flow and escalation management including partners and SAP
o Remove obsolete incident attributes
• Problem Management:
o Update problem management process to include new analysis tools
• Service Level Management:
o Update SLAs if required (due to changed business KPIs)
o Update SLA reporting
• Access Management:
o Access for new solution / tools granted to new support team members including
partner resources
o New/changed access management process for new/changed solution items (e.g.
SAP HANA database)
• Change Management:
o Update support resources including requesters and new approvers
o Update categorization, if required
o Process flow including partners and escalation management
o Include project defects in incident database
o Remove obsolete change attributes
o Evaluate current change process to include e.g. SAP HANA changes
• Test Management:
o Test library should include new test plans/scripts
• Job Management:
o 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:
o Changed tools and activities due to new concepts in data volume management
(e.g. data aging)
o Adapt process in those areas where classic data archiving is no longer available
• System Recovery:
o 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 on 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 BW/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.
Accelerators
• Customer Center of Expertise
• Getting Started with Primary CCOE
• Primary CCOE Check List
• SAP Support Standards

4.20.4. Operations Support Tools

Objective
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 greater. 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 BW/4HANA, it may be required to adjust existing IT operational support tools,
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. As part of the Premium Engagement packages, SAP has dedicated
offerings to support this task.

• Adjust SAP Solution Manager configuration with respect to:

o General system management (“Managed System Setup”)
o Monitoring elements (e.g. critical interfaces, critical batch jobs, End-User-
Experience, SAP HANA DB), and monitoring customizing (e.g. alert thresholds)
o 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:
o HANA Cockpit to manage the SAP HANA database
o SAP HANA Studio e.g. for HANA programming, or HANA dictionary
o SAP DB Control Center for central & aggregated DB monitoring
o 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.

Accelerators
• SAP Support Standards
• Applications Operations WIKI for SAP Solution Manager
• SAP HANA Administration Guide
• SAP HANA Technical Operations Manual
• Monitoring SAP Fiori Apps
• Troubleshooting SAP Fiori Apps
4.20.5. Operations Documentation
Objective
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 BW/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 settings 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 settings 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 on how to 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.

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.

Accelerators
• SAP Support Standards
• SAP HANA Administration Guide
• SAP HANA Technical Operations Manual
• Monitoring SAP Fiori Apps
• Troubleshooting SAP Fiori Apps
• SAP Fiori Troubleshooting Guide
• SAP Fiori UI Development Toolkit

4.20.6. Knowledge Transfer

Objective
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 the Go-Live of a new solution, 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 the 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.
 Execution, Monitoring and Controlling Results
Description
The purpose of this deliverable is for the project 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.

Tasks
• Direct and Manage Project Execution
• Update Project Management Documents
• Manage Project Issues, Risks, and Changes
• Communicate Project Status and Progress
• Plan and Execute Agile Sprints
• Perform Scrum-of-Scrums Meeting (Iterative)

4.21.1. Direct and Manage Project Execution

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

4.21.2. Update Project Management Documents

Objective
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)

4.21.3. Manage Project Issues, Risks, and Changes

Objective
The purpose of the Manage Project Issues, Risks, and Changes task is to have a consistent,
comprehensive approach to managing project issues and 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.

4.21.4. Communicate Project Status and Progress

Objective
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 updatetypically produced 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 reuses 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.
 4.21.5. Plan and Execute Agile Sprints
Objective
The purpose of this task is for the project team to plan and execute agile sprints. The project team runs
the Realize phase in a 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).

Figure: Steps of Agile Sprints

During each sprint the project team conducts the 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) selects 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 the
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:

1. What went well during the sprint?

2. What do we want to preserve?

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

Accelerators
• Agile Release Planning (Customer)
• Backlog Template

4.21.6. Perform Scrum-Of-Scrums Meeting (Iterative)

Objective
A 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.

Accelerators
• Agile Scrum Meeting Guidelines (Customer)
 OCM Alignment Activities
Description
The purpose of this deliverable is to identify and assess other OCM relevant areas.

Tasks
• OCM and Testing Alignment
• OCM and Data Migration Alignment

4.22.1. OCM and Testing Alignment

Objective
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

4.22.2. OCM and Data Migration Alignment

Objective
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

Phase Closure and Sign-Off phase Deliverables

Description
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

Tasks
• Conduct Knowledge Management Gate
• Conduct Project Quality Gate
• Conduct Project Management Review Service
• Conduct Design Review Service
• Manage Fulfilled Contracts
• Obtain Customer Sign-Off for Phase Completion
 4.23.1. Conduct Knowledge Management Gate
Objective
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.

Accelerators
• Lessons Learned Guide (Customer)
• Lessons Learned Template (Customer)

4.23.2. Conduct Project Quality Gate

Objective
The purpose of the Quality Gate is to ensure that both compliance and project management standards are
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 mandatory deliverables
associated with a methodology while ensuring best practice standards have been applied to ensure
quality. In detail:

• To ensure that all key deliverables and actions of the gate have been completed in compliance
with recommended practices and to the customer’s satisfaction

• To enable project management to continuously communicate the process and build quality directly
into the project

• To provide a tool to effectively manage project expectations and monitor customer satisfaction.
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 to the quality gate checklist by the Project
Manager to the different project types.

Accelerators
• QGateChecklist Concept SAP Activate
• QGateChecklist Template Introduction
• Quality Built In New QGate Checklist

4.23.3. Conduct Project Management Review Service

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

4.23.4. Conduct Design Review Service

Objective
The purpose of this task is to execute a Design Review of SAP Solution service that provides a proactive
quality assurance review of the design of the SAP solution which is being implemented. It delivers an
impartial analysis of all aspects of the solution design – across all relevant design perspectives – and
leads to an early detection of potential solution risks and offers actionable risk mitigation
recommendations.

4.23.5. Manage Fulfilled Contracts

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

4.23.6. Obtain Customer Sign-Off for Phase Completion

Objective
The purpose of this task is to conduct formal closure of the project phase and sign-off the deliverables
completed during the phase. The main goal of this process is to:

• Ensure that all required deliverables from this phase and the project are complete and accurate,
and close any outstanding issues

• Identify lessons learned during the phase to prepare for formal project closure

• Capture customer feedback and potential customer references

When sign-off is obtained, the project can proceed to the next phase. Use the attached sign-off sheet for
this task.

Accelerators
• Phase Sign-Off Template (Customer)
5. Deploy Phase
Once quality gate Q3 – Realize-to-Deploy has been passed successfully, the final preparation for Go-Live
starts in the Deploy Phase.

Figure 5.1: Activities in the Deploy Phase

End user trainings for the new solution are running in the Solution Adoption work stream.

In the Application Design & Configuration work stream, the implementation activities will come to an
end. Integration validation ensures the required performance.
Testing (in particular regression and user acceptance testing) is taken care of in the 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 Extensibility work stream in the Deploy phase.

In the Technical Architecture and Infrastructure work stream, final IT service setup activities followed
by, the final rehearsal of the cut-over procedure will take place. Most importantly, this work stream
processes the implementation of the productive system which will be finalized at the Go-Live weekend.

Operations & Support ensures the IT operations team is ready to operate the new system 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 system. The Deploy phase ends with the production
cutover at the Go-Live weekend.

Phase Initiation
Description
The purpose of the phase initiation deliverable is to formally recognize that a new project phase starts.

Tasks
• Allocate Resources and Update Project Schedule
• Perform Kick-off Meeting

Accelerators
• Project Setup Checklist Sample (Customer)

5.1.1. Allocate Resources and Update Project Schedule

Objective
The purpose of this task is to confirm resource availability for the particular phase.

Accelerators
• Global Resource Management Portal page (SAP Employee)

5.1.2.Perform Kick-off Meeting

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

Accelerators
• Project Kick-off Template (Customer)

Learning Realization
Description
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
1. Create Training Execution Plan
2. Execute End User Training

Results
The end users have been trained. They are enabled to use the new system.

5.2.1.Create Training Execution Plan

Objective
The training execution plan is based on the results as of the training concept, the Learning Needs
Analysis, and the end user assignment. Create a training execution plan.

Procedure
.

The training execution plan should include:

• The scheduling of the trainings.

• The training approach and method (as of the concept).
• The assigned instructors (Co-instructor / Key Users)
• Location, duration, 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.

5.2.2.Execute End User Training

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

How SAP Can Support

With event and invitation management, SAP can support this task as part of an individual education
consulting offer from SAP Education. Event and invitation management is the process of booking training
facilities /resources, managing courses in the learning management solution, and publishing learning
content in the digital environment. For instance, SAP can:

• Send invitations to trainers and end users including all necessary information
• Prepare facilities (virtual or onsite) for training delivery
• Allocate properly sized and equipped rooms for training (including network connection)
• Organize training material distribution.

Accelerators
• SAP Enable Now at SAP Online Help Portal

Integration Validation
Description
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.

5.3.1.Finalize Integration Validation

Objective
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 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 order the CQC for Technical Performance Optimization (TPO).

Accelerators
• Service Information – Service Components for Safeguarding the Digital Transformation
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• CQC for Technical Performance Optimization (TPO)

Dress Rehearsal
Description
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 intended changes 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:

1. The detailed cutover plan with owners, dependencies and durations fully documented.
2. The involvement of all task owners.
3. A test environment representative of the source and target platforms for production.
4. The technical cookbook, which details all of the required technical migration steps.
Procedure
• Perform Cut-Over Rehearsal

5.4.1.Perform Cut-Over Rehearsal

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

5.4.2.Finalize IT Infrastructure Services

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

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.
 Operations Readiness
Description
This activity checks the customer’s ability to operate SAP HANA and SAP BW/4HANA as of Go-Live.

Requirements and Constraints

This activity is recommended for all scenarios.

Procedure
• Operational Readiness (System Conversion)

or

• Operational Readiness (New Implementation)

5.5.1.Operational Readiness (System Conversion)

Objective
In case of a system conversion, the customer operated a productive SAP BW 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 already knows how to operate SAP. Only the delta
to safely operate SAP BW/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:

1. Roles and Responsibilities

2. Support Processes and Procedures
3. Operations Support Tools
4. Operations Documentation
5. Knowledge Transfer

Results
The IT support organization is ready to operate SAP BW/4HANA as of Go-Live.

How SAP Can Support

SAP offers an Operations Readiness check. The scope covers tools for monitoring, troubleshooting, and
software logistics. It also includes 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.

Accelerators
• Service Information – Service Components for the Transition to Operations

5.5.2.Operational Readiness (New Implementation)

Objective
In case the customer knows already how to operate SAP BW, then only the delta to safely operate SAP
BW/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 BW/4HANA.

Procedure
For customers who know how to operate SAP BW already: Check if all operational aspects have been
implemented as planned (see Operations Implementation activity in the Realize phase). This covers:
 1. Roles and Responsibilities
2. Support Processes and Procedures
3. Operations Support Tools
4. Operations Documentation
5. 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
BW/4HANA operations (see SAP Support Standards).
• Check if primary CCOE certification has been gained.

How SAP Can Support

SAP offers an Operations Readiness check. The scope covers tools for monitoring, troubleshooting, and
software logistics. It also includes 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.

Accelerators
• Service Information – Service Components for the Transition to Operations
• Customer Center of Expertise
• Getting Started with Primary CCOE
• Primary CCOE Check List
• SAP Support Standards

Execution, Monitoring and Controlling Results

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

Tasks
• Update Project Management Plan
• Direct and Manage Project Execution
• Monitor and Control Project Activities
• Manage Issues, Risks and Changes
• Communicate Status and Progress to Project Stakeholders

Accelerators
• Project status report for SAP Activate / S/4HANA
 5.6.1.Update Project Management Plan
Objective
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.

5.6.2. Direct and Manage Project Execution

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

5.6.3. Monitor and Control Project Activities

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

5.6.4.Manage Issues, Risks and Changes

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

Accelerators
• Change Request Log - template (Customer)
• Open Issues List Template.xls (Customer)

5.6.5. Communicate Status and Progress to Project Stakeholders

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

Accelerators
• Project status report for SAP Activate / S/4HANA

Release Closing
Description
The purpose of this deliverable is to formally close the release and prepare for next release and/or sprint
planning meeting.

Tasks
• Prepare Product Backlog for Next Release/Sprint
• Conduct Release Retrospective
• Update the Release and Sprint Plan
 5.7.1. Prepare Product Backlog for Next Release/Sprint
Objective
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 the definition of
Ready for Build so they are understood by the SCRUM team and can be estimated during the sprint
planning meeting.

Accelerators
• Backlog including Delta Requirements and Gaps.xlsx

5.7.2. Conduct Release Retrospective

Objective
The purpose of this task is to conduct retrospective meetings with the project team to identify potential
improvements of the SCRUM process. The objective of this task is to serve as a 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.

Accelerators
• Agile Sprint Retrospective Template (Customer)

5.7.3.Update the Release and Sprint Plan

Objective
The purpose of this task is to update the Release and Sprint Plan according to changed priorities and
focus of the team. It is the accountability of the Product Owner to maintain the Release and Sprint plan
and keep it current during the project.

Accelerators
• Backlog including Delta Requirements and Gaps.xlsx

Production Cutover
Description
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 (Selective Data Transition)

Results
After completion of this activity, the productive SAP BW/4HANA system is available for the end users.

How SAP Can Support

The “SAP Going Live Support” service component 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.

Suddenly slow running applications in the new productive system are addressed by a Technical
Performance Optimization service component (SAP Enterprise Support order the CQC for Technical
Performance Optimization (TPO) instead): The technical performance optimization service component
improves your SAP solution by helping you to configure your SAP BW/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 Advisor for details.

Accelerators
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions
• Service Information - Value Assurance Foundation
• CQC for Technical Performance Optimization (TPO)

5.8.1.Convert Productive System (System Conversion)

Objective
The goal of this task is to convert the productive system.

Procedure
Proceed as follows:
1. Request Restore Point of Production System Prior to Final Cutover Activities
2. Execute the conversion of the production system following the tasks defined in the cutover plan.
3. Document the actual duration of each step to support future projects.
4. Capture any variances to the plan along with the decision maker who approved the change.
5. The cutover manager(s) should proactively notify task owners of upcoming tasks, to ensure their
availability.
6. Regularly communicate status to stakeholders.
7. After conversion has finished (including mandatory post-processing activities), the system has to
be tested and validated
8. 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.

5.8.2.Production Cutover (New Implementation)

Objective
The goal of this task is to cut over production.
Procedure
1. Execute the cutover following the tasks defined in the cutover plan. This includes the final
production data load.
2. Document the actual duration of each step to support future projects.
3. Capture any variances to the plan along with the decision maker who approved the change.
4. The cutover manager(s) should proactively notify task owners of upcoming tasks, to ensure their
availability.
5. Regularly communicate status to stakeholders.
6. After the data is loaded, testing and data reconciliation must be completed.
7. 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.

Post Go-Live End-user Training

Description
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

Tasks
• Prepare End-User Training for Scope Option
• Deliver End-User Training for Scope Option
• Collect Training Evaluations Feedback
• Perform People Readiness Assessment

5.9.1.Prepare End-User Training for Scope Option

Objective
The purpose of this task is to adapt available training material and make it suitable for End User training

5.9.2.Deliver End-User Training for Scope Option

Objective
This task executes the delivery of EU training as well as capturing feedback on both the training session
and the trainer.

5.9.3.Collect Training Evaluations Feedback

Objective
The purpose of this task is to capture feedback on both the training session and the trainer delivering the
material.

5.9.4.Perform People Readiness Assessment

Objective
This task checks how prepared the people in the organization are with regards to the identified changes
and if they have received an end user training.
 Production Support after Go-Live
Description
The purpose of the production support and transfer to solution deliverable is to confirm that the resources
and processes are in place to support the ongoing solution and to complete the steps required to close the
project and finish documentation.

Tasks
• Finalize Solution Manager Update – Solution Documentation
• Obtain Solution Transition to Production Acceptance Protocol Sign-off

5.10.1. Finalize Solution Manager Update – Solution Documentation

Objective
Purpose of this task is to hand over the finalized implementation project and its content and set it up as a
productive solution in SAP Solution Manager. This provides the basis for the follow-up activities in the
Operate Phase.

5.10.2. Obtain Solution Transition to Production Acceptance Protocol Sign-Off

Objective
Purpose of this task is to obtain customer approval (sign-off)
 Hyper Care Support
Description
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)

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. With the monitoring of the core business processes
and the system environment of the new 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.

Accelerators
• Service Information – Service Components for Safeguarding the Digital Transformation
• SAP Value Assurance for SAP BW/4HANA – Service and Service Component Descriptions

5.11.1. Monitor Resource Consumption

Objective
The objective of this task is to identify the resource consumption after Go-Live and to manage it
permanently to answer questions like:

1. What is the current workload profile?

2. Is the resource consumption in a reasonable ratio to the business logic and value?
 3. 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:

1. Physical CPU consumption over time (SAP application and DB server): [average per month /
week / day]
2. Workload profile (SAP application and DB server): [peaks, averages, load balancing]
3. Consider seasonal fluctuations: [e.g. period end closing]
4. Memory consumption (SAP application and DB server): [buffer settings and usage]

5.11.2. Analyze Workload

Objective
Workload analysis first has the goal to provide information about 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

1. Resource consumption per task type: [#steps * (CPU time + DB time)]

2. Resource consumption per transaction/process: [#steps * (CPU time + DB time)]
3. Duration of background jobs: [seconds]
4. Response time per dialog transaction: [average time, time distribution]
5. 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

5.11.3. Check System Scalability

Objective
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:

1. Sort the list of top consumers by the consumption of the resource that is the largest bottleneck.
2. Check, starting with the largest resource consumer:
 o Whether it is possible to reduce the resource consumption by optimizing the database or
the coding that is responsible for the resource consumption.
o Whether it is possible to avoid the bottleneck by optimizing load balancing and scheduling
of services.
o 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 gives
the ability to predict the effect of changing business beforehand.

5.11.4. Follow-up on Going-Live Check (Verification Session)

Objective
Depending on the project scope, you have either ordered the analysis session of an SAP OS/DB Migration
Check, or an SAP Going-Live Functional Upgrade Check, or an 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.

Accelerators
• SAP OS/DB Migration Check
• CQC OS/DB Migration Check
• SAP Going-Live Functional Upgrade Check
• CQC for Upgrade
• SAP Going-Live Check for Implementation
• CQC for Implementation
 Handover to Support Organization
Description
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
1. Resolve and Close Open Issues
2. 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 functional design
and execution services.

Please ask your SAP contact (e.g. SAP Client Partner) for more information.

Accelerators
• Build Execution

5.12.1. Resolve and Close Open Issues

Objective
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 an acceptable timeframe, 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.

5.12.2. Handover Operations Responsibility

Objective
In this task, operations responsibility is formally handed over from the team who operated the new SAP
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 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.

Project Closure and Sign-Off Project Deliverables

Description
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

Tasks
• Conduct Knowledge Management Gate
• Conduct Project Quality Gate
• Conduct Project Management Review Service
• Manage Fulfilled Contracts
• Resolve and Close Open Issues
• Finalize Project Closeout Report
• Obtain Sign-off for Project Closure and Results Acceptance

5.13.1. Conduct Knowledge Management Gate

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

Accelerators
• Lessons Learned Guide (Customer)
• Lessons Learned Template (Customer)

5.13.2. Conduct Project Quality Gate

Objective
The purpose of the Quality Gate is to ensure that both compliance and project management standards are
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 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.

Accelerators
• QGateChecklist Concept SAP Activate
• QGateChecklist Template Introduction
• Quality Built In New QGate Checklist

5.13.3. Conduct Project Management Review Service

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

5.13.4. Manage fulfilled Contracts

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

5.13.5. Resolve and close open Issues

Objective
The purpose of this task is to achieve a closure of all open project issues which is a prerequisite for the
final project closure.

5.13.6. Finalize Project Closeout Report

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

5.13.7. Obtain Sign-off for Project Closure and Results Acceptance

Objective
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.
Accelerators
• Phase Sign-Off Template (Customer)
• Project Closeout Report Presentation Template (Customer)

QG5 – Transition to Support Organization

Description
When reaching quality gate 5, operations of the new SAP system has been matured, and the conversion
project comes to an end.
Requirements and Constraints
This quality gate runs together with the activity Project Closure and Sign-Off Project Deliverables.

Procedure
• Run Q-Gate Transition to Support Organization

5.14.1. Run Q-Gate Transition to Support Organization

Objective
The objective of this task is to run the last Q-Gate. The main purpose of managing the quality gates is to
ensure quality within the project and the transition to the support organization. All open tasks or issues
should be assigned from project team members to support organization members and if in place, the SAP
engagement team (e.g. SAP MaxAttention).

Prerequisites
In order to support the appropriate Quality Gates for the engagement, the SAP TQM and Quality Manager
must have access to the Project Charter and any primary document giving an overview of the project
schedule and the major milestones defined by the customer’s Project Management Office.

Procedure
The quality gate includes the review of the project status, the confirmation of major deliverables being
completed, and the formal sign-off of the quality gates based on the defined completion criteria. The
process owner is the project manager. To get the most possible value out of the quality gate, it is
recommended to perform /execute the quality gate by a quality manager (from customer/ partner or SAP
side) who is independent of the project management constraints (time, cost and budget) but has
experience in managing projects and generally experienced in the technical and operational background.
In exceptional cases project participated key team members (customer project manager supported by the
SAP TQM) may take over the role of the quality manager.

How to proceed:

• Process begins with a preparation call to plan the deliverables to be checked during the quality
gate, and to identify participants at the assessment meeting (include the customer project manager,
SAP TQM (if SAP has delivered services within the project phase), program manager as applicable
and representation from others on invitation partner project manager, PMO and additional experts
to support specific technical or business aspects.
• At the beginning of the quality gate the customer project manager presents the overall project status.
• The assigned quality manager reviews the fulfillment of the requirements of the checklist items. He
verifies the quality of deliverables regarding completeness, accuracy (if applicable) and actuality to
reach the defined and agreed customer expectations.
• The result of the quality gate is a signed quality check list which contain agreed action items for
follow-up.
When the Q-Gate is not passed the transition to new stage is on hold and action items have to be defined
for follow-up. Store the Q-Gate results in SAP Solution Manager if possible. Decide on sending the Q-
Gate results to SAP.

Results
The filled-out Q-Gate check list shows the status of the project at the end of the Hyper Care phase.
The team has handed over all open tasks, issues to the operations team and if in place, the SAP
Engagement (MaxAttention).

How SAP Can Support

The SAP TQM supports the Q-Gate as part of the Value Assurance Foundation. The results of the Q-Gate
can be sent to the SAP MCC for support.

Accelerators
• Q-Gate Check List Transition to Support Organization
6. Run Phase
The transition project has ended with the Deploy phase. In the Run phase the aim is to establish 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.

Figure 6.1: Activities in the Run Phase

 Operate Solution
Description
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.

6.1.1.Safely and Efficiently Operate the new Solution

Objective
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 using SAP Solution Manager
• If not yet done configure core IT support processes like:
o Incident and Problem Management
o 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, your
COE needs to be “Primary Certified”.
• Configure efficient system management - SAP has developed a concept called “Run SAP like a
Factory”. Core elements are:
o Application Operations
o Business Process Operations

See SAP Support Portal (accelerator section) for getting 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 proactively 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 using the tools daily. 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, and
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

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 have permanent service available to address required changes and execution of service
requests.

In case the 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 in the
industry – from infrastructure to applications.

See accelerator section for details.

Accelerators
• SAP HANA Enterprise Cloud
• SAP Application Management Services
• Operations Control Center (OCC)
• Customer Center of Expertise
• Getting Started with Primary CCOE
• Primary CCOE Check List
• SAP Support Standards
• SAP Support Processes supported by SAP Solution Manager (Information and Offline Demos)
6.1.2.Continuously Optimize IT Operations
Objective
The purpose of this task is to continuously improve IT operations (e.g. via automation or switching from a
re-active to a pro-active operations approach).
Procedure
This task can only name some out of the 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).

Accelerators
• SAP Application Management Services
• Advanced Customer Center of Expertise (aCCOE)
• Continuous Improvement and Innovation with a Customer Center of Expertise – White Paper
 Improve and Innovate Solution
Description
The aim of this activity is to further improve and simplify your new solution to realize the 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

6.2.1.Periodically Update your SAP System

Objective
The goal of this task is to keep the SAP system 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.

Please note: More details on SAP feature and support pack implementation will be added to the road map
in a future version.

How SAP Can Support

SAP offers the planning and execution of SAP maintenance via Proactive Solution Maintenance as part of
SAP Application Management Services, complemented by embedded Test Management and Test
Execution services. See accelerator section for details.

Accelerators
• SAP Application Management Services

6.2.2.Initiate a new Innovation Cycle

Objective
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 cutting 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.

Accelerators
• Business Transformation Services
• Business Process Analytics
• Business Process Improvement
• SAP Application Management Services