L.T Beddis, Senior Buyer and J.M.Fenley, Senior Buyer, Consolidated Rail Corporation, Phila., Pa., 215-209-4190
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:
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:
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:
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.
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
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.
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:
Points to Avoid.
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:
|Exhibit I. Consolidated Rail Corp. Service Contract Volumes|
|February 1992 - July 1993||Number||Value|
Note: As the downsizing trend of corporations continues and as a result, the proliferation of "out sourcing", the need for Service Contracts will increase.