Enterprise resource planning (ERP) systems have become a fact of life in higher education. A 2002 EDUCAUSE Center for Analysis and Research (ECAR) study estimated that higher education 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 majority of institutions of higher education will be running ERP systems.
An ERP system’s success rests on the integration of data across the institution. An ERP eliminates the need for individual data stores, duplicate records, and coordination of disparate data systems 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 customer service between offices;
- difficulty complying with reporting requirements;
- heavy reliance on the computing center staff; and
- lack of capacity for process improvements.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 significant 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, the ongoing support costs, both direct and indirect, represent the single largest 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 periodically 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 departments 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 blessing of the university’s administration, the CIO pulled together a steering committee that oversaw the development of a request for proposal (RFP), the solicitation of bids, and the awarding of a contract. The ERP system selected was a database-centric suite of software applications that supported admissions, registration, financial aid, finance, human resources, and university advancement. The implementation of Gonzaga’s ERP solution took two years and was completed in 1997. Since that time the application has matured, with the school’s business processes being melded into and molded by its use.
Six years have passed since the migration to the new ERP system from in-house developed and third-party software solutions. University management asked the CIO to review the investment Gonzaga had made in the software and its relationship with the software vendor. Management also wanted to determine if the current strategy for use of enterprise software was still sound or if a different way of supporting the business functions of Gonzaga would be advantageous and a strategy of change prudent.
Questions to Answer
This study addressed a number of questions:
Analysis Methodology
Based 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 Gonzaga’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 necessary to support the system. This includes employees tasked with supporting the ERP both within and outside Gonzaga’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 implementation 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 Investment
ROI is, conceptually, the savings returned to the institution by the adaptation 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 system 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 Assessment
The 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 business 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 reasonably 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 project 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 departments. Thus, the study was able to determine, with a comfortable degree of accuracy, the initial cost of implementation. Costs for ongoing support relied on current expenditures and estimates of personnel time.
Results
To evaluate the Gonzaga ERP implementation, the study sought data in each of the categories considered relevant: total costs of acquisition and ownership, ROI, business needs, and comparison with peer institutions. The findings follow.
Total Cost of Acquisition
To determine the total cost of acquisition of the ERP system, the study combined 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 significant increase in scope and cost from the application vendor;
- a need to engage the application vendor 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 implement 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 Ownership
Again, TCO was estimated by combining 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.
Click image for larger view.
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. Moreover, a little over half of the costs are indirect in the form of staff dedicated to system and end-user support.
Return on Investment
Disappointingly, it proved impossible to estimate the ROI for the present project 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 management knew that an integrated software system was the only way that business 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 integrated software system. Several people in the development area stated that departmental headcount would have to be increased by six positions. The admissions department reduced headcount by four after the ERP implementation, 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.
Business Needs Assessment
We surveyed key department heads to determine the role the ERP system plays in the university’s business processes. 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, especially 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 historical database for all business and student information. Several employees stated that the ERP far exceeded their expectations 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 integrated application like [our ERP]."
- "We could not be raising the kind of funds we are today without [our ERP]."
- "[Our ERP] revolutionized the use of data in the university environment."
- "It was critical for Gonzaga to reconcile and standardize its business processes. [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 universities use for their core business application(s), how do they like their vendor relationship, and how well are they being supported? Of the nine institutions surveyed, 67 percent used the same ERP system as Gonzaga for their core application. All of them used enterprise applications; no university used a best-of-breed approach. Of the 28 institutions in the AJCU, 86 percent of them use an ERP solution, 11 percent use best-of-breed, one uses a homegrown application, and one uses nothing.
Interestingly, no institution was interested in changing. Each was pleased with its vendor’s support, frequency of feature/function upgrades, response to technical issues, and so on. Some complained 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 applications 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 individual small software companies going out of business, and two had experienced just that problem. Most mentioned either the difficulty or the impossibility 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 support 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 outsourcing as part of our research, this solution usually costs more. Moreover, institutions usually have some cultural comfort 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. However, 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.
Conclusions
Each 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 businesses, need accurate, clean, stable, current, and historical data. For universities to make informed decisions, to operate efficiently, and to offer their students the best educational experience possible, 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 available 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 university 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 functionality available within the application 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 functions. 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 University take full advantage of its ERP implementation.