Modelování činnosti Helpdesk v prostředí ITIL

Transkript

1 Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování Modelování činnosti Helpdesk v prostředí ITIL Analýza aplikace Helpdesk pro správu incidentů podle ITIL Bakalářská práce Autor: Tomáš Mysliveček Informační technologie Vedoucí práce: doc. Ing. Bohumil Miniberger, CSc. Praha červen 2009

2 Prohlášení: Prohlašuji, ţe jsem bakalářskou práci zpracoval samostatně a s pouţitím uvedené literatury. V Praze dne Tomáš Mysliveček

3 Anotace práce: Tato bakalářská práce se zaměřuje na analýzu aplikace Helpdesk pro správu incidentů podle metodiky ITIL. První část přináší obecné informace o metodice ITIL, zejména pak procesu pro správu incidentů. Druhá část přináší návrh procesů fungování Helpdesku a případovou studii nasazení aplikace Helpdesk ve společnosti. Na konci práce je krátké doporučení pro malé a střední podniky. Abstract: Scope of the bachelor work is analyzing of Helpdesk application for Incident Management described in IT Infrastructure Library (ITIL). The first part gives you an overview of the ITIL framework especially about Incident Management process. The second part contains concept of Helpdesk operation and case study for implementing of Helpdesk into a company. There is short recommendation for SMB market at the end of the bachelor work.

4 Poděkování: Děkuji docentu Ing. Bohumilu Minibergerovi, CSc. za jeho vstřícnost, odborné vedení této práce a za jeho rady a komentáře, které mi velmi pomohly při psaní. Dále děkuji mým kolegům, zejména Ing. Janu Tolarovi, za pomoc při zvládnutí problematiky ITIL. Také bych chtěl poděkovat své přítelkyni Sábě za psychickou podporu, bez které bych práci nikdy nedokončil.

5 Obsah 1. Úvod Představení knihovny ITIL Rámcový model ITIL Podpora sluţeb Dodávka sluţeb Plánování implementace správy sluţeb Správa infrastruktury ICT Správa aplikací Správa bezpečnosti Incident management podle ITIL Ţivotní cyklus incidentu Service Desk Typy Service Desk Konfigurační databáze Business analýza aplikace Helpdesk Modelování procesu incidentu Obecný model procesu fungování Helpdesk Návrh modelové aplikace pro Helpdesk Představa řešení Obecné poţadavky Poţadavky na funkci správy poţadavků Business model procesu správy incidentu Analýza požadavků na Helpdesk a jejich řešení Případová studie nasazení Helpdeskového systému

6 Výchozí stav Seznam problémů a jejich dopad na uţivatele Výsledek analýzy Moţné řešení Realizace Přínosy nasazení Helpdesku ve společnosti Výsledky ITIL v malých a středních společnostech Závěr Seznam použité literatury Seznam obrázků Příloha Knihovna ITIL

7 1. Úvod Podpora uţivatelů je vedle standardní správy IT jednou z hlavních aktivit kaţdé IT organizace. Mechanismus aplikované podpory koncových uţivatelů by měl vţdy reflektovat poţadavky uţivatelů resp. odběratelů sluţeb IT. Důleţitým předpokladem pro zajištění správného fungování této podpory je zavedení řízení IT sluţeb, neboli tzv. IT Service Management ve společnosti. Právě touto problematikou se zabývá IT Infrastructure Library (ITIL). ITIL je souborem knih, které tuto oblast pokrývají, a které obsahují soubor nejlepších praktik a zkušeností v tomto oboru. Moje práce má v úvodu za cíl poskytnout obecný přehled o ITILu, a zejména pak o procesu správy incidentů a funkci Service Desk. V následujících kapitolách se jiţ budu zabývat procesem správy incidentů ve společnosti s návazností na Helpdesk. Pokusím se navrhnout obecný proces fungování Helpdesku a uvedu případovou studii nasazení aplikace Helpdesk ve společnosti. Práci ukončím krátkým doporučením pro malé a střední společnosti, které uvaţují o nasazení procesů ITIL. 7

8 2. Představení knihovny ITIL ITIL Information Technology Infrastructure Library (Knihovna infrastruktury informačních technologií) je knihovna svazků popisující rámec nejlepších praktických zkušeností pro poskytování IT sluţeb. V 80. letech byla vytvořena britskou vládní agenturou Central Computer and Telecommunications Agency (CCTA) a čítala více neţ 30 knih postupně vytvářených a zveřejňovaných. Tyto knihy obsahovaly praktické zkušenosti z oblasti informačních technologií, které byly nashromáţděny z řady zdrojů, a to i včetně interních zkušeností dodavatelů informačních technologií a poradenských firem z celého světa. Po začlenění agentury CCTA pod úřad Office of Government Commerce (OGC) byl projekt ITIL dále rozvíjen v rámci poslání úřadu, a to pomoci britskému veřejnému sektoru v otázkách dosaţení efektivity, návratnosti investic a zvyšování úspěšnosti při realizaci projektů. Cílem úřadu nebylo vytvoření komerčního produktu, ale byla to spíše reakce na stále rostoucí závislost vládních institucí na informačních technologiích, která spolu s absencí standardizovaných procedur zvyšovala náklady na projekty a provoz informačních technologií a umoţňovala opakování stále stejných chyb. Cílem tedy bylo shromáţdit nejlepší zkušenosti, které by pomohly řešit danou situaci. S postupem času začalo být zjevné, ţe z rozšíření těchto zkušeností by mohly mít uţitek i organizace v soukromém sektoru. Knihovna ITIL nebyla sepsána pracovníky agentury CCTA, ale byla a je formulována odborníky v jednotlivých disciplínách a poté je pečlivě revidována nejprve Poradní skupinou ITIL a následně recenzenty z řad komunity ITIL. Díky tomuto formálnímu procesu je zajištěna kvalita publikace ještě před jejím vydáním. V roce bylo původních 30 knih zhuštěno do sedmi knih, z nichţ kaţdá se soustředí na jednu konkrétní stránku problematiky managementu informačních technologií. Tento soubor je nadále rozvíjen předními experty, odborníky a významnými osobnostmi z oblasti informačních technologií a v současnosti čítá 9 knih 2. ITIL není ţádným standardem, normou či nařízením. ITIL poskytuje doporučení, návody a architektury odvozené z nejlepších praktických zkušeností a proto nástroje, procesy či personál nemohou být označovány jako ITIL Compliant (ve shodě). Knihovna ITIL byla vytvořena tak, aby byla procesně orientována a přesto poskytovala dostatečnou flexibilitu a 1 V tomto roce byl vydán soubor publikací známých jako ITIL v2. Od roku 2007 je k dispozici ITIL v3. 2 viz. Příloha č. 1 - Knihovna ITIL 8

9 škálovatelnost. Návody, principy a koncepci ITIL mohou přijmout za své malé, střední i velké nadnárodní společnosti, a to pomocí koncepce přijmout a přizpůsobit (Adopt and Adapt). V případě, ţe se společnost rozhodne přijmout koncept ITIL, je třeba si uvědomit, co ITIL je a co není. ITIL není metodologie. ITIL není přesný popis metrik procesů, vazeb mezi procesy či závislostí. ITIL nedoporučuje konkrétní implementaci a nástroje. ITIL není návod pro implementaci v konkrétním prostředí. ITIL není návod pro procesní analýzu, dokumentaci či definice workflow. ITIL je souhrn doporučení. ITIL je operační rámec pro správu sluţeb ICT. ITIL je souhrn doporučených procedur a aktivit prováděných v rámci procesů. ITIL upozorňuje na moţná rizika a náklady. ITIL pomáhá definovat role a odpovědnosti. ITIL pomáhá definovat klíčové výkonnostní indikátory (KPI), poţadavky na znalosti. V současné době je jiţ ITIL zcela samostatným oborem činnosti a podnikání, jenţ v sobě zahrnuje oblasti ITIL Best Practices a Know How poskytované ve formě základních a doplňkových publikací, vzdělávání a certifikace odborné způsobilosti jednotlivců, certifikaci společností (ISO 20000), poskytování konzultačních sluţeb, vývoj a implementaci softwarových nástrojů pro podporu procesů ITSM a mezinárodní platformu profesionálů a odborné veřejnosti Rámcový model ITIL ITIL poskytuje vyčerpávající návody pro všechny aspekty řízení sluţeb IT a na rozdíl od tradičního funkčně-liniového řízení, ITIL přináší moderní, procesně orientovaný přístup k řízení sluţeb IT. Proces řízení je logický sled činností transformujících nějaký vstup na nějaký výstup, přičemţ plnění jednotlivých činností v procesu je zajišťováno rolemi s jasně 9

10 definovanými odpovědnostmi. Kaţdý proces má vlastníka procesu, který je zodpovědný za jeho řízení, monitorování, měření, vyhodnocování a neustálé vylepšování. Všechny procesy jsou navrhovány s ohledem na potřeby zákazníka 3, tzn. kaţdá aktivita, kaţdý úkon v kaţdém procesu musí přinášet nějakou přidanou hodnotu pro zákazníka. Rámec procesů řízení sluţeb IT je podle ITIL nezávislý na jakékoliv platformě. Dokonce je moţné ITIL pouţít i pro navrţení procesů úplně mimo oblast ICT a to v jakékoliv firmě, která podniká ve sluţbách. Vedle výše popsaných charakteristik knihovnu ITIL také charakterizují vlastnosti jednoznačné terminologie a volná dostupnost. Jednoznačná terminologie je někdy málo doceňovanou nebo úplně opomíjenou charakteristikou ITIL, ale jen do té doby, neţ nastane poprvé v praxi nutnost řešit nedorozumění plynoucí z toho, ţe někdo pouţívá stejný termín v jiném významu, neţ je očekáváno. Volná dostupnost znamená, ţe kaţdý si můţe knihy ITIL koupit a procesy řízení sluţeb IT podle ITIL ve svém podniku implementovat, aniţ by musel platit jakékoliv další licenční poplatky. Tato skutečnost mj. přispěla k rychlému celosvětovému rozšíření ITIL. Rámcový model ITIL je představen sedmi moduly představenými na následujícím obrázku. Obrázek 1: Rámcový model ITIL (zdroj: Rudd, 2004) 3 V pojetí ITIL je oddělení IT ve funkci dodavatele a business ve funkci odběratele. 10

11 Obrázek 1 souhrnně znázorňuje prostředí a strukturu modelu ITIL a vztah kaţdého svazku k zákazníkovi a k technologiím. Jak lze vidět, svazek Obchodního pohledu je úzce spjat se zákazníkem a svazek Správa infrastruktury ICT s technologiemi. Srdcem rámcového modelu ITIL jsou svazky Podpora sluţeb a Dodávka sluţeb, které jsou navzájem úzce spjaty v oblasti Správa sluţeb. Těchto sedm svazků představuje jádro knihovny ITIL. Podpora služeb (Service Support) popisuje procesy spojené s kaţdodenními aktivitami podpory a údrţby spojenými s poskytováním sluţeb IT, a to zejména řešení změn, problémů a náhodných událostí. Kniha Podpora sluţeb obsahuje popis funkce Service Desku a procesů podpory sluţeb IT Řízení konfigurací (Configuration Management), Správa incidentů (Incident Management), Správa problémů (Problem Management), Řízení změn (Change Management) a Release Management. Dodávka služeb (Service Delivery) pokrývá procesy spojené s plánováním a dodávkou kvalitních sluţeb IT a zaměřuje se na procesy spojené s delším časovým dopadem a zlepšování kvality dodávaných sluţeb IT. Kniha Dodávka sluţeb obsahuje procesy Řízení dostupnosti (Availability Management), Řízení kapacit (Capacity Management), Správa zachování kontinuity sluţeb IT (IT Service Continutity Management), Řízení úrovní sluţeb (Service Level Management) a Řízení financí pro IT sluţby (Financial Management for IT Services). Plánování implementace správy služeb (Planning to Implement Service Management) zaměřuje se na problémy a úkoly související s plánováním, zaváděním a zlepšováním procesů v organizaci. Tato kniha poskytuje vodítka kde začít při plánování implementace ITIL v organizaci. Správa infrastruktury ICT (ICT Infrastructure Management) pokrývá celou problematiku informační a telekomunikační infrastruktury. Nalezneme zde popis hlavních procesů řízení všech oblastí souvisejících s technologiemi, jako je vyhledání obchodních poţadavků přes nabídkový proces k testování, instalaci, rozšíření aţ k následným operacím a optimalizaci komponent ITC a sluţeb v IT. Správa aplikací (Applications Management) pokrývá celý ţivotní cyklus aplikace od zadání aţ po ukončení s důrazem na jasné poţadavky, definice a implementace s cílem uspokojit potřeby koncového uţivatele v souladu s projekty a strategií businessu. 11

12 Správa bezpečnosti (Security Management) obsahuje procesy plánování a správu definované úrovně bezpečnosti informací a sluţeb IT s reakcemi na bezpečnostní incidenty. Obsahuje rovněţ analýzu a správu rizik a implementaci protiopatření. Obchodní pohled (The Business Perspective) snaţí se pomoci managementu a pracovníkům IT pochopit problematiku poskytování sluţeb IT k businessu Podpora služeb Svazek Podpora sluţeb knihovny ITIL obsahuje sadu procesů kaţdodenních aktivit podpory a údrţby spojenými s poskytováním sluţeb IT a popis funkce Service Desku. Následující obrázek zobrazuje vazby, výstupy a vstupy pro jednotlivé procesy a funkci Service Desk. Obrázek 2: Podpora služeb (zdroj: OGC, 2004) Na obrázku můţeme vidět jak funkce Service Desk vytváří hlavní rozhraní směrem k zákazníkovi a od zákazníka sluţeb IT a hlavní výstupy z kaţdého procesu. 12

13 Funkce Service Desk poskytuje jediný ústřední bod pro kontakt všech uţivatelů sluţeb IT a má na starosti správu všech incidentů, dotazů a poţadavků problematiky sluţeb IT. Poskytuje rozhraní všem ostatním procesům Podpory sluţeb. Proces Správa incidentů (Incident Management) pokrývá správu všech incidentů od zjištění a jeho záznamu aţ po vyřešení a jeho uzavření. Hlavním účelem procesu je co nejrychlejší obnova sluţby do normálního stavu s minimálním dopadem na zákazníka sluţeb IT. Proces Správa problémů (Problem Management) má za cíl minimalizovat nepříznivý dopad incidentů na zákazníky IT a brání opakování incidentů. Dalším jeho cílem je diagnostika podstaty a příčiny incidentů a iniciace případných změn v prostředí. Správa problémů jsou procesy reaktivního a proaktivního charakteru. Reaktivní aspekt se týká řešení problémů vzniklých jedním či více incidenty. Proaktivný aspekt se týká identifikace a řešení problémů či známých chyb předtím neţ incident nastane. Proces Řízení změn (Change Management) slouţí pro účinné a efektivní zpracování změn v provozu sluţeb IT kaţdé organizace. Jedním z klíčových výstupů procesu je výhledový plán změn a ústřední program změn dojednaný se všemi úseky, zaloţený na dopadu na zákazníka IT a naléhavosti. Proces Správa releasů (Release Management) zajišťuje úspěšnou distribuci a nasazení změn do IT infrastruktury. Zajišťuje, ţe oba aspekty (technický i netechnický) budou v souladu. Proces Správa konfigurací (Configuration Management) poskytuje logický model IT infrastruktury a sluţeb pomocí identifikace, řízení, správy a verifikace všech konfiguračních poloţek, z nichţ se IT infrastruktura skládá. V procesu Správa konfigurací je základním prvkem konfigurační databáze CMDB 4. CMDB zachycuje vztahy a propojení všech konfiguračních poloţek, které definují, jak je kaţdá konfigurační jednotka propojena a svázána se sousedními konfiguračními jednotkami. Tyto vztahy umoţňují analýzy dopadů na sousední konfigurační jednotky či sluţbu při selhání konfigurační jednotky. 4 CMDB Configuration Management Database jedna nebo více databází s detailními záznamy o komponentách infrastruktury IT a o dalších důleţitých částech majetku. 13

14 2.3. Dodávka služeb Svazek Dodávka sluţeb (Service Delivery) se zabývá procesy spojenými s plánováním a dodávkou kvalitních sluţeb IT s delším časovým dopadem a zlepšováním kvality dodávaných sluţeb IT. Následující obrázek obsahuje všechny procesy, kterými se zabývá svazek Dodávka sluţeb, s jejich vazbami a doporučenými výstupy. Obrázek 3: Procesy Dodávky služeb (zdroj: Rudd, 2004) 14

15 Základním rozhraním vůči zákazníkům sluţeb IT je proces Správa úrovně služeb (Service Level Management), který převáţně zajišťuje plánování, návrh, smluvní zajištění a dodávku sluţeb IT v odpovídající dohodnuté kvalitě. Hlavním cílem procesu Správy úrovně sluţeb je zajištění rovnováhy mezi poţadavky zákazníků na sluţby a moţnosti IT. Volněji řečeno, dodávat sluţby přesně na takové úrovni, která je poţadována a schválena, tj. ani niţší, ale ani vyšší neţ je třeba. K tomu mu pomáhají dokumenty poţadavků na sluţbu (Service Level Requirements/SLR) a dohody o úrovni sluţby (Service Level Agreements/SLA). Proces dbá na měření, reportování a hodnocení kvality sluţby směrem k zákazníkovi. Další jeho důleţitou rolí je tvorba a údrţba Katalogu sluţeb (Service Catalogue), který poskytuje základní informace o portfoliu poskytovaných sluţeb. Proces Řízení dostupnosti (Availability Management) je zodpovědný za optimální vyuţívání IT prostředků, předpovídání a kalkulaci případných selhání a implementaci takových opatření tak, aby byla zajištěna odpovídající a cenově efektivní dostupnost sluţeb pokrývající poţadavky a potřeby zákazníků. Proces zahrnuje takové aspekty, jako jsou bezpečnost, provozuschopnost, obnovitelnost, spravovatelnost a stabilita. Pro dosaţení cílů proces vyuţívá měření a monitorování dostupnosti klíčových částí IT infrastruktury a sluţeb IT. Řízení kapacit (Capacity Management) zodpovídá za zajištění trvale odpovídající kapacity tak, aby byly splněny všechny poţadavky zákazníků sluţeb IT. Proces na základě poţadavků zákazníků, kapacitních nároků jednotlivých sluţeb IT a informací o kapacitních moţnostech technologické infrastruktury aplikuje vhodná opatření tak, aby poţadovaná kapacita byla dostupná v poţadovaném čase a s akceptovatelnými náklady. Proces pokrývá oblast hardware, software, lidských zdrojů apod. Proces Řízení financí pro IT služby (Financial Management for IT Services) se zabývá evidencí a řízením nákladů spojených s provozem IT a s dodávkou sluţeb IT. Proces je zodpovědný za sledování a hodnocení návratnosti vloţených investic, finanční plánování spojenými s provozem IT a v případě potřeby za účtování dodávky sluţeb IT. Hlavním cílem procesu Správa zachování kontinuity služeb IT (IT Service Continutity Management) je zajištění schopnosti poskytovat sluţby IT o definované úrovni i v případě havárie, katastrofy či jiných událostí. Hlavní pozornost proces věnuje pro zákazníky kritickým sluţbám neboli takovým, které, zajišťují a podporují klíčové aktivity a procesy zákazníků. 15

16 Proces má za cíl identifikovat, řídit a sniţovat rizika a hrozby a připravovat procesy obnovy po havárii Plánování implementace správy služeb Svazek Plánování a implementace správy sluţeb (Planning to Implement Service Management) pokrývá činnost plánování implementace a zlepšování procesů ITIL v organizaci. Zabývá se problematikou kde a kdy začít, organizační změnou, změnou kultury, plánování projektu a programu, definicí procesu a zlepšováním výkonnosti. Jádrem Plánování a implementace správy sluţeb je formální program implementace a řízení procesu kontinuálního zlepšování (Continuous Service Improvement Program dále CSIP). Následující obrázek znázorňuje jednotlivé etapy CSIP. Obrázek 4: Etapy programu plánování implementace správy služeb a průběžného zlepšování CSIP (zdroj: Rudd, 2004) 16

17 V úvodu je stanovena obecná vize IT, coţ je vzájemně dohodnutý dokument mezi zákazníkem sluţeb IT a oddělením IT, který zachycuje záměry a cíle. Dokument obsahuje popis cílu a účelu plánu na kontinuální zlepšování sluţeb v rámci procesů Správy sluţeb. Po stanovení vize je důleţité vyhodnotit růst IT pomocí organizačního modelu, který určuje současnou vyspělost organizace IT z hlediska vize a strategie, řízení, procesů, personálu, technologií a kultury organizace. K posouzení mohou být vyuţity i další techniky jako jsou externí benchmarking nebo vyhodnocení procesů vůči průmyslovým normám či návodům. V další etapě se musí poloţit otázka Kde chceme být, kdy odpověď je shoda mezi zákazníky IT sluţeb a IT na budoucí roli a charakteristikách poţadovaných na organizaci IT. Výstupem je zpráva posuzující nedostatky společně s business case pro CSIP. V této etapě je důleţité identifikovat rychlé cíle (tzv. Quick Wins), které slouţí k zachování akcelerace během projektu. Následně by měl být připraven projekt pro CSIP, a to v rámci etapy Jak se tam dostaneme. V této etapě zvaţujeme otázky, jak hodláme dosáhnout změn, kde začít a jaké součásti jsou podstatné ve vztahu k CSIP. Odpovědi na tyto otázky určují přístup, rozsah a kompetence pro projekt. V poslední etapě, před zahájením projektu CSIP, je nutné dohodnout mnoţinu měřitelných milníků a výstupů, dále pak kritických faktorů úspěchu a klíčových indikátorů výkonu. Tyto oblasti je třeba pravidelně měřit, monitorovat a vyhodnocovat v kaţdém stádiu projektu, aby byl zajištěn celkový úspěch. Po zahájení projektu přichází jeden z nejtěţších úkolů, a to udrţet zaměření a poslání CSIP etapa Jak udrţíme tempo. Jak narůstá rychlost změn, je obtíţnější udrţet zlepšování, a proto vyuţíváme úspěchy rychlých cílů k zachování akcelerace projektu. Během veškerých aktivit CSIP je nutné stále zdůrazňovat a opakovat klíčová témata o zaměření na obchod, obchodní priority a dopady a zajištění souladu mezi IT a zákazníky tak, aby zlepšení realizovala skutečný prospěch pro obchod Správa infrastruktury ICT Svazek Správa infrastruktury ICT (ICT Infrastructure Management) se zabývá procesy řízením infrastruktury ICT, které pokrývají oblasti procesů správy a administrace, návrhu a plánování, technickou podporou a rozmisťováním a provozem. Procesy Správy infrastruktury 17

18 ICT 5 (dále ICT IM) jsou úzce spjaty s infrastrukturou IT a zaměřují se na ty oblasti IT, které jsou nejblíţe aktuálním nástrojům a technologiím znázorněných na následujícím obrázku. Obrázek 5: Oblast Správy infrastruktury ICT a její hlavní rozhraní (zdroj: Rudd, 2004) Procesy ICT IM odpovídají za správu sluţby IT ve všech jejích fázích ţivotního cyklu, a to od návrhu a plánování aţ po její vyřazení. Jednotlivé procesy ICT IM vytvářejí podmínky a rozhraní pro další procesy spojené se sluţbami IT, jako je například fáze provozu a optimalizace, která je v odpovědnosti procesů Podpory sluţeb. Oblast procesů Návrhu a plánování je zodpovědná za všechny strategické otázky spojené s provozem funkce IT. Má na starosti komunikaci se zákazníkem sluţeb IT o budoucích obchodních plánech a společně se zákazníkem a oddělením IT vytváří plány, architekturu a strategie pro zajištění současných a budoucích poţadavků a řešení IT. Technická podpora má na starosti zajištění podpory veškerých sluţeb dodávaných řízením infrastruktury IT tím, ţe je k dispozici nutná podpora, dovednosti a znalosti. 5 V ITIL je správa IT zaloţena na účinném a výkonném řízení čtyř P, personálu, procesů, produktů (nástroje a technologie) a partnerů (dodavatelé, prodejci a outsourcingoví partneři) 18

19 Proces Rozmístění se stará o rozmístění nových a změněných řešení IT do prostředí businessu v odpovídající a dohodnuté kvalitě, nákladech a načasování. Proces se zpravidla zabývá zaváděním projektů a projektovou metodologií. Provoz spravuje a kontroluje provozní sluţby a prostředí IT a zodpovídá za nastavení a optimalizaci všech provozních úseků IT. K tomu vyuţívá všechny dostupné nástroje pro správu tak, aby byly splněny všechny provozní cíle u sluţeb IT a jejich částí tak jak bylo dohodnuto se zákazníkem sluţeb IT a dalších týmů pomocí SLA a OLA Správa aplikací Procesy Správy aplikací (Application Management) poskytují vodítko tradičním přístupem ţivotního cyklu aplikace. Zabývají se vývojem, správou, zlepšováním a v konečné fázi i ukončením aplikace. Cílem procesů Správy aplikací je, aby aplikace respektovala poţadavky Správy sluţeb, tzn., měla by být navrţena a realizována jako provozuschopná, dostupná, spolehlivá, udrţovatelná, výkonná. Fáze ţivotního cyklu podle Správy aplikací jsou poţadavky, návrh, vývoj, nasazení, provoz, optimalizace. Obrázek 6: Životní cyklus aplikace (zdroj: Rudd, 2004) 19

20 Fáze Požadavky (Requirements) obsahuje procesy identifikace funkčních a procesních poţadavků na změnu či novou aplikaci, a to v souladu s poţadavky zákazníka. Ve fázi Návrh (Design) je z poţadavků navrţeno technické řešení. V tomto bodě se také vytváří studie Total Cost of Ownership (TCO) pomocí které se identifikují náklady na vývoj a podporu aplikace. Fáze Vývoj (Build) zahrnuje samotný vývoj aplikace či změn a procesy testování tak, aby byly splněny funkční a procesní poţadavky. Nasazení (Deploy) pokrývá procesy nasazení aplikace do produkce a zaškolení uţivatelů. Procesy fáze Provozu (Operate) se zabývají procesy provozu a dohledu, změnových poţadavků a řešení chyb aplikace. V této fázi také dochází k monitoringu výkonnosti a dostupnosti a mimo to obsahuje procesy na řešení krizových situací. Procesy poslední fáze Správy sluţeb Optimalizace (Optimize) adresují problematiku funkční a výkonové optimalizace. Jsou proaktivně vyhledávána úzká hrdla aplikace, která mohou mít dopad na poţadavky zákazníka aplikace. Procesy Správy aplikací se nezabývají samotným vývojem aplikací či správou sluţeb, proto oblasti Správy aplikací, Vývoje aplikací a Správy sluţeb IT jsou vzájemné a musí být v souladu Správa bezpečnosti Správa bezpečnosti (Security Management) je proces správy definované úrovně bezpečnosti informací, sluţeb IT a celé infrastruktury. Proces Správa bezpečnosti zajišťuje realizaci bezpečnostních poţadavků definovaných v Service Level Agreement (SLA), poţadovaných legislativou nebo předepsanou interní či externí bezpečnostní politikou. Proces je zodpovědný za základní bezpečnostní politiku organizace, která je nezbytná pro zajištění kontinuity správy organizace a její zjednodušení. Proces Správy bezpečnosti se skládá z aktivit, které uskutečňuje buď sám proces Správy bezpečnosti, nebo z aktivit, které jsou procesem Správy bezpečnosti kontrolovány. Protoţe organizace a její informační systémy se konstantně mění, musejí být aktivity procesu 20

21 průběţně revidovány tak, aby zůstaly aktuální a efektivní. Proces Správy bezpečnosti je kontinuální proces a jako takový můţe být měřen pomocí QCD 6. 6 Quality Circle of Deming cyklus zlepšování kvality předloţený E. Demingem, sestávající se ze čtyř kroků: Plan; Do; Check; Act (naplánuj, urči záměr zlepšení; realizuj, uskutečni tento záměr; proveď kontrolu, vyhodnoť dosaţené výsledky; proveď korekce, úpravy, pokud výsledky neodpovídají plánovaným záměrům) 21

22 3. Incident management podle ITIL Incident management neboli správa incidentů je proces svazku Podpora sluţeb. Proces pokrývá správu všech incidentů od zjištění a jeho záznamu aţ po vyřešení a jeho uzavření. Jeho hlavním cílem je obnovení normálního fungování sluţby v co nejkratším čase. Normální stav fungování sluţby je stanoven v SLA (dohoda o úrovni sluţby). Proces se nezabývá hledáním příčin incidentů ani jeho trvalého řešení, toto má na starosti proces správy problémů. Obrázek 7: Základní rozsah procesu (zdroj: Vlčková Denisa, 2008) Vstupem do procesu Incident management je incident, který je definován jako událost, která není součástí standardního provozu sluţby, a která způsobuje nebo můţe způsobit přerušení dodávané sluţby nebo sníţení její kvality. Jako vstupní rozhraní je buď Service Desk nebo jakýkoli dohledový nástroj. Výstupem procesu je vyřešení incidentu. Vedle incidentů by měl proces řídit i ţádosti uţivatelů týkající se IT sluţby, přestoţe ţádost nemá souvislost s dostupností nebo kvalitou sluţby, protoţe tyto ţádosti mají podobný ţivotní cyklus jako incident. Za proces Incident management odpovídá Incident manaţer, který dohlíţí na správné fungování procesu a sjednává nápravu, pokud proces není dodrţován. 22

23 3.1. Životní cyklus incidentu Etapy ţivotního cyklu incidentu jsou identifikace incidentu a jeho zaznamenání, prvotní posouzení incidentu a určení jeho priority, podrobná diagnostika a vyřešení incidentu a jeho následné uzavření. Obrázek 8: Životní cyklus incidentu (zdroj: Vlčková Denisa, 2008) Identifikace incidentu a jeho zaznamenání můţe přicházet proaktivně z dohledových nástrojů nebo zadáním prostřednictvím Service Desk. Během zaznamenání se k incidentu přiřadí veškeré dostupné informace, které jej dokáţou blíţe popsat nebo pomohou při jeho odstranění. Svazek Service Operation obsahuje celou řadu příkladů vhodných atributů. Dalším krokem je prvotní posouzení a určení priority incidentu. Incident je ohodnocen podle matice důleţitosti a tabulky priorit. Klasifikuje se typ incidentu a proběhne jeho eskalace dále k řešení. 23

24 Obrázek 9: Příklad matice a tabulky priorit (zdroj: Vlčková Denisa, 2008) Následují dvě stěţejní etapy ţivotního cyklu incidentu, prošetření, diagnostika a vyřešení a náprava. V těchto etapách jiţ proběhne důsledná diagnostika incidentu a jeho vyřešení. Po akceptování řešení je incident uzavřen. Je důleţité, aby byl záznam o incidentu udrţován aktuální v průběhu celého ţivotního cyklu. Tímto je umoţněno kaţdému členovi týmu podpory dávat zákazníkovi aktuální zprávy o postupu řešení Service Desk Primárním úkolem Helpdesku / Service Desku je kromě role kontaktního centra pro uţivatele resp. rozhraní mezi IT a odběrateli sluţeb, správa, koordinace a řešení událostí/incidentů tak rychle, jak to dovoluje daná situace a zajištění, ţe ţádný s poţadavků či incidentů nebude ztracen, opomenut či ignorován. Jeho další základní činnosti jsou: Příjem, registrace, kategorizace a sledování průběhu řešení příchozích poţadavků Monitorování stavů všech registrovaných událostí Reportování o stavu řešení Informování uţivatelů 24

25 První úroveň podpory V případě potřeby eskalace událostí a koordinace Uzavírání incidentů a potvrzování řešení s uţivateli Obrázek 10: Vstupy a výstupy Service Desku (zdroj: Vlčková Denisa, 2008) Ze strategického hlediska firmy je Service Desk nejdůleţitějším místem v organizaci. Pod Service Deskem mohou dále ve firmě existovat funkce Call centra a Helpdesku. Tyto funkce můţeme definovat následovně. Call centrum má na starosti jen správu uţivatelských volání, disponuje minimálními znalostmi řešených oblastí a zabývá se registrací a kategorizací poţadavků a jejích eskalací. Helpdesk naproti tomu spravuje omezený počet uţivatelských volání a je primárně zaměřen na řešení došlých incidentů. Celé toto zastřešuje Service Desk, který je tedy komplexním rozhraním zahrnující nejen komunikační a podpůrné funkce (Call centra, Helpdesk), nýbrţ i další procesy zaměřené na zefektivnění podpory včetně poskytování dalších sluţeb zákazníkům. Pro podporu Service Desk a ITIL procesů se v praxi nasazují aplikace Helpdesk. 25

26 Typy Service Desk Typ struktury Service Desku závisí na mnoha faktorech, neexistuje univerzální struktura Service Desku, která by vyhovovala všem společnostem. Důleţitým faktorem je její flexibilita. Existují tři typy Service Desku, lokální, centrální a virtuální. Lokální Service Desk Lokální Service Desk nalezne většinou uplatnění u menší firmy nebo v začátcích společnosti. Tento typ řeší pouze lokální potřeby, coţ je postačující do doby, kdy je potřeba rozšířit podporu na další pobočky. Zde pak dochází k duplikování zkušeností a zdrojů. Pokud organizace udrţuje několik lokálních Service Desků, je důleţité zavedení jednotných provozních standardů. Centralizovaný Service Desk Nevýhody lokálního typu Service Desku řeší Centrální Service Desk. Při centrálním uspořádání se všechny poţadavky na sluţby zaznamenávají centrálně na jednom místě. Oproti lokálnímu Service Desku, má centralizace při více pobočkách společnosti, věcné přínosy. Patří mezi ně niţší provozní náklady, konsolidované řízení a lepší vyuţití zdrojů. Virtuální Service Desk Posledním typem je Virtuální Service Desk, který vhodný zejména pro mezinárodní společnosti. Pro sníţení nákladů a zvýšení efektivity podpory IT sluţeb se v tomto případě zajišťuje jediná, globální podpora, která sdílí znalosti, data. Virtuální Service Desk postupuje v rámci stejných definovaných procesů a je pouţíván jeden komunikační jazyk. Virtuální pak v tomto ohledu znamená, ţe neexistuje jedna centrální fyzická lokalizace Service Desku, nicméně podpora navenek jako jednotná vystupuje. Společnosti, které potřebují pro své pobočky zajistit 24-hodinovou podporu, vyuţívají tzv. Follow The Sun metodu. Při této metodě v podstatě dochází k přecházení mezi dvěma a více Service Desky v různých lokalitách tak, aby nemusela v kaţdé lokalitě fungovat podpora celý den, ale aby fungovala globálně 24 hodin. 26

27 3.3. Konfigurační databáze Všechny procesy v rámci ITIL jsou podporovány Konfigurační databází (dále jen CMDB), která má poskytovat informace o konfiguračních jednotkách, jejich atributech, vztazích a s nimi spojených událostech. CMDB, podle ITIL, plní úlohu jediného a centrálního místa, které pro plnohodnotné naplňování své funkce obsahuje aktuální a aktualizované údaje. Naplňování CMDB mají na starosti všechny procesy ITIL. Za správu CMDB zodpovídá proces Configuration Management. Hlavním úkolem CMDB je poskytnout logický model infrastruktury prostřednictvím identifikace, kontroly, údrţby a ověřením verzí všech v organizaci existujících konfiguračních jednotek, včetně jejich vzájemných vazeb. V praxi to znamená, ţe existují různé systémy pro podporu procesů ITIL ve společnosti, které společně vyuţívají CMDB jako úloţiště výše uvedených informací. Obrázek 11: Příklad struktury konfigurační databáze CMDB (Vlčková Denisa, 2008) 27

28 4. Business analýza aplikace Helpdesk Správu incidentů ve firmě má obvykle na starosti Helpdesk. Jedná se o tým lidí, kteří se snaţí, v pokud moţno, co nejkratším čase reagovat na příchozí poţadavky v podobě telefonických volání, hlasových vzkazů, ů a někdy i faxů. Poţadavky přichází buď přímo od uţivatelů, nebo od různých monitorovacích systémů. Na Helpdesk obvykle navazují další stupně podpory a řešení incidentů. Komunikace mezi stupni je ve většině případů řešena pomocí aplikace pro správu incidentů, která slouţí pro evidenci incidentů, monitoringu stavu incidentů a reportingu. Obrázek zobrazuje rámcový model podpory ve firmě. Hlášení událostí/požadavků Uživatelé Systémy Řešení/realizace požadavků První stupeň podpory Druhý stupeň podpory Přesměrování incidentů k dalšímu řešení Helpdesk Interní podpora Řešení/Oprava Realizace požadavků Aplikace pro správu incidentů evidence, monitoring, komunikace Třetí stupeň podpory Externí podpora Dodavatelé Obrázek 12: Rámcový model podpory (zdroj: vlastní úpravy) Prvním stupněm je tedy samotný Helpdesk, který přijímá, zaznamenává incidenty a poţadavky, komunikuje s uţivateli či zákazníky. Helpdesk je často schopen poskytnou základní podporu, např. za pomoci vyhledání ve znalostní databázi či dle předem daných postupů. Helpdesk musí být schopen ohodnotit a kategorizovat incident. V případě, ţe Helpdesk není schopen incident či poţadavek vyřešit, předává incident dále na druhý stupeň podpory. 28

29 Druhý stupeň podpory, obvykle interní podpora společnosti, provede diagnostiku incidentu, sama řeší incident, nebo předává dále třetímu stupni podpory, obvykle externí podpora nebo dodavatel. Celý proces ţivotního cyklu incidentu k výše uvedenému rámcovému modelu Helpdesk je znázorněn na následujícím obrázku. První stupeň Druhý stupeň Třetí stupeň Detekce a registrace Procedura žádosti o službu Ano Žádost o službu? Ne Klasifikace a první pomoc Možno vyřešit? Ne Diagnostika A zjišťování Ano Řešení a oprava Možno vyřešit? Ne Diagnostika A zjišťování Ano Případná další line supportu Řešení a oprava Možno vyřešit? Ne Diagnostika A zjišťování Ano Uzavření Řešení a oprava Obrázek 13: Životní cyklus incidentu ve více úrovních podpory (OGC, 2004) Ke kaţdému stupni je definovaná role Zadavatel - kaţdý uţivatel sluţeb IT, který podává na Helpdesk svůj poţadavek. Zadavatel dodává všechny potřebné údaje pro zaloţení incidentu a kontroluje průběţný stav svého poţadavku. Zadavatelem případně můţe být i systém. Řešitel prvního stupně pracovník Helpdesku, který incident do stanovené doby převezme a provede kontrolu zadání. Při telefonickém zadání hlášení incidentu, provede zadání do HD systému místo zadavatele. Přiděluje incidentu prioritu 29

30 (počáteční urgence incidentu stanovuje zadavatel o změnu urgence můţe poţádat kdykoliv v průběhu řešení), začne řešit incident a do doby stanovené podle SLA na základě priority incidentu zpřístupní řešení zadavateli prostřednictvím Helpdesk systému. Při nemoţnosti řešení v prvním stupni přidělí řešitele dalšího stupně a kontroluje průběţný stav tohoto poţadavku. Má moţnost uzavřít incident. Řešitel druhého stupně obvykle pracovník IT správce aplikace, serveru, apod. incident do stanovené doby převezme a provede kontrolu zadání, incidentu a případně upraví jeho prioritu. Řešitel můţe upravit i další údaje od zadavatele, jako je název systému nebo specifikace chyby. Řešitel druhého stupně začne řešit incident a do doby stanovené podle priority incidentu zpřístupní řešení na Helpdesk systému. Při nemoţnosti řešení ve druhém stupni provede analýzu incidentu a přidělí řešitele třetího stupně. Má moţnost uzavřít incident. Řešitel třetího stupně obvykle externí konzultanti či dodavatelé, incident do stanovené doby převezme a provede kontrolu zadání, začne řešit incident a do doby stanovené podle priority incidentu zpřístupní řešení na Helpdesk systému a uzavírá incident Modelování procesu incidentu Helpdesk je ve Správě incidentů popisován jako sluţba, která je podporována souborem procesů, popisující ţivotní cyklus incidentu ve společnosti od jeho přijetí aţ po uzavření. Helpdeskový systém slouţí pro podporu činnosti Helpdesku a převáţně slouţí k evidenci a sledování přijatých incidentů. Systém musí zajistit, ţe ţádný z incidentů nebude během procesu ztracen. Helpdeskový systém by měl zejména podporovat dodrţování definovaných procesů. Domnívám se, ţe pokud chceme nasadit Helpdeskový systém, musíme nejdříve stanovit poţadované procesy správy incidentů. Nyní se pokusím navrhnout proces správy incidentů ve společnosti a následně navrhnout aplikaci, která bude tento proces podporovat. 30

31 Obecný model procesu fungování Helpdesk uživatel Help Desk operátor 1. stupeň podpory Registrace incidentu nebo žádosti o službu Přiřazení incidentu nebo žádosti o službu Dignostika & řešení Uzavření incidentu nebo žádosti o službu 5 2. stupeň podpory Dignostika & řešení Incident Manager 4 Escalation Manager Řízení eskalací Obrázek 14: Obecný model procesu fungování Helpdesk (zdroj: vlastní úpravy) Obecný model procesu správy incidentů vychází ze ţivotního cyklu incidentu podle ITIL. Model je navrţen ve dvoustupňové podpoře uţivatelů. V modelu existují ještě další dvě další role. Incident Manager je role, která dohlíţí a odpovídá za správné fungování procesu a případně sjednává nápravu, pokud proces není dodrţován. V našem procesu má na starosti dodrţování dohodnutých SLA k incidentu, kvalifikaci priority incidentu a komunikaci směrem k Escalation Manageru. Escalation Manager jedná se o výkonnou roli, v podstatě to je team leader či projektový manaţer. Escalation Manager dohlíţí na plnění dohodnutých SLA, vytváří řešitelské týmy a navrhuje postupy řešení incidentů. Postup procesu je následovný: Uţivatel registruje incident či ţádost o sluţbu na Helpdesku (proces 1. Registrace incidentu nebo ţádosti o sluţbu). Během tohoto procesu jsou doplněny všechny nezbytné informace. V dalším kroku je poţadavek kategorizován a přidělen ke zpracování (2. Přiřazení incidentu 31

32 nebo ţádosti o sluţbu). Následuje jeho pokus o řešení (3. Diagnostika a řešení) nebo eskalace na další stupeň podpory (4. Řízení eskalací), kde dochází k jeho řešení (5. Diagnostika a řešení) a následně dojde k ukončení (6. Uzavření incidentu nebo ţádosti o sluţbu) a informování uţivatele. Jednotlivé procesy navrţeného obecného modelu jsou na následujících obrázcích. 1. Registrace incidentu nebo žádosti o službu Automaticky generované incidenty Web Telefon Žádost o službu (SR) HelpDesk operátor 1. stupeň podpory 1.1 Přijetí a zobrazení Incident 1.2 Validace Incidentu Odmítnutí Uzavření incidentu Odmítnutí Odmítnutí 1.4 Vytvoření SR 1.3 Přijetí žádosti o službu (SR) Přijetí 1.5 Validace SR Akceptace 1.7 Vyžadována okamžitá eskalace Ne Proces 2 Akceptace 1.6 Doplnění vstupních informací Ano Přiřazení pro Incident Managera Obrázek 15: Proces registrace incidentu nebo žádosti o službu (zdroj: vlastní úpravy) Uţivatel nebo systém generuje na Helpdesk událost o zaloţení ţádosti o sluţbu (dále SR) nebo vytvoření incidentu (1.1). Jedná-li se o incident, proběhne jeho validace (1.2), tzn., proběhne kontrola formální správnosti a oprávněnosti ţadatele. V případě SR, se v úvodu ţádost ohodnotí, zda přísluší danému Helpdesk (1.3) či v případě poţadavku na změnu, je tato změna standardní, tzn., nevyţaduje spuštění procesu Change managementu. Dále následuje akce vytvoření SR (1.4) a proběhne jeho validace (1.5). 32

33 V dalším kroku, jsou případně vyţádány dodatečné informace (1.6) a následuje ohodnocení (1.7) podle priority, závaţnosti či poţadavky doby na řešení. V případě nutnosti eskalace se spouští proces 4. Řízení eskalací, jinak je postupováno podle procesu 2. Obecně v aplikaci Helpdesku jsou akce zastoupeny vstupním formulářem incidentu či SR. V této fázi je velmi vítané napojení aplikace Helpdesku na CMDB. Díky tomu je moţné okamţitě zjistit, jaké dopady má daný incident a případně zaţádat o eskalaci. Také z CMDB jsou automaticky doplňována poţadovaná data k incidentu či SR. 2. Přiřazení incidentu nebo žádosti o službu Proces 1 RFA Request for Action RFC Request for Change RFI Request for Information Ano 2.2 Dokončení pracovní úlohy Ne 2.1 RFA? Monitorování otevřeného požadavku HelpDesk operátor 1. stupeň podpory Ne 2.3 RFC? Ne 2.5 RFI? Ano Ano 2.4 Change Complete 2.6 Informace je dostupná Ano YES Ne Ano Poskytnutí informace žadateli a uzavření Proces 6 Ne Ne 2.7 Požadavek na druhý stupeň podpory? Ne Proces 3 Proces 5 Ano Obrázek 16: Proces přiřazení incidentu nebo žádosti o službu (zdroj: vlastní úpravy) Následuje kategorizace incidentu nebo SR, zda se jedná o ţádost o akci podpory (2.1) či ţádost o změnu (2.3) nebo poţadavek na informace (2.5). Akce podpory (RFA) v tomto případě znamená typizovanou úlohu jako např. obnova dat, reset hesla, apod. Po dokončení úlohy (2.2) je incident či SR posunut do procesu 6. U standardní ţádosti o změnu (RFC) je poţadovaná změna provedena a následně je SR posunut do procesu 6. 33

34 V případě poţadavku na informaci (RFI) poskytne první stupeň podpory informace. Pokud tyto informace nemá, předává dále na další stupeň podpory (proces 5) Tento proces musí, zvětší části provést Helpdesk operátor, v této fázi aplikace slouţí jen k evidenci incidentů a SR. 3. Diagnostika a řešení - první stupeň podpory Proces 2 Proces 3 Proces 6 Přiřazení pro Incident Managera 3.1 Diagnostika a Identifikace řešení 3.6 Známá chyba? Ne Ne 3.11 Eskalace Ano Ano HelpDesk operátor 1. stupeň podpory 3.2 Dostupnost řešení Ano 3.3 Aplikace řešení a jeho zaznamenání Ne Ne 3.5 Kontrola známých chyb 3.7 Dostupný workaround? Ano 3.8 Aplikace workaround a zaznamenání Vyřešeno workaroundem? Ne Ne 3.12 Přiřazení další úrovni podpory Proces Požadavek vyřešen? Databáze znamých chyb Ano Ano 3.10 Doplnění záznamu Proces 6 Obrázek 17: Diagnostika a řešení (zdroj: vlastní úpravy) V další fázi se první stupeň podpory pokusí vyřešit incident na své úrovni. V úvodu proběhne diagnostika incidentu a identifikace řešení (3.1). Ve většině případů k tomu slouţí obecně dané postupy, kdy za pomoci dotazů na uţivatele operátor diagnostikuje problém. V případě, ţe je k dispozici řešení, aplikuje ho (3.3) a zaznamenává informaci k řešení do aplikace Helpdesk a incident ukončuje (proces 6). Před tím, případně, doplní další důleţité informace k incidentu. 34

35 V případě nedostupnosti řešení (3.2) se podpora pokusí vyhledat řešení v databázi známých problémů (3.5), pokud je chyba nalezena a existuje pro ní workaround 7 (3.7), je toto řešení aplikováno (3.8) a případné nové informace zapsány do databáze známých chyb (Knowledge Base). Následuje proces uzavření incidentu (proces 6). Nevyřešený incident je buď eskalován na Incident Managera či předán na další úrovně podpory. Jak je vidět z částí procesu, je vhodné do aplikace zakomponovat znalostní databázi, která následně pomáhá při řešení jiţ objevených chyb. Pro správnou funkci znalostní databáze je však nezbytná disciplína uţivatelů při doplňování informací k incidentům. V praxi se to většinou moc nedodrţuje. 4. Řízení eskalací 4.5 Revize situace 4.8 Vytvoření plánu řešení 4.11 Eskalace vyřešena 4.15 Provedení dalších kroků dle plánu Escalation Manager 4.6 Sestavení eskalačního teamu 4.7 Vytvoření komunikačního plánu 4.9 Aktualizace záznamu 4.10 Provedení plánu řešení Ne 4.12 Aplikace komunikačního plánu 4.13 Stanovení dalšího postupu Ano 4.14 Informace a potvrzení řešení 4.16 Aktualizace záznamu a uzavření Proces 6 Proces 1 Proces 3 Incident Manager 4.1 Evaluace eskalace 4.4 Směrování na Escalation Managera Ano 4.2 Validace eskalace Ne 4.3 Neplatná/ Nekorektní Eskalace Obrázek 18: Řízení eskalací (zdroj: vlastní úpravy) Je-li nezbytná eskalace incidentu či SR, např. při negativním dopadu na dodrţení SLA, je incident eskalován. Incident management definuje pro řízení eskalací Incident manaţera, který je zodpovědný za celý proces správy incidentů. Většinou se jedná o vedoucí Helpdeskového týmu či jím pověřené osoby. Vstupem do procesu eskalace je proces 7 Workaround je pojem označující obejití rozpoznaného problému v IT sytému. Typicky se jedná o dočasné řešení, vyţadující skutečné řešení. Z častého pouţívání workaroundu se většinou stává konečné řešení. ( 35

36 Registrace incidentu nebo ţádosti o sluţbu (proces 1) či Diagnostika a řešení prvního stupně podpory (proces 3). Operátor Helpdesku sám o sobě nemůţe eskalovat incident přímo na druhý stupeň podpory. Důvodem je nutnost naplánovat realizační tým a hlavně naplánovat jeho čas (alokace zdrojů), tak aby řešení problému nenarušilo další činnosti teamu. Incident manaţer ohodnotí potřebu eskalace podle platných SLA (4.1), případně podle dalších kritérií a buď směruje incident či SR na eskalačního manaţera (vedoucí teamu či projektový vedoucí) (4.4), nebo zamítne eskalaci jako neopodstatněnou a vrací incident zpět na řešení prvnímu stupni podpory. Eskalační manaţer zreviduje a seznámí se s situací (4.5), určí realizační team a alokuje jeho zdroje (4.6). Ve velkých společnostech se následně připraví komunikační plán pro případ neúspěšného řešení směrem k zadavateli (4.7) či dalším skupinám ve společnosti. Následuje vytvoření plánu řešení a jeho realizace ( ). V případě, ţe je problém vyřešen, aktualizuje se znalostní databáze o postup řešení, provedou se případné další kroky a incident či SR se uzavírá. V opačném případě se postupuje dle komunikačního plánu (4.12) a stanovují se a případně se realizují další kroky k nápravě aţ do doby vyřešení. Jako podporu činnosti incident manaţera je vhodné zakomponovat do aplikace Helpdesku databázi všech SLA a propojit je s poloţkami v CMDB. Díky tomuto je moţné v krátkém čase vyhodnotit závaţnost eskalace. 36

37 5. Diagnostika a řešení druhý stupeň podpory Proces 2 Proces 3 Proces 6 RFC do Change Management Schválení od Change Management Ano Proces Diagnostika incidentu 5.2 Úspěšná diagnostika Ne 5.5 Nutná rekonfigurace? 2. stupeň podpory Proces 4 Ano Ano 5.3 Eskalovat? Ano Ne 5.6 Provedení řešení 5.7 Řešení bylo úspěšné? Ano 5.11 Zalogování a návrat Ne Ne 5.4 Dostupnost řešení 5.8 Potřeba další podpory Ne Ne Ano Přesměrování na dodavatel Obrázek 19: Diagnostika a řešení (zdroj: vlastní úpravy) Druhý stupeň podpory je více fundovaný ve znalosti systému či problematiky, ke kterým se incident, SR či informace váţe, neţ první stupeň podpory. Pracovník podpory v úvodu diagnostikuje incident (5.1). Při neúspěšné diagnostice, např. systém je tzv. black-box, předává problém k řešení dodavateli. V opačném případě rozhodne, zda je nutné incident eskalovat, např. dostupnost zdrojů. Pokud není nutná eskalace, zjistí nebo navrhne řešení. V případě, ţe pro řešení incidentu je nezbytná rekonfigurace systému, vytváří se událost pro procesy Change managementu. Následuje provedení řešení (v případě rekonfigurace, incident čeká na schválení řešení) a při jeho úspěšném dokončení je řešení popsáno a incident vrácen zpět na Helpdesk (proces 6). Aplikace Helpdesku zde slouţí k evidenci incidentů a podpoře procesu. 37

38 6. Uzavření incidentu nebo žádosti o službu Proces 2 Proces 3 Proces 4 Proces Vyřešen Incident/SR? Ne První stupeň podpory Proces 3 HelpDesk operátor 1. stupeň podpory Ano 6.2 Aktualizace záznamu 6.4 Aktualizace & Přeřazení Ne Druhý stupeň podpory Proces Řešení verifikováno a akceptováno Ano 6.5 Uzavření Incidentu/ Service Request Obrázek 20: Uzavření incidentu nebo žádosti o službu (zdroj: vlastní úpravy) Posledním procesem je uzavření incidentu či ţádosti o sluţbu. Pracovník Helpdesku verifikuje ukončení incidentu či ţádosti o sluţbu a zasílá uţivateli informaci o jeho dokončení. Uţivatel následně akceptuje řešení, čímţ celý proces incidentu uzavírá Návrh modelové aplikace pro Helpdesk Nyní se pokusím popsat, jak by měla taková aplikace podporující činnost Helpdesku vypadat. Návrh vychází z výše uvedeného modelu fungování Helpdesku Představa řešení Chceme vytvořit aplikaci pro podporu navrţeného modelu fungování Helpdesku. Aplikace by měla umoţňovat registraci incidentů nebo ţádostí o sluţbu. Zadavatelé incidentů by měli mít moţnost zadávat incident pomocí formuláře, zobrazit si stav otevřených incidentů. Zadavatel můţe během doby incidentu doplnit údaje nebo incident stornovat. 38

39 Po odeslání incidentu nebo SR se incident musí objevit na konzoli operátora Helpdesku. Operátor schvaluje SR jiţ v úvodu procesu. Operátor doplní informace k incidentu, kategorizuje incident a přiděluje incident k vyřešení. K systému přistupují další členi podpory. Ti mají právo zobrazit si seznam incidentů přidělených jim nebo jejich skupině. Mohou doplňovat postupy řešení, měnit stav incidentu, přidělit incident jiné skupině a incident uzavřít. Incident vţdy musí mít vlastníka. V průběhu řešení poţadavku musí aplikace umoţnit proces eskalace, tj. předání poţadavku vedoucí pozici, která má moţnost vytvořit tým řešitelů. V praxi to znamená, ţe poţadavek můţe mít i několik vlastníků. Uzavřít tento poţadavek můţe jen vedoucí eskalační skupiny. Členi mohou poţadavek upravovat. Systém musí umoţnit vytváření reportů a sledování kvality řešení incidentů. Systému by měl obsahovat znalostní bázi, kterou můţe kdokoli z podpory aktualizovat. Znalostní báze by měla mít funkci vyhledávání. Systém automaticky hlídá dobu plnění incidentu a SLA k incidentu, o nedodrţení informuje vedoucího skupiny. Systém musí umoţnit správu uţivatelů a napojení na CMDB, odkud získává informace o všech konfiguračních jednotkách a jejich atributech. Následující odstavce sumarizují všeobecné poţadavky společností na Helpdeskový systém pro správu incidentů Obecné požadavky Přesně definované rozhraní mezi koncovými uţivateli, pracovníky technické podpory a dodavateli. Zajištění důslednosti a jednotnosti dokumentace poţadavků na řešení problémů. Zajištění sledování plnění závazků uvnitř IT organizace. Sjednocení způsobu komunikace se všemi dodavateli. Zajištění informovanosti o stavu a změnách systému a o řešení problémů. Vytvoření znalostní báze známých řešení opakujících se poţadavků. 39

40 Vytvoření zdokumentovaných předdefinovaných postupů řešení poţadavků. Zajištění souhrnného reportování spolehlivosti a úrovně poskytovaných sluţeb. Automatizace správy problémů a poţadavků: o předdefinované události, o navazující akce (např. upozornění), o předdefinované eskalační procedury a havarijní plány. Moţnost integrovat další systémy. Lokalizace produktu Požadavky na funkci správy požadavků Záznam poţadavku na řešení. Identifikace zasaţených uţivatelů a znalost konfigurace jejich IT prostředí. Sledování stavu řešení poţadavku. Přidělování řešení poţadavku informatikům a správcům aplikací. Evidence historie aktivit spojených s poţadavkem nebo uţivatelem. Řazení poţadavků do příslušné fronty podle typu nebo priority. Sledování otevřených poţadavků. Hierarchie a souvislosti poţadavků spojených s poţadavkem se společnou příčinou. Varování při neřešení poţadavků či při překročení garantovaných servisních parametrů. Vytváření znalostní báze známých řešení, opakujících se problémů. Generování reportů, spolehlivosti objektů správy, vytíţení pracovníků podpory, poţadavků na dodavatele. Uzavření poţadavků na základě definovaných událostí. Definování různé úrovně servisu pro různé systémy s různými prioritami. Sledování dodrţování servisních smluv a dob odezvy. 40

41 Definice SLA dodavatelů. Kontrola SLA dodavatelů Business model procesu správy incidentu Následující obrázek představuje přepracovaný model procesu správy incidentu, zobrazený pomocí notace diagramu procesních řetězců z metodiky Select Perspective. Tento business model vychází z předchozího návrhu procesů fungování Helpdesku a vychází z vlastních zkušeností nasazování Helpdesku. Obrázek 21: Business model procesu správy incidentu (zdroj: vlastní úpravy) 41

42 5. Analýza požadavků na Helpdesk a jejich řešení Zavedení procesů správy sluţeb IT (dále ITSM), implementaci podpůrných procesů a SW nástrojů nelze povaţovat za jednorázovou aktivitu, ale za dlouhodobý rozvojový program, který pomáhá v rámci dílčích kroků maximalizovat podporu aktivit společnosti či organizace prostřednictvím vyváţené skladby kvalitních sluţeb IT. Obrázek 22: Demingův cyklus zvyšování kvality (OGC, 2004) Implementaci procesního řízení IT a principů ITSM do prostředí společnosti není moţné také povaţovat výhradně za doménu IT organizace, ale do procesu zavádění ITSM musí být zaangaţovány všechny klíčové sloţky společnosti, neboť zavedení konceptu dodávky sluţeb IT má v konečném důsledku přímý dopad na všechny organizační sloţky společnosti a kaţdého jednotlivého uţivatele IT. Aplikace koncepce ITSM by proto neměla být zaváděna ţivelně a izolovaně od ostatních sloţek společnosti, ale její zavádění by mělo probíhat vţdy koordinovaně v těsné spolupráci s vedením společnosti, s vedoucími pracovníky jednotlivých organizačních jednotek a se zástupci uţivatelů. Samotnému zavádění ITSM by měla předcházet odpovídající osvětová kampaň v rámci společnosti, v jejímţ rámci by měly být komunikovány přínosy zavedení ITSM a procesního řízení IT, dopady na společnost, vliv na práci jednotlivých uţivatelů, ale i moţná rizika, časový plán zavádění ITSM, odpovědné osoby a další skutečnosti. Před samotným zahájením programu implementace ITSM by měl být také proveden průzkum mezi zaměstnanci společnosti. Tento průzkum by měl být zaměřen primárně na vnímání profilace IT jako dodavatele sluţeb, současné vnímání a 42

43 hodnocení IT a přání a poţadavky uţivatelů, které mohou výrazným způsobem pomoci s hodnocením připravenosti společnosti na zavedení ITSM a s identifikací případných rizik pro zavádění ITSM (např. negativní přístup vůči změnám, lhostejnost, neochota ke spolupráci, nesouhlas s důvody pro implementaci ITSM apod.). Společnost si musí uvědomit, ţe cílem ITSM je maximální provázání sluţeb IT s potřebami společnosti, jejích aktivit a procesů, a to při trvalém zlepšování kvality poskytovaných sluţeb IT a výsledkem zavedení ITSM je redukce dlouhodobých nákladů spojených s poskytováním sluţeb IT. V následující kapitole uvádím příklad analýzy nasazení Helpdeskového systému u zákazníka a jeho výstupu. Domnívám se, ţe tento příklad můţe pomoci při řešení otázky, jak a zda nasadit centrální Helpdesk s podporu ITIL procesů. Z této studie také vychází návrhy procesů v předcházející kapitole Případová studie nasazení Helpdeskového systému Díky svému zaměstnavateli jsem měl moţnost se účastnit analýzy poţadavků na nasazení Helpdeskového systému u velké společnosti s potencionálními uţivateli Helpdeskového systému, vlastním IT oddělením a s početnou základnou externích konzultantů a dodavatelů. Na základě této zkušenosti, jsem v minulé kapitole, navrhl obecné procesy fungování Helpdeskového pracoviště. Nyní se zaměřím na popis analýzy z vlastní zkušenosti. Na této skutečnosti bych rád prezentoval příklad, jakým způsobem postupovat při plánování a nasazování Helpdesk ve společnosti. IT oddělení zákazníka si plně uvědomovalo potřebu standardizované podpory uţivatelů a správy IT a plánovalo komplexní zefektivnění podpory uţivatelů prostřednictvím zavedení Helpdeskového centra, jeţ se mělo stát styčným centrem mezi uţivateli a IT oddělením pro příjem uţivatelských poţadavků, hlášení závad či ţádostí o poskytnutí sluţby. IT oddělení si bylo také vědomo, ţe vybudování takovéhoto centra nelze realizovat bez řádné přípravy, vhodně aplikovaných nástrojů a podpůrných procesů, zejména pak bez odpovídající zangaţovanosti jak pracovníků IT oddělení, tak běţných uţivatelů sluţeb IT. Na základě výše uvedených skutečností byla naše společnost vyzvána k provedení analýzy prostředí společnosti pro nasazení standardizovaného Helpdeskového řešení a související procesní podpory. Cílem analýzy bylo zmapovat stávající úroveň podpory koncových 43

44 uţivatelů, shromáţdit očekávání a poţadavky pracovníků IT a klíčových uţivatelů na Helpdeskové řešení. Dále pak kvalifikovat případná rizika, jeţ by mohla ohrozit či dokonce znemoţnit nasazení takovéhoto řešení. Výsledky analýzy slouţili k výběru odpovídající řešení Helpdesku. V rámci analýzy byly vyuţity následující metody a mechanismy pro zjišťování informací a vyhodnocování získaných dat: typizovaná dotazníková metoda zaměřená zejména na zjištění hlavních poţadavků na Helpdesk, osobní cílené rozhovory, v jejichţ rámci byly zjišťovány informace vztahující se ke kvalitě stávající podpory, očekáváním od nového Helpdeskového pracoviště, odhalování rizik a hodnocení připravenosti společnosti respektive IT oddělení na zavedení standardizovaného Helpdesku, materiály poskytnuté pracovníky IT, metody pro kvalifikaci rizik CRAMM 8, FTA 9, základní kvalifikace procesní podpory prostřednictvím tzv. Capability maturity modelu Výchozí stav Na základě shromáţděných informací bylo moţné zhodnotit úroveň správy sluţeb IT a podpory koncových uţivatelů. Ve společnosti neexistoval jednotný systém zadávání poţadavků a incidentů uţivatelů. Kaţdá pobočka a oddělení měla odlišně nastavená pravidla pro nahlašování poţadavků a incidentů. Podpora zajišťovala sice celou řadu úkolů, avšak v celkovém pohledu značně nevyváţeně, nestrukturovaně a neefektivně. Za kritický problém 8 CRAMM (CCTA Risk Analysis and Management Method) je metodika pro zavádění a podporu systému řízení bezpečnosti informací (Information Security Management System nebo ISMS) pro provádění analýzy rizik informačních systémů a sítí, k návrhu bezpečnostních protiopatření, určování havarijních poţadavků na informační systém a k návrhům na řešení havarijních situací. 9 FTA (analýza stromem poruch) byla vyvinuta v roce 1960 a je nejčastěji pouţívanou metodou při kvantitativním hodnocení rizik procesu. FTA je deduktivní technika, která se soustředí na jednotlivou havárii nebo závaţnou poruchu systému a poskytuje metodu pro určení příčin této události. 10 Capability Maturity Model je model procesní vyzrálosti, který byl vyvinut v polovině 80-tých let Software Engineering Institute (SEI), jako základní metoda pro hodnocení schopností a jakosti pro oblasti systémového a softwarového inţenýrství. Primárním účelem modelu je určení stupně procesní vyspělosti, identifikace nejkritičtějších problémů v oblasti kvality a pomoc při definování strategie zlepšování procesní správy, tj. jak se posunout na vyšší úroveň procesní vyspělosti. 44

45 jsme povaţovali nepřítomnost jasného procesního rámce, jenţ by definoval pravidla, procedury, aktivity a role pro příjem poţadavků, hlášení událostí, jejich řešení či eskalace v případě nevyřešení poţadavku v definovaném čase. Pozitivně jsme hodnotili ochotu pracovníků IT a koncových uţivatelů ke změně, totiţ k nasazení standardizovaného Helpdeskového řešení, a také poměrně jasnou představu o roli a funkcích Helpdesku, jakoţto kvalitativní posun v podpoře koncových uţivatelů a celkový růst efektivity IT. Na základě interview se zástupci uţivatelů, lokálních správců a pracovníků IT bylo zjištěno, ţe existují v podstatě tři způsoby jakými je incident/poţadavek procesován. Schéma řešení uživatelských požadavků/incidentů na pobočkách s lokálními správci Pobočka má jednoho či více zaměstnanců na plný nebo částečný úvazek, jenţ je zodpovědný za podporu uţivatelů v dané lokalitě. Uţivatelé se se svým poţadavkem, incidentem obraceli (telefonicky, em nebo osobně) na příslušného lokálního správce, který jej začal řešit. O úspěšném vyřešení zpětně uţivatele informoval. Pokud na základě svých znalostí a zkušeností nebyl schopen poţadavek, incident vyřešit sám, předal jej pracovníkům centrálního IT. Ti zpětně informovali lokálního správce o jeho vyřešení. Uţivatelé však často lokální správce obcházeli a zadávali poţadavky, incidenty přímo pracovníkům centrálního IT. Přičemţ k nahlášení poţadavků, incidentů a informaci o jejich stavu nepouţívali ţádné předem definované kanály, ale kombinaci telefon, , osobní kontakt. Schéma řešení uživatelských požadavků/incidentů na pobočkách s lokálním týmem lidí Pobočka má svůj tým lidí, součástí jejichţ pracovní náplně je i podpora uţivatelů. V tomto případě je tento tým schopen vyřešit velkou většinu uţivatelských poţadavků, incidentů. Nevyřešené poţadavky, incidenty se převáţně týkaly sluţeb, které jsou poskytovány centrálně. Uţivatelé se v případě poţadavků, incidentů či získání informací o stavu svých incidentů telefonicky obraceli přímo na pracovníky týmu. Pracovníci týmu se pokusili poţadavek, incident vyřešit. Po vyřešení informovali uţivatele. Pokud se jim poţadavek, incident vyřešit nepodařilo, předali jej pracovníkům centrálního IT k vyřešení. Stejně jako v předchozím případu i zde uţivatelé k nahlášení poţadavků, incidentů nepouţívali ţádné předem definované kanály, ale kombinaci telefon, , osobní kontakt. Schéma řešení uživatelských požadavků/incidentů na pobočce bez lokálního správce 45

46 Poslední způsob byl vyuţíván na pobočkách bez lokálního správce. Uţivatelé se obraceli přímo na pracovníky centrálního IT. Uţivatel nahlásil (telefonicky, em nebo osobně) poţadavek, incident přímo pracovníkovi centrálního IT, který jeho poţadavek, incident vyřešil a informoval uţivatele o vyřešení. I zde uţivatelé k nahlášení poţadavků, incidentů nepouţívali ţádné předem definované kanály, ale kombinaci telefon, , osobní kontakt Seznam problémů a jejich dopad na uživatele Na základě informací byly identifikovány následující problémy, jeţ pociťovali uţivatelé při absenci centrálního Helpdesku. Výčet problémů je rozdělen na dvě skupiny a to na problémy, z pohledu uţivatelů a z pohledu řešitelů. Myslím si, ţe ve výčtu problémů určitě nalezne jakákoli firma bez centrálního Helpdesku podobnost. Z pohledu uţivatelů dlouhá čekací doba a špatná komunikace, zastupitelnost lidí uţivatel neví, na koho se má obrátit v případě nepřítomnosti řešitele, dostupnost lidí z centrálního IT, často nejsou k sehnání, neinformovanost uţivatelů o stavu incidentů/poţadavků - nutnost kontaktovat řešitele, aby uţivatel zjistil stav jeho incidentu/poţadavku, Z pohledu řešitelů zastupitelnost lidí - nebyl formalizován systém zastupování a tím pádem mohlo docházet k problémům při řešení incidentů/poţadavků místo kolegů, neexistence systému, který by upozorňoval na procházející termíny např. u ţádosti o změnu, obecně nízké povědomí uţivatelů o IT, různá úroveň znalostí lokálních správců, někteří pracují pouze na částečný úvazek, nemoţnost prosadit standardní konfigurace PC a instalovaného SW, 46

47 uţivatelé si sami mohli instalovat SW (pro prosazení standardních konfigurací PC chyběla podpora ze strany vedení), díky telefonickým a osobním kontaktům nebylo moţné optimálně organizovat práci - řešitelé byli v některých případech uţivateli nuceni věnovat se uţivatelským problémům, i kdyţ měli jiţ naplánovanou práci jinde. Řešitelé tedy nemohli řešit přidělené incidenty/poţadavky podle priority, ale podle toho, kdo je nejvíce urgoval, neinformovanost uţivatelů o aktuálním stavu nahlášených incidentů a podaných poţadavků, nedisciplinovanost uţivatelů - uţivatelé často kontaktovali přímo řešitele a zadávali mu svůj incident/poţadavek a tím vlastně obcházeli své lokální správce, opakující se dotazy - uţivatelé své dotazy často opakovali a tím zbytečně zatěţovali řešitele, neexistence znalostní databáze nutnost hledat řešení ke stejným incidentům opakovaně, neexistence evidence incidentů/poţadavků - ztíţená moţnost předávání incidentů/ poţadavků kolegům, a obtíţné vykazování činnosti Výsledek analýzy V následujícím odstavci jsou stručnou formou představeny hlavní poţadavky na Helpdeskové pracoviště společnosti tak, jak byly tyto zaznamenány v průběhu dotazníkových akcí a osobních rozhovorů. Domnívám se, ţe níţe uvedené poţadavky mohou poslouţit komukoli, kdo uvaţuje o zavedení Helpdesku, jako podklad pro výběrové řízení. integrovatelnost do interního portálu společnosti, online integrace / ověřování uţivatelů s adresářovými sluţbami, jednotné grafické rozhraní, moţnost registrace poţadavků a sledování stavu řešení přes webové rozhraní, moţnost registrace poţadavků a sledování stavu řešení prostřednictvím u, moţnost registrace poţadavků prostřednictvím telefonu, 47

48 moţnost přístupu do systému Helpdesk z PDA zařízení, moţnost přiřazení události konkrétnímu řešiteli prostřednictvím u, standardizované formuláře pro zadávání poţadavků, informativní přehled registrovaných poţadavků / pracovních úloh při přihlášení uţivatele do Helpdesk systému, registrace a klasifikace příchozích poţadavků (incident, ţádost o sluţbu apod.), sledování průběhu řešení přijatých událostí a poţadavků, udrţování kompletní historie řešené události, moţnost přidávat přílohy k registrovaným událostem a poţadavkům, filtrace událostí a poţadavků, podpora eskalačních mechanismů (informování dalších osob o řešení), priorizace řešení událostí a pracovních úloh v závislosti na specifických podmínkách, automatická notifikace v případě vypršení nebo ohroţení termínu řešení, pravidelné celkové statistiky a statistiky upozorňující na neřešené události a poţadavky, SPOC 11 pro netechnologické poţadavky uţivatelů, incident management proces, evidence HW, SW, vytvoření CMDB, správa SLA směrem k externím dodavatelům, lokalizace do češtiny, evidence / uloţení instalačních postupů a návodů, informační nástěnka (plánování výpadků, nedostupnosti některých sluţeb apod.), udrţování znalostní báze. 11 SPOC Single Point of Contact jeden kontaktní bod 48

49 Jako preferované kanály komunikace byly vybrány, telefon (37,5%), mail (37,5%) a intranet (25%) Rizika Jako u kaţdé změny i zde byly identifikovány rizikové faktory, jeţ mohly váţným způsobem narušit, nebo v některých případech dokonce znemoţnit zavedení Helpdeskového řešení do prostředí společnosti. Hlavní identifikovaná rizika ve vztahu k zavedení Helpdeskového pracoviště byly nepřijetí koncepce Helpdesku ze strany IT a uţivatelů, nedostatečná podpora zavedení standardizovaného Helpdesku ze strany vedení, absence potřebných zdrojů, rezistence vůči změnám, absence jasně definovaných procesů pro práci IT a komunikaci s uţivateli, nedisciplinovanost uţivatelů, odmítání koncepce Helpdesku, neexistující jednotná evidence vyuţívaných technologických prostředků a zdrojů, nejednotnost názvosloví a pouţívané terminologie (incident vs. problém vs. poţadavek apod.). Ačkoliv jsou zde nastíněné rizikové oblasti poměrně závaţné, je moţné tyto aplikací vhodných protiopatření zcela eliminovat nebo alespoň výrazným způsobem zmírnit. S ohledem na charakteristiku valné většiny rizikových faktorů lze přitom uvaţovat zejména o opatřeních v rovině sociální, především vhodná osvětová kampaň mezi pracovníky IT, uţivateli a vedením společnosti. Dále pak včasné plánování potřebných zdrojů, definování a komunikaci jednotného komunikačního a procesního rámce a aplikaci vhodných technických opatření sjednocení terminologie, vytvoření jednotné evidence technologických prostředků apod. V rámci všech aktivit vztaţených k nasazení Helpdesku by měly být jasně prezentovány přínosy zavedení Helpdeskového pracoviště (velice přínosné je demonstrovat přínosy Helpdesku na jednoduchých praktických příkladech). 49

50 Možné řešení Na základě zjištěných skutečností a posouzení stavu zajišťování uţivatelské podpory, poţadavků na Helpdeskové pracoviště, rizik a připravenosti IT na zavedení Helpdesku ve společnosti, je vhodné realizovat následující kroky směřující k úspěšnému nasazení Helpdesku. Detailní analýza procesních cyklů uvaţovaných pro budoucí Helpdeskové pracoviště. V kontextu myšleno podrobné zmapování stávající postupů řešení incidentů a poţadavků a výběr těch, které budou pouţity v rámci centrálního Helpdesku. Vytvoření zralostního modelu podpůrných procesů. Jedná se o modelování a popsání vybraných postupů jako podpůrné procesy. Detailní definice hlavních podpůrných procesů, procedur a aktivit pro práci Helpdesku. Definice, které procesy ITIL budou pro společnost vhodné a do nich pak promítnutí vybraných stávající podpůrných procesů společnosti. Výběr vhodného podpůrného SW nástroje. Na základě definovaných procesů vybrat vhodný podpůrný SW nástroj (není nezbytné jeden), který podpoří procesy ve společnosti. Implementace definovaných procesů, SW a Helpdesku. Testovací provoz. Otestování provozu s vybranými uţivateli. Post-implementační review. Důleţitá část, jedná se o revizi nasazení s uţivateli a jejich pohled na Helpdesk, díky němuţ se předchází deziluzi. Korekce postupů. Na základě post-implementační review úprava procesů. Předání do produkčního provozu. Revize a zdokonalování. Průběţná revize a zdokonalování zajišťují správnou funkci Helpdesku a spokojenost uţivatelů Realizace Vzhledem k povaze a rozsahu zjištěných skutečností a s přihlédnutím ke specifikům prostředí společnosti a její aktuální situaci v oblasti zajišťování dodávek sluţeb IT, jsme nakonec 50

51 navrhli realizaci níţe uvedených kroků, které v konečném výsledku poskytly útvaru centrálního IT a společnosti rychlý a odpovídající efekt. Proběhla implementace pracoviště Helpdesku, během níţ proběhl výběr a implementace odpovídajícího SW nástroje. Společně s IT oddělením jsme definovali odpovídající role a odpovědnosti a stanovili základní funkční okruhy Helpdesku. Z procesů byl implementován proces Incident Management a částečně proces Configuration management. Implementace procesu Incident managementu obnášela design, validaci a akceptaci procesu a jeho aktivit. Definici odpovídajících rolí a odpovědností v procesu a jeho zavedení v podpůrném SW nástroji. Proces Configuration management byl zaveden jen částečně s doporučením zavádět tento proces postupně, v limitovaných realizačních krocích (definice základního názvosloví, definice rozsahu a detailu CMDB, postupné plnění CMDB atd.). Důvodem bylo, ţe společnost nedisponovala odpovídajícím procesním, technologickým ani znalostním zázemím pro komplexní nasazení procesu správy konfigurací. Částečným zavedením je myšleno, zadání informací o základních sluţbách IT do SW a doporučením jakým způsobem proces zavést a implementovat CMDB Přínosy nasazení Helpdesku ve společnosti Nasazení centrálního Helpdesku přineslo následující přínosy. Přínosy pro společnost redukce času nutného na zavádění nových sluţeb IT, redukce času nutného na realizaci změn, lepší dostupnost sluţeb IT a podpory pro interní aktivity univerzity, úroveň poskytovaných sluţeb IT definovaná potřebami VŠB-TUO a uţivateli, garantovaná a měřitelná úroveň vyuţívaných sluţeb IT, moţnost vyhodnocování efektivity IT. Přínosy pro uţivatele zvýšení spolehlivosti a dostupnosti odebíraných sluţeb IT, 51

52 lepší podpora kaţdodenních pracovních aktivit, informovanost o řešení poţadavků a událostí, unifikace komunikačních kanálů směrem do IT, garantované zaznamenání poţadavku/události a jejich řešení, garantovaná kompetentní podpora ze strany centrálního IT. Přínosy pro zaměstnance IT lepší produktivita práce, vyváţená alokace IT prostředků a zdrojů, moţnost nabízet různou úroveň sluţeb IT různým interním zákazníkům/uţivatelům, moţnost přesné evaluace vhodnosti vyuţívaných IT technologií, lepší řízení nákladů do IT v návaznosti na poţadavky obchodu na skladbu a úroveň poskytovaných sluţeb IT, lepší řízení vztahů s dodavateli, eliminace přetíţenosti pracovníků IT, jednotná evidence spravovaných IT technologií, jejich atributů a vazeb, centrální evidence všech incidentů/poţadavků vč. jejich kompletní historie a řešení, rychlejší izolace moţných příčin události a jejích moţných konsekvencí. 52

53 6. Výsledky V předchozích kapitolách jsem se snaţil ve zkratce představit metodiku ITIL a následně navrhnout obecný model fungování Helpdesku a jeho procesu. V další kapitole jsem představil příklad výstupu analýzy společnosti před nasazením Helpdesku a rizika s tím spojená. V závěru jsem představil výstup poţadavků na Helpdesk a plán řešení. Doufám, ţe tyto informace budou přínosem pro společnost, která se rozhoduje nasadit proces správy incidentů a centrální Helpdesk. V závěru mé práce bych rád ještě krátce popsal doporučení pro malé a střední firmy, které uvaţují nasazení procesů správy sluţeb IT ITIL v malých a středních společnostech Primární cílovou skupinou pro zavedení procesů ITIL jsou převáţně velké společnosti, pro které byl také původně vyvinut. Pro velké společnosti se procesy stávají nezbytností. Ve velkých společnostech, kde IT podporuje tisíce uţivatelů, jsou procesy nezbytné pro koordinaci toku informací, kontrolu a vyváţení. A k tomu právě slouţí procesy ITILu. V malých společnostech o velikosti desítek či stovek uţivatelů, obvykle IT oddělení čítá jednu aţ tři osoby, které jsou zodpovědné za všechny činnosti podpory IT, jako jsou audit, upgrade a update software, nasazování dalších aplikací a podpora uţivatelů. I zde nalezne ITIL uplatnění. Následující obrázek ukazuje smysluplnost implementace jednotlivých procesů ITSM dle ITIL v závislosti na velikosti IT oddělení společnosti. Obrázek 23: Význam ITSM procesů v závislosti na velikosti IT oddělení (Desiano, 2006) 53