ChaRM Offensive
With version 7.2 of the s, SAP is also changing some things in Change Request Management, especially in the linking of change requests with documentation.
This has always been a sore point when I've talked to customers about change management and also managing the associated documentation.
A ChaRM implementation definitely makes sense, but it also has to be well planned. It is impossible to launch it as a submarine, so to speak, in SAP Basis and then have it pop up at some point.
Since change management maps all disciplines from application to go-live via a workflow, various areas in IT all the way to the business department are naturally involved.
The first step starts with an essential objective. Why does an IT department want to introduce change request management in the first place?
What are the goals associated with that? I've seen a whole portfolio of goals here over the last few years. From avoiding media discontinuity to the topic of regulatory requirements, many goals are legitimate.
However, it is important to have this specification, ideally combined with guard rails, as it is always possible to keep in mind how much the different variants contribute to the goal when discussing processes and procedures at a later stage.
ChaRM implementations that simply replace an existing tool - even if it is Excel on a Windows share - are usually doomed to failure. With a ChaRM implementation, one should also discuss existing procedures.
It is therefore important to develop a concept for the processes. In my opinion, ChaRM prototypes that are then used in a productive system landscape after basic customizing is complete are not very effective, because they usually do not include processes and documentation.
Only when the concept is in place, an implementation makes sense. In particular, the following points should be considered and detailed for the creation:
- What change processes currently exist for SAP changes?
- How should a software change be documented in the future?
- What do the target landscapes look like?
- How is the cross-system object lock handled?
- How are requirements described and by whom are they approved and planned?
- Is release management desired?
So there are a lot of open issues that certainly can't be resolved in a workshop. Rather, they require a lively discussion within IT as well.
Since IT processes cannot be defined on a grassroots level, the IT management has to define them. The most surprising issue for me in recent months was a customer who wanted to implement a general change process, but wanted to map a special workflow for two key users. It makes sense to cut off precisely these kinds of braids.
Authorizations are a much-loved topic. Unfortunately, a customer without a ChaRM workflow usually only documents his requirements and changes in a very rudimentary way.
Nevertheless, these very customers then have concerns in ChaRM that every key user could also read the change requests of the neighboring department. Although it is possible to set up in-depth authorization constructs for this purpose in Solution Manager, you should then also carefully consider whether it is really worth the administrative effort.
It is not difficult to set that only the IT employee who is assigned to the change can also process it. However, I always wonder how the customer would like to act if this very employee were to fall ill.
Since the topic of documentation is also closely linked to ChaRM, this aspect must also be clarified. Here it is relevant to define templates and also to demand these in the respective workflows for a change request or a change.
In sum, a concept and a roadmap are the most important things for a successful implementation. The technical implementation is - as is often the case in the area of application lifecycle tools - the least effort driver.
The organizational changes are not to be neglected and are often the guarantor for a successful implementation.
