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 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 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 – Business Critical – |
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 | Limited EUT only Regression Test | Approximately |
Emergency Release | Urgent action required. Major business process or system will stop working without fix. | Specific | Emergency Fast-track |
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.
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.
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
