![]() |
© 2022 Black Swan Telecom Journal | • | protecting and growing a robust communications business | • a service of | ![]() |
“An institution is the lengthened shadow of one man.”
—Ralph Waldo Emerson, Essays
You can’t run a great institution or business by committee. The leadership at the top really matters.
In 12 short years, Steve Jobs transformed Apple from a second-tier computer supplier to a wireless device and content distribution juggernaut. At this writing, Apple’s market cap is $293 billion, higher than Microsoft’s $239 billion and Walmart’s $193 billion. Simply amazing.
Yet when you analyze Apple’s success with the iPhone, you realize that no single skill set spelled the difference. It’s the confluence of talents across many areas that’s made Apple “insanely great.“
On the technology side there was innovation in embedded computing, OS design, and the user interface. In marketing, Apple brought together superior advertising, human engineering, and retail store excellence. Content distribution wasn’t an afterthought: Apple’s app and music stores were integral to the full package. Even its partnering with AT&T and other telecoms was pulled off with brilliance.
So what can folks in the revenue assurance profession learn from Jobs, the management genius? Perhaps, it’s that people who can juggle multiple glass balls at one time are quite valuable.
The greatest sin is being one-dimensional. To be good in revenue assurance, training in bill audits and forensics is necessary, but not enough. A thorough knowledge of B/OSS systems is also needed. Then too, coordination with other departments, such as billing, customer care, marketing and engineering, is equally vital. And you certainly need to have a solid relationship with IT/operations, the folks who often run the mediation, billing, ordering, and inventory systems that RA wraps controls around.
It’s the critical relationship between IT and RA that is the subject of this blog. And here to wade in on the issue is Rob Mattison, the founder and president of GRAPA, the Global Revenue Assurance Professionals Association.
Rob is a piece of work — hard work. He’s an expert who talks from authority because he’s lived a lot of the business stories he tells. He’s worked at telecoms, in IT and in revenue assurance. He’s written a few business books. And he’s got degrees in computer science, telecommunications, and — you’d never guess this one — anthropology.
Though he could easily make money having vendors sponsor his training events, he’s chosen instead to keep his organization free from outside influence. In that way, he remains a independent expert who can freely speak his mind with no axe to grind.
In the following interview, Rob uses a case study to show how IT and Revenue Assurance misunderstand each others’ roles. Then in the second half of the interview, Rob teaches revenue assurance managers a lesson about sticking to their guns and honestly examining their true worth to their telecom organizations.
Dan Baker:Rob, it’s well known that IT organizations are hard to deal with. But are there some irreconcilable differences here between IT and revenue assurance? |
Rob Mattison: Dan, first of all, I think it’s important to tell you where I’m coming from on this issue.
I’ve worked for many different telcos in many different capacities, and for more than half my career I was a telecoms IT guy. I am, in fact, a true IT geek. I love IT and IT people. 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. Plus I’ve been playing with computers for many, many years now.
I tell you this for an important reason: when I say IT is a problem for revenue assurance, I know what I am talking about.
Now I’m not saying that IT is always going to be a problem for revenue assurance. In fact, at many places I know, IT and Revenue Assurance are very strong allies. And at these shops, revenue assurance and IT understand what their respective roles. What’s more, many of the biggest revenue assurance successes are accomplished by the heavy contribution and hard work of our IT friends and allies.
But at some telcos the relationship just doesn’t work at all. Reading your blog, I came across one case where IT put up a stone wall between RA and itself. |
Yes, at some telco organizations, dozens of “little“ revenue assurance problems are overshadowed by one very big problem — the IT organization itself. And this was certainly the case at the telco you’re referring to, a place where I actually worked.
At the time, people in the postpaid and interconnect areas were complaining about CDRs being either missing or formatted wrong. So the CFO instructed a team of us to assure the mediation system.
But when we approached the mediation people to examine their operation, they treated us like a group of plague carrying beggars. They told us ...
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 would be addressed in another two to three months. Unbelievable.
But here’s where it gets real interesting. When we asked the IT group about the possibility of purchasing a “revenue assurance system“ that would allow us to check on how the mediation system was working — reading the CDRs before and after processing by mediation — we were treated like their best friends.
Our request for a new system shot up to the top of the work queue, and the new system was implemented in under four months.
The story is highly interesting, but what does it tell you about the source of this IT / RA conflict? |
The starting point for a lot of these problems, I believe, is when senior management decides that IT should “run systems.“
Now this is an easy mistake to make. Since IT understands how the system is installed, why not just have run the systems too? IT can definitely staff the running of the system with a lot less manpower than an operational group. Operational groups usually want to check on things, and make sure they work right. IT just makes sure that the “engine is running.“
Sadly, I see this operating philosophy in place at a lot of telcos. I’ve seen mediation systems staffed with one part time IT or network ops person for whom mediation is one of a dozen “critical systems“ that he manages. Another case: A prepaid billing system responsible for millions of dollars of revenue a month is staffed by one or two support staff.
But when operational systems are critical and revenue sensitive systems are under-covered, who does management ask to “fix“ the problem when those under-covered systems start creating leakage? Why Revenue Assurance, of course.
Unfortunately, by this time the people running the system really believe they are doing it the right way. So when revenue assurance comes in and points out leakage areas, these people get defensive, angry and feel they are unfairly treated. Yet from their perspective, these attitudes are completely justified. They are doing exactly what they were told to do.
Sounds like what we have here are different interpretations of “running a system.“ An IT person can adequately run the system’s engine — its access control, databases, network links and servers. But that’s very different from the system’s operation, which implies knowing the nuances of how billing, mediation, and order management processes are supposed to work. |
It’s very true. IT is running the billing system without an appreciation of the billing process, and 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,“ — either taking the system away from IT and giving it to an actual operational group (like billing) or 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 make the problem worse. Instead of correcting the underlying operational shortfall, they commission the revenue assurance group to set up yet more controls. These are really a set of meta-controls — controls outside of the operational area itself whose purpose is to verify that the operational area is working correctly.
At first glance, this seems quite clever. After all, getting people to do things the right way the first time requires painful retraining, rearranging budgets and H/R issues. It‘s 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 doesn’t fix anything. All it really does is increase the 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 “system,“ 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 “backup singers“ for IT.
Think about it. How many revenue assurance organizations think they are doing revenue assurance, when what they‘re really doing is 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?
Rob, this is heady stuff and a pretty strong wake-up call for revenue assurance managers to challenge the assumptions behind the role they play. |
Dan, I think it boils down to two diametrically opposed views of Revenue Assurance:
Most of the time when you think that IT is the revenue assurance problem, 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 revenue assurance 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 “shortcut” instead of tackling the hard parts of their job:
So if you’re a revenue assurance manager, and you think you have a problem with IT, the first place I recommend you look is in the mirror. If IT is causing problems, it’s 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.
This article first appeared in GRAPA’s Mattison Avenue blog.
Copyright 2010 Black Swan Telecom Journal