To understand Change Request Management (ChaRM), you first need to know where it fits into SAP Solution Manager. SAP Solution Manager has grown from simply a gateway to SAP support to a complete IT management solution. The tools covered by SAP Solution Manager are divided into three major groups called scenarios (Figure 1). The implementation scenario covers the project design (i.e., Business Blueprint), test planning, training planning, and documentation (using a powerful centralized knowledge warehouse). The optimization scenario covers the changes to the system (e.g., maintenance, enhancements, and bug fixing) as well as Service Desk functions. Change Request Management (ChaRM) is part of the optimization scenario. Finally, the operations scenario covers system management, including monitoring tools for both technical and functional teams, batch processing management, and Root Cause Analysis.  

Figure 1

SAP Solution Manager scenarios

Before ChaRM, changes in SAP were managed only through transport requests. A developer would make a change in a program or a configuration in a developing system. He would then record this change in a transport request that was released and transported to a test system. The test team performed integrated tests and regression tests (to check the impacts of the change in running solutions). If the test failed, the developer had to fix the issues, save the fix in another transport request, and transport it to the test system again. In the end, hundreds or thousands of transport requests had to be organized, classified, and transported to the final production system.

To manage this complex flow and all its variables, project managers used spreadsheets, operated an approval workflow (usually via email), and performed several hours of checking, double-checking, and sorting. Common problems included transport issues, missing objects, or incorrect sequences — problems that can delay an entire project. Worse, there was no real control on the process sequence: developers could change, release, and transport any number of requests at any time.

This scenario already sounds complicated, but it actually only takes one project into account. Companies usually have several projects running in parallel, with several teams and developers creating and transporting many transport requests. Managing this by controlling each and every transport request demands a huge effort.

ChaRM introduces project-based change control. With it, changes are not only managed at the transport request level but also grouped into so-called corrections (i.e., a set of related modifications), which are then grouped into projects. Only entire corrections, or even entire projects, are transported; single changes are not. You can manage entire project transports in several ways, depending on the correction type. In this article, I’ll explain how this management takes place using the appropriate correction type, which is defined by how urgent the change is to the organization.

Using ChaRM, only designated team members are allowed to create transport requests and only at certain project phases. They can create tasks that developers use to save their changes. These developers are only allowed to release their own tasks, not release requests. The requests are released at a specific moment (usually this moment is determined by the project manager or the governance team) and transported together by the individual responsible (usually a project manager). It is also possible to restrict access to project systems based on project phases. For example, you could configure it so the developer could only log in to the development system through SAP Solution Manager, using only the correction to which he was assigned, and only in the development phase. He would not be able to log in to the test system because this system is assigned only to testers.

In this article, I show you how ChaRM works with changes, managing every step from planning to production and segregating the urgent from the planned in your system. I also explain how you can manage complex projects with minimal impact on your running landscapes, and how ChaRM enhances the object lock control that gives developers and project leaders control over every single object that is created or changed in SAP. Finally, I provide advice on both the challenges and benefits that ChaRM can provide for an organization.

Corrections in ChaRM

Figure 2 shows a standard normal correction workflow. You can see how each player is inserted into the change context. Note that all of the players are defined by the change manager during the project planning.

Figure 2

Correction workflow

ChaRM has two types of corrections, urgent and normal. The names speak for themselves: urgent corrections are used on changes that urgently need to reach production systems, while normal corrections are used on changes that demand deeper management and can go live in a planned schedule. Here is some more information on the two types of corrections:

• Urgent corrections are used to manage short, critical, and quick changes. Examples of these changes are mandatory legal modifications (e.g., news in Sarbanes-Oxley regulations), critical SAP Notes implementations, and small corrections that need to reach production systems quickly.
• Normal corrections generally involve phased projects (I explain the project phases and how they help managers to control the entire project life cycle later in this article). These corrections can take longer to reach production systems and demand deeper management. The projects are often composed by several functional teams, developers, and other players. Such projects are created in the tool by change managers, who assign the other team members to these projects before the project starts.

One of the main problems faced by SAP change managers is abandoned changes. Abandoned changes refers to situations in which a developer performs changes, saves them into transport requests (and perhaps even transports them to test systems), but doesn’t take them to the production system. This is usually because the user didn’t test them, but sometimes the developer simply forgets about the change.

To alleviate this problem, ChaRM allows you to withdraw changes or erase change documents that were created by mistake. Note that withdrawing urgent corrections is possible only if there are no transport requests assigned to the change document or the transport requests are still empty. In addition, after a normal correction’s status becomes test confirmed, withdrawing the change into development or withdrawing a whole change transaction is impossible. Developers actually need to undo these changes to prevent them from reaching productive systems. In this way, the ultimate change manager nightmare — changes abandoned en route to production — can be completely avoided.

Normal corrections allow development (and therefore the creation of transport requests) only in the development phases of a project, while urgent corrections allow development up to the go-live phase. Therefore, the phase is ignored by ChaRM if an urgent correction is performed. In normal corrections, it is possible to create several transport requests. However, this is not recommended by SAP because one of the major benefits of ChaRM is reducing the amount of transport requests. In urgent corrections, only one transport request per type can be created — one for configurations and one for developments because the type of object differs. This significantly reduces the number of transport requests created during projects.

In normal corrections with the status in development, you can only perform test transports. These test transports are not performed using the real transport requests, but rather with copies that are transferred to the consolidation (test) buffer system where tests take place before the real transport request is released and transported. In urgent corrections, requests can be released almost anytime. They can be released during all project phases — except for go-live and subsequent phases (e.g., a production or post-production checklist phase).

Function groups (a subset of common project tasks such as transport request release, transport request import, and project phase switch) within the task list of normal corrections must be unlocked by the administrator before team members are allowed to execute these tasks. In urgent corrections, these function groups are open by default. The task list is a project control panel of sorts that allows for the management of project tasks (such as release requests, transport requests, change phases, and the analysis of project logs). You can also execute most of these tasks using a workflow-based document (known as a change document) on which the project teams have controlled access depending on the role they play and the correction status. The task list is restricted to the person responsible for the project, usually the project manager.

To finish a correction, you must switch its status to production. For normal corrections, switching to the production status is only possible when the transport requests related to the change transactions are successfully imported into all production systems in the relevant SAP system landscape (also known as project tracks). For urgent corrections, switching to the production status is possible when the transport requests related to the correction are successfully imported into the production system. The difference is that for normal corrections, all transport requests for all corrections must be imported together. For urgent corrections, all transport requests for a single transaction must be imported to allow the switch to the production status.

You can import normal corrections using the import project method from within the cycle task list (only the person responsible for the project, such as the project manager, can perform this task), and all exported transport requests are imported with the import project method (Figure 4, which appears later in this article, illustrates this transport control). You can only import transport requests once into each project system with the role type Target (test) or Production. Importing into production systems with the import project method can be performed only during the go-live phase.

For urgent corrections, you can set the status as to be tested. Imports into the test system can be automated in all cycle phases, starting at the beginning of development. The transport requests are imported by correction, not by project — which means that single corrections can be imported.

Urgent corrections are managed as one single correction. Switch all urgent corrections that are released for import into the production environment to the released for import status so that when the person responsible for the changes executes the import into production action, this will be performed for all selected urgent corrections. Figure 3 shows the transport dynamics of urgent and normal corrections.

Figure 3

Transports within normal and urgent corrections

All transport requests assigned to urgent corrections are kept in the production transport buffer after they are imported to that system. They are imported again when the corresponding project is imported. Urgent corrections are also part of a project, along with normal corrections. This happens because urgent corrections are often imported before the project is finished, and they sometimes contain changes that could be overwritten by normal corrections when these are imported. ChaRM controls the transports so the last version of each object is properly transported into production (Figure 4). This prevents incorrect versions of objects from becoming active in the SAP landscape.

Figure 4

Transport flow using ChaRM

As mentioned earlier, normal corrections are managed by the following phases (remember that urgent corrections do not follow phases):

• Development without release: During this phase, transport requests and transport of copies can be created. The developers can work but the transport requests cannot be released.
• Development with release: During this phase, you can create transport requests, but SAP does not recommend this because all the requests should be created in the previous phase, as this is usually the single test phase where developers test their work. Also during this phase, transport of copies can be transferred to test systems and transport requests can be released (upon consolidation of the entire change document, which is what automatically changes the project to the next phase).
• Test: During this phase, the entire correction can be consolidated and, during this consolidation, all transport requests (i.e., the entire project) are transported to the test (consolidation) system. After consolidation, the development (i.e., modifications) should stop. Only test messages should be allowed.
• Emergency correction: If an emergency repair is needed, you can do this through test messages. Test messages are separate corrections in the same project and are quite similar to urgent corrections, but have a narrower scope (i.e., less approval steps and they are managed as part of the normal correction itself). In other words, emergency corrections are used to fix issues found in normal corrections that are being tested, and urgent corrections are used to perform fast changes not directly related to a specific context.

• Go-live: Transport to production is allowed only in this phase. Upon execution, the development is closed, as are all the related test messages.

Retrofit, Cut-Over, and Cross-System Object Locking

Today, more and more companies are adopting dual landscapes to segregate running systems from project systems. In other words, they duplicate their landscape (or part of it) to avoid the risk of changes performed in large projects harming the running system.

On the other hand, short and urgent changes cannot be avoided and should be done without affecting or being affected by large projects. Therefore, you can perform these changes in the running landscape. One of the main challenges is to keep the project landscape updated by transferring changes performed in the running landscape to it. You need to bring all the changes performed in the project landscape to the running landscape in the simplest, shortest, and least intrusive manner possible. It’s best to avoid (or at least minimize) the risk of two developers changing the same object (i.e., one in the running landscape and the other in the project landscape). The solution to these challenges lies in some of the innovations introduced in ChaRM: cross-system object locking, retrofit, and cut-over (Figure 5). I’ll explain these next.

Figure 5

Retrofit, cut-over, and cross-system object locking processes

Cross-System Object Locking

Before ChaRM, ordinary SAP transport requests could help you avoid the risk of two developers changing the same workbench object (e.g., an ABAP program) at the same time in the same system. This was done by locking the object until the transport request that holds that object is released in the development system, in order to be transported to the test system. Customizing objects (e.g., a new cost center) cannot be locked.

ChaRM has a locking feature that manages locks for both workbench and customizing objects. The locks are kept until the transport request is successfully transported to the production system, which significantly improves system reliability. If someone tries to change a previously changed object, a message is issued stating that the object is already locked, the user who locked the object, and in which transport request this has been saved (Figure 6). The developer can contact the owner of the other transport request to decide how to deal with the situation or, in another approach, inform a central governance team. The governance team is responsible for deciding what to do in each situation and centrally managing all the conflicts. This team can, for example, unlock the object so the first developer can keep working if the change is urgent (Figure 7).

figure 6

Cross-system object locking alert example

Figure 7

Cross-system object locking management cockpit

ChaRM also handles locks between different development systems (Figure 4). Changes performed in the running landscape cannot be overwritten by changes performed in the project landscape. The system simply avoids cross-system and cross-landscape changes. The only requirement is that the production system of the project landscape also be the development system of the running landscape (Figure 5).

Several configuration options manage cross-system object locking. The major ones are cross-system (locks are handled between systems) and cross-project (locks are handled between projects). These options can be combined as a matrix (e.g., cross-system but not cross-project). It is also possible to only warn the second developer that the object is still locked rather than prevent him from performing a change. This gives the developer the option to go on or to stop and communicate with the first developer.

Retrofit

Changes performed in the running landscape need to be transferred to the project landscape so the project team members can work with the latest version of the running objects. If this is not handled properly, when a project goes live it can simply undo emergency repairs or modifications that took place during the project life cycle. Simply transporting the requests with the changes from the running landscape to the project landscape could overwrite objects that were already changed in the project.

Fortunately, ChaRM has a feature called retrofit. All the changes that reached the production system of the running landscape can be repacked into new transport requests in the development system of the project landscape. The objects aren’t overwritten, but are instead merged with the new changes using Business Configuration Sets (BC Sets) for customizing objects and Correction Workbench (transaction SCWB) for workbench objects.

The person responsible for performing the retrofit is able to compare what is being taken to the destination system against what is already there. The system shows the changes that could be affected and provides options to the user (e.g., abort the process or overwrite everything) as shown in Figure 8. Objects untouched in the destination system are automatically changed, so the workload significantly decreases.

Figure 8

Retrofit comparison screenshot

Cut-Over

When a project goes live, you need to transfer all the changes performed in the project landscape to the running landscape. Because the running landscape is a live one, project tests have to take place (e.g., performance tests, regression tests) to ensure that nothing stops working. All this work has to be done quickly because changes are potentially always needed in the running landscape (e.g., legal changes that have to be performed immediately) and cannot be performed if a large project hasn’t reached the production systems yet. There is also a risk of these changes taking other changes to production if both changes were performed on the same objects. For example, say that a developer changed a configuration during the project and a critical change took place in the same configuration when the project was being tested. The project configuration would be transported into production together with the critical one.

With cut-over, ChaRM transfers all the transport requests from the consolidation system of the project landscape to the development system of the running landscape. Once there, all these transport requests are repacked into one or two (one for customizing and the other for workbench objects) large transport requests. You then can transport them to the consolidation system, test them, and transport them to the production system by means of a cut-over project (usually an urgent correction). This way, instead of handling several hundred transport requests, you only have to manage one or two. This also means you have only one source system for all changes (i.e., the development system of the running landscape), which is strongly recommended by SAP. It is important to remember that these repacked transport requests are also managed by cross-system object locking.

Challenges and Benefits of ChaRM

A ChaRM implementation project can face critical challenges, but also provides you with a variety of benefits. The main challenges are:

• Lack of user knowledge about the new functionalities and resources
• Changing mindsets about transport request management — strong resistance from users and stakeholders is common
• Getting a commitment from the entire company to use the new tool to replace legacy systems
• Performing changes in existing processes and procedures in parallel with current projects and demands (people cannot simply stop their work)
• ChaRM is an innovating solution (i.e., the number of companies that use it is growing fast, but is still a relatively small percentage of the current SAP customers), so there are few benchmarks and market references
• Training all your consultants and project members and redesigning governance and system management structures, as well as downsizing the volume of changes in the running landscape to allow for the concept change

The major benefits are:

• Compliance with Sarbanes-Oxley (e.g., grant traceability) and International Organization for Standardization (ISO) requirements, as well as Information Technology Infrastructure Library (ITIL) best practices
• Gaining agility and control over urgent transports, thus reducing the impact on productive environments thanks to effective transport management
• Quicker execution of demands and changes (e.g., corrections and improvements)
• The transparent change processes, as well as the central and standardized management of change flows throughout your company’s SAP landscapes
• Reduction of future training efforts on management tools
• Simplification of the change governance process across all landscapes by reducing the number of involved systems. Several legacy systems, such as transport and change approval workflows, can be discontinued.
• Better segregation of project roles and responsibilities (e.g., development, testing, and change management)
• A more stable running landscape with fewer ongoing changes, allowing safer emergency corrections and reducing production impacts from concurrent changes
• Ability to execute better regression tests

A ChaRM implementation project can take anywhere from weeks to months. This depends on several variables. The phases are the same as for any system implementation project — planning, execution, training, and support:

• Planning depends on the users. How many validation meetings do they need? How many people can opine on the design? Where in the evolution scale are they on the subjects of processes and approval flow?
• Execution depends on the level of demanded customization. On a tending to zero customization scenario (i.e., tool is implemented with as few changes as possible to standard configurations, scenarios, and workflows), the configuration of ChaRM can take four to eight weeks —assuming you have experienced people working on it. This involves configuring urgent correction, normal correction, and test messages, using parallel landscapes, and configuring cross-system object locking, retrofit, and cutover. My assumption does not take into consideration Basis tasks; the system, landscape, logical systems, and related configuration must already be in place. Otherwise, you can assume your planning time will increase significantly to allow time to perform these tasks.
• Training depends on the number of users and their knowledge level for ChaRM. The recommended approach is to first train the so-called trainers, the key users who will operate and support the solution. Then, they can plan and perform the training sessions. Training materials usually take two weeks to create and sessions usually take one to three days (one day if key users already know ChaRM, three days if they don’t know it at all).
• Support depends on the level of demanded customization. The higher the number of tailored details, the longer the support takes. Using the “tending to zero” assumption, three to four weeks of support should be adequate.

Cristiano Canzone

Cristiano Canzone is an SAP Solution Manager-certified consultant who has worked at SAP Brazil since 2008. In his 12 years of SAP experience, he has also worked at PricewaterhouseCoopers and IBM as an SAP Basis-certified consultant. Cristiano is currently the SAP resource responsible for the SAP Solution Manager initiatives at Petrobras, the largest oil company in Latin America. He lives in Rio de Janeiro, Brazil with his wife, who is also an SAP consultant (specialized in SAP ERP HCM).

You may contact the author at cristiano.canzone@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.