Ambiguity is a problem often faced by software designers. If a program requests a single record from the database, and multiple records meet the criteria, then we have an “ambiguous” result. The designer must anticipate this possibility, and provide measures to resolve the ambiguity.
I winced the first time I heard the verb “disambiguate,” in December 2002. I was working at Route One, where one of our dealer identifiers was found to match more than one of Ford’s. The speaker was R.J. Bussone, and for all I know the coinage was original with him. The term has since entered common usage, at least among software designers.
At MenuVantage, we found that we could not precisely identify the model of a given Ford Truck from its VIN alone. The error message “ambiguous model” was despised by our customers, not only because it placed a burden on them to resolve the ambiguity – but also because few car dealers seem to recognize the term. One called our help desk wanting to know if an “ambiguous” vehicle was one that could run in the water.
MenuVantage is based in Fort Lauderdale, and it happens that tour-bus operators here use amphibious vehicles called “ducks”.
“Look,” I said to my lead developer, Jeremy, “there goes one of those ambiguous vehicles.”
“It is ambiguous,” he replied, “I can’t tell if it’s a truck or a boat!”
In the software business, we often blame the customer for not embracing our latest innovation. This has certainly been the case with e-contracting. We solved a host of technical problems, from data standards to digital signatures, only to discover – dealers won’t use it.
They have some good reasons. Laser forms require multiple copies and multiple signatures. Signature pads cost money and customers don’t trust them. Laser printers are expensive. Inkjet printers are cheap enough, but you need one in each office. Blank paper is $9.00 a ream, compared with contract stock brought in free by agents and field reps. All things considered, the impact printer works just fine.
This reminds me of when we first put credit applications online. Dealers already had the perfect solution. “I go have a smoke while they fill out the app, and then I blast fax five lenders.” How do you compete with that?
We showed that online credit, combined with automatic approval, closed more deals. We showed that the internet was cheaper than the fax, and that the system would share data with your DMS. We also kicked in a $20.00 spiff, as I recall, which we recovered in data entry costs.
Today’s challenge is no different. Dealers are shrewd enough to know that the benefits of automation accrue mainly to the finance sources and the product providers. As innovators, it is our job to show what’s in it for them.
I had lunch yesterday with an old friend from AutoNation. David now works for JM&A, and I started thinking about the two companies. AutoNation is the world’s largest auto retailer. Jim Moran Enterprises is the most vertically integrated. I picture them in opposite corners of a Gartner chart.
Mike Jackson put an end to AutoNation Financial Services in 2002, because he wanted no distractions from the pure retail business. Mr. Moran’s vision, by contrast, was that he would control every revenue stream within his Southeast Toyota footprint – from the port to the stores, including financing and all the F&I products. Today the finance arm, World Omni, is so strong that it does third-party servicing for other lenders. Each of these businesses, up and down Moran Boulevard, is a strong competitor in its own right.
I wonder if a single entity could combine the two strategies – the depth of a JM with the breadth of a public dealer group.
Thanks to the people who responded to my query on Linked-In. I am still learning about the systems used by my customers in the vehicle service contract (VSC) market. Most, it seems, have homegrown AS/400 systems. I have also gotten referrals for Sirius and Stone Eagle. Please comment here, and tell me what system you are running, whether COTS or custom, and what the platform is. Thank you.