0 оценок0% нашли этот документ полезным (0 голосов)
173 просмотров47 страниц
A change request is used to request changes to software or systems. It passes through an approval process and can be categorized. If approved, change documents are created from the request to document the development, testing, and implementation activities. Change requests and documents are integrated in SAP Solution Manager for managing the entire change process.
A change request is used to request changes to software or systems. It passes through an approval process and can be categorized. If approved, change documents are created from the request to document the development, testing, and implementation activities. Change requests and documents are integrated in SAP Solution Manager for managing the entire change process.
A change request is used to request changes to software or systems. It passes through an approval process and can be categorized. If approved, change documents are created from the request to document the development, testing, and implementation activities. Change requests and documents are integrated in SAP Solution Manager for managing the entire change process.
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