Skip to Content

Given the increasing volumes of change most SAP IT teams have to manage, I’ll be using the next few blogs to share what we have learned about Release Management and the various methods of controlling change in a release managed environment.

But firstly, let’s consider what Release Management is and why an organisation might consider it.

Release Management

On an ongoing basis changes of various types and differing volumes are introduced into existing production environments (Business As Usual or BAU). According to Gartner, five different types of change are going to be introduced, these being:

•    Large business enhancements
•    Small business enhancements
•    SAP support packs
•    Problem resolutions
•    Emergency fixes

If change was to be managed via a release, new functionality would be collected to be promoted to an existing production environment in a release ‘package’ on a given date. The release may contain one or more types of change, for example:

•    New business enhancements (e.g. Projects)
•    Small changes to existing BAU functionality (e.g. Change requests)
•    Non-urgent fixes to existing BAU functionality (e.g. Service requests)

If managed by release, all approved changes would be developed and gathered and released together as a single package of work. An appropriate amount of time for planning and testing of the changes is allowed for and conflict with other BAU change is minimised.

Considerations

The key objective of Release Management is to protect the live environment whilst enabling BAU changes and enhancements to be implemented in a controlled way.

In high volume change environments, Release Management can minimise the risk of business process interruptions associated with system changes that have been poorly planned or insufficiently tested due to time and/or resource restraints.

Any organisation implementing new functionality that is closely related to existing functionality, whilst simultaneously processing a steady volume of BAU fixes and changes, could also consider Release Management as a risk management strategy. An example might be an ERP solution that is to be rolled out to a new area of business, for which business processes are required to differ from those of the business areas already implemented or the merging into an existing solution of a recently acquired business.

Release Management is less important for organisations for which the existing functionality is very stable or the new functionality being implemented is not likely to conflict with the existing functionality.

Next blog

In the next blog, we will be discussing the Release Management system architecture and several critical factors for success.

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Santosh S A

    Hello Rick,

    I have read through this blog and searching for more details and information on the right system to install the Rev Trac – ECC – non-prd or PRD or on a solution manager . For java transports is it mandatory for Rev Trac to be on a dual stack (like solution manager)

    Could you please help me if these are covered in any of your blogs as this is required for me to analyse and install Rev Trac on the right system with the correct approach.

    Regards,

    Santosh

    (0) 
    1. Rick Porter Post author

      Hi Santosh,

      Thanks for your comments. I believe the Rev-Trac  support team have been in touch in the meantime. No doubt they have confirmed that the Rev-Trac Master System is usually installed on a Solution Manager system and that a dual stack install is not necessary for the management of Java Transports.

      If you have any other queries, please don’t hesitate to contact us.

      Best regards, Rick

      (0) 
      1. Santosh S A

        Thank you Rick,

        The Rev Trac support have been very helpful in assisting me with the questions on this subject.

        Regards,

        Santosh

        (0) 

Leave a Reply