Total Cost of Ownership of Enterprise Resource Planning Software: Simulating a Dynamic Feedback Perspective in the Higher Education Environment

Meg Fryling, Ph.D. Candidate

Informatics Department

University at Albany

Agenda

• Enterprise Resource Planning (ERP) • Case Study Environment• Problem Statement• Research Questions• Research Process• Questions

Enterprise Resource Planning (ERP)

• Based on a common database and a modular software design.– Student Records, Student Accounts, Financial Aid, Human

Resources, Financials – Common database allows every department of a business to store

and retrieve information in real-time.

• Information more reliable, accessible, and easily shared. • Data for the various business functions are integrated.

– Financial aid awarded => rebate check issued– Bill paid => hold removed– Deposit paid => eligible to register, advisor assigned, userid

created, email account created

Pre-ERPDisparate Computer Systems

(Data Silos)

StudentRecords

StudentFinAid

StudentAccts

ParkingMgmt

HumanResources

Financials

ERP Integration

StudentRecords

StudentFinAid

StudentAccts

ParkingMgmt

•Shared database

•No Interfaces

•All data is “real time”

•No data redundancy

•Standardized technology

•Database

•Software

•Hardware

ERPERP at UAlbany 1995-19971995-1997March 1999March 1999

Purchase ERP (RFI, RFP, etc.)Purchase ERP (RFI, RFP, etc.)Prospects, version 7.6Prospects, version 7.6

June 2000June 2000 HR, version 7.6HR, version 7.6

November 2000November 2000 Admissions, version 7.6Admissions, version 7.6

March 2001March 2001 Orientation andOrientation andSPC, version 7.6SPC, version 7.6

February 2002February 2002 SR & SF for UHS, ver. 7.6SR & SF for UHS, ver. 7.6

September 2002September 2002 Upgrade to 8.0Upgrade to 8.0

June 2003June 2003 Student Records, version 8.0Student Records, version 8.0

January 2004January 2004 Financial Aid, version 8.0Financial Aid, version 8.0

May 2005May 2005

August 2008August 2008

Full Student FinancialsFull Student Financialsversion 8.0version 8.0Upgrade to 9.0Upgrade to 9.0

ERP Lifecycle• Planning

– Most important part – Fit-gap– Functional and technical parties must be involved and work hand-in-hand

• Execution– KISS – Avoid customizations – Who makes decisions (Customize vs. BPR)?

• Post-Implementation– The system will NOT be 100% when you “go-live”– Maintenance, upgrades and extension of capabilities

• UPGRADE ERP implementations average between 1 and 3 years

- Source – Enterprise Resource Planning Research Center, www.cio.com

SD and ERP

• ERP projects are dynamic problems arising from complex social, managerial and economic systems.

• ERP projects are dynamic system characterized by interdependence, mutual interaction, information feedback, and circular causality

• Need for improved policy analysis and design

Feedback Loops

Patches/Upgrades

(Y)

Rework/Recustomization

(Z)

Time to

Implement ERP

(X)

1. The Problem

• The time and resources required to implement and maintain ERP systems far exceed original expectations

• The purchase price for ERP software is the most visible expense, but implementation and maintenance contains many hidden costs

• Organizations fail to recognize the true Total Cost of Ownership (TCO) of ERP systems and often make policy decisions early in the implementation plan that likely have long-term impacts on the TCO

1. The Problem

• Tend to make decisions with little solid information. This happens simply because we are running out of time!

• Sometimes our decisions come back to haunt us in the long-term.

• Have not fully extended the ERP capabilities (Stage 3) let alone create new capabilities (Stage 4).

• The inability to move forward in the ERP lifecycle prevents realization of the full potential benefit of ERP (West and Daigle 2004).

• Unable to get the decision makers to see the big (long-term) picture.

Source: ECAR Research Bulletin “Total Cost of Ownership: A Strategic Tool for ERP Planning and Implementation”

We are here

Lifecycle of ERP Benefits

Functional vision

What they don’t see

What can we do to make them see the entire picture?

2. Hypothesis

• Adding time and resources can complicate the issue

• The major problem is scope related• The scope creep problem is significantly

larger than anyone realizes with long-term recurring implications (feedback loops)

• The dynamics over time are not known to the key decision makers – If this could be communicated more effectively earlier in the process different decisions would be made

Relationship between Time, Resources and Scope

Scope

Time Resources

Diagram taken from IBM literature

Scope

Time Resources

Relationship between Time, Resources and Scope

Research Questions

• Why after all these years are organizations still doing a poor job at estimating the time, cost and workforce resources required when implementing and maintaining ERP systems? – What cost drivers are we missing when estimating ERP cost?– What are the dynamic relationships between these cost drivers?– How can we better predict long-term total cost of ownership to

implement and maintain ERP systems?– How do policy decisions upstream influence cost outcomes

downstream? (e.g. deployment strategies, fit gap analysis, corporate governance changes, level of customization versus business process reengineering)

Study PurposeTo develop a framework using system

dynamics that will…– Enable organizations to better predict the

long-term cost of ERP implementations – Identify key cost drivers– Reveal the impact of and justification for

significant organizational changes in such a way as it can be easily communicated to key stakeholders

– Improve IT and Functional communications– Improve decision making

Research Process

• Phase 1 – Literature Review• Conduct literature review of the following

domains: – Information Systems/Technology– TCO methods and components– ERP implementation case studies– Business Process modeling– Organizational Behavior and Management– Project Management– System Dynamics (as it relates to the domains above)

Research Process

• Phase 2 – Model Prototype• Develop model prototype based on existing

system dynamics project models. Model will specifically address pre-packaged software implementations; tying model constructs to literature.– Includes extending model/research that was developed as

part of Ph.D. coursework and presented at the 2007 System Dynamics Conference in Boston, MA.

Research Process• Phase 3 – Case Study Data Collection• Qualitative

– Observe decision making behavior in Steering Committee Meetings

– Interview key decision makers (e.g. CIO, VP of Enrollment Management)

• Quantitative– Survey project participants (technical, functional,

steering committee)– Collect UAlbany ERP upgrade task tracking data

from existing data source

Interview, Surveyand Observation

• What factors drive/influence decisions?

• Who do different parties see as the primary stakeholders?

• Functional vs. technical perceptions– Resources required (long-term) vs. ROI

Task Tracking Data

• Number of total tasks– Open, In-progress, resolved, closed

• Number of customizations– Number of times customization reapplied

• Expected effort

• Actual effort

• Rework (tickets reopened)

Research Process

• Phase 4• Calibrate model with UAlbany case study

data• Validate model structure and behavior by

interviewing UAlbany key players in original ERP implementation and/or upgrade

Research Process

• Phase 5• Re-interview key decision makers with model

demonstrations – Anything surprising?– Would they make a different decision?

Dynamic Behavior to Consider

• Customizations must be reapplied if that part of the software product is redelivered

• TCO of a customization will increase indefinitely. Only way to stop growth is to eliminate customization.

• Once a customization exists there is a customer expectation that it will remain

• Once you customize one component it is difficult to justify not customizing another (political slippery slope)

Dynamic Behavior to Consider

• Customizations can break other delivered components of the software (domino customization effect) – Vendors don’t support customizations

• When preparing for an upgrade, tasks completed in the old environment must be completed twice

• Resources tied up on upgrade work are unavailable for new projects (task backlog)

3. Computer Simulation Model

Scope Stocks

4,000

3,000

2,000

1,000

0

0 8 16 24 32 40 48 56 64 72Time (Month)

Tasks perceived remaining : ERP Base tasksTasks perceived complete : ERP Base tasksTasks actually remaining : ERP Base tasksAbandoned tasks : ERP Base tasks

Scope Flows

60

45

30

15

0

0 4 8 12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72Time (Month)

Accepting new tasks : ERP Base tasks/MonthDiscovering cust needing rework or reapp : ERP Base tasks/MonthDiscovering work : ERP Base tasks/MonthCompleting tasks : ERP Base tasks/MonthEliminating tasks : ERP Base tasks/Month

5. Test Policies Increase Work Hours Policy

(40 to 65 per week)Tasks actually remaining

4,000

3,000

2,000

1,000

0

0 8 16 24 32 40 48 56 64 72Time (Month)

Tasks actually remaining : Increase Work Hours tasksTasks actually remaining : ERP Base tasks

5. Test Policies No Customizations Policy

Tasks actually remaining

4,000

3,000

2,000

1,000

0

0 8 16 24 32 40 48 56 64 72Time (Month)

Tasks actually remaining : No Customizations tasksTasks actually remaining : ERP Base tasks

Importance

• Do more with less

• Allocate resources more wisely

• Biggest bang for the buck - Low hanging fruit

• Make better decisions - aligned with organizational goals

Issues with Existing Cost Estimation Models

• Accuracy and Portability

• Need to take into consideration managerial and organizational characteristics of the environment - not just technical aspects (Abdel-Hamid and Madnick 1990)

Research Goals

• Improve communication between IT and functional decision makes

• Develop model that will provide policy insights

• Help institutions make better IT implementation decisions!– …leading to more effective resource

allocation/utilization

Thank you!

Questions?

Sources

• Abdel-Hamid, T. and S. E. Madnick (1990). Software Project Dynamics: An Integrated Approach. Upper Saddle River, Prentice Hall.

• Dodds, T. and R. Spencer (2007). "Next-Generation Administrative Systems: Philosophy, Principles, and Technology." ECAR 2007(19).

• West, R. and Daigle, S. L (2004). “Total Cost of Ownership: A Strategic Tool for ERP Planning and Implementation”. ECAR 2004(1).

• Hammer, Michael (1990). Reengineering Work: Don’t Automate, Obliterate. Harvard Business Review. July-August.

• Martin, M. H. (1998). An ERP Strategy. Fortune. February: 95-97.• Peterson, S. (2003). Lost Signals: How Poor Communication and Other

Nontechnical Issues Hampered Arkansas’ Innovative Statewide ERP Implementation. Government Technology. February.

• Richardson, George P. (2001). “ System Dynamics”. Encyclopedia of Operations Research and Management Science. 807-810.

• Tapp, R. M., J. Hesseldenz, et al. (2003). The Role of Project Acceptance in the Successful PeopleSoft Human Resources Management System Implementation for the Kentucky Community an Technical College System. Ninth Americas Conference on Information Systems.