Faculty of EE and Computing University of Zagreb

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

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

Episode I The Faculty

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

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

Project Plan [and Realization] 6

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

Projects fail at the beginning q After about three months n n inexperienced & inactive implementer’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 q Restructuring of the implementer’s team n n n An experienced and active implementer’s Project leader assigned Some consultants dismissed from the Project Some valuable consultants entered the Project q The Project recovered and started to develop properly. 8

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

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

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

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

Project execution, monitoring and control q On-site collaboration of consultants and end users n n n interviewing testing training q Additional system analysis n n performed by Faculty project manager, his deputy and key users identification of use cases simulation of business processes role playing q Project meetings n n n 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 13

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

Joint development and brainstorming 15

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

Production q Data migration – with help of the outsourcer of the old IS n n n 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 q Security issues n n role-right matrix system administrator can manage the users, not the data ! 17

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

Project closure and attempts for further deployment q Thirteen months after project kick-off n n n 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 q Rather fair presentation for the University n n n to encourage the other faculties to implement the solution Minimum window dressing - to be honest P 2 P presentations suggested 19

Episode II The University

The master plan Deadline 1. 9. 2009. 1. 1. 2010. 1. 4. 2010. 1. 7. 2010. 1. 10. 2010. 1. 1. 2011. 1. 4. 2011. 1. 7. 2011. 1. 10. 2011. 1. 1. 2012. FER Rectorate + 3 faculties 6 faculties 5 faculties Project management Quality assurance Production support q Project was kicked-off „on the first deadline” 21 21

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 22

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

Major problems and proposed solutions (1) q Support of the project n n n 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 q Lack of key end users at the faculties n n 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 q Production and maintenance n n n 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, …) 24

Major problems and proposed solutions (3) q Project execution n n 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 q Project monitoring and control n n a common system of communication (PMIS) - deferred, later forgotten weekly meetings of the PM bord – became monthly to quarterly 25

Major problems and proposed solutions (3) q The opposition n n n n 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 … 26

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

… what really happened 1. 9. 2009. 1. 1. 2010. 1. 4. 2010. 1. 7. 2010. 1. 10. 2010. 1. 1. 2011. 1. 4. 2011. 1. 7. 2011. 1. 10. 2011. 1. 1. 2012. q Six months after project start n n n 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 q Implementer still had the contract n the scope had to remain the same q University still had the budget q Any suggestions 28

Episode III The Twist

Annex 2 (to the contract) 1. 9. 2009. 1. 1. 2010. 1. 4. 2010. 1. 7. 2010. 1. 10. 2010. 1. 1. 2011. 1. 4. 2011. 1. 7. 2011. 1. 10. 2011. 1. 1. 2012. q Change of scope within the same budget n n 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 q New deadline: 6 months after start of „the twist” n n Proposed by the main opponent Supported by consensus of PM board Presented to Council of deans Approved by Steering committee 30

The implementation 1. 9. 2009. 1. 1. 2010. 1. 4. 2010. 1. 7. 2010. 1. 10. 2010. 1. 1. 2011. 1. 4. 2011. 1. 7. 2011. 1. 10. 2011. 1. 1. 2012. q Progress n n 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 q Implementer gave up of development and proposed the closure n n 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 q So the closure was negotiated until the end of that year 31

The Closure 1. 9. 2009. … 1. 1. 2012. 1. 5. 2012. 1. 7. 2012. … 23. 10. 2012. 28. 12. 2012. 20. 3. 2013. 14. 4. 2013. q How to calculate the value of the work accomplished/remained ? q Non-implemented functionalities compensated by Annex 3 n n Post-production activities Support and adaptive maintenance Other user requests system migration from the initial location to University Computing Centre q Agreement about the ownership and licenses with the Ministry q Bottom-up verification n n End users - middle management - project managers (UPM and IPM) PM board „Commission for verification and handover” Steering committee 32

The reasons for failure q Although 85% percent of the requirements was met and the contract (annexes) was fulfilled the project was not a success q Some predictible reasons n n n n n 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 q Lack of commitment !? 33

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

Episode IV Further developments

System Committee q Body to deal with the system in production n n 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 q Current state n Data warehouse and exchange with Student IS still required q Alternatives ? n n n Continue with SAP and the Implementer University Computing Center as SAP Competence Center Public procurement of the 3 rd party solution Insourcing … 36