You are on page 1of 24

9/4/2017 The Complete ChaRM Solution | SAP Blogs

Products
Products Industries
Industries Support
Support Training
Training Community
Community Developer
Developer Partner
Partner

About
About

Home / Community / Blogs + Actions

The Complete ChaRM Solution


November 27, 2009 | 14,464 Views |

Community User
more by this author

Retagging required

community user

share
1 share
0 tweet share
0 1
like

Unfollow

Over the past few years, more and more projects are jumping into utilizing
Solution Managers 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

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 1/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

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 Alls 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).

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 2/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

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.

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 3/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

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
https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 4/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

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

SAPs 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

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 5/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

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.

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 6/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

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.

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 7/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

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

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 8/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

(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.

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 9/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

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

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 10/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

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/


Development Release

Final Preparation Perform Integration/Regression Test


Testing

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

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 11/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

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.

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 12/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

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 Create Change Requests to document and approve


Transactions: 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

cProjects 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

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 13/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

Project Resource Planning (with Workforce Management


Core)
Project System (PS) in SAP ECC

Cross-System Provides cross-system object lock across projects or


Object Lock within a specific 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.

Retrofit 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

Quality Gate Provides milestones for a project based on phases


Management Scope, Build, Test and 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

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 14/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

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

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 15/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

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

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 16/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

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

Alert Moderator

16 Comments

Wolf Duttlinger

December 22, 2009 at 9:57 am

Christine,
it really is. This blog gave me a first REAL insight into how I can use SOLMAN.
One question you might want to comment came up.
How would you address a stepwise implementation scenario (vs. Big-Bang)?
Reason Im asking: I would like to use SolMan for the implementation of SAP ERP
central repository for doc, training, test etc Now I intend to minimize risk by
seperate the go-live for FI-GL from FI-AR, FI-AP, MM-INV, MM-PUR. BUT dont
know exactly where to draw the line between the different mini-go-live until AFTER
the Blueprint phase.
What comes into my mind and it would be great to hear your opinion on this:
create an implementation project as a template

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 17/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

do project prep and business blueprint in this one


copy (?? is this the right term/approach ??) the template to the agreed
implementation projects (this should make sure that all implementation projects
reference (also during alteration) the original documents
as needed (complexity) route the different implementation projects through
different landscapes
as soon as the first project goes live establish a maintenance project
Would this make sense?
And further question:
urgent modifications: I understand from your article that normaly I would have a
maintenance project that would host all changes occuring during a certain period. An
urgent fix would be specially marked and could be imported seperatelly but later on
would still be included in the phase end procedure.
Now assuming Im in an inplementation project. Everything is coded/configured,
unit tested and ready for QA. So I set the appropriate marker and am in QA now
testing and no development allowed anymore. But hey someone found a bug
would I be able to develop an emergency fix within the project, get it to QA or am
I misunderstanding what you wrote beneath Table 1?
Again thanks for taking the time to write this blog!!
Wolf

Anonymous

December 22, 2009 at 10:29 am

Thank you Wolf. To address your questions


1. In theory, you are correct. Create a template and then add the
template to an implementation project (insert the template properties on
the tab Scope/Template selection in the project administration). Alas,
ChaRM is just not yet perfectno matter how much I love it for
transport management. We have yet to figure out a good way to keep
the template in sync if you have multiple projects as you are describing.
When a new project goes live, the baseline of the system has changed
as the new functionality is now in use. If you already have copied the
template to the next implementation, it is out of sync with the actual
configuration/documentation. There are methods to try to merge/flag
changes, but we didnt have much success and just ended up keeping
much of the documentation in the template and/or manaully updating
the template. I would love to hear anyones suggestions!
2. Urgent corrections can be created anytime, no matter what the
phase. However, urgent corrections are only used in Maintenance

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 18/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

Cycles, not implementation projects. In an implementation project, you


can create Test Messages to fix bugs as you described. (Transaction
Type SDTM).
Hope this helps!
Christine

Raquel Pereira da Cunha

January 18, 2010 at 10:44 am

Hi Christine,
congratulations for your blog.
Just would like to do a small correction on your post to
Wolf:
2. Urgent corrections can be created anytime, no matter
what the phase.
In fact, Urgent Corrections are permitted in every phase
except for the Go-Live phase.
Regards,
Raquel Cunha

Anonymous

January 18, 2010 at 11:22 am

Great catch! Thanks.

Sunil Kollabathini

March 18, 2015 at 8:49 pm

Hi-we have QGM and Charm and we are doing a System refresh so how can i get a
list of TR from charm to reimport .
any steps please?

Thanks

Sunil

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 19/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

Deepak Gupta

January 8, 2010 at 11:43 am

Hello
We are in a blueprint phase and we have done the charm configuration. We have our
development system ready. In my system landscape i have added the virtual system
for quality client. i had added one more client in the Project from where the transport
requests can be created, its giving me an error when i go to create the transport
request The development systems in I000000003 do not match the project definition
ZCHARMECC.

After the research i found out that i need to first close the cycle I00000003 and then
in the new cycle i can add the new client and for that whatever transport requests are
created in I0000003 needs to be released.
My concern is that in future when the development is in progress and my other
systems will come and I have to do any changes in the cycle like adding any client
where the transport should go, what I would do in that case
Best Regards
Deepak Gupta

Anonymous

January 18, 2010 at 11:03 am

ChaRM assumes there is one and only one client where transports
originate from. I tried to configure ChaRM with a Configuration Client and a
Development Client, and it just doesnt work.
However, you can have as many considation or delivery clients as you
would like. This you can change easily in the middle of a project cycle.
Christine

Sivasubramaniyan Balamurugan

January 20, 2010 at 7:19 am

Christine,
This is a wonderful & comprehensive blog!!
We are trying to configure ChaRM for a 4 system landscape (Dev,QA,Pre-Prod,Prod)
in an Implementation project. Our transport routes are from Dev->QA->Pre-Prod-

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 20/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

>Prod. We created a new custom system role called Pre-Prod for logical
components. Upon activating ChaRM, we are thrown with an error saying No export
system for RPI 100. When we modified the route to go from Dev -> QA -> Prod, it
doesnt throw any error. Any idea on how to overcome this? Is this a problem in role
of systems in logical components or something else?

Jamuna Nithyanandam

February 15, 2010 at 8:16 am

Hi Christine,
Can you please let us know if charm would work with two development clients one
for config and another for developments?
Thanks and Regards,
Jamuna Nithyanandam

Anonymous

February 15, 2010 at 8:22 am

No the RFCs used in ChaRM are client specific -transports are created
and released from the client that one client. This one was of our biggest
problems, but then we did end up consolidating Development and
Configuration into one client with no problems to the project team. (other
than a different logon!)

Smita Kumar

May 10, 2010 at 5:26 pm

Hi Christine,
We are in process of implementing ChaRM. Currently we have a 5 system landscape
for Rollout and ongoing production ( as described in your blog). Also currently we
have multiple Rollouts going on and we are using SolMan for all config and other
activities.
The current trasnport movement path is Rollout dev > Rollout QA > Support dev
> support QA > Production.
How can I replicate this transport movement through ChaRM. Also in current Rollout
and Support environment we have multiple client i.e. for configuration and

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 21/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

development separately.
Also many rollout will be in progress when ChaRM will go live, how to enable ChaRM
in between the implementation project.
Regards,
Smita

Jos Ouddeken

June 23, 2011 at 1:36 am

Hi Christine,
First of all i like to compliment you on this excellent blog explaining the most
important aspects of ChaRM. Having been active in the SAP-world (technical and
functional) for about 20 years now i think i know my way around a little
At the moment however im facing an issue with a customer where we perform
Product-development, Implementations/Roll-out and Maintenance processes for
a (still growing) multitude of existing/new customers each with their own productive
systems.
Each of these definitely require ChaRM-based/like processes. Currently these are
supported by TMS, combined with E-mail and well known XLS-solutions. Not very
professional, but thats what we have. So, in other words. a bit of am
enhancement-opportunity here..(to say the least).
To get things organized we recently started to work with releases. Nothing much
fancy, just a collection of transports put together in one main transport-request
For now, it will do the trick.
Next steps (after cleaning up all the inconsistencies) could be to introduce AAK
(SAPs Add-on Assembly Kit). This is more commonly used by SAP Add-on providers
to distribute their SAP-solutions to customers. One of the major advantages for us is
that release-management is very well implemented and thus results/should result in
a more reliable roll-out of new implementations and bug-fixes.
Combining AAK with ChaRM however might be the next challenge From your
obvious experience with CharM how would you favor such a combination ? And are
there any pittfalls (especially with ChaRM) to be reckoned with ?
My personal opinion would be to first implement ChaRM and later on combine with
AAK. Because using ChaRM gives you the benefit of controlling the development
work altogether, whereas AAK only deals with the process of consistent roll-out of
releases/bug-fixes.
In both cases however, we have the challenge of getting a consistent delivery-
system, based on which we can further roll-out/develop/bug-fix. But thats a
separate challenge altogether i think.

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 22/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

Your professional advice would be very much appreciated here..


Best regards.
Jos Ouddeken

Ashutosh Shukla

November 7, 2013 at 10:07 pm

Awesome Job..what a detailed guide to explain everything about using Solution


manager functionalities with focus on Charm implementation..Great!!! Thanks for
sharing this.

Faaiez Sallie

February 3, 2014 at 7:24 am

Hi CHristine

Thanks for this detailed look at ChaRM. This blog was done in 2009. Any chance of a
more recent look highlighting any changes in the past few years?

Thanks

Andres Bermudez

July 23, 2014 at 8:53 pm

ChaRM Works with SAP BO and SAP DS ??

Sunil Kollabathini

March 18, 2015 at 8:54 am

Hi-we have QGM and Charm and we are doing a System refresh so how can i get a
list of TR from charm to reimport .
any steps please?

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 23/24
9/4/2017 The Complete ChaRM Solution | SAP Blogs

Thanks

Sunil

Add Comment

Share & Follow


Privacy Terms of Use Legal Disclosure Copyright Trademark Sitemap Newsletter

https://blogs.sap.com/2009/11/27/the-complete-charm-solution/# 24/24