The Expanding Dealer Automation Space

In my earlier article on Cox Automotive, I wrote that the subsidiaries tile our “function space.”  By this, I usually mean the F&I function space, although Cox is broader than that.  In today’s post, I will explain about function spaces and why this idea is important for software strategy.

Let’s say that you have been asked to identify all the functions performed in the F&I office, and then find software to automate them.  I did exactly this for AutoNation, back when PVR was $600.  The first thing you discover is that a simple list won’t do.  You at least have to put the functions into workflow sequence.

Tasks in sequence are a one-dimensional function space: a timeline.  This will help you to define where the credit process ends, for example, and menu selling begins.  Ah, there’s the rub.  Maybe the workflow branches out, and now it occupies two dimensions.

As I wrote in F&I Magazine, the workflow that produces a finance contract is a lot like the workflow that produces a VSA.  If you can picture the “F” workflow as parallel to the “I” workflow, this is much more useful than a simple timeline.

Function Space

Typically, when you see a diagram like this, it is already partitioned into the familiar systems: CRM, Desking, etc.  That’s the definition of “thinking inside the box.”  If you were designing an integrated system, you would want to start with the unpartitioned space.  That’s the only way to properly scope and organize your web services.

In fact, it may give you some new insights about how to pass data and control among the functions.  Should a desking system pull VSA rates?  Should the menu run OFAC?  Can you instantiate a “deal object” somewhere, and pass it by reference?

Last summer, I wrote about mapping dealer-system functions onto the consumer space.  So, that’s a third dimension based on who the user is, plus a strategic imperative that the online experience must dovetail with the dealership experience.


What we see with Cox Automotive is an expansion of the domain covered by a single vendor.  The space dominated by the old CDK-Reynolds duopoly is a subset of this one (I will illustrate this in a later post, using a function point inventory).  The overarching function space was always there, of course, but it was filled with disconnected niche vendors.

In practical terms, this means that an increasing share of the dealer’s software budget will flow to integrated vendors outside the duopoly domain.  Since this is a strategy post, I will close with a Go metaphor.  Reynolds and CDK have been playing the game on a quarter board, and now Cox has highlighted their absence from the other 280 points.

Brockman Cracks Down on Interfaces

At lunch today, a colleague asked me what Reynolds’ strategy might be, with regard to shutting down DMS integration.  We have both worked on “unsanctioned” interfaces previously, and he wondered if dealer backlash might yet force Reynolds to change course.

They offer “certified” alternatives, which generally do not meet the commercial or technical needs of the ancillary systems. 

Most readers of this blog already know the story.  Dealers depend on their DMS, but they also need several other systems.  These ancillary systems share data with the DMS using a variety of techniques, none deemed safe or reliable by the DMS vendors.

For as long as I can remember, the vendors (ADP as well as Reynolds) have threatened to shut down these rogue interfaces.  They offer “certified” alternatives, which generally do not meet the commercial or technical needs of the ancillary systems.  With no DMS interface, the ancillary systems perform poorly.  The dealers suffer, and then defect to another DMS.

So, my friend wondered, will Reynolds continue shutting down DMS interfaces even if it means alienating scores of dealers?  Is the new CEO, Bob Brockman, really so adamant?  Well, I said, Mr. Brockman is known to prefer high margins rather than market share.

I observed that, under Brockman, Reynolds has ramped up its software development capacity.  He must recognize that every ancillary system represents a weakness in Reynolds’ product line, and every interface enables a competitor.

In Brockman’s position, I would first redouble my efforts to compete across the product line, and then I would cripple my competition by shutting down their DMS interfaces.  When dealers complained about losing their favorite, say, desking system, I could then offer an integrated product suite – without those nasty security issues.

This strategy is exactly how Microsoft parlayed the dominance of Windows™ into dominance for its Office™ suite.

Provider Network Expands

PEN-LogoI recently attended the F&I Conference in Orlando, where I spoke with leaders of Open Dealer Exchange (ODE), ADP and Reynolds’ joint venture for credit aggregation.  ODE will use the Provider Exchange Network (PEN), which I originally developed for MenuVantage.  They are still running the network in good earnest.  Route One is also a PEN user, so maybe there is room for “co-opetition” between the two aggregators.

Reynolds Certified Interface

About a year ago, I advised GMAC Insurance to develop a service-oriented (SOA) front end, so that DSPs could integrate with them – instead of a DMS extraction approach.  This turns out to have been the right call, now that Reynolds has shut down DMS extraction.  No one I spoke to at the conference has a good solution to the new security measures.

Contact me if you need help developing a sanctioned interface.  I have a thorough understanding of the requirements, having been briefed in Dayton by Reynolds developers.