Using sap implementation to drive process change


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Using sap implementation to drive process change

  1. 1. A collaboration of: Using SAP Implementation to Drive Process Change Phil Awtry Nebraska Public Power District
  2. 2. Background: NPPD & SAP Case Study: The EDM Project Success Factors for Driving Change Key Points to Take Home Q & A Our Agenda
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 22. Slide 22 Improved UI – Drawing Search Tools • Custom ABAP WebDynPros, one for needs of each business unit.
  23. 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. 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. 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
  26. 26. Slide 26 Questions / Answers
  27. 27. A collaboration of: Phil Awtry Nebraska Public Power District