Processing Requests for Change

The process describes how you can create, edit, approve, and implement requests for change. 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 requests for change:

Requester: creates a message or creates a request for change straight away
Service employee: Edits the message and creates the request for change
Change manager: categorizes, prioritizes, approves, and monitors requests for change
Change advisory board: steering committee in the change process that approves the budget and scope for requests for change
Developer: implements changes and passes them to the tester
Tester: tests changes and confirms the status in the change document
Administrator: advances the phases of the cycle and imports project-related changes
IT operator: takes care of software logistics

Note Note

For more information on user roles in Change Request Management, see Start of the navigation path SAP Solution Manager Configuration Next navigation step Change Control Management Managed System Setup Step 7.1 Create Managed System Template Users End of the navigation path .

End of the note.

Prerequisites

You have configured the Customizing settings under SAP Solution Manager Capabilities Change Control Management .
The users in the change management process have the required authorization. To do so, system administration has created user roles that include these authorizations and assigned these roles to the 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 change control landscape in SAP Solution Manager, activated change control management, and created a change cycle. See Configuring Change Request Management and Solution Documentation.

Process

This graphic is explained in the accompanying text.

A user working in a product system discovers a change requirement in a transaction that he/she uses, for example, an error or a missing function. The processor can now create a message directly from the transaction, allowing them to describe the situation and request a change.
The message appears in the worklist or the widget of a service employee who processes the message and creates a request for change.

Note
The processor can create the request for change from scratch, or from a template from which the available information can be copied. He can also create a follow-up document from an incident or a problem.

End of the note.
The system displays the request for change in the worklist of the responsible change managers. They can see the requests for change and change documents for which they are responsible. The change managers are responsible for prioritizing the request according to its impact (for example, high, medium, or low) and to define its scope. They also specify for which systems the change is relevant.
The type of the change document determines the scope. You can define your own change document types in Customizing, or use the change document types supplied by SAP:
If the error is serious enough to justify a correction, the change managers assign a change cycle to the request for change. The change managers can also assign solution documentation elements, test cases, and additional information relevant to the change process, such as which business process is affected. Then, they release the request for change for approval.
The request for change must be approved before a change document can be created. In the standard system, the change managers are entered as the approvers – however, you can also enter an additional business partner (such as the change advisory board), if required.
Once the request for change is approved, a change document is generated automatically. In the following work steps, the change document is the operational basis for developers, testers, and IT administrators, and passes through different phases, which depend on the type of the change document.
A request for change can still be changed or extended after its approval. You can add further change documents, for example.
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 managed system 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.
As soon as the tester has tested the change , it can be transported through the system landscape to the production system.
The change managers complete the request for change. If all change documents for a request for change have been fully processed, the request for change is also completed.