Project of SAP ERP Implementation Into Academic Co m munity – Lessons Learned

1. Project of SAP ERP Implementation Into Academic Community – Lessons Learned Faculty of EE and Computing University of Zagreb, Croatia Krešimir Fertalj (kresimir.fertalj@fer.hr) Damir Kalpić (damir.kalpic@fer.hr)

2. Introduction • A case study of introduction of a complex ERP system into a complex and heterogeneous environment • The episodes • The Faculty • The University • The Twist • Further developments

3. Episode I The Faculty

4. Choice of the ERP for University • University budgeting due to become lump sum • the Rector’s Office was not prepared for that task • The Ministry decided to finance and to introduce ERP to higher education • SAP accepted as platform • already present in the National Treasury and in most ministries • fixed prices according to achieved and acknowledged functionality • The authors’ Faculty was chosen for the pilot project • Replace the outsourced BIS • Fulfill a list of wished functionality • Connect to existing SW (e.g. student administration IS) • The project makes sense only if the Faculty becomes a showcasein HE!

5. Project organization Steering comittee : Ministry, University, Faculty, Implementer Director – Ministry Director – Implementer Project manager & deputy - Faculty Project manager & deputy - Implementer subteams: consultants and key users Procurement mgt. Financemgt. and bookkeeping Project mgt. Business reporting Data exchange and integration with other systems Informing and Decision making HR mgt.

6. Project Plan [and Realization]

7. Setting the stage for the pilot project • A CD with Faculty system analysis handed over to implementer • 600 pages, 300 main diagrams, 200 main business classes • Problem: Faculty is of dual nature • Budget for education and science (partly) • Proprietary earnings from scholarships and scientific projects • Proprietary earnings form contracts with industry and economy • Like a budgeted institution containing some 150 semi-private SMEs • The Faculty project leader, his deputy and the key users • have checked and supplemented the design document of the project, • helped the consultants to accomplish the SA and to complete the WBS

8. Projects fail at the beginning • After about three months • inexperienced & inactiveimplementer’s project leader • consultants overbooked, pretending to work on the Project • consultants offered standard solutions as made on purpose for the Faculty • some consultants could not understand that the Faculty had not ordered a list of SAP modules but it had required • the functionalities to support business processes of the Faculty • the system to become a showcase for the rest of the University • Restructuring of the implementer’s team • An experienced and active implementer’s Project leader assigned • Some consultants dismissed from the Project • Some valuable consultants entered the Project • The Project recovered and started to develop properly.

9. Project management – prerequisites for success • Leadership • Project manager • Project manager deputy • Head of accounting department • Strong support from the top management • Dean and his subordinates • Formal authority • Project charter issued by Ministry • Informal authority • knowledge, experience and dedication • Commitment of all stakeholders !

10. Project scope management • Scope planning - Design document (Blueprint) • a broad vision of what the end result of the project will be • Major problem: Getting out of the SAP modules • from BPA to BPI and BPR • Scope definition (Blueprint++) • broadening the design with identification of crucial business processes • performed by the Faculty project manager, key users and Dean • Progressive elaboration • the incremental design and refinement of the initial concept toward the project plan • Scope control • by proper change management

11. Project communications management • Communications Planning • identification of the stakeholders and their communication needs • list of stakeholders and their contact information • document templates • Information Distribution • email with extensive use of carbon copies • web portal with "alert me" feature • Performance Reporting • monthly reports to project director • written by Implementer project manager • approved by Faculty project manager

12. Web portal • Project documentation • templates and samples of business documents and reports • company policy and regulatory documents • interview notes • end user documentation • technical documentation • Project management documentation • task lists • meeting memos • project performance reports • Supporting information • calendar events (eg. meetings, milestones) • contacts • hyperlinks

13. Project execution, monitoring and control • On-site collaboration of consultants and end users • interviewing • testing • training • Additional system analysis • performed by Faculty project manager, his deputy and key users • identification of use cases • simulation of business processes • role playing • Project meetings • weekly in early phase, once in two weeks in mature phase • project managers, consultants and key users • brainstorming • plan-do-check-act cycling • requirements management, risk management, change control

14. Conflict management • Problem solving • whenever possible • Forcing • forcing deadlines (eg. production of payrolls just before summer holidays) • aforementioned restructuring of the implementer’s team • Compromising • Faculty accepted some limitations of SAP technology • Implementer did the best to provide substitute features • resource balancing • Smoothing • rarely to none

15. Joint development and brainstorming

16. Major technical problems • Principle "Data should be entered on the site of their generation" • could not be implemented due to unbearable cost of licenses • Proprietary Web services developed • Insight into financial accounts, Traveling orders, Invoices to customers, Orders to pay the fees to contributors in contracted projects • Registration office • Slow processing, Organization to be improved • Human resources • Faculty members to be entered twice - once as institution’s employee and for the second time as an author on contract • Partly solved – 2 personal codes, most of the personal info. uniquely stored • Data exchange with Student administration IS • Mutual waiting - implementer of ERP and implementer of SA IS

17. Production • Data migration – with help of the outsourcer of the old IS • master data owned by Faculty • list of vendors synchronized with the list maintained by State Treasury • manual entry of HR data that were missing in the old system • summary data about transactions closed prior to actual business year • all data about running transactions • Security issues • role-right matrix • system administrator can manage the users, not the data !

18. Post-productionsupport at Faculty • Faculty IT department • SAP system administrator and his deputy • Faculty Web administrator • other administrators • Standard support of end users • maintenance of personal computers and peripherals • networking and security management • office software and anti-virus software management • SAP administration • installation and configuration of SAP client software • administration of SAP users • system auditing • installation of patches • Other • deployment of web services

19. Project closure and attempts for further deployment • Thirteen months after project kick-off • About 85% completed • All crucial functionality achieved • The Faculty dropped some of requirements, • the implementer provided substitute functionalities • while some new arouse • changes in legislation/organization • Some loose ends to be solved by expected continuation project • Rather fair presentation for the University • to encourage the other faculties to implement the solution • Minimum window dressing - to be honest • P2P presentations suggested

20. Episode II The University

21. 6 faculties 6 faculties 5 faculties 6 faculties 6 faculties Project management Quality assurance Production support The master plan • Project was kicked-off „on the first deadline” Deadline 1.9.2009. 1.1.2010. 1.4.2010. 1.7.2011. 1.10.2011. 1.1.2012. 1.4.2011. 1.7.2010. 1.10.2010. 1.1.2011. FER Rectorate + 3 faculties 21

22. Project organization SUPERVISORY BOARD Ministry University Faculties Implementer QUALITY MANAGEMENT BOARD PROJECT MANAGEMENT BOARD Director – University Director – Implementer PM – Implementer (IPM) PM – University (UPM) PMs – faculties (FPMs) Advisors – from faculties and University CC RECTORATE Coordinator UPM’s deputy (pilot) FACULTY UPM and deputy FACULTY #1 FPM and deputy FACULTY #2 FPM and deputy FACULTY #3 FPM and deputy

23. Reluctance and how to moderate it • Three faculties chosen to immediately follow the suit • Resistance from some institutions had been expected • but how to circumvent it, was partly neglected Faculty #1 - A supposedly similar faculty • Initially expected to help in further implementations • Fiercest opposition; demanded as prerequisite: • Full description and analysis of all the BPs at the University • Gap analysis - Impossible & senseless Analysis paralysis • Finally convinced!? Faculty #2 - A different, highly respected medical faculty • Why to bother with something far from their profession? • Finally convinced!? Faculty #3 - A large and important faculty of economics • Accepted the implementation in a lukewarm way

24. Major problems and proposed solutions (1) • Support of the project • the contract - between the University and the SAP implementer • possible lack of support by management in faculties involved • agreement signed by the faculty deans and the Rector - discarded • Lack of key end users at the faculties • Faculties' administrative personnel - scarce and reluctant to change • remuneration for administration with increased workload - discarded • peer-to-peer communication with counterparts from the pilot project • deferred, later out of scope • Production and maintenance • Partly imprecise contract for the project (support, maintenance) • Undetermined number of SAP licenses to be transferred from the Ministry • to be negotiated • The faculties should be aware what awaits them (workload, costs, …)

25. Major problems and proposed solutions (3) • Project execution • the idea of autonomous execution of sub-projects at the faculties • by enforcing the authority, independence and self-esteem of faculty PMs • Fragile competence and authority – some FPMs “in shadow” • due to lack of support from their respective deans and/or • dominated by some more competent colleagues, members of PM board • Project monitoring and control • a common system of communication (PMIS) - deferred, later forgotten • weekly meetings of the PM bord – became monthly to quarterly

26. Major problems and proposed solutions (3) • The opposition • obstructed „best practices” • could not move on without clear strategy for the university and wider • expecting some answers to be given by Ministry (as initiator and financer) • denying the contract and the way the Implementer was selected • proposing V-model instead of evolutionary and incremental approach • asking for a reference model (neglecting the pilot) • demanding Inception Report, Project Status Report • (re)definition of aim and objectives, scope, … • claiming and proving the blueprint (design) was unacceptable • …

27. Whatwethought at that time … • Successful pilot implementation - no significant technical obstacles • a more elusive but dangerous threat deriving from the human factor • The opposition is insisting on technical by-the-book procedures • professionally naive ? true motives ? • the major challenge - to tame this explicitly unexpressed danger • Faculty managements deserve some reward if the ERP system is successfully implemented at their institutions • It must be legally settled, not to be regarded as any conflict of interest • So-called incremental budgeting may be another reason for obstruction • state money received per student derives from history, not from the real costs • the computerization works directly against the interest of such faculties

28. … what really happened 1.9.2009. 1.1.2010. 1.4.2010. 1.7.2011. 1.10.2011. 1.1.2012. 1.4.2011. 1.7.2010. 1.10.2010. 1.1.2011. • Six months after project start • Faculty #1 – expressed verbal support to the project, but also that they have already bought another SW so they are not interested to use the system • Faculty #2 – avoided to express the support, then bought another software • Faculty #3 – supersede the dean • Implementer still had the contract • the scope had to remain the same • University still had the budget • Any suggestions

29. Episode III The Twist

30. Annex 2 (to the contract) 1.9.2009. 1.1.2010. 1.4.2010. 1.7.2011. 1.10.2011. 1.1.2012. 1.4.2011. 1.7.2010. 1.10.2010. 1.1.2011. • Changeofscope within the same budget • 33 shallow faculty functionalities instead of 3 full packages • Central personnel records administration for the whole University • Gross wages expenditures and material costs from the budget • Data exchange with Student administration IS • Data warehouse • Rectorate with full „faculty” functionalities • New deadline: 6 months after start of „the twist” • Proposed by the main opponent • Supported by consensus of PM board • Presented to Council of deans • Approvedby Steering committee

31. The implementation 1.9.2009. 1.4.2010. 1.1.2010. 1.7.2011. 1.10.2011. 1.1.2012. 1.4.2011. 1.7.2010. 1.10.2010. 1.1.2011. • Progress • Rectorate implementation in three months • 33 faculties during the next three months • Data exchange got stuck due to problems of Student IS • Data warehouse got stuck due to non-standardized master data • Implementer gave up of development and proposed the closure • Meanwhile, 85% of the contract was invoiced • Implementer claimed that few remaining small tasks are worth 15% • unilateral termination of the contract would follow otherwise • The UPM rejected • So the closure was negotiated until the end of that year

32. The Closure • How to calculate the value of the work accomplished/remained ? • Non-implemented functionalities compensated by Annex 3 • Post-production activities • Support and adaptive maintenance • Other user requests • system migration from the initial location to University Computing Centre • Agreement about the ownership and licenses with the Ministry • Bottom-up verification • End users - middle management - project managers (UPM and IPM) • PM board • „Commission for verification and handover” • Steering committee 1.9.2009. … 1.1.2012. 28.12.2012. 20.3.2013. 14.4.2013. 23.10.2012. 1.5.2012. 1.7.2012. …

33. The reasons for failure • Although 85% percent of the requirements was met and the contract (annexes) was fulfilled the project was not a success • Some predictible reasons • Imprecise contract with items of undetermined value • Invoicing ahead acknowledged functionality • External factors : licenses, ownership, strategy, .... • Partially unregulated and sluggish business system • Partial incompetence of implementer (SA, BPM) • End user resistance • End user fluctuation • Hesitancy, slow decision making • Scattered disobedience within the hierarchy • Lack of commitment !?

34. Lessons learned ? • Other faculties are not the Faculty • Lack of commitment is crucial but may be solvable • The opposition within the PM board may be fatal • Project manager must be authorized to manage the resources of both the project and the organization • Project documentation matters, especially when project goes wrong • Should project manager give up (resign) due to infeasible “twists” ? • We scheduled, planned risks, reported progress etc. • Could we do better / differently ?

35. Episode IV Further developments

36. System Committee • Body to deal with the system in production • Vice-rector (former director of the project) • Dean of the Faculty • Director for the University Computing Center • Dean of the Faculty #1 („The advisor”) • Two other members • Current state • Data warehouse and exchange with Student IS still required • Alternatives ? • Continue with SAP and the Implementer • University Computing Center as SAP Competence Center • Public procurement of the 3rd party solution • Insourcing • …