The dynamic development of the Can Pack Group in recent years has made it one of the leading manufacturers of packaging in the world. It was possible thanks to the implementation of engineering projects and investments worth hundreds of millions of dollars. The purchase of modern equipment played a significant role in accomplishing such a significant position on the market, as it allowed the company to achieve a global level in packaging production technology. The company’s business growth led to the need for reorganization of IT services. One of the elements of this reorganization was the project involving implementation of Change Request Management, which allowed ordering of the existing IT processes, an increase of processing efficiency and better control of implemented changes.
Change Request Management (commonly called ChaRM), one of the SAP Solution Manager components, is a tool for complex change management – from small configurational changes to large implementation and development projects. ChaRM demonstrates its abilities at companies which have an extended landscape of SAP systems and at which numerous projects are conducted simultaneously. It may be used for management of the following projects in SAP Solution Manager:
- maintenance – related to standard tasks maintaining SAP systems in good condition,
- implementation – long-term projects related to implementation of new business projects in a given environment,
- upgrade – projects related to upgrading the existing SAP systems,
- template – projects, the purpose of which is to create templates for other projects, including objects assigned to them, such as documentation and IMG activities.
In the scope of implementing ChaRM in the Can Pack Group, the following types of changes were used:
- Request for Change,
- Normal Change,
- Urgent Change,
- Admin Change.
Request for Change
Change management commences with preparing a Request for Change by the Requestor (one of the key roles in ChaRM). The Requestor enters basic information, such as the change title, suggested priority, information about the system and detailed description of the change. Then, the request is forwarded to the Change Manager who is the first person to verify the validity of the request. The manager’s tasks during processing of the Request for Change include determining priority, category and scope of systems covered by the change, as well as indicating a group approving the request. Then, the request is received by the Change Advisory Board, the group that approves or declines the request.
Normal Change
After approval of the request, a Change Document is created. One of the option is Normal Change – created for changes, which require going through the entire process of change approval. Normal Change passes numerous tests before it is imported into the production system. Usually, this type of change is related to standard system maintenance and development works. Processing of the Normal Change document involves engagement of the Developer, Tester, IT Operator and Change Manager.
Urgent Change
Urgent Change is used in cases of serious problems or system failures affecting a large number of users, key processes and requires an immediate reaction from people managing the system. This type of change is fully optimized for quick processing, while maintaining complete supervision by people involved in the change implementation. It differs from Normal Change by automation of the change transfer phase to the test system and a decrease in the number of steps required from persons involved.
Admin Change
Admin Change is used to process changes where transports are not used. It aims at documentation of changes, which must be introduced directly on one of the systems in the SAP environment: developer, test or production environment.
Change management in the Can Pack Group
BCC (now All for One Poland) was a partner in the implementation of Change Request Management in the Can Pack Group. During the project, the most important challenge was to adjust the ChaRM tools to fully adapt it to the business requirements. It was assumed that the tool would be easy to use, and therefore fully functional. The first step was to create a scenario that would allow adjustment of ChaRM to the change management system applicable in the Can Pack Group.
The system was adjusted in such a way that ultimately the paper version of the Request for Change was fully replaced with the electronic form, using a standard extension of the ChaRM view with additional fields, allowing identification of documents in accordance with the standards of the Can Pack Group. Another step involved adjustment of the course of change approval. Currently, each Request for Change goes to an appointed Change Manager who verifies it and forwards it to people responsible for approving a given change in the system. The approval strategy was based on the organizational unit from which the request was sent. It is supposed to ensure approval of each change by key people managing the SAP system and ultimately by the director of the organizational unit requesting the change.
The next stage involved adjustment of change documents. Normal Changes were extended with the possibility of automatic import of transports from the developer systems into the test systems, and therefore activities related to transport management by the Basis team were limited.
An interesting solution was to integrate Incident Management with ChaRM. Currently, each user can report an incident directly from the SAP system. Based on the data included in the incident, the managing person can create a Request for Change or a change document.
At the last stage, additional types of changes were made: admin and urgent. For complete documentation of changes, which do not require transport, an Admin Change was used. It was adjusted to the requirements of the Can Pack Group analogically as in the case of the Request for Change, Normal Change and Urgent Change. Thanks to this solution, each type of change will be fully documented.
Bartłomiej Krawczyk, Specialist Coordinator for the SAP system, CAN-PACK S.A.
Transparent and ordered changes
Owing to the increasing number of requests for change in the SAP system, there was a need to implement a tool that would accelerate the registration method, as well as service of the requests. So far, requests were prepared in paper, and then described manually by the person managing them. Updating request statuses, as well as creating comparisons and analyses was conducted manually, which was frequently subject to human error.
Given the processed changes, additional registers of transports, estimates of workload and specification of necessary actions were conducted in the system, where the workload was very high and could not be implemented using one tool. An additional criterion to select the tool was its complete compliance with the ITIL methodology, pursuant to which IT services are managed in the Can Pack Group.
The main benefits of implementing ChaRM in the Can Pack Group is to organize the change management process and better control it. Coupling of registers of requests for change directly with documents regarding changes and transports increased system safety (it is not possible for one person to process a change) and allowed the progress of works regarding changes in real time to be reported. The functionality of Transport of Copies allowed the number of transports forwarded to the production system to be decreased, and facilitated performance of tests due to work on a single transport until the expected result is achieved.
From the perspective of the Change Manager, the main benefit is the possibility for clear organization of change documentation and better control of the process, for which the system was properly prepared. Currently, the entire documentation from the moment of submitting the request to its closure is in one place and available for each authorized person. At any time, it is possible to check the status of the request implementation, as well as prepare reports due to the given criteria. Ultimately, transferring requests into a fully electronic form will save time necessary for registration.
BCC professionally implemented the project of change management in the Can Pack Group, responding to challenges and adjusting the solutions to our specific requirements at each stage. Works were implemented in a timely manner and in accordance with the assumed implementation methodology. The leading Consultant in the project demonstrated broad knowledge on the subject of change management, as well as the entire SAP Solution Manager system.
Bartłomiej Krawczyk, Specialist Coordinator for the SAP system, CAN-PACK S.A.
Until now, users informed the IT department about the required change via a paper request that must be manually signed by the director of the unit requesting the change. Based on this, the request was registered in the system and work to develop documentation commenced, and its processing continued. There was no central place to store documentation and confirmations of users, which resulted in organizational chaos in some cases.
Thanks to the implemented solution, after creating an incident in the SAP system, it is possible to generate a post-incident document, such as a Request for Change. The request contains the entire history of the incident by linking it with the Request for Change. Then, after verification and determination of the type of change the request concerns, the change manager forwards the request for approval, which takes place through the commonly accessible Web UI view.
Thanks to personalized notifications sent via e-mail, ChaRM allows information about the required user’s activity to be forwarded, and through the attached link, the approving parties can log in directly to ChaRM and go to the request where their actions are required.
Moreover, in the developer system an innovative solution regarding transport management was introduced. Having completed the actions, the developer releases the executed transport task, and its change is automatically sent to the test system in the form of Transport of Copies. Transport of Copies guarantees that transport will be transferred only to the test system. Importing is conducted automatically in the defined time window. The tester can conduct verification in the test system and in case of failure; decide about withdrawing the change to the developer system, where further tasks can be added for transport.
Only after the approval of tests in the test system, is the appropriate transport released, automatically registered in the test system and imported by the Basis team into the production system.
This solution allows the problem of dependency to be limited and the number of transports forwarded to the production system decreased. After the change is completed, information is automatically sent to the Request for Change, and then the request is closed or extended with more documents regarding the change, depending on the requirements.