Risk Management and Revenue Assurance: separate, but connected

Today’s guest post is by Michael Lazarou of MTN Cyprus. In recent weeks, talkRA has run a debate about the relationship between risk and control, and the extent to which revenue assurance and fraud managers should place their work in the context of enterprise-wide risk management. Michael continues the debate, expressing his views on the family ties between risk management and RA.

The difference of risk management and revenue assurance could be summed up in one sentence by defining RA as an actual risk mitigating activity and NOT a risk managing function. Revenue assurance activities or controls are implemented exactly to reduce the risk of revenue leakage within a system that is both dependent on human interactions/communication and a complicated technical system that has to be properly configured to record and pass on information until it is billed. It is NOT managing risk, it is an ACTUAL implementation of the solution for a specific risk.

Therefore, my understanding of what Eric is saying, but also my personal belief, is that RA is one of many ways of dealing with one of many risks within a specific business (telecoms). It is indeed true that risks vary and can be dealt with in many ways – from taking out burglary insurance to enhancing your product portfolio. These are definitely not part of RA, although there is a wealth of information available within RA to aid the decision making (i.e. for products – usage, trends, credit controls etc). The point that is made is that RA has the quantification and the analysis of this can offer a lot of information to the business. Behind the numbers might be a problematic system, lack of resources or a cry for a process improvement. This is for management to see and decide upon.

Obviously a breakthrough in the industry can make most of RA controls completely irrelevant. This is why a good analyst is not the one who can fool around with an expensive toy but one that can take the information, dig in and analyse it. Analyse the issue and propose a solution. If not even this is available to RA then it is limited to donkey work. After the data and analysis is presented it is again clearly management’s call to decide where to allocate resources.

Being a hybrid function, with a demanding skill set required to do well (and in addition a high level of telecoms required) RA does seems to be very limited in both the type of work and its impact within the organization. As Eric alluded to, sometimes RA personnel might feel that it is a natural progression to general risk management – when, in fact, the relationship is not so strong. It is in the interest of RA to avoid this misinterpretation and to focus on delivering the best checks that it can. However, something has to give; RA should be involved in the product development, sign off product notes before they launch, it has to have a simple BI tool to present some information more effectively, it should be guaranteed reliable and complete data and allowed to make suggestions for process improvements. RA does not want any part in risk management, but it should be more than running a script and escalating exceptions. The infant grows into an adult whether the parent likes it or not – each stage has its benefits and drawbacks – but the parent needs to be involved and understand his/her child in order to help it along and allow it to express its full potential.

Michael Lazarou
Michael Lazarou
Michael Lazarou manages revenue assurance and fraud at Epic, a Cypriot telco, having joined their RA function in March 2011. His background includes a double major in Computer Science and Economics, as well as an MBA. Before being lured into the exciting world of telecoms he worked as a software developer.

Michael is interested to gain a better understanding of different aspects of RA and data analysis. He shares his insights on training courses he participates in with Commsrisk. Michael's accumulated experience of online training also led him to volunteer for the role of Coordinator of the RAG Learning online education platform.

5 Comments on "Risk Management and Revenue Assurance: separate, but connected"

  1. Michael,

    My hat goes off to you. It’s a very fine and concise statement of the differences between risk management and revenue assurance. I learned a lot from your perspective.

    The only things I know about risk management are the things that guys like you and talkRA’s High Preizt have taught me.

    I’m wondering if there’s an analogy here to the game of chess? Let me explore that notion a bit and get yours and the forum’s feedback on whether my leap into this fantasy is silly or makes a little sense.

    A telco’s top executives are the ones making the moves in the game of telecom chess. And if I understand Eric’s lessons, there are both defensive (protective) and offensive (opportunities-to-exploit) aspects to enterprise risk management.

    Now a company’s business units and leading product lines can be considered the more attack-oriented pieces on the board — the Queen, Rooks, and Bishops — who can strike deep into the opponent’s territory in one move.

    Meanwhile, the Knights — because they can only advance two squares at a time — are more defensive players. So we have the RA knight on the left and the fraud management knight on the right who together protect things in the business operating realm.

    The pawns too are mostly defensive pieces. Perhaps these can be likened to burglar insurance and fire sprinklers in buildings. And those pawns protect things outside the operational issues that RA/FM worry about.

    Now a chess master (like the current world champion Viswanathan Anand from India) strikes the perfect balance in strategy (or risk balancing). You can never become a world champion if you are too defensive: you need to aggressively take risks and exploit offensive opportunities so long as you don’t sacrifice the safety of your King.

    Coordination is also key: an RA team can’t be pushing its efficiency agenda in every corner of the business because it’s a waste of resources. The RA knight is best positioned to support the main attack thrusts that will ultimately win or lose the game. And that includes RA being in on the planning as new services and network-deployments are rolled out.

    Finally (and to complete my weird analogy) I think the RA Knight have its own game going on in another dimension — at a level below the main chessboard. And there, I think, RA has an analogous executive power that the higher level executives playing the main chessboard have little to no appreciation for.

    So I hope this analogy has some relevance to how RA and risk management fit together in the real world.

  2. I love the game analogy…

    To add a bit of reality check to the conversation, Revenue-Assurance will never be a risk managing function indeed. In fact, RA brings along its own set of risks. If the RA team is poorly staffed, or poorly trained, if the review-process is not well defined, etc., RA will produce recommendations that can potentially have damaging effects to the business. We’ve all read or experienced cases where the RA department thought it could save the company money by disconnecting services that were supposedly not billed for, to realize later-on that it genuinely disconnected people that probably shouldn’t have (a prime-minister… or an old-lady with a family member connected to the press)…and it ends up being a media-mess that the company has to deal with…
    RA is taking initiatives to request process changes…most of the time for the better…but with every change comes its own set of risks…

  3. Michael Lazarou Michael Lazarou (ml) | 31 Oct 2013 at 11:55 am |

    Dan and Lionel,
    Couldn’t agree more, both with the game analogy but also with the risk factor – nobody should have the power to make un-scrutinized decisions… I see the interactions between various departments as a means of achieving an equilibrium; which is always up for review as well. RA adds numbers to the mix in order to better inform everyone’s decision-making. As a fast evolving industry, telecoms will always be in a mode of adapting and learning. As am I. Therefore, the post and comments are based on my own limited experience and interpretation of “how-things-should-be” – my own 2 cents – nothing more.

  4. RA is Audit. Specialized Audit for telecom in this case. and like audit give recommendation acceptance and implementation is by management and process owners .

    Like statutory audit , assurance activates must be based of risk assessment. Thus RA has risk assess the telco value chain and determine where revenue or cost leakage can arise as per RA charter. In this case, Yes RA is part of risk management (Identify, assess and respond)

    By going by good general good governance practices RA is a specialized assurance function needed to respond to the telecom data and systems complexities that poses a deepened risk in revenue and cost integrity. This operation become the real risk owners and the responsibility to ensure revenue and cost completeness lies with them. RA will do independent audit and offer technical advise to those team on how to fix their mess. Finally RA Risk assessment can be use to report on overall finical risk exposure and offer report to validate operation report as the second line of defense.

  5. Michael Lazarou Michael Lazarou | 4 Nov 2013 at 9:27 am |

    Hi Patrick,
    Have to agree with you as well. And this is not because I am trying to be agreeable with everyone – each sentence I read I keep on thinking: “Yes but…”.

    RA dances between an implementation of risk management (which involves in most cases, scripting, SQL etc), audit, governance practices, analysis, data mining, reporting, risk assessment, recommending and suggesting best practices to departments from marketing to technical and billing… So it is audit, but on steroids – or very specialised at least.

    The only reason that we are discussing the definition of RA – I assume – is to clarify what the role, skills and daily work of an RA practitioner is…. doing everything from writing sql queries, setting up databases and scripts, analysing results from these, understanding billing-roaming-interconnect, creating reports, presenting reports, analysing top-ups, validating bill runs, checking provisioning, etc etc ..- all with an underlying element of continuous improvement in mind….. and in the end *nobody* knows what exactly you do… sometimes I even wonder what exactly it is I do :) (the latest talkRA post, mentions some of these points)

Comments are closed.