Abstraction Reactions

In the telecommunications industry, time is money in a very literal sense. Even those with the most basic understanding of telecoms know that. In one of my former jobs, I fondly remember tormenting an audit junior from a Big 4 firm that was tasked with the important job of identifying weaknesses in my revenue assurance strategy. She kept stressing the importance of not losing minutes, so I kept asking her where I would normally find these ‘minutes’ she kept referring to. Poor girl, she lacked the training to even begin to formulate an answer. There was no talk of protocols to transmit files or definitions of the fields in call records. Instead, she just kept saying that minutes could be lost, as if minutes were sheep and I was the shepherd. She simply did not know the subject matter or the terminology, which was why it was so easy to give her a hard time. It tells you a lot that the Big 4 employ audit teams with such high-level briefings that, when placed under pressure, they can be cracked so easily. Do I feel bad that I was mean? Not really. Time is money, metaphorically as well as literally, and telcos pay for the time of their auditors, and for the time of staff like me as well. If I had really wanted to tear the audit junior apart, I would have pointed out that her questions could be best described as value-add because there was no connection between them and the reliability of the financial accounts (if you lost data on transactions, it would be prudent not to recognize the revenue, hence leakage may impact the final revenue number, but does not impact the integrity of the final number). And there is not much value added by an auditor who asks questions without being able to properly understand the answers. Even so, I finally relented and took pity on the poor girl, explaining what CDRs are and where they come from, so she could write up her pathetic management letter points and bluff a little more persuasively at the next client she visited.

Part of the problem with telecommunications operations, like any complex subject matter, is that the abstractions people use to understand the topic are not going to be consistently reliable. The poor audit junior knew that losing minutes was bad, but had no idea that the minutes she was talking about are an abstraction based on the difference between two data fields – start time and end time – and that a record of a call is itself nothing but a stream of data more or less bulked up into files of whatever format on whatever disk space associated with whatever computer. Not knowing that, the audit junior was obviously going to struggle to go into detail as to how these minutes might be lost. Her abstract model knew that minutes started somewhere, and ended somewhere else, but she had no idea of what they were or how they might go missing. She also was going to find it hard to conceive of the many ways that minutes can go missing. She could understand losing or corrupting data, but would always have conceptual blind spots when it came to the difficulties of knowing whether you recorded the start and end time accurately to begin with, or the cumulative loss if you chop off some digits in the trade-off between processing burden and precision. For me, abstraction is the single biggest problem for revenue assurance. Lots of people want to talk intelligently and confidently in terms of abstract representations of what can go wrong. The problem with most of those abstractions, even if very intelligent and given by someone very confident (unlike the poor audit junior) is that they ultimately wil break down. Abstractions may obscure vital aspects of what is happening in the detail, or skew the perception of risk so that effort is mis-directed. I have been in more than one telco that has put disproportionate effort into assuring usage compared to non-usage, because people could imagine what might go wrong with usage but not with non-usage. Similarly, when checking usage, people tend to put disproportionate effort into the problem of getting data from one place to another, and forget about problems like assuring whether the data was any good in the first place. Abstraction is vital for communicating and for having an overall understanding of the domain where risks are treated according to priority, but poor abstraction leads to poor decisions. Like so many things in life, the devil, with revenue assurance, is in the detail.

There are layers and layers of abstraction to telecoms, of course, and I use the word layer deliberately there. Knowledge of detail is essential, but knowing the detail of the layers OSI architecture, or of the COSO framework, or of the eTOM, is only going to get you so far. In the end, they are all useless unless you can also understand the connections between those abstractions and the systems and practices in place at whichever telco you are dealing with. I fondly remember another group of auditors, who were employed to check the accuracy of retail billing. They spent a day asking their questions of whatever poor souls they decided to pick upon. At the end of the day, they came to the conclusion that they had serious concerns with the precision of the records used. That resulted in some serious concerns on my part – about the competence of these auditors. After a couple of pertinent questions about the systems at fault, it transpired they had wasted the day reviewing records only used for interconnect billing. Although the auditors made a gross error in performing their work, on one level it is easy to understand. They got so tied up with the detail of the systems they were looking at, they forgot to ask some themselves some basic questions about how those systems related to their audit goals. Detailed knowledge is fundamental, but there is no individual is going to have enough knowledge to cover all aspects of revenue assurance. The trick is to be able to apply a useful abstract model, and to bend and change it to reflect the real and detailed facts. That requires professional scepticism, not only of the statements presented as fact, but also of the abstract models used to organize those facts. The two are in constant tension. The abstraction may lead to questions about the details, and the details may prompt questions about the suitability of the abstraction.

There is another aspect to abstraction that people sometimes skirt around or conveniently ignore. Abstraction goes deeper and higher than just the technical detail of how systems and processes work. If you want to get really sceptical at the detailed end of revenue assurance, you end up needing to understand things like the fetch-decode-execute cycle of CPUs or the speed transmitting radio waves through the air or electrons down a wire. I have seen people talk, at a supposedly detailed level, like these things are constants for the businesses they are talking about. A moment’s reflection should have satisfied anyone with competence that they are not. Switches are designed specifically to deal with high volumes with little variance in their performance, but their performance does vary according to load. The laws of physics may be universal, so electrons and radio waves all travel at the same speed, but that is not the same as saying that transmission always takes the same amount of time – transmitting over a longer distance obviously takes longer than over a shorter distance, but I have seen supposedly detailed and scientific technical audits that blundered by stating that the times, and not the speeds, are a constant. At the other end of the scale, we must not lose sight of why we do revenue assurance. Somebody needs to see a benefit, be it customers or shareholders. Yet many abstractions of revenue assurance simply come up with some hideously and unjustifiable assertion about what all customers and/or shareholders want, or worse still pretends that all stakeholder goals can be neatly and conveniently aligned. That may help revenue assurance vendors sell their products, with taglines about improving customer confidence, increasing revenues, and achieving regulatory goals as if all three are harmonious. However, only a simpleton (or somebody not stepping back and taking a moment to think about what they are doing) actually believes that the priorities of all stakeholders are identical and are equally satisfied by the same choices. In all choices there will be trade-offs, and an oversimple perspective on what stakeholders want only causes revenue assurance people to persuade themselves of their success, whilst failing to recognize the compromises they have chosen.

Building up revenue assurance abstractions to link the most excruciating detail with the most pervasive understanding of stakeholders is a never-ending process. It requires perpetual addition and refinement. The irony is that revenue assurance is about spotting and stopping errors and wastage, yet without the right abstractions, you may not be able to communicate about them, or even conceive of them.