1. A collaboration of:
Using SAP Implementation
to Drive Process Change
Phil Awtry
Nebraska Public Power District
2. Background: NPPD & SAP
Case Study: The EDM Project
Success Factors for Driving Change
Key Points to Take Home
Q & A
Our Agenda
3. Who Is Nebraska Public Power District?
•Nebraska is the only all-Public Power state in the USA
•NPPD is the largest Electric Utility in Nebraska
– Provides power to over 1,000,000 Nebraskans
– Annual Sales: 19.8 billion kWh (2010)
•Total annual revenue: $925M (2010)
•2200+ employees
•7500 miles of transmission & distribution lines
•3,100+ MW of generation
– Coal-fired, Nuclear, Gas-fired, Combined-Cycle, Hydro, Wind
4. NPPD’s History With SAP – 14 Years
• Initial implementation of R/3 was in 1999, 3 phases thru 2001.
• Multiple upgrades since then, additional rollouts.
• Current SAP environment:
• ECC 6.00, NetWeaver 7.0 components (Portal, BW, PI)
• Financials (FI, CO, TR), Asset Management (PM), Materials Management
(MM, IM), Project Management (PS), Human Resources (HR, Payroll,
Employee Self-Service), Sales & Distribution (SD)
• Currently launching CR&B implementation for Retail division
• In use across all NPPD business Units:
• Power Generation, Nuclear Generation, Transmission & Distribution, Support
Services
5. Slide 5
Our Case Study – The Enterprise Document
Management (EDM) Project
• Based on a formal assessment in 2005
• Sponsorship, funding & direction from COO
• Scope: standard, efficient, compliant process for
managing drawings using SAP DMS
o Geared to facility configuration management, compliance
auditing.
• Project Team:
o Document Management, IT, SAP DMS/ECM Consultants
o Unable to secure team members from major asset business units
6. Slide 6
The EDM Project Change Challenge
• Multiple business units, with multiple processes, some 30
years old.
• Multiple home-grown legacy DM systems tailored to each
areas processes.
• Each business unit assumed their process was the best.
o In reality, none of them were best practice.
• Everyone must change!
7. Slide 7
Technology Project or
Process Improvement Project?
• Most everyone viewed the project as a technology
change, replacing old systems with SAP DMS.
• But the team recognized up front that the project was
80% process change, 20% system change.
o In other words, a process change initiative
disguised as a system change…
• The SAP DMS implementation was the
Trojan horse to get process change in the gate.
8. Slide 8
Our Change Results
How Did We Do?
• As of early August, all NPPD business units are:
o Managing drawing and configuration changes using SAP DMS
and ECM.
o Using a standard core process, to some extent…
What Did We Do?
• Not going to give a detailed project explanation, since
DMS is boring stuff…
• Instead will highlight some Change Success Factors…
o …and not so successful factors.
9. Slide 9
Disclaimer
I Do Not Have Any Change Management Magic Bullets!
• …because they do not exist.
• NPPD is not a highly change adaptive organization, like
many utilities, especially public ones.
But I Have Some Examples for You to Consider in Your
Own Projects.
• Use and apply as you see fit.
• You mileage may vary…
10. Slide 10
Change Success Factors (1)
Planned the Project for Change
• Could have technically done the system implementation
in 8 months…
o …but would have failed miserably.
• Intentionally planned the project to enable change:
o Longer duration (initially 12 months, actual went longer)
o Smaller project team to keep cost ‘burn rate’ under control.
o Intentionally slowed project timeline to allow the organization
time to absorb the changes.
11. Slide 11
Change Success Factors (2)
Built A Prototype
• Short-term (4 weeks) consulting engagement prior to
actual project startup.
• Helped us define a basic process flow and sandbox
system configuration.
o Populated the prototype with some of our own legacy data.
• Helped visualize the potential changes coming in not
just the system, but also processes.
• Useful starting point for final solution design.
12. Slide 12
Change Success Factors (3)
Took the Show on the Road
• Allowed us to communicate early and directly to each
business area about:
o The overall project – drivers, scope, etc.
o The coming changes, and determine change readiness of each
business unit.
o Demo the prototype and get early feedback.
• The prototype and the roadshows made the project much
more tangible to the remote sites and plants.
13. Slide 13
Change Success Factors (4)
Conducted a Formal Change Assessment
• Conducted a change readiness survey after the
roadshows.
• Simple questions to gauge:
o Awareness of the project and changes.
o Support for the project by the individual, department, site.
o Understanding of the business drivers.
• Results were both encouraging and disappointing.
o Shared results with management team, planned accordingly.
14. Slide 14
Change Success Factors (5)
Focused on Simple, Clear Change Drivers
• Three main business drivers for the project:
o Drawing management efficiency & effectiveness (work
destruction / capacity creation).
o Improved compliance and configuration change auditability.
o Replace obsolete, aging and risky technology that old
(beloved) drawing management systems were based on.
• In other words – Process, Regulatory, Technology
o Simple, easy to remember, easy to relate to.
15. Slide 15
Change Success Factors (6)
Didn’t Try to “Sell the Change”
• Communicated coming changes in a manner that
assumed they were going to happen.
• Didn’t focus on individual benefits or value.
o Avoided the “This will make your job easier” pitch, since in many
cases that wasn’t true.
• Focused instead on the high-level business drivers and
benefits to the company, and the fact that the changes were
coming.
16. Slide 16
Change Success Factors (7)
Didn’t Trash-Talk The Current State
• Learned this lesson (the hard way) early on during the
roadshows.
• Overstating what’s wrong with the current processes &
systems offended those who had invested many years in
developing them.
o Instead learned to applaud people for making current processes &
systems work as well as they had for so long…
o …but due to new business drivers, that wasn’t good enough
anymore.
17. Slide 17
Change Success Factors (8)
Identified & Engaged With the Right Leaders
• We found the best local sponsors to be Engineering
management people with a business sense.
o But may have under-estimated the power of local culture.
o There is such a thing as too much ownership.
Carefully Selected & Recruited SMEs From All Areas
• Recruited opinion leaders, didn’t just take who’s offered.
• Made them work together as a whole team for design &
testing, and as smaller teams owning rollout & support.
18. Slide 18
Change Success Factors (9)
Dealt With Each Area Individually
• Each business unit had it’s own, unique process change
issues and challenges.
o Used a common template for each business unit to work through
how process adoption, cutover, etc would be done for them.
• Individual site implementation plans developed for/by each
business area, facilitated by Core Team, owned by Site
Teams.
o Where possible, referred to how other business units had solved
common issues.
19. Slide 19
Change Success Factors (10)
Stayed Flexible
• Focused on compliance with the major process and
functionality steps, but left flexibility in how each
business unit would adopt them.
o Rigid standardization is/was an unrealistic goal.
• Example: Use of Digital Signatures
o How each area would apply the DS approval step (who
assigned to approve, what level of approval it represented, etc)
was their decision. But use of the DS was not optional.
20. Slide 20
Change Success Factors (11)
Used Advanced SAP UI Tools to Ease Transition
• Recognized early on that asking users to navigate
dozens of new SAP transactions for ECM and DMS
would fail.
• Legacy web-based drawing search/view tool was very
popular, needed to create a replacement that was as
good or better.
• Examples:
o Custom developed ECM Workbench, Drawing Search tools
21. Slide 21
Improved UI – ECM Workbench
• Custom ABAP WebDynPro, combined multiple
ECM and DMS transactions into one screen.
o Deployed via SAP Portal, SAPgui, browser
22. Slide 22
Improved UI – Drawing Search Tools
• Custom ABAP WebDynPros, one for needs of
each business unit.
23. Recognize the Size and Scope of Change
• Make process change assessment and planning part of the
early project scoping.
• Plan the project around the process change that is needed,
not just the system implementation steps.
• Set up the SAP implementation to be the process change
Trojan Horse.
Connect to Solid, Simple Business Drivers
• Communicate in a way that makes the coming change seem
inevitable.
Key Points to Take Home
24. Find the Right People in the Impacted Areas
• Engage with them early and often, give them an identity.
• Work to transition these people from being:
o Victims of the change, to…
o Participants in the change, to finally…
o Owners and makers of the change.
Bring People from Different Areas Together
• Nothing breaks down individual resistance like peer pressure.
• Plus it’s fun to watch them argue with each other.
Key Points to Take Home
25. Be Creative in Use of SAP UI Tools
• Much resistance to use of SAP can be overcome by some
investment in tools for a better user experience.
Don’t Count on Compliance and Lasting Change Just
Because the COO Says So
• We’re already dealing with intentional drift from the standard
processes in some areas.
• Michael Hammer was right: “Culture wins!”
• Don’t be discouraged, and plan for ongoing governance.
Key Points to Take Home
