The ERP Landscape: 10 Years in the Making

1. The ERP Landscape:10 Years in the Making

2. Panelists • Phil Goldstein, Goldstein & Associates • Mike Gower, University of Vermont • Al Horvath, Columbia University • Barry Walsh, Indiana University

3. Topics • Implementation Experiences (Gower) • Realizing the benefits of an ERP (Walsh) • The Evolving Vendor Landscape (Goldstein) • ERP’s as a Lifetime Investment (Horvath)

4. “What I Did On My Summer Vacation…”Implementation Experiences J. Michael Gower University of Vermont

5. Background: 1996/1997 • I was at Duke University • ERP implementations were in an early stage • SAP (Duke’s vendor) was in an even earlier stage for higher education • Implementation consultants barely knew (or did not know) the latest software versions • Internet versions were not available yet

6. Background: 1997 • Some functionality was “invented” on the fly (for example, 403 (b)) • It was unclear whether some functions could even be performed • “Best practices” were little known • “Paving the cowpath” was a real danger

7. Post-Y2K • Much more competition for implementation services • Software is more of a commodity • User groups are more prevalent in higher education • Basic functionality is there – and best practices are generally represented

8. Today’s Implementation Challenges • It’s still a complicated world – picking and licensing the software is the easy part • Some critical functionality is still evolving • Budgeting • Effort reporting • Software is still buggy and hardware is increasingly complicated – especially in an “Oracle world”

9. Lessons Learned (Times Two) • Get a good lawyer! Contractual protections and accountability are very important for a successful implementation • The project plan is everything! The project manager is everything else! • On-time and on-budget is still a challenge, but it’s easier than in the ‘90s • Paving the cowpath is still a danger

10. Lessons Learned (Times Two) • It is still hard to change “dumb” practices if they are ingrained in the culture • Be prepared to tackle them immediately • Prepare users for some rough times • Lower expectations – gains will come only after “building upon the roadbed” of the core system • Holding together a team is more difficult – at least in NW Vermont!

11. Lessons Learned (Times Two) • Analytic capabilities require a different project focus entirely • Getting good data into ERP is easy • Getting good data out is still hard • Different customers need these services • ROI is still tough – but the cost of not making a change is still large • It’s a long-term investment

12. Lessons Learned (Times Two) • Executive leadership is essential for the project team and to keep the vendors “honest” • Sharing with other institutions and asking for help is essential • UVM got vital help from University of Delaware • UVM will share its “new stuff” with Delaware and with the Users Group

13. Implementation Observations • There are lots of capable implementation partners out there; however, • “Fusion” is a great unknown – who will help with upgrades when it will be new to everyone? • How will open source be supported? • “Best practices” should be easier to discern

14. “My University Spent $__ Million on an ERP and All I Got Was This Stupid T-Shirt!”Realizing the Benefits of an ERP Barry Walsh Indiana University

15. History in the xRP space • MRP • Wrote one of the first in 70’s • MRP-II • Designed some in the 70’s/80’s • ERP • User of vendor ERPs

16. Background: 1995 • Had responsibility for financial systems • In 1991, needed to replace 25 year old mainframe system • RFP • IA  SCT • AMS co-development  FIS 1994-95 • Some doubts about vendors creeping in

17. Expectations • Vended software is better than what we currently have • Safety in Numbers • Subject Matter Best Practices • Support Costs

18. Is Vended Software Better? • Expectations: • Experts designed it • Uses current technology • We can stay current • Reality • Mostly true; especially for pure vanilla implementations • EDUCAUSE ECAR study….most schools have felt it was a success

19. Safety in Numbers? • Expectations: • If we’re all in it, we’re safe, right? • We represent a large market segment for vendors, right? • Realities: • M&A activities • Vendors disappear • IA; code dead-ended….~500 IA customers still running 15 year old software • PeopleSoft software? Jury still out -- Fusion in ~2010 • Market ‘weight’ • HE is around 1% of Oracle’s world wide revenue now. • We’re terrible customers!

20. Subject Matter Best Practices • Expectations: • The software brings them with it • Software was developed by ‘our’ SMEs • Realities • In some areas we get industry best practices • Some of these don’t work in HE • But see former expectation…market weight

21. Support Costs • Expectations: • We will be able to reallocate the developers that used to maintain our old systems • We will have predictable costs • Reality • The Law of N+M • N = number of developers that used to maintain your older system • M = a number (> 0) dependent on the size and/or complexity of institution • Yes, we will have predicable costs…predictably higher

22. “What’s Your Name Again?”The Evolving Vendor Landscape Phil Goldstein Goldstein and Associates

23. Then and Now

24. Myths and Truths

25. Changing Vendor Landscape

26. What Has Changed? • The names have changed but the degree of choice is comparable. • Vendors are less higher education centric. • Future vendor directions are less predictable. • Product capability is more comparable. • Product quality is improved.

27. Services Have Changed, Too • Implementation services are becoming commodities. • Software vendors are more interested in services. • Provider knowledge has shifted from industry to application. • Consultants are being used in more targeted ways.

28. Predictions • Concerted efforts to limit the ERP vendor’s ‘footprint’. • Renewed interest in best of breed solutions. • Rise of niche providers of higher education specific modules. • Less focus on vendor demos and more focus on life-cycle costs and strategies to capture benefits. • Greater need for institution’s to manage their own implementations.

29. “The Gift That Keeps on Giving”ERP’s as a Lifetime Investment Al Horvath Columbia University

30. Background: 1995 • I was at NYU • We were assessing our financial processes and systems - and were about to conclude that it was time to implement a new set of financial applications • Y2K was in the distance • I still had some hair

31. Background: 1997 • At NYU, we implemented PeopleSoft public sector modules (financials) • I’ve had experience with Oracle and PS HR • We implemented version 5 • Almost immediately, we were faced with the unrealized reality of new vintage ERP systems—the upgrade • We upgraded to version 6 only nine months after the initial implementation

32. ERP’s Are a Lifetime Commitment • ERP systems bring with them a requirement of “keeping current” • Patches to correct gaps or problems • Major functional upgrades • Upgrade paths are forced into obsolescence • Driven by need for additional functionality • The level of effort required to stay current was generally underestimated (by a lot)

33. ERP’s Are a Lifetime Commitment • The lifetime commitment should NOT have been a surprise • Legacy system vendors had gone through several organizational changes • Age of legacy systems encouraged bolt-on strategies as opposed to major functionality upgrades

34. ERP’s Are a Lifetime Commitment • The PeopleSoft experience (i.e., consolidation into Oracle) was a very unexpected outcome, looking through a 1995 lens • Raises the question of the reasonable “useful life” of such a set of applications • Is 25 years an unreasonable future expectation? • Does “FUSION” impact a university’s thinking?

35. ERP’s Are a Lifetime Commitment • Beyond the organizational considerations, how will the software evolve in subsequent versions? • Will my functionality requirements get priority in upgrades? • If not, what are my options? • Is the software flexible enough for solutions outside of the base package itself?

36. Lessons Learned • Upgrades take a significant resource commitment • Establish a set of protocols to determine how often these should be undertaken • Tracking changes in “patch set” is labor intensive • Establish a regular review process, including functional organization participants

37. Lessons Learned • Be prepared for questions from senior management or trustees around your strategy with a single vendor • Decisions are being reconsidered in light of vendor organizational changes • Be prepared to defend the decision to keep the “status quo”

38. Lessons Learned • Make yourself and your institution known to your vendor • Have a voice in their future release plan • Let them know what you need and what doesn’t work particularly well

39. Questions & RoundtableDiscussion