INTRODUCTION OF SAP ERP SYSTEM INTO A HETEROGENEOUS ACADEMIC COMMUNITY

1. INTRODUCTION OF SAP ERP SYSTEM INTO A HETEROGENEOUS ACADEMIC COMMUNITY Vedran Mornar (vedran.mornar@fer.hr) Krešimir Fertalj (kresimir.fertalj@fer.hr) Damir Kalpić (damir.kalpic@fer.hr) Faculty of EE and Computing University of Zagreb, Croatia

2. Introduction • A case study of introduction of a complex ERP system into a complex and heterogeneous environment • the context • the major steps of ERP implementation to the authors’ institution • current status and foreseeable further developments • The aim – expand the system to the other University members • difficulties and risks encountered

3. The history • The authors’ home institution has a remarkable history in efforts to computerize its core activities • student administration, subsidized students’ nourishment, scheduling of lectures, the library and support to educational activities • Administration and bookkeeping were regarded as standard tasks • BIS was outsourced from a major local supplier of such software • Experience with SAP buyers, about 20-10 years ago • Buy SAP licenses at 150% of Germany price • Hire consultants at 1,000 US$/day rate, who were inexperienced • Start with General ledger • Apply Big Bang - risky • Rigid - Inappropriate to local loose conditions at that time • The approach appeared unacceptable to the authors

4. A break point • Computerization of Croatian hospitals • multiple bidders, each appointed to a particular hospital • due to the change of Government, the bidding was cancelled • the largest SAP implementer in Croatia continued its engagement in its respective hospital free of charge • Change of attitude • Increased number of local competent consultants • Discounts on licenses • Gradual implementation • Increased flexibility

5. Choice of the ERP for University • University budgeting due to become lump sum • the Rector’s Office was not prepared for that task, • nor were the very different and heterogeneous faculties • The Ministry decided to finance and to introduce ERP to higher education • SAP accepted as platform • SAP was already present in the National Treasury and in most ministries • fixed prices according to achieved and acknowledged functionality • aforementioned behavior in the hospital and change of attitude • 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 showcase for SAP in higher education!

6. Implementation of the pilot project • Steering committee • Ministry - Minister’s aide for computerization • University - Vice-rector for finances • Faculty - Dean • Implementer - High executive • Ministry • Project director - High official • Faculty • Project leader - Associate professor • Project leader deputy - Full professor • Key users - Dean, Vice Dean for finances, Chief accountant, Head of a department & Leader of scientific and professional projects • Implementer • Project leader • Coordinator - A high executive • Consultants

7. Setting the stage for the pilot project • A room in Faculty premises dedicated to consultants • A web portal with "alert me" feature • containing project documentation and additional information • A CD with FER 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 in high tech

8. First attempts of the implementer to minimize the efforts • After about three months • 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 • the Faculty’s members involved in the project dismissed most of these proposals, as inacceptable and inappropriate • 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

9. Restructuring of the implementer’s team • The Faculty project leader, his deputies 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 • Steering committee meeting • 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.

10. Major 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

11. 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 • initially forgotten • Rather fair presentation for the University • Minimum window dressing • To be honest • To encourage the other faculties to implement the solution • P2P presentations suggested

12. 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 #1A supposedly similar faculty • Initially expected to help in further implementations • Fiercest obstruction; demanded as prerequisite: • Full description and analysis of all the BPs at the University • Gap analysis - Impossible & senseless  Analysis paralysis • Finally convinced! #2 A different, highly respected medical faculty • Why to bother with something far from their profession? • Finally convinced! #3A large and important faculty of economics • accepted the implementation in a lukewarm way, lost interest • missing the necessary support from their Dean, maybe due to other problems

13. Expected further episodes • Development model • incremental and evolutionary approach suggested by the authors • versus classical V-model approach suggested by our opponents • Human factors as necessary precondition • The Faculty members were motivated for success • it was their core business, it opened for them wider professional possibilities • What would the responsible persons from other faculties achieve? • Necessary remuneration • for administration with temporarily increased workload • What about dean and vice dean for finances ? (Being a dean or a vice dean is an elective position with two years term)

14. Major problems and proposed solutions • The reference model • Opponents suggest selection of a reference model from some more developed country or a model that SAP may draw “out of the box”. • Imposing the successful pilot as the reference model is sine qua non • Support of the project • The contract - between the University and the SAP implementer • Possible lack of support by management in faculties involved • An additional agreement signed by the involved faculty deans and the Rector seems necessary.

15. Major problems and proposed solutions (2) • Competence and authority of nominated PMs • Fragile competence and authority of nominated PMs at the faculties • lack of practical experience in project management • not enough authority at their institutions • The PM of the pilot now leads the project at the University level • he should transfer best practices from the pilot project. • Autonomy of faculties and data privacy • The faculties reluctant to expose their transactional financial data • The Rector’s Office should receive only the summary data. • additional agreement to grant the data privacy (Rector-deans)

16. Major problems and proposed solutions (3) • Lack of key end users at the faculties • Faculties' administrative personnel - scarce and reluctant to change • peer-to-peer communication with counterparts from the pilot project • Integration of business processes • requirements accumulation while the faculties will be joining the project • Integration of transactional functionalities • integration of data at the University as a summary information

17. Major problems and proposed solutions (4) • Project execution • The PMs from some faculties “in shadow” • due to lack of support from their respective deans and/or • dominated by some more competent colleagues, members of PM board • autonomous execution of sub-projects at the faculties, in co-operation between the faculty PM and the SAP PM • The PM appointed by the University should enforce the authority, independence and self-esteem of faculty PMs • Project monitoring and control • Transparency of project activities at 3 dislocated faculties • The PM should provide a common system of communication • A portal containing relevant information • Weekly meetings of the PM board

18. Major problems and proposed solutions (5) • Support and maintenance • Partly imprecise contract for the project (licensing, support, maintenance) • The faculties should be aware what awaits them • additional workload, costs of licenses and maintenance • the Steering committee should negotiate the conditions for the production stage ASAP • Reorganization of the University • Some participants propose that the computerization should immediately support an integrated University as it may look in some not so near future. • out of scope – limited influence of stakeholders on future organizational actions taken by the University and by the Ministry • implementation according to the current practice - revision of user roles and privileges as a consequence of future organizational changes

19. Conclusion • 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 • the only conceivable way is to put them at the end of the implementation line and condition their further financing with quality of supply of their information