RA ….The real value add.

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.

This entry was posted in Leakage Detection, Revenue Assurance, Revenue management. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s