ChaRM – changes are effective and documented

ChaRM stands for Change Request Management. It was used during the replication of an SAP solution from the UK to its headquarters in the Netherlands. During this project, which was supported by SNP (now All for One Poland), a wide range of adjustment work was supported by the ChaRM tool. The ChaRM implementation project in the LeasePlan Corporation was designed to tailor solutions for SAP ECC and SAP SRM (Supplier Relationship Management) systems.

Custom environment

The implementation at LeasePlan was an interesting one because of the environment where the work was carried out. The SAP environment included six systems in a dual track configuration, which allowed for the secure implementation of the solution. By dividing the environment into two tracks (maintenance and development), the risk of implementing changes in the systems intended for daily work was avoided. Thanks to fully isolating the changes, all the maintenance work was carried out on a regular basis and did not affect the project.

After the project Change Request had been approved, it was implemented in the DEV` system. This is also the system where the project path started that eventually ran through all the systems in the SAP environment: from the project track to the maintenance track. For the sake of consistency of the environments, transports from the DEV system were also transferred back to DEV` and QAS` systems.

Roles in the project

For implementation purposes, SNP (now All for One Poland) established several key roles in the Change Management process:

Developer – specified by the Change Manager when creating a Change Document. Based on the information provided in the change request, the Developer introduces corrections in the development system.

Tester – verification of solutions in test systems according to the Test Case. Submission of changes to the IT Operator.

Change Manager – acts as a decision maker in the Change Management. It is his responsibility to properly process changes. He performs an initial verification of the request to check whether all required information has been properly submitted by the Requester.

IT Operator – responsible for transferring transports between systems.

Change Requests

Any change introduced in SAP systems had to be accepted beforehand. The prepared change requests included basic information such as: a subject, a description of the change, the people involved, a date of change, the module affected by the change. In the next step, the request was approved or rejected by the people responsible for a given module. Upon approval of the request, the Change Manager could prepare the Change Document for selected developers and submit the change for implementation.

Development phase – development environment – DEV`

Changes introduced in the development environment were managed via  the Normal Change (NC) process in ChaRM. Changes that did not require transport were documented separately. The information in NC was prepared on the basis of the RfC and the relevant people were assigned their roles. Besides that, information on the changes to be implemented was entered and the team of developers to be involved in the change was formed.

The Normal Change document allows for the secure transfer of transports between systems using the Transport of Copies (ToC) mechanism. In the first step, the Change Manager appointed a team working on the change: developers, testers, IT administrator. Then he forwarded a change to developers. Developers created transports using ChaRM and assigned transport tasks to people handling transports. When making changes, developers were constantly informed of the impact of changes to the objects in the DEV system from the maintenance environment.

Thanks to the Cross System Object Lock (CSOL), developers could be informed about the need to verify the impact of changes on the maintenance environment. The second mechanism that was helpful in the implementation, Downgrade Protection, tracked changes in the DEV` system and informed developers which transport was in conflict with their changes. Developers could determine whether the transports contained in another NC actually affected their changes and could mitigate before releasing the transport. Upon completion of the implementation in DEV`, the change was marked as ready for testing, without releasing the transports. As a result, the change was taken over by the ToC mechanism and transferred to the QAS` system.

Transport of Copies (ToC) is a tool that enables the reduction of the number of transports to the production system by more than half. It makes copies of the transport with the contents and transfers the changes to the next system in the transport path. ToC is only transferred to another system and then is not available in the buffer for subsequent systems. This allows the changes to be transferred to the test system without the need to release a source transport and to create new ones if corrections are required.

Transport of Copies

Testing phase – development environment – QAS`

After each phase of the process, the people who have one of the key roles in the Change Management process, such as the Developer, Tester, Change Manager, or IT Operator, can track changes and verify them in ChaRM in the pre-prepared WebUI interface. Basic information about tasks that require their attention and action is visible. During the testing phase, a verification of previously implemented changes was performed. In case of any problems, the changes were reverted to the previous phase, where corrections were made within the same transport, and transferred again as ToC to the next system. Testers, who had approved changes in the QAS` system, automatically forced the release of the transport in the DEV` system. As a result, all transports were automatically placed in the import queue. The moment of releasing the transport in ChaRM is the key moment for the proper placement of transports in the queue so that they are transferred to subsequent systems in the right order.

This significantly facilitated implementations during the LeasePlan project. Finally, nearly 100 transports were delivered to the production system, and this number could have been even three times higher without the use of ToC.

Retrofit

Upon approval of the tests, the changes done in the maintenance track were transferred to the development track using the Retrofit mechanism. Retrofit is an option of separating long-term tasks in the development environment from system maintenance tasks in the maintenance environment. Changes made in both environments do not affect each other, which eliminates conflicts. Each process can be processed in a separate environment by different teams. Any minor changes introduced in the maintenance environment should also be implemented in the same way in the development environment to ensure proper operation of the production system, where transports from both environments are delivered.

Testing phase – maintenance environment

At this stage, it was verified whether the new implementation had affected the current solutions in the maintenance environment. In the case of conflicts, the changes were re-adjusted and re-verified in the QAS system.

Pre-production phase – maintenance environment

The final phase allowed for the final verification and adjustment of a detailed plan to Go-Live. The Go-Live plan provided information as to which transports would be transferred, and in what order. Previous implementations enabled the exact times of change transfers and adjustments to be determined. By using the fourth system in the queue, the security of the implemented changes was guaranteed and the solutions were verified using the most up-to-date data from the production system.

Go-Live phase

The changes were transferred to the production system with the ChaRM solution smoothly and without complications. And all this thanks to the tools that support the Change Management process, and eliminating all conflicts between objects in earlier phases.

Eelco Roeten, Global GFS Architect, LeasePlan Corporation

Project fully planned
The ChaRM solution using the Retrofit mechanism allowed us to keep a complex landscape synchronized. Changes in the production system were replicated to the development track in an efficient and organized way. Thanks to the Change Management System, the project was carried out in a fully planned and controlled way.
Eelco Roeten, Global GFS Architect, LeasePlan Corporation