The 7 circles of SAP project delivery hell - Basis Technologies

The 7 circles of SAP project delivery hellWhy system changes are slow, clumsy, and every sane person’s worst nightmare

Here’s a basic dilemma:

If you’re anything like a typical SAP-based business, you need a reliable production system that keeps running without fail:

To deliver consistent service


To keep customers happy


To keep customers happy

To protect your revenue

But at the same time....

Your business is constantly evolving. Anything from:

Setting up a new storage location




To creating a new report for accounts





To re-inventing the market with a revolutionary new offer





To re-inventing the market with a revolutionary new offer

… means you need to make a change to your core business platforms.



SAP transports are tricky.

And you need to rely on them more and more often these days. In parallel. At different paces.

To different priorities.

Unfortunately, the way things are right now, pretty much every single SAP change threatens

your working systems with major disruption:

Downtime

If you move faulty code into production and it breaks.

Loss of revenue

Because the crash makes you miss that big delivery deadline.

Reputation

Because you promised that wasn’t going to happen.

Customers

Because they definitely weren’t happy about it.

And that’s a risk every single time you deliver an SAP release.

In short, most companies open the

gates of hell every time they make a change to

their SAP systems.

In short, most companies open the

gates of hell every time they make a change to

their SAP systems.

Here’s what that hell looks like for most organizations:

The visibility vortex


If you’re the person responsible for delivering SAP releases in your organization, you don’t need us to tell you this:


They’re impossible to track.


And that’s not just the requests and ideas for potential changes – it’s the actual development, too. Lots of people are working on lots of changes simultaneously. Even dev team leaders don’t necessarily know who’s doing what and where they are in the process.


Not to mention the C suite, who’s hopelessly out of the loop.

All of which kills collaboration and makes the system changes in your organization about as transparent as brimstone.

Spreadsheet limbo

The reason nobody knows what’s going on is that there isn’t a single system in place that

everybody can work from.

Spreadsheet limbo

Instead, Jim is using IT service management software while John, Mike and Laura are each working from a different version of the same spreadsheet.

Spreadsheet limbo

And that’s not even mentioning the exponential document proliferation that happens when you outsource some of your dev and change.

Spreadsheet limbo

So just tracking everything that’s going on is more than enough to keep release managers and IT directors busy (and close to insanity) all day.

And that means they’re not actively managing anything.

Spreadsheet limbo

Manual process damnation

There’s another nasty effect from all the different documentation silos: You do everything by hand.

Things like:

Ring up the third controller from the left, with a request

for an approval


Things like:

After approval, write an email to your basis guys asking them to deploy the changes


for an approval


Things like:

Stand over their shoulder to make

sure sequencing is done right



for an approval


Things like:



for an approval



Print out a spreadsheet that’s definitely old news

by the time you bring it to the CAB meeting


Things like:



for an approval



Print out a spreadsheet that’s definitely old news by the time you bring it to

the CAB meeting

Re-key changes across several development

systems and hope that they’re identical


Things like:



for an approval



Print out a spreadsheet that’s definitely old news by the time you bring it to

the CAB meeting


Things like:

Re-key changes across several development

systems and hope that they’re identical

Manual process damnation

And that’s no way to run a project, is it?

Agility annihilation

Your production system, which is the big beating heart of your business, needs to be able to react to demands quickly.


For developers, this means continuous dev and deployment. Not twice a year or once a quarter, but whenever the code is ready.


That sounds great, but without an up-to-speed testing setup it easily turns into a business agility killer:



Because there’s no way you can deploy your changes quickly without the confidence that you’ve tested against production-like data.

But as things are in most organizations, it takes ages to stand up a test system that’s wortht its salt.

And that pretty much means saying goodbye to more agile development. And that’s goodbye to agile business change, too.


The torment of QA

The torment of QA

Here’s another reason manual testing is still one of the most pain-inducing processes for many businesses:

In the real world of big-organization dev-test-release cycles, there is no such thing as plenty of time, ever.

The torment of QA

And this means that dev happens in a hurry, with coders trusting the testing team to pick up the pieces, tie up the loose ends and hope that the support team fixes anything that needs fixing.

The only problem is that when changes move to test, testers are usually neck deep in work, and up against several bygone deadlines already.

The torment of QA

So instead of prioritizing quality control early on, you end up washing all the dev debris into test, rushing approvals, and trusting in random sampling and sloppy dependency checks.

The torment of QA

The torment of QA

And that knot-in-your-gut-feeling means you just know this kind of procedure is incredibly bad news for

The torment of QA


• The overall quality of your code

The torment of QA



• The stability of your SAP system.

The torment of QA



• The stability of your SAP system.

YIKES!

The licking flames of approval


Let’s go back to those approvals for a minute. They’re kind of a big deal, because it’s really hard for anybody to see five levels down into the impact of the change they’re approving.


Wouldn’t it be great if...

People actually had some insight into what elements in the system are affected by a given change?



A little red flag popped up when you touched a risky object? Or when two developers are making a change to the same one?



An “ok” didn’t just mean “I guess it’s fine”, but was actually a conscious approval based on a thorough dependency check?


But as things stand, people are authorizing an intimidating number of dev changes without really knowing what is being changed at a technical level.


Which is kind of crazy considering this stuff will eventually come full circle and end up affecting priority number one, which is:


Your. Sacred. Production. System.

The cutover catastrophe

Given all that, it’s really not too hard to imagine the worst nightmare coming true:

A release that you’ve developed and tested. And suddenly, when you’re moving it into production, for some reason, everything goes wrong.



And you know:


And you know: X It will create downtime



X Stop your business




X Enrage your users (or worse, customers)





X Lose you money, every single second





X Lose you money, every single second

X And benefit your competitors.


And there isn’t an option to reverse it in a Control-Z kind of way.


And this simple fact makes you want to be responsible for that transport like you want another hole in the head.

You didn’t need us to tell you:

More often than not, SAP changes are



• Slow



• Slow

• Inefficient



• Slow

• Inefficient

• Unmanaged



• Slow

• Inefficient

• Unmanaged

• Of uncertain quality



• Slow

• Inefficient

• Unmanaged

• Of uncertain quality

• And potentially dangerous to your business.

And you certainly know that for most organizations that have invested in a pricey SAP solution, another costly tool to manage that solution isn’t an option.

And you certainly know that for most organizations that have invested in a pricey SAP solution, another costly tool to manage that solution isn’t an option.

So where’s the good news?

The good news

A lot of the torture we just outlined is actually easily resolved using a few nimble tools that take the hell out of SAP release management. And they let you do some really important things:


Bring everything together in one place So everyone can track the status of changes and releases


Orchestrate parallel development So all your improvement efforts, even in a complex SAP landscape, go hand-in-hand


Embed quality control from day one For faster releases and fewer surprises in test and production


Actively move changes through your system To avoid the downtime created by manual management and communication silos


Optimize testing and approval So you can focus on fixing the gaffes, instead of finding them


Check dependencies thoroughly To make your code safer and more stable


Instantly back-out failed changes So your operation and profits have a safety net

And this means you can focus on change strategy instead of headache management, save your company a lot of money and yourself the torment of ad hoc, manual, disorganized transport management.


We’re Basis Technologies and we’ve been through hell.

Our team of indomitable SAP specialists has been through the seven circles of release

management hell and back.

And they’ve created a fire-hardened, software-only, easy-to-implement tool that helps you get the most out of your SAP development, speed up the process and minimize the risk around your dev activity.

And they’ve created a fire-hardened, software-only, easy-to-implement tool that helps you get the most out of your SAP development, speed up the process and minimize the risk around your dev activity.

It’s part of a family of development and performance optimizers that are re-enabling businesses by changing the way they run their SAP systems.

And it might just change the way you feel about yours.

Talk to usWant to know more?

www.basistechnologies.com

http://bit.ly/1Kn6qh0

http://www.basistechnologies.com/

Documents

The 7 circles of SAP project delivery hell - Basis Technologies