Hledaný výraz musí mít více jak 2 znaky.
SLA (Service Level Agreement) obsahuje například garantovanou časovou dostupnost, garantovanou cenu nebo garantovanou rychlost řešení potíží se službou.
Níže je uveden seznam doporučených položek SLA:
- Obsah a popis služby (ze servisního katalogu)
- Provozní doba služby
- Měření dostupnosti a spolehlivosti služby
- Měření výkonnosti služby
- Doba reakce a vyřešení incidentu
- Schválení změny služby a její implementace
- Zodpovědnosti obou stran (dodavatel služby a odběratel služby)
- Komunikace obou stran (kontakty, eskalace)
- Reporting
- Proces revize
- Bezpečnostní parametry
Ale není to jen o Service Managementu, každá nová aplikace, kterou přidáváte do provozu je v podstatě nová služba pro zákazníka, tudíž by měla mít definované parametry poskytování služby Service Level Agreement. Je dobré to mít na paměti a společně se Service Managementem prověřit, zda se parametry nezměnili, pokud se jedná o stávající aplikaci anebo definovat nové SLA u nové aplikace. Definice SLA není práce Projektového Managera, ale měl by kontaktovat Service Management, aby zkontrolovali, zda je vše v pořádku. Většinou je to součástí předání aplikace do provozu.
SLA je důležité i z jiného pohledu projektového řízení. Uvedu příklady z praxe, kde SLA sehrálo klíčovou roli v rámci projektu. První příklad byl organizační program na restrukturalizaci a sloučení dceřiných společností mezinárodní korporace, konkrétně udělat z 9 společností 3. IT fungovalo jako samostatná firma (interní dodavatel) pro všechny dotčené společnosti. Oddělení Enterprise Architectury (EA) se teprve rodilo (dlouho a bolestně) a spíš duplikovalo některé stávající funkce. Prostě to klukům z Enterprise Architectury nešlo a při dotazu na celkový seznam aplikací kvůli analýze dopadu se zatvářili chytře, ale mysleli si něco o novém scifi filmu. A jelikož organizační program není jen o IT, ale i o oblastech jako přesuny zaměstnanců, účetnictví, controling a hlavně o právních záležitostech (jako zápis do obchodního rejstříku, akcionáři atd.), které jsou navzájem více či méně závislé, muselo vše klapnout k definovanému termínu. Proto jsem oslovil Service Management a dostal celkový seznam poskytovaných SLA který kromě jiného obsahoval i seznam aplikací. Bylo jich cca 120 a postupnými kroky jsme identifikovali 80 opravdu dotčených, u kterých se musely provést změny. Celý program trval skoro dva roky stál nás jedny Vánoce a díky napjatým termínům občas víc času, ale dopadlo to velkým úspěchem.
Další příklad využití SLA byl projekt migrace lokálního datového centra do cloudu (Amazon a Azzure) a s tím spojená i migrace všech aplikací. Díky tomu, že se oddělení Enterprise Architectury stále dlouze a bolestně rodilo použili jsme stejný přístup založený na SLA, respektive seznamu aplikací jako u přecházejícího organizačního projektu, pouze s tím rozdílem, že se jednalo o všech 120 aplikací a služeb a při analýze byl přidán i technický detail nutný pro infrastrukturu a bezpečnost. Projekt opět dopadl úspěšně i díky tomu že se stejným frameworkem založeným na SLA aplikační týmy pracovaly již v předchozím organizačním programu.
Nakonec nelze zapomenou na primární význam SLA, a to poskytovat informace o definovaných parametrech služeb poskytovaným zákazníkům. Ale jak již bylo zmíněno není to zbytečná administrativa požadovaná Service Managementem. Je to dokument, který může poskytnout informace, které se dají využít i v jiných oblastech jako uvedené příklady při řízení změn. Proto je důležitá interakce mezi projekty předávanými do provozu a revizí, anebo definicí nových SLA, protože nikdy nevíte, kdy ty informace budete jako projekťáci potřebovat. Takže stojí za to mít někde na konci vašich projektových tasků i tuto položku.
Zdroje:
- Service Level Agreement
Autor článku
Sedlmajer Michal