Ashwin Menon

Ashwin Menon began his foray into Revenue Assurance as an implementation on-site engineer with Subex Ltd. Being trained in both Revenue Assurance as well as Fraud, he undertook projects specifically pertaining to Revenue Assurance. During the course of his career, he has been involved with various clients across the Asia-Pacific region, including Tier 1 telcos, for Revenue Assurance.

He has witnessed various leakage scenarios across telecom operators in the Asia-Pacific region, and has been privy to the different methods and controls that were implemented to target and plug issues in a telecom operator's value chain.

He is currently employed at Subex as a Senior Consultant for Business and Solutions consulting.

Etisalat is a behemoth in the world of telecom. With operations across 18 countries and total revenue well over 8 billion USD, it is easy to see why Forbes named Etisalat the most powerful company in the UAE in 2012. But in the midst of grandiosity, we see a humbling simplicity. Etisalat literally means “Communications” in arabic. This to me is not coincidence, but an insight into the razor-sharp focus of the organization. I recently had the privilege to see this focus at work in their Revenue Assurance & Fraud Management divisions as well.

I was invited as a panelist for the Group RAFM Forum for Etisalat. Our hosts brought us into beautiful Sri Lanka from the 29th till the 31st of October – and what an event it was!  In the broad, wide world of Revenue Assurance, I would call myself a “technician”, i.e. I’m interested in the nuts and bolts. Just like a building built on shaky foundations, unless people understand the grass root activities involved in RA, the management level reporting would simply collapse under scrutiny or pressure. I’m also a fan of RAFM departments who assure 30% of the key revenue chain with 100% certainty, as opposed to departments that attempt to cover 100% of the revenue chain with 30% certainty. It was so refreshing to see that the Etisalat RAFM team shared these beliefs, not just in principle but in actual operations.

Onwards to Sri Lanka! The theme of the event was “Bridging the Gap”. The first step to addressing any issue is to acknowledge the existence of the issue. I find that the most successful RAFM departments are the ones who have the courage to acknowledge their “gaps”. When operators speak plainly and openly, vendors and partners feel encouraged to strive to find solutions to specific problems; as opposed to throwing resources, software and the kitchen sink at the telco and hoping that the issue gets addressed. In my opinion, the Etisalat RAFM forum was able to strike the right chords and create a productive environment for all involved.

With that prologue, I found the theme very pragmatic. The Group RAFM team (presided by Francis Fernandes and Amit Agrawal) wanted the various Opcos that constitute the Etisalat RAFM function to collectively “raise the bar”, as it were, in terms of synergistic collaboration. Now, while I have heard a lot of talk regarding effective and efficient group reporting I have to be painfully honest and outline three things which lead to slow or non-adoption of group guidelines:

a)      Lack of relevance – Not all companies in a group follow the same reporting methodology across all lines of business.

b)      Lack of consistency – Companies publish group KPIs based on their “interpretation” of the KPI. This is largely due to the absence of standardized Published Manuals and Standard Operating Procedures being in place.

c)       Lack of transparency – There is a hesitation in posting information to a global over-seer, when the purpose and the consequences of such information is not clear.

I have to say that Francis and Amit have done a good job of laying the foundation to overcoming these 3 issues. To start off with, the group ideology is not forced onto the opcos, but is rather being co-developed with the active participation of leading minds from the various opcos. Amit is a seasoned RAFM veteran who has never shied away from rolling up his sleeves and getting his hands dirty. Therefore, it is no surprise to see a bottom-up approach being developed by his team. The working sheet has been disseminated to the various group companies, along with the underlying formulae and validation mechanisms. There was active participation and debate from various opcos who had studied and analyzed the various tools in trying to reach a group consensus. It was an enriching experience to hear from domain stalwarts like Ashish from Mobily, Taimur from PTCL and Ramadan from Atlantique Telecom both during and after the session. During the discussion itself it was evident that the local entities have a significant say in shaping the overall group RAFM Strategy and evolution. It convinced me that it is the support and knowledge of local entities which would ultimately drive the success of the group initiative.

Secondly, the Etisalat team has developed a series of “manuals” for prepaid, postpaid, interconnect, voucher and so on. These manuals talk in detail of leakages, the points of investigation, source systems etc. The manuals were sent to all the companies as well, for their feedback and criticism. Of all the actions that Etisalat has taken for maturing their RAFM practice, I found this the best. A junior analyst in Etisalat now no longer needs to depend on ad-hoc experts or “industry certifications” (dubious at best). He/She has access to a well-structured document which outlines their work universe and the associated information they need to do their job. While clearly development of manuals was an important first step in the right direction, the very active contribution and discourse by various experts like  Kusum of Etisalat Sri Lanka, Mohammed Gamal of Etisalat UAE and Alfred of Etisalat Afghanistan,would see Etisalat standing to gain even more from the evolution of these base manuals.

Lastly, Amit spoke of the structured link between group assistance and reported figures. This is very re-assuring to me as a local entity. The group is in essence telling me that in the absence of any scope coverage growth (either in breadth or in depth), the group will come in with assistance on how enhance my performance. This highlights the subtle shift from reprimanding non-performance to actually partnering with the local entity to drive positive value. This help would come in the form of on-request consulting with the group partners, performance assessments, training and learning from the Etisalat academy etc. This approach of group-wide enablement is an intelligent approach in fostering positive team-work and overall maturity growth.

All in all, the best advice comes from those who have put in countless hours in the trenches. Bruce Lee said it best when he said:

“I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times”

The wealth of operational and technical knowledge which filled the beach-side venue in Colombo was incredible. I don’t remember a single presentation which didn’t present a valuable insight or a new way to look at an old problem. With leaders like Francis and Amit collaborating with RAFM experts, and ably supported by their agile and nimble team of Raghuram Meda, Asem Abughazaleh and Suraj Kadbe , one can’t help but wait with anticipation for the outcome.

Bookmark and Share

Our story begins with Farmer Joe who has a beautiful daughter Janet. Farmer Joe decides to bequeath the family decorative pin to Janet on her 20th birthday. Now Janet, in a fit of unbridled joy decides to run around a haystack holding the pin towards the heavens. Suddenly,in a scene far too clichéd to be coincidence, she trips and the pin falls into the haystack…

Now begins the daunting task of “finding the pin in the haystack”. Janet is faced with a dilemma which would be quite familiar to RA analysts the world over – how do we find the pattern which highlights the root cause (or the pin, if you are a farmer’s daughter who goes by the name of Janet) within a world of millions of CDRs.

Of course, the solution is to cut the haystack into smaller cubes and search smaller segments for the pin. Does this sound familiar to you, my RA analyst friend? It should – because this is the way we attempt to find the root cause today. When your system presents you with millions of CDRs (or, God forbid, meaningless summaries), we tend to break them into smaller sets which have seemingly similar patterns. Then begins the back-breaking task of finding the elusive pattern that indicates the root cause – an endeavor that involves quite a few cups of strong coffee, pointless mails and shattered dreams regarding deadlines and analyst efficiencies.

But hey, this is how we do Root Cause Analysis the world over right? We would reduce our effort by managing the problem size right? Well, it gives me great pleasure to say that the winds of change are blowing. Today, I would like to introduce to you to a fundamental paradigm shift in Root Cause analysis which would effectively transform the way we do RA.

Let’s imagine for a second that Janet decides to find the pin by placing a powerful magnet over the haystack. Consider how much time and effort she saves, as compared to breaking the large haystack into smaller stacks. Consider how sure this solution is, as compared to the possibility of not finding the pin even after breaking the haystack into smaller segments.

Now imagine such a magnet for RA. A magnet that presents the analyst with all the hidden patterns in a problem set (discrepant CDRs). Imagine how this would change your day in terms of boosting analyst efficiency, achieving cost efficiencies as a department, being prepared to handle new and upcoming technologies and always staying one step ahead of the curve.

That magnet has a name, and its name is “Zen”. Subex recently launched ROC Revenue Assurance 5, and along-with RevenuePad (which my colleague Moinak would write about), Zen is one of the fundamental pillars of this ground-breaking solution.

Zen is an automated Root Cause Advisory engine which provides, for the first time ever, machine intelligence for pattern identification and presentment. What makes it revolutionary is that the engine is programmed to sniff out patterns with minimal involvement from the analyst. Give Zen two data sets, and it will tell you exactly why some CDRs in data set 1 are not present in data set 2. This also involves telling the analyst what percentage of the total data set can be linked to any particular pattern. Since pictures speak louder than words, here is a sample illustration:

The future of Root Cause Analysis

 

 

 

Zen is essentially a data analytics engine for ROC Revenue Assurance 5. Based on the discrepant sets identified as the result of an audit, Zen automatically fires up the pattern analytics engine. As Zen works on identifying the patterns, it also works on linking the patterns to specific CDRs (to ensure that an audit trail would be maintained). Finally, Zen presents the analyst with a comprehensive view of:

  • All identified patterns in the discrepant data set
  • Distribution of how many CDRs are linked to which pattern
  • Historic event indicators to further guide the analyst towards the root cause

Zen is keyed towards two “Intelligent” actions:

  • Pattern Analytics
  • Analyst Feedback integration

We refer to Patterns as “Areas” and the learning from past investigations as “Reasons”. Why do we need both, you ask? The answer is fairly simple – the same pattern (or Area) might have presented itself for very different “Reasons”. A simple example of Subscriber profile between HLR and Billing might clarify this point.

An analyst, on performing the HLR vs Billing subscriber reconciliation, finds that 20 subscribers on the HLR are not present on the Billing platform. Now, in the absence of provisioning logs, he/she might surmise that this is a simple case of provisioning error and forward the information to the relevant teams.

However, if the same discrepancy is seen next week for the same set of subscribers, it might be prudent to address the possibility of internal fraud as well. Here we see an example where the same pattern (20 subscribers are missing repeatedly in billing but are provisioned on the network) might be due to two distinct “Reasons” – Provisioning Error or Internal Fraud.

Zen helps you tie it together. Reasons are incorporated into the Zen engine based on “Acknowledgments” received from various teams. This helps to ensure that “False Reasons” are minimized. In this manner, Zen becomes a repository of Analyst intelligence to address the world-over issue of Knowledge Management in RA.

Zen is a virtual analyst who never sleeps, eats or goes on vacations. For sure he will never leave the team (taking his accumulated knowledge with him).

In conclusion, I want all of us to take a moment to step into Janet’s shoes. The pin is in the haystack, and the stack is getting bigger and bigger all the time (due to burgeoning volumes and technology/product complexity). The timelines to find that pin are ever-shrinking, and cost reduction is the call of the hour globally.

How is your team planning on finding that pin?

 

Bookmark and Share

In the world of Revenue Assurance, we see the rise and fall of champions and arch-enemies galore. I would dare say that Avatar would have been equally entertaining if we replace the characters as:

a) Na’vi – Home Grown RA system champions
b) Humans – External RA system champions
c) Toruk Maktur – The silver bullet solution enthusiast

Essentially, on the home planet (Telecomora), there is an ongoing war between the humans and the Na’vi. The Na’vi want to feed off the land (indigenous software) and the humans want to mine the land for all its worth (external software). On one side, we have those who will not take more than they need, and on the other side we have those who will not need more than they take. At some point, the disagreement reaches a fever pitch and war breaks out (Business & IT – sounds familiar?).

During this challenging time, a hero rises – The Toruk Maktur. Initially, the hero is cloned to resemble the Na’vi (speak their language and convince everyone about TCO reduction and Operational benefits). He is inducted into their environment through an age old, mystic ritual, the origins of which are lost in the shroud of eons gone by – a.k.a. response to RFP. The hero learns the challenges of the Na’vi, while inadvertently learning to think like a Na’vi. All the while, he reports back to the humans regarding the potential chinks in the Na’vi armor (eg. Scope of coverage is extremely limited, assurance is not guaranteed, sampling won’t help them get a good night’s rest etc.).

While these discussions are in play, the hero realizes that sometimes, the silver bullet might need to be tinged in gray. He realizes there is no single solution which will cure all ailments and support both perspectives. Humans and Na’vi are fundamentally different – their beliefs, their cultures, their aspirations and even their KRA. How can he bring both worlds together?

This is where the movie ends. Agreed, it feels like I’ve conned the world into paying $20 for the ultimate buzz-kill – but then again, I do want to take revenge on James Cameron for Titanic (I find that movie inexcusable. I find that he made a Gabazillion dollars off that movie even more so).

There are a couple of plausible endings, which will be released in Disc 2, and the broad outlines are listed below. It would be interesting to see which one is the most popular:

Ending 1 – Fall in love with a Na’vi princess, and convince the Humans that we don’t need the whole solution, but let’s work together with a preliminary assessment which helps us gauge where the Na’vi solution might be inadequate and where the Human solution is required

Ending 2 – Fall in love with a Na’vi princess, but convince the Na’vi that the current Ehwa mechanism isn’t built to scale and would consume far more resources and Na’vi days than initially estimated. It would also help to tell the Na’vi not to blame the Na’vi project manager, because Microsoft Project Plan isn’t the primary skill expected on a world where internet connectivity is provided via a funky disco tree, and the USB interface is strange tentacles hidden in his ponytail.

Ending 3 – Fall in love with a Na’vi princess, but go to the CFO and highlight potential risk buckets which need to be addressed as of yesterday.

Na’vi princess aside (big William Shatner fan, in case you haven’t noticed already), each ending has its pros and cons. In Ending 1, we are attempting to forgo the big bang approach for a structured growth path into a comprehensive assurance umbrella. In Ending 2, we are highlighting the scenario where over-dependence on a functionally non-scalable system might skew all metrics which are reported from that point on. In Ending 3, we appeal to a higher power to unite the two factions to work together in a spirit of love and co-operation towards a higher goal which benefits the entire planet (hopefully, unless the Toruk Maktur in this case is a weasel).

Now, dear audience, I would like to know which ending has the most production value. Which is the path you have seen most taken? And of course, the grand mystery remains – who is the Na’vi princess?

Bookmark and Share

Due to overwhelming demand to explain the statement “Frankenstein was most probably an RA vendor” (well, not really, but it helps with a little thing I call my ego), here is the follow up to the statement.

Some stories I have heard about RA practices and the gambit of RA are incredible. I have put together a choice selection for the perusal of TalkRA’s esteemed audience. What follows is a set of activities which are apparently being performed from the RA system:

a) Dealer Hierarchy Management (not assurance, actual hierarchy management)
b) Incentive Analysis (again, not assurance but actually recommending how incentives should be structured)
c) Margin Analysis & Accounting verifications (and poof, there goes the product & finance teams)
d) Be a parallel billing platform (as a redundancy, not completely in jest)
e) Make coffee for the analyst while playing “Serenade for Strings in C major, Op. 48: 4th movement, Finale by Peter Ilyich Tchaikovsky”

Now, anyone who has read Mary Shelly’s Frankenstein would remember a turning point in the story where Dr. Frankenstein, after spending countless hours in morgues, suddenly unravels the mystery of what animates the organic mass which is the human body. Of course, like any scientist of questionable intentions (as all scientists in novels are required to be), he decides – “Hey, why don’t I collect and collate bits and pieces from deceased people and see if it can be brought to life”. And the rest, as they say, is history.

Do you, perceptive reader, see the parallel? What happens when RA is misunderstood to be a cover-all solution? What happens when RA goes beyond assurance and starts sitting within the core business chain of a Telecom Operator? What happens when a core RA team demands non-core functionality from an RA system? Where do we, as conscientious RA professionals, draw the line between true-blooded assurance activities and core systems monitoring, maintenance and redundancy generation?

From a parallel perspective, let me share what I have learnt about Internal Auditing. From a paper by Mr. P Sudhir Kumar, I have seen that it is important to not only highlight the “core roles” of a team, but it is also important to identify “legitimate roles with safeguards” as well as “non-core roles”. I am of the belief that this is a lacuna in the current RA atmosphere.

 

Frankenstein’s Monster turned out to be a creature in search of his true identity, and in its search, it made the life of its creator hell. By attempting to make an RA solution which is not focused on core assurance, the risk a vendor takes is trying to step outside their domain competency and of course, the risk to the telecom operator is a half-baked solution. If the vendor has the necessary breadth of knowledge in parallel product lines to support additional specialized functionality, then I suggest go right ahead. If not, then remember, the monster takes your name, as it happened to Frankenstein, and drags you down with it.

A simple recurrent phenomenon to demonstrate this fact is the Rating functionality within RA solutions. I personally recommend against my customers from walking down a full-blown, 100% re-rating + discounting + billing approach. There are various methods to intelligently sample rate-plans and ensure a cyclic (or periodic) coverage. Such methods can be performed either on a Subscriber sample basis, or a regional basis, or a rate plan set basis, or ad-hoc sampling basis etc. The advantages are numerous, but to list a few arguments in favor of sampling:

a) Do you really want to maintain 2 parallel rating systems? For true rating assurance, we should never copy the setup directly from the billing systems, for in this case we are merely replicating the error. We should ideally re-enter the rate plans in the parallel engine with an understanding established about what the marketing tariff plan means. This means that every rate plan which gets edited/added/deleted etc. on the billing platform needs to be maintained as such on the parallel engine as well, if we walk down the 100% re-rating and billing path.

b) Do you really want to replicate the hardware which has gone into your billing platform? RA systems will not magically reduce the rating & billing hardware to half. If you want full-scale re-rating and billing, the same amount (or marginally different amounts) of hardware would go into the RA system rating platform as well. Instead of using it for only rating, I would personally use it for future expansion areas as well as powerful record matching functionality on a bulk data basis. But hey, that’s just me ;)

Perhaps I am being contrary to popular belief, but RA vendors do genuinely have the customer’s best interests in mind. It definitely suits us to have happy customers. This is why I believe, personally of course, that instead of saying okay to every requirement; it is beneficial to understand if all checks and balances requested are truly required. The last thing any vendor wants is to let Frankenstein’s monster loose…or do they (insert sound of maniacal laughter, to the background of wolves howling and rolling thunder)…

Bookmark and Share

Again, I have been MIA from the TalkRA roster for quite a while, but the truth of the matter is that I have spent the last year in a parallel world. Of course, there might be some among you who decide to prove that this is not true and you saw me in a conference or a customer meeting or something, but rest assured, that was a doppelganger I employ from time to time for tax reasons (apparently, slipping into an alternate dimension doesn’t exempt you from paying taxes).

Now in this parallel dimension, many things were the same as in our world, but there were some glaring changes which literally leap out at you. To list my three favorite aberrations:

a)      Revenue Assurance is now incomplete without a minimum of 80,000 checks

b)      TMF is for hobbyists and there are no real RA standards

c)       RA is now ruled by “Industry Buzzwords” as opposed to real work

My dad never tires of reminding me about how his generation was the best that ever was or ever will be. Reason, you ask? Simply put, technology and quality of life took a quantum leap within a span of 50 odd years. His generation saw radios with diodes and mobile phones which looked like a car radiator. Air travel was something Aladdin and his buddies did. His perspective is that today, due to the ready availability of everything, we are jaded. I didn’t really buy into his viewpoint till last year.

RA has steadily become a cover-all application. There was a time, in my humble opinion, when RA was about protecting the bottom-line. It was genuinely about covering the bases and making sure that the revenues you deserve as an operator was landing squarely in your pocket. Furthermore, it was about making sure your pockets didn’t have any holes. Now that RA systems are a dime a dozen (here, I lose all credibility as a vendor), the focus has been diluted somewhat.

It is again my opinion that when a RA practice starts out, it is important to define your RA coverage based on what impacts your business the most. My logic here is that, when a new system is being implemented, it is important to show the benefit of the system as soon as possible. The idea being sustained ROI helps in gaining management support for when you want to expand the remit of the function. Personally, when I am called in for a consulting engagement, I follow an extremely simple process, defined as follows:

If the size of the RA team is 10 people, and as a vendor I recommend 120 daily audits, there are a couple of things which would happen:

a)      The RA analysts would grow increasingly frustrated by the bottomless pit which is their daily case-load

b)      The RA managers would get increasingly frustrated by a system which keeps them from their families and forces them to live in caves without a hint of daylight for months on end

c)       The team decides to march to the vendor headquarters at night with pitchforks and torches to have a “Conclusive Discussion” (P.S. – On a related note, Frankenstein was most probably a RA vendor, but more on that later)

It is important to understand the “Boundaries of Efficient behavior” as I like to call it. Boundaries do not refer to only one or two items, but the universe the RA team operates in. I would break it down to the following items:

1)      Size and experience level of the RA team, including future hire

2)      Operational Expenditure from IT to support the RA team

3)      Crystal clear reporting cycles with well-defined action paths

Just to be clear, I am not against a large RA scope – I merely do not recommend it when you start out. Like riding a bicycle, any “investigation heavy” function like RA needs a bit of a teething period during which a Plan of Action and Standard Operating Procedures get purified and cemented. Trying to do everything at once is a recipe for disaster.

The second thing which was a bit surprising, though closely related to the first point, is how the TMF RA guidelines are seen as too sparse and high level by some practitioners. I respect their point of view, but then I fall deeper into the rabbit-hole where the Mad Hatter is now telling me that RA is responsible for Network Optimization and Bandwidth Allocation and what not. Again, as I sip my tea with the Queen of Hearts telling me that the crumpets served by GRAPA are far tastier, I try to expand my view to see where I lost track of Self-Organizing Networks coming under the gambit of RA. I like the RA guidelines, because it follows a thought process which is logical. Here again, my attempt is not to limit the scope of RA, but to see a well-defined, process-oriented growth in the practice as opposed to “Weed Growth” theory. “Weed Growth” is another term I’ve coined for a RA scope which is created with no consideration for the resources it saps either internally (as in providing Analysts with a scope they are not ready to handle) or externally (when a field is introduced in a core network element to simplify RA’s task while necessitating rework in other downstream elements). Without building a synergistic growth model, I have personally seen RA departments paint targets on their backs from other teams (normally from IT). Revenge is a dish best served cold, and apparently server rooms are kept quite cool – if you get my drift.

Thirdly, it is not uncommon to hear a RA head ask you about “Customer Experience Management” driven Revenue Assurance nowadays. There are ways to highlight the impacted subscriber set due to certain issues (eg. if a rate plan is over-charging, we can pull out the subscribers who are impacted due to this error and send out mails to them, apologizing for the same), however when you start defining your checks based on individual subscribers there is a huge overhead that is being introduced from multiple aspects. For example, if the checks were being defined on a per subscriber level, then the rate plan scenario I mentioned before would span hundreds of thousands of cases for investigation by the RA analyst. Consider the alternative, where a single case is created but we can identify the impacted subscribers. We achieve the same thing, but in the first case at a huge man-hour cost and IT resources perspective. There are intelligent ways to utilize the data from RA for a whole host of activities. Some good ideas which were suggested by operators were:

a)      Use the RA Platform for Internal Audit

b)      Extend the analytics present in RA to enable Product/Service Performance

c)       Usage of data within the RA Universe to enable Cash Automation (primarily related to Prepaid  Channel Assurance, with extension to financial platforms)

All in all, last year was fun. We had brand new challenges, we saw a definitive leap in RA practices around the region and we had our R&D team come out with a Root Cause Advisory engine. I have a feeling that the upcoming year will see the expansion of RA into a truly integrated ERM framework. On a personal note, hopefully, I increase my blog run-rate to more than 1 per year!!!

 

Bookmark and Share