Revenue Assurance and The Curious Case of Benjamin Button – Part 2

In Part 1,  I talked about the potential for an RA ‘clock’, which could reverse time for Benjamin Button and I showed the first glimpse. Now let me discuss why this was needed, and bit more detail about it.

Donning the hat of a Product Manager: The Motivations for RevenuePad

Let me share as a product manager of a  Revenue Assurance application what we did to create value for operators (our customers).

The challenges of telecom operators and therefore in an RA department (our Benjamin) are not unknown: shrinking margins, need for improving top line and focus on reducing costs all across. Effectively it is about doing more with less. When we analyzed the effect on ‘Benjamin’ and team (I mean the RA team), it boiled down to finding more and fixing more and therefore proving efficiency of operations (in terms of cost effectiveness as well). But the more tactical or rather operational problems that prevail are:

  1. titanic data volumes to be handled and therefore inability to scale beyond reconciliation and analysis of usage data – switch to mediation, IN, and other network elements and such.
  2. complexity of existing and newer networks doubled with efforts of maintaining offline and online RA systems. Offline information is always maintained on macro based spreadsheets and or otherwise PowerPoint presentations or Keynotes.
  3. knowledge and information management across the board.

The third point is somewhat severe; because:

  • even now a large number of RA operations intend to believe that RA is about processing billions of records per day and finding the ‘needle in the haystack’;
  • Rating Assurance is about having a parallel rating and billing systems from an RA tool, hoping the RA system would replicate all possible billing systems on the planet.
  • Presence of complex tools that have steep learning curve, and well if there key resources leave- all hell breaks lose to find a replacement.

All this leaves the RA team look “like a chicken with its head cut off”. Apologies for the apparently cruel analogy, but I could not find a better way to explain the frenzy in the RA departments around the globe. Personally, I have seen a large Asian operator with over 100 million subscribers put the efforts of over a 100 personnel in RA department to gather inputs from its geography-wide set up into over “2000” macro-enabled MS Excel sheets to showcase performance in terms of leakage detection and recovery. Staggering numbers- but they are true.

Once I was asked, if I had to explain RA to my 85 year old grandmother or a 4 year old kid, how would I do? The answer is difficult, but Subex has created in the answer in the form of RevenuePad. Effectively the RevenuePad had to be instinctively intuitive for any user. How did we do it?

In part 1, I explained, how we enabled mapping the “entire” business structure into the tool. Once the mapping is done, RevenuePad rolls up the complete data from all the underlying KPIs and cases into a simple to use ‘dashboard’ created with the UI principles of progressive disclosure. This makes every non-domain-related personnel understand and drill into the details as and when required. By doing so, we addressed one of the aspects of knowledge management, because now all the quantitative parameters of loss detected, recovered, still recoverable, and time of recovery, across the operational geography has been mapped into one place. But there is one more aspect: strategic directions and objectives are still on powerpoints and key notes- offline documents that are not constantly visible, gathers dust before being referred to after a period of time. Often, therefore the visibility is lost and at times it is necessary to re-do activities to get back on track.

RevenuePad provides a framework where such strategic visions and directions, can be mapped and maintained within the product. In part 1, I used a screen-view which showed how for the business nodes existing (evaluated) RA Maturity could be tracked. RevenuePad takes the tracking one step further with its framework approach. The vision/direction and evaluated maturity now being available as a part of the application and that the performance of the nodes in terms of quantified values are also showcased at a single place, provides the operators (our customers) with the understanding of:

  1. where they are vis-à-vis where they need to be
  2. how much of the strategic vision has been implemented operationally, and how much is yet to be implemented
  3. how the business in totality and each of the business nodes individually have performed operationally over time, based on which a decision to re-evaluate maturity, coverage, performance improvement programs or such can be initiated. Essentially RevenuePad provides the all encompassing view at one go.

That I was using the story of Benjamin, RevenuePad with such views, data and information all put together in an easy to use format, serves as the anti-dote or clock that can help Benjamin recover from an otherwise dying or frenzied state. But strategic viewing of operational performance is also not enough. What is also important is to ensure that operational performance of analysts is improved. Zen, as Ashwin had mentioned in his post, was a part, but there is a second part of improving productivity for analysts, which I would cover in the next post.

Here is a hint, ‘a picture speaks a thousand words’.Let me explain more about RevenuePad next week

 

Moinak Banerjee
Moinak Banerjee
Moinak works at Protiviti Kuwait, as Product Lead for their Risk Technology Services. Over the years, he has worked in product management for several leading vendors of telecom OSS/BSS software.

Related Articles

2 COMMENTS

  1. @ Rajun (if that is your real name)

    No, this is still the blog for people who want something really valuable for free. Luckily we don’t depend on your gratitude or your money – or anyone else’s.

    You seem to be based in Israel. Now I’m curious to know what you’ve freely contributed to the world of RA. Perhaps you work for a vendor that contributes a lot of misinformation about their own performance – I recently wrote about a vendor just like that. Or maybe I’ll write about the vendor that told me they had lots of customers for their new cloud-based service, and said they would be able to name them later… but never did. Or should I write about the vendor that launched exciting new products, kept telling me the good news in the hope I would repeat it word-for-word, but refused to give the slightest detail of what the products actually did?

Comments are closed.

Get Our Weekly Newsletter by Email