(ITSM) (KPI's) v IT a podle

(1)

MA S A R Y K O V A U N I V E R Z I T A

F A K U L T A I N F O R M A T I K Y

Měřitelnost a reportování podle klíčových ukazatelů výkonnosti

(KPI's) v řízení IT služeb (ITSM)

D I P L O M O V Á P R Á C E

Bc. Filip Pražák

Brno, podzim 2017

(2)

(3)

Prohlášení

Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Bc. Filip Pražák

Vedoucí práce: Ing. Aleš Studený

(4)

(5)

Poděkování

Tímto bych chtěl poděkovat Ing. Aleši Studenému za vedení diplo

mové práce. Dále taky všem, kteří na mě mysleli a podporovali po celé mé studium včetně Jeho. A v neposlední řadě těm, kteří někdy řekli, že to nezvládnu, protože tím se stali mým hnacím motorem.

(6)

Shrnutí

Diplomová práce se zabývá tématikou neustálého zlepšování služeb v oblasti reportování. První tři kapitoly představují teoretická výcho

diska vycházející z odborné literatury Čtvrtá kapitola se zabývá ana

lýzou současných ALVAO reportů a návrhem nových. Na základě informací zjištěných během diplomové práce byly vytvořeny nové reporty, které se během příštího roku zapracují do produktu ALVAO Service Desk.

iv

(7)

Klíčová slova

ITIL, ITSM, nejlepší praktiky, měření, reportování, neustálé zlepšování služeb, Demingův cyklus

(8)

(9)

Obsah

Úvod 1 1 ITSM a ITIL 3

1.1 IT Service Management (ITSM) 3 1.1.1 Obsah a rozsah ITSM 3 1.1.2 Prínosy ITSM 5 1.2 ITIL a jeho historie 9

1.2.1 Historie a vývoj ITIL® 9 1.2.2 Co je to ITIL® 10 1.2.3 Vymezení klíčových pojmů 12

2 Měřitelnost a metriky 17 2.1 Proč měříme? 18 2.2 CSFs a KPIs 20 2.3 Co jsou metriky? 22

2.3.1 Proč metriky nejsou SLAs 23 2.4 Kaskádové metriky a jejich hierarchie 24

2.4.1 ITIL cesta od vize k měření 24 2.4.2 Balanced scorecard 25 2.4.3 IT komponenty v scorecard hierarchii 28

2.4.4 SWOT analýza 29 2.4.5 Demingův cyklus 30

2.5 Reportování 31 2.5.1 Zvýšení hodnot reportů 32

3 Nejlepší praktiky vybraných procesů 35

3.1 Event Management 35 3.2 Information Management 38 3.3 Incident Management 39 3.4 Problém Management 40 4 ALVAO a reportování 47

4.1 Analýza ALVAO reportů 48 4.2 Návrh nových ALVAO reportů 91

4.2.1 Návrh pro vývoj s novými reporty 94

(10)

5 Výsledky a vyvozené závěry 137

6 Přílohy 139 6.1 Hodnocení zákazníků 139

6.2 Obrázky 139 6.2.1 Analýza reportů ALVAO 139

6.2.2 Dotazník zjišťující kvalitu ALVAO reportování . . . 168

Bibliografie 171

viii

(11)

Seznam tabulek

2.1 CSF s vybranými KPIs 22

2.2 Příklady CFS s jednotlivými perspektivami balanced scorecard 27

2.3 Příklad IT komponenty v scorecard hierarchii 29

(12)

(13)

Seznam obrázků

1.1 Diagram ITSM [16] 4 2.1 Proč měříme [3] 19

2.2 Řetězec od požadavku k reportu [4] 24 2.3 Cesta od vize k měření [14] 25

2.4 Balanced scorecard [8] 26 2.5 Demingův cyklus [14] 31

3.1 AĽVAO katalog služeb ve službě technická podpora 37 3.2 Diagram Paretovy analýzy [9] 43

4.1 Přihlašování Service Desk Anály sis esy 49 4.2 Graf - Otevřené požadavky 51

4.3 Kontingenční tabulka k záložce „Otevřené požadavky" 52

4.4 Pohled na průtok požadavků 54

4.5 Kontingenční tabulka průtoku požadavků ve službě

„Technická podpora" 55

4.6 Pohled na první reakci dodavatele 57

4.7 Kontingenční tabulka první reakce dodavatele ve službě

„Technická podpora" a s daným řešitelem 58 4.8 Pohled na následnou reakci dodavatele 61

4.9 Část kontingenční tabulky následné reakce dodavatele ve službě „Technická podpora" 62

4.10 Graf zobrazující průběžné informování dodavatelem 65 4.11 Část kontingenční tabulky ze záložky informování

dodavatelem ve službě „Technická podpora" 66 4.12 Graf zobrazující řešení požadavku v čase 69

4.13 Graf zobrazující počet znovuotevření a dobu do vyřešení v hodinách 72

4.14 Kontingenční tabulka znovuotevření požadavků 73 4.15 Graf zobrazující vykázaný čas v hodinách u jednotlivých

požadavků 76

4.16 Kontingenční tabulka deníku ve službě „Technická podpora" 77

4.17 Graf zobrazující způsob založení jednotlivých požadavků 79

(14)

4.18 Počet jednotlivých požadavků podle typu založení na záložce „Požadavky" 80

4.19 Graf zobrazující počet vytvořených požadavků v

závislosti na dni v týdnu a hodině v průběhu dne 82 4.20 Kontingenční tabulka záložky „Vytváření

požadavků" 83

4.21 Graf zobrazující počet vyřešených požadavků v závislosti na dni v týdnu a hodině v průběhu dne 85

4.22 Kontingenční tabulka záložky „Vyřešení požadavků" 86 4.23 Graf i s kontingenční tabulkou záložky „Dotazník

spokojenosti" 89

4.24 Návrh pro vývoj - záložka Otevřené požadavky - služby 97 4.25 Graf - záložka Otevřené požadavky - služby 98

4.26 Kontingenční tabulka - záložka Otevřené požadavky - služby 99

4.27 Návrh pro vývoj - záložka Otevřené požadavky - řešitelé 100

4.28 Graf - záložka Otevřené požadavky - řešitelé 101 4.29 Kontingenční tabulka - záložka Otevřené požadavky -

řešitelé 102

4.30 Návrh pro vývoj - záložka Bilance požadavků 103 4.31 Graf - záložka Bilance požadavků 104

4.32 Kontingenční - záložka Bilance požadavků 105 4.33 Návrh pro vývoj - záložka Průtok požadavků 106 4.34 Graf - záložka Průtok požadavků 107

4.35 Kontingenční tabulka - záložka Průtok požadavků 108 4.36 Návrh pro vývoj - záložka První reakce - průměrná 109 4.37 Graf - záložka První reakce - průměrná 110

4.38 Kontingenční tabulka - záložka První reakce - průměrná 111

4.39 Návrh pro vývoj - záložka. První reakce - plnění 112 4.40 Graf - záložka První reakce - plnění 113

4.41 Kontingenční tabulka - záložka První reakce - plnění 114 4.42 Návrh pro vývoj - záložka Průb. informování -

průměrné 115

4.43 Graf - záložka Průb. informování - průměrné 116 4.44 Kontingenční tabulka - záložka Průb. informování -

průměrné 117 xii

(15)

4.45 Návrh pro vývoj - záložka Doba do vyřešení - průměrná 118

4.46 Graf - záložka Doba do vyřešení - průměrná 119 4.47 Kontingenční tabulka - záložka Doba do vyřešení -

průměrná 120

4.48 Návrh pro vývoj - záložka Deník 121 4.49 Graf - záložka Deník 122

4.50 Kontingenční tabulka - záložka Deník 123 4.51 Návrh pro vývoj - záložka Požadavky 124 4.52 Graf - záložka Požadavky 125

4.53 Kontingenční tabulka - záložka Požadavky 126 4.54 Návrh pro vývoj - záložka Vytváření požadavků 127 4.55 Graf - záložka Vytváření požadavků 128

4.56 Kontingenční tabulka - záložka Vytváření požadavků 129 4.57 Návrh pro vývoj - záložka Vyřešení požadavků 130 4.58 Graf - záložka Vyřešení požadavků 131

4.59 Kontingenční tabulka - záložka Vyřešení požadavků 132 4.60 Návrh pro vývoj - záložka Dotazník spokojenosti 133 4.61 Graf - záložka Dotazník spokojenosti 134

4.62 Kontingenční tabulka - záložka Dotazník spokojenosti 135 6.1 Přihlašování do Service Desk Analysis esy se 7 dny 240 6.2 Otevřené požadavky - 7 dní z DB 141

6.3 Průtok požadavků - 7 dní z DB 242 6.4 První reakce dodavatele - 7 dní z DB 243 6.5 Následná reakce dodavatele - 7 dní z DB 244

6.6 Průběžné informování dodavatelem - 7 dní z DB 245 6.7 Řešení požadavku - 7 dní z DB 246

6.8 Znovuotevření požadavku - 7 dní z DB 247 6.9 Deník - 7 dní z DB 148

6.10 Požadavky - 7 dní z DB 249

6.11 Vytváření požadavků - 7 dní z DB 250 6.12 Vyřešení požadavků - 7 dní z DB 252 6.13 Dotazník spokojenosti - 7 dní z DB 252 6.14 Otevřené požadavky ve službě „Technická

podpora" 253

6.15 Průtok požadavků ve službě „Technická podpora" 254

(16)

6.16 První reakce dodavatele ve službě „Technická podpora" 255

6.17 První reakce dodavatele ve službě „Technická podpora" a daným řešitelem 256

6.18 Následná reakce dodavatele ve službě „Technická podpora" 257

6.19 Graf zobrazující průběžné informování dodavatelem ve službě „Technická podpora" 158

6.20 Graf zobrazující řešení požadavku v čase ve službě

6.21 Kontingenční tabulka řešení požadavku v čase ve službě

6.22 Souhrn jednotlivých překročených SLA ve službě

„Technická podpora " 262

6.23 Graf zobrazující znovuotevření požadavků ve službě

6.24 Graf zobrazující vykázaný čas v hodinách u jednotlivých požadavků ve službě „Technická podpora" 263 6.25 Graf zobrazující vykázaný čas v hodinách u jednotlivých

požadavků ve službě „Technická podpora" a podle SLA

„B4 - negarantovaná technická podpora" 264 6.26 Rozbor požadavku číslo 73728 265

6.27 Graf dotazníku spokojenosti s hodnotami „Profesionalita"

a „Odbornost" 266

6.28 Graf dotazníku spokojenosti pouze s hodnotou

„Profesionalita" 267

6.29 Jednotlivé požadavky u kterých byl vyplněn dotazník spokojenosti 168

6.30 Dotazník zkoumající situaci u zákazníků AĽVAO 269 6.31 Vyplněný dotazník zkoumající současnou situaci od

zákazníka ALVAO 270

xiv

(17)

Úvod

V dnešním světě je komunikace součástí každodenního života. Již po prvních slovech lze člověka zařadit do určité skupiny. Pokud jeho první slova nezapadají do obecných měřítek, často může být posuzován záporně, jako nesympatický. V současné době je komunikace člověka s IT světem nedílnou součástí života každého z nás.

Reportování je jednou z forem komunikace světa počítačů k nám, k lidem. Dělá ze světa IT techniky, která často říká pouze jednotlivá slova, partnera, který s lidmi komunikuje formou souvislých vět. Stejně rychle jako člověk umí odsoudit druhého člověka, lze stejným způso

bem odsoudit i daný report. Tím se neodsoudí pouze daný report (ale i vykonávaná práce) k záhubě, protože člověk přijde o cestu k infor

macím, které počítač nasbíral, možná i ve spolupráci s dalšími lidmi.

Měření společně s reportováním se proto stává důležitým faktorem nejen IT světa. Každý IT manažer dnes potřebuje reportovat, ať již kvůli nadřízeným, podřízeným nebo pro sebe. Proto je potřeba sbírat kvalitní a správná data, která tvoří správnou základnu pro reportování.

Pokud jsou tato data sbírána, je nutné se zamyslet, pro koho jsou dané reporty tvořeny a co mají ukazovat. IT management tak musí nalézt vhodnou cestu, jak data vizualizovat. Pokud si vybere špatnou formu reportování, stanou se z českých vět věty čínské a těm každý porozumět neumí.

Cílem práce je neustálé zlepšování služeb v oblasti reportování ve firmě A Ľ V A O . Součástí práce je analýza nejlepších praktik v ob

lastí řízení IT, analýza současných A L V A O reportů a popis daných problémů. Dále práce obsahuje návrh se změnami v reportech pro vývojové oddělení a nově navržené reporty.

Práce je rozdělena do šesti kapitol. První tři se zabývají teoretic

kými poznatky o měřitelnosti a reportování. Čtvrtá kapitola obsa

huje praktickou část složenou z analýzy současných AD7AO reportů a návrhu nových. V páté kapitole jsou vyvozené závěry a výsledky.

Poslední kapitola obsahuje přílohy, které nejsou potřebné v textu di

plomové práce.

(18)

(19)

1 ITSMalTIL

1.1 IT Service Management (ITSM)

Smysl existence každého podniku je dán jeho podnikovou strategií, která mimo jiné definuje, co je předmětem jeho podnikání, jakými čin

nostmi se podnik zabývá, jak je organizovaný a řízený, jaké jsou jeho cíle například v oblasti marketingu, výroby, financí atd. Podnikové procesy v podniku existují proto, aby s jejich pomocí mohl podnik dosáhnout svých cílů determinovaných podnikovou strategií. Podoba podnikových procesů proto vychází z podnikové strategie. Tyto pro

cesy v celé řadě případů buď úplně stojí na používání informačních a komunikačních technologií (ICT), nebo s nimi alespoň úzce souvisí.

Disciplína, která se této oblasti věnuje, se nazývá IT Service Ma

nagement neboli řízení služeb informačních technologií. Je to souhrn nejlepších praxí a referenčních modelů procesů řízení služeb IT. IT Service Management (ITSM) představuje způsob řízení informačních a komunikačních technologií, jejich provozu i rozvoje, který využívá principů řízení na bázi služeb, zahrnuje tedy pohled zákazníků i po

skytovatele samotných IT služeb [18].

V ITSM je třeba vydefinovat a popsat služby, které podniková informatika poskytuje zaměstnancům, naučit zaměstnance s těmito službami pracovat v kontextu jejich každodenních činností a následně tyto služby kontinuálně řídit, a to jak na operativní, tak i taktické a strategické úrovni [16].

Podle oficiálního slovníku je ITSM implementace a správa kvality služeb IT, která splňuje potřeby businessu. Správa služeb IT je vy

konávána poskytovateli služeb IT za využití vhodné kombinace lidí, procesů a informačních technologií [2].

1.1.1 Obsah a rozsah ITSM

ITSM jako manažerská disciplína zahrnuje tři relativně samostatné, ale přesto navzájem propojené a na sobě závislé oblasti. Tuto závislost lze znázornit jako vzájemně propojené vrcholy jednoho trojúhelníku (viz diagram ITSM):

(20)

i . ITSM A ITIL

Lidé

Nástroje Procesy

Obrázek 1.1: Diagram ITSM [16]

• Lidé

Všichni zaměstnanci podniku, kteří přicházejí do kontaktu se službami IT, tj. uživatelé, kteří se službami IT pracují na denní bázi, jejich manažeři, kteří s útvarem podnikové informatiky vyjednávají parametry služeb IT, interní podnikoví IT specialisté, kteří zajišťují dodávku a podporu služeb IT, a v neposlední řadě externí dodavatelé.

• Nástroje

Nástroje usnadňující řízení služeb a infrastruktury IT a nástroje automatizující rutinní činnosti a spolupráci různých lidí.

Zejména sem tedy patří nástroje pro:

- monitoring,

- správu a řízení komponent infrastruktury IT,

- nástroje pro řízení životního cyklu incidentů, požadavků, problémů, změn a dalších entit,

- knihovny elektronické dokumentace a software, - ukládání a sdílení dat, informací a znalostí, - komunikaci.

4

(21)

i . ITSM A ITIL

• Procesy

Veškeré organizačně-procesní prvky systému řízení služeb IT, zejména definice pojmů, vymezení aktivit, rolí a jejich odpo

vědností, definice vstupů a výstupů aktivit a procesů, definice komunikačních kanálů, metrik, reportingu a dokumentace ce

lého systému. Tímto aspektem rozumíme jak jednotlivé ITSM procesy či jejich dílčí aktivity, resp. jejich ostatní prvky (role, metriky atd.), tak celé systémy řízení služeb IT, které se skládají ze všech těchto organizačně-procesních prvků.

Pro každý ze tří výše uvedených aspektů existuje v oboru ITSM možnost jeho nezávislé certifikace, tzn. ověření toho, zda konkrétní člověk, nástroj či systém řízení služeb splňuje parametry definované určitou normou, resp. certifikační autoritou, což následně pomáhá při implementaci systémů řízení služeb IT [16].

1.1.2 Přínosy ITSM

Implementace systémů řízení služeb IT má celou řadu kvalitativních i kvantitativních přínosů, a to jak pro samotný útvar podnikové in

formatiky, tak pro podnik jako celek. Osm nej důležitějších přínosů korelující jeden s druhým [16]:

1. Zvýšení spokojenosti zákazníků:

• již po velmi krátké době zavedení ITSM se zlepšuje spoko

jenost uživatelů,

• service desk je jedním z největších pomocníků,

• pocit spokojenosti se liší podle povahy jednotlivých uživa

telů.

2. Eliminace zbytečné práce:

• v jednom systému udržované všechny informace,

• jednotliví zaměstnanci mají přiřazené role, které mají vyko

návat,

• vzájemná koordinace mezi skupinami specialistů díky jed

nomu systému,

(22)

i . ITSM A ITIL

• kompletní přehled právě řešených požadavků.

3. Zvýšení konkurenceschopnosti:

• služby IT řízené prostřednictvím sofistikovaného systému, jenž je založen na osvědčených „best practice", jsou spo

lehlivější, než služby takto neřízené,

• díky Demingovu cyklu a jeho neustálého zlepšování služeb [14].

4. Vyšší produktivita a využívání znalostí:

• vytvoření znalostní databáze v závislosti na „problém ma

nagementu,"

• vyšší produktivita zaměstnanců vzniká díky zajištění větší dostupnosti a spolehlivosti služeb.

5. Zvýšení dostupnosti a spolehlivosti služeb:

• analýza výpadků služeb z toho vyplývající správné nasta

vení SLA's,

• asset management a s ním spojený konfigurační manage

ment nám ukážou oslabená místa v naší infrastruktuře.

6. Zlepšení komunikačních toků

• organizování pro neustálé zlepšování služeb,

• komunikační toky rozšiřují prostor pro plánování a vytvá

ření tzv. „quickwins" [14].

7. Omezení nákladů na změny obchodních procesů

• Omezení nákladů na vytváření byznys (neboli obchod

ních) procesů, procedur a na implementaci nových služeb je dosahováno díky samotné existenci procesů ITSM a díky transparentnímu stanovení rolí a odpovědností při jejich řízení, neboť součástí těchto procesů jsou i procedury pro hladké řízení integrace nových požadavků do stávajícího systému řízení podnikové informatiky [16].

6

(23)

i . ITSM A ITIL

• Protože se v dnešní době prakticky žádný byznys proces neobejde bez podpory služeb informačních technologií, je bezpodmínečně nutné, aby při zavádění nového, resp. re- designu stávajícího byznys procesu bylo součástí těchto aktivit i specifikování požadavků na informační technolo

gie včetně požadavků na poskytování podpory služeb IT potřebných k zajištění chodu tohoto byznys procesu. Tyto požadavky jsou zpracovány prostřednictvím procesů port

folio management a service level management, které zajistí, aby byly posouzeny jako jeden celek (s pomocí instrumentu nazvaného service level requirements - SLR). Díky tomu budou vzájemně odsouhlaseny a následně zaintegrovány do stávajících procesů systému řízení služeb IT, a to jed

nak prostřednictvím smluv typu operation level agreement a kontraktů na podporu poskytovanou externími partnery, a jednak prostřednictvím nového, resp. upraveného doku

mentu typu service level agreement obsahujícího vzájemně odsouhlasené veškeré aspekty dodávky a podpory služeb IT potřebné pro tento nový, resp. modifikovaný byznys proces.

Bez existence procesů ITSM, tedy bez existence instrumentů na řízení požadavků na dodávku, resp. změnu dodávky služeb IT, se nově vytvářené či modifikované byznys pro

cesy stávají zranitelnými a křehkými, protože neexistuje jistota, že všechny požadavky na informační technologie byly jednak správně pochopeny, a jednak správně integro

vány do stávajících procesů a aktivit [16].

8. Měření efektivity a hospodárnosti

• Implementace systémů řízení služeb IT vnáší do podnikové informatiky transparentnost díky schopnosti měřit skuteč

nou efektivitu a hospodárnost IT zdrojů. Přestože nějaké metriky pro jejich měření většinou v každém podniku exis

tují, bez implementace systému řízení služeb IT není vůbec možné hovořit o tom, že máme k dispozici věrohodné údaje o efektivitě a hospodárnosti podnikové informatiky jako celku. Teprve máme-li vydefinovány jednotlivé procesy

(24)

i . ITSM A ITIL

a aktivity a k nim přidělené konkrétní role, specifikovány metriky pro každou skutečně klíčovou aktivitu, vydefino- vány parametry služeb IT a následně implementován mo

nitoring pro jejich sledování a zaznamenávání, můžeme přistoupit k vyhodnocování efektivnosti jednotlivých čin

ností, rolí, služeb a infrastrukturních komponent fungují

cích efektivně a naopak. Teprve na základě těchto zjištění pak můžeme přistoupit k vylaďovaní jednotlivých prvků systému řízení služeb IT a zvyšování jeho výkonnosti.

Bez implementovaného systému řízení služeb IT tedy není možné určit, kolik a jakých zdrojů je zapotřebí pro zabezpe

čení chodu jednotlivých služeb IT, resp. které komponenty by bylo vhodné nahradit hospodárnějšími, a tudíž nelze smysluplně měřit ani efektivitu, ani hospodárnost podni

kové informatiky.

Důsledkem schopnosti měřit efektivitu a hospodárnost podnikové informatiky je možnost poskytovat obchodním útvarům kvalitní služby IT i za situace:

- existence rozpočtových omezení,

- nedostatku zdrojů (lidských i finančních, interních i externích),

- rostoucí složitosti systémů, - obrovské rychlosti změn, - růstu očekávání zákazníků.

Bez zavedení systému řízení služeb IT není v současné době možné se efektivně vypořádat se všemi výše uvedenými omezeními a hrozbami, aniž by neutrpěla kvalita dodáva

ných služeb.

Investice do systému řízení služeb IT je tedy strategic

kým záměrem, který je vynucený okolnostmi dnešní doby [16].

8

(25)

i . ITSM A ITIL 1.2 ITIL a jeho historie

1.2.1 Historie a vývoj JTÍL®

První verze knihovny ITIL® (označovaná jako ITIL® VI) spatřila světlo světa koncem 80. let minulého století, kdy britská vládní agen

tura CCTA, Central Computer and Telecommunications Agency, za

čala postupně vydávat jednotlivé publikace shrnující nejlepší zkuše

nosti z oblasti řízení služeb IT (první svazek ITIL® VI vyšel v roce 1989, celá knihovna VI čítala příjemných 46 svazků).

Klíčovým rysem ITIL® již tehdy bylo, že se nejednalo o pravidla vymyšlená úředníky či teoretiky, ale o skutečnou a osvědčenou praxi.

Díky tomu, že ITIL® obsahoval postupy, které skutečně fungovaly, došlo k jeho rychlému rozšíření mimo britský vládní sektor, pro nějž byl původně určen, a zhruba od přelomu století je ITIL® považován za mezinárodně akceptovaný standard pro řízení služeb informačních technologií.

Celosvětovému rozšíření ITIL® napomohly dvě další významné okolnosti, k nimž došlo na začátku 90. let minulého století:

• Založení sdružení itSMF, IT Service Management Fórum, v roce 1991 ve Velké Británii. Toto sdružení se zformovalo okolo autorů a recenzentů první verze knihovny s cílem sdílet zkušenosti z oboru ITSM, avšak brzy začaly být zakládány pobočky itSMF i v dalších státech (v ČR až v roce 2006), a to jako neziskové organizace sdružující IT manažery a ITSM specialisty.

• Zavedení mezinárodně akceptovaných certifikací odborné způ

sobilosti v ITSM. Jednotlivé podniky zjistily, že pro řízení infor

matiky potřebují nejen technicky, ale i manažersky kvalifikované odborníky, a tak začaly pro obsazení klíčových manažerských pozic v IT vyžadovat znalost řízení služeb IT potvrzenou certifi

kační zkouškou.

Vývoj druhé verze knihovny ITIL® (označované jako ITIL® V2) započal koncem 90. let ještě pod vedením CCTA. První publikace této druhé verze ITIL®, kniha Service Support (některými odborníky považovaná do dnešního dne za nejúspěšnější publikaci v celé historii knihovny vůbec), vyšla v roce 1999. Důležitým mezníkem v historii

(26)

i . ITSM A ITIL

ITIL(R) byl zánik agentury CCTA v roce 2000 a převod správy knihovny na nově vzniklou agenturu OGC, jež je současným vlastníkem pod názvem Cabinet Office ITIL®. OGC pak dokončil vydání druhé verze knihovny poslední publikace druhé verze vyšla až v roce 2006. V této verzi měla knihovna celkem 10 titulů.

Práce na třetí verzi knihovny ITIL® (označované jako ITIL®

V3) započaly již v dubnu 2004, tzn. dva roky před vydáním poslední publikace druhé verze, a byly završeny 31.5.2007 vydáním pěti ústřed

ních publikací ITIL®. Nicméně tím rozvoj třetí verze knihovny zda

leka neskončil - postupně byly a stále jsou vydávány další doplňující a rozšiřující publikace, takže současná podoba knihovny čítá okolo 20 svazků.

Pět ústředních publikací ITIL® a „Výkladový slovník pojmů a zkratek" byly v roce 2011 aktualizovány (tato verze je označovaná jako ITIL® 2011 Edition), ostatních publikací se tato aktualizace ne

dotkla [16].

V roce 2016 vyšla poslední kniha s názvem ITIL® Practitioner Guidance, která slouží jako podklad ke splnění certifikace úrovně practitioner. Dále je tato publikace praktickým průvodcem, který po

máhá odborníkům v oblasti ITSM obrátit teorii ITIL do praxe prostřed

nictvím případových studií, pracovních listů, šablon a scénářů.

1.2.2 Co je to ITIL®

Pohled byznysu: ITIL® je lehce upravitelný rámec best practice, s po

mocí kterého byznys organizace dosáhne požadovanou kvalitu IT služeb a překoná překážky, související s rozvojem svých IT systémů.

Pohled IT: ITIL® je fyzicky sada knižních publikací, která obsa

huje sbírku nejlepších zkušeností z oboru řízení služeb informačních technologií. Tyto publikace jsou ve vlastnictví britské společnosti AXE- LOS Ltd., která kromě ITIL® spravuje ještě šest dalších celosvětově používaných manažerských rámců a metodik, z nichž v ČR nejzná- mější je metodika řízení projektů PPJNCE2®.

Název „ITIL® " vznikl jako zkratka slov „Information Technology Infrastructure Library", nicméně v současné verzi knihovny již není původní význam těchto 4 písmen nikde uváděn, dokonce ani v oficiál

ním ITIL® výkladovém slovníku, zřejmě proto, že obsah knihovny se 10

(27)

i . ITSM A ITIL infrastruktuře informačních technologií věnuje jen z pohledu jejího řízení, a to ještě jen ve vztahu ke službám IT, nikoliv k technologiím jako takovým [16].

ITIL® ve své současné verzi obsahuje:

• Pět klíčových publikací:

1. Service Stratégy lze chápat jako návod, jak se navrhuje, vy

víjí a implementuje správa služeb. Obsah tohoto svazku se vztahuje např. k vývoji na domácích a zahraničních trzích, aktivům služby a implementaci strategie pro celý životní cyklus služby.

2. Service Design nabízí návody pro návrh a vývoj služeb a procesů. Představuje designové metody a principy, po

mocí kterých lze převést strategické cíle do portfolia služeb a aktiv služby.

3. Service Transition se stará o zavádění nových nebo pozmě

něných služeb do výrobního prostředí.

4. Service Operation se zabývá činnostmi s ohledem na účin

nost a efektivitu dodávky a provozu služeb.

5. Continual Service Improvement poskytuje nástroje a ná

vody pro nepřetržité zlepšování služeb a všech dříve zmí

něných aspektů jako je návrh, zavádění a provoz služeb IT [12].

• Dvě desítky publikací

Zaměřující se na jednotlivé aspekty ITSM, resp. svým obsa

hem cílí na specifické čtenáře. Mimo jiné zde nalezneme knihy, které pomáhají připravit uchazeče na certifikační zkoušky pro

fesní způsobilosti. Množina těchto knih je průběžně rozšiřována (každý rok vychází několik nových publikací) [16].

Poskytovatelé služeb IT a IT organizace se musí vypořádat s množ

stvím externích požadavků, které se týkají i problematiky ITIL®, a tam, kde se jejich použití osvědčilo, jsou integrovány.

• Výkladový slovník

(28)

i . ITSM A ITIL

Slovník pojmů a zkratek, jenž mezinárodně kodifikuje termi

nologii v oboru ITSM. Tento slovník je k dispozici v překladu do mnoha jazyků včetně češtiny a je možné jej volně stahovat a používat za určitých podmínek [16].

1.2.3 Vymezení klíčových pojmů

Nyní se následuje seznam popsaných vybraných pojmů, které budou dále používány v diplomové práci [2]:

• Balanced scorecard - Manažerský nástroj vyvinutý doktory Ro

bertem Kaplanem (Harvard Business School) a Davidem Norto- nem. Balanced scorecard umožňuje rozčlenit strategii do klíčo

vých ukazatelů výkonnosti (KPIs). Výkonnost měřená pomocí KPI se používá k prezentaci toho, do jaké míry byla strategie úspěšná. Balanced scorecard má 4 hlavní oblasti, každou z nich reprezentovanou několika KPI. Tyto čtyři oblasti jsou posuzo

vány v různých úrovních podrobnosti v celé organizaci.

• Benchmark (Referenční bod ve srovnávacím testu) - Výchozí stav (baseline), jenž je použit pro porovnání příbuzných mno

žin dat jako součást provedení benchmarkingu. Např. aktuální snímek procesu může být porovnán s předchozím stavem téhož procesu, nebo lze současný stav porovnat s externími údaji nebo s nejlepšími praktikami.

• Best practices (Nejlepší praktiky) - Osvědčené činnosti nebo procesy, které byly úspěšně použity několika organizacemi. ITIL je příkladem nejlepších praktik.

• Budget (Rozpočet) - Seznam plánovaných příjmů a výdajů or

ganizace nebo podnikové jednotky pro definované období.

• Business (Byznys) - Korporátní entita nebo organizace, která se skládá z více podnikových jednotek. V kontextu ITSM vý

raz business zahrnuje veřejný sektor a neziskové organizace stejně jako firmy. Poskytovatel služby IT poskytuje službu IT zákazníkovi v rámci businessu. Provozovatel služby IT může být součástí stejné firmy jako jeho zákazník (interní poskytovatel služby) anebo částí jiné firmy (externí poskytovatel služby).

12

(29)

i . ITSM A ITIL

• Continual Service Improvement (CSI) (Neustálé zdokonalo

vání služeb) - Etapa životního cyklu služby. Neustálé zlepšování služeb zajišťuje, aby služby odpovídaly měnícím se potřebám byznysu, a to tak, že se identifikují a implementují zlepšení slu

žeb IT, která podporují podnikové procesy. Výkonnost poskyto

vatele služeb IT se průběžně měří a realizují se zlepšení procesů, služeb IT a infrastruktury IT za účelem zvýšení hospodárnosti, efektivity a nákladové efektivity. Neustálé zlepšování služeb je zlepšovacím procesem v sedmi krocích. I když tento proces je přiřazen neustálému zlepšování služeb, většina procesů má činnosti, které se realizují ve více fázích životního cyklu služby.

Viz také Demingův cyklus, „Pian - Do - Check - Act".

• Configuration item (Cl) (Konfigurační položka) - Jakákoliv kom

ponenta nebo jiné aktivum služby, které by měly být spravovány za účelem dodávky služby IT Informace o všech konfiguračních položkách jsou zaznamenány v konfiguračním záznamu v sys

tému správy konfigurací (CMS) a jsou udržovány během jejich životního cyklu správou aktiv služeb a konfigurací. Konfigurační položky jsou řízeny správou změn. Typicky zahrnují služby IT, hardware, software, stavby, lidi a formální dokumentaci, jako je dokumentace procesů a SLA.

• Critical Success Factor (CSF) (Rozhodující faktor úspěchu) - Něco, co se musí stát, aby služba IT, proces, projekt, plán nebo další aktivita dosáhly úspěchu. Dosažení tohoto faktoru se měří klíčovými ukazateli výkonnosti (KPI). Např. rozhodující faktor úspěchu „ochrana IT služeb při provádění změn", je měřitelný takovými klíčovými ukazateli výkonnosti jako jsou „procentuální redukce neúspěšných změn", „procentuální redukce změn způ

sobujících incident", atd.

• First-line support (První úroveň podpory) - První úroveň v hi

erarchii podpůrných skupin začleněných do řešení incidentů.

Každá vyšší úroveň má k dispozici specialisty s hlubšími zna

lostmi nebo má více času nebo dalších zdrojů.

• Gap analysis - Diferenční analýza - Činnost, která srovnává dvě množiny dat a identifikuje rozdíly mezi nimi. Diferenční

(30)

i . ITSM A ITIL

analýza je obvykle užívána pro porovnání množiny požadavků s aktuální dodávkou, viz také benchmarking.

• Key Performance Indicator - KPI (Klíčový ukazatel výkonnosti) - Metrika, která pomáhá řídit služby IT, procesy, plánovat pro

jekty nebo další činnosti. Klíčové ukazatele výkonnosti se pou

žívají pro měření, zda byly dosaženy kritické faktory úspěchu (CSF). Lze měřit mnoho metrik, ale jen ty nej důležitější jsou definovány jako klíčové ukazatele výkonnosti a jsou aktivně používány při řízení procesů, služeb IT nebo činností a jejich vykazování. Měly by být vybrány tak, aby sloužily ke komplexní správě hospodárnosti, celkové efektivity a efektivity nákladů.

• Operational Level Agreement - OLA (Dohoda o úrovni pro

vozních služeb) - Dohoda mezi poskytovatelem služeb IT a další součástí téže organizace. Podporuje dodávku služeb IT posky

tovatelem služeb zákazníkům IT a definuje zboží nebo služby, které by měly být poskytnuty, a odpovědnosti obou stran. Např.

dohoda může vzniknout:

- mezi poskytovatelem služeb IT a oddělením nákupu, aby obstaralo hardware v dohodnutém čase,

- mezi service deskem a podpůrnou skupinou, aby zajistila vyřešení incidentu v dohodnutém čase.

• Service request (Požadavek na službu) - Formální požadavek uživatele na něco, co má být poskytnuto - např. požadavek na informaci nebo radu, na obnovení hesla, nebo na instalaci pracovní stanice pro nového uživatele.

• Service Level Agreement (SLA) (Dohoda o úrovních služeb) - Dohoda mezi poskytovatelem služeb IT a zákazníkem. Do

hoda o úrovních služeb popisuje službu IT, dokumentuje cíle úrovní služeb a specifikuje odpovědnosti poskytovatele služeb IT a zákazníka. Jedna dohoda o úrovni služeb může pokrývat řadu služeb IT nebo více zákazníků. Viz také dohoda o úrovni provozních služeb (OLA).

• Underpinning Contract (UC) (Podpůrná smlouva) - Smlouva mezi dodavatelem služeb IT a třetí stranou. Třetí strana dodává 14

(31)

i . ITSM A ITIL zboží nebo služby, které podporují dodávku služby IT zákazní

kovi. Podpůrná smlouva definuje cíle a odpovědnosti, které jsou požadovány za účelem splnění cílů úrovně služeb v rámci jedné nebo více smluv o úrovních služeb (SLA).

(32)

(33)

2 Měřitelnost a metriky

Když můžete měřit to, o čem mluvíte a vyjádřit to v číslech, tak o tom něco víte, ale když to v číslech vyjádřit neumíte, jsou vaše znalosti skromné a neuspoko

jivé. Může to být začátek poznání, ale sotva ve svých myšlenkách pokročíte do nejaké vedy.—Lord Kelvin, Britský fyzik a člen Sněmovny Lordů, 1824-1907.

Měřit lze cokoli. Pokud můžeme něco nějakým způsobem vnímat, tak se to hodí k nějakému typu měřicí metody. Bez ohledu na to, jak

„fuzzy" měření to je, je to stále měření, pokud vám to řekne víc než jste věděli dříve. A ty věci, které vám připadají neměřitelné, jsou prakticky vždy řešeny poměrně jednoduchou metodou měření [10].

Měřitelnost a metriky jsou pokládány za jádro ITSM a neustálého zlepšování služeb (CSI). Je důležité měřit, co bylo uděláno a co bylo doručeno, v pořadí co děláme dobře a co potřebuje být zdokonaleno k demonstrování hodnoty byznysu a zákazníkům, abychom mohli dělat objektivní rozhodnutí.

Měřitelnost je charakterizována jako jednotlivý údaj o chování něčeho, co nás zajímá. Např. datum a čas, kdy jeden z disků v poli RAID selhal, nebo datum a čas, od kdy disk selhal, do jeho obnovení do provozu.

Metrika je charakterizována jako něco, co je měřeno a reportováno ke zlepšení řízení procesů, IT služeb nebo aktivit. Např. maximální doba potřebná k obnovení po selhání disku v poli RAID.

Ve zkratce nám měřitelnost ukazuje část dat, která můžou být sbí

rána a metrika je něco již vypočítaného z jednoho nebo více měření [3].

Hodně poskytovatelů IT služeb zdá se věří, že cokoli může být měřeno, mělo by být měřeno. Často můžou reportovat stovky key performance indicators (KPIs) a generovat rozsáhlé reporty zobrazu

jící, jak si IT vede proti každému KPI. Ti co znají ITIL podrobněji, ví, že existuje mnoho KPIs. Adoptování všech KPIs z ITIL publikací by poskytlo 355 věcí k měření a reportování. Samozřejmě KPIs v ITIL kni

hách jsou pouhé příklady a nikdo neočekává, že IT oddělení adoptuje všech 355 měření. Je důležité umět si správně vybrat. Pokud si adoptu

jeme příliš mnoho KPIs, tak potom může být velmi těžké identifikovat

(34)

2. MĚŘITELNOST A METRIKY

ty, na kterých opravdu záleží. Report, který obsahuje 250 cílů, které splňují dané KPIs a 105 takových, kteří nesplňují, nepomáhá iden

tifikovat, co je potřeba zdokonalit. Objemný počet dat má tendenci skrýt významné věci. Malý počet dobře promyšlených KPIs se obecně ukázal mnohem cennějším. Je možné sbírat data, které aktuálně nejsou používány v reportech, protože tyto data mohou být užitečné v jiných specifických okolnostech, ale jinak ne. Zkusme se vyvarovat sbírání dat, které definitivně nepoužijeme a tak se taky definitivně vyvarujme reportování, které se skládá se zbytečných dat. Držme počet KPIs, které měříme a reportujeme na co nejmenším počtu můžeme [3].

2.1 Proč měříme?

Před začátkem měření je potřeba se ujistit, že rozumíme navrženým cílům a záměrům.

Na obrázku 2.1 můžeme vidět 4 důvody, proč lidé monitorují a měří:

1. ověřit (to validate) - slouží ke kontrole předchozích rozhodnutí, 2. řídit (to direct) - slouží k nastavení směru pro aktivity ve správ

ném pořadí, aby se setkali s danými cíli. Řízení je nejvíce převlá

dající důvod pro monitoring a měření,

3. zdůvodnit (to justify) - skutečnými důkazy, že jsme vybrali správný postup,

4. zakročit (to intervene) - umožňuje identifikovat bod zásahu včetně následných změn a nápravných opatření [3].

18

(35)

\ 0

s-—\ Targets

j^{( ) and}

/ metrics

O

To váli dáte

To justify

Your measurement framework

f ľ i

Value Performance realized,

factual evidence

Changes corrective actions

Obrázek 2.1: Proč měříme [3]

Poskytovatelé IT služeb používají měření k podpoření široké škály různých aktivit, jako:

• Zlepšení plánování - Monitoring a měřitelnost jsou často po

užívány k ujištění „Kde jsme nyní?", abychom mohli zajistit budoucí zdokonalování aktivit a měřit „Dostali jsme se tam?"

k vyhodnocení, zdali zdokonalení bylo efektivní, či nikoli.

• Detekování a reagování na události - Monitoring a měřitelnost je srdcem Event Managementu. Umožňuje IT organizaci detekovat změny ve stavech konfiguračních položek (Cl) a zasahovat při řešení detekovaných položek. Reakce na události neznamená pouze zaznamenávání incidentů a jejich okamžitou nápravu.

Nejlepší měření jsou prováděna včas, aby se problém / incident vyřešil dříve, než dopadne na zákazníka.

• Reporting - Ve všech organizacích potřebují produkovat roz

sáhlé reporty, které podporují mnoho různých aktivit. SLA re-

(36)

porty pro zákazníky slouží k ověření, že IT organizace doručuje dohodnuté služby a uspokojí budoucí zdokonalování aktivit.

Reporty pro vlastníka procesů jsou často přímé. Zajišťují, že se vlastník procesů soustřeďuje na korektní akce a zasahuje v pří

padě, že potřebují zdokonalit. Reporty můžou taky sloužit pro řízení dodavatelů, prokazovat splnění zákonných nebo regulač

ních požadavků a pro mnoho dalších účelů. Více o reportování v kapitole 2.5.

2.2 CSFsaKPIs

Critical success factor (CSF) neboli rozhodující faktor úspěchu je něco, co musí být dosaženo, pokud IT služba, proces, plán nebo další aktivita má být úspěšná. Přestože CSFs jsou důležité, jsou často těžko měřitelné.

Příklady CSFs můžou být:

• nová služba umožňuje obchodníkům trávit více času se zákaz

níky,

• výpadky IT služby nemají významný dopad na obchodí procesy zákazníků,

• webová stránka společnosti je chráněna před útoky hackerů.

Každý z těchto CSFs je důležitý, může je být ale různě náročné měřit. Takže je potřeba definovat klíčové ukazatele výkonnosti (KPIs), které podpoří možnosti měření. Na rozdíl od CSFs jsou dobré KPIs aktuálními metrikami. KPIs mají další funkce, které nejsou přímo aplikovatelné na CSFs. Tyto funkce nebo cíle jsou často sumarizovány pomocí nástroje nazývaného SMART [3].

SMART je jednoduchý nástroj napomáhající definovat cíle. Tento nástroj se uplatňuje především v rámci strategického řízení a řízení projektů, ale je možné ho použít i pro všechny ostatní oblasti (osobní cíle, cíle oddělení/firmy, cíle procesů, apod.).

SMART je zkratka anglických termínů pro různé oblasti definice cíle:

• S - Specific (specifický) - cíl musí být definován přesně. Čím přesněji je definován, tím snadněji se bude plnit a hlavně, pře- 20

(37)

dejde se možným nedorozuměním. Co je zřejmé pro jednoho, nemusí být vůbec zřejmé pro druhého.

• M - Measurable (měřitelný) - splnění cíle musí být možné změřit.

Měřením se rozumí posouzení, do jaké míry bylo cíle dosaženo.

Parametry měření by mělo být možné změřit exaktně (rozměry, váha, množství, vlastnosti, apod.).

• A - Accepted (akceptovaný) - cíl musí být akceptovaný odpo

vědnou osobou. Bez akceptace, přijetí cíle za své, se vždy najde něco „zajímavějšího" na práci.

• R - Realistic (reálný) - cíl musí být reálný. Musí být možné ho splnit v reálném čase, musí být k dispozici příslušné nástroje a znalosti, apod. Nemá cenu stanovovat nedosažitelné cíle.

• T - Timed (časově ohraničený) - cíl musí mít daný termín. Pokud není stanoven termín, splnění se bude odkládat „až bude čas,"

což nebude nikdy [17].

Na začátku sekce CSFs a KPIs jsou ukázány příklady CSFs. Níže můžeme vidět, jak spolu CSFs a KPIs souvisí. KPIs můžou pouze pomáhat demonstrovat dosažení daného CSF To je běžný vztah mezi CSFs a KPIs. K vyjasnění toho si nejprve ukážeme co KPI znamená:

• Key - KPI měří něco důležitého, ne nějaký malý aspekt toho, co se děje.

• Perfomance - KPI říká něco o tom, jak to dobře funguje.

• Indicator - KPI indikuje, jak dobře se něco dělá, ale samo o sobě to nedokazuje.

Tedy klíčové ukazatele výkonnosti KPI (Key performance indicators) jsou indikátory, ukazatele či metriky výkonnosti, které jsou přiřazeny procesu, službě, organizačnímu útvaru nebo celé organi

zaci a vyjadřují požadovanou výkonnost (kvalitu, efektivnost nebo hospodárnost) [11].

V tabulce 2.1 vidíme porovnání CSFs a KPIs. Ke každému CSF budou přidělena dvě KPIs. Někdy můžou být tři, nebo čtyři KPIs potřebné k podpoře CSF. Úroveň počtů KPIs je potřebné držet na

(38)

Tabulka 2.1: CSF s vybranými KPIs

Nová služba umožňuje ob

chodníkům trávit více času se zákazníky.

Zvýšení počtu zákazníku za den, kteří navštíví jednoho prodejce.

Dotazník spokojenosti pro

dejců se zvýší o polovinu bě

hem následujících 6 měsíců.

Výpadky IT služby nemají vý

znamný dopad na obchodí procesy zákazníků

Maximálně 4 výpadky služeb v každém roce.

Maximální čas výpadku je sta

noven na 30 minut pro každý výpadek.

Webová stránka společnosti je

chráněna před útoky hackerů Kritické záplaty jsou instalo

vány na všechny webové ser

very během 12 hodin od vy

dání oznámení.

Webová stránka prochází pe- netračními testy každých 6 mě

síců.

co nejnižší hodnotě. Pokud je jedno KPI úspěšné, můžeme definovat nové, ale je nutné se poté ujistit, že nám nové KPI generuje přidanou hodnotu.

2.3 Co jsou metriky?

Metriky jsou jiný termín pro měření a jsou důležitou sočástí manage

ment systému, který řídí a ovládá IT správným směrem. Metriky musí být navrženy spolu se zákazníkovými požadavky. Tyto požadavky musí být dosažitelné a monitorovatelné, aby bylo zajištěno jejich udr

žování [4]. Toto je cíl neustálého zlepšování služeb (CSI). Je velmi důležité porozumět cílům byznysu v používání metrik v ITSM [4].

22

(39)

Mezi základní cíle patří:

1. Propojit byznys cíle s IT:

• poskytovat účetnictví pro IT procesy a výstupy

• informovat zúčastněné strany ITSM,

• pomáhat zúčastněným stranám pro porozumění IT záleži

tostem.

2. Pomoci s dosažením požadavků na dodržování předpisů pro obchodní operace:

• strategicky řídit IT operace,

• pomoci s dosažením ISO20000, COBIT nebo jinou certifi

kací,

• dosahovat Critical Success Factors (CSFs),

• minimalizovat počet přerušení byznysu.

3. IT strategicky řídit provoz:

• měřit IT a výkonnost procesů,

• ovládat ITSM procesy,

• řídit IT takticky,

• maximalizovat produktivitu a výkon IT,

• prokazovat vytváření hodnot IT organizace [4].

Ve zkratce je důležité řídit konkrétní oblasti správným směrem [4].

2.3.1 Proč metriky nejsou SLAs

Dohoda mezi organizací, zákazníkem a IT je ujednání mezi manaže

rem úrovně služeb (Service level manažerem) a výsledky ze souboru SLAs. Tyto SLAs definují, jakou úroveň služeb je IT schopno poskyto

vat.

SLAs používané manažerem úrovně služeb definují Operational Level Agreements (OLAs), které zahrnují třetí strany s podpůrnými smlouvami (Underpinning Contracts (UC)), které umožňují doručo

vání služeb.

(40)

Critical Success Factors (CSFs) pro IT vycházejí z OLAs. CSFs jsou opatření, které musí být splněny pro uspokojení SLAs. Každé CSF pak může být použito k definování klíčových ukazatelů výkonnosti (KPI).

KPI se pak stává ukazatelem toho, zda je CSF naplněno.

Custotner ftequirement SLA —l> OLA/UC CSF KPI •••> Monthty Report Obrázek 2.2: Řetězec od požadavku k reportu [4]

Na obrázku lze vidět, že celý řetěz je řízen zákazníkovými poža

davky. KPIs můžou být měřeny a reportovány zpět zákazníkovi, aby viděl, jak efektivně se setkává IT organizace s dohodnutou úrovní služeb [4].

2.4 Kaskádové metriky a jejich hierarchie

Metriky a měření nemůžou být tvořeny ve vakuu, měly by se rov

nat vyšší úrovni požadavků a tak mít větší hodnotu, jako je tvoření hodnoty pro zákazníka. Existuje více cest, které přemýšlí, jak spojit aktuální měření s požadavky na vysoké úrovni. Vybrané cesty jsou následující:

• ITIL cesta od vize k měření,

• Balanced scorecard,

• IT komponenty ve scorecard hierarchii,

• SWOT analýza [14],

• Demingův cyklus.

2.4.1 ITIL cesta od vize k měření

Hierarchie metrik začínají vizí (vision) a misí (mission) organizace, z toho jsou derivovány záměry (goals) a cíle (objectives), CSFs, KPIs, metriky a měření, jak můžeme vidět na obrázku 2.3 [3].

Pokud používáme tento přístup, je potřeba s definováním úplně nahoře s vizí a misí a pak pokračovat dolů, kde skončíme u měření. To 24

(41)

Obrázek 2.3: Cesta od vize k měření [14]

zajišťuje, že všechno co měříme, může spojit s vizí a misí organizace, pomáhá to předcházet situacím, kdy různé věci jsou měřeny jenom proto, že můžou být. Když se podíváme na obrázek 2.3 a začneme na úplném dně u měření, pak budeme pokračovat do metrik, který ústí do KPIs, které demonstrují úspěchy proti CFSs, které pomáhají dosahovat cíle a záměry, atd. To znamená, že ze shora dolů si nejprve všechno definujeme a pak to zespoda nahoru měříme [3].

2.4.2 Balanced scorecard

Koncept Balanced ccorecard na obrázku představuje strategický mo

del podniku, vyvinutý profesory Harvardské univerzity R. Kaplanem a D. Nortonem, je v dnešní době považován za nejlepší přístup k trans

formaci podnikových vizí do konkrétních, měřitelných aktivit, které berou v úvahu všechny důležité faktory, ovlivňující dlouhodobé zvy

šování hodnoty.

Balanced scorecard je metodou, která vyvažuje rozporuplné cíle managementu, stavící proti sobě potřebu dlouhodobé konkurence-

(42)

schopnosti s krátkodobou finanční výkonností, k níž jsou manažeři nuceni. Tlak na krátkodobou výkonnost ale může vést k omezování výdajů na dlouhodobé investice (vývoj nových výrobků, zkvalitňování procesů, informační technologie, rozvoj lidských zdrojů), kam ovšem řadíme i rozvoj péče o zákazníka [8].

The Balanced Scorecard

Customer

1 Objectives • Targets

1 Measures * Irttfoflves

Financial

• Objectives * Targets

• Measures * Initiatives

Strategy

Learning & Growth

• Objectives * Targets

* Meo suras Initiatives

Business Processes

• Objectives • Targets

• Measures • Initiatives

Obrázek 2.4: Balanced scorecard [8]

Balanced scorecard se skládá ze 4 perspektiv, viz obrázek 2.4:

1. Customer (Zákaznická) - Tato perspektiva zohledňuje důleži

tost zkušeností zákazníků a jejich spokojenost.

2. Financial (Finanční) - Tato perspektiva se soustředí na tradiční finanční management, kterého by každá organizace měla být součástí.

3. Business Procesess (Perspektiva interních procesů) - Tato per

spektiva pomáhá porozumět vnitřnímu zdraví fungování orga

nizace a může tak být klíčovým indikátorem zlepšení firemních výkonů.

26

(43)

Tabulka 2.2: Příklady CFS s jednotlivými perspektivami balanced scorecard

Zákaznická Finanční Perspektiva interních procesů

Perspektiva učení se a růstu

1

Zákazníci jsou spokojeni s provozními službami.

IT významně přispívá k růstu podni

kání.

IT reaguje rychle na požadavky

zákazníků na změny.

End-to-end

služby IT jsou vysoce

dostupné.

Zákazníci jsou spokojeni se schopností

dodat nové a změněné služby.

IT významně přispívá k úspoře ná

kladů.

Plány vzdě

lávání IT zaměstnanců

jsou účinné.

Zákaznické in

cidenty jsou ře

šeny rychle a efektivně.

4. Learning & Growth (Perspektiva učení se a růstu) - Tato per

spektiva je velmi spjata s neustálým zdokonalováním. To zahr

nuje trénink a rozvoj lidí, znalostí z řízení a dalších přístupů, které můžou zajistit, že se organizace bude podle potřeby vyvíjet [3].

V tabulce 2.2 si můžeme vidět příklady CSFs spojené s jednotlivými perspektivami balanced scorecard [3]:

Definování metrik pro všechny čtyři oblasti balanced scorecard může pomoci zajistit že budou dobře vybalancované, bez přílišného soustředění na jednu oblast. Na uživatelské úrovni bude třeba defino

vat CSFs jako:

• Spokojenost zákazníků - Jedna s populárních měření spoko

jenosti je Net Promotér Score (NPS), takzvaná míra loajality zákazníků, či jejich spokojenosti. NPS se vypočítá tak, že se budeme ptát, např. otázkou „Jak je pravděpodobné, že byste doporučili naše služby kamarádovi nebo spolupracovníkovi? "

Lidé, kteří budou hodnotit 9, nebo 10 jsou tzv. „promoters",

(44)

můžeme říci spokojení, lidé, kteří budou hodnotit 6 a méně jsou hodnoceni jako „detractors", můžeme říci kritici. Výsledek se vypočítá tak, že odečteme hodnocení kritiků od promotorů.

• Moment pravdy - Tato metoda měří jaké očekávání mají zákaz

níci v určitých významných bodech v organizaci. Identifikování klíčových momentů pravdy, které mají na zákazníka největší dopad na zákazníka a měření toho, jak se zákazník cítí, nám může poskytnout dobrý přehled o tom, co je pro něj důležité [3].

Tyto zákaznické metriky dávají velmi rozdílný pohled na ITSM metriky vnitřních procesů a v kombinaci s dalšími balanced scorecard můžou zajistit úspěch v organizaci. Balanced scorecard může být použita na různích úrovních organizace. Nejlépe to bude fungovat pokud začneme na úplném vrcholu organizace a pak se po kaskádách budeme posunovat níže do organizační struktury, abychom si přitom mohli vytvářet potřebné informace z každé úrovně.

Více informací o balanced scorecard můžete najít např. v knize ITIL Continual Service Improvement na straně 107.

2.4.3 IT komponenty v scorecard hierarchii

Měření IT komponent může být použito pro výpočet výsledků služby, které může být následně použito jako vstup pro scorecard nebo ba

lanced scorecard. Příklad takového použití můžeme vidět v tabulce 2.3.

28

(45)

Tabulka 2.3: Příklad IT komponenty v scorecard hierarchii

Komponenta Dostupnost sálového pc 99.96 %

WAN 98%

L A N 97.5 %

Desktop 96%

Služba Dostupnost 1 služby 91.96 %

Dostupnost 2 služby 98%

Scorecard Zákazník: Počet nedostupností služby 1

V této tabulce je vidět dostupnost 91.69 % pro Službu 1. Tento výsledek je sestaven ze všech čtyřech komponent, výpočet síťové do

stupnosti je 99.96 % x 99 % x 97.5 % x 96 %. Dostupnost Služby 2 je 98

%, protože jedině W A N síť nebyla dostupná během periody měřený, všechny ostatní komponenty v daný moment neselhaly.

Tento druh frameworku může být použit k automatizaci některých aspektů měření a reportingu, k tomu mu poslouží existující nástroje.

Velkou pozornost je potřeba věnovat tomu, aby výsledky skutečně odpovídaly zkušenostem uživatelů. Dobrá IT metrika by se měla sou

středit na „customer value creation", tedy na tvoření hodnot zákaz

níků, tzn. na jejich produktivitu, množství prodaných výrobku nebo na další opatření zaměřená na druh podnikání. Důležité taky bude měřit více kvalitativní aspekty zkušenosti zákazníků např. pomocí NPS nebo momentu pravdy, které jsou zmíněny v oddílu 2.4.2.

2.4.4 SWOT analýza

SWOT je zkratka pro Strengths (silné stránky), Weaknesses (slabé stránky), Opportunities (příležitosti), Threats (hrozby). Tato technika zahrnuje přehled a analýzu čtyřech specifických oblastí z organizace [14]:

• interní silné stránky,

• interní slabé stránky,

• vnější příležitosti,

(46)

• vnější hrozby.

Jakmile budou tyto oblasti analyzovány měly by následovat další akce:

• rozvíjet, využívat silné stránky organizace,

• redukovat, minimalizovat, nebo smazat slabé stránky,

• maximální využití příležitostí,

• řídit, zmírnit a eliminovat hrozby.

SWOT analýza může být provedena velmi rychle. Je vhodná spíše pro konkrétní oblasti, než pro celou organizaci. SWOT se často pou

žívá jako vstup pro tvorbu možných strategií. Pro tvorbu následující strategie je vhodné si položit následující otázky [14]:

• Jak můžeme použít každou ze silných stránek?

• Jak můžeme zastavit každou slabou stránku?

• Jak můžeme využít každou příležitost?

• Jak se můžeme bránit proti každé hrozbě?

2.4.5 Demingův cyklus

W. Edwards Deming je nejvíce známý pro jeho management filozofii, vedoucí k zvýšení kvality, produktivity a konkurenční pozice. Formu

loval 14 bodů pozornosti pro manažery. Některé z nich jsou spíše pro management služeb. Pro zlepšování kvality navrhl Demingův cyklus nebo Cyklus. Tento cyklus je aplikovatelný v rámci CSI a skládá se ze čtyř fází:

1 Pian 2 Do 3 Check 4 Act 30

(47)

Nejčastěji je PDCA cyklus, jak se někdy také nazývá, vyznačen na lineární křivce, která roste. To je z toho důvodu, že tento graf ukazuje zároveň i úroveň dospělosti organizace, jak můžeme vidět na obrázku 2.5.

Continuous quality control and consolidation

Time Scale

Obrázek 2.5: Demingův cyklus [14]

Demingův cyklus je kritický pro dva body neustálého zlepšování služeb a to na:

1. implementaci CSIs,

2. aplikaci CSIs do procesu služeb a managementu služeb.

2.5 Reportování

Po získání hodnot z měření, je očekávána další spousta práce. Nasbí

raná data bude potřeba dát dohromady a analyzovat, kvůli získání určité hodnoty z těchto dat. Tyto data můžou mít různé formy a je potřeba získat (vyfiltrovat) taková data, které nám pomůžou k neustá

lému zlepšování. Proto je důležité se nejprve ptát, proč měříme, viz

(48)

kapitola 2.

Rozhodnutí, jak prezentovat dané výsledky, zahrnuje identifikování všech zainteresovaných stran a ujištění se, že rozumíme všem potře

bám každé strany Prezentace měřitelnosti a metrik je běžně udělána pomocí reportů nebo dashboardů.

• Report

Reporty poskytují shrnutí a analýzu metrik, jak je popsáno v ka

pitole 2. Využijeme tedy přístupy „ověřit, řídit, zdůvodnit, za

kročit".

Typicky bude report prezentovat sbírané data a porovnávat s da

nými KPIs. Dále bude ukazovat dané trendy a výjimky a konečně bude zahrnovat popis toho, jaké akce se mají vykonat po dané analýze.

• Dashboard

Dashboard poskytuje rychlý vizuální souhrn metrik. Můžou být tvořeny skrze ITSM nástroje a jsou typicky aktualizovány velmi často, tak aby byl vždy viděn současný stav dat. Dashboard může ukazovat stav dané technologie (dostupnost aplikací a in

frastruktury), procesů (počty požadavků service desku) nebo end-to-end služby (počet úspěšných a nezdařených transakcí za poslední hodinu). Z toho vyplývá, že reporty jsou na střední (týdny), až dlouhou dobu (měsíce) a dashboard slouží k vizuali- zaci krátkodobých dat (hodiny, dny).

Dashboardy jsou často používané k rychlé interakci (při překro

čení prahových hodnot), ale může sloužit taky k ověření, jestli je všechno v pořádku. Dashboard by měl být vytvořen pro speci

fické publikum. Informace potřebná pro manažera service desku je velmi rozdílná od potřeb manažera obchodního oddělení [3].

2.5.1 Zvýšení hodnot reportů

Mnoho poskytovatelů IT služeb vytváří reporty s nejasným účelem a neidentifikovanými zainteresovanými stranami. Často tak produkují reporty s velmi malou hodnotou. Tyto organizace by často mohli ušet

řit čas a úsilí tím, že jednoduše přestanou produkovat tyto reporty.

32

(49)

Některé IT oddělení produkují širokou škálu dlouhých reportů plných dat, které nikdy nečetly. Tyto reporty jsou často založeny na požadav

cích vytvořené managementem mnoho let zpět, ale manažeři, kteří tyto reporty používali se někam buď přesunuli, anebo reporty přestali používat. V dalších odděleních jsou reporty, které zobrazují stovky informací, ale používají se pouze tři z nich.

Aby se zajistilo vytvoření reportů s maximální možnou hodnotou, je třeba se ptát:

• Pro koho jsou reporty určeny?

• Co je cílem těchto reportů?

• Co se děje na základě reportů a kdo to dělá?

• Jaká data jsou potřebná pro vytvoření reportu?

Je důležité mít na paměti, že obrázek je často lépe pochopitelný, než slova. Proto je nutné používat grafy a diagramy namísto velkého počtu textu a čísel.

(50)

(51)

3 Nej lepší praktiky vybraných procesů

Nejlepší praktiky neboli best practices je pojem, který ve svém názvu skrývá osvědčené postupy, procesy nebo osvědčené metody řízení, díky kterým se dosáhlo dobrých výsledků více organizacích. Tyto postupy se pak staly doporučením pro ostatní. Za soubor nejlepších praktik se pokládá námi vybraný ITIL. Z výčtu nej významnějších procesů, byly pro praktickou část vybrány první 3 procesy, ostatní procesy se hodí spíše k reportování např. asset managementu a k jiným účelům.

• Event Management,

• Incident Management,

• Problém Management,

• Request Fulfillment,

• Change Management,

• Information Management,

• Configuration Management,

• Release Management,

• Capacity Management,

• Availabilty Management,

• Service Level Management.

3.1 Event Management

Každou sekundu nastávají v technické infrastruktuře desítky, až stovky eventů (událostí). Úkolem tohoto procesu je eventy detekovat a roztří

dit je (typicky) do následujících 3 kategorií:

(52)

3- NEJLEPŠÍ PRAKTIKY VYBRANÝCH PROCESŮ

1. Informational (Informační) - U této kategorie je třeba pouze zaznamenat eventy pro účely dalších analýz, například sledo

vání kapacitních trendů, do této kategorie může spadat Request Fulfilment.

2. Warning (Varování) - Varování signalizují dosažení konkrétní přednastavené prahové hodnoty (zatížení CPU, RAM, transakční odezva, počet současně přihlášených uživatelů atd.), což umož

ňuje předcházet vzniku incidentů.

3. Exception (Výjimka) - Kategorie signalizující nestandardní stav, který často vyžaduje bezprostřední akci. Příklady: pokus o při

hlášení s neplatným heslem, e-mail nedoručen, „pád" serveru, chybová hláška z aplikace XY apod. Do této kategorie spadá Incident, Problém a Change Management.

Proces současně musí být schopen filtrovat opakované eventy a eventy zcela nepodstatné. U eventů kategorie warning a exception musí zajistit jejich interpretaci do člověku srozumitelné formy a inici

ovat odpovídající akci.

Vyspělost systémů řízení služeb IT je velmi často měřena tím, jaké

% incidentů z celkového počtu je identifikované prostřednictvím event managementu.

Nej důležitější přínosy procesu:

• zkrácení doby trvání výpadků služeb IT díky jejich včasné iden

tifikaci, ideálně ještě dříve, než výpadek pocítí uživatel a díky rychlé iniciaci příslušné akce,

• předcházení výpadkům služeb IT,

• zvýšení spokojenosti zákazníků a uživatelů.

Důsledky neexistence procesu:

• používání uživatelů služeb IT jako nástroje pro identifikaci výpadků služeb IT,

• vysoká reaktivita, téměř nulová proaktivita při řešení výpadků služeb IT = IT specialisté pouze hasí požáry, které se již naplno rozhořely [16].

36