Progressive KPIs

Now here’s a question. Can RA practices be standardized (or bottled) into a one-size-fits-all solution?

What do I mean by the above statement? Should it be imperative that every issue/leakage raised by the analysis of underlying data yield a “bigger-picture” analysis, or should each issue raised be closed on a case-by-case basis. It is still a fairly common practice to reconcile data on atomic levels (xdr levels) by performing transferance checks through all the downstream systems. In effect, we could say that we are going to re-validate the expected business process defined for a particular product. However, is the effort and time that we would need to put into this exercise worth it? I am not of the opinion that we do not need to validate transferance, but do we need to be matching each and every xdr and check for its presence in the downstream systems? The number of analysts required to crunch the outputs of such large data correlation check and the time that would be going into it would not be, in my opinion, a correct and efficient use of the resources at your disposal.

If we go by the KPIs defined in “GB941-A_KPI_Metrics_Wookbook” (from TMF), we could see a fairly good set of indicators for monitoring the overall health of a system. However it is my opinion that it has been formulated from the viewpoint of an operator with a good level of maturity in RA, with emphasis on a process-driven methodology. Would this approach be accepted by every operator who wants to setup a RA department? In my personal opinion, I do not think they would. Over a period of time, once the intial steps have been taken, then perhaps the operator would gravitate towards a more standardized approach, but in the initial few months everyone runs around trying to justify the RA function. This is essentially a period of “controlled chaos” where we are looking for all the quick-win scenarios. Unfortunately, the emphasis is only on discovery and not recording the methodology for ascertaining best processes towards progressive maturity. Even though this is a period of individual heroics, it could lead to the development of a viable process by various learnings that one gains.

I was thinking along the lines of a set of KPIs at each stage of the maturity progression, with emphasis on capturing key learnings at each stage. Any thoughts on this?

Ashwin Menon
Ashwin Menon
Ashwin Menon is the Head of Product at Subex. He has also been a consultant and he began his foray into revenue assurance as an implementation on-site engineer.

3 Comments on "Progressive KPIs"

  1. Avatar dakmatt | 1 Nov 2008 at 7:54 am |

    Hi,

    I think the next questions will be what are the length of period that we are looking for? This has to be done with the vision of RA as long term KPI and progressive KPI as a short term target.

    Another thought is how do we present the progressive KPI to management? The management team would preferable to see how does this progressive KPI benefit to them in the end. What I could think about is to map the progressive KPI to achieve being a proactive RA and also use RA as a monitoring tools to assess risk.

    dakmatt,

  2. Hi Dakmatt,

    “What I could think about is to map the progressive KPI to achieve being a proactive RA and also use RA as a monitoring tools to assess risk.”

    Interesting thought, but I need to understand better. Why should the progressive KPI be proactive only? I completely agree with you regarding using RA as a monitoring tool to assess risk, but I find it not really feasible to setup proactive RA KPIs initially.

    Please keep in mind that this is merely my opinion, but in the initial few stages of setting up KPIs to gauge overall RA performance, I find that most departments gravitate towards reactive checks. This is essentially done so that there is an overall understanding of the business flows within each stream. Once the understanding of “expected” flow has reached a certain stage, thats when I see more proactive steps coming in.

    But, I would like to understand your perspective on the same and why you think that the KPIs need to be mapped towards a future proactive approach? I can see the inherent benefit of such an approach, but if we consider the typical greenfield operator (or an operator with a new RA team), I think that it would be a bit difficult for them to envision such KPIs intially.

  3. Hi,

    I would also say from experience that operators tend to go for the reactive completeness checks first. This is done in functional areas where there is a burning platform to engage and resolve. What is the implication of a generic set of KPI’s at each maturity level for operators with limited resources? Would I adopt a set of KPI’s at level 1 maturity which brands me as “level 1 mature” but which does not plug my immediate known leakage?

    This is a hypothetical question. I want to think that the various KPI lists out there should be fairly representative of the common leakage points. What would the approach be to divide these lists into 5 maturity stages?

    On Dakmatt’s proactive checks point, these can be brought in earlier if there are staff members (in team and execs) who understand the RA maturity matrix and can see the vision. I believe the RA profession is not maturing as fast as it could because those in position to enable its growth do not see or understand the vision. The Maturity matrix (GB941b) describes 5 aspects of maturity which must be incorporated into the design of progressive RA KPI’s. Factors in the organisation, people, tool, process and the team’s influence in the organisation are very important when adopting a set of KPIs.

    I remember in my last role we had a list of KPI’s, half of which I would term level 1 maturity but which we could not implement because we did not have automated tools in place or people with enough technical savvy to do SQL’s or advance Excel. Process maps were not in place and the majority of the staff were admin/accounting type people who did not have telco network knowledge. Yet, we were able to implement process changes befitting of pro-active controls where these did not require tool or technical knowledge.

    Just to add some complexity to your envisaged solution :)

    G

Comments are closed.