Improving CLEC OSS Environment

The Telecommunications Act of 1996 has ushered in a new era of local competition, as emerging service providers seek to cherry-pick ILECs' high-paying business customers. Since voice-related services still provide the majority of revenues, hundreds of emerging service providers-CLECs, IXCs, ISPs and cable companies-are competing for a share of this market.

The challenge for these providers is not in building the network infrastructure, but rather on the Operation Support Systems front. OSS deals with all aspects of creation, delivery, assurance and accounting of services to customers, and includes functions and processes for pre-ordering, ordering, provisioning, maintenance and repair, billing, customer care and network management. The ILECs took years to build and optimize their OSS for supporting voice services. The emerging providers need to implement similar OSS functions, in a fraction of the time, to have any chance to compete against the incumbents. The problem is compounded by the fact that there is a shortfall of OSS expertise today, and the expertise developed by the Bell companies over the years has been dispersed across hundreds of carriers. Since CLECs offer a broad variety of services such as POTS, Centrex, PBX, voice mail, private line, and Internet, they have the most complex operations among emerging providers. For most CLECs, the volume of orders for voice services (local and long distance) far exceeds that for data services, and hence achieving high throughput for these services is a prime objective.

Among voice-related services, switched local services such as POTS and Centrex are the most complex from an ordering and provisioning standpoint, and they determine most of the OSS requirements. OSS Challenges

CLECs operating in any of the three service delivery modes (See sidebar for a description of different service delivery methods) face significant OSS challenges to be successful in the marketplace. These challenges vary from the complexity of services to the diversity of OSS and the reliance on trading partners.

1. Flow-Through Service Provisioning
Today, a CLEC gauges its success by the number of access lines and customers commissioned. CLECs use a face-to-face sales strategy and employ a significant sales organization that may be a large portion of its workforce. So, it is not surprising that most CLECs have little trouble signing up customers, especially when they offer lower prices and better product bundles than the ILECs. The challenge is that the order volume far exceeds the throughput of their operations.

The goal of each CLEC, is to achieve complete flow-through for all its high-volume services. In this environment flow-through means that once an order is entered and released, it should be untouched by human hands on the CLEC side. This can be achieved by tightly integrating various OSS for inventory, assignment, activation, order management, billing, LEC gateway and LNP ordering.

2. Accuracy of Billing
The billing system database represents the charges billed to the end-user for CLEC services. There are three main ingredients in generating a customer bill: a product definition specifying all recurring and nonrecurring charges for services and features; a customer's service definition specifying the products and services subscribed to, and usage data such as Call Detail Records (CDRs).

The accuracy of a customer's bill depends on the accuracy of the data in the billing system. If the billing process is not coordinated with the ordering and provisioning process, the data in the two systems may be out of synch. In a TSR scenario, the LEC could be charging the CLEC for reselling features for a service, but a CLEC might not be billing its retail customer. In a facility-based scenario, the CLEC could be under-billing the customer if the features provisioned on the switch do not align with the definition in the billing system. This problem is especially acute if the operations environment is manual and nonintegrated. A typical business Centrex service can have 15 -20 lines with dozens of features. The billing for these lines and features has to be coordinated with ordering and provisioning.

3. Dependency on Trading Partners
The vast array of services provided to a customer by an emerging service provider is often a combination of resale and facility-based elements. Today a facility-based CLEC has to deal with a multitude of external trading partners and suppliers such as ILECs, IXCs, NPAC, service bureaus and fulfillment houses. Each of these trading partners supports a separate interface using a separate protocol. For example, ILECs support interfaces ranging from paper, Web and EDI to other proprietary means for exchanging information on preordering and ordering--LSRs (Local Service Requests) and ASRs (Access Service Requests). In addition typical CLECs provide services in multiple regions and hence have to deal with multiple incumbents. Each incumbent requires a different implementation of the gateway function, and even within an ILEC the means for exchanging data depends on the OSS function. For example, Bell Atlantic offers an EDI interface for ordering, but trouble reports are accepted only through the Web interface.

Standards bodies like ATIS (Alliance for Telecommunications Industry Solutions) and its subcommittees such as the OBF (Ordering and Billing Forum) and T1M1 (Trouble Management) are defining guidelines and standards for exchange of information between trading partners. However, it will be a while before all concerned parties converge and adopt these standards.

CLECs in the meantime have to deal with reality and implement separate gateways to all their trading partners. The lack of electronic application-application gateways supported by these trading partners truly hinders a CLEC in integrating gateway functions with its other back-office functions.

4. Integration of Diverse Systems
In support of its operation a CLEC would need to implement a variety of OSSs ranging from customer care, order entry, order management and billing, to trouble ticketing, inventory, assignment, activation and billing mediation. Diverse systems, most likely obtained from a variety of vendors, have to be integrated into a single, seamless OSS. In such a scenario, a common workflow must drive all tasks. Entering an order for a service must result in resource assignment, network activation, a trading partner order, and billing system provisioning, as a unified end-to-end process.

The emerging providers are growing organically (through line growth) as well as through mergers and acquisition. Each growth activity brings about a new set of systems. CLECs who don't design their OSS around a billing or inventory system will be more adaptable to change. Also a front-office, user-facing system that is independent of the billing system and the trading partner interfaces will allow a CLEC to manage change effectively and reduce training time for customer service agents. In the back-office, a workflow engine must be at the heart of the CLEC operations and must drive workflow tasks to completion through other system interfaces.

5. USOCs, USOCs and more USOCs
The Bell companies invented a set of three-character codes (plus optionally additional two-character suffixes) called USOCs (Universal Service Order Codes) that are used to define a customer's service. USOCs identify the service, equipment, and features affected by a service order, as well as all non-usage charges associated with a customer's service. USOCs always have quantities associated with them and are billable entities. When a bill is created, the charges for a customer's use of service are calculated from these USOCs. The incumbent Bell companies use about 20,000 different USOCs. Additional codes called FIDs (field identifiers) are like attributes and can carry customer and account-specific information, or associated with USOCs to describe specific attributes. For example, a remote call forwarding feature USOC-RCD-will have a FID associated with it that represents the telephone number the call is being forwarded to. When CLECs exchange ordering data with the LEC they must communicate in terms of USOCs. USOCs have billing implications, and hence must be handled appropriately. Since USOCs vary from LEC to LEC, and even within a LEC from state to state, the CLEC has to implement the complexity in its OSS to transmit the correct USOC. If not handed intelligently, a CLEC will end up cataloging each and every variation of a USOC in its OSS database. These codes also have to be duplicated in the CLEC billing system to render accurate end-user bills-an administrative nightmare for the CLECs.

Today's CLEC Ordering Process

Most CLECs today operate in a manually intensive environment, whether they are resellers or facility-based. A typical CLEC implements a billing system as a first step in OSS deployment. Interactions with the LEC and other trading partners are handled manually, either using fax or using a system (such as a Web interface) provided by the partner.

As explained in the sidebar, 80 percent of all orders processed by CLECs are "migrations." Most CLECs are pursuing business customers, and these customers have fairly complex service definitions. Moreover, the service was established and modified over the years, and hence most customers cannot produce an accurate description of their current service. It becomes the CLECs' responsibility to discover this service definition and then provision the same definition, as is or with changes, through its own OSS.

The migration process starts when a customer signs an LOA (Letter of Agency) with the CLEC. This gives the CLEC a right to convert service from the LEC. Once the LOA is in place, a CLEC operator requests a Customer Service Record (CSR) for the customer from the LEC. CSRs are cryptic and contain USOCs and FIDs that define customer's current service with the LEC. The CSR is the vehicle through which a CLEC discovers customer's current service. Using the CSR, the CLEC can establish all the customer locations, local telephone lines, features, billing address, LD carrier, and other billable options, as they exist with the LEC. The interpretation of this CSR is a complex process and requires operators well-versed and trained with USOCs and FIDs. In a manual environment, different operators work on different regions, since the CSR rules and USOC and FID catalog differs from LEC to LEC and region to region.

After establishing the customer's service definition from the CSR, the operator creates an appropriate order to the LEC, by filing an LSR (Local Service Request) form or entering the information into the LECs Web interface. In a resale environment, this order is called an assume-as-is (no changes), or an assume-as-specified (with changes). The operator then tracks the responses from the LEC: firm order commitments, order completions and rejections. Once the order is completed, an operator enters all the billing-related order information again into the billing system. It is not uncommon for the data to be incorrectly entered into the billing system, since a business customer for Centrex service can have about 20 lines, each with 20-30 features. Each of these codes has to be entered into the billing system.

A facility-based provider has to perform additional steps as part of the ordering process: order unbundled network elements from the LEC, provision services and features (derived from the CSR) on the switch, provision Local Number Portability (LNP), and set up directory listings and E911 service.

The entire ordering process in this example is labor intensive and requires multiple data entries into different systems, making it prone to errors, reduced order throughput, and inaccurate billing. To add the misery, if the CLEC has multiple billing systems (a realistic scenario looking at the number of mergers and acquisitions in the telecom service provider industry), then customer service data has to be entered into one of the many multiple systems (based on product/service, geography, or any other criteria). Some CLECs, after just a couple of years of operation, have amassed numerous billing systems and cannot even produce an accurate list of their customers.

A typical CLEC provides about 10 services, and for each service and each type of order (new, add, move, changes) a different ordering flow is required. Moreover, an ordering flow has 20-30 associated tasks. For a CLEC processing 10,000 lines a month, this means manually processing millions of tasks a month. This environment leads to Customer Service Agent (CSA) productivity erosion, reduced operations efficiency, lengthened time to bill, and ultimately customer churn.

Integrating OSS Functions

Ordering and provisioning are the key processes within a provider's operations, since they are the first steps in establishing customer's service. The previous section described a manual service order management process. High ordering efficiencies and better levels of customer service can be achieved by automating some of the most complex and manually intensive steps.

1. Customer Centric OSS
Every CLEC wants to differentiate itself from the incumbent on the basis of the quality and level of service. To enable CSAs to serve each customer - expeditiously and accurately, all customer data must be made available to them from a single point. To obtain this customer-centric view, a number of front-office (account management, contact management, trouble ticketing) and back-office (billing and order management) systems have to integrated. Once this integration is complete, a CSA can perform all work from one system, in relation to a customer, may it be trouble inquiry, a billing adjustment or a new service order. This concept of a Customer Workspace provides a way to integrate different applications through desktop level integration, as well as data level integration. The customer database is independent of any OSS function. The action performed in relation to a customer invokes the appropriate application with the right set of data.

2. Auto Order Creation
Since a CSR describes a customer's current service definition with the LEC, it can be a starting point for creating an order for a CLEC service. After electronically retrieving the CSR from the LEC (either via EDI or FTP), the CSR is parsed based on the LEC-specific parsing rules. The parsed data in an intermediate format is passed to the CSR mapper. The CSR mapper uses CLEC-defined rules and product definitions to map the parsed data to a service definition in an object-oriented manner. For example, the mapping function can map multiple flavors of LEC Centrex service described by multiple USOCs to a single CLEC Centrex service definition. This function dramatically reduces the complexity imposed on CLEC OSSs by LEC service definitions. Moreover, the CSR mapper can identify USOCs that don't map to any CLEC service, those that are "not priced," and those that have been "grandfathered" by the LEC.

Once the CLEC service definition has been created, a CSA can directly convert the service definition to a "migration" order and then view and modify the order to incorporate changes requested by the customer. Upon completion this order will accurately reflect the customer's service with the CLEC. A facility based CLEC can use the services, features and attributes described in the order to provision the service on its own switch.

This process dramatically reduces, or in some cases completely eliminates, the amount of order entry required to complete a migration. Since order entry and conversion errors are reduced, the process results in higher order throughput and dramatically faster migrations. This will in turn add important dollars to the CLECs' bottom line and reduce customer churn.

3. Service Order Processing
Once an order is released, a number of tasks have to be executed to complete the order. A workflow engine called the Service Order Manager (SOM) manages these tasks. The workflow associated with each type of order for each service is pre-configured in the SOM. The workflow can be a simple sequence of tasks, or a complex mix of tasks with dependencies and exception handling procedures. Each task can be executed in a manual mode or an automated mode. Manual tasks are provided to the users for processing. A typical workflow for provisioning of a UNE order includes, obtaining a line equipment assignment from the inventory system, sending the UNE order to the LEC, activating services and features on the switch, communicating LNP data with the NPAC, transmitting E911 and directory services request to a service bureau, and updating the billing system to enable accurate billing of the service.

Since the SOM updates the customer database with task completion information, the status of an order in the context of a customer can be viewed at any instance from the Customer Workspace. SOM has app-app interfaces to other OSS systems such as inventory and assignment, activation, gateway, and billing to enable "no-touch" provisioning. The electronic processing of workflow and its associated tasks is a key step toward achieving flow-through provisioning. Since ordering and provisioning is coordinated with billing, the customer's bills are accurate. The centralized workflow and automated interfaces improve order throughput and dramatically reduce operational expenses.