Last month I told you about a great article which explains some of the elements of the Telenor Revenue Assurance Program (TRAP). Telenor is an international telecoms group, with a controlling or minority stake in various affiliated national operations across both Europe and Asia. Recently I asked Einar Nymoen, Project Director at Telenor Global and the man who overseas TRAP, to tell me more about how Telenor Group tackles revenue assurance. Einar very kindly shared his insights and experience with me.
Eric: To begin with Einar, can you tell us a little bit about the history of the TRAP program, and its purpose?
Einar: We need to go back five years. We started in 2003 with what we call the Telenor Revenue Assurance Program, or TRAP. The idea in the beginning was to implement a common method for control development. We travelled around and ran what we called ‘implementation projects’ in the affiliates of Telenor. We had two aims with these projects. One was to set up RA organizations in the affiliates if they did not have one beforehand, and also to set up the first set of controls covering a specific focus area. After a while we gradually changed the focus from setting up new RA organizations to establishing the TRAP network, doing performance monitoring and such activities.
Eric: You wrote this article that was included in the TM Forum’s Revenue Management newsletter. It mentioned the fact you used some of the thinking that came from the TM Forum. Could you please explain a little about why you used the TM Forum’s work as part of your TRAP program?
Einar: We need to relate what we are doing to what is happening in the industry. I find the TM Forum very good as a frame of reference. More concretely, with the maturity model we wanted to benchmark ourselves against the industry. So in addition to is using the benchmark internally, we are going to join the TMF study.
Eric: Did you look at alternative sources for benchmarking and guidance?
Einar: We have been discussing benchmarking for quite some time. We followed the benchmarking activities in the TMF with the operational benchmarks. We decided we will not use those on the group level, but instead focus more on strategic KPIs. As I wrote in my article we combine the maturity matrix with what we call the Coverage KPI, which is the first one we implemented. The idea with the Coverage KPI is to measure what degree we have control over the value chain. This fits very well with the concept of the maturity model.
Eric: Do you apply the Coverage KPI and the maturity measurement across all the Telenor affiliates, or is it a voluntary activity where some may be in, and some may be out?
Einar: It has been voluntary. We have just concluded this round of benchmarking. Out of the eleven operators where Telenor has control, ten have submitted both for the maturity model and the Coverage KPI. The one not participating is in the process of establishing a centralized RA function, so it may be premature to compare. I am sure they will join the next time.
Eric: Is this the first time that you have done this, or tried to do this, across the eleven companies that Telenor controls?
Einar: No it’s not the first time. We have run the Coverage KPI several times, and we have had one previous round with the Maturity Model.
Eric: Are you looking to do this on a regular basis, going forward?
Einar: Yes. We will do this at least annually, it could be that we do this every six months. I think we need to do this several times before we really know what we are measuring.
Eric: And how much time do you find you’re spending in order to perform one of these reviews? Is it quick? Is it time-consuming?
Einar: It is a bit hard to answer that clearly. It takes time. If you take the maturity model, filling in the questionnaire would take maybe one hour or two hours. The first round of the maturity model we travelled around and visited the affiliates and did the assessment with the RA managers. In some companies it took four hours to complete. That was because we had a lot of discussions along the way. How much time is it taking this time? This time the questionnaire is more familiar; it probably is not taking that much time. My main main concern is that we set enough to analyse the results. Comparing the top line results is not that meaningful – we need to dig behind.
Eric: Sure, it does not give you all the answers. It gives you a starting point for looking at the broad picture and saying, “where do we need to ask more questions?”
Einar: Yes, to get full value we must use these results also as input for further analysis, to see if we can identify some common trends and also where we differ, and why we differ… to see if we can find strong and weak points.
Eric: It’s interesting that you mention where you differ across companies. Do you find that you are able to implement the same TRAP framework consistently across the different countries, or do you have to spend some time tailoring and modifying it for each country?
Einar: There are differences. The organizations differ and there are different cultures, but the main value chains are very similar. The TRAP framework is not extremely strict. It is a conceptual framework, and a description of some methods and tools which can be used locally without much adaptation. Just as important is to build common concepts and a common language to facilitate the exchange of information. One of the great benefits of the TRAP program is that we have a common language now for revenue assurance within Telenor affiliates. This makes discussions between the affiliates much easier and therefore more meaningful.
Eric: Just picking on that particular point of language, ‘coverage’ can mean so many different things to different companies, especially when you have a different idea of what your scope is, and you have a different range of products, or you have a different point of view on what Revenue Assurance should be doing. How did you determine what should be included within, and how to measure, the Coverage KPI?
Einar: We try to be as precise as possible. We have five main processes and a set of sub-processes, which define the scope from product development to collection. The other dimension is the products. The scope is defined by the combination of processes and products.
Eric: That would therefore be different for different companies then, because there would be different products in different countries.
Einar: The processes would be the same, but the products will differ. We use the revenues per product as a weight, to calculate the Coverage KPI. That means if, for example, in markets where prepaid is dominant, prepaid revenues will carry a higher weight than in other countries where postpaid is a greater part of the revenues.
Eric: Also in terms of defining coverage, is it possible with the way that you measure coverage, to actually get 100% coverage. There’s always an argument that there are things you don’t know you’re not covering, or things that should have been included in scope but which weren’t included. How do you regard that question of whether it is possible to get to 100% coverage.
Einar: Technically it’s possible. We use a five-step scale in the Coverage KPI, very similar to the type of scale in the maturity model, and we have defined a set of criteria to reach each step. So to reach level five in the Coverage KPI for a specific process, all the controls need to be in place. You need to have input/output controls, you need to have controls focusing on the process logic, you need to have controls focusing on the reference data used for that process etc. We also require that all controls are well-documented, and are part of a risk management framework, so it’s very hard to reach level five, which would give 100%. I do not see it as a target to reach 100% coverage for all processes. The interesting discussion is how good is good enough – which means relating control costs to risks and benefits. Defining the goal is maybe more important than focusing too much on the concrete output of the rating process.
Eric: Sure. You start off with a group-wide definition, but you work to understand what is specific and useful in each company.
Einar: We’ve had a quite interesting process. The first version of the Coverage KPI tried to define what should be the common core of revenue assurance across all the affiliates. We have changed this, and the present version of the KPI defines what should ideally be the total scope of revenue assurance. We know that not everybody will cover the whole scope, which means they will score less than 100%. So instead of defining the common core or the minimum, we are now defining the total scope of revenue assurance more on an ideal level.
Eric: There may be people who do go beyond the common core, and it’s worth giving them some credit, as well, when they do work that goes beyond the core.
Einar: Yes, and I know that this KPI is being used internally in some of the affiliates to set targets and also, actually, some of the RA managers have bonuses attached to this KPI.
Eric: So it’s used for genuine performance management of individuals then, as well?
Einar: It is, at least in some of the affiliates. This is a local decision, but I support it strongly.
Eric: If a company launches a new product, does that mean the coverage can go down in that company?
Einar: If they have a new revenue stream that is not covered by controls, then the total score should go down.
Eric: Your finding then, that there is this constant need for further work just to remain a level of coverage across the group.
Einar: Yes, and that is as it should be, in my opinion. The job is never done. We have changes to the value chain, changes to the products etc, and this should be reflected in the Coverage KPI’s. It’s the same with the maturity model. We have some examples now where some companies are scoring less this year than in the last round, because of reorganizations, restructuring processes etc.
Eric: You have to keep working just to stay where you are.
Einar: That’s also an important signal to management. You’re not at a level forever. You need to build new controls and to maintain existing controls, in order to stay at a certain level.
Eric: From your experience of the Coverage KPI, and the way it has been applied across the various Telenor companies, if you were going to give advice about the best places to put effort in, in order to increase the coverage of controls, where would you recommend people put their effort in to begin with?
Einar: If we were starting from scratch, the main focus would be on the main revenue streams – traditionally voice, SMS – the cash generators. That also gives the highest score on the KPI, because we are using revenues to weight.
Eric: Would you recommend that people try to gain coverage by doing things through automated reconciliations, or would you recommend that people start by doing more of a walkthrough between people to discuss and understand where the controls are in place and how they could be improved on a manual level . What would be the quickest way to increase coverage?
Einar: Again, if we are looking at a new operation, my recommendation would be to start with the main traffic streams, and to build automatic controls. Our approach is not to try to cover the whole value chain in one big project, but to work incrementally, taking one step at a time in smaller projects. The focus for a project is based on an assessment of risks and where the effect will be the greatest.
Eric: So you would favour even a new operator, with new revenue assurance, starting off straight away with building automated reconciliations?
Einar: Yes, that would be my recommendation. We have a slogan that says “Think Big, Start Small, Deliver Quickly”. We need to demonstrate that we are able to deliver results. This also means that we must start with the main revenue streams.
Eric: You mentioned you have different weightings, therefore different priorities, for different revenue streams. Is that based on the number of customers or the value of the revenues. How do you weight these priorities for the different products?
Einar: It’s the revenues.
Eric: Do you also therefore, cover costs at all in your Coverage KPI, or is just revenues?
Einar: We have extended the KPI to cover volume-driven costs like interconnect and roaming costs, and also dealer commissions and similar costs. I think RA should focus on the gross margin, and not only the top line revenues.
Eric: So it’s something that’s part of an ongoing discussion within Telenor, as to what are the limits of what’s included, and whether costs should be included in the scope of this work
Einar: We need to focus at least on the traffic-driven costs. That’s a minimum.
Eric: We have not talked about the maturity model and what you use that for. You observed in your article that leakages will go down as companies reach higher levels of maturity. Do you find that may sometimes cause a problem for justifying revenue assurance in companies that have a higher level of maturity – that the business case for revenue assurance may actually decline because of the success of having RA reduce the leakages?
Einar: Yes, of course when the quick wins are taken, and the effects go down, this becomes an issue. We have the same dilemma when it comes to loss prevention: the more proactive we are, the less leakages we will find. I’m not sure this is a question of maturity. In a mature organization we don’t focus only on the cash effects, but we need to find goodalternative ways to measure the contribution from revenue assurance to profitability.
Eric: What you’re saying there is that one of the things that makes a company mature is being less focused on the specific financial provable gains of revenue assurance, and moving towards the kind of work which, as you say, is preventative, or where you look at risk without always trying to link it to a straightforward financial benefit. The mature companies will do that, and will start to change their focus as a result.
Einar: That’s the process, but that’s also a very difficult process. One of my concerns is how do we really get a good measure of risk. If we were able to establish a good measure of risk, it would much easier to communicate to what extent we reduce this risk by establishing controls.
Eric: Do you find that there are patterns across the group, say with the way coverage rolls out is different between Asia and Europe?
Einar: It’s a bit difficult to really see. There is a difference in markets. There is a difference for example between prepay markets where IN and real-time rating is the big issue, and postpay markets where it is easier to get the money even if there is an error – in the prepay market it’s lost. Another example is that in some markets the sales channels are difficult to manage, in other markets these are easier to control. There are different risks in different markets and we need to be sensitive to that.
Eric: In some markets, say because of the importance of prepaid, or because of the difficulty of managing the collection process, it’s more important to be proactive… there’s more value to the company in being proactive and preventing things before they go wrong, because it’s harder for you to recover value afterwards.
Einar: Yes, and because of these differences, I’m very sure that revenue assurance has to be a local activity, it’s not something we can manage in detail from the group level.
Eric: The group level is providing a common framework to understand and to help and to share information, but it’s not dictating how to do the specifics in each country.
Einar: That’s correct.
Eric: Again, about specifics and making things specific – I remember a few years ago we were talking and you were, at that time, interested in modifying the maturity model and making it more specific to Telenor. Why did you decide not to do that in the end?
Einar: Well, we had that discussion, and I was in the process of starting up this modification but then I heard about the TMF [benchmarking] study. I wanted to join this study, which meant keeping the questionnaire as it was. The modifications I had in mind were mainly simplifications in the questionnaire. In some cases the questions are very long, and some of the answers are very long, and they are open for interpretation, which makes it difficult to compare. We have had long discussions about what is really meant by the alternatives. I would therefore like to get the alternatives more precise.
Eric: You should feel free to make suggestions. This is only version two – there’s plenty more numbers left…
Eric: … we can always have a version three or four. So please do make suggestions for how the questions and answers can be modified.
Einar: Yes, thanks, I will do that. And also, as I said to you last time, if we make modifications, I still want to make sure the questionnaire is consistent with the general one. I don’t really think we should have a Telenor-specific version that is not comparable to anybody else’s. We need to do this jointly.
Eric: Yes. Perhaps after the end of this TM Forum benchmark study would be a good time to get feedback – suggestions for how things could be changed – and to make sure altered questions and answers are put into the model going forward so that when we next perform the study, we’ll be doing it with a new common basis that people find easier and more effective. So it’d be great to have your input on that, Einar. So you’re going to participate in this benchmark study, then?
Einar: Yes, what I agreed with Gadi [Solotorevsky, TM Forum RA team leader] is that I am going to send the results from the affiliates to the TMF. The results will be submitted on a company level, so I have asked for an okay from each of the affiliates. I am glad to say that nobody has declined submitting their results.
Eric: A question on a similar theme – you mentioned in your article the importance of measuring the status of revenue assurance in the whole organization, not just the Revenue Assurance department. What would you say would be the main reasons for assessing not just the Revenue Assurance department, but the whole organization?
Einar: The value chains cover the whole organization. Revenue leakages often occur because of faults in the design or implementation of processes – especially in the hand-off points between department. Also, controls are carried out in many parts of the organization, not just in RA. In a mature operation, the RA unit will work in a ‘network’ within the organization. This perspective is in line with the maturity model. We have built this perspective also into the Coverage KPI. To get the top score, all controls have to be embedded in the line organization.
Eric: You have a very strong philosophical point of view there – that the detail of the work should, wherever possible, be executed by the business unit itself, instead of by the Revenue Assurance team.
Einar: Yes. That’s the ideal. But we also have another side of this coin. In order to really understand what the controls are showing, we need to understand in detail how the total value chain “works”. This requires a good understanding of how data flows in and between systems and processes in order to understand what is really going on. This is a competence that is developed by experience in the RA unit. Having this competence is unique and actually a very valuable asset to the company. This means RA must be “hands on” and not just auditors relying on the line organization to perform the controls. If RA only act as auditors, they will soon become irrelevant.
Eric: They’re the safeguard to make sure the detail is still relevant and useful to the company.
Einar: Yes. This is one of the dilemmas we have to live with and which is one of the reasons RA is so challenging – and fun to work with.
Eric: You want them to work together, to be close and to understand what each other is doing.
Einar: I guess that is the essence of it. It is easy to day, but not so easy to achieve in practice.
Eric: I’ve heard in some businesses a counter-argument to measuring the whole organization, which is “how do you work out what the RA team is responsible for, versus what everyone else is responsible for?” What would you say to people who have that point of view?
Einar: This will not be unclear if RA has a clear mandate and works within a clear framework that is understood and accepted by the rest of the organization. As we just discussed, control monitoring should ideally be performed by the line organization. RA may very well take on this task, especially the more complex controls, but this should be based on a clear understanding with the process owners. Also, regardless of who is doing the detailed control monitoring, the RA manager still has a responsibility for making sure that controls are in place for all relevant processes. One way of achieving this is that the roadmap for RA is approved by top management, and that the progress is reported back to top management. The Coverage KPI is an instrument that can be used in this process. If controls are lacking in a specific area, this will be reflected in the KPI. RA can use this as a basis for clarification of who should do what to cover this area and include this in the roadmap.
Eric: You mentioned quite a lot whilst we were talking about controls, you mentioned about the importance of work being local. There are different points of view. Some people I know are working in the industry and they are taking a group of companies and they run a series of automated reconciliations from one central place, from a revenue operations centre, on behalf of all the group companies. It sounds like Telenor is going down a different route. What is your perspective on that as an alternative way of doing revenue assurance?
Einar: As I have said before, I strongly believe that RA is a local activity in the individual affiliate. I also need to relate to the governance structure of Telenor as a group. Telenor is different from some of the other international players in that the organization is decentralized. I see some practical advantages in centralizing some of the concrete control activities, mainly from a cost perspective. But there are also some issues. If it is too centralized, there is a risk that the local managers will not relate to the results and that local variations will not be captured.
Eric: There’s two elements here. There’s fitting in within a relatively decentralized group like Telenor, and there’s also an element of making sure the results are understandable and can be used at a local level. One final question for you, Einar, you’ve used some of the TM Forum thinking to help devise your TRAP program. In terms of the future of the TRAP program, and in terms of the future of the TM Forum’s advice, where would you like to see the future for revenue assurance?
Einar: It’s a difficult question to answer. In the future, the traditional defensive controls will be in place, so the focus will shift. What we see in the market is that there is a shift towards new value chains, new ways of doing business, so the risk picture is changing. I think the main focus for RA will be to follow up on these changes and to adapt to the changes in the market place. It’s about focusing more on risks, more on prevention than the defensive controls.
Eric: Do you see ultimately RA being more and more aligned to a Risk Management function?
Einar: It has to have good relations, at least. RA needs to have its own opinion of the risks. A Risk Management function also includes other areas, not relevant to RA. The focus should be on the revenue streams, but RA will be an important contributor to the risk analysis of the company.
Eric: I’m very appreciative of your time today, Einar. Thanks again.
Einar: Thank you.