Show TOC

Process documentationProcessing Change Requests Locate this document in the navigation structure

 

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

  • Requester: creates a problem message or creates a change request straight away

  • 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 passes them to the tester

  • Tester: tests changes and sets the 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 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 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.

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 from a 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 scope. You can define your own change document types in Customizing, or use the change document types supplied by SAP:

    The change manager assigns a project and, optionally, a solution to document the changes, to the change request. 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 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, you can also enter an additional business partner (such as the change advisory board), if required.

  5. Once the change request 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 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 , it 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