SAP Standard for E2E Solution Operations
Document Version: 1.0 – 2014-12-12
CUSTOMER
SAP Standard for Change Control Management
SAP Solution Manager 7.1
Typographic Conventions
Type Style
Description
Example
Words or characters quoted from the screen. These include field names, screen titles,
pushbuttons labels, menu names, menu paths, and menu options.
Textual cross-references to other documents.
Example
Emphasized words or expressions.
EXAMPLE
Technical names of system objects. These include report names, program names,
transaction codes, table names, and key concepts of a programming language when they
are surrounded by body text, for example, SELECT and INCLUDE.
Example
Output on the screen. This includes file and directory names and their paths, messages,
names of variables and parameters, source text, and names of installation, upgrade and
database tools.
Example
Exact user entry. These are words or characters that you enter in the system exactly as they
appear in the documentation.
<Example>
Variable user entry. Angle brackets indicate that you replace these words and characters
with appropriate entries to make entries in the system.
EXAMPLE
Keys on the keyboard, for example, F 2 or E N T E R .
2
PAGE \*
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
SAP Standard for Change Control Management
Typographic Conventions
Document History
Version
Date
Change
1.0
2014-12-12
First version created
SAP Standard for Change Control Management
Document History
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
3
Table of Contents
1
1.1
SAP Standards for E2E Solution Operations .............................................................................................. 5
Control Center Approach ........................................................................................................................................ 6
2
2.1
Overview of the SAP Standard for Change Control Management ........................................................... 9
Change Request Management ............................................................................................................................... 9
2.1.1
Types of Change..................................................................................................................................... 11
2.1.2
Release and Deployment Management .............................................................................................. 12
2.1.3
Defining a Release Strategy ................................................................................................................. 12
Basic Architecture ................................................................................................................................................. 14
2.2.1
Tools for Managing Changes ............................................................................................................... 14
2.2.2
Tools for Increasing Business Flexibility ............................................................................................. 16
Integration with Application Lifecycle Management .......................................................................................... 17
2.2
2.3
3
3.1
3.2
3.3
3.4
Lifecycle of Change Control Management............................................................................................... 20
Plan .........................................................................................................................................................................20
3.1.1
Project-Related Aspects.......................................................................................................................20
3.1.2
Organizational Aspects ........................................................................................................................ 21
3.1.3
Technical Aspects ................................................................................................................................. 21
3.1.4
Change Control Management Processes ........................................................................................... 23
Build ........................................................................................................................................................................ 24
3.2.1
Solution Manager Landscape .............................................................................................................. 24
3.2.2
Functional Implementation .................................................................................................................. 29
3.2.3
Authorization Concept ......................................................................................................................... 32
3.2.4
Testing, Bug Fixing, and Retesting ...................................................................................................... 32
3.2.5
Developing Templates in Complex System Environments ............................................................... 33
Run .......................................................................................................................................................................... 33
3.3.1
Plan ......................................................................................................................................................... 34
3.3.2
Build ....................................................................................................................................................... 35
3.3.3
Run ......................................................................................................................................................... 36
3.3.4
Optimize ................................................................................................................................................. 37
Optimize ................................................................................................................................................................. 38
3.4.1
Method ................................................................................................................................................... 38
3.4.2
Monitoring and Reporting .................................................................................................................... 39
4
4.1
4.2
Driving Continuous Improvement ............................................................................................................. 42
Quality Assurance Tasks....................................................................................................................................... 42
Quality Targets and KPIs....................................................................................................................................... 42
5
5.1
5.2
Training ......................................................................................................................................................... 45
Expert Guided Implementation Sessions ............................................................................................................46
Setup Support by SAP ..........................................................................................................................................46
6
More Information ........................................................................................................................................ 48
4
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
SAP Standard for Change Control Management
Table of Contents
1
SAP Standards for E2E Solution
Operations
IT organizations face new challenges every day as they attempt to remain effective and future safe while also
keeping costs for day-to-day operations as low as possible. They are also being challenged more than ever to
demonstrate their value to businesses. Therefore, it is important to optimize the day-to-day tasks that have less
obvious business value and to use KPI and benchmark-based reporting to make IT processes more visible,
demonstrating the real value that IT can provide.
In order to minimize the costs of IT, it is necessary to standardize and automate IT processes end-to-end (E2E)
without reducing the SLAs required by the business, such as stability, availability, performance, process and data
transparency, data consistency, IT process compliance, and so on.
Based on the experience gained by SAP Active Global Support (AGS) while serving more than 36,000 customers,
SAP has defined process standards and best practices to help customers set up and run E2E solution operations
for their SAP-centric solutions.
The Build phase of SAP best practices supports a Build SAP Like a Factory approach, consisting of the following
processes:
Custom code management
Change, test, and release management
Incident, problem, and request management
Solution documentation
Remote supportability
During the Run phase of a solution, adapting your IT infrastructure to a Run SAP Like a Factory operation impacts
both application operations and business process operations. Therefore, operations processes, such as technical
monitoring, end-to-end root-cause analysis, technical administration, and data volume management need to be
optimized to achieve state-of-the-art application operations. In business process operations, the same applies to
business process and interface monitoring (including performance optimization), data consistency management,
and job scheduling management.
Quality management processes and tasks need to be established throughout the lifecycle to guarantee
continuous improvement of the end-to-end operations processes while simultaneously ensuring the flexibility
needed to react to changing requirements.
SAP Standard for Change Control Management
Table of Contents
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
5
Figure 1: Organizational model for solution operations
This figure shows an organizational model for solution operations that aligns SAP best practice topics and E2E
standards with SAP's control center approach.
The Operations Control Center executes and controls the Run SAP Like a Factory processes, while the Innovation
Control Center ensures optimal custom code management and a smooth transition to production with integration
validation procedures. SAP connects to these control centers from the Mission Control Center to ensure that
professional support is available to the customer. The following Application Lifecycle Management (ALM)
functions are not provided directly in one of the control centers because they must be handled across different
areas:
Change, test, and release management
Incident, problem, and request management
Solution documentation
Remote supportability
The quality management methodologies are an essential part of SAP's Advanced Customer Center of Expertise
(CoE) concept and ensure that the KPI-driven processes are continuously improved across all processes and
teams. In addition, the quality manager roles ensure consistent and value-centric reporting to the business and
management. This unified reporting platform is known as the Single Source of Truth.
1.1
Control Center Approach
The Operations Control Center (OCC) is the physical manifestation of the Run SAP Like a Factory philosophy. The
OCC allows for automated, proactive operations, which simultaneously reduces operational costs while increasing
the quality of IT services, leading to improved business satisfaction. The OCC also drives continuous improvement
of business processes and IT support. To achieve these goals, it relies on a close interaction with both the
Innovation Control Center (ICC) and the SAP Mission Control Center (MCC).
6
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
SAP Standard for Change Control Management
Table of Contents
Figure 2: Interaction Between ICC, OCC, and MCC
The OCC is a central IT support entity at the customer site, which monitors the productive SAP environment as
well as important non-SAP applications. During operation, the OCC requires a workforce of 2 full-time equivalent
(FTE) per shift to ensure that incidents are detected and resolved as quickly as possible. The OCC is equipped
with large screens that display the status of business processes, IT landscape components, as well as exceptions
and alerts. If problems occur, you use a video link to get live support from SAP and partners. The customer usually
sets up the room with assistance from SAP Active Global Support (AGS). The customer is responsible for
managing the OCC and the team of technical and functional IT operators who act on the alerts.
The OCC is most effective when closely integrated with other IT processes, such as IT Service Management
(ITSM) and Change Management. Central monitors and dashboards based on application and business process
operations display the current status of business and IT-related processes. This data can also be used to drive
continuous improvement.
An effective system monitoring and alerting infrastructure is fundamental to the success of an OCC.
SAP Standard for Change Control Management
Table of Contents
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
7
Figure 3: OCC Concept
The OCC is most effective when closely integrated with other IT processes, such as IT Service Management
(ITSM) and Change Management. Central monitors and dashboards based on application and business process
operations display the current status of business and IT-related processes. This data can also be used to drive
continuous improvement.
An effective system monitoring and alerting infrastructure is fundamental to the success of an OCC.
For Job Scheduling Management, the OCC supervises all background monitoring processes, SAP controls and
legacy background operations. It reacts to job monitoring alerts according to predefined error-resolution
activities, and triggers follow-up activities for error handling if the relevant task are not completed within a certain
timeframe.
8
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
SAP Standard for Change Control Management
Table of Contents
2
Overview of the SAP Standard for Change
Control Management
In SAP Solution Manager, Change Control Management provides a number of tools for implementing and
maintaining company-wide change control management processes. In addition, best practices for change and
transport management within your organization help you to implement a well-defined process flow conforming to
industry standards, such as the IT Infrastructure Library (ITIL). The Change Control Management portfolio in SAP
Solution Manager consists of a number of tools, including Quality Gate Management, Transport Execution
Analysis, Retrofit, and Change Request Management. It is designed to handle a wide range of tasks, providing
everything from a technical overview of the Change and Transport System (CTS) to a full workflow-driven change
management solution.
The change management process is divided into two major areas in SAP Solution Manager, namely Change
Control Management and IT Service Management. While Change Control Management deals with the technical
aspects of change management, IT Service Management focuses more on the process-oriented and
organizational aspects of making changes to your SAP solution landscape or any other part of your IT
environment.
The Change Request Management tool combines both of these areas. It is integrated into the technical
environment of the CTS and provides a sophisticated process layer for running change processes and release and
deployment processes within SAP Solution Manager. This document focuses on using Change Request
Management to implement the best practices for E2E Change Control Management. For more information on
other tools, see Basic Architecture.
2.1
Change Request Management
SAP Solution Manager offers a set of preconfigured change management processes that you can set up with the
help of a guided configuration procedure. Based on this ready-to-use configuration, you can adjust the tools to
meet your individual business requirements. You can adapt workflow settings, service organization, user roles,
automatic email notifications, UI adoptions, and reporting capabilities. In addition, SAP Solution Manager offers
many features as standard, for example, authorization management, different inbound and outbound channels, a
post-processing framework, and an enhancement workbench for making adjustments to individual fields without
the need for manual coding.
One of the major benefits of this solution is that you can integrate it into the SAP environment and use it with
deployment tools to help automate change processes across your SAP and non-SAP landscape.
Due to its open interfaces, you can integrate Change Request Management into non-SAP technologies. The
following table contains an overview of the main tasks related to Change Request Management and the features
provided by SAP Solution Manager to support these tasks:
SAP Standard for Change Control Management
Table of Contents
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
9
Tasks
Features
Create, process, and review requests
for change
Sophisticated approval management
Clearly defined responsibilities for each change phase
Assess, evaluate, and authorize
changes
Close integration with release and deployment
management
Authorize and coordinate creation,
testing, and implementation of changes
Ability to create reports as follow-up documents from
individual incidents and problems
Review and confirm changes
Integration with SAP Project and Portfolio Management
(PPM) and Test Management
Billing and chargeback based on actual effort
Change Request Management uses the following types of transaction:
Requests for Change
Requests for change are created to request changes to your software or a company system, for example, an
enhancement or to a function. End users and key users create requests for change to fulfill completely new
requirements. If a change is necessary due to an incident or problem, service desk employees can also create
requests for change.
When creating the request for change, the requester provides information about the change, for example, impact,
urgency and priority, category, required end date, and the affected system. Either a Change Manager or a Change
Advisory Board checks, evaluates, and verifies this information based on predefined guidelines and then either
rejects or approves the request for change.
Change Documents
After change approval, the system automatically creates a change document, which documents the activities of
the users that are involved in the change process, for example, developers, testers, and system administrators.
Everyone involved in the process is assigned a specific key task. The following table shows a list of roles and their
key tasks:
Role
Key Task
Change Managers
Oversee the process
Developers
Implement the change
Testers
Verify the change
System administrators
Transport the change into the production environment
As Change Request Management is so closely connected to backend systems, SAP Solution Manager triggers
some processes automatically.
In general, the process for Change Request Management is as follows:
1.
The developer creates the transport request in the development system.
2.
The change is handed over to the tester or a test team.
3.
In the background, the change is transported to the quality assurance system.
4.
After successful verification, the change can be transported to the production system by the system
administrator.
10
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
SAP Standard for Change Control Management
Table of Contents
Figure 4: Interaction Between Requests for Change and Change Documents
2.1.1
Types of Change
The type of change you want to implement influences when you import the change into the production system.
The ITIL defines the following types of change:
Change Type
Description
Preapproved changes
Standardized changes that occur regularly with limited
risks and defined impacts. They are executed based on
simplified guidelines and workflows and can go live
whenever they are ready.
Normal changes
Changes that are not too complex or urgent. They
require good coordination and appropriate approval
steps before they can be transported to the productive
environment. Different normal changes are combined
in a single release, which needs to pass several testing
levels before it is imported into the production system
at a well-defined point in time to decrease the impact
on end users.
Emergency changes
Highly urgent changes to resolve serious issues that
affect a high number of users or important service
processes. You execute this type a change according
to shortened workflows combined with high-level
management supervision.
The workflows in Change Request Management are based on procedures described by the ITIL. In addition to the
workflow that supports executing a request for change, there are also workflows that help you to make the change
itself. Workflows are available for the following changes:
SAP Standard for Change Control Management
Table of Contents
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
11
Emergency changes in SAP systems
Periodic changes in SAP systems
Administrative changes
General changes
Troubleshooting during integration testing
2.1.2
Release and Deployment Management
Change Request Management also contains features to support release and deployment management. The tool
differentiates between the following main types of release:
Releases related to SAP components
Custom releases that can be assigned and related to any type of configuration item that has been defined in
the system
SAP Solution Manager also contains a project management suite that enables you to control and manage all
release-related activities in detail. The following table contains an overview of the main tasks related to release
and deployment management and the features provided by SAP Solution Manager to support these tasks:
Tasks
Features
Create and process change documents
Control your project phases, such as release and
go-live, by using a task list
Update the status of previous records, such as
requests for change, problems, or incidents,
following a successful change
Deploy SAP-based changes (ABAP, Java) across
your SAP landscape by using the Change and
Transport System (CTS, cCTS, and CTS+)
2.1.3
Advanced CTS functionalities, such as Transport
of Copies, which minimizes the number of
transport requests, or Transport Collection, which
groups together all changes belonging to one
request for change
Integration with SAP Project and Portfolio
Management (PPM)
Integration with Test Management (assigning test
plans or test packages)
Solution Manager Requirements and Release
Management (for SAP MaxAttention customers
only)
Defining a Release Strategy
Systems, configurations, and infrastructure changed frequently within companies, for example, due to legal
changes or economic conditions. These changes can cause planned or unplanned interruptions in applications
and business processes that cannot always be foreseen in heterogeneous and complex system landscapes.
Therefore, Release Management has to minimize the risk of disruption to business processes when changes to
the production systems are performed. This also reduces costs.
There are many reasons for disruptions, but they are most often the result of insufficient planning or testing in the
development system.
12
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
SAP Standard for Change Control Management
Table of Contents
Release Management teams manage a high number of changes and aim to ensure that releases are implemented
in the correct sequence. To avoid conflicts between releases, you need to define, plan, develop, test, and set all
project requirements appropriately.
There are two types of release.
Major Release
A major release takes three to six months. In a year, customers develop between two and four major releases.
These releases include all types of changes, even those that affect core business processes. Therefore, a major
release requires complete regression testing that goes above and beyond normal release testing.
Minor Release
A minor release has a substantially shorter duration of between one to four weeks. The goal of minor releases is to
bundle bug fixes and minor enhancements, then move them to the production system at short-notice. For a minor
release, testing is limited to the core business processes and the extensions provided.
By following SAP's release management recommendations, you can achieve the following benefits:
The frequency of changes in the production system is reduced.
Imports into the production system occur at a predefined point in time.
End user satisfaction is increased due to early communication and training.
Each change is tested appropriately.
Daily changes are restricted to emergency fixes.
The risk of inconsistencies due to missing transports or transports imported with sequence violations is
reduced.
The administrative effort for transports is reduced when you import changes using SAP Solution Manager.
SAP Standard for Change Control Management
Table of Contents
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
13
2.2
Basic Architecture
Figure 5: Change Control Pyramid
The change control pyramid shows how the different functions of SAP Solution Manager help support the change
control management process. This section provides a brief overview of how you can use these tools and features
to implement effective change control management processes. For more information on how they can be used to
support Application Lifecycle Management, see Change Management and Application Lifecycle Management
Process.
You can seamlessly integrate Change Request Management into the change processes on any managed systems.
In SAP Solution Manager, you can centrally create and release transport requests, and import them into
subsystems. For all changes to ABAP stacks, you can integrate the system into the Change and Transport System
(CTS). For changes in Java-stack systems, such as SAP Portal, or dual-stack systems, such as SAP Business
Warehouse (BW), you have to configure the Enhanced Change and Transport System (CTS+) in the managed
system landscape. Change Request Management also interacts with this infrastructure. You can even use it to
manage non-SAP environments, for example, AS400.
2.2.1
Tools for Managing Changes
Central Change and Transport System
You need SAP Solution Manager Support Package 10 to access the central Change and Transport System (cCTS).
With this feature, you can cluster several system landscapes, which enables you to model system dependencies
using the Transport Management System (transaction STMS).
Example
You cluster all of your landscapes according to system role, for example, one cluster for all development
systems, one cluster for all quality assurance systems, and one cluster for all production landscapes. This
enables you to manage cross-system changes, for example, when a certain requirement leads to changes
in an ERP and BW system that need to be deployed at the same time. SAP Solution Manager and cCTS
ensure that both transports are synchronized in one change document.
14
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
SAP Standard for Change Control Management
Table of Contents
Transport Analytics and Configuration Validation
To measure the success of your Change Control Management implementation, you must be aware of every
change that has been performed across your system landscapes. Transport analytics and configuration validation
help you to view any changes to your system landscape and the related information.
Transport analytics provide information about imported transport requests, compare the number of released and
imported transport requests, and display any overtakers and imports with errors. In addition, you can see how
long has been spent on the quality assurance system, which enables you to estimate the time spent testing and
the efficiency of your tests.
Configuration validation enables you to compare the current system configuration with a reference system
configuration. The reference system configuration usually represents the system in a stable state. When an
application becomes unstable, it can be compared with the reference system to identify changes that were
performed between when the system was stable and the current state.
Retrofit
In addition to basic three or four-tier system landscapes, you can separate the development and maintenance
landscapes to enhance the stability of the production system. This is known as a dual landscape. In dual
landscapes, maintaining synchronization between the maintenance-production and development landscapes is
essential in order to avoid overwriting maintenance changes when the project is transported to the production
system. However, the time and effort spent synchronizing the landscapes often makes this option unappealing.
Retrofitting the changes can help to synchronize your landscapes by automating the process as much as possible.
SAP customers report around 85% to 93% of their objects can be automatically or semi-automatically imported
using retrofitting. Objects that have been changed in the maintenance-production landscape but not in the
development landscape can be automatically retrofitted. If the same object from the maintenance-production
landscape has already been changed in the development landscape, you can decide which version to keep using
SAP correction workbench. For objects that are not connected to the correction workbench, you need to perform
the retrofit manually.
Cross-System Object Lock
If cross-system object lock is active, whenever you make a change in a managed system, an entry is made in the
cross-system object lock table in the central SAP Solution Manager system. This entry contains information about
where the object was changed, when it was changed, as well as other details such as the transport request
number, transport number and object ID. This lock entry prevents changes being made to this object in any other
transport requests. If a user tries to change a locked object, an error message is displayed.
The lock is only removed when the changes are transported to the production system. This helps prevent
overtakers in large landscapes or when working on parallel projects.
You can use cross-system object locking either on its own or in conjunction with retrofitting.
Quality Gate Management
You can use Quality Gate Management (QGM) to manage changes in a heterogeneous system landscape. A
project acts as the central entity and is divided into several phases by quality gates. By default, each project
comprises four phases: scope, build, test, and deploy. If a change passes a quality gate, for example, because of
certain authorizations and by applying the four-eyes principle, background activities are performed. For example,
when a change passes the gate between the build and test phases, all changes are transported from the
development to the quality assurance landscapes. Using Quality Gate Management, you can import these
changes simultaneously for all landscapes in the project.
SAP Standard for Change Control Management
Table of Contents
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
15
Change Request Management
You can use Change Request Management to develop, manage, and optimize your change processes, including
change execution. The Change Request Management tool actually supports the entire change management
lifecycle from initiating the change to processing it and implementing it as part of release and deployment.
Specifically, you can use it to manage the following processes:
Initiating, documenting, and authorizing requests for change
Viewing change impact analyses
Approving or rejecting requests for change
Monitoring and reporting on the implementation
Deploying changes
2.2.2
Tools for Increasing Business Flexibility
Change Request Management offers many different ways of checking requests for change and change
documents across various system landscapes. Different workflows enable you to fix bugs quickly and efficiently in
production landscapes or to develop completely new features in a release project.
SAP Solution Manager provides several functions that allow you to be more flexible when dealing with changes.
Downgrade Protection
Caution
Before implementing any other tools mentioned in this chapter, you must have set up downgrade
protection to ensure that your system is not accidentally downgraded.
When you are working in a flexible and changing environment, changes often appear in different projects with
different levels of urgency. The downgrade protection function tracks objects in transport requests, and reports
conflicts in five scenarios when an object that is saved in two or more transport requests is released, reassigned,
or imported. This applies to all managed development systems and clients for which the cross-system object lock
is active, and the Change and Transport System plug-in is installed.
Downgrade protection ensures that you do not downgrade your system. This means that you keep your test and
production systems consistent. If you are working with flexible release management, you can keep your releases
and their deployment consistent. This ensures a more stable production environment. In combination with a
cross-system object lock, downgrade protection provides protection at every stage of a technical change.
Preliminary Import
If you cannot delay the development go-live until the full release, you can process a normal change separately so
that it is imported immediately, irrespective of the full release. You can access preliminary import from the
process flow of a normal change.
The normal change is treated in the same way as an urgent correction. It is first imported separately from the
other developments and the relevant transport requests are then kept in the import buffer of the production
system so that you can run a consolidated import at the time of release.
16
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
SAP Standard for Change Control Management
Table of Contents
Reassignment of Change Documents
You may find that you cannot complete an enhancement in time, especially when implementing projects. As
implementation projects have no recurring lifecycle, you perform checks to prevent a project from being
completed until all transports have been implemented.
As of SAP Solution Manager SP05, you can choose to delay the project, undo a specific change, or reassign a
change document from one project to another. During a reassignment you can check whether the target project is
being run in the same landscape. In SAP Solution Manager 7.1 SP05 to SP09, you can only reassign change
documents with unreleased transport requests. As of SP10, you can reassign change documents with released
transport requests and use the central Change and Transport System (cCTS).
Decoupling and Coupling Transport Requests
When working in project cycles that have different phases, you may have to remove individual transport requests
from the cycle or reassign transports to new change documents because of changing parameters from the
business processes or incomplete developments.
Change Request Management provides features to change the assignment of transports before the project is
released, giving you the maximum flexibility with your releases and allowing you to perform detailed checks on
transport requests.
2.3
Integration with Application Lifecycle Management
You can integrate Change Request Management into a broad range of features and systems. Change Request
Management comprises all of the integration scenarios shown in the following figure:
Figure 6: Change Request Management Integration Scenario
The following example outlines the interaction between IT Service Management (including Change Management)
and Application Lifecycle Management.
SAP Standard for Change Control Management
Table of Contents
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
17
Example
1.
SAP Solution Manager monitors your company’s business processes and its entire system infrastructure.
You configure SAP Solution Manager to automatically generate an alert if one of your KPIs reaches a
predefined threshold (Event Management).
2.
The alert generates a dedicated incident record because you have integrated IT Service Management (ITSM)
into your solution.
3.
In SAP Solution Manager, a service desk employee uses ITSM to process this incident report and you perform
a detailed root cause analysis with the help of other SAP Solution Manager applications and functions, such as
trace, change, or exception analyses. You can then consider its relevance to other objects (Impact Analysis).
4.
To examine the cause of the alert in more detail, the service desk employee creates a problem record from
the incident report. This is created as a follow-up document.
5.
This problem is forwarded to the Problem Management team, who are trained to further investigate the
problem.
6.
You integrate the Problem Management process into SAP support message processing (SAP collaboration).
From here, you request support from SAP Active Global Support (AGS).
7.
SAP AGS provides an SAP Note as a solution for your issue, which is ready to be implemented with the help of
SAP Note Assistant. However, as this leads to a change in the production system, you create a request for
change from the problem record (Change Management).
8.
After the change has been approved, it is implemented in the development system and transferred to the
production system (Deployment Management).
9.
The incident record states which business process is affected by the change. You use this information to
identify an appropriate test case using Solution Documentation.
10. You test the business process that is affected by the change either manually or automatically (Test
Management).
11. The problem and incident records are closed and a knowledge article is generated. You use knowledge
articles to document the solution method for the problem. If the same problem occurs again in another
system you can access the knowledge article and fix the problem quickly and efficiently (Knowledge
Management).
18
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
SAP Standard for Change Control Management
Table of Contents
Figure 7: Interaction Between ITSM into ALM
SAP Standard for Change Control Management
Table of Contents
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
19
3
Lifecycle of Change Control Management
3.1
Plan
In this phase, you have to consider all of the aspects that might affect the implementation process. This is
important because you need to perform the implementation in the same way as you would a project. The following
chapter provides guidance on how to plan your implementation and fulfill the prerequisites.
3.1.1
Project-Related Aspects
It is important to clarify the general aims for implementing Change Control Management in your company. For
this you should apply both "as is" and "to be" analyses. You need to define the scope of the project, including
which change management processes and functions should be deployed. At first, you will probably not need all of
the processes or tools with specific functions. You need to identify business-critical core services and processes
and focus on them.
Think about what kind of project you intend to run. For instance, you might consider a rapid deployment solution if
you are running a pilot or proof-of-concept or you might want to run a full implementation using a phase-based
approach with well-defined milestones. The kind of project you are running also affects how you proceed with any
subsequent planned activities.
You need to start defining priority-based work packages and schedule required time frames for finishing them,
calculate the effort, and plan your assets according to resources and capabilities. The following table lists
examples of these factors:
Factor
Resources
Capabilities
Examples
Available staff
Budget
Current or planned infrastructure
Access to information
Existing applications
The structure of your organization
Management responsibility
Current documented processes and knowledge
You need to evaluate which part of your IT landscape needs be covered by Change Control Management. You also
have to decide if you need to include non-SAP applications as well. The main difficulties in doing this are
organizing and standardizing current live processes and ensuring cooperation between all stakeholders.
You need to consider the following high-level work packages:
Analysis of functional and organizational requirements
Blueprinting and preparation of functional specifications
Hardware setup
20
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
SAP Standard for Change Control Management
Table of Contents
Implementation (prerequisites, basic configurations, customizing, and migration)
Preparation of master data (users, organizational units, technical systems, and authorizations)
Preparation of documentation (configuration documentation, user manuals, and test cases)
User and administration training courses
Testing (functional tests, integration and acceptance tests)
Bug-fixing
Planning and preparation for go-live
Performing go-live
Project management
3.1.2
Organizational Aspects
In addition to the project-related aspects, you have to examine any organizational aspects. It is important to
identify critical functions, roles, and responsibilities. Document this in a responsibility assignment (RACI) matrix
and prepare a communication plan. This means that you have all the necessary contact details in place. You need
to clearly assign all project members to the change management project and ensure that they are available for the
duration of the project.
First, you need to make sure that all project members have a general understanding of Change Control
Management. If your staff are preforming the implementation, you need to train them appropriately. SAP offers
several training courses and knowledge sources for this purpose. For more information, see Training and More
Information. You can also get support from external resources responsible for various project-related activities
such as project management, implementation, or development, for example, from the SAP Customer Center of
Expertise (CoE).
The Customer CoE improves transparency and quality management, aiming to resolve critical challenges across
SAP Solution Operations. The CoE program provides information, methodologies, and tools to help you improve
quality checks and continuously improve SAP Solution Operations. It verifies the processes that customers
implement to perform these activities and ensures that the process is compliant with the SAP Standards for E2E
Solution Operations.
Be aware of any disagreements between your departments or employees regarding changes. In order to be
successful, you need to have the acceptance and support of your management staff, affected process owners,
and stakeholders.
You also have to consider work spaces and grant access to buildings or other necessary areas for external
employees during an on-site engagement.
3.1.3
Technical Aspects
When planning an implementation of Change Control Management, you need to consider the following technical
aspects:
Hardware Sizing
When sizing your hardware for Change Control Management, you need to consider the following KPIs:
SAP Standard for Change Control Management
Table of Contents
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
21
Number of documents (request for change, change documents) created per day
Number of low activity users (10 dialog steps per hour or less)
Number of medium activity users (2 dialog steps per minute, approximately)
Number of high activity users (10 dialog steps per minute or more)
Workdays per year, according to company policy
When scaling your dedicated hardware, you need to consider the following KPIs:
Average number of concurrent users during peak times
Average number of queries per user in one hour
Average number of high and medium connectors per query
Total number of files to be loaded
Total number of business objects to be loaded
Number business objects increase per year
For more information, see the SAP Solution Manager 7.1 Sizing Toolkit at
http://help.sap.com/solutionmanager71 Sizing
SAP Solution Manager Configuration
Before starting your Change Control Management implementation, you need to complete the System
Preparation, Basic Configuration, and Managed System Configuration scenarios of SAP Solution Manager
Configuration (transaction SOLMAN_SETUP).
Master Correction Note and Change Request Management Master Note
Make sure that the latest version of the Master Correction Note is implemented according to your SAP Solution
Manager support package stack level. Check for updates regularly to ensure that bug-fixes are implemented.
For every support package, there is also a Change Request Management Master Note which contains known bugfixes and the corresponding SAP Notes that solve this issue. You need to update this SAP Note regularly.
System Access
You need to grant system access, including Internet access or internal network connection, to everyone involved
in the configuration in both SAP Solution Manager and the managed systems. In addition, do not forget to prepare
SAP Solution Manager system users, including user names and passwords, with sufficient authorizations for all
involved stakeholders. Requesting authorization objects can be time consuming and laborious during the
implementation phase.
If SAP staff are involved in the implementation, it is crucial that you enable the remote SAP R/3 and HTTP
connection from SAP Service Marketplace to SAP Solution Manager.
Change Control Management Process
Implementing and customizing actions are stored in dedicated transport requests as workbench and customizing
requests. Therefore, you need to think about your Change Control Management process for the implementation
project. SAP recommends that you bundle all Change Control Management transports in one CTS project.
SAP Connect
You need to configure SAP Connect (transaction SCOT) to send emails according to defined email actions within
IT Service Management.
22
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
SAP Standard for Change Control Management
Table of Contents
Text Retrieval and Information Extraction
To enable full-text searches within requests for change and change documents, you need to set up the Text
Retrieval and information Extraction (TREX) search engine.
3.1.4
Change Control Management Processes
Change Control Management processes require specific planning and design activities before you can start the
implementation.
Existing Processes
You need to review all process documentation, for example, process flow diagrams or descriptions, particularly
those relating to requests for change and change processes and check if you need to make any modifications. You
use this documentation as a basis for the implementation.
You must work with all process stakeholders, including the process owner, process manager, and practitioners to
define process descriptions. In addition, you need to make sure that all of these stakeholders have been added to
the RACI matrix and the communication plan.
Functions
Check whether your specific functional requirements are covered by SAP Change Control Management. You
might find it helpful to build a requirement matrix to analyze whether key features are covered fully, partly, or not
at all. You can also easily document necessary developments here. Later, you need to track any effort spent
implementing key functionalities, such as customizing or development, in the project plan.
You need to analyze the following core features:
Automatic email notifications in case of status changes
Multilevel categorization
Structure of your organization
Support Organization
You can build the basic structure of your individual support organization in SAP Solution Manager. You have to
analyze and define the structure for your specific organization. You can base your structure on any kind of
organizational structure. You can then assign team members, for example, developers, testers, system
administrators, or change managers, to these teams.
Setting up your support organization enables you to use several features in Change Request Management. For
example, you can notify the responsible team via email when a request for change has been automatically
dispatched to this team or when the search filter for change records assigned to the team becomes applicable.
Authorization Concept
You must identify all user groups working with Change Control Management and define the related authorization
roles. Documenting and setting an authorization concept is not simple and must be carefully considered. SAP
Solution Manager allows you to define many authorization objects, for example, to view and use different UI
components, set the visibility of text types, apply specific workflow statuses, or create and modify requests for
change and change records.
SAP Standard for Change Control Management
Table of Contents
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
23
3.2
Build
Once you have completed the plan phase, you can begin to implement your solution. You need to make finance,
IT, and personnel resources available from the start of the build phase.
You must have set up a system landscape with a minimum of two systems for development and production. If you
are performing a completely new implementation, you can use a sandbox environment. After implementing and
successfully testing the sandbox, you can copy it to construct a maintenance landscape.
After preparing the system and performing a basic configuration of SAP Solution Manager, you need to complete
a configuration for managed systems. The following chapter provides guidance on how to implement your change
management process.
3.2.1
Solution Manager Landscape
SAP recommends that you set up a three-tier system landscape with a development, quality assurance, and
production system. You begin your change management implementation on the development system. After
finishing the implementation, you have to transport the changes to the quality assurance system which you use to
run test cases. After a successful test, you can transport the Change Control Management implementation to the
production system and activate it. Continuous improvements, for example, developments, implementing new
features, bug fixing, and upgrades, should only be introduced in the development system. This protects your
production environment against any unconfirmed and unsuccessfully tested changes.
Figure 8: Recommended Three-Tier System Landscape
If for any reason you cannot set up a three-tier landscape, you must establish at least a two-tier landscape for SAP
Solution Manager. In this case, you use the non-productive system for both the pilot project implementation and
for testing.
24
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
SAP Standard for Change Control Management
Table of Contents
Figure 9: Two-Tier System Landscape
You have to connect the non-productive SAP Solution Manager systems and the non-productive managed
systems to the productive SAP Solution Manager system. You can use one of the following connection types:
Connection via trusted RFC between productive and non-productive SAP Solution Manager systems
Connection via trusted RFC between productive SAP Solution Manager system and managed systems
TMW and READ RFC between productive SAP Solution Manager system and managed systems
To evaluate change processes, it is essential that you set up an environment to create transport requests for
testing purposes. You have several options for this. The following examples are typical options used by
customers:
Option 1: Separate Clients on Solution Manager Development or Quality Assurance System
SAP Standard for Change Control Management
Table of Contents
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
25
Figure 10: Example Environment Option 1
The three clients represent a classic three-tier system transport landscape. With these additional clients you can
simulate your change processes by using customizing changes.
Option 2: Separate Clients on Managed System
Figure 11: Example Environment Option 2
The three clients in this scenario also represent a classic three-system transport landscape. With these additional
clients, you can simulate your change processes by using customizing changes. The advantage compared to
option 1 is that you have RFC connections throughout the system between SAP Solution Manager and the
managed system.
3.2.1.1
Dual Maintenance
In addition to the classic three or four-system landscapes in which maintenance and project developments are
performed in parallel in the same track, more and more customers are splitting these activities by creating a
separate track for implementation projects with a cycle longer than 3 months.
This enables you to focus on emergency and minor changes, which can be tested independently from ongoing
developments for major releases, in the maintenance track. Major releases can be tested more precisely in a
stable environment before they are sent to the maintenance landscape.
You need to implement a preproduction system, particularly if you are developing parallel releases because you
have to test one release in isolation before transferring it to the maintenance landscape. Import from the project
to the maintenance landscape is called the cutover.
26
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
SAP Standard for Change Control Management
Table of Contents
You need to make changes to customizing and workbench objects if you use the production system to perform
maintenance activities. These changes must be synchronized with the project landscape to avoid downgrading
objects which were changed during the cutover process. This synchronization is supported within SAP Solution
Manager using the retrofit function. For more information, see Tools for Managing Changes.
Figure 12: Dual Landscape
3.2.1.2
Parallel Development
Note
It is important to note that the there are also negative aspects to running parallel system tracks.
Using a parallel development landscape can cause the following problems:
Extra administration activities must be performed
Extra retrofit activities that cannot be performed using tools must be preformed
Additional cutover planning is required
You must implement advanced security functions, such as downgrade protection or cross system object lock, to
avoid overwriting or downgrading your systems, especially when you perform development activities that take
place in several development systems.
Any changes that are separate from workbench or customizing are stored in a central table in SAP Solution
Manager.
SAP Standard for Change Control Management
Table of Contents
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
27
If an object is changed multiple times, a warning or error message is raised depending on the central system
object lock configuration. A warning message allows developers the option of continuing with the change, but this
increases the risk of creating a downgrade. An error message is more restrictive.
You need to evaluate customer requirements precisely to identify the best method, as different options are
available. For example, you might decide to have multiple project changes return an error message while
emergency changes only return a warning.
When working with parallel development and projects two kinds of problems can occur:
Object Conflicts
Figure 13: Object Conflict
In this scenario, the same objects are contained in different projects. The project that is imported last overwrites
the objects in the other project. Therefore, the project that was imported first may no longer work after you have
imported the second project.
Object Dependencies
Figure 4: Object Dependencies
In this scenario, objects in different projects reference each other. For example, a program in project 1 calls an
object included in project 2. If only one of the projects is imported into another system, it will fail. This problem is
called cross-reference inconsistency.
Object dependencies are not recognized by the cross-system object lock.
Solutions
To fix cross-referencing inconsistencies, you have to use a preproduction system. If the preproduction system's
software and configuration are up to date, you can detect and fix the error in preproduction provided that you
perform an isolated test of the project releases in the preproduction system.
SAP recommends the following actions to avoid object dependencies:
28
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
SAP Standard for Change Control Management
Table of Contents
The responsible development teams estimate potential collisions (objects changed differently in several
projects) before a project starts
o If no collisions are expected, projects can run in parallel.
o If collisions are expected, projects should be run in sequence or handled as one common project.
o If possible, several small projects should be bundled into one big project with a single go-live date.
Working with parallel projects requires a rigorous governance and process control. Ideally a quality manager
should be responsible for checking collisions and defining workarounds.
You need to implement the following procedures to mitigate the risk of undetected collisions:
Release transport requests later to keep the object locked
Lock objects that are identified as potential collisions in a dummy transport
Put objects that are identified as potential collisions into the critical objects list
Move long-running projects into separate environments
Clearly assign transport requests to their project, either by using a CTS projects or by using a naming
convention for the short text of the transport requests
3.2.2
Functional Implementation
The start point for your Change Control Management implementation is the Change Request Management
scenario of SAP Solution Manager Configuration (transaction SOLMAN_SETUP). This includes a guided
configuration procedure containing everything you need to do to set up Change Request Management.
Figure 5: SAP Solution Manager Configuration for Change Request Management
In addition to SAP Solution Manager Configuration, you can find advanced implementation activities and
documentation in the Solution Manager Implementation Guide.
To find this, in SAP Customizing, Execute Project (transaction SPRO) choose SAP Reference IMG SAP Solution
Manager Implementation Guide SAP Solution Manager Capabilities (Optional) Change Request
Management.
SAP Standard for Change Control Management
Table of Contents
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
29
Adapting Change Management Workflows
When you have completed the Change Request Management basic configuration, you can adapt the workflow for
requests for change and change documents according to business needs by customizing dedicated transaction
type profiles. You can use the BAdIs provided by SAP to enhance the processes. The web-based user interface
can be adjusted using the Web UI configuration mode or the Application Enhancement Tool.
Master Data
Before you can create or process change records, you must prepare the master data.
The master data contains the following objects:
System User
Business Partner
Organization
IBase-Components
Multi Level Categorization
Logical Components
Business Partners
In SAP Solution Manager, business partners guarantee effective and easy communication between all employees
involved in change processes. All relevant information relating to business partner can be accessed from a central
location.
If you have a business role with the appropriate administrative authorizations, for example, SOLMANPRO, you can
create individual business partners manually in SAP Solution Manager. In general, however, business partners are
migrated from connected SAP systems with background processing. The report copies all or selected users
(including their email addresses) from other systems and generates all the necessary business partner functions
in SAP Solution Manager, for example, contact, employee, or general. In addition, you can generate an SAP
Solution Manager Login User and assign a template authorization role to the user. You can make the relevant
settings in the implementation guide for SAP Solution Manager.
Which part of a process the business partners are involved in does not matter. For example, a single employee can
function as both a requester and tester. Therefore, you can use SAP Solution Manager to assign a business
partner different roles and relationships to other business partners.
In the standard configuration shipped by SAP, some partner functions have already been defined. The following
table shows examples of some predefined business partners and their functions:
Role
Function
Requester
Creates the request for change
Change Manager
Approves or rejects the request for change
Gives the authorization for production import of urgent
changes
Developer
Implements the change
Tester
Verifies the provided solution on quality assurance
system
Current Processor
Is the employee currently responsible for the change
document
30
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
SAP Standard for Change Control Management
Table of Contents
Role
Function
IT Administrator
Triggers the import into subsequent systems.
The organizational schema in General Attribute Change tool (transaction PPOMA_CRM), must be up to date and
accurately display the organization of the change department.
You use this tool to define the various levels and assign employees to the various groups of experts. This is a
prerequisite for activating automatic rule determination that finds a responsible group within your change
organization based on document characteristics, for example, document category.
IBase and Logical Component
To use Change Control Management scenarios in SAP Solution Manager, you must first define the installation
(IBase). You must create an IBase component for each component system used during the change process.
Therefore, IBase components represent managed systems in your landscape.
In a standard system, IBase components in SAP Solution Manager are managed in the SOL_MAN_DATA_REP
installation IBase structure (installation 1) and are updated automatically when changes are made in the
Landscape Management Database (transaction LMDB).
A logical component is an administrative entity, which assigns logical systems to the system roles or phases in a
project, system landscape, and across projects.
System Settings and Transport Routes
In addition to the connections between SAP Solution Manager and the managed systems, you also need to
perform the following tasks on the managed systems in Transport Management System (transaction STMS):
Activation of Extended Transport Control
Activation of TMS Trusted Services
Set up a single transport and no delivery after confirmation transport strategy.
You also need to set up the following two transport routes.
Route
Description
Transport layer
Create a transport layer for your development client.
A transport layer is assigned to each development class and to all objects in that class. The
transport layer determines in which SAP system developments or changes to repository
objects are made and where these objects are transported.
Delivery route
Create a delivery route from your quality assurance client to your production client.
SAP Solution Manager Project
SAP Solution Manager projects specify which landscape changes are performed. Logical components assigned to
an SAP Solution Manager project represent the landscape. On the managed system, the SAP Solution Manager
project is represented by an IMG project in the development system and by a CTS project in the development
client. Transport requests created in Change Request Management for a specific SAP Solution Manager project
are automatically assigned to this CTS project to enable you to distinguish between ongoing, parallel projects.
The following figure illustrates SAP Solution Manager project architecture:
SAP Standard for Change Control Management
Table of Contents
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
31
Figure 15: Project Architecture
3.2.3
Authorization Concept
You have already created your authorization concept for your Change Control Management solution during the
Plan phase. During the Build phase, you begin to create the user profiles for dedicated change management user
groups. SAP provides predefined authorization composite-roles for each user group, which include individual
roles for the entire change management process and each feature. For more information about implementing an
ALM authorization scenario, see the Security Guide for SAP Solution Manager on the Service Marketplace at
http://service.sap.com/instguides/ SAP Components SAP Solution Manager Release 7.1 Operations.
3.2.4
Testing, Bug Fixing, and Retesting
Test packages with test plans must be available to perform an integration test that covers the entire change
process together with other integration scenarios and systems. SAP provides tools for test management
processes. These help you to store test sources for central access. For more information, see the SAP Standard
for Test Management.
Any issues are then sent to the relevant Change Request Management expert for correction. Bug fixing and
retesting activities usually require a lot of time so you need to plan them carefully.
In addition to testing activities performed on the demo landscape, you should perform a test on a real landscape,
such as ERP, if possible. To do this you need to perform the following tasks:
Set up RFC-connections and logical components
Apply the necessary system settings on the landscape
Create a Solution Manager project on the productive SAP Solution Manager system
Execute any non-critical changes to verify that the change workflows also work in a true-to-life environment.
32
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
SAP Standard for Change Control Management
Table of Contents
3.2.5
Developing Templates in Complex System
Environments
The release and project management concept of Change Control Management provides a structure to separate
different types of changes. By using different project types as implementation or maintenance, changes within the
same landscape can be separated and controlled individually. In combination with a dual landscape, an
implementation landscape can be used to provide a template version of an application which will be distributed
once or on a regular basis into one or more parallel maintenance landscapes.
Supporting standards, such as the SAP Standard for Solution Documentation, can be used to define the business
processes including configuration data and test cases. A template project function allows you to generate an
individual implementation project when you roll out the application into one of the parallel landscapes. In addition,
you can define, within the project, which objects can be changed locally. If an object is globally defined, you cannot
locally change objects.
Functions, such as retrofit, can be used to synchronize the template development with maintenance changes
performed in a roll-out landscape.
3.3
Run
After a successful integration test, you have to prepare and perform the transition phase. The production system
is then ready for you to import Change Request Management transport requests. You have to perform any preprocessing activities before import, including, loading master data. During import, the SAP basic team and
Change Request Management implementation team need to be available to fix import errors immediately. After
importing Change Request Management transport requests, post-processing tasks are performed. This ends the
transition phase.
Change Control Management is an important solution across an organization. Therefore, you must inform all
involved and affected partners about the implementation of the new processes. Ideally, you have provided training
sessions before production usage starts. Your support organization must be ready to handle requests from end
users, such as developers and testers. You should have a single point of contact to bundle different inbound
channels for incidents that are caused by the new Change Control Management solution.
During service operation, process owners have to monitor different change management aspects, including
performance and feedback from end users. Change Request Management offers different reporting features that
enable you to analyze the state of your implementation at any given time. You can make emergency modifications
to your solution during maintenance activities to fulfill the change management process SLAs that you defined
during the Plan phase. You perform any additional modifications or improvements, including implementing new
features as part of Optimize phase.
Change Control Management is not just one part of ALM, but plays a role across all phases of an application's
lifecycle. Therefore, it is important to maintain a holistic view and understand how Change Control Management
supports each of the Plan, Build, Run, and Optimize phases in the lifecycle of an application. The following
sections provide an overview of a running Change Control Management implementation through each of the
phases of the application lifecycle.
SAP Standard for Change Control Management
Table of Contents
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
33
3.3.1
Plan
The plan phase can be divided into the following sub-phases:
Requirement: List the requirements for an application
Design: Create a detailed specification for these requirements
Requirement Sub-Phase
In this sub-phase, you need to consider what kinds of changes need to be made. This decision will be based on
your individual application. You might want to implement a completely new application or adapt an existing one.
You need to differentiate between major changes, minor changes, and bug fixes, as this allows you to define the
effort and impact associated with a change.
You can document requirements by using either of the two following tools:
IT Service Management provides the service request and incident features, which allow you to document
incidents and problems.
Change Request Management provides the request for change feature, which allows you to document any
requirement that will lead to a change.
Each of these features can be interlinked and used in a predefined way. For more information on ITSM, see the
SAP Standard for IT Service Management.
With Change Request Management, you can create a request for change as either a follow-up document for an
incident or service request, or as a new document. For example, you can state the following information for the
change:
Detailed description
Priority
Impact
Timeline
Affected system
This enables you to precisely document the requirement and describe the planned or requested change.
Design Sub-Phase
In this sub-phase, you need to create a detailed specification for any requirements identified in the requirements
phase. You have to consider how to analyze and approve a change. You add details about the requirement to a
request for change. In addition to the basic information, you have to add information describing the impact of the
change on other business processes or systems. If the business processes are described within SAP Solution
Manager, you can link related processes to the change management documents. You can also use multi-level
categorization to specify the request in detail. Assigning an approval procedure enables you to define the approval
workflow, which means you can set the following restrictions regarding your change approval process:
Type of user
Number of users
Workflow sequence
In a project assignment, you can determine in which context this change should be processed. According to the
change type that you defined in the requirement phase, you can perform this change in either a maintenance or
implementation project. The project assignment does not just define the context in which the change will be
performed; it also lists the possible ways of transporting the change from the development system to the
production system because each project has an individual timeline.
34
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
SAP Standard for Change Control Management
Table of Contents
You can also link requests for change to a project in SAP Project and Portfolio Management (SAP PPM). This will
exchange any relevant data between the request for change and the project. You can use this feature to reduce
the workload of your project managers, as you can always clearly see the status of the request for change in the
request for change project management environment. Effort stated in the request for change document is
automatically synchronized to the corresponding PPM project.
Caution
Any changes that you make can affect multiple systems.
To define the scope of your change, you can use a separate assignment block to maintain systems and clients on
which changes need to be performed. You can then process the complete request for change. In addition to
providing a definition for each system, you need to define which process should be followed to process the change
on that system. You can define changes according to different categories. The following table describes the
possible categories:
Type
Use
Normal Change
Standard changes
Urgent Change
Time-critical changes
General Change
Changes that have no impact on a system, for
example, changing a printer
Admin Change
Changes in systems that you do not manage with the
Transport Management (TMS), for example, a number
range change
If you have any external documents that help to specify a required change, these documents can be attached to
the request for change. Instead of uploading the document, you can add a URL to the document.
The SAP Standard for Solution Documentation describes how business processes can be documented in SAP
Solution Manager. You can also add information to these business processes, for example, configuration
documentation, development documentation, test cases, or user guides, and establish a link to a business
process or document from the process repository in SAP Solution Manager. By doing this, you can reuse existing
information to provide further details in the request for change
You then need to decide if a change can be moved forward to the Build phase. Depending on your specific
approval procedure, one or more people, for example, the Change Manager, need to give approval. Once the
approval has been granted, the request for change will switch to the approved status, which enables you to move
it to the follow-up process. This follow-up process is documented and controlled in a change document. The
request for change is linked to the change document and information is copied from the request for change into
the change document when the change document is created.
3.3.2
Build
The build phase can be divided into the following sub-phases:
Build: Process all data collected during the plan phase, and make the change in the development system
Test: Verify this change in the development or quality assurance system
SAP Standard for Change Control Management
Table of Contents
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
35
Build Sub-Phase
After you have identified and recorded all data relating to the change, you have to use this data to process the
change itself. In Change Request Management, you use the change document to support this process. The
change document itself is defined by the request for change. In the change document, you should store
information about the following topics:
System
Client
Specification
Timeline
Priority
A developer processes the change document by setting an appropriate status, for example, In Development, and
performs the change in the system or client indicated by the request for change. The developer can use functions
in Change Request Management to present information and create a transport request from a change document
on the managed development system. In addition, the developer can access the managed system by using the
links provided in the change document.
Functions such as a cross-system object lock can be used to support the Build phase by ensuring that only one
person can work on certain objects at any given time. This ensures data control and consistency, especially in
major projects or across several parallel projects.
Changes to configuration can be documented in documents attached to the change document, including by
copying them from a request for change, or documents linked via URL or a business process link.
However, Change Request Management does not just document the workflow and all of its details. Integration
with Transport Management System (transaction STMS) allows direct access to TMS functions from inside the
change document. For example, you can create transport requests from managed systems. You can also export
and import changes in managed systems.
Status values indicate the progress of a change document right up to when you import it into the production
system. After finishing the development, the change is ready for testing.
Test Sub-Phase
Once the change has been developed, you have to verify it in the development or quality assurance system. You
can use different types of tests, for example, regression, integration, user acceptance, or performance, to do this.
You can very closely integrate change request management with test management. You can link a test to your
change in the request for change. This means, you can reuse test cases stored and used in test management. You
can also use all of the functions available in test management to verify a change before moving it to the production
system.
Test cases can be rated after execution. If the test case is linked to a change, this result is shown in the change
document and can be used to move forward or backwards if necessary.
3.3.3
Run
The run phase can be divided into the following sub-phases:
Deploy: Implement the change
Operate: Manage the change as a project
36
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
SAP Standard for Change Control Management
Table of Contents
Deploy Sub-Phase
Changes which have been tested successfully can be moved into production by using Change Request
Management functions. A task list provides various functions for verifying and moving a project through the
system landscape to the final production system. Importing a project into the production system ensures data
consistency and guarantees that changes belonging to the same project are made consistently.
You can use transport management to manage changes in complex system landscapes that use a different
technological basis. CTS+, for example, allows you to manage non ABAP changes, such as Java or .NET.
Data consistency is a major topic across all ALM phases. Complex system landscapes and different activities in
multiple projects, which might be performed in parallel, require strict control and documentation. You can use the
concept of release management in combination with various functions in Change Request Management to do this.
After successfully deploying your change, it becomes part of the live IT landscape.
Operate Sub-Phase
Different IT services ensure that business operation is not disrupted or that impact is minimized when changes
need to be performed to the live landscape.
You have to manage any change during the Run phase in the same way you would manage a project. A request for
change defines the change, for example, as a hot fix or planned maintenance. You then assign this request for
change to a project. You use maintenance projects to manage changes. These act as a baseline for Change
Request Management support during the Run phase.
A request for change contains all of the information required to approve a change. When approval is given, you
use a change document to create any follow-up processes. You then use this as a basis for making the change. It
is important for you to define the type of change. The urgent change type is particularly important during this
phase. As all changes are managed like a project, you have to follow a project timeline. The urgent change process
allows you to create and transport one change into the production system. This means you can move an urgent fix
to the production system quickly and still follow and apply the Change Request Management guidelines.
Monitoring and reporting functions help to identify and manage requests for change. You can raise these requests
for change either directly or, more likely, as a follow-up process to an incident or service request made in ITSM.
3.3.4
Optimize
The optimize phase can be divided into the following sub-phases:
Analyze: Investigate and asses how well the change has dealt with any related problems.
Improve: Use this information to identify how changes could be better implemented in the future.
Analyze Sub-Phase
To verify the data consistency within the IT landscape, you can use transport analytics to analyze changes you
have already transported. This means that you can not only identify what has been transported using functions
like Change Request Management or Quality Gate Management but you can also identify changes that were not
transported to every system or changes that have been in a system for a long time. As any of these issues can
lead to inconsistencies between systems, you need to be aware of them.
The configuration validation function allows you to compare systems to ensure that they have, for example, the
same software component level or the same type of system setting. You can also compare which SAP Notes are
implemented in which system.
SAP Standard for Change Control Management
Table of Contents
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
37
Improve Sub-Phase
Once you have identified improvements, you can use them as requirements to start the cycle over again,
beginning with the plan phase. You can also use the optimize phase to upgrade your systems, implement new
software components, make changes to system settings, or add support packages.
3.4
Optimize
The following chapter provides a method for identifying and applying aspects of your current Change Request
Management implementation that could be improved. SAP Solution Manager provides features to help you do
this.
3.4.1
Method
An ideal method for implementing your Change Request Management is the Deming cycle. This is also called a
Plan–Do–Check–Act (PDCA) cycle. It is an iterative four-step management method used in business to check and
continuously improve processes and products.
The following table describes the aims of each step of the cycle:
Step
Aim
Plan
Prepare a project plan and a functional specification to
establish the objectives and processes necessary to
deliver results in accordance with the expected output.
Do
Execute the activities defined in the project plan and
functional specification, and implement Change
Request Management.
Check
Testing the implementation by executing your
prepared test cases. Study the results and compare
them to the expected results in the functional
specification.
Act
Make corrective actions, for example, bug-fixing,
where required, and highlight and eliminate significant
differences between the implementation and the
functional specification.
Adapt new requirements, if necessary.
After your Change Request Management implementation is complete, it reaches a level of stability called the
baseline. This stable working configuration is then the starting point for the next iteration of the cycle. Performing
the cycle a second time enables you to learn more about your implementation and make further improvements.
38
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
SAP Standard for Change Control Management
Table of Contents
Figure 6: Deming Cycle
You then consider the following activities when defining a starting point for the next plan phase:
Implementing SAP Notes
Implementing a new version of the central correction note
Updating to a new support package stack level
Implementing new features
Meeting new requirements
Automating manual activities
ITSM monitoring and reporting
3.4.2
Monitoring and Reporting
SAP Solution Manager offers various reporting and monitoring capabilities, which help you to improve your
change management processes.
3.4.2.1
Web UI Online Monitoring
The Web UI Online Monitoring enables you to create snapshots of current change management records. An end
user can define custom searches based on the concatenation of multiple parameters. These searches can be
stored for later usage and shared with a broad range of users. You can also export the results list as an Excel
spreadsheet and perform an advanced analysis of the data.
You can apply a variety of filters to your analysis. The following parameters are the most useful for improving
change management processes:
SAP Standard for Change Control Management
Table of Contents
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
39
Filter
Use
Category Text
Filtering by category can be a useful way of measuring
the effectiveness of your categories. If you find that
people are assigning categories to changes, then your
organization is using them effectively. If you find many
records with non-specific or no categories, you may
need to redefine your categorization schema. If users
are not using categories effectively, it is more difficult
and less beneficial to process new documents and
search for previous solutions
Ratio of Normal and Emergency Changes
Filtering by ratios of changes can be a useful way of
measuring the effectiveness of your application as a
whole. A large number of emergency changes implies
that your change management team has to continually
apply quick changes in order to restore working
systems. If you find that there are more emergency
changes, you need to make appropriate adjustments
to ensure that downtime is minimized.
These two categories are examples and you can use many filters to come to a range of conclusions. However,
further investigation is often required to get to the root of the issue.
Note
Concatenating multiple filter criteria provides valuable information for your specific scenario.
3.4.2.2
ITSM Business Warehouse Reporting
You use ITSM BW Reporting to analyze historical data. The responsible analyst can select any period of time for
reporting purposes. You can export the results in form of an Excel spreadsheet and perform an advanced analysis
of the data.
With ITSM BW Reporting, you can track the following KPIs:
Average processing time
Time recording analysis
Workload
Total amount
New documents
Status iteration analysis
40
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
SAP Standard for Change Control Management
Table of Contents
Figure 7: Historical Data Analysis with BW Reporting
SAP Standard for Change Control Management
Table of Contents
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
41
4
Driving Continuous Improvement
4.1
Quality Assurance Tasks
You need to have a defined quality assurance procedure to make sure that you can continually improve your
solution. When developing your procedure, consider the following tasks:
Track the number of closed changes (periodically), changes executed as planned, and the number of failed
transports
Track Change Advisory Board (CAB) approval trends
Ensure transport requests can be mapped to change requests
Review the quality of change process, including, documentation, and the success of Incident Management
and Transport Management integration
Ensure the documentation, including the Operations Handbook, is updated following changes
Analyze emergency changes to assess their urgency
Determine the risk of emergency changes (sharpen Business awareness)
Select suitable test cases (Change Impact Analysis)
Include business-related operations personnel in test execution and signoff
Report on management decisions to skip quality gates (correlate with occurring issues)
4.2
Quality Targets and KPIs
To assess the quality of the Change Control Management process, you need to set clearly-defined parameters
and measurable objectives. Key parameters should be collated and evaluated with regular reporting. The
historical data that is created in this way can be used to identify trends and develop ways to improve your
application.
The following targets are important to ensure the maturity of your control management process and drive value
recognition:
Speed up responsiveness to business requirements
Improve transparency and auditability for business compliance
Reduce poorly controlled emergency changes to increase business continuity
Reduce change-related effort by automating tasks and improving performance
The following table describes the main challenges for each of these quality targets and which KPIs can be used to
measure them:
Target
Speed up responsiveness to
business requirements
42
Challenges
Speed up change request
procedure
Ensure sufficient information is
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
KPIs
Average time spent for
approval (classified by
priorities)
SAP Standard for Change Control Management
Table of Contents
Target
Challenges
KPIs
provided
Improved transparency and
auditability for compliance
Increased business continuity by
improving emergency changes
Reduced effort by automation and
better performance
SAP Standard for Change Control Management
Table of Contents
Number of delayed change
approvals per quarter
(classified by priorities)
Percentage of requests for
change confirmed or accepted
by your organization
Average time from request for
change to implementation
(classified by priorities)
Number of routing activities
between your organization and
the IT department before
requests for change are
accepted
Percentage of unauthorized
implemented changes
Percentage of implemented
changes without impact
analysis
Number of incidents related to
transport errors, for example,
missing transports or
sequence errors
Trend measured by time and
effort for audit preparation
Trend in numbers, for re-work
items due to objections raised
by auditor
Percentage of changes that
cause incidents
Number of emergency changes
Percentage of unplanned
outage or unavailability due to
changes
Effort for testing measured in
percentage. Effort should
decrease, while the number of
changes should be reduced.
Predict the impact of business
requests on systems
Make legal and regulatory
requirements transparent and
auditable
Set up Change Control
Management processes and a
central overview of processes,
approvals and dependencies
appropriately
Synchronizing and checking
changes across platforms
based on different types of
technology
Ensure that changes do not
conflict with each other in
projects of maintenance
activities
Avoid disrupting ongoing
business
Reduce the number of
emergency and failed changes
Deal with high manual effort
when transporting to ABAP or
a Java stack
Apply expert knowledge
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
43
Target
Challenges
44
Test systems manually and
thoroughly
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
KPIs
Costs for change adoption in
percentage.
Trend in time spent for error
analysis and production down
situations
FTE involvement in transports
Percentage of unplanned
outage/unavailability due to
changes
Percentage of effort to
administer
SAP Standard for Change Control Management
Table of Contents
5
Training
For implementing Change Control Management, SAP offers the following training courses:
E2E200 – E2E Change Control Management
This course covers the following topics:
Solution Documentation:
o Introduction of System/Solution and Business Process Documentation in SAP Solution Manager
Change and Transport System:
o SAP NetWeaver development environments
o Transport of Non-ABAP objects via Enhanced Change and Transport System
Reporting and Analysis Tools/CTS Analytics
o CDMC CTS Analysis for Risk Mitigation of transporting of new custom code before go-live
o Impact analysis with the business process change analyzer and reporting on current system
configuration
o Configuration validation to compare multiple systems and using Transport Execution Analysis Self
Service
o Control Dashboard to control recent changes
Software Change Strategies:
o SAP best practices for transport landscape topologies and release strategies
o Transport Management with SAP Solution Manager:
o Project usage in SAP Solution Manager for Transports
o Cross system object lock functionality
o Retrofit
Quality Gate Management:
o Administration and grouping of transport requests into logical units
o Controlling the quality of an implementation project at certain quality gates.
Change Request Management:
o Approval process including demand consolidation, prioritization, categorization and scheduling of
changes
o Tool based workflow for the execution of change requests from development to production
Test Workbench Integration
o Maintenance Management
o Support packages and enhancement packages
o Use cases of Maintenance Optimizer and System Recommendations in SAP Solution Manager
SM200 – IT Service Management Configuration
This course covers the following topics:
Overview of Change Request Management and Application Incident Management
SAP Standard for Change Control Management
Table of Contents
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
45
Basic setup steps for Application Incident Management and Change Request Management
Master data
Projects in Change Request Management
The Application Incident Management process and its integration with Change Request Management
The Change Request Management processes
Monitoring
Customizing IT Service Management
5.1
Expert Guided Implementation Sessions
For Enterprise Support Customers, SAP offers Expert Guided Implementation Sessions (EGI).
Expert Guided Implementation (EGI) sessions are a combination of remote training, live configuration, and ondemand expertise, which allow you to perform complex activities with the help of experienced SAP support
engineers. The instructor will demonstrate what to do step by step. Afterwards, you can perform the relevant
steps in your own version of SAP Solution Manager. If you have any questions, you can then contact an SAP
expert via phone or e-mail.
For Change Management the following EGIs are available:
CTS+ (4 days)
Quality Gate Management (4 days)
Change Request Management Basic (4 days)
Enhanced Change Request Management (3 days)
More information regarding the content of the EGIs and time schedule can be found at the EGI calendar at
http://www.service.sap.com/~sapidb/011000358700001780312008E
5.2
Setup Support by SAP
To assist customers in implementing the change processes, SAP offers MaxAttention, Safeguarding, and PSLE
customers the Rapid Deployment Solution service for change control management. This RDS service is divided
into four parts: basic setup, Retrofit setup, enhanced flexibility setup, and reporting and analysis empowering.
46
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
SAP Standard for Change Control Management
Table of Contents
Figure 17: Change Control Management Service Packages
For more information, see the ITSM Wiki Page at http://wiki.sdn.sap.com/wiki/display/SAPITSM.
SAP Standard for Change Control Management
Table of Contents
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
47
6
More Information
Documentation
Link
SAP Service Marketplace
https://support.sap.com/solutionmanager
Processes Change Control Management
SAP Help Portal
http://help.sap.com/solutionmanager71 Application
Help SAP Library Change Control Management
IT Service Management Wiki
http://wiki.sdn.sap.com/wiki/display/SAPITSM
Ramp-Up Knowledge Transfer
http://service.sap.com/rkt-solman
SAP Press
IT-Service-Management with SAP Solution Manager
available from https://www.sap-press.com/
48
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
SAP Standard for Change Control Management
Table of Contents
www.sap.com/contactsap
SAP Standard for Change Control Management
Error! Use the Home tab to apply SAP_Title1NoNumber to the text that you want to appear here.
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All
rights reserved.
50
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
No part of this publication may be reproduced or transmitted in any
form or for any purpose without the express permission of SAP SE
or an SAP affiliate company.
The information contained herein may be changed without prior
notice. Some software products marketed by SAP SE and its
distributors contain proprietary software components of other
software vendors. National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company
for informational purposes only, without representation or warranty
of any kind, and SAP or its affiliated companies shall not be liable for
errors or omissions with respect to the materials. The only
warranties for SAP or SAP affiliate company products and services
are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein
should be construed as constituting an additional warranty.
SAP and other SAP products and services mentioned herein as well
as their respective logos are trademarks or registered trademarks of
SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the
trademarks of their respective companies. Please see
www.sap.com/corporate-en/legal/copyright/index.epx for
additional trademark information and notices.
Material Number:
ding 1" \l \* MERGEFORMAT
SAP Standard for Change Control Management
More Information
CUSTOMER
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
51
