1

INTRODUCTION OF SAP ERP SYSTEM INTO A HETEROGENEOUS ACADEMIC

COMMUNITY

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

#1 A 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!

#3 A 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

20