Making Revenue Assurance Maturity Models Practical

Revenue Assurance Maturity Models (RAMMs) are abundant today, because they are useful as evaluative tools and can provide the basis for a phased roadmap. Yet their documentation often lacks pointers for crossing over from the academic realm to the real world. Significant questions such as which people should be involved in revenue assurance efforts, how they should be organized and whom they should report to are left unanswered. Similarly, if RAMMs show the way, they only seem to do so with linear or tactical roadmaps. Although they suggest a long-term, enterprise-wide approach, they are light on the details explaining how a telco crosses over from an initial project-level approach.

The key to filling in these gaps is to understand the assumptions and lessons learned underlying these models. Talking with the experts makes it clear that a RAMM, like any other revenue assurance tool, requires the right perspective to deliver its intended value.

The Five Phases of Metamorphosis
Most RAMMs are similar in that they identify five steps or phases of maturity. These phases progress from the zero point, where an organization has few or no revenue assurance controls or processes, to an advanced stage, where all new products have revenue assurance controls built in and the company has enough automation and analysis to take preventive action against revenue leakage. Borrowing from several examples provided by the TeleManagement Forum, Lavastorm, Cognizant and others, and normalizing for subtle differences, most RAMMs adhere to a progression similar to this:

• Level 0: No revenue assurance practices, processes, policies or tools are in place.
  
  
• Level 1: Basic revenue recovery consists of ad hoc, manual audits, generally driven by a small, voluntary team or by individual efforts. Some revenue is recovered.
  
  
• Level 2: Basic project and process management involving repeatable tasks is implemented. Point solutions are installed to detect and correct certain types of revenue leakage. Business rules and audits are defined. A project-level team is in place, but project prioritization remains best-guess.
  
  
• Level 3: Revenue recovery shifts to revenue assurance, where greater automation is introduced to move from auditing to continuous monitoring of revenue streams. Business rules for detecting and correcting leakage are implemented systematically into existing processes. Teams are focused more on analysis and correction than simple identification, driven by technology tools that help prioritize areas of greatest leakage and potential ROI. Business analytics and dashboards are implemented to quantify and forecast revenue assurance performance.
  
  
• Level 4: Leakage is quantitatively understood and controlled. Formal processes and controls are in place. Financial streams undergo regular, systematic analysis. Tools are expanded across the enterprise. An expert revenue assurance team is in place, and it educates and builds participation with other product and functional groups across the enterprise. Operational assurance metrics and dashboards track root causes of leakage, rather than just leakage itself.
  
  
• Level 5: Revenue assurance shifts to revenue management. Revenue assurance practices, processes and tools are analyzed for performance and continuous improvement. The focus is on cross-functional, cross-organizational efficiencies and communication. Tools and processes are enhanced to identify potential problems and take preventive action. All new services are designed with revenue assurance controls built in or factored in.

Some of the models in the marketplace differ a bit in terminology and progression of certain details, but at a high level they all follow this basic, logical curve. Organizations can mature over time from having no practices to basic revenue recovery mode; then to real revenue assurance, where revenue streams are consistently monitored and controlled with automated tools; and finally to true revenue management, where the entire end-to-end picture of the business is visualized and monitored from a revenue perspective, and perhaps aligned with related ERP and supply chain management efforts.

RAMM Assumptions
If the model makes academic sense, to go from paper to implementation it’s necessary to understand the assumptions behind it. “The first goal of the model is for a company to be able to evaluate itself,” says Gadi Soloterevsky, chief scientist for cVidya and team leader for the TeleManagement Forum’s revenue assurance team. The model can be applied to specific projects or entire enterprises, he says, and will give the evaluator an idea of “what the next steps are and what methodologies might apply.”

A RAMM is not intended as a single linear roadmap for an entire enterprise. It is always assumed that revenue assurance will start on a project basis, though with executive-level support. “In revenue assurance, you may have a product line that has a RAMM level of 4 or 5, but your entire enterprise is probably a 2 at that point,” says Brandon Smith, vice president of global marketing and product management for Lavastorm. “You have to start out at an individual product level. The good news is you can go from level 1 to level 4 in one project.”

Revenue assurance projects can pay for themselves, and successful ones tend to fund further efforts, but typically they start from modest roots and don’t try to take on the entire scope of correcting revenue leakage in one enterprise-wide swoop. “You can’t go after entire organizations at once,” says Smith. Because revenue assurance, on an enterprise scale, will cut across so many distinct groups and ask so many people to communicate and report their activities differently, “that sort of boil-the-ocean approach is bound not to succeed,” Smith argues.

Building an RA Organization
Ideally, any revenue assurance effort should start with executive support in order to carry with it the mandate and authority to accomplish its purpose. “In all of the successful places, there is one common denominator: that revenue assurance has strong support from management. If it doesn’t, it won’t succeed,” says Soloterevsky. He says that most often, revenue assurance groups tend to report into the CFO, but they can also start in IT, OSS or other groups. In some cases, the revenue assurance group’s customer is the CFO or a consortium of the CFO, CIO and COO. Soloterevsky says it is critical for any executive who wants to drive revenue management to recognize that “at the beginning the whole organization will be afraid of revenue assurance.”

Acknowledging Fear
The fear stems from the idea that revenue assurance is meant to uncover problems that may have been swept under the rug and quantify them in real dollars. “Whenever you cross organizational boundaries you get into big issues,” says Chris Couch, chief marketing officer for Ace-Comm. “No one wants to be pointed out as making a mistake, and it is difficult to resolve those issues.” A revenue assurance initiative that points fingers, however, is generally regarded as an example of poor management. “If a revenue assurance project ends in blaming someone for losing money,” says Soloterevsky, “the revenue assurance management has a problem.”

The witch-hunt mentality can spring from several sources. Sometimes, revenue assurance is designed and empowered as a witch-hunt with the idea of conducting audits to root out specific problems. “When we did audits, it was a witch-hunt and everyone feared the big stick,” says Ted Fadick, wireless services lead for Convergys’ professional services group. Management often has good intentions, but by empowering a specialized SWAT team without setting expectations or earning the cooperation of groups the audit will impact, a witch hunt develops all on its own and brings out inherent animosity. Often, Fadick says, the success of tools in identifying problems creates a witch-hunt because service providers “have the tool to go in and find all of the problems up front, and the whole problem is so massive that everyone feels threatened.”

Fadick suggests throttling back on the number of problems to identify up front, in order to focus on fixing a few at a time that will provide the most payback. Revenue assurance is something that has to be learned over time and that people have to become accustomed to and buy in to. “You have to build justification and the feeling in the organization that revenue assurance is welcome,” says Soloterevsky. The question is how to build an agreeable, cross-functional group and still have a centralized revenue assurance manager who’s not looked at as the local Cossack.

Building Consensus
Revenue assurance, it is typically agreed, must be the responsibility of a specific group or person, but it necessarily requires cooperation from groups that are not going to become part of the revenue assurance domain. Fadick says the purpose of building a revenue assurance team “is not auditing. It is to ensure revenue streams. It’s not like, ‘Here’s the problem, let’s send in the SWAT team.’ It’s more like, ‘Let’s get our revenue streams clean and turn this from a cost center into a profit center.’ ”

In most cases, fixing revenue leaks has to do with cleansing data or improving processes. This means the folks from billing, provisioning, inventory and other groups that own those data and processes must be involved in assisting revenue assurance efforts, but getting them to communicate can be a challenge. “In the beginning, bring these people into revenue assurance and teach them to communicate and work together,” suggests Soloterevsky. “As things become more mature, send them back into the department they came from. They’ll know what revenue assurance is about, so you’ll have a core revenue assurance team with people linked to revenue assurance in each activity.”

Fadick agrees and suggests that a service provider have a “small team in the revenue assurance department, and they have small teams throughout the enterprise. When the small revenue assurance team identifies a problem, you then have the right team go out and make the fix.”

This is a form of consensus building where people are educated about how their home groups can better contribute to the company’s bottom line, and it is universally agreed that achieving this kind of buy-in is critical to the success of any revenue assurance organization. “People are not blasted because of a problem—they are recognized for correcting the root cause of the problem, [and] that team can say, ‘We just recovered a million dollars per cycle,’ ” says Fadick. This model is also very flexible, however, and can allow for a team of specialists to educate and improve the inter-communication of many groups over time, if empowered the right way.

Today, many revenue assurance practices lack both management support and authority and thus are not making enterprise-wide progress. “There doesn’t seem to be one single owner of this whose charter is to make sure the company is minimizing leakage,” says Rani Goel, director of worldwide communications marketing for Business Objects. Similarly, says Couch at Ace-Comm, “revenue assurance groups don’t have the authority to control the billing, network, provisioning or sales guys.” That authority comes from the top, and is hence another reason that executive support is necessary for success.

Technology Progression
At the same time that consensus and cooperation are built to generate an effective, enterprise-wide revenue management program, technology must be put in place to support the new activities. Revenue management “is clearly a three-legged stool,” says Lavastorm’s Smith. “One leg is technology, one is process, and the third is the people who create value from the process and the tool.” In other words, each element depends on the others to create an effective program.

Digital Data
Following the RAMM, it is clear that organizations will only be ready for certain types of technology at certain points in their maturity, and there is in fact a technology maturity curve to consider. The first step, typically, is just moving from paper to digital data.

“One [capability] that has propelled the discipline to a more mature level is the ability to get data into a digital form,” says Tom Nolting, director of financial assurance for Vertek Corp. “If you can’t get data into an electronic form and if it’s not searchable, then you can’t do much revenue assurance.” He cites past experiences with a major ILEC where he would receive a 4,000-page CABS bill and would have to pay the equivalent of 1-1/2 full-time service reps just to load that invoice, because there was no loader or parser for CABS then. Such loaders and parsers are widely available today, yet many carriers do not use them—and so they struggle to reconcile information from documents like CABS bills.

Business Rule Auditing
On the process side, business rule auditing is another key technology milestone. When revenue assurance programs are engaged on a one-off or product-by-product basis, often the small, unrelated teams in charge will build homegrown database queries that provide the basis for repeatable audits. This can help identify leakage but won’t necessarily make identifying and fixing root causes any easier. The next level of maturity would have a service provider using “some sort of business rule auditing software. That means going from having [revenue assurance] in an audit format to instead analyzing the data and putting it to use to correct problems or perform process optimization,” says Nolting.

This is one of the fundamental differences between revenue recovery and revenue assurance. In revenue recovery mode, leaks are quantified and attempts are made to recover revenue that was never collected. In many cases, however, some consistent error in an established process contributes to chronic leakage. Also, leakage results from mere inefficiencies in key processes that have not been identified—usually at the point of inter-organizational hand off. Auditing business rules makes it easier to optimize processes across organizational boundaries and sets a foundation for optimizing revenue assurance processes themselves—a key piece in the step to true revenue management.

EnterpriseReporting
Reporting is another critical technical element for revenue assurance. The ability to report across the enterprise and up to management is necessary for building consensus and maintaining support. “At the end of the day, what’s measured and supported and important is what gets done,” says Business Objects’ Goel. Naturally, effective reporting will depend on digitized data and measured processes, otherwise a reporting engine in effect has no source for its reports. One of the weaknesses in many existing programs, Goel says, is that “a lot of the information is at the operational level, but [service providers] don’t correlate that to customers or products.”

As Fadick at Convergys pointed out, this has been one problem with some revenue assurance tools that spit out volumes of data but do not provide a basis for action. This means problems are identified on a broad scale, but not necessarily fixed in a systematic fashion, prioritized by dollar value or engaged with executive support. “You want to make the data visible to the executive team so that when you look at the dollar-and-cents scope and impact of the revenue leakage, it becomes easier to prioritize,” says Goel; otherwise “it just becomes a best guess based on anecdotal evidence.”

Being able to prioritize projects based on dollar value is another key maturity milestone in RAMMs, but it can’t happen without the help of technology. The combination of accessible data, analytical reporting and business process auditing helps manage the data volume, put information into contexts that make sense to the groups that need it and identify where new revenue assurance programs or tools might be useful.

Revenue Management Platforms
Recent years have brought a proliferation of more advanced revenue assurance-specific software platforms that can solve a broad range of revenue and cost leakage problems. The tools themselves have matured along a curve similar to that of the RAMM. Early tools were focused on grabbing digital data and presenting it in a searchable, manageable form to an auditor. These tools were a good first step from paper to bits, but in the end they required an expert user to perform analysis on the data to identify discrepancies, and they didn’t suggest or take any corrective action. Many of the tools on the market have advanced well beyond this stage and now include components for loading and parsing data, auditing and adjusting business rules, identifying the potential root causes of leaks, delivering enterprise wide reports, and taking or suggesting corrective action in an automated or semi-automated manner.

The leading tools in the market today are semi-autonomous and designed to provide continuous analysis of revenue streams with the ability to take automated, corrective action if the service provider wishes to put that much control under the system’s responsibility. They have also advanced significantly in their configurability, which in the past relied on coding and has, at least with some of the leading vendors, shifted to configuration by drop-down menus that are accessible to business analysts rather than programmers.

Revenue Operations Centers (ROCs)
The ultimate realization of continuous revenue stream monitoring could be a revenue operations center. Though it is not universally agreed that a ROC is the ultimate end goal for a revenue assurance practice, its advocates believe that ROCs “should be on the same track or higher than network operations,” says Jim Wilburn, market development manager for telecom marketing and strategy for Sun Microsystems. The ROC would be a centralized management site tasked with monitoring, identifying and diagnosing problems that jeopardize the revenue stream, much as a NOC does for the network.

Wilburn states clearly that “the ROC concept is in its infancy” but stresses that “revenue leakage and fraud management detection has to be instantaneous.” He backs up this argument with a forward-looking perspective that acknowledges the exponential growth in revenue leakage and fraud that may result from multi-party, real-time application services. “There are so many new players hitting the market,” he says, “that having to identify that something is coming from a legitimate player is going to become critical.”

This last point is universally agreed, even if a ROC as the solution is not. Yet the ROC makes great sense from the point of view that telecom has shifted from a network-centric monopoly business to a revenue-centric competitive business. If the network was what to watch in the past, it makes sense that the flow of revenue is equally if not more important today.

Armed with an effective RAMM, a good IT roadmap and executive support, the question is where to begin. Many areas, like interconnect, offer plenty of revenue to be recovered that not only can justify the revenue program but also can help fund further efforts in other products lines or organizations. Even with reporting tools and the like, experts throughout the business will have a solid idea of where leaks may exist. Certainly any areas where manual handoffs can impact a revenue-generating process or where massive volumes of billing-related data are being audited manually—if at all—are the first places to look.

The real importance of the first step, however, is to “take on projects up front that create value,” says Lavastorm’s Smith. “That will get the momentum rolling and help you get to that enterprise-wide program that will in turn get your company to a high level in the maturity model.” Once the starting point is identified, using a RAMM in the right context should provide a solid model for a reasonable, incremental approach.