Again, I have been far removed from the TalkRA world for some time. The reason this time around is quite interesting and I couldn’t wait to post it. The last 7 months had me working with a team on optimizing the approach to Revenue Assurance in terms of “indicating” to the analyst the key areas for improvement. The TMF already has quite a good set of KPIs, but as I’ve mentioned in one of my earlier posts, some of the Telco’s in the APAC region of the world have highly specific areas for monitoring, some of which are far too atomic to apply TMF KPIs to.
The problem that lay before us was to setup a framework and not a point indicator to the leakage. Towards this end, the shining knight said “Tally Ho” and set forth to discover the “Holy Grail” of Revenue Assurance – The Key Performance Vector (KPV). As I’m sure most of you know, a vector has two components – Magnitude AND Direction. What I wanted to do was try and see if the existing set of KPIs could be converted into KPVs. At this point, via the magic of intuition, I can see quite a few eye-brows going up and a few mustaches being twirled at the thought of “Yet another metric?!?! RA loves the metric system more than UK”.
The reason behind the KPV is what I would call a Goal Cascade (GC). The intent of the Goal Cascade is to enable the various sub-sections of the RA team to be aligned with the highest level RA goal of the organization. For example, when a Telco says “0.4% leakage is acceptable to me – anything beyond it calls for discussions with HR”, how does the analyst know the weightage of his/her function to that 0.4%? Furthermore, how should he/she interpret the functional KPI? The KPI definitely does highlight the true state of affairs at that moment, but is it in need of further improvement or should the analyst call his mates and nip down to the local pub for a pat on the back?
The Goal Cascade is an engaged activity where the trickling of the Key Goal to the various sub-sections of the RA team is cohesive – and trended over a period of time. Now comes the kicker. The KPV is not a “In-point-of-time” indicator. The KPV is the second derivative of the KPI magnitude trended over a period of time – its not exactly the second derivative, but that is the closest generalization. The KPV actually involves quite a complex formula taking into account multiple factors. If you hate mathematics as much as I do, you’ve probably fallen asleep at this point. However on waking, the end-result of a KPV is an in-line representation of
KPV = magnitude(from the KPI) +functional performance up/down+alignment percentage to Key Goal
The KPV is not mean’t to replace the KPI. The KPV is an extension of the KPI itself. The KPI builds structure in a vast science (Einstein used to wonder about two things – the boundary of the universe and secondly, the boundary of Revenue Assurance – of course I am joking). KPV come in useful when the RA team requires a synchronized view of KPI aggregation.
I would love to hear your comments on the concept – have I finally gone bonkers, or do you see value in this as well?
Ashwon,
This is a very informative article.
In todays revenue assurance is all about dimensions and measure. I being a product specialist myself havent seen any products which can actually cater to the newly designed concept of KPV’s.
But if incase you are trying to point out the concept of KPV’s as a derivative of a KPI, then I think we may have a newly developed concept.
There needs to be more proactive systems in the telecom space today. What does your thinking have to say , ashwin?
This idea of the KPV is fascinating but I imagine most readers will struggle to understand it. I’m struggling with it myself. Am I correct in thinking the KPV is a measure of the rate of change of the KPI where the rate is measured on a proportionate basis relative to the Key Goal?
It’s funny that I just wrote a sentence that is pretty much as complicated as any sentence you have written in your post. At least I’m confident I know what I mean by it, even if others might be no wiser for reading it ;)
Fascinating.
Perhaps an illustration would make it clear e.g. assume company with revenue of $100 has said 0.4% is acceptable…..take us through the example to the end.
@Luigi – I am definitely of the belief that the proactive side of RA needs to develop significantly. Now RA, due to its very nature makes a truly “proactive” approach significantly difficult. I would be very interested in seeing the evolution of a powerful method to proactively assure. My belief is that KPVs, by its ability to indicate the direction of growth, might be a step towards proactive RA. But it definitely is not a solution – its a step in that direction.
@Eric – You’ve got it in a broad sense. The KPV, in absolutely simple terms, is an up/down indicator (which is derived from past performance) and how that change would positively/negatively impact the organization (derived from the Key Goal Cascading). I know that the concept itself is quite a bit to read and understand immediately (I’ve been working on this for months on end, and it still isn’t completed). Let me see if I can break this down further:
a) Goal Cascade refers to how a high-level goal is broken down into smaller and specific goals for each sub-section of the function (eg. RA Goal is broken into goals for the prepaid team and postpaid team).
b) The Sub-Sectional goals define the outer limit of negative performance, which is continually updated based on KPI tracking.
c) The KPV is created over existing KPI by linking the historical performance trend (its a bit more complex than a simple averaging)
d) The KPV now indicates performance of functional departments in conjunction with the Key Goal
Hi Joe,
This would be a good exercise. Let us assume that said company has visible revenue of 100. We assume this is the revenue at risk.
They have said that 0.4% leakage is the threshold. This translates to 0.4% of 100 = 0.4 units
Now lets assume the said company has only 2 divisions, for the sake of simplicity. These would be the Prepaid division and the Postpaid division. The stake of these divisions are divided as
Prepaid – 85%
Postpaid – 15%
How do we derive the stake? Well, its a mix of the subscriber base split, the billed records/MOU, product spread across these headings. Back to the scenario.
Now the Prepaid Threshold is 0.4*85% = 0.34
Postpaid Threshold is 0.4*15% = 0.06
The above is a very simplistic representation of a goal cascade. It goes down further into the individual KPIs, eg.
In Prepaid, 0.34 = Subscriber Misalignment (SM) KPI (assume it constitutes 15%) + Records Lost (RL) KPI (assume it constitutes 85%)
This means SM = 0.051 (15% of 0.34)
RL = 0.289 (85% of 0.34)
Now the highest thresholds for each region are defined in the KPI. Moving forward, giving an example of the KPV is extremely difficult, but 2 weeks down the line, a KPV reading for RL might read like this
RL-KPV = 0.141m (representing the magnitude) || <> (assuming performance has improved over the last week) || 49% under Recommended threshold
Joe – Does this example help?
Ashwin,
Many thanks for the example. This certainly does make things clearer.
Hi Ashwin,
I’m working off your example as the basis for how your KPV works. I think there is value in there but I have a few comments (which may just be that I don’t fully understand it yet).
Perhaps an issue is that this assumes you have a complete and current understanding of all the potential leakage that may exist and where it is at, at any point in time, so you can measure this performance relative to the KPI (and so roll this up as well). I’m not sure if this is the case for all telcos and certainly requires one big, RA system (essentially and almost a parallel environment to the production environment it is monitoring).
The thought process behind this though is very interesting (especially the RL/SM split). In past lives, I have modeled the revenues of a product line against three broad areas of leakage (rating/billing calculation, usage reconciliation & provisioning misalignment) and the estimated leakage on that product based on industry provided benchmarks and some assumptions about our processes and system controls. We then aligned that data against the amount of testing we had done (coverage, for lack of a better word) and the results (i.e leakage found) from that testing.
This enabled us to have a model that provided some science to the following numbers: % of revenue tested by RA, % of leakage on tested revenue and more critically for designing our work program the estimated % of leakage remaining in each product line that had yet to be identified. This allowed us to prioritise our work and also explain the rationale for choosing one area over another.
Hi Mike,
I find the last bit very interesting (“% of revenue tested by RA”). Did you develop a framework that allows you to build controls based on this? Also, how did you actually measure % of revenue tested by RA?
To answer the question that you have raised, or rather the issue – we do not need to have a complete understanding of all the leakages. We only need to have an organizational goal, and then we will split the Key Goal into Sub-goals based on a generic classification. As we move forward, we will be able to further split the sub-goal into more relevant constituent areas.