I was trying to think about on how RA has moved, changed and re-invented itself in the 13 years I’ve now been involved, in some form or another, with RA. To my view there have been some movements and if I look at those, then perhaps I can have some liberty and crystal ball gaze to the future.

The first trend is the emergence of increasingly powerful software tools to specifically identify, address and help manage revenue assurance. There should be little doubt that this has helped RA investigate new areas of revenue streams for potential loss while also automating much RA activity. This can be very beneficial for those new to RA who can draw on this expertise to learn from the experience of the vendor and deploy an RA capability quickly and usually with some financial benefit. The contrast of this is that the maturity of the tool set exceeds the maturity of the RA people, who may miss valuable steps in understanding the underpinnings of RA work and how their business works. The risk is that this can produce an over reliance on RA to be “solved” by the software tool. The greater risk though is that RA is “defined” by the software tool and its capabilities and roadmap and not by the operator. Missing those early baby steps in RA can lead to a strategy that is aligned solely around the technology deployed and is hence, however well intentioned by the vendor, unbalanced.

This is a similar issue as faced by fraud management. In this case, I have seen many operators who struggle to adapt to new fraud types, until the vendor issues a software update, and will argue passionately that because their system does not detect that type of fraud, then it is not really fraud. When the software update though is deployed, it can be thought of as a fraud again.

The leads to the second trend which is the growing number of organisations undertaking services work in the revenue assurance domain. If RA got into the limelight first during the dot.com and tech busts of the late 90s and early 2000s then we should not be surprised that it has been reinvigorated through the latest GFC. The mantra around billing or charging accurately for every event is particularly powerful when revenue growth is limited. But perhaps these service organisations are also seeking to fill a void in the operators where, due to the reliance on technology as above, the ongoing return on investment from RA is not what was expected. But what might this void look like? Firstly, as RA becomes more operationalised into the business, the RA team comprises a greater number of staff whose role is orientated around the RA tool. I’ve mentioned this above already but it leads to a distancing from the real data and business processes and, more particularly, the need to think and challenge conventional ways becomes reduced. This is not unique to RA of course as increased reliance on computing and the automation they provide, means loss of the real experts in a system or process and replacement with defined work instructions that ensure consistency, if perhaps not always quality. You could speculate that this is how RA was able to come into existence in the first place as that level of complete and detailed knowledge held by system owners across the revenue chain was lost. This loss was not just from automation of course but the increased complexity that the automation enabled. The risk from this is that as RA becomes more automated, the room for thinking disappears as reducing cost becomes an increasingly important corporate objective. And so, I expect that we will start to see and hear of an increasing number of examples of RA missing some significant leakage or undertaking poor quality work. In fact, this trend is already evident as I have had vendors indicate to me that when they have done a proof of concept at an operator, they have found leakage that the incumbent RA system missed. By the same measure, operators have spoken to me about an increasing false positive rate, diminishing value of leakages identified and a greater role to alert a potential issue rather than alert, detail and then help in the resolution of these issues. This can only be due to looking for the same leakage day after day, month after month, rather than expanding thinking to look into areas not yet automated.

The last trend I want to comment on is the move from reactive to proactive RA – however that be chosen to be defined. A quote from Fernando Sales (Gerente General de Inteligencia Comercial, Telefonica Venezuela) in a 2009 Hugh Roberts presentation summed this up for me nicely: “the worst thing that I did was to set our [RA] department up as a profit centre – we are still paying the political price for this in our relationships with other business units, particularly IT”. Perhaps the quote does not align to the reactive-proactive issue but on further inspection it suggests to me that the creation of a function predicated around finding and recovering lost revenue can create a short, and even medium term, star but one that burns twice as bright for half the life. As an operator, leakage should reduce over time. Complexity may increase but so should RA operational efficiencies, new products may be launched but so should more effective detection mechanisms, new business models may be introduced but RA should know their own business and where the risks exist. And so, RA that built its business justification on leakage, will find it contributes diminishing returns and so investment becomes more difficult to justify. Looking forward then, I can’t see how any RA function will continue to justify itself on leakage – the question for each operator is how long. And so the move to the “nirvana” of proactive RA, where RA doesn’t have to find loss, it has to prevent it; and as importantly, the prevention of those losses are recognised as tangible and of business value. This is an issue RA must solve.

Against this back drop, it should hardly be surprising then RA people and vendors have sought to reinvent and legitimise themselves in many different ways. This includes aligning to more established functions, extending its remit beyond traditional switch to bill audits, moving into cost domains, moving from reactive to proactive, supporting transformation efforts and seeking creditability through industry standardisation. This post is not about my view on any of these but it is important to think on the motivation and rationale for any extension beyond traditional RA and understand in what direction, sometimes irreversible, this may take both the individual function and the overall discipline. The risk for RA is that it becomes too tool orientated and too operationalised such that it starts making errors (including errors of omission) while all the time returning less value. RA loses its attention to detail and understanding of the business and so become part of the problem not of the solution. Further the standardisation of RA techniques see the gradual removal of the strategic thinkers from RA teams and to vendors, consultancies, other functions or other industries.

Having forecasted gloom, I believe RA still has the opportunity to add real and lasting value but to do so needs to address the following, and probably within the next 12-24 months:

· Developing software tools that expose data and its treatment to the RA function to ensure the end-to-end process is transparent and understood by RA

· Having the different standards organisations, define RA by the work that needs to be done and not by what the tools that seek to address can do

· Defining “proactive” RA and a value proposition that extends beyond financial measures and ensuring this is communicated and understood at the most senior levels of organisation

· Enhancing the alignment in RA between data integrity activities and process improvement to drive root cause resolution; and using tools and techniques already developed in these areas

· Extension of RA and acceptance of its methodologies across other industries to allow cross industry movement of RA people

· Learning by telco RA of how these challenges are met in other industries and incorporating that into best practices

I’ve recently returned from attending Beacon Event’s 10^th annual Asia Pacific Billing and Revenue Assurance conference in Bangkok. While I’d planned and hoped to provide a daily update, that proved too difficult with an unstable hotel WiFi connection (missed revenue opportunity?) and so this comes to you a day later and 7500 kms away from the conference.

Tony Poulos provided a timely reminder within 10 minutes of the conference start when he spoke of the multi thousand person Billing events that used to be staged at Earl’s Court in London in the last 90’s and early 00’s. Of course these incorporated fraud and revenue assurance as well but while those days are long gone, there was a healthy 150 or so people in attendance.

If the agenda reflects what people want to hear and know about, then these are things for us to be aware of:

- why not simplify pricing constructs to minimise the likelihood of revenue loss but also better manage customer experience and prevent bill shock?

- What role should RA have in transformation projects? Everyone, not surprisingly, agreed RA should be involved but its ability to halt a transformation activity if KPIs are not being met was more contentious

- Where should call senders sit in an overall RA strategy?

- Where should RA sit in an organisation and should it be integrated with other functions including fraud, credit management, marketing, product management or extend its remit to business assurance and revenue protection?

- How can RA and billing cooperate more with the traditional enemy of Marketing?

- The increasing importance of analytical support for RA.

- What unique challenges exist for multi play operators, and is the risk of loss from bundling and discounting greater than the risk on a single product line alone?

- What does preventative RA or proactive RA actually look like?

- What does it mean when the customer service group has a lower tolerance for leakage than the RA group?

- Why is prepaid fraud so often overlooked and neglected, despite the significant amount of money sitting on the platform?

Some of these may resonate with you and some may not and, in large part, that comes down to the unique operating environment in which everyone works.

Firstly happy new year to everyone – I hope 2010 is a successful one.

Reflecting on some recent posts, both on talkRA and more broadly, I found myself asking the above question.

My rationale was that much of the discussion around RA seems to centre on what the next step of evolution for RA should be. It is almost as if finding and preventing leakage is not enough to sustain an RA function and that more needs to be added to the RA portfolio for it to continue to be seen to be adding value. I wonder if the logic for this is an assumption that, with a well-established RA function, either leakage will fall away or more likely the costs of finding and fixing it outweigh the benefits it will bring.

In many ways this makes sense. The TMF maturity model advocates greater decentralisation of the “RA” mindset and capability across an organisation. Now in many organisations this is not practically possible to achieve but it is possible to move further along the continuum. And this would imply that the RA managers who do the right thing for their organisation by spreading the thinking of RA may find their role reduces as resource moves out to operational areas as the perceived value of RA moves from tangible detected loss to less tangible prevented.

So is it the case that RA done well means that the RA manager must look to extend their remit to hold their status in their organisation? Is RA alone not “noble” enough to provide a sustainable career path? Now, I don’t have the answers to this but as I have recently moved from an operator to being an independent consultant, this question is also relevant for me personally.

Surely though this challenge for RA is not that different to other risk management disciplines – primarily I am thinking of fraud and security but this could also apply to other risks such as legal, regulatory etc. When RA is new in an organisation then opportunity for attention arise as the leakages are found and fixed but at some stage a steady state will be met. Must RA extend itself to continue to have influence and attention at the CxO level…and if not will it find its position becomes less relevant? I don’t have the answer to this question and I suspect it will actually evolve and change anyway over time but it is something every RA manager driving their company along the maturity curve should consider.

Reading the recent news on talkRA of the merger of EcTel and cVidya, and financial results for Subex got me thinking. Add to that when I was on an internal call last week, I was asked why we need to use the RA tool to perform a reconciliation, and not just use SAS.

Is it the case that the RA tool, as a specialised piece of software, that can command a premium price, is going the way of the dinosaur? On the phone call, I was able to argue that the configuration work had already been done so it was pointless to repeat it, but would I have an easy as response as this, if the work had not yet been started?

I have recently been thinking again about the TMF’s RA maturity model. What I am sure on is that the benefits from an RA investment (be that time, people or tool), will not be more than the lowest individual dimension of maturity. So if 4 of the 5 dimensions of the TMF maturity are high, but the “people” dimension (for example) is low; then only low benefits will be realised (don’t ask me to define low vs. high benefit).

And so the RA manager’s role must be to align each dimension to deliver and sustain the next level of maturity. Delivering this though requires thought, based on an honest appreciation of where capability is currently at, and strategic leadership to see how to move in the next level.

To bring this back to why I was thinking about this originally, there seems a disconnect between the seemingly unflattering business performance of RA vendors, and the apparent growing need for RA work. It raises the question that, in general, are RA tools and software more mature than the people and processes, or is it the other way around? And depending on that answer, is this recognised by the RA software vendors, and if so what could, or must, they do to lift their own profit?

I started writing a comment to Ashwin’s blog but as it was getting too long, I thought I should just start a blog.

From my perspective, there is little doubt that detailed analytics are essential to be undertaken by RA teams and should be the primary activity. Dashboards serve some value in identifying trends but I suggest that any movements upwards or downwards in trend lines (such as the 0.3511% in Ashwin’s email) become almost impossible to justify as leakage. Let me explain my views:

First – what is the right baseline value to begin a dashboard with? Assume every day for the last 3 years, 100 calls come into a mediation device and 70 come out. So you set a baseline at 70 and if this drops to 65 then you decide to follow up with the mediation people. Great theory, but who says 70 is correct in the first place? It may well be that there is a leakage in the 70 and in fact it should have been 80 all this time. The only way to know where to set a possible baseline then is by doing a detailed analytic. So let’s now assume we did that and we know it should have been 80, we’ve fixed the mediation device and we start seeing 80 go through every day. Great stuff: we found 10 lost calls, fixed that issue (hopefully got a pat on the back), and are now monitoring every day just in case, this drops back to 75 in which case we will be on the phone and get that problem fixed as well. Two weeks later, and the volumes hit 70 and they stay there for the next few days. You’re on the phone saying something is wrong, no-one believes you and ask you for the call detail to prove it. You do the analytic again and find that 70 is the right volume as new products have been introduced and the mediation device treats them differently, or there was more of a particular call type in that time period due to a marketing promotion, or…etc etc. My point is that the reasons could be endless and setting a good baseline dashboard value would only be possible in a stagnant, never changing, environment – not really well suited to telco then. And if, every time you called out “leakage !!!” when there was some other change you would be 1) busy tryng to prove this and 2) lose your reputation for integrity and the time of the people who you keep raising alarms to.

Second – many revenue leakages reside in the less than 1% bracket. Sure, there are some massive ones and these are the ones that we talk about at conferences or hear of in training but the normal reality is that most are so small, relative to the revenue pool that a dashboard would find impossible to discern from other activity (similar to my point above). But if you have a $100M product, then finding $1M is a good result but to find it is likely going to need detailed analytics.

Third – only with some detailed data can you go back to the business area and tell them what specifically to consider addressing. Analysis may even also know what to fix specifically. Analysis can also tell you the extent of the issue, making a quantification of the total impact, more easily achieved and this can help drive prioritisation of resources to address this, relative to all the many other competing demands across the company for money and people’s time.

Lastly (for now anyway) – the cost and effort to maintain a RA dashboard that adapts for all the business rules and changes that go on in a business would be very high. In fact, I would contend that it would be almost as high as putting in the operational system changes that it is meant to monitor. Why? to keep it current of all network and IT changes going on would not be insignificant, add in all pricing changes, campaigns, what the competition is doing and how to account for the behaviour of people is practically impossible to model. To make a point, how many times have I heard stories of RA managers raising alarms at a 50% drop in traffic over a 2 hour period, only to later realise that this was due to the nation being absored by a football match (and the RA manager probably was watching on TV as well).

Do I think there is value in RA dashboards then? Well, yes but they have to have some key attributes:
1) data presented has to be summarised correctly from accurate underlying data (avoid garbage in – garbage out)
2) “alerts” have to drive an action (e.g. do analytic, phone billing)
3) more true positive alerts are generated than false alerts (the challenge of our fraud system friends as well)
4) data needs to be delivered in a timely manner (no point finding a leajage after everyone else has)

Putting that into play though requires time, thought and effort. And that effort could be spent on doing a detailed analytic. Getting the balance right is the challenge !!!

Much is often made of the need and benefit of training to enhance the knowledge and skill of revenue assurance practitioners. The claims made of the benefits certainly vary considerably and, in recent times, there also seems an increased focused on accreditation or certification to prove that the student has the necessary skills. My blog is not about the content of varying and competing courses but some considerations that I recommend be thought of when evaluating different training options.

Firstly, technical training on how to use RA software tools is essential. There is little value in spending money on a tool that no one can use, or as is often the case, is not used to its full capability. No need for anything more on that.

We all know that it is people that use tools and need to apply their thought processes on the best way to achieve the outcomes that are expected of them.

Training in revenue assurance often seems centred around ensuring that the students have an adequate understanding of how a telecoms operator is “put together”. By this, I mean ensuring that the underlying technology and platforms are understood. This is certainly valuable but I suggest any RA training you undertake needs to go beyond this and if it is too weighted in this area, then it is more telco 101 than RA training.

RA training often discusses known leakage points and what to look for. It’s great to hear that operator ABC lost millions by $ by a wrong configuration but there’s a reasonable chance that the configuration is specific to that operator and not so relevant to you. Case studies are always of interest but for anyone other than absolute RA novices, we know how leakage can occur. Simply, we lose call/event records, we misalign services provisioned to those billed and/or we charge the wrong amount. Most leakages seem to be some variation of these. What you want training to do is improve your efficiency and effectiveness at finding revenue leakage.

So how can this be done? I don’t have all the answers but here’s some thoughts:

• ensure that the training encourages you to think about you own operational situation, as opposed to a generic model of a typical telco. For example, calls can be lost but what are the relevant systems in your organisation, what are they meant to do and what might go wrong. With that knowledge, you already have the start of a scoping document for some work.
• model what good RA work looks like –  how long should it take, how will precision be ensured, how is the programme managed, how are updates communicated, how are outputs prepared, what will be done to fix any identified leakages etc. This includes understanding what the challenges are to undertaking RA work, and highlight, very specifically, how these can be overcome.
• how do you define a programme to prioritise your efforts. We all know our companies are large and we could look everywhere but, depending on your priorities, where should we invest our time? For example, if you are chasing revenue, then generally, complexity and/or manual processes lead to the largest losses. Training should ensure you understand some of these principles and apply them to your situation – what is complexity to you (in the design, the build, in the implementation, in what CSRs are meant to do)?

To summarise, when you look at training options, be wary of training purporting to be RA when it may be on other subjects and seek out training that defines better how you can specifically improve the quality and quantity of your RA output.