SLA a OLA pro různé druhy služeb

Dohody o úrovni služeb určují vztahy mezi poskytovateli a příjemci služeb a významně ovlivňují jejich průběh. V této práci se zabývám rozdílem dvou hlavních typů těchto dohod Service Level Agreement (SLA) a Operational Level Agreement (OLA), popisuji jejich strukturu, shrnuji doporučení pro jejich tvorbu dle metodiky MMDIS a operačních rámců ITIL a MOF, analyzuji různé cenové modely pro jejich poskytování a nakonec demonstruji jejich použití pro různé typy služeb. Záměrem této práce je poskytnout pracovníkům v oblasti IS/ICT základní přehled o struktuře dohod o úrovni poskytované služby a nabídnout jim snadno pochopitelný návod na jejich tvorbu.

1 Úvod

Dohoda o úrovni poskytovaných služeb tvoří základní nástroj pro hodnocení úrovně poskytovaných služeb a řeší faktory, které souvisejí s jejich dostupností a výkonem. Příjemce služby ji uzavírá s poskytovatelem služby, aby si zajistil plynulý a nepřerušovaný odběr služby. Tato dohoda je hlavním nástrojem pro porovnání úrovně dodávaných služeb s úrovní očekávanou, kterou je poskytovatel povinen zajistit.

V rámci dohody jsou řešeny požadované aspekty, jako jsou dostupnost, výkon a bezpečnost, evidence incidentů, řešení problémů a mnoho dalších faktorů a situací vzniklých při poskytování a příjmu IT služby. Součástí každé dohody o úrovni poskytované služby musí být cena a samozřejmě postih za neplnění. Dohoda o úrovni poskytované služby se může týkat různých IT služeb, každopádně však její význam roste u kritických částí infrastruktury a byznys aplikací.

V této práci se zabývám rozdílem dvou hlavních typů těchto dohod Service Level Agreement (SLA) a Operational Level Agreement (OLA), popisuji jejich strukturu, shrnuji doporučení pro jejich tvorbu dle metodiky MMDIS [?] a operačních rámců ITIL [?] a MOF [?], analyzuji různé cenové modely pro jejich poskytování a nakonec demonstruji jejich použití pro dva různé typy služeb.

Mnoho firem poskytujících služby v oblasti IS/ICT rádo uvádí, že jejich produkty jsou zajištěny s použitím SLA. Zpravidla se však jedná jen o vymezení dostupnosti a ceny bez hlubšího rozvedení podmínek poskytování služby. Za SLA a OLA nelze považovat jednostranně prosazované podmínky. Je potřeba dojít k oboustranné dohodě, aby poskytovatel byl schopen službu trvale dodávat ve vymezené kvalitě a příjemci přinášela požadovaný užitek.

Cílem této práce je přehledně shrnout rozdíly mezi SLA a OLA dle výše zmíněných metodik a operačních rámců, aplikovat je na příkladu z praxe a poskytnout tak srozumitelný návod pro jejich tvorbu.

2 Service Level Agreement a Operational Level Agreement

Hlavní a základní rozdíl mezi Service Level Agreement (SLA) a Operational Level Agreement (OLA) spočívá ve stranách těchto dohod. Zatímco SLA je dohoda o úrovni poskytovaných služeb mezi IT organizací jako celkem a jejím zákazníkem, OLA je dohoda o úrovni poskytovaných služeb mezi jednotlivými funkčními IT celky organizace.

Základním vyjádřením SLA může být počet zaručených hodin provozu celého systému – tedy dostupnost celé služby. OLA naproti tomu obsahuje záruky provozu jeho jednotlivých součástí, např. záruky provozu a údržby koncových stanic, záruky provozu a údržby serverů, databází, datových spojů, apod.

Rozdíl spočívá hlavně v návaznosti poskytovaných služeb a vytvoření záruk pro jejich plnění. Záruky uvedené v SLA musí být měřitelné a plně podporované ze strany OLA, na nichž je SLA závislá. Bez plnění podmínek stanovených v OLA nelze splnit ani podmínky SLA.

2.1 Ilustrace vztahů založených na SLA a OLA

Ilustrace [MOF 4.0, Business IT Alignment SMF, s. 25] ukazuje vztahy založené na SLA (mezi příjemcem služby a manažerem služby), vztahy založené na OLA (mezi manažerem služby a jednotlivými jednotkami zabezpečující provoz služby) a vztahy založené na UC (mezi jednotkou zabezpečující část provozu služby a externím dodavatelem).

Výše zmíněný termín UC (Underpinnig Contract) tvoří třetí typ dohod o úrovni poskytovaných služeb. Jedná se o dohodu uzavíranou mezi organizační jednotkou podílející se na poskytování IT služby a jejím externím dodavatelem. Ve své podstatě se jedná o obdobný dokument jako OLA, i když některá ujednání bývají odlišná právě v návaznosti na fakt, že se jedná o dodavatele mimo organizaci.

V následujícím textu sumarizuji a vysvětlím obsah a formu obou dohod o úrovni služby, jak k nim přistupují metodika MMDIS a operační rámce ITIL a MOF.

3 SLA a OLA podle MMDIS

Metodika MMDIS vyvíjená a spravované na Vysoké škole ekonomické v Praze uvádí následující strukturu SLA:

„identifikace – odpovídá na otázku „Kdo a komu službu poskytuje?“,
cíle, efekty – specifikuje „Proč se služby poskytuje?“,
objem – odpovídá na otázky „Kde?“, tj. ve kterých lokalitách a kterým uživatelům se služby poskytuje, a „Kolik?“ tj. jaký je celkový objem služby v daném období,
kvalita – specifikuje „S jakou dostupností, dobou odezvy, spolehlivostí a bezpečností se služby poskytuje?“,
cena a obchodní podmínky – udávají „Za kolik se služba poskytuje?“ a „Jaké okolnosti ovlivňují výslednou cenu služby?“,
ostatní charakteristiky služby – tato část uvádí zbývající obchodně-technické charakteristiky služby, jako způsob vykazování služby, postup při změnách služby, postup při ukončení služby atd. [VOŘÍŠEK, 2008, s. 298]

3.1 Identifikace služby

První část obsahuje název služby, definici stran poskytování služby (poskytovatel, příjemce a jejich odpovědné osoby), kategorie uživatelů a definici typu služby. Dále pak odkazy na další smluvní závazky stran služby jako například tzv. rámcovou smlouvu. Ta bývá používána ke shrnutí podmínek společných pro více služeb poskytovaných jednomu příjemci. Součástí by mělo být i uvedení stavu, ve kterém se SLA nachází (návrh, schváleno, platná do, atd.)

3.2 Cíle a efekty

Tato část je dle MMDIS uváděna jako fakultativní. Obsahuje důvod poskytování služby a její přínosy. V některých případech však není vhodné toto ustanovení používat. „Je-li poskytovatelem externí organizace, může být uvedení byznys cílů služby v SLA nevhodné, protože se tím mohou dostávat mimo podnik citlivé interní údaje.“ [VOŘÍŠEK, 2008, s. 299]

3.3 Obsah/předmět služby

Tato část SLA slouží k přesné specifikaci dodávané služby. Specifikace a především forma jejího vyjádření se liší podle druhu služby. Informační či infrastrukturní služby mívají méně technicky zaměřený popis. Oproti nim popis aplikačních služeb bývá rozsáhlejší, jelikož obsahuje kromě obsahu služby i technickou specifikaci způsobu poskytování.

Mezi základní součásti obsahu/předmětu definice služby v SLA podle metodiky MMDIS patří:

„obsah dodávaných informací,
struktura dodávaných informací,
komunikační kanál a jazyk, ve kterém jsou informace dodávány.“ [VOŘÍŠEK, 2008, s. 299]

Rozšiřující součásti obsahu/předmětu definice služby v SLA tvoří:

„funkcionalita,
vstupní a výstupní datové struktury,
drobná údržba, přizpůsobení a integrace na ostatní aplikace příjemce služby“ [VOŘÍŠEK, 2008, s. 299]

3.4 Objem a rozsah služby

Typickými ukazateli objemu poskytované služby jsou: počet uživatelů, počet míst odebírajících službu, objem zpracovaných či přenesených dat, apod. Uživatelé bývají zpravidla děleni do skupin, často je potřebné i určit konkrétní uživatele v jednotlivých skupinách a přesné určení místa odběru služby z důvodu monitoringu dostupnosti a řešení reklamací.

Rozsahem služby je pak rozuměno určení lokalit, ve kterých je služba dostupná. Může se jednat nejen o budovu podniku, útvar podniku či konkrétní osoby, ale může jít i o geografické vymezení podle dostupnosti signálu mobilních operátorů a připojení k internetu.

3.5 Kvalita služby

V této části SLA by měly být co nejpřesněji určeny kvalitativní požadavky na službu a způsob jejího poskytování. Pod pojem kvalita jsou dle metodiky MMDIS zařazeny následující atributy služby: aktuálnost dat, doba poskytování služby, dostupnost služby, doba odezvy, reakční doba, doba řešení a bezpečnost služby. [VOŘÍŠEK, 2008, s. 302]

Aktuálností rozumíme správnost dat v okamžiku jejich doručení příjemci služby. Obecně, nejen podle metodiky MMDIS, je rozlišován přístup k aktuálnosti dat podle toho, zda zdroj dat ovládá poskytovatel nebo odběratel služby. Je zřejmé, že v případě, kdy poskytovatel služby jen zpracovává data, která mu poskytuje příjemce služby, bude zodpovědnost za aktuálnost dat jiná, než v případě, že odběratel služby přijímá veškerá data od poskytovatele služby.

Doba poskytování služby určuje, v jaké době je služba dostupná. V této oblasti existuje mnoho zaběhnutých modelů. Nejznámější je nejspíš model 24/7/365, kdy je služba poskytována nepřetržitě. Jsou ale i jiné, např. jen v pracovní dny a to ještě ve stanovené době. „U nepřetržitě poskytovaných služeb je pak obvyklé, že SLA obsahuje také plánované odstávky provozu služby, ve kterých probíhá údržba software a technologické infrastruktury.“ [VOŘÍŠEK, 2008, s. 301]

Od doby poskytování služby je potřeba odlišit dostupnost služby. Dostupností služby rozumíme čas, po který lze službu reálně odebírat. Dostupnost se zpravidla pohybuje mezi 95 – 99,99 %. Dostupnost se také významně podílí na ceně služby (s rostoucí požadovanou dostupností roste cena služby).

Dobou odezvy rozumíme čas potřebný na provedení dané transakce – čas od vyslání požadavku do přijetí odpovědi.

Reakční doba je doba pro zahájení řešení od přijetí incidentu a reakční doba je maximální čas pro jeho vyřešení.

V praxi je pro nastavení úrovně kvality služby zpravidla používáno několik úrovní. Metodika MMDIS uvádí 4 (standardní úroveň, podstandardní úroveň, kritickou úroveň a nadstandardní úroveň). Úrovním kvality a jejich vlivu na cenu služby se budu více věnovat v části Cenové modely.

3.6 Cena služby

Cena služby tvoří jednu z významných atributů služby. Vzhledem tomu, že cenové modely jsou součástí samostatné kapitoly, přenechám strukturu a tvorbu ceny této části práce. Rozhodně je však potřeba uvést, že významný vliv na tvorbu a schválení cenového modelu bude mít druh dohody o úrovni poskytovaných služeb. „V případě, že poskytovatelem služby je interní ICT útvar, využívají se pro přeúčtování nákladů na jiné útvary především nákladové ceny. U externího dodavatele je pochopitelně k nákladům přičten zisk.“ [VOŘÍŠEK, 2008, s. 303]

4 SLA a OLA dle ITIL

Information Technology Infrastructure Library (ITIL) V3 rozebírá dohody o úrovni poskytování služeb v části Service Design. V této publikaci ITIL jsou diskutovány především následující hlavní hodnoty pro byznys:

„redukce celkových nákladů na vlastnictví (TCO),
zlepšení kvality služby,
zlepšení konzistence služby,
jednodušší implementace nové nebo změněné služby,
lepší zacílení služby,
zefektivnění výkonu služby,
zefektivnění celého procesu Service Managementu a IT procesů,
přístupnější informace a zlepšení přijímání rozhodnutí“ [ITIL FOUNDATION]

Dle ITIL je implementace celého návrhu služby (Service design) a tedy i východisek pro tvorbu SLA založena na přípravě a plánování tzv. 4P (Four Ps) [ITIL FOUNDATION, s. 102]:

lidé (People),
procesy (Procesess),
produkty (Products) – služby, technologie a nástroje,
partneři (Partners) – dodavatelé, výrobci a obchodníci).

Detailní průzkum těchto čtyř oblastí:

kteří lidé se účastní,
které procesy jsou ve službě obsaženy,
jaké produkty má služba poskytovat,
s kterými partnery je potřeba spolupracovat,

má vyústit v definici požadavků na úroveň služby (Service Level Requirements). Tyto požadavky musí brát v úvahu všechny oblasti navrhované služby tak, aby daná služba vždy dosahovala funkcionalitu a kvalitu, kterou byznys očekává.

Požadavky na úroveň služby pak slouží jako vstup do procesů tvorby SLA či OLA. Dle ITIL se jedná o následující procesy:

„stanovit, vyjednat, dokumentovat a odsouhlasit veškeré požadavky na novou nebo změněnou službu, zahrnout je do katalogu požadavků (Service Level Requirements – SLR) a ten pak transformovat do stanovených cílů v SLA.
monitorovat a měřit výkon všech služeb oproti cílům stanovených v SLA,
měřit, porovnávat a zlepšovat spokojenost zákazníka,
reportovat provoz služby,
provádět kontrolu služby a podněcovat zlepšování v rámci celkového plánu vylepšení (Service Improvements Plan),
kontrolovat a revidovat vzniklé SLA, OLA a další podpůrné kontrakty,
vyvíjet a dokumentovat kontakty a vztahy s byznysem, zákazníky a zainteresovanými stranami.“ [ITIL FOUNDATION, s. 112]

Součástí efektivního vytváření a správy SLA i OLA je také vytváření, provozování a správa postupů pro zaznamenávání kladných i záporných reakcí stran dohod a jejich zapracování do aktuálních šablon těchto dohod. Zkušenosti z návrhu, vývoje i provozu služeb se musí odrážet v databázi znalostí poskytovatele služby.

ITIL rozeznává tři základní druhy SLA:

servisně orientovanou SLA (Service-based SLA): jedna služba poskytovaná více zákazníkům,
zákaznicky orientovanou SLA (Customer-based SLA): dohoda s individuální skupinou zákazníků pokrývající všechny služby, které jsou jim poskytovány,
multi-level SLA: vícevrstevná struktura, kombinující obě předchozí např.:

„Korporátní úroveň: řeší otázky vztahující se ke každému zákazníkovi
Zákaznická úroveň: řeší otázky relevantní jen k určité skupině zákazníků nebo byznys jednotce
Servisní úroveň: řeší otázky vztahující se ke specifické službě ve vztahu k specifické skupině zákazníků.“ [ITIL FOUNDATION, s. 130]

Dokument SLA má podle ITIL V3 následující strukturu:

Základní podmínky
Popis služby
Rozsah ujednání
Doba provozu služby (service hours) [?], dostupnost služby a spolehlivost služby
Zákaznická podpora, kontaktní místa a způsob eskalace (incidentů)
Výkon služby
Změnové řízení, zajištění kontinuity a bezpečnosti služby
Odpovědnosti
Cena
Reportování a revize

ITIL neuvádí popis jednotlivých částí SLA přímo v procesu Service Level Management, ale přenechává ho do popisu podprocesů (v rámci Service Level Managementu), z kterých tak můžeme vyvodit jejich obsah.

Samotný proces SLM ještě uvádí příklady metrik služby (Key Performance Indicators - KPI), které dělí na objektivní (obecně měřitelné a vyjádřitelné) a subjektivní (měření a vyjádření je závislé na individuálním posouzení).

Objektivní:

Počet nebo procentuální vyjádření splněných cílů služby

Počet a závažnost výpadků služby

Počet služeb s aktualizovaným SLA

Počet služeb s včasným reportováním a revizemi

Subjektivní:

Zlepšení v uspokojení zákazníků

Tabulka 1 – Příklady KPI podle ITIL V3 [ITIL FOUNDATION, s. 132]

V následujícím popis podprocesů Service Level Managementu se zaměřím především na cíle určující obsah SLA.

4.1 Service Catalog Management

Charakterizuje službu a její okolí. Zajišťuje správnost a aktuálnost stavu, rozhraní a závislostí služby. Při tvorbě SLA je důležitý pro stanovení popisu služby.

4.2 Availability Management

„Vytvoření a správa patřičného a aktuálního plánu dostupnosti služby, který reflektuje současné a budoucí požadavky byznysu.“ [ITIL FOUNDATION, s. 140] Při tvorbě SLA je důležitý pro stanovení podmínek dostupnosti služby, tedy kdy bude služba k dispozici.

ITIL uvádí několik příkladů měření dostupnosti:

Dostupnost (%) =

Spolehlivost (Střední doba mezi systémovými incidenty) =

Spolehlivost (Střední doba mezi pády) =

Udržovatelnost (Střední doba pro obnovu) =

Zajímavou metrikou může být také užitečnost (Serviceability), vyjadřující schopnost dodavatele dostát svým závazkům. „Zpravidla se jedná o kombinaci dostupnosti, spolehlivosti a udržovatelnosti stanovených na určitých hladinách.“ [ITIL FOUNDATION, s. 146]

4.3 Information Security Management

Cílem je ochránit zájmy těch, kteří spoléhají na systémy a komunikace, jež doručují informace, před újmou způsobenou pádem [ITIL FOUNDATION, s. 152]. Při tvorbě SLA je tato část důležitá pro stanovení bezpečnosti, tedy dostupnosti, důvěrnosti a integrity. ITIL uvádí navíc autentičnost informace a neodmítnutelnost informace.

4.4 Supplier Management

„Cílem je řídit dodavatele a služby, které poskytují. Supplier Management je důležitým procesem zvláště pro tvorbu OLA.“ [ITIL FOUNDATION, s. 158] ITIL výslovně uvádí, že tento proces se má starat o „získání hodnoty za peníze“´[ITIL V3, s. 127], tedy přeměnit finanční prostředky do hodnoty, kterou poskytne dodavatel. Strategie řízení dodavatelů by měla vyústit ve vytvoření databáze dodavatelů (Supplier and Contract Database), která obsahuje veškeré informace (nejen OLA) o dodavatelích. Tato databáze by měla být udržována v permanentní konzistenci s požadavky na službu (SLR) a uzavřenými SLA.

4.5 Capacity Management

„Cílem je zajistit existenci nákladově zdůvodnitelných kapacit ve všech oblastech IT, které jsou přiřazeny k současným i do budoucna dohodnutým požadavkům byznysu.“ [ITIL FOUNDATION, s. 164] ITIL do tohoto procesu zahrnuje správu kapacit a výkonnosti služeb. Jedná se především o hlídání incidentů [?] a problémů [?] a jejich řešení. Pro tvorbu a udržování SLA a OLA je tento proces velmi významný. Bez stanoveného plánu kapacit a způsobu odstraňování vzniklých problémů nelze zajistit plnění sjednaných podmínek. ITIL tento proces navíc rozvádí do tří oblastí: Řízení byznys požadavků, řízení služeb, které podporují dosahování byznys požadavků a řízení kapacity jednotlivých komponent, ze kterých se služba skládá.

4.6 IT Service Continuity Management

Tento proces klade důraz na udržitelnost poskytování služeb. Doporučuje stanovit, kontrolovat a revidovat Business Continuity Plan a analýzu rizik. Reviduje správnost nastavení a provádění ostatních procesů Availability Managementu, a tím i dodržování podmínek stanovených v SLA pro danou službu.

5 SLA a OLA dle MOF

Vzorová SLA podle MOF obsahuje následující strukturu:

poskytovatel a příjemce služby,
oblast, kterou dohoda pokrývá, proč je ujednávána a k čemu slouží,
doba platnosti a způsob provádění zásadních změn v obsahu dohody,
obsah služby a způsob poskytování,

podrobný popis služby, hardwarového i softwarového zázemí,
doba poskytování služby (service hours) – přesné vymezení času,
zákaznická podpora - čas a způsob komunikace stran dohody, včetně doby odezvy na požadavky,
dostupnost služby,
spolehlivost služby,
výkonnost služby,
způsob provádění změn – popis celého procesu změny,
bezpečnost služby, včetně požadavků na hesla apod.,
cena nebo způsob jejího výpočtu,
způsob provádění drobných změn. [MOF 4.0, Business IT Alignment SMF, s. 37]

MOF klade důraz na jednoduchost a stručnost obsahu SLA. Podle MOF bychom měli mít stále na mysli, že SLA je zákaznicky orientovaný dokument, který by neměl obsahovat technicky zaměřené výrazové prostředky. Jedná se o dohodu, která musí být pro obě strany jasná a srozumitelná.

Toto pravidlo však platí ve všech výše zmíněných metodikách či operačních rámcích a vychází z úvodního rozdělení SLA a OLA. SLA uzavírají složky IT a byznys, na rozdíl od OLA, které vznikají výhradně mezi IT složkami, a obsahují podrobné technické definice úrovně poskytovaných služeb.

Nyní se podrobně zaměřím na způsob tvorby SLA podle výše zmíněných přístupů.

Operační rámec MOF definuje vždy 4 oblasti, které je potřeba při každém procesu brát v úvahu. Jsou jimi Základní otázky (Key Questions), Vstupy (Inputs), Výstupy (Outputs) a nejlepší praktiky (Best Practices).

Základní otázky ulehčují provedení popisu služby. MOF do nich zahrnuje [MOF 4.0, Business IT Alignment SMF, s. 2]:

Má služba exaktní specifikaci?
Má služba dohodnuté cíle (dostupnost, kapacita, doba provozu podpory, atd.)?
Jak budou předávány reporty z provozu služby?
Jak jsou identifikovány závislé OLA a UC? Kdo jsou jejich vlastníci?
Jak bude SLA publikována? Bude svázána s katalogem služeb? Jak zaručit, že bude SLA používána?
Jak měřit výkonnost SLA? Budou prováděny periodické revize SLA?
Kdo je vlastníkem SLA ze strany IT a kdo ze strany byznysu?
Jaké bude struktura SLA? Bude sestavena se zaměřením na službu, zákazníka nebo závislé služby?

5.1 SLA podle MOF

Vstupy pro tvorbu SLA obsahují:

OLA,
UC (Underpinning Contract),
katalog služeb.

Jak je vidět, MOF zde klade důraz na postup tvorby jednotlivých dohod stylem odspoda nahoru, vycházející z návaznosti a závislosti jednotlivých služeb. Katalog služeb a způsob jejich poskytování (interní x externí) jsou vstupem pro sestavení finální podoby SLA s obecnou strukturou:

„Definice stran dohody,
Popis služby
Doba trvání SLA
IT role a jejich odpovědnost
Doba poskytování služby a způsob komunikace výjimek při poskytování a příjmu služby
Definice dostupnosti služby
Definice spolehlivosti služby
Popis procesu řešení incidentů
Metriky
Popis procesu změny služby, odpovídající na otázky:

Jak bude provedena změna SLA?“
Jak budou strany upozorněny?
Kdo změnu schválí?
Kdo může žádat o změnu?

Popis procesu přerušení služby, odpovídající na otázky:

Jak bude ošetřeno přerušení poskytování služby?
Jaká je nejzazší doba obnovy poskytování služby?
Jak je řešena eskalace a kdo má oprávnění eskalovat?“ [MOF 4.0, Business IT Alignment SMF, s. 32]

Best practices při tvorbě SLA kladou hlavní důraz na ujištění, že jsou všechny podpůrné služby v provozu a jsou zabezpečeny svými OLA a UC. V případě zakládání nové SLA nesmí být zaručováno něco, co nemůže být současnou infrastrukturou podporováno (chybějící infrastrukturní kapacita).

Stejně jako ve vzorové SLA je i v obecných přístupech opět kladen důraz na formulaci SLA ze strany byznys účastníka – používání metrik z obchodní oblasti raději než z oblasti IT. „Například u skladového systému pracujícího v reálném čase bude lepší použít termín přesnost zásob na skladě nebo dostupnost reportů skladových zásob v reálném čase než dostupnost serveru.“ [MOF 4.0, Business IT Alignment SMF, s. 33]

MOF dále uvádí jako jednu z klíčových best practices při tvorbě SLA zhodnocení metrik SLA (s přihlédnutím k následujícím kritériím):

„Podporují metriky byznys cíle?
Jsou specifické?
Mohou být měřitelné?
Jsou dosažitelné? I v případě speciálních požadavků na stranu IT?
Jsou realistické? Ve vztahu k výhodám, které přinesou straně byznysu?“ [MOF 4.0, Business IT Alignment SMF, s. 31]

Při pohledu na způsob hodnocení metrik podle MOF je zřejmé, že se Microsoft při jejich tvorbě inspiroval definicí cíle dle projektového managementu – SMART (Specific, Measurable, Attainable, Realistic, Timed).

5.2 OLA podle MOF

Prvním krokem při tvorbě OLA podle Microsoft Operations Framework je zodpovězení klíčových otázek.

„Existuje mapa služeb, která definuje všechny služby, jejich závislosti a jejich vztah k byznys-službám identifikovaným v katalogu služeb?
Která kritická závislá služba potřebuje OLA, aby zajistila splnění SLA? Která z těchto závislých služeb formuje základní infrastrukturu, která podporuje všechny byznys služby? Příkladem může být Microsoft Active Directory and Network Services.
Kdo jsou vlastníci těchto závislých služeb?“ [MOF 4.0, Business IT Alignment SMF, s. 29]

Vstupem pro tvorbu OLA jsou podle MOF:

Servisní mapa
Existující SLA

Výstupem je pak samozřejmě OLA optimálně podporující dosahování podmínek stanovených v SLA, jejíž některou část zajišťuje.

Při tvorbě OLA uvádí MOF doporučení, aby byl kladen důraz na sdílenou odpovědnost všech, kdo se podílí na zajišťování klíčových a nákladově nejvýznamnějších služeb, které významně přispívají k dosahování cílů organizace. Podle MOF je zpočátku vhodné omezit počet OLA jen na tři nebo čtyři, které jsou nejvíce rozhodující pro základní infrastrukturu. OLA, které jsou dle MOF vždy vysoko na seznamu jsou:

„OLA pro zajištění služeb uživatelů (především Microsoft Active Directory),
OLA pro zajištění bezpečnosti,
OLA pro zajištění síťové infrastruktury (ta však může vyvolat potřebu více OLA pro jednotlivé dílčí části, jako například DNS, DHCP, LAN nebo WAN).“ [MOF 4.0, Business IT Alignment SMF, s. 30]

6 Nákladové modely

Jak jsem zmínil již z počátku, vychází cenové modely především z rozdílu, zda se jedná o službu poskytovanou zákazníkovi nebo zda se jedná o službu uvnitř organizace. Služby poskytované mimo organizaci (zákazníkovi) jsou ceněny dle nákladů na zabezpečení požadované úrovně (dohodnuté v SLA) a k nim je přičten zisk. Služby poskytované interně (mezi jednotkami organizace) jsou ceněny dle nákladů.

U placených služeb existují v zásadě dva hlavní modely. První je postaven na trvalých platbách za určitý, shora omezený objem služby. Druhý je postaven na objemu skutečně odebraném. Zatímco první s sebou přináší výhody pro poskytovatele – vždy dostane sjednanou částku, i když je poskytnutý (odebraný) objem služby nulový, druhý je rovnoprávnější pro obě strany. „V řadě ICT služeb se kombinují oba modely. To znamená, že zákazník platí určitou paušální sazbu a k ní je připočtena druhá část ceny, která odpovídá spotřebě zdrojů v daném období.“ [VOŘÍŠEK, s. 304]

Metodika MMDIS kalkuluje cenu služby jako součet ceny za provoz služby a ceny za údržbu služby. „Pro účtování údržby se obvykle používá ceník prací, dle kterého může zákazník objednávat specifické podpůrné služby“ [VOŘÍŠEK, s. 304]. Cenu provozu MMDIS stanovuje jako součet základní částky (paušál) a variabilní složky (podle poskytnutého/odebraného objemu). Od této částky je následně odečtena sjednaná sleva za nedodržení podmínek

„V ITIL se nákladové modely skládají z identifikace složek nákladů a faktorů, které ovlivňují jejich přidělování na služby, které podporují.“ [BUCALO, 2008] Složky nákladů zahrnují hardware, software, ceny externích poskytovatelů služeb či náklady na interní oddělení. Faktory, které ovlivňují jejich přiřazení, jsou například dohodnutá úroveň kvality poskytované služby, objem a rozsah poskytované služby a v neposlední řadě také významnost odběratele (klíčový zákazník bude mít přednost).

Jelikož ITIL není metodikou, neuvádí konkrétní návod, jak stanovit cenu služby. V Knize Service Design jsou však vyčteny různé druhy nákladů, jenž je potřeba brát v úvahu. Které z nich budou použity, již nechává na konkrétní situaci.

· Náklady příležitosti – náklady vynaložení pro vznik určité příležitosti, „např. nákup nového serveru odstraní náklady na udržování toho starého“ [ITIL V3, s. 140]

- Kapitálové výdaje (CAPEX) – náklady, které poskytují dlouhodobou hodnotou, např. počítačové vybavení, ale i celá budova,

- Přímé – náklady, které jdou jednoznačně přiřadit k jednomu zákazníkovi,

- Nepřímé – náklady, které nelze přiřadit k určitému zákazníkovi – zpravidla se rozpočítávají podle celkového počtu zákazníků (viz absorbované náklady),

- Okrajové náklady – náklady na pokračování v poskytování služby (bez již vynaložených investic), např. vývoj nové SW a zaškolení

- Fixní náklady – nezávisí na objemu poskytnuté služby, např. cena HW

- Operační – náklady na každodenní bázi (energie, zaměstnanci, atd.),

- Absorbované – nepřímé náklady, které byly rozděleny na jednotlivé zákazníky,

- Neabsorbované – nepřímé náklady, které nebyly rozděleny na jednotlivé zákazníky (například pokuty za nesplnění podmínek SLA).

Jinou možností je počítat celkové náklady na vlastnictví (TCO). Problémem tohoto přístupu je fakt, že služby jsou poskytovány průběžně prostředky na ně vynaložené tedy nelze považovat za jednorázovou investici, ze které plynou přínosy bez dodatečných nákladů. Je však možné TCO rozšířit o náklady průběžné a pokrýt tak variabilitu výdajů.

Nákladové kategorie, jejichž východiskem je TCO, lze rozdělit na kategorie:

- přímých nákladů: „náklady na viditelné investice do IT a podpory. Kalkulace těchto nákladů závisí na tom, jak přesné jsou inventáře majetku, platby, prodejní i osobní záznamy. Mezi tyto náklady řadíme například hardware a software, náklady na zaměstnance, pravidelné platby dodavatelům apod.“ [IT GOVERNANCE, s. 115],

- nepřímých nákladů: náklady vzniklé z nenadálých událostí, které ovlivní poskytování služby, ať již jejím celkovým zastavením nebo jen omezením. „Mezi tyto náklady zařazujeme např. prostoje uživatelů, kdy nemohou pracovat, protože služba není dodávána nebo dobu údržby systémů (40 minutová údržba způsobí prodlení 40 minut v produktivitě.“ [IT GOVERNANCE, s. 116]

Jak je z předchozího textu patrné, přístupů k modelování nákladů a predikci výdajů na poskytování služeb je mnoho. Kromě výše zmíněných existují samozřejmě další a těžko lze říci, který model je nejlepší.

V každém případě je však vhodné posoudit náklady z různých pohledů a aplikovat více modelů pro výpočet jejich výše a výskytu. Osobně se přikláním k přístupu dle ITIL. Jelikož se v případě ITIL jedná spíše o návrhy řešení než konkrétní pravidla, jsou i nákladové modely mnohem obecnější, jdoucí skrz všechny procesy. Je pak jen na řešiteli, které z nich správně přiřadí k nastalé situaci. Každopádně však od ITIL dostává jejich podrobný a široký výčet s mnoha uvedenými příklady.

7 Shrnutí MMDIS, ITIL a MOF pro různé druhy služeb

V následujícím textu se zaměřím především na části SLA a OLA, které budou rozdílné podle typu služby. Vynechávám záměrně úvodní části obsahující definici poskytovatele a příjemce služby. Pro správné určení stran a řešení případných budoucích sporů je však vhodné vymezit oba subjekty co nejpřesněji, včetně uvedení osob oprávněných za ně jednat a osob, které dohody uzavírají.

Pro ukázku SLA jsem zvolil webovou službu poskytování hromadných dat. Jedná se o aplikační službu, na které lze dobře předvést klasickou skladbu SLA včetně kombinovaného cenového modelu, jiného způsobu měření kvality než varianty dostupné/nedostupné a technických parametrů provozu služby.

Pro OLA jsem zvolil službu elektronického bankovnictví, které je vhodným příkladem situace, kdy k zajištění dodání služby zákazníkovi je potřeba sestavit a udržovat v chodu poměrně složitý systém vlastních i cizích IT procesů a zdrojů.

7.1 Srovnání uvedených přístupů

ITIL i MOF uvádí velmi podobnou strukturu obsahu a tvorby SLA i OLA. Používají dokonce i téměř shodnou terminologii a oba přístupy explicitně vyjmenovávají druhy používaných metrik.

MOF definuje vždy 4 oblasti, které je potřeba při každém procesu brát v úvahu: Základní otázky – Key Questions, Vstupy – Inputs, Výstupy – Outputs a nejlepší praktiky – Best Practices a uvádí hlavní otázky, které by si měl poskytovatel služby položit, aby lépe a jednodušeji službu definoval.

ITIL uvádí vždy výchozí popis procesu, záměr a důvody jeho použití. Dále pak hlavní cíle, kterých je potřeba dosáhnout a vždy vyjmenovává dostatek příkladů - potřebné dokumenty, dohody, metriky, způsob jejich použití, prováděné aktivity, způsob měření, vyhodnocování a reportování a popisuje roli manažera procesu a jeho činnosti (povinnosti). Vysvětluje pojmy a uvádí u nich dostatek příkladů. V případě SLA a OLA uvádí i jejich typický obsah.

Srovnáme-li přístup MMDIS a ITIL, vidíme, že jsou si dost podobné. MMDIS je sice jako metodika více teoretická, ale paralelu vidíme hned v několika oblastech. MMDIS má podrobně rozebrané dílčí části dohod o úrovni poskytované služby jako jsou identifikace, cíle, obsah, kvalita, objem a cena, ITIL zase definuje pro každou oblast samostatný proces, jehož optimalizace má zabezpečit danou část v požadované kvalitě. Nakonec ani MOF nezůstává pozadu a staví manažerovi procesu otázky, které jej mají vést k úspěšnému návrhu, zprovoznění a řízení služby.

Tvorbu cenových modelů staví všechny tři přístupy na základě mikroekonomických pravidel fungování trhu. Dle mého názoru je nejlépe rozebírá metodika MMDIS, která jasně stanovuje všechny nákladové aspekty služby. MMDIS dekomponuje celkové roční náklady vynaložené na informatiku a rozpočítává je na individuální služby, přičemž ponechává rozhodovací pravomoc vedení, aby některé služby upřednostnili před jinými (strategická rozhodnutí na základě významu jednotlivých služeb). Náklady na jednotlivou službu pak rozděluje na fixní a variabilní, respektive na provoz a údržbu. Základem fixních nákladů je podle MMDIS cena stanovená v SLA, ke které je nutné připočíst náklady na řízení služby a objemové vlivy (např. počet uživatelů). Náklady na údržbu lze z části omezit stanovením stropů pro změnové požadavky, případně požadavky na změny zcela vyloučit (např. při zcela standardizovaném řešení). Výsledkem je pak celková výše nákladů na službu v daném období, ke které je přičten zisk, jehož výše je založena na strategickém rozhodnutí poskytovatele služby.

ITIL při tvorbě ceny služby vychází ze dvou základních pojmů: užitečnost (utility) a záruka (warranty). ITIL je definuje jako „vhodnost pro daný účel“ (fitness for purpose) a „vhodnost k použití zákazníkem“ (fitness for use). Na těchto dvou pojmech staví návody a rady k tvorbě ceny. Radí, aby cena byla stanovena vždy na základě detailního průzkumu trhu a zjištění, co opravdu zákazníci potřebují a hledají. To pak má být vyvinuto a poskytováno a čím lepší je průzkum trhu a čím méně má podobné služby konkurence, tím výše může být nastavená cena. ITIL klade důraz na vytváření strategických aktiv (strategic assets) a stálého zvyšování potenciálu služby, což vede ke zvyšování poptávky po službě a zvyšování příjmů. Zvýšení příjmy lze opět využít na zvýšení potenciálu služby.

MOF se zaměřuje obdobně jako MMDIS na standardizované ekonomické přístupy a využívá především modelů operačních nákladů na provoz služby, návratnost investic (ROI) a celkové náklady na vlastnictví (TCO). Stejně jako ITIL však klade důraz na vytváření výsledné „hodnoty pro zákazníka“. I když se jedná o měkkou metriku (MOF uvádí, že se liší podnik od podniku), jedná se o hodnotu, kterou bude chtít znát manažer celé služby. Odpovídá totiž na úvodní otázku, co má být zákazníkovi poskytováno a určuje, zda toho bylo dosaženo.

7.2 SLA - Hromadné poskytování dat

Hromadné poskytování dat je v současnosti často využívanou formou komunikace mezi institucemi státní správy, ale i státní správou a soukromým sektorem. Na následujícím příkladu uvádím dohodu o úrovni poskytované služby pro získávání dat o průmyslových právech (patenty, vzory, ochranné známky, atd.). Představme si subjekt, který disponuje know-how, SW i HW, aby dokázal kumulovat informace o průmyslových právech, a tato data bude za úplatu poskytovat zájemcům z řad soukromého sektoru, jako jsou právní a patentové společnosti, advokáti apod., kteří tato data využívají při své činnosti. Jedná se o SLA, kterou mezi sebou uzavírají dva soukromoprávní subjekty. Dohoda by měla obsahovat vymezení druhu služby jako elektronické poskytování dat zabezpečené stanovenou technologií. V následujícím příkladě jsem zvolil webové služby, dnes velmi rozšířený standard. Poukazuji na to, co by v SLA nemělo chybět a uvádím pasáže výslovně zaměřené na tento druh služby. Doporučená struktura SLA je převzata z operačních rámců ITIL a MOF. Obsah je založen na kumulaci dat z mnoha rejstříků, jako např. rejstříku Evropského patentového úřadu (prostřednictvím jím poskytované webové služby Open Patent Services [EPO]) a poskytování nashromážděných dat za úplatu třetím stranám.

SLA – Dohoda o úrovni poskytované služby

1. Smluvní strany

Poskytovatel služby a příjemce služby, včetně firmy, sídla a identifikačních údajů. Nesmí chybět ani IČO, DIČ a údaje o zápisu do rejstříků ekonomických subjektů.

2. Název služby

Elektronické poskytování dat průmyslových práv.

3. Kontaktní osoby

Kontaktní osoby poskytovatele služby a příjemce služby. Může být uvedeno více osob. Zvláště na straně poskytovatele, aby měl příjemce služby možnost kontaktovat více osob pro případ nedostupnosti některé z nich.

Osoby oprávněné ke schvalování změn smlouvy, reklamací, eskalaci porušení smlouvy, incidentů a problémů a kontrole plnění smlouvy.

4. Doba trvání smlouvy

Smlouva nabývá platnosti a účinnosti dne …

Smlouva je platná do …

5. Způsob provádění změn ve smlouvě

Způsob provádění změn, kdo má oprávnění je navrhnout, kdo je schvaluje a jakým způsobem bude provedena změna smlouvy v návaznosti na změny.

Od kdy budou změny v platnosti, tedy od kdy má být poskytovatelem plněno.

Kdo je oprávněn k revizi změn a kdo je zodpovědný za schválení jejich úspěšné implementace.

6. Způsob ukončení smlouvy

Způsoby a situace, kdy může být smluvní vztah podle této smlouvy ukončen. Např. ukončení provozu služby, ukončení odebírání služby, hrubé porušení (porušování) smlouvy.

7. Popis služby

Služba poskytuje data o průmyslových právech v elektronické podobě z rejstříků národních úřadů průmyslového vlastnictví a to pro země: xxx, xxx, …

Data jsou poskytována prostřednictvím webové služby dle její standardizované specifikace: protokoly HTTP a SOAP a specifikace dle standardu WSDL.

Služba přijímá dotazy na individuální nebo hromadné poskytnutí dat o průmyslovém právu nebo právech. Služba poskytuje odpověď ve formátu XML definovanou pomocí standardu WSDL.

Specifikace webové služby dle standardu WSDL:

<?xml version="1.0" encoding="UTF-8" ?> <wsdl:definitions xmlns="http://ops.epo.org/wsdl" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="xxx" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ops="xxx" xmlns:exch="xxx" xmlns:ftxt="xxx" targetNamespace="xxx/wsdl" name="IprService"> … </wsdl:definitions>

7. 1 Uživatelé služby:

Definované lokality a subjekty, které mají přístup k webové službě. Definovaná omezení přístupu a autentizace i autorizace k webové službě.

7.2 Doba poskytování služby

Služba je poskytována nepřetržitě v režimu 24/7/365. Poskytovatel služby je oprávněn pozastavit poskytování služby v planém rozsahu maximálně 1x měsíčně na maximální dobu 2 hodin za účelem údržby HW, SW a další infrastruktury.

V případě nedostupnosti služby způsobeném havárií HW nebo SW vybavení poskytovatele je poskytovatel povinen uvést službu do provozu do maximálně 6 hodin.

7.3 Dostupnost služby

Webová služba musí být dostupná minimálně 95% času definovaného v článku 7.3. Služba musí být dostupná 99% tohoto času v době od 9 – 19 hodin středoevropského času.

7. 4 Kvalita služby

Webová služba musí zaslat odpověď nejpozději do 1 sekundy od přijetí dotazu. Odpověď je ve formátu XML a musí mít strukturu dle definice protokolu SOAP.

Obsah odpovědi musí být úplný a shodný s odpovědí získanou stejným dotazem prostřednictvím rejstříku průmyslových práv v zemi, na kterou je dotaz směřován.

Maximální povolené zatížení webové služby z jedné IP adresy příjemce je 100 dotazů během každých 60 minut v době od 9 – 19 hodin středoevropského času a 10.000 dotazů v době od 19 – 9 hodin středoevropského času.

7.5 Požadavek na službu

Webová služba je dostupná na adrese http://www.abc.com. Webová služba je dostupná prostřednictvím protokolu SOAP. Příklady použití služby:

Dotaz ve formátu XML:

<soapenv:Envelope> <soapenv:Header /> <soapenv:Body> Zde je uveden XML kód pro dotaz. </soapenv:Body> </soapenv:Envelope>

Odpověď ve formátu XML:

<soapenv:Envelope> <soapenv:Header /> <soapenv:Body> Zde je uveden XML kód pro odpověď. </soapenv:Body> </soapenv:Envelope>

8. Metriky služby

Kvalita odpovědí webové služby bude měřena porovnáním s odpovědí získanou stejným dotazem ve stejném dni prostřednictvím rejstříku průmyslových práv v zemi, na kterou je dotaz směřován. Odpověď rejstříku práv je výchozí pravdivou hodnotou. Porovnány budou následující atributy průmyslového práva:

1. Číslo registrace

2. Číslo přihlášky

3. Datum přihlášení

4. Datum registrace

5. Název

6. Majitel

Chyba v hodnotách 1 - 4 je tehdy, liší-li se jakkoliv odpověď webové služby od odpovědi rejstříku. Chyba v hodnotách 5 a 6 je tehdy, nelze-li z odpovědi webové služby jednoznačně určit název či vlastníka průmyslového práva.

V případě, že webové služba poskytne chybně kteroukoliv hodnotu 1 – 4, je celá odpověď chybná. Je-li poskytnuta alespoň jedna hodnota 5 nebo 6 správně a hodnoty 1 – 4 jsou správné, je celá odpověď správná.

Dostupnost služby je měřena na datovém výstupu z datového centra poskytovatele na adrese …

Kvalita odpovědí webové služby bude měřena 1x měsíčně na vzorku libovolných 100 dotazů na průmyslová práva v libovolných zemích uvedených v článku 7.

9. Odpovědnost stran

Poskytovatel služby je odpovědný za řádný provoz webové služby dle podmínek stanovených touto smlouvou. Poskytovatel zodpovídá za HW a SW vybavení potřebné k poskytování služby.

Příjemce je zodpovědný za HW a SW vybavení potřebné pro komunikaci s webovou službou. Příjemce služby je zodpovědný za připojení vlastních zařízení do sítě internet s minimální šířkou pásma 2048kb/s, aby mohl s webovou službou komunikovat.

Zde je vhodné uvést veškeré požadované odpovědnosti a povinnosti obou smluvních stran. Obě strany by měly dbát na to, aby jejich odpovědnost byla jasně vymezena a nebyla přenášena na druhou stranu.

Poskytovatel i příjemce provedou 1x ročně revizi této smlouvy a písemně potvrdí změny.

9. Cena služby

Cena služby se skládá z fixní měsíční částky a úhrady za odeslané odpovědi na dotazy na webovou službu.

Cena může být také ovlivněna kvalitou vrácených odpovědí. Jestliže poskytovatel dosahuje dlouhodobě velmi spolehlivých odpovědí, může mít nárok na zvláštní odměnu.

Naopak v případě chybného poskytování nebo porušování ujednaných kritérií kvality a dostupnosti by měl být poskytovatel penalizován.

Pravidelná pevná měsíční platba činí xxx,- CZK

Cena za jednu odeslanou odpověď činí xxx,- CZK

Celková měsíční částka je splatná nejpozději x. dne měsíce, za který je placena na základě vyúčtování poskytovatele.

Poskytovatel bude příjemci zasílat měsíční daňové doklady nejpozději do … dnů od obdržení platby.

7.3 OLA – elektronické bankovnictví

Pro rozbor této dohody jsem zvolil službu elektronického bankovnictví. Poskytovatelem služby je banka (právnická osoba), odběratelem je její klient (fyzická či právnická osoba). Služba je poskytována prostřednictvím internetové aplikace banky, ve které může klient provádět standardní bankovní operace.

Zatímco podmínky sjednané mezi bankou a klientem se budou řídit smlouvou o poskytnutí služeb elektronického bankovnictví a všeobecnými obchodními podmínkami, interní podmínky provozu služby budou řízeny SLA mezi manažerem procesu elektronického bankovnictví a vrchním manažerem IT oddělení (CIO). Ten je zodpovědný za dodání kapacit zdrojů služby tak, aby byly naplněny podmínky provozu služby. Jelikož každý zdroj má svého správce, CIO s nimi uzavírá dohodu o úrovni poskytování kapacit. Pokud jsou tyto zdroje uvnitř a pod kontrolou banky (interní oddělení), je pak tato dohoda typickým příkladem OLA.

Nyní stručně rozeberu produkt elektronického bankovnictví po IS/ICT stránce, abych mohl stanovit požadavky na zdroje a určit podstatné náležitosti OLA.

Elektronické bankovnictví je většinou internetová aplikace s napojením na služby (většinou webové), zajišťující zpracování bankovních požadavků jako jsou příkazy (jednorázové, trvalé, individuální, hromadné), výpisy (jednorázové, periodické, avíza o platbách) a nastavení (limity inkas, limity na platebních kartách) apod. Veškerá data zpracovávaná těmito službami jsou ukládána do databází banky.

Pro provoz elektronického bankovnictví (většinou v režimu 24/7/365) je nutné zabezpečit nepřetržitý provoz HW infrastruktury (databázové servery, webové servery, záložní servery, IP spojení), SW infrastruktury (operační systémy, webové aplikace, monitorovací a zálohovací aplikace), service desku (lidé, HW i SW vybavení) a mnoho dalších zdrojů banky. Zdánlivě jednotná služba se najednou rozpadá do celého portfolia služeb.

Typickou vlastností OLA je právě rozpad do dílčích služeb, jak ukazuje ilustrace [Smart SLA]. Tyto služby jsou pak seskupovány podle infrastrukturních, aplikačních či jiných hledisek. Lze tak vytvořit například skupiny služeb na zabezpečení provozu HW a skupiny služeb na zabezpečení provozu SW.

Ke každé skupině služeb je vhodné přistupovat samostatně, ale stále s vědomím, že se jedná o uzavřený celek. Vznikne tak více samostatných popisů služeb, definic spolehlivosti, dostupnosti, udržovatelnosti, výkonnosti i bezpečnosti pro každou individuální skupinu služeb, které ale tvoří integrovaný celek zabezpečující jedinou službu – elektronické bankovnictví.

Každá dílčí část pak obsahuje individuální hodnoty i metriky. Dostupnost serverů je měřena v procentech času, kdy server umožňoval přijetí požadavku, kapacita v době, kterou trvalo vyřízení jedné transakce, spolehlivost v počtu incidentů, apod.

Zde se mohu vrátit k ITIL metrice užitečnosti, která je pro OLA typickým příkladem měření úrovně služby. Kombinace dostupnosti, spolehlivosti, udržovatelnosti dohodnutá na určité úrovni pro celé spektrum služeb zabezpečujících provoz internetového bankovnictví.

Na výše zmíněném příkladu je názorně ilustrován rozdíl mezi SLA a OLA. Zákazník (uživatel elektronického bankovnictví) požaduje přístup k elektronickému bankovnictví stanoveným způsobem (identifikace a obsah služby), v požadované kvalitě (doba poskytování, dostupnost a doba odezvy) a za stanovenou cenu (cena služby). Poskytovatel musí poskytovat službu s těmito parametry. Navíc musí brát v úvahu množství uživatelů (objem a rozsah služby), aby byl schopen výše zmíněné parametry trvale naplňovat a hlídat naplňování parametrů sjednaných se svými vlastními dodavateli, ať již uvnitř podniku (OLA) nebo externími (UC). Pro poskytovatele služby to znamená udržet celý tento systém v běhu v požadovaných parametrech. Metodiky a operační rámce, které jsem uvedl, přináší různé pohledy, ale výsledný efekt lze považovat za shodný.

Metodika MMDIS představuje pro řízení model SPSPR (Strategy, Business Processes, Services, IT Processes, IT Resources). Strategická část, patřící do kompetencí vrcholového vedení podniku určuje cíle, vize a produkty. Část byznys procesů definuje pravidla, vstupy a výstupy samotného obchodního procesu elektronického bankovnictví (zde vzniká SLA s koncovým uživatelem i OLA s dodavateli). IT procesy jsou v kompetenci buď IT oddělení (pak mají své manažery a ti jsou zodpovědní za dodržování OLA vůči manažerovi obchodního procesu) nebo jsou nakupovány zvenčí a pak je manažer IT procesu zodpovědný za plnění UC dodavatelem.

Operační rámce ITIL a MOF přináší shodný pohled. Jejich rozdíl je v zásadě jen v umístění v cyklu služby. Zatímco ITIL definuje pro SLA i OLA proces Service Level Management v rámci druhé fáze životního cyklu služby – Návrh služby, MOF vyhrazuje SLA i OLA místo v procesu Business IT Alignment v první fázi životního cyklu služby – Plánování.

8 Závěr

V předchozím textu jsem se snažil vyložit podstatu dohod o úrovni poskytování služeb, jejich strukturu, obsah a přístup k jejich tvorbě podle metodiky MMDIS a operačních rámců ITIL a MOF.

I když jsou obě dohody SLA i OLA navenek velmi podobné, přístup k jejich tvorbě se liší. V obou případech je však nutné službu správně definovat, rozložit na dílčí části, stanovit reálnou (opravdu dosažitelnou) úroveň jejich poskytování, určit práva i povinnosti obou stran dohody, stanovit cenu, ale i postihy za neplnění a způsoby provádění změn a revizí dohody.

Metodika MMDIS i operační rámce ITIL a MOF sice uvádějí různé přístupy k jejich tvorbě, ale při celkovém pohledu je zřejmé, že podstata dohod, jejich struktury i tvorby zůstává stejná. Nelze jednoznačně určit, který způsob je nejlepší, vždy záleží na konkrétní situaci. V neposlední řadě je nutné poznamenat, že určitou roli hrají i osobní preference a znalost či orientace ve vybraném přístupu.

10 Použitá literatura

1. VOŘÍŠEK J., Principy a modely řízení podnikové informatiky, Oeconomica 2008, ISBN: 9788024514406

2. ITIL FOUNDATION, dokumentace ke školení ITIL Foundation, Unicorn Education 2010

3. Norton-Middaugh B., Dyer J., Henry C., Lemma D., Osborne J., Microsoft Operations Framework 4.0, 2.1 Business IT Alignment SMF, 2008

4. Norton-Middaugh B., Dyer J., Henry C., Lemma D., Osborne J., Microsoft Operations Framework 4.0, 2.4 Financial Management SMF, 2008

5. Van Bon J., de Jong A., Kolthof A., Service Design Based on ITIL V3: A Management Guide, Van Haren Publishing 2008, ISBN: 9789087531257

6. Kalder A., IT GOVERNANCE: A Practitioner’s Handbook, it governance 2005, ISBN: 9781905356034

7. ITIL ONLINE, cit. 21. 5. 2010, dostupné z www http://www.itil.cz/index.php?id=982.

8. WIKIPEDIA, The free encyclopedia, cit. 20. 6. 2010, dostupné z www http://en.wikipedia.org/wiki/Microsoft_Operations_Framework

9. BUCALO F., Rightsizing Service Cost Models, cit. 15. 6. 2010, dostupné z www http://www.itsmwatch.com/itil/article.php/3726706/Rightsizing-Service-Cost-Models-Part-I.htm

10. EPO, European Patent Office, Open Patent Services v. 2.6.1, dostupné z www http://www.epo.org/patents/patent-information/free/open-patent-services.html

11. Smart SLA, SYSOP Ltd, . 27. 8. 2010, dostupné z www http://www.sysop.co.uk/professional-services/sla-generator