What If Your Revenue Assurance Problem Is IT? Look In A Mirror.

datePosted on 17:59, August 19th, 2010 by grapa

I’ve been in the telecommunications industry for a very long time. My first job after university, back in the ancient times, was with ATT in Chicago. Since then, I have been privileged to work for many different telcos in a lot of different capacities.

What most people don’t know is that even though I have degrees in Statistics and a Masters Degree in Telecommunications, my original career was in IT. For more than half of my career, although I was working for telcos, I was doing that work as a telecoms IT guy. I am a true IT geek.

Don’t get me wrong. I love it. And I love IT people. Indeed, I am one myself. I am a certified DBA (DB2 and Oracle), a certified Microsoft Engineer, and a whole lot of other IT certifications that you really don’t want to know about. I have been playing with computers for many, many years now. However, I am telling you this for one very important reason. I want you all to understand that when I talk about IT being the problem for revenue assurance, I know what I am talking about.

First, let’s get one thing clear. I am not saying that IT is always going to be a problem for revenue assurance. In fact, there are many organizations that I know where IT and Revenue Assurance are very strong allies. In these organizations, both revenue assurance and IT understand what their respective roles are in the company, and they work together to accomplish these objectives. Many of the biggest revenue assurance successes are accomplished by the heavy contribution and hard work of our IT friends and allies.

That being said, the opposite situation is also true. There are some organizations where the dozens of “little” revenue assurance problems are overshadowed by one very large problem–the IT organization itself. I have come across a few situations where the IT organization is responsible for creating a lot of the biggest obstacles to doing the revenue assurance job.

One example comes to mind that illustrates these problems quite clearly.
In one telco where I was working, we were instructed by the CFO to take care of assurance for the mediation system. There were a lot of complaints and issues being raised by the postpaid and the interconnect billing areas about problems with CDRs. CDRs were missing, formatted incorrectly among many other issues.

So, we went off to talk with the mediation people. You would have thought that we were a group of plague carrying beggars the way we were treated when we went back to look at the mediation operations. It seemed that in this case, there was no “Mediation Operational Group” at all. Instead, the mediation system was simply “run by IT”.

a)    They were running the system according to the requirements given to them.
b)    That reading those irritating error reports was not their responsibility.
c)    That we had no right to ask for such information.
d)    That if we didn’t like it, we could submit a change request, to the IT change management committee and wait for an answer (the current backlog for emergency fixes was two months).

Being good team players we submitted the requests and tried to follow up. Six months later, we were told that the change request was “in the queue” and could be expected to be addressed in another two to three months. Unbelievable.

Now this is where it gets interesting. When we went to the IT group and asked about the possibility of purchasing a “revenue assurance system” that would allow us to check on how the mediation system was working by reading the CDRs before and after processing by mediation, we were treated like their best friends. Our request for a new system shot to the top of the work queue, and the new system was implemented in under four months.

This story, which is  absolutely true holds within it I believe, the heart of the nature of the problem when IT and revenue assurance  finds themselves in conflict. It is really an underlying conflict in mission and perspective. First,  in my opinion, there is a fundamental management and operational control problem in this situation. The first problem is that in this case, and in a number of telcos, management has decided that IT should ‘run systems”. It is an easy mistake to make. Since IT understands how the system is installed, why not just tell them to run the systems themselves? Easy!

Even more importantly, IT can staff the running of the system with a lot less man power than an operational group. Operational groups always want to check on things, and make sure they work right. IT just makes sure that the “engine is running”.

At first glance, this seems to be a brilliant idea, especially if the managers making these decisions don’t understand exactly what the systems do, and why they are important. You can see plenty of examples of this kind of thinking. Mediation systems are sometimes staffed with one part time IT or Network Operations person for whom mediation is one of a dozen “critical systems” that he manages.

How about when we have a prepaid billing system with only one or two support staff, when that billing system is responsible for tracking millions of dollars of revenue each month. There are far too many examples of this kind of “under-coverage” of key operational responsibilities. And when operational systems are critical and revenue sensitive systems are under-covered, who does management turn to “fix” the problem when those under-covered systems start creating leakage? Why revenue assurance of course.

The problem is that by this time, the people who are responsible for running this system really believe that they have been doing it the right way. When revenue assurance comes in and points out leakage areas, the people involved feel defensive, angry and unfairly treated. From the perspective of those running the system, these attitudes are completely justified. They are doing exactly what they were told to do. So for them, the presence of revenue assurance is a “resentment event”.

The issue is that the systems were being run improperly to begin with. They are running without the proper operational controls in place. When we are lucky, and when management is sharp enough, the revenue assurance team can  point out this lack of operational integrity to management, and the problem is fixed properly from the top down. The revenue assurance recommendation for a ‘correction’, by either taking the system away from IT, and giving it to an actual operational group (like billing) or by putting the right KPIs in place to assure that the system is run correctly will drastically reduce or eliminate the risks.

When we are unlucky however, management proceeds to exacerbate the problem and make it worse. Instead of correcting the underlying operational shortfall, they commission the revenue assurance group to set up yet more controls. A set of meta-controls. Controls outside of the operational area itself, which verify that the operational area is working correctly. At first glance, this may seem quite clever. After all, getting people to do things the right way the first time is a pain requiring retraining, rearranging budgets and H/R issues. It is easier to simply slap some additional controls on top of the existing controls, putting more “little jobs” on top of what the revenue assurance team is already doing.

The problem, of course, is that this actually does not fix anything. All it really does is increase the overall operational cost of running the system (since now you have yet another group, tracking the original group, without actually fixing what the original group was doing wrong in the first place). The result: more IT, more systems, more controls, more staff running around watching each other, and fewer people focusing on the real underlying problems.

I bet if you were to investigate all of the cases where telcos purchased revenue assurance “systems”, to assure underlying systems, that 99 times out of 100, that this would turn out to be the real problem. Think about that for a minute.  Think about all of the time, money, effort, confusion, chaos and oh yes, money, has been wasted, doing exactly the wrong thing and in fact making the underlying problems worse. Frightening, isn’t it?

I wonder how many revenue assurance departments are working under the belief that their job is not to fix the problems that cause leakage, but to function as a group of “back up singers” for IT. Think about it. How many revenue assurance organizations think they are doing revenue assurance, when they are really playing the “fall guy” for IT, providing back stop services, patches and meta-controls to make up for the fact that the underlying billing, provisioning, credit and sales systems were not implemented right in the first place?

So what have here are two diametrically opposed views of Revenue Assurance:

1.    The GRAPA view, which says that the objective of revenue assurance is to identify, quantify and address risks to revenues, based upon the best solution possible when working with operational managers to help them run their systems better.
2.    Those who believe the job of revenue assurance is to set up over-controls, which places controls on top of the people doing the jobs, and trying to fix things by giving those people negative feedback while trying to prove  how poorly they are doing their jobs.

Yes, when you really look at it closely, most of the time, when you think that IT is the revenue assurance problem, it turns out the real problem is the revenue assurance team themselves. The team has failed to understand the nature of their jobs, and the nature of the solutions that will make the most sense for their organization.

There are clearly some situations where software can help the revenue assurance team do their job. Any organization that believes that they can’t do a good job of revenue assurance without software, or who see their job as the implementers of IT controls everywhere, are revenue assurance people who, in my opinion, have lost their way, and have stopped doing revenue assurance, and started doing IT work instead.

The good news is that if the revenue assurance team is familiar with, and is following the GRAPA standards and principles, these problems can quickly be analyzed and corrected at minimum cost and with maximum impact.
I for one am tired of hearing people complain about how hard IT makes it for revenue assurance to do their jobs. More critically, I am tired of hearing people talk about how they implemented revenue assurance systems that don’t provide value. In all of these situations, the real culprit, my friends, is a revenue assurance team that has “lost their way” by taking a “short cut” instead of tackling the hard parts of their job:

1.    Rationalization and quantification – figuring out how much revenue is at risk – before developing a proposed solution.
2.   Accountability – doing the forensics, and communicating options to management.
3.    Integrity – not cutting corners (political or technical) to get you out of a problem in the short term.

So, in conclusion, if you think that you have a problem with IT, the first place I recommend you check is in the mirror. If IT is causing problems, it is because either you haven’t done your homework, or you haven’t taken the steps to do your job the right way in the first place.

Well, that’s enough for this time, this is Rob Mattison saying…be safe….

Related Posts:

Leave a Reply

Name: (required)
Email: (required) (will not be published)
Website:
Comment: