1. Copyright 2013-2016 Robyn Laing (Author)
This Presentation May Not be Reproduced or Published without the Author’s Written Permission
Robyn Laing
Principal SD/LE Consultant
SD LE Consulting Inc.
www.linkedin.com/in/sapsdguru/

2. Copyright 2013-2016 Robyn Laing (Author)
This Presentation May Not be Reproduced or Published without the Author’s Written Permission
Introduction
ERP Projects - The Pillars of Success
Wrap-Up
Q&A

3. Copyright 2013-2016 Robyn Laing (Author)
This Presentation May Not be Reproduced or Published without the Author’s Written Permission
My“ERPtrenches”… SAPandotherERPsystems
20 years SAP SD & LE consulting experience
Big, medium and small projects (with “Big Five”, mid-tier & niche consulting
companies) in US & Europe.
New implementations & “add-ons” & support.
Industries: Consumer products, beverages, value-add distribution,
manufacturing, medical & pharmaceutical, software & services.
Independent SAP consultant since Dec. 2009.
3 years EDI & Groupware software development, implementation & support
First exposure to SAP – integrating EDI into SAP Order Processing
10 years application development & support with multi-national CPG’s
distribution subsidiary
Home-grown ERP system in COBOL
Replaced with ERP “package” in RPG/400 – with many modifications!
2 years as “summer intern” with multi-national CPG
Developed PC-based Inventory Management system in DBASE II (“great-
grandfather” of Clipper, FoxPro, MS Access and others)
Developed statistical Sales Analysis tools in BASIC on an Apple II Plus (no Mac
yet back then…)

4. Copyright 2013-2016 Robyn Laing (Author)
This Presentation May Not be Reproduced or Published without the Author’s Written Permission
Programs
Processes
People
Project Management
Project Sponsorship

5. Copyright 2013-2016 Robyn Laing (Author)
This Presentation May Not be Reproduced or Published without the Author’s Written Permission
Programs=Technology
No “package” is perfect!
SAP can be enhanced in many areas (“user exits”, BADI’s etc.)
BUT: Excessive enhancements defeat the object of “buying a package”
because it takes more time & money to:
Design, Develop & Test
Document, Support & Upgrade
More custom program code = more program bugs
Bugs can take YEARS to surface = more difficult to troubleshoot and fix.
Your program bugs could cause standard SAP to malfunction
Enhancements need to be justified:
Why? …. “To make SAP look like the legacy system” is not a valid answer!
What else is possible? …. Creative configuration beats tons of custom code
Enhancement <> Modification of SAP’s own code
Modifications of SAP’s own code to be avoided 99.999% of the time.
Exception: Modification provides mission-critical functionality for which
no viable workaround exists & modification is minimally invasive.
Even so…. “Modify with Extreme Caution” !!

6. Copyright 2013-2016 Robyn Laing (Author)
This Presentation May Not be Reproduced or Published without the Author’s Written Permission
Processes –Outside&InsidetheSystem-1
To err is human…. But to really mess it up, use a computer
A badly designed process cannot be “fixed” by automating it
Automating it just causes more trouble a lot faster than when it was a
manual process – “efficiency” <> “effectiveness”!
Before doing a bunch of custom development to automate any SAP
process, make sure it works 100% when executed manually
G.I.G.O. = Garbage In, Garbage Out
Bad input data will – sooner or later – produce bad output data
The source of bad input may be very far away from where the bad output
shows up:
Example: Classifying Wal-Mart as a convenience store on the Customer
Master only showed up as an error in the monthly sales reports (shipping &
billing was not affected by this error)
A small input error can produce a very much larger output error:
One Customer Master record with incorrect Customer Group led to…
Thousands of incorrect billing documents classified incorrectly

7. Copyright 2013-2016 Robyn Laing (Author)
This Presentation May Not be Reproduced or Published without the Author’s Written Permission
Processes –Outside&InsidetheSystem -2
SAP Supply Chain – Cross-module ‘G.I.G.O’ example
Material Master – “Purchasing” data fields
Planned Delivery Time (PDT) Purchase Order Create Date plus PDT = Planned
Delivery Date from Vendor
Goods Receipt Processing Time (GRPT)  Planned Delivery Date plus GRPT = Date
when product available to pick & ship to customer
If PDT is wrong….
Warehouse Receiving Department can’t effectively plan and staff their receiving
dock because they don’t know when the product is going to arrive
If product requires Q/A on arrival, QC Department can’t plan & staff effectively
either
If SAP Order Processing promises availability against inbound PO’s, delivery dates
promised to customers will be incorrect – Customer Service Department flooded
with calls & complaints, financial penalties by customers for late delivery etc.
If GRPT is wrong….
System shows that product will be “available” when it may not yet be pickable
Delivery dates promised to customers will be wrong (see above)
Has potential to negatively impact Warehousing Picking efficiency

8. Copyright 2013-2016 Robyn Laing (Author)
This Presentation May Not be Reproduced or Published without the Author’s Written Permission
People–InandbeyondtheProject Team
The “people stuff” trumps the “program & process stuff” 99% of
the time
You can have a “perfect” system that executes “perfect” processes with
100% accuracy…
But if the users don’t understand or know how to use it
Or simply refuse to use it
Then “the system does not work”
Yet “Change Management”, “Communication” and “Training” are
often the most neglected (under-budgeted) areas on projects
Don’t forget that the new system affects others outside of the
organization:
Customers, vendors, share-holders….
“Communicate early & often” (but not too often…)

9. Copyright 2013-2016 Robyn Laing (Author)
This Presentation May Not be Reproduced or Published without the Author’s Written Permission
ProjectManagement
It’s a tough job but somebody has to do it!
Project Management = managing both the Business and
Technology areas, not just Technology
Inadequate project management can result in project
failure
Hershey Foods SAP R/3 implementation in 1999
“Industry analysts also concurred that problems in project management were
to blame for the debacle”
See Case Study article by lCFAl Center for Management Research (Authors:
Indu Perepu & Vivek Gupta)
http://members.home.nl/c.schalkx/Cases%20ARP/ERP%20Implementation%2
0Failure%20Hershey%20Foods%20Corporation.pdf
The Hershey story does have a happy ending....
Subsequent Hershey projects were successful (upgrade in 2001 ahead of
schedule and costs below estimate/budget)

10. Copyright 2013-2016 Robyn Laing (Author)
This Presentation May Not be Reproduced or Published without the Author’s Written Permission
ProjectSponsorship
Steering Committees & Project Sponsors need to be
truly involved
Many SAP projects result in some level of organizational and
process re-engineering = CHANGE
The leaders of the business need to support and actively lead
the change in order for it to be embraced by all
Steering Committees & Project Sponsors will be called upon
to make key project decisions –informed decisions, preferably
The fish rots from the head downwards….
Project teams and end-users have a keen sense of smell!

11. Copyright 2013-2016 Robyn Laing (Author)
This Presentation May Not be Reproduced or Published without the Author’s Written Permission
ERP project success or failure affects more than just the “ERP project
team”
If you’re an employee of the company – even if you’re never going to use the
system - your year-end bonus and/or pay raise could be affected
If you’re a shareholder in the company, your stock price and dividends could
be affected
If you’re a vendor, your payments & future orders could be delayed
If you’re a customer, your deliveries could be delayed (which could in turn
affect your ability to service your own customers)
So one day in the future, when your company (or customer, or vendor)’s
ERP project team requests your help (directly or indirectly) with the project,
don’t blow them off!!