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?

It’s been a while since my last post, and the reason is that I’ve been quite busy recently with some interesting developments in Revenue Assurance. I have started to notice a significant shift in the operator’s attitude to leakage detection and correction.

There used to be a time (long, long ago in a Galaxy far, far away…) when the most important item for most RA teams were a set of crisp and clean dashboards  that tell them “Hey Mr. RA Analyst, I’m working on dimensions and measures which have told me that you have 0.3511% leakage in product SuperSaver199 between the mediation and billing”. This used to suffice the needs of the RA analyst and he goes forth armed with “0.3511%”, “SuperSaver199″ and “Mediation vs Billing”, and reports the same to his network team. Naturally, Mr. Network Guy wants a sample set of records so that his team can go about plugging the leakage. Unfortunately, Mr. RA Analyst works with dimensions, measures and dashboards only…so he sets forth on another activity (a search for the Leakage Grail) where he tries to pull out the raw data from the network records that corrobrate his claim. While he proceeds on his quest for data, the leakage continues unabated. Furthermore, his view is a bit myopic as the leakage might have been analyzed from a data transfer angle, but might not have been investigated from a “Impact to customer” angle.

What I was trying to illustrate in the true fictional anecdote above is the need for RAW DATA and established workflows. I am a great believer in getting down to the raw data and validating the actual data flows between interworking systems and validating against expected business process flow. Recently, I have been interacting with operators who share the same view about working with raw data, as opposed to running a RA department based on pretty dashboards and metrics from datawarehouses.

There is a visible paradigm shift in the way that operators are setting up RA processes in the Asia Pacific side of the world. The business process of leakage reporting has matured significantly, where every issue needs to be reported with the associated “Proof From Network”, which usually constitutes the discrepant/mismatched records. The network and IT teams even tell the RA team what particular fields they expect in the report for their cross-verification. I have published a post earlier where I discuss the importance of leakage reporting AND tracking. We are now seeing cross-functional teams which have been tasked with ensuring that issues raised are being closed in a timely manner. When I say cross-functional I’m talking about workflows that involve first level of investigation by the RA team, impact analysis by a finance function, technical cross-verification by IT, corrective action by a network task force and rectification corrobration by RA and IT. I like the approach primarily because there is a shift in the way RA is now viewed as more than just a “Finger-Pointer”.

The emphasis on being able to “drill down” to the raw data is something critical to the success of a RA function, because here we are questioning the fundamentals of the underlying data, its behaviour in various complex network systems, the impact from a technical/financial/customer/service angle and so on. The natural evolution of an multi-impact view of leakage analysis is growth from a mere System healthcheck validation to something like Customer Centric Revenue Assurance. I read an interesting article recently about the audit process at Verizon. The RA team at Verizon has been been working on some interesting approaches to RA, and in the below link Kathy Romano of Verizon (Head of the RA function) talks about the importance of solid workflows and questioning the underlying data.

http://www.technology-research.com/experts/romano1.php

I was recently going through the recent posts, and one thing I’ve noticed is that we seem to be a bit partial in only addressing issues faced by established operators. Now, I want to initiate a discussion which focuses on Greenfield operators.

Assuming that we had an opportunity to help a new operator (Greenfield Operator) build a RA and FMS practice, what would we inculcate into the “DNA” of the operator from Day 1? The experiment is directly focused on checking the impact of “Early in the Day” enabling of RA and FMS, and to what extent the move would help the operator save on large leakage issues later on. In my opinion, the critical step for the Operator would be to design & decide the RA and FMS framework. The framework should be encompassing all aspects of reporting, tracking, evolution path and integration.My point of view regarding a RA & FMS practice from day 1 would be :

a) Planned integration of new network elements with RA as a test-bed for system accuracy
b) Existing fraudsters who have been active/ejected in other networks would find a Greenfield operator to be a “Soft” target
c) Building up of effective usage patterns for identification of Fraudsters via deviant usage tracking
d) Proactive verification of subscription data flow and sub-systems
e) Ensuring a “leak-proof” work-flow to handle all issues including rectification tracking

Of course, there are many more reasons for a new operator to take advantage of a full-fledged RA and FMS operation. While keeping in mind that Fraud and Revenue Assurance might not be a key component of a new operator’s roll-out strategy, it is also important to keep in mind that prevention is definitely better than cure.

It is absolutely clear to me that having a strong RA and FMS framework in place from Day 1 would definitely help an operator in both the short term as well as the long term. The progressive growth of the network will help the analysts to have a clear understanding of concern areas, as well as building a considerable in-house knowledge base. As a direct result of forward-planning, the in-house teams would also have to implement fairly strong work-flows. Simple errors, like business document version errors, could be foreseen and nipped at the bud.

I could go on and on, but I would be more interested in getting your views on the subject. Specifically, I’m wondering if anyone sees a reason for why a greenfield operator would NOT want to have a RA and FMS framework in place on Day 1.

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?

Been away for a while now, but on the way back, I got something which has become very, very clear. The way RA is currently being viewed by most Telco’s tends to give me the impression that RA is well on its way to being silo-ized.

Having siloed systems with no interaction/feedback moving through the value chain is one of the reasons for revenue leakages in the first place. Like for example, the switching team introduces a patch that causes a difference in the normal product stamping in the downstream systems. However, the news of this patch being applied is suppressed (perhaps because it might be a quick-fix for an earlier issue that was not highlighted). As a result, as the mediation teams have not got any updates, the incorrectly stamped XDRs are summarily being rejected.

Imagine a scenario where a RA department doesnt disseminate findings immediately, but instead wait for a weekly review or they mail a department of a finding, but due to an ineffective work-flow management, the issue is suppressed. Suddenly the switch and mediation teams are face to face with issues which could have effectively been culled at a grass-root level, but because of linear propagation, the patch has been transferred to other elements, which has effectively bloated up a minor issue.

Though this isnt in the truest sense a silo-izing of the RA department, it becomes critical for operators to not only have a good RA methodology or a good team, but it also becomes important to implement a solid, leak-proof work-flow and processes which govern the entire life cycle of a discrepancy, by which I mean,

Detection -> Investigation ->  Root Cause Identification -> Qualification -> Quantification -> Resolution

As someone in charge, I should be able to track, at least at a high level, the status of a particular issue with respect to the above flow.

I’ve heard a little story about Japanese fishermen throwing small sharks into fish tanks, so that the fish are kept in a constant state of activity, and when they reach shore, the fish would be suprisingly fresh. The point I’m trying to make is that for true RA coverage, it isnt enough to simply identify issues but it is also critical to be able to track it to closure. If the fish represent the discrepancies that were discovered, the shark would allude to vigilance on the part of telcos in being able to track progress/resolution. Else, all we get are rotten fish, a.k.a. lost findings.

Here’s a new thought. What exactly would we term (correctly) as proactive Revenue Assurance? I have seen quite a few scenarios where an operator claims that he has a proactive check system in place, but on further analysis, we find that it isn’t truly proactive, but merely reactive with a much smaller time period of detection and rectification.

It got me thinking about the nature of revenue leakage. When we take a step back and look at the big picture, we see that a leakage happens due to unforeseen eventualities, misconfigurations/omissions, poor system integrations or maybe even internal fraud. In none of the above cases (which are but a few of the reasons for revenue leakage) can we truly say that we are capturing all leakages. How would we go about proactively checking for integrity/completeness?

In my experience, I find that to a certain level, we can perform proactive checks as far as subscription data is concerned. Standard checks like Subscriber feature information matching between HLR, Provisioning and Billing etc. would in some ways prevent revenue leakages proactively(if the Subscription Data integrity is maintained, we find that many common scenarios which would come in usage data also reduce). Issues in usage data like usage not being billed can be attributed to unsynchronized subscription information across the Provisioning system and Billing system. I have seen cases where a subscriber is provisioned for certain services at the switch but the same set of services is missing in the billing system. What happens in such a case is that the subscriber uses certain services (eg. Voicemail), but won’t have to pay anything for the same.

For usage data (i.e. XDRs), I find that most proactive checks still require at least a minor amount of leakage to occur before an alarm is triggered. The only true way to perform proactive revenue assurance as far as usage data is concerned is to either ensure all root-cause possibilites are covered and alarms are set-up at the core level rather than at the data output level(which is a massive task), or have a RA test bed before launching any service into a production environment (we could scale down the total load to consider). Using the test bed approach, we could effectively run RA metrics to verify absence of leakages, as well as capture issues at an early stage. Once the RA department clears the new service/product, it could be launched into production. Once again, this would not give us a 100% assurance of no revenue leakages.

Any other suggestions for Proactive RA?