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.
Month
Calendar Year
Business requested system freeze
Minor
Jan Feb Mar Apr May June July Aug Oct Nov Dec
Major
Sept
Minor MinorMinor 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

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 PRDPRE
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.
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.
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.
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.
Dual Track Transport Landscape (1/3)
Production Support
Project Development
Retrofit

Production Support
Project Development
Retrofit
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 DEVQASPRE after project go
live for production support and build new
DEV2QAS2PRE2 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”.
System Role of the Pre-Production System

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 PRDPRE
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
Overview of Landscapes
QAS
QAS
QAS
Client 001: Common
Client 010: PRD1
Client 020: PRD2
Client 010
Client 020

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.

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)

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

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

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

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

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

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?

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.

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

BestPractices_SoftwareChangeMgmt

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to BestPractices_SoftwareChangeMgmt

Similar to BestPractices_SoftwareChangeMgmt (20)

BestPractices_SoftwareChangeMgmt