The changing requirements of telecom operations and business support systems

Operations support systems (OSSs) have always been essential software tools for the telecom industry, but as networks converge on IP, and business relationships and standards change, there is more emphasis on OSSs than ever before. This Telecom Insights series examines the major types of operations and billing support systems in this fast-changing industry, as well as "revenue assurance" issues that will help service providers prevent their revenue from "leaking" away due to common technology errors. Telecom service providers have to balance network evolution, new services and changing business process and OSS needs. Check out this series to help you with the process.

Operations support systems (OSSs) have always been essential software tools for the telecom industry, but as networks converge on IP, and business relationships and standards change, there is more emphasis on OSSs than ever before. This Telecom Insights series examines the major types of operations and billing support systems in this fast-changing industry, as well as "revenue assurance" issues that will help service providers prevent their revenue from "leaking" away due to common technology errors. Telecom service providers have to balance network evolution, new services and changing business process and OSS needs. Check out this series to help you with the process.

Fundamentals of working with operations support systems
by Tom Nolle 

The term operations support systems (OSS) is applied to the set of software tools that provide business support to providers of telecommunications, data communications, and other network services. These systems have been in use for as long as service providers have used computers, but they are an area where significant changes have been occurring recently as a result of changes in network technology, business relationships, standards, and other areas of business practice.

OSSs are expected to conform to a number of regulatory/compliance standards, and these vary, based not only on where the service provider operates but on its size, the nature of its business, and so on. Compliance is the responsibility of the provider and not of the vendors who may provide operations support systems or components, and the first thing any professional working with OSS must do is establish the compliance requirements that apply to their business. These requirements must be considered through OSS selection, installation and maintenance.

At a high level, there are three types of operations support systems, and you will need to understand clearly which of the three you have, or will deploy:

  1. Integrated single-provider OSS, where the entire software suite is provided by a single vendor. In this case, the integration of features and components is the responsibility of that vendor. In many cases, integrated OSS providers will make statements on the compliance features they offer, and though these can never be taken as authoritative, they will at least provide a starting point in considering compliance requirements.
  2.  OSS created from a common standard architecture, most likely the architecture defined by the TeleManagement Forum (TMF) enhanced Telecommunications Operations Map (eTOM), which provides detailed structural and interface rules. In this case, your integration of components of the OSS will be based on this standards set. Standards may in some cases offer broad comment on compliance, but they are less likely to offer rigorous compliance requirements because of the variability of those requirements.
  3.  OSS created through discrete integration of components. This means you will be building up your OSS by selecting components for integration. In this case, you will be responsible for the integration of components yourself. With this approach, compliance will be entirely up to your organization.

OSS will typically link to service provider operations processes and personnel in three primary dimensions: customer-facing, partner-facing and network-facing. In each of these areas, variations in provider practices will probably create specialized needs for interfacing and customization, and it is these areas where most professionals working with OSS will be focusing.

The primary question on integration in the customer dimension is the nature of the services. Services with high contract values and long contract terms are often customized manually at the time of order negotiation, and automated customer order tools are sometimes not only not needed but intrusive. On the other hand, services of short duration and low value, especially consumer services, cannot be supported economically without a high degree of automated ordering and customer care.

Operations support system processes that are built around a service model and that support automatic conversion of orders into resource commitments are most suitable where service automation is needed. Where more manual activity is involved, OSS processes based on supporting operations personnel in their activity will be more useful.

The partner/supplier dimension is more difficult. Not all service providers will wholesale to or obtain wholesale service components from others. The industry trend is definitely to the contrary, though, and you should probably not assume that this requirement will not affect your operation at some point. Partner/supplier integration involves the exchange of service orders and the exchange of service status. The primary issue in the former is ensuring that the processing of a service order for a wholesale component is fast enough to meet the service creation time target, and that customer care on orders with wholesale components is still effective.

This is true whether you are the wholesaler of a component or the receiver of such a component. Service status exchange will normally mean exchanging network status information on wholesale services, and this should be carefully planned because the passing of this type of information and the correlation of the information with the retail order is often difficult.

In the network dimension, the major challenge OSS planners and implementers face is the multiplicity of network equipment and network management systems. There are, at present, no standards that fully define a network management interface to an operations support system at sufficient detail to support complete network control by the OSS processes. Even where there is some standardization (TMF's Multi Technology Operations System Interface, or MTOSI), it is not supported by all equipment vendors. Operators report that integration between network equipment/management systems and OSS is often the largest single integration task in OSS installation, and processes here will have to be updated not only with the addition of new vendors or equipment, but sometimes even when new versions of an installed product's software base are made available.

It is often possible to use standard billing and order software to augment service-specific operations support software in smaller service provider installations, but the larger the provider is and the more regulated its operation, the more likely it is that a complete operations support system suite from a major vendor, or a set of products adhering to a common OSS standard such as the TMF's eTOM, will be the best approach.

Service provider billing system fundamentals
by Tom Nolle 

Billing systems for service providers vary considerably in their focus and complexity, and this is due to the variety of service/business models in place. At one end of the complexity range, providers may find that billing system products for standard enterprise use are completely suitable; at the other extreme, they may find that only highly specialized provider billing packages will suit their needs. The two primary issue areas for billing systems are those of integration into the operations system support and business processes, and support for the proper billing paradigm set required for the service mix.

Billing systems have to be integrated into the overall context of service provider operations. Service provider billing systems may address any or all of the following issues, depending on the business model and service set of the provider:

  1. Journal integration. Most service providers offer at least some services whose billing requires the collection of journaled data from call recording systems or other service event generation systems. This data can be broadly classified as "call event data" or "usage data," where the former collects information on service relationships created, and the latter, on the usage of resources (bandwidth, packet counts, etc.). There is a general industry trend away from usage pricing, but in many cases this level of detail may still be required for regulatory/compliance reasons.
  2. Customer management integration. Obviously, billing systems will have to integrate with customer relationship management systems (OSS elements) at a higher level to obtain information such as customer name and address. It will also normally be necessary to use customer data for information on pricing, service plans, and the applicability of certain specialized charges, such as taxes. Customer-care activities will normally require billing application access, since many inquiries will concern billing issues.
  3. Service management and activation integration. Providers typically demand that service orders and, more specifically, the activation, deactivation and change to service conditions be directly integrated with billing systems, even when the events may not change actual charging. Many jurisdictions require that operators list service features and service plan data on bills.

These integration requirements are normally in the scope of operations support systems (OSS), where such systems include a billing module/process. And where an integrated package or a standard operations system support framework is followed -- the TeleManagement Forum's enhanced Telecommunications Operations Map (eTOM), for instance -- this integration will fall out of the OSS activity.

Of the three issue areas for billing integration, the linkage to customer relationship management is the most critical. Billing questions generate a significant amount of customer interaction, and billing systems can both reduce the chances of a customer billing inquiry and improve the response to one that occurs.

The format of a bill must accommodate the need of the provider to communicate the charges and amount due, the needs of the regulatory processes for disclosures, the ability of the customer to understand the information, and the opportunity a bill presents for communication with the customer, even on non-billing issues.

Most leading-edge billing products are based on a separation of the processing of billing items and the presentation of those items. This accommodates not only the need to create flexible bill formats in the printed bills but also the desire by most providers to encourage online bill review and payment. The same capabilities can be used to give customers and customer service representatives different views of the same account data. The most desirable structure allows bills to be composed in a flexible language like XML, based on variables exposed during bill data collection and calculation. This capability will normally provide considerable flexibility, but some service providers may require additional features, such as the ability to support multiple languages to accommodate ethnic groups within the customer population.

Service provider billing packages will normally accommodate a wide variety of billing paradigms, which can be broadly grouped as billing calculation paradigms and billing integration paradigms.

Billing calculation paradigms embrace the choices in fixed-plan billing, multi-service discounts, incident (call or usage) billing, and so on. Most billing systems will support all of these options providing that they support the input of the proper journaling information, but you should verify that the incident billing calculations available will support your specific needs there, since this is the area where the greatest variability in product capability exists.

At the highest level, the products support business unit billing integration to accommodate the so-called "triple-play" multiple-service packages, where each service may have its own operations processes and may even be provided by different business units. Within this high-level structure, the normal hierarchy would be to include services, which are individual retail offers, and features, which are optional additional capabilities, and within these to provide for both package/feature prices and incident/usage prices.

Taxes and fees are not normally applied uniformly across all business units, services, and sometimes even features. Thus, it is important that the products accommodate these for each business/service combination and not just at the total-bill level. Basic telecommunications services are often not subject to local taxes, for example, but some advanced services may be. Similarly, universal service charges may be applicable to some services on a bill and not to others.

Any changes to billing systems should be tested and verified with great care because errors that generate customer inquiries will be very costly to resolve, and failure to accommodate all the applicable regulations may subject your service provider to fines and penalties.

About the author: Tom Nolle is president of CIMI Corporation, a strategic consulting firm specializing in telecommunications and data communications since 1982. He is a member of the IEEE, ACM and the IPsphere Forum, and publisher of Netwatcher, a journal in advanced telecommunications strategy issues. Tom is actively involved in LAN, MAN and WAN issues for both enterprises and service providers and also provides technical consultation to equipment vendors on standards, markets and emerging technologies.

Revenue assurance a critical tool for telecom success
by Michael Morisy, SearchTelecom.com News Writer 

Increasingly complex telecom networks are leaving more openings for revenue leakage from technical errors and fraud, a recent study suggests; and without proper revenue assurance practices, losses may get worse.

The annual study, conducted by Analysys and paid for by revenue assurance provider Subex Azure, found that average revenue leakage increased from 12.1% to 13.6% of turnover from the 2006 to 2007 surveys.

Geoff Ibbett, director of product management at Subex Azure, said that many companies are in denial about the amount of revenue that -- for one reason or another -- is never collected or accounted for.

"There is an attitude in the industry that we're not part of that, we're [losing] less than 1%," Ibbett said. "Until they actually monitor it … they really don't know."

Those losses come from a variety of sources, he said, and even if a provider has a handle on one area, other areas can quickly cause problems.

Some of the problem areas the survey highlighted are:

  • Poor processes and procedures
  • Poor systems integration
  • Applying new products and prices
  • Invoicing system errors
  • Rating or prepaid charging failure
  • Incomplete or incorrect usage data
  • Interconnect and partner payment errors

Ibbett said Subex Azure has developed a suite of tools to help quantify revenue loss and tie it to specific issues.

The system works alongside the billing agent, ideally collecting information as close to the subscriber as possible. The system then looks at the billing information and models projected usage both from the subscriber-side data and from billing data to compare actual usage and data patterns with what the billing system is reporting. That data is analyzed for discrepancies, which can be further studied to find fault points in the current system.

These faults points can range from consumer or operator fraud to services deployed without proper billing rules being in place. Ibbett gave one example where an engineer created a rule discarding any call longer than five days as a system error. While few voice calls ever lasted five days, plenty of data connections did last that long, and important revenue streams were being discarded as false operator errors.

Revenue assurance can also mean more than making sure proper billing was being implemented, Ibbett said. Complex systems often overlook the "recycling" of resources from cancelled services, so networks are oversupplied with connectivity even as some users leave. Subex Azure, he said, can rapidly find these unallocated resources and alert the provider to the error.

Critical to a provider's handing over revenue assurance to a third party is the need for security and for the revenue assurance not to disrupt the current billing operations.

"Subex Azure's system works independent of existing systems within the billing chain," Ibbett said. "So we don't put the billing chain at risk; we sit parallel to it."

By sitting outside the chain, these solutions can not only audit the information in regular reports, they can also be set to regularly alert the operator of corrective actions to take (such as billing a customer for provided services) or even take the corrective actions automatically, with the provider's monitoring.

Ibbett said that revenue assurance has come into its own as a discipline only in the past few years. As some vendors continue to discover major revenue losses, the field is becoming more formalized and comprehensive.

The next step, he says, is taking the traditionally separate departments of revenue assurance, fraud and credit risk and being able to see them in the larger context of revenue assurance as a whole. This holistic view is particularly important as convergence makes networks more and more complex -- and open to loss.

"Subex Azure is merging its systems to provide a consolidated view of these things," Ibbett said. And despite all the major revenue loss issues already highlighted, network convergence, cross-network interoperability and new technology platforms like IMS will continue to open up new ways for critical revenues to disappear.

"[The survey is] just really scratching the surface in terms of issues," he said.

Next-gen OSS may include revenue operations centers (ROCs) to monitor business processes
By Kate Gerwig, SearchTelecom.com editor 

In an environment where change is the only constant, service providers are faced with consolidating operations from a variety of acquisitions while they're reinventing themselves as visionary "next-gen" providers, even though the successful business model is far from clear. Not only do providers have to consolidate their networks and roll out new services, but they must somehow manage to have effective operations support systems (OSS) in place to keep track of how the whole business is functioning.

From the macro to the micro challenges facing the telecom industry, OSS expert Mark Nicholson, chief technology officer of Subex, has heard it all from service providers around the world. Nicholson talked to SearchTelecom.com's site editor Kate Gerwig about how providers are evolving and changing their business processes as they go through a network transformation.

At the Billing and OSS conference in April, Nicholson took part in a panel discussion about the value of providers building a revenue operations centers (ROCs) that would enable operators to monitor network operations and correlate their impact on revenue, costs and financial statements, much as their network operations centers (NOCs) measure the health of their networks.

What are service providers' main concerns in transitioning from their legacy operations support systems to the systems they'll need in the future? Mark Nicholson: The biggest challenge is that the telecommunications business is going through an evolution that's not finished. When you're going through that, it's hard to understand what your target state would look like, so it's hard to come up with the business processes and the OSS systems you'll need.

From your position, do you know what next-gen OSS will look like? Mark Nicholson: Everyone is talking about the "adaptive enterprise," and not just for telecom. That's the one constant. So the solution is to create an environment that can adapt more readily to change when it comes up, because who knows what the target state of service providers will look like in three, five or 10 years.

Is telecom any different from any other industry going through change? Mark Nicholson: What regulators and service providers are struggling with is that you have a business going through rapid technology change, and yet the magnitude of the challenge is radical because you're talking about national infrastructure. You don't want to make rash decisions. Somehow the industry has to find billions or trillions of dollars to reinvent itself. Where is it going to find that? Who's going to pay for it?

Since the end result is uncertain, what kind of OSS choices do service providers have? Mark Nicholson: The question for providers to answer is what aspects of their businesses they should change now. They need to decide whether to invest large amounts of human and financial capital in making a wholesale transformation now, or wait until there's more stability when they know what the business model might be. The group that wants to make wholesale changes now wants to make sure that their systems are adaptable. The other model is not to spend billions now but make incremental changes until there is some clarity.

How does industry consolidation affect business transformation? Mark Nicholson: Lots of consolidation has already happened in the U.S., and now providers have three of everything, and thousands of operations. Most executives see the incremental approach as more pragmatic because you don't want to go through wholesale transformation when you're in the middle of consolidation. But we have customers doing it both ways. Those using the hybrid approach are trying to make new services like video work with processes existing for voice, for example. The good thing is that you can put a toe in the water and see how it works.

When you take a micro look at the service provider environment, what's going on? Mark Nicholson: They're offering new products and services all based on a new technology, the IP protocol and digital media, which goes beyond video. Software is now content, and managed applications can be offered by traditional telecom operators, but this is a new model for them. In terms of network engineering, the challenge is to serve a multitude of market segments with different quality levels all on one network.

Serving the enlightened customer is another challenge. They don't want to hear all about the technical stuff. They want the provider to make things work, and they have a vision of what they want their services to look like. Video is a good example. Customers don't want to hear about latency and jitter. They want it to work like the cable they're used to.

You've been evangelizing the idea that service providers establish a revenue operations center (ROC), a similar concept to their network operations centers (NOCs). Can you explain your vision of a ROC? Mark Nicholson: Revenue operations centers, or ROCs, are something providers are beginning to think about. If a NOC shows the health of the network, a near-real-time ROC would show the health of service provider operations. This is still a new concept for service providers, but one of the things driving it is the focus on the company's financial performance vs. the network. There's a shift in the value of the brand, not just the network.

You can think of a ROC as the equivalent of a big screen with dashboards to show the health of operations. So you'd see orders coming in for certain types of services, see when trucks go out to a customer's location, see people calling in about video services, that sort of thing. A ROC could focus the impact of different departments on a product, the profitability of a service, and tie in all of the costs associated with a product. It would help service providers focus on operational efficiency across the board, not just department by department.

Does the technology to create a ROC exist? Mark Nicholson: We're pretty close to having the technology. Fifteen to 20 years ago, we had systems to do audits that did spot checks on revenue operations. Now you have the tools to check the health of the revenue chain all the way from events in the network to booked revenue.

The evolution of checking the revenue chain is the ability to check the other huge chains in the telco -- engineering and planning, ordering equipment, figuring out where to upgrade. Monitoring the service assurance chain is part of post-fulfillment, and it's all assuring that the customer is getting what they're supposed to get.

What's driving the acceleration of the ROC concept? Mark Nicholson: It goes back to the strategy of adaptability. Providers use a lot of third-party resources, but from a business point of view, services are supposed to be seamless. So a ROC comes in here, too, not just to monitor functions and resources within your control, but those included in your supply chain.

About the author: Tom Nolle is president of CIMI Corporation, a strategic consulting firm specializing in telecommunications and data communications since 1982. He is a member of the IEEE, ACM and the IPsphere Forum, and the publisher of Netwatcher, a journal in advanced telecommunications strategy issues. Tom is actively involved in LAN, MAN and WAN issues for both enterprises and service providers and also provides technical consultation to equipment vendors on standards, markets and emerging technologies.

This was first published in November 2008

Dig deeper on Telecom OSS and BSS

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchNetworking

SearchDataCenter

SearchCloudComputing

SearchCloudProvider

Close