Once you've got the right people in place for your implementation its time to think about the overall design of all the underlying "stuff" in Performance Analytics. I mention Legos in the title, but it may not truly be the best analogy at first. The underlying "bits" in Performance Analytics require a bit of explanation as justification before we talk about how much of them we need or when to create them.
Every ServiceNow application has an enormous amount of flexibility but it also runs on the same underling structure. We can leverage that structure when we build and implement our analytics solution. This comes into play very clearly with breakdown sources, but we're going to start with indicator sources.
Indicator sources are like a reusable "base class" of data from a ServiceNow table, which can be extended into different forms for different KPIs. Ok, maybe not all that clear, think of it like this: You have one smart phone, but use multiple different apps on it. Your phone would be the indicator source, and it can be re-used for each of the apps, which would be the indicator.
Another example? Ok, you're creating a resume for an exciting new job and you adjust your work experience to apply specifically to this new position. You add and remove different aspects of each bit of work history to efficiently demonstrate how great you are for the job. The actual work experience is the indicator source, and the resulting resume work blurb would be your indicator.
So how many of these do you need? Well, we're all about process improvement. We want to decrease cost and increase customer satisfaction in as many ways and places as we can. Generally, this comes in the form of work we have to do in order to complete or satisfy a task for our customers. (Boy that's a general description for what we all do for a living.) Anyway, this boils down into three different segments:
- Stuff we haven't work on yet, but need to.
- Stuff we are working on, or have been working on.
- Stuff we no longer need to work on.
As such, if you've got more than three indicator sources for each process you're measuring, strongly consider whether you need it. You could mostly likely create an indicator that accomplishes the job instead of having more sources.
Now that we've got these core objects we can tailor to our needs, KPIs can be intuited naturally. Open records not updated in 5 days? Well, that's just "Stuff we are working on" filtered down to updated more than 5 days ago. How about mean time to resolve? "Stuff we no longer need to work on" measured, not on record count, but on record resolution time. These concepts become our indicators.
Of course, indicators can be much more complicated, or much simpler. Determining what the best indicators are is a much longer conversation (much too long for this blog, let alone a single blog). Sure, for each process there are commonly accepted KPIs, but each organization has different things they can control. Establish what aspects of your business you have control over and focus on those KPIs — keeping an eye on the rest. Either way, these KPIs will generally derive from the same sources we identified earlier.
Ultimately, the number of KPIs you have are limited more on effective presentation than they are on maintenance load. Overloading a page with 10+ KPIs tends to diminish the direction of a dashboard, where targeted or purpose built pages will get more done. However, if you still end up with an overwhelming number of indicators for a single process, consider if there are too many cooks in the kitchen.
The big takeaway here is to reuse where you can — naming conventions can help here. Something like:
"[Aggregation] of [Source] [Records] where [Conditions]"
For example:
- Number of open incidents
- Average age of resolved problems
- Number of project tasks not updated in 5 days
We'll talk more about breakdowns soon, because this concept can also reduce the number of indicators you need.
