TECHNICAL FIELD
This application relates to software applications used to track and perform calculations on time-related information for vehicles that are in a vehicle repair facility for maintenance or repair.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram illustrating an exemplary vehicle downtime reporting tool.
FIG. 2 is an illustration of an exemplary graphical user interface (GUI) that can provide report information.
DETAILED DESCRIPTION
FIG. 1 illustrates an exemplary vehicle downtime reporting tool 100 that can be used to determine how much downtime has elapsed. Downtime may be defined as the elapsed time from the writing or entry of a repair order (“R/O”) to the time the job is completed by the last person to work on the last job to be completed on the vehicle.
In one example, a dealer management system (e.g., the exemplary dealer management system 102 of FIG. 1) such as Procede can be used in connection with or as part of the downtime report tool.
In one example, the downtime report tool involves creating ODBC links (e.g., to establish database connectivity to a database such as one that stores information relating to a technician's time at work or on a specific project). Screen scraping software can be used (e.g., to extract data from a file sent to be printed) to retrieve data to be used in computations.
In one example, a custom report (e.g., the exemplary custom report 104 of FIG. 1) can be used, such as Crystal Report. A SQL query (e.g., the exemplary SQL query 106 of FIG. 1) can be used to group certain attributes (e.g., by repair order), such as in a report 200 shown in FIG. 2. For example, such attributes can include the date/time a repair order (“R/O”) was created and the date/time the last technician to work on the R/O punched off of that particular R/O. An R/O may include multiple jobs or services to be performed on a vehicle. A downtime can be calculated for a particular R/O by subtracting the date/time the R/O was created from the date/time the last technician punched off (e.g., completed) the last job to be done on the R/O. Selectively, certain jobs may be eliminated from downtime computations. For example, if no R/O is written, a job takes less than a threshold time to complete (e.g., 30 minutes), or the job takes longer than a threshold time to finish (e.g., one month). The thresholds may be varied. Additionally, key metrics for downtime at each location can be determined. Such key metrics can include mean, median, standard deviation, and R/O count. These metrics can be displayed, for example, by an interface such as the exemplary graphical user interface (GUI) 200 illustrated in FIG. 2.
The downtime computations may be used, for example, in evaluating the efficiency of a vehicle repair facility. The efficiency may be evaluated relating to specific jobs also. The in-shop downtime may also be started and finished with another triggering and ending event (such as the time the first job of an R/O is started, or the time the vehicle operator retrieves the vehicle), but the above approach is desirable.
Having illustrated and described the principles of the invention by several embodiments, it should be apparent that those embodiments are illustrative only and should not be construed as limiting the scope of the present invention. The present invention encompasses all such embodiments as may come within the scope and spirit of the following claims and equivalents thereto.