Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

In a multi-lane SAP change strategy, Lane 4 is for large SAP projects that implement new SAP modules, upgrade major systems or for major in-house projects. A typical Lane 4 project might take six to twelve months to go live. Such projects run parallel to many Lane 3 releases and any number of Lane 1 or Lane 2 changes.

The traffic in Lane 4 travels much slower than the traffic in the others and so the potential for end-of-line collisions is very high. As more frequent change arrives in production from the other faster lanes, the base project code may have wandered away from the current state of productive systems they are heading towards. This loss of sync can result in significant post ‘go-live’ issues. I had one company tell me that the overwriting of 10% of standard BAU change per project release was not unusual.

Longer deliveries also face bigger policy enforcement challenges. Your in-house developers understand that what they do can cause serious issues for the business if they bend processes too far. But visiting contractors probably lack knowledge of your processes. They need more guidance - and on large projects, there are likely to be more visiting contractors involved.

Good change control software, like our own Rev-Trac, ensures all users know the rules. Its configuration will reflect your organization’s own unique processes. The way you do things can be an important tool for policy enforcement, so good change control software will honor, not change, your processes.

Shorter Lane 3 releases or projects often “borrow” a Lane 4 project’s resources. Good change control automation and policy enforcement will reduce resulting backlogs by relieving bottlenecks and eliminating human errors. You’ll see fewer go-live crunches and, with automation, all changes will have proper audit trails.

Any change request should have all transport requests relating to that piece of functionality attached so that a request carries all of its own related dependencies and nothing gets lost.

What you attach depends on your processes. You might treat a request as either a vehicle or a passenger with a 1:1 relationship, or as several transports related to each other and attached to the same Rev-Trac request. You can create dependencies between transports and change requests, linking them to make additional remaining changes easily visible. The details will depend precisely on “how you do things.”

With large changes, you’ll need systematic documentation - specifications, budget approvals, test scripts and results, and all the pieces of information that are collected along the way. Attach it all to your change request and make completeness a criterion for final promotion.

Most of these considerations also apply, to a lesser extent, to shorter-deadline changes. The key to managing all four lanes effectively is to find a good software solution, like Rev-Trac, that you can configure to provide automated enforcement of your own processes.

Flexibility in the change control technology selected is crucial – with it, enforcement is possible and multi-lane delivery strategies can be kept humming.

Labels in this area