Dave Stuart

David is the Assistant Director of Revenue Assurance and Fraud Management at Qtel International. A Revenue Assurance expert with over 10 years practical experience within Telecoms RA. David graduated from Brunel University with a Mathematics and Statistics degree, after which he moved into the financial services sector.

David started his RA career at MCI WorldCom, where he designed and project managed the development of a traffic assurance tool covering a dozen business units fixed line traffic.

From here David moved to One2One/T-Mobile where he provided architectural assurance over all of the company’s developments. David’s expertise in the company’s architecture led him to be made Test Manager over the UK’s first 2.5G launch.

From T-Mobile David moved to specialist RA consultancy 2Helix, where he held the position of Senior RA consultant, he worked on numerous projects all delivering RA software, often bespokely designed for the clients needs.

After 2Helix David moved to Cable and Wireless International, where he was again responsible for delivering RA tools, this time to CWI’s 33 business units.

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:

  1. Those developed by software programmers (ITRA) – generally with little or no RA experience, and
  2. 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.

  1. 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
  2. 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.

Bookmark and Share

With banking being the hot topic at the moment, I thought it would be a good idea to look at the next generation of Telecoms services – the mobile credit card(mobile wallet). For years the Telco industry watched the banking sector with envy, they’ve seen them making up to 7% on every credit card tansaction and how – by having a fixed line telecoms network into all retail outlets and (supposedly) oodles of cash to lend to the consumers. 

The mobile industry spotted the synergies between the banks and themselves and decided that they could offer the same services(all be it by sitting on the back of the existing architecture),  the operators have acquired banking licenses and now a few years on, the service would appear to be ready for launch - the idea being that you’ll swipe your phone instead of your credit card

So the question/discussion I wanted to have is: What does this all mean for Revenue Assurance?

There are a few topics that need to be considered:

Regulatory – currently operators only have to deal with Ofcom, however by offering credit card services things like the consumer credit act come into play as well as bodies like the FSA

Technically – To offer credit card services, the operators are going to have to add new systems – a seperate billing system  for credit card transactions(I would hope), seperate accounting, third party revenue share systems, maybe seperate CRM.

Fraud – Obviously the scope for fraud grows 10-fold by introducing consumer credit. Credit card companies charge high interest to cover the cost of fraud, so what are the implcations for the operators?

Revenue Assurance – where do we start? There will be the need for transactional monitoring systems ie all events pass from A to B successfully, rating assurance -  interest charges are applied correctly, billing verification, third party revenue share assurance etc etc. 

 For anyone thinking this doesn’t sound too complex consider the following scenario : I pay for my mobile phone bill via direct debit to my mobile credit card, upon receipt of my phone bill I notice that I have been charged 2 line rentals. I contact the operator and tell them of the mistake and they promise to reverse the mistake on the next bill. I do not pay off my credit card this month and as a result pay interest against the balance – including the extra line rental. Who owes me the interest?

The Mobile Credit Card is probably going to be the single biggest change to Revenue Assurance that we will ever see. Whether the operators push forward with it in the current economic climate is still to be seen, however if they do – what do we need to do to be ready?

Bookmark and Share

This question is a follow on from the previous impossible mission question posted a few weeks ago.  One of the comments posted on the question asked whether the problem of un-linkable data was a Revenue Assurance issue? I think this is an interesting question and would like to hear other readers views before posting my own.

Bookmark and Share

I think the easiest way to explain why setting a fixed rate KPI against revenue reclamation doesn’t work is to first look at a couple of  revenue loss scenarios per revenue stream

One Off System Faults 

  • A pre-pay billing system collapses for a period of time, during that period all calls are free.  Recovery 0%
  • A post-pay billing system collapses for a period of time, during that period no calls are rated. The CDR’s can be re-processed and recovery is 100%

Erroneous Reference Data

  • A pre-pay billing system is rating calls at 1p instead of 10p. You can’t back bill. Recovery 0%
  • A post-pay rating engine is rating calls at 1p instead of 10p, dependant on local regulations, duration of issue, company politics etc Recovery 0 to 100%

Now just from the above couple of examples, it’s plain to see that there is a drastic difference between recovery in pre-paid revenue loss to that of post paid revenue loss. This is mainly due to the fact that pre-paid recovery is rare(not impossible), so therefore when defining recovery KPI’s the first thing you need to do is seperate your revenue streams.

What is Recovery?

This seems like an easy/obvious answer – however when you bring in the subject of opportunity loss, is it so clear?  Well, can you recover an opportunity loss? – some people will say that because there is no billing error with an opportunity loss just a service prevention, there is no revenue to recover. However others will say, that by enabling the service to be used, the revenues that are achieved going forward are the recovery. The debate then grows into: if forward billing is classified as recovery, do we therefore have to track all customer accounts forever and if so how can we have KPI’s?  This debate can escalate exponentially and until there is a standard definition, any work on KPI’s and other standard measures is pointless.

I personally believe that to make life simple, recovery can only relate to revenues already lost(the stuff in the past) for resolution of opportunity losses and the ongoing revenues from fixing a recovery I would term these as Benefits. (Please note I’m really watering things down here, there are many more Benefits that need to be defined like OPEX and CAPEX savings resulting from any resolution)

Does Maturity Impact Recovery?

Of course it does!

I’m not going to write too much here(I’ve already written more than I’d wanted to), but quite simply the level of maturity of a function dictates the types of Revenue Loss that’s identified and as we’ve already seen “type” dictates recovery.

Summing Up

If we define recoverable leakages as being the moneys that should have been billed, but for some reason haven’t. Then what we are looking at is something we really have no control over. Pre-paid revenues generally can’t be recovered and post paid revenues are so wrapped up in regulations and customer choice that again we have little or no control over reclaiming this money. What we do have control over are the Benefits, every attempted recovery should have an associated benefit no matter what the type of loss

I’m sure that the headline of “Operators Recover Only a Third of Indentified Revenue Leakages” is statistically about right if you exclude all of the un-recoverable loss types stated above. Ultimately though, in the case of the majority of African Operators (99% prepaid), what you are talking about less than 1%(financially) of issues they will identify, therefore the KPI is pretyy much pointless.

If we want to look at Revenue Assurance as a whole, then a better study would be to look at All of the assoicated Benefits of each revenue leakage prevented/recovered 

Bookmark and Share

A complete change of question this week.  I saw this article and it made me chuckle, especially  “This study is a considerable breakthrough in the field of Revenue assurance KPI’s measurements,”

I’m sure I’m not the only person who has quoted the one third rule as a “nice average” for at least the last 5 years and I hope I’m not the only person who knows why it can’t be used as a KPI – so that’s this weeks question – why can’t 33% be used as a KPI for leakage recovery

Bookmark and Share