tSM - Telco Service Management

   tSM (Telco Service Management) is a modular system designed for the support of Telco OSS/BSS processes.

At its core there are several infrastructure modules:

• Process Engine  (workflow) - universal tool for the design and execution of processes and activities. It contains graphical process/activity designer, execution and modification of process instances,  mapping of activities to either automatic actions (interface) or manual tasks. In addition to manual tasks included in the workflow execution managed by the process engine, there is a Work Force Management  module to plan and assign tasks for field workers based on Resource Pool , priority, SLA, geographic information etc.

• Configuration - toolbox for extending the  main TSM entities (e.g. product, ticket, service) and/or for creating custom entities. The configuration is persisted as a JSON Schema standard and as such it may be published as a part of public  API (all APIs are documented with Open API Specification standard).
  
• Forms Designer -  create online custom forms (GUI). Form layout is persisted as additional configuration metadata from the Configuration  toolbox         

• Document management  - documents and attachments management. Document content may be stored using a simple TSM document store implementation or it may be attached to a legacy DMS system.
  
• Communication - a tool for interactive collaboration on TSM entity (comments with @mention).
  
• User Management  - user and user group management, LDAP synchronization
  
• Security - SSO (Single Sign On), application privileges, roles; user/role configuration, LDAP

   The overall TSM architecture is microservice based (set of loosely coupled, collaborating services), which communicate with each other using APIs (TM Forum Open API standard).

   Each module contains a backend API and a set of graphical API components, which can be combined in the resulting unified user interface. This enforces the same user experience across the whole application and single components can be customized while sustaining compatibility with feature system versions.

   Example: Customer Management contains a component with customer detail. It is part of customer GUI, but it is also used across other components with a single include:

< tsm-customer-detail id=513492 mode=”compact” />

    All TSM modules use common building blocks - fast and customizable filtering based on Elastic Search Engine, configuration, user forms (with a form designer), Excel exports, document management, user management, roles, SSO etc.

   TSM is delivered with a preconfigured set of Telco modules. These are built with regard to TM Forum  recommendations and according to TM Forum Open API Specification . This kind of standardization ensures the ease of interoperability with legacy provider systems and future module evolution. The customization of the Telco modules is based on Configuration  and User Forms  modules, while process-oriented modules may leverage our cutting-edge process designer from the Process Engine  module.

   At the heart of TSM Telco modules is service management - service catalog, provisioning, workforce, inventory and service assurance. There are also simplified product and customer oriented modules. Although it is not a full-fledged CRM system, it may be sufficient for infrastructure providers or for smaller providers with limited Customer base. It can be also useful if legacy CRM systems are not easily integrable.

tSM Process Engine

    tSM Process Engine  (workflow) is a universal tool for the design and execution of processes and activities. It contains graphical process/activity designer, execution and modification of process instances,  mapping of activities to either automatic actions (interface) or manual tasks.  

Based on Business Process Model and Notation (BPMN) industry standard, the process designer is a familiar tool for any process analyst and she may even directly import existing diagrams. With additional configuration, the process execution is then connected to other entities (users, groups, resource orders, alarms, NMS, network interface, …) and made executable.

Additional business attributes and forms can be created by tSM Form Designer (see “Config & Forms section).

Config & Forms

    tSM user interface allows end user customization using toolbars, dashboards and application widgets.

On top of the application is a configurable toolbar. Using drag & drop from tSM application menu, each user can create a personalized set of most relevant application links – this may be a dashboard, application module or an external link.

    There is also a notification area with distinction between process events and user comments. The latter is created when another user adds a comment with @mention and it is delivered immediately, which creates a possibility of focused online chat.

    Each user can create multiple dashboard screens and share it with another user or a user group. This is the way how can tSM be configured for the needs of various business processes and user groups.

Dashboard configurator is built on top of tSM Form designer (see picture above). Although it allows complex screen layouts (multiple columns, tabs, sections, …), it is also prepared for mobile view (responsive web design). Each dashboard consists of one or more application widgets, which can be (for advanced use cases) interconnected using expressions.

Widget types are:

• Listings – list of orders, tickets, alarms, CIs, notifications, etc. Part of a dashboard widget configuration is a set of displayed columns, fix filters, colors, refresh rate, …
• Charts & Aggregations – based on the same data as listing, advanced view of the data. Because the configuration can be complex, trained configurator should prepare preconfigured charts which are then available for a business user
• Info, Links, Buttons – custom content (similar to web page creation)
• External widget – integration with external systems using iframe or other technology
• diagrams.net diagrams – tSM comes with integrated (on premise) diagramming tool, which allow to draw charts and schemas enriched at runtime with actual data
• Custom widgets – this is the means of customization on the UI side. If needed, new widget is developed and then available for use in a dashboard or any other tSM screen.

   Listing, charts and aggregations come with complex query capabilities (based on the ElasticSearch component). It allows configuration of work queues such as “My tasks”, “Not assigned orders”, or complex queries for operational reporting and jeopardy management (“Due next week”, “After due FTTH west region”, “Average response time”).

   tSM Form Designer is not only used for creating Dashboards. It can also be used for other customization needs, for example, it is commonly used for customizing pages displaying e.g. entity (Customer, Order, Ticket ...) details or for process customization.

The CRM module

   Customer relationship management module. Allows to dynamically monitor and manage the business relationship with the customer at various levels.

“Customers” component

   The “Customer” is the basic entity that creates a core of the CRM module. The customers register is shared among entities.

   Customer represents a person or organization that buys products and services from the enterprise or receives free offers or services. Customers can also be other service providers who resell the enterprises products, other service providers that lease the enterprise's resources for utilization by the other service provider's products and services, and so forth. Main Customer attributes are its identifier, name, status and validity, description, characteristics, contact medium, related customer account, related party, customer credit profile information. Customer may have an Account used for billing or for settlement purposes.

• Customers management allows to create, edit and track the “Customer”, convert the “Lead” to a “Customer” or change the customer’s status
• Search the customers register according to various criteria, track the customers history and export the customers in common formats
• Link to other entities (“Contact”, “Contract”, “Order”, “Address”, “Phone”, “Event”, “Comment”, “Attachments”) is displayed for each customer
• Allows to manage events for the customer to ensure managed and planned customer care

“Accounts” component

   Relationship with the customer might be defined with framework, or any other, agreement where provider define what unique conditions will provide to customer. “Offers” and “Orders” can then be applied to the “Contract”.

• Allows to manage the contacts (create, edit, track the current status, track the relationship with other entities)
• Search the contracts according to various criteria, track the contracts history and export the contracts in common formats
• Allows to manage the contract status (“Proposal”, “Approved”, “Valid agreement”, Invalid Agreement”, “Denied”)
• Allows to link the contract with other entities (“Contact”, “Contract”, “Order”, “Address”, “Comment”, “Attachments”)
• Allows to create an activity for the contract and manage it using the “Activity calendar”

“Leads” component

    Leads component allows to capture first contact or promising business opportunity for further development.

• Allows to create and edit leads, monitor and change their status (“New”, “In Progress”, “Convert to customer”, “Rejected”) or manage the lead according to the priority
• Allows to search in lists, track the leads history and export the leads in common formats
• The opportunity that develops into a business case can be converted to a “Customer” and maintained accordingly then
• The “Contact” and “Address” used within the lead are also shared with other entities

“Persons” component

   “Persons” component allows keeping records for a person. Each person can be registered either individually or can be tied with a specific customer or lead.

• Allows to register contact information for each person (phone numbers, e-mail addresses, etc.)
• Allows to register roles for each person (manager, seller, engineer, etc.)
• Search the persons register according to various criteria and export the persons lists in common formats
• Allows to monitor the connection of a person with entities (“Lead”, “Customer”, “Account”, “Offer”, “Order”, etc.)

Ordering

Product Catalog

   A Product Catalog is a collection of Product Offerings, intended for a specific Distribution Channel, enhanced with additional information such as SLA parameters, invoicing and shipping details. Each Product Offering in a Product Catalog combines pricing and availability information with Product Specifications that describe the relationships between Products, the Services used to realize the Products, and the Resources they require.

   A Product Offering is orderable from the provider of the catalog and includes product specification, pricing information, SLA requirements, market segments, attachments, ... Product Offering may represent single product or bundle of products.

   The TSM allows to manage product catalogs and to configure products in the catalog. Product belongs to a certain category, contains specification, category of customers and detailed parameters (SLA, speed, etc.). For products the pricing is defined including the possible discounts register.

   The TSM GUI allows to search and edit products, run exports, track the product history, etc. and to define cardinalities and dependencies within between products (bundle, value-added service, etc.)

   Products have a defined link to services from the service catalog that realize the product.

“Orders” component

   A Product order  is created based on a product offer that is defined in a catalog. The product offer identifies the product or set of products that are available to a customer, and includes characteristics such as pricing, product options and market. The product order references the product offer and identifies any specific requests made by the customer.

• A Product Order is a type of order which can be used to place an order between a customer and a service provider or between a service provider and a partner and vice versa,
• Main Product Order attributes are its identifier, state, priority category (mass market, Enterprise, etc.) related dates (start, completion, etc.), related billing account, related parties and order items
• Main Order Items (aka order lines) attributes are the ordered offering and product characteristics with the related action to be performed (e.g. add or delete the products), state, location information for delivery.

   The “Order” creates a prerequisite for the realization of the business relationship. It is always tied with the “Customer” and can be tied with “Contract” or the “Offer”.

• Allows to manage orders (create, edit, track its status)
• Allows to tie order with an “Offer” and the “Contract”
• Search the orders according to various criteria, track its history and export the orders in common formats
• Allows to link the order with other entities (“Contact”, “Address”, “Contract”, “Product”, “Offer”)
• The order can be managed through the workflow and thus ensure all the steps related to the order
• Allows to create an activity for the order and manage it using the “Activity calendar”

   The product order is based on the product offer defined in the catalog. Allows to configure order states and transitions between states. The order life cycle is mapped to processes. While working with the product order it is possible to add products from the product catalog or services from the service catalog (simplified service provisioning). The main attributes of the product order include the required service start and implementation dates, the location for the service or the actions that need to be performed, e.g. add or remove products.

Product inventory

   A Product represents the subscription of a Product Offering by a Party (such as a Customer). Product may be a bundle (e.g. Voice Bundle  product) or a specific product ( Voice Over IP and Voicemail products). Product has a status, location, price, characteristics, billing account…

   The Product inventory is used to register customers’ products (customer product instance) and allows to establish, change and  register the service links for the issue identification.

Customer Portal

   The TSM provides an API for creating a customer portal. The “Customer portal” is always custom made, usually connected with existing customers portal.

Service Management

Service Catalog

    The TSM Service Catalog contains the definition of services in terms of OSS systems. It is mapped using a Customer Facing Service (CFS) at the input for an order from the Ordering and decomposes to a Resource Facing Service (RFS) provided within the service Network Inventory (NI) or by an alternative provider. Parameters needed for configuration are clustered in logical units - components. A component can be assigned to a CFS (containing parameters raised from Ordering including their decompositions) or to an RFS and then usually maps to Resource as known in NI. Components parameters are further fulfilled within the Provisioning process either with the interface (automatic tasks) or with user (manual tasks).

   The Service Catalog contains service definitions, configurations and registers. Among the main definition consumers are the Service inventory (service structure, registers) and the Service provisioning (service structure, CFS to RFS decomposition, Business Rules, registers). In addition, the Service Catalog contains downstream systems (SA, Supervision, Reporting, etc.) configuration in the form of service parameters and provides them in the form of the API.

    The Service Catalog has to be mapped to the related catalogs:

• Product Catalog – product or CFS mapping (e.g. in the form of agreed codes export)
• Technology Catalog – RFS and Resource mapping

   The CFS (Customer Facing Service) is a service provided to the customer (e.g. mobile calls, broadband internet connection, IP VPN, etc.). Such a service can be sold within various products from the Product Catalog. While the product must already have all the parameters with an impact on price (e.g. connection speed), the service contains them as instance parameters only.

   The RFS (Resource Facing Service) is a service provided by the provider’s network and it is therefore an internal service that then build the CFS. This service already contains technological details and, most importantly, decomposition to individual Resources.  RFS and individual resource also form the basis for designing a service within the Network Inventory, which allocates specific resources during service execution.

Service Inventory

    The Service inventory  makes up the master register of operational service settings in terms of OSS systems. It follows up the customer products data and contains links to consumed resources (end devices, IP addresses, business partners connectivity, etc.)

   Service Inventory is primarily fulfilled within the Service Provisioning process, but also be modified within reconfigurations or SA. When administrator intervention is needed, the GUI allows users to manually enter the data. Service Inventory exposes documented API for data create/update/read. Service Provisioning always retrieves the current service status in Service Inventory as a part of change request. Data warehouses replicate data online using database tools.

   In addition to the operational status the SI also contains the current projected status and annual history (“Project”/”Operation”/”Cancelled”/”Suspend” statuses).

Service Inventory register following basic Service Instance entities:

• Customer Facing Service (CFS) instances and their items
• Resource Facing Service (RFS) instances and their relevant items
• Mapping services (RFS, CFS) to other services and service components:

• Related services
• Relevant resources used to configure the service
• Services and resources from other providers’ systems that participate on the service

Service Inventory is used to:

• Register customers’ services, manage the service life cycle (“New”, “In realization”, “In operation”, “Suspended”, etc.). Allows to set two active states (operational state + required change in implementation)
• Trouble ticketing (failure reporting)
• Service Impact Analysis
• Reporting

Service Provisioning and Activation

       The TSM Service Provisioning works on the service (often referred to as a “technical”) order. It receives the products list as an input and translates them into service. Basic implementation steps are:

• Order validation (allows the back office to manually intervent)
• Service availability check
• Decomposition to RFS, required Resources determination
• Service design - request to Network Inventory for the resources allocation based on the RFS and Resource
• Service activation - either automatic or manual activation of allocated resources
• Field work - allows to connect with Work Force module to plan the engineer jobs according to the territory and skills
• Verify the function (either manually or automatically)
• Network documentation

   The Process Engine  to design processes, automatic actions configuration, manual tasks assignment configuration, etc.  is used within the service provisioning.

    Service activation is a dedicated process or, for simple use cases, it can be modeled as part of the overall provisioning as a subprocess. Based on the Service design, tSM will select automated or manual provisioning tasks to fulfill the activation request. The activation subprocess can be as simple as a single REST API call for network device configuration, or it can be several steps (e.g., get current configuration, set port, update IP address, etc.) with serial/parallel process and optional manual input. Rollback is also modeled at this level.

   Service activators are either configured on demand as part of the provisioning process, or they are selected from a library of preconfigured activators (and can be further modified). tSM contains connectors for standard NMS via REST / SOAP API (such as FortiManager) or direct activation using Netconf/YANG. tSM also utilizes Ansible / AWX, which enables it to use a wide range  of open-source collections (such as CiscoXR), see https://galaxy.ansible.com/  for more information.

   Separation of the BSS (Customer Order/Product Order) and OSS (Technical Order/Service Order) worlds in single modules might be over-detailed for some of the providers and it’s better to work with a single order, which contains both components. This means that ordering and service provisioning processes might be linked into a single process to simplify acquisition and processing of the order.

Workforce

   The Workforce module contains Resource Pools with skills, availability, geographic information etc. Workforce works on top of the manual tasks included in the workflow and assigns a field worker and time to the task. Part of the workforce module is a mobile application (Android and iOS) with offline mode for work in the field.

• The work is administered with a process-based approach, processes can be managed in the  Process Engine modeler.
• Main items included in WFM

• work order administration
• administration of resources, their availability and skills
• cost optimization in schedules
• scheduling based on geographic data and prioritization
• administration of customer appointments
• administration of material and stock availability

• Informations available for the field workers:

• description of the requested work
• job location description including the maps
• due date and time necessary to complete the job
• informations related to the infrastructure and technology (facility assignment) from the inventory module or from the third party sources
• consumables and stock items (e.g. modems, network terminators, cables, etc.)

Ticketing

    Trouble ticket  is an issue or problem identified by a customer or another system that need to be solved, used for reporting and managing the resolution of problems, incidents or request. Examples of Trouble Ticket API originators (clients) include CRM applications, network management or fault management systems, or other Trouble Ticket management systems (e.g. B2B).

   Trouble ticket has complex lifecycle and attributes specifying the nature and severity of the trouble or issue as well as all necessary related information. Main trouble ticket attributes are its description, severity, type, related dates (creation, expected resolution, resolution), state and related information (change reason and change date), related parties(originator, owner, reviser, etc.), related entities (product, product order, customer bill) and notes.Notifications are defined to provide information when a trouble ticket has been updated, including status changes.

Ticket management, e.g.,  contains:

• SLA configuration
• ticket prioritization

• process task automatization, based on process configuration
• ticket hierarchy, links - e.g. customer ticket linked to technology ticket

• RCA (Root Cause Analysis), SIA (Service Impact Analysis) - RCA/SIA must be delivered by Network Inventory system, however the Ticketing module interprets results, create tickets accordingly and calculates SLA, informs customers etc.

• WorkForce management - e.g. problem resolution needs field worker. Using the WorkForce module the work is planned to a specific place and time. TSM API also provides integration with third party systems.
• Communication with alarm/diagnostics systems.

   Trouble Ticket uses TSM Process Engine to design and run complex ticket workflows with human tasks and custom actions.

Billing

tSM contains two versions of billing:

• Billing Basic - generates monthly billing documents based on active service instances, performs aggregation and proration, and generates a PDF with an invoice attachment. It typically sends the actual billing data to SAP.
• Enterprise Billing - Complete billing including usage (CDR collection), A/R (accounts receivable) module, payment matching, etc.