TSM - Telco Service Management

   TSM (Telco Service Management) je modulární systém vytvořený pro podporu Telco OSS/BSS procesů.

Jádrem systému jsou následující moduly:

• Process Engine (workflow) - univerzální nástroj pro návrh a spouštění (provádění) procesů a aktivit. Obsahuje grafický designer pro procesy a aktivity, spouštění (provádění)  a modifikaci instancí procesu, mapování aktivit buď na automatické akce (rozhraní) nebo ruční úlohy (tasky). Kromě manuálních úkolů, které jsou součástí zpracování workflow řízeného procesním jádrem, je k dispozici modul Work Force Management pro plánování a přiřazování úkolů pro terénní pracovníky na základě Resource Pool, priority, SLA, geografických informací atd.

• Configuration - toolbox pro rozšíření hlavních entit TSM (např. produkt, ticket, služba) a / nebo pro vytváření vlastních entit. Konfigurace je ukládána jako JSON schéma a jako taková může být publikována jako součást veřejného rozhraní API (všechna rozhraní API jsou dokumentována standardem Open API Specification).

• Forms Designer ( Uživatelské formuláře) - designer formulářů pro online vytvoření uživatelských formulářů (GUI). Rozvržení formuláře je uloženo  jako další metadata z toolboxu Configuration .

• Document management   (Správa dokumentů) - správa dokumentů a příloh. Obsah dokumentu může být uložen pomocí jednoduché implementace úložiště dokumentů v TSM nebo může být připojen k legacy DMS systému.
  
• Communication (Komunikace) - nástroj pro interaktivní spolupráci nad TSM entitami (komentáře s  @mention).        

• User Management  (správa uživatelů) - správa uživatelů a uživatelských skupin, synchronizace LDAP.

• Security - SSO (Single Sign On), aplikační privilegia, role; konfigurace uživatelů a rolí, LDAP

   Architektura TSM je založena na microservice architektuře (volně propojené, spolupracující služby), které spolu komunikují pomocí  API (standard TM Forum Open API).

   Každý modul obsahuje backend API a sadu grafických komponent API, které lze kombinovat do výsledného jednotného uživatelského rozhraní. To zaručuje stejné uživatelské prostředí v celé aplikaci a jednotlivé komponenty lze přizpůsobit při zachování kompatibility s funkcemi systému.

    Příklad: Customer Management obsahuje komponentu s detailem zákazníka, které je součástí příslušného GUI ale může být díky odkazu použito i v jiných komponentách:

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

   Všechny moduly TSM používají společně stavební bloky - rychlé a přizpůsobitelné filtrování založené na nástroji Elastic Search Engine, konfiguraci, uživatelské formuláře (designer formulářů), exporty do Excelu, správu dokumentů, správu uživatelů, role, SSO atd.

    TSM se dodává s přednastavenou sadou modulů Telco. Ty jsou postaveny s ohledem na doporučení TM Forum   a podle specifikace TM Forum Open API Specification . Tento typ standardizace zajišťuje snadnou interoperabilitu s legacy systémy a budoucí vývoj modulů. Customizace Telco modulů je založena na modulech Configuration a User Forms , zatímco procesně orientované moduly mohou využít našeho špičkového procesního designeru z modulu Process Engine .

   Jádrem TSM Telco modulů je Service Management - Service Catalog, Provisioning, Workforce a Service Assurance. K dispozici jsou také zjednodušené moduly Product a CRM, které obsahují zjednodušenou evidenci zákazníků a jsou zaměřené zejména na B2B segment (typicky poskytovatele infrastruktury)  a menší B2C operátory (např. ISP).  Mimo scope zůstávají domény market a sales (např. marketingové kampaně, forecast, …).

Modul “ CRM ”

   Modul řízení vztahů se zákazníky. Umožňuje dynamicky sledovat a řídit obchodní vztah se zákazníkem na různých úrovních:

“Zákazníci”

   “Zákazník” je základní entita, která je jádrem CRM. Databáze zákazníků je sdílená mezi entitami.

   Zákazník představuje osobu nebo organizaci, která nakupuje produkty a služby poskytovatele nebo dostává bezplatné nabídky a služby. Zákazníci mohou rovněž pořízené služby nabízet dalším/svým zákazníkům. Hlavními sledovanými atributy zákazníka jsou jeho identifikátor, jméno, stav a platnost, popis, vlastnosti, kontakty, zákaznický účet apod. Účet zákazníka může být využit pro fakturace nebo dohody.

• Správa zákazníků umožňuje vytvoření zákazníka, editaci, sledování a změnu stavu “Zákazníka”
• V databázi zákazníků je možné vyhledávat podle různých kritérií, sledovat jejich historii a provádět exporty do běžných formátů
• Ke každému zákazníkovi se zobrazí propojení s dalšími entitami - (“Kontaktní osoby”, “Smlouvy”, “Objednávky”, “Kontakty” (telefon, e-mail, ...), “Události”, “Komentáře”, “Přílohy”)
• K zákazníkovi je možné plánovat události a zajistit tak řízenou a plánovanou péči o “Zákazníka”

“Smlouvy”

   Vztah se zákazníkem může být definován rámcovou nebo jinou smlouvou, kde je možné stanovit, jaké zvláštní podmínky budeme Zákazníkovi poskytovat. Ke Smlouvě lze následně vztahovat Nabídky a Objednávky.

• Smlouvy je možné spravovat (vytvořit, editovat, sledovat stav, sledovat vztah k dalším entitám)
• Mezi Smlouvami je možné vyhledávat podle různých kritérií, sledovat jejich historii a provádět exporty do běžných formátů
• Pro smlouvu je možné řídit stav (“Návrh”, “Schváleno”, “Platná smlouva”, “Neplatná smlouva”, “Zamítnuto”)
• Smlouvu je možné propojit s dalšími entitami (“Kontakt”, “Smlouva”, “Objednávka”, “Adresa”, “Komentář”, “Přílohy”)
• Ke smlouvě je možné vytvořit a spravovat aktivitu pomocí Kalendáře aktivit

“ Leady ” (Příležitosti)

    Příležitost slouží k zachycení prvního kontaktu nebo nadějné obchodní příležitosti k dalšímu zpracování.

• Lze vytvářet a upravovat Příležitosti a sledovat a měnit jejich stavy (“Nový”, “Zpracování”, “Konvertace”, “Zamítnuto”), případně pracovat s “Příležitostí” dle “Priority”
• Lze vyhledávat, sledovat historii a exportovat Příležitosti do běžných formátů
• Příležitost, která se vyvine v obchodní případ, je možné překonvertovat na Zákazníka a pak jej již opečovávat standardně

“Osoby”

   CRM modul také umožňuje vést evidenci osob. Každá konkrétní osoba může být evidována buď samostatně nebo může být “svázána” s konkrétním zákazníkem či leadem.

• U každé osoby lze evidovat kontaktní údaje (telefonní čísla, emaily,... )
• U každé osoby je možné evidovat role, v jakých daná osoba vystupuje (manažer, obchodník,...)
• V evidovaných osobách je možné vyhledávání a exportovat je do běžných formátů
• Lze sledovat propojení Kontaktů s entitami (Příležitost, Zákazník, Smlouva, Nabídka, Objednávka,...)

Modul “ Objednávky”

Produktový katalog

   Produktový katalog je kolekcí produktových nabídek pro konkrétní distribuční kanál rozšířenou o další informace, jako např. parametry SLA, fakturace a podrobnosti o přepravě. Každá nabídka produktů kombinuje informace o cenách a dostupnosti spolu se specifikacemi produktu, které popisují vztahy mezi produkty, službami použitými k realizaci produktu a zdroji, které vyžadují.

   Nabídka pro produkt, kterou lze objednat od poskytovatele katalogu, zahrnuje specifikaci produktu, informace o cenách, požadavky na SLA, segmenty trhu, přílohy, apod. Nabídka produktů může představovat jeden produkt, nebo také soubor produktů.

   TSM umožňuje spravovat produktové katalogy a konfigurovat produkty v katalogu.  Produkt patří do určité kategorie, má specifikaci, určenu kategorii zákazníků a detailní parametry (SLA, rychlost).

   Pomocí TSM GUI lze vyhledávat a editovat produkty, provádět exporty nebo sledovat historii produktu. Lze definovat kardinality a závislosti mezi produkty (bundle, value-added service). Pro produkty je definována cenotvorba včetně evidence možných slev.

   Produkty mají nadefinovánu vazbu ke Službám ze servisního katalogu, které produkt realizují.

Komponenta “Objednávky”

   Objednávka produktu je vytvořena na základě nabídky produktu, který je definován v katalogu. Produktová nabídka identifikuje produkt, nebo soubor produktů, které jsou k dispozici zákazníkovi a zahrnuje charakteristiky, jako např. cena, varianty, apod. Objednávka produktu odkazuje na nabídku produktu a identifikuje konkrétní požadavky zákazníka.

• produktová objednávka je typ objednávky, který lze použít k zadání objednávky mezi zákazníkem a poskytovatelem služeb, nebo mezi poskytovatelem služeb a obchodním partnerem, nebo naopak
• atributy produktové objednávky jsou: identifikátor, stav, kategorie priority (spotřebitelský trh, podnik, apod.), související fakturační účet, smluvní strany a položky objednávky

   Objednávka vytváří předpoklad pro realizaci obchodního vztahu. Je vždy vztažena k zákazníkovi a lze ji vztáhnout ke Smlouvě nebo k Nabídce.

• Objednávky je možné spravovat (vytvářet, editovat, sledovat stav)
• Objednávky lze připojit k Nabídce a ke Smlouvě
• Mezi Objednávkami je možné vyhledávat podle různých kritérií, sledovat jejich historii a provádět exporty do běžných formátů
• Objednávku můžete propojit s dalšími entitami (Kontakt, Adresa, Smlouva, Produkt, Nabídka)
• Objednávku lze řídit a sledovat pomocí workflow a tím zajistit realizaci potřebných kroků, které s ní souvisí
• K Objednávce lze vytvořit aktivitu a řídit jí pomocí Kalendáře aktivit

   Produktová objednávka je vytvořena na základě nabídky produktů definované v katalogu. TSM umožňuje základní práci s objednávkami - vytvoření, editaci, sledování aktuálního stavu objednávky a historii.

   Základní stavy produktové objednávky jsou Nová, Rozpracovaná, Technické šetření, Realizace, Ukončená a Zrušena. Stavy produktové objednávky lze měnit, stejně jako další informace o objednávce.  Stavy a přechody mezi stavy lze konfigurovat. Celý životní cyklus objednávky je mapován na procesy.

   Během práce s produktovou objednávkou je možné přidat produkty z produktového katalogu, případně služby ze servisního katalogu (zjednodušený service provisioning). Produktová objednávka je propojena s entitami Zákazník, Smlouvy, Kontakty, Adresy, Fakturace atd.. K hlavním atributům produktové objednávky patří požadovaná data začátku a realizace služby, umístění služby, akce které je potřeba provést např. přidat nebo odstranit produkty.

Produ ct Inventory

   Produkt představuje (např. zákazníkem) předplacené nabídky. Produkt může být balíček produktů (např. Hlasový balíček) nebo konkrétní produkt (Voice over IP, hlasová schránka, apod.). Produkt eviduje stav, umístění, cenu, vlastnosti, fakturační účet, apod.

   Evidence produktů zákazníka (instance produktu u zákazníka). TSM umožňuje založení, změny, evidenci vazby na služby, identifikaci poruch.

Zákaznický portál

   TSM poskytuje API pro tvorbu zákaznického portálu. Portál je vytvořen vždy na míru, typicky řeší napojení na již existující portál zákazníka.

Service Management

Servisní katalog

   Servisní katalog obsahuje definici služeb z hlediska OSS systémů. Na vstupu se mapuje pomocí CFS (Customer Facing Service) na objednávku z orderingu a provádí dekompozici na RFS (Resource Facing Service) poskytované z Network Inventory systémů (NI) nebo od alternativních operátorů. Parametry potřebné pro konfiguraci služby jsou slučovány do logických celků – komponent. Komponenta může být přiřazena k CFS (a pak obsahuje parametry vzešlé z orderingu včetně jejich dekompozic) nebo k RFS a pak se typicky mapuje na Resource jak jej zná NI. Parametry komponent jsou dále v rámci Provisioning procesu plněny pomocí interface (automatické tasky) nebo uživatelem (manuální tasky).

   Servisní katalog obsahuje definice služeb, konfigurační data a číselníky. Mezi hlavní odběratele definic patří Service Inventory (struktura služby, číselníky) a Service Provisioning (struktura služby, dekompozice CFS na RFS, Business Rules, číselníky). Kromě toho Service Catalog ve formě parametrů služby obsahuje konfigurace i pro návazné systémy (SA, Dohled, Reporting, …) a vystavuje je ve formě API.

   Service Catalog musí být mapovaný na návazné katalogy:

• Product Catalog – mapování produktů nebo CFS (např. ve formě exportů nebo smluvených kódů)
• Technology Catalog – mapování RFS a Resource

   CFS (Customer Facing Service) je služba poskytovaná směrem k zákazníkovi (např. Mobilní volání, Broadband Internet, IP VPN). Tuto službu lze prodávat pod různými produkty v rámci Produktového katalogu. Zatímco produkt v sobě musí mít již obsaženy všechny parametry s dopadem na cenu (typicky např. rychlost), služba je obsahuje jen jako instanční parametry.

   RFS (Resource Facing Service) je služba poskytovaná sítí providera. Je to tedy interní služba, ze které se poté skládají zákaznické služby CFS. Tato služba již v sobě obsahuje technologické detaily a zejména dekompozici na jednotlivé Resource (zdroje), které ji tvoří. RFS lze také objednat jako subdodávku od partnera. RFS a jednotlivé Resource tvoří také podklad pro design služby v rámci Network Inventory - ten v průběhu realizace služby alokuje konkrétní zdroje.

Service Inventory

   Service inventory slouží jako master databáze provozního nastavení služeb z hlediska OSS systémů. Navazuje na data o produktech zákazníka a obsahuje odkazy na konzumované zdroje (Koncové zařízení, IP Adresa,  Konektivita u partnera, …).

   Service Inventory je primárně plněno v rámci procesu Service Provisioning, může však být modifikováno i v rámci rekonfigurací nebo SA. Pro administrátorské zásahy je možné data zadávat manuálně přímo přes GUI. Service Inventory vystavuje zdokumentované API pro vytvoření / aktualizace / čtení dat. Service Provisioning si v rámci požadavku na změnu vždy stahuje aktuální stav služby z Service Inventory. Datové sklady si data online replikují pomocí databázových nástrojů.

   Kromě provozního stavu obsahuje SI i aktuálně projektovaný stav a roční historii (stavy “Projekt” / “Provoz” / “Zrušeno” / “Suspend”).

   Service Inventory eviduje následující základní entity Service Instance:

• Instance Customer Facing Service (CFS) a jejich položky
• Instance Resource Facing Service (RFS) a jejich relevantní položky
• Mapování služeb (RFS, CFS) na ostatní služby a komponenty služeb:

• Ostatní navázané služby
• Relevantní zdroje použité ke konfiguraci služby
• Služby a zdroje ze systémů jiných operátorů, které se podílejí na realizované službě

Service Inventory slouží pro:

• Evidenci služeb zákazníka, spravuje se v ní životní cyklus služby (nová, v realizaci, v provozu, suspendovaná, …). Může nabýt dva aktivní stavy (provozní stav + požadovaná změna v realizaci)
• Trouble ticketing (nahlašování poruch)
• Service Impact Analýzu
• Reporting

Service Provisioning

   Service Provisioning pracuje nad servisní (často označované jako “technickou”) objednávkou. Na vstupu dostává seznam produktů a provádí jejich překlad na služby. Mezi základní kroky realizace patří:

• Validace objednávky (případný manuální zásah od backoffice)
• Ověření dostupnosti služby
• Dekompozice na RFS, určení požadovaných Resource
• Service design - na základě RFS a Resource žádost do Network Inventory pro alokaci zdrojů
• Aktivace služby - automatické nebo manuální aktivace alokovaných zdrojů
• Field work - možné napojení na Work Force modul a plánování techniků dle regionů a dovedností
• Ověření funkčnosti (manuální nebo automatické)
• Dokumentace sítě

   V rámci service provisioningu je využit Process Engine s pokročilými funkcemi pro design procesu, konfigurace automatických akcí, konfigurace přiřazení manuálních tasků apod.

   Často je rozdělení mezi BSS světem (“zákaznickou” objednávkou / Product Order) a OSS světem (technickou objednávkou / Service Order) do samostatných modulů příliš detailní a z hlediska operátora je výhodnější pracovat nad jednou objednávkou, která v sobě obsahuje obě složky. Tato objednávka poté slučuje vlastnosti popsané v Service Provisioning i v Product Order. Přestože se jedná o jednu objednávku, tak stále obsahuje samostatné sekce pro “produkty” a “služby” - toto rozdělení je důležité z hlediska dekompozice produktu a vzhledem k billingu. Pokud má operátor netriviální produktové portfolio, pak toto rozdělení vždy doporučujeme.

Modul “ Workforce ”

    Modul  “Workforce” obsahuje plánování pracovníků v terénu  včetně požadovaných dovedností, dostupnosti, geografické informace apod. Pracuje nad manuálními tasky zahrnutými do pracovního postupu a přiřazuje terénního pracovníka a čas provedení úkolu. Součástí modulu je mobilní aplikace (Android, iOS) umožňující i offline práci v terénu.

• práce je plánována na základě přístupu založeného na procesech, které je možné spravovat v Process designeru
• základní prvky WFM:

• správa pracovních objednávek
• správa zdrojů, jejich dostupnost a dovednosti
• nákladová optimalizace plánů práce
• využití rajonizace a prioritizace při plánování
• sjednání termínu návštěvy s koncovým zákazníkem
• práce s materiálem a sklady

• informace dostupné pro terénní pracovníky

• popis požadované práce
• popis umístění úkolu včetně mapy
• datum a čas potřebný k dokončení úkolu
• informace týkající se infrastruktury a technologie (přiřazení zařízení) z modulu zásob nebo ze zdrojů třetí strany
• spotřební materiál a skladové položky (např. modemy, síťové terminátory, kabely, apod.)

Modul “ Ticketin g”

   Poruchový ticket je poruchou nebo problémem identifikovaným zákazníkem nebo jiným systémem, který je potřeba vyřešit, a který se používá  pro hlášení a správu řešení problémů, incidentů nebo požadavků. Mezi příklady klientů Trouble Ticket API patří aplikace CRM, systémy pro správu sítě nebo jiné systémy pro správu poruch (např. B2B).

   Poruchový ticket má komplexní životní cyklus s atributy, které specifikují povahu a závažnost problému a všechny potřebné související informace. Hlavními atributy poruchových ticketů jsou: popis, závažnost, typ, související data (vytvoření, očekávané řešení, řešení), stav a související informace (důvod a datum změny), dotčené strany (původce, vlastník, kontrolor, apod.), související entity (“Produkt”, “Objednávka”, “Faktura”) a poznámky. Oznámení jsou definována tak, aby poskytovala informace o aktualizaci problémového ticketu vč. změn stavu.

  Management poruchových ticketů postihuje např.:

• konfiguraci SLA
• prioritizaci poruchového ticketu
• automatizaci procesních tasků dle konfigurace procesu
• hierarchii ticketů (např. zákaznický ticket spojený s technologickým ticketem)
• RCA (Root Cause Analysis), SIA (Service Impact Analysis) musí být provedeny systémem Network Inventory, modul Ticketing však interpretuje výsledky, odpovídajícím způsobem vytváří tickety, vypočítává SLA, informuje zákazníky, atd.
• Správa WorkForce - plánování řešení problémů terénními pracovníky, příslušné API umožňuje integraci se systémy třetí strany
• komunikace s poplašným / diagnostickými systémy

   Poruchový ticket využívá Process Engine k navrhování a spouštění komplexních pracovních postupů s tikety s úkoly pro pracovníky a vlastními akcemi.