I saw this question posted on the Linkedin website by one of our guest authors, Mark Yelland, and I felt that it warranted dusting off my keyboard and writing my first blog in 18 months.
I have worked on all manner of RA tools from those procured from vendors to those built in house by the RA teams and in my opinion tools fit into one of two categories:
- Those developed by software programmers (ITRA) – generally with little or no RA experience, and
- Those developed by RA professionals (RARA) – generally with limited software development skills
Generally speaking the ITRA systems are those sold by vendors and RARA systems are those built in house (however I have seen instances where this isn’t the case).
Looking at the two types of systems, they differ vastly in functionality and capability. Firstly if we look at the ITRA system, fundamentally it is built to be re-used, therefore the system needs to be generic so that the cost of integration can be minimized. To do this the back-end of the solution is usually built into 3 components,
- Staging – this is the bespoke area of the solution where raw data is loaded,
- Core – this is the generic table structure into which the stage data is squeezed
- Reporting – rules are built(in some cases these are pre-defined, in others customized) to identify and report the anomalies (leakage) and a rich pre-defined GUI will sit over the top providing a graphical representation of Revenue Leakage.
As this type of solution is developed by IT professionals it will be built following a common structured programming methodology which incorporates all of the capabilities of the database software they are using i.e. fields are all defined, pre-defined DB functions are used or even built by the programmers.
The advantages of an ITRA system are that it’s easily scalable and, in theory, can be amended with ease to fit you ever changing business. Also from a management perspective it can give you a one-stop view of the deemed Revenue Leakage. They are, however, seen as quite expensive from both a Capex and Opex point of view and from the RA team’s view, they don’t provide enough flexibility to find all of the leakages.
Now, if we look at the RARA solution, what we’ll see is a system that is developed over time, it starts with one reconciliation and a couple of data feeds and slowly grows to become an all-encompassing RA solution. The back ends of these solutions are generally only a couple of components:
- Raw Data – as with the ITRA solution, this is where data is loaded
- Reporting – as everything is built bespokely, rules are run against the raw data tables. A GUI may exist, but isn’t deemed 100% necessary.
Please note that there is no need for a staging area for the data, as the solution will not need to be integrated with multiple types of OSS/BSS.
As this solution is developed by RA professionals, table structures are usually all VARCHAR (as RA people know that no matter what the source of the data, it can be corrupted therefore VARCHAR is the only guarantee that it will get into the RA system). There are also a lot more rules against each data set, so rather than just being reports on set A records missing from set B and vice versa, the rules will also be looking at the integrity of each of the data sets i.e. show all records where the activation date isn’t a valid date, show all MSISDNs with less than x digits etc.
The advantages of the RARA system is that they generally do what the users want them to do i.e. provide all data at the most granular level allowing the analyst to write infinite amounts of SQL queries to assess all aspects of the chosen revenue stream. However, from a management perspective, it is quite often seen as an unknown, as no one-screen dashboard generally exists. Due to the way that they are built they do become more and more difficult to maintain over time and a single major change to the OSS/BSS infrastructure can often result in significant downtime for the solution.
So when asking the question “What is Wrong with RA Tools” I generally find that the answer can be predicted based on the respondent to the question and the type of solution they have in place, i.e.
- The RA analyst – loves RARA hates ITRA as their number one requirement is for the system to allow them to delve deeply into the data
- The management team – loves ITRA and hates RARA as their number one requirement is to have a snapshot of areas of issue and financial loss/recovery
There is of course the RA Manager who, generally speaking, sits somewhere between the two.
Finally, in case anyone was wondering – what do I prefer? Well personally speaking, I prefer any team I’m working with to have gone through the experience of building their own solution. The reason being, that by building your own solution there is a greater understanding of the complexities of the data involved and as a result the team’s root cause analysis skills are better honed. It should always be remembered that no solution will do root cause analysis for you, a solution only identifies issues, and these issues should always be assumed to be data integrity issues until proven otherwise. Ultimately, though, these RARA solutions need to be laid to rest as the S&M overhead increases exponentially over time, therefore the procurement of an ITRA solution will free up resource to concentrate on the more complex aspects of Revenue Assurance whilst still providing assurance over the core Revenue Streams.
