VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE FAKULTA INFORMATIKY A STATISTIKY VYŠŠÍ ODBORNÁ ŠKOLA INFORMAČNÍCH SLUŽEB BAKALÁŘSKÁ PRÁCE

Transkript

1 VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE FAKULTA INFORMATIKY A STATISTIKY VYŠŠÍ ODBORNÁ ŠKOLA INFORMAČNÍCH SLUŽEB BAKALÁŘSKÁ PRÁCE NÁVRH ŘEŠENÍ PRO VYHLEDÁVÁNÍ A NÁSLEDNÉ UZAVŘENÉ TICKETŮ PRO ÚČELY OBS TÝMU SERVICE DESKU 1. ÚROVNĚ SPOLEČNOSTI CSC. ASSEL ABDIRAKHMAN 2012

2 P R O H L Á Š E N Í Prohlašuji, že jsem bakalářskou práci na téma Návrh řešení pro vyhledání a následné uzavření ticketů pro účely OBS týmu Service Desku 1. úrovně společnosti CSC vypracovala samostatně a použila pouze zdrojů, které cituji a uvádím v seznamu použité literatury. V Praze dne 21. května podpis autora

3 Poděkování: Děkuji paní PhDr. Heleně Kučerové za podporu při dokončení mého studia a konsultace při napsání této práce. Dále děkují společnosti CSC Computer Science s.r.o. za poskytnutou informací a vstřícný přístup. Zvláště děkuji mým rodičům a příteli za víru v mou schopnost všechno zvládnout.

4 Abstrakt: Tato bakalářská práce se zabývá návrhem dočasného řešení, které by pomohlo zaměstnancům Service Desku 1. úrovně společnosti CSC ve vyhledaní seznamu potřebných ticketů v systému pro registraci IT případů, jejich porovnání s seznamem čísel případů zaregistrovaných v systému spolupracující společnosti OBS a následné uzavření ticketů, které již jsou na straně OBS uzavřené. Teoretická část práce obsahuje vysvětlení problému samotného, popis formátů, které jsou generovány reportingovými nástroji obou spolupracujících společnosti a možnosti použití každého z nich pro řešení problému. Praktická část obsahuje popis prostředí v němž se problém řeší, popis vybrané funkcionality reportingových nástrojů obou systému, návrh a postup vytvoření vhodných reportů. Poslední části je návrh možných řešení pro hlavní problém a výběr nejvhodnějšího z těchto řešení. Abstract: This thesis is designed to create a temporary solution that would help employees of the 1. level Service Desk in CSC corporation to search needed tickets in the incident registration system, then compare them with case numbers registered in a system of a co-working OBS company and as a result of that comparison find and close tickets that are already closed in the OBS system. Theoretical part of this thesis consists of a detailed problem description, description of a formats that are generated by reporting tools of both of the co-working corporations and possibility of their use for the problem resolution. Practical part contains description of the environment in which is this problem solved, description of the functionality of the reporting tools used in the systems mentioned, design and process of creating appropriate reports. The last part deals with a design of a possible solutions for the main problem and selection of the best fitted of them.

5 OBSAH I.Úvod II.Popis prostředí Co je ITIL? Jaká cykly ITIL nás zajímají z hlediska této práce?...7 Service Design... 7 Service Operation Registrace Případu Stavy otevřených případů Jak najít frontu případů konkrétního týmu...26 III.Řešení problému Metoda hledání ticketů k uzavření...29 Varianta s tickety ve stavu Closed...31 Varianta s tickety v jiném stavu než Closed...31 Porovnání způsobu...31 Vytvoření reportu obsahujícího všechny tickety předané OBS Vytvoření reportu v MSS...39 Porovnání seznamu v Excel a následné uzavření ticketu v Remedy...42 IV.Závěr Zdroje

6 I. Úvod. Téma teto bakalářské práce vychází z reálné situace se kterou jsem se setkala během své práce na pozici agentů v týmu OBS SME (Subject Matter Expert) na Service Desku 1. úrovně společnosti CSC Computer Science s.r.o. Mou hlavní pracovní náplni na této pozici je poskytování informaci a porady agentům Service Desku, které jsou jediným styčným bodem mezi koncovým uživatelem a dodavatelem služeb. Poskytovaná informace se týká vymezení služeb, které společnost OBS dodává koncovému uživateli. Porada většinou agentům pomáhá určit co poruchu učinilo, a v případě, že je to problém, který by OBS vyřešila, jaké přesně informace pro stanovení příčin poruchy a jejich následné odstranění bude OBS od Service Desku potřebovat. V případě, že agent zaregistrovaný ticket pošle OBS, nejprve se ten ticket ocitne ve frontě která se nazývá OBS Focal, a o ni se stára náš tým. Agent z našeho týmu zkontroluje úplnost a přesnost údajů, které tam agent zadá, v případě, že ticket není vyhovujícím způsobem vyplněn, pošle ho zpátky agentovi s poznámkami o tom, co v nich chybí a jestli je to vůbec případ pro OBS. V případě, že je ticket vyplněn správně a nic v něm nechybí, pošleme ho přímo na OBS, a to se nazývá to bridge the ticket, což by se dalo přeložit jako přemostit případ. Použiti tohoto výrazu je opodstatněno tím, že mezi systémem, který pro registraci případů používá CSC, a systémem OBS existuje takzvaný bridge neboli můstek, který data uložena v jednom systému přenese do druhého. Někdy se ale stane to, že z nějakého důvodu ten můstek data poprvé vůbec nepřenese a ticket se ocitne ve frontě, která se nazývá OBS failed to bridge tickets. V tomto případě je jednou z našich odpovědnosti zkontrolovat ten ticket znova a zkusit ho přemostit ještě jednou, když to nepůjde i po druhé, tak se pošle ticket do naši osobní fronty a zahájí se manuální proces předání případu OBS. Někdy se může také stati, že se počáteční přemostění ticketu podaří, ale během vyšetřování případu, kdy nemáme možnost zkontrolovat to, jestli se data v ticketu obnovují nebo ne, najednou přestane můstek data přenášet a nikdo o tom neví. Může se stát, že se případ na straně OBS zavře, ale na straně CSC zůstane otevřený i po dobu několika měsíců, což způsobí porušení dohody o úrovní poskytovaných služeb (SLA Service Level Agreement). Takových ticketů může v systému být velice hodně, a jelikož náš tým má na starosti hlídaní fronty OBS, je naši povinnosti nějakým způsobem takové tickety uzavřít. Jediným doposud dostupným způsobem je otevření každého ticketu zvlášť a manuální porovnání poznámek a statusu v obou systémech, což není přijatelné, jelikož, za prve, může být ticketů ve frontě 2

7 až několik stovek, za druhé, otevření jediného případu a procházení různými záložky každého ticketů může vzít od 10 do 15 minut. Úkolem této práce je navrhnout značně automatizované řešení, které by potřebovalo minimální zásah od agentu, bylo poměrně lehké při použití a pomohlo by efektivně takové případy uzavírat. 3

8 II. Popis prostředí. CSC je velkou korporací, která na trhu B2B představuje jednu z největších společností poskytujících řešení a služby pro podporu vnitřních podnikových procesů těsně využívajících IS/ICT tohoto podniku. Pro poskytování svých služeb používá CSC standardů a nejlepších praktik, které jsou téměř totéž jako standard pro odvětví IT. Jedním z takových standardů je ITIL. CSC má certifikaci z příslušných mezinárodních certifikačních autorit jako ISEB a EXIN. Dá se říct, že jádrem byznysu CSC je management IT služeb, o čemž v podstatě celý ITIL je. 1. Co je ITIL? ITIL je zkratkou pro Information Technology Infrastructure Library, což se dá přeložit jako Knihovna Infrastruktur Informačních Technologií. ITIL je vlastně souborem nejlepších praktik pro ITSM (IT Service management řízení IT služeb). ITSM se ve své řádě zabývá spojením IT služeb s potřebami podniku, mysli na to jak efektivněji dodat IT služby pro podniky, jejichž hlavní činnosti je v podstatě práce s informací. Fyzicky sebou ITIL současně představuje řadu 5 hlavních publikaci, každá z kterých pokrývá jeden životní cyklus ITSM. Poslední verze ITIL je známá jako ITILv3 nebo ITIL edice Vytvoření ITIL bylo zahájeno vládou Velké Británie v druhé půlce 80. let minulého století. [1] Podnětem pro napsání nějakého rámce pro IT služby stal rychlý rozvoj těchto služeb a jejich všeobecné zavedení hlavně v státních orgánech. Cílem napsaní posloužilo celkové zvýšení efektivity státních IT Infrastruktur. Autoři této práce, které pracovali pro CCTA (Central Computer and Telecommunications Agency), sloučili nejlepší praktiky a zásady existující a používané v té době většinou v průmyslech. Tento soubor autoři pojmenovali jako Government Infrastructure Management Method (GITMM Metoda řízení státní infrastruktury). Později v roce 1989, když se ukázalo, že se o tu práci zajímají nejen státní podniky a organizace byl tento soubor přejmenován jako ITIL. Během 90. let zasloužila si ta knihovna celosvětovou popularitu, jelikož na ten okamžik byla nejkompletnějším souborem nejlepších praktik a standardů v řízení IT. Teď bych se chtěla pokusit krátce vysvětlit, co v podstatě ITIL v3 znamená, jelikož si myslím, že pro pochopení nejen cíle této práce ale vůbec pochopení proč se to má řešit, je velice důležité vědět o čem ITIL je. Po vysvětlení konceptů ITIL, zaměřím se na jednotlivé cykly a prvky ITIL, které se bezprostředně tykají termínu Service Desk. 4

9 Podle mě nejlepší analogie pro ITIL byla představena společnosti CompuCom ve videu, které je dostupné na youtube.com [2]. Představte si, že jste v restauraci a udělali jste objednávku. Po nějaké době Vám přinesou dezert a hned po dezertu dostanete americké brambory a vodu, ale smažený řízek, který je sice opravdu dobrý, Vám přinesou až nakonec večeři spolu s citronem, který byste chtěli přidat do vody, kterou již máte vypitou. Všechno co jste chtěli Vám sice přinesou, ale ne ve vhodnou dobu a ne jak byste toho přáli. Vůbec to není servis, který byste chtěli dostat. A většina z IT oddělení nebo podniků fungují akorát stejně, protože používají starých principů, které vedou IT podle technologií ne podle potřeb uživatelů nebo zákazníků. Dodají Vám servery, sítě, počítače jako potravinářský obchod potraviny pro restaurací. Oni spravují technické složky, kdežto byznys potřebuje informační služby, které přinesou mu hodnotu. Akorát tento problém adresuje ITIL, tak že předefinovává IT tak aby dodával Informační Služby zvyšující hodnotu podniku. Podle ITIL existuje 5 hlavních cyklu dodání těchto služeb, které můžeme přirovnat s cykly probíhající při založení a následném vedení restauraci. Založit opravdu dobrou sít' restauraci je těžké. Všechno začíná takovými klíčovými rozhodnutí jako výběr opravdu dobré kuchyně, návrh vnější a vnitřní úpravy restauraci tvořící určitou atmosféru tak ale aby ceny byli přijatelné pro adresovanou skupinu spotřebitelů. Tohle-to všechno má za cíl přitáhnout do podniků stálou klientelu a v restauračním byznysu se to nazývá Motiv restaurace (Restaurant Theming). Nejhlubší ležící ITIL cyklus, který se nazývá Strategie Služeb (Service Strategy), je totéž jako Restaurant Theming. Ten cyklus je určen pro to aby dal dohromady podnik a IT služby pro vytvoření byznys případů a určení cíli podniku, které ve své řadě definují co bude dělat IT. Po tom, co je definován Motiv restaurací, musí se navrhnout Menu, což má na starosti šéfkuchař, který musí uvést do rovnováhy suroviny, výrobu, náklady a dodavatelé tak, aby se v každém podniku podávalo to nejlepší jídlo. ITIL to nazývá Návrh Služeb (Service Design). Tento cyklus definuje Informační Služby které sledují potřebám byznys případů, při tom ale berou v úvahu úhrnné potřeby celého podniku nebo společnosti. Po tom co se nadefinuje Menu restauraci, nedají se kuchyně jen tak hned do vaření všech jídel. Před tím než to začnou dělat, provedou cvičební pokusy, připraví se a zdokumentují výsledky. Dělá se to proto, aby byli požadované pokrmy dobré a spolehlivě hotové tehdy, kdy budou na to zákazníci připravené. ITIL to nazývá Předání Služeb (Service Transition). V tomto cyklu plánuje IT spouštění služeb a změn v podniku tak aby 5

10 se dosáhlo maximálního prospěchu podniku. Číšníci v restauraci jsou samozřejmě zaměřené na dodání pokrmů, vědí totiž co každý jejich zákazník chce, a co by měla začít následujícím krokem připravovat kuchyně. Dá se říct, že v podstatě vládnou celkovou spokojeností zákazníků. V ITIL se tomu říká Provozování nebo Spravování Služeb (Service Operation). Tady takové prostředky jako Service Desk mají na starosti neboli vlastní odpovědnost dodávání Informačních Služeb zákazníkům včasně, v odpovídající kvalitě a v případě, že s dodávanými služby nastane nějaký problém, také mají na starosti ho vyřešit. A nakonec, tak jako ve všech dobrých restauracích existuje pán vrchní, který se stará o koordinací aktivit a dodržení standardů podniku, tak i v ITIL existuje 5. cyklus, který se nazývá Nepřetržitý Cyklus Zdokonalení Služeb (Continual Service Improvement Cycle). Tento cyklus existuje pro stálé měření a vylepšení přínosu, který musí IT přinášet podniku. 6

11 Cykly ITIL. Zdrojem obrázku 2. Jaká cykly ITIL nás zajímají z hlediska této práce? Jelikož situace, ke které se má navrhnout řešení, nastala na půdě Service Desku CSC a má vliv na statistická data, která ukazují jestli se dodržuje dohoda o úrovni poskytovaných služeb, bude nás především zajímat cyklus Spravování Služeb a Návrh Služeb. Jelikož podle pořadí stojí Návrh Služeb neboli Service Design před Spravováním Služeb neboli Service Operation, začneme z krátkého popisu cílů a úkolů tohoto cyklu jako prvního. Service Design. Hned po tom co jsou odsouhlaseni strategické servisy, které se mají poskytovat, mají se tyto servisy navrhnout. Má se navrhnout jejich podrobné schéma, které bude obsahovat celý balíček faktorů, které se mají brát v úvahu. Na oficiálních stránkách věnovaných ITIL, které jsou zřízené a obnovováni APM Group Ltd ve spojení s Cabinet Office, což je v podstatě součást Britské Vlády, je publikovaná úvodní přehlední studie o ITIL, která 7

12 poskytuje takovou definici pro Service Design: Návrh vhodných a inovativních IT služeb, v sobě zahrnujících jejich architekturu, procesy, politiku a dokumentaci, tak aby byli splněné současné sjednané a budoucí byznys požadavky [1]. Jaké jsou hlavní aspekty, které se mají brát do úvahy při navržení nových služeb nebo změn starých? Takových hlavních aspektů je 5 [3]: Řešení Služby (Service Solutions). Cílem pro Service Design je navrhnout nové nebo změněné služby pro zavedení do současně a skutečně existujícího prostředí. Tady slovo skutečně je velice důležité, protože pochopení potřeb, skutečně existujících v tom daném prostředí, je pro návrh naprosto nezbytné. Musíme si ujasnit, jaké jsou funkční požadavky které má zákazník nebo podnik, jakého stavu těmito požadavky chce dosáhnout. Samozřejmě že nic bez těchto požadavků nemůžeme začít navrhovat nebo stavět. Musíme také pochopit jaké tyto služby budou potřebovat zdroje a schopnosti, abychom věděli jestli na to skutečně všechno máme. Nechceme zákazníkovi slibovat něco, co v realitě nemůžeme poskytnout. Procesy (Processes). Pro řízení a hlavně podporu všech systémů a služeb, které budeme poskytovat, musíme se postarat o zavedení správných nebo, když je potřeba, pozměnění existující procesů. Uvažujme třeba existující současně na Service Desku problém s zavedením podpory bezdrátového připojení pro zákazníky. Agentům Service Desku a pracovníkům zákaznické společnosti, které jsou koncovými uživateli, bylo oznámeno, že začínaje z půlky března zahájí náš Service Desk podporu bezdrátového připojení k vnitřním korporativním sítím, což znamená, že při nějakém problému s připojením bude koncový uživatel kontaktovat nás. Ohledně zahájené podpory byli vytvořené skripta v Knowledge Management Tool dostupná pro agenty, kde bylo detailně popsáno jak se má uživatel připojit, co všechno se má nastavit, a v případě že to nebude fungovat, má se zaregistrovat incident a pošle se na OBS pro vyřešení. Jenomže když takový případ skutečně nastal, OBS řekla, že, za prve, konečnou dohodu o bezdrátovém připojení se zákazníkem nemá, protože provoz bezdrátového připojení je v testovací fázi, a, za druhé, i kdyby tento problém řešila, tak by neměla na to možnost, jelikož problém spočívá v tom, jak je nastaven profil tohoto uživatele a k tomu má přístup jenom jeden z týmů CSC spravující uživatelské účty. Kvůli tomu, že byl navržen špatný proces, řešil se tento případ velice dlouhou dobu a nakonec byl uživatel natolik poskytovaným servisem frustrovaný, že o tom napsal dopis svému vrcholovému 8

13 vedení. Tady je otázkou jestli se to opravdu mělo řešit Service Deskem, nebo měl koncový uživatel poruchu nahlásit někomu, kdo je za testový provoz odpovědný. Návrh vhodného procesu v sobě také zahrnuje určení závazků a odpovědnosti pro role, a to tak, aby při tom měli lidi, které mají tyto role plnit, určité znalosti a včasnou informaci, které jim v tom pomůže. Případ uvedený nahoře je velice dobrou ukázkou toho, že se mají procesy k poskytovaným službám být navržené a dohodnuté se všemi strany správně. Architektura Technologie (Technology Architectures). Z hlediska technologie je velice důležité, že architektura technologie nově navrhované služby je kompatibilní a vůbec zapadá do celkové architektury již existujícího systému. Jako případ tady můžeme uvést jednoho ze zákazníků CSC, ale konkrétní název společnosti uvádět nebudu, jelikož taková informace je delikátní. Servery tohoto zákazníku běží na různých verzích Micrisoftích operačních systémů Windows Server. Takhle to bylo téměř ze samotného začátku, a když byla potřeba operační systém a technologií modernizovat, zase se kupovali řešení od Microsoft. Tak se to dělalo kvůli tomu, že tyto systémy již zákazníkem a jeho dodavateli jiných služeb byli známy a tím se ještě nemuseli všechny jiné systémy přebudovávat. I když třeba řešení postavené na bázi Linux bývají velice dobré, přebudování celého systému pod nich bude zákazníkovi stát víc než použit řešení od Microsoft. Podpůrné Systémy (Supporting Systems). Před tím, než začít poskytování nových služeb, musíme se přesvědčit, že na to máme odpovídající podpůrné systémy. CSC, jakožto obrovská společnost jejíž hlavní činnosti je ITSM, již takový systém má. Tento systém ale není její vlastní výtvor, kupuje ho od společnosti BMC Software, která se speciálně zaměřuje na návrh takových systémů. Od BMC Software má CSC zakoupený celý balíček produktů, které jsou součásti skupiny produktů pod názvem Remedy, a to BMC Remedy IT Service Management Suite. Tento. Tento balíček obsahuje takové produkty jako: BMC Asset Management; BMC Change Management; BMC IT Incident Management ; BMC Problem Management; BMC Knowledge Management; 9

14 BMC Service Request Management; atd. (tady musím poznamenat, že CSC nejspíš má od BMC Software zakoupené ještě produkty dovolující sledovat analytická data, související se splněním stanovených SLA a vnitřních ukazatelů určených zlepšit celkové výsledky. S těmito produkty jsem ale jakožto agent Service Desku nepřišla do styku). Pro řešení problému stanoveného pro tuto práci budeme většinou pracovat s funkcionalitou BMC Remedy IT Service Management Incident Management. V dalších bodech práce bude také uvedeno jak se k této aplikaci nebo spíš systému přestupuje. Systémy Měření a Metriky (Measurement Systems and Metrics). Po návrhu a zavedení nových služeb se má nějakým způsobem kontrolovat, zdá jsou poskytována dle domluvených cílů nebo plánů. Na to jsou navržené systémy měření a metriky, podle kterých se měří úroveň poskytovaných služeb. Jak se takové metriky stanoví a kde jsou zdokumentované si popíšeme v dalších bodech, protože pro pochopení konkretních metrik se má také pochopit, co je Service Desk a jaké jsou jeho hlavní funkce a cíle. Tady si ještě řekneme, proč se také musí měřit úroveň poskytovaných služeb? To jestli naměřené veličiny odpovídají stanoveným cílům pomáhá nejen uspokojovat požadavky zákazníků, ale i předpovídat trendy a podle získané statistiky určovat krizové a nebezpečné body, na které se má dát zvláštní pozornost. Systémy Měření tak pomáhají včasně předpovědět a odstranit hrozící nebezpečí. Popsané aspekty dávají jenom přehled klíčových principů a cílů podle kterých se řídí cyklus Service Design, tady ale nebudu popisovat podrobněji všechny aktivity a procesy probíhající v tomto cyklu, jenom je uvedu tady jako seznam, vyjímaje jednoho bodu, který z hlediska teto práci od nás si zaslouží trošku větší pozornost: Service Catalogue Management (SCM) v podstatě katalogizace všech služeb poskytovaných zákazníkovi všemi dodavateli služeb; Service Level Management (SLM) stanovení, sjednání a dokumentace cílových bodů poskytovaných IT služeb, nedělitelnou části tohoto managementu je stanovení úrovně poskytovaných služeb Service Level Agreements (SLA); Capacity Management řízení a evidence všech zdrojů potřebných pro možnost poskytování IT služeb poptávaných zákazníky; 10

15 Availability Management řízení dostupnosti poskytovaných služeb, což je v podstatě zajištění toho, aby služby byli dodané včas, vhodným způsobem, a kdy je zákazník opravdu potřebuje, při tom se mají brát do úvahy náklady, které nese zákazník; IT Service Continuity Management (ITSCM) - zajištění toho, aby v případě nepředvídaných situaci měli jsme plán jak obnovit a zajistit poskytování služeb, především pro kritické oblasti podniku. V podstatě management rizik; Information Security Management (ISM) zajištění a řízení informační bezpečnosti tak, aby to odpovídalo korporativním pravidlům zákazníků. Tato aktivita je těsně spojená s bezpečnostní politikou prováděnou vedením podniku; Supplier Management v podstatě hlídání toho, aby dodavatele IT služeb a služby které dodávají odpovídali stanoveným cílům, nákladům, celkovým cílům podniku a vůbec pro nás byli výhodné. Service Operation. Jakmile všechny služby které se mají dodat byli navrženi v cyklu Service Design a otestována v cyklu Service Transition, přichází cyklus Service Operation, který má na starosti všechny služby konečně zákazníkovi dodat. Tento cyklus nebo stadium nám ukáže jestli v předchozích stadiích byla udělána dobrá práce. Cíle tohoto cyklu tedy můžeme definovat takto: Koordinovat a vykonávat všechny aktivity a procesy spojené s efektivním dodáním a řízením služeb na sjednané úrovní řídit infrastruktury technologií používaných pro dodání a podporu služeb; Koordinovat lidí které řídí technologie, procesy a služby. Klíčové procesy probíhající v tomto cyklu napříč všech funkcí tohoto cyklu jsou [1]: Proces řízení události (Event Management Process). Události je změna stavu, která má hodnotu nebo je důležitá pro Konfigurační Prvky (Configuration Item) nebo IT Službu. [5] Události mohou být: Informativní událost. Je důležité takové události vědět a je sledovat, nejsou ale příliš urgentní. Je to jako zelená barva ukazující, že je všechno v pořádku. Příkladem by mohla být notifikace o tom, že zálohování dat proběhlo úspěšně. Varující události. Takové události mohou mít špatný vliv, jestliže se s nimi nic 11

16 neudělá. Analogií je žlutá barva ukazující, že něco není jak by mělo být. Příkladem by mohla být též varování o ukončení zálohování dat, ale tato akce zaujala o 20% více času než obvykle. Výjimečné události. Mají okamžitý vliv, a je to červená barva ukazující, že něco je špatně. Obvykle po nastání takové události se hned registruje Incident. Příkladem může být to, že zálohování dat vůbec nebylo dokončeno kvůli poruchám v systému. Tady je důležité rozlišovat co je informativní, co je varující a co je výjimečná událost, protože v některých případech i informativní událost může mít výjimečný a okamžitý vliv. Proces Řízení Případů (Incident Management Process). Případem (Incident) je neplánované přerušení IT služby anebo snížení kvality teto služby. Selhání konfiguračního prvku, které ještě nemá vliv na poskytovanou službu je také případem. Pro lepší pochopení tohoto procesu tady představím diagram (viz Obrázek Proces Řízení Případů - Incident management process ), který ukazuje všechny aktivity v pořadí v jakém by měli správně být a pár pojmů tady také vysvětlím. Z hlediska teto práce je totiž zajímavé vědět co je Hierarchická a Funkční Eskalace Případu. Když je potřeba zahájit Funkční Eskalaci, to znamená, že agent Service Desku, který zaznamenal a kategorizoval po počáteční analýze pochopil, že nemá na vyřešení tohoto Případu prostředky a příslušné znalosti, a proto tento Případ předá řešícímu týmu 2. nebo 3. úrovně. Příkladem tady akorát může být předání Případu pro vyřešení OBS, jelikož OBS je v podstatě řešitel 2. úrovně. Hierarchickou Eskalaci je potřeba zahájit třeba tehdy, kdy se nemůže vůbec najít příslušný proces podle kterého se má postupovat dále nebo tento Případ potřebuje dohled ze strany Vedení. Základní koncepce Řízení Případů: obnovit dodání Služeb jakmile to půjde, nejlépe hned; dostat uživatele zpět do práce také nejlépe hned; řídit Případ od identifikaci do uzavření; a to všechno musí odpovídat sjednaným SLA. 12

17 Proces Řízení Případů - Incident management process 13

18 Proces Splnění Požadavků (Request Fulfillment Process). Tady požadavkem na službu je požadavek od uživatele na informaci, poradu, standardní změnu anebo na přístup k IT službě. Zajímavé je to, že ITIL Service Operation Book nedává definici cíle pro tento proces, to ale neznamená, že cíl tady není. Cílem můžeme nazvat Vyřízení všech požadavků na služby co nejefektivněji a to v rámcích stanovených pravidel a cílů pro služby [6]. Proces managementu přístupových práv (Access Management Process) nedílnou součásti procesu Splnění Požadavků, která zajišťuje to, že jenom příslušná skupina uživatelů bude mít přístup k příslušným službám podle stanovených pravidel a procesů. Proces Řízení Problémů (Problem Management Process). Problém je příčinou jednoho nebo více Případů. Příčina na moment vytvoření záznamu není obvykle známá, a Proces Řízení Problémů je zodpovědný za další vyšetření. Cílem tohoto procesu je v podstatě najít příčinu vyskytujících se Problémů, najít pro ty Problémy dobré řešení, tak aby se již více nevyskytovali anebo alespoň eliminovat důsledky, které ty Problémy přináší. Tady jde o pro-aktivní chování, které by udělalo celý systém poskytovaných IT služeb pro uživatele a zákazníky spolehlivější a stabilnější. Existují také takové aktivity, které se nedá zařadit ani do jednoho z výše popsaných procesů a takových aktivit je hodně, proto je tady nebudu popisovat všechny, jenom uvedu pár příkladů: monitorování a kontrola, řízení infrastruktur a jiné. Existuje 4 klíčových funkcí které se zařazují do cyklu Service Operation, jsou to: Funkce Service Desku. Service Desk je jediným "styčným bodem" (Single Point of Contact) mezi dodavatelem a koncovými uživateli těchto služeb; Funkce Technického managementu - Technical Management Function; Funkce Managementu Aplikací - Application Management Function; Funkce managementu IT Provozu - IT Operations Management Function. Nejvíce z těchto funkcí nás samozřejmě zajímá funkce Service Desku a pro ní jsem věnovala další část teto práci. 14

19 3. Registrace Případu. Celý proces začíná registraci Případu neboli, jak je obvykle nazývají agenti Service Desku, ticketu v systému. Za prvé, musí se agent přihlásit do systému, který se běžně mezi agenty nazývá Remedy. Na to aby se přihlásil použije agent své údaje, které se nazývají Global Pass credentials. Tyto přihlašovací údaje jsou propojené s dalšími systémy, které agent používá během práce, proto jsou Globální. Remedy je dostupné jenom přes připojení VPN a při tom, musí se používat zařízení, které je přidáno k potřebné doméně, a vůbec je mu připojení povoleno. Jiná možnost připojení je přímo v kanceláři CSC a to přes kabel, protože CSC WiFi připojení neschvaluje, jelikož podle CSC není bezpečné. Odkaz, který používají pracovníci Service Desku je Na Obrázku č.1 vidíte přihlašovací bránu pro Remedy. Obrázek 1: Přihlašovací brána Po tom, co je agent přihlášen do Remedy, uvidí regulérní agenti stránku, na které jich zajímají jenom 2 odkazy, a to na Knowledge Management Console a Incident Management Console. Tady se dá říct, že obyčejné agenti máji přístup jenom k těmto odkazům, jiné možnosti se jim prostě neotevřou, a to je opodstatněno tím, že ke své práci je ani nepotřebuji. Jelikož nás v tuto chvíli zajímá jenom registrace případu, přešla jsem 15

20 přímo ke stránce Incident Management, část které vidíte na Obrázku č. 2 Obrázek 2: stránka Incident Management Po otevření ovládacího panelu Incident Management pro registraci nového případu, musí agent otevřít stránku New Incident. Po kliknutí na New Incident se objeví nové okénko, ve kterém se máji vyplnit jméno a příjmení koncového uživatele, který případ nahlásil. Po vyplnění těchto údajů se klikne na Search (viz Obrázek č.3) 16

21 Obrázek 3: Hledaní uživatele V případě, že existuje jediný uživatel s takovým jménem, detaily profilu tohoto uživatele se vyplní automaticky, v opačném případě objeví se okénko, které vidíte na Obrázku č. 4. A tam bude muset agent vybrat správného uživatelé podle dalších detailu, které mu v tom pomohou. Například, telefonní číslo nebo druhé jméno uživatelé. 17

22 Obrázek 4: Vyběr správného uživatele Po té, co byl vybrán správný profil uživatele, vyplní se jeho údaje, a agent může postupovat dál kontrolou těchto údajů. Spolu s detaily uživatele se objeví i číslo případu, které systém automatický tomuto případu přidělí. Toto číslo se nazývá Incident Number/ID nebo ticket number, a začíná se jako EU-INC... (viz Obrázek č.5). V případě, že údaje uživatele jsou zastaralé a nejsou aktuální, bude muset je agent pozměnit a svou změnu uložit. To, jestli jsou tyto údaje aktuální nebo nejsou, je velice důležité zejména v incidentech týkajících se OBS z toho důvodu, že když se bude muset do místa, kde je něco přímo fyzický rozbité nebo nefunkční, poslat technik, bude muset OBS přesně vědět kam se technik posílá a musí se tomu technikovi poskytnout mapy ukazující sítovou topologií budov, kde se koncový uživatel nachází. Znalost takové topologie totiž práci a odstranění poruch usnadňuje a urychluje. Toto je první důvod, proč tyto údaje aktualizovat. Druhý ale neméně důležitý důvod je v tom, že pro účely kontroly a reportingu chce CSC uchovávat i ty adresy, které již nejsou aktuální třeba proto, že zákazník tam již žádnou kancelář nemá. Na druhou stranu OBS pokaždé svou bázi aktualizuje a má tam zaregistrované jenom současné lokace. Ke každé lokaci v systému OBS je přiděleno svoje ID a po předání případu OBS, se tento případ uloží do jejich 18

23 databáze tak, aby se dalo jeho spojit s nějakou existující lokaci, což v případě neaktuální lokace nebude možné a ticket se vůbec nepodaří přemostit. Takže když nejsou některé z údajů uživatele aktuální, stiskne agent tlačítko Modify. Obrázek 5: Vygenerované Incident ID Na stránce Modify se obvykle objeví všechna kontaktní údaje uživatelé. Při vytváření nového profilu uživatele nám Remedy prostě nedovolí ho uložit, jestliže nějaká základní informace jako například telefonní číslo nebo ová adresa tam chybí (viz Obrázek č.6). 19

24 Obrázek 6: Stránka Modify Po tom, co jsou data zkontrolována a je vybrán správný uživatel, musí agent vyplnit další nezbytné informace, jako popis problému, kategorizace případu ad. Jestliže problém, který má uživatel, leží v nějaké kategorie, například problém s IP telefonii, což určitě má na starosti OBS, muže agent vybrat z nabídky Templatu vhodný pro vyplnění. 20

25 Obrázek 7: Tlačítko Select Template Jakmile stiskne agent Select Template tlačítko, objeví se mu okénko s různými šablony. A pro OBS případy jednou z nejčastěji používaných šablon může být OBS Avaya Telephony Template. Pro náhled si tuto šablonu vybereme a podíváme se, co všechno tato šablona potřebuje po agentovi vyplnit a co vyplní sama. 21

26 Obrázek 8: Výběr šablony Po výběru šablony se automaticky nám předvyplní téměř všechno v horní části stránky (viz Obrázek 9). Obrázek 9: Předvyplněná pole Poličko Summary by mělo byt potom agentem pozměněno tak, aby obsahovalo specifičtější krátký popis problému. Dále Status ticketu je vždy při generovaní případu a vyplněni šablony bude ve status Assigned, což se během vyřešení případu mění. O tom, jaké mohou byt statusy ticketu si řekneme později. Polička Technical Severity, Impact, Urgency, Business Criticality a Priority nás v tuto chvíli až tak nezajímají a to, jak se 22

27 určuji, muže být předmětem dlouhé diskuze. Notes bude obsahovat šablonu, kterou musí agent povinně vyplnit. Pro otevření okénka Notes, stiskne se čtvereček vedle tohoto polička. Na Obrázku 10 je vidět jak vypadají Notes. Obrázek 10: Notes - poznámky Po vyplnění potřebných údajů se stiskne Ok a přejde se do dalších lišt, které se mají vyplnit nebo zkontrolovat. Ze všech lišt, které se máji zkontrolovat nebo vyplnit, nás zajímají jenom ty, co jsou ukázané na obrázcích číslo 11 a 12. Obrázek č.11 nám ukazuje lištu, která se nazývá Work Info. Tato lišta obsahuje veškerou informaci o to, co se během vyřešení případu vůbec dělalo. Kdy byl koncový uživatel kontaktován, jaké informace se od něho ten, kdo ho kontaktoval, dozvěděl, jaký řešící tým kdy tento případ pro vyšetření převzal, proč ho převzal, co se po vyšetření dozvěděl a proč ho předal dál anebo jak ho vyřešil tohle-to všechno musí Work Info obsahovat. Obdobný systém má i OBS, proto po tom, co se případ předá nebo přemostí se do OBS, začíná se každá změna, přidaný komentář nebo poznámka automatický odrážet v Remedy, což je pro sledování průběhu vyřešení případu nezbytné. Kromě toho, že se odrážejí v Remedy poznámky, také se mění stav ticketu v závislosti na tom, jaký stav mu přidělí v systému OBS. Problém, který se tady řeší je akorát v tom, že se někdy kvůli nějakým změnám na straně OBS, může se ticket přestat obnovovat. Přestane se 23

28 přenášet Work Info a přestane se obnovovat stav ticketu, což není dobře protože ticketů, které jsou přidělené OBS je veliké množství a sledování každého případu zvlášť není možné, jelikož to zabírá hodně času a tím i peněz. Jak už bylo řečeno na začátku, otevření ticketu v obou systémech a jejich následné porovnání může někdy vzít až kolem minut. Obrázek 11: Lišta Work Info Obrázek 12: Lišta Assignment Obrázek č.12 nám ukazuje lištu, kde se můžeme dozvědět, kdo se současně vyřešením anebo zkoumáním případu zabývá. V případě, že se po zaregistrování případ pošle na OBS, musí se nejprve předat týmu Service Desk Prague OBS Focal, který 24

29 zkontroluje zdá se případ týká OBS a jestli všechny potřebné informace jsou uvedené v ticketu. Stává se totiž tak, že agent, který přijal hovor, zaregistruje ticket a pošle nám ho s naprosto nepochopitelným popisem problému nebo tam neukáže jak vůbec zkoušel uživateli pomoct, anebo tam nedoplní nezbytné pro vyřešení případu informace. Po zkontrolování se ticket bud pošle dál přímo na OBS nebo se vrátí zpátky pro doplnění potřebných údajů. Dělá se to tak proto, že po tom, co se ticket pošlé přímo na OBS, vytvoří se v jejich systému jedinečné číslo tohoto ticketu a vytvoří se takzvaný můstek, který, jak už bylo řečeno dřív, automatický předává zprávy ze systému OBS do Remedy. Ze strany Service Desku CSC se může ten ticket aktualizovat novými detaily, ale nesmí se při tom měnit tým, ke kterému je tento ticket přidělen, jelikož to ten můstek hned zruší a někdo potom bude muset ten ticket převzat do vlastní fronty a sloužit tak pro něho živým můstkem tak, že ho bude každé 2 hodiny otevírat v obou systémech a změny v jednom systému přenášet do jiného. Tady vstává otázka: Proč se nesmí ten ticket prostě znovu přemostit do systému OBS? Odpověď je jednoduchá. Jelikož se ticket znovu přemostí do OBS, vytvoří se v jejich systému nový případ, což jednak způsobí redundanci dat a zbourá to statistické výsledky, a jednak po každém takovém vytvoření případu bude muset zákazník anebo odběratel služeb zaplatit zvlášť za každý případ i když se faktický týká jenom jednoho koncového uživatele. Takové příhody zákazník rád nemá a proto se mají kontrolovat. Proto byl vytvořen tým OBS Focal, který se snaží to hlídat a pokud je to možné posílat přímo na OBS takové tickety, které mají veškeré potřebné a nepotřebné informace tak, aby se nevraceli zpátky a nemuselo se žádat od agentu po jejich doplnění. Je to tím, že agenty Service Desku pro získání dalších informací většinou mají kontaktovat koncového uživatele, což může zabrat hodně času a při pracovní zátěži, kterou mají na Service Desku, není snadné ten čas najít a vůbec na to nezapomenout, což zase přidává práci týmu OBS Focal, protože členové týmu agentům mají pokaždé připomínat, že mají potřebné informace získat co nejrychleji. 4. Stavy otevřených případů. Po tom, co se vytvoří nový případ a přiřadí se konkretnímu týmu, co má ho vyřešit anebo poslat ho dal, musí se uložit a po tom, co se uloží, objeví se tento případ neboli ticket v určité frontě případů. Pro uložení vyplněného případu musí agent jednoduše stisknout tlačítko Save. Hned po uložení ticketu přidá se mu status Assigned, což v podstatě znamená, že je ticket přidělen konkrétnímu týmu nebo jednotlivci v týmu, a musí se na něm hned začít pracovat. Pro lepší pochopení je níže popsáno co znamenají 25

30 jednotlivé stavy neboli Status ticketů. New : Při vytvoření nového případu bude jeho status automatický ve stavu New dokud nebudou všechna povinná polička doplněna potřebnou informací a nebude případ uložen. Po uložení případu se změní jeho stav na Assigned. Assigned : Případ byl přidělen konkrétnímu týmu nebo jednotlivci pro vyřešení, ale nebylo ještě potvrzeno jeho přijetí. In Progress : Přijetí případu bylo potvrzeno a odpovědný tým začal na jeho vyřešení pracovat. Ve skutečnosti to funguje tak, že po tom, co se případ přidělí týmu počítá se za přijatý a SLA hodinky začínají cvakat. Pending : Práce nad případem byla dočasně pozastavená kvůli nějakému důvodu, kterým často bývá zdržení ze strany koncového uživatelé. Takové opodstatněné pozastavení práce také pozastavuje hodinky počítající SLA. Resolved : Služba byla znovu vrácená a to bud s řešením permanentním nebo takovým, které funguje trošku jinak ale přivede ke stejným výsledkům (workaround). Tady je potřeba aby řešení problému bylo potvrzeno ze strany zákazníka. Closed : Zákazník nebo koncový uživatel potvrdil řešení problému a od doby co byl případ převeden do stavu Resolved uteklo 5 dni. Po 5 dnech bude případ automatický systémem převeden do stavu Closed. Zákazník nebo koncový uživatel totiž má 5 dni na to aby se znovu ozval Servis Desku a oznámil, že se problém vrátil anebo poskytnuté řešení mu nefunguje. 5. Jak najít frontu případů konkrétního týmu. Pro účely teto práce Vám ukážu jak se hledá fronta pro konkretní Resolver Group, v tomto případe to bude Service Desk-Prague OBS Focal. Prvním krokem bude otevřeni okénka Search Incident z Incident management Console, které vypadá stejně jako okénko New Incident až na to, ze poličko Incident Number není vyplněno, a muže se tam zadat a najít konkretní číslo incidentu. Na to abychom mohli najít celou frontu ticketu potřebujeme přejít v Advanced search režim. Jakmile to uděláme, objeví se nám v dolní častí stránky Search Line na které můžeme nadefinovat dotaz (String), který nám najde co potřebujeme. Dá se říct, ze dotazovací jazyk v tomto případě docela podobny části SQL dotazu, až na to ze tady uživatel nemusí vědět strukturu tabulek a vůbec databáze. Tady se všechno může primo naklikat. Konečný 26

31 řetězec, který se používá pro hledaní ticketu v naši frontě vypadá takto: 'Support Company*' = "CSC" AND 'Support Organization*' = "Service Desk" AND 'Assigned Group*+' = "Service Desk-Prague OBS Focal" AND 'Status*' < "Resolved" Udělá se tento dotaz tak, ze se najde na stránce anebo na konkretní liště stránky nadpis Support Company a jednoduše se na něho klikne, což způsobí objeveni tohoto atributu v Search line ve správném formátu. Jestliže potřebné kriterium nemůžete najít, dá se použit rozbalovací lišty Fields, která nabídne všechny atributy, které se mají nadefinovat. Dále uvedeme, ze by Support Company melo rovnat CSC a tak pokračujeme dal, než vymezíme všechny kriteria hledaní. Kus řetezce 'Status*' < "Resolved" znamená, ze se najdou všechny tickety ve statusu Assigned, In Progress a Pending. Dá se říct, ze na to abychom našli všechny tickety v potřebné frontě, může postačit hledací řetězec nadefinovaný takto: 'Assigned Group*+' = "Service Desk-Prague OBS Focal" AND 'Status*' < "Resolved" bez kusu 'Support Company*' = "CSC" AND 'Support Organization*' = "Service Desk" tohle-to ale čas hledaní prodlužuje tak, že během něho může Internet Explorer zkrachovat. Po tom, co jsme dotaz nadefinovali, v levém horním rohu stiskneme tlačítko Search. Obrázek 13: Hledaní fronty týmu 27

32 Tady vidíte jak vypadá fronta pro Service Desk-Prague OBS Focal, o kterou se stará můj tým. Obrázek 14: Fronta OBS Focal Pro bezpečnostní účely data, která patři uživatelům budou zamalována barvou. Tickety, které jsou v statusu Assigned musí být ověřené a bud se pošlou dal anebo se vrátí zpátky agentovi. Tickety, které jsou ve stavu Pending, většinou jsou akorát ty, které ze samého začátku nemohli z nějakého důvodu být k OBS přemostěné a teď stojí v osobní frontě členů týmu a musejí se obnovovat ručně. 28

33 III. Řešení problému. Cílem této práce je navrhnout řešení, které pomůže pracovníkům týmu OBS Focal rychle a jednoduše najít tickety, které již jsou uzavřené na straně OBS a hromadným způsobem je uzavřít na straně Service Desku v Remedy. Nejlepším řešením pro tento problém by bylo odstranění původu problému, a to odladění samotného můstku mezi dvěma systémy. Toto by ale potřebovalo vědět jak oba tyto systémy fungují, jak jsou naprogramované a vůbec celou jejich strukturu. V daném případě jak už bylo řečeno dřív, systém který používá CSC patří třetí straně, a to společnosti BMC Software Inc., která tento systém vyvinula. Dá se říct, že komplexita obou systému není jednoduchá a zkoumání jejich architektury zaujme nejen hodně času ale také k tomu potřeba sehnat povolení a přístup. Jaké jádro pro svůj systém používá OBS nebylo docela jasné, jelikož jak se zdálo ze slov pracovníků Help Desku OBS, se kterými jsem měla možnost provést kratký rozhovor, používají systém, který se nazývá Clarify, a ten také OBS nepatří. Na druhou stranu, my jakožto třetí strana máme přístup k jejich systému přes webové rozhrání, které se nazývá My Service Space a tady je odkaz pro veřejnost: servicespace.orange-business.com/mssloginform/public/welcome-action.do Jak jsem pochopila z dopisování s týmem podporujícím MSS (zkrátka od My Service Space) tento produkt, byl vyroben speciálně pro OBS a současně se postupně přechází od starého systému k novému, a tým MSS přebírá starost o systém od vývojářů Clarify. Po rozhovoru s pracovníky CSC, které tady pracovali ještě před tím než společnost OBS přešla k novému systému, ticketů které selhali bylo mnohém víc než teď, což poukazuje na to, že nový systém je v nějakém smyslu lepší než starý. Po tom, co jsem se dozvěděla o těchto detailech, ukázalo se že vedení Help Desku OBS o problému s můstkem ví, a současně ze strany vývojářů začala práce nad jeho odstraněním. Avšak se neví kdy bude tento problém plně odstraněn, a tak se má navrhnout dočasné řešení s použitím funkcionality a prostředků obou systémů dostupných pro obyčejné pracovníky Service Desku CSC. Metoda hledání ticketů k uzavření. Před tím než navrhnout technickou stránku řešení je potřeba určit metodu podle které se budou tickety hledat. V MSS existuje možnost najít všechny tickety, které jsou již ve stavu Closed, ale 29

34 jenom když zadáme nějaký časový interval ve kterém se mají takové tickety hledat. Z tohoto reportu by se dalo vyčlenit jediný bod spojení ticketů v systémech OBS a CSC, a to Vendor Ticket Number číslo ticketu dodavatelé. Vendor Ticket Number na straně OBS obvykle představuje sedmimístné číslo, kdežto na straně CSC toto číslo bude ve formátu A::EQUANT::XXXXXXX, kde XXXXXXX představuje číslo ticketu ze strany OBS. V Remedy je toto číslo zapsáno v takovém formátu kvůli tomu, že OBS není jediným dodavatelem služeb zákazníku, existuji ještě takové dodavatelé jako Getronics. A::EQUANT:: je svérázné automatické označení ticketů předaných OBS. Nicméně po přidání označení A::EQUANT:: před každým číslem ticketu získaného z reportu z systému MSS, dalo by se vytvořit hledací string, který by vypadal přibližně tak: 'Support Company*' = "Orange Business Services" AND 'Support Organization*' = "Vendor" AND 'Assigned Group*+' = "EUR-OBS Voice and Data" AND 'Vendor Ticket Number'="A::EQUANT::XXXXXXX" OR 'Vendor Ticket Number'="A::EQUANT::YYYYYYY" OR... atd dokud nebudou vyjmenované všechny tickety, které se mají najít. Jenomže jednak, jak se ukázalo při experimentálním pokusu, v Remedy pomoci takto definovaného stringu hledat se nedá, Remedy totiž ukazuje varování o tom, že Vendor Ticket Number není nadefinované jako pole podle kterého se může hledat. Jednak, i když by se dalo pomoci tohoto řetězce tyto tickety najít, značná část těchto ticketů nehledě na problém s můstkem už budou uzavřené, a opakovaně je uzavřít Remedy také nedá. Takto nakonec vychází, že jediný kriterium, podle kterého se dá hromadně najít tickety k uzavření, je Incident ID přidělené ticketům systémem CSC a musejí se hned najít tickety které jsou problémem bezprostředně postižené. Reportingový systém Remedy umožňuje najít všechny tickety předané v systému formálně vytvořenému týmu s názvem EUR-OBS Voice and Data. Samotné uložení ticketu ve frontě tohoto týmu, jak už bylo řečeno dřív, spouští vytvoření můstku mezi MSS a Remedy pro tento ticket. Takto získaný seznam ticketů, bude obsahovat tickety na kterých se současně pracuje a tickety, které již jsou faktický vyřešené. Jelikož se v MSS dá vytvořit report obsahující data tykající se jak ticketů ve stavu Closed, tak i ticketů ve stavech znamenajících, že se na nich současně pracuje, vstává tady otázka jak reporty z obou systému lépe porovnávat a jaký report lépe v MSS vytvořit. Pokusím se tady obě varianty probrat a vybrat z nich nejlepší. Předběžně řeknu, že nezávisle na tom jaká bude na konci vybrána varianta, bude report z MSS obsahovat, mimo jiných poli, taková pole jako Incident ID (pro větší jasnost toto pole označím jako OBS Incident ID ) a Customer Reference (toto je vlastně Incident ID, které přidělilo tomuto ticketu Remedy). Report 30

35 vytvořený v Remedy bude určitě obsahovat pole Incident ID (CSC Incident ID) a Vendor Ticket Number (OBS Incident ID ve formátu A::EQUANT::XXXXXXX ). Varianta s tickety ve stavu Closed. Předpokládejme, že vytvořili jsme report obsahující všechny tickety ve stavu Closed ze systému MSS. Máme také vytvořený report v Remedy obsahující seznam ticketů současně předaných EUR-OBS Voice and Data. Co bude výsledkem porovnání těchto ticketů? V ideálním stavu by ani jedna položka těchto seznamu neměla být ve shodě, protože by uzavřené tickety OBS v seznamu otevřených ticketů CSC neměli vyskytovat. Jelikož současný stav ideální není, ty shody přece najdeme a Incident ID těchto shodných ticketů se musí poznamenat a vytvoří se z nich potom hledací řetězec pro hromadné uzavření ticketů. Varianta s tickety v jiném stavu než Closed. Teď předpokládejme, že máme report obsahující všechny tickety z určitého časového intervalu ve stavu jiném než Closed a report z Remedy. Tady by v ideálním stavu všechny tickety měli být v plné shodě beze zbytku. Jelikož tento stav ideální není, zůstanou v seznamu vytvořeném v Remedy tickety, které nebudou mít vůbec žádný protějšek. Ticketů v seznamu z Remedy bude prostě víc, a ty tickety které nemají žádnou shodu se mají poznamenat a vytvoří se z nich hledací řetězec pro hromadní uzavření ticketů. Porovnání způsobu. Pro porovnaní těchto způsobů musím tady vysvětlit některé zvláštnosti nebo spíš problémy se kterými se setkáváme při předaní ticketů OBS. Když uděláme Assign ticketu na OBS, tak ne vždycky se podaří ticket přemostit poprvé, a jak už jsem řekla dřív, vždy to zkoušíme udělat podruhé za 5 nebo 10 minut po prvnímu pokusu, a to jestli ovšem se ten ticket ukazuje ve frontě failed to bridge tickets. Jakým způsobem se pozná jestli není ticket přemostěn? Pozná se to podle pole Vendor Ticket Number, které bud bude prázdné nebo místo obvyklého formátu ukazuje dlouhé číslo, které je v podstatě TimeStamp. Někdy ale může nastat situace, že se ten ticket ve skutečnosti přemostí a na straně OBS se vytvoří jejich Incident ID, při tom se ale ten Incident ID neukáže v našem systému. Jelikož my nevíme jestli se ten incident na straně 31

36 OBS vytvořil nebo ne, přemostíme ten ticket podruhé, a to se nám podaří ticket z fronty failed to bridge zmizí, což bude znamenat, že konečně číslo Vendor Ticket Number je ve správném formátu a podařilo se ho vůbec získat, jenomže je tu háček, protože se nám ho podařilo získat podruhé, vytvořilo se v systému OBS druhé Incident ID ke stejnému ticketu. OBS takové věci nemá rada, a Incident ID, které se vytvořilo jako poslední udělá jako Child Ticket pro to, co se vytvořilo dřív, což způsobí to, že ticket v Remedy přejde do stavu Pending a k tomu, bude mít špatné Vendor Ticket Number, při tom v systému OBS bude hodně duplikátů. Co taková situace způsobí při porovnání ticketů? Při porovnání s tickety v jiném stavu než Closed, a v případě, že budeme porovnávat Incident ID od OBS a Vendor Ticket Number v Remedy, zůstanou nám bez protějšku tickety, které ve skutečnosti nejsou ještě uzavřené, ale my je nebudeme moci vyloučit, protože bychom měli projít vytvořeným seznamem ručně, což pro nás není přijatelné, a proto k tomu budeme muset mezi sebou ještě porovnat Incident ID od Remedy a Customer Reference uložené v MSS. Při tom ale stejně v tom nebudeme mít jasno a pořád to budeme muset probírat, protože uzavřít případ, který ještě nebyl vyřešen pro nás není přijatelně. V případě, že budeme porovnávat s tickety ve stavu Closed, jakékoliv spojení mezi čísly ticketů bude přijato, jelikož víme, že jsou definitivně uzavřené. Takovým způsobem vychází, že nejlépe porovnávat podle první varianty. Teď přejdeme k jednotlivým krokům, které je potřeba udělat pro uzavření těch ticketů. Vytvoření reportu obsahujícího všechny tickety předané OBS. První krokem pro vytvoření reportu obsahujícího všechny tickety na daný okamžik předané OBS je najít všechny tickety, které jsou v stavu Assigned nebo Pending ve frontě nominální skupiny pro OBS a to EUR-OBS Voice and Data. Jak se to může udělat bylo popsané dřív v bodě Jak najít frontu případů konkrétního týmu. Tady se ale má brát do úvahy to, že při hledaní všech ticketů pro OBS, bude systém také do výsledků zahrnovat ty tickety, které byli zaregistrované v Service Desku rozmístěném v Monrealu a obsluhujícím uživatele z Německé pobočky zákazníka, ke které my jakožto řešící tým nemáme vztah a proto musíme Německé tickety ze seznamu vyloučit. Výsledný hledací řetězec bude vypadat tak: 'Support Company*' = "Orange Business Services" AND 'Support Organization*' = "Vendor" AND 'Assigned Group*+' = "EUR-OBS Voice and Data" AND 'Status*' < "Resolved" AND 'Company*+'!= "ZFS Germany" 32

37 Obrázek 15: Seznam ticketu předaných OBS Po tom co najdeme všechny tickety musíme je všechny zvýraznit a na to se zmáčkne tlačítko Select all. Až budeme mít je zvýrazněné stiskne se tlačítko Report a objeví se nám okénko ve kterém si můžeme vybrat bud vytvoření vlastní kostry pro report nebo vybrat z existující nabídky. Jelikož takového reportu, který chceme ještě v nabídce neexistuje, vytvoříme si nový, který nazveme OBS test. Pro jeho vytvoření vybereme volbu Create. Zajímavé na teto stránce je to, že i když existuje lišta ve které se má vybrat typ reportu, je v ní jenom jeden typ, a to AR System jak je vidět na Obrázku

38 Obrázek 16: Vytvoření reportu v AR Systému Jakmile stiskneme Create, objeví se nám okno, ve kterém musíme vyplnit potřebná pole. V poli Report Name si podle přání napíšeme název reportu, což pro nás jak už jsem řekla dřív, bude OBS test. Polička Server Name a Form Name budou automatický předvyplněná a my nebudeme je měnit, jelikož na to není potřeba. Jinak, Server Name je server na kterém se nachází forma která ze které se má udělat report. Toto pole je nepovinné. V případě, že nebude specifikováno, automatický se předpokládá, že forma je na současném serveru. Form Name je název formy ze které se budou brát data pro report. Report Format - formát ve kterém bude report generován. Toto je implicitní formát pro tento report, který ale může být přepsán v průběhu generování reportu v závislosti na tom, jak bude definován cílový bod generování. Z nabídky Formátů si vybereme typ Column, protože chceme aby naše data byla zobrazována ve sloupcích. Locale je místo uložení reportu, které také nezávazné pro vyplnění. Report Set - soustava reportů se kterým 34

39 chceme tento report spojit. Toto pole také nebudeme vyplňovat jelikož současně s žádnou soustavou tento report spojovat nepotřebujeme. Obrázek 17: Výplnění formátu a obshahu reportu Jakmile budeme mít vyplněnou horní část údajů o reportu, přejdeme do lišty Fields, ve které si vybereme jaká pole chceme vidět v našem reportu. Tato pole můžeme podle sve volby volně přidávat nebo naopak odebírat. Jelikož jsme si vybrali sloupcově orientovaný report, můžeme si určovat pořadí ve kterém chceme ty sloupce vidět. K tomu také můžeme určit i šířku těchto sloupců. Poli které si můžeme do reportu přidat je velice hodně a proto nebudu je všechny tady vyjmenovávat, jelikož některé z nich pro naše účely se vůbec nehodí a některé se ani nebudou moci vyplnit. Z nabídky těchto poli považují za nutné do reportu zahrnout taková pole jako Vendor Ticket Number, Incident ID, Status, SLA Responded, Reported to Vendor Date a Company. Zkoušela jsem do reportu také přidávat pole Vendor Responded Date, Site ID a jiné pole ukazující především různé časové údaje, ukázalo se ale, že tato pole v konečném reportu ukazují v čistě číselném formátu, který zaujme hodně času pro převod do čitelného a člověkem pochopitelného formátu. Pole Vendor Ticket Number v reportu potřebujeme kvůli porovnání s Číslem Případu ze strany OBS. Pole Incident ID potřebujeme pro vytvoření výsledného řetězce podle kterého se budou hledat tickety k uzavření. Pole Status, Reported to Vendor Date a Company potřebujeme pro analytické účely. My totiž nevíme, co způsobuje přerušení předávání dat, a můžeme začít alespoň analýzou toho, v jakém stavu většinou toto porušení můstku nastává, jaké lokace jsou tím nejvíc postižené a kdy byl každý ticket 35

40 předán OBS. Pokus analyzovat lokaci je odůvodněn tím, že často při předání ticketu OBS se vyskytuje situace, kdy hned vidíme, že ticket nebyl přemostěn a důvodem je to, že systém OBS některé označení lokaci nebo Site ID jako platnou lokaci nepřijme. Může se stát, že jsou tyto věci mezi sebou spojené. Další lišta která nás zajímá je Sorting, ve které si můžeme určit pořadí podle kterého budou řádky v našem reportu uspořádané. Doporučuji je seřadit podle datu, kdy byl ticket předán a to v stoupajícím pořadí, jelikož z největší pravděpodobnosti tickety které selhali být obnovovány budou v takovém pořadí na začátku seznamu. Obrázek 18: Výběr seřazení Ostatní nejsou pro nás zajímavé, jelikož v nich nemůžeme pro sebe něco použitelného nadefinovat. Pro další informaci o dalších lištách viz Příloha 1. Pro uložení vytvořeného reportu stiskneme tlačítko Save v levém horním rohu a zase přejdeme do stránky, kde se dá v seznamu reportů po obnovení najít náš nový report a podle něho již dostat konkretní data se kterými budeme dál pracovat. Tady bych chtěla poznamenat, že se tento report má vytvořit jenom jednou, dále bude ten samý report přístupný pro všechny členy týmu OBS Focal. 36

41 Obrázek 19: Save Obrázek 20: Run report Po tom, co svůj report najdeme v seznamu reportů, budeme si muset vybrat kam chceme ten report nahrát. Máme volby si ho nahrát na obrazovku a do souboru. Jelikož s daty budeme potom ještě pracovat, nahrajeme report do souboru. Dál nás zajímá v jakém formátu ten report chceme. Remedy AR systém totiž je umí generovat v čtyřech formátech a to jsou:.csv tento formát se dá otevřít jako obyčejný Excel soubor. Dá se ho také otevřít v Notepadu, a kdybych pro řešení tohoto problému psala celý malý program tak bych ho otevírala akorát tam, jak se ale ukáže později, budeme muset pro řešení problému použít Excel..rep tento formát se dá otevřít také v Notepadu a také se dá ho v přehlednějším 37

42 stavu prohlížet v obyčejném Internet prohlížeči..arx - tento formát se otevírá stejným způsobem jako předchozí. a.xml formát xml je velice dobrá věc, která se může otevřít v hodně různých programech včetně Wordu, Excelu, Accesu a hodně jiných. Pro účely teto práce si vybereme formát.csv, jelikož jak už jsem řekla pro vyřešení problému použijeme funkcí Excelu. Odůvodněním tady je to, že z bezpečnostních důvodů není možné pracovníkům CSC bez odpovídajícího povolení instalovat žádné nové aplikace. Ovšem že by se dalo pro pracovní účely vytvořený program nainstalovat, ale sehnaní na to povolení zaujme více času, než by se chtělo. Při tom také každý ze členů OBS Focal týmu by měl svému vedoucímu vysvětlit proč ten program potřebuje. Napsaní programu, který by tento problém řešil automaticky zaujme možná více času a opravdu řečeno na to postačí funkcionality, kterou má Microsoft Excel 2010 před nedávném nainstalovaný na každý počítač Service Desku. Dalším důvodem pro výběr k řešení Excele je to, že jediný formám ve kterém se dá vygenerovat report v systému MSS je.xls. Takže potom, co si vybereme formát.csv také si vybereme Character Encoding, což doporučuji Windows-1252, které se používá defaultně v produktech Microsoft. Teď, když máme všechno nastavené zbývá kliknout Run a za pár vteřin budeme mít hotový report. 38

43 Vytvoření reportu v MSS. Na začátku se do systému přihlásíme. Obrázek 21: Přihlašovací stránka Potom uvidíme úvodní stránku a tam přejdeme do incident dashboard. 39

44 Obrázek 22: odkaz do incident dashboard Na teto stránce klikneme na tlačítko generate report a přejdeme do tvorby potřebného reportu. Obrázek 23: generate report Na stránce Reporting, si vymezíme časový úsek na kterém chceme zkontrolovat existenci neuzavřených na straně CSC tucketů. Doporučuji tady před tím než to zadávat podívat se do reportu vytvořeného v Remedy, tam totiž uvidíte, jaký je nejstarší ticket, který se až dosud řeší. 40

45 Obrázek 24: stránka Reporting, výběr časového úseku Po tom, co zadáme časový úsek, nadefinujeme jaké chceme v reportu vidět sloupce a v jakém pořádku. Obrázek 24: definice sloupců v reportu Všechny sloupce které vidíte vybrané na Obrázku 24 doporučuji do reportu přidat. Z již známých důvodů tam chceme Incident ID, Customer Reference a Country, Site ID a Site Address potřebujeme protože je nemůžeme uvidět v reportu v Remedy a Case Type 41

46 potřebujeme pro vyloučení jiných typu Případů než Incident. Obrázek 25: Kritéria hledání Na stránce Filter Criteria si určíme kritéria podle kterých chceme hledat. Jelikož náš Service Desk nepodporuje takové země jako Německo, SSA a Rakousko, musíme je z hledání vyloučit. Potom jak už jsem řekla budeme hledat jenom tickety typu Incident a také chceme aby Customer Reference v našem reportu začínalo jako EU-INC, protože OBS má hodně různých označení pro různé typy incidentů, ale je to jejich interní věc, pro nás je důležité aby Customer Reference pro nás začínalo jako EU-INC. Jakmile budeme všechny kritéria mít zadané, klikneme OK a generate report. Po chvíli budeme mít druhý report a můžeme začít s jejich porovnání v Excelu. Porovnání seznamu v Excel a následné uzavření ticketu v Remedy. Pro větší přehlednost tady ukážu jak vypadají reporty v Excelu. Na Obrazcích 26 a 27 vidíte report z Remedy a MSS podle uvedeného pořadí. 42

47 Obrázek 26: Report z Remedy Obrázek 27: Report z MSS Pro porovnání takto formátovaných záznamů musíme pro začátek oba reporty otevřít a jeden z reportu nakopírovat do listu druhého, například nakopírujeme report z MSS do reportu od Remedy. Po tom si otevřeme třetí list, a přejdeme do záložky View, tam najdeme položku Macros a klikneme na Record Macro. Obrázek 28: Record Macro 43

48 Po tom co vybereme volbu Record Macro začne Excel zaznamenávat každý krok který uděláte v teto aplikaci. Velice dobré vysvětlení toho co je Macros, jak funguje, jak se může napsat a na co se používá je na oficiálních stránkách pro Office Microsoft, odkaz najdete v zdrojích[7]. Tady ale musím vysvětlit proč pro řešení porovnání ticketů v Excel používáme Macros. Odpověď je jednoduchá, reporty které máme jsou v různých formátováních a musíme je dat dohromady. Na to abychom je dali dohromady, nakopírovali vedle sebe potřebné seznamy, očistili to co se má očistit, jako například odstranění části A::EQUANT:: ze sloupce Vendor Ticket Number, musíme udělat malé a docela jednoduché kroky, takových kroků ale bude hodně, a my budeme muset je opakovat každý týden nebo měsíc. Akorát pro úsporu času a celkové automatizaci kroku to děláme. Stačí jednou ty kroky pomoci Macrosu zapsat a už s tím nebudeme mít problém. Takže teď musíme zapsat nebo zaznamenat posloupnost kroků, které nám pomohou vytvořit seznam ticketů k uzavření. 1. Za prvé musíme svůj Macros pojmenovat a popsat. Uděláme to a klikneme OK. 2. Teď přejdeme do listu s reportem z Remedy, zvýrazníme sloupec který v sobe obsahuje Vendor Ticket Number a očistíme ho od části A::EQUANT:: a to tak, že stiskneme klavesy CTRL+F, tam přejdeme do lišty Replace, v poli Find what zadáme A::EQUANT:: a stiskneme Replace all. 44

49 3. Vedle sebe do třetího listu nakopirujeme Incident ID od CSC, očištěný Vendor Ticket Number, Customer Reference a Incident ID od OBS. 4. Zvýrazníme sloupce Incident ID od CSC a Customer Reference, v horní části dokumentu přejdeme do lišty Home a najdeme tam Conditional Formating, klikneme na to, přejdeme do Duplicate Values jak je to ukázáno na obrázku niž. Vybereme si Duplicates a barvu, kterou chceme zvýraznit tickety, které se mají uzavřít. 45

50 5. V horním pravém rohu najdeme Sort and Filter, stiskneme Filter. 46

51 6. Klikneme na Incident ID od CSC a vybereme volbu Filter by color. Hotovo, konečně máme seznam ticketů k uzavření. 7. Ty tickety okopírujeme a vložíme do nového listu, tak aby jejich seznam začínal na 4. řádku. Do prvního řádku a prvního sloupce nakopírujeme tohle: Support Company*' = "Orange Business Services" AND 'Support Organization*' = 47

52 "Vendor" AND 'Assigned Group*+' = "EUR-OBS Voice and Data" AND 'Incident ID*'= Do druhého řádku a prvního sloupce nakopírujeme tento kus: OR 'Incident ID*'= Potom do libovolné buňky nakopírujeme tento velký kus: =CONCATENATE(A1,IF(A4<>0,CONCATENATE("""",A4,"""")),IF(A5<>0,A2,""),IF(A5<> 0,CONCATENATE("""",A5,""""),""),IF(A6<>0,A2,""),IF(A6<>0,CONCATENATE("""",A6,"""")," "),IF(A7<>0,A2,""),IF(A7<>0,CONCATENATE("""",A7,""""),""),IF(A8<>0,A2,""),IF(A8<>0,CO NCATENATE("""",A8,""""),""),IF(A9<>0,A2,""),IF(A9<>0,CONCATENATE("""",A9,""""),""),IF( A10<>0,A2,""),IF(A10<>0,CONCATENATE("""",A10,""""),""),IF(A11<>0,A2,""),IF(A11<>0,C ONCATENATE("""",A11,""""),""),IF(A12<>0,A2,""),IF(A12<>0,CONCATENATE("""",A12,""""),""),IF(A13<>0,A2,""),IF(A13<>0,CONCATENATE("""",A13,""""),""),IF(A14<>0,A2,""),IF(A14 <>0,CONCATENATE("""",A14,""""),""),IF(A15<>0,A2,""),IF(A15<>0,CONCATENATE("""",A 15,""""),""),IF(A16<>0,A2,""),IF(A16<>0,CONCATENATE("""",A16,""""),""),IF(A17<>0,A2,""),IF(A17<>0,CONCATENATE("""",A17,""""),""),IF(A18<>0,A2,""),IF(A18<>0,CONCATENAT E("""",A18,""""),""),IF(A19<>0,A2,""),IF(A19<>0,CONCATENATE("""",A19,""""),""),IF(A20<> 0,A2,""),IF(A20<>0,CONCATENATE("""",A20,""""),"")) Tento kus pro nás vytvoří hledací string z 20 tickety, protože pro Remedy najít víc než 20 konkrétních případů je tak obtížné, že během takového hledání často pro mě zkrachovala. Takže stejně se bude muset hledat po částech. Tady je část výsledného hledacího řetězce: Support Company*' = "Orange Business Services" AND 'Support Organization*' = "Vendor" AND 'Assigned Group*+' = "EUR-OBS Voice and Data" AND 'Incident ID*'="EUINC " OR 'Incident ID*'= "EU-INC " OR 'Incident ID*'= "EUINC " OR 'Incident ID*'= "EU-INC " OR 'Incident ID*'= "EUINC " OR 'Incident ID*'= "EU-INC " OR 'Incident ID*'= "EUINC " OR 'Incident ID*'= "EU-INC " OR 'Incident ID*'= "EUINC " OR 'Incident ID*'= "EU-INC "... Hledání podle stringu bylo popsáno v předchozí části teto práce, takže přejdeme k samotnému uzavření ticketů. Na stránce s výsledným seznamem v Remedy stiskneme Select All potom přejdeme do lišty Resolution. Tam vyplníme taková pole jako Resolution, Resolution Method, Cause a další. Status ticketu postavíme jako Closed a Status Reason postavíme jako Automated Resolution, jelikož taková kategorizace pro uzavření těchto případů byla schvalená ještě před tím než jsem se začala tím zabývat. 48

53 49