Upravit stránku

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

Tento web využívá cookies

Tento web používá k poskytování služeb, personalizaci reklam a analýze návštěvnosti soubory cookie. Používáním tohoto webu s tím souhlasíte. Zobrazit podrobnosti