Using sap implementation to drive process change

A collaboration of:

Using SAP Implementation

to Drive Process Change

Phil Awtry

Nebraska Public Power District

Background: NPPD & SAP

Case Study: The EDM Project

Success Factors for Driving Change

Key Points to Take Home

Q & A

Our Agenda

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

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

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

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!

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.

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.

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…

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.

Slide 11


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.

Slide 12


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.

Slide 13


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.

Slide 14


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.

Slide 15


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.

Slide 16


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.

Slide 17


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.

Slide 18


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.

Slide 19


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.

Slide 20


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

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

Slide 22

Improved UI – Drawing Search Tools

• Custom ABAP WebDynPros, one for needs of

each business unit.

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.


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.


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.


Slide 26

Questions / Answers

A collaboration of:

Phil Awtry Nebraska Public Power District

[email protected]