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

[former_member214561]

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:

http://scn.sap.com/community/it-management/alm/solution-manager/blog/2015/02/12/how-to-make-a-succes...

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!