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:
- 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.
- 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.
- 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.
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.
