Design and Implementation of Electronic Requisitioning of Services

Author(s):

L.T Beddis
L.T Beddis, Senior Buyer and J.M.Fenley, Senior Buyer, Consolidated Rail Corporation, Phila., Pa., 215-209-4190

81st Annual International Conference Proceedings - 1996 - Chicago, IL

Introduction.
The main issues of this paper concern the design and implementation of electronic requisitioning for service contracts at Consolidated Rail Corporation, Phila., Pa. The contracting of services has often been referred to as the "neglected" side of purchasing despite the fact that service contracts typically involve high dollar amounts (please refer to Exhibit I for expenditure levels) as well as increased risk to exposure when compared to materials purchasing. This is due mainly to the fact that in most cases, contractors are performing services on Company owned or leased property and often involve construction, demolition, and environmental issues.

Service Contracting at Conrail was once a paper intensive process that required many levels of approval, all performed manually. Today, the requisitioning of services is a paperless procedure with a streamlined electronic approval process. As a result, the elapsed time between the input of a requisition and the actual service contract has decreased dramatically. What once took weeks or even months in most cases can now be measured in days.

This paper describes the journey to electronic requisitioning into five (5) distinct parts: 1)The objectives of the new Service Contract System (SCS) and more importantly, how were they achieved, 2) The search and selection of an outside software development vendor, 3) The implementation process, including the initial resistance by the user community and the struggle by the Purchasing department to maintain credibility during implementation, 4) A summary of the efforts needed to install radically new technology and the pitfalls faced during the process, and 5) What lies ahead - the future direction of the system.

Objectives of the New System.
The main objectives of the new Service Contract System (SCS) and how they were achieved were:

• Streamline preparation and approval of requisition - the current process involved the completion of a paper form (PA9) that was then forwarded (usually by mail) to a chain of approvers. The new system allowed any Conrail employee with access to the mainframe via PC, laptop, or a "dumb" terminal to enter a service request and also send that request to an approving official electronically. This ability to electronically approve service requests based on the scope of work (category codes)and/or dollar value has positively impacted the time it takes to get a service request into the hands of the appropriate purchasing buyer.
• Present the request to a buyer via on-line system queues - The new SCS system electronically distributes the approved requisitions to the appropriate buyer based on category codes. Category codes are seven (7) digit numbers that represent the type of service requested. Category codes are selected by the requisitioner at time of input.
• Ability to "track" a request - The new system allows anyone to easily find the status of a requisition. By "tracking", one can determine which buyer will handle the request, whether or not a contract has been issued, and perhaps the most useful function of all, the ability to see where the requisition may be bottlenecked.
• Eliminate non-value added steps - The new system did away with a long standing purchasing practice of logging in requisitions which was both cumbersome and time consuming. Additionally, this function was duplicated by the using departments. The new system also did away with literally hundreds of phone inquiries as to the status of a requisition. I.E. Do you have my requisition yet? Do you know who does? I'll call back in a few days to check again, OK?
• Generate contracts without clerical support - Conrail, being faced with the same downsizing atmosphere as other corporations, needed a system to electronically convert a requisition into a service contract. The new SCS system does just that, using a copy function of the software to transform information initially entered by the requester into a service contract. As a result, information such as service location, control clerk, technical representative, and period of performance are inputted only once. In the old system, pertinent data was transposed from the paper requisition to a "work sheet" that was then given to clerical personnel to type up contracts. The SCS system allowed us to eliminate the typing, proof reading, and corrections of typed five part carbon based Service Contracts.
• Reduce rework - A major problem of the old system was that we weren't aware of any accounting information errors until after the contract data was returned from an input center due to invalid data. With the new system, the accounting edits were built into the front end. The on-line editing feature of the new system will not allow a requisitioner to input wrong or inaccurate information on a requisition. I.E. Invalid work orders or management center data.
• Robust text capability to handle "category" specific general specifications - The new system was built with this feature. For example, if the service requested was for blacktopping or paving, the system would match up any available general specifications based on that category code. In addition, requesters could input their own "specs" in addition to the requested scope of work.
• Electronic interface with the Accounts Payable System - The new system has the capability to immediately interface with accounts payable the moment a contract is authorized. In the old system, a contract had to be typed, batched, and sent to an input center to be entered into the accounts payable system. This was time consuming and an error prone process.

The Search and Selection of an Outside Software Vendor. With the objectives in mind, a cross functional team was assigned to select a suitable system. First, the team looked to other railroads to see if anyone was using such a system, next they looked in-house to see if it would be feasible to develop the package ourselves. Both these options proved not to be feasible due to time constraints in developing a new or modifying existing systems. A decision was made to search for an outside software development vendor.

The search began with reference publications supplied by the Information Systems Department. A review was conducted on 76 "main frame" purchasing packages. The initial screening included performance capabilities, platform capability, and could the system handle services. Most of the purchasing packages available lend themselves to Material purchasing. From this criteria the "76" was shortlisted to ten(10) companies whose product seemed to be able to fit the bill. Literature was requested and questions were asked. Seven(7) more firms were eliminated. The search was now down to three(3) competent vendors who, to this point, offered products that seemed to satisfy our requirements.

Each of the three finalists were sent a detailed requirements document that spelled out exactly what type of application we were looking for. All three finalist were required to submit a demo, which was scrutinized and tested by the team and strengths and weaknesses noted. A scoring matrix was developed as a decision tool. The matrix was requirement based and included 28 separate elements. The three (3) vendors were then asked to submit formal cost and technical proposals which were dovetailed into the performance matrix and a decision was made and a Vendor selected and notified. The easy work was over. It would then take 4 to 6 weeks to develop and agree upon a detailed statement of work. From that point programming and testing would run approximately 2 to 3 months.

Implementation - Resistance To Change. Changes are viewed as potential threats either in terms of:

1. Making my job obsolete
2. Here comes more work for me, or
3. Here is something I will never be able to do.

Compound these basic attitudes with the fear of using the computer for the first time and in many areas the lack of accessibility to terminals and computers and you have the basic attitude we faced when we began our training.

To overcome these attitudes we established as one of our goals, during the training process, to demonstrate; how the system would directly benefit each user in terms of saving them time and to make their job easier. We stressed the following points as we taught the mechanics of how to enter a requisition:

• Reduction in time spent preparing requisitions (many requisitions were initially hand written and then typed, this was no longer necessary)
• Modification to requisitions are now just a matter of changing the specific section and not a total rewrite.
• Monitoring the approval status of a requisition is a simple query, while the old paper system required calling each approver to track the status in the approval cycle.
• Reduction in the cycle time from generating a requisition until the service is delivered.
• Ease of requesting an extension of a contract. Many of our contract require annual renewals.

We also stressed to our trainers the need to maintain a positive attitude about the system. Nothing will reinforce a negative attitude faster than a tentative or negative attitude of the teacher (preacher).

It is interesting to note that the department where we had the most resistance to the new system was our Information Systems (or Information Technology) Department.

Maintaining credibility. As stated above we stressed the advantages of the new system to our users. One advantage was the reduction in process time. One of the major challenges faced by the Service Contact Group was to rapidly turn the new electronic requisition into purchase orders and contacts. During the training and transition phase Service Contracts was staffed with one Manager and six Senior Buyers. Three of the buyers were trainers, which meant they were out of the office conducting classes and serving as a support function. It should be noted we had the support of one M & P Planner to help in training and the technical implementation of the system. After training a division (geographic operating territories) we would receive an average of ten calls a week and the calls could last up to an hour in length. At the end of the implementation a position was established within the Process Support Function to handle all calls for assistance.

At least 35% of the three trainers (Senior Buyers) time was consumed in scheduling training classes, traveling, training, answering problem calls and establishing the user and system files. The remaining three Senior Buyers and the Manager were committed to a separate initiative which was running concurrently - reengineering. Some buyers' backlog grew to more than 45 days. This backlog does not instill a great credibility with the user community. In order to maintain credibility for the system a higher priority was assigned to the electronic requisitioning to help demonstrate that the system did indeed function as promised.

Training.
It would be great to say that if you pick the right software package the job is done. Unfortunately, this is just the starting point. Training is the key to the success to any system.

1. Targeted population for training.
Before training started we established goals as to who should be trained. Initially we determined that all employees who initiated a paper requisition should be trained in the new process. We found that this goal was to general and could be interpreted in a number of ways. We also found that any employee that prepared one or two service requisitions per year had difficulty each time they entered a requisition in the new system. Users who utilized the system more frequently found the system to be far superior to the old paper process.

We trained a total of 407 employees during formal classroom training. A conservative estimate of those who actually entered a requisition within the first six months of their training was 30% of the trained population. This low percentage had many factors

• Our contacts on the divisions, who actually determined who would be trained, did not identify the correct population.
• We did not fully communicate who should attend.
• Some employees targeted to attend did not attend due to emergencies or they sent someone else in their place.
• Lack of access to equipment, forcing the entry of requisition at central point.
• Fear by Supervision to allow requisition to be entered into the System with out prior approval.

2. Training Methodology.
The format for the training classes were as follows:
a short introduction, then the instructor would lead the class through the basic operation (with the computer screens projected onto a screen) and finally have each student do some exercises on the system. These exercises would be entered on a test system. If you do not have access to a test system for the students to utilize you will have to make the decision as to whether to allow exercise data on the live system and then determine how to purge this data.

Unfortunately, only corporate headquarters and two of the six divisions had training facilities with terminals or PC equipment. Two of the remaining divisions had multiple phone lines in a conference room so we could utilize laptops and GRID pads. There were many more logistical and technical difficulties with dial-in training: lines did not work, host communications could not always be established, and it was tough to see the cursor while using the GRID pads. Even with these difficulties the hands on experience was helpful in the training process.

The remaining two divisions did not have a facility with phone lines nor did they have laptops or GRID pads. (At that time GRIDS pads were slowly being introduced) In these last two divisions there was no hands on experience within the class. While we did not log the help calls by the type of training received, all three buyers felt that there was a much higher proportion of calls from these two divisions.

In addition to some employees training themselves or learning from another user we found we trained a number of people by phone. This was time consuming and also not a very efficient use of time but sometimes was unavoidable.

3. What material would we cover.
We developed a course outline which covered all the material. We felt this material could be covered in a day and one half to two days (possibly a one day course with a half day follow-up.). Due to the time constraints the course was paired to four hours. There were several factors that were considered in cutting down the course: the number of training days needed by the instructor, the potential overtime by some of the students as many of the participants were union members, pulling people off their jobs for that length of time, coverage of jobs while people were at class, and last but not least, budget constraints.

Training manual - While this is important we found that many people never attempted to open the manual. They would call for support either through the formal channels (one of the Buyers) or more likely the informal channel. A couple of people in each department became proficient and became informal help lines.

What we learned the hard way. Although much is written for all of the following areas we had various degrees of success and failures with the below. We reiterate these points as we feel they are important.

Keys to Success.

• Planning - Planning the implementation, training, and establishing a help desk will pay dividends.
• Have the correct resources available (management commitment and understanding).
• Training is the key (the correct trainers and course content is critical)
• Establishing a support system for your users
• Use a team approach.

It will pay off over the life of the project if the correct mix of people are on a team (not just members from one department). When team members "buy in", a number of benefits will be generated:

1. You will not work in a vacuum and decide what is best for all the users of the system.
2. Implementation Planning is more complete with team members detailing missing steps and supplying who are the critical contacts in each department.
3. There is less resistance during training if a member of the user department is part of the training team.
4. The work load is spread among more people. Both authors are now part of a new training effort to implement The Procard Procurement Process. We can see the entire implementation/training process was much more efficient using the team approach.

Points to Avoid.

• No user involvement
• Putting the system in stages. This can be either a positive or negative, again planning is the key. Many of interfaces to other systems were not available at implementation. We found that the link between Accounts Payable was not immediately critical but the link between SCS and E-mail should have been established at implementation.
• Try to do everything yourself
• Working without support of the user community
• Don't promise future enhancements or results without the resources to follow through, it can kill the systems creditability.

Future Direction.
Since the implementation we have added user releases of rental equipment from Master Blanket Contracts.

A"GUI" (graphical user interface) version of the system for employees on the LAN at Corporate Headquarters. The electronic system is a mainframe based system. So our GUI version is actually just a screen scraper of the mainframe application with additional edits and user friendliness.

A material requisitioning segment has been added to the original services only system. This more than anything else has probably added to user acceptance as you can order service or materials using the same system. Both processes are very similar with the same PF keys and philosophy of a requisition composed of a header and line(s) item(s). There should not be two separate systems for ordering material and services. Two systems increase costs in terms of development, training and maintaining multiple systems.

While the Service Contract System was approved before the department's reengineering effort was initiated, many of the concepts generated from this effort were tested using the new Service Contact System. Principal among them was the use of a Blanket Order release mechanism used by field personnel in the areas of equipment rental and environmental remediation. In addition, many of the lessons learned in the implementation process of the SCS System will be applied when an IAP(Intelligent Acquisition Process)is implemented. IAP is an attempt to develop a system that would satisfy all requirements for all departments. It is not just a requisition and ordering system but an information and decision making tool with a flexible and friendly user interface. An IAP system is viewed as a critical next step in the on-going Departmental reengineering process.

Both Authors would like to thank and recognize Ann Lerro, Daisy Woods, Gary Watkins for the time and effort for both making the Service Contract System the success it is and for their assistance in the preparing this paper. While we feel there are no truly new ideas presented we hope that you will come away with the following thoughts:

1. If you are developing a new purchasing system make sure you can accommodate services and not just materials. One System that meets the needs of both is much more efficient.
2. Planning and Training and the resources for both of these functions are critical.

Note: As the downsizing trend of corporations continues and as a result, the proliferation of "out sourcing", the need for Service Contracts will increase.

Back to Top