SLA pro LMS: jak má vypadat a co by měla obsahovat?
SLA je smlouva o garantované úrovni poskytovaných služeb. SLA je u LMS něco jako záchranná síť jelikož jasně stanovuje jaké garance od dodavatele dostanete, kdy a za jakých podmínek.
Dostupnost není totéž co „reakční doba“
V rámci SLA se obvykle potkávají tři různé garance a je dobré je nepřekrývat.
Dostupnost je procento času v měsíci, kdy je služba použitelná pro uživatele. Počítá se bez plánovaných odstávek a je fér předem vypsat, kdy a jak často se tyto odstávky / údržby systému provádí.
Reakční doba znamená, za jak dlouho podpora incident přijme, potvrdí a začne řešit.
A konečně čas odstranění (nebo dočasného obejití problému) říká, za jak dlouho má být kritická závada opravena nebo alespoň stabilizována.
Vyplatí se také pojmenovat priority incidentů (P1–P4) - například:
- P1 = kritická chyba, která kompletně zamezuje využívání systému,
- P2 = chyba, která se týká zásadních funkcionalit systému a ovlivňuje většinu uživatelů systému,
- P3 = chyba, která znesnadňuje využíván systému uživatelům,
- P4 = drobná závada bez většího dopadu na provoz systému.
Jak se dostupnost počítá
Dostupnost systému bývá měřená měsíčně vztahem „100 % mínus neplánované výpadky“. Tento vzorec by měl být jasně definován v rámci každé SLA smlouvy.
Je dobrou praxí, když jsou s dostatečným předstihem oznamovány plánované výpadky či pravidelná okna pro údržbu systému (tzv. maintenance).
Pokud plánujete sezónní špičky v návštěvnosti vzdělávacího systému, vyžádejte si, aby v těchto obdobích probíhaly údržby jen výjimečně a po domluvě.
Kapacita API a garance výkonu
Moderní LMS stojí na integracích. Proto by SLA měla jasně uvádět také limity API (počet požadavků za minutu/hodinu, souběžná spojení), chování při překročení limitu a garance pro asynchronní úlohy (typicky importy a generování reportů).
Pozn.: Pokud platíte „za využití API, počtu dotazů, vytíženost stroje atp.“, chtějte i měsíční výkaz využití, ať Vás měsíční účet nepřekvapí.
Exporty dat a reverzní migrace bez kliček
SLA by měla popsat co, v jaké podobě a jak rychle dokážete z LMS vyexportovat – uživatele, skupiny, výsledky, historii certifikátů, katalog kurzů i metadata. K exportům patří i schéma dat, aby je bylo možné strojově načíst jinde. Pro „co kdyby“ scénáře si nechte zapsat reverzní migraci: dodavatel Vám v přiměřené lhůtě pomůže přenést data do jiného systému a poskytne součinnost.
Doplněním je obnova po havárii: jak často se zálohuje (RPO) a za jak dlouho je služba po výpadku zpět (RTO). Opravdu dobré SLA uvádí i informaci o tom, jak často se testuje obnova systému ze záloh (zda jsou obnovy v případě výpadku vůbec funkční).
Incidenty, komunikace a eskalace
Když se něco stane, rozhoduje kvalita komunikace. Smysluplné SLA stanoví kanály (portál, e-mail, hotline), dostupnost podpory (pracovní dny vs. 24/7 pro incidenty úrovně P1), eskalační kontakty a lhůtu pro zaslání závěrečné (shrnující) informace o tom, co se stalo, proč se to stalo a jak tomu pro příště zamezit.
Drobné písmo a další zlozvyky
Vyloučení z dostupnosti, výjimky a vyšší moc. To bývají místa, kde často dochází k "nejasnostem". Dejte pozor, aby se pod „vyšší moc“ neschovalo vše od problémů na cloudu až pod chybnou integraci samotného LMS.
Opakované porušení garance dostupnosti by mělo v rámci Smlouvy umožňovat odstoupení od smlouvy bez sankce.
Zároveň si pohlídejte, aby dodavatel nemohl jednostranně zhoršit SLA bez dohody; změny a výjimky si vyžádejte písemnou formou.
Jak vyjednávat, aby SLA dávala smysl
Začněte od rizik: nakolik je pro vás vzdělávací systém kritický? Které firemní procesy by výpadek LMS zastavil či zpomalil a jaký by to mělo dopad na váš business? Podle toho nastavte rozsah a reakční doby v rámci SLA. Jiné nároky bude mít klient, který používá LMS jen jako zaměstnanecký benefit a jiné nároky na SLA bude mít nadnárodní vzdělávací agentura.
Nepřeceňujte, ale také nepřeceňujte dostupnosti a garance v rámci smlouvy, ty se totiž přímo odráží ve výsledné ceně služeb.
Dobré SLA uvádí transparentně všechny tři oblasti: KDY je služba k dispozici, JAK HLÁSIT incidenty a JAK RYCHLE se tyto problémy řeší. Když k tomu přidáte jasně popsané limity API a plán reverzní migrace (obnovy ze záloh), získáte SLA, které podrží vaše LMS i v těch "horších dnech".
