KPIs get defined at the end of the fiscal year. But they can often only be measured 6 months later. Navigating blind for half the fiscal year is not the best option. Fortunately it is not our only option.
When do we come-up with new Key Performance Indicators (KPI's), or: when is it that we look for new ways to follow-up and measure new aspects of Business Outcome?
To answer this question, we need to ask another: when does it make sense to change the way we measure Business outcome?
Here are some common reasons:
- because of change in strategy
- because of change in management
- because of change in business
- because of change ...
No matter what the reason, normally tied into some form of change, and new KPI's tend to pop up by the end of the year.
Yes, we may decide on a new ways to work, new strategy, or new line of Business any time of the year, but invariably, new KPI's will come end of year.
Often, thinking about new KPI's is combined with drafting budget. In order to be effective, new KPI's will be tied in to a compensation, bonus or commission system. They will serve to keep track of individual, business unit and overall performance. As a result people's performance, salaries (and happiness) may come to depend on them. The link to the budget is clear, and tight.
As KPI's and compensation are being coupled, feedback will need to come merely a few days/weeks after they have been agreed upon.
- When do we want to be able to adapt activities of the Business Unit, in line with the overall desire of senior management?
- When do we want to be able to get feedback on these new KPI anchor points?
- When do we, as individual contributors to the overall cause, want to know if we are contributing?
As quickly as possible of course.
Data Reality - time to market
This is where we can get confronted with Data Reality. It can take the BI team 6 months or longer until they collect and connect data sets relevant to the KPI's. ERP tables, Supply chain data, CRM, Customer Satisfaction Survey results, Net Promoter scores, Marketing Automation Data coming from websites will be copied into a separate Database, the Data Warehouse.
The reason why the BI team nurtures a Data Warehouse, is because it allows them to connect multiple data sources, handle security and control data flow. A Data Warehouse allows you to track historical changes, and provide superior data quality. As many aspects get hand-coded, it tends to take a lot of time to alter and add in this setup. The implication of the 6 month delay, is that we may be navigating blind for the better part of that fiscal year.
By the time the BI team has figured how to connect results to data to KPI to salary and to happiness, we may find ourselves to be late in the fiscal. Maybe even too late to correct our actions.
Invariably, we will find that some of these new (now 6 month old) KPI's are hard to measure, or not able to really tie into results. We could, at this point, try and come up with new and better KPI's at this point, but that would likely take the rest of the fiscal year to implement.
Basically, this annual cycle of measuring and tuning forces us to work blind and risk steering the whole of the organisation in the wrong direction for the better part of the trajectory.
Data Oligarchy - power to the Excel savvy?
There must be a better way to approach this.
What often occurs, is that Business Units come up with their own KPI measurements. Frustrated by the delay, Excel-sharp Business user build small systems which help them provide ad-hoc statistics and support for the new KPI's.
This sure beats navigating blind for half the fiscal year. Unfortunately, this will likely not happen in all Business Units. Systems, tailored to the individual, will not be able to cater to other people in the organisation.
The Savvy Excel people become the prime bottlenecks. Over time this may yield nasty side-effects, such as the rise of the Data-Oligarchy: business Units with stronger in-team data minds gain in power. This competition could in fact work against us, and against overall interest.
Data Discovery & KPI specific measurement systems
Another approach is to try and implement a KPI-specific metric system, across the organization. Tool vendors like QlikView, Tableau or the newer versions of Microsoft Excel offer a Data Discovery approach to the KPI problem. Offering strong graphical options and ease of use, and selling these directly to business users, they manage to get budgets allocated. Promoting a "we-go-straight-to-data" attitude, is in disfavour of anything as slow as a traditional Data Warehouse.
As the approach is KPI-specific, rolling out multiple divisions would not pose a problem. After investing in specific tooling and training, getting the initial Dashboards rolled out to the Business tends to go fast. In this scenario, you could be up and running with some outside help and within one or two months.
As KPI-specific systems are intended for cross-departmental usage, wide acceptance is almost guaranteed. The data oligarchy threat from the previous example tends to be less prevalent.
Main problem with this approach is none of these tools are well equipped to handle the over-time change. The way the system is set up is to accommodate a specific set of KPI's. When something changes after the initial project, change of source data structure, another change of KPI's, change of end-user requirements, we may find ourselves having a rough time following through. As a result, time to market may explode.
We know that change will occur and accumulate over time. Creating new systems, every time the Business changes and we need to come up with new KPI's, creates KPI-islands.
Which, over time, will end up contra-producing each other. For this reason, KPI specific system will likely fail soon after initial roll-out.
Data Projects or Data Process?
The problem with all approaches is they handle the matter as a Data or KPI project:
you come up with KPI's, you create something to measure them.
Of course we know that new KPI's come often en regularly. Of course we know that other change will affect the existing KPI's and reports. But most of the change is somewhat predictable by nature. Hence, KPI's should not be matched up to data in the form of a Data as a project. We'd be better off consider a Data Process instead:
We need to be able to incorporate new KPI's as soon as management agrees to roll out, at the same time we need to accomodate specific needs of Business Units and Users & provide a good overall picture. So we need a Data Warehouse.
Data Warehouse Automation
Make no mistake, you need a Data Warehouse.
A common language Analysis model is by far the best proven way of consistently measuring Business outcome. Feel free to investigate the research carried out by TDWI, GigaOm or BARC on this matter.
But we need one which is capable of better handling the over time change. We need to be able to cut back response time from months to weeks or even days.
We may also need Data Discovery capabilities. We may even want to make use of some of the modern and mobile new Data Discovery tools out there. But at the same time we need to ensure that people are playing around with correct, quality data. What we need, is a form of governed data discovery.
The need to work with new KPI's is a given - a side-effect of our need to change the way we do business and adapt to new business realities.
Our capability to automate the process will be key to success.
Data Warehouse Automation will likely be our best approach.