These days many people know about what SAP calls a “5 system landscape”.

You may know it by a number of other names used by the SAP intelligencia…. dual track, multi-track and N+1 to name just a few.

To us, it is our SAP Parallel Track Development methodology.

In essence, it’s the idea of running your SAP production support stream in parallel with a project, or multiple projects, each of which has separate development source systems and associated test systems.

The development systems generally start as a copy of each other (or a copy of your production system) at a given point in time, but very quickly get out of sync with each other as your project development team and your production support development team go their own merry way, due to project and business drivers, with little or no consideration for the consequences of their actions on the other.

And that brings me nicely to the whole topic of this post – why customers should run a parallel track development landscape when it really sounds like a risky thing to do and a recipe for disaster when trying to bring your parallel tracks in line for a major release or project go-live.

In fact, I’ve met many people over the past 15 years of running this process who have been very badly burnt trying to run multiple SAP development systems.

These are very senior people who are often then (and now) project managers that know of the terror and pain that this process can cause to the SAP project people supporting it.

They often look at me with wild-eyed terror, a quizzical look of “Why would I ever want to do that again!?” burnt into their face.

The WHY is driven by business demand, to enable a rapid response to changing market conditions and the ability to grab a commercial opportunity before any competitor.

This flies in the face of traditional project and programme planning methodologies where the scope of a project is defined rigidly up front.

Each step has a set of sequential milestones, any changes to the original scope (or the sequential step) are wrapped up in a labyrinthine paper trail and approval process, where other initiatives are delivered in non-overlapping slots.

So what do you do if the real world intervenes …

The traditionalists will argue about risk to their project deliverables, the production systems they support and in short provide the fuel for many business leaders to describe IT professionals as lacking commercial awareness, innovation, and a blocker to progress.

The more enlightened (or pressured who cannot say no!) will try to rise to the challenge and venture into the world of Parallel Development Tracks.

The opportunity this provides is to run multiple initiatives at the same time and continue to provide high-quality support to current business processes with minimal fuss, risk and little to no downtime on change allowing the business to adapt to the outside world in an effective manner.

In my experience attempting this without a clearly defined method, good process and procedures, the correct tool, and people with the determination to succeed, normally results in chaos.

But you’re still not telling me why I should do this…

For me, the benefits are best highlighted through a customer example, BP.

They are one of our largest customers and use our products and methodologies globally for over 80 SAP systems.

Initially, they ran our multi-track process on their HR transformation project to draw over a hundred countries HR policies, procedures, management and provision of a personalized portal for over 100,000 users.

By personalized BP meant that when a user logged on they were offered the correct page(s) for their role, and the country providing remuneration, pension entitlements, holiday information … all tailored precisely to the specific user.

It was recognized very early that delivering this project in one hit would be impossible, so it was always planned to be rolled out across the globe in phased releases.

Due to challenges in various parts of the world the HR project were asked to achieve the impossible – or that was the belief anyway!

The only way to meet business deadlines was for the UK to go-live in April 2009 (with 10,000 users) and the US to go-live 6 weeks later (with 25,000 users) followed by multiple country roll-outs, on a quarterly basis for the next 24 months.

That was 10 major roll-outs in just over 2 years, whilst stabilizing and effectively supporting the rapidly increasing productive user base in parallel.

It was said that they were able to deliver a 5-year programme of work in less than 3 years by taking this approach.

And I think that is really what sums it all up in a nutshell.

You run parallel track development in order to deliver SAP changes faster and with less risk in order to make the business more competitive in the markets they operate in.

As an IT department – imagine if you were able to tell the business that you could do this for them?

So how did they do that?

They engaged our team to enable our Parallel Development Track methodology, supported by ActiveControl and field leading consultants.

We implemented the product in less than 20 days, together with our methodology to run the process and engagement of one of their consultants as release and cut-over manager for the programme.

This is a technique developed over 10 years ago, and we are continually driving process/technical improvements to it.

Over that time we have enabled a large number of SAP customers to “achieve the impossible” through the use of this process. They have all seen enormous benefit in doing so.

To learn more about ActiveControl, book a demo now.