Show TOC

Process documentationProcessing Requests for Change Locate this document in the navigation structure


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


  • You have configured the Customizing settings under   SAP Solution Manager   Capabilities   Change Management   Change Request 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   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 Transactions in Project Administration.


  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 request for change.

    In SAP Solution Manager, he/she opens the Change Management work center, from which he/she can start the WebClient UI directly.

    Note Note

    The service employee 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.

    End of the note.
  3. The system displays the request for change in the worklist of the responsible change manager. He/she can see the request for changes 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 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 manager assigns a project and, optionally, a solution to document the changes, to the request for change. 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. Then, he releases the request for change for approval.

  4. The request for change must be approved before a change document can be created. In the standard system, the change manager is entered as the approver – however, you can also enter an additional business partner (such as the change advisory board), if required.

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

  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 , it can be transported through the system landscape to the production system.

  8. The change manager completes the request for change. If all change documents for a request for change have been fully processed, the request for change is also completed.