Potřebujeme vůbec útvar informatiky? A když ano, jak početný mít tento útvar? Jaké efekty nám přináší? Jaké je nákladově optimální hardwarové vybavení? Kolik ročně vynakládat na informatiku? To jsou otázky, které si pravděpodobně čas od času položí každý ředitel firmy. Tento článek je zaměřen tak, aby po jeho přečtení bylo rámcově zřejmé, jak ve firmě postupovat k získání odpovědí na tyto otázky.

Metriky
V následujícím textu bude často používán pojem metrika. Metriky jsou součástí procesu řízení jako nástroj zpětné vazby a hodnocení efektivnosti při dosahování podnikových cílů, výkonnosti procesů, efektivnosti podnikových zdrojů a jako nástroj hodnocení realizovaných rozhodnutí.

Metriky užití IS/IT charakterizují efektivitu informatické podpory vykonavatelům hlavních procesů v podniku. Těmto metrikám je vlastní, že jsou umístěny na interface mezi poskytovatelem informatických služeb - útvarem informatiky a příjemcem - koncovým uživatelem.

Metriky provozu IS/IT jsou zaměřeny na efektivitu a výkonnost provozu samotného IS/IT. Musí být odvozeny od metrik interního užití IS/ICT. Efektivita provozu IS/IT přímo predeterminuje úroveň poskytovaných informatických služeb. Smyslem těchto metrik je podpora interního managementu provozu IS/IT pro realizaci definované úrovně poskytovaných služeb za minimálních nákladů.

Pro účely tohoto příspěvku si dále vymezíme pracovní definici pojmu metrika, měkká metrika, tvrdá metrika a portfolio metrik [UCEN_01].

Metrika je přesně vymezený finanční či nefinanční ukazatel nebo hodnotící kritérium, které je používáno k hodnocení úrovně efektivnosti konkrétní oblasti řízení podnikového výkonu a jeho efektivní podpory prostředky IS/ICT. Skupinu metrik sdružených za určitým cílem (tzn. vztahujících se ke konkrétní oblasti, procesu či projektu) nazýváme "portfolio metrik".

Tvrdá metrika je objektivně měřitelný ukazatel, který sleduje vývoj podnikových cílů, podnikových aktivit, či je zaměřen přímo na zákazníka. Jejich základní charakteristika: jsou snadno měřitelné, jsou k dispozici bez dodatečných nákladů, dají se většinou převést na finanční vyjádření.

Správně vybrané tvrdé metriky by měly náležet k oblastem, které přímo ovlivňují základní konkurenční faktory, resp. jsou formulovány v návaznosti na jednotlivé perspektivy metodiky Balanced Scorecerd, pokud je implementována. Struktura metrik musí odpovídat stádiu rozvoje firmy. Stádia "stabilizovaného řádu" a "rozmachu" jsou příznivá pro vyváženou aplikaci tvrdých metrik a měkkých metrik. Stádiím "vnitřního sociálního neklidu", "změn" a "rodícího se nového řádu" vyhovuje více uplatnění metrik s podstatně vyšším podílem měkkých metrik.

Tvrdými metrikami jsou mimo ukazatelů také indikátory. Indikátor je chápán jako ukazatel, u něhož jsou stanoveny žádoucí meze, nebo horní, resp. spodní limit. Pokud reálná hodnota vykáže odchylku od mezí, resp. od limitu, jedná se o odchylku od žádoucího stavu. Pokud metrika není indikátorem, musí mít definován žádoucí stav, se kterým je potom skutečná hodnota ukazatele srovnána a podle níže popsaných způsobů hodnocena.

Měkká metrika slouží k měření a hodnocení úrovně informatické podpory jednotlivých procesů či funkčních oblastí podniku auditním způsobem. Měkké metriky jsou koncipovány v souladu s účelem použití, kupř. tak, aby byly využitelné k hodnocení míry: plnění interních cílů v dané oblasti, dosažení potenciálních efektů z inovace IS/ICT .

Skupinu metrik sdružených za určitým cílem (tzn. vztahujících se ke konkrétní oblasti, procesu či projektu), nazýváme "portfolio metrik".

Potenciál zlepšení hlavních procesů
V každé firmě jsou realizátorem podnikového výkonu hlavní - hodnototvorné procesy. Pro správné stanovení struktury podnikových cílů dnes již řada firem používá přístupu založeného na metodě Balanced Scorecard (blíže viz [KAP_96]). Cíle podniku jsou v souladu s uvedenou metodou stanovovány ve čtyřech perspektivách: finanční, zákaznické, procesní a učení a růstu.

Podkladem pro stanovení těchto cílů je analýza trhu, analýza změn v relevantním okolí, SWOT analýza a analýza minulých výsledků firmy. V návaznosti na finanční cíle jsou stanoveny cíle v zákaznické perspektivě. Typickým výstupem je potom formulace cílů, jako jsou např.: cíle v "hunting" (prodej nově získaným zákazníkům v chtěné struktuře) a cíle ve "farming" (výnosy získané od stávajících zákazníků v chtěné struktuře).

Tento pohled je následně rozpracováván ve struktuře produktů a služeb, podle kategorií zákazníků, podle teritorií, podle jednotlivých tržních segmentů, podle procesů, podle organizačních jednotek (Business Units) apod. Hlavní procesy a jejich zdroje je tedy nutno nastavit tak, aby bylo dosaženo cílů v perspektivě zákaznické, a tím i v perspektivě finanční. Doporučuji uplatnit následující postup:

1. Stanovit tzv. absolutní potenciál zlepšení (APZ) u jednotlivých hlavních procesů. APZ se stanoví formulací toho nejlepšího možného způsobu, jak daný proces realizovat, a to zejména u klíčových aktivit procesu. Klíčové jsou ty aktivity, které mají charakter kritického faktoru úspěchu, úzkého místa, resp. slabiny daného procesu v dané firmě. Každý proces takové aktivity má a pouze malý podíl počtu aktivit procesu (typicky 3 až 8 %) rozhoduje z 80 až 90 % o výkonnosti daného procesu jako celku. APZ klíčových aktivit se stanovuje na základě: Best Practices (nejlepší způsob, jak realizovat tyto činnosti v současnosti, lépe však v blízké budoucnosti) nebo Benchmarking (porovnání kupř. se špičkami, resp. se standardem v daném odvětví). Za formulaci APZ je odpovědný vlastník procesu ve firmě, kterýí ale často neovládá Best Practices, ani není schopen dodat potřebné údaje o parametrech výkonnosti procesu u špičkových firem v odvětví, resp. o standardech v daném odvětví. Proto je velmi žádoucí externí konzultační spolupráce. Dalším důležitým předpokladem je, aby APZ byl stanoven bez ohledu na realitu daného podniku.

2. APZ není reálně dosažitelný žádným podnikem. Je to však meta, ke které se ti úspěšní přibližují rychleji než ostatní. Zásadním způsobem podmiňuje architekturu procesů. APZ je nedosažitelný vzhledem k reálně existujícím limitům (tržní pozice, úroveň řízení vztahů se zákazníky, úroveň spolupráce s partnery, úroveň firemního intelektuálního kapitálu apod.). Analýzou těchto limitů je redukován APZ na reálný potenciál zlepšení (RPZ). Podíváme-li se na obr. 1, kružnice reprezentuje APZ, červeně vyšrafovaná plocha RPZ a modře vyšrafovaná plocha zobrazuje současný stav. Ze současného stavu do RPZ je posun realizován na taktické úrovni ve střednědobém a krátkodobém horizontu formou projektů a dalších inovačních aktivit. Prostor mezi RPZ a APZ je prostor pro dlouhodobou strategii. Z tohoto hlediska není na procesní úrovni firemní strategie nic jiného, než hledání cesty vedoucí k odstraňování stávajících limitů. Tato strategie musí být realizována holisticky a harmonicky, aby nedocházelo ke zbytečným nákladům. Je nutno rozeznat skutečné limity, které lze překonat nebo zmírnit s dobrou návratností a jejichž překonání vytváří přínosy, od limitů nyní nepřekonatelných. Zkušenosti ukazují, že v mnoha případech jsou limitem pravidla, která jsme sami vytvořili.

Obr. 1: Potenciál zlepšení

Uplatněním měkkých metrik provedeme snímek současného stavu, tj. kvantitativní vyjádření současného stavu ve vztahu k RPZ. Zlepšení, vyjádřená formou měkkých metrik, musí vyústit do tvrdých metrik, tedy do kvantifikace předpokládaných přínosů. Blíže k postupu snímkování viz [UCEN_01].

3. Stanovení strategie dosažení RPZ. Principielně existují následující možnosti: zlepšení je dosaženo optimalizací hlavního procesu samotného, zlepšení je dosaženo optimalizací zdrojů, zlepšení je dosaženo zvýšením účinnosti podpory ze strany podpůrných procesů, v našem případě informatické podpory. V souladu se zvolenou strategií jsou rámcově formulovány projekty (zadání projektu) a ostatní inovační aktivity krátkodobého a střednědobého charakteru, včetně odhadu nákladů. Bilancí očekávaných přínosů a nákladů je proveden výpočet odhadu návratnosti dosažení RPZ. Je-li návratnost v soulady s cíly finanční perspektivy, je záměr realizován. Jestliže ne, je nutno provést korekce vedoucí k vyvážení strategie dosažení RPZ a cílů finanční perspektivy.

4. Řekněme, že zvolená strategie dosažení RPZ je založena na požadavku vyšší informatické podpory definovaných klíčových aktivit procesu (nebo i více procesů). To je alternativa, kterou rozpracujeme v dalších částech této úvahy.

Dimenzování podpůrných procesů na příkladu IT
Podpůrné procesy jsou ty, které nemají externí zákazníky a které vytvářejí přidanou hodnotu zprostředkovaně prostřednictvím služeb, které poskytují hlavním - hodnototvorným procesům. Měly by být dimenzovány v souladu s potřebami hlavních procesů a jejich náklady by se měly promítat do ceny interních služeb. Platí, že podpůrné procesy jsou z kvalitativního a současně nákladového hlediska zdravě postaveny tehdy, jestliže úspěšně odolají externí konkurenci. Podpůrné procesy však mají tendenci "žít vlastním životem", být přebujelé, a přitom neposkytovat služby v žádoucím rozsahu a na žádoucí úrovni. Předimenzovanost vyvolává neúměrné režijní náklady, aniž je mnohdy zajištěn žádoucí rozsah, kvalita a intenzita podpůrných služeb. Poddimenzování podpůrného procesu sice vede ke zdánlivým úsporám nákladů, ale ve skutečnosti způsobuje ztráty v hlavních procesech způsobené nedostatečným rozsahem, kvalitou a intenzitou podpůrných služeb.

Obr. 2: Dimenzování informatiky

Cesta, jak těmto nežádoucím jevům zamezit:

V návaznosti na RPZ dosahovaný prostřednictvím informatiky definovat nároky na informatickou podporu formou Service Level Agreement (SLA).

SLA je nástrojem stanovení správně dimenzovaných podpůrných služeb, v našem případě informatiky. Je prevencí devastace dosaženého RPZ podpůrných procesů.

Infrastruktura požadovaných služeb podmiňuje strukturu podprocesů samotné informatiky (vazby nároků hlavního procesu nelze realizovat přímo na podprocesy informatiky). Požadavky na zabezpečení žádoucí úrovně podprocesů informatiky jsou nástrojem správného dimenzování informatických zdrojů.

Vzhledem k tomu, že v souvislosti s SLA panuje i v odborných kruzích celá řada nepřesných představ až omylů, uvádím níže popis podle mne správné struktury SLA.

Service Level Agreement
Služby IS/IT jsou zajišťovány buď vlastním útvarem informatiky, nebo externím poskytovatelem, resp. v kombinaci. Metriky, které jsou komplexně zaměřeny na popis a hodnocení úrovně poskytovaných informatickým služeb jsou obvykle vtěleny do Service Level Agreement (SLA).

Určení požadované úrovně služeb
Service Level Agreement je portfoliem metrik, které je nástrojem řízení informatiky, a to jak ve vztahu k externímu poskytovateli, tak ve vztahu k internímu útvaru informatiky. SLA je pojem, které primárně vznikl jako nástroj měření úrovně poskytovaných služeb externím poskytovatelem v rámci outsourcingu, outhoustingu, resp. v rámci jiného typu smluvního vztahu, jako je kupř. servisní smlouva.

Naměřené hodnoty SLA potom podmiňují výši plateb, resp. uplatnění sankcí ve vztahu k externímu poskytovateli. SLA jako portfolio metrik je stěžejním parametrem rozhraní mezi odběratelem a externím poskytovatelem informatických služeb. V podnicích s vyšší úrovní řízení informatiky je SLA užíván i interně, jako nástroj přesnější specifikace požadované úrovně služeb poskytovaných vlastním útvarem IT. Pro interní užití je SLA většinou simplifikován. Již snaha po přesnější formulaci požadavků na informatickou podporu a přesnější vyjádření požadavků vede k optimalizaci nákladů i přínosů informatiky. Nadefinovaná úroveň SLA totiž predeterminuje nákladovost informatiky. Objektivní požadavky na úroveň funkcionality a intenzitu informatické podpory nejsou ale u všech uživatelů IS stejné.

Uplatnění tohoto přístupu potom vede k zařazení uživatelů do skupin, pro které je uplatňován diferencovaný přístup při eskalaci: hlášení poruch (tzv. incidentů), požadavků na změny stávajícího stavu IS/ICT, nových požadavků, tedy na rozšíření definované úrovně poskytovaných služeb.

Pro jednotlivé kategorie koncových uživatelů je možno stanovit standardy HW a SW vybavení, tréninkové programy apod. Příslušnost k určité skupině koncových uživatelů určuje prioritu, která upřednostňuje některé koncové uživatele, pokud v daný okamžik vznikají kapacitní problémy ve zdrojích podpory. Objektivizace podpory uživatelů IS/ICT není možná bez zřízení interního "Help-Desk", který stanovuje priority řešení a řídí eskalaci problému z hlediska předávání požadavku mezi jednotlivými úrovněmi podpory koncových uživatelů. Tento odstavec má platnost, pouze pokud se jedná o interní SLA. U služeb poskytovaných externě je tato starost problémem poskytovatele.

Příslušnost k dané skupině koncových uživatelů přitom není dána postavením v hierarchii firmy, nýbrž tím, do jaké míry je realizace "core business" svázána s potřebou informatické podpory. SLA syntetizuje parametry šíře a úrovně poskytovaných informatických služeb pro definované kategorie uživatelů.

Příklad kategorizace příjemců služeb informatiky:

Komerční uživatelé: Koncoví uživatelé systému využívající IS/ICT průběžně k výkonu rutiny. Vysoká závislost na ICT, snesou však kratší výpadky.

Komerční uživatelé 24: Koncoví uživatelé systému využívající IS/ICT průběžně k výkonu rutiny s celodenní podporou. Vysoká závislost na ICT, snesou však kratší výpadky.

Běžní uživatelé kancelářských aplikací: Uživatelé systému s nepravidelným přístupem k systému, snesou i delší výpadky.

Pokročilí uživatelé: Pracovníci technické podpory, vývojoví pracovníci, testéři. Vysoká závislost na ICT, snesou kratší výpadky.

VIP: Komerční uživatelé kriticky závislí na ICT podpoře. Výpadky jsou nežádoucí.

V podmínkách outsourcingu je stanovení kategorií koncových uživatelů, SLA, procedury eskalace problémů, standardy vybavenosti apod. jedním ze základních předpokladů úspěchu.

Při interním uplatnění SLA jsou sledovány následující cíle:

Dosažení definované úrovně a intenzity vztahů mezi útvarem informatiky - interním poskytovatelem služeb IS/ICT a ostatními útvary podniku.V některých případech jsou vztahy dotaženy do interního přeúčtování, resp. interních plateb, na bázi uplatnění Acvity Based Costing/Activity Based Management.

Metrikou služeb je SLA.
Optimalizace infrastruktury informatiky.
Optimalizace nákladů na informatiku.
Diferencovaná podpora koncových uživatelů.

Obsah SLA je dán charakterem služby. Některé složky SLA mají obecnou platnost a jsou uváděny u všech typů služeb, některé se vztahují pouze k dané službě. Současně platí, že SLA může mít rozdílné parametry pro různé kategorie koncových uživatelů. Níže je uvedena specifikace obsahu SLA, který stanovuje požadovaný objem a kvalitu jednotlivých informatických služeb za definovaných podmínek. Níže uvedená specifikace reprezentuje rozsah, který je minimální z hlediska odběratele, aby byly smluvně poskytované služby popsány na úrovni, která je prevencí možnosti rozdílného výkladu.

SLA jako porfolio metrik sestává z následujících částí:

a) Základní specifikace, podmínky a pravidla:
Kategorie příjemců.
Přesné vymezení počtu a umístění příjemců dané kategorie.
Poskytovatel - bližší určení (uvádí se, má-li smysl, resp. je-li uživatelů více).
Měření - postup, způsob, periodicita, odpovědnost a vykazování výsledků.
Ověřování - postup, způsob, periodicita, odpovědnost a vykazování výsledků ověřování správnosti měření.
Určení a způsobu realizace podpory (kupř. fyzicky na místě, vzdáleně apod.)
Návazné podpůrné služby spojené s danou službou (kupř. trénink na místě, resp. na učebně).
Cena služby.
Platební podmínky.
Pravidlo pro změny služby.
Práva a povinnosti obou stran - podmínky součinnosti.
Ostatní podmínky pro realizaci SLA (právo informovanosti, odpovědnost za vady a škody apod.).

b) Tvrdé metriky:
Dostupnost (v % vyjádřený skutečný čas disponibility aplikace na daném zařízení uživatele ve vztahu k celkovému efektivnímu fondu pracovní doby za určenou časovou jednotku).
Běžná a maximální přípustná (kritická) doba odezvy na požadavek, tzv. incident (v členění na jednotlivé typy požadavků, jako je např. hlášení poruchy aplikace , poruchy HW, přemístění koncové stanice apod.).
Běžná a maximální přípustná (kritická) doba řešení požadavků (v členění na jednotlivé typy požadavků).
Průměrná a mezní odezva aplikace v rámci služby.

c) Měkké metriky:
Ostatní metriky pro danou službu (kvalitativní ukazatele typu "akceptace", "zápis", "potvrzení realizovaného školení a prezenční listina", "hodnocení lektora školení", "hodnocení účastníka školení" apod.).

V souvislosti s tvrdými metrikami SLA, jako je odezva, dostupnost apod., jsou v některých případech stanovovány až tři úrovně tohoto parametru: Servisní úroveň - požadovaná hodnota parametru za standardních podmínek (např. dostupnost na úrovni 0,97 a vyšší). Minimální servisní úroveň - pod tuto mez nesmí hodnota daného parametru nikdy klesnout, např. dostupnost 0,94). Motivační (incentive) servisní úroveň - má motivovat poskytovatele k poskytování nadstandardní úrovně služeb (např. dostupnost nad 0,99).

Nedosažení "servisní úrovně" vede ke snížení plateb za služby. Nedosažení ani minimální servisní úrovně je událostí, která způsobí uplatnění předem definovaných sankcí. Dosažení motivační úrovně naopak zakládá nárok poskytovatele na bonus. Tzv. paušál plateb za poskytované služby je v podmínkách outsourcingu stanoven k "servisní úrovni". Platebními podmínkami je stanoven vliv minimální servisní úrovně a motivační servisní úrovně na jeho skutečnou výši za dané období.

Postup naznačený v tomto článku na obecné úrovni z pohledu dimenzování informatiky platí pro podpůrné procesy obecně. Logická návaznost kroků (a) cíle definované na bázi Balanced Scorecerd - (b) stanovení absolutního potenciálu zlepšení - (c) analýza limitů - (d) stanovení reálného potenciálu zlepšení a očekávaných efektů vyjádřených formou tvrdých metrik - (e) snímek současného stavu - (f) stanovení strategie dosažení reálného potenciálu zlepšení - (g) výpočet návratnosti dosažení reálného potenciálu zlepšení - (h) stanovení SLA jako nástroje dosažení žádoucí úrovně podpory hlavního procesu, jsou postupem, který se ve správném provedení může stát nástrojem dosažení optimálně dimenzované informatiky.

Literatura:
[UCEN_01] Učeň, P. a kol.: Metriky v informatice. Jak objektivně zjistit přínos informačního systému. Grada. Praha, 2001.
[KAP_96] Kaplan R. S., Norton D. P.: The Balanced Scorecard. HBS Press, Boston, 1996.
[CBT_1] ISACF COBITTM Executive Summary (ISACF, It Governance Institute 2000).
[CBT_2] ISACF COBITTM Management Guidelines (ISACF, It Governance Institute 2000).