Over the past few years, more and more projects are jumping into utilizing Solution Manager's Change Request Management functionality, commonly referred to as ChaRM. Forums and website are being filled with information on how to configure ChaRM. When setting up a new project in Solution Manager, it is tempting to prematurely click the button to activate ChaRM on the Change Request tab without really understanding why or how you should use ChaRM. It is important to understand some of the history of SAP Change Management in order to appreciate and leverage the features that have now been introduced by SAP. ChaRM enables projects to utilize the proven SAP Transport Management System (TMS) functionality as it was originally intended - as a software logistics process to ensure the integrity of your production environment. The purpose of this document is to provide insight into how best to use ChaRM to meet your needs.
The Driving Factors for ChaRM
When SAP TMS was first introduced with SAP R/3 4.0, it was a huge step for change request management. It provided a transport strategy for controlling and managing where and when changes were to be imported. With TMS, import queues are automatically populated to ensure that transports are imported into the consolidation and delivery systems in the same order they were released. This new functionality provided capabilities to perform "Import All's" of entire import queues. By using Import All, the transport process would perform the nine import phases on the collective queue. This ensured dictionary objects were imported and activated prior to the main import, no matter where they were in the import order, for example. Managing the sequencing of transports was no longer a concern, thus minimizing errors.
- If a transport request was released into Quality Assurance (QA) and determined to contain "incorrect" objects, a new transport should be released from Development (DEV) to fix the errors. With Import All functionality, the "bad" transport requests would always be imported first and then overwritten by the correct transports. This sequence is important to ensure required objects that may exist in the "bad" transports are not missed. Since "bad" transport requests were often abandoned after determining there were problems, required changes may never have been imported to Production (PROD), causing problems in that environment. By importing all transport requests into PROD in the same sequence as imported to QA, this risk is minimized.
- When performing transports, the tp process would perform the nine import phases on the collective queue, thus ensuring dictionary structures were imported and activated prior to the main import, e.g. (Import All functionality took care of determining dependencies and sequencing).
- Single transports could still be performed, but only as Preliminary Imports. A Preliminary Import is moved into the environment but not deleted out of the import buffer. This functionality allows a change to move quickly to QA and Production, but prevents change requests from being imported into various target systems out of order. By ensuring an Import All always follows, QA and Production are synchronized with the export order of DEV.
- Note that the use of Import All is not recommended for BI landscapes.
The features of TMS enabled SAP Project Teams to put down the spreadsheets commonly used to manage transports and rely on SAP tools to track changes. For many new implementations, TMS was fully embraced. Figure 1 shows the standard 3-system landscape where configuration and development is completed in DEV. When ready to move into Testing Phase, the transports are released from DEV imported together into QA and finally imported collectively into Production as part of cutover activities.
Figure 1: Three System Landscape
For a new implementation of SAP, this strategy is very effective. However, a problem arises in a waved implementation. After the first wave is live in Production, it becomes difficult to support production and the next wave at the same time. As the second wave is changing the Development system and testing in the Quality Assurance system, these instances no longer resemble the current Production, but the "to-be" Production system.
The as-is snapshot is very important when supporting production. Should a change be required immediately for Production, it becomes very difficult to make the change in Development and test in Quality Assurance if these environments are configured differently. As SAP is a highly integrated system, risk is introduced as you cannot test the production support change independently of the next wave changes.
The solution is to add two additional instances for Production Support, as shown in Figure 2. Once live, Production Support activities are done in DEV and QA, and DEV1 and QA1 are used for the next implementation. This ensures a stable Production Support Environment and a separate promote-to-production path for new implementations to move to PROD.
Changes made in the Production Support pipeline would need to be realized in the new implementation path so integration testing would include all changes. This is traditionally completed by manually configuring the changes in the DEV1 system, much to the chagrin of the developers, who would prefer to use transports already created. This ensured that changes in DEV1 were not overwritten by Production Changes, and a process was put in place to review and retrofit any differences.
Figure 2: Five System Landscape
Challenges managing the Production Support Pipeline
Production Support Teams strive for high customer satisfaction and respond quickly to end-user requests. Transports tend to move through the landscape in a haphazard manner, moving into Production as soon the change was tested, no matter what the order. Therefore, Import All functionality is often abandoned after the initial Go-Live for many implementations as each team is focusing on their changes only. The critical sequencing of transports is then managed manually if all changes are treated as Preliminary Transports.
In addition, the 5-System landscape for managing new implementations in a live production environment is not always used due to the maintenance and hardware costs of the additional DEV1 and QA1 systems. New functionality to meet changing user, business, management, or legal requirements is often introduced through the Production Support Landscape. These mini-projects have to be managed in terms of scope and schedule. In addition, SAP environment has become more complex, so dependencies are no longer in the same transport queue, but changes are made in other ABAP and non-ABAP systems.
Spreadsheets and similar tools have once again become the norm for tracking changes due to these factors. Email systems are often used to document approvals and notify the Basis team of imports. The emails may contain transport dependencies and the order imports must occur.
In many situations, these tactics do not address the risks introduced into the landscape:
- Dependencies are not always known within or among SAP components.
- Changes successfully tested in QA could have unexpected results in Production due to missing configuration/transports.
- Over time, DEV and QA could become out of synch as transports are abandoned in the import queue or imported out of sequence.
ChaRM - More than Just a Technical Tool
SAP's Change Request Management (ChaRM) functionality addresses the challenges described in the previous section by grouping changes together. These groups, or Solution Manager Projects, extend the TMS functionality by ensuring all transports are moved together into QA, integration/regression tested as a whole, and imported into Production collectively. Spreadsheets are no longer needed as the SAP Solution Manager Project will keep track of which transport requests are associated to which project and the order they need to be imported. By configuring CTS+, ChaRM extends to all ABAP and non-ABAP SAP landscapes in your project. Transports can be bundled and managed no matter what the source system.
The cycles of a Project provide additional governance by controlling the phase of the project. Transports that are not in the correct stage during a switch of the Project cycle issue warnings. At this point, the transport must be followed by a subsequent transport undoing the change - and thus ensuring synchronization of the landscape - or move to a new maintenance cycle. Functionality is also provided for urgent corrections that have to move to Production immediately, regardless of the Project phase.
Much more than just a Technical Administrators tools for transports, ChaRM is also a powerful project change tracking system. It provides capabilities to:
- Provide traceability to requirements and change requests
- Communicate actions to be taken for each change request by utilizing workflows
- Report and track statuses on individual change requests and the project as a whole
- Provide tracking of approvals for change management auditing
- Provide safeguards to control where transports applied based on the project phase. Example: If the project is in the test phase and an attempt is made to apply a project transport to production, there will be a TMS Alert Viewer error message, "You cannot import any requests for project xxxx at the moment."
Because ChaRM is more than a technical tool, it must be driven by Project Management who must get buy-in from all groups involved. Project Management must also spend time planning the projects to be used - what type of project, how many projects, and what the timeline should be for each project.
Solution Manager Projects
Solution Manager Projects are a set of workflows and reports to manage deployments. A Solution Manager project can be used from Blueprint to Go Live, and has methods to:
- Describe Scope
- Document Design Requirements
- Configure Applications
- Manage Testing
- Create Training Material and Learning Maps
Project systems use the Change and Transport System to manage transports associated with specific projects. ChaRM does not need to be activated for every project, however. Projects can be used to manage requirements and documentation only, without having to utilize ChaRM.
There are various types of projects that can be setup in Solution Manager using transaction Solar_Project_Admin. The most common ones are listed below:
Template Project - A project that creates a template for other projects. The project structure or parts of it, with its assigned objects (documentation, test cases, IMG activities) is then available to other projects. Template projects are especially suited to SAP partner solutions or global rollout. Template projects cannot be used for Change Request Management (ChaRM). However, they can be the starting point for Implementation, Upgrade or Maintenance Projects.
Implementation Project - A project based on the selection of business processes. The structure of an implementation project cannot be reused by other projects.
Maintenance project - A project for a landscape that is already in Production and uses Change Request Management to manage the solution. The project contains all maintenance activities and urgent corrections of a solution.
Upgrade Project - A project to upgrade an existing system. In an upgrade project you can perform upgrade customizing and/or delta customizing.
Within each project are cycles that define the stage of the project. They are called Maintenance Cycles for Maintenance Projects and an Implementation Project for the Template, Implementation and Upgrade Projects. Maintenance Cycles and Implementation Projects provide a list of tasks that can be executed for each phase. The Solution Manager project interacts with the Transport Management System in your satellite system to release and import transports according to the Phases.
For Implementation and Upgrade projects, there is a known start and end date, with planned dates for Configuration, Testing and Go Live. The phases of the task list will correlate to the phases of the project. For Maintenance Projects, the definition of a phase is not as clear as there is no end date for on-going Production Support. The cycles, therefore, can be used for Change Management by consolidating modifications into groups. All changes would be imported into QA, tested and imported into Production together on a cyclical basis, for example, monthly or quarterly. At the end of the period, the current Maintenance Cycle would be closed and a new Maintenance Cycle opened to start the process over for the same Maintenance Project.
The Importance of Planning Projects
Management needs to plan the types and number of projects at the start of the ChaRM implementation. This can be a challenging task as development and testing durations vary and Go-Live dates may change. However, planning is critical as SAP is a complex software package and all development and configuration should move into each environment together so they are tested as a whole. Overlaps in project phases should be minimized as much as possible. Consider the following:
- Projects that have Go-Live dates that are close together should synchronize the QA Testing and Go-Live Dates. Changes that go to Production at the same time should also be migrated and tested in QA at the same time.
- If two projects are migrated to QA at approximately the same time, but one project has a longer test cycle, the other project should not be moved to Production first without introducing risk. The goal is to provide a QA testing environment that is similar to what Production will be at the Go-Live date.
There are, of course, always exceptions to these rules. Overlaps are mainly a concern where there is overlapping functionality. Projects that are implementing different modules or different components may not introduce risk to each other. It is important to understand the content of the projects when determining the different phase dates.
Figure 3: Planning Multiple Projects
Figure 3 depicts a scenario could be encountered with a standard 3-system landscape (DEV →QA→PROD). The production support Maintenance (Project D) at the bottom is on-going, moving production changes throughout the year in defined cycles.
The implementation of new business processes (Project A) and new applications (Project B) have independent timelines as it was determined there would be no overlap in existing production functionality. As a result, there are no conflicts in configuration/development efforts and testing. The Production Support Maintenance Project is in the DEV environment at both times each project starts the testing cycle. Therefore, QA is a stable environment for testing new functionality. It should be noted that the new landscape component implemented with Project B would be added to the Maintenance Project D landscape after Go Live for on-going support.
Implementation Project C to enhance existing functionality aligns with the second cycle of the maintenance project so that testing and cutover production occurs at the same time. Maintenance projects can include enhancements, but in this situation, the Blueprint and Development phases are longer than the maintenance period, so a separate project is created. In addition, a separate project would provide reporting and tracking capabilities that would not be possible if it remained in the Maintenance Project.
If the implementation of new functionality or enhancements is a significant effort, or if an upgrade project is planned, a 5-system landscape should be established. The dependencies between the Maintenance and Implementation projects are reduced. As depicted in Figure 4, different development and testing cycles can be executed as there would be separate DEV and QA environments.
The DEV1 and QA1 environments for the new implementation project would have a separate transport path to Production and therefore be isolated from the Production Support DEV and QA paths. As stated in the beginning, change management is easier for large implementations, whether building an environment for the first time or implementing in a separate environment. A period of time is usually scheduled in the plan to release all transports from DEV, and Import All functionality is then used to build QA for testing and eventually Production for the Go-Live.
Even in a 5-system landscape, Production imports will always need to be coordinated as there is still only one Production Environment. It is also important to freeze Production changes during the Integration/Regression testing to provide a stable QA1 environment, although a Maintenance Project would still be open during this period for Emergency Changes and Post Go-Live Support of the Implementation project.
Figure 4: Projects for a 5-System Landscape
Depending on your needs, multiple maintenance projects can also be created and there are advantages to each approach. Each maintenance project can only have one maintenance cycle. Once a maintenance cycle is closed, however, a new one can be created. The advantage of this approach is change Requests can be moved to the next maintenance cycle if not ready for implementation.
Production Support Teams may have a desire to plan future deployments. Another option is to have two (or more) maintenance projects - with one project actively in development and testing and the other project defining scope and gathering requirements. The challenge with this approach is ensuring all changes planned for a maintenance cycle actually do move forward in a timely manner as they can not be deferred to the next cycle if it resides in a separate project.
This forecasting may seem daunting for many SAP teams. However, the planning required should not only be done for Solution Manager Projects, but for any implementation project or production support, regardless of the tool. SAP Projects already use methodologies for defining scope and resources. ChaRM provides a structure to also plan transport requests.
While multiple Solution Manager Projects provide additional control of change requests, complexity is added to document management. Processes will be needed to manage General Documents, Project Structure, Test Cases, Learning Materials and End User Roles created in the various projects and merged into one final product. When a Template project is used as the starting point of all projects, the SAP functionality for comparing and adjusting projects can help update documentation.
Controlling with Project Cycles
For all project types, you can only have one active cycle. You can have multiple projects within the Solution Manager system in different phases, but only one implementation or maintenance cycle per project. This is logical as one project usually only has one development, test or go live phase being executed at any one time. If there was more than one phase being executed at the same time, it would most likely be for different and discrete projects.
The applicable phases and process executed within the cycle are based on ASAP methodology as shown in Table 1. Each project cycle phase corresponds to a project phase.
Table 1: Mapping ChaRM Cycles to ASAP Methodology
ASAP Methodology Phase | Process | ChaRM Cycle Phase |
Business Blueprint | Define detailed scope | Created |
Realization | Perform Configuration and Development | In Development w/ Release |
Final Preparation | Perform Integration/Regression Testing | Test |
Go Live | Cutover to Production System | Go-Live |
Closeout Project | To be closed | |
Sustain | On Going Production Support | Completed (at this point a maintenance project should be created) |
Project cycles and the corresponding task list control the process for creating, exporting and importing Transport Requests. For example, when the Project Cycle is In Development w/o Release, transport requests cannot be exported from the development system. Subsequently, when a project is in Go Live, new transport requests cannot be created. The statuses of a maintenance cycle or implementation project represent events of the change process. The statuses are changed using the Solution Manager Scheduler transaction, usually by the Change Manager.
The standard workflow, which can be adjusted to meet your specific needs, is shown in Figure 5. The workflow for any change starts with the occurrence of a defect or missing functions. This is reported through Service Desk functionality where a change request is created. If the error is serious enough to warrant the implementation of a correction, the change request is then approved. The change transaction then passes through certain phases:
- Approving the correction
- Developing the correction
- Importing the correction into the test system
- Testing the correction
- Confirming that the correction is successful
- Performing the import of the correction into the production system
Figure 5: Maintenance Cycle Process
No matter how much planning or testing is done, there will always be situations where a transport request must move to production immediately to resolve a critical problem or respond to a vital request. These changes cannot follow the standard process for maintenance cycles. SAP provides a separate workflow for Emergency Corrections that allows you to by-pass the cycle phases and create/move changes through your environment. The process is similar in that there are development and testing actions and statuses to ensure even the most critical changes follow configuration management procedure, even if in a condensed cycle.
Urgent corrections can only be created for Maintenance Projects and are imported into the QA and Production systems as Preliminary Imports. Preliminary Imports are imported into the delivery systems as a single transport, but left in the import buffer. When the maintenance cycle is moved to Go Live and all transport requests are imported into QA and Production with the Import All functionality, the Urgent Corrections are also imported into Production again. As mentioned previously, this is not a new SAP technique but introduced with TMS as a method to minimize risk and ensure environment synchronization.
A built-in workflow for moving Normal and Urgent corrections through each stage helps to navigate the process. The workflow can be enhanced to send emails on certain status changes or specify critical transports that need additional review.
Configuration of ChaRM
After setting up a new project in Solution Manager, it is too tempting to click the button to activate change request management. Clicking that button early can result in cleanup challenges in multiple systems as ChaRM configuration could be prematurely propagated via RFC to all systems defined under the new project. Many steps are required prior to activating this switch.
The configuration of ChaRM does not stop once the basic settings are complete. Much of the functionality can be customized and features adapted to meet specific project needs.
Change Transactions: |
|
cProjects |
|
Cross-System Object Lock |
|
Retrofit |
|
Quality Gate Management |
|
When implementing ChaRM, the at least the following questions should be answered prior to beginning:
- How will Change Requests be created and by whom?
- Who will approve Change Requests and when?
- How will staff be notified of pending change requests or change documents?
- Who will be the Change Manager for approving Critical Objects, if used?
- What other ChaRM functionality will be used?
It is recommended that a Solution Manager Development environment be installed to configure and test new functionality as these components are tied together so closely. Configuration and use of ChaRM can be tested to determine what best meets your needs. As more scenarios and functionality are added, an instance will also be needed to test Support Stacks, Enhancement Packages and upgrades without adversely affecting your productive Solution Manager instance.
The Total Solution
It is often a surprise to hear that Service Desk must be implemented prior to activating ChaRM. Whether or not Service Desk is utilized, it must be implemented for ChaRM to function. ChaRM interacts with many other Solution Manager Scenarios to provide a complete solution for managing your SAP Landscape.
Figure 6: Interaction of Solution Manager Scenarios
The scenario selected depends on the project stage and the functionality to be implemented. For example, a new project would be created for the Blueprinting efforts. Once Realization begins, Service Desk could be used to send customer messages to SAP and ChaRM used to track transport requests and Support Stack implementations. The Change Request management process would be finalized during Final Preparation to prepare for on-going support with a new Maintenance Project. They may decide to use Service Desk as an End User Help Desk tool, so that process may also be updated at this stage.
In addition, Work Centers is a new feature in Support Package 15 in Solution Manager 7.0 to provide easy access to Solution Manager Transactions. It provides a role based navigation bar and reports for the various other scenarios. Work Centers provide users one-click access to frequent and important actions in various Solution Manager Scenarios. Work Centers can be setup independently of the other scenarios and roles added to users as functionality is implemented.
Figure 7: SAP Change Management Work Center
Conclusion
ChaRM is more than a transport tool as it provides powerful workflow, tracking and reporting for Change Requests on top of the Transport Management System (TMS). ChaRM also provides additional governance of projects needed for effective change request management and to successfully meet auditing requests. Organizations may be wary of the planning that must take place to implement SAP projects and activate ChaRM, but this is planning that should already be part of responsible project management activities. The planning required to configure ChaRM is not more than with any other configuration management tool.
Without ChaRM, all SAP projects would need to incorporate some manual process, whether with spreadsheets and email or other tools. These projects would still have to keep track of what is ready to move to QA and Production, and in what sequence if Import All functionality is not used. The integration of your Change Management System with the back-end SAP system eliminates various and disparate processes. ChaRM also provides the added advantage of being able to perform the transport from the change management tool.
ChaRM enables projects to utilize the proven TMS functionality as it was intended to be used - as a software logistics process to ensure the integrity of your production environment. ChaRM offers the following benefits:
- Increased efficiency through use of change management workflows and approvals
- Decrease costs as activities such as integration/regression testing are planned and consolidated
- Reduced risk of errors due to differences in environments or transport sequence
16 Comments
