The Zoom

Do you ever think revenue assurance is too broad? Do you sometimes feel that the list of expectations never ends? Or do you know people who work in revenue assurance who, in one sense, do a reasonable job, but somehow miss the point?

The recent post by Ashwin about macro-diagnosis and atomic checks links to the same themes that have inspired Güera and her academic research. That is very revealing. We are talking about two revenue assurance experts from very different backgrounds – a woman in South Africa with a background in psychology and a man in India who is an engineer – yet they are talking about the same phenomenon, one which I believe is unique to revenue assurance. I have my own pet name for the phenomenon. I call it the zoom, and it makes good revenue assurance quite unlike most other jobs.

You know about zoom lenses on cameras. You can set the lens so the camera sees everything from a distance. Twist the zoom, and suddenly it is focused on a tiny piece of detail. For similar reasons to why cameras have zoom lenses, revenue assurance practitioners need their own kind of zoom. Their zoom works with their mind, not with their eyes. They need to be able to stand back, and see the big picture. They need to do this to have a clear understanding of objectives, and to understand how a root cause in one part of the business leads to undesirable symptoms identified elsewhere in the business. Practitioners also need to be able to dive into the detail. They need to be able to analyse individual data records or understand specific lines of code. The zoom is one of the most important skills in revenue assurance, yet it does not have a proper name. Somebody with the ability to zoom in and out, who can comfortably shift between the micro and macro and see how they are connected, will be better at revenue assurance than someone who cannot. Yet you never see the zoom being properly described in job profiles. You may see job profiles that ask only for certain levels of analysis – sometimes micro only, sometimes macro only. You may see job profiles that ask for an unrealistic level of micro experience across too many fields, but fail to mention the real skill that is needed: the ability to learn, understand, and analyse the detail as and when necessary, which is not the same as knowing it all already. You may see job profiles that ask for big picture thinking, and links this to an arbitrary subset of detailed OSS/BSS knowledge; their prejudice about what subsets of detailed knowledge are needed only undermines the real requirement to have an open mind about where the root cause of problems may really lie. What you really should see is a job profile that asks for the zoom (or its equivalent when stated using the preferred terminology from science, psychology, engineering, or whatever other field is appropriate).

I doubt we ever will see a job profile that asks for the zoom, and not just because people may find the phrase funny and so not take it seriously. In telcos, some people (especially engineers) get paid a lot of money to know the detail. Other people (especially execs) get paid a lot of money to see the big picture. They are supposed to work together and deliver services that please customers and processes that satisfy the needs of the business. However, the job is too complex and they make mistakes. That is where revenue assurance comes in. Which is why revenue assurance people need to be able to work with detail and the big picture, to ensure everything is correctly aligned. But hang on… if people get paid a lot for detail, and people get paid a lot for the big picture, surely that means revenue assurance people need to get paid the engineer’s salary plus the exec’s salary ;) That is silly, of course. You are not going to solve the problems of big complicated companies by employing people to act like all-knowing gods, aware of everything that is going on at every level of detail and abstraction simultaneously. Tempting though it is to try to solve the problems of telcos by giving somebody the job of solving those problems, they will not succeed if the task is not humanly possible. If the solution was to train an RA person to know everything, at every level from macro to micro, you might as well train the people already in the company and save the cost of paying someone to do RA. The real solution is to employ an RA person who is skilled in communicating and working with people, and can use the skill to link the detail to the big picture, and highlight the inconsistencies. But that skill sounds a bit abstract, so employers get scared and ask for kinds of knowledge where it will be easier to test if the person already has it. They ask for practical knowledge like the ability to write SQL queries, knowing the components of a GSM network, or knowing the implications of different revenue recognition policies. This kind of knowledge is easier to check in an interview, but not relevant – knowing how things worked in the past is not a reliable indication of the aptitude to learn about things in future, or understand where complex systems have gone wrong. The point is not knowing about, say, GSM networks, but knowing how to obtain the key information needed for revenue assurance, and how to apply it. If you can do that for one kind of network, you can do it for any other. The same applies to business goals. One business may want to increase margins, another wants to increase customer numbers. A good RA practitioner will understand how to prioritize their work to best reflect the priorities of the business, which change over time anyway.

The zoom is about managing complexity. The skills needed to manage complexity should be what makes revenue assurance a unique practice. It is not RA’s job to know the detail better than another part of the business, or tell execs what the big picture should look like. RA adds value if it acts as a bridge, highlighting where the detail and the big picture are not aligned. Of course, people do that all the time as part of their jobs. What makes RA special is that it addresses the misalignments that are not obvious to anyone, because they are lost in complexity. To manage complexity, you do not start by trying to know everything. Knowing everything just means copying complexity, not managing it. To manage complexity, you need to be able to break it down, identify the essentials, and ignore the non-essentials. This draws upon a variety of skills, like being able to identify patterns in large volumes of data, or being a careful listener who can tell if person A said something inconsistent to person B. People who lack the zoom will inevitably look for root causes in the wrong places, or work counter to the real priorities of the business, or advocate solutions to problems that are far less efficient or far more costly than alternatives they failed to consider. The zoom is the essence of good revenue assurance. The reason why we need revenue assurance is that most people cannot or do not zoom from big picture to fine detail as part of their normal job. The failure to zoom is the blindspot for most businesses. That is part of the reason why we lack a good name for it. We need the zoom; the challenge is in seeing that we need it.

Eric Priezkalns
Eric Priezkalns
Eric is a recognized expert on communications risk and assurance. He was Director of Risk Management for Qatar Telecom and has worked with Cable & Wireless, T‑Mobile, Sky, Worldcom and others.

Eric was lead author of Revenue Assurance: Expert Opinions for Communications Providers, published by CRC Press. He was a founding member of Qatar's National Committee for Internet Safety and the first leader of the TM Forum's Enterprise Risk Management team. Eric currently sits on the committee of the Risk & Assurance Group, and is an editorial advisor to Black Swan. He is a qualified chartered accountant, with degrees in information systems, and in mathematics and philosophy.

Commsrisk is edited by Eric. Look here for more about Eric's history as editor.
  • Ashwin Menon

    Eric,

    Couldn’t agree with you more. However, you have mentioned it in your post, but I wish to re-iterate this particular point…What is the definable or rather quantifiable basis for the “zoom”? People tend to get comfortable in a particular area, and they tend to grow within that narrow space.

    I think the challenge for us would be to define the Revenue Assurance “area”. How would we inculcate the bend of mind required for RA? When you remove all the technical jargon RA is about pattern analysis, flows (for data/process), enrichment, tracking and correlations. In my personal opinion, being an engineer is not a pre-requisite for these bits (though it might help to some degree).

    The reason why people are not able to define the requirements for a RA analyst is because they do not have clarity on the gambit of revenue assurance. Where does it start, what do I need to identify, where do I look, who provides me clarifications for queries, how do I track progress, how can I measure movement on the RAMM etc? When we have controls to answer these questions, then and only then will the true requirements come to light.

    A long time back, me and a bunch of friends decided to take up fishing. We went all gung-ho and bought top-of-the-line carbon fibre rods, certified bait (I wonder where the bait took the course to get certified!!!), pro-fishing hats and all other kinds of paraphernalia. We didn’t know what we needed, so we got it all. 7 hours into our fishing trip, a couple of kids with bread on a string captured about 4 fish in the space of 30-40 minutes…

    Us with our pro-fishing kits had caught a grand total of…1 fish!!!

    Sounds familiar?

  • Lee Scargall

    Ashwin, I particularly like your post because the questions you pose are very similar to the questions I had to reconcile, as I moved in to management. Of course there are no right or wrong answers here, but what helped me define the “area” of revenue assurance was the inventory of leakage points across the sales to GL chain, as proposed by Stephen Tebbett. Eric and I subsequently co-wrote a paper, published on the TM Forum’s website, describing how we used these leakage points to standardise reporting across an International operator, and by linking the leakages to a control methodology we were able to enforce a more robust control environment.

    I also found the requirements of resources for revenue assurance could be linked directly to the TMF maturity index. Depending on where an operator sits on the maturity curve, will ultimately define the types of skillsets, and relative number of resources to get the job done.