A while ago, Nexustelecom issued a press release, boasting of how they had supported a revenue assurance project for Mobilink. They explained some of the factors that led to ‘overwhelming’ success:
Detailed test call generation within the system included… real-time test CDR Generation and Collection
By now, the more astute reader will have already guessed at what my gripe is. It is literally impossible to generate a record of an event after the event has taken place. You have to record what happened when it happened. And yet, without the slightest hint of irony, Nexustelecom tried to pitch the ‘real-time’ generation of a test record as being a benefit specific to their system.
Readers of the talkRA book, and specifically its discussion of the 4C’s model of assurance, will already appreciate how the the techniques for assuring the accuracy, validity and completeness of event record generation will depend on utilizing an independent data source for comparison. One of those techniques involves making test calls. Test calls are arguably an underused form of assurance. One reason why test calling is overlooked is the bias in how RA techniques are described and promoted by some vendors and by the organizations they control, like the TM Forum’s RA team. Vendors naturally dislike discussion of assurance techniques that are not supported by the products they sell. Whilst test call generation is a valid and reliable source of assurance, automated RA test call generation is only supported by a small group of niche vendors. Rather ironically, we often hear certain vendors spouting very odd opinions, bending statistics to suit their interests, and reprioritizing risks to complement their product catalogue. They argue that reconciliations should never be based on a sample, because of the unacceptable risk that would introduce. Meanwhile, they refuse to mention the possibility of a big gap in assurance coverage, due to putting too much emphasis on reconciliations, whilst failing to perform any kind of assurance relating to event record generation. Furthermore, assuring the creation of event records is almost always going to be based on samples, unless a telco is in the highly unusual position of having two independent records of every event they process.
I quite like test call generation. If a test program is designed well, it will provide solid and substantive assurance. Test call generation is unusual in that it covers the first C: whether an event was correctly captured. And depending on how test calls have been implemented, they can also serve a similar purpose to other RA techniques, by providing assurance over the second and third Cs: conveyance of data and calculation of charges. But let us be clear that it is garbage to say test records are generated in ‘real-time’. That is like saying a camera works in real-time. If I want to take a photograph of how something looks, I get a picture of how it looks when I use the camera, not how it looked the day before. That is just how cameras work. It is not a special feature. The same can be said of taking an audio recording of a conversation, though very stupid people might think otherwise. And the same principle applies to using a watch to tell the time, or a mirror when combing your own hair. It is innate to many tools that they work in the present moment. That such a basic concept can be described as ‘real-time’ only reveals how badly confused some people are, when it comes to understanding what they do.