The Change Request Management (ChaRM) component of Solution Manager (SOLMAN) offers an organisation the ability to control changes in their SAP environment. I am confused as to why more organisations do not use SOLMAN and ChaRM to drive efficiencies, savings and reduce the risk to their production systems.
Thankfully according to recent feedback the take up of SOLMAN 7.1 is on the up and hopefully these companies are using it for more than simply generating installation, upgrade keys and approving downloads. However, the real efficiencies and cost savings are in additional components such as ChaRM, Testing and Documentation. There is a lot of focus in the forum with regard to the technical configuration of ChaRM and their related components of Service Desk and Incident Management and rightly so. A component that is as flexible as ChaRM unfortunately requires a sophisticated and complex configuration mechanism. However, for a moment I’d like to focus upon what I see as one of the other strands of a ChaRM implementation which are sometimes lacking which seriously undermines the effectiveness of ChaRM.
One of these strands is a strong project sponsor. Certain elements of SOLMAN can be implemented and utilised relatively independently within an IT department. For example a project manager may utilise the project documentation of SOLMAN quiet successfully within his project team and the NetWeaver manager utilise diagnostics and monitoring within his own team. However, ChaRM crosses so many different teams requiring the cooperation of them that without buy-in from every team a ChaRM project is doomed to failure before it even starts.
ChaRM requires that the NetWeaver manger configure the SOLMAN system and maybe ChaRM itself; end or key users request changes; Change Managers approve and categorise requests; ABAP or application teams work on the changes; testers to test; and operators move the requests to production once approved. More significantly than this are the changes to the modus operandi of the organisation when it comes to change requests. All change requests must originate from the SOLMAN system and everyone in the organisation must align to the regular maintenance cycles for the release of changes. Such difficulty in changing the modus operandi of the organisation can be seen by the compromising position that some organisations take by only utilising urgent changes thereby giving their developers some of the flexibility they previously had.
Such challenges of instilling organisational changes can only be accomplished by a strong project sponsor high up enough in the organisation who will drive the changes throughout the different teams in the IT department and will force through the organisational changes. ChaRM certainly does save time and money from a processing perspective and reduces the number of unauthorised changes in production but if it is implemented in an organisation without cross team support it will not be a successful implementation.
The final nail in the coffin is that any future attempts to revive SOLMAN it will suffer from the misplaced memory that it was ChaRM itself that was the failure last time rather than the implementation.
In summary while there is a significant amount of work with the technical implementation of ChaRM please do not forget the core project management aspects of a ChaRM implementation as this type of project is particularly susceptible to the lack of them. In fact, and speaking from personal experience, unless there is a strong project sponsor I would seriously reconsider implementing ChaRM at all and I do hope that you do not underestimate the organisational changes involved. I am a fan of ChaRM and I do wish to see many more successful implementations and wish you the best in yours.
