Carriers Seek Stronger Contracts for Billing and OSS Projects
Susana Schwartz
05/01/2004
For carriers, upgrading legacy systems to next-generation OSS and billing has often led to implementation costs that are three to four times that of the initial software purchase and projects that were not completed on time or on budget. However, operators are trying to change that by devising stronger contracts around licensing, co-sourcing and outsourcing. Carriers increasingly want control in deciding the best way to implement and integrate projects, even if it means utilizing a mix of technology from competing vendors.
“There was definitely a different spin in our last round of OSS purchases and buildouts,” says Brian Crotty, president of BridgeCom International, an ICP delivering voice and data services in the New York metropolitan area. As a reseller of resale and unbundled network elements (UNE-P), BridgeCom has grown quickly through its focus on streamlining back-office processes—both through homegrown systems, as well as a mix of more than a dozen solutions, including provisioning, reporting and inventory management from Concretio, as well as billing and CRM from Info Directions.
More than ever, Crotty notices billing and OSS players bending over backwards to accommodate his company’s needs. “They’ve done wonders in getting our systems to integrate,” says Crotty, explaining that, for instance, Info Directions, despite moving its systems from fat-client to Web-based models around .NET, is migrating .NET to client/server for BridgeCom. “Additionally, Concretio has proactively called our billing and hardware partners in order to get systems, switches and infrastructure tightly integrated.”
That’s a big switch from a few years ago, when it seemed everyone had everyone else’s logo on their Web site, regardless of whether there was a true partnership.
“Carriers no longer tolerate an integration project that becomes a razor for which they have to continuously buy blades,” says Kevin Williams, president and CEO of Concretio. “For that reason, OSS players can no longer sell products solely on product specifications to which carriers must adapt their business process to the functionality of the software.”
Rather, the consensus seems to be that OSS functionality has to be optimized and tailored around each customer’s business process and customer relationships in a proactive and flexible manner. That’s where the contract and its key components come in.
SLAs
Whether the RFP phase, pre-contract or contract phases, variables around volumes, scale, openness and customization must be outlined in greater detail for both the carrier’s sake and that of the vendor. Carriers need to know what to expect in terms of integration, knowledge transfer and upgrades. Vendors, who’ve also been affected by customers’ hardships, also need a certain level of protection, namely around expectations and change management so that projects don’t morph out of control once they start for reasons beyond the vendor’s control. In cases where service providers have determined their project’s scope, as well as the costs and expectations, the onus is on the vendor—whose job it is to meet expectations —to really evaluate and determine if the project can be done in the timeframe and manner specified.
“We’ve noticed that aggressive negotiations have made the terms-and-conditions phase of contracts more contentious, as RFPs have much more language about performance and timeframes than before,” says Don Tiedeman, director of architecture for Fujitsu Consulting.
He says one of the biggest pitfalls he sees is smaller companies in the RFP phase lulled into believing what they will have will keep them satisfied for 10 years. “Smaller companies that haven’t been burned so badly sometimes leave things out,” says Tiedeman, who recommends getting advice from intellectual property lawyers or consultants for projects in the $500,000 range or above.
In the RFP phase, carriers increasingly seek help in getting assurances around the estimated costs for customization and then take advantage of the capability to run competing packages in parallel before drawing up RFPs or contracts. That is becoming a common way for carriers to test not only order taking or bill processing ability, but integration capabilities between existing and new systems—all without hefty costs.
Additionally, carriers look for proof of not only the product’s capabilities, but of the vendor’s services capabilities. As vendors focus more and more on the service part of their business, SLAs increasingly spell out expectations around accuracy and timeliness of bills, as well as ongoing OpEx costs.
“SLAs should outline multiple levels of service, implementation costs, spending caps and timeframes—all paramount to determining the materials, labor and support are locked in,” says Crotty, noting the importance of setting absolute limits for getting systems to work the way you want them to work. That means some demonstration of understanding of what interdependencies the business processes have as they flow at the contract phase and how they will differ once the new system is implemented or the existing one upgraded.
Once the project falls into the hands of the true programmers creating the applications for sales and marketing, it’s too late. “You have to possess a high level of detail in the contract before you convert systems,” says Crotty. “You want to ensure that should they fail to integrate operational and functional areas within a certain timeframe and at a certain cost, that it’s their dime, not yours.”
In devising those timeframes and costs, carriers have to be sure to balance business goals with timeframes. Business goals should not suffer for a drive to meet time constraints. “To rush and leave important things out benefits no one in the end,” says Mark Farmer, director of marketing with Amdocs. “While there are companies whose main selling points are their commitments to meeting timelines—which they can get very good at—the fact remains that what is delivered at the end of the day is most important.” He recommends carriers look at reference accounts for more than timeframe compliance and more about whether or not the vendor met expectations around improving business processes and strategy.
ROI
In contracts, ROI can be a challenging variable to quantify, especially with the shift in IT organizations to justify projects based on business priorities.
“It’s important that companies focus on their specific business drivers and evaluate cost structure when building contracts,” says Marquita Martin, director of product management at Convergys. “We find that ROI is not tied necessarily to contracts, but we are asked more and more to include it in the planning process.” As a result, Convergys does economic modeling to show the savings yielded by automating processes. Convergys has also seen an increase in interest around revenue share concepts.
For Amdocs, ROI has come up with some big contracts, such as Bell Canada and Nextel. “They wanted a vendor who could help them find the potential value in their implementations,” says Farmer, who concedes it’s difficult to “commit to ROI,” however as a step in that direction, he says vendors can establish metrics for ROI and develop a plan for a true business case for developing ROI.
Rather than set tangible ROI goals, contracts usually consist of a projected goal, and then a cushion, and then a definitive cap that serves as a rigid parameter to be met in terms of what a carrier is willing to pay. “That entire process has to be pre-documented,” says Crotty, but even then, he warns, carriers should expect some glitches. “It is inevitable in next-generation applications and networks that entirely new modules or projects outside the initial scope are going to emerge, but you have to try to plan as much of that ahead of time as possible,” says Crotty.
Intellectual Property
Another issue that has to be considered way ahead of time is that of knowledge transfer and who owns the system once it is implemented. In the past, it was not typical that a contract would dictate parameters about handing over control, but if an operator is going to be running a large system itself, it must be clear on whether the OSS and billing vendors own the software, even after the purchase and tailoring of the software is complete.
Guidelines around knowledge transfer would possibly have mitigated the pains experienced by some high-profile cases, where large carriers had to go through the costly process of kicking out incumbent vendors and migrating to new platforms because they realized too late down the road that they had no people trained in the vendor’s billing environment. Without guidelines around knowledge transfer, operators end up having to hire large amounts of their vendor’s people during conversions, which means a very high price tag.
“We dictate that we have access to source code so that should we become dissatisfied or should a partner go bankrupt, we are protected,” says BridgeCom’s Crotty, who says he’s seen companies flounder when partners file for Chapter 11 or charge unexpectedly exorbitant fees for upgrades down the road. “Nowadays, we won’t even do business with a company if they don’t sign something saying we have significant control over our OSSes. There’s no point going further contractually if they’re not flexible enough to allow us to maintain control.”
“If a carrier wants to own the system when it’s all done, they have to have a knowledge base,” says Bob Sobczak, vice president of North American sales for Intec Telecom Systems. He says carriers should put milestones into the contract that reflect turnover and parallel implementations so that the cut-over time is established early on.
The advice to carriers from Concretio’s Williams is to “avoid locking yourselves into globally-specific commitments,” as integration efforts then usually involve multiple parties. “That's where you get hit with recurring integration costs, which usually occur when service providers agree to allow one OSS vendor to do all the integration for provisioning flows.” Because exclusivity can mean little or no alternatives once uncertainties are encountered, carriers building next-generation networks should be wary of engaging in such contracts.
“With the advent of multi-service cable, operators are finding it difficult to deal with just one vendor for all contracts,” says Anthony Starkey, vice president of business development with Mentis Broadband. “They are having now to deal with 15 different initiatives around triple play, and they all feed back to the core billing system.” As a result, Starkey sees a lot of cable operators relying on program management organizations to handle vendor partnerships and contracts. “They want more control over what consultants do in decision making, as there was too much leeway given in the past. They see they need more control, as accountability ultimately lay with the service provider.”
For carriers, losing control over tactical requirements could prove to be extremely expensive down the road, so it is recommended that carriers establish project teams comprised of their own people, in addition to their primary OSS providers and NE vendors. Even when co-sourcing or outsourcing all implementation, integration and maintenance, carriers should get information about intellectual property and upgrades on paper.
“A vendor has to have the flexibility to set up the types of joint ventures carriers want these days,” says Seth Nesbitt, marketing director of Amdocs. “Some carriers want to ‘ease’ into outsourcing arrangements.” Such was the case with Bell Canada, for whom Amdocs consolidated billing and customer care across multiple lines of business. Bell Canada wanted to maintain equity control of the organization that implemented the platform for them, so Amdocs set up a joint venture [Certen], which, after a certain high-risk period ended, Bell Canada became “comfortable enough” to allow Amdocs to buy out the rest of the joint venture, with the BPO outsourced to Bell, according to Nesbitt.
For Nextel, for whom Amdocs consolidated 14 databases and 11 billing systems, the tack was different. “In their RFP, they wanted it very clearly demonstrated how we’d consolidate their systems without disrupting their prodigious databases, price plans and thousands of customers. They had already been disappointed by two companies who failed to do that for them,” says Farmer. For Nextel, the answer was an outsourcing arrangement, which required a contract where fixed prices were associated with metrics around such things as fixed price per monthly bill or number of subscribers managed monthly.
Version Control
Version control expectations have to be documented early on if carriers are to ensure that current versions of billing and OSSes stay synchronized with other systems and databases once upgraded.
“It’s been in our best interest to lock in the bulk of ensuing releases two or three years in advance,” says Crotty. Because BridgeCom has an entirely softswitch network and next-generation application set, a lot of its inventory is comprised of virtual components. “That takes us beyond a physical realm and level, so we have to pre-buy for future releases so that we know our components will evolve as they need to.” Pre-documenting features that should be delivered in a particular timeframe is important for that to happen, he says. “If the vendor doesn’t deliver, then there should be financial penalties that give money back to the carrier,” Crotty adds.
In order to minimize the impact on spending, carriers need to know how much to expect to spend in reinvesting on upcoming versions.
“One thing we do with implementations is guarantee support for future releases, even if the technology changes,” says Convergys’ Martin. “We commit to supporting them and giving significant notice to customers,” she adds, noting that often means two releases ahead of time to ensure carriers can accommodate changes to their standard way of interfacing with existing systems.
“For operators with legacy environment issues, agreements should be made around published APIs that integrate easily with legacy environments,” according to Shirley Evans, senior director of product management at Convergys. “You don’t want to be locked into working with one vendor if your goal is a robust footprint, so you want APIs that allow you to configure and customize a solution without sacrificing the ability to move forward on a product.”
For that reason, carriers increasingly put language in contracts around component-based systems that have extensibility through open APIs. That facilitates an environment where they can do integration themselves or have SIs come in. “As you plan to broaden your billing system for vertical market extensions, carriers should think of the plug-in points they need for developing interfaces,” says Martin, noting that ultimately, linking up with other vendors through plug-and-play environments can reduce implementation costs.
In the mediation layer, there are many integrations that have to happen over time, making contracts around open APIs very important, according to Sarit Kaserzonm, marketing communications manager at Sheer Networks. “If integrating through order management systems for special services that must evolve to integrate for video-on-demand service on the same platform, contracts have to address expansion.” He says determinations of whether expansions will happen on top of existing platforms or on additional ones are to be considered before contracts are signed.
On the product side, carriers also want to make sure vendors will invest the time and effort into creating products if they can’t meet business issues with the ones they have. That means addressing R&D strategy in contracts, so that it can be determined that the vendor will evolve as the carrier needs more. “Whether outsourcing, joint ventures or R&D for developing solutions, contracts should spell out whether the vendor is willing to invest time and effort to address issues on the services side,” says Farmer. He adds that carriers in contracts should be clear on whether the vendor has the ability to adapt customized solutions as mainstream products down the road, so upgrades remain cost-effective.
Contingency Planning
An important aspect of version control is contingency planning, particularly for large engagements. Carriers should expect that OSS or billing vendors draw up planned analyses of key break points in their solutions, as well as contingency plans to cover them. “That should be part of the proposal that comes back from RFPs,” says Fujitsu’s Tiedeman.
Contingency planning can be very arduous, however, as it can be very difficult to get all parties involved to agree on full liability.
“Contingency planning with OSS contracts is a bit more difficult than with billing, as their nature is more ambiguous,” Williams says. “While you can put in stone the amount of accounts receivables procured in a day or CDRs processed per second, it’s more complicated to look at back-office provisioning of workflow automation and see what specific deliverables they can promise in the contract.”
For example, carriers might include clauses about the OSS vendor having to prove it can interface with certain switch specifications, so as to ensure everything will flow as it should.
Contingency planning means also taking into account learning curves necessary for building interfaces to next-generation switch providers. Vendors should be sure, if there are new API specs that emerge as the project evolves, to allocate time for expanding tool kits. “This is the time to be honest and set realistic expectations,” says Crotty.
Carriers should make sure they have the freedom to utilize other resources in an integration project if necessary. For that reason, contingency planning is becoming as important as the initial planning phase. That is especially true when there are multi-faceted, multi-party plans in the making. “The more pieces that exist, the greater the chances that some or many won’t have their deliverables on time,” says Williams.
To remedy that, service providers should, in the earliest stages of negotiation, communicate the importance and frequency of project status reviews. “If you don’t do that, one deliverable could impact an entire project,” says Williams.
Service providers, therefore, have to identify the risks inherent with certain elements ahead of time. “You have to do testing as you implement, so you want the contract to reflect that,” says Intec’s Sobczak.
For example, if an operator is building an automated process that requires the availability of a new interface from an ILEC that is scheduled to be available before the integration project is completed, the carrier should take the time to identify a contingency process in the absence of that interface so that it can still benefit from the rest of the process automation during the delay.
With contingency plans in their contracts, service providers can decide with vendors where manual workarounds could exist should a problem occur, thus affording them a chance to stay on target and realize a return on their investment as soon as possible—one of the key reasons for having a contract.
In a market as turbulent as telecom, where accounting discrepancies have pushed even the biggest telecommunication giants into bankruptcy, contingency planning is a must. Without it, the crucial contract components of SLAs, knowledge transfer, version control and upgrades are at risk.
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article