U-BUY Online Requisitions - One Giant Step!


Copyright 1991 CAUSE From _CAUSE/EFFCET_ Volume 14, Number 4, Winter 
1991. Permission to copy or disseminate all or part of this material is 
granted provided that the copies are not made or distributed for 
commercial advantage, the CAUSE copyright and its dateappear, and notice 
is given that copying is by permission of CAUSE, the association for 
managing and using information resources in higher education. To 
disseminate otherwise, or to republish, requires written permission. For 
further information, contact CAUSE, 4840 Pearl East Circle, Suite 302E, 
Boulder, CO 80301, 303-449-4430, e-mail info@CAUSE.colorado.edu


U-BUY ONLINE REQUISITIONS--ONE GIANT STEP!
by Joseph Harrington and David McCormack

ABSTRACT: This article describes the general concepts and system 
features of U-BUY, an online requisitions system at Boston College. The 
system development life cycle is outlined over the two years of 
development, along with the problems that emerged. A summary of a survey 
of the university community to measure their reactions to the 
implementation of the project is presented, and the functionality and 
impact of the system are discussed.

************************************************************************

Joseph Harrington has been Director of Management Information Systems at
Boston College since 1986, responsible for the development and
implementation of administrative systems applications. Formerly, he
served as Associate Controller at the university. Prior to joining
Boston College, he held systems management positions at Prudential
Insurance Company and Honeywell and was Director of Information Systems
Training at Raytheon Corporate Offices.

David McCormack is a programmer analyst in the technical support group
of the Boston College MIS department. He is one of those responsible for
the design of the infrastructure and overall architecture of the
administrative system network at the university. After graduating from
Boston College, he worked at GTE Corporation before joining the
university's MIS department in 1984.

************************************************************************


In the summer of 1989, Boston College1 implemented an online
requisition system, called U-BUY. Today, after two years of operation,
over 800 users in 130 campus departments use the system, which requires
online preparation of financial transactions. The only way to produce a
check requisition or a purchase order at the university is through U-
BUY--there are no manual routes to bypass the system!

We look back and view this development as a "watershed" application
that challenged our users and presented the opportunity for elevating
the level of computer literacy and comfort throughout the campus. U-BUY
also represents a prototype application for providing increased campus-
wide functionality in the 90s. This article describes the U-BUY system,
how it came about, how it was implemented, and the difference it has
made at Boston College.


A DECADE OF GROWTH, COMPLEXITY, AND MOUNTING PAPERWORK

During the 80s, growth at Boston College was not seen in terms of
enrollment increases, but rather in the emergence of a university with
an increased national appeal and focus. The transition from a commuting
community to a residential campus brought about construction of new
residential and dining facilities; increased emphasis on research
resulted in the opening of a major new library; and the magic of the era
of football star Doug Flutie triggered an upgrading in recreation and
athletic facilities.

Information technology, including communications, bloomed on the
campus. Simultaneously, a major capital campaign was initiated by the
development office. Many of these activities resulted in the initiation
of new programs and increased support services which, in turn, caused a
dramatic increase in the level of transaction processing throughout the
campus.

As part of the ongoing systems survey and planning cycle of the
management information systems (MIS) department, it became very clear in
1986 that the administrative processes of the university were deluged
with paper forms and requisitions. It took many days just to get a
purchase order out the door to a vendor. An ordinary check requisition
took twelve business days to result in a printed check. A student with a
credit balance from the application of financial aid to his or her
account had to wait a minimum of two weeks for a refund; at peak
processing times, it could be twenty or more business days.

Too frequently, relations with vendors were strained because of
late payments. This resulted in countless hours of phone conversations
from the vendor to the purchasing and accounts payable departments, and
to originating departments seeking invoices and investigating payments
or non-payments.

At that time, only one-fourth of the university departments had
access to terminal displays of their budgets. For those departments with
terminal access, the displayed balances available were not reflecting
the numerous requisitions and budget transfers that were grinding slowly
through the manual processes and approval steps. The departments without
terminals were even more in the dark.

Consequently, most of the departments were creating bootleg
accounting systems, keeping track of their spending with annotated
listings, index cards, or PC spreadsheet programs. Receiving a monthly
mainframe budget report ten days after the end of a month was of little
help to gauge departmental spending and balances, given the common lag
times in the purchase order/check requisition processes that fed and
interacted with the university's batch accounting system.

Rejections of requisitions because of unavailable funds was a
common occurrence. Additionally, trying to ascertain the status of a
transaction once the piece of paper had left the originating department
was an exercise in futility. The frustration voiced by department
administrators reflected the unrest of many staff members who were mired
in numerous unproductive tasks.

Along with the frustrations of the many departments on campus,
there was the treadmill activity of the business offices trying to stay
even. As transaction volumes rose, backlogs escalated and the servicing
departments (i.e., accounts payable, accounting, purchasing) had higher
stacks of forms on their desks to search through as more and more phone
inquiries came in regarding these unprocessed orders.

Productivity had hit the wall!

The community's displeasure with the paper-driven requisitioning,
receiving, payment, and budgeting processes was widespread. Requests for
additional people to handle the paperwork were emerging from departments
all over the campus. The discontent and complaints had reached the
executive officers of the university through various means. When the MIS
two-year plan was reviewed by the executive vice president and the
executive director of information technology, the highest endorsement
was given to the development of a new online requisition control system.

It was in October 1986 that the MIS department convened a meeting
with the key business officers in the financial vice president's area to
chart a course to address the paperwork morass that was choking the
campus. That was the beginning of a two-and-a half year journey that
produced the U-BUY requisition system in June 1989.


THE U-BUY SYSTEM

U-BUY is a menu-driven online requisition system running on an IBM 3090,
with terminal access through the CICS operating system in an MVS
environment, with functional capability to do a number of financial
transactions. U-BUY works in conjunction with, and is dependent on,
other components in our administrative systems environment.

University ID System. This component, used in the university log-on
procedure, identifies all individuals associated with the university
(students, employees, and other defined groups). It keeps track of each
individual's current status, and grants initial access based on that
status. These privileges include (but are not limited to) recreation
complex entry, library privileges, and administrative systems access.
This component interacts with the operating system security.

Universal Position System. This system contains a record for every
position in the university, and each record defines the attributes of a
position. Some of these attributes include the university identification
number and name of the current occupant, campus location, campus phone
number, phone and computer access privileges, department number, and
position number to which this position reports. When a signed-on user
selects the U-BUY function, the attributes in this file are available so
that many elements relative to the user are pre-formatted on the U-BUY
screens for creating U-BUY records.

Electronic Approval System. This system defines which university
positions are approvers or originators of different types of financial
transactions for accounts in the university's financial accounting
system. U-BUY requires that each account have one or more positions
designated as approver(s) of transactions, and that the position
occupant's password and personal identification number (PIN) take the
place of a signature on a form. All U-BUY transactions access these
records to determine the right of the user position to access and/or
update the keyed account. These records also contain rules such as
limits of spending on an account, or on a line item (sub-code) of an
account for a position. All approval records and rules are specific to a
position.

University Accounting System. As U-BUY requisitions are entered
into the online system, the system accesses the accounting files to
verify that there is a valid account for the transactions and that there
are sufficient funds available to make the purchase or payment. If funds
are available, then an encumbrance is immediately established and the
balance available on the line is reduced. Critical to the control
considerations of U-BUY is the interaction with the university
accounting system in the functions of requisitioning, invoice matching,
applications of credits, release of payment, and budget transfers. The
accounting system also contains a hierarchical organization chart of the
university accounts. Using this chart in conjunction with the electronic
approval system, U-BUY transactions create electronic lists of valid
position approvers for each transaction.

How the system operates

In the _requisitioning_ operation of U-BUY, the user provides a PIN
and user-name to sign onto the system. With this information the system
knows the universal position number(s) of the signed-on user and thereby
sees what computer access privileges are available to the position(s) of
the signed-on user. If the employee has access to U-BUY, then a menu is
presented. The user selects a function and one or more functional sub-
choices are presented. For purchase orders and check requisitions to a
vendor, the user enters a name and the system does a phonetic search and
presents all the vendors that fulfill that search. The user picks a
specific vendor and from one to six addresses appear for user selection.

When a line of requisition information is entered, the system verifies 
that the user has access to use this account (account sub-code line) and 
has funds available to spend from this account. (If a user is purchasing 
supplies, but has no funds in the supplies sub-code line, then the user 
may exit the process, go to the budget transfer function, and transfer 
funds from some other line into supplies. Then the user can return to 
requisitioning and process a requisition on the supplies sub- code 
line).

The user can insert a number of lines per requisition and each line
is edited appropriately. When the user is finished entering lines, the
system goes to a closing screen which is pre-formatted accordingly,
depending on whether the transaction is a purchase order or a check
requisition. The user can change the defaults presented on the closing
screen, and can optionally insert comments before marking the
transaction as complete by inserting a private password in a screen-
darkened area.

Once a transaction request has been completely entered it may or
may not need additional approvals. If the unit cost of all lines of a
purchase order are under $500 and the source of funds is a general fund
unrestricted account, then the purchase order goes directly to a laser
printer in the purchasing department. If any lines exceed $500, then a
second departmental approval is necessary before the purchase order is
routed to the laser printer. If the source of funds for a purchase order
is a restricted one, the transaction is routed to the accountant in the
controller's office responsible for those restricted funds before it
goes to the purchasing department printer.

Check requisitions are routed electronically to the accounts
payable department of the controller's office. Receipts for check
requisition transactions are inserted in a specially designed blue
envelope, for which campus mail service provides express sorting and
transmission. 
In the _receiving_ operation, goods are delivered directly to buildings 
and departments as the university has no centralized receiving area. On 
U-BUY, when a purchase has been delivered, the user selects the 
receiving menu item and the system presents a list of all outstanding 
departmental purchase orders that have not been received. The user 
selects the appropriate purchase order and marks the purchase order as 
fully received or partially received by line. If there are any problems 
with the goods, the user selects an option to refer the purchase order 
to the appropriate buyer who uses various transactions to resolve the 
problem with the vendor. The receiving transactions at the departmental 
level are simple and direct, even to the point of intentionally 
understating the complexity of the receiving process.

In the _invoice matching and payment release_ operation, the
purchasing department matches invoices to purchase orders online,
resolves problems, and closes out purchase orders. Invoices are
transmitted to accounts payable and payments are released online against
purchase orders. Accounts payable reviews receipts and invoices and
releases check requisitions which are paid on a batch check run that
runs three nights a week.

All users are capable of _viewing requisitions_ in a number of
different ways: (1) unpaid requisitions by originator, (2) paid
requisitions by originator, (3) unpaid requisitions by department, (4)
paid requisitions by department, (5) all requisitions by an account, (6)
any individual requisition, and (7) last year's requisitions.

Features of campus-wide transaction

Authorized users in any of our 130 departments may originate many
different transactions, provided their position has the appropriate
security clearance and spending authority over the referenced account
number and, most importantly, that there are available budgeted funds in
the account they are using. The available transactions are listed in
Exhibit I.

Given the security considerations and the account approval
mechanism controlled by the electronic approval system, one of the
design objectives implemented in the system was the elimination of any
manual process to get a requisition through the system. The user must
use the online system. Going to the purchasing department or the
controller's office to have these offices enter the information is not
an option. Positions in the user departments are established in the
electronic approval system as having spending authority over the
accounts they use. The purchasing agent or an accountant in the
controller's office have no spending authority on departmental accounts,
so if they tried to enter a requisition, it would result in rejection.

Real-time processing is a key feature in the system. The
requisitioning processing modules access the accounting system to verify
that there are dollars available in a line item for some purchase or
payment. Once a requisition is processed, instant encumbrances reduce
the dollar balance available for a sub-code line of an account. Real
time means real control!

In cases where there are insufficient funds in an account, the user
can return to the U-BUY menu and select a budget transfer function to
transfer funds, again in real time. This supplanted a manual process
that took days to accomplish.

Each user department worked with the controller's office to
determine the department approval structure best suited for their needs.
Various flexibilities within the electronic approval system, such as
setting sub-code spending limits per position per account sub-code,
allowed each office to have an approval structure that was tailored to
its environment. The financial management systems department in the
controller's office is responsible for the actual maintenance of these
electronic approval system records.

The electronic routing routines reside in the U-BUY system and are
predetermined depending on a number of characteristics in the
requisition data. Routing within the user departments is contingent on
the definition of electronic approval records. Once approved at the
department level, the requisitions appear on electronic screens or lists
in the various business offices for further approvals.

Purchase orders and check requisitions using restricted funds are
routed to the restricted funds section of the controller's office, while
purchase orders and check requisitions charged to unrestricted general
funds are routed directly to purchasing and accounts payable,
respectively.

Since U-BUY uses other components of the university information
system, the actual required amount of data to be entered by the user is
minimal. For the most part, the user enters only quantity, unit price,
and item description for a line of requisition data. Pre-formatted on
the screens are the originator's name, campus address, extension,
department name, delivery area, and account number.

Specific functionality for business offices

The purchasing department, internal services department, and
controller's office have specific transactions of approving, suspending,
and modifying requisitions. Additionally, they have other transactions
for matching invoices to a purchase order, processing credits, releasing
transactions for payment, requesting additional copies of purchase
orders, and so forth. Buyers in purchasing have capabilities for adding
extensive text to any purchase order to stipulate contractual terms and
conditions.

The restricted funds section of the controller's office has the
functionality to approve or suspend any requisition drawn on restricted
funds such as contracts and grants, or agency accounts. The accounts
payable department is able to: (1) release a payment on a check
requisition; (2) release payment for an invoice on a purchase order; (3)
suspend check requisitions back to the originating department; (4)
modify addressing for check disbursement; (5) apply credits to specific
vendor or requisitions; and (6) maintain addresses for a vendor.


ORGANIZATIONAL, POLICY, AND PROCEDURAL ISSUES

The system development process and approach was fairly methodical in the
months of conferring with users, defining requirements, designing,
prototyping, and testing the product, but there were organizational,
policy, and procedural issues that had to be resolved in the
implementation of this major campus-wide system.

Anticipating and meeting challenges

From the beginning, we realized that U-BUY would effect a
significant change in the way Boston College does business. The
transition from an untimely paper-driven system to an electronic system
would impact every department on the campus. Education and training
could be prepared and presented, but job redefinition was a more
parochial matter, in the control of the departments and business
offices. While education and training were successful early on, job
redefinition continues to evolve very slowly.

In the old requisition paperwork system, the practice of multiple
signatures on numerous different types of requisition forms had burdened
the community with confusion and delays. The concept of a paperless
requisition and the idea of a password as an approval mechanism gained
ready acceptance from the directors in the business offices, provided
that the environment was secure. Of more concern was the number of
required approvals.

Requiring two approvals on every requisition would mimic the old
system and slow the processing of transactions. One proposal was to have
hierarchical approval of requisitions, going up a number of levels
depending on the dollar value of the requisition. A more sensible
proposal was to have only one approval per requisition except when the
unit price on a requisition exceeded a defined amount. But what amount?
It was decided that requisitions with a unit price on a line exceeding
$500 would require two signatures.

The business officers struggled through this process. The Executive
Vice President of the university invited a partner in an external
auditing firm to review the proposed electronic approval system and its
procedure, and to voice an opinion on the risk and auditability of the
system. All breathed a sigh of relief when the external auditing partner
thought the system was sound and that one signature for requisitions
with line item amounts under $500 was appropriate and without risks,
given all the new and improved controls in the automated system.

At the other end of the requisitioning process, we anticipated that
receiving could be a problem. As mentioned earlier, Boston College has
no centralized receiving area (due to space constraints) and departments
must receive delivery of goods. In the old manual system this did not
work effectively. The nature of receiving goods is very complicated
because of numerous potential problems such as errors, replacements,
backorders, damaged goods, and so forth. We had to figure out a way to
accommodate this complexity in the automated system in an uncomplicated
fashion.

In U-BUY an order in excess of $500 must be received at the
department by the use of a terminal transaction. If there is any
discrepancy with the order--for example, a wrong color, wrong unit 
price, damaged goods--the user does not mark the order received, but 
rather refers the requisition electronically to the buyer who must 
resolve the problem with the vendor.

Transactions in the "problem resolution" section of U-BUY reside
with buyers in the purchasing department to resolve all the possible
discrepancies that can take place in the receiving function. This module
proved most difficult to design because of the various dispositions that
are called for with a purchase order "gone bad," for example, cancel it
and disencumber the funds, accept it and release part or all of the
encumbrance, and so forth--a programmer's delight!

As the project drew nearer to implementation, it was clear that
some of the purchasing requirements for free-form text were not
adequate, especially for purchases related to construction and capital
projects. Individuals who should have been involved in the definition of
requirements had not been included earlier in the project. Two modules
of the system needed minor design changes to incorporate a fuller text
capability for the header and lines of a purchase order, and to allow
for the the overall purchase order to include an "infinite" number of
lines or pages with contractual information and performance criteria.

Building the U-BUY team

In June 1988, nine months before implementation, executive
management endorsed an MIS proposal for an implementation committee to
address the many issues and challenges that were anticipated. This
committee was composed of business office users, security and auditing
personnel, public relations staff, training and education personnel, a
desktop specialist, and MIS representatives. The issues and tasks before
the committee led to the establishment of four working subcommittees:
publicity and promotion, education and training, security and security
awareness, and user documentation.

The publicity and promotion subcommittee was set up to prepare the
way and establish an image for the new system. Naming the system and
designing a ceremonial U-BUY coffee mug were two of the foremost tasks.
U-BUY was to be part of a university "series of systems." The motto
printed on the mug was: "We tried it ... we liked it." (Some months 
later, when the university president was interviewed and photographed in 
the alumni publication, he was holding a U-BUY mug!) News and publicity
releases for campus publications were prepared and published.

The training and education subcommittee was responsible for
identifying specific users for training, and preparing the curriculum,
printing the material, and organizing the class and lab exercises and
schedules. Six hundred people would need training.

The security and security awareness subcommittee took on a most
pronounced role. A secure U-BUY environment would require a heightened
awareness on the importance and confidentiality of PINs and passwords.
PINs had been used in the phone system for long-distance access. Since
fewer than half of the departments had terminals, the community, in
general, had made minimal use of passwords and, in many cases, there was
the perception that password use was quite casual. Reviewing CICS use
and identifying individuals on the campus who would work in a security
partnership with MIS were important tasks of this subcommittee, which
included the internal auditor, controller's office representatives, and
the MIS security administrator.

The user documentation subcommittee was composed of representatives
from MIS, the controller's office, the purchasing and budget
departments, and a desktop specialist from Information Processing
Support (IPS). It was their role to prepare, create, and distribute a
user manual for the community. But a funny thing happened on the way to
the forum. In preparing the documentation, individuals on this
subcommittee became key quality testers of the system. To write
documentation, they would need to use the test system, and their
feedback was quite significant in the successful implementation of U-
BUY. Essentially, their role evolved beyond its anticipated
significance.

These four subcommittees didn't just give advisory reports or
casual observations about different options that should be available;
they were working subcommittees. The tasks they had to complete became
part of their regular day's activities and were not shifted to the "back
burner."

To coordinate the activities of the subcommittees with the MIS
project team, monthly luncheon meetings were scheduled. When the
subcommittees, the MIS project team, and the network representatives got
together for the first luncheon, there was silence first, then
amazement, as twenty-two people realized we were doing together what no
single group could do on its own.

This first meeting set the tone to focus everyone on their
contributions to an effort and implementation that exceeded everyone's
perception; it was also an education for the MIS project team. Each
subcommittee gave a summary of progress and problems, the MIS project
team listed tasks completed and outstanding issues, and the network
services department updated everyone on how connectivity and
workstations were reaching every department. New tasks were identified
and deadlines were established for the next month's luncheon meeting.
The interaction of all of these groups created a synergy that enabled a
single, unified U-BUY team, vested in a common product and mission.

Each month, the luncheon meetings were convened and cooperative
efforts resulted, such as the campus information meetings in December
1988, which were sponsored by the security awareness, education and
training, and publicity and promotion subcommittees. Three hundred
people attended one of the four sessions to get an initial presentation
about the U-BUY project and what it would mean to their departments.
This was followed by a brief review of computer security and its
importance in the advent of the U-BUY environment. A short video on
security awareness was presented.

Early in 1989, the publicity and promotion and the training and
education subcommittees joined forces to work with the audiovisual
department to create a multi-media U-BUY presentation. This was a 14-
minute overview of the U-BUY system that was transferred to video tape
and was subsequently used in the training classes.


IMPLEMENTATION

In March 1989, the MIS department met with directors of the business
offices to discuss the implementation in the coming three months.
Although we had planned to release a fairly high level of functionality
the following month, it was agreed that it would be smoother to
introduce a lower level of functionality in April with full system
functions in June.

At the beginning of April, some of the MIS project team made a U-
BUY presentation to the executive management of the university at the
president's office. Their assurances of support for the implementation
was one of the major ingredients for success.

So in April 1989 the following functions were introduced:

  *  Online budget transfers for the current fiscal year.

  *  Purchase orders, blanket purchase orders, and agreements
originated for FY89-90.

  *  Approval of purchase orders, blanket purchase orders, and
agreements.

  *  Laser printing of next fiscal year purchase orders.

  *  Browse and display transactions.

That same month, training classes were scheduled for two straight
weeks. Each participant attended one-and-one-half hours of presentation
lecture, including the overview video, followed by one-and-one-half
hours of workshop experience on a Macintosh or a terminal for a total of
three hours. The participants took a U-BUY mug back to their
departments.

Over a two-week period, there were twenty sessions with twenty to
twenty-five participants in a session. In this initial Phase I effort,
approximately 380 employees were trained on U-BUY's rudimentary
elements, an average of more than two persons per department. The
trainers were from MIS, IPS, the controller's office, and the purchasing
and budget departments.

During the third week of April, when the system went live, a
documentation manual was delivered to the desk of everyone who had
attended the training sessions. Five hotlines were staffed by various
members of the U-BUY project team. Other team members were available to
be dispatched directly to departments to assist individuals with
application or connectivity problems. It was far from a serene week, but
after five days, the excitement and anxiety subsided.

The decision to introduce limited functionality in April was
helpful in focusing the training effort on a limited transaction set. It
also had a favorable impact on the community because it was a small
first step to the total change, which would take place in June. It gave
the user community a sense of comfort that change was gradual, and they
became quite adept with the delivered transaction sub-set. The menu
structure of the U-BUY system and its ease of use led the education and
training team to conclude that hands-on training on the extended
capability would not be required. In June, the people trained in Phase I
workshops were invited to attend one of three two-hour auditorium
presentations about Phase II functionality. These presentations were
announced through what we called our "bijou" ad (see previous page) to
create as much excitement as possible and an aura of fun. Over 400
people attended the three sessions. Those who had no workshop training,
or those who needed more training, were encouraged to sign up for U-BUY
classes scheduled weekly during June and July.

The summer is a quiet time at the university for many departments.
For the business offices and information technology and buildings and
grounds departments, summer saw some frenetic activity. In June, many
more U-BUY components were placed into production: check requisitions,
travel transactions, full approval, check printing, receiving purchase
orders, invoice matching, releasing payments, and problem resolution
(for receiving problems). Again, the hotlines were staffed, the phones
rang, and there were two weeks of questions, problems, and occasional
screams by a few who insisted on using paper requisitions. Every phone
call, complaint, or issue was recorded on a separate form for review and
assignment. With full functionality, enhanced documentation was
delivered to match the enhanced version of the system.

With each new development that took place, the project team
collected a dossier of the most frequently asked questions and hot tips.
From this collection, the team initiated U-BUY Update, an information
sheet which was prepared and distributed five times during the summer
and fall of 1989 to keep the community informed about system issues and
extended capability, and to stimulate and answer questions.


SURVEY OF USER COMMUNITY

A year after the implementation of U-BUY, statistics were gathered for
the first year's processing under U-BUY. The prime U-BUY contacts in 25
percent of the departments (excluding the business offices) were
surveyed. Some results of that survey follow.

  *  U-BUY had been announced to the general community in the December
1988 seminars. From the survey we learned that nearly a quarter of the
respondents had questioned their ability to perform sufficiently under a
new system when they heard that it would be coming. There had been a
good deal of anxiety in the user community!

  *  It was the users' perception that under the old paper system it
took 14.4 business days to receive a check after the submission of a
paper check requisition. With U-BUY, they perceive that they get a check
in 7.2 business days after entering an online check requisition.

  *  With a number of steps along the way for a paper check
requisition, and a long delay in receiving a check, phone calls became
the usual tool of expediting. In our survey, people reported that they
saved an average of two hours per week using U-BUY to track down
requisitions, invoices, and purchase orders instead of using their
telephone to get this information. Conversations between departments
(Purchasing, Budgeting, Accounts Payable) resulted in an enormous amount
of telephone traffic. If one department saves two hours a week, that's
104 hours per year. When you multiply that by 130 departments it amounts
to 13,520 hours per year. But phone conversations are between two people
so we can double the number and see 27,040 hours of savings in phone
conversations on our campus in one year. That's the equivalent of more
than 3,800 seven-hour days--an opportunity for fifteen years of 
increased
productivity.

  *  Sixty-five percent of the survey respondents felt their computer
skills and computer system knowledge had risen since using U-BUY.

  *  The survey question that asked respondents to answer yes or no for
returning to the old manual paper-driven system received a resounding
"no," with one threat of "I'd quit."


CONCLUDING OBSERVATIONS

The survey, coupled with observations and conversations with the user
community, showed that the U-BUY system has been fairly well received as
a friendly system that helps people in the management of their budgets
and the operation of their offices--when a quarter of the users 
initially had great apprehension about their ability to use the system. 
It's a credit to many of the staff of the university that they met the
challenge and exceeded their own expectations in a computer environment
hitherto unknown.

U-BUY spurred connectivity to the mainframe and in many ways drove
the resource components of Information Processing Support for training,
and Network Services for online connections. More importantly, it
stirred imaginations and appetites of our employees who are now asking
for online payroll time-sheets, personnel action forms, and buildings
and ground work orders. It's apparent that the U-BUY system is
accompanied by heightened awareness and use of information systems as a
more viable communications medium.

U-BUY as a prototype represented a tall mountain to be conquered.
However, having met the challenges of U-BUY, the introduction of new
online functionality for other applications will be more like rolling
hills, and much easier for both technology professionals and the user
community to scale.

It's necessary to say a few words about attitude in the experience
of changing the way Boston College does business. The project
implementation was a major step for everyone. There were system bugs and
problems, on occasion, but the overwhelming majority of the user
community was understanding and patient. Not all, but most, were
sensitive to the complexity and ambitiousness of what we all were trying
to achieve together.

The paperwork morass on the campus had led to increased irritation
in the community over the years. There was the perception that
bureaucratic practices contributed to the slow, unresponsive paperwork
processing. There was also the observation by certain members of the
community that to get a document processed, one should walk it from
office to office. In some cases, that worked! The MIS annual planning
activity was sensitive to the community's view of the requisition
process. User after user confirmed this in our work.

In the implementation committee structure and meetings that were
commenced in June 1988, the theme of "changing the way we do business"
was ever present. The project team felt strongly about this and they
worked together in prototyping and testing activities. The system
benefits became apparent. It was really exciting for the project team
user representatives to enter a test requisition for office supplies to
a contracted vendor on a terminal and see the purchase order coming off
a laser printer in the purchasing department in less than a minute. The
project team knew the product was one of speed, quality, and accuracy.
In the preliminary presentations to the user community, that enthusiasm
showed. This was accompanied by realism that conveyed, "There will be
problems, but we'll solve them together." The training and documentation
efforts were highly organized, structured, and presented in a very
positive way. The changing-the-way-we-do-business theme emerged clearly,
and the community was more than eager to give a shot to promised
improvement, supported and couched in careful preparation.

In sum, the spirit and cooperation of the community was an integral
part of this successful U-BUY project.

U-Buy is a unique product designed for Boston College. Behind U-BUY
are various system components and standards that have been carefully
designed and developed over the past years. This represents a system
architecture of open access that has guided the development of campus
administrative applications.[2] These pre-existing, home-grown 
components contributed greatly to the success of U-BUY. In a sense, U-
BUY was just the frosting on the cake, the sweetest part for all of the 
community to use.

========================================================================

Footnotes

1  Boston College is a private, Jesuit university with a student
enrollment of 14,515, located in Chestnut Hill, Massachusetts.

2  For a complete discussion of this architecture and its evolution,
see CAUSE Professional Paper #6 by Bernard W. Gleason, Open Access: A
User Information System (Boulder, Colo.: CAUSE, 1991).

========================================================================

Exhibit I

U-BUY Transactions

1. Originate check requisitions
2. Originate purchase orders, blanket purchase orders, and
agreements
3. Originate requisitions for internal services:
- computer store purchases
- purchasing stock room
- bookstore purchases
- bureau of conferences
4. Approve requisitions when more than an originator's approval is
necessary
5. Adjust blanket purchase orders
6. Cancel requisitions/purchase orders under controlled
circumstances
7. Originate budget transfer of funds between six digit accounts or
between two sub-code lines of an account
8. View transactions in numerous formats
9. Receive goods on a purchase order or refer received goods
problems to the purchasing department for problem resolution

************************************************************************