Month: April 2016

Life (Credit Life) without Recursion

I was chatting with Tim Gill the other day about auto finance math, and the topic of recursion came up.   Tim is one of the few vendors in this space with his own “calculations engine.”  Otherwise, there are not many people who will talk to me about esoteric math problems.  That’s why I write a blog.

People commonly describe Credit Life as a recursive calculation or, more properly, an iterative one.  This is because the premium must cover the amount financed, and the premium is itself financed.  So, if we write the premium as CLP, a function of the amount financed, A, then:

Fig1This is generally how people solve it.  They run a few iterations, and CLP converges quickly.  This is a preference, however, not a requirement.  Assuming that the premium calculation is distributive over addition, which it is, we can just as easily set the problem up as:

Fig2… which can be solved analytically.  This approach will work for most of your popular recursive calculations, like GAP insurance.  For an example, let’s take a typical “cost per thousand” insurance calculation, where f works out to ten percent.  You could go the infinite series route, which looks like this:

Fig3

Or, you could simply work the algebra problem:

Fig4Now, I know what you’re thinking.  You’re thinking that credit life calculations are far too complicated for this approach.  You may also be thinking that the premium is based on the monthly payment, M, not A.  In fact, these complaints are related.  The payment is directly related to the amount financed, through the PV annuity factor, which combines the term and the APR into this handy relation:

Fig5

So, when you see a payment formula like this one:

Fig6The insurance carrier is actually helping you, by combining the calculations for premium and monthly payment.  By the way, the last time I checked, C# did not have the payment and related methods from VB and Excel.  You are much better off coding your own PV annuity factor, and using it as described here.

Now, if you are designing a calculations engine, you may still prefer to use iteration, for the same reason that you may not want to algebraically reverse all your tax and fee calculations.  It is better, though, to use your algebra and know your options, than to rely blindly on iteration.

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.

Pillars

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.

Maturity Model for Software Startups

Software companies begin life at CMM Level One, and some of them die there. You may not be familiar with the Capability Maturity Model, but you will always remember your time at Level One. This is where the developers code all night because you need that next feature, to keep paying the rent. This is where you release new code and then spend all day patching it, in production.

How many users do you suppose we’ll drop, if we reboot it right now?

On the other hand, it is possible to have too much process control. I was at a Level Four company once where we had to three-bid a project to plan and initiate a second project that would develop the software. The chart below, from Ron Patton’s book, shows the levels as stair steps.

The model contemplates an otherwise stable company that has weak processes only for software. In a startup, all processes are weak and resources are limited. To be successful, processes must mature in step with revenue. In this article, I’ll illustrate holistic process maturity with some examples.

At Level One, you have limited HR capability, and therefore no diversity training or compliance. You have no benefits, no vacation policy, no travel policy, and no expense audits. Your exposure to liability is huge, for everything from “constructive termination” to respondeat superior.

The reason for Brad’s separation from the company is a private matter which I am not at liberty to discuss.

I looked into this, and found that there is indeed a maturity model for HR. The first step, in my experience, is to crib an employee manual and make everyone sign that they have read it. At least then you can disclaim any actions that go against the boilerplate in the manual. You might also invest in an employment law poster.

At Level One, you also have no marketing function. The sales people roll their own presentation materials, talk tracks, and brand message. The first step is to hire a dedicated “marketing person,” to do sales support and organize your booth at NADA. Actual marketing comes later.

Entrepreneurs are good at tracking their sales and market share. People I work with look forward to their first thousand dealers, a public dealer group, or a big agency. Celebrate each milestone by notching up your process maturity.

I would say that you should be out of Level One (for software) after eighteen months. If you are already taking distributions, while the business depends on “heroes and luck,” then you are gambling. Raise some capital, hire a good manager, and get it fixed. My earlier article, Sales-Driven Development, describes what I feel is a reasonable level of process maturity for a young software company.

Baby Steps

I will close this post with a few pointers for leaving Level One. Basic stuff. Most readers should be able to skip this list.

  • Create a maintenance window and stick to it. Only move code to production at 6:00 AM on Wednesday. If anything goes wrong, people are in the office. It’s also not Saturday, our peak volume day. If you are constantly having “emergencies” that can’t wait until Wednesday, you need to look at that.
  • Implement a code control system with a rollback capability. If the latest build has a problem, at 6:10 AM on Wednesday, you do not start debugging. You push the rollback button.
  • Set up a reliable QA environment, and sync it with the production database. I don’t know how many times I have heard that the build worked in QA but some new data was encountered in production, and it crashed the site.
  • Create a division of labor, such that the developers stop fussing with the servers. Developers love to fuss with  infrastructure, which is not their skill set.  At all.  Hire a professional, or rent one from your cloud service provider.
  • Implement a work order tracking system. Planning at Level One is a “pushdown stack,” which means that yesterday’s panic is still simmering when it is superseded by today’s panic. Start by writing commitment dates on a bulletin board, so that everyone has visibility into the backlog.