Cornell University: Putting a New Face on a Familiar System

Cornell University is known for excellence, and the school prides itself on ensuring that its high standards are met across all departments and functions. Purchasing is no exception. Cornell's busy decentralized, distributed purchasing environment involves 4,000 people processing approximately 60,000 purchasing requests each year to keep the private university running.

The school recently enhanced its purchasing systems—streamlining and modernizing them to create a user-friendly interface, while retaining the power of the robust, mainframe-based back-end. The new system brings a completely re-engineered interface to Cornell's mainframe-based purchasing system. With an intuitive menu structure, backed-up by self-guided online tutorials and pop-up help windows, the new system simplifies the purchasing process—a definite plus for requisitioners as well as for university management.

The Customer is Always Right
Cornell's Office for Purchasing Services views the university's faculty and staff as customers, with support and responsiveness being a critical focus of the department's mission. Feedback from these customers made it evident that something had to change with their homegrown, green-screen application, the Automated Procurement and Payment System (APPS). Despite training and support, customers accustomed to the look and feel of the Web and Windows-based applications found it difficult to navigate the multiple layers of screens, function keys, hidden text boxes, and special commands of the APPS. With nearly half its subscribers using the system on an infrequent basis, usability was a constant issue. The Office for Purchasing Service's help-line staff spent a great deal of time walking occasional users through the purchasing process. While they've done an admirable job, it has been time that could be better spent on a litany of other tasks.

"The APPS system d'es an excellent job of managing the purchasing process," explains Vince Patriarco, Cornell University's Director of Purchasing. "But for people who don't get into the system often, it can be confusing. When the University made the decision to keep APPS in place, we knew that making improvements to its user interface would create the largest possible positive impact for the user."

The University's APPS system is typical of other character-based, green-screen applications, characterized by complex navigation menus and cluttered screens filled with unused fields and confusing abbreviations—and access was another issue entirely. For control and security purposes, only about 1,200 personnel were authorized to access the 10-year-old system. Other users submitted paper requisition forms, which would then be entered into the system by a department secretary or administrative staff. Some even created shadow systems to handle parts of their purchasing needs. The inherent redundancy not only resulted in wasted effort, but it slowed the entire process, stressing resources and increasing the chance of confusion, miscommunication, and error.

Mapping the Course
To transform APPS into a more efficient and usable system—while retaining its strengths—Cornell decided to go with the outside integration firm, MODCOMP Inc., of Ft. Lauderdale, Fla. "We realized that hiring on the expertise was the best way for us to go," says Patriarco. "Resources are tight, and we knew if we contracted it out, we could keep our internal priorities on track."

Keeping the business logic of APPS in place was an important requirement of the project—only the interface was to change. The Office for Purchasing Services maintained their customer-driven approach by convening focus groups to determine the user requirements for the new Web interface. With the customer requirements well understood, development began, first creating the user interface, and then integrating its logic with the functions of the legacy APPS system.

This integration was accomplished using a Web-to-host technique termed screen mapping. Creating a bridge between the Web and legacy environments, custom scripts direct the data from the new, intuitive user screens to the appropriate fields in the underlying APPS system. The data flows in both directions—APPS data flows to the user screens as seamlessly as it flows from them—enabling Cornell to realize the full benefits of the Web environment while keeping all of its existing data and business logic in place. Cornell's new, easy-to-use purchasing system was deployed without touching a single line of code on the underlying mainframe system or disturbing any of the existing business logic.

Matching the Business Flow
At Cornell, each of the university's departments is responsible for initiating and approving its own purchase requisitions in a process that involves three functional roles in the APPS system: a "preparer," an "editor," and an "approver." The preparer d'es the initial data entry for the requisition, the editor reviews the request, and the department's approver approves and releases each requisition.

Before the new Web interface was in place, a person without APPS access would have to work with an authorized preparer to enter a request into the system. Each department handled this differently—via telephone, in person, using paper requisition forms, or through independently maintained shadow systems. Those that completed large quantities of purchasing requests had even developed their own systems for tracking. The request would then be routed through the ranks of editor and approver within the APPS system

With the new application, Cornell developed a "Requisition WebForm" that anyone with Web access can use to initiate a purchase request directly. Completely Web-based and separate from the APPS system, implementing the WebForm did not require any changes to Cornell's strict security and authorization standards.

The new online requests can be initiated from scratch, with the requestor filling-in the online form, or the requester can simply browse the online catalogs of Cornell's "Preferred Suppliers" and point and click their way to building the purchase requisition. To simplify ongoing and repetitive purchase requirements, users can save partially completed requisitions to use as templates for repeat purchases.

Once the requester completes the initial purchase requisition, it's saved on the Web server. The application uses Java servlets to send an e-mail to the appropriate person to approve the request, indicating that a purchase request has been generated that requires their review. The approver needs only to click on the link embedded in the e-mail for direct access to the Web page that lists all of the requisitions in their queue. A simple click on any of the requisition items pulls up the associated Requisition WebForm. The individual can accept, reject, or modify the requisition directly on the WebForm—and with just a simple mouse click, can even refer to the vendor catalog for more information. At this point, the request is not yet a requisition and has not been entered into the APPS system. It may even go through additional approvers (who are not recognized in APPS) before it gets to an APPS authorized department "editor" or "approver."

When finalized and approved by an APPS recognized approver, the data from the requisition moves into the APPS system, populating the appropriate fields in APPS with the data that was collected and processed through the new Web-based user interface. At this stage of the cycle, the system generates an e-mail to the department administrator approver for final requisition approval.

For example, if a graduate student working in the lab late at night discovers the supply of beakers is low, they can go online, bring up a vendor catalog, choose the beakers, and initiate the purchase process with a requisition. The next morning their faculty supervisor receives an e-mail to review the request. Once approved, an e-mail regarding the request will be sent to the department administrator. Upon approval of this authorized APPS user, the request becomes a requisition and information will be populated into the APPS system immediately and automatically. The remainder of the purchasing process takes place within the APPS system just as it always has; with final approval the requisition becomes a purchase order that the purchasing department sends out to the vendor.

"It just streamlines the process for the user," explains Patriarco. "Everything they need is there at their fingertips, in one browser window." Aside from the increased accuracy and the pure customer convenience factor of having the catalogs a click away, the university is looking forward to cost containment and contract utilization benefits that will come from increased usage of these preferred suppliers.

The second piece of the new interface is the "WebReq": A streamlined, simplified Web-based window into the APPS system. Over half of the APPS authorized users access the system a dozen or fewer times a year and the new Web interface makes it easy and intuitive, walking them through the process, guiding them every step of the way.

The newly designed APPS system user interface completely changes the way the system is used by matching the way people work—eliminating system redundancies and removing cumbersome legacy navigation that would lead to errors along the way. "This new system, with its drop-down menus, descriptive comments, and pop-up help windows, is considerably easier to use," says Patriarco. "We've eliminated codes, function keys, and levels within the system."

Making the Grade
Development was complete in just under six months, a major portion of the time was spent in the focus group user-interface design process to optimize the performance of the system and streamline user interaction. "There were no surprises here, we knew it would take a lot of effort," says Dennis Butts, Cornell's Manager of Purchasing Systems. "This was a complex development process; many of the Web screens require information from multiple APPS screens. APPS is a complicated application with error messages for every field, and without any documentation. It required extensive manual testing and de-bugging to fine tune the final release. The outside integrators and our team worked collaboratively to quickly get the project ready for real-world use."

Cornell's Office for Purchasing Services considers the project to be time well-spent—especially the up-front time spent in campuswide user focus groups that led to its well-designed, logical, intuitive processes. Having met the project's primary goal—to create an enhanced, intuitive user interface that is sufficiently easy to use as to allow direct interaction between customers and the system—Cornell is continuing deployment of the Web-based system to an even broader range of users. Use of the Web interface is steadily increasing, and Patriarco expects usage, currently at a volume of 150 to 200 Web-based requisitions per week, to expand. "New users come in waves," says Patriarco. "One person will find out about it, and share it with others they work with. We've had a great response, and are eager to expand the use."

Tip of the Iceberg
Cornell University's new Web-based purchasing solution is just the tip of the iceberg. With its open architecture and easy extensibility, the system is well positioned for future enhancement, as well as extension beyond this initial Web-based requisition application across other departments. With the success of this purchasing project, Cornell has already moved on to develop a Web-based interface to their budgeting and resource planning system, and is planning to develop the capability to accept vendors' invoices electronically.

For more information, contact Vince Patriarco, Director of Purchasing, Cornell University, at [email protected].

Featured