Benjamin was afflicted by a weird ailment that he was born old with a lot of old-age sufferings and gradually over time, became young, handsome, bright and vibrant before finally meeting his end by “vanishing”. For anyone who wants to have a quick overview of the story from the ‘Jazz’ era by F. Scott Fitzgerald, here is the link.
Revenue assurance somewhat followed and follows a similar path. Initially it was done the old-age method of billing assurance with lots of manual labor (much like an old man afflicted with ailments) and currently it has come of age as a vibrant community of practitioners (just as Benjamin over the years had grown younger), although the wise men who perform the art of crystal ball gazing to predict markets and growths, somewhat are of the opinion that it is actually a dying market (Benjamin, instead of being an adult, is going to become a child and then an infant and gradually wither away). Essentially, what I mean is, if the predictions are assumed correct, it seems Revenue Assurance is aging backwards. This is why I find the story of Benjamin completely similar to Revenue Assurance, while I am personally of the opinion that RA has got more to do in the coming years of telecom.
Over the years, and in multiple forums, especially in talkRA, we have discussed the challenges RA has to face on a day in day out basis. Industry forums of repute like TM Forum have spent a considerable amount of effort in helping define the scope of work for the benefit of the operators. But then the effort, in real life implementations (and by that I mean the operational procedures and practices for RA in real life telecom operators) may not always have seen the true light of the day as it should have. So what does Benjamin need? Rather what is that remedy for Benjamin which can stop the reverse aging and restore the process of natural growth. In effect, what does RA need to bridge the gap between all the standards and their strategic implications and importance that have been discussed and published for aiding operators, and the operational translation for converting the strategic lookout into operational effectiveness. What is that “something” that could span horizontally and vertically improving operations at the lowest level, and summing the effects to create a strategic viewpoint that would then allow overall improvement.
For Benjamin, it is a clock that can reverse time, and for RA, it is a system that can provide a systematic translation for improving strategic visibility into operational procedures. Being a product manager of an RA tool, I am going to share with you a series of articles about how we created a ‘clock’ for RA.
The first thing need was to improve strategic visibility into operational procedures. Some of curious questions that have often bother senior executives in telecom :
- How much am I losing?
- How much am I recovering?
- Do I have visibility into “everything”? what am I ‘missing’
- How quickly RA is scaling to cover areas being missed now?
RevenuePad answers these in the following ways :
- For understanding how much one is losing RevenuePad puts a quantification methods for all the operational KPIs; which means, if a threshold is violated, a loss quantifier formula (howsoever complex it may be) is used to calculate the leakage.
- Once a loss has been detected through a KPI threshold violation, a trouble ticket is raised within the system in the form of case management. Closure of the case follows by ensuring the recovery is accounted for). RevenuePad rolls up the recovery up to the strategic viewpoint.
- Providing visibility: RevenuePad uses the TM Forum assurance areas like a lot of other tools, but what its also adds is the capability to map the organization structure in the form of a “tree”/hierarchy. For example, if the operations, are geographically spread across multiple lines of business and service lines, (which is the case for telcos), the same structure would be mapped into the system in the form of a tree, along with allowable tolerance limits of leakage (if at all) per node.
But this is just the beginning of capabilities. I will elaborate on this later, because for the first time, there is an aspect of enterprise wide RA Maturity that has been addressed, which would need time to address and therefore the separate post - The fourth question was “How quickly RA is scaling to cover areas being missed now?”: To address this, RevenuePad first tracks how quickly cases have been closed which essentially means, how quickly revenue recovery was done. The quicker a node stabilizes w.r.t the parameters of : leakage detection, recovery, and final losses, the stable the business mode becomes w.r.t the configured KPIs. Essentially by tracking the performance of the nodes along these lines, RevenuePad showcases
- if the node is stable,
- if the node is stable, is it covering all the aspects of the areas that it needs to cover, if NOT
- it is time to add more controls and coverage, because the remaining controls have been stabilized.
So, essentially, RevenuePad allows gauging if a node is “quantitatively mature”.
Read next week’s post to find out more.
