Over the years SAP Solution Manager has received a lot of bad press, because it is seen not to deliver benefits. This is mainly because there is often a big gap between what SAP proclaims Solution Manager can deliver and what customers experience in reality. I've always had positive experiences with Solution Manager. Yes it can sometimes be challenging, but having a challenge makes it all the more fun. Furthermore, seeing firsthand the many benefits it can deliver has only added to my positive experiences. I often find that a lot of the bad press Solution Manager receives is largely to do with mismanaged expectations of what the tool delivers, and what is required to install and use the tool correctly.
For many years I have supported companies in realising the benefits of Solution Manager. One question I'm always asked is...
...can I use standard Solution Manager processes to facilitate Application Life-Cycle Management (ALM) processes?
This is often very difficult to answer. Firstly we need to understand why we should answer it and then we need to understand the implications of using the standard Solution Manager processes.
As discussed by Kiran Patel's blog "SAP Solution Manager… too complex and no real value?" Solution Manager is not just a series of tools, it is a platform for reducing TCO and risk in the never ending world of IT change. The diagram below illustrates, at a high level, the scope of the functionality.
So why use standard Solution Manager processes?
The basis of SAP's benefits case for Solution Manager is along the lines of...
Free licensing...if you fulfil the licensing and use guidelines
It's easy to implement
It provides fantastic business benefits that reduce the total cost of operating SAP Enterprise Solutions
We can't argue with the first point. However many companies still don't understand that there are some instances in which an extended license will be required, e.g. if Solution Manager is used to support non-SAP products.
With regards to the implementation, it's fair to say that Solution Manager isn't always easy to implement. For example, if your organisation is not able to use the standard processes then additional effort is required during the build and test process.
On many occasions I've seen shocked faces when the cost associated with implementing custom ChaRM process is understood.
So the reason for implementing standard processes is that it reduces the complexity and the associated implementation cost. In summary standard processes can mean easy implementation, with fewer costs and a stronger business case. This can also change the way in which the business operates and this might not be bad thing.
What are the implications of using standard Solution Manager processes?
Solution Manager provides standard ALM processes which are based on the IT Infrastructure Library (ITIL). As we know ITIL provides a best practice framework for IT Service Management. So with Solution Manager we have a tool that has been structured around a best practice framework, therefore there is a "one size fits all" approach being supplied. On the back of my Solution Manager experiences, I can safely say that this one size does not fit in many organisations.
Example enhancements and drivers
Every IT organisation will be required to meet internal business requirements, and in some cases, external regulatory requirements. An organisation that is required to be regulated, for example financial services or pharmaceuticals, will often approach ALM differently to an organisation that is not required to be regulated. This is logical because a company should only perform activities that add value or fulfil a business need.
In the current release of Solution Manager the standard processes and functionality provide a great foundation however, there are some areas that are still weak and generally organisations need these weaknesses corrected. Just to name a few examples:
There is no standard workflow process for documentation reviews and approval
The Change Request process does not include steps for Impact Assessments and Implementation Planning
The end-to-end Test Management is not clearly integrated to Change Request Management
Change execution processes do not provide all confirmation steps, e.g. approval to start test execution
Digital signatures are not provided in the standard Change Request Management process, e.g. when a authorisation for implementation is given
Maybe if SAP could provide ALM processes that have different options for different organisation types, there will be wider adoption of standard processes. But until this time we need to accept that Solution Manager might not be an out of the box solution for all organisations, and therefore customer specific ALM processes are more appropriate than the standard ALM processes.
On many occasions I've seen organisations decide against a Solution Manager implementation because of the cost, even when there is a strong business case that provides year on year returns. I often think this is mainly down to expectations. Because organisations are told Solution Manager is free and easy to implement, they expect that it does not require a budget. At the end of the day it's just another SAP product which can be tailored to fit your specific requirements, or you can adapt your processes if you have the choice.
If we start our Solution Manager journey with the understanding that investment is required, that we do need a project to deliver a solution based on the organisations requirements, then maybe we can start our projects and gain the benefits proclaimed by SAP.
To aid organisations in starting their Solution Manager strategy we always advocate the following process:
Define the business requirements of your Application Life-Cycle Management process
Analyse the gaps between your requirements and standard Solution Manager processes
Analyse the benefits and costs to get a clear business case
In short the approach is the same as any other system.