Skip to Content
Author's profile photo ROUGER Benjamin

How to make a successful ITSM / ChaRM project? (part 2)

Here is the second part of my blog on the steps to make a successful ITSM / ChaRM project. You can find the first part with this link:

3. Change Management

This is a part of the project that can easily be underestimated whereas it is one of the most important factor of its success.

When any ITSM solution is implemented, it replaces an existing tool or add a new tool in the IT processes. In any case, the old ways of working are going to change and it is never an easy thing to do.

To make the transition as smooth as possible, right from the beginning of the project, start communicating to the future end users about the project’s objectives, the solution designed, the benefits expected, etc.

It will help you in different ways:

  • Your teams members might identify some part of the process that have not been clearly defined or don’t fit how one group is used to work
  • The changes brought by the project will be more easily accepted and you will guarantee a much faster adoption of the solution
  • You will reduce the risk of the solution being rejected by some of your teams

You don’t need to spend a lot of time on those activities. Just a few days are necessary, but it will definitely change the way your solution is accepted.

4. Build

This is related to the change management part of the project, but don’t forget to involve ChaRM end users during the build phase. Organize demonstrations, Q&A, etc.

The build phase also requires a test landscape to validate the tickets behavior. You can always use solman, but the best configuration is to have an ERP sandbox as close as possible to the production landscape configuration.

It will make your life easier during the go live. You will avoid implementing SAP notes on the ERP systems, close to the go live date, because the SAP Basis level is lower on ERP than Solution Manager, for example.

5. Test

As for any IT project, the definition of the requirements is essential to successfully test the solution. You don’t want to forget any requirement, as it would lead to a solution partially tested. The best approach is to start building your requirements during the design phase. As you design the solution, you also define what should be tested and how.

Don’t forget to cover, with the requirements, your release management process and all the different ways your team works, depending on SAP modules or products.

6. Training

Keep your training documents simple. In many projects, I have seen clients build very detailed documentation. The problem is that they are very difficult to maintain and the end-users usually don’t use them, as the documents are too long and they cannot quickly find the answers they are looking for.

And remember that end-users will regularly change, your documentation should be easy to understand as the solution owner won’t be available to explain to all new users how they should use the solution.

Instead, when you’re preparing the documentation, think about how the end-users will consume it. What are the information they will need to look for regularly (naming convention, release management principles, etc.) and the ones they will look at once or twice (objectives of the project, ticket interface, etc.).

With this, you can divide your user guide in more comprehensive units and make sure that the solution will be used the way it was supposed to.

7. Go-Live

I have identified three steps to safeguard the go live of ITSM / ChaRM projects

  • Build the cut over plan throughout the project
  • Anticipate the technical operations
  • Build a transition plan for the existing tickets / transport requests

Build the cut over plan throughout the project

Depending on the size of the solution you’re dealing with, there can be a lot of operations that need to be performed. It is very easy to forget some.

To avoid that, the best thing is to start building the cut over plan as soon as the design phase starts and to update it regularly during the project.

Anticipate the technical operations

On most projects I’ve done, we usually had problems with the same operations:

  • System landscape preparation: basis team had trouble generating RFC destinations or setting up TMS the way ChaRM expects it
  • Authorizations on the satellite systems: the authorizations were not consistent on all the systems managed by Solution Manager and it can lead to errors in the processes (ex: transport requests not released)

All this problems can lead to a stressful go live and even delay it. My best advice is to anticipate those operations. Start working on them at least 1 or2 weeks before the go live.

You will give your teams more time to solve the issues and will avoid all the stress.


Build a transition plan for the existing tickets / transport requests

When the new solution will be deployed, you will have tickets in your previous ITSM solution or transport requests not linked to ChaRM tickets. You want to reduce them as much as possible, as it will confuse end users and can lead to errors.

For ITSM tickets in the legacy system, you can chose between three options:

  • Manually create the tickets in Solution Manager: easy to do when you have a few tickets, but the workload quickly increases
  • Work with the old tickets until they are all closed and use Solution Manager for all new requests / incidents: it is the easiest solution, as no work is necessary to prepare the go live, but it can be confusing for end users
  • Automatically transfer the tickets from the legacy tool to Solution Manager: SAP doesn’t have any tool to fulfill this requirement, but there are software, provided by third party vendors, that can perform this operation. It is the best solution and can be cheapest depending on the number of tickets to transfer

For transport requests, if you have deployed the cCTS infrastructure, you can link released and unreleased transport requests to your tickets. In that case, the best strategy is to create tickets and link them to transport requests before the go live.

8. Post go-live

Depending on the size of your organization, the changes brought to your IT processes can take a while to be fully understood by your team.

Make sure they are supported after the go-live to understand how the solution works, how it impacts their day to day operations and what benefits they can get from it.

Finally, after 6 or 9 months, execute a new TEA report to measure the progresses made and compare them with the initial objectives. And don’t forget to communicate about your successes!

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Esteban Hartzstein
      Esteban Hartzstein

      Hi Benjamin

      Thanks for this  nice article.  One the topics that I am interested in is how to set-up the right ChaRM organization.  There should be Release Manager planning releases for all the projects?  In which way you organize activities cross projects, such as CSOL, downgrade, retrofit, do you think in a centralized organization or you recommend distributed those roles.

      I found that this topic is one of the more complex to solve, who is responsible of what in organization starting using ChaRM everyday.

      Hope you can share your thougths.


      Esteban Hartzstein

      Author's profile photo ROUGER Benjamin
      ROUGER Benjamin
      Blog Post Author

      Hi Esteban,


      Setting up the right ChaRM organization is indeed a challenge. I think there is no perfect template, as it depends on a lot of criteria (size of the organization, numbers of consulting providers, on going projects, etc.). However, in the last 2 years, with the 2 releases per year concept, SAP really gave us a lot of good ideas on how to run an efficient ChaRM organization.

      If you have not read them, I highly recommend them, as you will get a lot of useful information to answer your questions.



      Author's profile photo Eric Poellinger
      Eric Poellinger

      Hi Rouger

      Great points in your article, thank you.

      Curious about your feedback on the "sanity" of keeping another ticketing system (e.g. Jira) as the keeper of change docs and then keeping them in synch via RESTful APIs. some companies have a significant non-sap investment and those teams push back against many of the things in CHARM.   the sap team wants the benefits of CHARM related to downgrade protection, cross system object locking, tea, automation.  I don't have a experience with CHARM but based on your blog I suspect this idea could be challenging 

      Author's profile photo ROUGER Benjamin
      ROUGER Benjamin
      Blog Post Author

      Hi Eric,

      In most organization, there is always another ITSM tool. Usually, in that case, we will start working in Solution Manager with the request for change or the change documents (normal / urgent changes) directly.

      But as you said, the problem is how do you keep both tools in synch. You can do that manually, a lot of organizations do that or you can develop a small interface, using web services. It is very easy to do and will make your end users life easier.

      In any case, what is important is that ChaRM will change the way people work. They might spend more time doing some stuff, but it will also make their life simpler and avoid a lot of problems (and save time in the end).

      So, even if you have to do manual synch, if you show them the value of the tool and the benefits they can get from it, having two ITSM tools should not be a problem for them.



      Author's profile photo Former Member
      Former Member

      Hello Rouger,

      Great articles!!

      I've been working in a ChaRM implementation and I am facing some of the situations you have pinpointed. It's great to get the things organized from beginning and for sure, it's much easier when we keep the standard and organize our processes based on it.

      If it's not a problem for you, could you tell me about implementation time?

      Considering the perfect world, when you've got a simple landscape (only one development system) and you want to implement ChaRM just for ERP for example. How long the implementation should take?

      Thanks in advance!