7 fatal assumptions about sap agility

7 fatal assumptions about SAP agility How legacy thinking is holding you back more than legacy software

If you’ve grown up with the belief that a solid, reliable SAP environment is an auto-renewing subscription to business success, then the last few years must have been tough for you.

The Übers, Netflixes, and Airbnbs of this world have been disrupting almost every market with smart innovations and new, customer-first business models. They’re changing whole industries in a matter of months. Many of them are doing it without large, complex ERP systems. And they’re basking in the glory of their nimble solutions, thumbing their noses at big, SAP-run business.

But before you turn all cynical thinking how, with your slow-moving, rigid, uncompromising system, you’ll never be able to pivot like these companies, consider this:

You’re not burdened with a legacy system. You’re a victim of legacy thinking.

Introduction

The truth is, there’s a good reason you’re running your business on SAP. And it’s not just about the back end heavy-lifting – the system you have right now is also capable of a lot more agility and innovation than you might believe.

As a matter of fact, businesses of all sizes are doing some remarkably quick-thinking, innovative things in their SAP environments. And they can do it because they’ve left behind their outdated assumptions about the system.

Introduction

In short, old-school thinking about SAP, based on the way it’s always been run, is probably the single biggest obstacle to innovation, holding big businesses back every day. And it’s the first thing you need to change if you want to keep the challengers from eating your lunch.

So let’s look at some of those assumptions that might be keeping you from aiming high, revving up, and leading business the way you should.

SAP modernization exposes you to unsustainable risk.

The biggest obstacle to change in many companies is the belief that, in an SAP environment, innovation is incredibly hard:

• Because it’s linear and slow – with a long-winded development process that disconnects the reasons for renewal from its execution (“Wait... why are we doing this again?”).

• Because every release could mean failure – with large-scope, outsourced, off-the-radar development projects potentially threatening your production system with downtime, loss of revenue, and reputation damage (and nobody wants to be responsible for that).

This has led to an unnecessary mindset of risk aversion in many SAP companies.

SAP modernization exposes you to unsustainable risk


But let’s face it:

The biggest danger for any business is NOT to innovate.

And, the truth is, the risk of innovation is entirely manageable in a modern SAP environment.

Progressive companies have demonstrated that there’s an elegant way of changing your business, by doing two crucial things:

• Speeding up the time-to-market for SAP development – by automating the workflow and approvals that traditionally stall development and make SAP releases so excruciatingly slow.

• Actively minimizing the risk of faulty releases – by putting mechanisms in place that control code quality (e.g. enforcing naming conventions, or running dependency checks to identify potential pitfalls on-the-go); and by enabling roll-back to earlier releases if problems arise.

These simple steps mean safer code, less technical debt, a massively reduced risk of downtime, and faster request-to-release times for any strategic change.

Which makes innovation a lot less risky and entirely manageable.


SAP releases must be delivered in massive packages.

In most companies, SAP releases have always been huge in scope, with all sorts of features and changes bundled into one big release that impacts all business functions at the same time. It’s made releases incredibly daunting – and given people the idea that innovations:

• Are few and far between

• Need to be planned out meticulously

• Can’t be changed, once started.

Huge scopes create a lot of waste 70% of development professionals said that, when work moves through the system in large batches, new and changing requirements can create large amounts of scrap.1

SAP releases must be delivered in massive packages

1. Source: Forrester Research. March 2013 Global Application Life-Cycle Management Online Survey


But really, there’s no reason not to break up SAP releases into smaller, more

manageable chunks.

And with a modern, continuous dev-and-release approach to SAP, they don’t need to be set in stone, either (we’ll talk more about this shortly).

The idea is simple: continuous development and testing unbundles that huge scope. It splits innovation and experimentation into smaller chunks, with development, testing, and releases of parallel projects happening all the time.

And that makes system changes a lot more focused, far less intimidating, and much better-connected to business goals.


SAP projects burn money, fast.

Most companies assume that the only way to handle an SAP system change is to throw a lot of resources at it. Gartner researchers reckon that 66% of the total cost of running SAP is staff – and many SAP projects double in size with an army of consultants and integrators.

That, frankly, is insane.

SAP projects burn money, fast


Because, if you take a different approach,

system changes don’t eat up anywhere near the resources you’re

used to deploying.

The money sinks actually come from the project methodologies that have developed in the industry. Because companies assume they save money by using offshore labor, they see no need to revisit their development practices. And that makes them waste resources at a large scale. (Or, as a recent Forrester report puts it, “outsourcing and offshoring is often merely ‘failure at 70% off’”2):

• They do QA late in the project, as an afterthought. With dev activity frequently outsourced and spread across different time zones, few companies bother to establish and enforce coding standards from the beginning.

• As a result, they have to invest serious money into time – and people-intensive rework. Up to 40% of any SAP development cost is rework, refactoring, and issue resolution. And it can add weeks and months to the project timeline.

None of that is actually necessary, if you do one simple thing: Build in quality control checkpoints from day one of any development activity.

There are relatively simple ways to analyze code, assess the impact of a change, and enforce coding standards as part of the ongoing development process. And that ultimately:

• Shaves considerable chunks of time and money off any SAP investment.

• Makes it a lot easier for businesses to trust the quality of their development.

• Lets the C-suite finally adopt the test-and-learn mindset that’s necessary for innovation.

And that’s a lot of bang for a little QA.


2. Source: Kurt Bittner et al. March 2014 Modern Application Delivery Drives Digital Business Success. Executive Overview: The Modern Application Delivery Playbook

A strategic overview of all SAP development is impossible.

Many businesses believe that SAP development activity is by nature opaque. That’s because they’ve never had any systems in place that make projects trackable. Instead, they’re still using spreadsheets, or lots of different, disconnected tools.

The result: there’s no bird’s-eye-view showing the status of all dev activity. And that makes it incredibly hard to re-prioritize individual activities in the program – even when new requirements come up.

(Old-school SAP people still regard a mid-flight change of scope as a defeat – a failure to implement the ‘master plan’.)

A strategic overview of all SAP development is impossible

That’s not an SAP issue. It’s a mindset problem.


Modern SAP-run businesses use change and release management systems that eliminate manual process updates, and give all stakeholders access to a dashboard overview at all times.

Because everyone knows where each project is at any point in time, strategists can respond to new requirements quickly, correct course and re-deploy development resources.

That’s a lot smarter than doggedly sticking to an outdated plan just because you committed to it many moons ago (and can’t see how or where to stop it).


Agile development is impossible in an SAP environment.

All-or-nothing is the hallmark of old-school SAP thinking.

When it comes to agile development, this mindset leads to a binary choice: you can do it 100% or not at all.

With functional silos deeply engrained, and so much outsourced development, most SAP environments stick to old-fashioned Waterfall models that lock requirements down early and leave little space for adjustment. “There’s no way to do agile in SAP”.

Agile development is impossible in an SAP environment


In fact, it’s not ‘all or nothing’: Many modern SAP businesses

are proving you can be a lot more agile without having

to jettison all practices in favor of full-on sprints and scrums.

They’re adopting an agile dev mindset, using collaboration systems that:

• Connect the business requests with the IT agenda.

• Facilitate communication and approvals.

• Speed up IT Ops to speed up Dev.

• Coordinate development across parallel systems.

• Allow for multi-speed programs that prioritize the urgent over the everyday.

That lets them stay flexible to changing requirements and take a big step towards continuous dev and deployment.

Which means IT can deliver to the needs of the business more often and at much shorter notice, making companies more nimble, light-footed – and more dangerous to their competitors. That’s what agile is all about.


In SAP, automated testing is a fantasy.

In the non-SAP world, automated testing takes a lot of the pain and suffering out of development. Applications that run hundreds of automated test scripts in a few minutes immensely cut the cost and time needed for manual testing.

But there’s a widespread (and erroneous) belief that, for SAP, test automation is just not realistic. Fully automated testing is really hard to do, and costs a lot of money – so most SAP shops stick with long-winded, manual testing setups.

In SAP, automated testing is a fantasy


Again, that’s based on a faulty ‘all-or-nothing’ assumption: that there

are no nuances between 100% automated and 100% manual testing.

In fact, many SAP development teams dramatically accelerate testing by deploying automation at critical points to:

• Identify instances where code touches risky objects – so they know where to focus their test efforts.

• Guide them to the spots in the code that need particular attention – instead of allocating all resources equally.

• Monitor the testing program – so they can update their test scripts mid-flight to remain relevant.

These businesses have proven that you can combine the best of automated and manual testing in a meaningful way, put your resources where they’re most needed, and speed up releases by speeding up testing.

If you’ve not automated your testing yet, you’re slowing everything down.


It’s always better to customize.

Many SAP businesses have a habit of customizing the system rather than mapping their requirements to what the system does best. They try to cater to every eccentric request:

• Writing their own versions of business processing programs even though standard SAP is very close to the requirements.

• Creating Z programs to deal with a peculiarity in the way they’ve always run their business.

And they get incredibly frustrated when the system becomes difficult to customize.

That’s possibly the most inefficient way of working with a complex business system like SAP.

It’s always better to customize

The only way to overcome that frustration is to flip the traditional business analyst

role upside-down.


Instead of blindly taking orders from stakeholders (and struggling to make SAP do things it’s not designed to do), the modern SAP business analyst knows the system inside out and explains the art of the possible to business people (so they want the right things).

This cultural change may be the best investment you’ll ever make in your SAP system:

• When it makes sense, you’ll revise your organization’s standard practices to fit your SAP environment – instead of the other way around.

• You’ll spend less time and resources customizing, meaning things happen more quickly.

• Your upgrades will go more smoothly.

• You’ll get ready for the future: with S4HANA on the horizon, the less complex custom code you’ve got, the quicker you’ll be up and running.

And because the business will have a much better understanding of the possibilities in SAP, you’ll be playing to its strengths.


Harness the power of the new SAP mindset.

Let’s face it: Your customers don’t care what you run your business on. They care about your relevance, responsiveness and service.

Your SAP system can be an incredibly powerful force for your business. But if it feels like a dull blade to you, then maybe you’ve been using it wrong.

The paradigm of the successful business may have changed, but that doesn’t mean that a solid and reliable SAP system isn’t still an enormous advantage – if you’re open to running it in new, more sophisticated ways.

So start thinking of your SAP system as an enabler, not an obstacle. Revisit your old assumptions about the system, and start innovating from a position of strength.

Harness the power of the new SAP mindset

We’re Basis and we’re helping organizations across the globe

change the way they think about SAP.

Harness the power of the new SAP mindset

Our DevOps tools make their operations more agile, their strategies more responsive, and their business more competitive.

And they can do the same for you.

Sounds good?

Talk to us.

www.basistechnologies.com

http://go.basistechnologies.com/fatal-SAP-agility-assumptions

http://www.basistechnologies.com/

7 fatal assumptions about sap agility

Documents