Release management under a new sign
Those of you who know me know that I have always been a friend of release management and that I always share this with customers in workshops and consulting days. Unfortunately, it's not that easy for me to convince users of this in workshops and consulting days.
The usual counter-arguments are that the department cannot wait for the requirements, but must have them put into production as soon as they are ready.
If we dig deeper, we find that the business department was able to wait a very long time during the test. All in all, we are unfortunately used to importing changes almost daily in the SAP environment due to our history.
Some SAP users then like to talk about a "daily release" in this context. While we are used to waiting for releases or support packages in other applications - no one would install individual features in their office at random - this is often a new thought for users and IT departments in SAP.
This has led to the fact that the "Normal Correction" was mostly not used by customers, since the "Urgent Correction" is more practical. You don't have to plan releases, but can always put individual changes into production - if the department wants to.
Of course, the transition from continuous development to a release does not happen immediately and at the push of a button. The organizational changes required are usually much more profound.
Up until now, release management has also always been very rigid. I was always asked what would happen if it was decided during implementation that certain requirements should not go live or were postponed to the next release.
SAP has responded to all these issues. While there used to be different Solution Manager projects to which individual changes are assigned, there is a real release in 7.2.
In the past, every change that was requested and approved via a workflow had to be assigned to a project before it was released. Woe betide anyone who incorrectly assigned a change to a project here.
Once the change was already in development, this could only be rectified with a great deal of manual effort. In some cases, customers also used add-ons to transfer the change to another project.
Fortunately, the release formation now takes place when we are talking about a real go-live. This is not quite as compliant as we know it in the non-SAP environment. But it is probably one of the ways to convince users of release management in SolMan. An organizational change is still necessary.
IT is required to talk to business departments, create release planning, and also agree on a true distinction between urgent requirements and changes that belong in a release.
I always have customers who shy away from exactly this conflict and then initially start bundling the projects as a release. Everything that is not a project, i.e. does not exceed a certain amount of work, is handled as an "urgent change".
At first glance, this sounds simple. However, if you consider the background of the transport control, the situation is much more complicated.
Since "Urgent changes" must also always be assigned to a project, they are imported again during go-live to ensure synchronicity. However, this means that customers running multiple projects in parallel must always assign all "Urgent Changes" to the project that goes live next.
In practice, this is more than complicated. The change manager is left looking like a drowned poodle when two projects play castling at short notice. Then changes have to be reassigned, which is not possible today in version 7.1 at the push of a button.
With SolMan 7.2, customers can now either develop completely "urgently" and always put everything into production, or they can make a real release at the time of going live.
All in all, this is a real and incredibly valuable enhancement. The challenge for IT managers now lies in anchoring the release mindset in the SAP context in their own company as well.
