Many users know that they can use the Change Request Management (ChaRM) functionality for tighter control of their change management processes, more accurate reporting, and less risk during the life cycle of maintenance projects. What users might not know is that they can use ChaRM to manage changes for an implementation project from the planning phases to the physical deployment of those changes within your landscape. Based on my experience, I’ll describe all the phases of a ChaRM implementation project cycle, including the actions that can be performed during each phase. I discuss the four relevant SAP Customer Relationship Management (SAP CRM) Service transaction types that are major parts of any ChaRM implementation. Particularly, I analyze the role that a normal correction, an SAP CRM Service transaction type, plays in a ChaRM implementation and the challenges it poses for every member of an implementation team. I finish with some ideas about how to support complex landscapes within ChaRM and the pitfalls that could arise during an implementation. Even with the additional effort involved with the setup and maintenance of ChaRM, there are many benefits for using it to support your implementation projects. Using ChaRM, a developer or configurator can perform a test transport and then migrate this new transport to the test environment without releasing the original transport. In this case, the original transport has not been released. Therefore, it maintains the lock so that cross-project changes need to be coordinated. Also, if defects are found during testing, the developer or configurator can make the necessary fix in the development system and store this change to the original transport under a new task. This reduces the overall number of transports for projects to make cutover for the projects easier and quicker. Having all of the fixes contained within the same transport helps to reduce the risk of migrating something out of sequence or missing something entirely. Tighter control over releasing and importing transports forces you to re-think bad habits and allows for easier tracking and reporting of what is in a release. Also, there is an extremely good audit trail on both the change document itself as well as the project.

How to Start a ChaRM Project

A project manager can activate ChaRM on a project-by-project basis by creating a Solution Manager project via transaction SOLAR_PROJECT_ADMIN or by going to System Landscape>Change Requests after completing the prerequisite setup steps. You can find this documentation in the Solution Manager IMG, which you can access via transaction SPRO. When the project manager activates ChaRM for a project, it creates an IMG project — if one is not already completed beforehand — in the development system defined in the Solution Manager project in the Landscape tab. The development system automatically activates the Change and Transport System (CTS) project functionality from the IMG project. It also automatically creates a project cycle for the Solution Manager project and links a task list to this project cycle. You access this project cycle or task list from within Solution Manager via transaction SOLAR_PROJECT_ADMIN. This begins the project cycle, which you can read more about in the “Project Cycle Stages” sidebar, which appears at the end of the article.

SAP CRM Service Transaction Types

Before I go into the steps in the process, you should know about the SAP CRM Service transaction types that ChaRM uses. These are a core feature available from SAP CRM that comes with the Solution Manager installation. SAP CRM Service transaction types are business objects or transactions related to service functions. They allow you to perform some type of business activity action — change documents in my example. The transaction types use SAP CRM actions to perform these functions, including the Post Processing Framework (PPF), a Basis component that can be automated with the initiation of outputs, follow-on documents or workflows. ChaRM also uses SAP CRM Service transaction types to document, manage, implement, and migrate changes within an SAP landscape using the back-end Transport Management System (TMS) tool. A key component of TMS is a container called a transport, which is where changes in the SAP system are stored. These transports are linked to a CTS project within the satellite (Figure 1). The developer or configurator assigned to a normal correction assigns the changes to the transports. These transports can be associated to the correct Solution Manager project based on the linkage to the IMG and CTS project. Each SAP CRM Service transaction type is associated with a four letter character identifier that gives it uniqueness and identifies it as a certain type of change document. The identifier is not a transaction code. It is the internal representation of the business transaction, or document in our case. An example of this is the identification of the change request as SDCR. For an implementation project, there are four relevant SAP CRM Service transaction types: Change request (SDCR): Documents the change required, the system it affects, and the impact to the systems. It then classifies the type of change and the relation to what type of project. When the change manager approves the change request, it creates a follow-on change transaction (Figure 1). The change request and the change transaction maintain a one-to-one relationship. The subject field on the change request identifies the relation to what type of project the change transaction is linked to and the SAP CRM Service transaction type that is created once approved. The follow-on change transaction (SAP CRM Service transaction type) can be a normal correction, administration message, or test message based on the subject of the change request. Normal correction (SDMJ): A document that one or more developers or configurators use to create their transports, make their changes, and then subsequently test, release, and migrate their changes throughout the SAP landscape. Each project can have as many normal corrections as required. Multiple developers can share a normal correction, and create multiple transport requests and transport tasks. You use this change transaction the most during your implementation project. Administration message (SDAD): Documents changes made in your SAP environment and does not require a transport, such as a manual configuration change, kernel patch, or database patch. This allows users to document and manage the rest of the changes that occur in an SAP environment in a consistent, thorough manner. Test message (SDTM): Can only be created if the project phase and cycle are in the test phase. This allows a configurator or developer to fix any defect found during testing and to migrate changes to the test environment without any additional approvals. There is a misconception that ChaRM can only be used to support the production support process for maintenance projects, but I will walk you through the process of approving, managing, and migrating a normal correction through the SAP landscape within an implementation project.

Normal Correction and Implementation Project Process Steps

A project team needs to take the following steps to create, approve, manage, and migrate a normal correction through the SAP landscape during an implementation project. These steps only focus on the process for a single normal correction in an implementation project, but a typical project has multiple normal corrections. This normal correction is similar to a document that contains status values associated to where it is in the process. The process flow for status values for a normal correction is depicted in Figure 2. To complete this example, you need the following roles: project manager, ChaRM administrator, change manager, requestor, developer, tester, and IT operator.   Step 1. Create a Solution Manager project. The project manager begins this first step of the journey using transaction SOLUTION_MANAGER. Figure 3 shows the screen used in creating or changing a project. Step 2. Activate ChaRM for the project. The ChaRM administrator completes this via transaction SOLUTION_MANAGER. The system then creates the project cycle, CTS project, and task list. The project cycle phase is initially set to Development without Release by the system. Also, the administrator changes the task list as needed and unlocks the tasks associated to the activities allowed for each of the systems (Figure 4).   Step 3. Create a change request with the appropriate subject/priority set. The requestor completes this via transaction CHARM_CREATE. In my example, I set the subject to Normal Correction (Implementation) and the default status of the change request to To Be Approved (Figure 5).   Step 4. Run transaction CRM_DNO_MONITOR in Solution Manager. The change manager picks up the change request with the To Be Approved status, and then reviews the change that is required. He validates the system, priority, and subject defined in the change request. Then he approves the change request by selecting the action Authorize Change Request in the action toolbar while in the change request and clicks the save button (Figure 6). The change request status is set to Authorized, and the system creates a normal correction with a status of Created and links it to the change request. The setting for the project cycle phase is still Development without Release.   Step 5. Run transaction CRM_DNO_MONITOR in Solution Manager. The developer picks up the normal correction with the Created status, and then reviews the change that is required. Then the developer takes the normal correction in process by selecting the action Set to In-Development in the action toolbar while in the normal correction and clicks the save button. This sets the status to In-Development. The setting for the project cycle phase is still Development without Release. Step 6. Execute action Create Transport Request in the action toolbar. The developer does this while in the normal correction, which creates a transport request in the corresponding development system based on the system defined in the installed base (IBase) field in the normal correction (Figure 7). The developer can create as many transports or tasks as needed. The project cycle phase setting is still Development without Release. Step 7. Execute the action Login to System in the action toolbar. This happens while in the normal correction, which logs the developer into the development system. While in the development system, the developer makes the necessary change based on what was requested. This change could be a new program created in the ABAP Workbench or a configuration change made in the project’s IMG. When prompted for the transport request, the developer selects the transport request created in the previous step to store the change. When the developer has completed the unit testing by executing predefined test scripts in the system, he releases the task in the transport related to the change. He only releases the task and not the transport. The setting of the project cycle phase is still In-Development w/o Release. Step 8. Run transaction SOLAR_PROJECT_ADMIN. The project manager then clicks on the Display task list button under Landscape Management>Change Requests. While in the task list, he sets the project cycle phase to Development with Release via the Change Phase button. The project cycle phase setting is now Development with Release (Figure 8).   Step 9. Execute action Complete Development in the action toolbar and click the save button. The developer does this while in the normal correction, which creates a new transport with copies of the changes made in the original transport. This is called a transport of copies and does not require the developer to release the complete original transport, only the task associated to the original transport. This action releases the new transport (transport of copies) to the follow-on SAP system, generally a quality assurance (QA) system. This transport is a single destination transport. This means that once it is imported into the QA system, it does not populate the follow-on system, generally a production system. This helps reduce the overall number of transports for a project. The original transport also contains all of the fixes needed via different tasks, so nothing is missed in the follow-on systems. Set the status of the normal correction to To Be Tested. Keep the project cycle phase set to Development with Release. Step 10. Import the transport of copies into the follow-on QA system. The IT operator runs transaction SOLAR_PROJECT_ADMIN and selects the display task list button assigned to the project. While in the task list, the IT operator selects and executes the task Import Transport Request (Background) under the QA system. This import uses the standard TMS functionality provided by the QA system to import the transport via the import project method, which imports all transports in the buffer for that particular project. This method quickens the process because it starts on one phase and executes for every transport before going on to the next phase. The IT operator can schedule the imports to run as many times as your project requires. The project cycle phase setting is still Development with Release. Step 11. Log in to Solution Manager and runs transaction CRM_DNO_MONITOR. The tester picks up the normal correction with the To Be Tested status and then reviews the test scripts. The tester performs the test scripts in the QA system and documents the test results. If the test was successful, he updates the status in the normal correction by selecting the action Confirm Successful Test in the action toolbar while in the normal correction and clicks the save button. This sets the status to Consolidated. This action also releases the original transport and adds it to the buffer of the follow-on QA system, which means that it can now be imported containing all changes needed so that the final integration test can be performed. The setting of the project cycle phase is still Development with Release (Figure 9).   Step 12. Run transaction SOLAR_PROJECT_ADMIN in Solution Manager. The project manager then clicks on the Display task list button under Landscape Management>Change Requests. While in the task list, he sets the project cycle phase to Test via the Change Phase button. Remember that at this phase the project cannot have any more normal corrections associated to it. To enter fixes into this system during this phase, the requestor or developer needs to create a test message (Figure 10).   Step 13. Import the transports into the follow-on QA system. The IT operator runs transaction SOLAR_PROJECT_ADMIN and selects the display task list assigned to the project. While in the task list, he selects and executes the task Import Transport Request (Background) under the QA system. This import uses the standard TMS functionality provided by the QA system to import the transport via the import project method. When this import is successful, the system adds the transport to the production buffer. Keep the project cycle phase set still to Test. Step 14. Run transaction SOLAR_PROJECT_ADMIN. The project manager then selects the Display task list button under Landscape Management>Change Requests. While in the task list, he sets the project cycle phase to Go-Live via the Change Phase button. The project cycle phase setting is now Go-Live (Figure 11).   Step 15. Import the transports into the production system. The IT operator runs transaction SOLAR_PROJECT_ADMIN and selects the Display task list button assigned to the project. While in the task list, he selects and executes the task Import Transport Request (Background) under the production system. This import uses the standard TMS functionality provided by the production system to import the transport via the Import Project method, which imports all transports in the buffer for that particular project. The project cycle phase setting is still Go-Live. Step 16. Run transaction CRM_DNO_MONITOR to pick up the normal correction with the Consolidated status. The change manager then reviews it to make sure that all post steps were completed. Then he executes the action Set Production Status using the action toolbar while in the normal correction and clicks the save button, which sets the status to Production. Also, he switches to the change request linked to the normal correction by clicking on the corresponding change request in the document linking section. The change manager executes action Confirms Realization using the action toolbar while in the change request and clicks the save button, which sets the status to Confirmed, meaning that the document is unchangeable (Figure 12).   Step 17. Log in to the system and runs transaction SOLAR_PROJECT_ADMIN. The project manager then selects the Display task list button under Landscape Management>Change Requests. While in the task list, he sets the project cycle phase to Being Completed via the Change Phase button. After you’ve performed all the checks for the cutover of the project, set the project cycle phase to Being Completed (Figure 13).