Inside the Billing System Selection Process

The dynamics in today’s telecom industry have service providers, large and small alike, outgrowing their billing systems faster than a teenage boy outgrows a favorite pair of jeans. With so many vendors on the market and direction of the next growth spurt unpredictable, decisions become as stressful as what to wear on the first date-except millions of dollars are at stake here. So service providers, like teenagers, begin a process sure to cause a few heartaches. And like a new pair of jeans, there are some options: make it yourself, have it custom-made, try to find a fit among the mass-produced, or borrow for a while. With the demands for rapid implementation and the industry-wide shortage of experienced IT professionals, off-the-shelf products often prove the most appealing.

Something brought the need for a new billing system to your attention. And, unless you’re a start-up looking for your initial biller, it probably was not a good “something.” Everyone Billing World interviewed for this story suggested the same starting point for any back-office application purchase: a good, hard, air-the-skeletons look in the closet.

In non-greenfield situations, carriers often try to replace the back-office component they perceive to be causing the greatest amount of pain, says TMNG’s Director of Research Valerie Finberg. The strategy sometimes works, but often skirts underlying problems. “Sometimes what appears to be a system causing a problem really is the processes surrounding the system; when you replace it with a new system, the problem remains,” she says.

Larry Handen, Principal at PricewaterhouseCoopers, explains that start-ups face challenges in not having established business structures and not being able to articulate their requirements. “Greenfield isn’t always your friend,” he says. Established carriers examine the business model and retain it or make improvements. New service providers don’t have that luxury.

Define the Criteria

Defining and analyzing the company’s business processes often requires painstaking attention to detail. However, it lays the foundation for a smooth selection and implementation process, says Ron Twine, vice president of billing operations at KMC Telecom. His company, a facilities-based CLEC, is migrating to a new billing system and implementing a third-party OSS. The exercise helped KMC pinpoint its goals for the new systems and enabled the carrier to eliminate quite a few vendors.

Peter Grambs, principal at Booz Allen & Hamilton says that this initial self-examination should provide an understanding of the carrier’s business philosophy, including what its leaders consider its competitive advantage and the reputation they want for the company. “Do they want to be known as the best customer care service provider?” he asks. “Or do they want to be the lowest-cost provider? Or do they want to have the most options or keep it simple?” Even a cursory examination helps establish the business foundation that drives for the rest of the selection process, he says.

The process must also project new lines of business for the service provider and address the possibility of implementing one convergent billing system. “Some carriers don’t want an integrated billing system,” Grambs says. “Some believe there isn’t one package with which they can adequately bill for all services. So they’re willing to have multiple systems, which they then integrate themselves.”

KPMG’s Mike Bruchey emphasizes the significance of taking an enterprise approach to the selection-including all major organization stakeholders. Each department, including finance, marketing, IT, network provisioning, service assurance, service provisioning, billing and customer care has specific requirements that need to fit in the equation. If one department holds responsibility for determining the requirements of a new system, its features are likely to be weighted in that department’s favor and may completely overlook or de-emphasize necessities in other areas.

“Generally everyone wants everything,” says TMNG President and CEO Rich Nespola. “It’s like Prego spaghetti sauce; they want to put everything in there. Sometimes you can’t afford it, not only from a financial perspective, but also from a timeline perspective. You have to prioritize. Ask what is mandatory on day one, and what can I add incrementally?”

Nespola explains that an effective approach is to view a biller as serving two constituencies-internal customers and external customers. Most of the attention revolves around the subscriber, or the external constituency, he says, with goals of delivering timely, accurate and complete bills. However, if the internal constituency doesn’t get the reporting, analysis and technological tools and capabilities it needs to run efficiently, the carrier has not selected the correct solution.

Finberg says that by leaving out critical departments, such as IT, carriers sometimes focus more vertically than horizontally and neglect to consider the interfaces required between the various components of their back-office systems. “By rushing the process,” she says, “they pick Vendor A, B and C for the feature functionality each offers and expect the systems to interact amicably from the beginning.”

Adding Wall Street and the need to be merger-and-acquisition friendly to the mix further complicates billing system selection. Some service providers select OSS components for name value alone, Finberg says. “Its members may not have heard of a small, start-up vendor with technologically advanced applications, but they have heard of the ‘household-name’ vendors, so even though it might not be the right fit, it meets the need of the deep-pocketed,” she says. “We also see that a lot on the financials side with Oracle or Peoplesoft or SAP, which are huge packages for very large organizations and may not really be the best thing for smaller carriers.”

Frequently, an M&A-oriented carrier chooses a billing system that will be compatible with its potential “bed buddies.” A case in point is SBC’s contract with Intertech for data billing-signed just after SBC’s recent deal with Williams Communications, another Intertech customer. Finberg sites another example, “When Qwest bought LCI, implementation of a vendor’s third-party billing system was already underway. After review, they decided to use LCI’s internal system.” The contract was dropped, not because of dissatisfaction, but merely for compatibility’s sake.

Narrow the Playing Field

Traditionally-and ideally, many say-a service provider issues a request for proposal [RFP] at this point in the selection process. By this time, Bruchey says, service providers should have reduced the list of possible vendors to four or five. If there are still 20 or 30 on the list, chances are some selection criteria definition is left undone. Many vendors will dismiss requests they receive that aren’t parallel to their offerings, he says. Bruchey also recommends that service providers give potential vendors “a heads up” at least two weeks before they release the RFP. This allows vendors to schedule the proper resources for a response. He advises service providers to keep in mind that “selections can become a beauty contest. Vendors want to stress their strengths and underplay their weaknesses, and it is critical to understand both.”

To RFP or Not to RFP?

Finberg says that carriers sometimes want to shorten or circumvent the RFP process.

“Their feeling is that they don’t have time to issue a full-blown RFP,” she says. “They say, ‘We’ve got to get the billing system in now. We know that we’ll probably look at these four vendors. So, we’ll look at them and talk to them.’ They’re going a little bit more on gut and basic capability than specifics. When it comes time to implement, because they haven’t articulated their requirements, the carrier may find that the vendor doesn’t have the capability for some seemingly small, but actually critical features. They think that they are saving on time by skipping some of the front-end process, but end up paying with both time and customization costs in the long run, or by compromising their original plans.”

Time-to-market considerations drove the decision to bypass an RFP process when Williams Communications relaunched its wholesale network as a separate business division in 1998. Williams Network Director of Accounting Services David Parrack says the company “didn’t feel like we had time to do a traditional RFP process-taking six months to develop requirements, six months to visit vendors, six months to implement. We tried to do the whole process in six months.”

Respective user groups and IT representatives developed a requirements survey and invited vendors to review the documents in a participatory manner, Parrack says. They were searching for best-of-breed functionality and a vendor with like-vision for a wholesale-focused OSS infrastructure.

The decision to follow this approach, Parrack says, “has been both helpful and painful. It was helpful in that it really did allow us to learn about vendors more intimately and quickly than we could have otherwise.” And it did get them up and running more quickly than a traditional approach would have, he says, although not without some difficulties. “The biggest challenge that we’ve had and continue to have is the integration.” Parrack also cites Williams Network’s rapidly growing business model-from systems, design and implementation perspectives-as a contributor to snags in the process.

Anyone would like to have more time to implement critical applications, he says, and in hindsight, there are things they could have done better. “We could’ve done some architectural things more easily up front, but given the time frames that we’ve had, I think we’ve done reasonably well,” he says.

If a service provider has already narrowed the field to two or three vendors and does not want to go through the formal RFP process, a more informal approach might be appropriate, Bruchey says. “By doing all the groundwork for an RFP, and then not issuing it, but instead, sitting down with the vendor and working through all of the requirements, you eliminate the fluff, the typical marketing answers. You essentially say to the vendor: ‘I know you’re good, what I need to do is measure you against my requirements and determine if our companies are compatible.’”

By defining the processes and business needs and subsequently issuing an RFP for an OSS application, decision-makers at KMC Telecom decided to file proof of concept requests to the three vendors on their “short list.” The team interviewed vendors, visited their sites, and gave them some data to run and accounts to create. The vendor with the signed contract was the one that bent over backward to perform, says KMC’s Twine. “They called us with only one question-one about an obscure international rate,” he says. Two weeks later, KMC representatives knew they had found a partner.

“The benefit of a proof of concept,” says Nespola, “is that you aren’t dealing with a paper exercise, but rather a task-related evaluative procedure.” However, Nespola doesn’t recommend this route if the RFP steps have been omitted. “It will usually protract the implementation, because all of the requirements have not been identified. If a proof of concept doesn’t map to a service provider’s products and only gives high-level generic solutions, it will generally fail. Simply running data through a biller is a simplistic way to be able to check something. The difficulty in billing may not be just the biller, but could be the surrounding systems with which it has to integrate. You don’t get that in proof of concept-especially if all you’re doing is running data through a biller.” “If you have to, you can select a billing system by the seat of your pants,” Nespola says. “Actually it can work out well. Companies implement ad hoc billers to get themselves in business or to market quickly. They usually won’t scale, however, sometimes it’s the most cost-effective and timely short-term option. If it’s a small company with a limited product offering, some of the systems can be home-grown, run off of some Pentium processors that will satisfy at least its initial needs.”

To help define the requirements for an RFP, consulting firms such as KPMG and TMNG keep databases of vendors and their capabilities. Both of these firms also have an RFP toolkit. KPMG’s template produces a document with extensive requirements and a scoring matrix for each vendor; TMNG’s software-based Lexicon contains more than 4,000 functional requirements. At first, Nespola says, the vendors resisted the Lexicon-which TMNG uses to issue between 30 and 40 RFPs per year, because they had no place to hide their systems’ shortcomings.

Now, he says, they like it, because it establishes clean and crisp criteria from which to work; it encompasses the general issues of organization and maps product set requirements. Additionally, it provides an objective method to score and grade potential vendors against the criteria that have been established by the service provider. These critical steps usually result in an expedited implementation. Play the Dating Game

After receiving completed RFPs, the final selection should take two to three months, says Grambs, though negotiations can lengthen the timeline. The service provider should tour the vendors’ sites and interview the vendors’ customers to determine how effective the system is and how well the vendor supports it. A vendor should match the profile of the carrier’s needs. Smaller carriers may be relying on their chosen vendor to function as its IT group for a while; larger carriers may not be as concerned about follow-up. Also, if the vendor has recently moved to a new platform, this would be good opportunity to ascertain how much experience the vendor has with the revamped system. The monetary cost for a developing product might be lower, but if time-to-market is critical, the service provider might want a well-proven application.

It is critical to understand and match the vendor’s product direction with the carrier’s business objectives. With a package billing system, the carrier does not have as much influence on the code development direction as they would for a solution-oriented approach, says Bruchey. “Don’t make things more complicated by demanding the vendor make significant changes to their system in order to support your needs if they are not consistent with the vendor’s future product direction,” he says. “If you think you’re buying a product and end up implementing a more solution-oriented approach, you have to be prepared to carry the incremental costs of maintenance and support if your changes don’t end up in a future release of the product.

Finberg says that many customers base their final decisions on the culture of the company and the personalities of the vendors’ representatives.

Start the Prenuptials

“A lot of people are beginning to perceive that many of the top billers have a lot of the same functionality. They want someone they can call a partner, rather than a vendor,” she says. Service providers also have to find a balance between being the most sophisticated-and therefore experimental-carrier using a system, and being one of the smaller-and thus, less significant-carriers using a system.

Grambs says, “In the end we find there are a couple systems will meet the requirements, then it comes down to the negotiations. Somewhat regularly, the first choice vendor doesn’t make it through negotiations and it’s important to have a second choice lined up.”

Formulate a Back-up Plan

It’s not uncommon for a larger carrier to realize midway through an implementation that they’ve chosen poorly and need to cut their losses and move to a new vendor, says Finberg.

Grambs concurs. “Unfortunately this is more common than people would like due to system complexity and lack of understanding of vendor capabilities,” he says. “Usually, this is because the match was not right. Some of the functionality that the carrier needed is still in development in the system, which is more common in areas of service that are still immature. If the vendor doesn’t have the capabilities, but has a proven past in development capabilities, it may be okay.”

Finberg adds: “There are connection problems in every single implementation, even if it involves two complementary vendors which are ‘strategically aligned.’ Every single time they come up against the same issues; they have the same interface and integration problems that they did with the previous implementation.” Although each carrier has some degree of uniqueness that requires minor code alterations, the serious problems arise from the shortage of knowledgeable and experienced system integrators and developers, and the lack of standard APIs. (see “Human Resource Shortage” story, p.xx)

Most vendors attribute the problems to scope changes and the nuances in carriers’ requirements in each implementation, says Kenan Systems’ Wireline Industry Marketing Manager Randy Fuller.

Finberg predicts success for third-party adapters or connectors between systems and end-to-end solutions. Some of the smaller vendors offer an end-to-end package but don’t have the feature-rich functionality of some of the more singularly focused vendors, she says. “The first vendor to offer a proven end-to-end solution will have a major competitive advantage because carriers are starting to get sick of the time, energy and money that is poured into a system integration.”

Meet the Family

Grambs feels that the implementation/integration team should play a major role in the system selection. “The end goal is to have an effective billing capability. Selecting the right system is part of the process, but how you execute really tells the difference between success and being able to use the system the way you want to, and mediocrity or failure,” he says. “Selecting the best system is for naught if it’s not executed and implemented correctly. On the other hand, implementing a mediocre system with the right team can make up for the shortcomings and still have success.”

Service providers in the negotiation process must also address considerations of future customizations, Bruchey says.

“After you’ve selected a vendor, you undergo a gap analysis,” he says. “What you’re trying to do is formalize the difference between what the vendor has and your actual requirements. In other words, you say ‘I need to be able to do XYZ.’ Then the vendor says, ‘yes, I can do that, however I have to do it this way.’ To do it the way you want may mean that code has to be customized. The gap analysis factors all of the potential customizations into a reasonably accurate cost appraisal. If you recognize that something was a requirement, but it was a lower priority, it can be weighed for cost efficiency.

“There are two different approaches to take for customizations. One is that the vendor presents a rough order of magnitude-moving forward on a time and materials basis. X amount of time plus Y for materials, plus or minus some percentage. The other approach is to negotiate with the vendor a fixed price for a particular component or all of the components.” The former way is more common, he says.

“Typically the software vendor takes charge of the customizations to the actual software, any changes to the code, and the installation. The system integrator manages the overall implementation, provides program and quality management, manages the process implementation and plays a role in determining the interfaces to the rest of the client’s organization. The key differentiator between integrators is the ability to manage the overall project and make sure proper expectations have been set and achieved,” Bruchey says. The major driver behind any successful billing system selection, installation and implementation remains communication-and not just between software components. As the systems go into production, new business processes must accompany them, Nespola says.

“Buying a biller without changing the surrounding processes to support the new ways you can do business is sub-optimizing your investment in that application,” he says. “Process review should accompany the new application. By not changing the processes, we have seen companies utilizing only 50 to 75 percent of the capabilities in an application.”