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.