Change Request

A change request is a transaction you use to request a change of your software or a

company system, for example, an enhancement or change to a function. A change
request can also be triggered by a problem message. It must pass through an approval
process before a change can be made. You can categorize a change request with regard
to the type of change, for example, as a normal correction, urgent correction or general
change. When the change request is approved by a change manager or another
employee, change documents are created from the change request and linked to it.
Note
You can assign several change documents to a change request. For example, if a change
affects several production systems of a project, you can record all changes in one
change request.

By default, you can use Customizing transaction type SMCR for the change request in
the WebClient UI. You can copy this transaction type and adapt it to your requirements.
For more information, see SAP Note 1493264.
Note
We recommend that you do not change the Customizing settings specified for
transaction type SMCR delivered by SAP.
Transaction type SDCR is available for the change request in the SAP GUI.
Structure
The change request consists of the header details, which are organized in individual
groups, and additional assignment blocks. You can adapt and customize the display of
the assignment blocks according to your requirements.
Header Level
In the header details you record your general data that is valid for the entire change
request. This includes, for example, the following data:
General data, for example, requester, change manager, and ID
Processing data
Data for change planning, for example, approval process and project
Relationships, for example, corresponding problem and corresponding event
Assignment Blocks
In the assignment blocks, you record additional data for the change request, for
example:
Scope of the change request
Here you specify the change category and therefore the type of the change
document or the change documents, for example, urgent or normal change.
Texts
Approval
Documents
Information about projects and solutions
Information about test management
Integration
Change requests and change documents with their content features are summarized
using the term change transactions. They are used for handling all change processes
with SAP Solution Manager.
Change Request Management uses variants of the service transaction for the processing
of change transactions in SAP system landscapes. For more information about
integration and the required settings, see the Customizing in SAP Solution Manager
Capabilities Change Control Management .
The execution of a change request can be planned in detail and, if necessary, can be
integrated with additional processes and functions. If a knowledge article was used to
complete a change request, this knowledge article can be attached to similar change
requests as a source of useful information.
More Information
&Change Document
&&Processing Change Requests
&&&Functions in Change Transactions




&Change Document
A change document is a transaction that documents the activities of the users that are
involved in the change process, for example, developers, testers, and system
administrators. A change document can be created automatically by the system as soon
as a change manager or another responsible employee approves a change request and
the status is set to In Development.
In the work steps following the approval of the change request, the change document
forms the operational basis for developers, testers, and IT administrators and passes
through different phases, which depend on the type of the change document.
You select the appropriate change document depending on the type of change. You can
define your own change document types in Customizing or use the change document
types supplied by SAP. By default, the following transaction types are available in
Customizing. You can copy the transaction types and adapt them to your requirements:
Change Document Type Transaction Type
Normal change SMMJ
Urgent change SMHF
Administrative change SMAD
General change SMCG
Error correction SMTM
Structure
The change document consists of the header details, which are organized in individual
groups, and additional assignment blocks. You can adapt and customize the display of
the assignment blocks according to your requirements.
Header Level
In the header details, you store general data that applies to the whole change
document. This includes, for example, the following data:
General data such as the developer, tester, and ID
Processing data
Data for change planning, such as the project and the task list
Relationships, such as a related change request
Assignment Blocks
In the assignment blocks, you store additional change request data that controls further
processing. You can use the following assignment blocks, for example:
Information about projects and solutions
Texts
Documents
Information about test management
Processing log
Information about transport requests, tasks, and the system landscape
Integration
Change requests and change documents with their content features are summarized
using the term change transactions. They are used for handling all change processes
with SAP Solution Manager.
Change Request Management uses variants of the service transaction for the processing
of change transactions in SAP system landscapes.
For more information about integration and the required settings, see the Customizing
in SAP Solution Manager Capabilities Change Control Management . Execution
of a change document can be planned in detail and, if necessary, can be integrated with
additional processes and functions.
More Information
Processing Change Requests
&&Processing Change Requests
The process describes how you can create, edit, approve, and implement change
requests in the context of a maintenance cycle or implementation project. With this
process and the documentation of all related tasks, you can find out at any time where a
request originated, who implemented it and when the change was implemented in a
production environment.
Employees with different roles are involved in the processing of change requests:
Requester: creates a problem message or immediately creates a change request
Service employee: edits the problem message and creates the change request
Change manager: categorizes, prioritizes, approves, and monitors change
requests
Change advisory board: steering committee in the change process
Developer: implements changes and transfers them to the tester
Tester: tests changes and sets the corresponding status in the change document
Administrator: advances the phases of the cycle and imports project-related
changes

Prerequisites
You have configured the Customizing settings under SAP Solution Manager
Capabilities Change Management Change Request Management .
The users involved in the change management process have the required
authorizations. To do so, system administration has created user roles that
include these authorizations and assigned these roles to the respective users.
These roles were created in SAP Solution Manager and in the managed systems.
For more information, see the Security Guide for SAP Solution Manager on the
SAP Service Marketplace at http://service.sap.com/instguides SAP
Components SAP Solution Manager <current release> .
You have created a project in SAP Solution Manager, activated change control
management for the project, and generated a project or maintenance cycle. See
Settings for Change Requests in Project Administration.
Settings for Change Transactions in Project Administration
In any implementation, upgrade, template or maintenance project, you must activate
change request management if you want to work with change requests in the respective
project. You can also make other settings in the project administration.
Features
In the project administration, you can perform the following settings under System
Landscape Change Management
Enable Change Request Management
If you select this indicator, all systems of a logical component are selected on the
Systems tab and are thus included in change request management.
You must now manage all changes in the system landscape using change
requests. Transports are then only possible in conjunction with change request
management.
Assign cProjects Project
Assign Variant for Task List
You can choose from two SAP standard variants with different transport
procedures to the production system: You use SAP0 if you work with urgent and
normal corrections. You use SAP1 if you only work with urgent corrections.
Create Task List
The system creates a project or a maintenance cycle and a task list.
Display Task List
You display the generated task list. The task list receives all jobs (methods) that
must or can be executed for a project.
Display Service Desk Transaction
You can access the processing functions for the project or maintenance cycle in
the WebClient UI and change the phase, for example. For more information, see
% Processing a Project Cycle and %%Processing a Maintenance Cycle.
Display Project Status Switch
You define whether and into which systems of a logical component transport
requests can be imported.
When a project cycle is created, the CTS status switches are deactivated by
default. This means that the functions of the Change and Transport System
cannot be used to create, release, or import transport requests. For
troubleshooting purposes, however, system administrators are permitted to
activate these project status switches. Double-click the project status switch that
you want to activate (Requests cannot be created, for example). The switch is
activated in the system. You can now create transport requests for a particular
project without having to use Change Request Management.
Check
You can check the configuration of the administration of change requests and
display details for the individual results. For more information, see Configuration
Check.
Task Lists
You can view all task lists, change documents, project and maintenance cycles,
and other data assigned to the project, and can display related detail
information.
Service Desk
Go to procedure monitor for list display of service transactions
Quality Gate Management
For more information, see Checking the Quality Gate Configuration.

%Processing a Project Cycle
This process creates and uses a project cycle for normal changes, defect corrections, and
administrative changes in non-maintenance projects. You can edit project cycles in the
WebClient UI.
Process
1. The project lead creates an implementation, upgrade or template project, in the
SAP Solution Manager project administration. For the project, he generates IMG
and CTS projects, and a project cycle, because change request management will
be part of the project.
2. The responsible system administrator activates the project cycle. In the project
administration, under System Landscape Change Management , they select
the Activate Change Request Management checkbox. The project cycle and task
list for the project are generated when they select Create task list.
You can now create change requests. When the status of a change request is set
to In Development, the assigned change documents are assigned to the project
cycle. The selected project in the Details assignment block defines which project
cycle is assigned by the system. If several projects are active at the same time,
you can choose from a list of projects.
3. The change manager sets the status of the implementation project to
Development without Release. In this status, features can be developed, and
transport requests and tasks can be created, but not exported.
Note
Do not use this phase in normal changes, as developers will not be able to
import changes into the test system.
End of the note.
4. When the change manager switches the status of the implementation project
from Development without Release to Development with Release, transport
requests can be released from within a normal change. The administrator uses
the task list to import all released changes into the test systems.
5. The change manager sets the status of the project cycle to Test. If there are any
normal changes, whose status has not yet been set to Tested Successfully when
the phase is changed from Development with Release to Test, the system issues
an error. In a development project, no changes can be excluded from the test;
they either have to be withdrawn or released.
6. If changes still have to be made after the test phase has been completed,
transport requests and tasks can be created and released as part of the
Emergency Correction phase. You can only do this by using the task list of the
Schedule Manager. This only applies to normal changes.
7. In the Go Live phase, the entire project buffer is imported into the production
system.
8. The project buffer is empty, and there are no open transport requests. You can
now close the project cycle, by setting the status to To be Closed. You can then
create a new project cycle.
More Information
Phases in project and maintenance cycles

%%Processing a Maintenance Cycle
This process creates and uses a maintenance cycle for normal and urgent changes,
defect corrections and administrative changes. You can edit maintenance cycles in the
WebClient UI.
Process
1. A project lead creates a maintenance cycle for a maintenance project.
2. The change manager sets the status of the maintenance cycle to Development
without Release. In this status, changes can be developed and transport requests
and tasks can be created, but not exported (except urgent changes). Urgent
changes are permitted in every phase except for Go Live.
3. The change manager switches the status of the maintenance cycle from
Development without Release to Development with Release. Transport requests
can be released from within a normal change. The administrator uses the task list
to import all released changes into test systems.
4. The change manager sets the status of the maintenance cycle to Test. If there are
normal changes whose status has not yet been set to Tested Successfully when
the maintenance cycle phase is changed from Development with Release to Test,
the system issues a warning. These changes are then excluded from the
integration test, and cannot be released.
5. During the test phase, errors are detected in the test systems, and are reported to
the developers by defect corrections. The developers correct these errors. If all
error messages have been closed, the maintenance cycle proceeds to the
emergency correction phase.
6. If changes still have to be made after the test phase has been completed,
transport requests and tasks can be created and released, as part of the
Emergency Correction phase, but only by using the task list of the Schedule
Manager.
7. In the Go Live phase, the entire project buffer is imported into the production
system. Neither transport requests nor urgent changes can be released during
this phase.
8. If there are still any open transport requests, return to the Development with
Release phase and repeat the process, including the test phase, to ensure that
any open requests can be released and transported.
9. If there are no open transport requests, you can close the maintenance cycle, by
setting the status to To be Closed. You can then create a new maintenance cycle.
Note
Normal changes can be created in the test phase of a maintenance cycle, but the
corresponding transport requests cannot be exported.
End of the note.
More Information
Phases in project and maintenance cycles

Phases in the Project and Maintenance Cycle
The phases in project and maintenance cycles define which activities are permitted as
part of change control.
Prerequisites
Each phase in the project and maintenance cycle corresponds to the status defined in
the status profile for the corresponding transaction types. You configure these settings
in Customizing for SAP Solution Manager under Capabilities Change Management
Standard Configuration Transaction Types Status Administration Define Status
Profile for User Status .
Features
Phase structure: Project and maintenance cycles have the following standard
phases:
1. Created
2. In Development w/o Release
A transport request can be generated but not released.
Note
Use this phase if developments are not to be transported to the test
system straight away.
End of the note.
3. In Development with Release
You can only release transport requests once you have reached this phase.
It is initiated by the change manager or the change advisory board and
allows you to release transports and to import them into the test system
for developer tests.
4. Test
Once changes to the project have been imported into the test system, this
phase can start and integration testing can commence. New change
requests can no longer be created for the project. Using error corrections,
you can only eliminate errors that have occurred during testing.
5. Go Live Preparation
Users with the corresponding authorizations can make additional required
changes.
6. Go Live
All changes that were successfully tested in the test phase are imported
into the production system.
You can display the phases in the Project Phases assignment block. The current
phase for the cycle is highlighted.
You change the phases and therefore the status of the cycle by choosing Actions.
Caution
To switch from one project phase to the next, you should use only the required
action in the project or maintenance cycle. Do not use the task list to switch
project phases.
Example: In a three-system landscape, all transport requests for urgent changes
that have the To Be Tested status are in the import buffer of the production
system. If you switch the phase in the task list and not in the maintenance cycle,
the system does not issue a warning, and the urgent changes would be imported
into the production system without being tested. If you switch the phases in the
maintenance cycle, the transport requests are checked. The user is therefore
aware of the situation and can act accordingly.
Process
1. A processor in the department discovers a change requirement in a transaction
that he/she uses, for example, an error or a missing function. This processor can
now create a service desk message directly from the transaction, allowing him or
her to describe the situation and request a change.
2. The message appears in the worklist of a service employee who processes the
message and creates a change request.
In SAP Solution Manager, he/she opens the Change Management work center
from which he/she can start the WebClient UI directly.
The service employee can create the change request from scratch or reference an
existing template from which the available information can be copied.
3. The system forwards the change request to the change manager. He/she can see
the change requests and change documents for which he/she is responsible in
the Change Management work center. The change manager is responsible for
prioritizing the request according to its impact (for example, high, medium, or
low) and to define its scope. He or she also specifies for which systems the
change is relevant.
The type of the change document determines the definition of the scope. You
can define your own change document types in Customizing or use the change
document types supplied by SAP:
o Normal change
o Urgent change
o Administrative change
o General change
o Error correction
The change manager assigns the change request a project and, optionally, a
solution for documenting the changes. The change manager can also assign
various documents, test cases, and additional information relevant to the change
process, such as which business process is affected. If the error is serious enough
to justify implementing a correction, the change request is released for approval.
4. The change request must be approval before a change document can be created.
In the standard system, the change manager is entered as the approver
however, if required, you can also enter an additional business partner (such as
the change advisory board).
5. Once the change request is approved, a change document is generated
automatically. In the following work steps, the change document forms the
operational basis for developers, testers, and IT administrators and passes
through different phases, which depend on the type of the change document.
A change request can still be changed or extended after its approval. You can
add further change documents, for example.
6. The change document appears in the worklist of a developer who implements
the change and releases it for testing.
All users involved in the change process can navigate from the change document
to the corresponding target systems in the maintenance or development
landscape. You make the required changes in these systems. The developer
confirms the change by setting a status, and as soon as a change document is
assigned a new status, certain actions have to be carried out, such as the release
of a transport request. Depending on the type of change document, these
actions are carried out either automatically when a change is saved, or explicitly
by the administrator.
7. As soon as the tester has tested the change successfully, the change can be
transported through the system landscape to the production system.
8. The change manager completes the change request. If all change documents for
a change request have been fully processed, the change request is also
completed.
More Information
Project Cycle
Maintenance Cycle
Worklists in Change Request Management
Creating a Change Request

&&&Functions in Change Transactions
Assignment blocks provide a range of integrated functions and information options that
you can use both in change requests and change documents.
Features
You can use the following functions:
Actions
Link to projects and solutions
Documents
Test management
Error log and error processing
See also Troubleshooting in Change Documents
Text management
Attachments
Note
You can define the changeability and visibility of fields in the Scope and Details
assignment blocks in change transactions depending on their status. To do this, in
Customizing for SAP Solution Manager, choose Capabilities Change Request
Management Standard Configuration Change Request Management Framework
Adjust Project Field and Scope in Change Request by Status .









Project Cycle

Controls the following activities in change control management over the whole duration
of a project:
Change requests and the resulting changes in the systems that are used in your
project
Transporting changes to the follow-on systems
Change logistics, that is, which transports can be transported into the follow-on
systems at which point in time
You create a project cycle for introduction, upgrade, and template projects.
From a technical perspective, the project cycle is a preconfigured service transaction
(delivered by default as transaction type SMDV).
Note
The Maintenance Cycle is a special type of project cycle where it is possible to pass
through the stages several times. It is created for maintenance projects.

You always create a project cycle for a project if you want to work with change
transactions. You use the project cycle to control which changes activities are permitted
in which phase. The project cycle phases determines the sequence of tasks in task lists.
Through its phase structure, the project cycle offers an operational enhancement to the
project plan.
Structure
The following functions are available by means of assignment blocks in the project
cycle:
Project phases
For more information, see * Phases in the Project and Maintenance Cycle.
Details
Contains general administration data for the project cycle, such as when and by
whom it was created, and the current project cycle phase.
Text
For more information, see **Using Texts and Text Templates.
Landscape
For more information, see ***Using the Landscape Assignment Block.
Associated transactions
Contains links to the task list and all change documents that use this project or
maintenance cycle.
Application log
For more information, see ****Using the Application Log.
Integration
You activate a project cycle for a project and thereby also activate the specific
corresponding task list.
Note
Each project cycle has just one task list, which is used for the entire project and all
corresponding change transactions.









*Phases in the Project and Maintenance Cycle
The phases in project and maintenance cycles define which activities are permitted as
part of change control.
Prerequisites
Each phase in the project and maintenance cycle corresponds to the status defined in
the status profile for the corresponding transaction types. You configure these settings
in Customizing for SAP Solution Manager under Capabilities Change
Management Standard Configuration Transaction Types Status Administration
Define Status Profile for User Status .
Features
Phase structure: Project and maintenance cycles have the following standard
phases:
1. Created
2. In Development w/o Release
A transport request can be generated but not released.
Note
Use this phase if developments are not to be transported to the test
system straight away.
3. In Development with Release
You can only release transport requests once you have reached this phase.
It is initiated by the change manager or the change advisory board and
allows you to release transports and to import them into the test system
for developer tests.
4. Test
Once changes to the project have been imported into the test system, this
phase can start and integration testing can commence. New change
requests can no longer be created for the project. Using error corrections,
you can only eliminate errors that have occurred during testing.
5. Go Live Preparation
Users with the corresponding authorizations can make additional required
changes.
6. Go Live
All changes that were successfully tested in the test phase are imported
into the production system.
You can display the phases in the Project Phases assignment block. The current
phase for the cycle is highlighted.
You change the phases and therefore the status of the cycle by choosing Actions.
Caution
To switch from one project phase to the next, you should use only the required
action in the project or maintenance cycle. Do not use the task list to switch
project phases.
Example: In a three-system landscape, all transport requests for urgent changes
that have the To Be Tested status are in the import buffer of the production
system. If you switch the phase in the task list and not in the maintenance cycle,
the system does not issue a warning, and the urgent changes would be imported
into the production system without being tested. If you switch the phases in the
maintenance cycle, the transport requests are checked. The user is therefore
aware of the situation and can act accordingly.











**Using Texts and Text Templates
You can save recurring information as personal text templates, and insert it into your
change transactions by mouse click. Such reusable information could be a signature or
telephone numbers, for example. The system administrator can also create system
templates with standard texts, which are available to all staff (for example, standardized
prompts to indicate which information must be entered in a change request.)
Prerequisites
You have configured the Customizing settings for text management. To do this, choose
SAP Solution Manager Capabilities Change Request Management Standard
Configuration Transaction Types Text Management .
Features
Creation of personal text templates for specific users and insertion into the Texts
assignment block
Creation of system templates for all users and insertion into the Texts assignment
block
Text log: Documentation of all status changes, approvals, and other transaction
changes. You can filter the display for the content by text type.











***Using the Landscape Assignment Block
In the Landscape assignment block, you can execute various functions in conjunction
with the ABAP and Java systems connected. You can:
Display the system relevant for the current status. If the change document has
the status In Development, for example, only the development system is
displayed.
Display all systems in the system landscape. The system relevant for the current
status is displayed by default. If you choose Show all Systems, all systems are
displayed.
Log on to a connected system.
















****Using the Application Log
The application log documents business and technical information that is relevant for
processing a change document or a project or maintenance cycle.
Features
Displays various activities, such as creation and release of transport requests, and
supports navigation to the related detail information by means of double-
clicking
Displays the status for activities, for example, that a transport request does not
contain errors
Displays who triggered the activity, for example, a user, transaction, or program
Integrates messages from the task list















Maintenance Cycle
Project cycle that was enhanced to meet the special requirements of maintenance
projects. A maintenance cycle is represented by a generated task list and a transaction
that is used only for the maintenance cycle. Together, they are called the maintenance
cycle. The transaction type for this transaction is SDMN in the standard system. The
transaction is used to set and shift project phases, for example.
The maintenance of a project landscape is described by an SAP Solution Manager
project of the type maintenance. The lifecycle of a maintenance project is divided into
maintenance cycles. Within a maintenance cycle, all changes are implemented and
tested. At the end of the maintenance cycle, all these changes are imported into the
production systems. In contrast to a development project, a maintenance project has a
defined start. But since maintenance is an ongoing processes, the individual phases of
the maintenance cycle can be passed through time and again.
After the completion of the implementation project, you assign your solution a
maintenance project with a maintenance cycle so that the solution can be kept up to
date.

The maintenance cycle follows the same phase model as the project cycle but has the
following particularities:
Working with urgent changes
In maintenance operation, messages regarding incidents that have to be resolved
quickly can occur at any time, for example, when the production systems could
fail. In this case, a normal change does not enable you to respond quickly
enough because it depends on the phase of the maintenance cycle. That means
that if the maintenance cycle is in the Development without Release phase, you
cannot enter any new changes for this cycle.
Urgent changes have their own task list, which means they can be transported
irrespective of the phase of the assigned maintenance cycle (with the exception
of the go live phase). You can import corrections for an urgent change into the
production systems before the normal changes are imported in the go live phase
of the maintenance cycle.
We recommend assigning a solution a maintenance project that runs as long as
the solution is operated. Within the maintenance project, all necessary changes
are covered by maintenance cycles. The change manager specifies the duration
of a maintenance cycle, for example, one month. During this time, the cycle runs
through all project phases from Development Without Release to Go Live. At the
end of the go live phase, the cycle finishes. At this time, the cycle is checked for
open and incomplete transactions and transport requests. Incomplete
transactions are copied into a new maintenance cycle when one is created.
Structure
For information about assignment blocks, see Project Cycle.

Processing a Maintenance Cycle

This process creates and uses a maintenance cycle for normal and urgent changes,
defect corrections and administrative changes. You can edit maintenance cycles in the
WebClient UI.
Process
1. A project lead creates a maintenance cycle for a maintenance project.
2. The change manager sets the status of the maintenance cycle to Development
without Release. In this status, changes can be developed and transport requests
and tasks can be created, but not exported (except urgent changes). Urgent
changes are permitted in every phase except for Go Live.
3. The change manager switches the status of the maintenance cycle from
Development without Release to Development with Release. Transport requests
can be released from within a normal change. The administrator uses the task list
to import all released changes into test systems.
4. The change manager sets the status of the maintenance cycle to Test. If there are
normal changes whose status has not yet been set to Tested Successfully when
the maintenance cycle phase is changed from Development with Release to Test,
the system issues a warning. These changes are then excluded from the
integration test, and cannot be released.
5. During the test phase, errors are detected in the test systems, and are reported to
the developers by defect corrections. The developers correct these errors. If all
error messages have been closed, the maintenance cycle proceeds to the
emergency correction phase.
6. If changes still have to be made after the test phase has been completed,
transport requests and tasks can be created and released, as part of the
Emergency Correction phase, but only by using the task list of the Schedule
Manager.
7. In the Go Live phase, the entire project buffer is imported into the production
system. Neither transport requests nor urgent changes can be released during
this phase.
8. If there are still any open transport requests, return to the Development with
Release phase and repeat the process, including the test phase, to ensure that
any open requests can be released and transported.
9. If there are no open transport requests, you can close the maintenance cycle, by
setting the status to To be Closed. You can then create a new maintenance cycle.
Note
Normal changes can be created in the test phase of a maintenance cycle, but the
corresponding transport requests cannot be exported.
More Information
Phases in project and maintenance cycles















Processing Normal Changes
You use this process to make normal changes in your maintenance landscape, and to
implement features in your development landscape.
A normal change is a project-based implementation of a new functionality, or new
features for a specific process, for example, for bigger changes that are released on a
quarterly basis. Usually, normal changes do not comprise bug fixes.
Prerequisites
A request for change has been created and approved, and a change document of
the type Normal Change has been created. The request for change has been
released for development.
To be able to process the normal change, the assigned maintenance cycle needs
to be in the phase Development with Release.
Note
If the phase is Development without Release, you cannot export anything. You
can create transport requests and make changes in the development system, but
you cannot release transport requests.
Process
1. The lead developer who heads a team of developers calls up the change
document from his worklist in the Change Management work center or directly
from the WebClient UI, and sets the status to In Development .
2. The lead developer creates a transport request in the development system via the
Transport Management assignment block. She adapts the relevant data in the
popup, for example, the description for the transport request and whether it is a
workbench or a customizing request. She additionally creates a task for each of
the developers in her team.
3. The developers log on to the development system via the Landscape assignment
block. They implement the requested featuers in the development system.
4. When the features have been implemented, the developesr release their tasks in
the transport requests in the transport organizer transaction (se09) in the
development system.
5. The developer indicates that she has completed the change by choosing
Actions Complete Development .
She then saves the change document.
6. The system creates a transport of copies and sets the status of the change
document to To be Tested. The changes are transported to the test system.
7. The lead developer assigns the change document to the IT operator to dispatch it
to a tester.
8. The tester starts testing the correction by logging on to the test system via the
Landscape assignment block.
He checks the change in the system.
Note
The transport of copies needs to be in the test system, for the tester to see and
test the change. For more information, see Importing Transport Requests:
Options.
9. In the change document, the tester chooses Actions Successfully tested ,
to indicate that the changed function has been tested, and can be imported into
the production system. The change document is now in the status Successfully
tested.
If the test was not successful, the tester chooses Actions Reset Status to In
Development .
10. After aligning with the change manager, the IT operator imports all transport
requests into the production system. Via the document flow, he navigates to the
task list and triggers the import to the production system.
To be able to trigger the import, the maintenance cycle must be in the Go Live
phase. Only then can the transport to the production system take place.
Note
You can change phases in the maintenance cycle via the Actions dropdown list in
the change document.
More Information
Maintenance Cycle
Processing a Maintenance Cycle
More information on change management-related roles and profiles: SAP Note
834534 and Security Guide SAP Solution Manager at http://service.sap.com
SAP Components SAP Solution Manager <current release> Security Guide
SAP Solution Manager .


Processing Urgent Changes
This process makes urgent changes in your production system. This transaction is only
permitted within a maintenance cycle. The urgent change is mainly used for fast
implementation, for example, if you want to fix an error in existing functionality. The
change is transported into the production system faster than a normal change.
Prerequisites
A request for change has been created and approved, and a change document of
the type Urgent Change has been generated by the system. The request for
change has been released for development.
The request for change is linked to a maintenance project. Urgent changes can
only be used in maintenance projects.
Process
1. The change document is forwarded to the designated developer, who calls it up
in the Change Management work center, and sets the status to In Development
in the WebClient UI when he starts making the change. To do so, he chooses
Action In Development , and saves the change document.
2. The developer creates a transport request in the Transport Management
assignment block, and adapts the data in the popup displayed by the system.
3. The developer logs on to the development system directly, in the Landscape
assignment block.
4. The developer makes the urgent change in the assigned development system,
tests it, and releases his task in the transport request, in the Transport
Management assignment block.
5. The developer releases the transport request manually in the Transport
Management assignment block. The transport is exported from the development
system. No Transport of copies transport request is created, as in the Normal
Change process. For more information, see Processing Normal Changes.
6. The developer forwards the urgent change to testing, by choosing Actions
Pass Change To Test . He then saves the change document.
7. The change document is now in status To be Tested and the transport is
imported into the test system.
8. The IT operator calls up the document from the Change Management work
center, or from his worklist in the WebClient UI. He assigns the document to a
tester, who in turn can see it in his work center or worklist.
9. The tester (or another developer with a test user role) logs on to the designated
test system via the Landscape assignment block, to check the urgent change.
If the change contains no errors, the tester chooses Actions Confirm
Successful Test in the change document, which is then in status Successfully
Tested. The change manager can now change the status of the urgent change to
Authorized for Production.
If errors occurred during testing, the tester returns the change document to the
developer, by choosing Action Reset Status to In Development , so that the
urgent change can be corrected. This new change has to be tested, and the
process is repeated.
10. The change manager approves the urgent correction for import into the
production system, by choosing Action Authorize for Production , and
forwards the change document to an IT operator. The status of the document is
now Authorized for Import.
11. The operator calls up the document via the work center or his worklist in the
WebClient UI. He triggers the import of the urgent change into the production
system, by choosing Action Import to Production . The status of the urgent
change is now Productive.
12. The requester (or the change manager) confirms that the change has been made,
by setting the status of the change document to Completed.
The change document is now locked for editing, and the status of the change
request is updated to Implemented. This is only true if all follow-on change
documents related to the change request are in final status. The last change
document related to a change request that has the status Completed updates the
request for change.
Note
To import a transport request for urgent changes into parallel systems, use the
report /TMWFLOW/SCMA_BTCH_SYNC_TEST. For more information, see SAP Note
817289.
After the transport request of the urgent change document is imported into the
QA and production systems, the transport request remains in the import buffer,
so that the changes are not overwritten by other transport requests in the normal
change cycle.
Note
You can choose between two tasks list variants, with different transport
sequences into the production system: Use SAP0 if there are urgent and normal
changes in your landscape, and SAP1 if you use urgent changes only. You make
these settings in the project administration, on the Change Request Management
tab page.
Note
If you want to set multiple change documents to the next status (from Approved
for Import to Productive, for example), execute the batch job
CRM_SOCM_SERVICE_REPORT. You can also use this report to import all changes
at a scheduled time, into the follow-on systems.
More Information
Project Cycle
Processing a Project Cycle
More information on change request management-related roles and profiles: SAP
Note 834534 and Security Guide SAP Solution Manager at
http://service.sap.com/instguides SAP Components SAP Solution Manager
<current release> Security Guide SAP Solution Manager .














Administration Change Processing
An IT operator (or administrator) wants to initiate a change that does not have to be
transported with a transport request, for example, an account number or number range
change in a system. To do so, he or she creates an administration change.
Prerequisites
A change request with the scope Administration Change has been created,
approved, and assigned to a processor.
The installation for the relevant production system is assigned to the change
request.
Process
1. In the Change Management work center or in his or her worklist in the WebClient
UI, the IT operator calls up the administration change from the change
documents assigned to him or her.
2. In the administration change, he or she chooses Actions Set to "In Process"
.
The status of the change is now In Process.
3. The processor logs on to the Landscape assignment block in the assigned
development system and makes the requested change.
4. The processor returns to the administration change and chooses Actions Set
to Complete . While saving, the system changes the status to Completed.
5. The IT operator confirms that the change was made and chooses Actions
Confirm Administrative Change . The message is completed.
More Information
Creating a Change Request






Processing General Changes
You want to request a change that does not require a connection to the SAP Change
and Transport System. This can be, for example, the repair of a printer or computer in
your organization.
Prerequisites
You have created a change request and specified in the scope assignment block
that the change is to be a general change. The change request was approved and
released for implementation.
The object affected by the change is maintained in the system with an
installation.
Process
1. Depending on the type of change, the processor who is responsible selects the
change document in his or her worklist in the Change Management work center
or on the WebClient UI. It has the status In Implementation.
2. The processor documents that he or she is making the change by choosing
Actions Set to "In Process" in the change document.
3. Once the processor has made the change, he or she releases it for testing and
chooses Actions Pass Change to Test .
4. The processor documents the change and the successful test and sets the status
by choosing Actions Set to To be Documented . Following that, the
processor enters the reporting person as the next processor in the change
document.
5. The reporting person chooses Actions Set to Change Analysis to check
whether the changes were made according to the requirements.
6. If the change was successful, he or she chooses Actions Confirm General
Change . The process is thus complete and the general change has the status
Confirmed.
If the change was not successful, he or she chooses Actions Failed .
7. In case of a failed modification, it is possible to search for an alternative solution.
To do so, the processor chooses Actions Restore Source .
8. The processor marks the change as canceled by choosing Actions Set
Change to Canceled .
The change document is closed and cannot be edited further.


Error Correction Processing
You can only create error corrections during the test phase of the project cycle. Since
the error correction is used during integration testing and this testing is based on the
entire project (that is, all changes), it is not related to a specific change or a change
request. It is used to report an error identified during testing to development and to
allow the responsible developer to correct the error using a transport request. Since the
scope of the project was approved using change requests, error corrections do not
include any approval steps.
Error corrections are necessary because no new normal changes can be created in the
test phase since this would distort the specified and approved scope of the project.
Process
1. A tester wants to send a message about an error detected during testing to the
developer. He creates an error correction in the WebClient UI and describes the
observed symptoms.
2. The IT operator forwards the error correction to the developer responsible who
sets the status of the change document to In Correction.
3. The developer creates one or more transport requests and corrects the error in
the development system.
4. To submit the change for another test, the developer sets the status to To Be
Retested using the Retest Error Correction action.
5. After importing the transport buffer into the test system again, the tester checks
the functions and confirms the success by setting the status to Confirmed by
choosing the Successfully Tested action.
More Information
Project Cycle







Worklists in Change Request Management

All change transactions are displayed in worklists for the responsible employees to
approve and process them further. You can access your worklists in the following ways:
Work Center: Change Management Work Center Change Requests and
Change Documents
Note
We recommend that you use the Change Management work center as a single
point of entry to access your worklists and other related information.
SAP GUI: Depending on user authorizations, the worklists can be accessed by
using the following transactions:
Transaction Code Menu Path on SAP Easy Access Screen
S_SMC_47000018 Requests for Change Change Requests Created by Me
S_SMC_47000019 Requests for Change My Non-Completed Change Requests
S_SMC_47000020 Requests for Change Non-Completed Change Requests
S_SMC_47000021 Documents for Change Change Documents Created by Me
S_SMC_47000022
Documents for Change Change Documents to be Processed by
Me
S_SMC_47000023 Documents for Change Change Documents to be Processed
S_SMC_47000024 Documents for Change Change Docs. To Be Proc. w/o Prcssr
You can open any change request or change document by double-clicking on it
in the relevant worklist. The system then opens the change transaction in the
WebClient UI .
SAP Business Workplace: On the SAP Solution Manager entry screen, choose SAP
Business Workplace. The inbox contains any change transactions you are to
process.
WebClient UI: You can access your change transactions by choosing Worklist in
the navigation bar.



Creating a Request for Change
A problem has been detected in a system. No support message has been created, but
you want to create a request for change anyway.
Prerequisites
You have the role SAP_CM_REQUESTER.
If you want to create requests for change from templates, you have created a
template. For more information, see ##Creating a Template for Requests for
Change.
If you want to create requests for change from a solution, you have selected the
check box Using Change Request Management, on the Solution Settings tab
page in the solution directory.
Procedure
Creating a Request for Change from the Change Management Work Center
1. Go to the Change Management work center.
2. Choose New Request for Change.
The WebClient UI is started.
3. Make an entry in the mandatory fields, or choose an appropriate option:
o Description
o Customer
o Reporter
This field should be prefilled with your business partner, but you can
change it.
o Change Manager
Enter the business partner of the change manager responsible for
approving or rejecting the request.
o Approval Procedure
By default, the CR Approval Procedure is selected.
4. On the Text assignment block, describe the change to be implemented.
5. Choose Save.
Creating a Change Request from a Template
1. Go to the Change Management work center.
2. Choose New Request for Change.
The WebClient UI is started.
3. Choose New from Template.
The system displays the search help for templates for requests for change.
4. Select the template on which to base your request.
5. Complete the request by making entries in the mandatory fields or choosing
options, as described above.
6. Choose Save.
Creating a Request for Change from a Solution
1. In the solution for which you want to create a request for change, go to a
structure element, for example, a business process.
2. Go to edit mode.
3. Choose Create Request for Change and confirm the popup.
The WebClient UI is started.
4. Follow the procedure for creating requests for change from the Change
Management work center, and continue from step 3.
Creating a Request for Change from a Job Request
1. In the Job Management work center, choose an existing job request for which
you are the processor. Select a job request, and choose Display or Edit.
The system displays the job request document.
2. Choose Actions Create Request for Change , in edit mode
3. When you save, the system creates a request for change.
You can now call up the request for change by choosing it from the Change
Management work center, or directly from the WebClient UI. The system has
transferred data from the job request to the request for change, for example, the
description and the processor. The request for change has the scope
Administrative Change assigned, and its predecessor is the original job request.
You can display this information in the corresponding assignment blocks.
You can now complete the request for change with more details.
Creating a Request for Change from an Incident
1. In the incident in the WebClient UI, choose Create Follow-Up and select Request
for Change.
The system generates a new request for change. It contains data from the
incident, for example, the number of the incident in the Relationships assignment
block and the installed base in the Scope assignment block.
2. Complete the request for change with more details.
3. Save the request for change.
Result
A request for change has been created and assigned to a change manager for
validation. The status of the request is Created. The change manager will get the change
request via his worklist, for validation and approval.
More Information
Worklists in Change Request Management
0Validating a Request for Change
00Approving a Request for Change
000Rejecting a Request for Change
0000Edit Job Scheduling Change Document

##Creating Templates for Change Requests

If you often create change requests with the same data in your projects, you can create
templates with the data that is always contained in your change requests. This allows
you to minimize the time required to create a change request.
Note
Similar to change requests and change documents, templates for change requests are
also based on business transactions. The transaction type provided for the change
request template in the standard system is SMCT. Your settings are the same as those
for the change request (SMCR), but there is a separate status profile and a separate date
profile, allowing the validity of a change request to be specified.
Prerequisites
You have configured the Customizing settings for the change request template.
Procedure
1. In the navigation bar of the WebClient UI, choose Change Request
Management Change Request Templates .
On the following screen, you can search for existing templates or create a new
template.
2. Choose New.
The system displays a blank input screen for a change request.
3. Enter all the data that is supposed to be part of your template and that you often
need to create change requests, for example, the change manager, the change
advisory board, and standard documents. Give your template a name.
4. In the Dates assignment block, specify the required validity of the template.
5. Choose Actions Release .
The template can now be used (or can be used as of the validity period) to create
change requests. You can later modify the template again, and invalidate it or
fully close it if required.
6. Choose Save.
Result
You have created a template for change requests. You can now display it in the search
for templates for change requests and use it for creating change requests.
More Information
Creating a Change Request




0Validating a Request for Change

As a result of a problem, a change needs to be implemented in a production system. For
this purpose, a request for change has been created by a service desk employee. This
request has to be validated by a change manager.
Prerequisites
A request for change has been created that documents the problem.
In Customizing for SAP Solution Manager, you have defined the production
system where the urgent change has to be implemented. For more information,
see SAP Solution Manager Capabilities (Optional) Service Desk .
You have the SAP_CM_CHANGE_MANAGER role.
Procedure
1. On the Change Management work center, choose the requests for change, to
which you have been assigned as the change manager responsible.
A list of all requests for change assigned to you is displayed.
Note
There are several options to display and access your worklists. For more
information, see Worklists in Change Request Management.
2. Select the request for change that you want to validate.
The system opens the request in the WebClient UI.
3. In the Details assignment block, choose Edit .
4. To indicate the status of the request, choose Actions Validate Request for
Change .
5. Review the data that has already been entered for the request.
6. To categorize the request, go to the Scope assignment block and choose Edit,
then Insert
7. In the Change Category field, select a category from the dropdown list, for
example, Urgent Change.
The system displays the transaction type for this category and the current status.
8. Select the relevant installed base of the production system where the change will
be done from the search help.
9. You can now add more information to the request, for example, the project and
solution to which the change should be assigned. On the Details assignment
block, choose Edit.
10. In the Project field, select the project to which you want to assign the change. If
there is only one solution for the project, the solution is displayed automatically.
If there are several solutions, select the relevant one from the search help.
In the Projects and Solutions assignment blocks, you can add more project
objects and solution elements to the requests, to further specify the relevance.
11. Enter other information into the request, for example, the urgency of the change.
You can also assign relevant documents, knowledge articles, and so on, in the
dedicated assignment blocks.
12. Choose Save.
The system sets the status of the request to Validation.
13. Choose Actions Release for Approval to have the request for change
approved by the employee responsible.
The system sets the status of the request to Awaiting Approval.
More Information
Approving a Request for Change
Rejecting a Request for Change









00Starting the Approval Process and Approving a Request for Change

A request for change, for example, for an urgent change, has been validated by a
change manager, who has also added more information to it. It now needs to be
approved in order to create follow-on change documents.
Prerequisites
A request for change has been created that documents the problem.
It has been validated and has the status Released for approval.
All business partners that are supposed to approve the request for change have
been inserted into the Approval assignment block.
You have the SAP_CM_CHANGE_MANAGER role.
Procedure
1. In your worklist, choose the work item to approve a request for change. For
example, on the WebClient UI, select a workitem and choose Execute.
2. Go to the Related Transactions assignment block and choose the request for
change.
The system opens the request.
3. Review the contents of the request for change. Note that all mandatory fields
need to be filled so that the request has the status Approved.
4. In the Activity column, choose the dropdown list and select the entry Approved.
Note
All business partners entered as approvers in the Approval assignment block
need to approve the request. If one approver rejects the request, the whole
request is rejected.
It is possible to choose the activity Not relevant. In case all approvers choose this
activity, the request for change remains in the status Awaiting approval.
5. Save the request for change.
The system sets the status of the request to Approved. To release the request for
further processing, choose Edit, and then Actions Release for Development
.
More Information
Using Approval Procedures




















00Using Approval Procedures

You can use approval procedures to control the approval process for change requests.
In an organization, certain processes must be approved by responsible persons before
they can be finalized. For example, a change request must first be approved before an
urgent or normal change can be made.
Approval procedures can be edited manually or integrated into the workflow. For all
information relevant to the approval of a change request, see the Approvals assignment
block of the respective change request.
Prerequisites
In Customizing, you have maintained the Approval Settings in SAP Solution Manager
Capabilities .
Features
In the header data of the change request, you assign the approval procedure. By
default, the approval procedure CR Approval Procedure is suggested for use.
The following functions are available in the Approvals assignment block:
o You can monitor the approval steps and the corresponding information.
For example, you can see which business partner has approved the
respective step and when the approval took place.
o The change manager is entered as the approver by default. You can also
add other approvers.
o The parties involved in the change request enter their approval activities.
Here, the options Approved, Not Relevant, and Rejected are available. The
approvers can add additional comments to the activity, for example,
explanations of a rejection.
o As long as the status of the change request has not been set to Approved,
you can add additional or remove existing approval steps and approvers.
In the Change Management work center, you see the change requests awaiting
approval that are assigned to you.
You can use workflow functions for the change request approval process so that
approvers are informed when change requests should be approved.
Activities
1. A service employee creates a change request and the change manager classifies
it, for example, as a normal change.
2. The change manager checks the request and releases it for approval. The change
request has the status Awaiting Approval. The system thus starts the approval
procedure.
3. As soon as all approval steps have been completed, the change request has the
status Approved and the change documents for the change request are
generated.
More Information
Processing Change Requests

















000Rejecting a Request for Change

A request for change has been created. In your position as change manager, you have
decided that the problem is not serious enough to warrant an urgent change. You now
have to reject the request in the Service Desk.
Prerequisites
A request for change has been created that contains information about the
problem.
You have the SAP_CM_CHANGE_MANAGER role.
Procedure
1. In your worklist, choose the workitem to approve or reject a request for change.
For example, on the WebClient UI, select a workitem, and choose Execute.
2. Go to the Associated Business Objects assignment block and choose the request
for change.
The system opens the request.
3. Review the contents of the request.
4. In the Activity column, choose the dropdown list and select the entry Rejected.
You can add comments to explain the reasons for the rejection.
5. Save the request for change.
The system sets the status of the request to Rejected.








0000Editing Job Scheduling Change Documents

You want to edit a request to change or create job documentation using Change
Request Management.
Prerequisites
The following conditions are satisfied:
The change manager has approved a change request based on a job request, and
created a change document.
The Job Scheduling Management assignment block is configured in the Web
client.
You have opened the job request in change mode.
Features
You can edit change documents for job scheduling in the Job Scheduling Management
assignment block of the WebClient UI.
You can use this assignment block for all change document types.
By default, the system uses the Administrative Change change document for job
scheduling.
Activities
You determine Administrative Change in one of the following ways:
You call the Web client (transaction CRM_UI).
1. You choose Change Request Management Change Document .
2. You select transaction type SMAD, for example, as the search criterion (for
theAdministrative Change).
You use the Job Management work center.
1. Choose the Job Request view.
Your personal object worklist (POWL) is displayed. For more information,
see Using the Job Request Overview.
2. You click on an entry in the CRM Document column. The system starts the
Web client.
More Information
Editing Change Requests
Change Request
Change Document
For more information about using the WebClient UI, see SAP Help Portal at
http://help.sap.com/crm SAP CRM 7.0 Application Help SAP Customer
Relationship Management Getting Started with the WebClient UI .

Creating a Request for Change
A problem has been detected in a system. No support message has been created, but you want to create a request for
change anyway.
Prerequisites
You have the role SAP_CM_REQUESTER.
If you want to create requests for change from templates, you have created a template. For more
information, see Creating a Template for Requests for Change.
If you want to create requests for change from a solution, you have selected the check box Using Change
Request Management, on the Solution Settings tab page in the solution directory.
Procedure
Creating a Request for Change from the Change Management Work Center
1. Go to the Change Management work center.
2. Choose New Request for Change.
The WebClient UI is started.
3. Make an entry in the mandatory fields, or choose an appropriate option:
o Description
o Customer
o Reporter
This field should be prefilled with your business partner, but you can change it.
o Change Manager
Enter the business partner of the change manager responsible for approving or rejecting the
request.
o Approval Procedure
By default, the CR Approval Procedure is selected.
4. On the Text assignment block, describe the change to be implemented.
5. Choose Save.
Creating a Change Request from a Template
1. Go to the Change Management work center.
2. Choose New Request for Change.
The WebClient UI is started.
3. Choose New from Template.
The system displays the search help for templates for requests for change.
4. Select the template on which to base your request.
5. Complete the request by making entries in the mandatory fields or choosing options, as described above.
6. Choose Save.
Creating a Request for Change from a Solution
1. In the solution for which you want to create a request for change, go to a structure element, for example, a
business process.
2. Go to edit mode.
3. Choose Create Request for Change and confirm the popup.
The WebClient UI is started.
4. Follow the procedure for creating requests for change from the Change Management work center, and
continue from step 3.
Creating a Request for Change from a Job Request
1. In the Job Management work center, choose an existing job request for which you are the processor. Select
a job request, and choose Display or Edit.
The system displays the job request document.
2. Choose Actions Create Request for Change , in edit mode
3. When you save, the system creates a request for change.
You can now call up the request for change by choosing it from the Change Management work center, or
directly from the WebClient UI. The system has transferred data from the job request to the request for
change, for example, the description and the processor. The request for change has the scope
Administrative Change assigned, and its predecessor is the original job request. You can display this
information in the corresponding assignment blocks.
You can now complete the request for change with more details.
Creating a Request for Change from an Incident
1. In the incident in the WebClient UI, choose Create Follow-Up and select Request for Change.
The system generates a new request for change. It contains data from the incident, for example, the number
of the incident in the Relationships assignment block and the installed base in the Scope assignment block.
2. Complete the request for change with more details.
3. Save the request for change.
Result
A request for change has been created and assigned to a change manager for validation. The status of the request is
Created. The change manager will get the change request via his worklist, for validation and approval.
More Information
Worklists in Change Request Management
Validating a Request for Change
Approving a Request for Change
Rejecting a Request for Change
Edit Job Scheduling Change Document