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?