Real-time production tracking and scheduling system

A computerized method of enabling the management of an automotive repair shop to optimize production by computing a job completion target through optimally scheduling a sequence of tasks on the basis of the availability and historical efficiency of individual technicians and historical average idle time of technicians and vehicles during the performance of the job, and providing detailed performance data of individual technicians on individual jobs for problem evaluation if the computed optimized target is not met.

DESCRIPTION OF THE PREFERRED EMBODIMENT FIG. 1 illustrates the overall organization of the system 10 of this invention. The heart of the system 10 is a central computer 12 which includes a database 14 and four major data processing functions 16 , 18 , 20 and 22 . Data is supplied to the system 10 by job intake workstations 24 and technician workstations 26 . The operation of the repair facility associated with the system 10 is monitored by supervisory workstations 28 which can direct the system 10 to generate desired reports at a designated workstation or on the printer 30 . The data processing function 16 , which is described in more detail below, is a scheduling and personnel availability function. Estimators at a job intake workstation 24 provide data to the scheduling function 16 regarding the estimated type and amount of work to be done on a car to be repaired. Based on that data, the technician efficiency and availability data stored in the database 14 , and the historical average idle time of cars and technicians during the repair process, the scheduling function 16 selects technicians and computes an optimum time required by them for the performance of all tasks involved in the job. That time, when added to the calculated job start time, can be recorded in the database 14 as the repair target or goal, i.e. the expected time of delivery of the repaired car, and may be so reported to the customer. In accordance with the schedule thus computed, the system 10 assigns work on a particular car or repair order to specific technicians in each department. Theoretically, if all the data in the database 14 is correct, and nothing unexpected happens during the repair job, the scheduled completion target should be met more or less exactly. If it is not, the below-described functions of the system 10 will enable management to identify any problems and take remedial action where appropriate. The event processing function 18 receives its input from the technicians' workstations 26 as each technician enters on his workstation 26 the beginning, interruption, restart or end of a repair task he is performing on a specific car. All events are recorded in the database 14 and are available to the other functions for scheduling, computation and reporting purposes. The efficiency/utilization function 20 compares the scheduled execution of tasks to their actual execution as determined by the event processing function, and computes from that data and from historical data stored in the database 14 the efficiency of individual technicians and technician/helper teams. This function also keeps track of the utilization rate of the business' resources, i.e. the idle time of technicians and the idle time of cars between repair tasks. The reporting function 22 receives data from each of the other functions and from the database 14 , and generates desired reports and status updates automatically or as requested by the supervisory workstation 28 . The operation of the system 10 can best be described in terms of functional modules as follows: 1. Scheduling As illustrated in the flow chart of FIG. 2, a bid may be entered at the job intake workstation 24 by an estimator, for example at 2:30 p.m. on Tuesday, October 3. The bid, i.a., identifies the vehicle and estimates the repair work required, e.g. 1.6 hours of body work, 2.7 hours of paint work, and 2.0 hours of color sand/buff work. The scheduling function 16 now searches the database 14 for the first available body shop technician. This may, for example, be technician B 2 whose currently assigned tasks are predicted by the availability data to keep him busy until 11:12 a.m. on Friday, October 6. The customer may thus be instructed, if the bid is accepted, not to bring the car in until Friday morning. The ability of the system 10 to accurately predict the date and time at which a technician will be able to start work on a car is important. Keeping a car idle in the shop's lot for days while awaiting the start of repair work not only wastes space, but subjects the customer or his insurer to unnecessary 20 rental car costs if the car is still drivable. The scheduling function 16 now determines from the database 14 that technician B 2 historically completes assignments, on the average, in three-fourths of the estimated time. Consequently, the function 16 determines that the body work will require 1.4 hours, allowing 0.2 hours for bringing the car into the work bay. It also determines from the data stored in database 14 how much idle time technician B 2 can be expected to have between the start and the end of his task. This is done by selecting similar tasks from the database 14 , e.g. tasks performed by technician B 2 that were estimated at ±5% of the labor estimate of the present task. The historical average of the idle times experienced during those previous tasks is calculated and is added to the projected working time of 1.4 hours. Assuming the historical idle time to be, for example, 0.8 hours, the scheduling function computes that the body work on the car will require a 2.2 hour block of technician B 2 's time. The scheduling function now looks for the first available paint technician. This may be technician P 3 . Having determined from the database 14 that technician P 3 historically takes 1.2 times the estimated time to do a task, and that he historically has 1.1 hours of idle time on this type of job, the function 16 computes that the painting task will require about a 3.3 hour block of technician B 3 's time. In the same manner, the scheduling function 16 computes a time block of 2.5 hours for color sanding/buffing technician C 1 (assuming that technician C 1 historically completes work in 0.8 times the estimated time and historically has 0.9 hours of idle time during this type of task). The time blocks computed for technicians B 2 , P 3 and C 1 are now added together, for a total of 8.0 labor hours. This time is added to the projected starting time of 11:12 a.m. Friday. Keeping in mind an 8 a.m. to 5 p.m. workday, 1-hour lunch breaks, twice-daily 0.3 hour coffee breaks, and non-working weekends, it will be seen that the scheduling function 16 will project completion of the repair job at 11:48 a.m. on Monday, October 9. This information can now be communicated to the potential customer together with the dollar amount of the bid. If the customer accepts the bid or immediately (dotted line in FIG. 2 ) if the job is not subject to bid, a repair order is issued, and the computed time blocks, estimates, and projected completion date are entered into the database 14 . At the same time, the individual time blocks computed for technicians B 2 , P 3 and C 1 are added to any time blocks previously assigned to them in database 14 by the scheduling/availability function 16 to pinpoint their availability time for the next bid. It will be understood that provision may advantageously be made for the manual or automatic selection of a particular technician when, for example, an unusual type of damage requires a technician with special skills. 2. Event Processing As illustrated in the flow chart of FIG. 3 , each event in a technician's work flow, such as starting a task, completing a task, interrupting a task (e.g. to work on another car), seeking special authorizations, etc. is entered by the technician on his workstation 26 . For example, when technician B 2 finishes his previous task, he records that event and consults his workstation 26 for his next assignment recorded in database 14 by the scheduling function 16 . He then gets the current car and enters a start-work event on the repair order associated with that car. If, during his work, a question arises e.g. as to whether a certain item of work is authorized, he can query a supervisor on the workstation 26 . Until the supervisor replies, the function 18 records idle time, which does not count against work efficiency. Likewise, time spent getting a part is entered on the workstation 26 and is recorded as idle time. If work on a car is temporarily discontinued e.g. due to the unavailability of a critical part or other reason, an end work/incomplete entry is made, and the function 18 holds the task in suspension while the technician does other work. If a part order will delay the repair job significantly, a note entered by the technician will alert the estimator to call the customer and advise him of the expected delay. Within allowed time limits, lunch and other authorized breaks are not recorded as idle time, as they are built into the technician's available on-duty time data used by the scheduling function 16 . 3. Efficiency and Utilization FIG. 4 illustrates the computation of efficiency and utilization data for individual technicians and teams. Each time an event is entered, the function 20 updates the records of the technician making the entry. For example, a start-task entry updates a car possession register to keep track of which technician has the car; an interrupt entry starts a technician and car idle time counter; and a task-completed entry triggers a comparison of the actual time expended on the task with the estimated time, and a resulting update of the technician's historic efficiency factor (which, as described above, is used by the scheduling function 16 in scheduling the technician's work). A task-completed entry also begins an idle-time count for both the technician and the car until the start of the next task for each. The idle-time counts provide valuable statistical information for the shop management, and as described above, are used by the scheduling function 16 . Typically, each task or job is inspected by a supervisor upon completion. If anything is unsatisfactory, the responsible technician will be asked to correct the deficiency and to enter the correcting task as rework. The time consumed by such rework is logged against the technician's efficiency factor. Entry of the last task completion for a given car provides data regarding the total labor hours, by technician, used on the car. This is compared by the function 20 to the estimated hours and is used to generate an historic efficiency rating for the estimator that allows fine-tuning of the estimates or bids. 4. Reports It will be appreciated that the above-described data stored in the database 14 enables the reporting function 22 to generate a wide variety of reports (for example those shown in FIG. 5 ) to management personnel. Also, interested parties such as customers and insurers can be advised at any time of the current status of the repair of any given car; or they can be automatically so advised at selectable predetermined intervals through status updates generated for transmission by fax or e-mail. From a management point of view, reports of the efficiency factors recorded for individual technicians and estimators are useful in assessing promotions or salary incentives, or in remedying problems in specific departments. Reports of cars' and technicians' idle time allow assessment of personnel needs. The main utility of the data available to management through the present invention is, however, the ability to closely monitor the performance of repair orders and thereby to identify repetitive types of deviations from the optimized calculated target that can be improved by reorganizations or other management policies. It will be noted that, as good management reduces the average idle times of cars and technicians, the scheduling function will inherently set ever tighter targets until the shop is performing as optimally as possible. It is understood that the exemplary real-time computerized production tracking and scheduling system described herein and shown in the drawings represents only a presently preferred embodiment of the invention. Indeed, various modifications and additions may be made to such embodiment without departing from the spirit and scope of the invention. Thus, other modifications and additions may be obvious to those skilled in the art and may be implemented to adapt the present invention for use in a variety of different applications.