Matthias Friedrich, Torsten Sternberg
Change Request Management
with SAP
®
Solution Manager
Bonn
�
Boston
261_Book.indb 3 7/8/09 5:01:45 PM
5
Contents
Preface ....................................................................................................... 11
1 Introduction .............................................................................. 15
1.1 IT Change Management and the Information Technology
Infrastructure Library ................................................................... 15
1.1.1 Classication of IT Change Management ........................... 15
1.1.2 Denition of Concepts ...................................................... 18
1.1.3 Tasks of IT Change Management ....................................... 19
1.1.4 Success Factors for IT Change Management ...................... 20
1.2 SAP Solution Manager and the Information Technology
Infrastructure Library ................................................................... 20
1.2.1 SAP Solution Manager Functions ...................................... 21
1.2.2 Support of ITIL Practices Using SAP Solution Manager ...... 24
1.3 Change Request Management with SAP Solution Manager ......... 28
1.3.1 Change (Request) Workows ............................................ 29
1.3.2 Project Administration ...................................................... 30
1.3.3 Monitoring and Reporting ................................................ 31
1.4 Summary .................................................................................... 31
2 Architecture of Change Request Management ........................ 33
2.1 Elements of Change Request Management ................................. 33
2.2 Project Administration in SAP Solution Manager ......................... 35
2.2.1 Solution Manager Project Types ........................................ 35
2.2.2 SAP Solution Manager Projects in Change Request
Management .................................................................... 39
2.2.3 IMG Projects and CTS Projects .......................................... 41
2.2.4 Project Cycle and Task List ................................................ 45
2.2.5 cProjects .......................................................................... 50
2.3 Transaction Types/Workows ...................................................... 51
2.3.1 Service Desk Message ....................................................... 53
2.3.2 Change Request ............................................................... 54
2.3.3 Change Document ............................................................ 58
261_Book.indb 5 7/8/09 5:01:45 PM
6
ContentsContents
2.3.4 Normal Correction/Development Activity ......................... 59
2.3.5 Urgent Correction ............................................................. 64
2.3.6 Administration Message ................................................... 65
2.3.7 Test Message .................................................................... 66
2.3.8 Job Request ...................................................................... 67
2.3.9 Change Transactions for Projects ....................................... 67
2.4 Summary .................................................................................... 68
3 Conguration of Change Request Management ...................... 69
3.1 Preparation ................................................................................. 69
3.1.1 Organizational Questions ................................................. 69
3.1.2 Technical Questions .......................................................... 70
3.1.3 Prerequisites ..................................................................... 70
3.1.4 Available Documentation and Resources .......................... 71
3.2 Conguration of Change Request Management .......................... 72
3.2.1 Standard Conguration ..................................................... 73
3.2.2 Extended Conguration .................................................... 85
3.3 Dening Projects and Systems in Change Request
Management .............................................................................. 102
3.3.1 Dening Logical Components ........................................... 102
3.3.2 Creating a Solution Manager Project ................................. 107
3.3.3 Final Check ....................................................................... 108
3.4 Summary .................................................................................... 109
4 Use of Change Request Management ...................................... 111
4.1 Roles and Activities ..................................................................... 111
4.1.1 Requester ......................................................................... 112
4.1.2 Service Desk Employee ..................................................... 113
4.1.3 Change Manager .............................................................. 113
4.1.4 Change Advisory Board ..................................................... 114
4.1.5 Developer ........................................................................ 114
4.1.6 Tester ............................................................................... 115
4.1.7 IT Operator ...................................................................... 115
4.1.8 Additional User Information ............................................. 116
261_Book.indb 6 7/8/09 5:01:45 PM
7
ContentsContents
4.2 Processes and Integration Examples ............................................ 116
4.2.1 Example of the Urgent Correction ..................................... 117
4.2.2 Retrot Process ................................................................ 134
4.2.3 Hot News ......................................................................... 140
4.2.4 Structure Elements for Change Transactions ...................... 142
4.3 Administration ............................................................................ 148
4.3.1 Task List ........................................................................... 148
4.3.2 Extended Conguration .................................................... 162
4.3.3 Change Tracking ............................................................... 163
4.3.4 Scheduling ........................................................................ 166
4.3.5 Project Logistics ............................................................... 167
4.4 Reporting and Monitoring .......................................................... 169
4.4.1 Solution Manager Reporting ............................................. 169
4.4.2 Transaction Monitor ......................................................... 171
4.5 Work Centers .............................................................................. 175
4.5.1 Change Management Work Center ................................... 175
4.5.2 Conguration of Work Centers ......................................... 179
4.5.3 SAP GUI for HTML Conguration ..................................... 180
4.6 Summary .................................................................................... 181
5 Security in Change Request Management ............................... 183
5.1 Authorizations in the SAP System ............................................... 183
5.1.1 Authorizations in the SAP Solution Manager System ......... 183
5.1.2 Authorizations in Satellite Systems ................................... 184
5.1.3 Work Center ..................................................................... 185
5.1.4 Extended Authorization Checks ........................................ 185
5.2 Cross-System Object Lock ........................................................... 186
5.2.1 Functionality .................................................................... 186
5.2.2 Required Settings ............................................................. 189
5.3 Critical Transport Objects ............................................................ 191
5.3.1 Functionality .................................................................... 191
5.3.2 Required Settings ............................................................. 193
5.3.3 Modications ................................................................... 194
5.4 Project Intersections ................................................................... 195
5.4.1 Real-Life Example ............................................................. 196
5.4.2 Required Settings ............................................................. 197
5.5 Summary .................................................................................... 198
261_Book.indb 7 7/8/09 5:01:46 PM
8
ContentsContents
6 Extensions of the Change Request Management Scenario ..... 199
6.1 Extended Transport Landscapes .................................................. 199
6.1.1 Three-System Landscape ................................................... 199
6.1.2 Four-System Landscape .................................................... 201
6.1.3 Parallel Phase Landscape .................................................. 203
6.1.4 Landscapes for Global Developments ............................... 205
6.1.5 Conclusion ....................................................................... 206
6.2 Enhanced Transport Management ............................................... 206
6.2.1 Components ..................................................................... 208
6.2.2 TMS Conguration ........................................................... 210
6.2.3 Integration with Applications ........................................... 214
6.2.4 Landscape Scenarios ......................................................... 217
6.2.5 Integration of CTS+ and Change Request Management ..... 225
6.2.6 Conclusion ....................................................................... 227
6.3 Extension Developments and Development Package ................... 227
6.4 Customer-Specic Tab ................................................................. 228
6.4.1 Dening the Necessary Data Structures ............................ 228
6.4.2 Dening the Layout and Flow of the Dynpro .................... 232
6.4.3 Integrating the New Tab via the Screen Control ................ 235
6.4.4 Tabs in the Change Request .............................................. 236
6.4.5 Inserting the Calculation Logic .......................................... 237
6.5 Extension of the Transaction Monitor .......................................... 239
6.6 Extended Actions and Conditions ............................................... 241
6.6.1 Extended Check for Text IDs ............................................. 242
6.6.2 Extended Check for Partner Functions .............................. 247
6.6.3 Displaying Transport Requests .......................................... 251
6.7 Summary .................................................................................... 255
7 Change Management in SAP Landscapes ................................ 257
7.1 Change Management Concept .................................................... 257
7.1.1 Maintenance — Maintenance Optimizer .......................... 258
7.1.2 Technical Integration ........................................................ 260
7.1.3 Testing .............................................................................. 260
7.1.4 Analysis ............................................................................ 261
7.2 Quality Management in SAP Solution Manager ........................... 261
7.2.1 Functional Scope .............................................................. 261
261_Book.indb 8 7/8/09 5:01:46 PM
9
Contents
7.2.2 Prerequisites for Quality Gate Management ...................... 263
7.3 Summary .................................................................................... 265
8 Technical Notes on Usage and Troubleshooting ...................... 267
8.1 Adding New Systems .................................................................. 267
8.2 System and Client Copy .............................................................. 268
8.3 Setting Up a Project Landscape ................................................... 271
8.4 Repair Flag for the Import ........................................................... 274
8.5 Urgent Corrections in Parallel Systems ......................................... 275
8.6 Transports and SAP NetWeaver Business Warehouse ................... 276
8.6.1 Urgent Correction ............................................................. 276
8.6.2 Import All ......................................................................... 276
8.7 Import Subset and Import Project ............................................... 277
8.8 Error Analysis .............................................................................. 278
8.8.1 Application Log ................................................................ 280
8.8.2 Reports for Completing Project Cycles .............................. 280
8.8.3 Authorization Problems .................................................... 283
8.9 SAP Notes .................................................................................. 284
The Authors ............................................................................................... 285
Index ......................................................................................................... 287
261_Book.indb 9 7/8/09 5:01:46 PM
33
Architectu2 re of Change
Request Management
Change Request Management consists of a number of individual elements in SAP
Solution Manager. To appreciate the full functional scope of Change Request Man-
agement, you therefore need to understand these elements and how they work.
This chapter explains the various functional areas within Change Request Manage-
ment and provides an initial insight into how Change Request Management ts
into SAP Solution Manager.
Elements of Change Request Management2.1
Change Request Management represents a core functional area within SAP Solu-
tion Manager. SAP Solution Manager provides a range of functions, information,
and services to support the entire lifecycle of an application. Figure 2.1 shows the
stages of this lifecycle and the corresponding functions for each of these stages that
are provided in SAP Solution Manager.
Core
Business
Processes
I
m
p
l
e
m
e
n
t
a
t
i
o
n
O
p
t
i
m
i
z
a
t
i
o
n
O
p
e
r
a
t
i
o
n
s
Change Request
Management
Follows ITIL Standards
Maintenance Processes
Service Desk
Best Practices
for Incident Management
Integration of 3rd-Party
Help Desks
Solution Monitoring
System Monitoring
Business Process Monitoring
Central System Administration
EarlyWatch Alert
Service Level Reporting
Solution Reporting
Upgrade of
SAP Solutions
SAP Methods
and T o ols
E-Learning
Management
Te st Management
Implementation of
SAP Solutions
SAP Methods and To ols
Global Rollout
Customizing Synchronization
E-Learning Management
Te st Management
Delivery of
SAP Services
Onsite/Remote
SAP Safeguarding
Solution Manager
Diagnostics
Safe Remote Access
Performance Measurements
Logs and Dumps
Tr aces
Te chnical Configuration
Change Request Management in SAP Solution ManagerFigure 2.1
261_Book.indb 33 7/8/09 5:01:50 PM
34
ArchitectureofChangeRequestManagement
2
Change Request Management is assigned to the optimization cycle. Within this
cycle, required changes that have been detected during normal system operation (for
example, corrections of program errors) are implemented, documented, and moni-
tored. The elements of Change Request Management are illustrated in Figure 2.2.
Project Administration Business Blueprint
Configuration
Te sting
System Landscape
Maintenance
SAP Change Manager
Service Desk Change Request Management
Tr ansport Management System
SN
cProjects
CR
CD
SAP Solution Manager
Project
cProject
DEV
IMG Project
CTS Project
Ta sk List
System and
Tr ansport
Configuration
Tr ansport
Tr acking
PRD
CTS Project
QAS
CTS Project
System Landscape
Te st Cases
Documentation
Tr aining
SAP Solution Manager
Elements of Change Request ManagementFigure 2.2
Project Administration
allows you to structure and classify change activities and
the associated technical changes. These technical changes result in transport
requests, which are distributed within the system landscape using the Trans-
port Management System. Information about the systems or system groups
that require support is also maintained in Project Administration.
System Landscape Maintenance provides information about the systems that
are to be supported. The systems are dened, connections congured, and vari-
ous systems grouped together in logical components as part of System Land-
scape Maintenance (see Section 3.3.1, Dening Logical Components).
In Figure 2.2, the SAP Change Manager box represents the functions specic to
Change Request Management. These include the task list and the various trans-
port tracking options.
261_Book.indb 34 7/8/09 5:01:50 PM
35
ProjectAdministrationinSAPSolutionManager
2.2
The Change Request Management box represents the two main subprocesses
that make up Change Request Management. The change request and the change
document each describes an organizational and technical subarea within a
change. Together, they represent the complete change request process.
The next section provides a detailed description of all of these areas and how they
work.
Project Administration in SAP Solution Manager2.2
Various project types are delivered as standard with SAP Solution Manager. These
serve project-related objectives in a range of scenarios, for example, implementa-
tion, upgrade, or Change Request Management for project organization, documen-
tation, and control.
Solution Manager Project Types2.2.1
The project types available in SAP Solution Manager are listed below:
Implementation project
This project type is used to implement new business processes in an SAP land-
scape with SAP Solution Manager. Detailed information about a process can
be mapped in the form of a project structure within the project. This infor-
mation includes process steps, documentation, test cases, and conguration/
customizing.
Maintenance project
This project type is used to maintain live solutions and is used predominantly
in Change Request Management. All maintenance activities for a solution are
grouped together in this project type. If the use of check-in/check-out functions
is enabled in the Solution Directory, where all live processes are documented,
maintenance projects are used there also.
Template project
The structures of a project can be dened in a template project and then made
available to other projects as templates. This means that you can dene pro-
cesses, process steps, documentation, or test cases, and then use these as a
template for an enterprise-wide rollout. It is also possible to specify in the con-
guration that selected areas cannot be modied.
261_Book.indb 35 7/8/09 5:01:50 PM
36
ArchitectureofChangeRequestManagement
2
Check-In /Check-Out Functions
Check-in/check-out functions allow you to transfer a live business process from the So-
lution Directory to a maintenance project without any effect on the active process. After
check-out, changes can be made to the business process in the maintenance project.
For example, new process steps can be de ned. You then use the check-in function to
transfer the changed business process back to the Solution Directory.
Upgrade project
Con guration settings required as part of an upgrade are made in an upgrade
project.
Safeguarding project
Safeguarding projects are used to analyze and subsequently eliminate the causes
of critical situations.
Optimization project
An optimization project enhances business processes or the general operation
of a solution. One possible area of application for these projects arises in the
context of SAP Services.
Projects can be created quickly using a web-based wizard, which you can access
with Transaction AI_SPS. This wizard is shown in Figure 2.3. Experienced users
can also access Project Administration directly, which is brie y outlined below.
Quick Project SetupFigure 2.3
261_Book.indb 36 7/8/09 5:01:51 PM
37
ProjectAdministrationinSAPSolutionManager
2.2
Transaction SOLAR_PROJECT_ADMIN provides access to central Project
Administration .
All existing projects in SAP Solution Manag1. er are displayed on the initial screen,
which is shown in Figure 2.4. You can also click on the Create Project button to
create new projects or navigate to project analysis.
Project Administration in SAP Solution ManagerFigure 2.4
If you double-click on a project to select it, a detailed view of that project 2.
opens. Here you can maintain various types of information that are of relevance
to the project. A range of tabs is provided for this purpose, the rst of which
is entitled General Data. A number of required entries need to be maintained
on this tab, including Project Language and Project Description. Other informa-
tion, such as status values and time values, are optional.
The other tabs, Scope, Proj. Team Member, Milestones, System Landscape, and 3.
Project Standards, contain various types of information that are not discussed
in more depth at this point because, with the exception of the information on
the System Landscape tab, these are not essential to Change Request Manage-
ment (see Figure 2.5).
You de ne the systems for a project on the System Landscape tab. Here you can
choose a logical component in order to select the systems belonging to an SAP
product and assign these to the project.
You de ne a logical component in System Landscape Maintenance4. (Transac-
tion SMSY), where you combine logical systems in logical components that can
then be used in various scenarios, such as implementation, testing, or Change
Request Management (see Section 3.3.1, De ning Logical Components).
261_Book.indb 37 7/8/09 5:01:51 PM
38
ArchitectureofChangeRequestManagement
2
Detailed Information About a Solution Manager ProjectFigure 2.5
Figure 2.6 shows an example of a logical component, ZCHARM_LANDSCAPE,
together with its assigned logical systems ST4:200, ST4:300, and ST4:400. The
name of each logical system consists of the system ID and client. Here, the logical
systems are the three clients of an SAP Solution Manager system that represent a
three-system landscape. This con guration is often used during the initial setup of
Change Request Management to verify locally that the setup is correct. It allows
you to test all functions of Change Request Management, including change trans-
ports. Only the transport of Workbench objects cannot be simulated, owing to the
cross-client validity of these objects.
Before we discuss the additional con guration options and information about the
System Landscape tab in more detail, we will brie y explain, in the next section,
the fundamentals of the Change Request Management architecture . This section
describes other types of projects in addition to the Solution Manager projects
speci ed above. We will then return to the topic of Project Administration in the
following sections.
261_Book.indb 38 7/8/09 5:01:52 PM
39
ProjectAdministrationinSAPSolutionManager
2.2
System Landscape — Project AdministrationFigure 2.6
SAP Solution Manager Projects in Change Request 2.2.2
Management
As mentioned above, Solution Manager projects provide a basis for various scenarios
in SAP Solution Manager. Four of the project typ es described in Section 2.2.1, Solution
Manager Project Types, can be used in the Change Request Management scenario; namely
maintenance project, implementation project, template project, and upgrade project.
However, some further classi cations are required from the perspective of Change
Request Management. A distinction is made among the four project types based
on whether they are executed cyclically (recurring) or once only (nonrecurring).
As shown in Figure 2.7, a maintenance project is de ned as recurring because it is
always started again after it has been successfully completed. Implementation proj-
ects, template projects, and upgrade projects, on the other hand, are nonrecurring.
There is normally only a single project start and end date for these projects.
Recurring
Implementation
Project
Te mplate
Project
Upgrade
Project
Maintenance
Project
Non-Recurring
Recurring and Nonrecurring ProjectsFigure 2.7
261_Book.indb 39 7/8/09 5:01:53 PM
40
ArchitectureofChangeRequestManagement
2
The reasoning behind this distinction has to do with the associated functional
requirements of Change Request Management. A maintenance project involves
maintaining processes or functions that are already used in production. The situa-
tion is different in projects of a nonrecurring nature, such as implementation proj-
ects. In this case, a new process or function is implemented for the rst time and
is only used in production after the project has been successfully completed. This
fundamental difference gives rise to different functional requirements, which are
discussed in more detail in Section 2.2.4, Project Cycle and Task List.
Solution Manager projects are a prerequisite for using Change Request Manage-
ment. You create and manage these projects in SAP Solution Manager. However,
additional project functions are used in the managed systems and linked to the
Solution Manager project to facilitate the monitoring of changes in these systems.
The project functions used are the IMG (Implementation Guide) project and the
CTS (Change and Transport System) project, which are discussed in more detail
in Section 2.2.3, IMG Projects and CTS Projects. Both project functions are Basis
functions and are therefore available in SAP NetWeaver or SAP Basis.
If you activate Change Request Management for a Solution Manager project (see
Section 3.3.2, Creating a Solution Manager Project), an IMG project is generated
automatically in the development system (of the logical component), and the infor-
mation in the Solution Manager project is stored there. If several logical compo-
nents are assigned to a Solution Manager project, an IMG project is created in each
development system dened.
With IMG projects, you also have the option of creating a direct link to CTS proj-
ects. This option, in turn, allows you to assign all changes and therefore also all
transport requests from CTS projects to the IMG project. Figure 2.8 illustrates the
interaction between the various projects and the associated systems. Other func-
tions in SAP Solution Manager are shown here alongside the projects described
above; namely, the project cycle and task list, as well as the optional connection
to cProjects, a project management solution.
A detailed explanation of IMG and CTS projects is provided below, followed by a
discussion of the functions that are fullled by the project cycle and task list. The
section concludes by examining the option of integrating cProjects into Change
Request Management.
261_Book.indb 40 7/8/09 5:01:53 PM
41
ProjectAdministrationinSAPSolutionManager
2.2
Project
(Created in
cProjects)
SAP Solution Manager
Project Cycle
Change
Tr ansaction
cProjects
Project Cycle
Ta sk List
IMG
Project
IMG
Project
Development
System
CTS
Project
Logical System
(System and
Client)
CTS
Project
Tr ansport
Requests
Q
Q P
P
D
D
Solution
Manager
Project
Architecture of Change Request ManagementFigure 2.8
IMG Projects and CTS Projects2.2.3
As explained above, IMG and CTS projects represent Basis functions and are there-
fore available in any SAP NetWeaver system.
IMG (Implementation Guide
) projects allow you to coordinate customizing
activities and save the resulting changes in a project.
CTS (Change and Transport System
) projects are parameters that can be used to
group transport requests. CTS project functions for the project in question can
be activated in an IMG project.
In SAP Solution Manager, you can link Solution Manager projects with IMG proj-
ects to access the systems in the IMG projects. The option of assigning a CTS project
to an IMG project means that the relevant information about transport requests can
also be used in an IMG project and, ultimately, in the Solution Manager project.
Figure 2.9 shows a Solution Manager project of the maintenance project type. The
System Landscape tab shows several subcategories (you will recognize the Systems
tab from Figure 2.6).
261_Book.indb 41 7/8/09 5:01:54 PM
42
ArchitectureofChangeRequestManagement
2
Maintenance Project with Assigned IMG ProjectFigure 2.9
If you select the IMG Projects tab, the assigned IMG project (CHARM01) is 1.
shown. Logical system ST4:200 is assigned to this IMG project . This corre-
sponds to the development system of the demo landscape, which consists of
the logical systems ST4:200 (development), ST4:300 (quality assurance), and
ST4:400 (production).
If you select the IMG project and click on the Display button, you automatically 2.
access the IMG project view in the corresponding development system. Figure
2.10 shows the detail view of the IMG project in the development system.
IMG Project in the Development SystemFigure 2.10
261_Book.indb 42 7/8/09 5:01:55 PM
43
ProjectAdministrationinSAPSolutionManager
2.2
The structure and display of the IMG project are very similar to those of the
Solution Manager project. The only indications that this is a different project
type are the type description Customizing Project at the top of the screen and
the number of tabs.
Next, select the Transp. Requests tab, which is shown in Figure 2.11.3.
Selecting the Transp. Requests Tab in an IMG ProjectFigure 2.11
The Transp. Requests tab shows information about CTS functions. From here,
you can also access information about the project data of the CTS project and
information about the transport requests assigned to the CTS project (see Figure
2.12).
If you click on the Display CTS project data button, the screen shown in Figure 4.
2.13 is displayed. Here you can see the CHARM01 IMG project and the corre-
sponding ST4_P00001 CTS proje ct. The other buttons, Assigned CTS Requests
and CTS Project Piece List (see Figure 2.12), also display relevant information
about transports.
261_Book.indb 43 7/8/09 5:01:55 PM
44
ArchitectureofChangeRequestManagement
2
The Transp. Requests Tab in an IMG ProjectFigure 2.12
CTS Project DataFigure 2.13
The nal screen element to describe in relation to CTS projects is the project 5.
status switches . The project status switches for CTS projects allow you to acti-
vate or deactivate various properties for the CTS project and for the correspond-
ing transport requests. Figure 2.14 shows the project status switches for a CTS
261_Book.indb 44 7/8/09 5:01:56 PM
45
ProjectAdministrationinSAPSolutionManager
2.2
project. Of particular relevance here are the switches for creating, releasing,
and importing transport requests.
Project Status Switches of a CTS ProjectFigure 2.14
If Change Request Management6. is active, it controls and monitors these
switches. This means you can prevent the creation of transport requests in the
supported systems for change activities that are not part of Change Request
Management.
You will  nd detailed information about con guration, in particular in relation
to the mandatory assignment of requests to projects, in De ne Project Assign-
ment for Requests as Mandatory in Section 3.2.1.
Now that you are familiar with the various project types and how they interact in
Change Request Management, an introduction to the project cycle, task list, and
integration of cProjects is provided below.
Project Cycle and Task List2.2.4
Up to this point, we have described functions used by Change Request Manage-
ment to gather information about changes in managed systems. To use this infor-
mation for a wide range of operational activities, such as the distribution of trans-
ports, a functional basis for the execution of these activities is required.
261_Book.indb 45 7/8/09 5:01:57 PM
46
ArchitectureofChangeRequestManagement
2
In Change Request Management, this basis is provided by the scheduling tool,
which is based on the familiar Schedule Manager function for executing and moni-
toring recurring tasks. In Change Request Management, the Schedule Manager
allows you to execute a variety of operational tasks, including the import of trans-
ports into target systems and the creation and release of new transport requests.
This scheduling tool also allows you to control the lifecycle of a Solution Manager
project.
All projects have a certain lifecycle, referred to as the project cycle. There is always
a 1:1 relationship between a project and project cycle, which is, in turn, divided
into a number of phases. These phases reect the individual steps involved in a
project, such as the development phase and test phase. The scheduling tool maps
project phases and the functions required during each of these.
The possible phase values for a cycle, which are identical in all projects, are as
follows: Created, Development without Release, Development with Release, Test,
Emergency Correction, Go-Live, To be Closed, and Completed.
The phase values that are relevant for daily system operation are Development
without release, Development with Release, Test, Emergency Correction, and Go-
Live. Various activities are executed within these phases over the course of a proj-
ect. Figure 2.15 shows the interaction between a project, project cycle, and the
individual phases with the corresponding changes.
Development
Activity
Synchronization
Project Cycle
Synchronization
Synchronization
Test
Go-Live
Emergency
Correction
cProjects
SAP Solution Manager Project (e.g. Implementation Project)
Development
(without and
with Release)
Implementation Project, Project Cycle, and ChangesFigure 2.15
261_Book.indb 46 7/8/09 5:01:57 PM
47
ProjectAdministrationinSAPSolutionManager
2.2
From a technical perspective, the project cycle, as shown in Figure 2.16, is repre-
sented by a generated task list (Schedule Manager) and a change transaction (CRM
document). The task list contains a list of activities and a representation of the sys-
tems supported within the project cycle, and it indicates the current phase of the
project cycle. The task list is part of the working environment of the IT operator.
The change transaction allows you to move from one project phase to the next
and provides information about the transport requests belonging to the project.
For more detailed information about the task list, see Section 4.3, Administration.
Figure 2.17 shows an example of a task list.
Project Cy cle
Change
T r ansaction
T a sk List
Project Cycle of a Solution Manager ProjectFigure 2.16
Task List in Change Request ManagementFigure 2.17
261_Book.indb 47 7/8/09 5:01:58 PM
48
ArchitectureofChangeRequestManagement
2
The project cycle shown in Figure 2.16 could apply to an implementation project,
template project, or upgrade project. It is useful to recall, at this point, the differ-
ence among these project types and maintenance projects (see Figure 2.7).
Maintenance projects also have their own project lifecycle. However, in this case,
it is referred to as the maintenance cycle. For example, a permanent maintenance
project for a live solution may be divided into maintenance cycles of three months
each. All necessary support and maintenance tasks are executed within these
maintenance cycles. These include, most importantly, development and testing
of corrections.
These activities are divided into phases within each three-month maintenance
cycle. For example, each cycle includes a development phase and a test phase. At
the end of the three months, the maintenance cycle has reached the nal phase
and all of the changes from the cycle as a whole are imported into the production
system. The maintenance cycle can be completed after a successful import into
the production system, and a new maintenance cycle can then be generated to
manage all changes that arise over the next three months. This continuous cycle
is illustrated in Figure 2.18.
Change
Tr ansaction
Ta sk List
Maintenance Project
Maintenance Cycle
with Phases
Maintenance Project and Maintenance CycleFigure 2.18
Maintenance projects differ from other project types in one important respect.
Within a maintenance cycle, it may be necessary to import an important change or
correction into the production system as quickly as possible. In this case, the three-
month cycle is too long. A special change transaction is therefore provided for this
very typical scenario. This change transaction is referred to as an
Urgent Correction.
261_Book.indb 48 7/8/09 5:01:59 PM
49
ProjectAdministrationinSAPSolutionManager
2.2
This change transaction is only available in maintenance projects, and enables an
immediate transport of changes into the production system, independent of the
phases in the maintenance cycle. This special feature of maintenance projects sets
them apart from other project types. For a detailed description of urgent correc-
tions, refer to Section 2.3.5, Urgent Correction.
Figure 2.19 illustrates the various change types in a maintenance project. Here,
once again, you can see the interaction between the maintenance project, main-
tenance cycle, and corresponding phases. This gure also indicates the phases in
which normal corrections and urgent corrections can be made and executed within
the maintenance cycle.
As you can see, normal corrections for a maintenance cycle are only possible
during the development phases (development with and without release). During
subsequent phases, normal corrections can only be transported into the quality
assurance system and, from there, into the production system. Urgent corrections,
on the other hand, can be created up until shortly before the go-live to ensure their
integration into the same maintenance cycle.
Urgent
Correction
(Independent of Maintenance Cycle)
Normal
Correction
Synchronization
Maintenance Cycle
Synchronization
Synchronization
Development
(without/with Release)
Test
Go-Live
Emergency
Correction
cProjects
SAP Solution Manager Project (Maintenance Project)
Maintenance Project, Maintenance Cycle, and TransactionsFigure 2.19
261_Book.indb 49 7/8/09 5:01:59 PM
50
ArchitectureofChangeRequestManagement
2
As explained in the detailed discussion of normal corrections later in this chapter
(see Section 2.3.4, Normal Correction/Development Activity), you can also create
a normal correction after the development phases. However, these will then be
part of the next maintenance cycle.
cProjects2.2.5
Integration of the Collaboration Projects (cProjects) solution for project manage-
ment into Change Request Management represents an optional enhancement. This
integration establishes a 1:1 link between a cProjects project and a Solution Man-
ager project, so that the Change Request Management process benets from the
advanced project management functions in the cProjects project. You can then use
a range of functions (such as phase-based project management); dene milestones,
roles, and deliverables; and display projects in graphical form as Gantt charts.
It is also important to point out exactly how cProjects and Change Request Man-
agement interact. If a cProjects project is assigned to a Solution Manager project,
the cProjects project has the same phase values as the corresponding Solution
Manager project. The following phase values are relevant in this case: Develop-
ment without Release, Development with Release, Test, Emergency Correction,
Go-Live, and To be Closed.
If a new phase is selected during the Solution Manager project cycle — for exam-
ple, if the phase changes from Development with Release to Test — a consistency
check is run against the cProjects project to verify the phase value is also Test in
that project. If not, a warning is issued in the task list, indicating an inconsistency
with the cProjects project. The correct phase value must then be set in the cProjects
project before it can be set in the task list or change transaction. This means that
cProjects plays a leading role in terms of project organization. It therefore provides
an effective working environment for project leads (see Figure 2.20).
Before you can integrate cProjects, you require a Solution Manager project with
Change Request Management activated. In addition, a task list must have been
generated for the project.
261_Book.indb 50 7/8/09 5:01:59 PM
51
TransactionTypes/Workows
2.3
cProjects with Maintenance ProjectFigure 2.20
Transaction Types/Workflows2.3
In Change Request Management, various work ows are provided to ful ll diverse
process requirements. These work ows are not to be confused with SAP Business
Work ows. The relevant work ows were introduced in Section 1.3.1, Change
(Request) Work ows. Here, we explain various work ows that are used either
directly or indirectly in Change Request Management.
From a technical point of view, all of these work ows represent various transac-
tion types created in the CRM service process transaction (CRMD_ORDER). Trans-
action types are documents created in the CRM service process transaction. They
can be used to represent a de ned process ow, provided that the relevant Cus-
tomizing settings are con gured. The transactions can be opened and edited in the
service process transaction.
261_Book.indb 51 7/8/09 5:02:00 PM
52
ArchitectureofChangeRequestManagement
2
Various transaction types (such as Service Desk messages or change requests) can
be linked together to unite different processes. You can display these links by
checking the document ow in Transaction CRMD_ORDER, for example. Links
between transaction types can be set by default or dened by the user in a selec-
tion eld. In this way, follow-up documents and processes can be linked on the
basis of the values in the selection eld in the original document. Figure 2.21
shows the possible links.
Change Process
Service
Desk
Message
Change
Request
Urgent
Correction
Normal
Correction
Administration
T e st Message
Transactions in Change Request ManagementFigure 2.21
The Service Desk message is not part of Change Request Management, but it often
initiates actions in Change Request Management. The Service Desk is another
functional area in SAP Solution Manager, which is used in the context of Incident
Management. In a Service Desk message, you have the option of creating a linked
change request. This option also represents an intersection with Change Request
Management because the change request is the source document for all subse-
quent activities in Change Request Management.
The change request may give rise to various follow-up transactions. These transac-
tions are mapped by default by urgent corrections, normal corrections, and the
administration message. Test messages represent a special case because they are
issued without a change request.
Information about the people and systems involved is stored in each transaction.
This information is stored as master data, which must be maintained in SAP Solu-
tion Manager. Business partners need to be maintained for the people involved,
whereas information must be maintained in the installed base (IBase) for the sup-
ported systems. For more detailed information about conguring Change Request
Management, refer to Section 4.1.3, Change Manager.
261_Book.indb 52 7/8/09 5:02:00 PM
53
TransactionTypes/Workows
2.3
Service Desk Message2.3.1
The default SAP transaction type for the Service Desk message , which has the tech-
nical name SLFN, represents a separate functional area in SAP Solution Manager.
Service Desk functionality allows you to create problem messages in SAP Solution
Manager directly or in a connected satellite system. This gives the end user the
option of reporting errors or problems and storing this information centrally in SAP
Solution Manager, where it can then be processed by the service organization.
A web-based interface (the Work Center ) allows end users to check the current
status of their Service Desk messages at any time and to respond as appropriate.
An example of a Work Center is provided in Figure 2.22. Service Desk functions
include an option for switching among various organizational units, access to a
separate solution database, a search function for nding SAP Notes, and a direct
exchange with the SAP support organization . One advantage of using Service Desk
functionality is the possibility of creating an SAP customer message for SAP from
your own Service Desk. The reply from SAP is also replicated directly to the Service
Desk in SAP Solution Manager and can be processed further there.
Work Center for Incident ManagementFigure 2.22
261_Book.indb 53 7/8/09 5:02:01 PM
54
ArchitectureofChangeRequestManagement
2
If the analysis performed within the Service Desk indicates that corrective action
is required, the Service Desk employee can create a change request from the Ser-
vice Desk message. Figure 2.23 shows how a change request can be created from
a Service Desk message in the service process transaction CRMD_ORDER.
Here you can call various functions from the action list . A change request can be
created directly with the Create Change Document action.
Note
The use of the term change document in this action is somewhat confusing because the
action creates a change request. As we will see later, this change request subsequently
results in a change document.
Creating a Change Request from a Service Desk MessageFigure 2.23
Change Request2.3.2
A change request , which is referred to by the technical name SDCR in Customiz-
ing, represents the  rst subprocess of Change Request Management . Its main role
is to document the request and all associated information, which can be classi ed
as required or optional.
261_Book.indb 54 7/8/09 5:02:02 PM
55
TransactionTypes/Workows
2.3
Some information is essential to ensure that no errors occur during further pro-
cessing of the request in Change Request Management. This required informa-
tion includes a description of the request in the text eld provided, and informa-
tion about the systems and users affected (for example, the change manager). A
change type must also be selected. This speci es the transaction that is to be used
to implement the change. Here, you can choose between a normal correction and
an administration message . In the case of maintenance projects, you also have the
option of implementing an urgent correction .
The optional information that can be speci ed in the change request includes
dates, additional user information, categorizations, and additional textual informa-
tion, such as a description of the effects on business processes or systems. You can
also attach documents to the request.
The purpose of the change request is to have a change approved or rejected. A sta-
tus pro le is provided to identify the various steps from the creation of a request to
the  nal decision regarding the change. This status pro le contains various status
values, which are displayed in the change request as the user status . Figure 2.24
shows an extract from the service process transaction (CRMD_ORDER), which
includes the user status.
User Status in a Change RequestFigure 2.24
The standard process delivered by SAP contains the following status values : To Be
Approved, Rejected, Approved, Implemented, and Con rmed.
261_Book.indb 55 7/8/09 5:02:02 PM
56
ArchitectureofChangeRequestManagement
2
If these status values cannot adequately map your change request process, the
relevant status pro le can easily be supplemented or modi ed. Customers tend to
have their own speci c process for handling a change request . In many cases, vari-
ous departments or partners need to be involved to ensure that a sound decision
can be made regarding the implementation or rejection of the change at the end
of the change request process.
Tip: Changing the Status Pro le
Do not change the standard SAP status pro le. Instead, copy the status pro le (SDCR-
HEAD) to the customer namespace. Make any necessary changes in the copied pro le
and then assign the new status pro le (for example, ZDCRHEAD) to transaction type
SDCR.
The
SOLMAN_CM_GENERAL IMG activity similarly advises you to always use an SAP pro le
as a template if you want to de ne your own pro le.
To conclude this section, we need to look again at the transaction type that must
be speci ed in the change request. As stated above, the selection of a transaction
type represents a required entry in a change request. If you fail to enter required
information or if you enter information incorrectly, a red traf c-light icon appears
in the top right of the screen in the service process transaction . You can click on
this icon to display a description of the error. Figure 2.25 shows an example of an
error message text that was issued because a transaction type was not speci ed in
the change request.
Error Message in the Change RequestFigure 2.25
The change type is speci ed in the Subject eld, where you can select from all
available change types. We have already introduced you to these change types at
the start of Section 2.3, Transaction Types/Work ows. In other words, the change
types correspond to the transaction types Normal Correct ion, Urgent Correc tion,
and Administra tion. For implementation projects, template projects, and upgrade
261_Book.indb 56 7/8/09 5:02:03 PM
57
TransactionTypes/Workows
2.3
projects, the term normal correction is replaced by the term development or develop-
ment activity
. This change is made only for the purpose of greater clarity because
these projects result in new developments rather than corrections. From a techni-
cal perspective, this corresponds to the Normal Correction transaction type (see
Section 2.3.4, Normal Correction/Development Activity).
To summarize, the following change types are available:
Implementation project
, template project , upgrade project
Development/Development Activity
Administration
Maintenance project
Normal Correction
Urgent Correction
Administration
The selection menu for change types is shown in Figure 2.26.
The Subject Field in a Change RequestFigure 2.26
Once all of the required information has been entered in the change request, an
action to reject or authorize the request can be executed. When you select one
of these actions in the action list of the change request, the status value is set
261_Book.indb 57 7/8/09 5:02:03 PM
58
ArchitectureofChangeRequestManagement
2
accordingly. Figure 2.27 shows the action lis t for authorizing or rejecting a change
request.
Authorizing a Change RequestFigure 2.27
If the change request is rejected, the user status Rejected is set automatically and
the document is closed. No further changes can be made to the document as of this
point. If the change request is authorized, the user status is set to Approved.
In this case, additional activities are executed in the background. First, a follow-up
transaction is generated for the change request in the same way as for the activity
between the Service Desk message and the change request. The transaction gener-
ated depends on the selection made in the Subject eld; for example, it may be
an urgent correction. Change Request Management then searches for a project or
maintenance cycle for the system speci ed in the change request. If only one proj-
ect or maintenance cycle exists for the system, this is automatically assigned to the
follow-up document. However, if several project or maintenance cycles exist for
a system, the system prompts you to select a project or maintenance cycle from a
selection menu.
Once all of these actions have been successfully executed, the status of the change
request is set to Authorized. Once it has this status, no further activities can be
executed in the change request. The Change Request Management process now
continues in the follow-up transaction; that is, in the change document.
Change Document2.3.3
Change document serves as an umbrella term for the transaction types for Urgent
Corrections, Normal Corrections, Administration, and Test Messages. As illustrated
261_Book.indb 58 7/8/09 5:02:04 PM
59
TransactionTypes/Workows
2.3
in Figure 2.28, it consists of all transaction types used for the technical implemen-
tation of a change request.
Change Process
Service
Desk
Message
Change
Request
Urgent
Correction
Normal
Correction
Administration
Te st Message
Change Documents
Change DocumentsFigure 2.28
This clearly indicates once again the general division of the Change Request Man-
agement process into sub-processes. Change requests are used to document and
organize requests. The focus here is on information gathering and documentation,
followed by authorization or rejection of the request. Change documents, mean-
while, implement an approved change request. Because various processes can be
used to implement a change, you can choose here between the familiar transaction
types Normal Correction, Urgent Correction, and Administration message.
Normal Correction/Development Activity2.3.4
A normal correction, which is also referred to as a development activity as part of
an implementation, template, or upgrade product, represents the typical process
used for new or change implementations. Most changes should be executed with
this transaction type.
The technical name of the transaction type is SDMJ. The technical name SDMI
indicates another transaction type called Normal Correction in SAP Solution Man-
ager. This is the initial version of this transaction, which can still be used. Enhance-
ments of the process and functions have given rise to the new version SDMJ,
which is the standard version now recommended and maintained by SAP.
261_Book.indb 59 7/8/09 5:02:04 PM
60
ArchitectureofChangeRequestManagement
2
Differences Between SDMI and SDMJ
The main difference between these two transaction types concerns the transfer of the
correction from development to testing. In version SDMI, the relevant transport request
is released after the development activity is completed, and can then be imported into
the quality assurance system. If testing in the quality assurance system results in errors,
the developer must create a new transport request in the development system and re-
peat the procedure.
If several transport requests are created in this way, the mechanisms of the Transport
Management System give rise to a situation where all test transports into the quality as-
surance system are also contained in the import buffer of the production system. If the
correction cannot be tested without errors by the time the project or maintenance cycle
comes to an end, the developer may be forced to import the defective developments
into the production system at the end of the cycle.
Version SDMJ bypasses this problem because only one transport of copies is executed
between the development and quality assurance systems. Copies of the changes are
therefore transported in a new transport request. This transport request is imported only
into the target system and not into the production system. As a result, the original trans-
port request remains in the development system until the correction has been tested
successfully. The original transport request is only released after successful testing and
can then be imported into the quality assurance system again, where an integration test
is subsequently performed during the test phase for the entire project.
Various users may be actively involved in a normal correction as part of the Change
Request Management process. These are normally the change manager, developer,
tester, and IT operator. For detailed information about roles in Change Request
Management, see Section 4.1, Roles and Activities.
During the course of a normal correction, these users (for example, the developer)
can set the correction to In Development (see Figure 2.29) and then generate
transport requests in the development system, to which the change will be added
later.
You can navigate directly from the Normal Correction document to the develop-
ment system and implement the correction or development activity there. Changes
can then be saved directly in the existing transport requests.
After the development activities have been completed, the normal correction can
be transferred to testing. The change is automatically released in the development
system and can then be imported into the quality assurance system. Once the cor-
rection or development is ready for testing, you can navigate directly from the
261_Book.indb 60 7/8/09 5:02:04 PM
61
TransactionTypes/Workows
2.3
Normal Correction document to the quality assurance system and conduct testing
there. Testing can then be evaluated as successful or unsuccessful in the normal
correction.
Normal CorrectionFigure 2.29
If testing is unsuccessful, the status of the change document is reset to In Develop-
ment, whereas successful testing changes the status to Consolidated. This status
indicates that testing has been successful and enables an import of the change into
the production system. This import normally occurs at the end of the project or
maintenance cycle , together with the import of all other change documents, and
should be executed by an IT operator.
When all changes have been successfully imported into the production system ,
the individual change documents can be completed by setting the user status from
Consolidated to Production. This can be done manually or with a report.
Note
For detailed technical information about the administration and use of Change Request
Management, refer to Chapter 5, Security in Change Request Management, and Chap-
ter 8, Technical Notes on Usage and Troubleshooting.
261_Book.indb 61 7/8/09 5:02:05 PM
62
ArchitectureofChangeRequestManagement
2
The various user statuses that represent the individual steps involved in a normal
correction are as follows: Created, In Development, To be Tested, Consolidated,
Production, and Withdrawn. These status values map the various steps in a normal
correction, provide a general overview for users, and facilitate navigation.
Figures 2.30 and 2.31 show the activities that are possible in a Normal Correction
document during the various phases of a project or maintenance cycle.
Figure 2.30 demonstrates that a normal correction can only be created and trans-
ported during the development phases of a project (implementation, template,
or upgrade project). Once the project has entered the Test phase, any necessary
improvements or corrections can be executed using a
test message (see Section
2.3.7, Test Message). All corrections must be released or withdrawn in the devel-
opment system when the project passes into the Test phase. Any necessary cor-
rective action can still be implemented during the Test and Emergency Correction
phases. However, transport requests can only be created centrally in the project
task list at this point. This gure also shows that an import into the production
system can only occur during the Go-Live phase.
Normal
Correction
Phase
Request
Approval
In
Development
Release
Finish
Development
Pass to
Test
Production
Import
Created
OXXXXXX
Development
without Release
OOOXXXX
Development
with Release
OOOOOOX
Te st
XXXXXXX
Emergency
Correction
XXXXXXX
Go-Live
XXXXXXO
Being
Completed
XXXXXXX
Completed
XXXXXXX
Projects (Implementation, Te mplate, and Upgrade Project)
Project Phases and a Normal CorrectionFigure 2.30
261_Book.indb 62 7/8/09 5:02:05 PM
63
TransactionTypes/Workows
2.3
Figure 2.31 shows a normal correction in a maintenance project. In this case,
a normal correction can be created and edited at any stage. However, once the
maintenance reaches the Test phase, any normal corrections created during this or
subsequent phases are not part of the current maintenance cycle. Instead, these
corrections are integrated into the next cycle and can be transported into the pro-
duction system as part of this cycle.
Projects (Maintenance Project)
Normal
Correction
Phase
Request
Approval
In
Development
Release
Finish
Development
Pass to
Test
Production
Import
Created
OXXXXXX
Development
without Release
OOOXXXX
Development
with Release
OOOOOOX
Te st
OOOXXXX
Emergency
Correction
OOOXXXX
Go-Live
OOOXXXO
Being
Completed
XXXXXXX
Completed
XXXXXXX
Maintenance Project Phases and a Normal CorrectionFigure 2.31
An export of a normal correction is only possible within the document during the
Development with Release phase. Once the project reaches the Test phase, normal
corrections from the maintenance cycle can no longer be released from a docu-
ment. This prevents the transport of changes into the quality assurance system
during the Test phase and therefore during the integration test.
The system behavior described here indicates the possible actions that can be
executed in a normal correction document.
The central task list of the maintenance cycle allows the IT operator or project lead
to take corrective action. This means the task list can be used to create transport
requests and transport these into the test system during the Test and Emergency
261_Book.indb 63 7/8/09 5:02:06 PM
64
ArchitectureofChangeRequestManagement
2
Correction phases. This is an option to be used in exceptional cases only. However,
it gives you the exibility you need to implement essential corrections at the last
minute. Note also that only the IT operator or project lead should be authorized
to implement corrective action in this way.
Urgent Correction2.3.5
Urgent Correction, which is only available in maintenance projects, is a transaction
used when a change must be transported immediately into the target system. It
therefore gives you the option of transporting a change into the production system
before the end of a maintenance cycle. Later, we will show that no problem occurs
with this procedure, particularly with regard to data consistency.
The urgent correction, which has the technical name SDHF, is a partly automated
transaction. Many activities are executed automatically in an urgent correction, in
contrast to a normal correction, where a large number of activities depend on the
specic selections made by the user. For example, transport requests are immedi-
ately generated after an urgent correction is set to In Development. In addition,
an individual urgent correction can be transported into the production system
within the document. In a normal correction, by contrast, an IT operator executes
this nal step centrally for all corrections at the end of a project or maintenance
cycle.
This exibility is due to the individual task list of an urgent correction. As explained
above in Section 2.2.4, Project Cycle and Task List, normally only project or main-
tenance cycles have a task list. If changes of the normal correction, test message,
or administration type are executed in a project or maintenance cycle, the current
phase of the cycle determines whether it is possible to release a normal correction
or create a test message, for example. In this way, the phases of cycles determine
the scope of permitted activities. An urgent correction therefore has its own task
list, which allows it to take effect independently of these restrictions.
Urgent corrections may have the following user statuses: Created, In Development,
To be Tested, Successfully Tested, Authorized for Import, Production, Conrmed,
completed, and Withdrawn. As shown in Figure 2.32, an urgent correction can be
created and changed at any stage up to the Emergency Correction phase. In the
Go-Live phase, an urgent correction can be created but cannot be exported.
261_Book.indb 64 7/8/09 5:02:06 PM
65
TransactionTypes/Workows
2.3
Urgent
Correction
Phase
Request
Approval
In
Development
Release
Pass to
Test
Release for
Import into
Production
Production
Import
Created
OXXXXXX
Development
without Release
OOOOOOO
Development
with Release
OOOOOOO
Te st
OOOOOOO
Emergency
Correction
OOOOOOO
Go-Live
OOOXOOO
Being
Completed
XXXXXXX
Completed
XXXXXXX
Projects (Maintenance Project)
Maintenance Project Phases and an Urgent CorrectionFigure 2.32
Administration Message2.3.6
The administration message (technical name SDAD) is used to document activities
that do not result in a transport request; for example, changing number ranges or
maintaining master data. Therefore, an administration message is only ever of rel-
evance to a selected system, rather than to the entire system group (development,
quality assurance, and production system), as is the case in normal or urgent cor-
rections. The purpose of an administration message is to document these specic
changes so that it is possible to track, at any point, which users have made which
changes to the system.
An administration message may have the following status values: Created, In Pro-
cess, Completed, Conrmed, and Withdrawn. In principle, an administration mes-
sage offers the same functionality as a normal or urgent correction. You can navi-
gate directly from an administration message to the relevant system and enter the
relevant documentation in various text types. The only functions not available
in an administration message are those relating to the Transport Management
System.
261_Book.indb 65 7/8/09 5:02:06 PM
66
ArchitectureofChangeRequestManagement
2
Figure 2.33 shows the possible activities in an administration message in the vari-
ous phases of the project cycle.
Administration
Phase
Request
Approval
In
Development
Release
Pass to
Test
Release for
Import into
Production
Production
Import
Created
OXXXXX
Development
without Release
OOOO
Development
with Release
OOOO
Te st
OOOO
Emergency
Correction
OOO
Go-Live
OOOO
Being
Completed
XXXXXXX
Completed
XXXXXXX
All Project Ty pes
Project Phases and an Administration MessageFigure 2.33
Test Message2.3.7
As already stated in Section 2.3, Transaction Types/Workows, the test message
represents something of an exception. This transaction type (technical name
SDTM) is created without reference to a change request. Test messages are used
for troubleshooting purposes during the integration test and can therefore only be
created during the Test phase of a project or maintenance cycle.
Because a test message refers to the correction of a change that has already been
approved, there is no need for a change request in this case. The users involved in
a test message are the developer and the tester. A tester can create a test message
in Transaction TEST_CREATE during the integration test. The developer can then
create a corresponding correction in the development system and then transfer
this to the tester for retesting. When the correction has been imported into the
quality assurance system, the tester can conduct a new test to include the correc-
tion. If this test is successful, the test message is completed.
261_Book.indb 66 7/8/09 5:02:06 PM
67
TransactionTypes/Workows
2.3
A test message may have the following user statuses: Created, In Process, To be
Retested, Conrmed, and Withdrawn. Finally, as shown in Figure 2.34, a test mes-
sage can only be created and changed during the Test phase of a project cycle.
Te st
Message
Phase
Request
Approval
In
Development
Release
Pass to
Test
Release for
Import into
Production
Production
Import
Created
OXXX
Development
without Release
OXXX
Development
with Release
OXXX
Te st
OOOOO
Emergency
Correction
OXXX
Go-Live
OXXX
Being
Completed
XXXXXXX
Completed
XXXXXXX
All Project Ty pes
Project Phases and a Test MessageFigure 2.34
Job Request2.3.8
If you already use the enhancement Job Scheduling Management with SAP Central
Process Scheduling by Redwood, you can also use it in conjunction with Change
Request Management. This gives you the option of using the Service Desk message
to document a job request and to process changes to job documentation in Change
Request Management. A job request can be processed and approved as part of a
change request. Corresponding job documentation is then edited and documented
in a change document.
Change Transactions for Projects2.3.9
The change transactions for project cycles and maintenance cycles are mapped
with transaction types SDDV and SDMN. As explained in Section 2.2.4, Project
261_Book.indb 67 7/8/09 5:02:07 PM
68
ArchitectureofChangeRequestManagement
2
Cycle and Task List, project cycles, regardless of project type, consist of a generated
task list and a change transaction.
The change transaction of a project allows you to transition from one phase to the
next, following the now familiar sequence of phase values: Created, Development
without Release, Development with Release, Test, Emergency Correction, Go-Live,
Being Completed, Completed, and Withdrawn. The activities permitted during the
various project phases can be deduced from the explanations provided above.
Summary2.4
This chapter introduced you to the various elements of the Change Request Man-
agement functionality. It explained how these t into SAP Solution Manager as
a whole and explained the Project Administration function and the concept of a
project cycle. The various transactions in Change Request Management were then
described in detail. We will return again and again to these fundamental elements
of Change Request Management and examine each in more detail over the course
of this book.
261_Book.indb 68 7/8/09 5:02:07 PM
287
A
ABAP Dictionary object
retrofit, 140
Action, 98, 99, 128, 241
definition, 96
list, 54, 58, 97, 119, 153
profile, 96
task list, 160
Activation
cross-system object lock, 90
log, 76, 137, 146
Administration, 64
Change Request Management, 148
Administration message, 56
Change Request Management, 52, 55
transaction type, 59, 65
Administrator
authorization, 82
Application log, 167, 192, 280
Application management, 21
Approval, 191, 194
critical transport, 156
Architecture, 33, 38
Attachment, 127
Authorization, 183
extended, 185
object, 105
reporting, 171
role, 183
user status, 129, 130
Availability management
ITIL, 25
B
BAdI
CRM_CUSTOMER_H_BADI, 229
CRM_DNO_MONITOR, 239
CRM_ORDER_AUTH_CHECK, 186
SOCM_CHECK_CONDITION, 245
SOCM_PROCESS_ACTION, 252
BAdI enhancement
action, 99
Basic conguration, 70, 72
Basic setting
action, 99
consistency check, 100
BCOS_CUST, 189
BC set, 76, 101, 134, 136, 145
retrofit, 140
Bill of material, 197
Browser, 181
Build phase, 262
Business partner, 94
transaction monitor, 171
Business process, 22, 142, 146
Solution Directory, 144
Business process and interface monitoring
work center, 175
Business Process Change Analyzer, 260
Business process monitoring, 23, 142
logical component, 102
Business scenario, 22, 146
C
Capacity management
ITIL, 25
Catalog, 92
Categorization, 112
Category, 173
Change advisory board, 18, 19, 114
partner function, 111
Change Analysis, 261
Change document, 59, 61, 178
Change Request Management, 35
transaction type, 58
work center, 176, 178
Change Management, 113, 257
ITIL, 27
work center, 175
Index
261_Book.indb 287 7/8/09 5:03:24 PM
288
Index
Change manager, 18, 19, 29, 60, 113, 118,
120, 131, 192, 194
partner function, 111
retrofit, 135
sample process, 133
Change request, 18, 20, 29, 35, 52, 54, 56,
58, 59, 67, 113, 119
authorize, 120
creation, 117
hot news, 141
management, 74, 99
process, 35
request for change, 18
work center, 176, 177, 178
Change Request Management, 18, 24, 28, 33,
45, 54, 69, 73, 225
configuration, 129
logical component, 103
process, 59, 60
project administration, 30
reporting, 170
transaction type, 98
Change tracking, 163
Change transaction, 47, 67, 117
partner function, 111
project cycle, 154
task list, 159
type, 90, 98
Check, 101
reporting, 31
task list, 160
Check-in, 146, 148
business process, 36
Check-out, 146, 148
business process, 36
Check report, 101, 108
Client
logical system, 103
RFC connection, 105
Client copy, 268
Client setting, 162
Close coupling, 215
Code, 92
group, 92
group profile, 92
Completion task
task list, 149, 159
Component
configuration, 71
logical, 37, 102, 104, 105, 107, 139, 267,
272
Condition, 98, 241
action profile, 97
consistency check, 100
definition, 243
status value, 100
Condition editor
action profile, 98
Conguration, 69, 72
extended, 85, 162
project, 154
Transport Management System, 77
work center, 179
Conguration management
ITIL, 16, 27
Conguration node
IMG, 72
Conict analysis, 187
Conict scenario
cross-system object lock, 89
Consistency check, 99, 108
retrofit, 136
Context, 146
Control function
change manager, 113
Copy control, 98, 101
Copying control, 251
Correction
action, 62, 63
Change Request Management, 52, 55
change transaction, 48
normal, 50, 56, 62, 64
process, 116
processing, 122
synchronization, 159
test transfer, 126
transaction type, 59, 64
urgent, 49, 56, 120, 124, 131, 150
workbench, 134, 136, 140
cProjects, 40, 45, 50, 90, 91, 155
Critical transport object, 87
CRMC_MAP, 229, 231
CRMC_MSGC, 243, 248
CRMC_MSGS, 244, 248
261_Book.indb 288 7/8/09 5:03:24 PM
289
Index
CRM_CUSTOMER_H_BADI, 229
CRM_DNO_MONITOR, 239
CRM_ORDER_AUTH_CHECK, 186
CTS+, 207, 213, 217, 223, 225
distributed landscape, 220
double stack landscapes, 219
CTSDEPLOY, 208
CTS project, 40, 41, 43, 83, 126, 159, 160,
161, 163
project assignment, 82
CTS Status switch
project logistics, 168
Customer, 53
Customer namespace
transaction type, 179
Customer-specic tab, 228
Customizing
global, 206
regional, 206
request, 126
transport request, 124
Customizing distribution
logical system, 102
Cutover, 134, 204, 205
Cycle
completion, 160
D
Daily overview
task list, 153
Data collector, 170, 171
Data consistency, 64
Date prole, 95
Date rule, 95
Date type, 95
Default conguration, 73
Deploy phase, 263
Deploy service, 207
Deploy Web Service, 208, 209, 217, 221
Developer, 60, 114, 135
partner function, 112
sample process, 133
test message, 66
Development
Change Request Management, 57
number range, 84
package, 227
phase, 49
project cycle, 48
status, 130
system, 60, 66, 122, 133
Transport Management System, 77
user status, 128
Diagnostics
root cause analysis, 175
Dictionary object, 134
Display list
transaction monitor, 175
Document ow, 52, 120, 131, 160
Document management
cProjects, 91
Domain controller, 71, 77, 79, 80
ABAP, 208
Domain link, 80, 217
transport domain, 80
Double stack, 207
landscape, 219
system, 210
target system, 213
Downgrade, 134, 195
Dual-control concept, 20, 115, 128
Duration type, 95
E
E-learning, 22, 142
material, 143
Enhancement package, 24, 258
Enterprise Edition
SAP Solution Manager, 143
Error analysis, 278
Error solution
ITIL, 25
Evaluation
criterion, 169
Event management, 26
ITIL, 17
Execution option
BC Set, 137
Execution time
action, 99
261_Book.indb 289 7/8/09 5:03:24 PM
290
Index
Export check, 193
critical transport object, 87
F
Fast entry
text administration, 96
Flow logic, 234
Follow-up document, 121, 133
Four-level system landscape, 201
Functional tester, 115
G
Gantt
cProjects, 50
Global customizing, 206
Global namespace, 206
Global template, 205
H
Hot News, 117, 140, 141, 179
work center, 176
HP Quality Center, 260
HTMLB, 180
I
IBase, 52
component, 71
ICF, 179, 180
IMG activity, 41, 55, 72, 73
number range, 84
IMG project, 107
Implementation
documentation, 143
lifecycle, 22
user status, 130, 132
Implementation and upgrades
work center, 175
Implementation project, 30, 35, 39, 40, 41,
42, 48, 57, 62
Import
authorization, 82
error, 155, 274
IT operator, 115
project, 277
subset, 277
Inactive system, 270
Incident Management, 16, 17, 26, 52, 113
event management, 26
work center, 175
Information
predecessor/successor, 195
Instance prole, 180
Integration test, 66, 115, 202, 204, 268
Interface setting
partner determination procedure, 94
Internet service, 181
configuration, 180
Interval
number range, 84
Issue management, 27, 71
IT Change Management, 15, 17, 19
monitoring, 20
ITIL, 15, 20, 91
change advisory board, 18, 19
change manager, 18, 19
change request, 18, 20
Incident management, 16
ITIL V3, 16, 17, 24
request for change, 18
IT operator, 60, 63, 115, 129, 130, 148
partner function, 112
sample process, 133
IT service continuity management, 25
ITSM, 15
J
Java stack
system, 207
Job documentation, 67
Job request, 67
Job Scheduling Management, 67
work center, 175
261_Book.indb 290 7/8/09 5:03:25 PM
291
Index
K
Knowledge Warehouse, 107, 143
L
Landscape
component, 104
global development, 205
Layout
transaction monitor, 173, 175
License management, 178
work center, 176
Lifecycle, 16, 21, 27
project cycle, 46
SAP Solution Manager, 33
Lock entry
cross-system object lock, 89
Lock information, 189
Logical component, 267, 272
logical system, 103
Logical system, 38, 42, 102, 103, 106
Loose coupling, 214
M
Maintenance activities, 258
Maintenance cycle, 48, 49, 58, 61, 63, 64,
160
completion, 159
retrofit, 138
scheduling, 166
urgent correction, 117
Maintenance documentation, 258
Maintenance landscape, 201, 204
Maintenance Optimizer, 258
work center, 176
Maintenance planning, 258
Maintenance project, 30, 35, 39, 40, 48, 49,
57, 63, 108, 139
number range, 84
Maintenance transaction
Maintenance Optimizer, 177
Maintenance unit
reporting, 170
Modication, 194
critical transport object, 87
Module, 234, 235
Monitoring, 20, 169
Change Request Management, 31
N
Namespace
global, 206
regional, 206
Navigation area
work center, 178
Non-ABAP object, 208, 209
Note
implementation, 157
Number range, 84, 92
object, 84
O
Object
critical, 163
extended configuration, 162
reporting, 31, 171
Object list, 191, 193, 195, 197
Object lock
cross-system, 87, 89, 90, 163, 186, 188
information, 190
scenario, 187
update, 191
Object reporting
reporting service, 88
Object version, 134
Operations
lifecycle, 22
Optimization
lifecycle, 24
Optimization project, 36
Order attribute, 83
Organizational Management, 172
Organizational structure, 69
Organizational unit, 172
reporting, 170
transaction monitor, 173
261_Book.indb 291 7/8/09 5:03:25 PM
292
Index
Overtaker, 165
Overview
work center, 176
P
Package, 227
PAI, 232
module, 235
Parallel phase landscape, 203
Parallel project, 201, 203
Parallel system, 275
Parallel system landscapes, 130
Parameter transaction, 173
Partner determination procedure, 94
Partner function, 93, 94, 116
PBO, 232, 238
flow logic, 234
module, 234
Personalization lter
work center, 175
Phase
change, 151
control, 150, 151
Controller, 160, 273
maintenance cycle, 160
project cycle, 64, 68, 108, 151, 160
Phase landscape
parallel, 203
Phase value
cProjects, 50
project cycle, 46, 68
Planning
project logistics, 168
Port
CTSDEPLOY, 208
Postprocessing
assignment, 156
retrofit, 137
system, 138, 139
Preparation
configuration, 69
Preproduction system, 202
Priority, 112, 178
transaction monitor, 173
Problem management, 17, 26, 27, 113
Process, 116
Process documentation, 143
Processor
current, 116, 128
partner function, 112
Process step, 22
Production
user status, 129
Production manager, 116
partner function, 112
Production system, 49, 61, 62, 64, 133, 134,
138
Transport Management System, 77
Prole generator, 137
Prole parameter, 180
Project
Change Request Management, 102
parallel, 201, 203
work center, 176
Project administration, 28, 30, 34, 107, 149,
154, 162
SAP Solution Manager, 37
Project analysis, 163, 165
Project assignment, 82, 163
Project category
scheduling, 166
Project cycle, 30, 40, 46, 50, 58, 61, 67, 108,
148, 152, 273
administration message, 66
complete, 280
completion, 159
Project header
reporting, 170
Project intersection, 195
Project landscape, 204
setup, 271
two-level, 134
Project lead, 63, 147
Project logistics, 167
Project monitor
logistics, 168
Project phase
project cycle, 68
Project planning
cProjects, 91
Project status switch
CTS project, 44
261_Book.indb 292 7/8/09 5:03:25 PM
293
Index
Project structure
logistics, 168
Project type, 35, 39
Q
Quality assurance system, 49, 60, 63, 128,
133
Quality gate, 263
Quality Gate Management, 178, 258, 261
phases, 262
Quality Management, 261
Quality manager, 263
Query
work center, 176
R
Regional customizing, 206
Regional namespace, 206
Regression test, 200
Release, 138
Release landscape, 201
Release management, 17, 27, 258
Release manager, 114
Release package, 27
Repair ag, 274
Report
work center, 177
Reporting, 169
Change Request Management, 31
SAP Solution Manager, 28
service, 87, 88
solution-independent, 177
Report on side-effects, 260
Request
own, 125
Request analysis
change tracking, 165
Requester, 112, 118, 131
partner function, 111
sample process, 133
Request for change
change request, 18
Result list
reporting, 170
Retrot, 130, 134, 137, 156, 204
function, 130
object, 137
process, 134, 135, 138
system, 135, 136, 137, 138
RFC connection, 80, 81, 89, 104, 105, 139,
158
configuration, 75
RFC destination, 81, 104
configuration, 75
Role, 174
Change Request Management, 111
cross-system object lock, 89
type, 155
work center, 179
Role maintenance
work center, 76
Root cause analysis, 23, 24, 175
S
Safeguarding project, 36
Sample process, 133
Sandbox system, 201
SAP Basis, 40
SAP Business Workow, 51
SAP Download Manager, 259
SAP EarlyWatch Alert, 23, 25
SAP GUI, 178, 179
for HTML, 178, 179, 180, 181
setting, 179
SAP infrastructure, 21
SAP NetWeaver, 40
SAP NetWeaver Application Server, 71
SAP NetWeaver Business Warehouse
transport, 276
SAP NetWeaver Development Infrastructure,
215
SAP NetWeaver Portal, 215
SAP NetWeaver Process Integration, 215, 216,
223
SAP note, 284
SAP product
system landscape maintenance, 104
261_Book.indb 293 7/8/09 5:03:25 PM
294
Index
SAP Service Marketplace, 72
SAP Solution Manager, 22, 25, 27, 28, 30, 37,
40, 52, 59, 107, 175
application, 117
application management, 21
change document, 35
configuration, 179
Diagnostics, 261
enterprise edition, 143
implementation, 22
ITIL, 20
lifecycle, 21
operations, 22
optimization, 24
reporting, 169
root cause analysis, 23
scheduling, 166
solution monitoring, 23
task list, 34
workflow, 29
SAP support organization, 53
SAPSYS, 283
SAP Transport Management, 206
SAP Tutor, 72, 116
SAP variant
task list, 167
Satellite system
Transport Management System, 76
Schedule condition
action profile, 97
Schedule Manager, 46, 85, 86
task list, 47
Scheduling, 166
analysis, 165
project logistics, 168
task, 153
Scope phase, 262
Screen control, 235
Security Guide, 183
Selection criterion, 171
transaction monitor, 171
Sequence violation
overtaker, 165
Service delivery
work center, 175
Service Desk, 23, 29, 71
change request, 117
employee, 113
message, 53, 58, 67
partner function, 111
sample process, 133
SAP Solution Manager, 53
transaction type, 52
Service level, 23
Service-level management, 25
Service-level reporting, 23
Service lifecycle, 24
Service process
monitor, 171, 173
Service process transaction, 51, 54, 55, 56,
141
CRM, 117, 118
Setting
scenario-specific, 73
Side effect, 260
Single transport
transport strategy, 78
SMSY_SETUP, 272
SOCM_CHECK_CONDITION, 245
SOCM_PROCESS_ACTION, 252
Software lifecycle, 142
Software Lifecycle Manager, 259
Software status
change tracking, 164
Sold-to party, 116, 118
partner function, 112
Solution
database, 26
reporting, 170
Solution Directory, 35, 142, 143, 144, 146,
147, 257
Solution landscape and operations setup
work center, 175
Solution monitoring, 23
Solution reporting, 23, 170
service level, 23
Source system, 138
Split screen editor, 136
SPPFCADM, 253
Stakeholder, 18
Standard prole
configuration, 92
Start condition
action profile, 97
261_Book.indb 294 7/8/09 5:03:25 PM
295
Index
Status
transaction monitor, 172
Status display
retrofit, 135
Status management, 94
Status prole, 55, 94
Status property, 98
profile, 94
Status switch, 151
Status value
administration message, 65
status profile, 55
transaction monitor, 172
Steering committee
change advisory board, 114
Structure element, 142, 144
Subject, 56, 120
profile, 92
Subject area, 173
Support Desk
logical component, 103
Support package, 24, 258
import, 158
System
add, 267
inactive, 270
logical, 38, 42, 102, 103, 106
parallel, 275
virtual, 269, 271
System administration, 23
work center, 175
System analysis, 163
change tracking, 164
System change option, 90, 162, 163
extended configuration, 162
project logistics, 168
System comparison, 270
System copy, 268
System data
reporting, 170
System ID, 102
System landscape, 139
Change Request Management, 41
configuration, 70
four-level, 201
maintenance, 34, 37
project administration, 37
retrofit, 134
SMSY, 139
three-level, 134, 195, 199, 203
System landscape maintenance
IBase, 71
System logon, 155
task list, 156
System monitoring, 23
work center, 175
System role, 139
logical component, 106
T
Tab
customer-specific, 228
Table
BCOS_CUST, 189
Target system, 138, 149
Task
release, 126
Task list, 50, 64, 86, 139, 148, 149, 152, 154,
268
Change Request Management, 34
creation, 108
lock, 153
number range, 84
Schedule Manager, 47
urgent correction, 150
Template, 205
global, 205
task list, 150
Template project, 30, 35, 39, 48, 57
Template report
task list, 86
Test
management, 260
person, 128
phase, 262
plan management, 154
project cycle, 48
test case, 142, 143
test instructions, 127
transport, 269
user status, 129
Test Data Migration Server, 269
261_Book.indb 295 7/8/09 5:03:25 PM
296
Index
Tester, 60, 115
functional, 115
partner function, 112
sample process, 133
Test message, 64, 66
Change Request Management, 52
transaction type, 66
Test Workbench, 260
Text
administration, 95
Customizing, 96
determination procedure, 95
history, 124
object, 96
text type, 96
Three-level system landscape, 134, 195, 199,
203
TMSADM, 185
TMWFLOW/CHARMCHK, 278
TMWFLOW/CMSCONF, 190, 193
TMWFLOW/LOCKMON, 189
Track
task list, 149, 156
Tracking
project logistics, 168
Transaction
CRMC_MAP, 229, 231
CRMC_MSGC, 243, 248
CRMC_MSGS, 244, 248
SMSY_SETUP, 272
SPPFCADM, 253
TMWFLOW/CHARMCHK, 278
TMWFLOW/CMSCONF, 190, 193
TMWFLOW/LOCKMON, 189
Transaction data
reporting, 170
Transaction header
text administration, 95
Transaction monitor, 121, 171
extension, 239
my department, 172
my team(s), 172
Transaction type, 51, 52, 59, 60, 90, 91, 146
date profile, 95
Transport
check, 158
copy, 60, 158
directory, 209
history, 271
log, 275
route, 213, 222
task, 155
task list, 160
Transport control, 77
configuration, 70
Transport domain, 71, 79, 80, 81
configuration, 70
Transport landscape
extended, 199
Transport Management
enhanced, 206
Transport Management System, 60, 65, 76,
77, 81
alert monitor, 155
authorization, 82
configuration, 210
import monitor, 155
Transport object
critical, 87, 191
reporting, 171
Transport Organizer Web UI, 208, 210, 220
Transport request, 122, 131
creation, 156
import, 158
project assignment, 82
registration, 155
release, 158
reporting, 171
Transport routes
Transport Management System, 77
Transport strategy, 78
Transport Management System, 78
Trusted RFC
authorization, 283
connection, 185
Trusted service, 79, 283
U
Unit test, 202
Upgrade project, 30, 36, 39, 48, 57, 204
Use
Change Request Management, 111
261_Book.indb 296 7/8/09 5:03:25 PM
297
Index
User
SAPSYS, 283
User group
partner function, 111, 116
User status, 64, 121, 127, 128
Completed, 131
Confirmed, 131, 132
status profile, 55, 94
test message, 67
V
Validating and Testing, 27
Variant
SAP0, 277
SAP1, 278
task list, 85
Versioning, 275
Virtual system, 269, 271
Visual Administrator, 215
W
Workbench
object, 136
request, 126
transport request, 124
Work Center, 53, 76, 117, 118, 121, 175, 179
Workow, 51
Change Request Management, 29
261_Book.indb 297 7/8/09 5:03:26 PM