In the first two years of my RA career, I did not use a revenue assurance system. We depended on ACL for data analysis because we could connect it to a wide range of data sources (relational databases, text files, spreadsheets and even extremely “malformed” data). In ACL, basic knowledge of joins, summation, duplicate checks and sequence checks, supported by a few string/numeric functions was sufficient to identify leakages. It could be argued that for all intents and purposes, ACL then was our RA “system” and I would not protest too much. However, I am talking about “proper” RA systems that are marketed as such (using huge budgets and lots of fanfare).
Later, when the RA department had proved its value to the kahunas on top floor, we were found worthy of a system and the company allocated some budget. Really, RA systems were not such a big invention (apologies to our esteemed vendors who would argue otherwise). The components were, and still remain, basic. An ETL engine capable of extracting data from various sources into a relational database, a dashboard showing the traffic trends across the network and billing platforms in addition to subscriber profile reconciliations, a mechanism of configuring alerts and a case management workflow for tracking various issues identified via the items above.
Much of the work we did as analysts (when we were young and innocent) revolved around those things. Because there were gaps in the “standard” RA and Fraud Management systems, some vendors also identified and marketed specialized areas which were not well covered in that model. Think of vendors of automated test solutions which are now used in identifying roaming issues, grey route traffic and even assessing quality of service on local and international calls. The selling point was always, “we go beyond what your RA/FM system can offer”.
For some time, this has worked quite well. What cannot be done on one system is well handled in another system… and so we became comfortable. Some vendors, like WeDo, still invest in driving innovation and challenging traditional ways of assurance but let us not kid ourselves that, as an industry, we are generally on the cutting edge.
Since taking on a new assignment at Vodacom Tanzania, several vendors have approached me hoping to deploy one solution or another. I have found myself responding, “we already have that in place” or “that is a risk, yes, but I know the amount of exposure, management is aware and it doesn’t merit additional effort/cost”. When I challenge them to come up with something that is a bit fresh e.g. a proof of concept project on predictive analytics in fraud management or a demo of machine learning capabilities in mobile money assurance, I can hear the dismay in their voices. The hopes of a quick sale fall through and the shameful shuffle back to R&D is not something they want to do.
I am unapologetic about this. I want to see more of innovative data science in RA. Yet, this is not my original idea. The likes of PayPal have been doing amazing work, moving into neural networks and deep learning in order to combat fraud. Telco RA functions and RA vendors are all talking about big data, pattern recognition, fingerprinting, machine learning etc. However, my informal discussions with managers in RA functions (and my push-back efforts on vendors who wish to sell me old stuff) show that this is still very much big talk. The concepts discussed in this article are still not common for tools offered to telco assurance functions.
How sad is it that an area of work that flourished because of risks of innovation is pussyfooting when it comes to innovating tools for doing the work?