We get this question all the time. Almost every time we deploy Visual KPI (which we do over the web in about 90 minutes in most cases) we spend about an hour deploying the software, but at least 30 minutes or more on discussing “what” the user wants to track, “what to call it,” and “how to organize it” (their data hierarchy).
First, there are many types of KPIs and multiple definitions but for our purposes at Transpara a KPI is:
- Anything you care enough to track (especially while you aren’t at your desk)
- Operational in nature (the “P” is for performance, so slow-moving or future planning data is usually out)
- Changes often (otherwise, why would you need it on your phone?)
- Often requires alerting when things go wrong (it’s important, right?)
- Has some form of context associated with it (is it doing well or not?)
For this post we will focus on the last bullet above and touch a bit on the others as well. Context is everything with mobile applications and even more so with decision support information like KPIs and alerts. So let’s dive into the various ways you can turn an average KPI into something great…
- KPI name: Might sound less-than-critical, but naming can really make or break a mobile KPI. Why? First, it needs to be short – on a mobile device, you don’t want the name taking up the whole screen (e.g. “how much fuel is being consumed”=bad; “Fuel Usage”=good). It will also show up on multiple devices, in different views and in multiple places so short always wins. Second, it must be obvious. Mobile data should be and will be shared so make sure others will understand what your metric means.
- Actual value: This is the heart of any great mobile KPI (or any KPI for that matter). Getting it right means getting it from the original data source (no middle-men if you can help it) and that it is as current as possible (most of our customers strive for near-real-time). In Visual KPI, it is the only required field besides the name.
- Targets & Limits: Let’s face it, a KPI is only a KPI if you can compare it with some expected behavior. Something you want to achieve (a target) and various states away from it (limits) that will put your data in context. These may come from internal or external sources of authority. Oh, and edit and test your targets and limits constantly (this is where the Visual KPI Designer’s preview mode really comes in handy for rapid prototyping). Most importantly, make sure your KPI limits and targets match the way people are actually measured and rewarded or they might end up being useless. (I’ll write more about choosing your KPIs in another post.)
- Data sources: Data can come from many sources, even at the same time, but the key word is “source.” The most important thing about operational KPIs is getting at the most reliable, timely and accurate data. People will be making decisions based on this, so be careful of intermediate or redundant data sources. Also remember that constant values and other manually entered data can be important (especially for targets and limits, not very exciting for an actual value).
- Responsible Party: KPIs are there to make sure the right people know when something has gone wrong (or particularly right). Because of the decision-making nature of a mobile KPI, you may want to alert the responsible party (ideal) or at a minimum let whoever is looking at know who they should notify if something deviates from the expected.
- Alerts: Similar to the responsible party (above), but there are two other things that can make or break a good alerting system – timing and volume – and they are related. First, a great KPI will only alert someone if the situation is real, meaning that the data really went to a new state. While each situation is different, this often means setting a “time-in-state” value so that a temporary blip doesn’t trigger an alert if it wasn’t needed. For example, several of our customers set alerts so they only happen if a KPI stays in the new state for over 5 minutes (again, depends on how active your data is). Second, volume. Simply put, it means to choose your alerts wisely or you will have alarm bells going off all over and a full inbox. Only alert on a subset of your KPIs and only when needed. Crying wolf isn’t the best strategy with operational situations.
- Hierarchy (how KPIs relate to each other): This is a large enough topic to warrant another post, but let me just say quickly that you need to define your hierarchy and naming convention with enough context to make sure things show up in the right places. A good mobile monitoring and BI application with be flexible enough to let you view things from different angles so getting the hierarchy and naming right can be key to keeping your house in order.
As with most of our posts we could talk for hours on the subject and bore you to tears (if we haven’t already). Either way, this stuff is important if you want to get the most out of your tools and your people. If you have questions, give us a call and we’ll happily geek out with you on any related (or sometimes unrelated) topic.
Download our free guide to getting mobile operations monitoring and BI right and avoiding the most common mistakes.
Like what you read?