an erp post implementation review ( planning for the future by looking back )

EDUCAUSE QUARTERLY • Number 3 200540

An ERP Post-Implementation Review:

Enterprise resource planning (ERP) systems have become a fact of life in higher education. A 2002

EDUCAUSE Center for Applied Research (ECAR) study estimated that higher edu-cation had spent close to $5 billion on ERP systems.1 According to the study, 54 percent of survey respondents had implemented an ERP as of the summer of 2002, and an additional 35 percent expected to implement an ERP module or to add a module to an existing system within the next three years. By the time this article appears in print—assuming these plans were realized—a large major-ity of institutions of higher education will be running ERP systems.

An ERP system’s success rests on the integration of data across the institu-tion. An ERP eliminates the need for individual data stores, duplicate records, and coordination of disparate data sys-tems with unique record formats. At one institution, circumstances that argued for moving to an ERP system included■ a redundant, disorganized database

structure;

■ inaccurate data;■ difficulty in reporting and sharing

information;■ dependence on manual processes and

human interventions;■ problems in providing seamless cus-

tomer service between offices;■ difficulty complying with reporting

requirements;■ heavy reliance on the computing cen-

ter staff; and■ lack of capacity for process improve-

ments.2

Many participants at an EDUCAUSE 2001 Roundtable cited an increased ability to provide student services as an additional reason for moving to an integrated ERP.3 ERP systems promise to increase operational efficiency, improve customer service, and help enforce an institution’s business rules.

An ERP system represents a signifi-cant investment, both for acquisition and for ongoing support. At small and mid-size institutions, the cost of acquiring an ERP system can seem daunting. For many such institutions,

A study of Gonzaga’s use of its enterprise resource planning system recommended further investment in the software

By Wayne D. Powel and Jim Barry

LOOKING BACKPlanning for the Future by

Number 3 2005 • EDUCAUSE QUARTERLY 41

the ongoing support costs, both direct and indirect, represent the single larg-est technology expenditure each year. An ERP system is more than just an information system, however—it embodies the institution’s business rules. It must be closely tied to the institution’s business needs for the institution to realize the system’s full benefit.

Therefore, not only is it critical that institutions choose an ERP system with utmost care, they should peri-odically review that system. Such a review should highlight, to the extent possible, the total cost of ownership (TCO) and how well the system aligns with the institution’s business needs. What follows is a description of just such a review conducted at Gonzaga University.

A Brief History of Gonzaga’s ERP System

In 1995, Gonzaga University embarked on a project to implement a university-wide information system. The search for an “out-of-the-box” solution began following an attempt to build an integrated data management system in-house. In the early 1990s, the university had slowly begun to digitize its student records as well as its financial and student accounts data. The university realized the advantage of tying these different data systems into an integrated system and the efficiency to be gained by managing one set of computer records. After more than two years of trying to get different depart-ments to specify their data needs and to integrate those needs with those of other departments, however, database

managers had made little progress.In 1994, Gonzaga decided to look at

commercial solutions to its database management problems. With the bless-ing of the university’s administration, the CIO pulled together a steering com-mittee that oversaw the development of a request for proposal (RFP), the solici-tation of bids, and the awarding of a contract. The ERP system selected was a database-centric suite of software appli-cations that supported admissions, reg-istration, financial aid, finance, human resources, and university advancement. The implementation of Gonzaga’s ERP solution took two years and was com-pleted in 1997. Since that time the appli-cation has matured, with the school’s business processes being melded into and molded by its use.

Six years have passed since the migra-


tion to the new ERP system from in-house developed and third-party soft-ware solutions. University management asked the CIO to review the investment Gonzaga had made in the software and its relationship with the software ven-dor. Management also wanted to deter-mine if the current strategy for use of enterprise software was still sound or if a different way of supporting the busi-ness functions of Gonzaga would be advantageous and a strategy of change prudent.

Questions to AnswerThis study addressed a number of

questions:1. What was the total cost of acquiring

and implementing Gonzaga’s ERP?2. What is the ongoing TCO?3. Is it possible to calculate the univer-

sity’s return on investment (ROI)?4. Does Gonzaga’s ERP meet the major

business needs for which it was purchased?

5. What are other approaches to sup-porting the same business functions, and what would it cost to migrate to and support these solutions? Are there other cost-effective ways to meet the same business needs?

6. What approach do other institutions take to information management? What core applications are they using? What are their experiences and relationships with their applica-tion vendors?

Analysis MethodologyBased on the answers to the above

questions, recommendations were to be made regarding Gonzaga’s ERP use and suitability.

Total Cost of Acquisition and Total Cost of Ownership

Both the total cost to acquire Gonza-ga’s ERP system and the total cost for ongoing support were determined by combining the direct and indirect costs for each. Direct costs include hardware, software, licensing, support contracts, and consultation. Indirect costs consist primarily of the salaries of staff neces-sary to support the system. This includes employees tasked with supporting the

ERP both within and outside Gonza-ga’s central technology department. In the latter case, the work performed was often classified as technology-type work but included making policy and process decisions necessary for imple-mentation of the ERP and its operation. Where necessary, an employee’s salary was prorated by the time the employee spent supporting the system.

Return on InvestmentROI is, conceptually, the savings

returned to the institution by the adapta-tion of a new business system or process. Ideally, an institution would be able to show either that a new business system was less expensive than the existing sys-tem or that a new system accomplished the same work more efficiently than the existing system.

ROI ends up as one of the more elusive measurements in higher education. First, while the costs of the new system are easy to identify, the savings often are not. The “return” part of ROI often comes from indirect savings, which typically do not appear on the bottom line. Instead they are the savings that come from operating more efficiently, or even from expenses avoided. Second, it can be difficult to clearly attribute some savings to the new system and not—in whole or in part—to other organizational changes. Institutions of higher education are dynamic, with myriad changes taking place at any time. It can be difficult, if not impossible, to confidently assign a savings or a return to a particular change, especially in a post hoc analysis.

Business Needs AssessmentThe RFP by which the university chose

its ERP served as the vehicle to judge the

extent to which the ERP was meeting business needs. The heads of various critical departments were surveyed to determine the extent to which the ERP did or did not meet those original busi-ness needs.

Comparison with Peer Institutions

The CIOs of nine other universities were interviewed to determine what software they used to support their business functions; their experience with their software vendor(s); and their propensity to change applications. This select group of institutions was reason-ably comparable to Gonzaga—all were private schools with enrollments of less than 10,000 students. The results of this survey were combined with one conducted by the Association of Jesuit Colleges and Universities (AJCU). The AJCU consists of 28 Catholic colleges and universities of various sizes in the United States.

Gonzaga’s CIO kept extensive notes and files on the process of selecting and implementing an ERP. These materials proved invaluable in looking back to 1995 and 1996. The original RFP was used as the baseline for proj-ect goals. The CIO’s notes gave a full picture of the implementation team and its meeting schedule; the notes were used to provide an estimate of the personnel costs for implementation. Many key department heads also kept notes of the implementation process within their departments, and these notes were used to estimate how the implementation affected those depart-ments. Thus, the study was able to determine, with a comfortable degree of accuracy, the initial cost of imple-mentation. Costs for ongoing support relied on current expenditures and estimates of personnel time.

ResultsTo evaluate the Gonzaga ERP imple-

mentation, the study sought data in each of the categories considered rel-evant: total costs of acquisition and ownership, ROI, business needs, and comparison with peer institutions. The findings follow.

It can be difficult, if not impossible,

to confidently assign a savings or return

to a particular change, especially in a

post hoc analysis


Total Cost of AcquisitionTo determine the total cost of acquisi-

tion of the ERP system, the study com-bined direct and indirect costs.

Direct Costs. Gonzaga’s original budget for this project was just under $1 million, including software, consulting, and the cost to upgrade to an HP 9000 mid-range server. The consulting budget was to cover implementation, education, and training, as well as some customization of the ERP.

There were significant overruns in direct costs, which added approximately one-third to the original budget. These overruns were attributed to■ a mid-stream change in the software

from a character-mode screen format to a graphical user interface (GUI) screen format;

■ a lack of understanding of the amount of Gonzaga resources needed to assist in the project, which drove a signifi-cant increase in scope and cost from the application vendor;

■ a need to engage the application ven-dor to perform programming tasks that were assumed Gonzaga staff would perform; and

■ a significant increase in the need for vendor education of Gonzaga staff.

Indirect Costs. Indirect costs more than doubled the cost of acquisition. They were estimated at about $2.2 million, making the estimated total cost of acquisition close to $3.5 million. The majority of those costs were human resources devoted to implementing and migrating to the ERP. The cost of human resources was estimated from the project plan developed by the CIO. The CIO closely detailed the makeup of both managerial and departmental resource teams, their project meeting plans and frequency, and the duration of the project. Discounting current employee costs developed a historical cost of resource. Time logs kept by some department heads during the project were used to estimate departmental resource investments in the ERP project.

Gonzaga anticipated it would take a significant investment of time and

other resources to acquire and imple-ment its ERP. However, the magnitude of the costs was surprising. If Gonzaga’s experience is typical, the indirect cost to an organization of implementing a business-wide software application far exceeds the direct costs. Regardless of the actual numbers, it is likely that most institutions fail to understand exactly how much staff time is required, nor do they account for the value of that time. A significant additional burden is also placed on the staff, particularly in terms of data and process migration.

Total Cost of OwnershipAgain, TCO was estimated by com-

bining direct and indirect costs of ownership.

Direct Costs. The direct costs for ongoing support of Gonzaga’s ERP were calculated as the total of annual licensing for the ERP as well as supporting software, the costs of supporting hardware, and an amortization of the mainframe system that supports the ERP. The hardware for the ERP is amortized over a five-year period—a bit on the long side for equipment of this type, but it balances hardware aging versus the demands of a tight budget. Ongoing costs for software represent about 20 percent of the initial software expenditure, which is typical for enterprise applications. Direct costs of ownership are about 42 precent of the total ongoing costs to support the ERP.

Indirect Costs. The total indirect costs are less well articulated. Included here are the costs of staff tasked with supporting and developing the ERP, whether or not they are in the central technology department. Also included are the ongoing costs for internally driven training. Together, these indirect support costs are 58 percent of the total ongoing cost to support the ERP. As would be expected, however, the ongoing indirect costs are a mere fraction of the cost to acquire and implement the system (18 percent).

See Table 1 for a summary of the total costs of ownership.

As should be clear, supporting an ERP demands a significant investment

of funds. Gonzaga annually expends close to three quarters of what it cost to acquire the system to support it. More-over, a little over half of the costs are indirect in the form of staff dedicated to system and end-user support.

Return on InvestmentDisappointingly, it proved impossible

to estimate the ROI for the present proj-ect because no financial justification was developed when Gonzaga decided to move from a homegrown system to an ERP system. As strange as this seems, it makes perfect sense. University man-agement knew that an integrated soft-ware system was the only way that busi-ness processes could be standardized and the foundation built that would allow Gonzaga to grow and prosper. Increased efficiencies and productivity were the common theme for ROI from the ERP system.

ROI discussions with staff quickly turned to discussions of what it would cost if Gonzaga did not use an inte-grated software system. Several people in the development area stated that departmental headcount would have to be increased by six positions. The admissions department reduced head-count by four after the ERP implemen-tation, while enrollment increased by a factor of two. General consensus was that because of the ERP capabilities, Gonzaga was able to maintain level or reduced staffing while the university grew substantially.

Table 1

Costs of Ownership

Direct Costs Percent

Software and licensing

29

Hardware 4

Amortization 9

Indirect Costs

Training 6

Gonzaga staff 52

Total 100


Business Needs AssessmentWe surveyed key department heads

to determine the role the ERP system plays in the university’s business pro-cesses. The survey included a look back at the university’s expectations for the ERP implementation and asked whether respondents believed the ERP solution has met RFP requirements. Department heads were also asked if they were aware of other ERP systems or best-of-breed systems that would better meet their departments’ needs or the needs of their constituents. These needs were the same used to develop the initial RFP (detailed in the sidebar).

No one interviewed said that needs were not being met. When presented with the list of system expectations drawn from the RFP, all agreed that the system met their basic needs. There was one unanimous exception—the need for an easy to use, ad hoc report writer. The consensus was that the ERP system’s report writer is difficult to use, espe-cially if only used occasionally. Once an employee was experienced in extracting and reporting data, the tool became second nature.

A recurring theme hammered home by everyone interviewed was the value of an integrated system and a single histori-

cal database for all business and student information. Several employees stated that the ERP far exceeded their expec-tations and that it fully supported the mission of both the university and their specific departments. The core reason for this view is the availability of clean, reliable data supporting a system that enforces set business processes. Some of the supporting comments follow:■ “Gonzaga could not have progressed

to the point it is today without an inte-grated application like [our ERP].”

■ “We could not be raising the kind of funds we are today without [our ERP].”

ERP System Expectations Based on RFPGeneral Objectives

To provide a single integrated univer-

sity information system that

■ Reduces redundancy and stream-

lines data entry using a variety of meth-

ods such as keyboard entry, scanning,

bar-coding, and others.

■ Allows current and historical data

to be efficiently stored, secured, and

accessed to provide accurate informa-

tion to the university community.

■ Provides a sophisticated tracking

system for use by all areas of the

university.

■ Provides an easy-to-use, user

friendly, ad hoc report writer that can

easily access any field (with appropriate

security) to extract data for producing

management, information, or special

reports on screen, printed, or down-

loaded to the workstation.

■ Provides a flexible system that can

adapt to changes and will continue to

meet our needs in the future through

new functionality, enhancements, and

improvements offered by future soft-

ware releases.

■ Utilizes a system based on UNIX

and Open Systems standards, which

better poises the university for future

technological decisions.

■ Integrates with various PC

applications.

■ Allows for the opportunity to

consolidate computing services for cost,

operating, and technology efficiency.

■ Allows for integration of image

processing, campus-wide ID cards, a

kiosk system, and telephone processing

of information.

■ Provides the university with the

opportunity to seriously examine the

current processes and determine how

to improve and realign our business

policies and practices in order to better

serve the university community.

■ Provides opportunities for better

personnel utilization.

■ Is completely operational, in its

baseline state, by the April/May 1997

timeframe.

Alumni/Development■ Provide effective management

of alumni information and events

including maintenance of historical

information.

■ Provide effective and accurate

tracking of cash gifts, pledges and

outstanding pledges, estates, matching

gifts, and other development records,

allowing for management of histori-

cal data on donors and prospects to

include tracking progress of prospects

through cultivation, solicitation, and

stewardship.

■ Provide an effective means of man-

aging the gift accounting and acknowl-

edgement process.

■ Allow for coding of donors/pros-

pects according to region and/or

interest.

Financial■ Maintain all required account-

ing records in accordance with GAAP,

NACUBO, the federal government, and

other agencies and standards.

■ Maintain all accounting records

and files to ensure accurate and effi-

cient budget management, from both a

current and historical perspective.

■ Ensure that all requirements for

financial statements, audit reports,

grant reports, IRS compliance audits,

etc., can be met accurately and

efficiently.


■ “[Our ERP] revolutionized the use of data in the university environment.”

■ “It was critical for Gonzaga to recon-cile and standardize its business pro-cesses. [Our ERP] did that for us.”

■ “Implementation of [our ERP] was the single greatest achievement of the last decade at Gonzaga.”

Comparison with Peer Institutions

What do other colleges and uni-versities use for their core business application(s), how do they like their vendor relationship, and how well are they being supported? Of the nine insti-

tutions surveyed, 67 percent used the same ERP system as Gonzaga for their core application. All of them used enter-prise applications; no university used a best-of-breed approach. Of the 28 insti-tutions in the AJCU, 86 percent of them use an ERP solution, 11 percent use best-of-breed, one uses a homegrown appli-cation, and one uses nothing.

Interestingly, no institution was inter-ested in changing. Each was pleased with its vendor’s support, frequency of feature/function upgrades, response to technical issues, and so on. Some com-plained of being oversold or of being sold “vaporware,” but that is a prevalent

phenomenon in the enterprise software world. Most of the institutions surveyed have looked at other enterprise appli-cations from time to time but found no compelling reason to change. The benefits of changing did not outweigh the costs.

Of the nine CIOs interviewed, none would ever again use anything other than an enterprise-level application. Implementing a best-of-breed solution was deemed too costly and, as one CIO stated, “A step back into the dark ages.” Some CIOs were concerned about indi-vidual small software companies going out of business, and two had experi-

■ Ensure that all internal requests for

any type of financial information (indi-

vidual payroll, departmental revenue or

expenditure, etc.) can be met promptly.

■ Provide authorized end-user access

to appropriate financial information

online.

Financial Aid■ Provide annual updates of recent

regulatory changes affecting the

administration of the federal student aid

programs.

■ Provide for enhanced budgetary

controls in order to monitor offers,

acceptances, and declinations of all

types of financial aid.

■ Reduce redundancy between the

Student Employment, Financial Aid, and

Payroll databases for student worker

data.

■ Allow for certain holds to be

created that are document- or fund-

specific in order to allow or prohibit

certain types of financial aid from being

awarded or disbursed.

■ Provide for automation of the

receipt and accounting of electronic

fund transfers for student loan proceeds.

■ Eliminate the majority of manual

efforts involved in monitoring of satis-

factory academic progress.

■ Allow for incorporation of a finan-

cial aid voice response system.

■ Provide for automated packaging

of financial aid based on packaging

philosophies and criteria determined by

our financial aid management.

■ Provide for efficient passing of

applicable taxable aid (i.e., waivers)

information to Payroll.

Human Resources■ Provide an integrated database

for Human Resources and Payroll to

streamline and enhance management

of employee records.

■ Provide a source of data on appli-

cants and employees that HR can use

to monitor, manage, and plan various

aspects such as Employment Admin-

istration, Job Classification, System

Design, Total Compensation System

Design, Benefits Administration, Equal

Employment and Affirmative Action

Compliance, Position Management,

Position Control, and Employee Rela-

tions Administration.

■ Provide a source of data for federal

and state compliance reporting.

■ Provide the ability to maintain

and report historical salary and benefits

data by program, department, and/or

employee group.

Student Information■ Provide for automated billing and

letter generation functions throughout

the Student system.

■ Provide for the advancement of

institutional research, through the avail-

ability of centralized data, for retention

and marketing efforts.

■ Allow restricted access to students

in order to eliminate unnecessary pro-

cessing steps.

■ Provide for an accurate, stream-

lined process for academic records from

Recruitment through Degree Audit.

■ Provide services to achieve enroll-

ment goals.

■ Provide faculty access to advising

information.

■ Provide for a centralized location

management facility.


enced just that problem. Most men-tioned either the difficulty or the impos-sibility of integration as a reason not to consider best-of-breed systems. Two also stated that best-of-breed solutions do not allow for setting and enforcing business processes, which is critical to all but the smallest universities.

The study also explored outsourcing and collaboration as ways for Gonzaga to obtain the business application sup-port needed other than by managing its own ERP.

Outsourcing. With an outsourcing solution, an outside vendor owns the equipment and software and provides connectivity to the application, support for the application, and other services for a fee. The systems are usually housed in a hardened data center. The institution’s connection to both the database and the application is by a high-speed dedicated network or through the Internet.

Although we did not price outsourc-ing as part of our research, this solution usually costs more. Moreover, institu-tions usually have some cultural com-fort issues with outsourcing. First is the concern that “Someone else has my data!” Outsourcing vendors are aware of this concern and take steps to build systems and processes to assuage the nervousness of their prospects. Second is a concern about the responsiveness of the vendor to problems or change requests. There is a general belief that the closer you are to the resource, the better the support you will receive, and the farther away, the worse. How-ever, responsiveness usually isn’t an issue after the system is turned over to the outsource provider and things are stabilized.

Collaboration. With a collaborative or consortium solution, two or more universities negotiate collectively to purchase hardware and software on the theory that cost per user will be driven down by economies of scale, particularly from the standpoint of the server and storage farm. One university hosts the equipment and the other consortium members connect as they would if the service were outsourced. For those

consortium members not hosting the service, not only are there the same set of concerns as in the outsourcing solution, but additional questions about data integrity and security and about the hosting institution’s commitment to equal service. Can non-host institutions be ensured parity of support, or will the host institution take care of itself first? Many software application vendors are not supportive of these arrangements. Consortium solutions often translate into lower licensing fees and larger support headaches.

ConclusionsEach university needs a system that

supports all its business functions, which need to be integrated. Business processes and practices must be well defined, supported, and enforced, and the university’s ERP system is central to this enforcement.

Universities, in their role as busi-nesses, need accurate, clean, stable, cur-rent, and historical data. For universities to make informed decisions, to operate efficiently, and to offer their students the best educational experience pos-sible, they need the best data possible. An ERP that integrates the business data on which an institution relies best meets this need. Moreover, data must be avail-able in real time to users across multiple departments and business functions. University faculty, staff, and students should find the system easy to use.

The cost of supporting technology is high for any business. Moreover, as the present study demonstrated, much of the cost of implementing and

maintaining technology can be hidden from view. Approximately two-thirds of Gonzaga’s total cost for implementing its ERP system was indirect. Still, the system goes a long way to pay for itself in terms of savings from unfilled staff positions alone. Even more difficult to price are the increased efficiency and improved customer service the system provides.

Gonzaga still has much more to gain from its ERP implementation. The uni-versity needs to extend its investment in the ERP system to support its new technological vision and fulfill the expectations of its stakeholders. The university should determine the func-tionality available within the applica-tion that is not being used, develop a program to begin using this unfulfilled potential, and educate staff on the features and use of the added func-tions. Finally, Gonzaga should develop an ongoing educational program for mid to senior management to train them in new features and refresh their knowledge of the system’s capabilities. These steps will help Gonzaga Uni-versity take full advantage of its ERP implementation. e

Endnotes 1. R. B. Kvavik et al., The Promise and Per-

formance of Enterprise Systems for Higher Education (Boulder, Colo.: Educause Cen-ter for Applied Research, Research Study, Vol. 4, 2002); <http://www.educause .edu/ers0204/>.

2. K. Pitter and M. Quiner, “Building the Raft While Going Through the Rapids,” pre-sented at EDUCAUSE 2002, Atlanta, Ga.; PowerPoint slides available at <http://www.educause.edu/LibraryDetailPage/666?ID=EDU02119>.

3. G. Spencer, Current Issues Roundtable, “Administrative Systems and Online Stu-dent Services,” roundtable conducted at EDUCAUSE 2001, Indianapolis, Ind.; meeting notes available at <http://www .educause.edu/ir/library/pdf/EDU0195 .pdf>.

Wayne D. Powel ([email protected]) is Associate Vice President for Information Tech-nology at Gonzaga University in Spokane, Washington. Jim Barry is Chief Executive Officer of 360 Consulting Group in Spokane, Washington.

Business processes

and practices must

be well defined,

supported, and enforced,

and the university’s

ERP system

is central to this

enforcement

an erp post implementation review ( planning for the future by looking back )

Documents