This paper was presented at CUMREC '99, The College and University Information Services Conference. It is the intellectual property of the author(s). Permission to print out copies of this paper is granted provided that the copies are not made or distributed for commercial advantage and that the title and authors of the paper appear on the copies. To copy or disseminate otherwise, or to republish in any form, print or electronic, requires written permission from the authors.


Functional Reengineering
Of A Purchasing Card System

Iowa State University (ISU) is a public land grant institution placing an emphasis on areas related to science and technology. ISU is organized into nine colleges, including the Graduate College. These colleges offer a total of 100 Bachelors degree programs, one Professional degree program, 105 Masters degree programs, one Specialist degree program and 81 Ph.D. programs. ISU serves over 25,000 students and employs over 6,000 faculty and staff. For further information visit http://www.iastate.edu/ on the web.

Abstract:

Successful reengineering of the functionality and methods in the highly automated ISU Purchasing Card System is the focus of this presentation. The development of ISU's purchasing card system, its processes, and subsequent changes to work load distribution within the system will be discussed. How this all resulted in the successful implementation of the reengineered system will be covered.

A major component in the reengineering was user involvement. Design was undertaken with active departmental participation. Users not only tested the new system but also contributed to its development throughout the four phases of evaluation, analysis, design, and reconstruction.

The functionality focused on the user with the realization that higher system usage will result in higher cost savings. Goals, developed in the analysis phase, that were incorporated in the design phase included: timeliness, accuracy, user-friendliness, accountability, cost-effectiveness, and client input.

The functional core of this system includes real time updating, nightly e-mail notification, and a hierarchical reconciliation audit trail. In theory, a transaction could be ready to post to accounting within 48 hours after an order was initially placed. Goods and electronic transmission would be received the day after the order is placed, and reconciliation often done that same day.

The effects on normal business operations within the Purchasing department have been noticeable even at this early date. Our "Check With Order" system is used less, the number of departmental orders have been reduced with their corresponding vouchers and checks, and order cycle times have been reduced by half.

Introduction

Iowa State University introduced its Purchasing Card (P-Card) Program as a pilot project in 1997. The intent of the P-Card Program is to implement an effective electronic business practice in the university environment. It is designed to delegate the authority and capability to purchase low-dollar supplies directly to the user through the use of a credit card.

For the cardholders, using the Purchasing Card provides quicker turn-around time on their orders, widespread acceptance by vendors, ability to purchase on the internet and reduces paperwork. For the university, using the Purchasing Card provides a means of reengineering the functionality of the purchasing and payment process.

Reengineering is most successful when processes are eliminated rather than just reallocated to another functional area. The use of the Purchasing Card eliminates work, labor, filing space, and material costs from user departments, Purchasing, Treasurer’s office, and Accounting. Purchasing Cards have several controls built in to limit the university’s liability and protect against misuse through pre-set dollar and merchant code limits and individual cardholder accountability.

It is not hard to see that the Purchasing Card concept is an acceptable and effective way of doing business since the P-Card market is now a $15 billion/year business and growing. The problem that organizations face with the use of the P-Card is the lack of solutions to make the reporting process more automatic, allow faster access to transactions, and permit greater ease and precision in the accounting application. In other words, we are doing the right thing, but how do we do the right thing the right way? How do we reengineer this process to be the most efficient system to use?

For the P-Card program to be successful and save the university time and money, we determined that the cards need to be used for most all low-dollar, non value-added transactions. Because this is a voluntary program and is definitely in the best interest of the university, the entire process needed to be reengineered to be user friendly, less costly, accountable, accurate, fast and paperless.

To be efficient the P-Card Electronic Reconciliation system needs to receive daily electronic transmissions from the credit card company showing posted card transactions. These transactions need to be validated for accuracy and receipt of goods. Once validated, these transactions have to be routed electronically to an individual who can reallocate the correct funding and accounting codes. The transaction can then be routed electronically to an approver, and upon approval moved into the general ledger system.

A major component in reengineering is user involvement throughout all stages of the project. This is necessary for appropriate design as well as acceptance of the system itself. So, that is where we shall begin.

Reengineering Steps

Four distinct phases can be seen in our reengineering effort of implementing the purchasing card program: evaluation, analysis, design, and reconstruction. User input was encouraged during each phase.

Evaluation:

Evaluation was performed in an attempt to get a comprehensive picture of the existing processes used in making low-dollar purchases. Several departments were queried as to their procedures pertaining to this type of purchase. It was determined that the existing system involved four multi-part forms, up to 10 individuals from a minimum of three departments, and at least 21 distinct processes. This phase also revealed costs not obvious to cursory review such as document storage, photocopying, and the amount of manual labor. A process matrix depicting these processes was developed after several meetings, surveys, and discussions involving over 100 individuals.

Process

Form

Department

Method

*Costs:

Requisition - completed

Requisition

Requesting

Varied

Form

Requisition - Filed

 

Requesting

Manual

Storage

Requisition - Mailed to Purchasing

   

Inter-office Mail

 

Requisition - P.A. research

 

Purchasing

Manual

Phone Calls

Requisition - Clerk

 

Purchasing

ADIN

DP Costs

P.O. - printed (5)

Purchase Order

Purchasing

 

Form, DP costs

P.O. - Proofed

 

Purchasing

Manual

 

P.O. - Mailed

 

Purchasing

Manual

Postage, Envelopes

P.O. - Filed (2 locations)

 

Purchasing

Manual

Storage

Invoice - received - time stamped

 

Purchasing

Manual

 

Invoice - copied

 

Purchasing

Photocopier

Photocopies (3)

Invoice - keyed

 

Purchasing

ADIN

DP Costs

Invoice - Filed (3 locations)

 

Purchasing

Manual

Storage

Voucher - printed (3)

Voucher

Purchasing

ADIN

Form, DP Costs

Voucher - Proofed

 

Purchasing

Manual

 

Voucher - Distributed

   

Inter-office Mail

 

Voucher - Accounting reviews

 

Accounting

Manual

 

Voucher - Filed (3 locations)

 

Accounting

Manual

Storage

Check - printed

Check

Accounting

ADIN

Form, DP Costs, Bank Fees

Check - Proofed

 

Accounting

Manual

 

Check - Filed

 

Accounting

Manual

Storage

Check - Mailed

 

Accounting

U.S. Mail

Postage, Envelopes

*Costs - excluding labor

Figure 1: Evaluation Matrix

Other major considerations were:

Analysis

The analysis phase also utilized user input to expand on the matrix in figure 1 and changes to it to deal with "non-typical" orders, a review of existing purchasing card programs from several banks, comparisons of existing software to deal with reconciliation of credit card transactions, and establishment of system goals. The hypotheticals had to be considered within the new system and were used to project the worst-case scenario. During this phase, we also researched programs within other universities and turn-key solutions existing at that time. After much review and discussion, development of an in-house system was selected. The system would be developed to satisfy the goals established, key players' needs, and the program responsibilities. As participation in the program is voluntary, user-friendliness was high on the list of goals as was with continued user input, to not only develop what was needed but also to develop a sense of ownership. Other goals included timeliness, cost savings, labor savings, flexibility, and accountability.

Key partners and their roles were identified and charted.

Bank

Issue Cards

Verify transaction limits and conditions

Transmit transaction data

ADP

Develop Software and Database to:

Receive and convert data

Reconcile transactions

Maintain system users information

Post transactions into accounting

User Departments

Establish hierarchical approval structure

Maintain documentation

Reconcile transactions

Purchasing

Promote Program

Administer Program

Train Users

Create & maintain user database

Assist in audits

Controller Office

Audit program

Additional players were identified at this time. The Bank uses a processor that compiles, encrypts and transmits the transaction data through a Value Added Network (VAN). Contacts were made and discussions held with these entities with the goal of establishing a mutual business understanding.

Program controls were established during this phase focusing on confidentiality and audit-ability. When dealing with credit card and Social Security numbers, security was a large concern. It was determined that University ID numbers would be used in place of Social Security numbers and that e-mail notifications would not contain any pertinent account information, including card numbers or University ID numbers. Contact was made with in-house auditors to determine system compliance.

Design

The design phase began by addressing the goals set in the analysis phase and developing a process flowchart (figure 2). Departmental comments were garnered from a marketing-type presentation given by the Purchasing department. Cost savings, user-friendliness, and time-savings were emphasized and a few suggestions were incorporated into the system design.

The design of the system incorporated transmission of transactions from card processor, validation of each transaction, reallocation of appropriate internal funds, approval, and posting to the General Ledger System. The validation, reallocation and approval processes require on-line participation of each user department. Each user department would determine who would perform each function.

The validator is the person responsible for validating or verifying that each transaction is an authorized purchase, billed correctly, and that materials/supplies have been received. The reallocator is the person responsible for entering the accounting information on-line for each transaction. The approver is the person responsible for approving specific fund numbers assigned to a particular transaction. Each of these functions requires a proxy, in case of illness or vacation of a primary. These individuals are "System Users" entered into the Purchasing Card System database.

The process steps are linked by e-mail notifications. As transactions are posted and transmissions received, the validator receives an e-mail message informing that person of transactions which need processing. Likewise, each process function receives an e-mail message when each is required to perform an on-line task. To reduce the burden of multiple e-mails and delays in processing, the system can determine if one individual is both a validator and reallocator, thus combining the process function in one step. This allows the individual to validate and reallocate at the same time.

Flexibility is a key component in achieving user-friendliness. In most processes, there are exceptions or situations that require a customized response. Some transactions represent the joint financial responsibility of two or more departments. The system needed the flexibility to reallocate any transaction up to six different fund numbers and maintain the integrity of the designated approval authority.

Finally, design must consider the organizational culture in which the system operates. In our case, Departmental Executive Officers have the fund approval authority, but lack the time to spend on small-dollar transactions. The system needed the flexibility to allow each department a means to determine which approver received e-mail notifications. Each department has the capability to alter the system to send e-mails to approver only, proxy only or both.

Reconstruction:

The purchase order system reconstruction aspect involved a major change in how procurement is done.

The existing system contained five multi-part paper documents and 21 steps. The reengineered system contains no paper documents and three or four steps. The new system with highly automated processes reduces the labor involved in paper shuffling, filing, proofing, etc. Payment transfer is electronic with a balance verified against the electronic transactions received throughout the month.

The automated system reduces and/or eliminates manual involvement from the user department, Purchasing, Accounting, and Treasurer’s office. The system eliminates the need to store paper documents in the Purchasing and Accounting departments and significantly reduces the storage of paper in the user department. The potential impact of the system could reduce as much as 70 reams of stored paper from one department each year. University–wide impact of stored paper documents reduction could be as high as 510 reams. The potential impact on labor reallocation is noteworthy, as well. Labor efforts can be diverted from non value-added functions, such as filing, proofing, key-entry, etc. to other tasks more beneficial to the mission of the university.

Currently, the purchasing card program is in the pilot stage with six departments participating and 80 cards issued. Campus-wide release will begin in November, 1998 with aggressive marketing done by the program administrator.

The ADP Center computing systems support is provided via an IBM 9672 central server running OS/390, CICS, and DB/2. The system utilizes an IBM 9393 RAMAC Virtual Array RAID-6 disk support along with a 3490 tape subsystem. The system provides sub-second response times for 200,000 transaction loads per day.

The Future

This system is designed to be flexible to accommodate banks, users, hardware, etc., thus reducing future costly upgrades or internal functional changes. Changes in file layouts, transmission specifications, and software revisions can be performed without third party considerations. User requests for individualized reports and unique requirements are more easily generated and better managed with support staff knowledgeable of organization needs. The ability to utilize existing hardware reduces initial investment and ongoing maintenance costs. Support screens can be customized to address user understanding pertaining to existing systems currently being used, which helps in user acceptance of change. In-house technical support provides additional flexibility and a more personal response.

The ADP Center is currently reviewing two software packages that would allow this system to be accessed from the internet with few, if any, changes to the system. Design for the web access was of minimal concern initially due to how users currently access computer systems and their access to the internet itself. Intranet access is projected to be in place within the next year with current access also available.

Summary


Reengineering success can be measured by processes and costs being eliminated, rather than reallocated to other functional areas, and overall acceptance by users. The Purchasing Card Program offered an opportunity to reengineer a function, which reduced and/or eliminated processes and costs for other functional areas, as well. The P-Card program streamlines the purchasing and payment process for low-dollar procurement. It offers users quicker turn-around time on orders, broader scope of acceptance by vendors, and the ability to purchase through the internet, with significant paperwork reduction.

Purchasing Card Program success is dependent on utilization. Since participation is voluntary, reengineering the payment function was key to acceptance of the entire program. The online reconciliation of purchasing card transactions provides an efficient method of internal transaction validation, fund allocation and approval. It is highly user-friendly, timely, accurate, and flexible. The savings in labor, material, and service costs for Purchasing, Accounting, Treasurer’s Office, and user departments is significant. In addition, the adaptability of the system will also will provide significant savings by avoiding costly upgrades in the future.

Reengineering the purchasing function through the use of purchasing cards is doing the right thing. Reengineering the purchasing payment function associated with the purchasing card is doing the right thing, the right way for ISU.