mitigating risk in large sap projects

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.


3


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


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


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


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


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


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


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.


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


12

solution being implemented as such changes are likely to

encompass the greatest risks (and also the greatest rewards)

to an organization.


13

Introduction


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:


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


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


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


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.


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


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.


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


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


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.


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.


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.


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


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.


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:


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


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.


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


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


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


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


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.


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.


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.


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


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


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


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


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)


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.


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


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!"


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


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:


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,


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!


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.


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.


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.


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


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.


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


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.


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


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.


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.


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.


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.


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


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


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


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.


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


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


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


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


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


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


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


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


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


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


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.


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.


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.


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


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.


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.


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.


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


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


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


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),


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


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.


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


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.


91

The Five

Basic Phases

of an SAP

Project and the Risk

Inherent in Each


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


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.


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


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


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


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.


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.


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.


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


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.


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.


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


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


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.


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


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.


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.


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.


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.


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.


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:


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


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.


115

Risk Management

for SAP Projects

“Management must manage!” ~ Harold Geneen


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.


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


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.


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


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.


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.


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.


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


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.


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


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.


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


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


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.


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


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!


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.


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.


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


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:


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.


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


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


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.


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.


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


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.


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


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.


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


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.


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.


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


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!


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.


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


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.


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


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


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


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


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.


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


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.


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


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


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


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


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.


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.


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


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.


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


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


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


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.


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


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


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


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.


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


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


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


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.


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


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


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


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.


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


185

The "Perfect" SAP

ECC Project

A Hypothetical Case

Study

“I seek as much as I can to mitigate risk”

- John R. Allen


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.


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.


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


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


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.


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.


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


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


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.


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


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


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


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.


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


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


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.


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


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


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.


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.


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.


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


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"


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.


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.


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):


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


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.


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.


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.


216

Glossary of Terms


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


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


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


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.


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


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.


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


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


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


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


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


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:


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:


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


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.


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


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.


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.


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


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.


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


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.


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


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


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.


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.


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.


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.


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-


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


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


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.


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.


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.


251

Appendices


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


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:


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


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


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


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?


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.


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.


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.


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.


262


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]

mitigating risk in large sap projects

Documents