Mitigating Risk in Large SAP Projects By Lawrence Compagna First edition copyright 2014 ISBN: 978-1-312-51988-6 Published by Lulu.com
Mitigating Risk in
Large SAP Projects By Lawrence Compagna
First edition copyright 2014
ISBN: 978-1-312-51988-6
Published by Lulu.com
Mitigating Risk in Large SAP Projects
2
SAP® and SAP® R/3® are registered trademarks
of SAP AG in Germany and in several other
countries. Services related to SAP® software on
this website is offering of iii Technologies and
should not be confused with that of SAP America
or SAP AG.
Trademarks
All products and services mentioned on this
website are trademarks of their respective owners.
SAP, mySAP, mySAP.com, SAP NetWeaver and
other SAP products and services mentioned herein
as well as their respective logos are trademarks or
registered trademarks of SAP AG in Germany and
in several other countries all over the world. All
other product and service names mentioned are the
trademarks of their respective companies.
Mitigating Risk in Large SAP Projects
3
Mitigating Risk in Large SAP Projects
4
Table of Contents
Preface............................................................................... 10
Introduction ....................................................................... 14
The Success of SAP ERP Software............................... 14
A Few Words on the SAP Enterprise Central Component
....................................................................................... 15
The Failure of Major IT Projects In General................. 16
The Failure of Major ERP Projects ............................... 17
What This Book is About .............................................. 19
Why SAP? ..................................................................... 21
Greenfield SAP Implementation versus the
Modification of SAP .................................................. 23
Type of SAP Projects .................................................... 27
Implementations ........................................................ 27
Re-implementations ................................................... 27
Partial Implementation .............................................. 27
Support Pack Application .......................................... 28
Module Activation ..................................................... 28
Upgrade ..................................................................... 28
Two Project Nightmares (hypothetical) ............................ 32
From the Perspective of Company XYZ's Project
Manager ......................................................................... 32
From the perspective of the Implementation Partner of
XYZ ............................................................................... 45
Mitigating Risk in Large SAP Projects
5
It's Happened ................................................................. 51
SAP is a Great Software Product! The Implementations
Are Not Always So Great …......................................... 52
The Risks Inherent in Large SAP Projects ....................... 54
General Project Management ........................................ 56
Time ........................................................................... 56
Money ........................................................................ 60
Scope ............................................................................. 61
Development versus configuration in SAP ............... 63
Development Risk ..................................................... 65
Established SAP Modules Compared to Newer Ones 75
Strategy: The Big Bang Approach and the Phased
Approach ................................................................... 76
The Inherent Risk of Long Time Lines ..................... 78
Timing of the Change-over........................................ 79
Conversion Strategy .................................................. 79
Interfaces ................................................................... 82
SAP modules ............................................................. 83
Size of Team .............................................................. 85
International Complexity ........................................... 85
Degree of Fit .............................................................. 87
Things That Should Never Be in Scope .................... 88
Scope – the Final Word ............................................. 89
The Five Basic Phases of an SAP Project and the Risk
Inherent in Each ................................................................ 92
Mitigating Risk in Large SAP Projects
6
A Word on Project Methodologies Used on SAP Projects
....................................................................................... 92
The ASAP Methodology ............................................... 92
The Risk Inherent In Each SAP Project Phase .............. 93
Risk Inherent in the Project Preparation Phase ......... 94
Risk Inherent in the Business Blueprint Phase .......... 96
Risk Inherent in the Realization Phase .................... 102
Risk Inherent in the Final Preparation Phase ........... 108
Risk Inherent in the Go-live and Support Phase...... 111
Final Word on the Relative Risk of Each Phase ...... 112
Risk Management for SAP Projects ............................... 116
The Risk Management Plan ........................................ 116
Change Management ................................................... 117
The Guardian Angel ................................................ 117
Communication ....................................................... 118
Participation ............................................................. 119
Training ................................................................... 121
Project Policies ............................................................ 124
Project Personnel ......................................................... 126
Acumen of key project resources ............................ 126
Hire or Contract Out? .............................................. 128
Develop Your Own SAP Experts ............................ 129
Redundant Personnel ............................................... 131
Loss of key personnel .............................................. 132
Mitigating Risk in Large SAP Projects
7
Project Location ....................................................... 132
Daily Work Schedule ............................................... 134
Roll-on, Roll-off ...................................................... 135
Contracts...................................................................... 145
Types of Contracts ................................................... 145
Litigation Proofing .................................................. 148
Internal Controls .......................................................... 153
Internal Control Structure ........................................ 153
Core Modifications .................................................. 154
Control over mini-modifications ............................. 156
Bad Design and Configuration ................................ 157
Integrity of the SAP Landscape ............................... 159
Quality Assurance Client ......................................... 163
Development ............................................................... 165
Testing ..................................................................... 166
Stress Testing, Volume Testing, and Other "Basis"
Oriented Tests .......................................................... 178
Documentation......................................................... 179
The Project Plan....................................................... 180
Security .................................................................... 181
Handling the Unexpected ............................................ 184
A Hypothetical Case Study: The "Perfect" SAP Enterprise
Central Component Project ............................................. 186
The Request for Proposal ............................................ 187
Mitigating Risk in Large SAP Projects
8
Some Assumptions .................................................. 187
Development of the Request for Proposal ............... 187
The RFP Response................................................... 191
The Winner Is …. ........................................................ 193
Congratulations! You've won. Now what? ............... 195
Blueprinting ............................................................. 197
Realization ............................................................... 199
The Go-Live Preparation Phase ............................... 202
Integration Testing ................................................... 203
The User Acceptance Test ....................................... 204
Go-live Preparation .................................................. 207
Go-live ..................................................................... 208
Post Go-Live Support .............................................. 209
Long-term Support .................................................. 210
Summary ..................................................................... 211
Conclusion: ..................................................................... 214
The Ramifications of NOT Following SAP Implementation
Best Practices .................................................................. 214
Glossary of Terms ........................................................... 217
Appendices ...................................................................... 252
Appendix 1 - SDLC and the ASAP Project Management
Methodology ............................................................... 252
The ASAP Project Management Methodology ........... 253
ASAP Methodology - Phase 1: Project Preparation 254
Mitigating Risk in Large SAP Projects
9
ASAP Methodology - Phase 2- Business Blueprint 256
ASAP Methodology - Phase- 3 - Realization: ......... 258
ASAP Methodology - Phase 4 - Final Preparation: . 260
ASAP Methodology - Phase 5 - Go-live and Support:
................................................................................. 261
About the Author ............................................................ 263
Mitigating Risk in Large SAP Projects
10
Preface
This book assumes that the reader has a rudimentary
understanding of what an ERP system is, and more
specifically what SAP is.
The SAP Enterprise Central Component is a German
software package used extensively by the world's largest
organizations for accounting, financial control, production
control, human resources, material management planning,
and many other facets of business' operation. For those
readers who do not know SAP stands for "Systems,
Applications and Processes in data processing". ECC
stands for "Enterprise Central Component". The
predecessor of the Enterprise Central Component was R/3,
and before that it was R/2. The origins of the SAP ERP
system date back to 1972 when it was founded as a
mainframe software system. In 1992 they developed their
client server based ERP program and their growth has
exploded since then.
In the course of examining the risks associated with SAP
and how to mitigate them, the term SAP will be used to
denote the central component only (SAP Enterprise Central
Component). Other SAP products like BI are excluded
from the conversation except where specifically mentioned.
The hallmark of SAP is the tight integration of its core
business suite. This core product is based on industry best
practices. Consequently SAP is the world's leading ERP
software manufacturer.
Mitigating Risk in Large SAP Projects
11
While this book focuses on SAP, much of what is written is
applicable to other large ERP implementations, and to a
lesser extent large IT projects in general.
The cases discussed throughout this book, even those
deemed "hypothetical", are a blend of real world examples
that I have experienced firsthand, but none are treated
exclusively at any point.
When I use the term partner, implementation partner,
consultant, consulting firm, advisor, integrator, or systems
integrator all of these terms should be considered
synonymous. All of these terms refer to a third party firm
hired to assist an organization which has a license for SAP
in making changes to it or using it.
Lastly, when I use the term "the business", I am referring to
any organization (both private and public sector) that is
having SAP implemented, modified, or upgraded within it.
This term will never be used to denote the implementation
partner that is advising and assisting "the business" with
their implementation. The implementation partner will be
referred to with that term, or as a similar term such partner,
advisor, or integrator. Furthermore the term
"implementation" will be used to denote any major SAP
project (with a budget of over $1 million to quote an
arbitrary figure), that could in fact be a re-implementation,
enhancement project, module deployment, the end-to-end
deployment of an entire new business process, or an
upgrade.
In all discussions, changes to the SAP ECC (SAP
Enterprise Central Component) will be central to the
Mitigating Risk in Large SAP Projects
12
solution being implemented as such changes are likely to
encompass the greatest risks (and also the greatest rewards)
to an organization.
Mitigating Risk in Large SAP Projects
13
Introduction
Mitigating Risk in Large SAP Projects
14
Introduction
The Success of SAP ERP Software The success of the world's third largest software retailer,
SAP AG, cannot be denied. As of 2012 there were 44,000
installations worldwide of its flagship software SAP
Enterprise Central Component, in some of the biggest
organizations: 3M, Kraft Foods, and Colgate Palmolive, are
but a few of the members of the Fortune 500 that run this
brand of ERP. On the public sector side the Government of
Canada, the US Army, and the State of California are a few
examples of massive entities that run the SAP successfully.
Thumbing through the 1,887 success stories on SAP's
website you will encounter names such as Citrix, Proctor
and Gamble, and the University of Kentucky. Time and
time again the stories document gains in productivity,
customer service, and a positive return on investment.
SAP is the most common type of ERP system that you will
find in the marketplace, as indicated in this graph:
Mitigating Risk in Large SAP Projects
15
In 2000 SAP had a market share of 11%; by 2012 it had
climbed to 25%. SAP has a market share in the ERP
market that is equal to that of its three biggest competitors.
There is no denying SAP's success. The benefits of
implementing it are well documented.
A Few Words on the SAP Enterprise
Central Component The SAP Enterprise Central Component, often abbreviated
to SAP ECC is the cornerstone of SAP`s software
offerings. While SAP now offers many other products that
can be bolted on to the Enterprise Central Component, this
component is the core.
It is also the software element that has helped SAP become
the third largest software retailer in the world, and the
Mitigating Risk in Large SAP Projects
16
undisputed champion of the enterprise resource planning
(ERP) marketplace.
The Enterprise Central Component is a collection of
modules that are all contained on the initial compact disks
that are loaded on to a client`s servers. Though they are
referred to as separate and distinct modules the client in
fact has them all loaded and they all exist in the SAP
system whether they are active or not.
Initially when the Enterprise Central Component software
is loaded on to the customer`s server it does not work.
None of the modules can in fact be used "out of the box",
despite SAP often being referred to as an "out of the box"
solution. Any module desired for use has to first be
activated and then configured. Only after it is activated
(and configured) in the Implementation Guide can a user
perform business functions.
The beauty of the SAP Enterprise Central Component lies
in its real-time integration. The majority of modules pass
information from one to another in real time without having
to run any batch jobs (there are a few exceptions, for
example the Contract Accounting module – FICA, requires
a batch job to be run to move its summarized values to the
General Ledger).
The Failure of Major IT Projects In
General Like any major IT project, implementing SAP amounts to a
major change to an organization, especially if they've never
had it before. There are many perils along the way, and
Mitigating Risk in Large SAP Projects
17
sometimes those SAP projects that were not diligent, did
not employ knowledgeable people, and did not follow best
SAP implementation practices falter. SAP is not alone:
according to Mark Jeffery and Ingmar Lelveld writing in
the spring 2004 issue of the MIT Sloan Management
Review, 68% of IT projects fail on either budget, their
timeline, or they fail to "deliver the originally stated
business goals".
The Failure of Major ERP Projects Because of SAP's huge market share in the ERP space there
is also a proportional amount of failures. According to an
article published by CIO Magazine entitled "10 Famous
ERP Disasters, Dustups and Disappointments" half of the
examples involved SAP. On that list, the number one,
three, and five spots involved SAP implementations that
went awry.
According to that article order fulfillment problems with
Hershey Chocolate's SAP centered project caused the
Mitigating Risk in Large SAP Projects
18
"stock price to dip 8%". The Waste Management SAP
project resulted in an "acrimonious $100 million legal
battle".
In the case of their failed SAP project, Select Comfort's
actions were "indicative of extremely poor judgment by
management".
Many organizations improve their operations with SAP, but
in some instances, as seen in the examples above, the
implementation can turn into a disaster. In virtually all of
these cases the failure lies with the organization making the
switch to SAP or their implementation partner. In the
words of Warren Buffett, "failure results from not knowing
what you are doing". This especially holds true in the case
of major SAP project failures.
Mitigating Risk in Large SAP Projects
19
What This Book is About There are many types of risk that can be discussed when
having a conversation about an organization. There are
legal risks, there is the risk of theft, and the risk carefully
looked at by internal auditors.
This book is not about any of those types of risks.
Specifically this book is not about SAP's GRC module that
helps internal auditors work with a live SAP system, nor is
it about how to implement that module.
This book is about how to avert disasters involving major
SAP projects, so that your organization can fully reap the
benefits that you can justly expect. Specifically this book
is about how to implement SAP Enterprise Central
Component with the lowest possible risk to both the
organization that is converting their operations and the
consulting partner organizations that help them convert.
This book cannot promise that risk can be totally averted,
but it will outline the sources of risk, how to mitigate it,
provide cases of SAP projects that went awry (based on
examples both real and hypothetical), and finally present an
example of an implementation that minimized its risk.
What are the risks? In broad terms the risks that this book
seeks to manage are financial loss to any of the parties
involved in an SAP implementation, the risk of missing
deadlines, and avoidance of massive technical failures once
Mitigating Risk in Large SAP Projects
20
the project has gone "live". Another risk that is not so
tangible is the loss of reputation.
This book is about the specific risks involved with the
execution of a large SAP project. By large we mean a new
implementation of a complete SAP system, a
reimplementation of a complete SAP system, or the
implementation of at least one new module in a live SAP
system where a team of at least half a dozen people are
required to deploy it. To a lesser extent the principles set
forth in this book can be applied to upgrades and support
pack applications, but endeavors such as these tend to carry
much less risk than the former endeavors.
Though many of the idea in this book can be applied to
other ERP systems, they are all applicable specific to the
most prevalent of all ERP system – SAP.
Mitigating Risk in Large SAP Projects
21
Why SAP?
Implementing SAP can provide a significant return on
investment for the organization, make your operations more
efficient, and more effectively move the organization
towards its goals. However, implementing the system
carries significant risks, many of which are specific only to
the world of SAP. The purpose of this book is to help the
reader avoid the pitfalls that have plagues other
implementations and caused significant failures in the past.
Employing the risk management strategies contained in this
book will help mitigate those risks.
The hallmark of SAP is its integration. You enter
information once into the system, and that information is
carried through to all other modules, usually in real-time.
It is however, not heavily automated. As one SAP
consultant once said "SAP is integrated, not automated. It
Mitigating Risk in Large SAP Projects
22
requires staff to think about what is going on. Not to watch
the system do their job".
There are numerous modules within SAP, and within those
areas there a multitude of sub-modules. The graphic
below is a sampling of modules within Enterprise Central
Component:
When I use the term "the business", I mean the non-
technical folks of an organization that is the subject of the
SAP project. For example: If SAP is being implemented
in company XYZ, then the office of the comptroller is one
Mitigating Risk in Large SAP Projects
23
element of "the business". Another element of the
business could be the Central Stores warehouse
administrative staff of company XYZ. The IT department
for company XYZ is not part of the "business".
Often times an outside consulting or implementation firm is
utilized to help transform a company like XYZ by
leveraging SAP more efficiently and more effectively than
they could themselves. In this case the consulting firm of
"ABC" is assisting. To further define what we mean by
"the business", no one from the consulting firm of ABC is
part of the business.
And one last thing about "the business": it does not matter
whether the organization that is the subject of the project is
for profit or non-profit. The above definition holds for
both.
Now that we have that understanding we can begin to
discuss risk mitigation in an SAP project.
Greenfield SAP Implementation versus the
Modification of SAP In some ways a "green field" implementation, one in which
a new implementation of SAP is being installed, can be
easier than an upgrade, the addition of new modules to the
scope of an existing implementation, or embedding a new
process into an existing SAP system.
This is because you can control the way a green field
implementation is done. If you are working on an existing
install of SAP you inherit what could be an implementation
that was not done according to best practice.
Mitigating Risk in Large SAP Projects
24
Consider the case of a client that I worked on many years
ago. The objective of the project was to look at the
organizational hierarchies that were in place in the SAP
system of this huge computer manufacturer.
Along the way I learned that so many core modifications
were done to the code of this system that it could not be
upgraded. They had implemented SAP many years before,
and were already running on an antiquated version of the
project. At the time that I did the project they only had a
few years of SAP support left for their current version. It
was about to expire and the organization could do nothing
about it.
From the Gartner Group: "CIOs Must Take Action to Address Fast-Approaching Reality
of “Legacy ERP”
The likely scenario long-term would have involved a
complete reimplementation of SAP, but this never came to
pass because the company was purchased by another
company and the firm was absorbed into that other
company. I do not know the fate of the SAP system. I
have since encountered several more organizations whose
systems were not upgradeable because they were heavily
customized with many core code modifications.
Mitigating Risk in Large SAP Projects
25
The above illustrates a unique risk area when your project
involves an already existing installation of SAP: the extent
of core modifications to SAP's code in that system. At the
earliest possible point in such an endeavor a core-
modification assessment of the system should be
conducted. The BASIS team will be able to assist with
this task. You should also review the functional
specification documentation (assuming you have them) as
this will describe the enhancements done to the system. It
will also be necessary to review the technical specification
documents to determine exactly how the change was coded.
Did the ABAP resource make a copy and prefix the
program with a Z, or did they simply change the standard
SAP code. The latter is a worst case scenario and widely
regarded by seasoned SAP professionals as a violation of
SAP implementation best practices.
Aside from the unique risks posed by a project that
involves an already existing SAP installation, all of the
other items discussed in this book in the context of a green
field implementation still apply. This means that you
should not implement any core modifications, avoid Z
tables and Z programs, and even user exits. You should
keep the number of interfaces to a minimum, and try to
implement SAP only for processes where the fit is
reasonable.
Mitigating Risk in Large SAP Projects
26
“You can never protect
yourself 100%. What you
do is protect yourself as
much as possible and
mitigate risk to an
acceptable degree. You
can never remove all
risk.”
Kevin Mitnick
Mitigating Risk in Large SAP Projects
27
Type of SAP Projects There are several different types of SAP projects that can
be large in scale. By large scale I mean involving multiple
people and multiple SAP modules, and lasting several
months. Here is a look at some of the variations:
Implementations An implementation refers to the complete installation and
configuration of SAP. There is usually a legacy system
whose values must be converted to those in the new SAP
system. Initial implementations are sometimes called
"Greenfield" implementations to denote that they are
completely new.
Re-implementations Sometimes an SAP system has been badly implemented
and a decision is made to treat it as a legacy system and re-
implement SAP. In this kind of project, the old SAP
system is the legacy system. A re-implementation does
not differ much from a "Greenfield" implementation.
Partial Implementation Often an organization will already have SAP installed, but
decide after go-live (or as part of phased approach to
implementation) to implement some additional
functionality using modules not initially in scope. For
example, they may decide to implement capital budgeting
(the Investment Management module), and capital project
management (the Project Systems module). These two
modules will tie in with the Asset Accounting module that
the organization already has deployed.
Mitigating Risk in Large SAP Projects
28
Such a project is a partial implementation as it will involve
a small team of people, cross multiple modules, and take
several months to deploy.
Support Pack Application From time to time SAP releases support packs that apply
many OSS Notes to an existing system. These notes are
essentially bug fixes. A support pack release will usually
take a few months and involve a team to apply and test to
ensure that the SAP system still functions as desired.
Module Activation One of the smaller projects in our discussion is the
activation of a module in an SAP system that is already
live. For example, a live SAP customer may have their
fixed assets in an external system. A decision could be
made post go-live to transfer the fixed assets to the fixed
asset system of SAP known as Asset Accounting (AA).
Consequently a small SAP project could be kicked off to
implement the new SAP module.
Upgrade The final type of major SAP project that we will examine is
the upgrade.
An upgrade involves moving the present SAP version to a
version above it. It could be an upgrade one level higher,
or several levels higher (i.e. they do not have to be
sequential).
Some of the general activities related to an upgrade are:
Mitigating Risk in Large SAP Projects
29
There are three types of upgrades: technical,
techno/functional, and functional.
In a technical upgrade no attempt is made to add any of the
new functionality available from the higher version. All
that is done is to move the system to the higher version, and
ensure that nothing in the as-is business processes have
changed. Consequently this type of project mostly
involves the work of the Basis team, and a testing team.
There may be a few things that are broken by the upgrade
that require the re-configuration of business processes, or
that require ABAP developers to repair, but usually this
aspect of the upgrade project is minor.
On the other hand a techno/functional upgrade involves the
activities mentioned in the preceding paragraph, plus the
deployment of select new functionality available from the
new version. The selection of new functionality normally
takes place after the functional team has reviewed the
Release Notes for the version that are published by SAP.
The Release Notes list almost every new change that the
new version has over the earlier version. These notes are a
Mitigating Risk in Large SAP Projects
30
delta between the next earliest version and the new one, so
if the upgrade involves a move from several version earlier,
the Release Notes of each successive version must be
examined to get a complete understanding of the delta
between your as-is version and the version you intend to
upgrade to. Note that I say the Release Notes list most
(but not all) of the changes, this is because you may find
that there are some changes that are not listed. Usually
you will find additional documentation in the OSS system
(see glossary for an explanation).
The final type of upgrade is simply a functional one. The
technical one has happened in an earlier project, and now a
functional one is undertaken. The mechanics of a
functional upgrade are no different than that described
above.
The best practice is to perform a technical upgrade first,
and after that project is complete, have a separate project to
implement the desired functional improvements available
from the upgrade. This affords the lowest risk to the
organization.
***
Because the simplest and easiest type of project to
understand is that of a "Greenfield" implementation, the
majority of this book will center on that type of activity.
However, most of this book is applicable to every type of
project described above. In fact, much of what is written is
applicable to project involving other types of ERP systems,
though there are some aspects that are applicable only to
the unique world of SAP.
Mitigating Risk in Large SAP Projects
31
Two Project
Nightmares
Implementing SAP ECC
“A man may fall many times,
but he won't be a failure until
he says that someone pushed
him” ~ Elmer Letterman
Mitigating Risk in Large SAP Projects
32
Two Project Nightmares
(hypothetical)
Before moving into specific risk mitigation strategies it is
helpful to consider two nightmare scenarios, one from the
perspective of an internal project manager of company
XYZ, and the other from the perspective of a manager from
the company's implementation partner.
From the Perspective of Company
XYZ's Project Manager You know that the new SAP system could have made your
organization so much more efficient and effective because
it is so tightly integrated, and it supports business processes
based on best practices. You also know that you and your
team have not done a good job with the project.
As you sit in front of the CIO, the COO, and the CEO and
they jointly tell you that they are rolling back from the new
SAP system to the prior legacy systems your mind begins
to race and you think of all the things you would do
differently if you had another chance:
Back when you were on the committee to formulate an RFP
for this initiative the focus was to get a low cost provider
who had a track record of success with this type of project.
The aim was to get as much possible out of the vendor and
squeeze out the most value.
The CIO was the official project sponsor, but she did not
seem to be gung-ho about the idea. Luke warm was how
Mitigating Risk in Large SAP Projects
33
you would have described her back then. She grudgingly
acceded to the recommendations of her subordinates, but
never really "bought in". You know now that this was a
red flag. A change like this requires a powerful and
dedicated friend. The dedication was a little lacking in
this case.
So the RFP went forward. The scope of the project would
involve the "big bang" approach. "Let's do it all!" The
more we do in SAP the better the value proposition ….
That was the thinking. So the scope included the core
Enterprise Central Component modules of SAP: Materials
Management, Payroll, Accounts Payable, and Contract
Accounting. Because you already had an Oracle general
ledger, the SAP general ledger was left out of scope.
Attached to the SAP contract accounting module would be
SAP CRM. Overall reporting would be via SAP Business
Intelligence with a Business Objects overlay.
Also in scope: a non-SAP sales and use tax package, a
point of sales package, SAP Portal, a materials package,
and several other non-SAP packages.
The RFP identified several interfaces that the SAP project
had to build, and specifically stated that the team must
build functionality into SAP to support your business
processes if that functionality did not exist in standard SAP.
Looking back at the RFP, you realize what a huge mistake
that was.
So you released the RFP and several vendors responded
with proposals. Company XYZ was selected, out of seven
that firms that had been invited to respond. Another red
Mitigating Risk in Large SAP Projects
34
flag was that three out of seven firms decided to not make a
bid on this project. When queried about this two of them
confided that they thought that the scope was far too large
for them to undertake.
You and the other members of your committee scoffed at
that. Someone on the committee even called them
cowards!
You pressed ahead with contract negotiations. Squeezing
the vendor for maximum value became the strategy
employed on your side. Despite the vise you put the
prospective implementation partner in you remained
amicable, and even had lunches and dinners with their
team. (the implementation partner paid of course)
In keeping with this strategy, the contract devised by your
legal department was of the form "time and materials, not
to exceed" a fixed amount. This meant that the vendor had
to meet very specific targets, milestones, and deliverables
while providing specific time and resource rates. At the
end of the day, the overall amount they could charge was
capped, no matter how much effort they had expended on
the deliverables.
This transferred a lot of risk on to the implementation
partner, which from your perspective was fantastic.
Unfortunately the vendor pulled out of the contract
negotiations citing unacceptable risks and you had to
engage the backup vendor in new contract negotiations.
This new vendor, slightly less experienced with SAP, and
largely based overseas, eagerly entered the contract
Mitigating Risk in Large SAP Projects
35
negotiations. They accepted the fixed price not to exceed
contract, along with all of the milestones and deliverables.
The contract was signed.
The project kicked off a few months later. Because the
scope was so big, the timeline called for a total duration of
24 months. Everyone felt confident that with such a long
timeline, success was assured. There was a big kick off
party and everyone celebrated.
Phase one, project planning, would be six months long.
Plan it right was the mantra. Make the perfect plan, a great
charter, clearly spell out the scope and policies … then
execute. As you carried out the project preparation phase
you and a few other key players from your organization had
lunch with the implementation partner, with the partner
footing the bill of course!
As defined in your contract, one of the key strategies
employed was to have the implementation partner do as
much as possible. Consequently there were only a handful
of people from your organization on the project. The
implementation partner was responsible for configuration,
development and testing. They would also provide one
month of support following go-live.
There would be little time spent looking at the as-is,
because that's a "waste of time". "We do not want to
replicate what was done in the past"! Consequently the
project plan called for a relatively short period of
blueprinting, and a realization phase comparable in
duration to that of similar SAP projects.
Mitigating Risk in Large SAP Projects
36
The implementation partner began to ramp up. They
brought a multitude of resources to the project site, and one
thing you noticed was that many of them were ABAP
developers. Furthermore there were only a few citizens of
your country on the team. You also learned that many
more resources would be located off shore.
Six months has gone by and you are now into the short
blueprint phase. Blueprints are produced and according to
the schedule it's time to sign off. However, the business
process owners express concern that the blueprints do not
accurate reflect the requirements of their areas. That's
because little time was spent looking at the as-is.
Furthermore it has become apparent that the
implementation partner is lacking in the skills necessary to
make this project work.
The project sponsor (CIO) who was never a huge supporter
of this initiative joins the steering committee for a
discussion about the integrator. It is clear that this
integrator cannot help this project succeed. A decision is
made to remove the implementation partner and bring in
one of the other candidate firms from the original RFP.
The not-to-exceeds of the contract are slightly higher, and
the new partner accepts the terms. The old partner is given
one week to get out.
The new partner comes in. They have slightly fewer
ABAP'ers and more configuration personnel. Many of the
ABAP resources are located offshore. In an effort to keep
the timeline on track, the project will move into realization.
The new partner must accept the blueprints as they are.
Mitigating Risk in Large SAP Projects
37
You move into realization. You overhear more than once
the words "package slam" muttered under the breath of
some of the expert SAP consultants on the team.
The manager of the implementation partner is very
technical, as shown by their keen interest in hardware and
code coupled with what seems like a lack of knowledge of
general business. You are confident that the hardware has
been scaled properly, but wonder how much understanding
they have of practical business?
As realization moves forward many gaps are uncovered.
The prime strategy for these gaps is to write code to
overcome these gaps. You are assured that this is the way
to go. SAP is not meant to do everything, the manager of
the partner tells you. That's where ABAP code comes in.
You have never been involved with SAP before so you
have to rely on their expertise that this is the correct way to
do things.
The gaps are overcome, mostly through the use of custom
ABAP code, and the project completes the realization
phase and moves into the testing phase. The vendor has
managed to submit deliverable and meet milestone targets,
so they get paid. Their fee is under the cap.
Integration testing begins. The test consists of a string of
transaction codes performed in sequence by the
implementation partner. Since the project has very little
involvement from your own organization, there will be no
user acceptance test. The partner's integration test results
will be considered enough to go-live with.
Mitigating Risk in Large SAP Projects
38
As the partner's integration test is in progress, the steering
committee discusses the SAP version. Because of the
long-time line, the SAP version being implemented is no
longer the latest version. The newest version has some
exciting new benefits. Furthermore the project is still six
months from go-live and SAP is preparing for yet another
enhancement pack release right about then. Implementing
an old version of SAP seems like a poor practice to the
steering committee, and according to their SAP
representative it is. Furthermore the new version will
overcome a couple key gaps that have been identified.
A decision is made to upgrade the system before the go-live
date, and utilize the new functionality to overcome some of
the gaps. Fortunately, the ABAP development team has
not yet been engaged to help resolve these gaps, though
many other gaps have been overcome already using custom
ABAP code.
In regards to the development, the steering committee asks
you this question: "why is there so much ABAP code being
written. Isn't this an off the shelf system?" You answer the
question to the best of your ability: "SAP does not work
when you first plug it in. You have to activate certain
switches before it will work. It also does not do things
exactly the way we do things which is why we need to put
some of our own code in it." They seem satisfied with your
answer.
The project moves forward. A single cycle of integration
testing uncovers many defects. One by one the
implementation partner overcomes these defects, but there
Mitigating Risk in Large SAP Projects
39
is no second round of integration testing to prove that the
defects have been resolved, and as was said before, no user
acceptance test. The defects are purportedly solved and
the system is deemed ready to go live with, which is the
consensus at the go/no-go decision point.
You have become aware that the implementation partner is
starting to lose money on this contract, so their motivation
to go-live and not do any further testing is very strong.
They assure you that the system is operating as it should.
The implementation's conversion team begins its
preparations. Earlier in the project they objected
strenuously when they were told that they must convert
some of the historical financial data from the old system
into the new SAP system. Eventually they relent, as this
was a deliverable spelled out in the contract. They gather
the data and it is ready to be migrated using a tool they call
the SAP Legacy System Migration Workbench (LSMW).
The Go-live target is the first day of the financial year. For
this organization that day is May 1st. As the day draws
near it becomes apparent that the legacy data conversion
team is having difficulties and cannot meet that date.
Consequently, a few days before the go-live date, the go-
live is postponed to June 1st.
Unfortunately rather than making things easier for the
conversion team this makes it harder. The team must now
convert an additional month of financial data into the new
system. Also, unbeknownst to project management the
asset accounting module (FI-AA) must move at the
Mitigating Risk in Large SAP Projects
40
beginning of the fiscal year. To not do so will cause a
multitude of complications.
The implementation partner accepts a financial penalty for
not converting the legacy asset system. Furthermore they
must convert it the following year, and must build an
interface between the two systems at their own expense.
The timeline to build this new interface is only a month, so
it is built without any financial or technical specification
document and some very hasty testing (in other words it is
"slammed" in).
It's now June 1st and the plans to go-live move forward.
The implementation partner cannot afford any delays as
they are now losing money. Thankfully you and the
contract negotiation team have them in a not-to-exceed
contract, so there is no chance of this project running over
budget. The financial loss falls solely on the
implementation partner (or so you think… but as we shall
see later your organization is not as insulated as you think).
On Saturday of the go-live weekend the final data
migration takes place. The volume of data is enormous.
The final configuration and development was imported into
the new production client on Friday night. The conversion
of the historical data began on Saturday morning, and it
appears that it will stretch into Sunday. This is not a long
weekend, so the system must be ready on Monday.
Unfortunately, as the data is being converted, there are
exceptions being raised by the system.
There was no time to test the production system, so this is
the first time these exceptions have been seen. While the
Mitigating Risk in Large SAP Projects
41
configuration and development teams examine the
exceptions, the conversion team continues their work on
the areas of the system that are not affected by exceptions.
It is Sunday and the conversion effort is far from over.
The functional and development teams have solved most of
the defects, but several still remain. It is apparent that the
system cannot be turned over to the users on Monday
morning. The security team is told to lock all end-users
out until the exceptions are cleared and all data is
converted.
It is now Monday night and the system is still not ready, so
the organization remains at a standstill and unable to
operate. 10,000 end users are not able to work on Tuesday
morning. Rolling back to the legacy system is now being
seriously considered,
The pressure on the team is enormous. Finally on Tuesday
night the exceptions have been cleared and all the data
loaded. There is no time for a financial reconciliation of
the data. The system must be turned over to the end-users
on Wednesday morning.
Wednesday morning and everyone celebrates. The system
is LIVE!!!! Everyone is happy except the end users, many
of whom have not been trained. Because of the tight
budget, the implementation partner used the functional
configuration team for its testing. Consequently the testing
was haphazard, and not the central focus of these staff
members. Furthermore there was no link between testing
and security profiles, so many users do not even have
access to the areas they need to have access to, so they
Mitigating Risk in Large SAP Projects
42
cannot work. Equally as bad some users have access to
sensitive areas, like payroll information. ("That's our
CEO's salary?" You overhear a user say to a fellow user as
they look at the system).
Those who can get into the system and are able to use it are
expressing some concerns over what they are seeing for
data. It is not correct they proclaim. The organization's
accountants are raising alarms that the integrity of the
financial data appears to be compromised. There is no
continuity between last year's financial data and this year's.
After a month the implementation partner is about to roll
off the project and this is the state of your SAP project:
The historical accounting data that was loaded is
incorrect
The help desk is overwhelmed with trouble tickets
The accounting balances are off! The sub-ledger
balances do not equal the corresponding general
ledger control account totals.
Users cannot do their jobs
Some users can view sensitive information they
should not be privy to
The interface for assets is not working
Serious bugs are popping up, particularly in the
areas that standard SAP was not used
Your people are unable to support the system
(because they did not configure it)
Mitigating Risk in Large SAP Projects
43
It is now go-live plus four months and little has improved.
Your stress level is through the roof, and many of the
problems listed earlier continue to linger.
It is especially disconcerting that none of your people
actually know how the implemented SAP system is actually
configured.
The financial damages to your organization are mounting.
Many of them are difficult to quantify: what is the damage
of users being able to see data they are not supposed to see?
Furthermore your organization has been unable to do a
single month-end financial close, and in fact the knowledge
transfer between the implementation partner and the
accounting department was not done because it was not a
specific deliverable, so the knowledge of how to do it does
not exist. Your Comptroller is expressing doubts that the
implementation partner even knows how to close the
books.
There is also evidence of double counting with some of
converted data, but that cannot be proven or disproven as of
yet.
Information about the difficulties has now made its way to
the financial markets. Your organization's stock price is
beginning to fall. So far shareholder value has dropped by
5% and the trend is down. There is little confidence that
your organization will get this under control in the near-
term. You do the math: if shares have dropped by 5%, the
total loss to your shareholder's is $1.4 billion dollars. You
gasp. You realize that the search will be on for a
scapegoat to pin this on and you are in the cross hairs.
Mitigating Risk in Large SAP Projects
44
You realize that it's time to find another job, and do so.
You are fortunate that you are able to find a quick job,
though the money and the level amount to a demotion for
you. You resign from your organization for the new job
amidst continuing chaos.
A couple of months into your new job you read that the
implementation has been deemed a failure and your old
employer is rolling back to the old system. Their stock
price is still depressed, and since this is a publicly traded
company the disclosed financial loss has been pegged at
about $40 million (and that does not include the loss of
shareholder value).
It's obvious that litigation is going to arise and you will
undoubtedly be deposed.
Your new job is going well and no one at your new job is
aware of the key role you played in the debacle at your old
job. You are careful not to mention it. It is a stain on your
reputation that you wish to keep secret.
Finally some papers are served to you that you initially
think involve your deposition. They do not. You have
instead been named as a co-defendant along with the
implementation partner and a few others from your old
employer. Because you accepted gifts from the partner (e.g.
they bought you lunch several times), your role in the
debacle is questionable (for a real life example of this see
the complaint in the court case of Marin County vs.
Deloitte).
Mitigating Risk in Large SAP Projects
45
Those free lunches that the implementation partner bought
you were apparently not so free after all.
From the perspective of the
Implementation Partner of XYZ The phone rings forcing you out of your slumber. It's 8 am
but you have taken the day off. You deserve it, and you
deserve a little extra sleep and some relaxation! You have
been working for a year now on this massive SAP project
and it has now been live for the past few months. As you
answer the phone you realize it's someone from work. Do
not they realize you are on vacation! You answer hello.
"It's Jamie. We have a problem…"
"What?" you answer sleepily
"It's the system" is the reply, "It's broken!"
"What do you mean "broken"?"
"SAP won't post any invoices, it just gives us error
messages. A/P, A/R are effected, even the G/L. The
system is not working!"
Mitigating Risk in Large SAP Projects
46
You think the person is exaggerating, but you get reports
like this from all over the firm. You begin to realize that
something has seriously gone wrong. The company is
heading into its busiest period, and you have just learned
that nothing can be shipped. Purchase orders have also
been affected.
As reports filter in, and the error messages are relayed to
you, the realization that this is a catastrophic failure that
seems to be tied to bad SAP configuration starts to set in.
By mid-day the stock market gets wind of the issue and
your client's stock begins to fall. By the end of the week
the SAP system still is not working and the company's
stock has fallen by 8%. The slide will continue if you
cannot get SAP working very soon. This catastrophe has
so far cost your client's shareholder's almost a billion
dollars.
You start to reflect on your implementation of SAP, it
literally flashes before your eyes. The complaint that the
invoices combined from the SD and FICA modules do not
add up, the haphazard testing, reports that people could
configure directly in the quality assurance client. The
memories begin to nauseate you.
But you had to go live. The pressure was enormous. And
the scope was huge…. The consensus was that the big bang
approach to implementing SAP was the way to go. Not
only did you have seemingly every module from SAP in
scope, but you had CRM, BI, and a few bolt on programs
as well. You wanted more cycles of integration and user
acceptance testing, but there was no time. The steering
Mitigating Risk in Large SAP Projects
47
committee said you had to push forward. Not going live
was unthinkable.
And then of course, there was the business itself, or more
specifically those who will use the system. You could not
get them properly engaged. Most units barely participated
in the user acceptance test, and you actually did not have all
of their sign off.
Another month from now and your firm would have been
off the project. You and your implementation consulting
firm were only contracted to help support the system for
another month.
You quickly draft an email to your boss outlining what is
happening at the client and what you think the cause is
(some sort of configuration issue) as well as recap of the
problems you have seen with this project over the duration
of the implementation (users not involved enough,
insufficient testing, lack of control over configuration and
development, etc.). You realize that there is going to be a
lot of finger pointing when all is said and done with this.
One of the deliverables in the contract is to conduct lessons
learned sessions to promote the idea of continuous
improvement. You can only get better if you learn from
your mistakes! Each month you have conducted these
sessions and one is due the day after tomorrow. You begin
to prepare the PowerPoint presentation with an assessment
with what has gone wrong and how these problems could
have been avoided.
Here's what you have so far:
Mitigating Risk in Large SAP Projects
48
More cycles of integration testing
More cycles of user acceptance testing
Better user involvement
Tighter control over configuration
Basis should have kept the quality assurance client
closed to configuration
A full-time accountant should have been on the
team to reconcile critical financial processes,
especially the convergent invoicing between the
sales and distribution (SD) and contract accounting
(FICA) modules.
Better control over ABAP development.
Some of these have been repeated in prior Lessons Learned
workshops, but they continue to be points that your firm
can improve on.
As you are writing this you think back to the pre-sales
process. You were involved and you remember a
demonstration where the people who engineered the system
put it together using functionality from the available
version of SAP, functionality from an unreleased version,
and functionality from custom ABAP code prepared on the
spot by an ABAP'er that was not at all integrated. You
open the email from the guy who made the sale outlining
all of this just to refresh your memory. You did not think
much of it at the time, but it forced your project team to
have to meet unrealistic expectations as to how the system
would function.
You add this to your lessons learned, but then you realize
this is probably not a good thing to discuss with the client,
Mitigating Risk in Large SAP Projects
49
so you add it to an internal lessons learned that is also
conducted once a month with just project personnel from
your firm.
Two weeks have now gone by and this company that
implemented SAP a few months ago still cannot use the
system. It continues to spit out error messages regarding a
fiscal year variant problem. SAP is now in the system
making table level corrections to overcome this problem.
They should be up and running soon. It's not going super
quick because all of the changes have to be unit tested in
the development client, subjected to end-to-end integration
testing in the quality assurance client, and finally a user
acceptance test, also in the quality assurance client.
They figure another week and the system will be
operational. Meanwhile this failure, at the company's
busiest time of the year, has now resulted in a 12% drop in
stock prices. The toll on the shareholder's is now well over
a billion dollars. The slide seems to have abated as the
stock market expects that the problem will soon be
rectified. It's hard to know how much in sales has been
lost, but the early estimates are that about 200 million
dollars of sales have been lost and will not be recoverable;
all because the stock cannot be delivered to the retailers.
There is talk about rolling back to the legacy system.
It's now 17 days into the catastrophe when you get the call
that you have been expecting…..
You have been fired!
Mitigating Risk in Large SAP Projects
50
Unfortunately this nightmare is not over.
You managed to find a job several months later, and you
think this terrible period of your life is over. You are
trying to forget about it.
One day, about seven months later, a man knocks on your
door. You answer it and he hands you a letter. You have
been served with legal documents. You and your former
employer are being sued for $80 million plus punitive
damages!
So begins a two year odyssey that will take you into
countless lawyer's offices, courtrooms, and depositions.
During this discovery process you are confronted with
several damning pieces of evidence: every "lessons
learned", and every email you wrote about the problems at
this client is being used against you. They've also
uncovered the "smoking gun" email that describes the pre-
sales process and how it was rigged to show functionality
that did not actually exist.
You begin to ask yourself: when will this nightmare end!
The project only lasted for a year, and it's now been three
years since the SAP system went live. And it does end,
thankfully. One day you get an email from the attorneys
representing you and your former integration partner
employer: the case has been settled out of court for 90
million dollars. The nightmare is over, though you'll
probably get flashbacks for years to come.
Mitigating Risk in Large SAP Projects
51
It's Happened The frightening part of everything that has been described
in the preceding cases is that it is all based on true events.
It is actually a mélange of several catastrophes that I have
been called in to either fix, or as an expert witness in court
cases. This book is about how to avoid catastrophes when
you are involved in implementing, modifying, or upgrading
SAP.
This book is for anyone involved with such a project,
whether they are the project sponsor, a manager on the
team, or someone involved with actually configuring SAP.
Having a common understanding of the source of
catastrophic failures is relevant to everyone involved,
whether they are from the implementation partner or from
the business actually implementing SAP.
Mitigating Risk in Large SAP Projects
52
SAP is a Great Software Product! The
Implementations Are Not Always So
Great …. It should also be noted that nothing in this book should be
construed as negative towards SAP software itself. When
properly implemented SAP is a great product and is
appropriately considered the leader in enterprise resource
planning software. It is tightly integrated and for the most
part that integration is real time. The processes that it is
capable of supporting all reflect best practices. Firms that
successfully implement SAP in their business processes
tend to be more competitive than those that do not. The
reasons for implementing SAP are valid: it usually does
make an organization run more efficiently and more
effectively than their similar organizations that do not run
it.
Almost every failure involving the implementation of SAP
was not due to the software, they were due to people who
did not appropriately manage the risk factors of the
implementation. Do not view this book as negative about
what SAP is capable of; this book is meant to help
organizations avoid the pitfalls of a bad SAP project while
fully realizing the benefits.
Mitigating Risk in Large SAP Projects
53
The Risks
inherent in
Large SAP
Projects “The first step in the risk
management process is to
acknowledge the reality of risk.
Denial is a common tactic that
substitutes deliberate ignorance
for thoughtful planning”
- Charles Tremper
Mitigating Risk in Large SAP Projects
54
The Risks Inherent in
Large SAP Projects
The key to a successful SAP implementation is managing
risk. Generally speaking the expected rewards of
implementing SAP will generally be realized, if the risks
can just be managed.
This book will explore the sources of risk and the ways to
manage it, and through management a means to mitigate
this risk.
This book does not seek, nor promise, to completely
eliminate risk because that is not realistic. Furthermore this
book is focused on the risks implicit in an SAP
implementation or enhancement project. There are many
other forms of risk that involve SAP that are not within the
scope of what we will discuss, for example the risk of
fraud, or any other kinds of risk that do not directly stem
from an SAP project.
In this book we will explore the elements of risk from
project conception, through the implementation, and finally
in the post-implementation support phase. Very few
people will be part of an entire life cycle of project
conception through to a multiyear support phase, but the
elements discussed through each aspect can stand by
themselves. However, if you are not part of a phase (for
example the conception phase) you will inherit some of the
risk that was incorporated into the project at that time.
Mitigating Risk in Large SAP Projects
55
Furthermore your personal ability to manage risk will be
determined by your position in the project. If you are a
project manager you will have more "macro" risk
management opportunities, but less "micro" management
abilities. For example, bad configuration by a module
specialist could become the source of a major project
failure. Let me illustrate from experience:
If you are the project manager and you have implemented
best practices in change control, but yet unbeknownst to
you an FI module specialist has change the fiscal year
variant mid –year, and the testing by users was not
adequate to show the effect, you could have a situation
where your SAP production system will not function for
two months while you and your team deal with the
damaged tables that result from such an incident. This is an
example from my personal experience (I was brought in to
get this fortune 500 company functioning again after this
happened in their productive system!).
Some of you may find the technical jargon challenging if
you have never actually configured the processes of SAP
before (as is the case with many project managers), but
nonetheless it is a situation that will pose a risk to your
ability to control an SAP implementation.
So then, what are the risks?
The risks are many and diverse. Some of them stem from
your timeline, while others stem from the people you
employ. Some are beyond your control, while others are
directly or indirectly within your control. Some involve
money, some involve communication. Some involve
Mitigating Risk in Large SAP Projects
56
executive support, and some involve project policy.
Others could stem from how the Request for Proposal was
worded, or the scope. There are many sources of SAP
project risk, and in this book we will attempt to describe
and most importantly provide advice on how to mitigate
these risks.
General Project Management
For our purposes time and cost will be treated as general
project management topics, while scope will be treated
later in this chapter and extensively discussed.
Time An unrealistic timeline can cause a number of issues. If
it's too long you may go over the budget allotted for the
project, or be forced to undergo and unexpected technical
upgrade. If it's not long enough you can end up with low
quality work.
Mitigating Risk in Large SAP Projects
57
If a team is pressed for time they are more apt to make
errors, produce poor documentation, faulty configuration,
or rush the testing (which is what happened in the example
mentioned earlier where a changed fiscal year variant was
introduced in the middle of the fiscal year of a fortune 500
company's productive system without adequate testing
resulting in two months of SAP system downtime).
None of the risk factors of an SAP implementation are
isolated. They all integrate just like the SAP system itself
(the hallmark of the SAP Enterprise Central Component
system is its tight integration). Time is effected by other
risk factors. An inexperienced SAP project manager may
not have the acumen to set up a realistic timeline for the
project. In his or her mind the timeline was adequate and
optimal, but their inexperience can result in the timeline
being too short or too long.
In some cases the overall project timeline is adequate, but
the phases within it are not. Perhaps the project initiation
phase is overly long, at the expense of the blueprinting
phase. In such a case the project team will not have enough
time to adequately frame the organizations requirements
into a meaningful blue print and may end up not producing
the optimal system design as a result. Two months after
Mitigating Risk in Large SAP Projects
58
go-live it's realized that a whole process was missed, and
guess what… it was because the team did not have
adequate time to blue print because the project initiation
phase took up to much time devising project charters,
policies, etc.
Because all of the risk factors are integrated, a timeline that
is too short to realistically go live on the target date will put
stress on the project budget and the team. If the budget
stays static as does the timeline, the risk of a catastrophic
system failure is more likely to be realized after go-live has
been achieved.
The people behind the project timeline must have not only
a lot of SAP specific experience, but they should also be
experienced with the modules themselves. Ideally the
project manager is a person who at some point in their
career was a module specialist and configured some of the
elements of SAP to be implemented. This hands-on
experience will give them the acumen to judge how
realistic the blue print and realization phases are. This
experience will also come in handy as we discuss some of
the other aspects of an SAP implementation.
How can risk in the timeline be mitigated?
1. Make sure the person who leads the effort is
seasoned with many years of SAP experience
behind them and a long track record of success.
2. Ensure that the team producing the project plan has
intimate knowledge of the modules being
implemented.
Mitigating Risk in Large SAP Projects
59
3. If the project manager reports to you, trust in their
acumen if they satisfy point one and the team
collaborating in the project planning process
satisfies point two. Do not coerce them into an
unreasonable timeline or you are unwittingly
assuming more risk in your career.
4. Ensure that each phase, when considered by its self,
has enough time allotted to it.
5. Incorporate some slack into the timeline. Slack
allows for a contingency plan to be enacted. We
all know that things come up that are beyond our
control. Have some time built into the timeline to
accommodate such risk.
6. Finally, ensure that the overall project timeline is
reasonable and not overly optimistic.
Mitigating Risk in Large SAP Projects
60
Money It may seem pretty obvious, but if an SAP project is
underfunded a multitude of risks are entered into.
Often the project is funded for the amount requested
(during the capital budgeting cycle), but the estimate to
complete the project was unreasonable due to an
unreasonably short time line. The budget could be the
result of an estimate to complete delivered by a person
inexperienced with implementing SAP.
The funding amount could be insufficient due to
unreasonable pressure to deliver at a budget less than what
was requested. If that is the case the scope of the project
should be cut so that the overall venture is not jeopardized.
See the scope section for a discussion on that aspect.
Mitigating Risk in Large SAP Projects
61
Can a budget that is too high be a problem? I have only
seen it once in my career. It led to a lot of waste, an
inordinate timeline, and ironically many missed go-live
dates because the team was far larger than needed and thus
inefficient and ineffective. The money was provided by the
government to a private sector company. Those who
profited from the fiasco might be inclined to call it a
success.
Scope I have heard it said that given an unlimited budget and an
unlimited amount of time, almost any scope can be
accomplished. Unfortunately I have yet to see a project
that has either. Usually at least one of them is quite
ambitious and aggressive and it is the third aspect of
general project management that either suffers or causes the
pressure on time and budget to increase.
Most often the time and budget aspects of the equation (i.e.
amount of time + budget amount = accomplishment of a
finite scope) are essentially static, while scope is viewed as
somewhat variable, no matter how firmly the stake for
scope has been planted in the ground.
Furthermore scope is often overly ambitious because it is
the aspect of the fundamental project management equation
that is most poorly understood. Time and budget are easy
to understand, while understanding that including the tax
depreciation books of 37 different countries in the scope of
a project, for example, is much less clearly understood in
terms of its ramifications.
Mitigating Risk in Large SAP Projects
62
No other component of SAP implementation risk is as
dependent on the request for proposal process as Scope.
Scope involves determining what will be implemented.
Defining scope is one of the most important tasks early in
an SAP project. During the process of establishing a
precise scope the team members have an opportunity to
state what they will do and what they will not do. They
also have an opportunity to include or exclude high risk
elements from their project, subject to what has been
inherited by the project team from the statement of work
(part of a contract) whose general scope may have been
defined for the most part from a request for proposal.
Scope creep refers to the addition of items, processes, or
functions to the scope of an existing project that was not
included in the original plan of that initiative. An SAP
project will face constant pressure to expand its scope.
Scope creep will also be one of the greatest risks that the
members of the implementation team will face. There will
be constant pressure to add "something that we forgot".
Mitigating Risk in Large SAP Projects
63
The problem with adding "something that we forgot" is that
it was not considered in formulating the project plan, nor
was it considered in formulating the project budget. Scope
creep equals missed deadlines, and more work.
In terms of specific elements of scope any element that
involves any development of any sort is a higher risk
endeavor than those which involve functionality that can
simply be configured. The exception may be the
development of interfaces which allow the team to exclude
a business process that is an extremely poor fit for SAP and
move it to a non-SAP system better suited for it. Let's take
a moment to look at the type of work within an SAP
project's scope to better understand this idea:
Development versus configuration in SAP It is commonly held among experienced SAP practitioners
that most SAP modules and industry solutions have proven
to meet 60-80% of business requirements within a specific
industry without the need to add your own code to SAP's
off-the-shelf code. The percentage of standard SAP
package fit is higher when using the more established
modules (e.g. Materials Management, Controlling, etc.) for
the less industry specific functions
A strong push towards the use of vanilla SAP can push the
60-80% business fit to a higher proportion, perhaps even
upwards of the 80% figure. These figures are of course
subjective, but experience bears them out. It is important
to try as much as possible to change the organization's
business processes to conform to those that are possible in
SAP for two reasons: 1) The process in SAP is based on
Mitigating Risk in Large SAP Projects
64
best practice, and 2) configurable solutions carry far less
long-term risk than those that stray away from what is
configurable.
***
The core of SAP, known today as SAP Enterprise Central
Component (earlier versions were known as SAP R/3, SAP
R/2, and MySAP), is considered a "package" software.
What is meant by this is that an organization that buys the
SAP Enterprise Central Component has purchased a
product with all of the code included. Ostensibly there is
no code to do, especially with SAP since it will support the
best practices in each process.
However, even though SAP includes all of the code, and
supports best practices, it will not work right after it has
been purchased "off the shelf". It needs to be configured.
"Configured", for our purposes means that elements of SAP
code can be activated and modified by activating it in the
Implementation Guide (IMG). As a general rule, if
something can only be done in the Implementation Guide,
it is considered a configuration task.
On the other hand there is "development". For our
purposes development is any code that is inserted directly
into SAP, or coding to interface to an external system. We
shall extend the definition of true coding to include any
code to "bolt on" any product to SAP Enterprise Central
Component, including products sold by SAP itself.
In short, all development work puts the project at a higher
risk than a scope which includes only configuration to
Mitigating Risk in Large SAP Projects
65
adequately meet all the requirements of an organization.
ALL!
If you have the opportunity to set the high-level scope, be
wary of anything that falls into the development category
as it will be much more difficult to control, much more
prone to design flaws, and will put the initiative at risk for
scope creep, missed go-lives, and budget overages.
That being said it will be very difficult to exclude all
development, so let's look at the level of risk posed by each
type of development:
Development Risk If an SAP project could be confined to configuration only,
the overall risk profile would be considerably less.
Unfortunately it is rare to see a project without at least
some development involved. Let us begin by looking at the
types of development and following that we'll look at those
that pose the greatest risk.
Usually SAP development is discussed in terms of
RICEFW. As shown in the illustration below the acronym
stands for Reports, Interfaces, Conversions, Enhancements,
Forms, and Workflow.
Mitigating Risk in Large SAP Projects
66
Let us take a look at each element from a risk perspective:
1. Reports – the development of reports can carry two
forms of risk:
a. The first concerns the data that it represents.
If the data does not reconcile from an
accounting perspective, the confidence in
the project can be shattered. Sometimes the
reports can indicate a significant underlying
problem. For example they may indicate
that invoices sent out to customers do not
Mitigating Risk in Large SAP Projects
67
reconcile to the invoice data supplied by two
or more SAP modules that produced the data
(i.e. convergent invoicing). Such an issue
could cost the business millions of dollars.
This is not a hypothetical possibility: I have
seen it first hand when I was part of the
plaintiff's legal team in a prominent case in
the United States. It is for this reason that I
recommend that most projects have
qualified accountants on board whose only
job is to reconcile financial data and ensure
its integrity.
b. The inherent difficulty in satisfying multiple
users of reports is a second risk that is less
catastrophic than the first risk that I
discussed, but a risk that can cause timelines
to be missed. This is also a risk that is very
difficult to manage, particularly if the report
is meant to be more of an ad-hoc report
facility rather than a defined report. If the
report is well defined (for example a
business wide report for open invoices with
little to no variations in its appearance), then
do a mock up using Microsoft Excel and
have it signed off by the highest possible
authority in the business. If it is ad-hoc it
will be much more difficult to define and
one should expect a longer time-line.
Adding to this type of risk is the plethora of
reporting options available: ABAP, Business
Objects, Crystal Reports, etc. This may
Mitigating Risk in Large SAP Projects
68
pose a difficulty for the functional resource
that may be an expert in the core SAP
Enterprise Central Component, but will not
have expertise in the method used to create
the report thereby complicating the
functional report creation process.
2. Interfaces
a. Interfaces to external systems likely cannot
be avoided, but understand that they are a
source of more risk than those involving
tasks that can be configured from the SAP
Implementation Guide if that configuration
can adequately meet the business
requirements. This is because they are
more apt to have design flaws, require more
testing than configuration tasks, usually
involve external systems that will be
difficult to control, etc. When devising the
scope of the implementation the starting
point should be "NO interfaces". Accepting
anything beyond that puts the
implementation at greater risk.
b. Usually you cannot avoid having at least
some interfaces within the scope of your
project. When you cannot avoid them,
simple one-way interfaces involving no
transactional data, (especially no data
involved in financial processes) tend to be
low risk. An example of this would be an
interface carrying a list of project managers.
Two-way interfaces carrying financial
Mitigating Risk in Large SAP Projects
69
transactional data are higher risk. As much
as possible financial interfaces should carry
only balance information rather than
transactional data so as to greatly mitigate
the risks involved in misrepresenting or
double counting financial transactions.
Dividing two-way interfaces that carry
financial data into two one-way interfaces
also tends to lessen the complexity (and
thereby the inherent risk) of the interface.
3. Conversions
a. The greatest risk pertains to conversion
strategies that attempt to import a large
amount of historical financial transactions
into a new SAP system. Though the
motives are always good, the strategy is
heavily flawed and exposes the project to
great risk. This strategy, along with the
conversion of financial balances approach,
will be discussed at length later in this book.
b. It is advantageous if some of the functional
SAP personnel can do some of the simpler
conversions themselves. An example of the
type of data your functional consultants can
handle is master data of less than 50,000
records. If they can handle simple
conversions themselves that only pertain to
the go-live (i.e. they will never have to be
used after go-live), the conversion of this
data will take far less time and will not
require a functional specification document
Mitigating Risk in Large SAP Projects
70
and a technical specification document. To
that end, poll your functional consultants to
find out who has expertise in creating simple
data load conversion programs using the
SAP's Legacy System Migration Workbench
(LSMW) and have them teach the rest of the
team how to do it. The time that your
project will save on many conversion items
can increase the amount of slack you have in
your project time-line, thereby giving you a
tool to fight the unexpected difficulties that
will arise on your project, and reducing the
amount of risk the project is exposed to.
4. Enhancements – the greatest overall risk arises
from this type of development category. It is also a
development category with many different
variations. Since we are discussing development,
the enhancements made by way of configuration
will be excluded. Suffice it to say though, that any
enhancement that can be accomplished by way of
standard configuration carries a risk to the project
far less than that which involves any type of
development. Following this section we will look
exclusively at enhancements and the risk they carry.
5. Forms – forms are inherently a low risk type of
development. That is because they are easy to test
and the scope is well defined and limited. There
are several tools that can be used including
SAPScript, Adobe Forms, and many others. From
a risk profile ensure that the type of tool used is
certified for use with SAP, or has an established
Mitigating Risk in Large SAP Projects
71
track record with SAP. Aside from that, ensure that
the forms are properly tested in the integration and
user acceptance tests and the results approved; this
will assure that they are functioning as desired.
6. Workflow – adequate testing is the key to ensuring
that this type of development is functioning
properly. The integration test is especially
important in this case since this type of
development is prominent in integrated business
process flows. The risk profile of workflow is
inherently about medium as compared to
enhancements involving other forms of
development.
More on Enhancements
Let's take a closer look at the types of development that are
called enhancements and the specific risk profile each
carries. Note that this list is in order of highest to lowest
risk.
1. Core modifications ("Core mods") – The first type
of enhancement, and the most dangerous, is what is
called a core modification. A core modification is
the insertion of ABAP code into standard SAP
Enterprise Central Component programs where
SAP has not provided a user exit. This is usually
Mitigating Risk in Large SAP Projects
72
done because the configurable SAP processes do
not support those of the organization. Introducing
a core modification into the system is extremely
high risk because it can lead to downstream
problems, support problems, and will be overwritten
by upgrades. It is important that the project policy
disallows all core modifications except with
executive approval. The only way that a core
modification should ever be allowed should be if
there have been approvals at the highest level of the
organization. That being said: do everything in
your power to stop core modifications. Generally
speaking the organization should change its
processes to conform to the best practices inherent
in SAP configuration rather than the other way
around, and when a core modification is absolutely
deemed necessary every effort should be made to
copy the native SAP program to a Z-program prior
to modification (see the next point).
2. "Z" programs – the next highest risk area of
development is that of Z programs. A "Z program"
refers to a program that is not native to a normal
SAP system. It does not involve the inclusion of
SAP code into an SAP program (see point number
1), but rather it is the inclusion of an entire program
into SAP. Z program development should require
high level approval, for example at the steering
committee level. The inclination should be to
reject such development requests and force the
organization to use the best practices available in
Mitigating Risk in Large SAP Projects
73
the Implementation Guide. Z programs are often
strung together to replace entire areas for which
SAP has already developed a solution – for
example, as an alternative to the entire Controlling
(CO) module. Such solutions are inherently rife
with problems, whereas the SAP solution is usually
solid, well established, integrated, and based on best
practices.
3. "Mini" core modifications – for our purposes mini
core mods are modifications to SAP code that are
allowed by SAP via user exits or any other avenue.
Those these are allowed they should still be
avoided. Though they will not be overwritten by
upgrades they are still more apt to have problems
than the normal code in SAP, and require much
more extensive testing. Mini core mods should
require senior project approval, with a view to push
the organization towards the use of SAP best
practices as they exist in the Implementation Guide.
4. Non-SAP "Bolt-on" programs – Non SAP bolt on
programs involve programs that were not created or
are not sold by SAP. Those that have not been
certified by SAP pose the greatest risk, but even
those that have been certified carry a risk
significantly higher than that posed by configurable
processes within SAP Enterprise Central
Component. There is at least one notable
exception: sales and use tax programs are well
established within SAP, with a long history and
Mitigating Risk in Large SAP Projects
74
configurable integration points in the
Implementation Guide. Furthermore it is less risky
to use them than to configure the rates directly into
your SAP system (which is a huge task that would
require many hours of configuration, as well as
constant up dates). There are other exceptions. As
a general rule, if it has a configuration point within
the SAP IMG, if it has been certified for use by
SAP and if the alternative to not using the bolt-on is
many hours of configuration followed by constant
updating, then it is less risky to use the bolt on than
to not use it.
Bolt-on programs that have been extensively tested
with SAP's participation carry this designation:
5. SAP's own bolt-ons: lets differentiate here between
bolt-ons that SAP developed (like Business
Intelligence), and those that it simply sells because
it bought a company (like Business Objects). Both
carry far more risk than that of configurable
processes within the Implementation Guide of the
SAP Enterprise Central Component, but are less
risky than doing a core-mod to a process (item # 1
on this list). Many of the bolt-ons involve
reporting, so also note that it is extremely difficult
to control reporting requirements: ask five different
Mitigating Risk in Large SAP Projects
75
people what the requirements are for a certain report
and you are liable to get five widely ranging
answers. Consequently it is best to limit the
number of reports that are in the scope of a project,
or better yet, to not allow any custom report
development within the scope of your SAP project.
6. Z transactions – A "Z" transaction simply refers to a
program that has been assigned to a custom
developed transaction code. The program and the
transaction are two different development efforts.
If it relates to a custom program see point number
four. The use of a Z as the first letter of the
transaction code helps assure that it will not be
overwritten during the upgrade process. The
inherent risk of this type of development is very
low.
Established SAP Modules Compared to
Newer Ones Every so often SAP introduces a new module to its core
SAP Enterprise Central Component system. For example,
the SAP Grants Management module (SAP GM) was
introduced in the early 2000's. Such programs tend to
have far more bugs in them than older modules like SAP
Materials Management (SAP MM); therefore the inclusion
of them in your scope puts the entire project in greater peril
than if you stick to the well established modules. Even
new functionality within an old established module carries
additional risk to a project because it too will contain more
Mitigating Risk in Large SAP Projects
76
bugs than the established modules. On the other hand, the
new functionality could solve a critical gap that might be
otherwise difficult to overcome.
Note: even the older established modules of SAP have the
occasional bug in them. That's why you need SAP
consultant experts who have the experience to differentiate
between a bug and a configuration issue. This will lead to
a speedier resolution of such issues.
***
In closing out this discussion of development as a risk
factor in the context of scope, let me just say that this is the
area of the project conception phase (including RFP
planning) that will be the most instrumental to determining
the degree of risk that will be undertaken by the initiative.
Strategy: The Big Bang Approach and the
Phased Approach A "big bang" approach is one where the maximum amount
of functionality is deployed all at the same time on a "go-
live" date. The term "go-live" refers to the date commonly
used in SAP circles for the day that the implementation is
activated for users in the production environment.
I am not a proponent of the big bang approach as it
inherently involves a strategy incorporating the maximum
risk. I am a proponent of taking on the least amount of
scope possible ….. small steps toward the ultimate goal of
an IT program.
Mitigating Risk in Large SAP Projects
77
A strategy of taking the smallest steps forward as possible
is known as a phased approach. Such an approach is
basically a risk mitigation tactic in its own right, and
perhaps one of the most effective. It is a strategy that can
be practiced at the level of the project manager, down to the
team leads, since the team leads must make decisions that
are at a lower level than those that the SAP project manager
makes. It probably goes without saying that I am a
proponent of the phased approach.
To illustrate a phased strategy: instead of deploying the
SAP General Ledger (FI), SAP Cross Application Time
Sheet (CATS), SAP Business Intelligence (BI), and SAP
Materials Management (MM) all at the same time how
about deploying Business Intelligence in a subsequent
release? If cutting CATS and MM from the scope does not
necessitate an interface be built to a legacy system, you
may be able to cut them as well. Look for opportunities to
reduce scope in every aspect of the project initialization,
and even during the project itself.
Mitigating Risk in Large SAP Projects
78
Furthermore every member of the team should look for
opportunities to reduce scope.
The Inherent Risk of Long Time Lines The bigger the scope of a project the more likely it is to
have a relatively long time line … that is a timeline over a
year.
In my career I have seen several projects longer than two
years. Invariably such projects encountered a problem
with the SAP version they were attempting to go live with.
SAP releases new versions every few years. Often they
have significant improvements, and contain solutions that
will overcome the gaps your team finds during your
project's blueprinting phase. Knowing that a solution to a
gap exists in the latest released version often means that
your team must do an unexpected upgrade in the middle of
your project.
The upgrade eats up the slack you had built into your
timeline, thereby increasing the overall risk that your
project encompasses.
As you consider risk, try and tailor your scope and timeline
to what is considered the optimum project length: 9 to 12
months. Shorter than nine months is fine if the scope is
extremely limited. If the project is a green field
implementation any timeline shorter than nine months
might carry its own risk due to an abbreviated duration.
Any timeline longer than a year carries the risk that you are
implementing what will be a quasi obsolete version by the
time you go-live.
Mitigating Risk in Large SAP Projects
79
Timing of the Change-over While the overall length of a project can incorporate
unnecessary risk in a project, so can the actual timing of a
change.
All of the tasks of a project should be planned with the least
disruption possible to the business. Certain times of the
year are not only disruptive to the business but innately
dangerous to implement a new solution during. For
example, the last month of a fiscal year should be off limits
for most changes because they put the issuance of financial
statements at risk that could cause financial penalties if
missed.
On the positive side, going live on holiday weekend has the
advantage of an extra day in the go-live weekend plan, so
try to take advantage of such times in the year.
If payroll is in the scope of the project you may want to
stay away from the period December to March when
payroll tax forms must be issued (with fines imposed for
failing to file). Going live on non-pay weeks is also an
advantage where payroll is involved.
Conversion Strategy The data conversion strategy can become a contentious
issue if it is not explicitly spelled out at the earliest possible
point in the project, ideally during the preparation of the
request for proposal (i.e. well before the start of the
project).
Good intentions often push the strategy towards a strategy
of converting historical data. For some types of data this
Mitigating Risk in Large SAP Projects
80
might be alright, but for anything that involves a financial
accounting document it is not.
Trying to recreate the double entry postings of historical
documents is time consuming, futile, and ignores the fact
that a legal book of record already exists (the prior system).
It is futile because you cannot simply recreate old financial
records, because they must obey the fundamental
accounting equation of assets = liabilities + equity which
means that each historical posting must contain a debit and
a credit. In addition the old financial records will have to
satisfy the checks and balances of the new SAP system
which may be significantly different to that of the old
legacy system.
To load historical accounting information, each sub-ledger
would have to have the original documents posted to it and
the month end jobs run (for example depreciation). As you
post each month, a "month-end" would have to be
performed to ensure that the balances are correct (including
the reconciliation of key balances such as those for the
bank).
Financial statements would have to be created for each
historical month and then validated against the actual
statements that were already created.
If you cross fiscal years, the year-end carry forward
programs would have to be run for the general ledger and
sub-ledgers.
Mitigating Risk in Large SAP Projects
81
Further complicating the idea of converting historical
financial data into a new SAP system is the fact that data
objects between the two systems could be quite dissimilar.
You may have to make up data for historical transactions to
fulfill the requirements of SAP. For example, if you have
the Profitability Analysis module of SAP activated (CO-
PA) you may have to make up the profitability segment
postings to satisfy the requirements of the new system.
Considering this is historical data from a legal book of
record that is not your new SAP system, this could be both
confusing, excruciatingly time consuming, and ignoring the
fact that the old system remains the legal book of record.
The difficulty is that in many projects the old book of
record will be on a system that is destined to be
decommissioned (perhaps a mainframe). If that is the case
the data from the old system of record should be exported
to a flat file and archived in an appropriate system with
appropriate hardware. Your new SAP system is not
designed for archiving such information.
The best practice data conversion strategy involves only the
take-over of balance sheet related accounting information.
This strategy extends through all sub-ledgers that provide
the initial point of record for accounting purposes. Thus if
possible close all open payables, receivables, purchase
orders, etc. to avoid having to deal with the conversion
complexities these bring to the implementation prior to go-
live. Amounts that cannot be closed should have only their
open balance brought over with a reference back (and
access to) the old system.
Mitigating Risk in Large SAP Projects
82
An open balances centered conversion strategy is best
executed at the beginning of the fiscal year. This is the
lowest risk option available.
If go-live must be within the fiscal year (i.e. not on day one
of the fiscal year), the year-to-date balance in each P&L
account must be entered into the SAP General Ledger as a
journal entry with reference back to the original system.
Interfaces As mentioned in the strategy discussion, cutting SAP
functionality from scope may cause additional interfaces.
Determining the degree of fit of each SAP module involved
is the key to determining whether it is better to cut that
module or to cut the interface. Determining the degree of
fit requires an SAP expert.
In some cases the interface versus SAP functionality
dilemma described above is not present. That is: not
incorporating the interface does not necessitate the
activation of the SAP functionality. In such cases the
strategy is clear: strive to remove such interfaces from
scope.
Mitigating Risk in Large SAP Projects
83
SAP modules
As mentioned earlier, there is often a dilemma between
SAP functionality and interfaces. If the SAP module is a
good fit it is usually preferable to choose that rather than an
interface to a legacy system or any other system. On the
other hand, if an SAP module can be cut without building
an interface, it is a good idea to cut it to reduce scope. It
can always be deployed at a later date in keeping with the
phased approach strategy.
One module that should almost always be in scope is the
SAP General Ledger (SAP FI-GL). It is the central point
for all financial information and cannot be cut if you are
attempting to deploy any modules that create financial data
(which is almost all modules in the core SAP Enterprise
Central Component system). Even if you are contractually
required to interface to a non-SAP general ledger (Oracle
for example), you will still have to deploy the SAP General
Ledger because it is required in order to configure most
other modules of SAP, even if they don't appear to be
Mitigating Risk in Large SAP Projects
84
accounting related (e.g. the Sales and Distribution module
is not an accounting sub-ledger, yet it requires the SAP
General Ledger to be configured in order to configure
account assignments).
A module that is especially good to cut from scope and
deploy at a later date is SAP payroll. Payroll is perhaps
the most complex and most sensitive module that can be
deployed out of the SAP Enterprise Central Component.
Including it in scope puts almost every other SAP module
at risk during the go / no go decision point that almost
every project has in their timeline. If you have extensive
SAP functionality at stake, and payroll is but small part of
it, there is a good chance that the entire implementation
will miss its initial go-live date due to any issue with
payroll.
This is especially bad if some modules must go live at the
beginning of the fiscal year or risk a delay of another year
for an opportunity to deploy. Such is the case with the
SAP Asset Accounting module (SAP-AA). The Asset
Accounting module can be implemented mid-year but it is
far more complicated to do so, and requires additional
configuration both before and after it is live.
The mantra is CUT IT FROM SCOPE and deploy during a
separate phase, unless of course the module in question is
the SAP FI General Ledger.
Other aspects of scope that will affect the overall risk you
undertake when you embark on your project are the size of
the team required to execute your plan, the international
Mitigating Risk in Large SAP Projects
85
complexity involved, and the degree of fit between the "as
is" process and the "to be process" available in SAP.
Size of Team The size of the team is directly proportional to the amount
of scope you take on. The more modules involved, the
more processes involved, the more interfaces and
development involved, the bigger the team.
While the size of the team is not as big a risk factor as say
taking on a lot of development work, or not implementing
vanilla SAP, it is nonetheless a risk factor. I have seen
project with as many as 300 members on the team, and a
budget of several hundred million. The project was so big
that no single "war room" could contain it. Many of the
people working on the project did not even know who the
project manager was. The project had several failed go-
live attempts, and the massive scale of the project was
partially to blame.
Carving down the scope of a project whenever possible will
mitigate risk. This holds true as much at the request for
proposal stage as it does at the blueprinting stage. Keep
the team as small as possible.
In general, SAP projects with the number of team members
below 30 are relatively easy to control and yet can produce
some amazing results.
International Complexity An international scope to your project also increases the
complexity and thereby the overall risk assumed by the
project. If the project can be deployed in just one country
Mitigating Risk in Large SAP Projects
86
initially, followed by deployments in follow-on projects the
inherent risk is far lower. The initial implementation will
be challenging enough without throwing a deployment to
multiple countries into the equation.
Deploying to multiple countries entails multiple tax
jurisdictions. It means that the system must accommodate
the rules, laws, and regulations in those areas. This means
added risk that your team may miss some of these
regulatory or statutory issues or that they will not fully
understand the tax consequences of their design. Your
team will be under duress just to bring the system up and
adhere to the rules, laws, and regulations of the host
country.
Consider a template approach. Go-live only in the host
country with the initial SAP system. After that system is
up and stable, begin the deployment of the template one
country at a time. Start with a gap-fit first, make any
necessary changes to accommodate those gaps (example:
the new jurisdiction has different rules for depreciating
assets so a new depreciation area must be set up and
configured), and then deploy the template. Repeat this for
every country.
This concept can also be used for intra-country roll-outs.
For example, I have seen the same concept used for the
deployment of SAP through the multiple counties of a state
in the USA. The overall project took five years, but the
roll-out was always on time and had no major incidents. It
was a very successful project. At no point was the team
more than thirty in size (see the section on team size),
Mitigating Risk in Large SAP Projects
87
whereas had a big-bang approach been utilized it probably
would've required a team three times the size and
encompassed multiple serious problems along the way.
Things like missing the go-live date, missed business
requirements, and bad configuration and development by
rogue consultants could have (and most likely would have)
occurred.
Degree of Fit The overall strategy of an SAP project should always be to
implement vanilla SAP. While it's easy in the early stages
of the project life cycle to say that the organization must
alter its business to conform to the available settings of
SAP's configuration panel, it is much more complex and
difficult in reality.
While the adoption of a vanilla SAP stance will always
result in the lowest risk SAP project, it is still advisable to
do the due diligence early in the project (ideally at the
request for proposal stage) to get an idea how far off
standard SAP processes are from the current as-is
processes. Knowing this, certain processes might be
deemed out of scope because they are so unique to the
industry that they do not exist in normal SAP.
One example of this is the Telco revenue process before the
advent of the SAP Telco solution. The revenue process
called "separations" was not supported. Another concept
that was not supported until recently is that of convergent
invoicing. This is the production of one SAP invoice from
multiple modules and processes. While it does not sound
that ominous, overlooking the complexity of this process
Mitigating Risk in Large SAP Projects
88
and SAP's inability to support it brought about one of the
biggest SAP related litigation cases in history. So ensure
that a study is undertaken as early as possible, ideally at the
request for proposal stage so that you go into the project
with a good understanding that vanilla SAP is a reasonably
good fit to the processes that are in scope.
In cases where vanilla SAP just is not a good fit for a
business process, attempt to push that process out of scope,
even if you have to build an interface. Having to build an
interface is far less risky than attempting to force SAP to
accommodate a process that it simply cannot accommodate.
If you are still in the contract phase such language can be
inserted to safeguard both parties.
Things That Should Never Be in Scope Core modifications, mini-modifications, Z-programs, and
Z-tables should never been in the initial scope of a project.
If possible core modifications should never be allowed on
the implementation. The other types of development
should also be avoided, but if it cannot be avoided, they
should arise from unforeseen needs discovered during the
blueprinting phase, or put off to a later phase.
Mitigating Risk in Large SAP Projects
89
Scope – the Final Word From the initial conception of the SAP project, to the go-
live, the pressure to add things to the functional scope of
the endeavor will never cease. "No" should be the stock
answer to any request to add scope, even for the request for
proposal if you are involved in that stage. The types of
"scope" you want to push for at the request for proposal
stage are the addition of factors that will help mitigate risk,
things like having accounting folks included in the scope to
just do reconciliations, or to add a full blown change
management office to your project.
During the project, scope creep will be a constant
challenge. Look to not only stop scope creep, but cut
things out of the original functional scope whenever
possible. Cut out an interface here, cut out a business
process there, and turn a simple conversion over to a
functional person trained in the Legacy System Migration
Workbench to avoid the creation of functional and
Mitigating Risk in Large SAP Projects
90
technical specification documents. Conversely, if you can
add personnel to your project to help control risk, do so
whenever possible.
Remember that after the project has started you have very
little control over two out of three of the factors in the
fundamental project management equation of time + money
= the accomplishment of a finite functional scope. If you
reduce that initial functional scope, and prevent scope
creep, you may find that you have a surplus of budget.
Mitigating Risk in Large SAP Projects
91
The Five
Basic Phases
of an SAP
Project and the Risk
Inherent in Each
Mitigating Risk in Large SAP Projects
92
The Five Basic Phases of an
SAP Project and the Risk
Inherent in Each
A Word on Project Methodologies Used
on SAP Projects There are many different project methodologies used for
SAP projects. Many are "proprietary" methodologies
belonging to the implementation partner that are used as
marketing tools to differentiate one implementation partner
from another. The five basic phases often appear with
different names and the activities juggled from one phase to
another, but the activities generally remain the same.
ASAP is the project methodology developed many years
ago by SAP that despite rebranding (to Value SAP for
example) is still well known in the SAP industry by this
term and continues to be used. One of the reasons for this
is that the use of the term ASAP and the use of the ASAP
methodology allows SAP project veterans to instantly share
a common understanding that can be carried from project to
project.
The ASAP Methodology A general discussion of the ASAP methodology appears in
the Appendix. The phases are:
1. Project Preparation
2. Business Blueprint
Mitigating Risk in Large SAP Projects
93
3. Realization
4. Final Preparation
5. Go Live and Support
A few of the activities included in each phase are shown
below:
The Risk Inherent In Each SAP Project
Phase In this section of the book we will examine each phase in
light of the intrinsic risk each phase carries.
Mitigating Risk in Large SAP Projects
94
Risk Inherent in the Project Preparation
Phase The risks inherent in the project preparation phase of an
SAP project are not readily apparent. Risk mitigation
tends to involve setting up the proper internal control
structure, based on project policies designed to control risk.
Risk mitigation at this stage also involves staffing the
project with people who have the appropriate skill set. In
particular, subject matter experts and SAP experts with in
depth knowledge of their areas is integral to success
because they will be relied upon to direct the team towards
best practices.
Implementing an SAP module without an expert providing
advice on it is kind of like shooting darts in a crowded
barroom. Someone is going to get hurt!
Module leaders who do not have the appropriate level of
expertise are less likely to find standard solutions to the
business requirements presented to them, and thus are
likely to push the project towards unnecessary development
that carries an inherent risk far higher than a standard SAP
solution.
See the Project Personnel section for a more in depth
discussion of this area.
During this phase you'll also be creating a resource loaded
project plan. Create this as soon as possible and maintain
it throughout the project. I once saw an SAP project with a
team of over 100 people, and no project plan until they
entered the Realization phase. The Project Manager
Mitigating Risk in Large SAP Projects
95
attempted to create a bottom up plan that turned into a
disaster. The plan eventually had to be abandoned. It's
important to have bottom up participation in the planning
process, but the overall chief of the project cannot abdicate
their role in coordinating and controlling the vast human
resources that will be involved in the project. To do so puts
the entire endeavor at risk due to a lack of vigilance.
The timeline that you and your team put together should
also be rapid, typically on the order of nine to twelve
months. This is to prevent issues with upgrades and
support packs that invariable plague projects with longer
timelines. This aspect was discussed earlier in this book.
During phase one of the project, there should also be a
concerted effort to not just define the scope, but reduce it.
There are often gray areas concerning scope that present an
opportunity to tighten the vise on it. As the project
progresses, opportunities to compress the scope become
fewer and fewer.
One final word on the project preparation phase: though
you do want to take an appropriate amount of time to
diligently plan out the project, do not take excessively long!
Any time you save in this time can be used to create slack
in the project plan and keep the implementation nimble so
Mitigating Risk in Large SAP Projects
96
that it can deal with the unexpected things that inevitably
pop up in later phases.
Risk Inherent in the Business Blueprint
Phase The business blueprinting process is fundamental to
understanding the business requirements that must be
incorporated into the design of the SAP system you will be
deploying. Because it requires an understanding of what is
possible within standard SAP configuration, having at least
one expert in every module that is within the scope of the
solution is crucial to delivering the best possible solution.
The starting point for blueprinting is the study of the
organization's as-is state. Often organizations oppose this
because they do not want to replicate the existing state.
This stems from a misunderstanding of the purpose of
studying the as-is. The reason for studying it is to
determine the business requirements that underlie the as-is.
The functional team will ask the question "why are they
Mitigating Risk in Large SAP Projects
97
doing this process"? Experienced SAP professionals will
understand that they are not out to replicate, they are out to
understand and then put forth as solution based on the best
practices inherent in SAP configuration. They are also
looking for gaps that may challenge the standard
functionality of SAP.
Skipping a review of the as-is often indicates that the
project is poorly managed and likely to become a "package
slam". The term "package slam" is a derogatory term used
by seasoned SAP people to denote a project that is not
observing best practices and has put expedience (and
possibly profit or budget conservation) ahead of quality.
Such projects are at high risk to not realize the benefits
promised by the business case, or worse yet have a
catastrophic failure.
Thus, examining the as-is state is crucial to a successful
SAP project. Deriving the true business requirements from
this examination is equally crucial. The final blueprint
document should show a clear trail between the as-is and
the requirements.
From these requirements should flow the design. Ideally
the design will be 100% based on standard SAP
configurable processes. To get to this point the senior
executive of the business (especially the highly placed
project sponsor), must be adamant that the business will be
reshaped to conform to the processes available in standard
SAP. Without such a strong high-level commitment it will
be very difficult to reshape the business to follow SAP
processes in cases where the gap is wide.
Mitigating Risk in Large SAP Projects
98
Making the business conform only to the processes
available in SAP will be a huge challenge for the functional
team. Once again, a highly seasoned expert in each
module is crucial to making this happen. Without them
such a transformation will be extremely difficult because
less seasoned personnel will not have an understanding of
what is possible. There may also have to be additional
modules added that were not anticipated at the beginning of
the project, but adding them is almost always preferable
(i.e. cheaper in the long run and far more effective) than in
house ABAP development.
Although it is not part of the “official” ASAP project
methodology, I highly recommend the use of active and
continuous SAP prototyping to give the business a sense of
what the to-be state may look like. This can save a lot of
time by allowing the business to get a glimpse of how their
business requirements may be handled in SAP and get
instantaneous and invaluable feedback well before the
blueprint has been finalized. There may also be several
alternatives and the use of a prototype can help the business
understand the differences and give informed input to the
future design.
Another key ingredient in the transformation of the
business to SAP best practices is a strong change
management team. This team is so critical to such a
radical change that cutting functional scope is preferable to
cutting change management scope. If anything, it is
preferable to cut functional SAP scope to fund an increase
in change management scope and staff.
Mitigating Risk in Large SAP Projects
99
Unfortunately it is extremely rare that a project can use
only standard SAP without some sort of development.
Reports are seldom robust enough (some modules like
FICA have no standard reports at all!), and some industries
or organizations have processes where a different software
package is better at handling a process (sales and use tax
calculation is one example).
The mantra should be vanilla SAP, i.e.100 per cent use of
standard SAP processes, but be prepared to accept
something less than 100 per cent. The closer you stay to
standard SAP, the safer your project, and the lower the
overall risk profile.
In order to keep your project as close to vanilla SAP as
possible, the blueprints should only be allowed to contain
designs that utilize standard SAP. Any non-standard SAP
solution should require sign-off by senior project
management. Taking this a step further, any solution that
requires the use of a developer should require senior
approval, this includes user exits. If a user exit is required
the project managers of the project should understand
exactly why, and it should be allowed if the configuration
alone cannot meet the business requirement.
Project managers should push hard to keep the project as
close to vanilla as possible, and this means keeping a
vigilant eye on the blueprints for designs that stray away
from solutions that can be configured in the
Implementation Guide without any sort of development,
even solutions that involve user exits push the system
further away from what is available by just configuring.
Mitigating Risk in Large SAP Projects
100
About mid-way through the blueprinting phase the
functional team should have an idea of what interfaces,
bolt-on programs, and z-transaction codes will be
employed. In fact, they may have already been decided
much earlier in the process, perhaps as early as the request
for proposal stage. However, the blueprinting process may
have uncovered the need for additional interfaces and bolt-
on programs that are a better fit for the business
requirements of the organization, and demonstrated their
value to project management. The important take-away
here is that at some point in the blueprinting process it will
be time to start working on functional specification
documents that can be turned over to the developers (who
to this point have virtually nothing to do on the project), so
that they can begin their technical specs and be ready to
start developing their programs at the beginning of the next
phase.
If you have not been able to deter other forms of
development you'll also have to get the functional
specification documents started for these sometime in this
phase as well. However, I once again stress that
deterrence should be the mantra. All forms of development
aside from interfaces, bolt-ons, and z transactions pose
risks to the project ranging from mild for user exits, to
medium for z-programs and major for core modifications.
Be on the lookout for z-programs that amount to building a
custom module in SAP, especially if a module to
accomplish that function already exists. (Earlier in this
book I gave an example where an organization in
California developed their own module to accomplish
management accounting when SAP already had a very well
Mitigating Risk in Large SAP Projects
101
developed module called Controlling, also known as the
CO module, to accomplish the same function! Such
development poses the highest possible development risk to
the project and should never be allowed.)
Because there is a finish-start dependency between the final
blueprint design and the functional specification documents
for development that have to be written, the production of
these documents will have to stretch into the early part of
the next phase. The phases of the project are arbitrary, and
some tasks like this rightly belong in two phases. As the
project plan is drawn up, bear this in mind – there are cross
phase tasks. In this case, the key deliverable ending the
phase is the Business Blueprint.
At the end of the blueprinting process the final document
produced (that is the Business Blueprint) must be signed
off by the appropriate representative of the business. The
blueprint can be module based or based on integrated
processes, the choice is yours, and each has advantages
over the other. Regardless of the choice, the blueprint
must be signed, or the project is halted until it is. Do not
enter realization with this as a loose end or the issues
holding it up could grow in size, putting the project at
further risk.
In terms of duration, the blueprint phase should be second
only to the realization phase in terms of the proportion of
your total timeline that it occupies. You need to get the
design right, and then you need to build it right, and have
adequate time for both activities.
Mitigating Risk in Large SAP Projects
102
Risk Inherent in the Realization Phase Only after all blueprints have been signed off should the
project move into realization. The pressure on the business
and the functional SAP team to come to agreement over
any contentious issues should be immense. It should be
tied to the ability to go-live.
Once the blueprint has been signed off the process of
configuring the system according to the design documented
in the approved blueprint can begin. Before that a link
between the build and the requirements identified in the
business blueprint should be constructed. That link is
known as a "requirements traceability matrix".
The requirements traceability matrix can be constructed
right at the end of the blueprinting phase while the team is
waiting for the blueprints to get signed off. Each
requirement identified in the blueprint should be given an
index number that is shown in the blueprint so that it can
easily be found in the indexed requirements matrix
document.
Once the realization phase is in progress, the matrix should
have several sign off columns. The first will show an
estimate of completion or the initials of the person who
fully configured the functionality. A second column should
show that the configuration was imported manually into the
unit test client (via transaction code SCC1) as indicated by
the initials of the team lead for the module. The third will
show that it has been unit tested and Failed (F), or that it
passed which is indicated by the initials of the person who
tested it.
Mitigating Risk in Large SAP Projects
103
After a baseline configuration has been created and
successfully unit tested all development approved in the
Business Blueprint should be in progress. Some can begin
prior to this baseline (after both functional and technical
specs have been created), but many are reliant on base
configuration to be in place before the development can
begin. Managing the interdependency of configuration and
development can be quite challenging. This is another
reason that less development in a project translates to lower
the risk to the timeline.
In order to keep the project as close to standard SAP as
possible, every use of a developer should be closely
examined, even if the development is part of a user exit.
Solutions that involve configuration only are by far the
safest and most expedient. Anything that involves a
developer entails more risk and is less expedient. At the
mild end of the development spectrum are user exits or
other "mini" modifications, solutions that are slightly risky
include Z objects of any sort (other than Z transactions that
are low risk), to the core modifications to SAP code which
should never be allowed because they are high risk,
cumbersome, and if you do enough of them will render the
system impossible to upgrade in the not so distant future.
If you are able to keep the project close to a pure vanilla
implementation you will benefit from a smaller more agile
team because you'll require not only less technical folks,
but potentially less functional staff members because you
will not have the plethora of functional and technical
documents that have to be developed. You'll also have
less time spent with the functional team explaining the
Mitigating Risk in Large SAP Projects
104
solution to developers and you'll avoid the iterations of
testing that arise from development. The functional team
can cut this out entirely if they can simply configure a
solution using what is available in the SAP Implementation
Guide. (Note: check the glossary to see what the
Implementation Guide actually looks like.)
Also: if you have been incredibly vigilant in preventing
custom development since the scope of the project was first
devised you will also benefit from avoiding the whole
debate concerning off-shore versus on-site development.
While off-shore development has financial benefits, it
carries more risk than using development resources that are
on-site. Communication is just one element that suffers
when resources are located outside of the country.
The other thing to keep an eye on is the integrity of the
golden development client. Take steps to ensure that no
one posts data into the golden client so that certain
configuration settings are not locked in. As mentioned
earlier there are certain settings that cannot be changed
once there is transactional data posted. A misstep in this
area could cost many lost days of your team's time.
Unfortunately I am not aware of a way to prevent this using
either SAP system settings, or security settings. The only
way to prevent this is through training, communication, the
use of seasoned resources, and vigilance.
During the realization phase the only type of testing
undertaken by the team is unit testing. Unit testing is
informal because there could be several iterations in a day,
and there is nothing to be gained by burdening the
Mitigating Risk in Large SAP Projects
105
functional team with unnecessary paperwork. See the
testing section for more information on this type of testing.
The configuration person, with his or her expert advisor
looking over their shoulder, creates the configuration in the
golden client. Then the go to the unit test client and import
the transport that the change was assigned to using the
transaction code SCC1. The screen will look something
like this:
Safeguarding the integrity of the unit test client is
somewhat similar to that of safeguarding the golden client
in that there is no way to force compliance through either
system settings or security settings. You'll have to rely on
training and communication.
Of the two, the integrity of the golden development client is
the greater immediate risk. Encountering an unchangeable
configuration setting due to transactional data having been
posted can have immediate and significant negative
consequences to the project, whereas the effect of the unit
test client getting out of sync with the golden client
configuration is likely not be felt until much later.
Mitigating Risk in Large SAP Projects
106
The progress of the realization phase should be easily seen
in the Requirements Traceability Matrix. Which
requirements have already been proven by unit tests, which
have not even been started? Once every item on the matrix
has been successfully unit tested you'll be ready to move on
to integration testing.
As mentioned in detail in the testing section, the purpose of
the integration test is to validate that the system works as
designed as data flows across modules. It is more than a
string of transactions pieced together however (which is
referred to a as a "string test"), it is a carefully controlled
test using scripts that are based on real world cradle to
grave business scenarios that have been put together in
conjunction with the business. Inherent in this test is a
string test in that the functional team has to ensure that
every transaction code configured is contained within these
scripts. These scripts will serve a dual purpose, not only
will they be used in the functional team's integration test
but they will also be used in the user acceptance test which
will follow the successful integration test.
Any interfaces or external bolt-on programs will also need
to be included in the integration test scenarios, as will any
Z transaction codes. If you have not been able to keep the
program to vanilla SAP you'll also have to ensure that Z
objects (like Z Programs and Z tables) are included in the
scope of the test. Core modifications to code will not
require testing because implicit in this book is that you
have not allowed them (because as has been mentioned
many times … they should never be allowed). Nor have
Mitigating Risk in Large SAP Projects
107
you allowed the construction of an entire module created
using extensive ABAP programming.
The details of Integration Testing are discussed extensively
in the testing section. Suffice it to say that there will be
multiple rounds of testing until all defects have been
eliminated. Following the last test cycle the leaders of
every functional team involved in the script should sign the
scripts to indicate they agree that the script has passed
successfully.
Immediately following the integration test is the user
acceptance test. This is also discussed at length in the
testing section. In general, the same scripts used in the
integration test will be used in the user acceptance test.
The key difference is that users, who are not part of the
SAP project team, are brought in to do the testing and are
expected to initial every step of every script. Following
their testing, the representative of the business who has
been given the authority must sign off. Just like the
signatures requisite for moving from the blueprint phase to
the realization phase, signatures on the user acceptance test
are required on every script before the project can progress
from the realization phase to the project preparation phase.
Do not be afraid to put the entire project and all of its
workers, on hold while you await the signature. The
pressure on the signatories to sign off must be immense (as
must the pressure on your team to address the concerns that
prevent them from signing). You cannot afford to move
into the next phase with loose ends that tend to become
tethers that can cause the project bigger problems down the
road.
Mitigating Risk in Large SAP Projects
108
Sign off on the User Acceptance Test scripts is to the
Realization phase what the approved Business Blueprint is
to the blueprinting phase: it is a milestone indicated that the
key deliverable of the phase has been approved. There
may be tasks on your work breakdown structure that
overlap between the phases, but these two approvals mark
the end of phases two and three of your ASAP based
project plan. If you are using a different project
methodology, the names of the documents and phases may
be different, as may the phases that certain activities reside
in, but the activities themselves will remain (as will their
criticality to achieving the end state).
One final word on the realization phase: because the actual
construction of the system as well as the testing and
approval of the system reside in this phase, this should
occupy the greater part of the timeline than any other
phase.
Risk Inherent in the Final Preparation Phase By the time you get to the Final Preparation phase much of
the risk has already been incurred or diffused. If you got
the requirements of the blueprint phase right, built an SAP
system as close to vanilla as possible while staying faithful
to the requirements; if your system was completely built
from the available settings in the Implementation Guide; if
you ran an effective integration test containing all of the
transaction codes and utilizing real-life scenarios and
eliminated all of the defects, and if all of the critical
documents have been signed off on by the business,
including the user acceptance test, then you are on the path
that leads to a successful SAP project.
Mitigating Risk in Large SAP Projects
109
Still there are some activities that are critical to the success
of the project, though they tend to be somewhat "softer"
and most involve change management. One of these is
training. The specifics are discussed at length in the
Training section. Suffice it to say that training must be
targeted and timely. You do not want people unable to do
their job on go-live day.
Other change management activities, like those of the
communications plan must continue to be executed to
ensure the highest level of acceptance for the major
changes that are coming when the change-over to the new
SAP system is completed.
There are also a few not so soft activities whose completion
is important to the Final Preparation phase. One of these is
the go / no-go decision that is a milestone in the latter part
of the phase. If you have handled everything right to this
point you'll undoubtedly be going live. If you have not,
and the risk items are of a highly significant nature, do not
go-live. The pressure to go live when significant risks
abound, or when significant defects are known, is often
immense. The implementation partner may lose a lot of
money if you do not go live, the senior people involved
may not want their reputations damaged by not going live,
or you may be implementing a module that absolutely must
go live on a certain date. Such factors can make the idea of
not going live very unpalatable.
Most SAP projects, however, go smoothly enough that the
go / no-go is virtually a formality. There is no question
that you are going live.
Mitigating Risk in Large SAP Projects
110
And now that you are going live, the cut-over plan becomes
the key tool of coordination within the project. The plan
will consist of many steps, many of which must be
performed in the order they appear on the plan.
As part of this plan, weeks ahead of go-live you'll be
running programs to load all of the necessary master data
into the SAP Production system. First you load the
account assignment objects: general ledger accounts, cost
centers, internal orders, fund centers, work break down
structure elements, etc. After the account assignment tables
have been loaded, you'll load the vendor accounts,
customer accounts, and material masters. These loads may
range from a few master records, to millions. The size of
the data load may determine who actually executes the
loads.
Remember how you had your functional team members
trained to build and execute their own Legacy System
Migration Workbench (LSMW) programs? For anything
less than say 100,000 records your functional team has
created and run the loads themselves. This means that the
steps of creating functional specs, technical specs, and
trying to make a developer understand what every element
of the conversion program means was unnecessary since
the functional subject matter experts were able to do the
conversions on their own.
For the largest of data loads (over 100,000 records for
example) a technical person and a functional person had to
collaborate to get the data loaded.
Mitigating Risk in Large SAP Projects
111
The majority of the conversion effort will be in the area of
master data, though there will be some limited transactional
data that will be required. In keeping with the conversion
strategy chapter there will be no historical data loaded. An
example of transactional data that may need to be loaded is
open purchase orders. However, the cut-over plan will
involve steps to limit the amount of transactional data that
needs to be loaded. An example of this: having the
business close all open purchase orders prior to going live.
The cut-over plan will have dates that certain activities
must cease (for example the posting of invoices in the old
system). Several weeks before the official go-live things
such as the day-to-day entry of manual invoices will have
already been transferred to the new SAP system.
All of the dates and activities will have been carefully
orchestrated with the cut-over plan culminating in the
actual day of go-live, which will be after cut-over weekend.
On cut-over weekend the final preparations will be
executed: things like setting the indicator in certain
modules to "productive" and setting defaults involving
dates.
Risk Inherent in the Go-live and Support
Phase The Go-live and Support phase has the least inherent risk of
the five phases. By this time all of the practices of the past
year or so, whether good or bad, will have created the
environment that you are in.
Mitigating Risk in Large SAP Projects
112
In fact, most SAP projects that will fail will have done so
without actually going live, because the majority of the
opportunity for failure exists in the Realization, Business
Blueprinting, and Project Preparation phases (in order of
greatest inherent risk to lowest).
Final Word on the Relative Risk of Each
Phase To reiterate, in an SAP project the opportunity for failure
stems primarily from decisions made in the Realization
phase, followed by the Business Blueprinting phase and the
Project Preparation phases. By the time the user
acceptance test is executed (or not executed when it should
have been) the risk profile of the initiative has pretty much
been decided. Only a few activities that mitigate or
contribute to risk exist after the end of the Realization
phase: one example is training.
Failures that occur just before or just after go-live can
usually be traced back to decisions made far earlier in the
project. Examples of such decisions are:
Mitigating Risk in Large SAP Projects
113
The decision to convert massive amounts of
historical data leads to a break down in the financial
integrity of the system after go-live.
A lack of accountants on the project available to
reconcile data leads to convergent invoices that do
not tie back to the source documents of the Contract
Accounting module and the Sales and Distribution
module resulting in millions of dollars lost after go-
live.
Out of control development allows for a module to
be completely developed using custom ABAP code.
Several months after go-live the processes suffer a
massive failure and the development has to be
abandoned. A decision is made to roll back to the
old system.
Many departments cannot operate on the day of go-
live. Their users do not have access to the system,
nor have they been trained. User level
dissatisfaction causes the go-live to be abandoned.
The project collapses under the weight of a big-
bang release. Deploying an SAP system with most
modules of logistics, financials, and human resource
areas of the SAP Enterprise Central Component in
scope along with Business Information warehouse,
Customer Relationship Management, and a call
center to 58 countries all at the same time
completely overwhelms the project team. Issues
with the project cause the company's stock price to
plummet causing the project to be shut down.
The implementation partner firm is fired halfway
through the realization phase as it become apparent
Mitigating Risk in Large SAP Projects
114
to the business that they do not have enough people
with the skills necessary to help the project succeed.
The implementation partner's approach of loading
the team with cheaper resources from overseas
backfires on both them and the business, causing
both millions.
The business enters an agreement whereby the
implementation partner will be completely
responsible for all aspects of the project. Other
than a few management types, the business will
supply no resources. All testing will be conducted
by the partner, including acceptance testing. After
the project is live, the business realizes that the SAP
system does not meet a significant portion of their
business requirements. They file suit against the
implementation partner.
All of the failures above are based on real life examples,
and they all stem from decisions made well before the final
phase of their respective SAP projects.
The key point here is that the least risky of the five stages is
the final one: go-live and support. The second least risky
phase is the second last one: the project preparation phase.
In conclusion: vigilance in keeping the risk profile low in
the first three phases of the project, especially the Business
Blueprint and the Realizations phases, will pay off as the
project progresses into the final two phases. Do the first
three phases right, and the go / no-go decision will be a fait
accompli , and a successful go-live will be all but
guaranteed.
Mitigating Risk in Large SAP Projects
115
Risk Management
for SAP Projects
“Management must manage!” ~ Harold Geneen
Mitigating Risk in Large SAP Projects
116
Risk Management for SAP
Projects
The Risk Management Plan A specific deliverable of any large SAP project should be
the risk plan. The risk plan should document as many
risks as possible and categorize them in terms of magnitude
and relevance to the project along with a rationale for the
ranking. The plan should also include risk mitigation
strategies for each along with a monitoring and reporting
system to track the risks.
At least one of the people authoring the risk plan should be
an expert in both hands-on configuration and SAP specific
project management, with several successful SAP projects
under their belt operating in both capacities.
After the plan has been approved the monitoring and
reporting system should be implemented and the status
actively communicated to all of the stakeholders including
the steering committee and the project sponsor.
Mitigating Risk in Large SAP Projects
117
Change Management
Every SAP project is an exercise in change management.
Often this aspect of the project can be more important than
the technical aspects of the project, at least in the early part
of the lifecycle.
This is because people inherently do not like change. They
know how to work the present system, they understand
their job, and they fear the unknown: will my job even exist
after this new SAP system is implemented, or after this
change to our present SAP system?
Change management will help these people with the stress
that they experience, but change management also involves
protecting the initiative itself, which means that the project
must have a "guardian angel" looking after its interests
from up above.
The Guardian Angel Effective change management begins with leadership.
Does the project have the firm backing of an executive in
Mitigating Risk in Large SAP Projects
118
the upper most echelon of the organization? If it does, and
the person is adamant in their support of the project, it has a
much better chance of succeeding.
Communication Communication is the key to helping people understand the
change that is coming and how it will affect them.
Communication is two-fold. Firstly it involves macro
communications using elements such as a newsletters,
email updates, and posters.
Secondly, communication is also at the micro level. The
communications team must analyze the changes at the
lowest levels of the organization. Will some people lose
their jobs? Will some staff members need retraining or a
new assignment within the organization?
Once the team knows the effect of the initiative they can
take steps to mitigate the effect on the workers involved.
Mitigating Risk in Large SAP Projects
119
Participation
The participation of the organization is paramount in
ensuring the success of the project.
The general model of an SAP implementation is that every
member of the implementation partner team (usually an
outside company contracted to assist the company actually
installing or making changes to its systems). Often,
however, the subject of the SAP implementation does not
have people to place on the project, does not have high
quality people to place on it, or cannot find people within
their organization to place on the project. All of these
situations pose a risk to the project.
The risk of not having adequate personnel on the project
from the subject organization is primarily to the
Blueprinting effort. This is due to the fact that experienced
Mitigating Risk in Large SAP Projects
120
and knowledgeable staff members are experts in the
processes of that organization with an intimate knowledge
of the as-is process.
SAP is highly configurable, with the ability to support a
multitude of different ways of perform a business process
such as procure to pay. Outside consultants who are
experts in what SAP is capable of are indispensible, but
they do not have the inherent knowledge of the "as-is"
business process of the organization. They also do not
have the contacts within the organization that the internal
subject matter expert has. Thus each SAP expert must be
partnered with an expert from within the business. This
leads to a better design, and also reduces the risk of a bad
design.
Mitigating Risk in Large SAP Projects
121
Training There are several forms of training that are utilized in an
SAP project. One is team training, meant for members
who are actually going to be involved with the
implementation. Another is end-user training. There is
also executive training meant for those who will not be
hand's on in either the implementation, nor will they
participate in the day-to-day maintenance of the system;
they will however need training to understand at a high
level how SAP works so that they can better manage the
organization.
Implementation Team Training
Training for the implementation is usually centered on the
members of the organization installing or materially
changing SAP, since outside consultants are expected to
possess expert level knowledge already. There are times
when the entire team must be trained together, but this is
the exception.
The main members of the organization will be sent for
training appropriate for their area. Their training may
begin with a high level overview course, followed by
introductory level courses in their module. After the
introductory level course is complete the staff member will
have the prerequisite for intermediate courses, and
following that they will have the prerequisite for advance
level courses. The intermediate courses may have some
light configuration involved, whereas advance courses have
in-depth configuration involvement.
Mitigating Risk in Large SAP Projects
122
For example, the team leader representing the subject
organization for the Accounts Payable area may start with
the high level course "Introduction to SAP" (which
involves no configuration), followed by intermediate
Accounts Payable course where the participants will enter
the configuration panel (called the Implementation Guide
or "IMG" for short) to make some very basic configuration
changes.
In the advanced course the participant will focus almost all
of their energies on configuring the Accounts Payable
module of SAP.
The Accounts Payable Team Leader (internal from the
business) is now ready to lead the implementation of SAP
with the assistance of his or her SAP Accounts Payable
system expert.
End-user training
End user training is usually a far more daunting task than
project team training. Often the amount of people to be
trained is quite high, as the intent of such training is to
ensure that everyone that will be "hands-on" with the
system has the knowledge to perform their tasks as soon as
the system goes live.
Depending on the amount of people that will be affected by
the implementation an entire team may be devoted just to
end-user training. After a needs analysis, there will be a
complex schedule put together, with participants tracked to
ensure that they were trained.
Mitigating Risk in Large SAP Projects
123
Often times the security team will piggy back on the work
of the training team to ensure that only those who have
been trained have access to that part of the SAP system.
Such a strategy is a win-win for both teams as it gives the
training team a control point to ensure compliance, and
helps the security team determine how to lay out the
security.
Finally there is executive training. The vice-president of
finance does not need to know how to configure SAP, nor
does he or she need to know how to enter an invoice.
They do have to have a high-level understanding of how
SAP works, and thus must be trained with that in mind.
Proper training, as part of a comprehensive change
management strategy, will help the organization achieve
the goals of the SAP implementation (while also helping to
mitigate the risks associated with bad implementation
decisions, users who are not prepared to work with SAP,
and executives who do not have an appropriate high-level
understanding of SAP to make their decisions).
Mitigating Risk in Large SAP Projects
124
Project Policies
In addition to the normal policies governing mundane
things like work hours, dress code, etc. the policies set by
the project management office should specifically address
the critical risk areas that the project will face. The
policies should be documented at the outset of the program
to help control the implementation. Among the policy
items:
Core modifications – define what constitutes a core
modification, and the rigorous process for getting
them approved. Developer keys are required to
make a core modification. Such keys should be
strictly controlled by senior project management
office staff.
All development should be subject to a peer review.
It should be clear from the process documentation
whether a core modification is involved.
Work schedule – If you want to attract the best
consultants, ensure that the project maintains a four
day onsite schedule so that they can maintain a
home life. See the Resource section for a
discussion of working conditions.
Health policies: people who are contagious should
not be at work. If possible mandate that every
member of the team must be immunized against the
influenza.
Mitigating Risk in Large SAP Projects
125
Who configures the system?
o This is critical point for members of the
project team who belong to the actual
business (as opposed to the implementation
partner). Generally speaking the members
of the implementation partner will be
inclined to do the configuration themselves
in the interest of expediency. Unfortunately
this leaves the members of the business
without a solid knowledge of how
configuration works. In your project the
Security team should provide configuration
access to the golden client only to the team
members of the business. The members
from the implementation partner only have
display access to the golden client. They do
have full access to the sandbox, however.
At the end of this project all configuration in
the golden client will have been performed
by members of the business. Hence the staff
members who have to support SAP in the
years after go-live have a solid
understanding of how it was configured.
They did this configuration of course, with
their expert advisor sitting side-by-side with
them. No golden client configuration
should ever be done without the business'
staff performing it (with their SAP
consultants sitting next to them).
Mitigating Risk in Large SAP Projects
126
Project Personnel
Acumen of key project resources
SAP is often referred to as an off-the-shelf ERP software
package. Unfortunately this gives the impression that you
install it and it is ready to run. That, of course, is not the
case. It first has to be configured. The options in
configuration are myriad, which is one of the many reasons
for its popularity. It is scalable, processes are selectable,
and in most cases the processes can be changed as time
goes on through the configuration panel. While this
configurability makes SAP powerful, the process of
implementing it is very reliant on personnel who know
what the inherent capabilities are of the system.
Consequently it is extremely important to find highly
experienced experts in the modules that you are
implementing.
If you do not find experts with the degree of acumen
required for an SAP module it is possible that the people
you bring on board to the project will not have the breadth
of knowledge necessary to lead their area from blueprinting
(where they have to design the system on paper), to
realization (where they actually lead the configuration
effort), and go-live.
Mitigating Risk in Large SAP Projects
127
If you do not find experts with the degree of acumen
required it is possible that functionality will be missed, or
not configured properly. Certain processes will work
awkwardly or not function properly at all.
Generally speaking the best people to lead a module come
from a functional background, have in essence led a
department that carried out the function of that module in
their career prior to SAP, have been formally trained in that
module (i.e. have a certificate), and have many years of
experience with multiple go-lives under their belt.
Appended to the names of the best experts is usually a
CPA, MBA, P.Eng, MD, LLB, etc.
If you are on the business side, hiring an implementation
partner, most of your experts will come from their talent
pool. Unfortunately their talent pool may not be as deep as
you are led to believe in the contract negotiation phase.
Consequently it is important that you have the right to
interview and refuse any candidate they wish to onboard.
Interview their people before they join your team. Get
them to summarize their experience with the module and
their training. Have someone from your team who is an
expert in SAP to ask interview questions, even if you have
to have a separate contract with such a person (e.g. an SAP
quality assurance consultant).
Throughout this book we will suggest controls which will
alert you to the possibility that you do not have the
strongest resources as the subject matter experts of an SAP
module and safeguard you against some of the things such
resources might push the SAP system towards due to their
Mitigating Risk in Large SAP Projects
128
uncertainty about what is possible in standard SAP. Your
project will be susceptible to this because finding SAP
module experts is extremely difficult.
So, attracting and retaining good personnel is critical to
implementing and maintaining an SAP system with the
lowest possible risk.
There are many strategies to consider, but one of the first
things to keep in mind is that the market for experienced
SAP experts is very sparse. Finding them is difficult as is
keeping them. Expect your people to be constantly
recruited by head hunters. Consequently there are several
things to consider with respect to project personnel. What
follows are a few tips that may help mitigate the long-term
risk this poses to your project.
Hire or Contract Out? Hiring an SAP expert can be very difficult. Six figure
salaries are often not enough to lure them into the
organization.
Developing junior people into SAP experts can take years,
and once they attain proficiency they are liable to jump to
another firm for considerably more than you are paying for
them.
Hiring a firm to provide resources as required can be quite
cost prohibitive as you have to pay for their mark up on the
resources.
Hiring offshore firms can be frustrating as well as the
communications is difficult both due to language issues as
Mitigating Risk in Large SAP Projects
129
well as geographic issues. Furthermore it is possible that
such hiring may lead to unfavorable tax rates down the road
as governments attempt to battle what they see as an
outsourcing problem.
Assuming that you do not have unlimited funds, the issues
surrounding personnel are so complex that I cannot offer a
cookie cutter approach to this issue. The best I can offer is
that you should assume that you will have great difficulties
in obtaining skilled people and dynamically adjust your
strategies as you progress through the implementation.
Utilize a multi-pronged approach to resources: Have a few
junior people that you can develop over time, hire skilled
SAP people whose salary needs are not too high, but be
prepared to give them raises and bonus' every year, and use
a website like DICE.COM to contract directly with very
experienced SAP consultants at a rate far lower than what
consulting firms charge for similar resources. The final
avenues should be the use of external staffing firms and
lastly offshore firms as these are prohibitively expensive
with respect to the former, and involve lesser quality
resources in the case of the latter.
Develop Your Own SAP Experts Finding SAP expertise is difficult and when you find,
prohibitively expensive. For long-term risk, SAP expertise
is a definite area you should be concerned with. Expert
SAP resources are also very mobile, and a favorite target of
head hunters. If you have a finite budget, you need to have
a strategy that includes SAP expertise incubation.
Mitigating Risk in Large SAP Projects
130
There is no better opportunity to incubate new SAP talent
than during an SAP implementation, especially a "green
field" one. Re-implementations and partial
implementations can also be very powerful incubation
tools. Upgrades and other types of major SAP projects
are less effective for developing new SAP talent.
If you are in an implementation or partial implementation,
and have an interest in the availability of future SAP
expertise, do not squander this opportunity; there will never
be a better opportunity until the next such project you are
involved with (assuming you will one day be involved in
another such project).
For starters, do not allow the present SAP experts to have
configuration access to the golden client (the starting point
of configuration that is meant to be migrated to
production). The actual authors of such configuration
should be those people that you want to develop into SAP
experts. The role of the consultant experts is just to advise
members of the business on how to configure the SAP
system. The experts are the teachers; members of the
business are the students learning how to configure SAP.
The experts still have the final responsibility.
Consequently only they should have the ability to release
the transports that contain the work of the more junior
personnel (using transaction code SE10).
The business' configuration people should produce
documentation as they do configuration. It should also be
clear that the business staff member is not allowed to do
configuration without their SAP advisor/expert next to
Mitigating Risk in Large SAP Projects
131
them. Both the expert consultant and the member of the
business who will configure SAP should sign a document
stating this so that there is a clear understanding of roles
and responsibilities.
It is also the duty of the SAP expert to ensure that
configuration is moved to the unit test client (via
transaction code SCC1), and that unit testing is properly
conducted. That testing should be conducted by the junior
SAP person with the expert overseeing the test.
Spending extra time to develop and enforce this process is
well worth it if you have an interest in developing SAP
expertise or will have to manage the risks that are posed by
a lack of SAP expertise.
Redundant Personnel Expect attrition. Expect that personnel will come and go.
Some of these staff members will be critical to the project.
They may be subject matter experts that are difficult to
find. Constantly review the human resource weak points.
Which resources are critical, which are most likely to leave,
which have low morale. Have an overall profile and
manage the risk by using a variety of tactics: Have
contractors ready to go, have junior personnel that are
being developed to take over, ensure that the critical
experts are effectively transferring knowledge to others.
Do not underestimate the value of SAP experts and their
ability to quickly move on from your project to another that
offers them more money. Be prepared!
Mitigating Risk in Large SAP Projects
132
Employ at least one intermediate level accountant to
reconcile critical financial business processes. At least one
project failure that I am aware of partially failed because
project management did not realize that the convergent
invoicing totals did not reconcile to the source documents
in the Sales and Distribution modules and Contract
Accounting modules.
Loss of key personnel I'll repeat this one more time: SAP experts are in great
demand, so do not underestimate their mobility. Be
prepared to lose key resources along the way, and have a
plan to deal with it. The preceding strategies will help
guard against this risk.
Project Location A number of factors should be considered when choosing a
project location. Since the theme of this book is about
minimizing risk, we will focus ourselves in that area.
First off, the location should accommodate the entire
project team in one location. Splitting the team into
multiple locations reduces the quality of communications
between the team. Furthermore the team should all be
located in one "war room". No walls, no offices …. Just
one big room filled with a bunch of experts (both SAP and
business). There should be small break out rooms, but not
individual offices. It is critical that everyone can hear
what other teams are saying. Often a seemingly
unimportant comment will lead to a critical discussion
between two teams to discuss the integration of the system.
Mitigating Risk in Large SAP Projects
133
If a war room environment is not used, the opportunity for
such inter-team discussion is lost.
Furthermore, the war room should have good access to key
people who are not directly part of the team, people like
project sponsors, area directors, etc. This will lead to
enhanced communication. Great communication equals
less risk.
You will also want to create a healthy work place. You
cannot afford to have key people sick at key times. Offer
free flu shots onsite, have a fitness gym onsite, ensure that
the war room is properly ventilated and not over populated
(i.e. make sure the war room is big enough to accommodate
the maximum team size). Treat your people right, and
keep them healthy and happy. You need them!
Coffee! Do not make your team leave the office for it.
Supply it. Also consider supplying some food for those
who are working long hours, especially if restaurants are
not easily accessible after 5pm.
Mitigating Risk in Large SAP Projects
134
Daily Work Schedule If you want the best and most skilled SAP experts your
project should operate on a four day week. The typical
schedule for a traveling consultant is Monday to Thursday,
but consider a Tuesday to Friday schedule instead because
most statutory holidays fall on a Monday (which can throw
off your schedule).
Also consider offering your traveling consultants every
second or third week the opportunity to work from home.
This will help them with both their home life and their
long-term health, as well as create a happier work place.
Your project will also become the preferred project to work
on in the world of SAP, thereby allowing you to attract the
best talent and retain it.
Allowing a limited work from home option for traveling
consultants will also reduce travel costs (which can become
quite exorbitant). If you are involved in negotiating the
contract consider incorporating the limited work from
home option into it to reduce the costs of this SAP project:
even if the contract does not include the payment of travel
Mitigating Risk in Large SAP Projects
135
expenses, one way or another they will end up getting built
in.
To reduce the need to travel, ensure that everyone has and
uses the power of Skype to emulate the feeling that
everyone is together onsite. Great things are possible with
Skype, yet to date very few firms seem to have harnessed
the possibilities of this technology to aid the offsite worker.
Roll-on, Roll-off Having staff roll on to the project before their time is
disruptive and steals energy from an SAP project.
Keeping the team as small as possible, at all times, has
many benefits. It:
Saves budget
Allows team leaders to focus on the most important
tasks
Reduces space requirements
You do not have people wandering around trying to
figure out what to do
Better optics: the team looks more efficient
The on-boarding process itself is a time consuming one. If
you have a large team (20 or more) consider having a
clerical person whose job is to assure that each new arrival
on the project is properly briefed on the policies and
procedures of the project. The process can be time
consuming. Refer to the diagram below for some guidance
on the process:
Mitigating Risk in Large SAP Projects
136
On-boarding – Phase One (Project Prep)
Aside from the project managers from both the business
and the implementation partner side, the first recruits to the
team should be the SAP experts in the modules being
deployed, along with the experts from the business who
will assume team leadership roles. All of these personnel
should be functional. At this point there is no need for any
technical staff aside from one Basis expert who will lead
that aspect of the project.
The experts and the team leads should advise the project
managers as the plan, charter, policies, and strategy
documents are put together. The project managers are the
coordinators, not the experts.
Mitigating Risk in Large SAP Projects
137
As the first phase of the project progresses a change
management expert should be brought on board to advise a
change management lead from the business side (who has
also recently been on-boarded). The team is still a small,
tight, cohesive group. There is no confusion as to roles
and responsibilities, and no one is roaming the halls with
their hands in their pockets asking the productive people
how they can help.
Assistants will be brought on board to handle clerical
activities like booking meeting rooms and making sure that
there are enough office supplies.
As the second phase approaches the project management
team, with input from the business' functional team leads
and SAP experts, will on-board supplemental personnel for
the blueprinting effort. These people may possess SAP
expertise that is missing from the team, or be junior folk
who will produce deliverables such as documentation.
There will also be a determination as to who from the
business will configure each module, because the SAP
experts will only be advising these people from a position
looking over their shoulder. The people who you give
configuration access to must be those who are earmarked to
Mitigating Risk in Large SAP Projects
138
support the business long term as business analysts. This
SAP configuration experience is the best learning tool
available for knowledge transfer to the business. It must
not be squandered because these people who will support
the system may never get another opportunity to see how
the system is built (from the ground up) again.
The change manager (along with their advisor) will have
created a change management strategy document and a
plan. They will begin adding staff for communications,
organization impact, key stakeholder analysis, training,
etc., and some of these staff members will begin to on-
board towards the end of phase one.
As of yet there will be no one rolling off by design.
On-boarding – Phase Two (blueprint)
Phase two will see controlled growth in project staffing.
The functional teams will have been supplemented with
junior personnel and select SAP experts. The change
management team begins to ramp up as well. The Basis
team may have incorporated a new recruit or two just to
ensure some redundancy in this critical position, and to
provide an opportunity to train people from within the
business.
There is still one key component from the team that is
completely missing: the technical development folks.
If this was a perfect SAP project, there would be no need
for any technical folks. The functional team would
configure an SAP solution using standard Implementation
Mitigating Risk in Large SAP Projects
139
Guide settings that is a 100% match to the requirements of
the business.
Unfortunately I have rarely seen such perfection.
Usually there are at least a few interfaces to be built.
Often there are many interfaces, some user exits and s-
mods to code, and the odd Z-transaction to construct. At
the very least there will be SAP OSS Note Corrections that
require an ABAP programmer to implement. Projects that
are not diligent in controlling custom development will see
a plethora of Z-programs and Z-tables.
The bottom line is that there needs to be at least one ABAP
programming expert and one ABAP trainee from the
business side on most projects. Depending on the scope,
there could be many technical development folks on the
project.
The key take-away here is that they do not have to join the
project team until sometime during the second phase
(blueprinting). If the scope warrants it, the first technical
people to bring on board in phase two will be the business'
technical manager and their expert advisor from the
implementation partner. To bring on technical people any
sooner than this stage is unnecessary and not fiscally
responsible.
Mitigating Risk in Large SAP Projects
140
By mid way through the second phase the first technical
development people will be on board. This is essential
because toward the end of this phase there will be
functional specification documents produced by the
functional team and from these the technical team will have
to produce technical specification documents in preparation
for the programming to actually be performed in the next
phase.
At this point there have been no planned roll-offs.
On-boarding – Phase Three (realization)
As the system is being configured, the change management
team is on-boarding the personnel who will develop
training materials in conjunction with trainers who will
ideally come from the business itself. They will use the
blueprints of the second phase of the project to begin
designing the course work, as well as the eventual baseline
configuration to finish off their training materials. The
Basis team will have created a dedicated training client for
the training team that is a copy of the quality assurance
client created for integration and user acceptance testing.
Mitigating Risk in Large SAP Projects
141
Meanwhile the configuration team will have reached their
maximum size early on in this phase. Towards the end of
it the first roll-offs will begin. The roll-offs will include
highly specialized SAP experts, and junior functional
personnel who were brought on for tasks like writing
functional specification documents, etc.
Technical personnel will likely reach their maximum size
later in the realization phase and their numbers will not be
reduced until phase four. If you have been effective in
keeping this a vanilla SAP project as well as getting the
functional team to handle most of the conversions
themselves (using the Legacy System Migration
Workbench), the technical team was comparatively small
relative to the functional team. The Basis team will have
remained stable in size since mid-way through the second
phase.
Roll-offs – Phase Four (preparing for go-live)
With the final sign-off of the user acceptance test
completed, the fourth phase of this project has become
primarily a change management effort. Hence there may
be a few additions to the change management team, while
all other teams are shrinking or stable. This is because
configuration is complete, as is all development.
During the fourth phase conversion programs will be
streamlined, and the data scrubbed. This will be the
primary activity of the functional team who have been
trained in the Legacy Data Migration Workbench and are
able to handle almost all conversions. The largest
conversions (say those of over a hundred thousand
Mitigating Risk in Large SAP Projects
142
records), will have necessitated the addition of a technical
conversion specialist on-boarded at the beginning of this
phase.
The trainers will be finalizing their courses, and the first
students will attend courses about the middle of this phase.
Training will continue well into the final phase of the
project.
The primary deliverable of this phase is the execution of
the cut-over plan. Senior members of the functional team
from both the business and the implementation partner will
be placed in charge of formulating the plan and managing
it. Its completion will mark the end of the phase.
The entire SAP implementation team will have reached its
maximum size toward the end of the prior phase. From
this phase on the roll-offs will accelerate.
Roll-offs – Phase Five (Post go-live)
In the final phase of an SAP project there will be many roll-
offs culminating with the complete departure of the
implementation partner a few months after.
Mitigating Risk in Large SAP Projects
143
Because the system was completely configured by
personnel from the business (the implementation partner
did not even have configuration access to the golden
client), the business is able to support their own system.
Likewise, for any development and Basis: personnel from
the business are able to support the system because they've
been doing all the hands-on work since the beginning of the
project.
The last members of the implementation partner to leave
are likely to be a few of the module experts. Often they
will outlast even the partner's project managers. These
experts may even be contracted to support the
implementation long-term.
Conclusion
There are many reasons that it is prudent to actively
manage roll-ons and roll-offs besides the obvious financial
advantages. The team will be more streamlined and
cohesive. It will be more productive instead of being
Mitigating Risk in Large SAP Projects
144
smothered by the weight of too many resources. Optically
it will be much better for the implementation partner to
have resources that are truly needed at certain times rather
than standing around or cruising the internet out of
boredom.
Mitigating Risk in Large SAP Projects
145
Contracts This book will not attempt to discuss the nuances of
contract negotiations or all of the terms that should be in a
contract. It will look, however, at high-level contract issues
that can affect the risk profile of an SAP project.
Types of Contracts If you are involved in negotiating contracts, either on the
side of the integration contractor, or on the side of the
subject of the SAP implementation, you should be aware of
the risk implications of the contract you are negotiating.
There are three main types of contracts: fixed price, time
and materials, and staff augmentation. Time and materials
contracts can further be subdivided into time and materials
not to exceed. Each of these carries a different risk profile
depending on which side of the negotiation table you are
on. Because staff augmentation contracts do not take an
active role in the success or failure of a project we will
ignore that type for the purposes of this book.
The fixed price contract ties the integration firm to a set of
deliverables. The integrator must meet the schedule of
deliverables no matter what difficulties may arise. If it
Mitigating Risk in Large SAP Projects
146
takes twice the estimated hours, the integrator must eat the
cost. Consequently, this type of contract carries the
highest risk profile of the three types from the integrators
perspective. Still, the integrator may prefer such a contract
because they can build in higher hourly rates for their
services which they do not have to disclose.
From the perspective of the organization hiring a systems
integrator, the fixed price contract appears to be the lowest
risk of the three types. It does carry unique risks from this
perspective though. While it does limit the amount that the
project will cost, it also forces the integrator to cut corners
and economize as much as possible. Perhaps they cut out
the entire blue printing process; this is the stage of the
project where the SAP project team studies what the
organization does today (referred to as the "as-is") and how
it should be done in SAP (i.e. the "to-be). Cutting out this
part of the SAP project can and does happen. It even has a
derogatory name in SAP land: It is called a "package slam"
and it rarely ends well.
Time and materials contracts carry the lowest risk from the
integration firm's perspective, but they must disclose their
rates and are still responsible for deliverables and a
schedule. They cannot be driven into a position where
they lose money, which is obviously a benefit for the
integrator. From the perspective of the organization hiring
the integration firm the obvious risk is that the project can
go over budget. Less obvious is that this type of contract
mitigates certain risks, for example the risk of your project
becoming a package slam with inherent low quality.
Mitigating Risk in Large SAP Projects
147
The last contract form we will discuss is the "fixed price
not to exceed" type. From the integrator's perspective this
is the worst type of contract. They are still on the hook for
the deliverables, even if their delivery requires far more
consulting hours than expected and pushes them into taking
a loss on the project. Furthermore, they must disclose their
rates and the hours performed, so both are likely to be less
than they could be in either of the other two forms of
contract.
From the perspective of the organization hiring the
integrator, this type of contract has the same advantages of
the fixed price contract with the added benefit of being able
to control rates and hours charged. However, this type of
contract may encourage the integrator to perform a package
slam, the effects of which could be far worse than having a
project go over budget.
No matter what side of the negotiation table you are on, and
what type of contract ensues, understand the inherent risks
in it; then try hard to mitigate these risks, and build in
safeguards to your SAP project to manage that risk when
you haven't been able to completely eliminate it via the
terms of the contract.
Mitigating Risk in Large SAP Projects
148
Litigation Proofing This section is for the benefit of integration partners and
SAP consultants, because they are the ones who are more
likely to get sued if things go wrong. The subject
organization of the SAP implementation is rarely sued in
the process of installing or changing its SAP system.
Law suits do happen in SAP land. This is a very real risk
faced, especially by SAP integrators. I have been engaged
as a legal expert in several cases, one of which involved
hundreds of millions of dollars. At times I have worked on
the side of the plaintiff, while on other cases I have worked
with the legal team representing the defendant, so I have
seen how both sides work.
So let us assume that you will get sued one day.
With this in mind make sure that your rates incorporate a
risk premium and that you are well insured. Then
incorporate some policies that will aid you should litigation
result:
Lessons Learned – One of the "best practices" in SAP
project management today is to conduct sessions called
"lessons learned". In these sessions all of the players
gather (usually with staff from both the integrator and the
subject of the integration involved) do discuss what went
well, and what did not go well. The objective of this
exercise is continuous improvement. By discussing the
success and failure of different activities all parties
(especially the integrator) will "learn how to do it better".
Mitigating Risk in Large SAP Projects
149
If you are with the systems integrator (i.e. external
consulting firm) you are not being paid to "learn how to do
it better". You are paid for your expertise and implicit in
that is that you know how to do it right the first time. By
doing a lessons learned work shop, and "learning how to do
it better" you are admitting that you did not have the
expertise you said you had during contract negotiations.
So how does the best practice of conducting a lessons
learned session fit in to an SAP implementation? If you are
the integrator, IT DOES NOT.
In the discovery phase of a litigation case involving SAP in
the United States, thousands and thousands of pages of
evidence will be put forth for examination. What is one of
the first things that a legal team will search for among all
this information? The answer is anything with the term
"lessons learned" in it.
Lessons Learned are an admission of guilt and will be used
if a project goes awry and litigation ensues. Emails, notes,
minutes of meetings, and anything else related to Lessons
Learned workshops and meetings will be scrutinized.
Talk in person, don't write an email!
Everything written in the course of an SAP project,
including emails, is discoverable. If things go to litigation
and you do not want something brought up during a trial,
DO NOT WRITE IT DOWN, AND DO NOT WRITE AN
EMAIL ABOUT IT. To discuss issues that may result in
litigation, use the phone, talk in person, or use Skype to
discuss. Do anything except write it down!
Mitigating Risk in Large SAP Projects
150
When you verbally discuss something it cannot be
uncovered by the search of a database of thousands of
emails. It cannot be discovered by sifting through notes.
Furthermore, in the unlikely event that it is somehow
discovered, it is subject to recollection and interpretation.
Incorporate Litigation Proofing Sessions into Team
Meetings
Do not label meetings with suspicious subjects like
"litigation proofing", but incorporate such discussions
(verbally) in your internal integration team meetings while
onsite at the project. Having the entire team on the same
page with respect to litigation proofing could save your
firm millions of dollars down the road (and perhaps even
save the firm from being bankrupted by litigation).
In closing, if you are a member of an integrator, do not hold
lessons learned workshops; do not take notes concerning
contentious issues, and never send emails about them. Use
verbal methods of communication about these issues, and
make sure the entire team understands these rules by
incorporating their discussion in team meetings.
Mitigating Risk in Large SAP Projects
151
Contract Clauses
Lastly I leave you with a number of clauses to consider that
will help mitigate the potential risks you incur when you
sign on to be an implementation partner:
1. Vanilla SAP will be implemented – A "vanilla"
SAP system is one where only standard SAP
processes, configurable in the Implementation
Guide of the SAP system, will be implemented.
Stipulating that the project will employ vanilla SAP
ensures that custom development, in the form of
core modifications, Z programs, and Z tables, will
be held to a minimum. The closer the project is to
a true vanilla version of SAP while still meeting the
business requirements of the organization, the
closer it is to encompassing the lowest long-term
risk.
2. Where the project strays from vanilla SAP, the
work will be performed under special task orders
that will be on a time and materials basis with no
maximum. Non-vanilla solutions should require
sign-off of both the most senior implementation
partner representative and the project sponsor.
Such a high-bar will ensure that only the most well
thought out and critical custom development objects
will be realized. This approach also reflects the
fact that such solutions encompass a higher degree
of risk than any that employ standard configurable
SAP processes.
3. Ensure that the contract precludes events that could
significantly change the environment and put your
project at risk. One such event is a data center
Mitigating Risk in Large SAP Projects
152
move. The data center environment must be stable
throughout the implementation.
4. If you are on the business side, contracting with an
implementation partner, it is important that you
have the right to refuse any candidate they wish to
onboard. Interview their people before they join
your team. Get them to summarize their
experience with the module and their training. It is
especially important to the success of the project
that their SAP module experts actually are of that
caliber. Have someone from your team who is an
expert in SAP in their own right to ask interview
questions and give you an opinion on the partner's
people, even if you have to have a separate contract
with such a person. Also consider incorporating
penalties into the contract that will be incurred by
the implementation partner if they fail to find an
acceptable SAP expert.
Mitigating Risk in Large SAP Projects
153
Internal Controls Now that you have successfully negotiated a contract and
mitigated risk to the greatest extent possible prior to the
beginning of this initiative, lets incorporate some internal
controls to minimize some of the inherent risks of an SAP
project that still remain.
Internal Control Structure As in every good internal control model, there should be a
hierarchy of approval levels within this SAP project to
control its risk exposure. At the highest level there should
be a steering committee made up of senior members of both
the integration firm and the organization that is having SAP
changed or installed. The project sponsor (a high ranking
executive of the business) has veto or approval authority
beyond even that of the steering committee.
Below these two structures sits the senior project manager
of the endeavor. If an outside integration firm is involved
there should be two such individuals: the internal project
manager and the integration firm's project manager.
Below the senior project manager is the manager of
development, the manager of change, and the manager of
the functional team. Just like in the case of the senior
project manager, there are most likely two of each of these,
one from the business and one from the partner.
The lowest levels of approval are those of the team leads
and/or the leaders of each business process or SAP module.
Again two for each team (a representative of both the
business and the integrator).
Mitigating Risk in Large SAP Projects
154
Once the structure is in place, the policies governing the
level of sign off for each type of change must be set forth in
the project policy document.
Core Modifications Among the many goals of an SAP implementation should
be the target of zero core modifications. From a technical
standpoint, core modifications are the source of greatest
risk and the controls to prevent them should be very strict.
First and foremost, a request for a development key from a
non-ABAP developer should require the approval of the
senior most member of the project team. Such a request is
a red flag that a consultant is attempting to perform a core
mod. The modification may be a "mini-mod", but it must
still be carefully examined by senior project management.
Furthermore, if it is determined to be a significant core mod
(rather than a mini mod) it should require sign off from the
steering committee.
Controlling the ABAP development team is not quite as
easy as the functional configuration team because the
nature of their work necessitates that they have a developer
key. The key to identifying and thereby controlling core
modifications that may stem directly from the ABAP team
is the peer review.
At the top of the peer review document it should ask in
bold capital letters if the change involved any core
modifications. The question could be structured like this:
"Does this change involve the inclusion of custom code
into the standard SAP code that was not produced by SAP
Mitigating Risk in Large SAP Projects
155
nor made possible by means of a user exit? If the answer is
yes, approval from the steering committee is required"
A clear and simple definition of what constitutes a core
modification also needs to be made on this document.
Below is one possible definition:
"A core modification is the inclusion of custom ABAP
code into the natural code of the SAP product that was not
created by SAP, nor made available through a user exit.
This does not include custom Z transaction codes, but does
include Z tables and Z programs that were not made
possible via a user exit". The inclusion of Z programs and
Z tables expands the normal definition of what constitutes a
core modification, but when utilized to replace standard
functionality within SAP they have the same (and
sometimes more) impact as a conventional core
modification.
The above is a suggestion only. You or your staff may
have a better definition. The critical distinction is that a
core modification involves code that was not written by
SAP and not provided for by a SAP user exit.
When assessing core modifications a distinction must also
be made between core modifications to processes within
the core SAP Enterprise Central Component (for example
procure to pay) versus simply making a core modification
to a standard report. The former is far more critical than
the latter is, however the better practice for the report is to
copy the standard into a "Z" version of the same report and
attaching a "Z" transaction code to it. That way neither
will be overwritten by an upgrade, and you have not
Mitigating Risk in Large SAP Projects
156
overwritten the standard code of SAP for the report with
your own code.
Control over mini-modifications As previously mentioned, mini modifications are those
changes to native SAP code that were either written by
SAP (and perhaps offered to the project team via the SAP
OSS customer support system), that involve S-mods and C-
mods that are simple things such as changing the label of a
field to read "Department" instead of the standard SAP
language, or user exits where SAP has made it possible to
easily incorporate your own code without effecting the
overall integrity of a process within SAP.
The most important consideration here is that what
someone calls a "mini-mod" may conflict with what senior
management consider a "mini-mod" and may be more
appropriately deemed a core modification by the latter.
Therefore the level of approval must be that of the senior
managers of the project. They are responsible for
escalating the proposal to the steering committee if they
think it is more appropriately deemed a major core
modification. The senior managers will also be held
accountable if such a change slips by them.
Therefore on the second line of the peer review there
should be a clear and concise question meant to identify if
this is a "mini-mod". The question could be structured like
this:
"Does this change involve user exits, s-mods, c-mods, Z-
tables, or Z-programs? If it does, approval from the senior
project director is required."
Mitigating Risk in Large SAP Projects
157
The wording of the question should be clear enough to
capture all possible core modifications, even if the
functional and technical folks do not consider them as such.
Bad Design and Configuration A poor design and bad configuration are difficult to control
directly. The members of the team who have access to the
Implementation Guide can do whatever they want in the
development environment if they have access to it. Apart
from business extensions that may need some
authorization, the team can turn on and turn off
functionality, alter functionality, and even change the
functionality of other modules.
The only way to control the design and the ultimate
configuration is indirectly, through the blueprinting
process, via internal controls, and then downstream through
the testing process.
Blueprinting is a critical part of the project where the as-is
state is carefully examined; not to replicate it in SAP but to
determine the business requirements inherent in it. Once
these business requirements are determined the "to-be"
state will be defined that will spell out how each
requirement will be met in SAP. There will usually be
some gaps that also have to be discussed in the blueprint.
Once the blueprint is completed it must be signed off by the
person in the subject organization who is responsible for
the process. Once their signature is obtained it should be
signed off by the project sponsor.
Mitigating Risk in Large SAP Projects
158
Blueprinting as outlined above is a common practice in an
SAP project. Less common, but just as important, is the
requirements tracking matrix.
A requirements tracking matrix (RTM) is a listing of every
individual requirement and a brief statement of how it will
be accommodated (per the blueprint). Each of these lines
has a space for the team leader from the business to sign
when it has satisfactorily been met in the SAP quality
assurance system.
The opportunity for the requirement to be signed off on is
during the unit test of the functionality. This unit test will
also be the first of many tests of the functionality of the
SAP system and the underlying configuration and/or
development. This line by line accounting of requirements
and their solutions, along with a signature, will substantiate
that the requirement has been appropriately handled in the
SAP system. This will be important as the project
progresses towards the go-live.
Downstream there will be two more critical tests of the
configuration. After the initial unit testing there will be an
integration test, where processes that cross modules will be
tested. When the integration test is successfully completed
it will be followed by the user acceptance test, where end-
users have an opportunity to test the system by executing
integrated processes (i.e. across modules).
The end result of the approved blueprints, the approved
requirements tracking matrix, the unit test, the integration
test, and the signed user acceptance test is that project
Mitigating Risk in Large SAP Projects
159
management will have indirectly controlled the design and
ultimately the configuration of the deployed SAP system.
Integrity of the SAP Landscape The SAP landscape refers to all of the SAP systems
involved in the SAP configuration and development
process.
At a minimum there are three separate systems, on three
separate "boxes" (i.e. central processing units or CPU's).
This basic landscape involves a development box, a
separate quality assurance box where changes are "staged"
before going to the production box, and finally the
production box itself.
Within an SAP box there can be several "clients". A client
is a separate SAP environment within a box. Most
changes within in it are unique only to that client.
However, there are certain types of configuration that are
"cross-client". Cross client means that if you configure it
in one client, the change will immediately be reflected in
all clients on that box; hence the use of separate of boxes
for the purposes of quality assurance testing and
production.
Within the development box the best practice is to have a
"golden client". A golden client is the originating point of
new configuration meant to eventually be deployed to the
production client. Hence any configuration change in this
client is recorded in a transport. Transports are the
mechanism to move configuration (as well as development)
to the quality assurance client and eventually to the
production client.
Mitigating Risk in Large SAP Projects
160
A key feature of the golden client is that transactional data
is not allowed. The reason for this is that certain
configuration settings cannot be undone once transactional
data has been entered. An example of this is the Update
Profile in the SAP Funds Management module. If you set
it one way, and it is incorrect or not optimal, it can be set a
different way …BUT ONLY IF TRANSACTIONAL
DATA HAS NOT BEEN POSTED. Once transactional
data has been posted the configuration is effectively locked
in.
From an internal control standpoint the golden client is
very vulnerable. There is not a systematic way to prevent
transactional data from being posted. If you try and lock
down the transactions which post data through the security
process you will inhibit the configuration team from quick
unit tests to see what the screens involved look like after
they've changed them. Once again we have to rely on
indirect controls of the process.
Those people who have access to the development client
should have to sign a document that they understand that
transactional data cannot be posted in the golden client.
This will ensure that everyone has this understanding.
Another indirect control would be to have a system
message every time someone enters the gold client
communicating to them that it is important that
transactional data not be posted.
Unit Test Client
Because transactional data cannot be posted in the golden
client, there must be another client available in the
Mitigating Risk in Large SAP Projects
161
development box where transactional data can be posted so
that unit testing can be carried out (in cases where
transactional data is required). This client is usually
known as the unit test client. In order to get the
configuration from the golden client into the unit test client,
the person doing the configuration must execute transaction
SCC1 in the unit test client and manually enter the transport
number that the change was recorded on in the golden
client. Once this transaction is run with the transport
number in the unit test client, that client will reflect the
change and the unit test can be fully carried out by posting
whatever transaction data is required. If it passes the unit
test, there is now the possibility of moving it to the quality
assurance test client for further testing by releasing the
transport out of the golden client.
Like the policies concerning transactional data in the
golden client, the copying of configuration between the
golden client and the unit test client cannot be directly
controlled. Indirect controls to ensure this happens must
be utilized. The importance of this happening is that as
time goes by the two clients will become out of sync if
configuration personnel have not been diligent about
copying their configuration to the unit test client and it
becomes increasingly difficult to unit test as years go by.
If you intend to be involved with the project for the years
after the go-live be particular vigilant about the controls
that are put in place to keep them in sync. Once they
become out of sync it can be extremely difficult to get them
back in (perhaps impossible without copying some other
client).
Mitigating Risk in Large SAP Projects
162
Internal controls consist of indirect methods such as sign-
offs from the configuration personnel and if possible a
report from the Basis team (the team responsible for the
SAP hardware) comparing transports that are in the golden
client but not in the unit test client along with the date it
was created. If a transport sits on the list for over a month
it's likely that it will forever cause an out of sync condition
if action is not taken.
Another impediment to the effectiveness of the unit test
client is the maintenance of year-end procedures. Some
modules, such as the Asset Accounting module (FI-AA),
become useless if the year-end procedures are not carried
out. Consequently there should be a year-end checklist for
the unit test client (as well as the quality assurance client)
to assure their long-term usefulness. Once again take note
that an integration partner may have little motivation to
institute such measures since they often do not support the
system beyond a few months after go-live. Consequently
they will usually not provide advice concerning this long-
term post go-live strategy.
Sandboxes
The best practice in SAP development is that experimental
configuration work and prototyping alternative solutions
should not be done in either the golden client or the unit
test client, therefore at least one additional client is
required: a "sandbox".
Sandboxes are usually copied directly from the production
environment with periodic refreshes (i.e. copies) from
production carried out a couple of times a year. This
Mitigating Risk in Large SAP Projects
163
affords the configuration personnel the opportunity to try
different things without fear of messing up the golden or
unit test clients.
Quality Assurance Client The quality assurance client is a box separate from the
development box (which contains golden clients, unit test
clients, and sandboxes) that is reserved for the activities of
integration testing and final user acceptance testing.
Because of the latter it is sometimes called a staging client.
Control over this box is much easier than it is for the
golden and unit test clients of the development landscape.
The only way for configuration to get into this client is via
a released transport. Releasing a transport implies that the
configuration person has unit tested it. We will discuss
testing fully in the next section.
The quality assurance client by necessity has transactional
data in it. Furthermore it should be as close to Production
as possible, so copying Production to create or refresh it is
fine. The main difficulty in this is timing as there is usually
some sort of testing going on all the time in this box. The
refresh will overwrite this testing. The importance of this
timing is underscored in the following example:
As discussed earlier I once had a client that had an SAP
consultant make a change to the fiscal year variant of a
company that had been live for many years with SAP. He
did this in the middle of the fiscal year. Transporting this
change into production in the middle of the fiscal year
causes database inconsistencies in the system that rendered
Mitigating Risk in Large SAP Projects
164
it unusable (for a lengthy period of time while it is repaired
at a table level).
However, the consultant was not alone in his culpability.
This catastrophic change should have been caught when it
was moved into the quality assurance client. Unfortunately
for this fortune 500 company the perfect storm happened.
After this bad configuration was moved into the quality
assurance client, and after some early (but obviously
incomplete) testing had been completed, the system was
refreshed unexpectedly to the testers, who would ultimately
approve the user acceptance test because they had thought
that the test was complete "enough". The lessons to be
learned from this story are that all testing must be complete
before a quality assurance system is refreshed with a copy
of production, and all user acceptance testing must be
complete before approving a change to go to the SAP
system. There can be no short cuts.
The result of this perfect storm was catastrophic. For two
months this fortune 500 corporation could not use its SAP
system. Because of the failure in QA testing the consultant
involved could not be held legally culpable (though they
did sever their relationship with him).
***
This concludes our discussion of landscape. There may be
other boxes within your landscape, but for the purposes of
our discussion of risk a minimal landscape has been
discussed.
Mitigating Risk in Large SAP Projects
165
Development Control of development, like configuration, is integral to
minimizing risk in an SAP project. Unlike configuration,
which does not involve any code changes, development can
be a much higher risk. Take note of the stipulation made
earlier to not allow any core modifications to your system.
Allowing core modifications to your SAP system will open
your project up to even more risk than other types of
development (with the possible exception of Z programs
and Z tables depending on the extent they are used).
The best way to control the risk of development is to not
have any. Unfortunately it is rare that you can have a large
SAP project without some degree of ABAP development.
If all that you have is a few interfaces, count yourself
lucky.
Even the mini-modifications (e.g. user exits for example),
open you up to increased risk.
So then how do we minimize the risks of development?
1. If you are involved in the contract negotiation or project
initiation phase, try to avoid as much development as
possible. Start with pushing for no development
whatsoever. If you can accomplish such a feat, you have
significantly reduced the amount of risk you will be
exposed to.
2. Assuming you cannot totally avoid development, limit
development to the smallest number of interfaces possible.
If you do not allow any other types of development your
risk profile remains low.
Mitigating Risk in Large SAP Projects
166
3. Allow only Z transaction codes in the core SAP
Enterprise Central Component system. No other forms of
development (including core modifications) are in scope.
Any other types of development increase the risk that you
carry in your SAP project. Once again I stress the mantra:
no core modifications allowed, ever!
For those types of development that you have not been able
to escape, ensure that the requirements and a well thought
out solution is documented in the functional specification
document and ensure that it is signed off by the appropriate
person in the business before hand off to the technical
developers.
Once in the hands of the technical developers they should
complete a technical specification document before their
work is promoted to the quality assurance client for testing.
Have a process to ensure that both the technical and the
signed functional specification document have been
completed.
Before this there will have been a unit test, most likely
conducted by the technical developer in league with the
functional SAP person. Once this is completed then the
normal testing cycles (see testing section) should be carried
out.
Testing The testing process utilized by your project serves many
roles. The user test allows the person who did the
configuration or development an opportunity to test their
work in isolation. The user acceptance test allows users to
Mitigating Risk in Large SAP Projects
167
approve the work before it goes to Production, and the
integration test allows for an entire process that crosses
modules to be tested. Regression testing ensures that
previously approved work hasn't been broken by new work.
Load testing ensures that your system compares favorably
to certain benchmarks when it is under stress.
From our standpoint testing is about reducing risk.
Primarily it’s about preventing bad configuration or
development from getting into your pristine production
environment.
Remember the example of the fortune 500 company whose
system became unusable because of the change of fiscal
year variant mid-year? Ultimately this fortune 500
company was responsible for the disaster because their
testing was not well controlled. Had it been well
controlled, the disaster would have never happened. So be
vigilant about the testing process, and I do not mean just
the paperwork of the process.
Even if you are the senior most person on a large team,
make sure that you are intimate with what is going on in
testing. Walk amongst the team and ask questions.
Reports are great, but you should use them to support your
intimate knowledge of what is going on in the testing
process.
There are many forms of tests: prototyping, unit tests,
regression tests, integration tests, user acceptance tests.
Your team will use all of them. Let's discuss them one by
one with a focus on how they relate to overall risk.
Mitigating Risk in Large SAP Projects
168
Prototyping
Prototyping refers to configuration and development whose
design is still somewhat in flux. To avoid putting
unwanted configuration and ABAP code in the golden
client, such testing should be done in a sandbox.
Because it is done in a sandbox the risk is extremely low,
while the benefits are high. It allows for an optimal
solution to be in place before the true configuration or
development begins. The sandbox does not have transport
recording turned on, so whatever happens in that sandbox is
just like Las Vegas… it stays in that sandbox. Dirty
configuration is harmless in it.
Due to the experimental nature of prototyping no test
documentation is required.
Sandbox
A sandbox is an actual computer processing unit loaded
with a copy of SAP that is not attached to the transport
landscape. It is wide open to configuration and has little if
any security to impair the free experimentation with
different Implementation Guide (IMG) set ups.
Unit Testing
Unit testing refers to isolated tests performed by the
originator of configuration or of development in the unit
test client. You will recall that the unit test client is not the
same as the Golden Client. There needs to be a closely
controlled transport copy (transaction code SCC1) process
to copy the configuration or development from the Golden
Client to the unit test client. This is to preserve the ability
to change some configuration in the golden client (because
Mitigating Risk in Large SAP Projects
169
as was stated earlier, once transaction data is posted in the
golden client, certain configuration can no longer be
changed).
The appropriate level of control over unit testing is
somewhat disputed in SAP circles. A minority of SAP
practitioners think that there should be formal sign off's for
every unit test done. I am not one of those people. Best
practice, based on a review of many implementations is that
the unit test process should be kept very informal. The
pass or fail of any unit test is up to the person who
configured it. If the process involves ABAP development,
the pass or fail of the unit test is either up to the ABAP
developer, or depending on the circumstance, a business
analyst.
The reason I favor the informal unit testing process is due
to the fact that there can be many iterations of a unit test in
a single day. To attach the process to a formal and
cumbersome process lengthens the cycle time of
configuration and development without producing any
significant benefits. This is not the point at which the
work will be tested as part of an integrated end-to-end
process, nor does it involve the final approval from users.
The bottom line is this: do not attach any cumbersome
controls to this unit test process because you cannot
effectively mitigate risk using them.
The only part of the unit testing process that you do want to
control is the movement of transports between the golden
client and the unit test client. Do not let them get out of
synchronization. Have the BASIS team do regular
Mitigating Risk in Large SAP Projects
170
comparisons of transports between the clients and quickly
get any offenders of this process back inline.
Integration Testing
Integration testing requires far more formality (i.e. control)
than does the unit testing process. There need to be scripts
outlining the entire process, and those scripts need to be
signed by the appropriate members of the implementation
team who represent the business. These team members
should have a business background. However, these are
not the same people who will do the user acceptance test.
As we will see in the next section, the people who approve
the integration test should not be the same as those who
approve the user acceptance test.
Integration Test Design – the integration test should be
based on real life business scenarios, not just a series of
transaction codes (such a test is known as a "string" test
and will be discussed later in this book).
A scenario based integration test refers to the testing of
situations that often come up in the normal course of
business and that initiate a series of actions in the business.
For example: the organization gets an order from a
telecommunications company to build them a cell phone
tower. The order will contain specifications, involve an
approval process, a budget will be formulated for the work
order based on the contract, etc. Eventually the tower will
be built, employees will charge time to the construction
process, and the telecommunications company will have to
be billed. Eventually money will be received and the
accounts receivable liquidated. In this scenario the
Mitigating Risk in Large SAP Projects
171
company that ordered the tower may have a warranty issue
that becomes part of the integration test.
Such a test would challenge the SAP system to handle a
complex real-life situation.
There will be many such scenarios, submitted by experts in
the subject organization who have a keen understanding of
the types of scenarios that the system must be able to
handle.
To ensure that the integration test is comprehensive, the
transaction codes used in the scenarios should be compared
to a list of transaction codes put forth by the
implementation team to ensure that all aspects of the
system are included. By doing this, the elements of a
string test are also included.
The same scenarios will likely form the basis of the user
acceptance test. The difference lies in the people who
execute the tests: in the user acceptance test phase people
not directly associated with the project team will execute
the tests.
The integration test will uncover many issues. As a result
it will be iterative. There should be three integration test
cycles. The first cycle will be difficult and full of errors.
The second should be much easier, with about 80% of the
issues solved already. The final cycle should see the
resolution of the final 20% of the issues. There may even
be additional cycles depending on the success of the third
cycle.
Mitigating Risk in Large SAP Projects
172
Each cycle must be controlled. As we are getting closer to
the final user acceptance test, each step should be signed
off, with the entire script eventually approved by the most
appropriate business member from the project team.
The directors of the project should closely monitor the
scripts to ensure that they have all been signed off.
Furthermore, the director should know the people who have
signed off so that they can rely on them. Also, as
mentioned earlier, do not rely solely upon reports. The
process is important enough that the senior most people of
the project team should be intimate with what is going on
during the test. Listen to the banter of the team, and the
interactions. Talk to the team members about any specific
issues they are having. Don't be locked away in the ivory
tower during this process as it is your opportunity to make
sure that the SAP system is performing as it is expected to
perform, as well as one of your greatest opportunities to
mitigate risk.
Online Support System (OSS)
This is the old name for SAP's support system. Though it
has not officially had this name for many years, people in
the industry continue to refer to it as "OSS".
This is a system where solutions to problems, including bug
fixes, can be found. It is also a system where those who
are working on the system can bring issues to the attention
of SAP and get their opinion as to how it can be resolved.
The system is not meant to supply instructions on how to
configure the SAP system, it is expected that each
organization will employ and retain people to help them
Mitigating Risk in Large SAP Projects
173
with this. As a consequence the SAP Online Support
System does not provide actual consulting advice; its
purpose is to allow SAP to provide assistance with
suspected system malfunctions.
User Acceptance Testing
User Acceptance Testing is one of the greatest risk control
devices one can have in an SAP project. Not only does it
significantly reduce risk but it also serves to spread the risk
between the project, and the rest of the firm, and between
the integration partner and the subject of the
implementation. If you are an integration firm, the latter is
invaluable in litigation proofing one's self. With an
effective user acceptance test everyone wins, even if
getting sign off is extremely difficult.
In addition to mitigating and spreading risk, it is also a
valuable change management tool as it is the first
introduction of the new or redesigned SAP system to
people outside of the project team.
As mentioned in the prior section, the UAT will often use
the same scripts developed for the integration test. If that's
the case almost all of the bugs should have been worked
Mitigating Risk in Large SAP Projects
174
out of the system by the time the outside users put their
hands on the system.
Documentation and sign-offs are more important at this
stage of the project than at any other time. This is the
point where the business gets to say "we have extensively
tested the SAP system you developed and it's awesome!"
Awesome in this case means they signed off. That sign off
is golden: it means they tried it and liked it, so to a large
extent the project team can no longer be faulted if things do
not go well when the system is deployed.
If the same scripts are used as those that were used in the
integration test, then it's important that those scripts were
developed by the business. Consequently there should be
a sign off process for the construction of the scripts with
the preeminent sign off being that of the business.
However, don't forget that every transaction code used in
the to-be design of SAP must be encompassed in those
scripts, so the document must be signed off by the project
team leads as well.
The user acceptance test is the final test before moving into
the realization phase of the project. This is the phase
where you and your team prepare to deploy (i.e. turn-on)
the new SAP system. This is called "go-live".
Mitigating Risk in Large SAP Projects
175
Upgrade
An upgrade involves taking an SAP system from a lower
level of SAP to a higher level. For example, taking SAP
from Enterprise Central Component Enhancement Pack 5,
to Enhancement Pack 6. An upgrade can be technical
only, or both technical and functional (where new
functionality available in the new version is deployed as
part of the upgrade project).
Regression Testing
Every time something fails, and a correction is made via
configuration or new development, the change has to be
tested to ensure that nothing that previously passed has
been broken by the change.
The concept of regression testing applies to all tests
previously performed: from unit testing all the way to user
acceptance testing. The more that has changed, the more
regression testing that must be done. If the process affects
downstream processes then they too should be retested.
The degree of comprehensiveness of the regression testing
depends on those two factors: degree of change, and effect
on downstream processes.
Mitigating Risk in Large SAP Projects
176
From a risk perspective the process of regression testing in
an SAP implementation is difficult to control. This is
especially true of the unit testing portion which is usually a
highly informal process anyways. If the regression testing
applies to unit testing it will continue to be informal.
There could be multiple rounds of regression testing at this
point and there is no need to slow it down in a futile
attempt to control a process that does not need a lot of
control.
The integration testing aspect is different. This is the key
place for regression testing. Depending on what the failure
was, the effect of regression testing on integration testing
may be the testing a few steps in a scenario, or it could
require the retest of an entire scenario. Depending on how
integrated the process is there may be several scenarios
effected, which must all be tested to some extent.
Integration testing already has two or three cycles. The
regression test would be an additional partial cycle after the
last integration test cycle (because those cycles essentially
already have regression testing built into them).
The impact on user acceptance testing depends on the
findings of the regression testing that was appended to the
integration test. However, to some extent there must be at
least partial scenarios tested to make sure the integrated
process is subjected to a thorough test by the outside
business users.
Because regression testing is critical to the integration
testing cycles as well as the user acceptance testing there
Mitigating Risk in Large SAP Projects
177
should be adequate documentation and control over the
process.
Each failure detected following the last integration cycle
should result in documentation that includes a regression
test plan. The regression test plan should be carefully
monitored by senior project members for both its
reasonability and its completion. After the regression test
for this aspect has been completed it should be followed by
a plan for regression testing by users (i.e. a UAT), which
should also be closely monitored for reasonability,
completion, and approval by senior project management.
The attention to detail required by senior project
management in this process is requisite because a late
testing failure was detected and if not adequately tracked
this failure could make its way to the productive system.
Therefore it is imperative that this process be carefully
controlled. This is a high risk area.
Accounting Reconciliations
Accounting reconciliations are not usually considered
among the tests employed in an SAP project. This is a
mistake. You must ensure the integrity of the financial
data that your system is employing. In most cases this is
not an issue because SAP is a solid product from a financial
Mitigating Risk in Large SAP Projects
178
perspective that produces a great audit trail. However,
there can be issues between modules like asset accounting
and the general ledger, and when contract accounting is
used. Having at least one intermediate level accountant on
your team to reconcile critical financial business processes
is an important part of a solid testing strategy for an SAP
system implementation.
At least one project that I am aware of failed because
project management did not realize that the convergent
invoicing totals did not reconcile to the source documents
in the Sales and Distribution modules and Contract
Accounting modules because they were never adequately
reconciled. The result was a massive lawsuit.
Stress Testing, Volume Testing, and Other
"Basis" Oriented Tests There may be other forms of testing on your project, or
other names for the types of testing we have already
discussed. One other form of testing that is common on
SAP projects is stress testing. This is a test usually
conducted by the Basis team to ensure that the hardware
configuration can handle the expected volume and to get an
idea of the response times. Another form of testing that is
closely related to stress testing is volume testing: how
many concurrent transactions can the system handle?
From a risk perspective the results of these types of tests
tend to be less critical to those of the integration and user
acceptance testing types, unless your organization is subject
to some sort of service level agreement with severe
penalties. Therefore you can put your reliance on your
Mitigating Risk in Large SAP Projects
179
Basis team to ensure that the test is well designed and that
the results are acceptable. You do not generally have to
"micro manage" this process like you do some of the other
aforementioned test types.
Documentation Throughout this book we have discussed documentation
requirements for each type of activity. One of the
challenges of an SAP project is not only gathering the
documentation, but also storing it so that it can be retrieved
in the years following go live.
Some of the documentation may also be important for
litigation purposes. If you are on the implementation
partner side of the table, you may want to ensure that you
have copies of all test documentation, blueprints, as well as
functional and technical specs. Write it into the contract so
that you can legally retain copies of these. The
documentation, in particular that of the user acceptance
test, could be invaluable should litigation ever occur.
Depending on the size of your project the amount of
documentation produced by the team could be exorbitant.
You may need a dedicated documentation controller to
ensure that all the documentation required is produced in a
timely manner, and that it is securely stored and easily
accessible. They would also be charged with the
responsibility of ensure continuity with the documentation
so that it is easily accessible in the years following the go-
live.
Mitigating Risk in Large SAP Projects
180
The Project Plan
The project plan is a key tool for planning your resource
requirements and ensuring that the project time line is
valid. It is also an important risk management tool that
can alert you to slippage and give you an indication of how
much actual risk is contained in the schedule.
First off let us assume that:
A project plan exists.
The project plan was designed by someone with
acumen in the planning process.
Because of the preceding the plan has the proper
relationships between tasks (end to start, parallel,
etc.).
The plan is resource loaded and the resource
assignments are accurate.
It has been maintained.
Assuming all of the assumptions above are true there are
some good indicators of risk in the plan. First off, how
much "slack" is built into the plan? If the plan has little to
no slack in it than the risk of not being able to go-live on
Mitigating Risk in Large SAP Projects
181
the established go-live date is high. The risk may not be
just to one's reputation: there could be financial penalties if
you are the integrator.
The risk could be even worse than simple financial
penalties. Some SAP modules MUST go live at the
beginning of a fiscal year, especially those that are both
financially sensitive and time sensitive (for example SAP
asset accounting). This could mean waiting an entire year
for another opportunity to go-live with these particular
modules.
Aside from slack, if the plan has been loaded with all of the
resources and these assignments are accurate, it could give
you an indication of which resources will have too much
work to accomplish for the timeline to be achieved.
Finally, the other area of risk than we can assess using the
project plan is that of budget, or more correctly budget
overruns.
If all of the above assumptions are true about the project
plan it can be used to determine whether you will be able to
deliver the project with the dollars that have been allotted
to it, and how much risk to that budget there is (see the
discussion on slack). Such an analysis could be quite time
consuming to produce. If you have a large project you may
want to employ either a project financial controller or a
project financial analyst to produce this analysis for you.
Security The final area of project control we will discuss is that of
SAP security, sometimes called authorizations. This is the
Mitigating Risk in Large SAP Projects
182
aspect of SAP that is concerned with who has permissions
to do what in the SAP system.
The authorization concept is fairly well established in SAP
and as a result it is not a high area of risk. It can
unnecessarily bog down your project if you do not take the
following precautions:
In terms of scope ensure that only security by
transaction is encompassed in the plan. Explicitly
spell out that no other forms of SAP security will be
employed. There will be no security by document
types, no security by cost center (aka department),
and no security by general ledger account, etc.
Spelling this out in the scope, or better yet at a
contractual level, could save headaches down the
road as these increased levels of security can turn
out to be very similar to development projects (and
thus carry the risk inherent with that sort of work).
Security by transaction code is very straight
forward. The transaction codes will be further
grouped into user roles, which is also straight
forward. Sticking to the basics will help keep the
project on time and on budget.
Do not overburden the project team with undue
security restraints. Security is for the people at the
user level, not for those who are configuring and
developing. Do not apply any security to the nodes
within the Implementation Guide (IMG) as you will
reduce the productivity of the configuration team.
Access to the Implementation Guide itself can be
Mitigating Risk in Large SAP Projects
183
secured, as should access to the development clients
(especially the golden client) themselves.
Aside from obeying legislative requirements (some
places have laws protecting sensitive information
that must be abided by when working on an SAP
project), the configuration and development team
members should have carte blanche access to any
transaction they want in every client except
production.
Users in the both the production and quality
assurance environments should be locked down
using transaction code based authorizations. Those
authorizations should be identical in both
environments.
Users should not have access to anything other than
production and quality assurance clients. On
occasion it may also be appropriate to give them
access to a sandbox.
The central message of this section on SAP security is: do
not over do it, and confine it to transaction code based
security only.
Mitigating Risk in Large SAP Projects
184
Handling the Unexpected Stuff happens!
In general, the best ways to handle unexpected issues are:
Have a sufficient budget
Have plenty of slack in your project plan
Have redundant resources
Have a solid plan in place to handle the departure of
key resources
Mitigating Risk in Large SAP Projects
185
The "Perfect" SAP
ECC Project
A Hypothetical Case
Study
“I seek as much as I can to mitigate risk”
- John R. Allen
Mitigating Risk in Large SAP Projects
186
A Hypothetical Case Study:
The "Perfect" SAP
Enterprise Central
Component Project
Unfortunately very few SAP projects go from inception to
go-live without some major hitches. Let us consider a case
where everything goes as it should to exemplify risk
reduction while still attaining the expected benefits of
implementing or enhancing an SAP system.
In this example we will assume the role of the
implementation partner's SAP project manager. However,
most of the risk mitigation strategies contained in this
example apply to the role of the business' internal project
manager as well.
The project team in question will be charged with
implementing SAP for the first time in a large organization.
It does not matter whether that organization is in the private
sector or the public sector. Both would have the same goal:
to reap the benefits of an integrated SAP system, without
having the initiative go "off the rails" before it gets there.
Mitigating Risk in Large SAP Projects
187
The Request for Proposal
Some Assumptions In some SAP projects the inception of the project can be
traced back to the request for proposal (RFP), or even
before. Since we are illustrating the perfect project we will
ignore the fact that most consulting firms are forbidden to
reply to an RFP if they had advised the client during the
formulation of the RFP. In this case we are going to
assume that this exclusion has not been made (ignoring the
possible conflict of interest to keep this example nice and
clear).
Some SAP projects will not start with a Request for
Proposal, but they will start with a process very similar to
that of formulating an RFP. They will still have to
formulate a scope, and there is often a partnership between
the organization for which SAP will be implemented or
changed, and an outside integrator or consulting firm.
Development of the Request for Proposal What is most pertinent about the Request for Proposal
process for our purposes is the formulation of scope.
Depending on how rigid the RFP is, scope may already be
locked in by the time the project begins because of the
contractual obligations of the Request for Proposal. It is
this aspect of the RFP that is most critical to the amount of
risk assumed in the project.
Mitigating Risk in Large SAP Projects
188
At the outset of the discussions it was decided that this
would not be a "big bang" SAP project. The big bang
strategy is aptly named, for it often has a big bang along the
path, but we wish to avoid any large explosions in our
project; so the strategy adopted was one of "take the
smallest step forward possible".
It was also decided between the business and its consultant
that only the core SAP Enterprise Central Component
system would be implemented, with the exception of one
"bolt-on" package to take care of sales and use tax. It was
decided that the risk of not utilizing this bolt on far
outweighed the risk posed by including functionality
outside of the core SAP Enterprise Central Component
system. (To not implement it meant that the organization
had to maintain a staff to monitor changes in tax legislation
across many different jurisdictions, and then put through a
Mitigating Risk in Large SAP Projects
189
transport change to the SAP system every time a change
occurred).
It was further decided during the RFP formulation process
that not only would this implementation focus on the
implementation of core SAP Enterprise Central Component
modules, but it would implement only the oldest and most
stable modules. Modules like Grants Management, though
part of core SAP Enterprise Central Component would be
avoided because they are newer and consequently less
stable than modules like SAP Project Systems. In essence
the only modules in scope were those that a) existed when
SAP R/3 first came out in the early 1990's and b) hadn't had
any significant changes in functionality in the last ten years
(e.g. SAP Funds Management though an old and
established module had a major change to it a few years
prior to the RFP and was therefore considered less stable
than some of the other modules and was thus eliminated
from scope).
The reason for the avoidance of newer modules or
established modules that contain a major change is that
such modules tend to necessitate many OSS Note
applications to fix bugs. I.e. they tend to have a few bugs
that will slow down the realization phase of the SAP
project due to the research necessary to find the OSS Notes
as well as the overhead of having to have them applied,
tested, and transported through the various clients of the
landscape.
Although the business had a strong desire to implement a
bolt on reporting system, and a third party customer
Mitigating Risk in Large SAP Projects
190
relationship management system, it was decided to keep the
focus of the RFP nice and tight and exclude these.
Furthermore the SAP modules to be implemented would be
limited to just the core financials with some materials
management. There was a strong desire to implement SAP
Human Resources including SAP Payroll, but in keeping
with the small steps strategy it was decided that these
modules would comprise phase II and have their own
request for proposal and project. Consequently, this
decision entailed that an interface be built between the
existing payroll system and the General Ledger of the
future SAP system.
Hence the SAP modules in scope for the request for
proposal are: Financials (including the General Ledger),
Controlling (for departmental accounting), Accounts
Payable, Accounts Receivable, Project Systems (for capital
projects), Investment Management (for capital budgeting),
Asset Accounting, and the Cross Application Time Sheet
(CATS).
The decision to use CATS entailed yet another interface to
be included in the scope since it has to feed data to the
outside payroll system, so we now have two interfaces in
scope.
At this point the project team ponders the fact that two
interfaces are now in scope. Is there any way to take them
out of scope? After much deliberation and good intentions
it is decided that the only way to take them out of scope
would be to implement SAP Human Resources and Payroll.
Mitigating Risk in Large SAP Projects
191
After some debate it is decided that to do the latter would
depart too drastically from the small steps strategy.
A word on SAP Payroll: implementing this module is
perhaps the most contentious of the SAP Enterprise Central
Component modules. Payroll is critical to a firm. A
mistake in that module can be truly disastrous in many
ways: negative press, bad labor relations, missed go-lives,
etc.
The SAP consulting firm strongly recommends to the
business that SAP Human Resources, and especially
Payroll, be a separate and distinct implementation project
undertaken when the core SAP financials becomes stable.
Furthermore, they advise that no other modules be
implemented concurrent with these, so that the entire team
focus can be on this functionality.
Such an approach to scope is the most effective in
mitigating risk, and the business accepts the
recommendation of their consulting partner.
By the end of the request for proposal formulation exercise
a clear, concise, low risk RFP has been created that
involves the lowest risk possible and the greatest chance of
success in achieving its goals on-time and on budget to the
satisfaction of all involved.
The RFP Response Unlike the real work where the consulting firm advising on
the formulation of the request for proposal (RFP) is usually
excluded from bidding on the work, no such exclusion was
made.
Mitigating Risk in Large SAP Projects
192
Now your firm must compete with other firms for the work.
This is crucial time for you and your firm as millions of
dollars in SAP related consulting work is on the line.
You'll be competing with several other large firms for this
juicy contract (which you helped turn into a relatively low
risk endeavor through your work in advising the client on
the RFP formulation).
Now you most show your capabilities.
At this point I'd like to interject some reality into this world
of fantasy. A few years ago I served as an expert witness
for the plaintiff in one of the largest litigation cases ever
involving an SAP implementation. The strategy employed
by the plaintiff's attorneys was to not try and prove that the
implementer was negligent, but that they were in fact
fraudulent.
The alleged fraud centered on a "smoking gun" email
concerning a demonstration of SAP functionality in which
a senior member of the integration company stated that the
customer thought they were seeing one version of SAP, but
unbeknownst to them they were seeing two different
versions of SAP mixed together. One of those version
wasn't even available on the market yet. Furthermore, the
team had used some custom ABAP code to make up
functionality that did not exist in standard SAP software.
While the actions of the sales team were reprehensible, the
fact that they wrote about it in an email to each other (the
email came from the team leader) showed that they had not
been educated on how litigation works. The sales team did
Mitigating Risk in Large SAP Projects
193
not realize that every email they write, every note they
make, is discoverable during an American litigation case.
This "smoking gun" email was the centerpiece of the case.
The case was eventually settled out of court for an
unspecified sum. Based on the fact that the amount
specified in the lawsuit was 800 million U.S. dollars, I
speculate that the sum that was settled on was tremendous.
The moral of the story: If you are a senior member of an
implementation and consulting firm educate your
professionals on one key strategy: do not put major issues
in writing if the issue is legally contentious! Do not take
notes about them, and especially do not write emails about
them: Discuss all such issues verbally, in person or over
the phone.
The Winner Is …. For the purposes of this perfect world example we fast
forward to the beginning of the contract negotiation
between the implementation partner (your firm in this
case), and the client (the subject of the SAP job).
Because our consulting firm was a trusted advisor we
ended up winning the work. Now our two parties discuss a
contract.
From the perspective of the outside implementation
consulting firm there are several things that you want to
avoid: there will be no workshops entitled "Lessons Learn"
or anything else that implies that you are anything less than
Mitigating Risk in Large SAP Projects
194
expert. You are paid to NOT make mistakes, so do not
have contact terms that force you to admit to making them!
Remember that during the contract phase we said that if
SAP standard functionality could not support the client's
current business practice that they must change their
processes to conform to SAP. Stick to that!
There will be no core modifications ever! In addition,
there will be no Z tables, no Z programs, and no other
development that is similar to a core modification,
regardless of whether or not it will be overwritten by future
upgrades.
Also remember how you stated in the contract that "mini
mods" such as S-mods, as well as user exits would require
senior project approval and result in a time and materials
based task order that would cost extra … stick to that. You
do not want to make it easy to stray from vanilla SAP.
Aside from that points made above, all of the usual aspects
of contract negotiation are in play. Make sure you
negotiate a timeline with as much slack as possible. In
order to estimate this you'll have to have a project plan
already formulated so that you can have a meaningful
estimate as to how long it will take, and what resources will
be consumed. If there is no slack in your timeline, if you
cannot meet the expected dates, or if you know that you
cannot bring the project home within the client's budget,
then you should walk away. Do not hope for a miracle, if
the numbers do not support your ability to bring this project
home without unreasonable risks you and your team must
walk away.
Mitigating Risk in Large SAP Projects
195
Even if everything looks promising both parties will be
assuming some significant risks, so do not walk into
something that already appears to be a failure on paper.
Congratulations! You've won. Now
what? It is now time to execute the scope of work. Below is a
high level graphic depiction of the typical phases of an SAP
project:
The five phases above apply to green field
implementations, re-implementations, upgrades, the roll out
of new modules, and major enhancement projects.
So, now that you have won the work, and you have an idea
of what's in front of you, it is time to take the scope of
Mitigating Risk in Large SAP Projects
196
work, and the high-level plan you made, and begin the
project initiation phase.
Take the time you need to make a good plan, to arrange a
suitable work space, make arrangements with suitable
subcontractors, and bring on board the right employees.
Also take the time you need to formulate a project charter,
the procedures, and especially the project policies. The
policies you enact, plus the controls you put in place to
ensure that they are followed, will be critical to controlling
what could be a very large project team and their output.
Make sure that you get the right people on board. If the
modules involved are engineering related the people
involved with configuring it should be qualified
professional engineers. If they are accounting oriented
ensure that they are qualified CPA's. You can teach
people to configure SAP, but you cannot create a CPA
overnight.
While I did say take the time you need, I also caution you
to not take more than you need. This is not a value added
part of the project, there is no system being brought to life,
nor none to deploy. Get this phase of the project over as
soon as possible without sacrificing the quality of the more
important aspects such as the project plan and the project
controls.
Move into Phase Two as soon as possible. This is the
blueprinting phase where the team will look at the as is
state to determine the business requirements, and then
design an SAP system that meets those requirements.
Squish the first project initiation phase down as much as
Mitigating Risk in Large SAP Projects
197
possible in terms of time so as to rapidly get to the more
critical phases that follow.
Blueprinting Now it's time to begin the blueprinting process. At a high
level this phase consists or further definition of the business
processes in scope, an analysis of the as-is state of those
processes, a design to satisfy the requirements that come
out of the as-is review (known as the "To-be"), and some
unit testing. The blueprinting process is shown in the
graphic below:
Remember that during the contract phase we said that if
SAP could not support their current business practice that
Mitigating Risk in Large SAP Projects
198
they must change the processes to conform to SAP. Stick
to that principle! The business much change to suit SAP.
There will be no core modifications, ever! Nor will there
be any Z tables or Z programs. Thank god you put that
provision in! Such provisos serve to guard against the
possibility that some of the configuration resources on your
team may not know the available SAP functionality as well
as they should. Through the provisions against core
modifications, z-tables, and z-programs they will be less
likely to quickly propose custom development if they do
not know how to configure the solution.
Also remember how you stated in the contract that "mini
mods" such as S-mods, as well as user exits would require
senior project approval and result in a time and materials
based task order that would cost extra … stick to that. You
do not want to make it easy to stray from vanilla SAP.
Before proceeding make sure that every element of the
project's scope is covered in the blueprinting effort. On a
large SAP project this could get overlooked.
Ensure that each team member understands the blueprinting
process and that the standards you have set are followed.
While the as-is gets analyzed, ensure that each element of
the requirements traceability matrix (RTM) is signed off by
members of the business. The sign off on individual
elements of the RTM will be used to help persuade the
person who has the ultimate responsibility over the entire
process to sign off on it.
Once all blueprints are signed off you can proceed into the
realization phase.
Mitigating Risk in Large SAP Projects
199
Realization The realization phase is the part of the project where the
design that you described and got sign off for during the
blueprinting process is actually configured and developed
in the SAP landscape.
This is in essence the "build" phase of the project.
One of the most frequently mishandled control procedures
during this phase is the copy of configuration from the
golden client to the unit test client (using transaction
SCC1). This lack of control may be a reflection of the fact
that most implementation partners are no longer involved
with the system beyond a few months after the project has
gone live, let alone a few years later when the unit test
client has gotten horribly out of sync with the golden client.
Hence, placing controls on the process is not high on an
implementation partner's list.
One area that should be of more importance to the
implementation partner (since the effects can be seen quite
quickly) is that of transactional data tarnishing the golden
client. Remember our discussion of the effects of
transactional data in the golden client? To reiterate: It
makes certain configuration settings irreversible.
In our project we have taken steps to control the integrity of
both. During the on-boarding process anyone involved in
configuration had to sign a document verifying that they
understand the importance of the two processes above.
In addition, the Basis team was also able to create a report
that compares the transports in the unit test client to that of
Mitigating Risk in Large SAP Projects
200
the golden client. Every week the manager of the
functional team discusses items from the list with the team
members responsible.
Who should configure the system? This is an important
point for members of the project team who belong to the
business, and to the issue of long-term support. Generally
speaking the members of the implementation partner will
be inclined to do the configuration themselves in the
interest of expediency. Unfortunately this leaves the
members of the business without a solid knowledge of how
configuration works. In our project the Security team has
provided configuration access to the golden client only to
select team members from the business side. The
members from the implementation partner only have
display access to the golden client. They do have full
access to the sandbox however. At the end of this project
all configuration in the golden client will have been
performed by members of the business. Hence, the current
staff members who have to support SAP in the years after
go-live have a solid understanding of how it was
configured.
The staff members from the business did the initial
configuration of course, with their SAP consultant sitting
side-by-side with them. During the initial implementation,
no golden client configuration should ever been done
without the business' staff performing it with their SAP
consultants sitting next to them.
Parallel with the configuration effort the two interfaces we
identified earlier are being developed based on a functional
Mitigating Risk in Large SAP Projects
201
specification document that is consistent with the blueprint
design.
The sales and use tax bolt on package does not need a
custom interface developed as it has standard connections
that are configured in the SAP Implementation Guide
(IMG).
The two interfaces are the only development items.
Because the contract and scope document had strong
provisions against any sort of development (even
seemingly minor development), all development has been
avoided.
This has led to some change management challenges since
some business units have to drastically change the way they
do business.
The "no development" stance has also required some
creativity from the functional SAP team because the
blueprinting process did uncover gaps. A strategy for each
gap was devised, but it was very challenging and there was
plenty of controversy.
The contract and scope document did allow for some
development such as user exits (though they required
special task authorizations with high level approvals). Had
any been approved the senior management of the project
would have spent extra time with the team involved to
ensure both the necessity and the ability to effectiveness of
the solution. This reflects the fact that these are
moderately high risk areas of the project.
Mitigating Risk in Large SAP Projects
202
As the realization phase of the project continues the unit
testing is compared to the requirements traceability matrix
(RTM). As each item in the RTM is satisfied the team gets
a sign off. The purpose of this is to get the team used to
getting signatures, and to have small steps signed off over
time so that eventually large sweeping approvals will be
easier to get. This unit test sign off is not an actual
contractual approval process. It is informal. Aside from
getting the team used to getting sign offs the managers of
the team can more easily see which realization items are
slipping and which have already been met from the
perspective of the business..
As the realization phase of the project draws to a close in
our hypothetical "perfect SAP project", each item on the
requirements traceability matrix has been signed off. All
configuration is complete, as are the interfaces. We are
ready to move into the go-live preparation phase.
The Go-Live Preparation Phase With the culmination of the realization phase and the sign
off on all the individual requirements as indicated by the
requirements traceability matrix, the project is ready to
begin testing integrated processes.
The hallmark of SAP is its integration. You enter
information once into the system, and that information is
carried through to all other modules, usually in real-time.
It is however, not heavily automated. As one SAP
consultant once said to me "SAP is integrated, not
automated. It requires staff to think about what is going
on; not to watch the system think for them".
Mitigating Risk in Large SAP Projects
203
Now it's time to put that integration to the test.
While the functional team was configuring the SAP system,
another team working in parallel was designing a series of
scenario based integration scripts. The scenarios were
elicited by senior members of the subject organization who
are responsible for each area and who will ultimately sign
off. The team devising the integration test scripts
compared the transaction codes required by the scenario
tests to ensure that all transaction codes in a list prepared
by the team leaders of each SAP module are reflected. If
they are not, they discuss the exception with both the
module team leaders and the people responsible for
approving the script to determine why the exception exists
and then determine a resolution. All exceptions are
reported back to the project managers along with their
resolution.
Before the integration test starts the script is signed off for
completeness by both the business approver and the team
leads of all modules involved in the scripts.
We are now ready to begin the integration test.
Integration Testing The purpose of our integration test is to allow the internal
team an opportunity to see how the system performs in an
integrated end-to-end test of processes. These processes
cross modules and will show if there are any deficiencies.
There are multiple cycles of integration testing. In our
project we have planned on having three. The first cycle
will be slow and contain many defects. The defects will be
Mitigating Risk in Large SAP Projects
204
corrected and after they have been properly unit tested the
changes will be promoted to the quality assurance client.
Once all defects in a scenario have been corrected, and the
changes imported into the quality assurance system, the
script will be once again tested from end-to-end. Thus the
integration script also covers the concept of regression
testing in that it retests even those steps that have already
passed.
As mentioned earlier the first cycle is expected to have
several defects. By the second cycle of our project the
defects are greatly reduced to the point of just a few. By
our third and final cycle there were only a couple of minor
defects and we were deemed ready to move into the user
acceptance testing phase.
They only sign-off's on this testing were from resources
internal to the project. The next phase will involve
members of the business from outside of the project team.
The User Acceptance Test Because of all the risk mitigation strategies we employed
along the way, right from the request for proposal to the
contract terms, from the tactics of scope control to ensuring
our golden client stays golden we sailed through the
integration test. By the time we finished the second cycle
there were only minor defects. Every item on the
requirements tracking spreadsheet was signed off except
for those that related to the defects. Consequently we flew
through the third round of integration test and are now
ready to bring the outside users in and begin our user
acceptance test.
Mitigating Risk in Large SAP Projects
205
Because of our thoroughness throughout this project the
user acceptance test goes very well. We did two rounds.
The first uncovered a few defects. A few were a concern
but once we clarified the new processes to the users they
became less of a concern.
Most of the defects turned out to be training issues. After
assuring them that there would be plenty of training classes
prior to go-live, as well as after, the training issues
disappeared.
There was a bit of grumbling as was to be expected. After
all, we have significantly changed the way the organization
does business, forcing users to conform to the best practices
inherent in the core SAP Enterprise Central Component
system. Some people even quit.
If not for the work of our change management team the
push back might have been even greater. Some people
hate change, so this is a hard time for them. Our change
management people recognize this and have been taking
steps to mitigate it.
Mitigating Risk in Large SAP Projects
206
Luckily we have firm support from the executive sponsor,
who in this case is the Chief Financial Officer. The CFO
is an ardent and vocal supporter of the project because she
(or he) recognizes that SAP will make the organization
more efficient and effective. The organization will be
stronger because of it, so the rewards far outweigh the
risks. We need to make sure that the expected rewards are
realized by safely and effectively implementing SAP.
As mentioned earlier the first round of user acceptance
testing has just a few defects. We quickly correct these
and get the outside users back in to conduct the second
round. This is in fact our fifth round using these scripts
(three times during integration testing and two for user
acceptance testing). The testing goes through without a
hitch this time.
Mitigating Risk in Large SAP Projects
207
The user acceptance test is approved! The business has
signed off on the test and is now ready to move into the go-
live preparation phase!
Go-live Preparation The go-live preparation phase consists of building the
production environment, training and education, and the
milestone of the go/no go decision.
By this time most risks have already been mitigated. The
scope was controlled, the requirements clearly defined, the
vanilla SAP design documented and built, and of course
thoroughly tested.
As mentioned previously, some of the modules are very
time sensitive: they can only be implemented at the
beginning of the fiscal year. Our go-live is that day, and
we have financial modules involved in our implementation.
We cannot afford to miss the go-live date! Things are
clearly looking like we are on track though.
If we do not mess up the production build, do a good job
with conversions, training and communicating, the decision
will be clear: we are going live!
As this short phase progresses the production box is built
by importing the transports that flowed into the quality
assurance box. The training team begins to ramp up their
training. The security team is also finalizing their
authorizations matrix. To do this they use the training
course attendance list. If you do not attend training for a
certain business process you do not get access to the
transaction codes of that process in the production
Mitigating Risk in Large SAP Projects
208
environment. The change management team is diligent
about communicating this relationship between training and
the ability to work within certain SAP processes.
A few weeks before the go-live date, the steering
committee assembles to discuss the go / no-go
recommendation of the project's management team.
Because we have mitigated our risks effectively the
recommendation is clearly and without hesitation to go-
live. We are ready!
Go-live
As the first day of the new fiscal year approaches, which
also corresponds to our go-live date, we prepare the final
configuration steps. These include items like setting the
productive indicator (there are actually several modules
with such an indicator including SAP Financials / General
Ledger) as well as other date related configuration. We
push these through as part of our go-live. The actual
timing of the go-live steps is a long weekend (because this
is the perfect project!). We want as much time on that
weekend as possible to run our last minute conversions as
well as put through the final configuration.
During the go-live weekend, and in the days leading up to
it, we execute a go-live checklist. This is a lengthy list of
activities arranged in order of when they need to be
executed. This list could also be called a "cut-over"
Mitigating Risk in Large SAP Projects
209
checklist. Each action item is checked off and the entire
list is carefully monitored by the project management team.
The check list includes a number of rudimentary tests
executed by the business members of the team to ensure
that the system is functioning as designed before we turn
the system over to the outside users on the specific go-live
day.
Each test is satisfactorily completed. The system is ready.
The security team confirms that the authorizations are in
place as well. On go-live day both they and the Basis team
make changes so that the system can now be used for day-
to-day operations.
We are live!
Post Go-Live Support For the implementation partner the project is coming to an
end. There is just one final deliverable: to help the subject
organization with post-go live support, and to help them
build a sustainable post-go live environment.
The actual post-go live support will be managed through a
help desk. Help desk tickets will be logged for any defects
that pop up after go-live. Most of the items will be minor:
staff who cannot log on, staff who do not know how to log
on, the date format is not correct, and problems accessing a
transaction code are examples of some of the minor issues
that will arise. Many of them will in fact be training issues,
not defects.
Mitigating Risk in Large SAP Projects
210
A few of the defects may not be minor. Perhaps some
configuration did not come into the productive system
correctly, or the document numbering has not been set up.
These will flow through the help desk and eventually be
routed to the project team members who configured those
areas.
As this SAP project winds down the involvement of the
implementation partner comes to a close and there will be a
formal hand off of the management of the system from the
project team to the business' information technology
support group.
Long-term Support The implementation partner is gone. The last member of
their organization left approximately three months after go-
live. Now the business is on its own. It is now one year
past go-live and there have been several challenges.
There were a few issues with the response time of the
system, but your Basis team was able to remedy them
quickly. Also, a few bugs never seen before were
uncovered, but the functional SAP team was able to quickly
locate patches in the SAP OSS system to correct the
problems.
Thankfully, because of the policies and controls your team
put in place during the implementation, the unit test system
has stayed in sync with the golden client. You have also
been able to keep the golden development client pristine by
keeping transactional data out of it.
Mitigating Risk in Large SAP Projects
211
One of your biggest headaches has been human resources.
You have had a few staff members leave. They were
offered more money by other organizations, and for that
reason they left. Luckily you had agreements in place that
anyone that your company invested large sums of money in
to train had to repay that money. SAP training can cost
thousands per week, so having such agreements in place is
critical to safeguarding your organization's investment in
key people.
You also had the foresight to plan for the loss of SAP
expertise over time, and started an SAP expert incubation
program very early in the project. You have a couple of
people who have progressed to the point where they can fill
the shoes of several of the people that left. The incubator
was a smart move: finding and retaining experienced SAP
people is almost impossible. This will be your greatest
challenge in the coming years.
You should also be prepared to bolster the support from
time to time with some of the experienced independent
SAP consultants you can find on websites like Dice.com.
The rates that these consultants charge may seem
exorbitant, but they are probably far less than the rates you
would pay for the same quality of consultants from a large
consulting company. Furthermore they can come in, get
the job done, and depart when it's done.
Summary Let us summarize all of the steps we took to mitigate risk
during our implementation (as well as help ensure that all
of the benefits of implementing SAP are realized):
Mitigating Risk in Large SAP Projects
212
During the request for proposal stage we confined
the scope of the project to "vanilla" SAP.
We found a powerfully placed project sponsor in
the senior most ranks of the organization.
We reduced the number of interfaces in scope to
two.
During the contract phase we included a clause that
s-mods, c-mods, user exits, z tables, and z programs
could only be included in scope if they were paid
for in a separate time and materials based task
order.
During the project prep phase we instituted policies
that required special approval for the above objects.
We also forbade core-modifications.
We employed a change management team that
effectively managed this part of the project. All
project communication made it clear that this
initiative belonged to the functional side of the
business rather than the information technology
side.
We instituted strict controls to safeguard the golden
configuration client, to keep the unit test client in
sync, and to monitor the requirements from
blueprint to the end of the testing cycle.
We educated our team on the policies of the project.
To foster the growth of SAP configuration
knowledge within the business we authorized only
members of that firm to configure SAP. The
implementation partner did not have the ability to
configure in the golden client (their role was only to
give advice).
Mitigating Risk in Large SAP Projects
213
We kept the unit testing process very informal so as
to not unnecessarily burden the process with
unnecessary controls.
Integration testing was more formal. It involved
three complete cycles of scenario based scripts that
contained every transaction code available in our
system. This method of testing also assures proper
regression testing.
User Acceptance Testing was very formal. The
two cycles of testing used the same scripts as those
used in integration testing.
We provided end user training in a timely manner.
For long-term support purposes we instituted an
SAP expert incubator program so that we the
business could grow its own experts over time.
Mitigating Risk in Large SAP Projects
214
Conclusion:
The Ramifications of NOT
Following SAP
Implementation Best
Practices
In my years of SAP consulting I have seen the results of
NOT following SAP implementation best practices first
hand. Here are some of the consequences I have seen:
An implementation partner for a public sector
organization in San Diego was ousted in favor of a
new partner.
A large project implementing an SAP revenue
solution missed its go-live four times before being
able to go live.
A chocolate company had great difficulty meeting
the demand for its product during the busy
Halloween season due to the overwhelming scope
of a big bang implementation of SAP.
A waste and recycling company sued the
implementer for fraud.
A computer manufacturing company had so many
core modifications to the code of their SAP system
that they could not upgrade it.
Mitigating Risk in Large SAP Projects
215
The internal project manager of an SAP project was
sued along with the external implementation
partner.
Bad configuration, bad testing practices, and lack of
communication rendered the SAP system of a fortune 500
company in the food processing business unusable for two
months.
In closing, I have also seen people fired, and their
professional reputations tarnished because the areas of risk
in their areas of responsibility were poorly managed.
Mitigating Risk in Large SAP Projects
216
Glossary of Terms
Mitigating Risk in Large SAP Projects
217
Glossary of Terms
ABAP
ABAP is the programming language that the SAP
Enterprise Central Component is written in. Those who
code it are often called "ABAP'ers". Though SAP is an off
the shelf system, there are still valid times when ABAP
code must be added to the system by your own
programmers. These include corrections that are sent by
SAP, or available in through OSS notes (see glossary), and
user exits.
Account Assignment Element
An account assignment element refers to the individual
accounting assignments made on a given document. The
elements may support financial, management, cost, fund,
project, or any other type of accounting.
ASAP
ASAP, short for "accelerated SAP", is the traditional term
for the SAP methodology project management
methodology promoted by SAP since at least the mid
1990's. It has gone through variations and name changes
over the years (e.g. "Value SAP"), but the term ASAP has
been persistent among SAP professionals for many years.
Authorizations
Authorizations refer to the security profiles set up for each
user that control what the users can create, modify and
Mitigating Risk in Large SAP Projects
218
change. At their basic level authorizations control access
to transaction codes. These transactions codes are then
grouped into user roles which are then assigned to users.
Basis
Basis refers to the technical infrastructure of the SAP
system. It includes the hardware, the software, and the
connectivity of the system. It also refers to the technical
settings of the system.
Basis Team
The Basis Team is responsible for the setup and
maintenance of the hardware that the SAP software resides
on, the application of the software to those boxes, and
maintenance of those boxes. They are also responsible for
the high level technical settings of the system.
Best Practice
The term best practice is term used quite broadly and often
with no supporting evidence to show that a practice is in
fact "best". Standard configurable SAP processes
themselves are based on best practices. Methods
considered "best" practices in this book (such as the
prohibition against core modifications) are based on
experience.
Big Bang
A big bang implementation is one where the full breadth of
desired functionality is deployed. For example, it could
include modules from the human resources, financials, and
Mitigating Risk in Large SAP Projects
219
logistics areas, in addition to Customer Relationship
Management and Business Intelligence. Aside from
functionality, the term big bang could also be used to refer
to the deployment of SAP to every business unit, and every
geographic area (including all countries where the
organization operates). See also "Phased".
Blueprint
A blue print is the primary design document for the "to-be"
vision of the SAP system. Best practice is that it is based
on requirements gleaned from a study of the subject
organization's "as-is" process. It usually includes a
discussion of gaps between requirements and SAP
functionality and how they will be overcome.
Bolt-on
A "bolt-on" refers to a software package that is used to
perform functions within SAP, but that is not part of the
integrated SAP Enterprise Central Component system.
Most often they are made by firms other than SAP, for
example by one of the many sales and use tax package
vendors (Vertex for example).
Bolt-ons can further be differentiated into those that were
made by SAP, those that are certified by SAP, and those
that are not certified by SAP. Obviously the non-certified
software packages carry the most risk.
Box
A "Box" refers to a physical computer processing unit
(CPU). From a configuration perspective the key
Mitigating Risk in Large SAP Projects
220
consideration is that cross client configuration cannot jump
from box to box, but this type of configuration can affect
all of the clients within the box that it is housed in. Most
configuration items are not cross client, so they only affect
one particular client within the box.
Break Fix
After an SAP system has "gone live" and entered the
support phase, a break-fix is any defect which is contrary to
what the approved business blueprint and the functional
specification documents say.
Business Process
A business process is a series of activities and SAP
transaction codes that accomplish a business task. An end-
to-end business practice, or a "cradle-to-grave" business
process is one that traces the activities back to a trigger
point and then carries the activities through a number of
steps and a number of transaction codes (that often cross
SAP modules), until it reaches a point where no further
action is possible.
Certified
The term "Certified" can be used with reference to a person
who has gone through one of the SAP academies for
disciplines such as financials and controlling, human
capital management, or public sector integration. It can
also refer to complimentary third party software that has
been "certified" for use with SAP.
Mitigating Risk in Large SAP Projects
221
Client
A client is an organizational unit where multiple company
codes (an SAP organizational structure representing a
distinct legal entity) are contained. Most configuration
items do not cross clients, but there are some configuration
activities that are cross client. As the name suggests, these
are configuration changes that will affect all of the clients
within a box.
Company Code
A company code is an SAP organizational structure
representing a distinct legal entity. In the private sector
these are usually incorporated entities that require a
separate profit and loss statement and a separate balance
sheet for statutory financial reporting.
Configuration
Configuration refers to the setting of flags, switches, and
calculations in the SAP Implementation Guide (also called
the IMG). These activities turn off and on standard SAP
code. The processes that result are built on best industry
practices.
See the Glossary entry for "Implementation Guide" to see a
screen shot of it.
Controlling Module
The Controlling Module is the name given by SAP to the
area that contains the functionality for management and
cost accounting. It is abbreviated as CO, and contains its
Mitigating Risk in Large SAP Projects
222
own ledger that operates parallel to the General Ledger of
the Financial (FI) module.
Conversion
For our purposes this refers to the conversion of data from
the legacy system to the New SAP system. The data could
be master data, table data (for example choices in a
configured list of responsible managers), and occasionally
transaction data.
Core Modification (also known as a "Core Mod")
A core modification involves the insertion of ABAP code
into a standard delivered SAP program, where no provision
by SAP has been made to do so. For example, if
transaction code FB01 is not a perfect fit for a business
process, the insertion of code that enhances the
functionality so that it more closely fits the business
process is a called a core modification (assuming that SAP
did not provide something like a user exit to facilitate this
action). The inclusion of code in such a manner voids
SAP's warranty and support for this specific transaction, so
if there are problems with it you cannot rely on SAP for a
fix.
Furthermore, future upgrades will overwrite your code with
the original code, essentially breaking your process. When
you upgrade, you will also be susceptible to changes that
SAP has made to the process and the transaction code that
may no longer be compatible with the enhancement your
team made.
Mitigating Risk in Large SAP Projects
223
There are also changes that you can make in the
configuration panel (i.e. the Implementation Guide or the
IMG) that require a developer key. For our purposes we
will call these "mini" core modifications. The fact that a
developer key is required serves as a warning that a core
modification may be in process.
The concept of a core modification does not include
changes where SAP has designed a break point in their
code where you can insert your own script. This is called a
user exit, and it is not considered a core mod. The
important distinction is that SAP has designed it so that you
can include your own code in a user exit, and an upgrade
will not over write this change.
In addition, the concept of a core mod does not encompass
Z programs, Z tables, or Z transactions. The use of the "Z"
prefix places the objects in the customer name space. By
placing a Z object in the customer name space it will not be
overwritten by an upgrade (as opposed to core
modifications that will be overwritten). Thus if you have a
developer copy the transaction code FB01 into a new
transaction code ZFB01, and then copy the underlying
program of this transaction SAPMF05A to ZSAPMF05A,
any modifications you do to this Z program are not a core
mod. Consequently the best practice should you
absolutely need to make changes is to copy native SAP
code and prefix it with a Z before you make your
alterations. However, the new Z program is still
susceptible to future changes to SAP and will not be
supported by them. In this scenario you still have the
Mitigating Risk in Large SAP Projects
224
original code of the original program intact and you can
revert back to it at any time in the future.
Customer Message
A customer message denotes a message created by an SAP
customer relating a possible product error in the software.
Customer messages are created in the SAP online support
system (which is referred to by the unofficial acronym
OSS).
Cut-over
Cut-over refers to the time period when a number of steps,
defined by the cut-over plan are initiated and carried out,
eventually culminating in the official go-live day. The cut-
over period usually extends for as long as a month before
and a month after the go-live date.
Development (activity)
In SAP, the concept of development means any activity
other than configuration (see definition earlier) that adds
ABAP code to the SAP Enterprise Central Component
system functions or creates code for the purposes of
interfacing with the SAP Enterprise Central Component
system.
Development (client)
Development in the context of the system landscape refers
to the client where the initial configuration or ABAP
development work is done. These clients reside on
Mitigating Risk in Large SAP Projects
225
physical boxes that are different than those used for quality
assurance or production purposes.
End-user
An end-user is a member of the business who uses SAP to
conduct the day-to-day business of the organization.
End-user documentation
End-user documentation is an instruction manual intended
to help the people who conduct the day-to-day business of
the organization on the live SAP system.
Enhancement
The term enhancement is very general in nature and can
refer to one of many possible changes to a live SAP system.
The enhancement could be accomplished by making
changes exclusively in the SAP Implementation Guide,
through the use of ABAP programming, or by some other
form of programming. Enhancements are very controlled,
with their movement through the SAP landscape
accomplished via transports that are moved by the Basis
team.
Enterprise Central Component (ECC)
The Enterprise Central Component is the core of SAP's
product offerings. It is the system SAP has built to handle
most business processes within an organization. It
comprises a multitude of modules in a highly integrated
real-time system that can handle logistics, financials, and
human resources. The "hallmark" of the SAP Enterprise
Mitigating Risk in Large SAP Projects
226
Central Component is the real-time integration between the
modules within it.
Enterprise Resource Planning (ERP)
Enterprise resource planning, also known as ERP, is a
blanket term for many different software packages that can
run a wide variety of business processes. SAP is the
leading vendor of ERP packages.
Functional
Functional refers to the business aspect of data flow within
SAP. For example, the function of the system is to post
vendor invoices. See also "technical".
Functional Specification
A functional specification documents the way a certain
report, interface, conversion program, enhancement, form,
or workflow is meant to work from a business perspective.
Specifically it lists the business requirements. See also
technical specification.
Functional Team
The term "functional team" refers to those people who are
involved in how the standard SAP system functions from a
business perspective. These people tend to be business
people: people who were managers, business analysts,
accountants, and engineers prior to working with SAP.
They will usually have degrees in business, MBA's,
degrees in disciplines like mechanical or civil engineering,
or CPA's. Configuration of the standard SAP processes is
Mitigating Risk in Large SAP Projects
227
undertaken by members of this team. This group works
with the technical team by providing them functional
expertise as they develop objects like interfaces.
Gap (functional)
In the world of SAP a functional gap indicates a functional
deficit between what SAP standard configuration can
support, and what the business requires in a certain
business process. There are also other gaps within the
framework of an SAP project such a technical and
performance, but it is most commonly used with reference
to business functionality.
General Ledger (GL)
General ledger is a common accounting term denoting the
main ledger that statutory financial reports are derived
from. In SAP this module is part of the financials module
(SAP FI).
Golden Client
The golden client is the starting point for all system
configuration that is meant to be migrated to the production
client. It is located in a development box and contains
only configuration and master data. Transaction data is
not allowed in this client because it precludes certain kinds
of configuration from being changed in the future (for
example: the Funds Management Update Profile).
Go-live
Mitigating Risk in Large SAP Projects
228
The term go-live is the prevalent term in the world of SAP
for the formal day that the system is viewed as being
activated for general use in the business. Usually this
means the first day that most end-users are able to log in
and carry out their day-to-day duties. See also "cut-over".
Industry Solution
The SAP Enterprise Central Component is available in
different industry solutions, for example: SAP Insurance,
SAP Banking, SAP Public Sector Management, and SAP
Utilities. Each industry solution has slight variations to
make SAP more applicable to the industry. For example:
the utilities version has a different nomenclature for SAP
Plant Maintenance (PM) objects and uses a unique billing
and invoicing solution (ISU Billing and ISU invoicing),
whereas the public sector solution has a unique tool called
FMDerive to aid in its unique fund accounting and budget
requirements.
Below is a partial list of SAP Industry Solutions:
Mitigating Risk in Large SAP Projects
229
Implementation
For our purposes, an implementation refers to the initial
installation of SAP, or part of SAP. A Greenfield
implementation refers to an implementation where no SAP
system has previously existed.
Implementation Guide (IMG)
The Implementation Guide (abbreviated to IMG) is the part
of SAP where configuration is performed. In the IMG, all
of the standard SAP functionality can be turned on, turned
off, and modified to the extent that standard SAP allows.
Tables used for drop down menus can also be populated, as
can calculations. The IMG can be accessed through the
transaction code SPRO.
Because of the power of the IMG, it is carefully controlled.
It cannot be accessed at all in any client by most users.
Configuration personnel have access to it the development
client, but have read-only access in the quality assurance
and production environments.
This is what the implementation guide looks like:
Mitigating Risk in Large SAP Projects
230
Implementation Partner
An organization that is intent on implementing SAP, or any
other large project involving SAP, will usually hire an
implementation partner. The "implementation partner"
refers to a firm that has expertise in SAP (and business
transformation in general) that will help the business
achieve the objectives of the project. Generally speaking
the implementation partner will also assist the business in
avoiding unnecessary risk when implementing the
software. Another term for implementation partner is
software integrator or systems integrator.
Instance
Sometimes different SAP landscapes (see definition) are
required to support different geographic regions (for
example one in Asia, one in North America) or when
multiple industry solutions are required for one
organization (for example: an organization that needs to run
the SAP utilities solution and the SAP public sector
management version for different aspects of their business.
Integration
Integration refers to data flow between modules. SAP is
referred to as integrated because data entered once into the
system flows seamlessly between modules in real-time.
Integration Test
Integration testing refers to the testing of an end to end
business process (also known as cradle to grave testing).
The trigger for the beginning of a process is identified and
Mitigating Risk in Large SAP Projects
231
that is where the test starts. The process continues from
SAP module to SAP module until it is complete. The
process tends to be quite formal with a script that is usually
based on real life scenarios in the organization.
Interface
A program built to handle the data flow between the core
SAP Enterprise Central Component program and external
programs. Usually these external programs are not
manufactured by SAP.
Landscape
In the world of SAP, a landscape refers to a complete
infrastructure that supports separate development, testing
(staging), and production boxes (see "box"). This three
tiered landscape is considered a minimum, there are often
more environments than this at an SAP installation site.
Legacy Systems Migration Workbench (LSMW)
The Legacy Systems Migration Workbench is a tool
provided in the standard SAP Enterprise Central
Component for converting data into SAP.
Mitigating Risk in Large SAP Projects
232
Lessons Learned Session
"Lessons Learned" workshops are a series of meetings
conducted in the interest of continuous improvement to
improve the implementation process by examining what
worked and what did not work. From a legal perspective,
such a session will be closely examined should litigation
arise down the road (refer to the section on litigation
proofing for more information).
Live
In the SAP world, a “Live” system is one where the
productive system is in general business use. Such a state
follows the day of “Go-live”.
Mitigating Risk in Large SAP Projects
233
"Mini" Mods
For our purposes a modification to SAP code that is
facilitated by SAP itself is what some professionals in the
industry call a mini modification, or a "mini-mod" for
short.
Included in this definition of mini mods are user exits,
customer includes, s-mods, and c-mods. An example of
such a change to SAP is the change of the label for the field
"Cost Center" to "Department".
There are also changes that you can make in the
configuration panel (i.e. the IMG) that require a developer
key. For our purposes we will call these "mini" core mods
as well.
Extending our definition, there are items in the
configuration panel (i.e. IMG) that SAP strongly
recommends that you do not change, however these items
do not require a developer key to alter. Unfortunately,
there are no system controls to prevent such changes by
your configuration personnel.
Mini mods, like core mods, are susceptible to being
overwritten in an upgrade (though much less so). The
Basis team can run job prior to an upgrade which shows all
such objects contained in your SAP system.
Though these changes are minor compared to a true core
mod, it is still recommended that they be avoided because
they tend to cause problems later on during the support
phase of the project, especially during upgrades.
Mitigating Risk in Large SAP Projects
234
Module
The SAP Enterprise Central Component is divided into a
series of modules that are specifically designed for a
general function. For example, management and cost
accounting are handled by the Controlling module, also
abbreviated to CO. The Materials Management module,
also called MM, is designed to handle the logistics of
physical materials processing.
When a company buys the SAP Enterprise Central
Component, they receive software that has all of these
modules in it. None of them are active until the
configuration teams activates them, but they are all present
Thus, an organization may be running on SAP, but they do
not realize the code for an out of scope module like Quality
Management (QM) is already in their productive system
lying dormant.
Also, generally speaking, all of these modules are
seamlessly integrated in real time. If you enter data in one
module, it is passed on to all subsequent modules and never
needs to be entered again. This powerful integration is the
hallmark of SAP.
There are a few modules that are not integrated real time to
the general ledger, such as contract accounting (FICA), but
they are by far in the minority.
Mitigating Risk in Large SAP Projects
235
OSS (Online Support System)
The term "OSS" is the informal term used by people
involved with implementing and supporting SAP to refer to
the system provided by SAP to research issues that often
cannot be resolved through configuration or user training.
The acronym OSS has survived from a time when SAP's
help system was called the "online support system". The
same system has since gone through several name changes.
Often the OSS system provides corrections that can be
applied to your system to resolve the issue. In order to
access the OSS system your BASIS administrator must
create an ID for you to use that requires a password.
Using the OSS system you can also set up access for SAP
to review the issue in your system and give you an opinion.
This will sometimes result in SAP logging into your system
and directly fixing the problem, or developing a fix
specifically to resolve the situation.
OSS Note
An OSS note is a document found in SAP`s online support
system repository that contains information that can be
Mitigating Risk in Large SAP Projects
236
used to resolve a problem in its software. Many OSS
notes contain Corrections, which contain code that can be
used to patch the system, while other notes contain
programs that can fix the problem. Some OSS notes
contain recommendations on how to solve the problem
without the use of additional code or programs.
Below is a sample of what the SAP OSS database looks
like as at the time of writing. (Courtesy of SAP AG)
Package Slam
A package slam is a somewhat derogatory term used by
SAP professionals to denote an SAP implementation where
short cuts from best practice are used to compress the
timeline of the project. Short cuts can include: no
blueprint or a blue print without a review of the as-is,
functional or technical specification documents are
skipped, or less (or no) integration and or user acceptance
testing cycles. Package slams are extremely risky for both
the business and the implementation partner. A package
slam is often motivated by onerous obligations in a
contract.
Mitigating Risk in Large SAP Projects
237
Phased Approach
A phased approach attempts to break up what would be
much larger SAP project (with a much bigger scope) into a
series of smaller projects with a tighter scope. Such an
approach presents less risk to the business.
Production
Production refers to the actual client that the organization
performs its day-to-day business on. It is a carefully
controlled environment and one where configuration is not
possible.
Project Management Office (PMO)
The project management office is as general term for the
team in charge of the general management of an SAP
project. It includes the project directors, project managers,
and administrative staff.
Prototype
A prototype is a configured SAP demonstration system
usually created in a sandbox environment for the purposes
of presenting the business with a preliminary view of the
proposed SAP solution. It is sometimes called a "straw
man".
Quality Assurance Client
The quality assurance client (also known as QA) is the
client where integration testing and user acceptance testing
Mitigating Risk in Large SAP Projects
238
are performed. This client always resides on a physical box
different than the boxes where the development and
productive instances occur.
Real Time
In system integration the term “real time” refers to
integration between modules that does not require a batch
program to be run. In real time integration, data passes
from one module to another immediately. In particular,
accounting data from sub-ledgers like accounts payable are
summarized and sent over to the general ledger
immediately. For example, if you post a document in the
accounts payable module and look at the general ledger for
the account that was credited you will immediately see the
impact.
Realization
The aspect of an SAP project concerned with actually
building the SAP solution, either through the use of the
configuration panel (the IMG), or through development.
Reconciliation
The term reconciliation is a general accounting term. It
refers to the activity of proving that a financial balance is
correct using various accounting methods. One of the best
known reconciliation is that of the bank account. The
general ledger bank account balance is simply compared to
the statement produced by the bank. An itemized statement
accounting for differences between the two balances is used
to prove the integrity of the general ledger account.
Mitigating Risk in Large SAP Projects
239
Refresh
A refresh refers to the copying of data and configuration
usually from the Production client to another client, often
the quality assurance client or a sandbox.
Regression Test
A test performed to assure that functionality that had
previously performed satisfactorily still functions correctly
after a change has been put through that could have
negatively affected it.
Re-implementation
Occasionally a new SAP implementation replaces a
preexisting SAP implementation in its entirety. In such an
implementation the old SAP system is treated like a legacy
system and all other phases of a normal SAP green field
implementation are carried out. There are several reasons
to do a re-implementation: the prior implementation may
have been a poor one with the modules not being used in
the way they were meant. Another reason is that there may
have been a number of core modifications done to the old
system that have made upgrading to the latest version of
SAP impossible.
The term can also be used for the re-deployment of a
module or several modules to replace the exact same
modules in an existing SAP system. In this case the
module or modules are “re-imagined” in a new business
blueprinting phase and the system is reconfigured
according to the new design. There are many situations
Mitigating Risk in Large SAP Projects
240
where a reimplementation of a module(s) may be required:
it may have been a bad implementation with the modules
not being used in the way they were intended, or a new
factor may have emerged that may have necessitated a
complete overhaul of the way the module is used (for
example a change to International Financial Reporting
Standards).
Release Notes
SAP's Release Notes highlight the differences between a
previous version and the one that these notes document.
They can be found in SAP's service portal.
Request for Proposal (RFP)
An invitation sent by an organization to a select group of
vendors inviting them to put forth a proposal (for SAP
integration services for example).
Requirements
The term “requirements” refers to the business needs of an
organization that underlie certain functions and processes.
For example, if an organization is utilizing International
Financial Reporting Standards then one of the business
requirements of the SAP Asset Accounting module is that it
carries a book of depreciation that is in accordance with
those standards.
Requirements Traceability Matrix
A requirements traceability matrix is a document that lists
every business requirement discussed in the business
Mitigating Risk in Large SAP Projects
241
blueprint and then traces the requirements through each
configuration and testing phase so that there is visibility as
to the status of the requirements being satisfied. The
requirements traceability matrix can also be used to
indicate the status of the project as a whole.
RICEFW
The acronym RICEFW refers to the combined development
objects of Reports, Interfaces, Enhancements, Forms, and
Workflow.
Scope
The scope of an SAP project refers to the breadth of
functionality to be deployed, the modules to be deployed,
the interfaces to be deployed, and sometimes the custom
development that will be generated from a project.
Scope Creep
Scope creep refers to an increase in scope such that the
scope is now bigger than it was originally envisioned.
Script
A script is a testing document that is used in various tests,
especially integration and user acceptance. It is usually
scenario based in that it incorporates a real life trigger to a
chain of business transactions and processes, and follows
them right through to the last possible event in the chain.
Mitigating Risk in Large SAP Projects
242
Security
The term “security”, when used in an SAP context, has a
different meaning than the usual information technology
definition. Security for SAP refers to the authorization
schemes that are managed by the security team. The
authorizations determine who can do what in the SAP
system. It does not refer to security against threats such as
that posed by a virus.
Solution
Out of a list of alternatives, a solution is the recommended
course of action to solve an issue.
Solution Manager
The Solution Manager system is a stand-alone product that
SAP has designed for use with its software offerings.
Solution Manager can be used many different ways. Often
it is used as a document repository for things such as
blueprints, functional specification documents, technical
documents, landscape diagrams, and any other document
pertaining to SAP. It can also be used as a work
management system (with tickets).
Scope
Scope refers to the list of functionality and changes that are
within the mandate of the team to work on and transform.
Mitigating Risk in Large SAP Projects
243
Standard SAP
The term “standard SAP” refers to functionality in the SAP
Enterprise Central Component that can be achieved through
configuration alone. The term can be loosely applied to
SAP functionality that required user exits to achieve as
well. The term does not include functionality achieved by
means of core modifications to SAP’s code, solutions that
use Z-programs, or solutions that use Z-tables.
Statement of Work
A statement of work is a document that lists the details of
an engagement including the deliverables, timeline, and
scope. It is often a binding contractual agreement that can
be appended to a general contract.
Mitigating Risk in Large SAP Projects
244
Steering Committee
A steering committee is a group composed of senior
executives from the business and its implementation
partner, as well as the leaders of the project itself. The
project sponsor must always be part of the committee.
Stress Test
A stress test is one that is designed to emulate the actions of
many processes being run simultaneously by many users.
It is usually conducted by the Basis team.
String Test
A string test refers to a string of transaction codes involved
in a process that are used in sequence to test a process. It is
more comprehensive than a unit test, but less
comprehensive than an integration test. During an
implementation the integration test will encompass all
transaction codes, and thus they also constitute a string test.
Support
Support refers to a period after the SAP system or change
has gone live when the team is in "break/fix" mode
addressing any reported defects in the system. Many of
the perceived defects tend to be training issues.
Support Pack
A support pack consists of multiple OSS bug fixes that are
applied all at once to an SAP system. It is likened to a
mini-upgrade, but does not encompass any new
functionality.
Mitigating Risk in Large SAP Projects
245
System Integration – see Integration
System Integrator – see Implementation partner
Technical
In general terms the word “technical” in an SAP context
means any functionality attained by a means other than
configuration via the Implementation Guide.
Technical Specification Document
Usually called a tech spec, the technical specification
document outlines the programming logic necessary for the
requirements of a functional specification document to be
realized.
Technical Team
The technical team consists mostly of programmers who
take care of the actual coding of ABAP programs and other
types of programs. They build interfaces, code ABAP
enhancements, and carry out things like user exits. They
work closely with the members of the functional team.
Technical Upgrade
A technical upgrade refers to the movement of an SAP
system to a higher version without activating any of the
new functionality available in that version.
Testing Team
A team charged with carrying out integration testing, string,
and regression testing. If the team is composed of end-
Mitigating Risk in Large SAP Projects
246
users they will be charged with carrying out user
acceptance testing (UAT) as well. However, the team that
performs UAT should not be the same as the team that
carries out any other form of testing. Unit testing is
outside the scope of testing for either team as it is
performed by the people who made the change.
Timeline
A timeline refers to the duration of a project. A typical
timeline of a large SAP project using the ASAP
methodology is nine to 12 months.
Transaction Code
A transaction code is a short cut for executing a function in
SAP. For example, typing in transaction code FB01 will
lead you to the screen for entering a general journal entry
into the general ledger without having to go through the
menu system.
Transport
Transports are the mechanism, administrated by the Basis
members of your SAP team, by which configuration and
development changes are moved between the development
clients and the quality assurance clients (also known as
staging) , and once they are successfully tested to the live
production client.
Unit Testing
A "unit test" refers to testing within a module, often within
a single transaction of that module. This type of testing
Mitigating Risk in Large SAP Projects
247
tends to be informal and conducted by the person who
configured or developed the change.
Upgrade
An upgrade refers to the process of elevating the version
level of an SAP system to a version higher than the existing
one. Upgrades do not have to be sequential. For example,
an organization currently on version 4.7 can upgrade
directly to the latest version of SAP without having to
upgrade to the versions between it and the latest version.
User Acceptance Test (UAT)
A user acceptance test is a test performed by the users to
give them an opportunity to approve a change prior to it
being moved to the production client. It is usually
performed in a quality assurance client (sometimes called a
staging client). In an implementation the user acceptance
test usually follows the same scripts as those used for
integration testing. After the system is live the user
acceptance test will resemble more of a unit test or a string
test. The bigger the impact of change, the more
comprehensive the testing and the closer it gets to an end-
to-end integration test.
User Exit
A user exit refers to a change to a standard SAP program's
code where SAP has provided an insertion point so that an
ABAP developer from the business can insert their own
code. This is called a user exit, and it is not considered a
core modification to the system. The important distinction
Mitigating Risk in Large SAP Projects
248
is that SAP has designed it so that your team to include its
own programming logic. An upgrade will not overwrite this
work.
Despite this type of change being specifically designed for
your team to insert its own code it is still ABAP
development that will require a Functional Specification
document as well as a Technical Specification document.
It requires a considerable amount of work (relative to
configuration) and should be avoided if possible.
Vanilla SAP
A "vanilla SAP" project refers to the implementation of an
SAP system without the use of any core modifications to its
code. A more extreme definition of this would also
include that a vanilla SAP system has no Z-tables and no Z-
programs.
Volume Test
A volume test is one that is designed to emulate the actions
of many processes being run simultaneously by many
users. It is usually conducted by the Basis team.
War Room
In SAP project terms a "war room" refers to a large space
housing the majority of the SAP project team. Such a
room has no walls. This open environment promotes
quick communication between team members, and allows
others on the team to hear conversations that the speakers
may not think are relevant to them, but are.
Mitigating Risk in Large SAP Projects
249
Work Breakdown Structure Element
A work breakdown structure element in the SAP Project
Systems module is a cost collector that reflects a logical
piece of work on a project. It is also a common term
utilized in project management outside of SAP circles.
Z-Objects
In SAP a "Z object" is any programming that has a Z
prefix. It can be a program, table, or transaction. The
significance of the Z is that it places the programming in
the SAP customer name space protecting it from being
overwritten by upgrades.
Z-Programs, Z-Tables, and Z-Transactions
The use of the "Z" prefix places the objects in the customer
name space. Such objects will not be overwritten by an
upgrade. Thus if you have a developer copy the
transaction code FB01 into a new transaction code ZFB01,
and then copy the underlying program of this transaction
SAPMF05A to ZSAPMF05A, any modifications you do to
this Z program are not a core modification. Consequently
the best practice should you absolutely need to make
changes is to copy native SAP code and prefix it with a Z
before you make your alterations. However, the new Z
program is still susceptible to future changes to SAP and
will not be supported by them. In this scenario you still
have the original code of the original program intact and
you can revert back to it at any time in the future.
Mitigating Risk in Large SAP Projects
250
Of these objects the Z transaction is the lowest risk and
requires the least amount of labor to develop. On the other
hand Z-programs and Z-tables involve considerable time to
develop and can materially change the performance of
SAP.
In an extreme example of the use Z programs, I once had a
client that had essentially designed their own module for
management accounting purposes through the extensive use
of Z programs and Z tables. These Z program and tables
were extremely buggy. They also ignored the fact that
SAP already had a well established module for
management accounting called the Controlling module
(CO) that incorporates best practices. The poorly
performing custom module based on Z programs and tables
had to be deactivated, and the CO module implemented in
its place.
Because of examples such as the above I recommend that Z
programs and Z tables be avoided in your SAP project, and
be considered comparable to core modifications.
Mitigating Risk in Large SAP Projects
251
Appendices
Mitigating Risk in Large SAP Projects
252
Appendices
Appendix 1 - SDLC and the ASAP
Project Management Methodology Below is a generic graphic for a software development
project. Though it implies the development of custom
development, the same general stages apply to large
projects involving ERP package software like SAP. All
project methodologies at a high level look like this, though
different terminology may be used, and the five phases
further subdivided.
Below is the ASAP methodology. This is the
methodology developed by SAP many years ago, rebranded
several times, called different things over the years, but still
the same as it was in the earlier days of SAP. If you look at
Mitigating Risk in Large SAP Projects
253
the generic SDLC representation above you will see many
similarities.
The ASAP Project Management
Methodology ASAP stands for Accelerated SAP. Its purpose is to help
design SAP implementation in the most efficient manner
possible. Its goal is to effectively optimize time, people,
quality and other resources, using a proven methodology to
implementation. ASAP focuses on tools and training,
wrapped up in a five-phase process oriented road map for
guiding implementation.
The road map is composed of five well-known consecutive
phases:
Mitigating Risk in Large SAP Projects
254
• Phase 1 Project Preparation
• Phase 2 Business Blueprint
• Phase 3 Realization
• Phase 4 Final Preparation
• Phase 5 Go-Live and support
ASAP Methodology - Phase 1: Project
Preparation Phase 1 initiates with a retrieval of information and
resources. It is an important time to assemble the necessary
components for the implementation. Some important
milestones that need to be accomplished for phase 1
include
• Obtaining senior-level management/stakeholder
support
Mitigating Risk in Large SAP Projects
255
• identifying clear project objectives
• architect an efficient decision-making process
• creating an environment suitable for change and re-
engineering
• building a qualified and capable project team.
Senior level management support:
One of the most important milestones with phase 1 of
ASAP is the full agreement and cooperation of the
important company decision-makers - key stake holders
and others. Their backing and support is crucial for a
successful implementation.
Clear project objectives:
Be concise in defining what your objectives and
expectations are for this venture. Vague or unclear notions
of what you hope to obtain with SAP will handicap the
implementation process. Also make sure that your
expectations are reasonable considering your company's
resources. It is essential to have clearly defined ideas, goals
and project plans devised before moving forward.
An efficient decision making process:
One obstacle that often stalls implementation is a poorly
constructed decision-making process. Before embarking on
this venture, individuals need to be clearly identified.
Decide now who is responsible for different decisions
along the way. From day one, the implementation decision
Mitigating Risk in Large SAP Projects
256
makers and project leaders from each area must be aware of
the onus placed on them to return good decisions quickly.
Environment suitable for change and re engineering:
Your team must be willing to accept that, along with new
SAP software, things are going to change, the business will
change, and information technology enabling the business
will change as well. By implementing SAP, you will
essentially redesign your current practices to model more
efficient or predefined best business practices as espoused
by SAP. Resistance to this change will impede the progress
of your implementation.
ASAP Methodology - Phase 2- Business
Blueprint SAP has defined a business blueprint phase to help extract
pertinent information about your company that is necessary
Mitigating Risk in Large SAP Projects
257
for implementation. These blueprints are in the form of
questionnaires that are designed to probe for information
that uncovers how your company does business. As such,
they also serve to document the implementation.
Below is a description of the Business Blueprint phase
published by SAP on its website:
Each business blueprint document essentially outlines your
future business processes and business requirements. The
kinds of questions asked are germane to the particular
business function, as seen in the following sample
questions:
1) What information do you capture on a purchase order?
Mitigating Risk in Large SAP Projects
258
2) What information is required to complete a purchase
order?
Accelerated SAP question and answer database:
The question and answer database (QADB) is a simple
although aging tool designed to facilitate the creation and
maintenance of your business blueprint. This database
stores the questions and the answers and serves as the heart
of your blue print. Customers are provided with a customer
input template for each application that collects the data.
The question and answer format is standard across
applications to facilitate easier use by the project team.
Issues database:
Another tool used in the blueprinting phase is the issues
database. This database stores any open concerns and
pending issues that relate to the implementation. Centrally
storing this information assists in gathering and then
managing issues to resolution, so that important matters do
not fall through the cracks. You can then track the issues in
database, assign them to team members, and update the
database accordingly.
ASAP Methodology - Phase- 3 - Realization: With the completion of the business in phase 2,
"functional" experts are now ready to begin configuring
SAP. The Realization phase is broken in to two parts.
1) Your SAP consulting team helps you configure your
baseline system, called the baseline configuration.
Mitigating Risk in Large SAP Projects
259
2) Your implementation project team fine-tunes that system
to meet all your business and process requirements as part
of the fine tuning configuration.
The initial configuration completed during the base line
configuration is based on the information that you provided
in your blueprint document. The remaining approximately
20% of your configuration that was not tackled during the
baseline configuration is completed during the fine tuning
configuration. Fine tuning usually deals with the exceptions
that are not covered in baseline configuration. This final bit
of tweaking represents the work necessary to fit your
special needs.
Configuration Testing:
With the help of your SAP consulting team, you segregate
your business processes into cycles of related business
flows. The cycles serve as independent units that enable
you to test specific parts of the business process. You can
also work through configuring the SAP implementation
guide (IMG). A tool used to assist you in configuring your
SAP system in a step by step manner.
Knowledge Transfer:
As the configuration phase comes to a close, it becomes
necessary for the Project team to be self-sufficient in their
knowledge of the configuration of your SAP system.
Knowledge transfer to the configuration team tasked with
system maintenance (that is, maintenance of the business
processes after Go-live) needs to be completed at this time.
Mitigating Risk in Large SAP Projects
260
In addition, the end users tasked with actually using the
system for day-to-day business purposes must be trained.
ASAP Methodology - Phase 4 - Final
Preparation: As phase 3 merges into phase 4, you should find yourselves
not only in the midst of SAP training, but also in the midst
of rigorous functional and stress testing. Phase 4 also
concentrates on the fine tuning of your configuration before
Go-live and more importantly, the migration of data from
your old system or systems to SAP.
Workload testing (including peak volume, daily load, and
other forms of stress testing), and integration or functional
testing are conducted to ensure the accuracy of your data
and the stability of your SAP system. Because you should
have begun testing back in phase 2, you do not have too far
to go until Go-live. Now is an important time to perform
preventative maintenance checks to ensure optimal
performance at your SAP system. At the conclusion of
phase 4, take time to plan and document a Go-live strategy.
Preparation for Go-live means preparing for your end-users
questions as they start actively working on the new SAP
system.
Mitigating Risk in Large SAP Projects
261
ASAP Methodology - Phase 5 - Go-live and
Support: The Go-live milestone is itself is easy to achieve; a smooth
and uneventful Go-live is another matter altogether.
Preparation is the key, including attention to what-if
scenarios related not only to the individual business
processes deployed but also to the functioning of
technology underpinning these business processes and
preparation for ongoing support, including maintenance
contracts and documented processes and procedures are
essential.
Mitigating Risk in Large SAP Projects
262
Mitigating Risk in Large SAP Projects
263
About the Author
Lawrence Compagna has been providing SAP consulting
services for almost 20 years. He is a CPA who was
certified as an SAP Consultant in 1998 and received a
certificate in SAP's ASAP Project Management
methodology in 2001
In his long career consulting on the SAP ERP system he
has been a team leader of SAP functional consultants, an
SAP solution architect, and an SAP project manager. He
has also served as the advisor to the chief operating officer
of one of the world's largest SAP integrators performing
"best practices" audits of SAP projects with budgets of over
$20 million dollars. He has consulted to a variety of
industries including manufacturing, telecommunications,
utilities, professional services, as well as public sector.
Among his past clients include: the US Army, Compaq
Computers (now part of HP), Deloitte Consulting, the State
of California (Judicial), Mercedes Benz, two Sprint
affiliates, and the United Nations.
He has also been engaged as an expert in SAP functional
best practices by either the defendants or the plaintiffs in
several SAP related litigation cases, including one of the
largest in history.
Mr. Compagna's successful leadership over the merger of
two NASDAQ traded telecommunications companies on
the SAP platform is among his career highlights.
He can be reached via email at [email protected]