The Year that was…

Again, I have been MIA from the TalkRA roster for quite a while, but the truth of the matter is that I have spent the last year in a parallel world. Of course, there might be some among you who decide to prove that this is not true and you saw me in a conference or a customer meeting or something, but rest assured, that was a doppelganger I employ from time to time for tax reasons (apparently, slipping into an alternate dimension doesn’t exempt you from paying taxes).

Now in this parallel dimension, many things were the same as in our world, but there were some glaring changes which literally leap out at you. To list my three favorite aberrations:

a)      Revenue Assurance is now incomplete without a minimum of 80,000 checks

b)      TMF is for hobbyists and there are no real RA standards

c)       RA is now ruled by “Industry Buzzwords” as opposed to real work

My dad never tires of reminding me about how his generation was the best that ever was or ever will be. Reason, you ask? Simply put, technology and quality of life took a quantum leap within a span of 50 odd years. His generation saw radios with diodes and mobile phones which looked like a car radiator. Air travel was something Aladdin and his buddies did. His perspective is that today, due to the ready availability of everything, we are jaded. I didn’t really buy into his viewpoint till last year.

RA has steadily become a cover-all application. There was a time, in my humble opinion, when RA was about protecting the bottom-line. It was genuinely about covering the bases and making sure that the revenues you deserve as an operator was landing squarely in your pocket. Furthermore, it was about making sure your pockets didn’t have any holes. Now that RA systems are a dime a dozen (here, I lose all credibility as a vendor), the focus has been diluted somewhat.

It is again my opinion that when a RA practice starts out, it is important to define your RA coverage based on what impacts your business the most. My logic here is that, when a new system is being implemented, it is important to show the benefit of the system as soon as possible. The idea being sustained ROI helps in gaining management support for when you want to expand the remit of the function. Personally, when I am called in for a consulting engagement, I follow an extremely simple process, defined as follows:

If the size of the RA team is 10 people, and as a vendor I recommend 120 daily audits, there are a couple of things which would happen:

a)      The RA analysts would grow increasingly frustrated by the bottomless pit which is their daily case-load

b)      The RA managers would get increasingly frustrated by a system which keeps them from their families and forces them to live in caves without a hint of daylight for months on end

c)       The team decides to march to the vendor headquarters at night with pitchforks and torches to have a “Conclusive Discussion” (P.S. – On a related note, Frankenstein was most probably a RA vendor, but more on that later)

It is important to understand the “Boundaries of Efficient behavior” as I like to call it. Boundaries do not refer to only one or two items, but the universe the RA team operates in. I would break it down to the following items:

1)      Size and experience level of the RA team, including future hire

2)      Operational Expenditure from IT to support the RA team

3)      Crystal clear reporting cycles with well-defined action paths

Just to be clear, I am not against a large RA scope – I merely do not recommend it when you start out. Like riding a bicycle, any “investigation heavy” function like RA needs a bit of a teething period during which a Plan of Action and Standard Operating Procedures get purified and cemented. Trying to do everything at once is a recipe for disaster.

The second thing which was a bit surprising, though closely related to the first point, is how the TMF RA guidelines are seen as too sparse and high level by some practitioners. I respect their point of view, but then I fall deeper into the rabbit-hole where the Mad Hatter is now telling me that RA is responsible for Network Optimization and Bandwidth Allocation and what not. Again, as I sip my tea with the Queen of Hearts telling me that the crumpets served by GRAPA are far tastier, I try to expand my view to see where I lost track of Self-Organizing Networks coming under the gambit of RA. I like the RA guidelines, because it follows a thought process which is logical. Here again, my attempt is not to limit the scope of RA, but to see a well-defined, process-oriented growth in the practice as opposed to “Weed Growth” theory. “Weed Growth” is another term I’ve coined for a RA scope which is created with no consideration for the resources it saps either internally (as in providing Analysts with a scope they are not ready to handle) or externally (when a field is introduced in a core network element to simplify RA’s task while necessitating rework in other downstream elements). Without building a synergistic growth model, I have personally seen RA departments paint targets on their backs from other teams (normally from IT). Revenge is a dish best served cold, and apparently server rooms are kept quite cool – if you get my drift.

Thirdly, it is not uncommon to hear a RA head ask you about “Customer Experience Management” driven Revenue Assurance nowadays. There are ways to highlight the impacted subscriber set due to certain issues (eg. if a rate plan is over-charging, we can pull out the subscribers who are impacted due to this error and send out mails to them, apologizing for the same), however when you start defining your checks based on individual subscribers there is a huge overhead that is being introduced from multiple aspects. For example, if the checks were being defined on a per subscriber level, then the rate plan scenario I mentioned before would span hundreds of thousands of cases for investigation by the RA analyst. Consider the alternative, where a single case is created but we can identify the impacted subscribers. We achieve the same thing, but in the first case at a huge man-hour cost and IT resources perspective. There are intelligent ways to utilize the data from RA for a whole host of activities. Some good ideas which were suggested by operators were:

a)      Use the RA Platform for Internal Audit

b)      Extend the analytics present in RA to enable Product/Service Performance

c)       Usage of data within the RA Universe to enable Cash Automation (primarily related to Prepaid  Channel Assurance, with extension to financial platforms)

All in all, last year was fun. We had brand new challenges, we saw a definitive leap in RA practices around the region and we had our R&D team come out with a Root Cause Advisory engine. I have a feeling that the upcoming year will see the expansion of RA into a truly integrated ERM framework. On a personal note, hopefully, I increase my blog run-rate to more than 1 per year!!!


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 "The Year that was…"

  1. Ashwin, that was a great blog – and with such witty and perceptive insights, we’d all love to see you post more often! ;)

  2. Güera Romo Güera Romo | 26 Apr 2011 at 2:39 pm |

    Weed growth. Amen to that!

  3. Joseph Nderitu Joseph Nderitu | 27 Apr 2011 at 5:54 am |


    “Frankenstein was most probably an RA vendor”

    Why do I feel so inclined to agree with that?

Comments are closed.