Práce s informacemi a tím i IT služby se již dávno staly integrální součástí fungování téměř každé organizace libovolné velikosti. Jako každá „subdodávka“ hlavního předmětu podnikání, i tato musí splňovat nějaká kvalitativní kritéria. Jak je ale stanovit a na co by se měl odběratel služeb soustředit?

Kvalitativní normativ pro IT služby

Když se řekne kvalita, většině čtenářů se vybaví ISO a jím vydané normativy. V oblasti řízení IT služeb tento ekvivalent dlouho neplatil. Velké části IT obce se vybavily v této souvislosti spíše pojmy ITIL, COBIT a jiné. Opravdovým kvalitativním mezinárodním standardem, dle kterého lze certifikovat, se ale v této oblasti stal až ISO/IEC 20000. Tato norma byla vydána v prosinci loňského roku, a proto ještě není ani mezi odbornou veřejností příliš známá. Vychází z mnohem známějšího procesního rámce pro poskytování IT služeb ITIL (Information Technology Infrastructure Library). Pro představu o podobnosti ISO/IEC 20000 a ITIL je v tabulce uveden seznam základních procesů obou publikací.

ISO/IEC 20000	ITIL	Český ekvivalent ISO/IEC 20000
Configuration management	Configuration management	Management konfigurace
Incident management	Incident management	Management incidentů
Problem management	Problem management	Management problémů
Change management	Change management	Management změn
Release management	Release management	Management nasazení
Service level management	Service level management	Management úrovně služeb
Capacity management	Capacity management	Management kapacit
Service continuity and availability management	Availability management	Management kontinuity a dostupnosti služeb
	IT service continuity management
Budgeting and accounting for IT services	Financial management for IT services	Rozpočtování a účetnictví pro IT služby
Information security management	Security management	Management bezpečnosti informací
Business relationship management	Business relationship management	Management vztahů s odběrateli
Supplier management	Supplier relationship management	Řízení dodavatelů
Service reporting		Reportování služeb

Na první pohled je zřejmá téměř úplná shoda co do rozsahu. Tato shoda panuje i v oblasti obsahu požadavků na jednotlivé procesy. Lze tedy říci, že pokud je organizace certifikována dle ISO/IEC 20000, jsou její procesy v souladu s doporučeními ITIL. Opačně tvrzení neplatí, protože dle ITIL nelze certifikovat organizaci, ale pouze jednotlivce.

Procesy na rozhraní mezi poskytovatelem služeb a zákazníkem

Všechny výše zmíněné procesy jsou sice důležité pro kvalitní poskytování IT služeb, ale to neznamená, že se všemi musí zabývat přímo odběratel těchto služeb. Některé z procesů zůstávají pro zákazníka zdánlivě skryty (např. management problémů, management kapacit). Ve skutečnosti se nefungování takových procesů projeví především v tom, že náklady na poskytování IT služeb jsou vyšší, než by být musely, nebo se poskytuje něco trochu jiného, než organizace nezbytně potřebuje. Dále se ale budeme zabývat především procesy, kterých se přímo účastní odběratel IT služeb a ve kterých může rozsah a kvalitu dodávaných služeb aktivně ovlivňovat.

Management úrovně služeb je jedním z nejdůležitějších procesů, ve kterém zákazník specifikuje své požadavky a současně kontroluje úroveň a parametry poskytovaných IT služeb. Prvním krokem v tomto procesu je vytvoření smlouvy/dohody o úrovni služeb tzv. SLA (service level agreement) a katalogu služeb, ve kterém oba partneři (poskytovatel a zákazník musí být partnery, jinak proces s vysokou pravděpodobností příliš fungovat nebude) specifikují parametry jednotlivých elementárních IT služeb. Příkladem takových služeb jsou například:

• instalace PC,
• přemístění hardwaru,
• poskytování on-line přístupu k aplikaci,
• řešení požadavku v rámci služby s danou prioritou apod.

Jako příklad nejobvyklejších parametrů může sloužit:

• maximální doba výpadku služby,
• dostupnost služby v procentech za sledované období,
• odezva na požadavek nebo odezva aplikace na specifikovanou akci,
• maximální počet výpadků za sledované období apod.

Bez takovéto „smlouvy“ je jakékoliv hodnocení úrovně poskytovaných služeb v podstatě nemožné, a pokud vám externí dodavatel nenabídne společné vytvoření takové smlouvy, nemá smysl s ním dále ztrácet čas – služby na profesionální úrovni od něj nečekejte. V případě interního poskytovatele služeb se taková dohoda může zdát zbytečná – stejně obvykle nelze uplatňovat sankce ani bonusy. Ve skutečnosti se stále jedná o vaše peníze. Činnost vaší organizace nepotřebuje totiž například dostupnost IT služeb na úrovni 99,9 %, ale bohatě vyhovuje třeba jen 95 %. A ta 4,5% navíc stojí nemalé náklady, které vždy nakonec zaplatí zákazník. Tento proces je tedy především o nastavení správné úrovně IT služeb dle potřeb odběratele služeb a o sledování plnění této úrovně. Povinnost sledovat a vykazovat úroveň poskytovaných služeb obvykle bývá na straně dodavatele. Nicméně pro účely kontroly (a tím zvýšení vzájemné důvěry) je nejvhodnější sdílet softwarový nástroj pro podporu řízení pracoviště service desk (popis viz dále) a evidenci incidentů. Zde zákazník musí trvat na nastavení takových reportů, ze kterých je dosažená úroveň služeb jasná a nezpochybnitelná. Pokud toto není zajištěno, vystavujete se nebezpečí mnohahodinového dohadování ve stylu „jak to tenkrát vlastně bylo“.
Kromě těchto přesně specifikovaných a relativně snadno měřitelných parametrů se doporučuje sledovat i spokojenost uživatelů s poskytovanými službami. Je to sice poměrně obtížné a výsledky bývají často zpochybňovány stejně jako například průzkumy veřejného mínění, ale na druhou stranu je to jediná možnost, jak získat zpětnou vazbu o tom, zda zástupci zákazníka a poskytovatele služeb stanovili správně úroveň služeb a zda se soustředí opravdu na to, co je podstatné pro koncové uživatele, tj. faktické odběratele těchto IT služeb.

Management incidentů je nejběžnějším procesem, se kterým přichází zákazník do styku téměř každý den. Jedná se také o proces, který bývá ve většině organizací dobře zvládnutý. Jeho cílem je co nejrychlejší obnova přerušené nebo omezené dodávky služeb. I když říkáme „co nejrychlejší“, stále musíme mít na zřeteli, že jsme své požadavky na rychlost specifikovali v SLA. Koncový uživatel u tohoto procesu nejvíce ocení, pokud má jedno místo na nahlášení incidentu (telefonní číslo, e-mail, specializovanou aplikaci) a je o průběhu řešení uspokojivě informován. Tyto služby by pro něj mělo zajišťovat pracoviště tzv. service desku. Toto by mělo být jediné kontaktní místo pro všechny uživatele. Jak jednoduše se to řekne a jak složitě implementuje. Každý máme zkušenost s tím, že se raději obrátíme na známého „technika“ nebo jiného specialistu s nadějí, že urychlíme řešení našeho požadavku. Někdy se to může podařit, ale důsledky jsou obvykle následující:

• Náš známý „ajtík“ nezaeviduje tento požadavek (nemá to v popisu práce, a navíc je pro tuto činnost jeho čas zbytečně drahý) a to nám zkresluje statistiky poskytování služeb.
• Řešení požadavku se nezaeviduje a znemožní se tak jeho přenesení do tzv. znalostní databáze, která pomáhá poskytovateli služeb rychleji řešit opakované incidenty a požadavky.
• Doba reakce na požadavek se neměří, a tak nelze reklamovat nedodržení SLA.
• Poskytovatel služeb nemůže rovnoměrně rozdělovat práci a to má dopad na jeho kapacity a následně i na cenu/náklady jeho služeb.
• Požadavek nepatří do kompetence osloveného a on jej nepředá správnému řešiteli nebo jej předá na service desk a řešení požadavku se zbytečně prodlouží.

Z toho vyplývá, že má smysl „nutit“ všechny uživatele, aby respektovali definovaný průběh tohoto procesu, například dle obrázku 1.


Obr. 1: Schéma procesu management incidentů

Vřele doporučuji soustředit všechny aktivity tohoto procesu s výjimkou „řešení incidentu“ na service desk. Pokud to neučiníte, velmi si zkomplikujete sledování plnění SLA a nevyhnete se „ztraceným“ incidentům, za které nikdo nenese odpovědnost.

Management změn nepotřebujeme sice tak často, jako řešení incidentů, ale neexistence nebo nefunkčnost tohoto procesu způsobí ztrátu možnosti dynamického přizpůsobování IT služeb potřebám zákazníka a jejich rozvoje. A tento požadavek je poměrně klíčový, pokud vůbec chceme svůj business rozvíjet. V procesu managementu změn musí zákazník společně s poskytovatelem služeb zajistit, aby byly prováděny jen takové změny, které mají smysl pro zákazníka a přinášejí mu nějaké výhody – vyšší výnosy, úspory nákladů, eliminaci rizik. Pokud vám dodavatel není schopen zdůvodnit požadovanou změnu výše uvedeným a „mlží“ výroky jako „nevyhnutelný trend v IT“ nebo „finančně to sice vyčíslit nelze, ale kvalita bude podstatně vyšší“ nenechte se tím uspokojit. IT specialisté mají často tendenci implementovat každou novinku, která se objeví na trhu, aniž by příliš domýšleli, zda ji zákazník potřebuje, nebo nikoliv. V procesu rozhodování o realizaci změn v IT by měl mít proto hlavní slovo zákazník. Nenechte se v tomto procesu „utlouci“ odbornými argumenty z IT oblasti. Společně s poskytovatelem služeb musíte najít ve změně kvantifikovatelný přínos pro vaši organizaci. Pokud se to nepodaří, změna by měla být odmítnuta. A ještě jedno doporučení k řízení změn; při první implementaci pamatujte, že v jednoduchosti je síla a nesnažte se do procesu zahrnout všechny výjimečné situace, které nastávají jednou za pětiletku. Příklad takového jednoduchého procesu znázorňuje na obrázku 2.


Obr. 2: Schéma procesu management změn (RFC – Request For Change) zde znamená požadavek na změnu

Doposud jsme se příliš nezabývali tím, kdo vlastně IT služby poskytuje. Předchozí procesy byly totiž nezávislé na skutečnosti, zda je poskytovatelem IT služeb interní útvar, externí dodavatel nebo oba současně. Každá z těchto variant však má své výhody a nevýhody a je třeba využít takového uspořádání, které nejvíce vyhovuje cílům vaší organizace. Nebudu zde podrobně rozebírat disciplínu nazývanou „sourcing strategy“, to by vydalo na samostatný článek, ale v následujících odstavcích se zaměřím na skutečnosti, které je vhodné brát v úvahu při daném způsobu zajišťování IT služeb.

Poskytování IT služeb interně

Nejčastější chybou při tomto způsobu zajišťování IT služeb je spoléhání se na sílu organizační struktury (ředitel organizace může IT útvaru přece nařídit cokoliv) a efektivitu zajištěnou rozpočtem IT útvaru. To, že rozpočet je dodržen, vůbec neznamená, že IT služby jsou poskytovány efektivně. Proces Managementu úrovně služeb tady tedy má své opodstatnění. Příležitostí, která by neměla být v tomto uspořádání promarněna, je možnost přímo podporovat IT službami hlavní činnost organizace. IT útvar má nejlepší podmínky pro získání dobré znalosti potřeb organizace.

Výhody:

• nejužší sepětí s businessem a tím možnost rychlé reakce na požadavky zákazníka
• nižší náklady na interní pracovní sílu (pozor – nemusí znamenat celkově nižší náklady na služby)
• není riziko závislosti na externím dodavateli
• bezpečnost informací je pokryta jednotnou bezpečnostní politikou
• požadavky na služby nemusí být tak exaktně popsány
• změna v parametrech služeb nemusí znamenat změnu ceny

Nevýhody:

• obvykle chybí know-how z více projektů a aplikace nejlepších praktik
• nižší dynamika a reakce na změny v požadavcích businessu
• není obvykle možné uplatnit „economy of scale“
• nestandardizované rozhraní mezi poskytovatelem IT služeb a uživatelem
• obtížná motivace specialistů

Outsourcing části IT služeb

Při tomto způsobu zajištění IT služeb spočívá hlavní riziko v nesprávně provedené strategii outsourcingu a následně rozhodnutí o tom, které služby mají být outsourcovány. Jinými slovy, organizace obvykle nestanoví přesně cíle pro outsourcing, a pak je nemile překvapena například tím, že outsourcováním vývojových kapacit na software se prodloužila doba řešení programových změn (tím nechci tvrdit, že to musí vždy nastat, ale obvykle nějakou dobu trvá, než se externí firma seznámí s prostředím organizace a převzatým programovým vybavením, než se standardizuje proces managementu změn apod.). Základem je tedy jasně definovaný cíl typu – snížení nákladů, získání know-how, odstranění rizika závislosti na vysoce specializovaných a tím drahých profesionálech, které se nedaří dostatečně motivovat atd.

Výhody:

• možnost řešit konkrétní cíle organizace přesným zacílením outsourcingu
• omezení rizika závislosti organizace na dodavateli služeb
• možnost „testování“ poskytovatele IT služeb na službách méně klíčových pro chod organizace a zavádění outsourcingu postupně

Nevýhody:

• vzniká rozhraní mezi poskytovateli služeb a mohou nastávat kompetenční spory
• riziko závislosti na poskytovateli IT služeb v outsourcované oblasti
• složitější přizpůsobování potřebám businessu (komunikační šum)
• strategie IT může být řešena několika subjekty a nemusí být tak konzistentní

Komplexní outsourcing

Při tomto způsobu zajištění IT služeb existují největší příležitosti, ale také největší riziko. Riziko spočívá především v tom, že zákazník je plně závislý na poskytovateli služeb. Toto lze částečně eliminovat smluvně, kdy je součástí smlouvy podrobně zpracovaný plán zpětného převzetí IT služeb nebo předání na třetí stranu. Vždy je to ale proces velmi „bolestivý“.
Příležitostí je zde možnost standardizovat vnitřní procesy a zvýšit úroveň IT služeb převzetím know-how od profesionálního poskytovatele. Komplexní outsourcing umožňuje také využít poskytovatele IT služeb pro tvorbu IT strategie, která nejlépe podporuje hlavní předmět činnosti zákazníka. Tento dodavatel má obvykle hluboké znalosti o moderních trendech v IT oblasti a je schopen doporučit nejvhodnější cestu jak v oblasti technologické, tak procesní. Tento způsob rovněž poskytuje největší dynamiku v objemu poskytovaných IT služeb – snížení či zvýšení rozsahu je snazší než v případě propouštění nebo najímání interních zaměstnanců.

Výhody:

• není žádné rozhraní mezi poskytovateli IT služeb a tím ani nejasná zodpovědnost a komunikační šum mezi poskytovateli
• u profesionálního poskytovatele je reálné dosažení vysoké kvality služeb za nižší cenu než jsou interní náklady (některé zdroje jsou sdíleny více zákazníky)
• možnost využití know-how poskytovatele pro tvorbu té strategie IT, která nejlépe podporuje business
• vysoká dynamika v kvalitě i rozsahu služeb

Nevýhody:

• riziko plné závislosti na poskytovateli IT služeb
• může vzniknout „komunikační šum“ mezi poskytovatelem IT služeb a zákazníkem v oblasti strategických cílů
• konflikt zájmů poskytovatele IT služeb a zákazníka v oblasti tvorby ceny
• k informacím mohou mít přístup i lidé mimo organizaci

Závěr

Cílem článku nebylo rozebrat poměrně rozsáhlou problematiku kvality v oblasti IT služeb, ale spíše upozornit na to, že i v této oblasti existují konečně standardy. S jejich využitím lze pomoci fungování celé organizace, ať již zefektivněním a tím úsporou nákladů, nebo lepší podporou hlavního předmětu činnosti organizace a tím zvýšení výnosů.

Autor článku působí jako konzultant pro oblast řízení IT služeb ve společnosti AutoCont CZ.