It’s been a while since my last post, and the reason is that I’ve been quite busy recently with some interesting developments in Revenue Assurance. I have started to notice a significant shift in the operator’s attitude to leakage detection and correction.
There used to be a time (long, long ago in a Galaxy far, far away…) when the most important item for most RA teams were a set of crisp and clean dashboards that tell them “Hey Mr. RA Analyst, I’m working on dimensions and measures which have told me that you have 0.3511% leakage in product SuperSaver199 between the mediation and billing”. This used to suffice the needs of the RA analyst and he goes forth armed with “0.3511%”, “SuperSaver199” and “Mediation vs Billing”, and reports the same to his network team. Naturally, Mr. Network Guy wants a sample set of records so that his team can go about plugging the leakage. Unfortunately, Mr. RA Analyst works with dimensions, measures and dashboards only…so he sets forth on another activity (a search for the Leakage Grail) where he tries to pull out the raw data from the network records that corrobrate his claim. While he proceeds on his quest for data, the leakage continues unabated. Furthermore, his view is a bit myopic as the leakage might have been analyzed from a data transfer angle, but might not have been investigated from a “Impact to customer” angle.
What I was trying to illustrate in the true fictional anecdote above is the need for RAW DATA and established workflows. I am a great believer in getting down to the raw data and validating the actual data flows between interworking systems and validating against expected business process flow. Recently, I have been interacting with operators who share the same view about working with raw data, as opposed to running a RA department based on pretty dashboards and metrics from datawarehouses.
There is a visible paradigm shift in the way that operators are setting up RA processes in the Asia Pacific side of the world. The business process of leakage reporting has matured significantly, where every issue needs to be reported with the associated “Proof From Network”, which usually constitutes the discrepant/mismatched records. The network and IT teams even tell the RA team what particular fields they expect in the report for their cross-verification. I have published a post earlier where I discuss the importance of leakage reporting AND tracking. We are now seeing cross-functional teams which have been tasked with ensuring that issues raised are being closed in a timely manner. When I say cross-functional I’m talking about workflows that involve first level of investigation by the RA team, impact analysis by a finance function, technical cross-verification by IT, corrective action by a network task force and rectification corrobration by RA and IT. I like the approach primarily because there is a shift in the way RA is now viewed as more than just a “Finger-Pointer”.
The emphasis on being able to “drill down” to the raw data is something critical to the success of a RA function, because here we are questioning the fundamentals of the underlying data, its behaviour in various complex network systems, the impact from a technical/financial/customer/service angle and so on. The natural evolution of an multi-impact view of leakage analysis is growth from a mere System healthcheck validation to something like Customer Centric Revenue Assurance. I read an interesting article recently about the audit process at Verizon. The RA team at Verizon has been been working on some interesting approaches to RA, and in the below link Kathy Romano of Verizon (Head of the RA function) talks about the importance of solid workflows and questioning the underlying data.
Great post and link!
I was amazed by one of Kathy Romano’s statements:
“Altogether in our RA function we have between 500 and 600 people”.
I have never seen or heard of such large numbers before. Is that really representative of other Tiers 1 operators?
500-600 is a huge team!!! It shows how serious Verizon is about Revenue Assurance and impact to end-customer.
However having said that, such a large RA team is unheard of. One thing we need to remember is that Kathy is head of RA and Billing at Verizon. Maybe in the team size she has included not just the core RA team, but the interacting teams like IT, Finance, Risk, Network etc. who directly talk to RA and provide inputs/outputs (eg. financial assessments, corrective actions, truck rolls). The key thing here is that in Verizon, as per my understanding, the workflows between different functions are fairly tightly coupled. So a person might not be part of the core RA team but might be an integral member of the RA function.
Well put Ashwin. I’m also very lax in contributing to this great site but after reading your post was motivated into action. Kathy Romano is certainly one of the movers and shakers of the industry but I want to focus on some of the points you raised.
RA is definitely changing. I get the feeling it is no longer the analytical, deep-diving, dark art it used to be. After all, anybody can pay to become a ‘certified’ RA professional overnight by attending a GRAPA course. ;-)
RA is melding under the broader ‘Customer Expereince’ banner, best described as RA marries Network Management but also has a fling with Customer Care. I’m not sure if it is intentional but it seems to be a byproduct of the much-mooted merging of BSS and OSS as we roll out horizontally-structured NGNs.
To get a holistic view of a customer and make sure they are getting what they expect we now want to monitor their whole lifecycle. Was it is easy for them to place an order, was it provisioned correctly, did the service work first time as expected, did they get billed correctly, is it continuing to work and is the customer still using it? If no why not? Hmmmm, everything here impacts revenue, but it needs info from the network elements and other BSS and OSS processes to be effective, and all in real-time, of course.
On the cost or supply side, it’s much the same story with operators now having to buy content, services and applications from somebody else and monitor that they are getting what they pay for as well as collecting the expected revenue to cover what they are buying from third parties. One small error here, one either side, can cost big dollars. When I last spoke with Kathy Romano she highlighted that this was now squarely in her domain.
I think this may be the new world of RA – accounting/audit meets network management, producing a child called ‘Customer Experience’. Only when things go terribly wrong will they call on the bastard son ‘Drill-Down Analytics’ to get things sorted.
I remember when preparing a process work flow started from alarm detection ,verification by RA team, handover risk to business owner and get fix by technical owner. And each process work flow is unique to certain business streams because of different approach apply for example prepaid and postpaid. At each stage of the workflows, there is a KPI to meet, log and report . At certain level, we make RA as part of the technical’s owner KPI where the value are quantify in dollar $$.
If we look into the TMForum maturity level 4 and 5,there is a requirement to embed RA operational function to business owner and technical owner on respective business streams. There’s come the 500-600 people involved in RA activities.