Many client project workplans I intersect have the line item "Determine KPIs". Without further context to frame this work, folks typically end up with something that:
- is (too) narrow, functionally
- is impermanent -- KPI reporting and analysis lasts only as long as the effort itself is sustained
- is disconnected from / uncoordinated with other, interdependent parts of the business
Now, consider the view from the analytic teams supporting efforts like these. When multiple such requests come in, it's left to these teams to prioritize them, and reconcile them semantically and logistically. This is hard.
To deal with these challenges, many BI (Business Intelligence) tool vendors provide pre-built "business models" that suggest a set of KPIs based on a more fundamental concept of the operations they reflect. These can be useful, but they're not free, and it's a lot of work to retro-fit them to your business. This is expensive.
Whether you use a vendor model as a point of departure, or roll your own, I've found it useful to have a basic "Caveman BI Model" that serves three purposes:
- it provides a common language to the folks involved in the KPI development effort
- it provides a broader context on how KPIs fit into the business, so folks don't lose the forest for the leaves
- it starts simple, so your team can work its way up to the complexity you need, rather than trimming back from the complexity it's given by a pre-existing model
The Caveman BI Model starts with a plain-English, noun-verb description of what the business does that needs to be understood better:
"We use resources to create products that we sell to customers with content through channels."
Generic and esoteric maybe, but in one sentence we've described the entities of the business that we need to understand better:
"We use resources to create products that we sell to customers with content through channels."
Put another way, this one sentence describes "things I need to know about to run the business".
Next, we use metrics to describe how (well) we're managing the entities. Metrics have the following progression of development:
- a raw count: "we have n customers"
- a synthetic measure, commonly a quotient, produced from more than one count: "$x in sales for #y in customers"
- an index that allows us to compare a raw count or a quotient longitudinally (against past performance), cross-sectionally (say, against competitors or industry averages), or as a variance vs. a budget / plan / forecast
Now, each of these entities has dimensions that allow us to "slice" metrics by to dig into the business a bit. For example:
- resources would include capital, people, raw materials, and fixed assets, each of which might have their own characteristics (equity vs. debt; hourly vs. salaried; source; etc.)
- products could be characterized according to needs served (say, a disease condition for a pharmaceutical), or an underlying technology or legal framework that makes it possible (say, "Forty-Act" in the mutual fund business)
- customers can have a number of properties that allow us to segment them usefully; these might include wealth, how big their relationship with us is, geography, gender, age, etc.
- content would include "campaigns" that use different marketing assets, themes, or promotions
- channels covers distinctions like "direct sales" vs. "distributors", or "TV" vs. "digital"
(Oversimplifying: Ralph Kimball's BI bible, The Data Warehouse Toolkit, calls metrics "facts" and suggests constructs called "fact tables" and "dimension tables" that relate facts and dimensions to each other. Put another way, what are the different dimensions that we have to slice each fact by in order to understand the business? "Sales to customers by product and customer geography" would be an example of an intersection we might want to know about.)
These dimensions in turn have hierarchies. Geography, for example, has "city, state, country". Some hierarchies are helpfully scalar: second-minute-hour-day, for example. But, hierarchies are often a big problem because they don't reconcile neatly. For example, weeks don't divide neatly into months; some industry data may be sourced from places that use different hierarchies, making apples to apples comparisons hard.
That's pretty much it. Summing up:
- what do we want to know about? entities
- how do we want to measure it? metrics
- how do we need to slice this measurement? dimensions
- how do we roll up / roll down these slices? hierarchies
So how do we define and distinguish KPIs from the myriad metrics we could choose? One rule of thumb I've applied is to choose metrics that start and end a process. For example, "qualified leads" are an output of a marketing process that become an input to a sales process. A transaction is then the end of the sales process. Each of these could be a KPI; a "synthetic" KPI might compare leads to sales as a "conversion rate".
If you're charged with coming up with KPIs and then provisioning them for decision-makers (who may include you too!), I'd suggest you start by asking someone to explain what the "Caveman BI Model" is for your business, using this framework as your interview guide. If you find that such a model has not been expressed per se, or doesn't exist, take a pass through creating one, maybe by trying to tie some of the key numbers you see used a lot back into the framework.
Again, the purpose of this post isn't to be the last word in Business Modeling, but rather to share a basic approach you can carry around in your head -- and in common across your heads -- that's been useful to me in the past. Please let me know what you think!
