Managing Change in a Release Management Environment – Part I

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.