White Paper
Service Order Management Solution Design In a continuously evolving business/service scenario, telecommunications service providers are looking for a Service Order Management (SOM) framework which will improve their time to market, reduce their delivery cost and turnaround time, automate flows, and handle exceptions in a better way. The traditional service order management application (bespoke or COTS) faces issues because most of the provisioning processes are product based and are hard-coded flows, conceding an inflexible process flow and expensive service delivery cost. This paper outlines a design framework for service order management solution to overcome flaws and pain-points which too will be mentioned duly. Telecom Operations Support Systems/Business Support Systems (OSS/BSS) and processes are evolving rapidly. They are not only accelerated by the advancements in the underlying telecom and IT technologies but also by an increasing trend towards standardization of various entities through the initiatives of the Telecom Management Forum. However, the horizontal and vertical scaling of a typical OSS/BSS stack is doubtable. The SOM Solution Design provides a framework to decouple the traditional BPM from order management and gives a pragmatic methodology of implementing and exposing services. It refers to how service catalogue can be used to make the processes flexible and scalable. In addition to this, a data element called as Provisioning code is introduced. This solution, hence, as mentioned above, will improve time to market, turnaround time, and help in developing scalable and flexible solutions.
About the Author Nagraj Shetty Nagraj Shetty is a Telecom IT Solution Architect specializing in Oracle Order management solutions. He has been working with Tata Consultancy Services Ltd since Aug-2008 as a Solution Designer for Order Management & Fulfilment Solutions. He played the role of lead IT Solutions Architect for a strategic IT program to implement Oracle OSM for a UK based CSP and is now leading the customer's FMC (Fixed Mobile Convergence) IT Delivery platform in the capacity of Program Manager. He is also a TCS certified Solution-Architect-Functional-Architect (SAFA) and has varied exposure in IT Strategy for customers, pre-sales engagements and active member of TM Forum. Constantly recognized as one of the young achievers he holds a Bachelors Degree in Engineering from VJTI, Mumbai India.
2
Table of Contents 1.
Introduction
4
2.
Problem Statement
4
3.
Solution Overview
5
4.
Conclusion
15
3
Introduction The current trends in the area in order management show that service providers want a solution which can match the pace of the ever evolving technological arena of telecommunication services and product offerings which are spawned from customer demands. This connotes cue to improve their time to market, in a competitive environment their flow through time and overall customer experience. This paper endeavors to solution aspects that currently are key issues for several SPs looking for a framework of service order management. The new framework should be one that solves problems of tight coupling between Products and Provisioning, Scalability of the solution when launching future products and services, solution which is data-driven and so on. In essence, this artifact will attempt to answer: Business View: How can we (SP) offer products and product bundles with an improved turnaround time in a standardized manner? Technical View: How can we (SP) build product agnostic services which can be easily reused, scalable/enhanced and maintained? Hence, this document is organized in the following manner to improve comprehensibility. The subsequent section will, in detail, draft the problem statement that the solution is undertaking to answer. The section after, will lucidly provide the solution, and the methodology to achieve it; illustrating a case snippet where the framework was successfully implemented. The last section would then draw the inference and benefits from the solution framework provided. The primary audiences of this document are solution designers who intend to draft a framework for a service order management solution. The extended users could be Presales team who would want to exhibit TCS capabilities and Service designers who will draft capabilities of an SOM system etc.
Problem Statement With reference to the two key questions stated in the Introduction, in general, the problem statement can then be posited as: Service providers wish to launch products and services at a better turnaround time, reduce delivery cost and (by) reuse/enhance existing services, for which IT is expected to provision a solution that can cater the same. To deduce from the above, following are the problems that this paper attempts to solve: n n n n
To come up with a solution that will enable evolution of services with minimum impact To seed standardization that will aide integration of systems and reduce maintenance To demarcate between business rules and provisioning rules To provide a solution that does not have any impact or might have paltry impact when bundled products and features are launched derived from existing products or features. 4
Solution Overview The primary methodology for the solution will be to come up with a mutually exclusive telecom services catalogue. Using the telecom service catalogue, applications service catalogue would be derived; this will then provide a comprehensive view of the solution implementation. The integration service will provide a single interface to utilize any of the available services. The key driver here is to decouple the services between BPM and order management. The way the solution framework will be deployed here is: n n n
Telecom Service Catalogue – Concept & Usage Technical Service Catalogue – Concept & Usage Implementation View
Solution Details 1. Telecom Service Catalogue Telecom Service – represent how products offered to the market are implemented, for example, Voice, Data etc. Service is often confused with Products. Services are the building blocks for product(s). Products are mainly commercial offerings of the service provider to its customers; a commercial offering could go up to bundling products together, which is offered as double play, triple play and so on. Every play there could have a commercial meaning to it like billing, marketing, and so on , however, its base will be a service like data, voice, video services mash up to be sold as triple play, and so on. Just as there is product life cycle management, there, indeed, is a service life cycle management which takes care of service’s concept to retirement lifecycle. It is paramount that the thin difference between the two is identified to buoyant evolution of services along with products. A product’s life cycle may last to a season or period of time but a service’s life cycle is much beyond the products’ life cycle. If we consider ADSL Broadband service, it has been offered ever since broadband became commercial. The service catalogue, hence, can be said to be an aggregation of all the services offered by a service provider and subsumes the network facing services. Figure 1 depicts an example of product service resource mapping:
5
Double Play
Voice
Broadband
Voicemail Products & Family Services Voice (Add/Modify/Remove)
L1
L2
Data (Add/Modify/Remove)
Voice Mail (Add/Modify/Remove)
Voice Line (Add/Modify/Remove)
Service Profile (Add/Modify/Remove)
Port Profile (Add/Modify/Remove)
Voicemail Server
Softswitch
BRAS/LDAP
MSAN/DSLAM
Resources
Table 1: Produce to Service to Resource Map
Typical examples are: Service 1: Voice Specification: Phone Number, CPE etc.
n
n
Service 2: Date Specification: Upstream, Downstream etc.
The service can be shown in the following format: S. No.
Service
Access Layer
CPE
Specifications
1
Data
Copper
Modem
Downstream Upstream .......
The product catalogue is then a composition of service catalogue and billing catalogue packaged for specific sales purposes.
6
Typical Examples: n
Product: FTTx P-100 n
Service 1: FTTx – Data Specification: Bandwidth, email, installation etc
n
Price Type: Recurring, Non - Recurring etc
Considering a typical product and how it will be hence provisioned: n
Product: Net-super n
Service1: Access ADSL Attribute: Speed
n
Service2: IP Attribute: Quantity of IP Address, ISP Name, Username etc.
n
Service3: CPEAttribute: CPE Type, Serial Number, Equipment Specification etc.
The services are the resource facing specifications/services. For provisioning this product, the following streams are to be worked upon: n
n
n
Inventory based System: n
Wherein service and resource inventory configuration and assignment is done in the inventory management system.
n
For assigning of access speed, number of IP addresses (number management) with customer details and a unique identifier (service id) for linking the facilities are required.
Activation based System: n
Wherein service and resource activation is done en-route the activation system
n
For which speed and resource details (retrieved from the inventory) are needed to complete activation.
Workforce (field force): n
Wherein resource configuration (installation) is done
n
For which, CPE details, resource details (obtained from the inventory), and customer service address are required.
Case 1: Without Service Catalogue 1. Designing provisioning logic without service catalogue implicates to have flows based on products. 2. The order handler (may be CRM itself ) will have to post the order into the provisioning engine based on the product it has to fulfil. 3. Hence, the entire ramifying flow will be dedicated for the provisioning of Net-super. The process flow will not have any data driven orchestration. 7
The provisioning flow will be similar to the one mentioned previously. Now, suppose that another feature service–VoIP–is added to the existing Net-super Product; the resulting catalogue will look like: n
Product: Net-super i-Voice n Service1: Access ADSL Attribute: Speed n Service2: IP Attribute: Quantity of IP Address, ISP Name, Username etc. n Service3: CPE Attribute: CPE Type, Serial Number, Equipment Specification etc. n Service4: VoIP Attribute: Phone number
[Note that the services that are newly launched already exist but were not part of the net-super offering.] Following are the impacts due to this: 1. Launching a new product of ADSL along with some already existing features to be ridden over ADSL would mean that the provisioning logic would have to change as each of the new feature service will require new activities to be fit in previous logic. 2. A process needs to be designed and new process for provisioning Net-Super bundled will be called upon by the order handler for fulfilment. 3. During inventory based activities, along with speed and IP, VoIP service would have to be categorized and configured/assigned. 4. In activation process, a soft-switch also needs to be activated along with speed services. 5. While for field force (workforce), even CPE for VoIP i.e. a buzz phone would have to be installed at customer site. 6. The above changes could either be a modification of current workflows, or creating a new one for this product offering and keeping the previous workflow intact (for the original product offering). 7. The Service provider has now decided, suppose, to start another new service (such as email services) which will be an added feature. 8. In addition to the changes listed above, there will be changes even in the inventory, and activation and workforce systems. 9. All these changes so incurred, however, will be regressive for provisioning system, i.e. instead of scaling the existing process of inventory, activation etc., a new process would need to be created for fulfilling this requirement.
8
Short-comings with this approach: 1. The provisioning system consists of product-oriented workflows, a logic in which, the provisioning workflows will be designed for provisioning each product. 2. Activation, inventory and workforce are called based on the products and not services. 3. Limits the possibility of launching future products, without affecting provisioning engine and other OSS systems. 4. Making the product lingo understood by the provisioning based systems (provisioning, activation, inventory, and workforce) will hinder creation of service oriented order management, and also make it difficult for swift fading of products (retirement). 5. Product bundling cannot be done unless the workflows support cross provisioning logic. 6. The processes of provisioning lack scalability and agility Case 2: Service Catalogue Conceptualized For creating a service catalogue, there are two approaches - one is for Greenfield and other is for Incumbents i.e. creating service catalogue from base zero or coming up with it from the existing product catalogue. For already-existing Product catalogue, we will carry forward the example taken earlier in Case 1. 1. First, define the service catalogue from the product catalogue without considering the products. The format has been given before in Case 1. 2. For provisioning the same product net-super, order handler will post an order as provision (Provide) to the provisioning engine. 3. The same set of processes will be called. 4. This seemingly looks similar to ‘without service’ catalogue, however, the main jugglery comes into play when instead of creating another flow for another product, the same flow done for net-super is used. Net-super bundled (carry forwarding the same sample Product from Case 1) 1. Taking the case of adding a voice service already existing in a different offering is now clubbed in the net-super offering. (Assume that the VoIP and its attributes are already present in the service catalogue, which would also mean that the provisioning process flow built with the service catalogue will have the process to fulfil voice as well.) 2. No change at all needs to be attuned with the product change. Now to consider the second impact due to launch of a new service, email (similar to Case 1) 1. Add the email service and its service attributes in the service catalogue. 2. Add the relevant processes to the existing provisioning workflow. 3. Add relevant attributes of email in the inventory and subsequent method of soft activation of this service. 4. The process is now ready for the new service launch. The overall impact compared with service catalogue is reduced substantially, as the only approach to consume this new service was to scale the current processes. 9
Service catalogues typically created by OSS managers will keep the demand and supply internally in sync. Service catalogue is not an essential element for fulfilment, but is a tool that calls for agility and augments flexibility. Advantages: n The services offered are, in principle, agnostic of products, thereby, making it simpler for the network engineers and other OSS personnel to comprehend them better. Also the OSS systems’ data model will be scalable and flexible; hence it will not be affected by product changes. Thus, the processes can be reused with no or minimal changes. n The provisioning (or order and service management) system will be product-agnostic, and the order orchestration rules will be based on services to be provisioned. A new product could be added without changing the provisioning logic. n Reduced time-to-market - reduced development and launch time for products through component reuse and fewer redundant options reduces the volume of data required to assemble new offerings. Differentiating factors: It gives a holistic view of all the services offered by the organization, which are mutually exclusive and collectively exhaustive, as a single-window-view to all the services is not available using product catalogue. n A common model provides consistency and relation between customer and resource facing services. Additionally, it makes process flows data-driven and aiding enhancement in an easier way. n Product Catalogue can evolve, but still the service catalogue can remain the same (unless a new service is added or an existing service is modified). n
The above explanation gives a cogent picture about the importance of service catalogue and how it can be implemented. 2. Technical Service Catalogue Technical Services – basically represent encapsulation of a set of capabilities for provisioning a telecom service, for example Add FMC. Service Order Management system should expose an Integration Service which can then help the evolution of SOM independently. The message processing logic would then parse and call the appropriate order type (or an application service). Following is an example of the way a service could be exposed
10
Provisioning Order Request Response to be exchanged The request consists the product Response to be exchanged The request consists the product- service data and an action
BPM
SOM Adaptor for transforming the message to SOM specific format and identifies the service to be instantiated in SOM based on the data in the order. Note - the IS will call the application service with appropriate process to be instantiated in the request
SOM WSDL exposed Upstream invokes this webservice for Provisioning Order methods
Service Contract
Message Processing Logic
Provision Service XXX
[Application Service] Provisioning Processes
activation Utility Svc Int PlugIn
activate Data Proc Svc activation Task Svc
Process
Could be any process exposed for activating a service say data or voice. This service can well be called by another process at a higher level which might control the overall process order management
SOM Processes that orchestrates the service order request. And retrieves inventory details to send the request for activation etc.
Notification Utility Svc
Fallout Management Utiltiy Svc
Table 2: Technical Service Maps
The service contract has the properties like – a scalable schema, stateless binding type, internal validation based on the telecom service to ensure data provided is accurate and so on. Also, the message processing logic’s primary quality is to identify the technical service or process to be invoked and parse accordingly. Provisioning Processes layer is where all the processes and data are built and used for provisioning a service. Figure 2 also explains how different services within a process can be used to full advantage and can be reused. For example, the activation utility service for integration plug in which parses and sends request to an activation management system can not only be used in the above process but can also be consumed in any other process. The Activation Data process service internally calls activation task service. The activation task service could be used for activation of data or voice, but based on the data driven rules, appropriate content will be sent to the related network element eventually. Activation data process is specific to data, the reason being the rules embedded in the service will be for data service alone. This can be scaled to include complex data provisioning based on the rules in the service. By analogy, a set of generic tasks can be encapsulated into one process; this process can also be a sub process in a process which does something specific or generic to be a sub process. The entire composition of sub processes can then be used by a process which will do orchestration based on the scenario or use case and rules. 11
Additionally, a fallout management utility service can be built to customize the exception management in a better way and can be configurable-rule-based. For example, the exception management could include ceasing a circuit on LDAP if while providing the service request fails with the reason as ‘Circuit Already Exists’. Similarly, these rules can be evolved during production and tuned on-the-fly. Service Order Management’s service catalogue should hence consist of two levels: Integration Service – this will contain the service contract details to access the application services. The format for the implementation can be as below Service Name
Operations
Input
Output
Binding Type
Capability
ISSOMProvision Service Order
provisionOrder
Service details, Customer details etc. Format XML
Order Id created, Format XML
SOAP/JMS/ Synchronous
Manage Order to Activation flow. Track Order. Publish notification etc.
Application Service – this will provide the application’s capability specifically. The following format can be used Service Name
Input
Output
Binding Type
Capability
ASSOMProvideData
Service details, Customer details etc.
Order Id
JMS/ Asynchronous
Allocate inventory for data service. Activate DSLAM port. etc
In this section, we saw a detail explanation on the usage of technical service catalogue in order to have an understanding of how to go about defining services and implementing them in a service order management system. Though most of the above concepts are general and can be applied to any system, the examples are accentuated on how to implement them in SOM. 3. Implementation View In this part of the solution design for SOM, implementation framework will be covered and which eventually facilitate in applying the concepts discussed so far. The section will not try to present how process flows are drafted or what should it consist of, or provide a check list for provisioning flows etc, as these general aspects are well-written and can be found easily. This section or the paper, in general, will provide a framework of how SOM should be implemented. Let’s consider a scenario using the previous figure (Fig 2), if the application services exposed are Provision data & Provision voice, and each has a capability to provision the service from invoking allocation
12
inventory system to activation system. The application service is invoked by the integration service which will perform the routing and parsing based on the data in the order. Note that the Provision Voice Service and Provision Data Service are exposed directly instead of Provision Service. This can be a decision taken into consideration through SP requirements as the service from SOM can be either fine grain or façade. The above service can be definitely scaled to Provide Service wherein Provide Voice & Provide Data can be called internally by the master process service. The dependency between the two can then be managed. The above clearly depicts properties of SOM like Order decomposition, service order dependencies, and various types of order that can be provisioned. It also evinces how services can be composed, controlled, consumed, and orchestrated as an isolated unit to drive the solution logic for that unit. Provisioning Code This identifier introduced at the onset is the key mapping device between commercial offerings, Service and Resource. Figure 3 depicts a typical map extended from SID
Single Play Commercial Offering
Bundled Offering
Voice Voicemail Simple Product
Products & Family Services L1
Activate Voice (Add/Modify/Remove)
Service
Provisioning Code
L2
Voice Mail (Add/Modify/Remove)
Voice Line (Add/Modify/Remove) Service Specification
Resources
Provisioning Code
Resource
Resource Specification
Voicemail Server
Softswitch
Table 3: Provisioning Code Maps
13
To link products, services and resources, a map is required which is called as Provisioning Code in this artifact. Provisioning code is used for the following purposes: n To identify the service specification n For example, Voice will contain DN, CLI etc. n Each will have a distinct Pcode. n This PCode can be bundled to establish its Service. (Voice in this case) n
Cross reference between Customer Facing Service and Resource Facing Service n Network elements, for example, will have a nomenclature to map a particular specification or activation template. n These specification or templates vary from vendor to vendor. n The mapping can hence be dynamic based on the requirements.
n
Identify the appropriate activation service. n An activation platform will have a service exposed. n To identify the appropriate service for the given service specification i.e. PCode.
Advantages: n Aide data driven processes n Flexibility in composing of services and products n Potentially no change when existing service specifications are mix and matched n Simple method of decoupling OSS/BSS data functions by linking both worlds by a single key Disadvantages: n As any data driven process would ensue, debugging could be sometimes time consuming as which data caused the problem may be hard to find. Therefore, exception management should be done in a better way and full cognizance of the system is a must. n Data change is too easy; therefore, there is a higher chance of resulting in data integrity mishap. To mitigate this, privilege management must be diligently used to change Pcodes. Hence, setting up the pieces together presents a composite view of the Solution framework. To summarize, the following concepts were discussed: n Telecom Service Catalogue n Technical Service Catalogue n Implementation View (Provisioning Code concept) The above steps can be the pillars of solution designing an SOM framework which can then be elaborated with detailed implementation perspective (which, of course, is precisely dependent of customer requirements)
14
Conclusion This solution has tried to answer the question posted in the beginning of this document viz. Business View: How can we (SP) offer products and product bundles with an improved turnaround time in a standardized manner? Technical View: How can we (SP) build product agnostic services which can be easily reused, scalable/enhanced and maintained? The answer has been provided as by framing the below building blocks: n Telecom Service Catalogue n Technical Service Catalogue n Implementation View – Provisioning Code Service provider would be able to launch products & services at a better turnaround time, reduce delivery cost and (by) reuse/enhance existing services, for which IT is expected to, provision a solution that can cater the same. Objective
Solution
To come up with a solution that will enable evolution of services with minimum impacts.
Technical service catalogue has provided the benefits of building independent services at provisioning level.
To seed standardization that will aide integration of systems and reduce maintenance.
Introduction of Integration service will bolster the interfacing of systems.
To demarcate between business rules and provisioning rules.
Business rules are mainly products driven; provisioning rules will be implemented using Telecom services and their order management will be done at the technical service level.
To provide a solution that does not have or might have paltry impacts when bundled products & features are launched derived from existing products or features.
Using Telecom service catalogue and a key called as provisioning code, the solution is scalable enough to introduce new product variants with least impacts on OSS systems.
The next logical step would be to come up with industry standard service catalogue for typical services and use cases so that they can be consumed directly with little changes as appropriate. A strong catalogue can be a benefiting asset. There are challenges for implementing this solution, as the conceptualization time could be a tad-long as this phase would have long term repercussions. Hence, it would be sound to launch a phase-wise approach keeping the future in mind. Hopefully, this paper has given justice to the problems it endeavored to solve.
References [1] TM forum http://www.tmforum.org [2] SOA Principles http://www.soaprinciples.com/p3.php
15
About TCS Telecom Industry Solution Unit TCS’ Telecom Business Unit is the second largest vertical contributing higher percentage to the overall TCS revenues. With a dedicated pool of professionals and an accumulated experience and ongoing associations with world-class Telecom service providers and equipment manufacturers, TCS has acquired unparalleled understanding of the Telecom domain. TCS helps wireline, wireless, broadband, and cable service providers redefine their markets with innovative solutions that help them become more agile, reduce fixed operations costs, and introduce next generation services. TCS sets customers apart from their competitors with instant access to industry solutions, best-in-breed technology, assets, and frameworks.
Contact For more information, contact
[email protected]
Subscribe to TCS White Papers TCS.com RSS: http://www.tcs.com/rss_feeds/Pages/feed.aspx?f=w Feedburner: http://feeds2.feedburner.com/tcswhitepapers
About Tata Consultancy Services (TCS) Tata Consultancy Services is an IT services, consulting and business solutions organization that delivers real results to global business, ensuring a level of certainty no other firm can match. TCS offers a consulting-led, integrated portfolio of IT and IT-enabled infrastructure, engineering and assurance services. This is delivered through its unique Global Network Delivery ModelTM, recognized as the benchmark of excellence in software development. A part of the Tata Group, India’s largest industrial conglomerate, TCS has a global footprint and is listed on the National Stock Exchange and Bombay Stock Exchange in India.
IT Services Business Solutions Outsourcing All content / information present here is the exclusive property of Tata Consultancy Services Limited (TCS). The content / information contained here is correct at the time of publishing. No material from here may be copied, modified, reproduced, republished, uploaded, transmitted, posted or distributed in any form without prior written permission from TCS. Unauthorized use of the content / information appearing here may violate copyright, trademark and other applicable laws, and could result in criminal or civil penalties. Copyright © 2011 Tata Consultancy Services Limited
TCS Design Services I M I 07 I 11
For more information, visit us at www.tcs.com
