A Practical Approach to SAP Release Management

By: Kim Snow    Posted: February 18, 2010    Category: SAP White Paper
A Practical Approach to SAP Release Management

Why SAP Release Management?

Regardless of an up or down economy everyone wants to get the most value for their dollar; particularly in the IT space where costs continue to rise. There are always more projects to be done than a company can reasonably afford. The more mature your SAP environments become, the more changes, upgrades, and enhancements, your company needs to make. SAP is always rolling out additional modules, support packs and new versions.

Every business sponsor would like to believe that their SAP environment has been built in the same manner and approach as a master carpenter who builds their own home – using the best materials and paying attention to every painstaking detail until the home is finished. Then for the next 20 years the builder provides enhancements to the structure, sparing no expense on maintenance, upgrading rooms, and keeping up with the latest trends in home improvement.

The reality is, however, that many SAP projects are underfunded and planning isn’t always perfect. Many details of the implementation are left until the proverbial “Phase Two”. This cleanup phase often never comes for a variety of reasons. Sometimes attention and money is turned to new technologies or pressing projects. Often there is turnover in expert staff without proper knowledge transfer. As of late, changing market conditions have caused a shift in priorities away from IT projects. Instead, there has been a greater emphasis on making what is already in place last a little longer and work a little better. Paying for SAP does not stop after the initial implementation. Making changes to an existing landscape, upgrading, and adding modules or instances comprises a bigger part of the IT budget at most companies. For the most part everyone understands the need to control “changes” and ensure that these changes are compliant. SAP like many other ERP systems is an integrated solution. It is not enough to manage changes by making sure they fall within compliance guidelines.

One of the outcomes of the introduction of the Sarbanes-Oxley Act of 2002 focused organizations toward compliance and controlling changes in their IT environment. This adherence to compliance helped to stabilize environments to some extent. During the early 2000’s companies spent a lot of money and energy into becoming compliant and putting controls into place. Every change introduced to the system has the ability to “break” the system. The amount of changes and the speed at which change is introduced is directly proportional to disruptions in service and downtime. Because SAP is so integrated one can follow all of the compliance requirements and pass single objects (change requests) through all testing and pass, yet still have problems once they reach production. Hence, the need to package sets of changes, the need for Release Management.

What is Release Management?

iRelease Management is used by the software migration team for platform-independent and automated distribution of software and hardware, including license controls across the entire IT infrastructure. Proper software and hardware control ensures the availability of licensed, tested, and version-certified software and hardware, which functions as intended when introduced into existing infrastructure. Quality control during the development and implementation of new hardware and software is also the responsibility of Release Management. This guarantees that all software meets the demands of the business processes.

The goals of release management include:

  • Planning the rollout of software
  • Designing and implementing procedures for the distribution and installation of changes to IT systems
  • Effectively communicating and managing expectations of the customer during the planning and rollout of new releases
  • Controlling the distribution and installation of changes to IT systems

Release management focuses on the protection of the live environment and its services through the use of formal procedures and checks. A Release consists of the new or changed software and/or hardware required to implement approved changes.

In common terms Release Management is simply this:

Organizing a set of desired changes into one concise cohesive work package whose components can be developed together, moved to the quality test environment together, tested together, and then moved to production as one change (release).

The Manufacturing Analogy — W.I.P.

Whenever I talk about Release Management I relate to it in terms of a simple manufacturing process. Orders or changes come in as separate pieces like materials coming into the front end of the process (such as a funnel). The changes (materials) are sorted out in some priority fashion and sent through the landscape from development to test and into production much like “Work In Process” phases of the manufacturing process. If one were to develop parts of a machine using metric measurements and another set of parts using American Standard measurements, the two sub-assemblies obviously would not come together in final assembly. It works the same way in integrated ERP systems like SAP. You can manage individual changes, individual modules, individual projects, but sooner or later they get integrated and rolled into your total solution. Unless they are developed and tested as subassemblies you can have a problem when they become part of the complete solution. See the diagram below:

A Practical Approach to SAP Release Management

The Problem with Managing individual Changes

There are three key problems when managing individual changes in a complex ERP integrated environment: “code collisions”, incorrect prioritization, and improper utilization of resources.

For example, let’s say I am managing independent changes and I introduce a change to the test environment on a Tuesday and test it and the change works. I then introduce a change to the test environment on Thursday and this change also works. However, the change I made on Thursday caused some failure to the change made on Tuesday. I would not realize this failure until it showed up in the production environment (i.e. a “Code Collision”). A Code Collision is an error which could cause system downtime or causes problems for the customer including potentially costing the customer money to untangle (locked tables causing automated jobs to stop in their tracks etc.). If I had, instead, held the first change and then moved the two changes into test together, I would have found the “code collision” and been able to correct it in the test environment.

The second issue caused by managing individual changes is improper prioritization. As changes come into the funnel they are prioritized. When individual changes are requested there is a tendency to work on what is perceived as most important rather than what may benefit the organization as a whole. To coin a few terms “the squeaky wheel gets the grease” and “whoever has the most money gets the service” (The Golden Rule). My personal favorite – “your lack of planning does not necessitate an emergency on my part”. I am sure we have all worked in environments where this is the perception of how work gets prioritized and resources assigned.

The third issue with managing individual changes is an improper allocation of resources. Many times a report request will come in from one division and a developer will be assigned to complete the coding. Another developer in another work area may be doing a very similar report with the same data. It is possible the two reports could have been assigned as one using different variants. Unless the developers are talking independently with each other this waste of resources often goes undiscovered. Perhaps there is a better way to gain some synergies.

Managing Changes as a group — Release Management

When you begin to look across all of the changes that are coming into the IT organization you can begin to see logical groups of changes (i.e. this set of changes are all reports that may contain some of the same data, perhaps they can be developed together realizing some synergies). The next set of changes are all for one division so we can tap the business resources for one period of time rather than constantly going to them for testing and SME time. Another set of changes will require a hardware upgrade, so the hardware upgrade will need to be expedited to align with all changes that are better served to be done after the upgrade is complete, etc. You can begin to create sets of changes that will reap the benefits of synergies – consistent development without overlap, better scrutiny in regard to correct prioritization and enhanced testing to prevent code collisions in production. See diagram below:

A Practical Approach to SAP Release Management

You might think that this discipline is intuitive and it would be natural to assume that your IT organization is automatically working in this way. However, more often than not, IT shops manage changes on an individual basis and only to the level that is required to be compliant.

For a variety of reasons IT organizations tend to be reactionary. Advances in technology are happening more quickly. Mergers and acquisitions are more frequent and system changes to accommodate those transitions come with little or no advance warning. SAP is shifting from a module based focus (MM, SD, PP, FI) to a more process-oriented view (Order to Cash, Procure to Pay) etc. However, skill sets and development teams are largely still aligned in the more silo construct organized by module area. Managers tend to still react, staff, and organize work in that silo, module, and non-matrix fashion.

Moving to Release Management requires a paradigm shift throughout the organization. The Organizational Change Management accompanied with this shift should not be underestimated. Even though it requires a great deal of shepherding, it is worth the effort.

What are the Benefits of Release Management?

Release Management done properly can create some obvious benefits and some that are more subtle. The obvious advantage of working in a release management strategy is moving changes together through the landscape. One can define specific work tasks and define a timeline that can be managed, thus reducing the cost of “wasted” time in organization and planning (i.e. developers randomly hopping from one fix to the next trying to accommodate shifting priorities). Once a release is set everyone knows the priorities. Only true emergencies can be moved into the release so there will be careful scrutiny. The second most obvious benefit is that objects will be tested together in your quality environment. This testing reduces the risk of failures in production as described in my earlier example. Another benefit is the reduced cost from less errors occurring in production. There will be less backing out code and correcting bad data, reprocessing orders and related work that I call “do-overs”.

Some benefits that are not so obvious can be the synergies obtained from the entire team viewing the system as a whole. Once you move to the release concept you will notice more dialogue around correctly prioritizing changes; performing additional testing; checking to see that infrastructure needs, storage space, and security questions are answered ahead of time instead of at the 11th hour. All of this dialogue leads to better performance from your delivery teams.

Some benefits that are not so obvious can be the synergies obtained from the entire team viewing the system as a whole. Once you move to the release concept you will notice more dialogue around correctly prioritizing changes; performing additional testing; checking to see that infrastructure needs, storage space, and security questions are answered ahead of time instead of at the 11th hour. All of this dialogue leads to better performance from your delivery teams.

Are they in the pipeline? Are they poised to move to production? Once you establish a release calendar everyone knows when the next move to production will take place.

How Do I start Release Management?

I approach moving from a change/control management discipline to a Release Management discipline in three steps. I will go back to the manufacturing analogy for a moment.

  1. Step 1) Secure the pipeline.
  2. Step 2) Rearrange and manage the funnel.
  3. Step 3) Enhance both the pipeline and the funnel (process and architecture).

These three steps are counterintuitive and here’s why. It would seem to make more sense to start at the top by organizing changes as they come into the funnel, building relationships across the business areas and building bridges into the IT organization then building out your landscape and infrastructure to match how you plan on developing releases, and finally, ending with actually moving releases through this well-defined structure and process as a release. From a process standpoint that makes sense. But the reality is that you are processing changes every day. More changes are coming in all the time, and as stated earlier, you cannot underestimate the organizational change management needed to shift the paradigm and recover from perhaps some already poor relationships between business and IT.

In addition, many company’s first reaction is to go out and find a tool that can perform release management. Some comprehensive tools can be brought up with minor configuration in order to manage changes, build releases, and do it automatically. I highly advise against considering tools until much later in the game. You cannot hope that a tool will take the place of a sound process or that it will fix bad will.

In addition, many company’s first reaction is to go out and find a tool that can perform release management. Some comprehensive tools can be brought up with minor configuration in order to manage changes, build releases, and do it automatically. I highly advise against considering tools until much later in the game. You cannot hope that a tool will take the place of a sound process or that it will fix bad will.

Now that you are forming an organized queue that will allow you to present future target dates to the business, you can establish a calendar based on how fast requests come in and the type of resources you have at your disposal. Also take into consideration what the business will tolerate. You may prefer to move to quarterly releases but that may be too big of a paradigm shift and you will have to settle for monthly releases. After a few on-time moves to production you will have restored some confidence between business and IT. You have now “Secured the Pipeline”.

Step 2: With confidence levels rising you can now begin to work on the funnel. Organize requests that have already been submitted to your organization. Reconnect with the business and begin to build bridges talking about effective prioritization. Organize IT managers so they are looking across all of the changes coming into the IT organization rather then looking at just what is in their individual queue. Once you have re-arranged the funnel and how managers view the work, you can now manage the flow of information coming into the funnel.

At this point you can begin to look at what types of releases you may wish to produce. Do you organize releases by process area, by division, by project types? Do you treat projects as separate releases independent of operational-type changes? How you organize releases depends largely on how you work the relationship between business and IT. Once your changes are coming into the funnel and being assigned into specific releases you have completed step 2.

Step 3: Enhance the pipeline and Funnel (Process and Architecture). Finally, you can consider how to enhance the manual process you have built. Enhance aspects of both the funnel and the pipeline. Maybe now you can consider creating some N+1 landscape architecture or perhaps an alternate production path for low impact changes vs. long term projects. Maybe you increase the type of testing or enhance testing with automated tools. You can investigate how to streamline the process in which changes are brought into the IT area (a single path for entering changes). Now is also the time to look at tools that can automate some of the workload in regard to change management. SAP Solution Manager CharM? There is no point in doing this, however, until you have a manual process that works. Automating a mess creates an automatic mess.

So in summary the three steps in effectively beginning release management are:

  • Secure the Pipeline (manage what is in the process)
  • Re-arrange and Manage the Funnel (control the front end)
  • Enhance the Process and Architecture

What Are the Pitfalls of Release Management?

Moving to a Release Management discipline has some drawbacks at first. It is a paradigm shift that requires organizational change management. Once you overcome the initial resistance you will raise confidence by producing fewer errors in production. The business units will be happier with the IT organization, developers will find the repeatable process easy to work within, and testing will become more comprehensive.

The hazards are that there will be an initial resistance from the business when you tell them you need to slow moves to production. The knee-jerk reaction can be “you mean to tell me I have to wait weeks just to put in a two line code change?” You may also get a backlash from developers who contend it is easier to deal with changes as they arise rather than treating changes as a group. You may also expect dissension between development teams. The thinking initially may be, “we are already organized better and work faster than so-and-so group — we can’t wait for them! Our process is too different”.

As is always the case there will be requests that come in late from the business that must be done. Priorities will shift based on the market, the season, or economic climate. Mergers and acquisitions will happen. People will move in and out of roles. Larger projects will threaten your ability to control the release timeline. There are answers for these objections and other objections you may think of that will probably be raised; ones that I haven’t mentioned in this paper.


1. SAP is too complex and integrated to continue moving changes individually.
2. Release management requires effort in Organizational Change Management.
3. There is a three step process to effectively starting Release Management.

  • Secure the pipeline
  • Rearrange the funnel
  • Enhance the process and architecture

4. The benefits of Release Management include

  • Lower costs per change
  • Fewer production errors
  • More comprehensive testing
  • Better prioritization of work

The description of Release Management is taken from the following: http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library

About The Author

Jim Gerber PMP SAP Release Manager

Jim Gerber is a PMP certified project Manager with 15 years IT experience. He holds a Bachelor in Business Administration from Carthage College, Kenosha Wisconsin. He has played a variety of roles in SAP from Developer to Project Manager. Jim is currently the SAP Release Manager at a Global Pharmaceutical Company.

To contact Jim Gerber or discuss how we can assist you with implementing a Release Management strategy, please call Kim Snow, Vice President of Delivery at BayForce, 813-908-8593 or send an email to ksnow@bayforce.com.


We’re here to help. Call or email any time.