I was looking into how “RA” is being done in a number of places– for all the good legal reasons cannot share the sources. But what was strange was to find out — the “outcome” seems to be somewhat distorted in a number of places. “RA” is about “revenue” and “assurance”– so you have revenue to be “assured”; and revenue is “things for which you would raise an invoice” (a novice definition, but good enough for my post in here!).
One of the methods of “RA” is leakage detection. But then what do you do after that. The scope of RA just starts with “detection”– and so no point in exclaiming that $x amount of leakage has been detected. It does not help anyone– except for marketing teams of vendors who sell RA tools. The challenges are (1) to fix the issue (could be leakage or even something else), (2) “ensuring” that the same is not repeated, (3) if a heart-beat is noticed in the particular control, identification of the real-cause behind the repetitive behavior.
In a number of cases, I have seen, this heart-beat is where the real problem is. It is chronic in nature– and contributes to cases which after detailed analysis have been found to be a form of fraud. A real example as I have seen of this is here: In an operator, suddenly the analysts found a drop in chargeable calls. Analysis proved a misconfiguration in a network element. It was fixed. Here is the first catch. A network element is suddenly behaving/behaved in an erratic manner. What was the cause? The identification is a must. What went wrong is identified. Now it was the time to find out the “why”. As a matter of fact, a bunch of subscribers had started misusing the situation– all they needed to do is prefix a particular number before they called– that is another aspect of the fraud part. The question is, was the misconfiguration “deliberate”? The next question is, the group of subscribers that benefited from the misconfiguration– were they linked? Either way– the answers are of prime importance, but the real “RA” in here, is to be able to identify all such calls first, ‘quantify’ the value, ensure that the appropriate subscribers are billed, compare the payment received vs, $ value of the loss, and then say, how much was actually “assured”. The next step is to ensure possible detection of such happenings “before they have caused the harm”. That is the real “ASSURANCE” part.
This brings another question in mind, “what is the scope of RA” ? I would cover what I feel about the scope in my next post.
A question on a different track– how much was the operations cost vs the recovered/detected/assured $ value? This is to be able to measure, over a period of time, the real benefit of the revenue assurance activity. But then again, if it is found that the ratio is not heartening, can an operator even think of stopping such a function?? NEVER– the reason is simple, what seems a small value today, will simply bloat up exponentially before realizing that the situation is out of control.
Let me know what you think about this.