University ERP: Big Mess on Campus

Disastrous ERP implementations have given more than a few universities black eyes. Fortunately, alternatives to these complex integrations now exist.

When Stefanie Fillers returned to the University of Massachusetts-Amherst campus last fall, she needed to log into the school's new online registration system, called Spire, to make certain that the courses she had signed up for would allow her to graduate. She also wanted to waive her participation in UMass's health insurance plan. So when Spire crashed the day before classes began, Fillers, a senior, was annoyed. But at least she knew where her classes were—unlike most first-year students.

"The freshmen were going crazy because they didn't know where to go," Fillers says. The Spire system allows all 24,000 students at the Amherst campus to register for classes and perform other online activities. So when it crashed as the result of a PeopleSoft Web portal implementation that had been rushed, classes were half-empty for the first three days of the semester. And there were long lines everywhere you looked.

Around the same time, returning Stanford University students were also welcomed by a nonfunctioning Web portal that prevented them from finding out where their classes were. And some 3,000 students at Indiana University were denied financial aid by a buggy new ERP system, even though they had already received loan commitments. While the IT department and financial aid administrators scrambled to fix the bugs in the complex system, short-term loans were processed for those cash-strapped coeds who needed to pay for classes, rent and food.

These recent campus meltdowns illustrate how the growing reliance on expensive ERP systems has created nightmare scenarios for some college CIOs. In every case, the new systems are designed to centralize business processes in what historically has been a hodgepodge of siloed legacy systems. And indeed, that's exactly why college administrators are drawn to ERP systems. They drool over the integrated views that an ERP system offers of finance, HR, student records, financial aid and more.

But those same officials often fail to see the enormous cultural and technical obstacles that can delay—and even cripple—such ambitious implementations. A recent survey found that university ERP implementations have taken far longer than expected and cost five times more than what the projected price tag was. "There are a lot of people who have scar tissue" from ERP failures, says Bob Weir, vice president of IS at Northeastern University—including himself.

ERP implementations are difficult, even in very top-down corporate environments. Getting them to work in universities, which are essentially a conglomeration of decentralized fiefdoms, is nearly impossible. Staff in the largely autonomous departments do not cotton well to the one-size-fits-all strategy of an ERP implementation. Yet for universities, developing all software in-house is not an option. These nonprofit organizations simply don't have the talent and financial resources to create and manage a robust enterprise system. Indeed, representatives from PeopleSoft, which dominates the higher education market for ERP, say that a large part of the problem results from the inexperience of university IT departments and their tendency to rush implementations and inadequately test the new systems.

There is, however, a workable alternative, according to some university CIOs who have endured ERP implementations and lived to tell about it. And that is using an integration middleware layer to stitch together a number of best-of-breed applications. In this environment, the integration layer allows CIOs to plug legacy systems into newer Web-based applications. Northeastern's Weir is using this approach to provide state-of-the-art systems for NU's students and administrators.

"The beauty of the Web is that you can do it all behind the curtain, using a relatively steady interface," he says.

ERP or Bust

By the mid-1990s, most college administrative systems were a disconnected mess of legacy applications. Forward-thinking administrators knew that they needed to graduate their aging homegrown systems. College administrators loved the idea of having an HR management, financial and student administration system that could unite offices and departments. PeopleSoft was one of the first ERP vendors to promise that views into financial aid information, class enrollment and registration data, staff benefits and faculty course loads would be available in real-time, with increased efficiencies and reduced costs.

The pitch worked.

At the end of 2004, PeopleSoft could boast more than 730 college and university installations, and it was the clear leader in higher ed. However, universities also purchased financial systems from other vendors. One university that bought into the ERP pitch early on was Cleveland State, and it now serves as a cautionary tale for CIOs. In a suit Cleveland State filed against PeopleSoft, the university alleged that the vendor sold it virtually unusable software that caused Cleveland State to lose millions of dollars in revenue because it couldn't collect accounts receivables, and subsequently, it had to install other software to do the job. (On Feb. 25, Oracle—which has since acquired PeopleSoft—and Cleveland State settled; news sources estimate the undisclosed settlement at $4.25 million.)

Northeastern is another university that succumbed to the ERP siren song, initially at least. The urban Boston university had long-term plans to reinvent itself into a U.S. News & World Report top 100 institution, and at the heart of this overhaul would be PeopleSoft software. "My predecessor and his boss bought it hook, line and sinker," Weir says. Northeastern's former president and the head of IS purchased 22 modules and wanted them installed by Y2K.

In 1998, with his predecessors shown the door and an IS department in disarray, Weir took the top IT job at Northeastern. The new administration charged him with getting the derailed ERP project back on track. The first thing Weir did was bring the administration's expectations back to reality. Instead of installing 22 modules before Y2K, Weir scaled back the plan to just one: PeopleSoft's HR application would replace the noncompliant Y2K homegrown app. He further winnowed the scope down to exclude Northeastern's 11,000 part-time employees from the HR application; only the 4,000 full-time employees would be in the upgraded system for now. "We had a Y2K deadline, and we bludgeoned our way to the goal," Weir says.

He managed to get through Y2K, but a major question remained: How would he handle the other enterprise system rollouts staring him in the face?

Standardizing at Stanford

Like Northeastern, Stanford University also bought into the late '90s enterprise software pitch. But unlike Northeastern, Stanford never slowed down its implementation engine. "In hindsight, we tried to do too much in too little time," says Randy Livingston, Stanford's vice president of business affairs and CFO.

Starting in 2001, Stanford implemented student administration systems, PeopleSoft HR, Oracle financials and several other ancillary applications. Four years later, users still complain that they have lower productivity with the new systems than with the previous ones, which were supported by a highly customized mainframe. Users also have had difficulties in accessing critical information on a timely basis. Livingston says many transactions—such as initiating a purchase requisition or requesting a reimbursement—take longer for users to do than with the prior legacy system.

Stanford has also not realized any of the projected savings the vendors promised. "We are finding that the new ERP applications cost considerably more to support than our legacy applications," Livingston says. And he doesn't know how much it will cost to get the enterprise systems working at the level everyone was accustomed to.

But Stanford's biggest problem is that its IT department is still trying to get campuswide buy-in for the enterprise applications, which have necessitated new ways of doing business. And that either leads to nonuse of the new systems or costly customizations to keep everyone happy. For example, Stanford's law school operates on a semester schedule, while the other six schools operate on a trimester schedule. "This means that every aspect of the student administration system needs to be configured differently for the law school," Livingston says. Within the schools, some faculty are paid a 12-month salary; other schools pay by nine months, 10 months or 11 months. "The standard HR payroll system is not designed to handle all these unusual pay schedules," Livingston says.

Livingston has his work cut out for him now that his CIO, Chris Handley, resigned in December 2004 and forced him to take over the IT reins. Livingston has since reorganized the IT department, which he hopes will be better able to manage the enterprise projects going forward. He created a separate administrative systems group that will report directly to him, with responsibility for development, integration and support of the major ERP systems.

The hurdles Stanford and other universities face with the new ERP system are largely cultural ones. For instance, lean staffs and tight budgets at most university campuses usually lead to a lack of proper training and systems testing. At Stanford, Livingston says that plenty of training was offered, but many users didn't take it. He has set up new training programs, including a group who sits side by side with users to help them learn how to do certain complex tasks; periodic user group meetings; website and e-mail lists that offer more help; and expert users embedded in the various departments who aid their colleagues.

Stanford's IT was still struggling with integrating the enterprise systems when the newly launched PeopleSoft Web portal (called Axess) crashed last fall. Like the new UMass portal, Axess couldn't handle the load of all the returning students trying to log in to the untested Web-based system at the same time, Livingston says. Stanford was able to fix those problems relatively quickly, but Livingston and his staff continue to struggle with the enterprise projects. The university's departments remain "highly suspicious and resistant" of his efforts to standardize and centralize business processes, Livingston says.

Overloaded at Umass

At the University of Massachusetts, IT hoped to originally have the Web portal rollout installed by March 2004. Delays in testing the Spire system, however, forced them up against an immovable deadline: the return of 24,000 students to campus over Labor Day weekend.

By midday Tuesday, after some periods of slowness, "the system choked," says John Dubach, CIO at UMass-Amherst. It stayed down for a long four days at the most crucial time of the year—when students needed to add or drop classes and find out where their classes were on campus.

Dubach would later realize that his staff did not do enough load testing on Spire. A configuration problem with the password system also reared its ugly head. An explanatory e-mail had been sent out to the students, informing them of the password requirements in the new system. It turns out no one read the e-mail, and therefore, students flooded the "I forgot my password" option because they couldn't log in. After about a thousand of these requests, the system buckled. "We didn't test for a thousand password requests," Dubach says.

The opening day nightmare was compounded by the fact that PeopleSoft seemed unable to help. "We were looking for help left and right," Dubach says. "PeopleSoft had suggestions but no solutions to anything. They hadn't had that much experience with the portal in this type of environment."

PeopleSoft representatives see it differently. Jim McGlothlin, now a vice president with Oracle who also worked for PeopleSoft, says that onsite consultants for the vendor did help UMass out. McGlothlin says universities sometimes experience problems with the software because of their tight deadlines and inadequate load testing of the new system. "You need to allow a couple of weeks to do proper load testing," he says.

After four long days and nights, Dubach and his staff were able to corner most of the problems. Students and faculty were allowed back onto the system without restriction the following Monday. A few periods of slowness raised the anxiety levels during the weeks after, but the system never went down again. Dubach reports that student registration in November for spring '05 classes went smoothly.

Dubach took away some valuable lessons. First off, he says he was naive about the amount of testing and fine-tuning such a new and intensive system demanded. In the future, Dubach says, he will try to coordinate hardware upgrades with application upgrades. When he buys new hardware, he will install the software upgrades on the new hardware, test it and have it working perfectly before he replaces the old systems with the new ones.

While Dubach says he is going to stick it out with PeopleSoft, in large part because UMass has already purchased the software licenses, some university CIOs say there is an easier way.

Middleware to the Rescue

1 2 Page
Join the discussion
Be the first to comment on this article. Our Commenting Policies