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].
