Sie sind auf Seite 1von 11

The Complete ChaRM Solution

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 alltransport 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 QAPROD). 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

In Development w/ Release

Development
Final Preparation

Go Live

Sustain

Perform Integration/Regression
Testing

Test

Cutover to Production System

Go-Live

Closeout Project

To be closed

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:

Create Change Requests to document and approve changes

Approve Critical Objects


Create, Release and Import Transports
Create Administration Requests for Non-Transportable changes
Workflow can start from Service Desk or from a Change Transaction
Cross-industry tool that supports the product development process.
Business Content for the cProjects component enables you to evaluate data
from cProjects in the SAP Business Information Warehouse.
Requires:
SAP BI
Project Resource Planning (with Workforce Management Core)
Project System (PS) in SAP ECC

cProjects

Provides cross-system object lock across projects or within a specific


Cross-System Object
Lock

project, providing either an error or a warning when a conflict is encountered,


depending on the scenario. This can be configured for just client-specific
customizing or cross-client customizing, repository or DDIC objects.
Provides capability to realize changes made in one development system in
with another development environment, without overwriting changes or creating
inconsistencies. This is done by moving objects found in transports without moving
the transports themselves.
This is particularly useful for a 5-system landscape where Production
Support Changes have to be made in the New Implementation Landscape.
Available with SPS15

Retrofit

Provides milestones for a project based on phases - Scope, Build, Test and
Quality Gate
Management

Deploy.
Available with NetWeaver Enhancement Package 1/SPS 18

When implementing ChaRM, the at least the following questions should be answered prior to beginning:
1.

How will Change Requests be created and by whom?

2.

Who will approve Change Requests and when?

3.

How will staff be notified of pending change requests or change documents?

4.

Who will be the Change Manager for approving Critical Objects, if used?

5.

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

Das könnte Ihnen auch gefallen