How to successfully manage SAP change across an N and N+1 landscape!

Managing SAP change across increasingly complex landscapes can be a nightmare for SAP IT teams.

Yet, IT still has specific goals for better SAP change outcomes including:

• Speed: delivering business-requested changes quickly
• Quality: avoid unscheduled systems downtime
• Compliance: ensure changes obey mandatory regulations

To meet the challenge of managing SAP change in complex environments, more and more SAP IT teams are deploying N and N+1 landscapes. This helps to minimize risk and better manage projects, enhancements and business-requested changes.

In this approach, N is the business as usual track (BAU) and N+1 is for projects, releases, upgrades etc. So, SAP IT teams can develop and test major projects in a separate landscape without disrupting the business.

The benefits of this method are well documented. However, the risk and challenges of managing SAP change in a complex N+1 environment are not so clear.

Managing SAP change in N and N+1 landscapes

N and N+1 landscapes have several change control challenges that increase levels of risk and threaten production system stability.

Managing SAP changes at the same time across parallel development systems and eventual delivery to the same production system accounts for much of the risk.

While significant, however, it is not the only control challenge inherent in N and N+1 landscapes. SAP IT teams need to:

• Ensure all changes in the production and support track are reapplied to the project track;
• Prevent developers from making parallel changes to the same object in each system without being aware of each other’s changes; and
• Identify when N+1 track transports need to be migrated to production – and in which order – to deliver SAP applications and enhancements.

As a result, most organizations manually keep account of all maintenance (BAU) changes and rekey each into the project track to prevent overwriting project changes.

The problem is, re-keying is a time-consuming process and is prone to human error. It may delay the go-live date of new functionality until rekeying has finished.

So, what’s the answer?

Automating your SAP change management processes. Adopting tightly controlled automation and uniform governance to your N and N+1 environment enables you to deliver high volumes of SAP change, more frequently with less risk.

Meaning you can respond quickly to changes in the market, eliminate conflicts between transport and maintain production stability. And your SAP IT team is now free to spend more time on innovation and less on fixing problems resulting from incorrect transports being migrated to production.

Rev-Trac as the starting point to managing SAP change

Rev-Trac delivers full SAP change management automation with policy enforcement and complete, audit-ready documentation.

The solution incorporates features and capabilities which address N and N + 1 challenges. These include:

1. 1. Project concept and request cloning
      In an N and N+1 landscape, individual changes are allocated to one of two tracks – production support and project. When changes in the production support track reach PRD or any pre-defined point in the cycle, Rev-Trac can automatically clone requests for reapplication to the project track.This ensures all BAU (N) changes are considered for reapplication into the project track, preventing potential overwrite when N+1 work is promoted to PRD.

1. 1. Locking system
      The locking system fosters cross-track collaboration between developers making independent changes in parallel tracks. Developers receive an alert when attempting to change an object or configuration table in one track that has been changed in the other.Cross-system locking highlights any parallel development taking place, so developer leads can better manage and control it.

1. 1. Protecting project changes with OOPS
      When moving production support changes to the project track, it’s important to ensure they don’t overwrite present project changes. Some organizations spend countless developer hours rekeying production support changes manually. A method which contributes to rising costs and threatens SAP systems stability.To avoid costly, unscheduled downtime, Rev-Trac incorporates an Overtake and Overwrite Protection System. OOPS automatically migrates production support changes to the project track, eliminating high-risk manual effort. If OOPS detects the proposed migration would overwrite a change saved to a transport in the project track, for instance, an alert is sent to the developer.Pre-migration OOPS makes re-keying an exception rather than a rule. Up to 95 per cent of BAU changes can be reapplied automatically, minimizing risk and releasing developer resources for innovation.

1. Release concept and Release Management Workbench
   Every Rev-Trac request can be assigned to a user-defined release within a single track. At the same time, controls can stop changes associated with the release from migrating to a particular system – such as PRD – until specific conditions are met. When approved, Rev-Trac migrates the changes automatically or on command to PRD in the correct sequence.Rev-Trac’s release management workbench simplifies the collation, management and categorization of SAP changes for deployment which helps to maintain systems stability. Managing N+1 work in pre-defined releases enables PMO’s to determine which groups of transports should go when and in which order. As a result: it’s easier to deliver functional software in project, Agile or release formats.

For more information on how automation can solve the nightmare of managing SAP change in complex environments check out our Rev-Trac resources page. Or if you have a specific question, reach out to one of our experts will get in touch.