BestPractices_SoftwareChangeMgmt

Software Change Management Elements of a Software Change Management Strategy

SAP AGS - IT Planning

May 2013

Elements of a Software Change Management

Strategy

Introduction

© 2012 SAP AG. All rights reserved. 3

Introduction Software Change Management is a key operations process

Software Change Management is a key operations process

Enterprise change is continuous: Go to market strategies, regulatory compliance,

manufacturing innovations and technology upgrades are a few of the drivers that are fueling

continual change.

Enterprises need to be prepared for continual change

to remain competitive and compliant

– in a consistent cyclic and re-occurring manner.

Software Change Management is a key operations

process for an SAP system.

A good Software Change Management strategy includes

– the definition of procedures and responsibilities,

– and the choice of supporting tools and transport landscape.

When implemented correctly,

Software Change Management will

– mitigate the risks to production

– whilst enabling innovation to support the needs of the business.


Requirements

Management

Transport Management

Test Management

Release Management

Change Request Management

Requirements

• Input Channels

• Prioritization

• Classification

Design

• Blueprint

• Level of Effort Estimate

• Release Assignment

Build

• Resource Assignment

• Develop

• Unit Test

Test

• Integration Test

• Regression Test

• Performance T.

• Cutover Test

• User Acceptance Test

Deploy

• Dress Rehearsal

• Go-Live

Operate

• Monitor

• Support

• Continuous Improvement

Introduction Holistic View on Elements of a Software Change Management Strategy

Elements of Software Change Management Strategy


Introduction IT objectives for Software Change Management

IT objectives for Software Change Management

Typical IT objectives for Software Change Management are:

– Quality of service – Minimizing failure of changes, service degradation, and unplanned outages

– Speed of deployment – Reducing the time to implement support for a new business requirement or a fix into

production systems

– Reasonable IT cost – Minimizing IT cost without compromising quality of service

– Keeping technology up-to-date – Ensuring that infrastructure and software are up-to-date enough to enable

innovation and guarantee support from the vendors

The importance of the different objectives is different

– from customer to customer

– from solution to solution within a customer,

based on the individual requirements (criticality of the system), and the amount of changes

expected for the solution (new vs. mature solution, small vs. large customer, etc.).

So there is no “one size fits all” for Software Change Management processes and supporting

tools and transport landscape.


Strategy

Release Management


Release Management Motivation

Concept of Release Management: Bundling of Changes


Release Management Motivation

Motivation: Why should changes be bundled into releases?

A release is the collection of software, processes and documentation which is required to

implement one or multiple approved changes. Such a release is then treated as single piece

when it comes to testing and deployment.

A release may contain one or many projects.

– In a release with multiple projects, all projects must align

when the Release enters or exits a quality gate or

major milestone.

Benefits of managing changes in releases:

– Clear promise to the business of what goes live when.

– Increased stability of production because frequency of

changes to production is reduced and solid testing for the

releases done

– Lower cost (people and systems) and

more simplified testing process using common regression and integration testing for several projects /

changes in one run

– Reduced risk of inconsistencies for example due to "forgotten transports" or sequence violations

– Reduced administration efforts for transport management as all projects move from one phase to

another at a single point in time


Release Management Release Categories

Release Categories differ in test effort/duration and therefore in scope/level of

changes that can be included in such a release

Major

Release

Minor

Rel.

Minor

Rel.

Emergency Changes

Standard Changes

Go Live

Cycle

Change Request

Categories

included

Change

Request

Priorities

included

Test Strategy Examples

Every

3 - 6 months

All types of

changes

including invasive

changes

Normal

Priority Complete test scope

New (major) functions,

Support /

Enhancement

Packages,

Upgrades

Every

1 - 4 weeks

Non-invasive

changes

(+ Re-Import of

Emergency

Changes)

Normal

Priority

New features +

Regressions for core

processes

(automated tests)

Non-critical

configuration, medium

or low priority incidents

Every

1 – 7 days

Standard changes

only (non invasive ,

low risk and impact

well known)

Normal

Priority

Test identified in pre-

approval.


processes

(automated tests)

Already approved

changes e.g. storage

locations, currency

exchange rates

On Request

only Emergency only

Emergency

only


processes

(automated tests)

Any changes to solve

high priority incidents


Release Management Release Categories

The test strategies (scope, effort and duration) are different per release

category according to the level of changes.

Major

Release

Minor

Rel.

Minor

Rel.

Emergency Changes

Standard Changes

Unit

Test

Scenario

Integration

Test

User

Acceptance

Test

Regression

Tests

Performance

/ Load

Tests

Additional

Tests

(System, Cut-

over Tests)

Yes,

including code

inspector and

peer reviews

Yes

(important)

Yes

(usually

required for

sign off)

Yes (complete

regression

test)

Recommende

d (e.g. based

on outcome of

single activity

trace)

Potentially

(depending on

request)

Yes

(code

inspection and

peer reviews if

possible)

Yes

Yes

(per

correction/

change)

Recommende

d at least for

core

processes

No Usually no

Yes

(According to

standard

change

process)

No No No No No


Release Management Release Calendar (agreed with the Business)

Release Calendar

After the release categories are defined, the releases are put into a central release calendar.

Best Practice is to align the release go live dates across all SAP applications within an

environment (e.g. SAP ERP and SAP APO within a region).

The release calendar needs to be aligned with the business on freeze periods, downtime

scheduling and frequency of shipment of changes.

The release calendar should also include cut-of days, CAB meetings and testing periods.

Mo

nth

Calendar Year

Business requested system freeze

Minor

Jan Feb Mar Apr May June July Aug Oct Nov Dec

Major

Sept

Minor Minor Minor Minor Minor Minor Minor Minor

Major

Business agreed planned downtimes


Release Management Link of Change Request Management to Release Management

Change Requests

1) Break Fixes

2) New

requirements

3) Standard

changes

4) Business

enhancements

……..

……..

……..

Project

features

1)……

2) ….

3) …..

……..

x)…..

Requirements

Project

features

1)……

2) ….

3) …..

……..

x)…..

Non-business-driven

Requirements

1) OS/DB Patches

2) DB Reorg

3) …..

Requirements

Review

Central categorization and prioritization of requirements

Allocation of all change requests (and projects) to release categories based

on change categories and prioritization and other well-defined criteria

Alignment to a specific releases and Go-Live dates for a change/project

Major

Release

Minor

Rel.

Minor

Rel.

Emergency Changes

Standard Changes

Release Categories


Strategy

Transport Landscapes


Transport Landscapes Overview of Transport Landscapes

Overview of Transport Landscapes

Find below typical transport landscapes used by SAP customers. A lot of variations of the

shown landscapes exist and could be suitable – based on the company’s requirements.

In large enterprises, the 3-system landscape is generally not suitable given the expected

high amount of changes that needs to be processed.

Supports enterprises during initial implementation

and also production support where change volume is

low.

3-System

Landscape

To reduce risk and increase flexibility, an additional

testing instance is added.

PRE is a pristine testing environment where release

changes can be imported and tested in isolation.

4-System

Landscape

To further mitigate risk, a second development track

can be introduced to separate production support

from project development. Production in PSD,

projects in DEV track.

5-System

Landscape

Similar to the 4-tier landscape, an additional testing

instance can be added to the project landscape (and

potentially for the production support track) to isolate

release changes and improve testing capabilities.

6-System

Landscape

DEV QAS PRD

DEV QAS PRD PRE

PSD PSQ PRD

DEV QAS

DEV QAS PRE

PSD PSQ PRD


Single track 3-System Transport Landscape

Concept:

– All changes are created and unit tested in DEV.

– All major tests are done in QAS before transports are imported into PRD.

– Sandbox System can be added (temporarily) and used for prototyping of new functionality or initial testing

of disruptive changes such as maintenance. There should be no transport path between SBX and DEV.

This landscape has lowest costs, but quality risks in case of high project activity/scope

– Overlapping projects with different release dates may be tested in parallel in QAS.

Testing environment does not represent PRD. Risk that change works in QAS, but not in PRD.

The 3-tier landscape is best suited to those customers that have entered a mature production

support state, and need only to update production periodically with minor enhancements and

corrections.

This scenario is not suited for testing multiple long running development projects as the ability

to isolate and test in a pristine environment is restricted to QAS where developments with

such a requirement would be in varying stages.

Transport Landscapes Single track 3-System Transport Landscape


Single Track 4-System Transport Landscape

Concept:

– All changes are managed in a single development system, incl. production support and project

development.

– All changes can be transported to QAS for integration testing. This system partially contains the changes

from the new release that currently is in development.

– PRE (=pre-production) provides a pristine environment where the next release can be isolated and tested.

That means that only changes released for the next release go to PRE – “staged testing”. Release and

regression testing is done in PRE

This landscape is best practice for solutions with production support and development projects

of a medium scope.

There are a number of very large customers who manage all changes – even larger projects –

through this environment. Pre-requisites are a very mature organization and very mature

software change management processes.

– Some of these customers even execute SAP maintenance events in this landscape, whereas others use a

temporary dual track landscape consisting of a project DEV and QAS for maintenance events.

Transport Landscapes Single Track 4-System Transport Landscape (1/2)


Single Track 4-System Transport Landscape – Illustration of Staged Testing

Example of Staged Testing:

– 4 parallel projects in DEV, with only RED project going live with the next business release

Steps:

1. In DEV there are 4 separate independent projects.

2. At various stages 3 of the 4 projects are transported to QAS to start various testing scenarios.

3. Prior to the net release window PRD should be copied into PRE.

4. You then transport the RED project into PRE, conduct the necessary final regression and user acceptance

testing. Any potential dependencies / handshaking defects the RED project may have with any of the other

developments can only assuredly be detected during qualified and isolated testing in PRE.

5. After successful testing in PRE, you can transport the RED project to production.

Transport Landscapes Single Track 4-System Transport Landscape (2/2)

1

2

3

4 5

Soft Freeze for

Regression testing


Dual Track Transport Landscape – Overview

Concept:

– One set for production support and smaller projects: PSD, PSQ, PSP (optional)

– One set for major project development: DEV, QAS, PRE (required if multiple projects with different release dates)

– Changes in PSD are retrofitted to DEV periodically (ideally using Solution Manager ChaRM)

– Ideally the transport landscape is the same for all systems in an SAP solution. In case of a temporary project development

track for individual systems only, concept for early integration test needs to be worked out.

– More than one project development track is generally not recommended.

This landscape is a good option in case of large projects as it allows for segregation of production support

and development tasks and its personnel, thus for safe and fast production support at all times.

However, this landscape is not a must-have in case of large developments for a landscape. In the end it

becomes a costs/benefits discussion, as the additional costs are quite high with multiple applications. For

some customers it may only be suited as a temporary landscape for maintenance, if at all.

– Benefits: A dual track transport landscape can help mitigate risks for production from project development, e.g. if the

solution is still in full roll-out mode, there are different organizations with different skills involved, a lot of invasive transports

are expected or there is high risk sensitivity in the company or for the particular solution.

Transport Landscapes Dual Track Transport Landscape (1/3)

Production Support

Project Development

Retr

ofit



Production Support

Project Development

Retr

ofit

Refresh

from PRD

Regression testing w/o impact on production support

Dual Track Transport Landscape with 6 systems – Illustration of Staged Testing

Example of Staged Testing:

– 4 parallel projects in DEV, with only RED project going live with the next business release

Steps:

1. In DEV there are 4 separate independent projects, plus potentially a project in early phases in SBX.

2. At various stages 3 of the 4 projects are transported to QAS to start various testing scenarios.

3. Prior to the net release window PRD should be copied into PRE.

4. You then transport the RED project into PRE, conduct the necessary final regression and user acceptance

testing. Any potential dependencies / handshaking defects the RED project may have with any of the other

developments can only assuredly be detected during qualified and isolated testing in PRE.

5. After successful testing in PRE, you can cut-over the RED project to production.


Cut-Over Options PRO CON

1. Option:

PRE PSD (or QAS PSD if PRE does not exist)

Single source of developments for production, i.e.

all changes (project and correction) arrive in PRD

systems from PSD system.

Opportunity to build new transport packages in PSD

system in order to improve import runtime, e.g. re-

packaging original transports and by that achieve

that an object is only transported once.

This option is the standard configuration in SAP

Solution Manager ChaRM.

PSD system not available for production support

during time of re-packaging and testing of the

project developments in Pre-Prod systems.

In case of “Virtual Single Instance” (multiple PRD

with single PSD/DEV): very limited possibility to

deploy new projects to different PRDs at different

points in time, as production support for remaining

PRD systems may not be possible in PSD

anymore.

2. Option:

PRE PRD (or QAS PRD if PRE does not exist)

End-to-end support for development and production

support during project test and cut-over

Potentially more hardware required to run

regression tests in project and production support

environment (both PSQ and QAS have to meet test

data requirements)

3. Option: Track Switch

(using DEVQASPRE after project go

live for production support and build new

DEV2QAS2PRE2 for project

development, e.g. reusing

PSD/PSQ/PSP)

Easier go live from a single project perspective All open developments and change history in PSD

are lost after go live.

Challenges in Solution Manager if system role

changes.

Challenges in test systems if only certain

applications switch tracks (integration, data with

LOGSYS in key).


Options for Project Cut-Over in case of a permanent Dual Track Landscape

Generally not recommended


The Pre-Production System

• The pre-production system (PRE respective PSP on the previous slides) is the environment

the regression test, technical system tests of infrastructure changes and final integration

tests.

• The pre-production systems should represent the status in the production systems with

respect to technical architecture (e.g. HA setup), data and transport. In particular, it means

that the pre-production systems must not be “corrupted” with new functionality or new

maintenance packages until the appropriate time (ideally as close to go-live as possible). It

also means that the pre-production system should be regularly refreshed from production, if

possible.

• However, the pre-production system does not have to have the same size as the production

system. Primarily the set-up should be similar, i.e. multiple dialog instances.

• The quality assurance system (QAS respective PSQ on the previous slides) is used as a

testing environment for integration tests and unit tests. This system partially contains the

changes from the new release that currently is in development. Therefore regression tests in

the quality assurance system, e.g. for emergency changes, may not detect issues or detect

“false positives”.

Transport Landscapes System Role of the Pre-Production System


Transport Landscapes Suggested Sizes of the Systems in the Transport Landscape

Suggested Sizes of the Systems

Explanation of T-Shirt Sizes in table above:

High Availability

solution in place

CPU and RAM Size –

compared to PRD

DataVolume –

compared to PRD

S no small Small

M yes medium 100% of PRD

L yes 100% of PRD 100% of PRD

S M L

3-system

landscape

DEV QAS PRD

4-system

landscape

DEV, QAS PRE PRD

5-system

landscape

PSD, PSQ,

DEV

QAS

PRD

6-system

landscape

PSD, PSQ,

DEV, QAS

PRE

PRD

(PRE)

DEV QAS PRD

DEV QAS PRD PRE

PSD PSQ PRD

DEV QAS

DEV QAS PRE

PSD PSQ PRD


Strategy

Transport Landscapes for

Template Management


Transport Landscapes for Template Management Landscape Strategies to achieve Process Harmonization

Level of process harmonization depends on the Non-production Systems

1. Virtual Single Instance

Single DEV PRD 1

PRD 2

2. Template + Multiple Dev. Systems

Common DEV PRD1

PRD 2

L-DEV 1

L-DEV2

3. Multiple Dev. Systems

PRD 1

PRD 2

DEV 1

DEV 2

Harmonization across systems – same

as with single instance

All localization in central system

Harmonization across systems for

common processes

Localization in the multiple systems

Very complex model in practice

Autonomy of the systems

Harmonization across systems by

information sharing (“paper-based”)

0. Single Instance

Single DEV PRD

Harmonization across all tenants

All localization in central system


Best Practice Options for Template Dev. with multiple Production Systems

(1) Virtual Single Instance

all PRD systems share the same code and configuration

(2) Template DEV + localization DEV systems

PRD systems differ in terms of localization code/configuration

(3) Central DEV system with separate clients per PRD system

PRD systems share the same code, but differ in terms of localization configuration

Transport Landscapes for Template Management Overview of Landscapes

QAS

QAS

QAS

Client 001: Common

Client 010: PRD1

Client 020: PRD2

Client 010

Client 020


Transport Landscapes for Template Management General Pre-Requisites for having a common DEV (1/2)

Minimum technical Pre-Requisites for the Production Systems

If a DEV system is shared for multiple production systems (with or without additional DEV

systems for localizations), certain pre-requisites for the production systems have to be met:

– Same release, enhancement package, support package, country versions and legal packages

– Unicode compliance of all systems

– Same enterprise extensions and business functions activated – has business impact

Temporarily, e.g. in case of an upgrade, the systems can deviate.

If the system requirements cannot be met (e.g. flexibility on release levels needed by

production system), separate DEV systems on regional level are needed.

The production systems can have different OS/DB than DEV, but with operational

complexities.

– For safe software change management, it is important that similar hardware and same OS/DB as in the

production system are used in the corresponding pre-production systems.

– And in case of different DB platforms, performance tests per DB platform are recommended. To support

such activities the pre-production system should be set up like the respective productive system.

– In operations with different platforms, there are differences, e.g. you cannot just reuse tools, procedures

and configuration settings between platforms. And there are differences when it comes to maintenance

tasks, e.g. SAP kernel patching, OS patching, VMware patching etc. This drives complexity in operations.

– If the DB platform is different on central DEV and test systems than in production, you cannot just use

backup restores from production for test system refreshes, but have to use export/imports instead.


Transport Landscapes for Template Management General Pre-Requisites for having a common DEV (2/2)

Other Pre-Requisites

If a DEV system is shared for multiple production systems (with or without additional DEV

systems for localizations), certain other pre-requisites for the production systems have to be

met:

– Common landscape track usages – retrofit / track switching

– Single release strategy and release calendar

– Global solution manager for change request management by ChaRM

– Strategy for transport landscape and processes for related applications/systems (e.g. SAP APO)


Transport Landscapes for Template Management Option (1): Virtual Single Instance

Option (1): Virtual Single Instance

Explanation:

Single development system, independent of the number of production systems.

All localizations done in central development system, always hitting all production systems at

more or less the same time.

Result: all production systems share the same code and configuration

Project landscape can be added.

Considerations:

Single development system is easiest way to achieve harmonized processes.

– One development system easier to control

– Risk minimized for getting out-of-sync

– Psychological effects of a single system

In case a strong template is desired: strong governance is needed nevertheless to protect the

global processes. Otherwise proliferation of process variants can happen in this option.

QAS


Transport Landscapes for Template Management Option (1): Virtual Single Instance – Software Change Flexibility

Software Change Management Flexibility in Virtual Single Instance

Main principle: Production systems should be kept in sync as there is only a single

development system for support.

For speed for changes and downtime planning this model allows for more flexibility in

comparison to a single production system, but the flexibility is limited in the following sense:

– Single changes (in particular “emergency” transports) can be transported to a single PRD system first, but

should be regression tested and imported to all production systems with the next minor release (e.g.

weekly).

– Medium/major business releases should be imported to all production systems within a few days, ideally

within a weekend..

– Upgrades (or other major changes for which a project landscape is needed) can be done – if required – at

different consecutive weekends using the project landscape or the QAS-PRE landscape temporarily for

production support (of course with the respective limited support and extra retrofit effort).


Transport Landscapes for Template Management Option (2): Common + Localization DEV Systems (1/2)

Option (2): Template DEV + localization DEV systems

Explanation:

All common processes are developed as a template in the central development system and protected

against changes in the localization L-DEV systems (e.g. using BC-sets and authorization on development

classes)

All localizations done in L-DEV systems, only hitting the respective productive system.

Result: PRD systems share the same code and common configuration, but differ in terms of localization

configuration.

Project landscape can be added

Considerations:

Tools support the protection of the template (e.g. BC-Sets, authorization concepts), nevertheless quite

sophisticated governance process needed to avoid “too much localization”. Ideally only one development

team for common and local objects to avoid too much autonomy in the L-DEV systems.

Quite complex transport patch and – in case of dual track – very complex retrofit process.

Advantage that independent project schedules and downtimes per production system possible.

Advantage that only selective configuration hits the production system.

QAS


Transport Landscapes for Template Management Option (2): Common + Localization DEV Systems (2/2)

Keeping the Balance: Flexibility vs. Effort/Risk

The landscape can be used in very different ways and for different template cases, e.g. 95%

template or partial 20% template.

This landscape has built-in flexibility for change on the regional level, e.g. in case a correction

is urgently needed in one of the PRDs, this could be done in the respective L-DEV.

However this can partially also be achieved with a single DEV (e.g. cherry-picking of

transports).

And all flexibility on the L-DEVs comes with additional effort/costs and risks of inconsistencies:

– “Short-cuts” by implementing things first in one of the L-DEVs can lead to long-term inconsistencies. A solid

process of how to retrofit those changes back in DEV is required.

– The more flexibility on the regional level is allowed, the more complex is the overall process (governance of

the template, potential conflicts with the template / adoption of the template).

– If flexibility for upgrades is needed per track, the template DEV has to be maintained in multiple version.

So generally, companies who want a strong template do all major developments and all

corrections relevant for all PRDs only in DEV.

QAS


Option (3): Central DEV system with separate clients per PRD system

Explanation:

There is only one DEV system, but different clients are used for configuration for each PRD system.

Code and client-independent configuration is developed in client 001 and transported to all PRD systems.

Common client-dependent configuration is developed as a template in client 001 and copied to clients 010

and 020 in DEV where the localization happens. Configuration is then transported to the respective PRD

system (e.g. DEV client 010 to PRD 1 client 10).

Of course, each PRD system only has a single client.

Result: PRD systems share the same code and common configuration, but differ in terms of localization

configuration.

Implications and risks for operations:

Transport execution is significantly more complex.

Risk of inconsistencies for developments (configuration and code have to arrive at the same time.)

Not having identical PRDs can lead to issues, in particular for “cherry-picked” transports, e.g. unexpected

failure situations because of dependencies to/from cross-client customizing and coding possible.

Problem solving is more difficult (they first need to understand the differences in a given system).

Transport Landscapes for Template Management Option (3): Global DEV system with separate clients

QAS

Client 001: Common

Client 010: PRD1

Client 020: PRD2

Client 010

Client 020


Strategy

SAP MaxAttention

IT Planning Offering


SAP MaxAttention IT Planning “Strategic” services for Software Change Management

SAP MaxAttention IT Planning: Topics

SAP Production System Strategy, i.e. number, size and location of production systems

SAP Software Change Management

SAP Technical Architecture, i.e. type of hardware, number of application server per system,

HA/DR concept, virtualization concept, etc.

Example: SAP Software Change Management

Onsite Review of software change management processes at the customer

Comparison to Best Practices

Identification of improvement points

Result: Report with concrete recommendations for software change management

improvement points


SAP MaxAttention IT Planning Motivation (1/2)

Motivation

Customer has the requirement to rollout new functionality for the foreseeable future, in

release waves, during which time the customer will also need to able to:

– Stabilize and isolate production from on-going development and maintenance risks

– Provide an environment which has the ability to handle multiple major projects in parallel, inclusive of

maintenance, and provides software change management governance

– Is capable of supporting business as usual requirements, such as, providing production with emergency

corrections, standard changes and minor enhancements

Typical situations at SAP customers:

– Release Management processes, to manage complex requirements, are not in place.

– Project Management not optimized

o Projects are often treated as a release, and as such individual projects drive the landscape. This

leads to a landscape optimization/consolidation effort

o Project conflicts often lead to the deployment of a second development instance, separating the

projects, causing significant integration effort later

– Change Management / Transport Management and its governance not defined, causing errors in

production

o Transports in environments where they do not belong, at this point in time


SAP MaxAttention IT Planning Motivation (2/2)

Motivation

Most of these situations drive the customer questions:

– Are my software change management processes optimized?

– What are the software change management Best Practices?

– How to follow a fixed release calendar and still provide flexibility to the business units?

– How to manage multiple projects in parallel?

o How to manage object conflicts?

– How to govern change, their transports, and adequately test the change?

– Is the landscape optimized?

o What are the landscape best practices?

o How are other customers managing their software change management requirements and their

landscapes?


SAP MaxAttention IT Planning Overview of IT Planning Software Change Management Strategy Service

At a Glance: IT Planning Software Change Management Strategy Service

The IT Planning Software Change Management Strategy service …

– is a service exclusively delivered for SAP MaxAttention customers.

– helps customers to

o understand the benefits of proper software change management in general,

o understand how release management can ensure the quality of production software,

o understand how multiple projects can be developed, tested and deployed in parallel,

o ensure the fundamental change categories and prioritization are in place,

o evaluate transport landscape options and its usage to ensure it can manage the software change

management requirements.

– minimizes future risks and reduces costs of the future SAP landscape – for a relatively low investment

The IT Planning team has experience with software change management and its transport

landscape requirements – from jointly working with SAP MaxAttention customers around the

world.


SAP MaxAttention IT Planning Details for the IT Planning Software Change Management Strategy Service

Approach of the IT Planning Software Change Management Strategy Service

Onsite Workshop (typically 2-3 days):

– Understand the customer’s Software Change Management situation

o What is the customer situation (change volume, types of changes, time for realization of

enhancements, downtime requirements, ….)?

o What is the situation today? What are important boundary conditions?

o What will change in the future? What are new requirements

– Review of the overall Software Change Management concept.

o Does it effectively support the requirements of the customer?

o Is it in line with best practices?

– Review of the transport landscape

o What is the concept behind the current transport landscape? How did it evolve, what were driving

factors?

o Does it support the processes effectively?

o Is it in line with best practices?

o How does it compare to the landscapes used by other companies?

Remote creation of Final Report:

– Documentation of the findings and recommendations for improvement from the workshop

Result: Final Report (ppt-format) – delivered typically one week after the workshop

Thank You!

IT Planning

SAP Active Global Support

Date post:	13-Dec-2015
Category:	Documents
Upload:	abhbook
View:	213 times
Download:	0 times

BestPractices_SoftwareChangeMgmt

Documents