1

Project of SAP ERP Implementation Into Academic Community – Lessons LearnedProject 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

Episode IEpisode 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 showcase in HE!

5

Project organization

Business reportingBusiness reporting

Project mgt.

Project mgt.

Steering comittee : Ministry, University, Faculty, Implementer

Financemgt. and bookkee

ping

Financemgt. and bookkee

ping

Procurement mgt.

Procurement mgt.

Informing and

Decision making

Project manager & deputy - FacultyProject manager & deputy - Implementer

Director – MinistryDirector – Implementer

HR mgt.

Data exchange

and integration with other systems

Data exchange

and integration with other systems

subteams: consultants and key userssubteams: consultants and key users

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 & 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

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-production support 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

Episode IIEpisode II

The University

21

The master plan

Project was kicked-off „on the first deadline”21

Deadline 1.9.2009. 1.1.2010. 1.4.2010. 1.7.2010. 1.10.2010. 1.1.2011.

Project management

Quality assurance

Production support

Rectorate

+ 3 faculties

6 faculties

1.4.2011. 1.7.2011. 1.10.2011. 1.1.2012.

6 faculties

6 faculties

6 faculties

5 faculties

FERFER

22

Project organization

PROJECT MANAGEMENT BOARD

Director – University

Director – Implementer

PM – Implementer (IPM)

PM – University (UPM)

PMs – faculties (FPMs)

Advisors – from faculties and University CC

FACULTY #1

FPM and deputy

FACULTY #2

FPM and deputy

FACULTY #3

FPM and deputy

SUPERVISORY BOARD

Ministry

University

Faculties

Implementer

SUPERVISORY BOARD

Ministry

University

Faculties

Implementer

QUALITY MANAGEMENT BOARD

RECTORATE

Coordinator

UPM’s deputy

(pilot) FACULTY

UPM 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

What we thought 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

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

… 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.

Episode IIIEpisode III

The Twist

30

Annex 2 (to the contract)

Change of scope 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 Approved by Steering committee

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.

31

The implementation

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

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.

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.

1.5.2012.

1.7.2012. … 23.10.2012. 28.12.2012. 20.3.2013. 14.4.2013.

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 ?

Episode IVEpisode 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 …