November/December 2001

Bridging The Gap: Integrating Customer Management And Network Management

BY ADAM BOONE AND JOHN JANETOS

As a well-known marketing truism notes: Its more profitable in the long run to ensure a happy, loyal customer than to constantly fight to find new ones.

Forward-looking service providers have always recognized the need to focus on improving the customer experience. To minimize churn, these service providers inherently understand that responsiveness to customers and customer issues is a top priority. Customers want high-availability services that perform as promised, are delivered as promised, and are billed as promised. As another time-tested business truism states: No one wants to pay for more than they need.

Within telecommunications, the renewed emphasis on increasing customer loyalty has given rise to a host of products designed to deliver a better customer experience. These customer relationship management (CRM) solutions provide carriers with a more holistic view of their customers, but a fundamental problem stands in the way of fully realizing the benefits of these systems. Simply put, the functions and processes that manage customers whether dubbed customer care, CRM, accounting, or any other name often have little, if any, direct connection to the network and the processes that manage the network. This disconnection between the network and the customer processes prevents the service provider from having a truly unified view of its individual customers and inhibits the service providers ability to ensure an optimal customer experience.

There is, however, a new way to plan and implement an operations support systems (OSS) structure that enables network-facing systems and customer-facing systems to share immediate and useful information on the actual status of the network as it relates to every customer. This strategy customer-aware service management enables a service provider to directly link network management functions with customer management systems, making the customer the common denominator of network and service operations.

THE OSS FRAGMENTATION PROBLEM
Imagine a restaurant where the waiters did not directly communicate with the chefs in the kitchen. Dinner orders would get lost, chefs would have no way of knowing what to prepare, and what emerged from the kitchen would bear little resemblance to what was ordered. Customers would flee in droves. How long could such a restaurant stay in business? In todays OSS world, our restaurant analogy is close to the mark. Todays OSS is typically a loosely federated set of systems and processes that manage the network and the services running across it. These systems and processes are often either manually integrated or not integrated at all.

The network-facing systems and processes focus on provisioning and service activation, fault management, performance monitoring, and similar tasks. An order management/workflow system typically guides these processes in conjunction with an inventory system that tracks network resources to deliver the service to the customer. The customer-facing systems typically include a billing system, a CRM system, and a trouble ticketing system to handle service level agreement (SLA) definition, tracking, and other tasks. The network-facing systems control and capture data from the network itself while the customer-facing systems manage the interactions with the customers. Typically, only the customer-facing systems have in-depth knowledge of the actual customers who receive service.

Unfortunately, this fragmented OSS structure cannot provide a complete, real-time picture of end-to-end services and the customers receiving them. This partial view results from the customer-oriented systems being largely disconnected from the systems managing the network and services. In some instances, such as trouble ticketing, the customer-facing system is triggered by a network event, but the customer-facing system does not have deep knowledge about how the network event may affect the customer. In most cases, the network-facing service management applications typically do not share or act upon customer-specific data in an integrated, automated fashion.

For example, a fault management system might provide an effective picture of which faults are affecting which devices over a period of time or at any given time. However, the system should really help the service provider answer these questions:

• Which specific service connections are affected by a given fault?
• Which customers are affected by the fault, and how are they affected?
• What effect on revenue does this fault have?
• How often has each customer experienced service disruptions? How often for specific service connections? How often for all their services?
• Which of the affected customers have higher SLAs that place them at the top of the priority list for recovery or re-provisioning?

Without answers to these questions, does the service providers staff have the knowledge necessary to draw a clear picture of how satisfied any individual customer is? The short answer is no. Instead of proactively managing the customers experience, the service provider is probably reacting to customer complaints about service outage and consequently being placed in the position of having to struggle to retain the customer. In fact, a service providers ability to answer these questions quickly is a major factor in the customers levels of satisfaction and, ultimately, their loyalty.

NEW MODEL TIES NETWORK MANAGEMENT FUNCTIONS TO CUSTOMERS
To address these issues, service providers need a new OSS where network management and customer management systems and processes operate within the same spheres of influence. By making the customer the common denominator of service management processes and key network management functions, customer-aware service management posits an OSS that answers the questions outlined above. In effect, this approach links customer information from the customer-facing systems into the network-facing systems. This shared information enables customer-facing and network-facing systems to jointly correlate problems with specific customers and service instances, as well as with the network elements configured to carry those services.

One simple way to share this information is to develop a customer-focused knowledge base that is available to network management functions interacting with the network. In effect, the databases accessed by network-facing functions must also be populated with information about specific service instances and the customers receiving those services. Armed with this data, the network-facing OSS systems can make direct associations among the service instances, the customers receiving them, and the status or configuration of network elements carrying them. These associations can then be elevated to the customer-facing applications that track service quality, billing, and other critical functions that enable knowledgeable business decisions to be made. Ideally, knowledge of the network elements should be constantly updated in the knowledge base through an auto-discovery interface with the network.

By unifying service management tools in this fashion, the service provider can correlate how network events affect any given service instance as well as specific customers. The metrics and devices that are being monitored can be dynamic, based on the SLA and quality of service (QoS) parameters assigned at the time of service provisioning and activation.

For example, a customer contracts for a virtual private network (VPN) between Seattle and Chicago. The network service provider provisions the service and the system automatically populates the fault management and performance monitoring knowledge base with details on the VPNs monitoring parameters. In the knowledge base, the information about the customer and the service is directly linked to the network resources network elements and ports that are configured to carry it. This information includes the core devices, edge devices, and customer premise equipment. If a switch fails along the route of the VPN, the fault management system will flag the fault, instantly correlate it with the service and the customer, and alert both the network operations center and the customer service representative staff. Armed with this instantaneous information, the service provider can proactively call the customer with a status report before the customer may even become aware of the problem.

Correlating customers, services, and network elements in this manner results in a number of significant benefits:

• Improved SLA monitoring. The service provider now has greater visibility into real-time SLA-related performance data and the historical performance of a service in relation to the SLA;
• Improved customer relations. The service provider can instantly view which network events are affecting which customers, permitting proactive customer relations;
• Detailed service histories. Compiling performance and fault data as they relate to individual service instances can yield a detailed history of each service and how it has performed for each customer; and
• Improved resource planning. By having better visibility into how network resources are assigned to customers, service providers have better intelligence to more effectively plan network resources.

By understanding in real time the service experience of the customer, the service provider can provide faster, more efficient, and more personalized customer service, which in turn engenders increased customer loyalty. Increased loyalty translates into higher retention rates and, ultimately, higher profitability.

Adam Boone is director of strategic marketing for CoManage Corp., www.comanage.net, a developer of service management systems for network service providers. John Janetos is director of strategic alliances of Portal Software, www.portal.com, which develops customer management and billing software for communications and content providers.

[ Return To The November/December 2001 Table Of Contents ]

BY JIM CULBERT

Certainly, theres never a dull moment being a service provider. New technologies loom on the horizon that promise to change the way everything works. Web services will dramatically affect how independent software vendors (ISVs) build applications, how service providers deliver solutions, and ultimately how customers buy and use software. Exciting service opportunities abound but these are new and uncharted waters. To avoid running aground requires understanding both the challenges presented by Web services and the opportunity they present to implement better operational support systems (OSS)/billing support systems (BSS).

Web services allow large applications to be broken up into much smaller components, and combine true modular architecture with the ability to deliver modules as services over the Internet. This new technology will be at the core of a broad new class of applications where components from multiple best-of-breed vendors are easily assembled, disassembled, and reassembled without arduous custom coding or incremental development costs.

NEW CHALLENGES
Web services introduce two related complications to the service provider environment: Service granularity and complex partnerships.

Granular services
With Web services, a provider has to provision, bill, track, and support a much broader array of services. These new services require new business models. The bad news is that providers will lose their shirts implementing these services in an all-you-can-eat subscription model. The good news is that if they can figure out how to provision and bill for these services in an a la carte fashion breaking them up into their smallest components and mixing and matching them providers can turn these services into high-margin revenue. Several vendors offer new billing products that embrace Web services and eXtensible markup language (XML)-based processing architectures. These products are perfectly matched for supporting Web service offerings and provide the flexibility necessary to manage the intricacies of these services and realize their revenue potential.

Complex partnerships
Web services technologies multiply the number of services that providers offer and, in turn, multiply the number of partnerships they will be involved in. These partners will include technology partners, systems integrators, ISVs, and resellers.

The Web of agreements between providers and their business partners becomes very complex very quickly. Making sure that everyone gets paid correctly is a daunting challenge for traditional billing infrastructures. The good news here is that though the revenue model will get more complex, smart service providers will have more options to design and optimize their revenue models. New billing systems capable of modeling this complexity are emerging that use XML to manage the web of relationships among the service provider, their partners, and their customers.

A PROBLEM AND A SOLUTION
Web services may warm the cockles of your number crunching CFOs heart, but what about the overworked veterans of the IT trenches? Fear not many of the aspects of Web services that complicate your CIOs life also help to make it easier.

XML everywhere more access to important events First of all, most Web services transact XML and provide XML configuration. Whereas IT groups used to have to comb through arcane log files, they now have access to well-formed, self-describing XML documents. The increased access to event data, coupled with the advantage of having the data in easily-integrated XML format, makes it possible to implement tracking systems for usage-based billing necessary to make Web services profitable. Web service-based billing systems directly consume these XML documents and, because XML is human-readable, non-technical personnel can work with this data and build their own rating plans without involving IT.

Plug-and-play integration
Finally, and perhaps most importantly, Web services have the potential to untangle service provider OSS/BSS systems. XML and Web services will simplify business system integration by decoupling system components and by giving those components a common business and integration language: XML. The combination of technologies like XML, simple object access protocol (SOAP), Web service definition language (WSDL), and universal description, discovery, and integration (UDDI) allows business system vendors to build component-based software that may be pulled apart and recombined with other business system components to implement customized business processes. Dont like the rating engine from your billing vendor? Pop the vendors implementation out, implement your own, and snap it in. Need to integrate billing, provisioning, and service level agreement (SLA) monitoring from three different vendors? Just connect the XML message flows from the different systems and they will learn each others capabilities.

Admittedly, such out-of-the-box plug-and-play capabilities are not widespread today, but they are no longer science fiction fantasy either. Having common Web services protocols paves the way for plug-and-play configurable system customization. Systems integration will become a matter of configuration, not coding. Whats more, it will require significantly less time and money and be more reliable.

Jim Culbert is the CTO at MetraTech Corporation, where he drives the companys technology choices and architectural issues. MetraTech has developed a Web service billing, customer care, and revenue sharing solution. The companys platform provides an end-to-end billing solution, including transaction metering, rating, tax calculation, discounting, bill presentment, payment, revenue sharing, and customer self-care. For more information, visit their Web site at www.metratech.com.

[ Return To The November/December 2001 Table Of Contents ]