Vysoká škola ekonomická v Praze
Fakulta informatiky a statistiky
Katedra informačních technologií
Obor: Informatika
Hlavní specializace: Informační systémy a technologie
Diplomant: Jan Braverman
Vedoucí diplomové práce: Ing. Ota Novotný, Ph.D.
Recenzent: doc. Ing. Jan Pour, CSc.
TÉMA DIPLOMOVÉ PRÁCE
IMPLEMENTACE METRIK HELP DESK V MALÉ IT FIRMĚ
školní rok 2006/2007
Vysoká škola ekonomická Katedra informačních technologií
Fakulta informatiky a statistiky Školní rok 2005/2006
ZADÁNÍ DIPLOMOVÉ PRÁCE
Jméno : Jan Braverman
Obor: : informační systémy a technologie
Vedoucí katedry Vám ve smyslu nařízení vlády o státních závěrečných zkouškách a státních rigorózních zkouškách určuje tuto diplomovou práci:
Téma : Implementace metrik HelpDesk v malé IT firmě
Osnova:
1. Úvod, vymezení
2. Analýza procesů ITIL pro HelpDesk
3. Navržení modelu metrik vhodných pro měření HelpDesk
4. Popis zákaznického systému malé IT firmy a vytvoření jeho BI nástavby zobrazující navržené metriky
5. Ověření správnosti navržených metrik v praxi 6. Závěry
1. Novotný, O., Pour, J., Slánský, D. – Business Intelligence – ISBN 80-247-1094-3 2. Office of Government Commerce: Service Support (IT Infrastructure Library),
Stationery Office Books, 2000
3. Peter Brooks: Metrics for IT Service Management: ITSM Library, van Haren Publishing, 2006
4. Randy A. Steinberg: Measuring ITIL: Measuring, Reporting and Modeling - The IT Service Management Metrics That Matter Most to IT Senior Executives, Trafford Publishing, 2006
5. www.itil-officialsite.com 6. www.cssi.cz
7. www.itsmf.cz, www.itsmf.com 8. www.gartner.com
Prohlášení
Prohlašuji, že jsem diplomovou práci zpracoval(a) samostatně a že jsem uvedl(a) všechny použité prameny a literaturu, ze kterých jsem čerpal(a).
V Praze dne
……….
podpis
Tato práce si kladla za cíl navrhnout sadu metrik vhodných pro měření funkčnosti a efektivnosti help desk řešení a tuto sadu dále podrobit mutlidimenzionální analýze tak, aby navržené metriky mohly být použity v business intelligence aplikacích. Základním konceptem pro celé řešení byla metodika ITIL, která se již v oblasti IT služeb stala celosvětovým standardem. Z toho důvodu je v práci obsažena i stručná analýza procesů definovaných ITIL, které se zaměřením této práce souvisejí. Pro vyzkoušení a ověření některých z vyvinutých metrik, bylo tyto nasazeny v help desk aplikaci ve firmě autora této práce. Vzhledem k tomu, že řešení bylo aplikováno v malé firmě, bylo třeba předem zúžit navrženou sadu pouze na ty metriky, které jsou ve firmě tohoto rozsahu uplatnitelné.
Veškeré metriky byly také upraveny tak, aby bylo možné je v použité aplikaci implementovat. Závěr práce vyhodnocuje provoz vybraných metrik nad reálnými daty a zkoumá možné způsoby interpretace získaných výsledků.
Abstract
The object of this thesis was to design a set of metrics suitable for measuring functionality and effectiveness of help desk applications and to do a multidimensional analysis of this set in order to make them useful in business intelligence applications. The ITIL methodic was chosen as a basic concept of the whole solution because this methodic is the worldwide standard in the area of IT services. That is why there is also included a short analysis of ITIL processes related to this work. Some of the metrics proposed in the theoretical part of this thesis are implemented in the help desk software in the author’s company to test and validate them practically. The application, where these metrics are used, is rather small and therefore the set of proposed metrics had to be reduced for only such metrics that are applicable in small companies. All of these metrics were also customized in order to make them implementable in this particular solution. In the conclusion of the thesis the usage of chosen metrics with real data is evaluated and possible interpretations of gained results are searched.
OBSAH
1. TÉMA PRÁCE 11
1.1. DŮVOD VÝBĚRU 12
1.2. CHARAKTERISTIKA SOUČASNÉHO STAVU 12
1.3. CÍLE PRÁCE 13
1.4. PŘEDPOKLADY A OMEZENÍ PRÁCE 13
1.5. PŘEDPOKLÁDANÉ VLASTNÍ PŘÍNOSY ŘEŠENÍ 14
1.6. URČENÍ MATERIÁLU 14
2. ANALÝZA PROCESŮ ITIL PRO SERVICE DESK 15
2.1. DEFINICE POJMŮ A SPECIFIKACE LITERATURY 15
2.1.1 INFORMAČNÍ ZDROJE 15
2.1.2 DEFINICE POJMU „HELP DESK“ 16
2.1.3 DEFINICE POJMU „METRIKA“ 17
2.1.4 DEFINICE POJMŮ„BUSINESS INTELLIGENCE“ A „MULTIDIMENZIONALITA“ 18
2.1.5 DEFINICE POJMU „INCIDENT“ 18
2.2. SERVICE DESK 19
2.2.1 VRSTVY 20
2.2.2 STRUKTURA 20
2.2.3 PŘÍNOSY 21
2.2.4 RIZIKA 21
2.2.5 PROVÁZANOST SJINÝMI PROCESY 21
2.3. INCIDENT MANAGEMENT 22
2.3.1 VSTUPY 22
2.3.2 VÝSTUPY 23
2.3.3 ČINNOSTI 23
2.3.4 ROLE A FUNKCE 23
3. VÝCHODISKA PRO NÁVRH METRIK 24
3.1. PETER BROOKS 24
3.2. RANDY A.STEINBERG 27
3.3. GARTNER 30
4. NÁVRH SADY METRIK 33
4.1. DIMENZE 34
4.1.1 ČAS 34
4.1.2 ŘEŠITEL 34
4.1.3 SLUŽBA 35
4.1.4 ZÁKAZNÍK 36
4.1.5 ZPŮSOB ZAZNAMENÁNÍ POŽADAVKU 37
4.2. UKAZATELE 38
4.2.1 VÝDAJE NA SD JAKO PODÍL VÝDAJŮ NA IT[META] 39
4.2.2 NÁKLADY NA ZAVOLÁNÍ [META] 39
4.2.3 POMĚR POŽADAVKŮ VYŘÍZENÝCH BĚHEM PRVNÍHO KONTAKTU [GART5] 40
4.2.4 RYCHLOST ODPOVĚDI NA ZAVOLÁNÍ [BROOKS] 40
4.2.5 DOBA ČEKÁNÍ NA ODPOVĚĎSD 41
4.2.6 POČET HOVORŮ NA JEDEN „PLNÝ ÚVAZEK“SD[STEIN,META] 42
4.2.7 ZAMEZENÉ KONTAKTY [GART1] 43
4.2.8 POČET KONTAKTŮ NA KONCOVÉHO UŽIVATELE [GART1] 44
4.2.9 POČET ZTRACENÝCH/OPOMENUTÝCH POŽADAVKŮ NA SD 44
4.2.10 RYCHLOST NALEZENÍ ŘEŠENÍ VE ZNALOSTNÍ DATABÁZI 45
4.2.11 PRŮMĚRNÁ RYCHLOST NALEZENÍ ŘEŠENÍ VE ZNALOSTNÍ DATABÁZI 46 4.2.12 PROCENTUELNÍ VYUŽITÍ SD VŮČI EXISTUJÍCÍM UŽIVATELSKÝM ÚČTŮM 46
4.2.13 POČET PŘIHLÁŠENÍ DO SD 47
4.2.14 DOBA PŘIHLÁŠENÍ DO SD 48
4.3. VZTAHY MEZI DIMENZEMI A UKAZATELI 48
4.3.1 ČAS 49
4.3.2 ŘEŠITEL 51
4.3.3 SLUŽBA 52
4.3.4 ZÁKAZNÍK 53
4.3.5 ZPŮSOB ZAZNAMENÁNÍ POŽADAVKU 54
5. APLIKACE 56
5.1. POPIS APLIKACE 56
5.1.1 TECHNICKÉ PARAMETRY 57
5.1.2.1 Pohled klienta help desku 58
5.1.2.2 Pohled zaměstnance help desku 59
5.2. VÝBĚR METRIK 62
5.2.1 VÝDAJE NA SD JAKO PODÍL VÝDAJŮ NA IT 62
5.2.2 NÁKLADY NA ZAVOLÁNÍ 63
5.2.3 POMĚR POŽADAVKŮ VYŘÍZENÝCH BĚHEM PRVNÍHO KONTAKTU 63
5.2.4 PRŮMĚRNÁ RYCHLOST ODPOVĚDI NA ZAVOLÁNÍ 64
5.2.5 PRŮMĚRNÁ DOBA ČEKÁNÍ NA ODPOVĚĎSD 64
5.2.6 POČET HOVORŮ NA JEDEN „PLNÝ ÚVAZEK“SD 65
5.2.7 ZAMEZENÉ KONTAKTY 65
5.2.8 POČET KONTAKTŮ NA KONCOVÉHO UŽIVATELE 66
5.2.9 POČET ZTRACENÝCH/OPOMENUTÝCH POŽADAVKŮ NA SD 66
5.2.10 RYCHLOST NALEZENÍ ŘEŠENÍ VE ZNALOSTNÍ DATABÁZI 67
5.2.11 PRŮMĚRNÁ RYCHLOST NALEZENÍ ŘEŠENÍ VE ZNALOSTNÍ DATABÁZI 67 5.2.12 PROCENTUELNÍ VYUŽITÍ SD VŮČI EXISTUJÍCÍM UŽIVATELSKÝM ÚČTŮM 67
5.2.13 POČET PŘIHLÁŠENÍ DO SD 68
5.2.14 DOBA PŘIHLÁŠENÍ DO SD 68
5.3. VÝBĚR DIMENZÍ 69
5.3.1 ČAS 69
5.3.2 ŘEŠITEL 69
5.3.3 SLUŽBA 70
5.3.4 ZÁKAZNÍK 71
5.3.5 ZPŮSOB ZAZNAMENÁNÍ POŽADAVKU 71
5.4. VZTAHY MEZI DIMENZEMI A UKAZATELI 72
5.5. VÝSLEDKY A JEJICH ANALÝZA 73
5.5.1 POMĚR POŽADAVKŮ VYŘÍZENÝCH BĚHEM PRVNÍHO KONTAKTU 73
5.5.2 PRŮMĚRNÁ DOBA ČEKÁNÍ NA ODPOVĚĎSD 76
5.5.3 POČET KONTAKTŮ NA KONCOVÉHO UŽIVATELE 78
5.5.4 PROCENTUELNÍ VYUŽITÍ SD VŮČI EXISTUJÍCÍM UŽIVATELSKÝM ÚČTŮM 80
5.5.5 POČET PŘIHLÁŠENÍ DO SD 82
5.6. NÁVRHY NA ZMĚNU 84
6. ZÁVĚR 85
6.1. DOSAŽENÉ VÝSLEDKY 85
6.2. SPLNĚNÍ CÍLŮ 86
6.2.1 PRVNÍ CÍL 86
6.2.2 DRUHÝ CÍL 86
6.3. OBLASTI MOŽNÉHO ROZŠÍŘENÍ PRÁCE 86
7. ZDROJE 88
8. TERMINOLOGICKÝ SLOVNÍK 90
9. SEZNAM TABULEK 93
10. SEZNAM OBRÁZKŮ 94
1. Téma práce
Pro efektivní řízení současných ekonomických subjektů jsou potřeba různé metody a nástroje, které dokáží zprostředkovat pohledy na stav a vývoj těchto subjektů. Na počátku 21. století mezi takové nástroje patří oblast business intelligence (BI) a právě určitá vymezená část této oblasti bude tématem mé diplomové práce.
Širokou oblast BI si zúžím následujícím způsobem. Bude mě zajímat implementace části informačního systému určeného pro řízení informatiky a to konkrétněčásti help desk.
Tuto implementaci budu řešit pomocí metodiky ITIL a navrhnu sadu multidimenzionálních metrik, které bude možno využít pro měření využití, efektivnosti, vytížení či různých dalších vlastností help desku. Metriky budou navrženy tak, aby byly zobrazitelné právě pomocí technologie BI.
Celá práce bude rozdělena na dvě části a to teoretickou a praktickou. V první části budu definovat výše zmíněné metriky a pokusím se přiblížit jejich smysl a použití, tedy to, jak je možné je interpretovat. Jako vodítko pro definici jednotlivých metrik a formální podobu jejich návrhu mi bude sloužit [DIPL1]. Důvodem je, že tato práce bude do určité míry doplňkem nebo pokračováním uvedeného zdroje a je proto vhodné, aby byly použity stejné metody, a aby byly dodrženy stejné formální postupy.
Ve druhé části se pokusím do určité míry ověřit v praxi, zda navržené multidimenzionální metriky jsou navrženy správě, tedy jestli je možné je v praxi využít a zda v teorii navržené interpretace skutečně odpovídají reálným výstupům. Toto ověření bude uskutečněné aplikací vybraných metrik na intra/internetovou aplikaci help desku.
Aplikace, ve které budou tyto metriky nasazeny, bude založena na internetových technologiích a bude zajišťovat požadované funkce pro firmu, která spravuje výpočetní techniku outsourcingovou formou. Aplikace by měla zajistit následující funkce:
• Základ aplikace bude tvořit intranetová část, která bude sloužit pro evidenci zákazníků.
• Každý zákazník bude mít z internetu přístupné zfiltrované údaje z intranetové části.
• Zákazník bude mít k dispozici help desk.
• Help desk bude založen na principech popsaných v metodice ITIL.
• Evidenční systém i help desk budou generovat vstupní údaje pro měření metrik, které nadefinuje první část diplomové práce.
• Nad celou aplikací bude zprovozněno BI.
• Interně bude BI sloužit pro analýzu jednotlivých zákazníků.
Tento systém bude v praxi nasazen ve společnosti autora diplomové práce.
Vyvinutá aplikace by tedy měla v praxi ověřit, zda v první části nadefinované metriky jsou nadefinovány správně a zda jsou smysluplné. Je možné, že zkušenosti z chodu aplikace povedou k revizi teoretické části.
1.1. D ů vod výb ě ru
K výběru tohoto tématu mě vede moje snaha propojit teorii a praxi. Teprve praktické nasazení dle teorie nadefinovaných metrik může vést k potvrzení či vyvrácení jejich správnosti. Předpokládám, že v budoucnu by mohl systém být užitečný nejen mé společnosti, ale hlavně mým zákazníkům, protože povede ke zlepšení komunikace mezi firmou a zákazníkem. Předpokládám, že zlepšení komunikace povede k pozitivnímu dopadu i na ekonomické výsledky.
Důvodem pro volbu tohoto tématu je také souvislost s oblastí business intelligence, která mi přijde s výhledem do budoucna jako velice perspektivní. Mnoho společností postrádá nebo disponuje pouze velice omezeným monitorováním stavu svého hospodaření v reálném čase. Nevýhody zpětně (a tedy ne vždy plně aktuálních) generovaných zpráv o chodu podniku se daří pomocí BI překonat tím, že veškeré důležité informace pro rozhodování jsou přístupné daleko rychleji a pravidelněji. Je tedy evidentní, že schopnost nabídnout takováto řešení může v budoucnu být důležitou konkurenční výhodou v mém podnikání. K výběru tohoto tématu jsem se tedy rozhodl i proto, že bych chtěl více proniknout do oblasti BI, abych mohl tuto znalost dále využít v mé profesi.
1.2. Charakteristika sou č asného stavu
Metodika ITIL si získala ve světě poměrně velkou oblibu a v posledních letech lze sledovat, jak se pomalu dostává i k nám. Působí tu celá řada firem, které poskytují v oblasti ITIL školení s přípravou na zisk certifikátů Foundation Certification in ITSM [ITSMF1].
Jako zlomový se při analýze zdrojů zdá být zhruba rok 2002, kdy si několik společností na českém trhu uvědomilo, že by mohlo být výhodné tuto mezeru vyplnit.
V oblasti školení a zajištění následné certifikace se začala intenzivně angažovat společnost OMNICOM Praha, spol. s r.o. (vlastněná Českým Telecomem resp.
Telefonicou). Tato společnost také založila portál www.itil.cz. Mezi další společnosti nabízející školení v této oblasti jsou například AIT, s.r.o. nebo LBMS, s.r.o..
Vedle školení lze na trhu koupit již velké množství softwarových produktů, které jsou ITIL kompatibilní. Mezi tradiční dodavatele takových řešení patří bezesporu společnost Hewlett-Packard se svými produkty z řady Openview nebo IBM s produkty Tivoli. Vedle mnoha zahraničních společností dodávající produkty založené na ITIL knihovně lze nalézt i několik českých produktů. Za zástupce českých help desk systémů můžeme považovat společnost Datasys, která nabízí produkt Help.i.
Seznam certifikovaných společností a jednotlivců pro oblast ITIL lze v České republice nalézt na [ITSMF2].
Přestože specialisty na procesy ITIL i produkty na této metodice založené již na našem trhu nalezneme, tak pokud se zaměříme na oblast metrik pro tato řešení, tak zjistíme, že se většinou jedná o know-how jednotlivých společností, ke kterému bývá přístup pouze zakoupením příslušného produktu či služby. Proto na teoretickém poli help deskových metrik navíc ještě zúženém na metriky použitelné v BI toho na českém trhu mnoho nenajdeme.
1.3. Cíle práce
• Nadefinovat metriky pro měření help desku vytvořeného podle metodiky ITIL.
• Aplikovat navržené metriky na internetovou aplikaci, která v reálném provozu ověří, zda nadefinované metriky jsou definovány správně.
1.4. P ř edpoklady a omezení práce
Teoretická část této diplomové práce se bude zakládat na metodice ITIL a teorii BI, předpokládá ovšem čtenářovu základní orientaci v dané problematice. Nebudou zde proto vysvětlovány základní pojmy, budou zde pouze odkazy na literaturu, kde lze teorii z obou oblastí nastudovat.
Aplikace bude založená na internetových technologiích. Konkrétně je vyvinuta v prostředí PHP. Business intelligence nadstavba bude využívat Microsoft SQL Server a Microsoft SQL Sever: Analysis Services.
Úspěšnost závěrečného ověření správného navržení metrik pro help desk bude záviset na tom, jak se podaří aplikaci používat v reálném prostředí. Jako kritický faktor se
zde jeví to, zda se podaří získat dostatečné množství vstupních dat do doby, kdy dojde k vyhodnocení celé diplomové práce.
Metodika ITIL nedává žádné přesné návody, jak jí úspěšně v praxi nasadit. Při hledání odpovědí na mnoho otázek bude tedy pravděpodobně třeba čerpat i informace z různých internetových fór, kde lze nalézt mnoho cenných zkušeností. Problematická je ovšem možnost verifikace hodnověrnosti a pravdivosti takových zdrojů. Obtížné ověřování takových vstupních informací může proto být jedním z omezujících faktorů při tvorbě této práce.
1.5. P ř edpokládané vlastní p ř ínosy ř ešení
Oblast návrhu vhodných metrik pro kontrolu a měření ITIL procesů je ve světové literatuře již poměrně propracovaná. Jako příklad lze uvést publikaci [BROOKS] nebo [STEIN]. Již daleko méně propracované téma se po hledání a studiu různých zdrojů zdá oblast měření help desku jako takového. Lze očekávat, že metodiku měření help desku budou mít převážně vypracované společnosti nabízející produkty z této oblasti a dále analytické společnosti jako je např. Gartner.
Přínos, který by tato práce mohla nabídnout, je zúžení problematiky metrik pro help desk na metriky využitelné pomocí business intelligence. Multidimenzionální analýza sady metrik měřících aplikaci help desk je tedy důležitým bodem, kde lze spatřit hlavní užitek této práce.
Vedle teoretického prospěchu je třeba zmínit i užitek, který aplikace využívající zde vyvinuté teoretické poznatky přinese jak autorovi práce a jeho společnosti, tak zákazníkům této společnosti.
1.6. Ur č ení materiálu
Diplomová práce může sloužit jako vodítko vývojářům systémů, kteří chtějí do svého systému zapracovat help desk a zároveň nějakým způsobem měřit efektivitu a výkonnost help desku.
Jako materiál vhodný k inspiraci by se tato práce dala považovat i pro ty, kteří by dále chtěli rozšířit oblast metrik zpracovaných podle metodiky ITIL.
2. Analýza proces ů ITIL pro service desk
Navržení vhodných metrik pro měření help desku by měla předcházet analýza procesů, na kterých je tato aplikace založena. Veškeré tyto procesy budou vycházet z návrhů obsažených v ITIL dokumentech, jak jsou převážně popsány v [ITIL1]. Analýze bude v kapitole 2.1 předcházet definice základních pojmů, které se v této práci budou používat. Následně v kapitole 2.2 se budu věnovat service desku samotnému – jeho pozici v rámci jednotlivých IT procesů a jeho funkci. V další kapitole 2.3 zanalyzuji proces Incident Management, kterého se aplikace service desk zásadním způsobem dotýká.
2.1. Definice pojm ů a specifikace literatury
Před samotnou analýzou procesů by bylo vhodné blížeji popsat, ze kterých konkrétních zdrojů budu vycházet a proč. Též je potřeba nadefinovat jednotlivé pojmy, které budu při analýze používat.
Krátké shrnutí zdrojů bude obsahem části 2.1.1. Ústředním bodem, kolem kterého se celá tato práce soustřeďuje, je help desk, který bude podrobněji specifikován v bodě 2.1.2. Výsledkem teoretické části by měla být sada metrik vhodných pro měření a následnou analýzu help desku a to takových, které budou vhodné pro použití s technologií business inteligence. Proto se nejdříve v části 2.1.3 budu krátce věnovat pojmu metrika a v následné části 2.1.4 budu definovat právě oblast BI a související multidimenzionalitu.
V poslední části definic – 2.1.5 – objasním, v této práci hojně se vyskytující, pojem – incident.
2.1.1 Informa
ční zdroje
Jako hlavní teoretický základ, o který se budu v průběhu celé práce opírat, je literatura ITIL a to konkrétněčást Service Support [ITIL1]. Pro moje potřeby je ovšem tato kniha zbytečně rozsáhlá a zasahuje do oblastí, které se v úvodu vymezených cílů již netýkají. Tak můžeme z této publikace vynechat části Problem Management, Configuration Management, Change Management a Release Management. Zůstávají nám tedy dvě stěžejní kapitoly – Service Desk a Incident Management.
V souvislosti s ITIL bylo založeno fórum, které se snaží koncentrovat odborníky s této oblasti. Fórum, které vystupuje pod jménem ITSMF (IT Service Management Forum), se snaží svým členům poskytovat možnost vzájemného sdílení znalostí a zkušeností, stará se o správné certifikování odborníků v oblasti ITIL, vydává různé
publikace a studie, provozuje internetová diskusní fóra a organizuje po celém světě přednášky. Zde v České Republice toto fórum [ITSMF] plnohodnotně odstartovalo svůj chod k 1.1.2007.
Jako vhodné zahraniční zdroje jsem zvolil publikaci z knihovny ITSMF zaměřenou na metriky z oblasti managementu IT služeb [BROOKS] a knihu od dalšího odborníka na měření ITIL Randy A. Steinberga [STEIN].
2.1.2 Definice pojmu „Help Desk“
ITIL Service Support popisuje help desk jako [ITIL1]:
Central point of contact for handling Customer, User and related issues. (Ústřední kontaktní místo pro obsluhu zákazníků, uživatelů a souvisejících problémů.)
Tato funkce bývá v různých literaturách pojmenovávaná různými názvy jako je Call Centrum, Help Desk, Service Desk, Customer Hot line apod. Přesto lze nalézt určité rozdíly mezi těmito pojmy a v ITIL literatuře jsou popsány v závislosti na určité komplexnosti v následujícím pořadí:
Call Centrum
• Úkolem call center je profesionálně obsloužit velké množství příchozích hovorů a na telefonních hovorech založených transakcí pro služby bankovního či podobného typu.
Help Desk
• Cílem help desku je řídit, koordinovat a vyřešit incidenty v co nejkratším termínu. Zároveň je důležité, aby žádný požadavek nebyl ztracen, zapomenut nebo ignorován.
Service Desk
• Zde dominuje snaha funkci help desku komplexněji integrovat do řízení IT jako celku a do jeho procesů. V rámci ITIL rámce zde existuje provázanost na další aktivity jako jsou požadavky na změnu, Service Level Management či Configuration Management.
Teoretický rámec ITIL se právě snaží navrhovat řízení IT jako provázaný celek a je tedy logické, že zde je popisován právě Service Desk jako ucelené řešení. Ve skutečnosti mnoho Call Center či Help Desků postupně přechází právě v Service Desk.
Vzhledem k časové a finanční náročnosti bude v rámci praktické části této práce používaná aplikace spíše odpovídat definici Help Desku než rozsáhlejšímu pohledu Service Desku. Zároveň, ale bude snaha navrhovat aplikaci tak, aby byla snadno rozšiřitelná a integrovatelná až do podoby Service Desk.
2.1.3 Definice pojmu „metrika“
Definic metriky lze nalézt velmi mnoho, vždy totiž záleží pro jaký konkrétní důvod metriku definujeme. Při srovnávání definic se jako poměrně komplexní zdá být podoba uvedená na [WIKI1].
Metrika je systém parametrů nebo způsobů kvantitativního a periodického měření procesu, který má být měřen, spolu s procedurami, které ukážou tato měření a procedury interpretované v souvislosti předchozími a srovnatelnými měřeními.
Metriky jsou obvykle svázány s předmětnou oblastí, v rámci které, a pouze v ní, je možné je interpretovat.
Aby metrika mohla být považována za zcela definovanou, tak je potřeba, aby byla definována v následujících oblastech [ISM].
• Jméno metriky
• Popis metriky (co je měřeno)
• Procedury měření (jak je měřena)
• Frekvence měření (jak často)
• Odhad prahových hodnot (jak jsou prahové hodnoty kalkulovány)
• Prahové hodnoty (rozmezí hodnot, ve kterém je hodnota metriky považována za normální)
• Cílová hodnota (nejlepší možná hodnota)
• Jednotky
V kontextu ITIL je smysl metriky v tom, že slouží pro zkoumání efektivity jednotlivých popisovaných procesů. Teoreticky si můžeme představit, že při detailním nadefinování podoby jednotlivých metrik by bylo možné srovnávat hodnoty i mezi jednotlivými organizacemi. V praxi to je zatím problematické, protože každé praktické nasazení metriky vyžaduje určitou úpravu dle konkrétních podmínek, především dle dostupných vstupních dat.
2.1.4 Definice pojm
ů„business intelligence“ a „multidimenzionalita“
Na problematiku business intelligence lze nahlížet z několika pohledů. Důvodem je, že BI představuje nejen soubor činností a postupů ukazujících, jak ze základních dat získat kvalitní a jednoduše použitelné analytické informace, ale i poměrně rozsáhlý komplex technologií, pomocí kterých lze daného výsledku dosáhnout. Poměrně ucelená definice, která se snaží obsáhnout oba tyto pohledy, lze nalézt v [NOVO].
Business Intelligence (BI) je sada postupů, procesů a technologií, jejímž cílem je účinně a účelně podporovat rozhodovací procesy ve firmě. Představuje komplex aplikací IS/ICT, které podporují analytické a plánovací činnosti podniků a organizací a jsou postaveny na specifických, tzv. OLAP (On-Line Analytical Processing) technologiích a jejich modifikacích.
Z manažerského pohledu se tedy jedná o silný analytický nástroj, který by měl v reálném čase poskytovat velké množství agregovaných údajů vhodných pro řízení na taktické i strategické úrovni. Z technického hlediska se jedná o množství prostředků zahrnujících ETL (Extraction Transformation Loading), datové sklady, datová tržiště, multidimenzionální kostky a další, které v celku tvoří technologii OLAP.
Jedním ze základních principů BI je multidimenzionalita, která vyjadřuje myšlenku, že na samotná data firmy (v terminologii BI se jedná o fakta) je nutno nahlížet z různých pohledů nebo-li přes různé dimenze. Dimenze tedy představuje způsob, jak si ze základních faktů zobrazit pouze to, co nás momentálně zajímá. Dimenzí tak můžou být například jednotlivé pobočky společnosti, zákazníci nebo třeba produkty.
2.1.5 Definice pojmu „incident“
Definice incidentu použitá v publikaci [ITIL1] je následující:
Jakákoliv událost, která není součástí běžného chodu služeb, a která způsobuje nebo může způsobit přerušení služby nebo snížení kvality této služby.
Incidenty je často nutné nějakým způsobem kategorizovat, což je vhodné z několika důvodů. Jedním z nich je, že je tím umožněno správné směrování incidentů k řešitelům s odpovídající profesní specializací. Dalším důvodem je potřeba klasifikace pro následnou analýzu. Během chodu service desku je třeba analyzovat (a náplní této práce je právě návrh vhodného analytického aparátu) jeho efektivnost a slabá místa a to z hlediska různých druhůčinností. Nejsnazší kategorizací je právě rozdělení dle druhů incidentů.
Dělení incidentů je věc samozřejmě specifická pro konkrétní implementaci a použití, ale některé obecné kategorizace mohou incidenty členit např. na aplikační, hardwarové a požadavky na službu. Tyto obecné skupiny můžeme např. pro hardware dále členit na výpadek systému, automatické upozornění, chyba tisku, nedostupnost apod.
2.2. Service desk
V intencích ITIL literatury [ITIL1] je help desk funkcí a nikoliv procesem.
V oblasti IT podpory služeb se ovšem jedná o funkci velmi důležitou, která se prolíná a v mnoha ohledech je hlavním spojovacím momentem většiny dalších procesů IT služeb.
Důvodem, proč je tato funkce v dnešním IT tak důležitá, je fakt, že se v help desku centralizuje a formalizuje veškerá komunikace s uživateli i zákazníky IT služeb. Při správném navržení help desku a správném definování a provázání všech dalších důležitých IT procesů tak můžeme na jednom místě pohodlně sledovat veškerý průběh požadavků a problémů týkajících se informatiky.
Tato důležitá pozice help desku sebou přináší i značné riziko. Pro správnou funkci a při správném nadefinování všech IT procesů by právě help desk měl být jediným místem kontaktu uživatele či zákazníka s poskytovatelem IT služeb a to bez ohledu na to, zda se jedná o interní firemní službu či externí produkt. V tom případě je ovšem naprosto zásadní bezchybná funkčnost systému nebo-li vyloučení ztráty, opomenutí či nedůsledné řešení jakéhokoliv incidentu. Pokud by k takovým problémům totiž docházelo, tak by hrozila ztráta důvěry ze strany uživatelů a vznikala by snaha různými způsoby help desk obcházet.
Navíc v případě interního využívání funkce help desku je možnost přímého kontaktu s pracovníky IT oddělení ve snaze získat individuální přístup k řešení vzniklého problému velmi snadná a leckdy lákavá. Takový přístup je ovšem nejen nesystémový, ale především
může do značné míry zkreslovat výstupní údaje, které chceme pro řízení a plánování systému a souvisejících procesů používat.
Ztráta důvěry je spojena i se vzrůstajícím počtem stížností, špatně vyřešených incidentů a nedodržení sjednaných úrovní služeb, což vede ke ztrátě přízně ze strany vedení. Management si s odsouhlasením zavedení help desku většinou plně uvědomuje, že tato funkce bude z mnoha hledisek zásadní a může v mnohém ovlivnit vztahy se zákazníky nebo interní fungování IT. Proto je logické, že ze strany vedení bude velká poptávka po tom, jakým způsobem měřit a kontrolovat správnou funkčnost help desku.
Návrh metrik vhodných pro kontrolu nad help deskem je tedy určitě věcí zcela zásadní pro budoucí chod aplikace. Navíc se zdá být výhodné poskytnout určité patřičně zfiltrované metriky i zákazníkům, aby získali možnost patřičně dohlížet nad kvalitou dodávané služby.
2.2.1 Vrstvy
Základní princip service desku se snaží vytvořit několik vrstev podpory s tím, že help desk a tým lidí, který je v něm zaměstnán tvoří první vrstvu. V praxi bylo zjištěno, že je výhodné, aby byl problém pokud možno vyřešen nikoliv specialistou na danou oblast, ale spíše pracovníkem service desku, který bude mít k dispozici rozsáhlou databázi řešených problémů a další pomocné nástroje. Specialisté se tak stávají až druhou vrstvou, která je kontaktována pouze, pokud se problém nepodaří vyřešit pracovníky help desku.
Odborníci tak nejsou rušeni ze své běžné činnosti a výsledný výkon je vyšší na všech úrovních. Případně je možné definovat i další vrstvy např. externí dodavatele.
2.2.2 Struktura
V literatuře se objevují tři modely, jak strukturovat service desk. Lokální model představuje tradiční přístup, který je vhodné aplikovat pouze do doby než vznikne více středisek se stejnou potřebou service desku. Centrální service desk představuje fyzicky jedno místo, kde je služba realizována. Výhodou jsou nižší náklady a lepší řiditelnost než v případě několika lokálních service desků. Poslední strukturou je virtuální service desk, který je realizovatelný díky pokrokům ve výkonnosti sítí a telekomunikací. Aplikací tohoto modelu vzniká service desk přístupný po celém světě, u kterého je koncový uživatel zcela odfiltrován od konkrétního umístění a způsobu provozu řešení. Systém tak je často složen z několika navenek stejných středisek, které postupně přebírají pohotovost tak, jak na Zemi
2.2.3 P
řínosy
Dle ITIL lze zavedením funkce service desk do firemního IT sledovat celou řadu reálných přínosů, které se projevují jak směrem k uživateli/zákazníkovi systému, tak interně z hlediska řízení IT a úspor z efektivního řízení plynoucích.
Z pohledu uživatele by mělo dojít k minimalizaci negativního dopadu vzniklých problémů a tedy i k minimalizaci času potřebného k vyřešení problémů. Service desk by při správné implementaci měl působit jako aktivní prvek, který se bude snažit některým detekovatelným či predikovatelným problémům předcházet. Uživatel by též měl pozorovat zvýšení dostupnosti a profesionality IT podpory.
Při zkoumání přínosů pro podnik jako takový, tedy z pohledu managementu, by mělo na jedné straně dojít k redukci nákladů, a to jak operativních, tak i nákladů na zdroje.
Na straně druhé by mělo být zajištěno, že veškeré incidenty jsou pod kontrolou a to včetně případné eskalace problému. Tak se plně pod kontrolu dostává péče o zákazníka, což je pro podnik jednoznačně přínosem. Neopomenutelný přínos je i ve faktu, že service desk generuje velké množství důležitých manažerských dat.
2.2.4 Rizika
Zavádění service desku sebou dle očekávání nese i mnoho rizik, která je třeba dopředu znát a snažit se je vhodnými opatřeními minimalizovat. Je zřejmé, že při zavádění takto velké a důležité změny se nelze obejít bez souhlasu managementu. Nestačí ovšem pouhý souhlas, je potřeba, aby vedení daný projekt přímo podporovalo. Pro získání plné podpory od vedení je nutné zavést metriky, pomocí kterých lze zkoumat efektivitu celého procesu.
Správná funkčnost service desku vyžaduje nejen definování a realizaci správných procesů, ale i následnou údržbu těchto procesů. Nutností je také zachovat rozumnou složitost systému a snažit se, aby byl jednoduše ovladatelný. Nedodržení tohoto principu může vést k tomu, že značná část náplně support týmu bude podpora help desku jako takového, což jistě není efektivní. Zákazníky je také třeba dostatečně dopředu o zavedení či změnách systému informovat a v dané věci je náležitě vzdělat.
2.2.5 Provázanost s jinými procesy
Přestože service desk není proces ale funkce, je užitečné sledovat, jak je navázán na jiné procesy, které se řízení IT služeb týkají. Nejzásadnější vazbu lze nalézt v Incident
Managementu. Incident Management je při lehkém zjednodušení vlastně hlavní procesní náplní service desku.
Jestliže help desk je nástrojem, který přijímá požadavky na nápravu, obnovení či změnu služby, tak Incident Management má za úkol v co nejkratším možném termínu obnovit službu do stavu definovaném v SLA.
Při obecnějším pohledu a při bližším studiu dalších procesů, které nejsou náplní této práce (Problem Management, Configuration Management, Change Management a Release Management), lze vypozorovat, že service desk v pojetí ITIL teorie je určitým vstupním prvkem, který většinou spouští uvedené další procesy. Plní funkci vstupní brány, která inicializuje chod celého systému.
Vedle funkce service desku jako určité brány do IT služeb lze vysledovat ještě jednu důležitou součást celkového řešení supportu. Tím je centrální databáze CMDB (Configuration Management Database), do které je potřeba ukládat všechny údaje důležité pro chod systému. CMDB tak obsahuje nejen konfigurační údaje jednotlivých částí systému, které jsou v rámci supportu spravovány, ale i veškeré události v systému a jejich návaznosti na jednotlivé části systému. Všechny tyto informace mohou být naprosto zásadní při snaze o co nejrychlejší řešení vzniklých incidentů.
2.3. Incident Management
SLA by mělo definovat „normální úroveň služby“ a právě tato úroveň resp. její dosažení v případě problému je základní úkol, který si Incident Management klade.
Incident Management je narozdíl od service desku již plnohodnotným procesem, který má definovány vstupy a výstupy, činnosti a role.
Důvodem, proč zde uvádím velmi stručný popis tohoto procesu, je, že Incident Management je velice úzce provázán s činností service desku – v podstatě ho naplňuje daty. Proto se mi zdá vhodné alespoň v hrubých rysech tento proces představit. Zdrojem pro popis je [ITIL1].
2.3.1 Vstupy
Jako hlavní vstup Incident Managementu lze bezpochyby považovat samotný incident, který je iniciován přes service desk. Během procesu je potřeba čerpat z CMDB, dále do procesu vstupují informace čerpané z již známých problémů a chyb, případně při vyvolání žádosti o změnu (Request For Change – RFC) odpověď na tuto žádost.
2.3.2 Výstupy
Během řešení incidentu se pravidelně aktualizuje záznam o tomto incidentu, což je zároveň výstup tohoto procesu. V případě potřeby je vyvolán RFC. Po vyřešení a uzavření incidentu je znovu potřeba veškeré údaje zaznamenat. Proces intenzivně komunikuje se zákazníkem a v neposlední řadě generuje zprávy pro management.
2.3.3
Činnosti
Vznik incidentu je potřeba detekovat a následně zaznamenat. Pro správné nakládání a rozhodnutí o dalším postupu je nutné incident klasifikovat (viz definice incidentu) a poskytnout úvodní podporu. V procesu poté následuje snaha diagnostikovat problém a pokud to je možné, tak ho vyřešit a službu obnovit. Následuje uzavření incidentu a monitorování dalšího stavu. Provedené činnosti je samozřejmě nutné komunikovat s uživatelem.
2.3.4 Role a funkce
Rolí jsou týmy první, druhé i třetí vrstvy podpory. V procesu se dále objevuje role manažera incidentu a funkce manažera service desku.
3. Východiska pro návrh metrik
Před samotným návrhem sady metrik je potřeba podrobněji rozebrat, jak jsem ke konkrétně této skupině metrik dospěl. Důležitá je otázka, ze kterých zdrojů jsem čerpal, v čem se tyto zdroje od sebe lišily a naopak, kde se scházejí.
Při výběru vhodných metrik jsem čerpal ze tří hlavních zdrojů. Jedná se o dvě publikace vydané odborníky na oblast řízení IT služeb, kteří se pohybují v oblasti specialistů věnujících se na profesionální úrovni metodice ITIL. Konkrétně se jedná o publikaci, jejímž autorem je Peter Brooks, a která je nazvaná „Metrics for IT Service Management“ [BROOKS]. Druhým důležitým zdrojem inspirace je kniha „Measuring ITIL“ od Randy A. Steiberga [STEIN]. Další informace jsem čerpal z materiálů analytické společnosti Gartner.
3.1. Peter Brooks
Peter Brooks působil jako senior konzultant ve společnosti Hewlett-Packard na různých místech světa, pomáhal spustit chod itSMF na Novém Zélandě a je poměrně aktivním členem tohoto fóra. Jeho zde zmiňovaná publikace je začleněna do ITSM knihovny jako „Best Practice book“.
Autor doporučuje, aby se při návrhu metrik dodržovalo několik pravidel či principů, které pomohou zajistit, aby metriky byly efektivní a užitečné. Brooks varuje, před slepým přijetím metrik dodaných výrobcem podnikového systému a dalších implementovaných softwarových balíků. Místo toho doporučuje vyvinout si metriky vlastní, které přesně odpovídají potřebám firmy a teprve poté zkoumat, nakolik mohou firemní aplikace tyto metriky naplňovat.
Dále vřele doporučuje držet se pravidla SMART (Specific, Measurable, Achievable, Realistic and Timely). Navrhnout metriku dostatečně specifickou znamená, aby byla vázána na konkrétní proces, aby za ní byl majitel procesu zodpovědný. Měřitelnost metriky musí být leckdy zajištěna i odpovídajícím technickým vybavením (např. telefonní ústředna s integrovanou podporou pro IVR). Je třeba, aby konkrétní cílová hodnota metriky byla s existujícím vybavením ve skutečném provozu vůbec dosažitelná. Při návrhu metriky je třeba si klást otázku, zda měří něco reálného, zda neměří pouze něco, co je v podstatě pevně dané. Hodnoty metrik je třeba získávat v dostatečně krátkých intervalech a v souladu s měřením ostatních metrik.
Jako další princip, který je dle Brookse vhodné dodžovat, je pravidlo KISS (Keep it Simple Stupid). Pokud metriku při návrhu dostatečné nevysvětlíme a neukážeme, jak je možné jí dosáhnout, tak vzniká velké riziko deziluze, odmítání a hledání výmluv. Aby k tomu nedošlo, tak je třeba udržet složitost metrik na nižší úrovni a vždy dbát na to, aby měřily jednu konkrétní věc a ne několik záležitostí najednou.
GQM (Goal, Question, Metrics) metoda nahlíží na problematiku shora. Nejdříve doporučuje specifikovat konkrétní cíle, kterých má být ve zkoumaném procesu dosaženo.
Pro každý cíl se určí sada otázek, které budou zodpovězeny při dosažení cíle. A nakonec je pro každý cíl vyvinuta metrika, která měří výsledek konkrétní otázky.
MAPE (Mean Absolute Percentage Error) je statistická metoda, která pomocí výpočtů pomáhá na historických datech ověřit, zda vyvinuté metody předpovědí používané např. v kapacitním plánování jsou spolehlivé.
A jako poslední metodu pro zajištění vývoje kvalitních metrik doporučuje Peter Brooks Customer Realtionship Diagram. Cílem při tvorbě tohoto diagramu je nalézt vždy nejpřímějšího zákazníka každého procesu. Důvodem je nalézt místo, kde je možné a vhodné měřit spokojenost zákazníka, jako jednu ze zásadních metrik celého systému.
Důležité je též udržovat rozumný počet metrik jednotlivých procesů. Jako nejvhodnější se v této knize doporučuje něco okolo deseti metrik na jednotlivé procesy dle ITIL. Takový počet zajistí na jedné straně dostatečnou podrobnost zkoumání a na druhé straně zvládnutelnou míru složitosti a nákladů na měření.
Při popisování metrik používá autor následujícího postupu. Nejdříve krátce popíše cíle procesu, jak jsou uvedeny v ITIL metodice. Dále si určí poslání nebo úkol (Mission Statement), kterého je potřeba v rámci procesu dosáhnout nebo spíše stále dosahovat. Též je určen majitel procesu. Následně definuje cíl metriky (Metric Objective). Ten může být stejný i pro skupinu metrik a v rámci jednoho procesu může být několik takových cílů metrik a tedy i souvisejících skupin metrik.
A jaké konkrétní metriky tedy Peter Brooks pro nasazení v service desku doporučuje? Metriky rozřadím dle jejich cílů.
Prvním cílem metriky je „Obnovit normální chod služby co nejrychleji to je možné a minimalizovat negativní dopad na zákazníka a tak zajistit nejlepší možnou kvalitu služby“. Pod tento cíl zařazuje tyto metriky:
• Počet neeskalovaných hovorů na zaměstnance service desku
• Procento hovorů uzavřených napoprvé na zaměstnance service desku
• Počet hovorů, které překročí SLA
• Počet hovorů eskalovaných na druhou úroveň podpory
• Spokojenost zákazníka
• Počet hovorů eskalovaných na třetí úroveň podpory
• Průměrný čas čekání hovoru na odpověď
• Průměrný čas strávený pokusy zaměstnance kontaktovat zákazníka na jeden hovor
• Procento hovorů, které přichází přes web
• Procento hovorů nesprávně eskalovaných
Další cíl metriky definoval Brooks jako „Dostupnost service desku zákazníkům“.
Zde uvádí tuto metriku:
• Procento hovorů ukončených zákazníkem
Dalším cílem je „Změřit efektivitu procesu zacházení s hovorem tak, aby bylo možné zjistit vytíženost service desku“. Zde nacházíme opět jednu metriku:
• Procento hovorů, které jsou skutečně dále vedeny jako požadavky (tickets)
Dále uvažuje cíl „Analyzovat vytížení Service Desku a vypočítat požadavky na personál service desku“ s touto metrikou:
• Procento incidentů pocházejících z automatizovaných systémů
Jako poslední cíl pro service desk klade Brooks „Ukázat, že service desk disponuje odpovídající znalostí oblasti, pro níž řeší incidenty a umí správně směrovat problémy na správné pracovní skupiny“. Zde nalezneme metriku:
• Procento hovorů správně přiřazených napoprvé
V kapitole 4 se nachází mnou navrhovaná sada metrik service desku, z nichž některé jsou inspirované právě zde popsanými metrikami. Takové pak budou podrobněji popsány.
Závěrem této kapitoly bych rád zhodnotil pozitiva a negativa této publikace.
Obávám se, že tato publikace nedostála mých očekávání, které byly vzhledem k tomu, že Peter Brooks je aktivním propagovatelem myšlenek obsažených v ITIL publikacích a též díky tomu, že téma publikace odpovídalo tématu této práce, poměrně vysoké. Pozitivně bych hodnotil srozumitelnou strukturu celé publikace, ve které byla patrná snaha o postupné zodpovězení většiny základních otázek týkajících se metrik pro řízení IT služeb.
Bylo odpovídáno na takové dotazy typu co to metrika je, proč je potřeba je používat, kde je aplikovat, pro koho jsou určeny apod. Metriky samotné pak byly přehledně uspořádané dle jednotlivých ITIL procesů.
Kniha měla bohužel i negativa. Vůbec největší nedostatek bych viděl v samotném návrhu metrik. Ty byly dle mého názoru vybrány poměrně nešikovně a bez hlubšího pochopení směru, kterým se oblast metrik ITIL procesů ubírá. Většina metrik postrádá konkrétnější návaznost na fungování společnosti jako celku, na její cíle, na zákazníka společnosti, na business strategie. Vesměs se všechny pohybují na operativní úrovni a pro vyšší úrovně řízení tak nemají vypovídací hodnotu. Brooks se sice v jedné kapitole snaží navrhnout i metriky pro business vyhlídky, ale jedná se o pojmy poměrně abstraktní bez užší návaznosti na jednotlivé procesy.
Jako ne úplně šťastné považuji i členění kapitol s jednotlivými metrikami, konkrétně určování cílů metrik. Tyto cíle (viz výše) – minimálně pro kapitolu service desk – jsou definovány poněkud nejasně a myslím si, že jsou spíše zbytečné. Prostor mohl možná být věnován hlubšímu rozboru jednotlivých metrik a jejich dopadu na fungování systému. Jako velice zavádějící bych pak viděl uvádění konkrétních cílových hodnot u metrik, což je záležitost již plně implementační a tedy individuální.
3.2. Randy A. Steinberg
Randy A. Steinberg má 25-leté zkušenosti s implementací a řízením IT systémů a služeb ze společností po celém světě. Je častým přispěvatelem do diskusí itSMF a je autorem knihy „Implementing ITIL – Adapting Your Organization to the Coming Revolution in IT Service Management“.
Steinberg ve své publikaci vyvinul model ITSM metrik, kde jsou pro jednotlivé procesy metriky dále kategorizovány. Zavádí kategorii „Operačních metrik“, kam jsou
zařazeny ty metriky, které měří základní události v každém procesu. Tyto hodnoty pak slouží k výpočtu složitějších metrik v dalších kategoriích.
Další kategorie jsou KPI „Key Performance Indicators“. Ty již naznačují výkonnostní úroveň jednotlivých procesů a jejich částí a jsou proto využívány v manažerském rozhodování. Bývají odvozeny nebo vypočítány z jedné nebo více operačních metrik. Pro správné užívání je třeba podrobněji popsat smysl těchto metrik.
„Tolerance“ jsou dolní a horní hranice určující akceptovatelné a neakceptovatelné hodnoty KPI. Vznikají pásma, ve kterých se liší způsob reakce personálu service desku a managementu.
Další kategorie – „CSF – Critical Success Factors“ – obsahuje ty metriky, které jsou klíčové pro kvalitu chodu a výkon procesu. Jsou odvozeny od KPI a Tolerancí a jsou většinou na základě toho, v kterém pásmu se z hlediska tolerancí pohybují, hodnoceny jako vysoce, středně nebo nízko výkonné. Takové hodnocení slouží managementu jako
„semafor“.
„Dashboards“ jsou v podstatě grafickým znázorněním CSF metrik. Je zde hojně využívána metoda Balance Scorecard [BALAN].
„Výsledky – Outcomes“ jsou negativní situace, které mohou v důsledku nepříznivých hodnot KPI a CSF nastat. Jako příklad negativní situace Steinberg uvádí plýtvání, neočekávané náklady, narušení zabezpečení apod. Tyto metriky tak udávají, jaké je momentálně riziko, že proces bude směřovat k vytvoření nechtěné situace. Opět rozeznáváme tři stavy – vysoké, střední a nízké riziko.
Další kategorie „Co se stane, když – What-Ifs“ popisuje situace, které mohou nastat a jak se taková situace projeví na konkrétních hodnotách KPI a CSF. Lze si tak modelovat vliv různých situací, které mohou nastat.
„Analytická“ skupina obsahuje ty metriky, které již slouží spíše podrobnějším rozborům, které většinou nedělá management. Do této skupiny Steinberg zařadil metriky, které vykazují určité vlastnosti vhodné pro BI. Tedy určitá rozdrobitelnost agregovaných údajů až na základní data drill-down metodou.
Poslední kategorii – „Ostatní“ – již podle názvu naplňují ty metriky, které nešly zařadit do žádné kategorie popsané výše.
Pro service desk definuje Randy A. Steinberg tyto metriky (dělené dle výše popsaných kategorií:
A) Operační
• Celkový počet hovorů na service desk
• Průměrná doba hovoru
• Průměrná doba čekání
• Úroveň nástrojů service desku
• Počet přesměrovaných hovorů
• Počet zrušených hovorů
• Počet volných člověkohodin personálu service desku
• Celkový počet volných hodin service desku
• Celkový počet hodin, kdy nebyl service desku k dostupný B) KPI
• Míra vyřešených hovorů
• Průměrná doba hovoru
• Úroveň nástrojů service desku
• Využití zaměstnance service desku
• Míra zrušených hovorů
• Doba trvání hovoru
• Míra čekání hovoru
• Míra dostupnosti service desku C) CSF
• Míra vyřešení požadavku napoprvé
• Udržování produktivity zákazníka
• Zajištění positivní zkušenosti pro zákazníka při hovoru
• Poskytnutí efektivní podpory zákazníkovi při hovoru
Ostatní kategorie uvedeny nejsou, protože jsou již do značné míry závislé na implementaci a konkrétních podmínkách místa nasazení a na požadavcích managementu.
Publikace Randy A. Steinberga je sympatická tím, že se snaží pro každý ITIL proces navrhovat metriky v rámci modelu, který začíná na nejnižší – operativní – úrovni a postupně na základě těchto metrik vybudovává metriky komplexnější, které jsou již více orientované na řízení procesů a na celý business. Orientaci na řízení IT jako celku s cílem optimální podpory společnosti a jejích cílů vyjadřuje i pojem, který Stainberg zavádí –
„Metrics That Matter (metriky, na kterých záleží)“. Cílem procesu návrhu metrik má být
právě odhalení takových metrik, které odpovídají na otázky typu „Jaká je míra efektivity zavádění změn“ nebo „Jaké procento práce personálu na operativní úrovni je neefektivní nebo naopak přínosem“.
V knize je též jedna kapitola věnována situaci, kdy je k dispozici pouze málo metrik a nejsou dostupné zdroje na plnohodnotný vývoj celého systému metrik.
Doporučení zde uvedené se mohou hodit menším IT oddělením, které teprve chtějí vedení přesvědčit o nutnosti uvolnit prostředky pro vývoj soustavy metrik.
Knize bych vyčetl poněkud strohou grafickou úpravu, kdy mnoho stránek vypadá spíše jako trochu rozšířená textová prezentace. Velké množství prázdného prostoru na většině stránek mohlo být věnováno podrobnějšímu popisu a rozboru jednotlivých metrik, které jsou popsány pouze velmi stručně.
3.3. Gartner
Společnost Gartner byla založena v roce 1979 s cílem nabízet svým zákazníkům odbornou technologicky orientovanou pomoc při rozhodování. Zaměstnává mnoho špičkových odborníků z různých oblastí, kteří produkují velké množství analytických zpráv a přehledů. Tyto informace pak slouží managerům a vedení mnoha společností pro správné rozhodování v jejich businessu.
Vzhledem k tomu, že problematika IT procesů a měření jejich efektivity a fungování je v poslední době jedno ze zásadních témat moderního řízení společností, tak je logické, že se Gartner věnuje i této problematice. Oproti autorům předcházejícím se jedná o zdroj poněkud komplikovanější. Důvody, proč tomu tak je, můžeme nalézt dva.
První problém nastává s dostupností dokumentů publikovaných Gartner. Veškeré materiály totiž obsahují cenné know-how, které samozřejmě není volně přístupné a vzhledem k tomu, že Gartner má na trhu důležité postavení, tak ceny za přístup k informacím jsou značné a pro jednotlivce tedy téměř nedostupné. Tento problém byl naštěstí díky p. Otu Novotnému (vedoucí diplomové práce) částečně překonán.
Druhá komplikace nastává při studiu těchto materiálů. Společnost Gartner vydává své zprávy spíše strohé a poměrně úzce zaměřené. Lze z nich tedy obtížněji vyčíst, jaké metody při zkoumání IT procesů a následném návrhu odpovídajících metrik používá.
Tento problém nelze s mě dostupnými materiály plně vyřešit, přesto se pokusím s těmito kusými informacemi sestavit alespoň přibližný obrázek toho, jakým způsobem Gartner při zkoumání problematiky IT postupují.
Jako základní princip, který se je zřetelný v podstatě ze všech mě dostupných zdrojů, lze odhalit snahu o to, aby metriky vypovídaly něco o procesu či procesech ve firmě a ne jen o nějakých událostech či technických záležitostech. V materiálech je uváděno, že při návrhu metrik je třeba spíše než na jednoduchost jejich měření pohlížet na jejich vypovídací schopnost, tedy jak je možné podle změřených údajů měřený proces řídit, zlepšovat a kontrolovat. Mezi další otázky, které mají metriky zodpovědět patří to, jak zkoumaná záležitost ovlivňuje své okolí, jaký má dopad na zákaznickou spokojenost, na finanční otázky celé společnosti apod.
Pokud bychom to chtěli shrnout, tak je zřejmé, že specialisté z Gartner chtějí, aby metriky sloužily vedení, managerům jednotlivých úrovní, majitelům procesů a dalším při zkoumání celkové funkčnosti procesů ve firmě. Metriky tedy mají být zaměřené na business. Doporučení orientace metrik na business samozřejmě nezavrhuje metriky nižších úrovní, které jsou vhodné pro operační řízení. Pouze tyto metriky staví do role datového základu pro určení hodnot business metrik.
Dokument [GART1] poukazuje na změny používaných metrik, které korelují s vývojem help desků jako takových. Zatímco 90. léta jsou typická s help desky orientovanými na obsluhu telefonických hovorů a tedy i metriky 90. let měřily převážně záležitosti s telefonickými hovory související (počet hovorů, doba čekání, počet vzdaných hovorů apod.), tak s příchodem a masovým rozšířením internetu a souvisejících technologií se oproti telefonu objevují nové komunikační kanály (web, email, internetové diskuze). Ty jsou typické nižší nákladovostí a leckdy vyšším uživatelským komfortem, což vedlo ke stále větší oblibě těchto kanálů a tedy i k rostoucímu podílu na celkovém počtu řešených požadavků. Tento fakt inicioval počátkem nového tisíciletí snahu navrhovat metriky, které se zaměří právě na tyto kanály, přičemž ty je třeba často pojmout jinak než u tradičních kanálů. Důvodem je nemožnost zkoumání některých faktů (např. vzdané snahy o kontakt u webu) nebo naopak snazší přístup k některým údajům (např. větší možnosti při získávání zpětné vazby od zákazníků pomocí internetových dotazníků).
Vznik metrik nových komunikačních kanálů a technický rozvoj v automatizaci obsluhy telefonického komunikačního kanálu často vedl k nutnosti zamyslet se, jak je tradiční vnímání a tradiční cílování hodnot metrik tímto ovlivněno. Příkladem může být klasická metrika – „počet hovorů na zaměstnance help desku“. Tradiční přístup říkal, že vyšší hodnota této metriky svědčí o větší efektivnosti zaměstnance. S příchodem automatizovaných systémů ovšem může hodnota této metriky klesat, a to i přesto, že
celková efektivita bude růst. Navíc současná větší orientace na spokojenost zákazníka (související s business pohledem na metriky) naznačuje, že rychlost vyřízení hovoru rozhodně nemůže být brána jako údaj naznačující efektivnost řešení. Rychle, ale zároveň neuspokojivě „vyřízený“ zákazník rozhodně nebude spokojenější než zákazník, který na telefonu stráví podstatně delší časový úsek ovšem zakončený úspěšným řešením problému [GART2][GART4].
Dokument [GART3] poukazuje na nutnost provázání metrik help desku na existující SLA dokumenty. SLA dokumenty je přitom třeba tvořit především z pohledu vyššího vedení a zákazníka. Takový pohled totiž přináší kýžený cílový stav chodu procesů a určuje tak, kterým směrem stávající procesy usměrňovat a zlepšovat. Metriky v takovém případě slouží ke zkoumání, nakolik jsme se již ke chtěnému stavu přiblížili. Tvorba SLA dokumentů z druhé strany (např. IT personálu) může vést k nedostatečnému sledování business cílů. Pro spokojenost zákazníka nejsou důležité průměrné časy odpovědí, vytíženost personálu apod., ale to, zda bude jeho problém vyřešen. Musíme tedy spíše měřit úspěšnost řešení při prvním zavolání, dodržení termínů daných SLA, procento zamezených problémů atd.
Celkově hodnotím materiály Gartner jako jednoznačně nejpřínosnější při návrhu sady metrik v kapitole 4. Kvalitu dokumentů potvrzuje i to, že všechny mě dostupné jsou již staršího data vydání (3 – 6 let staré) a přesto jsou informace v nich obsažené naprosto relevantní a do značné míry stále aktuální. Lze tedy předpokládat, že současné materiály poměrně přesně ukazují směry, kterými se oblast help desků a souvisejících metrik vydává.
Jako velmi kladnou hodnotím maximální orientaci používaných metrik na přínosy pro business cíle a tedy i zákazníka.
4. Návrh sady metrik
Při návrhu metrik budu vycházet z formalizované podoby zápisu, která je předpokládána publikací [NOVO]. Tatáž podoba zápisu jednotlivých metrik byla použita i v diplomové práci [DIPL], na kterou se snaží tato práce navázat.
Charakteristika Popis
ID: Identifikace ukazatele
Název: Název plně vystihující smysl ukazatele Jednotka: V jakých jednotkách je ukazatel uváděn Zdroj: Kde zkoumaná data získáme
Poznámka: Zde lze popsat specifika definovaného ukazatele Tabulka 1: Ukazatel – šablona
Dimenze: JMÉNO DIMENZE ID: oznaceni_dimenze
Struktura Prvky Počty Poznámka
Struktura: Číselné zařazení do hierarchické struktury
Názvy prvků
v hierarchické struktuře
Podrobnější definice, pokud je třeba
Výpočty: Pravidla pro výpočet, pokud je třeba Zdroje: Kde zkoumaná data získáme
Poznámky: Zde lze popsat specifika definované dimenze Tabulka 2: Dimenze – šablona
Dimenze/Ukazatel Jméno ukazatele
Jméno dimenze: Indikuje, zda je ukazatel sledován podle dané dimenze.
Tabulka 3: Matice vztahů mezi ukazateli a dimenzemi – šablona
V kapitole 4.1 budou nejdříve představeny jednotlivé dimenze, které považuji pro problematiku service desku za podstatné, poté v kapitole 4.2 navrhnu vhodné metriky s jejich podrobným popisem a analýzou a následně budu v kapitole 4.3 zkoumat vztah mezi dimenzemi a ukazateli ve smyslu tabulky 3.
