Telematics systems and other data-gathering technologies such as radio frequency identification (RFID) systems are, at their most basic level, merely another data stream feeding our fleet-management information systems. In many cases, data is combined with other data, usually reported via pen and paper and manually entered. This information becomes useful as it drives management reports such as utilization reports, preventative maintenance (PM) reports, cost reports, and a host of other periodic management and maintenance reports.
One of the promising advantages of technology-based reporting systems is the potential for greatly increased accuracy and timeliness of the data they provide. Fleet managers are well aware of the problems with data that is manually collected in the field and keyed into the fleet-management information system by a data entry clerk. Corrupt data provide incorrect reports.
These reports, in turn, cause us to make poor decisions or take inappropriate actions. Skewed cost-per-hour numbers due to inaccurate hourmeter readings can cause poor repair or replacement decisions. An hourmeter reading that is too high indicates a machine due for scheduled maintenance when it is far from due. We dispatch a technician only to find out that we had bad information. One of these wasted trips can cost hundreds of dollars when you factor in technician wages, truck mileage and fuel, and, perhaps most costly, the opportunity cost in machines that we were unable to service because we were chasing bad information.
Telematics promises to help us solve these problems, but the potential for corrupt data still exists. We shouldn’t blindly import this data into our business systems without some sort of validity check. The perfect time to incorporate these validity checks is when our IT folks are building the applications that retrieve telematics data from the providers’ servers, parse it, and import it into our databases. Some simple logic can weed out the most obvious problems.
To illustrate the concept, let’s consider hourmeter readings. There are some basic principles we can apply to reject obviously incorrect readings. First, any new meter reading that is lower than the current reading is most likely incorrect: hourmeters don’t run backward. Our IT department built logic into our meter entry screen that rejects any reading lower than the previous one.
Readings that are too high are a little more difficult to detect, although some basic logic can help avoid the most egregious errors. For example, it is impossible for a machine to run more than 24 hours in a day. In reality, anything more than 20 hours per day for construction equipment is likely cause for a closer look. There are some situations that could cause a reading greater than 24 hours per day over short periods, but these are rare, particularly with telematics systems where data is retrieved daily.
I don’t recommend automatically discarding readings that are rejected, but that they go into a queue for further examination. The readings that are too low could be the result of a previous reading that was too high, or the result of a meter that was replaced without a corresponding change in the meter tracking system. Likewise, readings that appear too high may be correct. Of course, you may discover that the readings are just bad data and there are technical problems or human errors that need attention. Unless someone examines the cause of the anomalous reading and takes the appropriate action, some of these problems could continue indefinitely.
The system that we built requires all meter readings go through an approval queue before they are imported into the database. This may be a little extreme, but we feel that the cost of bad data is too high to take the chance. Although these principles apply to both telematics and manually reported data, it is important to avoid the trap of blindly accepting data from your new telematics system. Take a little time up front while developing your interface to avoid costly mistakes down the road.
