Copyright 1998 CAUSE. From CAUSE/EFFECT Volume 20, Number 4, Winter 1997-98, pp. 52-57. 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 date appear, 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 Jim Roche at CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301 USA; 303-939-0308; e-mail: [email protected]
by Kathe D. Graham and Paula J. Vaughan
In 1995, the University of Colorado at Boulder accepted the opportunity to pilot a procurement card program for small-dollar purchases. To meet objectives of maximizing purchasing efficiency, minimizing costs, increasing customer service, and providing appropriate control, it was imperative that the purchasing power be in the hands of the department cardholders while card-usage information be readily available to program participants and administrators.
A cross-functional project team from a variety of departments developed the program and policies, and called upon Information Technology Services to develop a system to work with the data. Since the pilot implementation in November 1995, the program has grown campuswide at both the Boulder campus and the University of Colorado�s Health Sciences Center campus in Denver, and is in the planning stages at the Colorado Springs campus. The program is also being adapted by other Colorado state agencies. Current volume is now over 3,000 transactions and $500,000 per month per campus.
In 1994, the State of Colorado Internal Audit Department recommended that the Division of State Purchasing implement a procurement card program to decrease the administrative costs of small-dollar procurement. In response to this recommendation, a task force was formed to pilot a program at three state agencies. The state task force includes the University of Colorado at Boulder (UCB), University of Colorado Health Sciences Center (UCHSC), and the state�s Government Support Services Division.
The resulting program at UCB is formally known as the Acquisition Card Program. Traditional purchasing procedures at UCB involve handwritten purchase requests, purchase orders produced by Buying and Contracting, individual merchant invoices, individual receiving reports, and checks cut by Accounts Payable -- regardless of the size of the purchase. The acquisition card program offers the university a new way of doing business by providing MasterCard credit cards to departmental end users for university-related small-dollar purchases (up to $1,000). The card provides staff and faculty with an easy, familiar purchase method that greatly improves customer service by reducing order time and "middle-man" paperwork. The payment side of the small-dollar purchase transaction benefits as well. Card-related payment processing in the Finance Office requires only ten minutes per month and involves simply reconciling one MasterCard bill and making one electronic transfer to the bank for the month�s acquisition card purchases. Merchants also benefit, as they are paid within two days of submitting the card purchase information to the bank versus the traditional net-thirty payment terms for most university purchases.
As a result of a successful Request for Proposal, the state task force signed a contract with First Chicago NBD, whose purchasing card program included many features that served as the building blocks for the design and development of the acquisition card program. These features included:
- card controls (dollar and transaction limits by cardholder and merchant type),
- default transaction account code per card,
- a hierarchical structure that could be used for reporting and security, and
- the university�s full liability for card transactions.
First Chicago NBD offered three options for delivering data to the university: hardcopy reports, ProValue Services� local-area-network-based software, and ASCII files. The hardcopy reports are produced and delivered by First Chicago NBD daily, by cycle, monthly, quarterly, or annually, depending upon the report. These reports can be used as the primary method for program management and administration or may be used to supplement the second and third choices. ProValue Services� LAN-based software, from ProCard, Inc., is used for receiving, reviewing, and reporting on transaction data. The ASCII files consist of daily transaction data, and are sent as an electronic download or on disk. The institution develops its own application system to work with the downloaded data.
The UCB project team was charged with the tasks of defining program mission and design criteria and carrying out the mission. To ensure widespread input and commitment for the program, the project team included representatives from five user departments with a vested interest in the program, process, or system, and reflected the variety of departments on campus (large and small academic departments, large and small administrative departments, and one "problem" department). These five departments were the "test pilots" and were the first to implement the program.
The project team also included representatives from Buying and Contracting, the Controller�s Office, Information Technology Services (ITS), University Management Systems (UMS), Business Process Transformation (BPT), Financial Services, Treasurer�s Office, Internal Audit, Distribution Services, Accounts Payable, Employee Development, Legal Counsel, and Sponsored Programs. The wide representation of the campus community ensured that policy and procedural issues would be evaluated and decided upon both by those whose day-to-day operations would be most affected and by those who would be responsible for enforcing the policies and procedures. The project mission was defined as: "Implement a department-driven and controlled procurement card and supplemental small-dollar purchase system." This long-term mission statement encompasses the design, development, and implementation of the acquisition card program as well as the design or redesign of various small-dollar purchase methods for those items that cannot be purchased with the card.
The project team used the following seven design principles to reach the program goals:
- Provide value to customers.
- Provide flexible, low-cost processing.
- Take appropriate levels of risk.
- Trust, train, and empower employees by delegating responsibility and authority to the lowest level.
- Hold people accountable for fiscal efficiency, effectiveness, and responsibility.
- Provide the right information to the right people at the right time.
- Simplify systems and processes while creating user friendliness.
A core team of eight people representing the pilot departments, purchasing, systems, and the controller, was selected from within the project team to handle program design and development details. The core team structure was small enough to accomplish much of the work, yet provided a clear avenue to any of the project team members for input on specific issues.
After reviewing the functionality, costs, and hardware requirements of First Chicago NBD�s data delivery options, the project team chose to have UCB�s Information Technology Services� Administrative Systems Group (ITS/ASG) develop an in-house system to work with the bank�s ASCII data. Due to the already-designated target date for the acquisition card pilot, the system had to be designed and implemented within six weeks of the decision date.
Design considerations included the following: The system had to work with any desk-top device (PCs, Macs, dumb terminals); it had to communicate with the bank using 3780 protocol and interface with the university�s Financial Reporting System (FRS). Users needed to have online access to transactions for review and account editing, and the system had to provide management reports and adequate controls. All data needed to be secure. The design also had to consider future portability to a relational database for an eventual client/server implementation.
ITS/ASG chose to develop the acquisition card system (ACARD) in a UNIX, Pick-based (Unidata) environment, a platform that would accommodate the variety of desktop devices found on campus and a development environment in which ITS/ASG had enough experience to tackle the project�s time frame and functional requirements with confidence.
Development of the program�s policies and procedures went hand in hand with the process and system design efforts. The project team designed a high-level process flow and defined policies; the core team worked out details of fitting the processes and policies together while defining the ACARD system requirements. Program and process development each uncovered issues that affected the design of the other. System design had to support policies and processes. Department representatives spoke up whenever they thought additional work was being passed on to them as a result of policy, procedure, or process. Each time this concern was raised, the process was reevaluated until agreement was reached.
The team tackled many issues during program design, always mindful of the campuses� varied purchasing needs, as well as the many different ways individual departments conduct business. The team�s work resulted in program decisions (described below) based upon meeting the goals, attaining the mission, and following the design criteria defined for the acquisition card program.
A $1,000 maximum per-transaction limit was set at the state level consistent with then-current purchasing delegation. The UCB Director of Buying and Contracting has the authority to allow higher limits on a per cardholder basis. Departments are allowed to define the maximum dollar amount per cycle and the number of transactions allowed per day and per cycle per cardholder. Appropriate and acceptable card-use policies complement the basic First Chicago NBD card controls.
To facilitate ease of use, the project team tried to minimize restrictions on the card. The program specifies five types of card-use violations that carry specific consequences: personal purchases, cash, split purchases, inappropriate purchases, and lack of original documentation. Test pilot team members recommended cardholder-oriented consequences, which differ depending on the nature of the violation, and range from retraining to loss of card to termination and criminal prosecution.
The controller�s influence helped establish the program requirement to reallocate each transaction from the default account:object code to help track purchases and ensure that each transaction is reviewed by the department. As part of the accounting discussion, rules conforming to university and federal accounting guidelines were also established.
Hierarchy, participants, and roles were defined to organize information and structure the program within the campus. Program participants assume one or more of four basic roles within the hierarchy: (1) cardholder, (2) approving official (monitors card usage), (3) reallocator (enters accounting information for each transaction), and (4) department liaison (manages the program within the department). The program allows a single person to assume multiple roles if desired, as long as a cardholder is not his/her own approving official.
Program documentation includes "set-up" agreements (Program Entry Form and Cardholder Agreement), which are required for all participating departments and cardholders. Every transaction must have an appropriate receipt for the purchase, and the cardholder and approving official must sign the monthly Statement of Account acknowledging that the cardholder�s transactions were for university business.
Each department undergoes an initial audit shortly after entering the program, involving a visit by representatives from Buying and Contracting and the Controller�s Office. Ongoing audits of random samples of statements with transaction documentation attached for Buying and Contracting review will also be conducted. The audit results are used as a training tool and for program improvement and accountability.
Given the variety of departments and purchasing needs, the team wanted to establish a flexible process allowing each department to adapt the program to their unique needs. The Rummler-Brache Group�s process-mapping methodology was used to design the process flow, which included six modules: set up and training, purchasing with the card, accounting, approval, filing, and payment to First Chicago NBD.1
The process map was five feet high by twenty feet long, and hung in the Buying and Contracting conference room for three months. This map illustrated the process steps and corresponding input and output, and highlighted required steps, the steps� added value, and controls. It also provided a visual aid for detecting repetitive tasks, missing tasks, or inappropriate sequencing. Open issues were noted directly on the map. The map also unexpectedly provided two side benefits: its omnipresence kept all participants thinking about the project, and it acted as a billboard advertisement for the acquisition card program for anyone meeting in the conference room.
The final design eliminated paperwork traveling across campus, eliminated duplicate transcription and keying of information, established new documentation filing rules for individual departments, and moved payment processing from accounts payable (for individual invoices) to the treasurer�s office for one monthly payment. The revised process also pointed out the need to make more purchasing information available through easily accessible sources such as the Web.
The primary objectives of the system design were to reflect First Chicago NBD�s data with 100 percent accuracy, to provide quick and easy review and allocation of transactions to appropriate university accounts, to provide management reporting, and to ensure security.
To meet these objectives, the ACARD system was designed with the following functions:
Bank transmission. An automatic process dials daily into First Chicago NBD and retrieves the day�s transaction data, which is read by the ACARD system. Cardholder, transaction, merchant, and hierarchy activity records are built and balanced against each other.
Daily e-mail. After transactions are posted, e-mail with volume totals is sent automatically to program administrators, while e-mail to each cardholder and the corresponding approving official lists transactions that arrived that day for the cardholder.
Online accounting entries. Three screens of varying functionality and complexity are available for reallocating transactions to appropriate accounts. Transaction information as sent from the bank (merchant, amount, transaction date, etc.) cannot be modified; only accounting information, transaction status, and notes can be entered by the user. The system edits accounts and object codes for validity and adherence to accounting rules established by the project team. Transaction entry screens are accessible only by users with reallocation rights, and only by those users who are related to the transaction through the program�s established hierarchy.
E-mail reminders. The system sends weekly reminders to users and reallocators for older transactions that have not been reallocated.
Financial system interface. A nightly feed to the Financial Reporting System (FRS) is automatically run for new edits and unedited ten-day-old transactions. E-mail with batch totals is sent to project administrators and data control. The system coordinates the bank payment cycle with the FRS close, so that only current cycle transactions are posted to current month FRS.
Disputed transactions. Transactions can be flagged for dispute on the ACARD system, which will generate bank-ready dispute forms.
Cycle closing. Cycle-end processes are handled automatically by the ACARD system upon recognizing transactions for the last day of the cycle. The system sends the controller and program administrator an e-mail with cycle totals and the amount due the bank. Cardholder statements are printed. Monthly totals are calculated and posted per organization hierarchy, cardholder, and merchant. In addition, all current-cycle transactions are fed in time for the FRS close.
Reporting. The system includes a variety of reports as well as ad hoc reporting capabilities. Reports fall into six broad categories of transaction-based, merchant, cardholder, statistics, audit, and administration.
Specific program controls are essential to promote correct use of the card, encourage timely reallocation of transactions, help detect fraudulent transactions, and protect transaction data and card account numbers. Many of the controls are built directly into the program and system, while other controls are handled through policy.
Card-oriented program controls include card activation and university-specific information printed on the card. In addition, card limits and purchase types are verified at the point of sale. The ACARD system adds control points with transaction-initiated e-mail sent to cardholders and approving officials, age-based reallocation reminder e-mails, system feeds of transactions to the Financial Reporting System based upon program parameters, automatic generation and distribution of monthly cardholder statements, and ACARD system security based upon user profiles.
Policy-driven controls include the cardholder agreement, which must be signed and kept on file. The MasterCard liability protection program addresses cardholders who have terminated employment, and each department has the right to cancel any card within their hierarchy at any time. Policy controls also cover departmental responsibility for educating cardholders, appropriate approving official relationships, and review and filing of monthly cardholder statements.
The test pilots were the first to experiment with all aspects of the program: training, record keeping, ACARD system use, and reporting. Record-keeping systems received a lot of attention, with one or more flavors tried out in each of the departments. Pilot departments are now using their experiences to help advise other departments as they come on board. Test pilot use of the ACARD system revealed a number of areas that could be improved, such as the need for a simplified "quickie" reallocation screen to handle those cases (the majority) when a transaction needs to be reallocated to only one account.
The full pilot implementation further extended the system. Training programs and documentation were refined, and a user-oriented program handbook evolved during this phase. Controls were re-evaluated to accommodate department-specific needs yet maintain the integrity of the program. And as system use increased, so did the list of requested modifications and enhancements. For example, a batch e-mail function was developed to provide Acquisition Card Program administrators with a means for e-mailing notices to selected groups of program participants.
The number of users and volume of data have not significantly affected system performance. To accommodate the implementation of the UCHSC campus, a separate system environment was established on the UNIX processor used to run UCB�s system. Each campus has its own data, but only one set of programs is being run. Campus-unique logic differences are handled through control file items.
Statistics and measurements of process performance help indicate how well program goals are being met. The majority of the goals have numerical targets or standards associated with them. Baseline data were collected before the implementation of the program for comparison purposes, and process improvement and movement toward the established goals will be gauged from these baseline points.
As a first effort to measure the impact of the program, a five-question survey was sent via ACARD�s batch e-mail process to the program�s first eleven departments (118 cardholders). Out of a 52 percent response rate, 93 percent of the respondents expressed satisfaction with the program; 80 percent believe the program involves less than or the same amount of work. Some respondents commented that they believe that once they become more familiar with the process it will be less work.
Some of the benefits of the acquisition card project are that only one monthly payment is needed for all of the small-dollar purchases handled through the cards, and users have control of their own purchases and accounting. Also, each department can develop the internal paperwork system that works best for them. Departments interested in implementing the card are able to examine the experiences of departments already using the card and adapt those procedures most applicable to their situation.
Other benefits are that vendors are paid quickly, and the program provides automated systems of control, notifications, and reconciliation. These automated functions are among the program�s most popular features: (1) Controllers appreciate e-mail reminders of tardy reallocations. (2) E-mail notifications of new transactions are great for auditing purchasing activity against the card. (3) The batch e-mail communication feature makes memo sending a breeze for program administrators. (4) The "quickie reallocation screen," listing all unallocated transactions per cardholder, is a hit with departmental account reallocators.
The program is not without its drawbacks. The university is liable for all purchases against the card, causing some departments to be hesitant about participating in the program. This liability is currently being investigated by UCB. Some departments have the perception that the program will generate more work for them. To alleviate this concern, pilot departments are sharing their experiences and successes with interested departments. At a functional level, matching the transaction documentation to the transaction sent by First Chicago NBD can be problematic, particularly in cases where a single cardholder makes many purchases with a single vendor in one day: the bank�s electronic transaction does not include an item description, transactions often have freight charges added, and orders may be only partially filled. From a planning perspective, if any interfacing system changes, the ACARD system must be able to accommodate the change. The most vulnerable area to date has been the bank interface.
As a whole, the Acquisition Card has been a positive addition to the University of Colorado purchasing tool set. The Boulder and Health Science Center campuses have wholeheartedly embraced the program, and the Colorado Springs campus is eagerly anticipating its implementation. Our survey respondents have told us that the ACARD system saves them a lot of time, is a huge improvement in their flexibility to obtain parts and supplies quickly, and has made their lives much better and purchasing much easier. They appreciate that they have more control over the process. When they have last-minute needs, they do not have to force a rushed timetable on others. Most significantly, they have reported that their cardholders love the program.
1 Rummler-Brache is a business consulting group. See http://www.rummler-brache.com/
This was one of the award-winning papers presented at the CUMREC �97. Other CUMREC papers can be found by searching the CAUSE Information Resources Library. For papers from 1997, enter "CUMREC and 1997". CUMREC �98 meets in Atlanta, May 17-20.
Paula J. Vaughan ([email protected]) is Manager of Application Systems Development in the Administrative Systems Group at the University of Colorado at Boulder.
Kathe D. Graham ([email protected]) is a Purchasing Agent and the Acquisition Card Program Manager at the University of Colorado at Boulder.
![[Comments]](/ir/library/html/cem/comments.gif){kind=small}
![[Search]](/ir/library/html/cem/search.gif){kind=small}
![[Home]](/ir/library/html/cem/home.gif){kind=small}