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 20^th 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:

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?

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?

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)…

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!!!

Again, I have been far removed from the TalkRA world for some time. The reason this time around is quite interesting and I couldn’t wait to post it. The last 7 months had me working with a team on optimizing the approach to Revenue Assurance in terms of “indicating” to the analyst the key areas for improvement. The TMF already has quite a good set of KPIs, but as I’ve mentioned in one of my earlier posts, some of the Telco’s in the APAC region of the world have highly specific areas for monitoring, some of which are far too atomic to apply TMF KPIs to.

The problem that lay before us was to setup a framework and not a point indicator to the leakage. Towards this end, the shining knight said “Tally Ho” and set forth to discover the “Holy Grail” of Revenue Assurance – The Key Performance Vector (KPV). As I’m sure most of you know, a vector has two components – Magnitude AND Direction. What I wanted to do was try and see if the existing set of KPIs could be converted into KPVs. At this point, via the magic of intuition, I can see quite a few eye-brows going up and a few mustaches being twirled at the thought of “Yet another metric?!?! RA loves the metric system more than UK”.

The reason behind the KPV is what I would call a Goal Cascade (GC). The intent of the Goal Cascade is to enable the various sub-sections of the RA team to be aligned with the highest level RA goal of the organization. For example, when a Telco says “0.4% leakage is acceptable to me – anything beyond it calls for discussions with HR”, how does the analyst know the weightage of his/her function to that 0.4%? Furthermore, how should he/she interpret the functional KPI? The KPI definitely does highlight the true state of affairs at that moment, but is it in need of further improvement or should the analyst call his mates and nip down to the local pub for a pat on the back?

The Goal Cascade is an engaged activity where the trickling of the Key Goal to the various sub-sections of the RA team is cohesive – and trended over a period of time. Now comes the kicker. The KPV is not a “In-point-of-time” indicator. The KPV is the second derivative of the KPI magnitude trended over a period of time – its not exactly the second derivative, but that is the closest generalization. The KPV actually involves quite a complex formula taking into account multiple factors. If you hate mathematics as much as I do, you’ve probably fallen asleep at this point. However on waking, the end-result of a KPV is an in-line representation of

KPV = magnitude(from the KPI) +functional performance up/down+alignment percentage to Key Goal

The KPV is not mean’t to replace the KPI. The KPV is an extension of the KPI itself. The KPI builds structure in a vast science (Einstein used to wonder about two things – the boundary of the universe and secondly, the boundary of Revenue Assurance – of course I am joking). KPV come in useful when the RA team requires a synchronized view of KPI aggregation.

I would love to hear your comments on the concept – have I finally gone bonkers, or do you see value in this as well?

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.

http://www.technology-research.com/experts/romano1.php