VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV INFORMAČNÍCH SYSTÉMŮ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS TECHNICKÁ PODPORA MANAGEMENTU INCIDENTŮ DIPLOMOVÁ PRÁCE MASTER‘S THESIS AUTOR PRÁCE Bc. Zdeněk Soukup AUTHOR BRNO 2012 VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV INFORMAČNÍCH SYSTÉMŮ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS TECHNICKÁ PODPORA MANAGEMENTU INCIDENTŮ TECHNICAL ASSISTANCE OF INCIDENT MANAGEMENT SUPPORT DIPLOMOVÁ PRÁCE MASTER‘S THESIS AUTOR PRÁCE BC. ZDENĚK SOUKUP AUTHOR VEDOUCÍ PRÁCE DOC. RNDR. JITKA KRESLÍKOVÁ, CSC. SUPERVISOR BRNO 2012 Abstrakt Předmětem této diplomové práce je proces managementu incidentů a další neoddělitelně související procesy (management změn, problémů a znalostí). Hlavním úkolem práce je implementace daných procesů do praktického používání v reálné společnosti a to s podporou informačního systému, jež je v rámci práce zvolen. Tyto procesy jsou dále konfrontovány s knihovnou ITIL (Information Technology Infrastructure Library) a optimalizovány tak, aby v co největší míře vyhovovaly jejím požadavkům. Abstract The topic of this Master’s Thesis is Incident Management process as well as other processes which are inseparably linked to it, such as Problem Management, Change Management, Knowledge Management, etc. Main focus of this work is taken to the mentioned processes implementation in the real environment of the real company. Those processes are to be supported by selected information system whereas the selection itself is also part of the project. The processess are compared and optimized with use of Information Technology Infrastructure Library (ITIL). Klíčová slova Management incidentů, management problémů, management změn, plnění požadavků, ITIL, ITSM, Help desk, Service Desk Keywords Incident Management, Problem Management, Change Management, Request Fulfillment, ITIL, ITSM, Help Desk, Service Desk Citace Soukup Zdeněk: Technická podpora managementu incidentů, diplomová práce, Brno, FIT VUT v Brně, 2012 4 Technická podpora managementu incidentů Prohlášení Prohlašuji, že jsem tuto diplomovou práci vypracoval samostatně pod vedením doc. RNDr. Jitky Kreslíkové, CSc. Uvedl jsem všechny literární prameny a publikace, ze kterých jsem čerpal. …………………… Zdeněk Soukup 30. dubna 2012 Poděkování Na tomto místě chci poděkovat vedoucí mé práce, paní doc. RNDr. Jitce Kreslíkové, CSc, za podporu, kterou mi při jejím psaní poskytla. Také nemůžu opomenout zadavatele práce, bez kterého bych se k tak zajímavému tématu jen těžko dostal. © Zdeněk Soukup, 2012 Tato práce vznikla jako školní dílo na Vysokém učení technickém v Brně, Fakultě informačních technologií. Práce je chráněna autorským zákonem a její užití bez udělení oprávnění autorem je nezákonné, s výjimkou zákonem definovaných případů. 1 Obsah Obsah ...................................................................................................................................................... 1 1 Úvod ............................................................................................................................................... 4 1.1 Užitek práce a důvěrnost ........................................................................................................ 4 1.2 Citace z cizojazyčných materiálů ........................................................................................... 4 1.3 Popis společnosti .................................................................................................................... 5 2 ITSM a ITIL ................................................................................................................................... 6 2.1 Historický vývoj IT služeb a vznik ITIL ................................................................................ 6 2.1.1 ITIL v3 ............................................................................................................................ 6 2.2 IT Service Management (ITSM)............................................................................................. 8 2.3 Management incidentů ............................................................................................................ 8 2.3.1 Životní cyklus incidentu ................................................................................................. 8 2.4 Management problémů ......................................................................................................... 13 2.4.1 Hranice mezi managementem incidentů a problémů .................................................... 13 2.5 Plnění požadavků .................................................................................................................. 13 2.6 Management změn ................................................................................................................ 14 2.7 Management znalostí ............................................................................................................ 14 2.7.1 Databáze známých chyb ............................................................................................... 15 2.8 Katalog služeb ...................................................................................................................... 15 2.9 Service Desk ......................................................................................................................... 15 3 Analýza současného stavu ........................................................................................................... 17 3.1 Procesní role ......................................................................................................................... 17 3.2 Administrace ......................................................................................................................... 17 3.3 SLA ....................................................................................................................................... 18 3.4 Konfigurační management .................................................................................................... 19 3.5 Management incidentů .......................................................................................................... 19 3.5.1 Systém pro zákaznickou podporu - Cerberus ............................................................... 20 3.5.2 Založení incidentu ........................................................................................................ 20 3.5.3 Řešení incidentu ............................................................................................................ 21 3.5.4 Operátor ........................................................................................................................ 22 3.5.5 Uzavření incidentu ........................................................................................................ 23 3.5.6 Dodržování SLA ........................................................................................................... 23 3.6 Management problémů ......................................................................................................... 23 3.7 Management změn ................................................................................................................ 24 3.8 Plnění požadavků .................................................................................................................. 24 2 3.9 Management znalostí ............................................................................................................ 24 3.9.1 Optimalizace ................................................................................................................. 25 3.10 Výkazy, statistiky ................................................................................................................. 25 4 Návrh řešení ................................................................................................................................. 26 4.1 Procesní a přístupové role ..................................................................................................... 26 4.2 Číselníky ............................................................................................................................... 27 4.2.1 Organizace .................................................................................................................... 27 4.2.2 Kontaktní osoby ............................................................................................................ 27 4.2.3 Pracovní skupiny .......................................................................................................... 29 4.2.4 Lokalita ......................................................................................................................... 30 4.2.5 SLA ............................................................................................................................... 30 4.3 Konfigurační management .................................................................................................... 31 4.3.1 Založení konfigurační položky ..................................................................................... 32 4.3.2 Změna konfigurační položky ........................................................................................ 32 4.4 Management incidentů .......................................................................................................... 32 4.4.1 Založení incidentu ........................................................................................................ 33 4.4.2 Přidělení incidentu řešiteli ............................................................................................ 35 4.4.3 Řešení ........................................................................................................................... 36 4.4.4 Uzavření incidentu ........................................................................................................ 36 4.4.5 Identifikace defektu ...................................................................................................... 37 4.4.6 Eskalace incidentů ........................................................................................................ 37 4.4.7 Plnění SLA .................................................................................................................... 37 4.4.8 Role Operátor ................................................................................................................ 38 4.5 Management problémů ......................................................................................................... 38 4.6 Management změn ................................................................................................................ 38 4.7 Plnění požadavků .................................................................................................................. 39 4.8 Znalostní management .......................................................................................................... 39 4.8.1 Založení znalostního článku ......................................................................................... 40 4.9 Výběr platformy implementace SD ...................................................................................... 40 4.9.1 Shrnutí specifikace ........................................................................................................ 40 4.9.2 Výběrové řízení ............................................................................................................ 41 4.9.3 Vícekriteriální analýza .................................................................................................. 42 4.9.4 Závěr výběrového řízení a volba platformy .................................................................. 44 5 Implementace ............................................................................................................................... 45 5.1 Architektura a topologie ....................................................................................................... 45 5.1.1 Produkční prostředí ....................................................................................................... 45 5.1.2 Testovací prostředí ........................................................................................................ 48 3 5.1.3 Zajištění dostupnosti ..................................................................................................... 48 5.2 Licence .................................................................................................................................. 54 5.3 Integrace s existujícími systémy ........................................................................................... 55 5.3.1 Active Directory ........................................................................................................... 55 5.3.2 Existující partnerský portál ........................................................................................... 55 5.3.3 Telefonní ústředna ........................................................................................................ 55 5.3.4 Helios Green ................................................................................................................. 55 5.4 Pilotní provoz........................................................................................................................ 55 5.4.1 Použitelnost systému, testování .................................................................................... 56 5.4.2 Akceptační testování ..................................................................................................... 65 5.5 Nasazení do ostrého provozu ................................................................................................ 65 5.6 Implementace SLA ............................................................................................................... 65 6 Metriky, statistiky, měření ........................................................................................................... 67 6.1 SAP BusinessObjects XI (BOXI) ......................................................................................... 67 6.2 Měřené hodnoty .................................................................................................................... 67 6.2.1 Dodržování SLA ........................................................................................................... 68 6.2.2 Tikety uzavřené do 3 odpovědí ..................................................................................... 68 6.2.3 Podíl odeslaných odpovědí k přijatým .......................................................................... 68 6.2.4 Podíl nových tiketů k zavřeným ................................................................................... 69 6.2.5 Podíl chybně zařazených incidentů ............................................................................... 69 6.2.6 Podíl napoprvé správně vyřešených incidentů .............................................................. 69 7 Závěr ............................................................................................................................................ 70 7.1 Možnosti budoucího rozvoje ................................................................................................ 71 7.1.1 Procesy .......................................................................................................................... 71 7.1.2 Zajištění vysoké dostupnosti systému ........................................................................... 72 7.1.3 Další doporučení ........................................................................................................... 73 Literatura .............................................................................................................................................. 74 Seznam obrázků .................................................................................................................................... 76 Seznam příloh ....................................................................................................................................... 77 Příloha 1 - Typy SLA a jejich definice ................................................................................................. 78 Příloha 2 – Seznam výkazů a statistik .................................................................................................. 80 Příloha 3 – Ukázkové workflow incidentu ........................................................................................... 85 4 1 Úvod Tato diplomová práce popisuje teoretickou, analytickou i implementační část zavedení informačního systému v prostředí zákaznické podpory reálné společnosti. Jejím předmětem je zmapování současné situace, navržení řešení a následná implementace. K tomu je využita knihovna ITIL (Information Technology Infrastructure Library). První částí práce (kapitola 2) je položení teoretického základu jako kvalitní základny pro pozdější konfrontaci současných procesů s nejlepšími zkušenostmi ze zmíněné knihovny ITIL. Ve druhé části práce (kapitola 3) je podrobně popsán současný stav ve společnosti, jsou rozebrány výhody i nevýhody současných řešení a ještě v rámci této kapitoly navrženy optimalizace. Třetí část práce (kapitola 4) je věnována návrhu nových procesů, kdy je v potaz brána jak situace ve společnosti, tak nastíněné nejlepší techniky. Je nalezena rovnováha mezi časovými možnostmi, zmíněnou situací a doporučenými postupy uloženými v rámci knihovny ITIL. Zde jsou specifikovány požadavky na systém, na jejichž základě je tento vybrán. Samotná realizace projektu je popsána v kapitole 5. Zde je popsáno výběrové řízení systémového integrátora a implementace navržených procesů ve zvoleném prostředí. Jsou popsány jak detaily nastavení systému, tak jeho limitace. Autor práce je osoba odpovědná za technickou stránku implementace systému, zejména tedy systémová podpora nastavených firemních procesů a bezproblémový chod aplikace. Významným způsobem se také podílel na návrhu procesů a jejich integraci do existujícího prostředí, stejně jako na samotné akceptaci řešení po technické stránce. Tato diplomová práce vzniká jako přímý následník semestrálního projektu, vypracovaného v rámci předcházejícího semestru. Tento se zabýval analytickou částí práce a definicí teoretické základny, což reálně odpovídá kapitolám jedna až čtyři a také kapitole zabývající se výběrovým řízením, kapitolou 4.9. 1.1 Užitek práce a důvěrnost Tato práce popisuje implementaci Service Desku v reálné organizaci. Tato organizace je z bezpečnostních důvodů utajena a nebude v práci zmiňována pod pravým jménem. Jako zástupný název pro společnost je v textu užito názvu XYZ-Tech. Prezentovaná data jsou ovšem pravdivá. Vedoucí práce i oponent znají pravou identitu společnosti. 1.2 Citace z cizojazyčných materiálů Při citování ze zahraničního autorského díla je toto volně přeloženo autorem práce. 5 1.3 Popis společnosti Zde popisovaná společnost je globální společností, tedy je přítomna na všech velkých trzích. Obchodní model společnosti, který je pro tuto práci důležitý, je prodej přes partnery. Společnost neprodává své produkty přímo koncovým zákazníkům, k tomuto využívá síť vyškolených partnerů. Takto je řešena i technická podpora:  První úroveň technické podpory je na zákazníkovi a jeho IT oddělení,  druhá úroveň podpory je v rukou partnera, ten je proškolen na práci se sw a jeho administraci,  třetí úroveň podpory je zákaznická podpora společnosti XYZ-Tech, která je poskytována partnerovi a k zákazníkovi se dostane skrze něj. Partneři mají přístup na webové rozhraní, které je známé pod pojmem Partnerský portál. Zde mají možnost:  nahlédnout do seznamu certifikovaných zařízení,  stahovat software a dokumentaci,  nahlédnout do znalostní báze,  reportovat incident. Obrázek 1 - Obchodní model společnosti XYZ-Tech 6 2 ITSM a ITIL 2.1 Historický vývoj IT služeb a vznik ITIL Řízení IT služeb se vyvinulo přirozeně s rozvojem technologií, kdy se IT organizace v dřívějších dobách soustředily převážně na vývoj a dodání aplikací. Až v průběhu doby se zvyšovala závislost společností na IT službách a to mělo zásadní vliv na rozvoj řídících technik IT procesů. V 80tých letech vzniknul koncept IT Help Desk 1 , což byla odpověď IT organizací na tlak od zákazníků na kontinuální dodávku IT služeb. Tato doba je také dobou, kdy se britská vláda začala zajímat o efektivitu a kvalitu řízení IT služeb, což mělo za následek vznik několik knih v pozdních 80tých a raných 90tých letech. Tyto knihy popisovaly přístup k řízení IT služeb, tedy vznikla IT Infrastructure Library (ITIL). Ranná verze souboru se jmenovala GITIM, Government Information Technology Infrastructure Management (Tipton, et al., 2007) První verze knihovny popisujících ITIL čítala přes 40 svazků a spustila řetězovou reakci zájmu o problematiku řízení IT služeb. S rostoucí popularitou knihovny ITIL se také začíná prosazovat a používat pojem řízení IT služeb (IT Service Management, dále v textu ITSM). Další verze knihovny ITIL byla vyvíjena v období od poloviny 90tých let až do roku 2004, kdy byl představen ITIL v2 čítající již jen 9 knih. (OGC - Office of Government Commerce, 2007) 2.1.1 ITIL v3 V červnu 2007 byla představena aktuální, třetí, verze knihovny ITIL. Ta obsahuje 5 knih a byla revidována od roku 2004 (Knapp, 2010). Tyto knihy jsou následující, včetně procesů, které obsahují: 1. Service Strategy (Strategie služeb) – tato kniha se zabývá IT Governance a popisuje tyto procesy:  Financial Management (správa financí)  Service Portfolio Management (správa portfolia služeb)  Demand Management (správa požadavků) 2. Service Design (Návrh služeb) – Cílem je navrhnout takové služby, které dokáží uspokojit současné i budoucí požadavky:  Service Catalogue Management (správa katalogu služeb) 1 Překlad: Zákaznická podpora 7  Service Level Management (správa úrovně služeb  Capacity Management (správa kapacit)  Availability Management (správa dostupnosti)  IT Service Continuity Management (správa kontinuity služeb IT)  Information Security Management (správa bezpečnosti informací)  Supplier Management (správa dodavatelů) 3. Service Transition (Přechod služeb) zavedení služby – cílem je dodat do produkčního prostředí služby požadované organizací. Kniha popisuje tyto procesy:  Change Management (správa změn)  Service Asset and Configuration Management (správa aktiv a konfigurace)  Knowledge Management (správa znalostí)  Transition Planning and Support (Plánování a podpora přechodu)  Release and Deployment Management (správa releasů a nasazení)  Service Validation and Testing (ověření a testování služby)  Evaluation (Vyhodnocení) 4. Service Operation (Provoz služeb) – cílem je dodávat služby v požadované kvalitě. Kniha popisuje tyto procesy:  Event Management (správa událostí)  Incident Management (správa incidentů)  Problem Management (správa problémů)  Access Management (správa přístupů)  Request Fullfilment (provádění požadavků)  IT Operation Management (správa provozu IT)  Application Management (správa aplikací)  Technical Management (technická správa) 5. Continual Service Improvement (Neustálé zlepšování služeb) – v knize lze nalézt následující procesy:  Service Measurement (měření služeb)  Service Reporting (vykazování služeb) (Čermák, 2009) 8 2.2 IT Service Management (ITSM) Definice ITSM je následující: představuje řízení všech procesů, které spolupracují tak, aby zajistily kvalitu dodávaných IT služeb dle úrovně dohodnuté se zákazníkem. (Bon, 2008) 2.3 Management incidentů Úkolem managementu incidentů je minimalizovat dopad na zákazníka obnovením služby na dohodnutou úroveň v co nejkratším možném čase a zajistit nejvyšší možnou dostupnost IT služby. (Tipton, et al., 2007). Dohodnutou úrovní je myšlena úroveň specifikovaná prostřednictvím SLA (akronym anglického originálu Service Level Agreement. Podrobně rozebráno v kapitole 3.3). Součástí managementu incidentů je každá událost, která přeruší nebo může způsobit přerušení dodávky služby. Incident jako takový je v knihovně ITIL definován takto: Jedná se o neplánované přerušení nebo snížení kvality dodávané IT služby (OGC - Office of Government Commerce, 2007). Zmíněná publikace dále upřesňuje, že incidentem je také selhání funkce, který zatím službu neomezila – například selhání jednoho z disků v poli zrcadlových disků. Případně je možné si představit selhání jednoho uzlu ve více uzlovém prostředí. Dalším specifikem managementu incidentů je fakt, že je pro ostatní ze všech popisovaných procesů nejvíce viditelným - zákazníci s ním přicházejí do styku. Toto je důvodem prvořadé implementace tohoto procesu a všechny ostatní jsou nesprávně brány spíše jako podpůrné. Stejně tak je to důvodem pro větší prostor věnovaný managementu incidentů v této práci. 2.3.1 Životní cyklus incidentu Níže je k vidění proces managementu incidentů a jeho popis tak, jak jej popisuje ITIL (OGC - Office of Government Commerce, 2007). 9 Obrázek 2 - Proces managementu incidentů podle ITIL (Security Procedure, 2008) 2.3.1.1 Identifikace incidentu Není nezbytně nutné, aby byl incident identifikován až díky uživateli, kterému nebyla plně nebo dostatečně kvalitně poskytnuta IT služba. Toto je ovšem stále nejčastější cesta, jak incident zaznamenat a to zejména v organizacích, kde je management incidentů implementován nově. Lepší cestou je monitorování služby pomocí vhodných nástrojů, které dokážou včas upozornit na nastalou/možnou nedostupnost služby. (OGC - Office of Government Commerce, 2007) 10 Incident je do systému Service Desk zaznamenán na základě telefonátu, osobního kontaktu, může být zadán přes webové rozhraní sloužící k tomuto účelu apod. 2.3.1.2 Zaznamenávání incidentů Je třeba všechny incidenty zaznamenat a není důležité, jestli vznikly skrze Service Desk, byly nahlášeny telefonicky nebo zjištěny pomocí automatizovaného kontrolního zařízení. Knihovna ITIL doporučuje u každého incidentu udržovat následující informace:  Jednoznačné identifikační číslo,  kategorii incidentu (často se rozpadají do několika úrovní),  urgenci incidentu,  dopad incidentu,  prioritizaci incidentu,  datum a čas zaznamenání incidentu,  jméno nebo ID osoby či skupiny, která incident zaznamenala,  metodu, jakou byl incident nahlášen (telefonicky, skrze Service Desk, emailem, osobně, …),  identifikaci uživatele,  status incidentu (aktivní, neaktivní, …),  příslušnou konfigurační položku,  skupina nebo řešitel, který má řešení incidentu na starosti,  metoda odpovědi (telefon, email, …),  popis symptomů,  přidružený problém,  činnosti, které byly provedeny k vyřešení incidentu,  datum a čas vyřešení incidentu,  kategorie vyřešení,  čas a datum uzavření incidentu. (OGC - Office of Government Commerce, 2007) 2.3.1.3 Kategorizace incidentu Při zaznamenávání incidentu je třeba zvolit i jeho kategorii. Ta slouží potom zejména v dalších procesech managementu problémů ke sledování trendů incidentů. Většinou je možné volit z několika úrovní kategorie. Jako příklad: 11 Obrázek 3 - Několik úrovní kategorizace incidentu Často nastane situace, kdy je kategorie incidentu chybně určena – důvodem může být například nedostatek informací při zakládání incidentu. Proto je důležité, aby bylo zařazení do kategorie revidováno při formálním uzavření incidentu, viz kapitola 2.3.1.8 2.3.1.4 Prioritizace incidentu Priorita incidentu je typicky počítána z urgence a dopadu, tedy jak rychle zákazník požaduje/potřebuje vyřešení incidentu. Pro takové nastavování priorit definuje knihovna ITIL následující jednoduchou tabulku: Obrázek 4 - Systém pro kódování priorit (OGC - Office of Government Commerce, 2007) Není možné opomenout, že takováto tabulka nedokáže pojmout všechny aspekty prioritizace – například může jít o zákazníka, kde je vysoký zájem o ukázání dobré vůle z důvodu dalších vztahů či podobně. Pro tyto případy je třeba mít možnost nastavovat a upravovat priority ručně. Ka te go ri e Hardware Počítač Monitor Periferie Software Operační systém Skladová evidence Účetní systém 12 2.3.1.5 Eskalace incidentu Incident může být eskalován dvěma způsoby: 1. Funkční eskalace – jakmile podpora zjistí, že není schopna sama incident vyřešit, je tento eskalován dále. To může znamenat například na technickou podporu dodavatele komponenty apod. 2. Hierarchická eskalace – popisuje uvědomění příslušné manažerské role o tom, že je třeba věnovat incidentu zvýšenou péči. Ta potom může vhodně zasáhnout, například vyhrazením dalších zdrojů na řešení incidentu. 2.3.1.6 Řešení a diagnóza Popisuje analýzu incidentu a hledání možností obnovení služby. Je důležité dokumentovat všechny činnosti během analýzy a řešení incidentu z důvodu další optimalizace a případného znovupoužití při řešení podobných incidentů. Později lze také na incidentu založit znalostní článek, viz kapitola 4.8.1 2.3.1.7 Vyřešení a obnova služby Jakmile je nalezeno možné řešení, je třeba jej otestovat a vyzkoušet. Toto je možné udělat ve vlastním testovacím prostředí, požádáním zákazníka nebo zadáním třetí straně. Po tomto kroku je incident předán dále k formálnímu uzavření. 2.3.1.8 Uzavření incidentu Service Desk je odpovědný za ujištění, že byla služba skutečně obnovena, že jsou uživatelé spokojeni a souhlasí s uzavřením incidentu. Další činnosti, které je třeba provést jsou následující:  Kategorie uzavření – je třeba zadat kategorii, do které spadá metoda, jakou byla služba obnovena. Také je třeba upravit kategorii incidentu jako takového, pokud byla při otevření nastavena chybně.  Průzkum uživatelské spokojenosti – pro ověření kvality služeb poskytovaných SD je určitému procentu incidentů odeslán průzkum, typicky emailem nebo telefonicky.  Dokumentace incidentu – doplnění detailů incidentu a postupu jeho vyřešení tak, aby byl záznam kompletní.  Trvalý nebo často se objevující incident? – Pokud je tento incident častý, je třeba založit problém, který je příčinou tohoto a jemu podobných incidentů. Dále je vytvořen záznam v rámci managementu problémů.  Formální uzavření – incident je formálně uzavřen. V některých společnostech je běžné, že jsou incidenty po určité době neaktivity ze strany zákazníka uzavřeny automaticky. 13 2.3.1.9 Znovuotevření incidentu Někdy je možné a žádoucí, aby byl incident znovuotevřen. Takováto činnost ale musí být podřízena pevně daným a komunikovaným pravidlům tak, aby nemohlo docházet k jejich zneužívání zákazníkem. Příkladem takového pravidla je, že do 5ti pracovních dnů po uzavření incidentu je možné incident znovuotevřít, později už je třeba založit nový a dřívější výskyt s ním provázat. 2.4 Management problémů Cílem managementu problémů je vyřešit základní příčinu incidentů tak, aby byl nepříznivý dopad na zákazníka minimální. Zároveň zabraňuje dalšímu výskytu incidentů, které se k tomu kterému problému vážou. Problém je potom chápán jako příčina jednoho či více incidentů a „známá chyba“ je diagnostikovaný problém, který má známé náhradní řešení obnovující službu. (Tipton, et al., 2007) Jak vyplývá z textu výše, tak problém je často identifikován na základě několika incidentů, které vykazují podobné symptomy. Je také možné jej identifikovat z jediného incidentu, pokud je neznámá příčina a dopad incidentu je značný. 2.4.1 Hranice mezi managementem incidentů a problémů Management incidentů má za úkol obnovení služby u zákazníka tak, aby byly splněny předdefinované podmínky. Ty jsou stanoveny, přesně definovány a vymezeny v rámci SLA. Jako příklad je možné uvést pravidelně se ukončující program (což není správně, cílem je dostupnost 24/7), který zajišťuje základní potřebu společnosti, například se stará o autorizaci uživatelů při vstupu do budovy. Bez této služby není možné do budovy vstoupit. Incident Management se postará o obnovení služby například tak, že bude službu každý den někdo restartovat. Ze zákazníkova pohledu vše běží jak má, dodávka služby funguje. Management problémů je potom samotná příčina incidentu. Ve výše uvedeném příkladu se jedná o zjištění, proč služba nefunguje (proč se vypíná) a o nalezení trvalého řešení. Tímto řešením je například použití aktualizované verze operačního systému. Je třeba zmínit, že incident je incidentem po celou dobu svého životního cyklu (viz kapitola 2.3.1) a nikdy se nestane problémem. Management incidentů tak slouží jako identifikační platforma pro problémy (tedy díky managementu incidentů jsou identifikovány nové problémy). 2.5 Plnění požadavků Požadavky je zde míněna celá škála žádostí, které na IT oddělení přicházejí. Pro přiblížení – může se jednat například o požadavek na změnu hesla, nainstalování informačního systému, případně 14 pouze žádost o informace. V některých organizacích je typické, že proces plnění požadavků je řešen v rámci managementu incidentů, kdy je vytvořena speciální kategorie pro identifikaci incidentů tohoto typu. Aby bylo možno rozlišit mezi incidentem a požadavkem, je možné se podívat na plánovitost výskytu – incident je typicky neplánovaná událost, naproti tomu požadavek bývá a měl by být plánovaný. (OGC - Office of Government Commerce, 2007) 2.6 Management změn Jestli něco popisuje současné obchodní prostředí v celém jeho kontextu, tak je to změna. Obzvláště informační technologie jsou v současné době velmi komplexním systémem, integrovaným do všech částí prostředí společnosti. Jakákoliv změna je potom velkým rizikem pro chod společnosti jako takové. Management změn představuje tři základní modifikace:  Změny – plánované změny do IT infrastruktury tak, aby se udržela funkční. Takovéto změny mohou představovat instalaci nové pracovní stanice, ale i fyzický přesun serveru do nové lokality. Tento druh změn dokáže do infrastruktury zavést chyby, které nemusejí být po dlouhou dobu objeveny, ale kvalitním procesem managementu změn je možné jim předcházet.  Opravy – jednoduše řečeno se jedná o opravy chyb, které byly do infrastruktury zavedeny.  Vylepšení a inovace – jedná se o implementaci nových služeb, komponent, apod. Tyto druhy změn často vyústí v dlouhodobé problémy, případně neočekávané důsledky. (Herold, 2007) Lze říci, že úkolem managementu změn je zavádět změny do organizace tak, aby došlo k minimálnímu vyrušení, dopad na společnost aby byl co nejmenší, minimalizovala se i rizika spojená se změnou a aby byla změna úspěšně zavedena již napoprvé. Knihovna ITIL definuje cíle managementu změn jako: zajištění změn, aby byly zaznamenávány, poté hodnoceny, autorizovány, prioritizovány, plánovány, testovány, implementovány, dokumentovány a revidovány v procesně kontrolovaném prostředí. (Macfarlane, a další, 2007) 2.7 Management znalostí Schopnost dodávat kvalitní služby leží ve vysoké míře na schopnosti reagovat na okolnosti, což zase velmi závisí na pochopení situace, možností, možných dopadů a přínosů. Jinými slovy závisí na znalosti situace, ve které se nacházejí, či by se nacházet mohli. Cílem managementu znalostí je tedy ujistit se, že znalosti byly ve správnou chvíli a správný čas na správném místě tak, aby umožnily učinit na jejich základě nejlepší možné rozhodnutí. (Macfarlane, a další, 2007) 15 2.7.1 Databáze známých chyb Jedná se o informační zdroj důležitý pro řešení jak incidentů (viz kapitola 2.3.1.6), tak problémů. Tato databáze obsahuje kompletní popis jak symptomů, tak případných náhradních a dočasných řešení. Je pravidelně udržována. 2.8 Katalog služeb Katalogem služeb je podle terminologie knihovny ITIL myšlena podmnožina služeb, která je sdílena se zákazníkem. Sestává ze služeb aktuálně poskytovaných zákazníkům nebo služeb, které byly do tohoto stavu převedeny (pokud je ještě nikdo nevyužívá). Katalog služeb neukazuje ani služby, které byly nabízeny v minulosti, ani ty, které jsou plánovány v blízké budoucnosti a představuje tak velkou hodnotu jak pro zákazníka, tak pro management při strategickém plánování. (OGC - Office of Government Commerce, 2007) 2.9 Service Desk Service Desk je pro zákazníky jednotným místem kontaktu (Single Point of Contact - SPC), kde mohou žádat informace, hlásit incidenty, problémy a obecně řešit všechny záležitosti týkající se IT služeb. Service Desk do organizace přináší zejména:  zvýšení pravděpodobnosti vyřešení incidentů po prvním zavolání,  podporu založenou na schopnostech,  urychlené obnovení služby,  zvýšení schopností rozpoznávání trendů v incidentech,  zvýšenou schopnost detekce problémů na základě incidentů, které vykazují podobné symptomy,  v konečném důsledku zvýšenou spokojenost jak zákazníka, tak samotných zaměstnanců. (Tipton, et al., 2007) Dále v textu bude na Service Desk referováno pomocí zkratky SD. 16 Obrázek 5 - Koncepce ITIL (Tipton, et al., 2007) 17 3 Analýza současného stavu Tato kapitola se zabývá popisem stavu procesů společnosti před zaváděním SD. Ve společnosti existují procesy, které jsou do určité míry popsány v dokumentech, které se nazývají „Standard Operating Procedure“ (dále v textu na ně bude referováno jako na „SOP“). Tyto dokumenty jsou všem zaměstnancům přístupné na intranetu společnosti a jsou pravidelně aktualizovány. Je třeba zmínit, že podpora zákazníků je řešena na dvou místech. Podpora interních zákazníků je směrována na IT oddělení, ale podporu externích zákazníků má na starosti oddělení zákaznické podpory. 3.1 Procesní role Celý systém obsahuje tyto role: 3.2 Administrace Vzhledem k různorodosti systémů implementovaných ve společnosti XYZ-Tech je jejich administrace více než obtížná. Tyto systémy jsou navíc zcela samostatné, chybí jakákoliv integrace, což značně komplikuje spolupráci napříč odděleními. Bylo již zmíněno, že také data jsou situována na různých místech, občas vznikají i redundance. V níže uvedené tabulce je možné nalézt popis jednotlivých systémů a data, která obsahují. Název role Popis Zákazník Zákazník je uživatelem produktu. Jedná se o třetí úroveň technické podpory, zákazník je schopen produkt konfigurovat. Partner Partner typicky prodává řešení společnosti zákazníkovi a zajišťuje druhou úroveň technické podpory. Identifikuje incidenty u zákazníka a slouží jako prostředník v komunikaci. Řešitel Řeší incidenty v rámci podpory společnosti XYZ-Tech. Je podporou třetí úrovně, tedy nejvyšší. Analytik Synonymum pro řešitele. Operátor Jedná se o speciální typ role Řešitel. Zajišťuje provozní záležitosti, ostatním řešitelům tak, aby ti mohli pracovat na incidentech. Bližší popis této role je možné nalézt v kapitole 3.5.2. 18 Název systému Popis IS Helios Centrální databáze zákazníků, partnerů a všech souvisejících dat. Partnerský portál Systém pro partnery, kde je možné nalézt informace o produktech, manuály, založit incident nebo objednat licence. Každý partner dostává unikátní přihlašovací údaje. Active Directory Evidence interních zaměstnanců, účtů a skupin. Polarion Informační systém oddělení vývoje, kde jsou uloženy informace o verzích produktu a jednotlivých sestaveních. 3.3 SLA V dodacích podmínkách produktů společnosti XYZ-Tech je definována dvojí doba pro dodržení SLA: 1. Hodnotná odpověď – je třeba zákazníkovi/partnerovi dodat hodnotnou odpověď do definovaného termínu. Jako hodnotná odpověď je brána informace o tom, že incident vyřešíme opravou (bude založen problém nebo změna), případně navržení dočasného řešení. Není tedy možné splnit SLA pouhým odesláním automatického emailu. 2. Dodání řešení – doba do obnovení služby jakoukoliv cestou. Stejně tak jsou přesně definovány následující pojmy: 1. Kritický incident – jedná se o kritické selhání důležité komponenty systému nebo jiným způsobem způsobení situace, kdy je většina organizace (nad 90% nebo nad 10 uživatelů) neschopna produkt využívat. Je také možné, že jsou nebo mohou být ztraceny důležité údaje. 2. Podstatný incident – nejčastější typ incidentu. Některá méně významná část systému přestala pracovat správně. Uživatelé jsou schopni využívat produkt i nadále. 3. Nepodstatný incident – jedná se například o kosmetické vady, jako jsou chybné překlady textů. Typicky by se vyřešením tohoto typu incidentu dosáhlo lepší funkcionality, ne obnovení. Jednotlivé typy SLA a přesná definice časů na odpověď/řešení je součástí přílohy (viz Seznam příloh). Definice pracovního dne vychází z pracovní doby zákaznické podpory společnosti XYZ-Tech, což je 8-17 hodin v pracovní dny dle své časové zóny. V systému SD budou implementovány tyto časové zóny:  8 - 17 hodin CDT 2 2 CDT – Central Daylight Time, UTC + 5 hodin 19  8 - 17 hodin CET 3 Nutno zmínit komplikaci v dodržování SLA a to je konkrétně příklad „Premium SLA“. Zde je pro Podstatný incident definována doba pro doručení hodnotné odpovědi „ten samý pracovní den“. Prakticky to potom znamená, že incident, který je nahlášen v 16:50 CET, musí dostat hodnotnou odpověď do 17:00. V opačném případě je poručeno SLA. Zřejmá je pak situace s tiketem založeným v 16:59. Níže je možné nalézt kompletnější přehled, příklady. 3.4 Konfigurační management V současné době společnost XYZ-Tech nepoužívá žádný druh konfigurační databáze a všechna data jsou rozprostřena v několika informačních systémech. Konfigurační databáze není použita ani pro vnější potřeby (zákaznická podpora), ani pro potřeby vnitřní správy IT. 3.5 Management incidentů Incident Management je ze všech procesů nejpropracovanější, existuje dokument dobře popisující celý proces. 3 CET – Central European Time, UTC +1 hodina Doba Čas nahlášení incidentu SLA vyprší 1 pracovní hodina 1. 4. 2012, 15:30 1. 4. 2012, 16:30 2 pracovní hodiny 1. 4. 2012, 15:30 2. 4. 2012, 08:30 1 pracovní den 1. 4. 2012, 15:30 2. 4. 2012, 17:00 Ten samý pracovní den 1. 4. 2012, 15:30 1. 4. 2012, 17:00 2 pracovní dny 1. 4. 2012, 15:30 3. 4. 2012, 17:00 60 pracovních dnů 1. 4. 2012, 15:30 30. 5. 2012, 17:00 20 Obrázek 6 - Mapa procesu managementu incidentů 3.5.1 Systém pro zákaznickou podporu - Cerberus V současné době je pro podporu managementu incidentů využíván systém Cerberus, což je opensource webový systém určený pro podporu spolupráce a workflow (WebGroup Media LLC., 2011). Tento systém se jeví jako méně výkonný ve způsobu práce s daty a znalostmi, má velmi nepřehledné rozhraní pro znalostní bázi, což má za následek ukončení jeho používání. Velkým nedostatkem systému je možnost statistik. Tyto jsou generovány přímo z databáze a všechny nové reporty vyžadují programátorský zásah. Takovéto řešení je sice velmi obecné a umožňuje vyhledat rozličné závislosti, ovšem uživatelsky je velmi nepříjemné a proto je celý proces reportování náchylný k chybám a nepružný. Další z důvodů přechodu na nový systém je podpora procesů – současný systém je nepodporuje nebo podporuje jen v omezené míře. Společnost také nedisponuje dostatečnými kapacitami pro vývoj systému a jeho další údržbu. 3.5.2 Založení incidentu Partneři mají přístup na Partnerský portál, kde je možné založit incident. Při jeho zakládání musejí projít přes znalostní bázi, čímž se jednak zvyšuje možnost nalezení řešení a incident tak nebude založen a jednak je poté v tiketu vidět, kudy se partner dostal a je tam možná určitá kategorizace incidentu. Při zakládání incidentu partner volí zákazníka ze seznamu (dynamicky generovaný pro každého partnera zvlášť) a tím se na tiket přiřadí SLA. Pakliže zákazník nemá uzavřenu smlouvu o 21 podpoře, je zvolena informace o tom, že tiket nepodléhá SLA. V současné době je i tak tiket zodpovězen, ale je to bráno jako dobrá vůle 4 . Při zakládání incidentu jsou od partnera požadovány následující informace:  jméno osoby, která incident hlásí (odpovídá přihlášenému uživateli),  kontaktní osoba,  kontaktní telefon,  SLA (vybrání zákazníka ze seznamu nebo volba „Zákazník nemá SLA“),  stručné shrnutí incidentu (odpovídá předmětu emailu),  popis incidentu,  postup, kterým lze incident navodit,  urgenci incidentu,  uživatel postižený incidentem,  datum a čas posledního výskytu incidentu,  postižené zařízení (IP adresa či jiná identifikace),  verze produktu,  přesná verze sestavení produktu,  přiložit k incidentu jeden nebo více souborů. Dále se automaticky generují následující atributy:  Jednoznačné identifikační číslo,  skupina nebo řešitel, který má řešení incidentu na starosti (nepovinné),  datum a čas vyřešení incidentu,  čas a datum uzavření incidentu,  komentáře. 3.5.3 Řešení incidentu Po založení incidentu je tento uložen v jakémsi „bazénu“, odkud si jej řešitel vyzvedne. Je tedy pouze na vůli a domluvě řešitelů, kdy se který tiket řeší a nesplnění SLA je spíše kolektivní vinou a není prakticky možné nalézt odpovědnou osobu. Na druhou stranu má tento systém velkou výhodu pro celý proces, protože řešitelé nejsou dedikováni pouze na řešení incidentu a mají i další povinnosti. Proto je potom procesně jednoduché ošetřit to, že řešitel je několik dnů/týdnů na pracovní cestě a řešení incidentů se tak nevěnuje. Toto ošetření spočívá v tom, že incidenty nejsou vázány na řešitele a proto je maximálně využit princip zastupitelnosti. 4 Dobrá vůle společnosti XYZ-Tech, která chce podporovat všechny zákazníky. Tento přístup je možné kdykoliv změnit. 22 3.5.3.1 Vzdálená pomoc Systém Cerberus neobsahuje nástroj, který by umožňoval vzdálenou podporu u partnera či zákazníka. V současné době je tedy využíván nástroj třetí strany – Teamviewer, případně WebEx, na které jsou zakoupeny licence. 3.5.4 Operátor Incident Management obsahuje důležitou roli operátora, která má za úkol řazení tiketů podle důležitosti a kategorizování podle oblasti, do které spadá. Řazení podle důležitosti nyní zahrnuje několik kategorií, které jsou podrobně popsány v SOP:  Incident typu A – jen nejzávažnější incidenty, které mají vysoký dopad na zákazníka. Typicky se jedná o kompletní vyřazení tisku, zákazník tedy nemůže tisknout a není známo náhradní řešení obnovující službu. Případně špatné účtování kreditu, kdy je uživateli stržena či připsána nesprávná částka.  Incident typu B – většina incidentů bude patřit do této kategorie. Zákazníkův business jako takový není v ohrožení, ale incident je nepříjemný.  Incident typu C – Méně závažné incidenty, bude sem patřit například nejasné chybové hlášení produkované softwarem, kosmetické nedostatky všeho druhu.  Incident typu X – Tato kategorie slouží pro otázky na konfiguraci a funkcionalitu. Prvotní rozřazení podle důležitosti provádí už sám partner při zadávání incidentu přes Partnerský portál 5 a to je následně revidováno operátorem. Na základě tohoto rozřazení je počítáno dodržení SLA se zákazníkem, je tedy velmi důležité hlídat si incidenty vysoké důležitosti u zákazníků, kteří mají zaplaceno SLA. Zde je možné získat statistiku o chybně řazených incidentech a takového partnera jakkoliv perzekuovat, případně nabídnout školení. Dalším úkolem operátora je rozesílání upomínek, kdy se čeká na partnera – pokud je incident po definovanou dobu bez odpovědi, je po jedné upomínce incident uzavřen. V současné době je nastavena doba čekání na odpověď na 14 dnů. Poměrně dlouhá doba je ospravedlněna faktem, že partner musí pro aplikaci řešení či dohledání požadovaných dat kontaktovat zákazníka. Tento proces může být v některých případech poměrně časově náročná aktivita a to zejména kvůli případným bezpečnostním politikám zákaznického prostředí. Také je občas třeba osobní návštěva partnera, což je také nutné naplánovat s předstihem. Nižší doba pro upomínku by mohla vyústit v uzavírání tiketů bez potvrzení řešení. Tomuto stavu se chce oddělení zákaznické podpory vyhnout. Hlídání vydávání oprav je také úkolem role operátor. Pravidelně kontroluje interní informační systém oddělení vývoje. Pokud je vydána oprava, na kterou některý partner čeká, je povinností 5 Přístupný z internetu pomocí přihlašovacího jména a hesla. 23 operátora jej notifikovat o možnosti stažení a vyžádat si souhlas s uzavřením incidentu. Po této notifikaci také upraví stav v interním vývojovém systému na „confirmed“, čímž se uzavře i tiket u oddělení vývoje. 3.5.5 Uzavření incidentu Incident je možné vyřešit a uzavřít jen v rámci oddělení technické podpory. Jakmile se povede nalézt řešení, například změnou konfigurace produktu, je tiket přepnut do stavu „Resolved to be confirmed“. Je ale častým scénářem, že je nutná konzultace s vývojovým oddělením, která může skončit identifikací chyby v sw a je tak iniciován proces opravy. To znamená založení tiketu pro opravu v interním systému vývojového oddělení a u incidentu nastavení stavu „Waiting for RnD“. Partner je o takové změně informován. Samotné uzavření incidentu proběhne až ve chvíli, kdy je partnerovi doručena oprava, což může být velmi dlouhá doba - v případech, že zákazník nemá SLA, je standardní dodací lhůta 120 pracovních dní. Ta se může ještě prodloužit, pokud jsou ve frontě prioritnější opravy. Po uzavření incidentu je možné ručně odeslat průzkum spokojenosti a ten je zvažován pro každý případ zvlášť. To je důvod, proč je velký prostor pro umělé vylepšování takových čísel, protože řešitelé nemusejí odeslat průzkum pro případy, kdy neposkytli tak kvalitní servis. 3.5.5.1 Znovuotevření incidentu Partner má možnost otevřít incident po libovolně dlouhé době poměrně jednoduchou cestou – odesláním dalšího emailu v příslušné emailové komunikaci reprezentující incident. Také je o této možnosti informován při uzavírání. 3.5.6 Dodržování SLA Současný systém pro zákaznickou podporu Cerberus neumožňuje hlídat SLA jinak, než zpětně. Jednou za týden je generován report dodržení SLA, který je rozeslán všem řešitelům a udržuje tím povědomí o celkové kvalitě poskytovaných služeb. Tento report, stejně jako další metriky jsou generovány ručně psanými skripty. Více v kapitole Systém pro zákaznickou podporu - Cerberu. Velmi žádanou funkcionalitou je notifikace o blížícím se porušení SLA, tedy proaktivní přístup k dodržování SLA. 3.6 Management problémů Proces managementu problémů není ve společnosti XYZ-Tech formálně definován. 24 3.7 Management změn Management změn není ve společnosti XYZ-Tech implementován ve své formě takové, jak jej chápe knihovna ITIL. Důvodem je to, že vstupem do procesu managementu změn je už identifikovaná nutnost změny v kódu. Mezi informačním systémem zákaznické podpory (informační systém Cerberus) a informačním systémem oddělení vývoje (informační systém Polarion) jsou párovány tikety pomocí svých jednoznačných identifikátorů. Toto párování není nijak automatizováno, vše se provádí ručně. Po identifikaci defektu (což je interní název popisující chybu v programu) je incident ponechán otevřený, je mu nastaven příznak, že se čeká na dodání opravy z oddělení vývoje a po opravě je partner notifikován. Jakmile partner opravu u zákazníka nasadí, je tiket uzavřen nebo řešen dále v případě, že oprava incident nevyřešila. 3.8 Plnění požadavků Procesy plnění požadavků nejsou ve společnosti XYZ-Tech formálně definovány. V současné době se jedná o 3 základní druhy požadavků:  požadavek na vzdálenou podporu,  požadavek na nový ovladač, na certifikaci zařízení,  požadavek o vydání konvertoru na čísla karet čtená ze zařízení a přenášená do systému. Ve všech případech je založen tiket pro zmíněný požadavek a po jeho splnění je uzavřen. Proces plnění požadavků je tak ve své podstatě součástí procesu managementu incidentů, jednotlivé tikety se liší pouze kategorizací. Plnění požadavků pro interní zákazníky, tedy podpora IT od oddělení IT je nyní řešena přes fórum na intranetu, kam mohou zaměstnanci zadávat své požadavky, například na výměnu či konfiguraci přidělaných zařízení. 3.9 Management znalostí Ve společnosti existuje několik znalostních bází, které jsou různě využívány a aktualizovány. Stručně lze říci, že neexistuje jasně daný, ucelený a standardizovaný koncept práce se znalostmi. 25 3.9.1 Optimalizace Toto je jedna z klíčových vlastností nového sytému, aby byl schopen umožnit integrovanou práci se znalostmi, jejich kategorizaci, přístupnost a sdílení a to jak mezi zaměstnanci společnosti a pracovníky zákaznické podpory, tak pro partnery a v budoucnu i samotné zákazníky. 3.10 Výkazy, statistiky Jsou využívány statistiky, které se zpracovávají v tabulkovém procesoru. Používané informační systémy nemají dostatečně flexibilní modul pro generování statistik tak, aby postihl všechny požadavky. V současné době jsou generovány statistiky pro následující skutečnosti: 1. Dodržování SLA a. Přehled nahlášených tiketů s SLA (počet, typ SLA, kolik dodrženo, kolik SLA bylo porušeno a proč. b. Přehled časů řešení dle SLA. c. SLA průměrný čas zpracování 6 podle řešitelů + celkově. 2. Komplexní report tiketů a. Kolik je otevřených tiketů. b. Kolik tiketů čeká na oddělení zákaznické podpory. c. Kolik tiketů čeká na oddělení vývoje. d. Kolik tiketů čeká na odpověď od zákazníka. e. Kolik tiketů dnes bylo vytvořeno. f. Kolik odpovědí odešlo z oddělení zákaznické podpory. g. Kolik odpovědí odešlo od zákazníka. h. Kolik tiketů bylo uzavřeno. i. Kolik tiketů bylo dnes uzavřeno do tří odpovědí. j. Počet tiketů dle kategorií a dle urgence. k. Počet tiketů otevřených partnerem. l. Počet odpovědí u tiketů (lze vyfiltrovat tikety s velkým množstvím). m. Výběr náhodných tiketů od řešitelů (pro hodnocení kvality odpovědí). n. Report tiketů podle agentů. o. Počet odpovědí. p. Čas strávený odpovídáním a řešením. 6 Celkový čas strávený odpovídáním a řešením tiketů vydělený počtem odpovědí 26 4 Návrh řešení V rámci této kapitoly je představen koncept nastavení procesů po implementaci systému pro podporu managementu incidentů. Jedná se jak o kompletní přepracování, tak o mírné či významnější úpravy zavedených procesů. Také je třeba říci, že tyto požadavky byly postupně upravovány a upřesňovány v závislosti na vybraném informačním systému. A tedy pořadí podkapitol neodpovídá časovému pořadí skutečně prováděné analýzy. Zde prezentované řešení je konečným návrhem k implementaci před jejím započetím. Požadavky vycházejí jednak ze současného stavu a jednak ze specifikace ITIL. Obecně lze říci, že není možné zajistit plný soulad s knihovnou ITIL, protože existuje mnoho specifik v organizaci, která nelze pokrýt. 4.1 Procesní a přístupové role Název role Popis Zákazník Zákazník je uživatelem produktu společnosti, ale systém SD nijak nevyužívá. Partner V případě potřeby podpory třetí úrovně zadává tiket do systému SD. Řešitel/Analytik Řeší incidenty v rámci podpory společnosti XYZ-Tech. Je podporou třetí úrovně, tedy nejvyšší. Má právo aktualizovat všechny tikety. Operátor Jedná se o speciální typ role Řešitel. Zajišťuje provozní záležitosti, ostatním řešitelům tak, aby ti mohli pracovat na incidentech. Bližší popis této role je možné nalézt v kapitole 4.4.8. Má práva jako řešitel a partner. Administrátor Přístupová role s oprávněními nastavovat všechny možnosti systému. Nejvyšší možná oprávnění. Administrátor konfigurační databáze Stará se o administraci konfiguračních položek. Analytik konfigurační databáze Disponuje přehledem o konfiguračních položkách, nemá možnost administrace. Manažer incidentů Je vlastníkem procesu managementu incidentů. Navrhuje zlepšení a optimalizuje proces k vyšší efektivitě. 27 4.2 Číselníky V rámci systému SD bude nutné udržovat několik číselníků, které nejsou součástí konfigurační databáze, ale přímo systému SD. 4.2.1 Organizace Jedná se o seznam organizací, které popisují příslušnost jednotlivých techniků partnera pod jednu mateřskou společnost. Tento seznam definuje oprávnění pro sdílení tiketů mezi nimi. Zdrojem dat je informační systém Helios Green. 4.2.2 Kontaktní osoby Seznam kontaktních osob bude popsán následujícími údaji. Jednoznačným identifikátorem je login (parametr User ID). Zdrojem dat je Active Directory. Název parametru Popis Name Název organizace Organization Code Kód organizace (např. IČ) Record Status Aktivní či neaktivní záznam Primary Phone Number Primární tel. číslo Alternate Phone Number Další tel. číslo Fax Number Faxové číslo Contact Name Kontaktní osoba pro organizaci Email Address Adresa pro další kontakt Pager Email Address Pager adresa Location Fyzická poloha organizace Description Komentář, popis Type Příznak určující, jestli je to organizace - partner, či organizace – koncový zákazník javascript:void(0) javascript:void(0) 28 Název parametru Popis Last Name Příjmení First Name Jméno Middle Name Prostřední jméno, titul User ID Uživatelské jméno pro přihlášení Job Title Pracovní pozice kontaktu Status Aktivní/neaktivní záznam Data Partition Omezení dat pro kontakt Access Type Typ přístupu do Systému SD Available Dostupnost kontaktu Supervisor Nadřízený kontaktu Contact Type Typ kontaktu Time Zone Časová zóna Telephone number Primární tel. číslo Fax Number Fax Pager Phone Number Pager Alternate Phone Number Mobil Email Address Email Pager Email Address Pager email Notifications Low Metoda notifikace při nízké prioritě Notifications Normal Metoda notifikace při normální prioritě Notifications High Metoda notifikace při vysoké prioritě Notifications Emergency Metoda notifikace při urgentní prioritě Workshifts for Notification Low Pracovní směna pro notifikace low Workshifts for Notification Normal Pracovní směna pro notifikace normal Workshifts for Notification High Pracovní směna pro notifikace high Workshifts for Notification Emergency Pracovní směna pro notifikace emergency Location Fyzická poloha Functional Organization Organizace pro skupinu Contact Notes Poznámky pro skupinu javascript:void(0) 29 4.2.3 Pracovní skupiny Číselník pracovních skupin bude udržován ručně v systému SD. Kromě níže zmíněných parametrů bude součástí popisu skupin následující:  Kontaktní osoby nebo další vnořené skupiny (propojení),  označení jednoho nebo více členů jako vedoucích skupiny,  povolení notifikace členů skupiny v rámci této skupiny. Název parametru Popis Group Name Název skupiny Contact Type Typ kontaktu Status Aktivní/neaktivní záznam Time Zone Časová zóna Telephone number Primární tel. číslo Fax Number Fax Pager Phone Number Pager Alternate Phone Number Mobil Email Address Email Pager Email Address Pager email Notifications Low Metoda notifikace při nízké prioritě Notifications Normal Metoda notifikace při normální prioritě Notifications High Metoda notifikace při vysoké prioritě Notifications Emergency Metoda notifikace při urgentní prioritě Workshifts for Notification Low Pracovní směna pro notifikace low Workshifts for Notification Normal Pracovní směna pro notifikace normal Workshifts for Notification High Pracovní směna pro notifikace high Workshifts for Notification Emergency Pracovní směna pro notifikace emergency Location Fyzická poloha Functional Organization Organizace pro skupinu Contact Notes Poznámky pro skupinu javascript:void(0) 30 4.2.4 Lokalita Systém SD bude udržovat seznam lokalit, který je popsán následovně. Zdrojem pro data je informační systém Helios. 4.2.5 SLA Systém SD bude udržovat seznam typů SLA dle následujícího seznamu: Název parametru Popis Name Název organizace Site Poloha organizace Timezone Časová zóna Record status Stav - aktivní nebo neaktivní Primary Contact Primární kontakt organizace Description Popis organizace (text) Address 1 Řádek pro adresu Address 2 řádek pro adresu Address 3 Řádek pro adresu Address 4 řádek pro adresu Address 5 Řádek pro adresu Address 6 řádek pro adresu City Město State/Province Stát - provincie ZIP / Postal Code PSČ Country Země Název parametru Popis Name Jméno Workshift Pracovní směna Timezone Časové pásmo Reaction Reakční doba Solution Doba dodání řešení Defect fix Doba opravy pro případ defektu Warning Doba varování před porušením SLA 31 4.3 Konfigurační management Bude vytvořena konfigurační databáze, kde budou udržovány všechny instalace produktu. Jedna konfigurační položka tak bude odpovídat jednou nainstalovanému software, ve většině případů tedy jednomu zákazníkovi. Případy, kdy tomu tak nebude, budou zejména velké společnosti, které mají pobočky na různých místech světa. Každá konfigurační položka na sobě ponese následující informace: Kromě importovaných dat bude konfigurační položka vztažena na organizaci, vlastnost lokality (viz kapitola 4.2.1) a na SLA (viz kapitola 4.2.5). Název parametru Popis Name Název Class Třida pro konfigurační položku Family Skupina (rodina) pro konfigurační položku Active? Aktivní/neaktivní konfigurační položka Is CI? Zdali je konfigurační položka skutečně konfigurační položkou Primary Contact Primární kontakt pro konfigurační položku Location Lokace pro konfigurační položku Service Type SLA pro konfigurační položku Version Verze Release Release Terminal Type Typ terminálu Organization (Customer) Zákazník Vendor (Partner) Partner License Počet licencí Expiration Date Datum vypršení SLA OS Platform Platforma operačního systému Note Poznámka Status Stav konfigurační položky 32 4.3.1 Založení konfigurační položky Konfigurační položka může být založena dvěma způsoby: 1. Ruční založení konfigurační položky – v systému pro SD bude možnost založit novou konfigurační položku vyplněním příslušného formuláře. Možnost založit novou konfigurační položku má i partner. 2. Automatické založení konfigurační položky – bude do systému pravidelně importováno z informačního systému Helios. Aktualizace dat potom bude probíhat periodicky, automatizovaně každý den. 4.3.2 Změna konfigurační položky Změny konfiguračních položek bude možné provádět pomocí žádosti o změnu, ale častějším případem bude automatická změna při změně konfigurační položky v průběhu incidentu. Typickým scénářem pak je situace, kdy partner povýší systém zákazníka na vyšší verzi a toto zapíše při uzavírání incidentu (viz kapitola 4.4.4) či v průběhu jeho řešení. 4.4 Management incidentů Proces managementu incidentů prošel úpravami zejména ve stránce přiblížení standardu, tedy jasnější rozčlenění pojmů incident, žádost o podporu, žádost o informace. Níže je uveden návrh procesu managementu incidentů – popisuje životní cyklus incidentu a možnosti přechodů mezi stavy. 33 Obrázek 7 - Životní cyklus managementu incidentů7 4.4.1 Založení incidentu Pro založení incidentu je možné využít jeden z následujících kanálů:  Webové rozhraní systému SD,  telefonní kontakt,  emailová adresa. Po prvním kontaktu je založen tiket buď pracovníkem společnosti, analytikem, nebo přímo partnerem skrze webové rozhraní. 7 Oranžová aktivita je ta, kde se nepočítá SLA 34 Je možné založit několik typů incidentů: Při zakládání incidentu jsou od partnera požadovány následující informace:  kontaktní osoba,  kontaktní telefon,  konfigurační položka (reference v rámci systému),  kategorie incidentu,  stručné shrnutí incidentu (odpovídá předmětu emailu),  popis incidentu,  urgenci incidentu,  uživatel postižený incidentem,  datum a čas posledního výskytu incidentu,  postižené zařízení (IP adresa či jiná identifikace),  kontrola verze produktu (je automaticky vyplněna dle konfigurační položky),  přesná verze sestavení produktu (je automaticky vyplněna dle konfigurační položky),  přiložit k incidentu jeden nebo více souborů. Dále se automaticky generují následující atributy:  jednoznačné identifikační číslo,  datum a čas vyřešení incidentu,  čas a datum uzavření incidentu,  komentáře. Přiřazení SLA je důležitým krokem při zakládání incidentu, protože je jedním z prvků vstupujících do rovnice pro výpočet priority. Toto přiřazení je provedeno na základě atributu uloženého na konfigurační položce, v konfigurační databázi. V rámci založení incidentu je také nutné vybrat odpovídající konfigurační položku, kde se incident projevil. Bude také možnost založit incident bez vybrání konfigurační položky, což je Požadavek typu Popis Hlásím poruchu/závadu Porucha, závada hw nebo sw, kterou je nutné co nejdříve odstranit. Požaduji podporu Požadavek na podporu, kdy zákazník/partner požaduje změnu konfigurace sw. Navrhuji změnu Požadavek na změnu, kdy zákazník/partner požaduje provést zásadní úpravy v konfiguraci HW nebo SW, v postupu, funkcionalitě apod., které nejsou vyvolané okamžitým výpadkem nějaké komponenty sw. 35 způsob, jak postihnout například testování produktu partnerem ve své laboratoři. Konfigurační položka udržuje informaci o aktuální verzi produktu, která ale nemusí být aktuální v době hlášení incidentu. Typickým scénářem je situace, kdy partner ví, že určitý problém je možné vyřešit přechodem na novější verzi, tu aplikuje, ale neaktualizuje informaci na konfigurační položce. V tomto případě bude informace aktualizována při první interakci SD a příslušné konfigurační položky. Na základě kontaktní osoby zadané v poli „Zadavatel“ bude zvolena příslušnost k organizaci. Při vytváření tiketu je také nutné vybrat kategorii, do které spadá. Tato kategorie je později využita ve statistikách (viz kapitola 6.2) pro určování trendů či k informaci pro oddělení vývoje, na kterou komponentu se zaměřit při optimalizaci uživatelské zkušenosti. Očekávaný počet nových incidentů je 150/týden. 4.4.2 Přidělení incidentu řešiteli Existují dva různé přístupy, jak systém SD využívat, jak přiřazovat tikety řešitelům. Jedním je již používaný systém ručního přiřazování samotnými řešiteli, tedy systém, který byl využíván před implementací systému SD. Tento postup je blíže popsán v kapitole 3.5.2. Další možností je automatické přiřazení řešiteli na základě jeho příslušnosti do skupiny a přítomnosti (dle indikátoru, jenž lze nastavovat). V tomto případě je potom každý tiket v každé chvíli přiřazen (má řešitele) a to i v případě, že není řešen nebo je ve stavu čekání na odpověď. Z důvodu struktury organizace a pracovní náplně řešitelů je zvolena první varianta, tedy stejná, jako je zmíněna v kapitole 3.5.2. popisující současný stav. Důvodem je fakt, že řešitelé se nevěnují dedikovaně jen práci se systémem SD, ale mají i jiné povinnosti, které znamenají zamezení přístupu k systému. V případě aplikování postupu zmíněného jako druhý by se poté mohlo stát, že zůstanou tikety s nebo před vypršením SLA přiřazeny na osobu, která nebude mít možnost je řešit. Tato komplikace by pak musela být ošetřena na procesní úrovni, což ale není možné podpořit zvoleným systémem SD. Tikety jsou tedy umístěny v bazénu, kategorizovány podle priority (její výpočet je popsán v kapitole 4.4.2.1) a ručně rozebírány řešiteli. 4.4.2.1 Výpočet priority Kalkulována dle definované matice na základě SLA a urgence. Kalkulace nezohledňuje stáří incidentu. Konkrétní implementace je zobrazena v následující tabulce. Typ incidentu Platinum SLA Gold SLA Silver SLA Bez SLA Kritický incident 1 1 3 4 Podstatný incident 1 2 3 5 Nepodstatný incident 2 3 4 5 Požadavek 2 3 4 5 36 4.4.3 Řešení Bude upuštěno od původního konceptu emailové komunikace. Tiket bude přístupný pouze prostřednictvím webového rozhraní systému SD. Stejným způsobem budou prováděny všechny změny stavů a parametrů. Partner bude mít ale zachovanou možnost na incident odpovědět emailem – důvodem je urychlení a zefektivnění komunikace. Vždy, když je incident ve stavu řešení, je status tiketu změněn na „V řešení“, čímž je pro ostatní řešitele indikováno, že tento tiket nemají začínat analyzovat. Také partner vidí změnu tohoto stavu, což je prostředek jak zefektivnit komunikaci mezi zadavateli a řešiteli. Akce ve stavu „V řešení“ umožňují: 1. Výkaz práce. Řešitel má možnost vykázat, že na řešení tiketu trávil čas a komentovat (i interně) svá zjištění. 2. Přidat interní komentář – tedy komentář, který uvidí jen řešitelé. 3. Přidat externí komentář – tedy komentář, který uvidí i partner, ale nebude změněn stav tiketu. 4. Odeslání odpovědi partnerovi. 5. Odeslání řešení partnerovi. Pakliže partner řešení přijme, je incident uzavře.. Pokud ne, dostává se do stavu, kdy opět čeká na řešení (stav „Zodpovězený partnerem“). 6. Žádost o konzultaci na oddělení vývoje. 7. Žádost o konzultaci na obchodním oddělení. 4.4.4 Uzavření incidentu Při uzavření incidentu bude probíhat kontrola zařazení kategorie, bude se vyplňovat políčko určující, co bylo příčinou incidentu (kód či kategorie uzavření). Toto políčko bude později sloužit ke sledování trendů. Také bude provedena aktualizace konfigurační položky, pokud proběhla změna (například ve chvíli, kdy byl incident vyřešen nahráním nové verze software). Důležitou změnou vůči předchozí implementaci procesu managementu incidentů je fakt, že incident je uzavírán partnerem a ne řešitelem. Tento koncept lépe odpovídá jak logice věci (kdo tiket otevírá jej i uzavírá), tak konceptu ITIL. 4.4.4.1 Upomínka Pakliže partner nepotvrdí řešení (uzavřením tiketu) nebo nedodá požadovaná data, je tiket automaticky přesunut do stavu „Upomenutý“ a partnerovi je zaslána notifikace. Termín pro takovou upomínku je nastaven na 2 týdny, důvody jsou stejné, jako je popsáno v kapitole 3.5.4. Do stavu „Upomenutý“ se lze dostat ze stavu „Zodpovězený řešitelem“ nebo „Vyřešený“. Po dalším časovém intervalu, který je opět nastaven na 14 dnů, je tiket automaticky uzavřen. 37 4.4.5 Identifikace defektu Při řešení incidentu se v určitých případech stane, že službu nelze obnovit bez vydání opravy, tedy bez zásahu do kódu. Tento zásah do kódu je řízen managementem změn (blíže popsáno v kapitole 4.6), stejně tak SLA je nastaveno dle definice (příloha č. 1). Incident zůstává až do vydání opravy otevřen ve stavu konzultace s oddělením vývoje. Od běžné konzultace je potom možné jej odlišit díky přiřazenému a otevřenému změnovému tiketu. 4.4.6 Eskalace incidentů Pakliže se blíží porušení SLA, je na tiket upozorněn vedoucí skupiny. Také operátor má ve svých povinnostech takové tikety kontrolovat a zajistit jejich vyřešení či zodpovězení před porušením SLA. Upozornění formou emailu je provedeno 1 hodinu před vypršením SLA, případně až se tak stane. Jestliže je SLA porušeno, je upozorněn jak vedoucí skupiny, tak vedoucí oddělení zákaznické podpory. 4.4.6.1 Vzdálená podpora Systém SD (konkrétně CA Service Desk Manager R12) umožňuje vzdálené připojení k zákazníkovi a je tedy možné upustit od používání systémů třetích stran. Limitací integrovaného systému je fakt, že nepodporuje běh na dvou monitorech, vždy je zobrazen pouze aktivní monitor. Toto je bohužel limitace natolik závažná (ze zkušenosti současných řešitelů), že znemožňuje nasazení integrovaného systému podpory. Do jejího vyřešení nebude tato možnost partnerům nabízena. 4.4.7 Plnění SLA SLA je definováno v příloze č. 1 a jeho plnění je implementováno do systému SD ve formě notifikací a měnících se stavů. Tyto stavy jsou měněny na základě plnění SLA (tedy porušeno/neporušeno/blížící se porušení). Ne ve všech stavech procesu managementu incidentů je ovšem odpočítávána doba do porušení SLA. Níže jsou uvedeny stavy procesu managementu incidentů a k nim náležící stav SLA. 38 4.4.8 Role Operátor Nový proces managementu incidentů stále obsahuje roli operátora. Ta má obdobné pravomoci a povinnosti, jako jsou popsány v kapitole 3.5.4. Jednou z nejdůležitějších povinností je potom notifikace o vydání oprav, protože procesy managementu incidentů a změn nejsou provázány. Jakmile tedy vyjde oprava (emailová notifikace), operátor projde všechny tikety, ke kterým se tato váže a notifikuje partnery o dostupnosti. Role operátora ovšem nově neobsahuje povinnost rozesílat upomínky, což je řešeno automatickým systémem, který je blíže popsán v kapitole 4.4.4.1. 4.5 Management problémů Tento proces není implementován. Je plně nahrazen managementem změn a incidentů. Hlavní roli v takové implementaci hraje zejména fakt, že příčina či defekt je odhalen již v rámci managementu incidentů. 4.6 Management změn Tento proces je implementován v totožné formě, jako je popsáno v kapitole 3.7. Tedy i nyní bude oddělení vývoje využívat informační systém Polarion, nicméně do budoucnosti jsou zvažovány plány přechodu na systém SD, který je pro vývoj software navržen a bylo by tak možno využít jeho potenciálu.. Stav procesu Plnění SLA Nový SLA se počítá Přiřazený SLA se počítá V řešení SLA se počítá Konzultace s obchodním oddělením SLA se počítá Konzultace s oddělením vývoje SLA se počítá Vyřešený Počítání SLA pozastaveno Zodpovězený řešitelem Počítání SLA pozastaveno Zodpovězený partnerem SLA se počítá Upomenutý Počítání SLA pozastaveno Uzavřený Počítání SLA pozastaveno Management změn SLA se počítá 39 Z řešitelského hlediska je změna založena tak, že se přímo na tiketu patřičného incidentu tato vytvoří a je spárována automaticky. Stále přetrvá ruční práce, kdy je nutné založit tiket v systému Polarion ručně a spárovat s tiketem změny v systému SD. Jakmile je defekt opraven, je operátorem změněn stav změnového tiketu do odpovídajícího stavu. Poté je třeba notifikovat partnera, což je provedeno manuálním odesláním informace o dostupnosti opravy. Podrobnější popis je možné nalézt v kapitole 4.4.8. 4.7 Plnění požadavků V počáteční implementaci budou zahrnuty tyto funkcionality: 1. Žádost o informace. 2. Žádost o vzdálenou podporu. 3. Žádost o službu IT. První dvě formy žádosti jsou převzaty z původního procesu managementu incidentů, třetí je ale novinkou, protože bude sloužit oddělení IT a nahradí tak současné řešení (blíže popsáno v kapitole 3.8). Plnění požadavků nepodléhá plnění SLA. 4.8 Znalostní management Z hlediska znalostního managementu je největším přínosem SD možnost jednotného místa pro informace a znalosti. Je možné jak prohledávat existující tikety, tak využívat rozsáhlé možnosti znalostní báze dat z hlediska integrace do prostředí společnosti. Bude tak umožněno odstranění současného, nepříjemně fragmentovaného způsobu uchovávání informací, kdy každé oddělení disponuje vlastní databází znalostí. Dochází tak nejen k redundanci dat, ale také, což je závažnější, k omezenému sdílení dat mezi jednotlivými systémy. Nicméně ani zavedení systému SD nezajistí úplný přechod na jednotnou dokumentační architekturu. Vývojové oddělení udržuje dokumentaci k produktu a to prostřednictvím webové aplikace společnosti Atlassian – Confluence 8 . Tato dokumentace nebude, zejména kvůli možnostem exportu z Confluence, které systém SD nemá, přenesena do znalostní databáze systému SD. Závěrem tedy je, že znalostní databáze udržovaná v systému SD bude spravovaná oddělením zákaznické podpory v kooperaci s partnery. 8 Více informací lze nalézt na stránkách produktu - http://www.atlassian.com/software/confluence/overview 40 4.8.1 Založení znalostního článku Znalostní článek může být navržen každým uživatelem (případně dle role). Poté proběhne schvalovacím procesem a bude nebo nebude zpřístupněn. Pro založení znalostního článku jsou následující možnosti: 1. Manuální vložení článku pomocí online editoru. 2. Vygenerování článku na základě incidentu, problému či změny. V tomto případě budou k článku mapovány i případné související tikety. Znalostní článek se může nacházet v těchto stavech, což také charakterizuje jeho životní cyklus: 1. Draft – dokument byl vypracován či je vypracováván a čeká na schválení znalostním manažerem či jinou pověřenou osobou. 2. Publikován – dokument je přístupný přes rozhraní systému SD. Dle nastavených oprávnění je možné jej nalézt v závislosti na právech uživatele. 3. Přepracováván – dokument prochází revizí, jsou doplňovány či upřesňovány informace. Je možné nechat veřejnou verzi v původním stavu nebo ji kompletně znepřístupnit až do vydání přepracované verze. 4. Vyřazen – dokument již nemá relevanci, je nepřesný. V tomto stavu končí životní cyklus znalostního článku. 4.9 Výběr platformy implementace SD Tato kapitola ukazuje výběr nejvhodnějšího řešení pro implementaci systému SD tak, aby vyhovoval jak knihovně ITIL, tak současným požadavkům, ale zároveň nabízel i možnosti rozšíření a úprav do budoucna. Výběr proběhne pomocí výběrového řízení, kde bude z doručených nabídek vybrána ta nejvhodnější. 4.9.1 Shrnutí specifikace Základní funkční požadavky byly definovány jak před samotným výběrovým řízením, tak během první fáze implementace a to tak, aby mohly zároveň sloužit jako zdroj pro tvorbu akceptačních kritérií. Specifikace stručně: 1. Systém SD bude provozován v prostředí společnosti XYZ-Tech. 2. Systém SD bude současně využívat 1 administrátor, 1 operátor, 20 řešitelů a 300 koncových uživatelů (partnerů). 3. Systém SD bude implementován s maximální možnou bezpečnostní politikou. Konkrétně se bude jednat o to, že bude provozován vnější server pro přístup partnerů (FrontEnd Server). 41 4. Pro všechna data spravovaná systémem SD (tikety, přílohy, definice SLA, znalostní dokumenty, konfigurační položky, …) bude jednotné úložiště (jedna databáze a jedno umístění na souborovém systému). 5. Bude možnost do systému přistupovat pomocí zjednodušeného rozhraní z mobilního telefonu. 6. Bude možné systém SD rozšířit na cluster bez nutnosti dokupování dalších licencí. 7. Do systému SD bude možné implementovat vnitřní procesy pro management incidentů, management změn, management znalostí, plnění požadavků, konfigurační management a generování statistik. 8. Řešitelé budou mít možnost vzdáleného připojení k partnerovi prostřednictvím rozhraní systému SD. 9. Každý řešitel bude mít možnost zobrazování doby strávené řešením incidentu. 10. Řešitelé budou mít možnost využití znalostních dokumentů. 11. Systém bude umožňovat implementaci SLA, stejně jako návrh a úpravu stávajících. 12. Systém SD bude umožňovat automatické zasílání statistik na emailovou adresu minimálně ve formátech pdf a xls. 13. Zadavatel bude mít možnost plné administrace systému. 14. Systém SD bude umožňovat plné definování rolí včetně přístupových práv k různým částem systému. 15. Systém bude umožňovat integraci s ostatními informačními systémy pomocí webových služeb. 16. SD bude poskytovat emailový konektor na MS Exchange, pro aktuálně podporované verze. 17. Bude možnost napojit SD na SMS bránu pro zasílání notifikací. 18. Během životního cyklu incidentu bude možné zaslat dotazník spokojenosti. 19. SD umožňuje automatickou archivaci historických dat a jejich obnovu v případě potřeby. 20. Dodavatel zajistí školení administrátorů, včetně vybraných řešitelů. Kompletní specifikace je součástí neveřejné části přílohy, viz Seznam příloh. Na základě těchto kritérií je potom volen a hodnocen systém, který se bude ve společnosti implementovat. 4.9.2 Výběrové řízení Samotné výběrové řízení je, bez ohledu na to, zda je podnik povinen jej použít, důležitým krokem po rozhodnutí o realizaci implementace informačního systému dodavatelským způsobem. Řídí se zákonem č. 137/2006 Sb., o veřejných zakázkách. Základním předpokladem úspěchu je stanovení jasných pravidel, na základě kterých bude probíhat jak samotné výběrové řízení, tak následná integrace. 42 Do výběrového řízení pro implementaci Systému SD se přihlásili realizátoři (systémoví integrátoři) s těmito řešeními: 1. CA Service Desk Manager R12 2. CA Service Desk Manager R12 3. CA Service Desk Manager R12 4. OMNITRACKER IT Service Management Center Přesná identita systémových integrátorů není pro potřeby této práce podstatná a i z důvodu zachování obchodního tajemství nebude zveřejněna. 4.9.3 Vícekriteriální analýza Hodnocení jednotlivých nabídek probíhalo na základě vícekriteriální analýzy. Ta ze své podstaty slouží k ohodnocení předem definovaných kritérií jednotlivých variant. Užitím této metody je potom z konečného seznamu variant vybrána ta nejlépe vyhovující, kompromisní varianta. (Brožová, a další, 2005) Jednotlivá kritéria byla zvolena takto a jsou blíže specifikována dále: Číslo kritéria Název kritéria Váha kritéria Jednotka Způsob bodování 1. Cena bez DPH 60 Kč minimum 2. Nabízené funkcionality nad rámec priority 1 20 body maximum 3. Servisní podmínky 10 body maximum 4. Technická podpora 5 Kč minimum 5. Výše smluvní pokuty za nedodržení doby realizace 5 Kč maximum 4.9.3.1 Kritérium č. 1 – cena řešení Váha tohoto dílčího kritéria je 60%. Číslo nabídky Cena [Kč] Bodová hodnota nabídky Vážená bodová hodnota nabídky 1 2 395 000,00 100,00 60,00 2 2 811 920,00 85,17 51,10 3 2 493 072,00 96,07 57,64 4 3 087 595,00 77,57 46,54 43 4.9.3.2 Kritérium č. 2 – nabízené funkcionality nad rámec priority 1 Váha tohoto dílčího kritéria je 20%. Číslo nabídky Nabízení funkcionality nad rámec priority 1 Bodová hodnota nabídky Vážená bodová hodnota nabídky 1 100,00 100,00 20,00 2 100,00 100,00 20,00 3 98,21 98,21 19,64 4 83,71 83,71 16,74 4.9.3.3 Kritérium č. 3 – servisní podmínky 9 Váha tohoto dílčího kritéria je 10%. Číslo nabídky Servisní podmínky Bodová hodnota nabídky Vážená bodová hodnota nabídky 1 14,58 14,58 1,46 2 2,78 2,78 0,28 3 62,50 62,50 6,25 4 100,00 100,00 10,00 4.9.3.4 Kritérium č. 4 – Technická podpora Váha tohoto dílčího kritéria je 5%. Číslo nabídky Technická podpora [Kč] Bodová hodnota nabídky Vážená bodová hodnota nabídky 1 300 000,00 100,00 5,00 2 342 140,00 87,68 4,38 3 773 200,00 38,80 1,94 4 314 093,00 95,51 4,78 9 Podrobnosti není možné pro účely práce zveřejnit 44 4.9.3.5 Kritérium č. 5 – Výše smluvní pokuty za nedodržení doby realizace Váha tohoto dílčího kritéria je 5%. Číslo nabídky Technická podpora [Kč] Bodová hodnota nabídky Vážená bodová hodnota nabídky 1 7 200,00 100,00 5,00 2 2 500,00 34,72 1,74 3 2 500,00 34,72 1,74 4 2 500,00 34,72 1,74 4.9.3.6 Výsledek vícekriteriální analýzy Číslo nabídky Kritérium č. 1 Kritérium č. 2 Kritérium č. 3 Kritérium č. 4 Kritérium č. 5 Výsledek 1 60,00 20,00 1,46 5,00 5,00 91,46 2 51,10 20,00 0,28 4,38 1,74 77,50 3 57,64 19,64 6,25 1,94 1,74 87,21 4 46,54 16,74 10,00 4,78 1,74 79,79 Závěrečné pořadí nabídek: Pořadí nabídky Číslo nabídky Systém SD 1 1 CA Service Desk Manager R12 2 3 CA Service Desk Manager R12 3 4 OMNITRACKER IT Service Management Center 4 2 CA Service Desk Manager R12 4.9.4 Závěr výběrového řízení a volba platformy Jak je uvedeno v kapitole 4.9.3 je vítězem výběrového řízení pro implementaci systému SD řešení společnosti CA - CA Service Desk Manager R12. Z důvodu zachování obchodního tajemství je pro účel této práce zatajena totožnost realizátora implementace systému SD, tedy skutečného vítěze výběrového řízení. V práci bude odkazováno na realizátora či integrátora systému. 45 5 Implementace V rámci této kapitoly jsou rozepsány detaily implementace systému SD v prostředí společnosti. Hlavní zaměření je na méně jasné součásti implementace, tedy ty, které jsou pro zmíněný systém netypické. Konkrétním příkladem takové netypické implementace nechť je kapitola 5.6, popisující implementaci pracovního dne do systému počítání SLA. 5.1 Architektura a topologie Systém CA Service Desk Manager R12 umožňuje instalaci různých komponent na různé fyzické servery. Je například možné mít jeden server pro databázi, další pro autentizaci a ještě jeden pro běh webového rozhraní. Běžnou praxí je také primární a sekundární server. Systém sestává z těchto komponent:  CA Service Desk CMDB  CA Service Desk Knowledge Tools  CA Businness Objects (BOXI)  CA Support Automation  CA Visualizer (CA Technologies, 2010) Konkrétní implementace ve společnosti XYZ-Tech je složena ze dvou nezávislých prostředí. Produkční, které slouží pro samotnou práci a testovací prostředí, které je určeno pro nasazování změn v systému, pro testování funkcionality a verifikaci nastavení. 5.1.1 Produkční prostředí Produkční prostředí společnosti XYZ-Tech sestává ze tří virtualizovaných serverů: 1. databázový server, 2. primární server, 3. sekundární server. 5.1.1.1 Databázový server První jmenovaný je hostitelským systémem pro databázi. Systém umožňuje implementaci jak jedné databáze, tak bezpečnější možnost více uzlů. Tato druhá možnost ze své podstaty umožňuje zamezení ztráty jak dat, tak dostupnosti služby, protože uzly se mohou plnohodnotně zastupovat. Jedná se o aplikační cluster s podporou funkcionality failover v konfiguraci aktivní-aktivní (tedy oba uzly přijímají požadavky současně). 46 CA Service Desk Manager R12 nabízí možnost integrace s několika databázovými servery: 1. Ingres Database, 2. Microsoft SQL Server, 3. Oracle. Konkrétní verze podporovaných databázových systémů je poté možné nalézt v poznámkách ke konkrétnímu sestavení produktu. (CA Technologies, 2008) Obrázek 8 - Možnosti implementace databázové architektury (CA Technologies, 2008) Ve společnosti XYZ-Tech je implementována varianta s jedním databázovým serverem, za využití řešení Microsoft SQL Serveru, v současné implementaci edice Express, která je poskytována zdarma. Důvodem volby tohoto řešení je především schopnost IT oddělení efektivně toto řešení spravovat a snížení nákladů v počátku projektu. Z hlediska implementace existuje možnost migrace implementovaného systému na řešení umožňující vyšší míru zajištění dostupnosti pro případy výpadků. Tím je myšleno zejména povýšení edice a zavedení dalších uzlů serveru. 5.1.1.2 Primární server Primární server je určen pro práci analytiků a operátorů společnosti XYZ-Tech. Je umístěn v interní síti společnosti a není přístupný z vnějšího síťového prostředí. Pro samotný běh je využit operační systém Microsoft Windows Server 2008 edice Standard. Primární server je ten, který přistupuje k databázi. 5.1.1.3 Sekundární server Sekundární server není spravován společností XYZ-Tech, ale z důvodu požadavků na vysokou dostupnost je předán do správy externí společnosti, která se zabývá poskytováním hostingových služeb. Analytici společnosti XYZ-Tech mohou využívat přístup přes sekundární server, je však doporučeno jej nevytěžovat a pro běžnou práci využívat interní primární server. Nicméně se jedná o vhodnou variantu pro případ nedostupnosti vnitřní sítě na obchodních jednáních či podpoře v místě pobytu zákazníka. Nutno podotknout, že v případě výpadku sekundárního serveru nemají partneři možnost se připojit na primární. 47 Sekundární server využívá pro přístup k databázovému serveru rozhraní primárního serveru. Toto řešení umožňuje bezpečné uložení databázového serveru v interní síti společnosti, případně v demilitarizované zóně, kde je poté jednodušší řídit přístupová oprávnění. Obrázek 9 - Produkční prostředí Obrázek 10 - Testovací prostředí 48 5.1.2 Testovací prostředí Toto prostředí je kompletně ve správě společnosti XYZ-Tech a slouží k testování funkcionality a verifikaci a validaci nastavení před jejich aplikací v produkčním prostředí. 5.1.3 Zajištění dostupnosti V rámci produkčního prostředí byly zvažovány scénáře výpadků jednotlivých komponent tak, aby systém poskytnul co nejvyšší možnou míru stability a dostupnost služby. 5.1.3.1 Výpadek sekundárního serveru Tento scénář popisuje výpadek sekundárního serveru. Role Omezení funkcionalit Analytik společnosti Analytik může pracovat na primárním serveru. Partner Partner nemá možnost využívat systém. Obrázek 11 - Zajištění dostupnosti - scénář č. 1 5.1.3.2 Výpadek primárního serveru Tento scénář popisuje výpadek primárního serveru. V tomto případě je celý systém paralyzován, protože pro přístup do databáze je využíván právě primární server. 49 Role Omezení funkcionalit Analytik společnosti Analytik nemá možnost využívat systém. Partner Partner nemá možnost využívat systém. Obrázek 12 - Zajištění dostupnosti - scénář č. 2 5.1.3.3 Výpadek databázového serveru Tento scénář popisuje výpadek databázového serveru. V tomto případě je systém kompletně vyřazen. Role Omezení funkcionalit Analytik společnosti Analytik nemá možnost využívat systém. Partner Partner nemá možnost využívat systém. 50 Obrázek 13 - Zajištění dostupnosti - scénář č. 3 5.1.3.4 Výpadek systému Helios Tento scénář popisuje výpadek informačního systému Helios, který slouží jako hlavní zdroj pro import dat do konfigurační databáze. Funkcionalita systému není dotčena, ale nejsou aktualizována data. V nejkritičtějším případě se tedy může stát, že není správně měřena SLA, protože není v systému SD správně přenesena hodnota. Také nově vytvořené konfigurační položky nebudou dostupné až do první synchronizace. Role Omezení funkcionalit Analytik společnosti Analytik může pracovat na primárním i sekundárním serveru. Konfigurační databáze není aktualizována. Partner Partner může pracovat na sekundárním serveru. Konfigurační databáze není aktualizována. 51 Obrázek 14 - Zajištění dostupnosti - scénář č. 4 5.1.3.5 Výpadek Active Directory Tento scénář popisuje výpadek doménového serveru pro autentizaci analytiků společnosti. Doménové řadiče jsou použity pro autentizaci analytiků. Po jejich výpadku nebude možné se do systému SD přihlásit. Nutno podotknout, že takový výpadek by paralyzoval i společnost jako takovou a je proto maximálně zajištěno, aby k němu nedošlo. V současné době jsou nasazeny 4 doménové řadiče a pro aplikaci tohoto scénáře by musel výpadek postihnout všechny a ve stejnou dobu. Role Omezení funkcionalit Analytik společnosti Analytik nemá možnost využívat systém. Partner Partner může pracovat na sekundárním serveru. 52 Obrázek 15 - Zajištění dostupnosti - scénář č. 5 5.1.3.6 Výpadek Partnerského portálu Tento scénář popisuje výpadek Partnerského portálu, který slouží jako hlavní zdroj pro import přihlašovacích detailů partnerů. Funkcionalita systému není dotčena, ale nejsou aktualizovány informace o přihlašovacích údajích. Například změna hesla se tedy nepromítne až do první synchronizace, případně nově vytvořené kontakty nebudou známy. Role Omezení funkcionalit Analytik společnosti Analytik může pracovat na primárním i sekundárním serveru. Databáze kontaktů není aktualizována. Partner Partner může pracovat na sekundárním serveru. Databáze kontaktů není aktualizována. 53 Obrázek 16 - Zajištění dostupnosti - scénář č. 6 5.1.3.7 Shrnutí Níže je shrnutí zobrazující nominální stupnici dopadů a rizik jednotlivých scénářů. Stupnice je zvolena s ohledem na celkový dopad na uživatele systému. Rizika jsou volena dle výše popsaných skutečností a s ohledem na historickou znalost výskytu podobných potíží. Scénář Omezení funkcionality Riziko Výpadek sekundárního serveru Minimální Nízké Výpadek primárního serveru Kritické Střední Výpadek databázového serveru Kritické Střední Výpadek systému Helios Minimální Střední Výpadek Active Directory Kritické Nízké Výpadek Partnerského portálu Minimální Nízké 54 5.2 Licence Pojem Service Desk popisuje systém, který slouží pro podporu koncových zákazníků nebo interních uživatelů (bližší vysvětlení v kapitole 2.9). Stejně tak je navržen popisovaný CA Service Desk Manager R12 a jeho licenční model. Jsou dva typy licencí: 1. Řešitelská licence – placená licence 2. Licence pro koncového uživatele, tzv. volná licence, která je poskytována zdarma. (CA Technologies, 2011) Jinými slovy neexistuje licenční model pro prostředí, které vyžaduje společnost XYZ-Tech (toto je podrobněji popsáno v kapitole 1.3), tedy prostředí, kde by několik partnerských techniků mohlo sdílet informace o otevřených tiketech v rámci jejich společnosti. V implementaci CA Service Desk Manager R12 pro společnost XYZ-Tech bude třeba využít licence pro koncové uživatele (tedy volné licence) pro partnery a najít řešení pro sdílení dat. Takové řešení je, po konzultaci se společnosti CA Technologies, možné implementovat pomocí možnosti číst z databáze bez nutnosti jakékoliv licence a pomocí této funkcionality spárovat existující partnery s existujícími konfiguračními položkami. K párování je využita příslušnost k organizaci (více v kapitole 4.2.1) V souladu s požadavky CA Service Desk Manager R12 v případě dočasného překročení řešitelských licencí nezamezí přístup dalšímu řešiteli, ale takovou událost uloží pro budoucí audit. (CA Technologies, 2011) Název role Popis licenčního modelu Zákazník Nevyužívá prostředí CA Service Desk Manager R12 a tedy ani nečerpá licence. Vůbec nedisponuje přihlašovacími údaji do systému. Komunikuje s partnerem pomocí prostředků, které si s Partnerem domluví (telefonu či Service desku provozovaném na náklady partnera). Partner Využívá prostředí CA Service Desk Manager R12 a čerpá tak licenci koncového uživatele. Z její podstaty má možnost pracovat s tikety, které sám zadal a pomocí webového reportu vidí i ostatní tikety ve své organizaci (tedy tikety otevřené u svých kolegů). Má možnost zadávat incidenty a další požadavky, využívat vzdálenou pomoc poskytovanou skrze systém. Řešitel Jedná se o zaměstnance společnosti XYZ-Tech, který využívá placenou licenci. Operátor Jedná se o řešitele s rozšířenými oprávněními, který také využívá placenou licenci. 55 5.3 Integrace s existujícími systémy Pro úspěšnou implementaci takto komplexního systému do existující organizace je nezbytné propojit data a definovat autoritativní úložiště. 5.3.1 Active Directory Ve společnosti XYZ-Tech je využívána adresářová služba společnosti Microsoft, Active Directory. V této službě jsou uloženy autentifikační údaje všech řešitelů a odsud budou přebírány. Uživatelé jsou do systému SD importování jednou a poté udržováni ručně. Uživatelé jsou nadále ověřováni vůči doménovému serveru – systém SD obsahuje všechny údaje, kromě hesla. 5.3.2 Existující partnerský portál Partnerská databáze (jinými slovy databáze obsahující data partnerů, jejich vztahy a autentizační údaje) je součástí existující implementace. Je vyvinuta skriptová aplikace, která ověřuje uživatele vůči tomuto stávajícímu řešení. Partneři budou, z důvodu komplikované implementace automatických systémů, do systému SD postupně přidáváni administrátorem. 5.3.3 Telefonní ústředna V rámci implementace proběhne integrace s telefonní ústřednou. Ta musí umožňovat otevřít určitou URL, na základě čehož se bude systém SD chovat. Typickým příkladem takovéto funkcionality je otevření detailu kontaktu na základě volající osoby. Telefonní ústředna také umožňuje vytáčet na základě jednoduchého skriptu a bude tak umožněno telefonování kontaktu pouhým kliknutím na webovém rozhraní systému SD. V současné době je používanou ústřednou model Alcatel-Lucent OmniPCX Office, která tyto požadavky naplňuje. 5.3.4 Helios Green V současné době se jedná o hlavní sklad dat společnosti XYZ-Tech. Tato skutečnost se implementací systému SD nezmění a data se budou pouze kopírovat, v pravidelných intervalech synchronizovat. Z tohoto systému se importují zejména data definující konfigurační položky a definující SLA. 5.4 Pilotní provoz V rámci pilotního provozu probíhá rozsáhlé testování a kooperace s vybranými partnery. Jsou provedeny zejména testy uvedené v následujících kapitolách. 56 5.4.1 Použitelnost systému, testování V této kapitole bylo provedeno testování na různé scénáře práce s incidentem. Tyto scénáře jsou popsány jednoduchým workflow na obrázku, kde jsou znázorněny stavy, ve kterých se tiket nachází. Součástí přílohy (příloha č. 3) je také ukázka, jak takový testovací scénář provést přímo v systému CA Service Desk Manager R12. 5.4.1.1 Testovací scénář č. 1 Jedná se o nejrychlejší variantu incidentu, kdy je incident uzavřen v průběhu telefonního hovoru. Incident jako takový je vytvořen přímo řešitelem a jeho stav je okamžitě nastaven na „Uzavřeno“. Je to v tomto případě jediný scénář, kdy je incident uzavřen řešitelem. Kontrola: Incident je uzavřen. Obrázek 17- Testovací scénář č. 1 Akceptace: ANO 5.4.1.2 Testovací scénář č. 2 Jedná se o nejrychlejší variantu incidentu, kdy je nahlášen například známý nedostatek. Kontrola: Incident je uzavřen. 57 Obrázek 18 - Testovací scénář č. 2 Akceptace: ANO 5.4.1.3 Testovací scénář č. 3 Zde je testováno komplikovanější workflow tiketu. Kontrola: Incident je uzavřen. Obrázek 19 - Testovací scénář č. 3 Akceptace: ANO 58 5.4.1.4 Testovací scénář č. 4 První odeslané řešení partnerovi nepomohlo, ale druhé ano. Kontrola: Incident je uzavřen. Obrázek 20 - Testovací scénář č. 4 Akceptace: ANO 5.4.1.5 Testovací scénář č. 5 Partnerovi je zasláno řešení na základě existujícího článku ve znalostní databázi. Ten jej akceptuje. Kontrola:  Incident je