Is ‘RA’ as a domain even remotely understood?

Weird as it may sound, especially when we are talking of saturated RA markets and stuff- but recent experience forces me to ask, “Across the planet, at an operational level, is RA as a ‘domain’, the need of it, and the requirements thereof ‘remotely understood at all’ ?”

I am forced to say ‘No’. Although we have excellent framework of TMF KPIs and RA Maturity Models, unfortunately the significance and value of the same does not seem to resonate at multiple telecom operations around the globe.

Not one, but I am facing multiple ‘adamant’ claims where the requirement/expectation from an RA system is to be able to process ‘few’ ‘billion’ (yes the words are ‘FEW’ and ‘BILLION’) usage records (per day) from different network elements and ‘almost’ do a one to one xDR/cdr match to find the discrepancies and report on the same. I am told, that is the way to do RA- and is the only way to find and fix leakage. I happen to find the requirement atrocious, more so because usage data analysis can provide only a part of the insights to effective RA. Leakages if found and fixed at the beginning of the revenue chain, always lowers the risks of heavy leakages downstream. Major challenges are typically with network configuration issues and mis-configurations for new products and offerings. However, they form only minor data volumes which can be easily handled.

Did I forget to mention, that one has to process the BILLIONS of usage xDRs with near-zero hardware costs?

In few other instances, I have found that the concept of Maturity model is way too misunderstood. The levels of ‘RA Maturity’ is not something that can be achieved or jumped on to ‘overnight’. Yet, disturbing as it may sound, there happens to be claims of the same.

What I am failing to understand now is, are these stray incidents, or is the capability and scope of RA really not understood ‘at the operational levels’? In the face of such claims, I somehow completely fail to understand the logic that may be used for monetization of ROI on RA teams and or systems. Would one ever get these by trying to match all of the billions of records across systems to detect leakage? If this is really the situation of understanding of ‘operationally effective’ RA, I am afraid, if we converge multiple domains along with risk management into a common ‘risk mitigation framework’ we may be creating a beast instead of solving actual problems at all.

Theoretically such approaches may sound as ‘the perfect solution’…. but no hope in hell, I am willing to accept that as an operational procedure for “effective” RA. If this is how RA is done, then I am Mickey Mouse, and we all Live in Jupiter….


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.

1 Comment on "Is ‘RA’ as a domain even remotely understood?"

  1. I agree. While as vendors we are required to comply and not question, however in a forum like this for the betterment of revenue related analytics, we must debate on the practicalities of the requirements mostly stated.
    How many RFPs really state the objective of the project – conducting RA is too naive and too vague. In order to propose a good solution, it is important to understand what objective is required to be fulfilled? Is it just automation of complex data processing, smart algorithms to reduce manual investigation and faster reporting? Is it to identify the most risky areas and secure them using a solution that would be relatively cheap and would be easy to maintain? A solution in both these cases would be different and the success criteria quite different.
    The vector of requirements stated, do they all have the same priority in terms of business? What level of maturity does the operator has in dealing with a large set of problems? A solution end of the day is as good as the people who use it and the best of the solutions can yield the worst possible results if handled by an immature team or inadequately staffed team and vice versa. Does operators realize it and how honest are operators in considering this while stating requirements? Again solution proposals should vary based on these.

Comments are closed.