Skip to Content

Release Management in SAP –A structured Approach -Part2

In the continuation of previous blog http://weblogs.sdn.sap.com/cs/junior/view/wlg/22804 Release Management in SAP –A structured Approach -Part1The Change and Release classifications and definitions (mentioned below) as well criteria cover scope of Release Management and also any change applied to the Production Environment. This incorporates both internal & external code change as well as data changes.  This emphasized Business–as-usual (BAU) transactional data maintenance is not within the scope of Release Management and also helped us in 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 following table provides an overview of the four primary types of system changes, change criteria, and examples. This we considered taking into account of users to be impacted, business functionality, and also to align with BAU so we had a couple of sessions with BAU team, Service delivery managers, and as well key stake holders.

 

Change Type

Criteria

Examples

Major Change

Significant functional enhancements which impact multiple parts of the system, or multiple systems.

Country go-live

New application

Major functionality changes
(> 100 hours)

Application Upgrades (e.g. version change)

Operational Change

Collection of non-emergency changes that have the potential to affect multiple system elements. Each release will have limited scope.

SAP Support Packs

Legal and Regulatory

BAU changes

Minor Change

Simple changes that are contained within one element of the system and which do not require a full regression test.

Minor enhancements
(<100 hours)

Incident (Defects) Fixes

Configuration updates

Minor report change

Emergency Change

Required to solve immediately, critical system or business issue for which there is no work around and the fix is required before the next scheduled release.

System outage

Legal and Regulatory –
Fast Track

Business Critical –
Fast-Track

 Releases Types

The table below provides a high level overview the three release types.

Release

Criteria

Testing Required

Frequency

Major Release

Country go-lives

Major Changes

( >100hrs effort)

Major Test Schedule (Integration, EUT, Regression)

3-4 times per year

Mid-quarter

Minor Release

Incident fixes

Minor changes
( <100hrs effort)

Limited EUT only

Regression Test

Approximately
Bi-Monthly

Emergency Release

Urgent action required. Major business process or system will stop working without fix.

Specific
Functionality Test

Emergency
(by exception only)

Fast-track
(IT&S controlled)

 

Major Releases

Major Releases are significant release windows intended for the introduction of major new functionality or country go-lives. Major releases provide a longer time frame for more significant system testing, EUT, training, process updates, work instruction changes, and change management generally associated with the introduction of major change across the business.  All changes will be considered to be a part of a Major Release unless approved by exception by the Change Approval Board to be introduced sooner into the production environment.

The following is a list of considerations/criteria for scheduling changes into releases.

  • Is the change a non-critical business or system change?
  • Can the change wait until the next release?
  • Does the change require a system outage to implement?
  • Is the change global, common (multi-country), or local (one country)?
  • Is the change a major change (> 100 hours)?
  • Is significant End User Testing (EUT) required?
  • Is training required?
  • Is change management required?
  • Is full Regression testing required?

 

If the change meets the above criteria, then there should be no reason why the change cannot be applied during a Major Release cycle.

Frequency
Major Releases will be scheduled approximately every 3-4 months.  The World Class Close year end freeze period will impact any release in the fourth and first quarters. 

 R1

Minor Releases

Minor Releases are much shorter release cycles intended for the transport of incident fixes and minor enhancements into the production environment.  Due to the shorter cycle, larger, more complex functionality may not have the appropriate amount of time available for testing, EUT, training, process updates, work instruction changes, and change management across the business.

 The following is a list of consideration/criteria for monthly release.

  • Is the change local?
  • Is the change a minor change (< 100 hours)?
  • Is minimal EUT required?
  • Is minimal to no training required?

 Enhancements may be released during a monthly cycle if they are required for usage prior to the next major, quarterly release cycle. For example, a payroll legal or regulatory change may be required to be applied prior to the next payroll run.

 Frequency

Minor releases will be scheduled every 1-2 months.   Various factors such as payroll cut-offs, and maintenance windows will impact the timing of these releases.

r2

Emergency Releases

From time to time, an emergency fix or change will be deemed necessary.  An emergency fix may require an emergency release into the production environment. An emergency release may not always be required if a planned release is imminent.An emergency release is an unplanned and off cycle release into the production environment.  Emergency releases are to be minimised as much as possible and should only be used as a last resort to resolve an issue.  Unplanned releases have the potential to cause serious disruption to the business and may cause greater issues if critical processes, such as a payroll run, are interrupted.

 Below is a list of additional key considerations/criteria for the decision to action an emergency release.

  • Is the fix required immediately? If so, why?
  • Is a workaround possible until the next release?
  • Will the system or business stop working if the fix or change is not applied?
  • Will a major process fail if the fix or change is not applied?
  • What are the other impacts of implementing an emergency release at this time? (e.g. Payroll runs)
  • When is the next scheduled release?
  • How many users are impacted?
  • What are the operational readiness impacts?
  • What is the financial impact of delaying this release?
  • Is this a regulatory requirement that must be in place before the next scheduled release?

 Emergency fixes will require exceptional approval by the Change Approval Board.  Emergency Releases will also require exceptional approval by the Change Approval Board. 

In blog Release Management in SAP –A structured Approach –Part3 http://weblogs.sdn.sap.com/cs/junior/view/wlg/22814 we foccussed  on Release Management process ,various inputs coming from  different processes such as change management etc.

In blog Release Management in SAP –A structured Approach –Part4 http://weblogs.sdn.sap.com/cs/junior/view/wlg/22816 we foccussed on Release Management Governance,roles and responsibility,and Communication.

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