Category: Software

Process Agnostic

Here’s a tip for designers of F&I software.  The way to win a feature-function debate is to challenge the other guy’s understanding of the process.  A surprising number of design decisions are made with no attention to process.

When, exactly, is the dealer going to do that?

Standalone product portals are just one example, where the F&I manager has to break his flow for a one-off activity and some extra keypunching.  By the way, pretty much every downstream system must have a DMS interface.

Among experienced designers, two techniques are successful.  One is to have a thorough understanding of the process.  Does he print the menu first, or the finance contract?  The big DSPs have people who study this all day long, on videotape.

The other technique is to design your software to work with more than one process – nonspecific, or “agnostic” in the vernacular.  This is not an excuse to duck process decisions.  On the contrary, you have to choose specific decisions not to make, and then design for various uses.

For example, MenuVantage can read an existing deal from the DMS, or create a fresh one and insert it.  It takes extra programming to support both processes, but it overcomes a likely objection from the dealer.

BMW Dealer Visit

TruckIn my business, you can never spend too much time in the dealership.  I bought a new car over the weekend, and took the opportunity to study their software (they didn’t believe me, that I had invented the InfoBahn).

“Hey, can I sign this waiver electronically?”  No.

“Does this desking system push to ADP?”  Not exactly.

Aeros is a slick little system, certified by BMW two years ago.  I gather they’re in a couple hundred dealerships.  I liked Aeros a lot, but noticed the F&I Manager rekeying between it and ADP.  Just user error, I hope.

The same goes for the menu presentation.  Scratching out the GAP row with a Sharpie is probably not what Maxim intended.

I enjoyed using Zag.  They have a good, web-friendly process, and it gets you close to invoice before the first phone call.  Of course, this cuts into gross – but hey, I drove past the other BMW dealer.  Like many BMW drivers, I will order a car sight-unseen. This makes BMW a prime brand for online selling, and Zag.

The Sad History of Disambiguation

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!”