This document discusses how legacy thinking surrounding SAP systems is the main barrier to agility and innovation for businesses. It emphasizes that modern SAP environments can enable faster development, reduced risk, and continuous innovation by changing outdated assumptions and adopting a more agile mindset. The document advocates for leveraging the capabilities of SAP as an enabler of business success rather than viewing it as a restrictive legacy system.

1. 7fatalassumptions
aboutSAPagility
Howlegacythinkingisholdingyouback
morethanlegacysoftware

2. If you’ve grown up with the
belief that a solid, reliable SAP
environmentisanauto-renewing
subscriptiontobusinesssuccess,
then the last few years must
have been tough for you.
TheÜbers,Netflixes,andAirbnbs
ofthisworldhavebeendisrupting
almosteverymarketwith
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
nimblesolutions,thumbingtheir
nosesatbig,SAP-runbusiness.
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’renotburdened
withalegacysystem.
You’reavictimof
legacythinking.
Introduction

3. 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
alotmoreagilityandinnovation
than you might believe.
Asamatteroffact,businesses
ofallsizesaredoingsome
remarkablyquick-thinking,
innovativethingsintheirSAP
environments.Andtheycando
itbecausethey’veleftbehind
theiroutdatedassumptions
aboutthesystem.
Introduction
Inshort,
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.

4. SAPmodernizationexposes
youtounsustainablerisk.

5. The biggest obstacle to change in many
companies is the belief that, in an SAP
environment,innovationisincrediblyhard:
• 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 –
withlarge-scope,outsourced,
off-the-radar development
projectspotentiallythreatening
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
mindsetofriskaversioninmany
SAP companies.
SAP modernization exposes you to unsustainable risk

6. SAP modernization exposes you to unsustainable risk
But let’s face it:
The biggest danger for any
business is NOT to innovate.

7. 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
developmentandmake
SAP releases so
excruciatingly slow.
• Actively minimizing the
risk of faulty releases –
by putting mechanisms
in place that control code
quality(e.g.enforcingnaming
conventions, or running
dependency checks to
identify potential pitfalls
on-the-go);andbyenabling
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
entirelymanageable.
SAP modernization exposes you to unsustainable risk

8. SAPreleasesmustbedelivered
inmassivepackages.

9. 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
inlargebatches,newand
changing requirements
cancreatelargeamounts
of scrap.1
SAP releases must be delivered in massive packages
1. Source: Forrester Research. March 2013 Global Application Life-Cycle Management Online Survey

10. SAP releases must be delivered in massive packages
But really, there’s no
reason not to break up SAP
releases into smaller, more
manageable chunks.

11. Andwithamodern,continuous
dev-and-releaseapproachto
SAP,theydon’tneedtobeset
instone,either(we’lltalkmore
aboutthisshortly).
Theideaissimple:continuous
developmentandtesting
unbundlesthathugescope.
Itsplitsinnovationand
experimentationintosmaller
chunks,withdevelopment,
testing,andreleasesofparallel
projectshappeningallthetime.
And that makes
system changes
a lot more focused,
far less intimidating,
and much better-
connected to
business goals.
SAP releases must be delivered in massive packages

12. SAPprojectsburn
money,fast.

13. 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
SAPisstaff–andmanySAPprojectsdouble
insizewithanarmyofconsultantsandintegrators.
That, frankly, is insane.
SAP projects burn money, fast

14. 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.

15. Themoneysinksactuallycome
fromtheprojectmethodologies
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
andoffshoringisoftenmerely
‘failure at 70% off’”2
):
• TheydoQAlateinthe
project,asanafterthought.
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
developmentcostisrework,
refactoring, and issue
resolution. And it can add
weeks and months to the
project timeline.
Noneofthatisactuallynecessary,
if you do one simple thing:
Build in quality control
checkpoints from day one
of any development activity.
Therearerelativelysimpleways
to analyze code, assess the
impactofachange,andenforce
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
qualityoftheirdevelopment.
• 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.
SAP projects burn money, fast
2. Source: Kurt Bittner et al. March 2014 Modern Application Delivery Drives Digital Business Success. Executive Overview: The Modern Application Delivery Playbook

16. AstrategicoverviewofallSAP
developmentisimpossible.

17. Many businesses believe that SAP
developmentactivityisbynatureopaque.
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
toimplementthe‘masterplan’.)
A strategic overview of all SAP development is impossible

18. That’s not an SAP issue.
It’s a mindset problem.
A strategic overview of all SAP development is impossible

19. Modern SAP-run businesses
use change and release
management systems that
eliminate manual process
updates,andgiveallstakeholders
accesstoadashboardoverview
at all times.
Becauseeveryoneknowswhere
each project is at any point
intime,strategistscanrespond
to new requirements quickly,
correct course and re-deploy
development resources.
That’s a lot smarter
thandoggedlysticking
to an outdated
plan just because
you committed to
it many moons ago
(and can’t see how
or where to stop it).
A strategic overview of all SAP development is impossible

20. Agiledevelopmentisimpossible
inanSAPenvironment.

21. 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
toold-fashionedWaterfallmodels
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

22. 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.

23. 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.
• Allowformulti-speedprograms
thatprioritizetheurgentover
the everyday.
That lets them stay flexible
to changing requirements
and take a big step towards
continuousdevanddeployment.
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.
Agile development is impossible in an SAP environment

24. InSAP,automatedtesting
isafantasy.

25. 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,
forSAP,testautomationisjust
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

26. 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.

27. Infact,manySAPdevelopment
teams dramatically accelerate
testingbydeployingautomation
at critical points to:
• Identify instances where
codetouchesriskyobjects–
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.
• Monitorthetestingprogram–
so they can update their
test scripts mid-flight to
remain relevant.
Thesebusinesseshaveproven
thatyoucancombinethebestof
automated and manual testing
in a meaningful way, put your
resources where they’re most
needed, and speedupreleases
byspeedingup testing.
Ifyou’venotautomated
your testing yet,
you’re slowing
everything down.
In SAP, automated testing is a fantasy

28. It’salwaysbetter
tocustomize.

29. 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
becomesdifficulttocustomize.
That’s possibly the most
inefficient way of working
with a complex business
system like SAP.
It’salwaysbettertocustomize

30. The only way to overcome
that frustration is to flip the
traditional business analyst
role upside-down.
It’salwaysbettertocustomize

31. Instead of blindly taking
orders from stakeholders
(and struggling to make SAP
dothingsit’snotdesignedtodo),
the modern SAP business
analyst knows the system
inside out and explains the
artofthepossibletobusiness
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’llbeplaying
to its strengths.
It’salwaysbettertocustomize

32. Harness
thepower
ofthenew
SAPmindset.

33. Let’s face it: Your customers
don’t care what you run your
business on. They care about
yourrelevance,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.
Theparadigmofthesuccessful
business may have changed,
but that doesn’t mean that a
solid and reliable SAP system
isn’tstillanenormousadvantage–
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

34. We’reBasisandwe’rehelping
organizationsacrosstheglobe
changethewaytheythink
aboutSAP.
Harness the power of the new SAP mindset

35. Our DevOps tools make their
operations more agile, their
strategiesmoreresponsive,and
theirbusinessmorecompetitive.
And they can do the same
for you.
Sounds good?
Talk to us.
www.basistechnologies.com