I started writing a comment to Ashwin’s blog but as it was getting too long, I thought I should just start a blog.
From my perspective, there is little doubt that detailed analytics are essential to be undertaken by RA teams and should be the primary activity. Dashboards serve some value in identifying trends but I suggest that any movements upwards or downwards in trend lines (such as the 0.3511% in Ashwin’s email) become almost impossible to justify as leakage. Let me explain my views:
First – what is the right baseline value to begin a dashboard with? Assume every day for the last 3 years, 100 calls come into a mediation device and 70 come out. So you set a baseline at 70 and if this drops to 65 then you decide to follow up with the mediation people. Great theory, but who says 70 is correct in the first place? It may well be that there is a leakage in the 70 and in fact it should have been 80 all this time. The only way to know where to set a possible baseline then is by doing a detailed analytic. So let’s now assume we did that and we know it should have been 80, we’ve fixed the mediation device and we start seeing 80 go through every day. Great stuff: we found 10 lost calls, fixed that issue (hopefully got a pat on the back), and are now monitoring every day just in case, this drops back to 75 in which case we will be on the phone and get that problem fixed as well. Two weeks later, and the volumes hit 70 and they stay there for the next few days. You’re on the phone saying something is wrong, no-one believes you and ask you for the call detail to prove it. You do the analytic again and find that 70 is the right volume as new products have been introduced and the mediation device treats them differently, or there was more of a particular call type in that time period due to a marketing promotion, or…etc etc. My point is that the reasons could be endless and setting a good baseline dashboard value would only be possible in a stagnant, never changing, environment – not really well suited to telco then. And if, every time you called out “leakage !!!” when there was some other change you would be 1) busy tryng to prove this and 2) lose your reputation for integrity and the time of the people who you keep raising alarms to.
Second – many revenue leakages reside in the less than 1% bracket. Sure, there are some massive ones and these are the ones that we talk about at conferences or hear of in training but the normal reality is that most are so small, relative to the revenue pool that a dashboard would find impossible to discern from other activity (similar to my point above). But if you have a $100M product, then finding $1M is a good result but to find it is likely going to need detailed analytics.
Third – only with some detailed data can you go back to the business area and tell them what specifically to consider addressing. Analysis may even also know what to fix specifically. Analysis can also tell you the extent of the issue, making a quantification of the total impact, more easily achieved and this can help drive prioritisation of resources to address this, relative to all the many other competing demands across the company for money and people’s time.
Lastly (for now anyway) – the cost and effort to maintain a RA dashboard that adapts for all the business rules and changes that go on in a business would be very high. In fact, I would contend that it would be almost as high as putting in the operational system changes that it is meant to monitor. Why? to keep it current of all network and IT changes going on would not be insignificant, add in all pricing changes, campaigns, what the competition is doing and how to account for the behaviour of people is practically impossible to model. To make a point, how many times have I heard stories of RA managers raising alarms at a 50% drop in traffic over a 2 hour period, only to later realise that this was due to the nation being absored by a football match (and the RA manager probably was watching on TV as well).
Do I think there is value in RA dashboards then? Well, yes but they have to have some key attributes:
1) data presented has to be summarised correctly from accurate underlying data (avoid garbage in – garbage out)
2) “alerts” have to drive an action (e.g. do analytic, phone billing)
3) more true positive alerts are generated than false alerts (the challenge of our fraud system friends as well)
4) data needs to be delivered in a timely manner (no point finding a leajage after everyone else has)
Putting that into play though requires time, thought and effort. And that effort could be spent on doing a detailed analytic. Getting the balance right is the challenge !!!
Hi Mike,
Excellent post!!! The specific line I’m going to focus on is “Getting the balance right is the challenge !!!”, because I find this to be key.
A lot of the RA Managers spend a considerable amount of time in getting the dashboards perfect. “From my perspective, there is little doubt that detailed analytics are essential to be undertaken by RA teams and should be the primary activity.” – Mike hits the nail on the head with this statement.
Analytics are key. Ability to understand the underlying data is key. Ability to justify leakage in tandem with the existing network process flow is key. When we try to create dashboards for everything, we are looking to fail. The reason is because the underlying data is very dynamic – products change, rates change, routes change, subscribers change…everything changes.
I personally believe in guiding dashboards – the rest is investigation and effective workflows. Nothing closes a discussion faster than hard evidence…in this case, the relevant call detail records.
Hi Ashwin,
Talking of detailed analytics being quintessential for RA teams; what are the kind of competencies one would expect of RA and its team members. I have always believed that RA analysts/Managers should have stronger technical capabilities than just financial knowledge.
Majority of the anamolies one would come across in present day networks are more technical in nature. Do you recommend a RA department within technology or finance or an operator wide spread out approach with key stakeholders in each department?
Best,
Dinesh Ramaswamy
Hi Dinesh,
This is the question of the century!!! Here on talkRA, we have debated on this exact same question (I suggest a read of this blog entry – http://talkra.com/archives/320#comments). Guera Romo, one of our authors, has done a lot of study in this particular area and I would invite her to add her inputs to this response. Suffice to say that all of us have seen varying requirements, from Finance controlled RA departments to Technology primed RA teams.
It is my belief that a centralized RA team with pre-defined interfaces to key stakeholders in different departments would be the most effective. The RA team itself would need people who are fairly adept at understanding:
a) Business documents pertaining to data flow and process flow within the core systems
b) Able to understand techno-financial impact of system inconsistencies and leakages
c) Telecom networks, not necessarily end-to-end, but have a working knowledge
From personal experience, I have seen that the RA process is fairly efficient in Singapore. I attribute their success to the modular process creation methodology that they follow.
For example, when a new product is being launched, there are multiple teams sitting across the table. One of the key watchdog teams is the RA team. In conjunction with the other stakeholders, each function defines a well-articulated set of measurements/tests they are going to perform and submit to other teams to confirm the health of the new offering. This approach will only work if there is a strong process that binds the data inflow/outflow between different teams.
Furthermore, the RA teams in Singapore make it their business to include network teams, billing teams etc. into their RA discussions. This has a very positive impact as different teams within the telco would now have a better understanding of what the RA team is trying to achieve.
I would not recommend a non-centralized team because I have seen that there is a dilution of focus and loss of synchronization on key deliverables. RA has such a wide scope that we often find disparate RA teams duplicating effort with no significant output. I would definitely not recommend that RA become a finance only or technology only driven team. These eventually turn out as an auditing function, technical or financial.
A key consideration for telcos, at least in my opinion – RA is not a annexe to the existing teams; It is a team with defined goals for its operation. What I’m trying to drive at is, the RA team should not be a sub-team within an IT function or a Finance function.
Dinesh – Would you agree?
Thanks Ashwin,
I did go through Guero Romo’s blog. Did get some inputs as well.
Apparently, the single biggest problem for RA Managers in terms of an operator wide spreadout approach is the stakeholder confidence in terms of integrity in detecting and reporting. Majority of the personnel in key departments tend to give a blind eye when the problem found would be associated with one self or within the concerned department; fearing the loss of employment, decreased performance review; directly impacting their individual performances and so on.
Companies mature enough to understand human errors and accept these errors while encouraging personnel is a tough call. I have advised many CSPs to create a reward and recognition program with the help of Human resource department; this way inspite of errors; individuals are still open and brave enough to accept and correct the anamolies. Ofcourse, errors incurring huge losses due to negligence, fraud should be dealt with more cautiously!