![]() | ||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||
|
Automated Estimating Systems Ease Body Shop Life Despite ProblemsPosted 10/7/1998By Patrick Paul
Collision repair office personnel and insurance adjusters have for years relied solely on what is probably the most unreliable mechanism for preparing vehicle damage estimates: themselves. As a body shop manager and self-proclaimed computer nerd, I'd like to think of myself as near perfect, but whenever I try doing math without a calculator, I have to admit I'm far from it. Among many other reasons, that's why computerized estimating systems have overtaken the use of pen, paper and crash book. They are easier to update, have no big books to lug around, and don't require pens to lose or numbers to keep track of. Of course, when estimating software was first made available, some may have argued the usage of such systems was a greater ordeal than writing an estimate by hand. Let's just say that some of the early computer estimating systems were, well, tedious. Some used a light pen and a binder full of bar codes that one scanned in order for the computer to "look up" manufacturer parts data. In essence, users were feeding the computer the crash data like food to a baby, doing all the real work themselves. To add to the headache, whenever updates were made to the data, one had to change out the sheets in the binder. Others weren't user friendly in their presentation, as computers had limited abilities to display lifelike graphics (pictures). Still, others forced the user to scroll through seemingly endless lists of parts to find the correct one for the model vehicle they were writing. Some, not too long ago, even required the memorization of certain commands corresponding to keys on the keyboard ... in foreign languages! Computers themselves weren't too likable, as the portable ones were bulky and required massive carrying cases more akin to checked baggage at the airport. Today, however, we benefit from a huge leap not only in technology, but also in concern for the customer when making collision industry software. The market for estimating software has become more competitive, thereby forcing vendors to become more customer-driven. Data is now stored on compact discs, which one merely has to insert in a computer's tray to access the information, and Windows-based interfaces make for easy "point-and-click" operation. Most systems are now capable of detailed VIN decoding, which will define the vehicle for which the estimate is written, in some cases, all the way down to the transmission type or engine size. Some even "filter" the parts lists in order to screen out parts not applicable to the particular model selected. These enhancements lead to a more foolproof, faster and easier way of writing damage estimates than was ever possible by hand. Popular estimating software packages also contain additional applications for job costing, parts tracking, digital photo imaging and other business functions. No matter the amount of technology, ergonomics and features packed into an estimating system, it is no more accurate than the data it utilizes to prepare estimates. Data accuracy has been a topic of great debate among collision professionals for some time, but it is even more prevalent when computer programs dictate not only the data, but how the data may be applied to the estimate. Due to the fact that most computer estimating systems use data provided by a major crash book publisher, the data is usually quite accurate. Mitchell UltraMate estimating uses the familiar Mitchell book data and pictures. CCC's Pathways and a host of competing products utilize the Motor crash estimating data. ADP's Shoplink uses its own proprietary database, Audatex. Confusion is sometimes the result of comparing labor times and parts descriptions of an estimate written with this proprietary database against one written with a crash book or other popular estimating program. Labor times are relatively accurate for all the major estimating databases; however, it seems, in my experience, that Mitchell labor times are often less than those of other systems for the same operation. For instance, to overhaul a rear bumper assembly on a 1996 Honda Civic, Mitchell data suggests 1.2 labor units, whereas Motor data suggests 1.5 units. Both figures are similar, however, and therefore can be considered equally useful due to the fact that no two technicians would perform the operation in the exact same time frame, and both are good data for flat-rate pricing. Some estimating systems suffer more from poor presentation than questionable accuracy, as they often break up labor times in an unusual manner. For instance, rather than displaying an "overhaul" time for a bumper assembly and then displaying below it all the individual bumper parts' labor as included in the overhaul time, Audatex will often seem to randomly assign a bit of labor to one bumper part, a bit to the core support, some to other adjacent assemblies and some to still other bumper parts. If one were to add these times together, one would arrive at a reasonable overhaul time for the complete bumper. This method of distributing labor to parts and operations can make an estimate difficult to decipher at times for a potential supplement. CCC's Pathways and EZest systems sometimes have trouble properly calculating labor for operations not commonly performed together. For instance, it is a rare event for two quarter panels to be replaced on the same vehicle, but when I was writing a late model Nissan Maxima hit in the rear end, replacing both quarters became necessary. Upon entering those operations in Pathways, I was alarmed to discover that the database had deducted for the included rear bumper R&I not once, but twice, because it did not expect both quarters to be replaced simultaneously along with the rear bumper cover. All systems sometimes suffer from a delay in data being published. It seems that no one data provider can keep pace with Chrysler Corporation's constantly escalating list prices, and therefore part prices are always off by a few dollars and cents on every Mopar product I write. Saturns prove similarly infuriating. Such anomalies are rare, though, and the vast majority of computer estimates written are very accurate and complete - more so, in fact, than they probably would have been if written by hand. One of the reasons (and my personal favorite) that computer software makes estimating more accurate and complete is the fact that the computer does all the math for you. There are no forgotten percentages, formulas or P-page procedures. Another is automated data filtering, offered on some newer systems, which keeps the computer from displaying parts that would not fit the particular year and trim level of the vehicle in question. No more accidentally figuring the headlamp for an XE when one is writing an LE. Some estimating systems list related operations adjacent to, or when performing, certain common replacements, such as offering toe-in adjustment when replacing a control arm, or headlamp aiming when replacing a header panel so the user doesn't forget to figure the "extras." Let's not forget to mention that one never needs an eraser or white-out when one has a "delete" key at their disposal. Among other benefits, these help make computer estimates faster to create and more accurate than handwritten ones. When it comes to the manner the estimating system allows the user to write the estimate, most systems have optional clear coat limits, aftermarket part database usage rules, as well as a plethora of other controversial exclusions, limits and methods that can be set up by the user or the user's manager. These options can be set up to protect the interests of the user by, for example, limiting clearcoat to 2.5 hours or not allowing the user to select OEM parts in some cases. Any of these options can be overridden, however, and should not be an excuse to curse computerized estimating. All this proves is that even though estimating systems are sophisticated and still improving, the art of negotiation and the use of good common sense - things inherently human - cannot be thrown into the "recycle bin" just yet when it comes to creating computerized estimates.
|
|||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||