Cloud, DevOps, IT4IT &Consumption Based PaaS Pricing for SAP, SAP HANA, S/4 HANA, BW on HANA, SaaS

Ajay Kumar Uppal

Customer Challenges

Confidential 2

Flexibility for production systems

Flexibility for non-production systems

High Availability, Cyber Security:− DevOps, Operations Orchestration, Cloud Service Automation, Security

− Excellent pro-active service delivery to avoid business disruptions

− Experience partner who has proven track record

Cost-effective: Improved SID/HW ratio; SID/FTE ratio

Consumption based & Minimal vendor lock-in

Agility: Transform from batch-oriented culture into real-time

Enable and improve online transactional processing

Provide real-time information at high speed

Enable real-time operational reporting

CUSTOMER Supported by PROVIDER

Confidential 3

Focus on the CUSTOMER

Future Business Maximise Business Value

− Enhance agility and flexibility in order

to react quickly to changes in

CUSTOMER needs and market

demands

− Focus on operational excellence and

efficiency enforcing consistency

through automation, improving

customer satisfaction

− Take advantage of new features and

functionality as they become available,

avoiding service enhancement

investments and disruption

Reduce Business Costs

− Create a leaner and more agile

business and IT environment

− Shift from a CapEx to OpEx model with

no upfront capital expenditure for new

infrastructure

− Take advantage of more flexible

commercial terms and avoid vendor

lock-in

− Reduce security risks and costs, both

financial and reputational

− Free-up subject matter experts to

focus on building competitive advantage

− Support growth and innovation e.g.

new products & services, new

markets, new channels, new

geographies

− Enable new business models e.g.

Reseller, SaaS

− Leverage the ‘everything as a

service’ trend with solutions for the

New Style of IT

− Real-time visibility, better control

− Overall productivity improvement

Consumption Based Key Principles

Pay only for what you use:

• It is Customers intent to acquire standard catalogue based services and components in a true P*Q model.

Focusing on actual usage, not allocated resources/components, usage per day or the smallest possible time

denominator.

Elasticity, scalability up & down:

• Customers expects that services acquired from the ICT supply base are scalable instantly, following demand

from Customers’ businesses, without the need for contract change notes.

No required minimum commitments

• The ICT consumption based model is free of any start-up costs, does not entail volume commitments and/or

contract duration, and has no termination costs and/or penalties when business demand drops. Charging starts

from the moment Customers is consuming services.

Self Provisioning – Consumer driven

• Providing Customers the ability to scale up, and limit demand up to the preferences of Customers, where

automated processes are embedded in the model. Including the ability to design budgetary ceilings and alerts

where required.

Real-time visibility to usage & performance

• Customers’ vision is to become a real-time company where ICT is an instrumental organization enabling this

vision. All ICT services need to provide full visibility on usage and performance

IT4IT

Confidential 6

DevOps Maturity Model & Cloud Services Maturity Model

Confidential 7

Cloud Service Automation & Orchestration Solution

ServerStorage NetworkingApplicatio

n

Application

owners

AutomationPortal

Catalog

Patching, Compliance, Auditing

Experts

IS

Consumer

Option

al

Self-

Service

Billing

Reports

Preserve Expertise

CostsRedution

IncreaseSatisfaction

PreserveInvestment

OperationalEfficiency

Req

ue

st

Business

Service

Cloud options for MS Messaging

Confidential 9

Leveraged IT4IT, DevOps & other tools to raise the productivity levels and introduced new KPIs like SIDs/HW ratio, Environments supported/FTE, Mean time between P1s , Zero Business downtime and ROI statistics.

Steered cultural change and improved SIDs/FTE ratio by 300% from 6SIDs/FTE to almost 20 SIDs/FTE.

Two Way Trust -Cross Forest Active Directory Deployment

Confidential 10

General HA-DR Architecture Design Principles

– Both Database and Application Tier have 100 % production capacity at both sites

– At the Site B site, hot standby capacity is installed for DR operations. Capacity is not used for anything during normal operations

– The application load is run on the servers at site A of the production database server

– The application servers at the DR site B run idle during normal operations. All dialog instances are installed and started, but don‘t carry any application load. Only if switching to DR mode, the application load will run on these servers

– Ideally, both sites will be indentical. Thus either site could run production permanently, and when failing over to the other site because of disaster or for maintenance reasons there will be no fail back.

HANA Database Server100 % Production Capacity

HANA DR Database Server100 % Production Capacity

Application Servers100 % Production Capacity

DR Application Servers100 % Production Capacity

Site A Site B

11

Pre Production Capacity

High Availability – DR Capabilities. Major Architectural Features.

Access via storageIP address

Storage Network

synch

mirrorsynch

mirror

Storage

Customer

Administration

Each server has independent

network interfaces for storage

network, administration network

and

customer network; there is no

routing among these interfaces

nor among the networks.

Corporate Network

Administration Network

CustomerFirewall

First Site Second Site

Admin NetFirewall

CustomerNetwork

Access tocustomernetwork(service IPaddresses)

Access toadministrationnetwork (serverIP addresses)A service IP address can exist only once in customer network

Each network transparentlyspans both sites

Metroclusters: Storage devices (filers) that span sites, each using a dedicated network connection to synchronously mirror data

(Encrypted access)

CustomerNetwork

High Availability Capabilities. Schematic Diagram – Normal Application

Operations.

Storage Network

NAS Filers

synch

mirrorsynch

mirror

Corporate Network

Administration Network

CustomerFirewall

First Site Second Site

Admin NetFirewall

Distance 10 - 20 km

CustomerNetwork

Service IP address in customer network mapped to service on a server at first site

Mirror not visibleto applicationswhenever primarystorage available.

(Encrypted access)

CustomerNetwork

DR Scenario Schematic Diagram – Normal Application Operations.

Storage Network

NAS Filers

synch

mirror NoMirror

Corporate Network

Administration Network

CustomerFirewall

First Site Second Site

Admin NetFirewall

CustomerNetwork

Service IP address in customer network stillmapped to service, but on a server at second site

(Encrypted access)

CustomerNetwork

Confidential 15

Operations orchestration & Cloud service automation

Confidential 16

Subscription based contract with 4 major parameters

SAP and / or HANA-as-a-service: Pricing Parameters

Number of Instances/ environments e.g. Prod, DR, Dev, QA, RTE, SBX…

RDBMS Database /Application Instances/VMs – in SAPS

HANA In-Memory Size of Instances in GB / TB

Persistent / External Storage per instance in GB / TB

Building & billing block sizes

BW on HANA or Business Suite on HANA Instance – At least 0.25 TB & multiples for Production. Monthly Billing is based either on installed capacity (i.e. subscription based model) or on actual peak consumption (i.e.

Total Resident Memory used for all HANA processes including code+ stack +OS+ working space) during the month for consumption based contract(s).

In-Memory per Instance for non-production– 64GB min. & multiples of 0.64 GB

Application Servers – 1000 SAPS and multiples

Additional Storage – At least 50GB and multiples of 50GB.

Economies of ScalePrice per SAPS goes down for higher contracted (baseline) capacity; as cost of underlying infrastructure, large servers and fixed charges work out cheaper than small servers & associated

SAPS ( SAP Application Performance Standard) is a hardware-independent unit of measurement that describes the performance of

a system configuration in the SAP environment. It is derived from the Sales and Distribution (SD) benchmark, where 100 SAPS is

defined as 2,000 fully business processed order line items per hour.

In technical terms, this throughput is achieved by processing 6,000 dialog steps (screen changes), 2,000 postings per hour in the

SD Benchmark, or 2,400 SAP transactions.

SAP HANA Volumes & Sizes under consideration

PROVIDER’s proposes deploying the following infrastructure based on CUSTOMER inputs and some assumed sizes

18

Environment Location Application Servers/VMs SAPS

HANA Capacity in TB assumed (to be verified before Go-Live)

Production (PR4) Primary DC 48000 8

Dual Purpose DR (PR4) Secondary DC 48000 8

Pre-production (TP4) Primary DC 2000 1

Quality Assurance (TQ4) Secondary DC 8000 1

Prod Dev (TD1) Runs on Dual Purpose in

Secondary DC4000 2

(runs on Dual Purpose DR)

o PROVIDER is proposing Dual Purpose DR for HANA Appliance where the DR HANA Appliance will run/ host couple of Non-prodenvironments thereby saving CUSTOMER additional costs for such HANA HW needed to host Non-production environments

o For Non-Production HANA instances, PROVIDER is proposing MCOS (Multiple Components on One Systems) where singleappliance (Dual Purpose DR) will host Pre-prod & Quality.

o Incase CUSTOMER opts for Dedicated DR, then CUSTOMER will need to order more Non-Production Capacity asPROVIDER won’t be in a position to accommodate Non-Prod on DR HANA HW.

o PROVIDER is proposing 2 separate 100% Application Servers/VMs for Production and DR to ensure 100% DR capacity on bothfronts i.e. Application Servers and HANA Appliances.

o However CUSTOMER can opt for cluster of Application Servers of 50%-50% spread across Production and DR sites. But inthis case, if there is DR, CUSTOMER will only be able to utilise 50% of the SAPS capacity.

PS: Temporary HW for Migration WorkBench, Oracle Clones will be provided for Initial Set-Up & Migration Phase.Considering the source DB size > 10TB,, PROVIDER proposes largest available SAP Migration WorkBench with 6CPUs & 32GB RAM

Unit Rates

Confidential 19

− Prices shown are for illustration only for fixed term of 36/60 months of operation after Go-Live.

− Prices are only valid for a period of 30 days of submission Prices shown do-not include any taxes.

− All taxes as applicable will be payable above these figures

− Actual Monthly Billing will be based on actual peak consumption (i.e. Total Resident Memory used for all

HANA processes including code+ stack +OS+ working space) during the month and the specified unit

rates In PROVIDER DC’s, both

− Capacity Ramp-Up & Capacity Ramp-Down are possible

Type of Unit Rate 0-12 13-24 25-36 37-48 49-60

Application Server / VM for Production with DR & ongoing operations + support – Monthly Charge /

1000 SAPS€ 89.00 € 87.00 € 85.00 € 78.00 € 78.00

Application Server / VM for Non – Production & Ongoing operations + Support – Monthly Charge /

1000 SAPS€ 67.00 € 66.00 € 65.00 € 60.00 € 60.00

Suite on HANA Capacity for Production + Dual Purpose DR & Ongoing operations + Support –

Monthly Charge per TB€ 3,800 € 3,600 € 3,500 € 2,900 € 2,700

Suite on HANA Capacity for Non – Production & Ongoing operations + Support – Monthly Charge

per TB€ 3,550 € 3,450 € 3,350 € 2,800 € 2,500

External Storage for Production + DR Application Servers / VMs – Monthly Charge per GB € 0.62 € 0.60 € 0.58 € 0.55 € 0.52

External Storage for Non - Production Application Servers / VMs – Monthly Charge per GB € 0.35 € 0.34 € 0.33 € 0.31 € 0.30

Base Fees for proposed 5 environments (S IDs) i.e. Production, DR, Pre-Production, Quality &

Development€ 8,500 € 7,500 € 6,500 € 5,000 € 4,900

Confidential 20

Financials

RUN costs 36 and 60 Months (8TB prod – 8 TB Non Prod)

Feature Comparison

PROVIDER’s CS900 Appliance Dedicated vs Pool

Dedicated Pool

Dedicated/

Bespoke vs Standard

Appliance is dedicated to the customer, all downtime

can be controlled. Built for CUSTOMER according to

unique requirements

System has shared, network, storage and backup

components. Subject to periodic limited downtime for

system-wide patching (customer agreed). Standard

building blocks and architecture.

Flexibility Can be scaled up by adding additional hardware.

Needs to be capacity managed.

Capacity is managed across whole customer base and

pool. Fast provisioning of incremental capacity and

scale-down of unused capacity

Commercial Commitment periods Lower commitment.

Evergreening Hardware has a life, new features and capabilities are

introduced and built at CUSTOMER ’s request

As additional features are developed, they can be

introduced. VPC is the initial development platform for

new functionality

Provisioning Time Within available capacity Capacity is available – within short agreed timescales

MCOD/MCOS/Virtualization on one SAP HANA Hardware Unit

Confidential 22

Productive Systems

“Classical” scenario

Appliance approach for

optimal performance

− 1 X Appliance

− 1 X HANA DB

− 1 X DB schema(e.g. ERP, CRM, BW)

“ABAP on HANA”

AS ABAP and

Database on one

hardware

− 1 X Appliance

− 1 X HANA DB

− 1 X DB schema

− 1 X Application Server

(AS ABAP 7.4)

− See SAP Note 1953429

Virtualized

Virtualization technology separates

multiple OS images each containing

one HANA DB

− n X Virtualized Appliances

− n X HANA DB

− n X DB schema

− N X Applications

− Sees SAP Note 1788665

Productive Systems

“MCOD”

Multiple Components on one

Database

− 1 X Appliance

− 1 X HANA DB

− n X DB schema

− n X Applications

− E.g. SAP ERP with SAP

Fraud Management See

Note 1661202 + 1826100

Non-Productive Systems

“MCOS” (aka multi-SID)

Multiple Components on one

System, multi-SID

− 1 X Appliance

− n X HANA DB

− n X DB schema

− n X Applications

− E.g. DEV and QA system on

one hardware See SAP Note

1681092

SAP HANA

AS ABAP SID: ABC

AS ABAP SID: XYZ

SAP HANA SAP HANA

<HDB1>Schema ABC

<HDB2>Schema XYZ

AS ABAP SID: ABC

AS ABAP SID: XYZ

SAP HANA

<HDB>Schema ABCSchema XYZ

AS ABAPSID: ABC

SAP HANA

<HDB1>Schema ABC

AS ABAPSID: ABC

<HDB1>Schema ABC

AS ABAP SID: ABC

AS ABAP SID: XYZ

SAP HANA SAP HANA

<HDB1>Schema ABC

<HDB2>Schema XYZ

PROVIDER’s Dual DC Based Automated DR

Confidential 23

Secondary site

DR SAP /

HANA Package

Synchronuous Replication

Q

Primary Site

Production

SAP / HANA

Package

sync SAP HANA System Replication

Less than 50 KM: sync

Dedicated DR: RTO<1hr

Quorum

Server

Acknowledgement

failover & takeover in case of failure

Dedicated DR allows ‘controlled fail-over’ for maintenance thereby reducing planned downtime

Disks Disks

Automated High availability/Disaster

Recovery system replication

− Uniform, cross-application HA/DR

technology

− Unattended secondary takeover

− Automated role reversal

− Client access handling

Simplified High availability/Disaster

Recovery configuration & administration

− Integrated with SAP startup

framework

− Non-intrusive design

− Regular configuration verification

− Context-driven instance restarts

− Onsite Back-Up for 30 days

− 6 Security Zones, BYOIP

− Anti-Virus, Encryption,

− Secure Access – 2 part

authentication

− Readily available spare-parts &

resident-engineers

− CUSTOMER ’s Monitoring

Tools/agents where possible

PROVIDER’s High Availability & Dual Propose DR Solution withTransport Paths

Confidential 24

QA HANA

DataVolumes

QA App Server

Pre-ProdHANA

DataVolumes

Pre-prod App Server

Dev App Server

DR App ServerSAP HANA Database Clients

Prod App Server

Primary DC Prod & Pre-prod Secondary DC Dual Purpose DR (Dev) & QA

As-a-Service from PROVIDER DCs: Typical Network Topology

Confidential 25

Dist . Layer VPN Instance

Leveraged VPC L3Core

Leveraged NIPS

Leveraged VPC Virtual

Firewall Context

Leveraged Dist. Layer

Leveraged Access Layer

Dist . Layer VPN Instance

Leveraged VPC L3Core

Leveraged NIPS

Leveraged VPC Virtual

Firewall Context

Leveraged Dist. Layer

Leveraged Access Layer

Customer Specific

Compartment

Stretched VLAN’s for specific customer

Customer Specific

Compartment

DWDM

PRIMARY DC SECONDARY DC

WAN router WAN router

Customer’s Global

MPLS / Other Network

TP

VPNVPN

END-USERS

Co-Vendor

SAP

Application Services

Provider(s)

VPN– Virtual private network

DWDM–Dense wavelength division

multiplexing

MPLS– Multiprotocol Label Switching

VLAN– Virtual local area network

VPC– Virtual Private Cloud

NIPS– Network intrusion protection system

WAN– Wide Area Network

Secure segregation of CUSTOMER’s

environments & traffic at Layer 2 &

Layer 3 leveraging

− VLANs

− NIPS

− Firewalls

PROVIDER’s

Responsibility

Governance

Confidential 27

CUSTOMER Business

Steerco Program

Management ()

Project Stream Move(INCUMBANT)

Project Stream Infra (PROVIDER)

Project Stream NZDT(SAP)

Project StreamTesting

()

Project Stream…..(….)

……Hardware Storage Network

Program Director

Tool Centric Approach for Migration and Operations

Confidential 28

− PROVIDER proposes using Guided Configuration &

SAP ACTIVATE.

− PROVIDER will aim to reduce the business outage

and migrate to Business Suite on HANA using NZDT

through 5 Test Migration Cycles

1. Mock-up test (Sandbox)

2. Unit, system testing and functional testing (DEV)

3. Integration, performance and User Acceptance

Testing (QA)

4. Load Verification (NZDT)

5. Dress Rehearsal for cutover (NZDT)

− 1 Cutover i.e. Production Migration and Go-Live

(during weekend)

− Pre-prod will be generated as system copy from

Production Copy as optional step

− PROVIDER endeavours to use/leverage existing SAP

native tools to keep Migration costs at bare minimum

Upgrade OS, DB & Data Migration

− After Go-Live, PROVIDER will use existing SAP

SOLMAN & Tools

− PROVIDER propose to use SAP’ ZDO for ongoing

maintenance (EPROVIDER upgrades)

PROVIDER will formalize a RACI matrix with Co- vendors

for quick resolution of incidents & problems

− PROVIDER will provide 24x7 support

− PROVIDER will be responsible for Capacity, Asset,

Configuration, Performance, Patch, Support-Packs,

OSS Notes

Ongoing Operations

PROVIDER will continue to provide

Consumption Report for billing, SAP Report*,

Performance Report*, Availability Report

Root Cause Analysis for Priority 1 incidents

Maintenance Schedule & Forward schedule of Changes

PROVIDER recommends

using SAP’s Business

Scenario Recommendation

Tool to firm up business use-

cases & processes.

Migration Approach: Plan A- Using SAP Native Tools & NZDT Customer + INCUMBANT + SAP + PROVIDER

Confidential 29

NZDT MethodolgyHigh level illustration - CUUC

Confidential 30

2a6

5a

Recording

1. Upgrade Preparation in PRD

2. Clone PRD system to Host B

2a. Remove all transactional data

3. Upgrade clone 1 system

4. Unicode conversion (export / import from host B to host C) – step not required for PL

5. Import customer transports on target (host C)

5a. Start recording

6. Initial load of all transactional data Using SNP T-Bone

7. Ramp Down (incl. user lock on production system)

8. Finish replaying transactions (Final Delta Replay – FDR)

9. System Copy & UC post-processing & infrastructure changes

10. Final business validation, sign off of new system, and GO decision

11. Ramp up new PRD system

Do

wn

tim

e

Migration Approach: Plan B– Third Party ToolCUSTOMER + INCUMBANT + PROVIDER

Estimated Downtimes during Migration

Confidential 31

Work package Plan A

Philips Lighting +

ATOS+HPE+SAP

(NZDT)

Plan B

Philips Lighting +

ATOS+HPE

Plan A

Philips Lighting +

ATOS+HPE+SAP

(NZDT)

Plan B

Philips Lighting +

ATOS+HPE

Ramp Down 5.0 5.0 3.0 3.0

Backup (Snap) 0.0 0.0 0.0 0.0

Restore (Intermediate sys) 0.0 0.0 0.0 0.0

Upgrade Downtime 0.0 0.0 0.0 0.0

Upgrade Post / UC prep 0.0 0.0 0.0 0.0

Export / Import 0.0 0.0 0.0 0.0

Migration post-processing 0.0 0.0 0.0 0.0

SUMG 0.0 0.0 0.0 0.0

SAP NZDT (FDR , XPRAS) 2.5 2.5 1.5 1.5

Reconciliation 1.5 1.5 1.0 1.0

Upgrade Post-reports (NZDT) 1.0 1.0 0.5 0.5

Transports (number ?) 3.0 3.0 1.0 1.0

System Switch 4.0 4.0 2.0 2.0

SUMG (NZDT case) 0.0 0.0 0.0 0.0

Testing (Basis) 2.0 2.0 1.0 1.0

Handover / others 1.0 1.0 1.0 1.0

Functional Validation 6.0 6.0 4.0 4.0

Go/NoGo 0.5 0.5 0.5 0.5

Ramp Up (incl. Backup) 2.0 2.0 1.0 1.0

Switch back to old environment 3.0 3.0 2.0 2.0

Summary in hours 31.5 31.5 18.5 18.5

Summary in days 1.3 1.3 0.8 0.8

Upgrade + Migration (worst case) Upgrade + Migration (best case)

Non-Production Reduced System Copies

Confidential 32

For landscape lifecycle management of these environments, PROVIDER proposes using CUSTOMER existing tools

Non-Production - SAP on Oracle environments

PROVIDER will use existing EPI-USE DSM (Data Sync Manager)

− Leverage existing BP templates for creating and refreshing consistent reduce

volume copies using DSM features like

− System Builder - for creating blank (no app date) non-prod system shell

− Client Sync – for creating fully functional thin (reduced ) SAP clients with

complete data integrity

− Object Sync – for copying specific functional data

− Data secure – for protecting sensitive data across non-prod envts using

masking

Non-Production - HANA environments

− Even for generating reduced volume Non-prod HANA environments, EPI-USE

states that System Builder - for creating blank (no app date) non-prod system

shell

− DSM application is embedded within the SAP application layer and

− is still agnostic to the database & OS platform that the system runs on.

− DSM is certified for use with HANA DB

− Customers are running DSM for HANA and it is going extremely well - the

tool works without any issues and the sophisticated slicing logic now runs

very quickly.

PROVIDER Aims to Minimise Maintenance Outage During RUN

Confidential 33

Planned Unplanned

ABAP

− Zero Downtime

Option (ZDO) of

Software Update

Manager*

− High Availability

(ABAP) Custer

HANA− Zero Downtime

Maintenance using

System Replication

− Host Auto- Failover

− System Replication

1

2

3

Reduce CUSTOMER overall SAP footprint by moving other SAP OLTP systems

at CUSTOMER to this particular Business Suite on HANA installation

− As the proposed Production system can be grown to 24TB

− PROVIDER can facilitate move to S/4 HANA and also stack all

− Future SAP centric OLTP (e.g. SAP SCM, APO, CRM HR etc.) or /and

− OLAP (BPC, BW, DSR) systems

− on this installation thereby reducing the costs drastically when compared to

putting additional/separate HANA Hardware for supporting new systems

PROVIDER’s Vision & Proposed Roadmap for CUSTOMER

Confidential 34

Repurposing of SAP Systems will allow CUSTOMER to activate and

suspend non-production environments that aren’t used/needed all year

round

− The same underlying hardware & infrastructure can be used to run a

learning environment, for example, for 40% of the time in a year (4 to 5

months) and the same hardware used to run Sandbox for 2-3 months

and other non-production environments for the rest of the year

Reduce the growth of date and overall Storage: PROVIDER has observed

that there is lot of historic data sitting in the online-storage mode within the

existing SAP Landscape at CUSTOMER . PROVIDER recommends deploying

a Big Data solution whereby CUSTOMER can offload

− The warm and cold data to NLS Sybase IQ centric archiving platform with

READ-ONLY access or

− Evaluate introducing Dynamic Tiering concept

− The warm and cold data to PROVIDER AppSystem for Apache Hadoop,

− Simply go for offsite Tape Library and as per Data Retention policy,

delete/purge historic/cold data from On-line systems year

Continuous

Optimization

Business Outcomes Service Mgmt

How On Demand Services for SAP Operate

Confidential 35

Central Monitors & Dashboards

Central Alerts & Actions Status System

Components

Business Processes

Operations Dashboard

Operations Control

Center (OCC)

− System Monitoring & Alerting

− Platform Monitoring & Alerting

(i.e. ECC, PI, BW)

− RCA & Exception Management

− Data Volume Management

− Software Update Management

− Downtime Optimization (with

SUM and nZDM/ZDO)

− Reporting & Dashboards (OCC)

Te

ch

nic

al O

pe

rati

on

s

− E2E Business Process

Monitoring

− E2E BP Operations Dashboard

− Business Process Analytics

− Monitoring of Job Health &

Impact on Business Processes

− Data Consistency in Interfaces

Bu

sin

es

s P

roc

es

s

Op

era

tio

ns

Problem Identification

(From re-active to proactive RCA)

Problem Evaluation

IT4IT OperationsIncident Management Problem Management Knowledge Management

Ch

an

ge M

gm

tR

ele

as

e* &

Dep

loym

en

t Mg

mt

Approved RfC

Request

for

Change

Bu

ild &

Te

st

Monitoring & Alert InfrastructureEvent to Alert Correlation,

Thresholds & Broadcasting

Incident Generation

Service Responsiveness

Alw

ays O

n

Qu

ality

& T

ran

sp

are

ncy

Upgrade Automation

–Description

• Supports the planning, realization and control of

SAP Upgrades (SaaS)

• Simulates Upgrade Impacts on Custom Code,

Modifications, Roles & Authorizations

• Each Impact is referenced as a „task“ in the Portal

with a detailed description of the necessary

corrections

• Identifies cloned programs (inofficial modifications)

via line-by-line code comparison

• Based on assessed Impacts due to Upgrade,

provides a Unit Test Plan -> Risk based Testing

• Analysis is performed in defined intervalls during

project with associated status tracking

Planning Dashboard

Benefit•Focus on necessary corrections (no trial / error ->

less test effort)

•Focus on used objects only (via SAP Workload

Monitor) -> Reduction of Scope

•Efficient risk based testing based on identified

impacts due to upgrade

•Automatic code corrections for a magnitude of

errors detected

Testing Automation

• Key Functionalities

• Automated Test Documentation: Tests can be recorded by the push of a button in the SAP R/3 System and will be automatically documented including Steps, Results with associated test data used and screenshots.

• Automated Test Execution: These tests can already be recorded on the current SAP environment for execution on the upgraded SAP 6.0 System ensuring that the test preparation can start already prior to having an upgraded system available. The tests recorded can be executed automatically – fully automatically, step by step or transaction by transaction.

• Real-time integration to HP Quality Center and SAP Solution Manager

Customer challenges

Test Data Management

ComplianceBe compliant with data protection lawsand secure personal and customer data

High FlexibilityExtract data based on business objects,

time slice, or a combination and reduce

test data in a flexible way to cut costs forstorage and hardware

Reduce ComplexityBuild up new project- and training systems

fast and flexible or reduce manual work

for pre- and post-processing of systemcopies

Automate RefreshsRegular refresh of quality-, training- and

development systems with productive

data

to ensure testability for all business cases

Refresh of Quality and Development Clients

Test Data Management

Requirements• Provide QA and DEV systems with the most

production-oriented data for defined test scenarios

• Minimize system outage and post processing work

and ongoing development activities don‘t have to

disturb

• Save disk space and hardware resources through flexible data reduction

Refresh Procedure• Master- and transactional data is deleted from receiver

• Customizing, users and authorizations and other system

settings (e.g. ALE) are preserved

• Data selection is performed: Full client, only master data, with reduced transactional data or business object base

Why Data Provisioning and

Masking?• Downtime of non productive systems is

reduced

• Manual post processing work is minimized

and highly automated

• Transport requests must not be released

and re-imported during refresh procedure

• Data masking rules can be applied during transfer

Data Masking after System Copy

Test Data Management

Requirements• System copy / cloning should be used to refresh non

productive system

• Sensitive data must be masked / deleted after the

copy and consistency must be preserved• Safe disk space by deleting unnecessary data

Refresh Procedure• Define masking rules in SNP DPM

• Execute system copy (e.g. with UC4, R3load or

cloning technology)

• Export and mask sensible table data

• Delete sensible and unnecessary data

• Re-import masked data

Why Data Provisioning and Masking?• Masking rules are defined on a central

server and can be re-used across systems

and copy scenarios

• Simple rules can be applied and configured

via customizing – no development required

• Example masking rules for customers,

vendors and business partners are delivered

and can be extended

• Masking routines ensure consistency of

redundant data within the masked system and across system landscapes