Az SLA nem papír a fiókban — hanem a céged IT-biztonsági öve.

A legtöbb KKV-vezető találkozott már az „SLA" kifejezéssel. A szerződésben ott van, kipipálták — aztán amikor tényleg leáll valami, kiderül, hogy senki nem érti pontosan, mit vállalt a másik fél. „Gyors válaszidő" — de mennyi az? „Prémium támogatás" — de mi történik éjjel? „Garantált rendelkezésre állás" — de kinek a felelőssége, ha mégsem?

A gond nem az, hogy nincs SLA. A gond az, hogy rossz SLA van — vagy jó SLA, rosszul értve. Ez a cikk segít, hogy vezetőként átlásd: mit kell kérned, mire figyelj, és milyen hibákat kerülj el.

Három fogalom, amit vezetőként értened kell

Az SLA-k világa tele van szakkifejezésekkel — de ha ezt a hármat tisztán látod, a szerződés többi részét is könnyebben átlátod.

Válaszidő vs. megoldási idő

Ez a leggyakoribb félreértés. A válaszidő azt jelenti, hogy az IT-szolgáltató mennyi időn belül reagál a bejelentésedre — felveszi a telefont, visszaír, rögzíti a hibajegyet. Nem azt jelenti, hogy megoldotta a problémát.

A megoldási idő az, ami tényleg számít: ennyi idő alatt áll helyre a működés. Lehet, hogy a válasz öt percen belül jön — de a megoldás órákat vesz igénybe, mert alkatrészre kell várni, vagy a hiba összetettebb.

Ha a szerződésben csak „válaszidő" szerepel megoldási idő nélkül — a szolgáltató technikailag teljesít, ha visszaír, és utána akár napokig nem történik semmi. Ezt neked kell kérned, hogy legyen benne mindkettő.

Kritikus vs. nem kritikus

Nem minden hiba egyforma. Ha a teljes levelezés áll, az nem ugyanaz, mint ha egy kolléga nyomtatója akadozik. Egy jó SLA-ban prioritási szintek vannak definiálva — és mindegyikhez más válaszidő és megoldási cél tartozik.

Ha nincs prioritási rendszer, akkor minden bejelentés „sorban áll" — és a kritikus hiba ugyanúgy vár, mint egy apróság. Ez állásidő-órákba kerülhet.

Rendelkezésre állás — mit jelent és mit nem

Sokan gondolják, hogy a „rendelkezésre állás" azt jelenti: bármikor hívhatsz, és azonnal segítenek. Valójában a rendelkezésre állás azt jelzi, a rendszer az idő hány százalékában működik a vállalt időszakon belül.

Ami fontos: a rendelkezésre állási százalék önmagában keveset mond, ha nincs mellette definiálva, hogy mi számít kiesésnek, és mi történik, ha nem teljesül. Kérdezd meg: a vállalás munkaidőre vagy nonstop vonatkozik? Mert egy hétvégi leállás simán „belefér" egy munkaidős SLA-ba — de a te ügyfeled ettől még nem kap választ hétfő előtt.

Öt tipikus SLA-hiba, amit KKV-k elkövetnek

Az alábbi hibák nem ritkák — sőt, a legtöbb kisvállalkozás legalább kettőt elkövet belőlük. Az a baj, hogy ezek nem a szerződéskötéskor fájnak, hanem az első komolyabb leállásnál.

1. Csak „majd jövünk" ígéret van, nincs konkrét vállalás

A szerződésben „gyors reakció" vagy „rövid válaszidő" szerepel — de sehol nincs leírva, hogy ez mit jelent órában mérve. Amíg nincs gond, ez nem tűnik fel. Amikor viszont áll a rendszer, és a szolgáltató másnap ér rá, nincs mire hivatkozni.

  • Következmény: nincs számonkérhetőség — a szolgáltató „teljesít", bármikor is reagál.
  • Mit kérj helyette: órában meghatározott válaszidőt és megoldási célt, prioritási szintenként külön-külön.

2. Nincs prioritási rendszer

Minden bejelentés egyforma — a szerver leállása és egy apró szoftverkérdés ugyanolyan sorban áll. Ha nincs meghatározva, hogy mi számít kritikusnak és mi alacsony prioritásúnak, a szolgáltató nem tud — és nem is köteles — különbséget tenni.

  • Következmény: a valóban sürgős problémák elvesznek a rutinfeladatok között, és a leállás költsége megsokszorozódik.
  • Mit kérj helyette: legalább három prioritási szintet (kritikus, közepes, alacsony), mindegyikhez saját válaszidővel és megoldási céllal.

3. Nincs kommunikációs elvárás

A szolgáltató elkezdi a javítást — de te nem tudsz róla semmit. Nincs státusz update, nincs visszajelzés, nincs várható idő. Te csak vársz, a csapatod kérdez, te pedig nem tudsz válaszolni. Ez nemcsak bosszantó — ez bizalomvesztés, ami befelé és kifelé is hat.

  • Következmény: nem tudsz tervezni, nem tudsz dönteni, és az ügyfeleidnek sem tudsz mondani semmit.
  • Mit kérj helyette: meghatározott kommunikációs ritmust — kritikus hibánál óránkénti, alacsonyabb prioritásnál napi vagy heti státusz.
Nem tudod, mennyire véd a jelenlegi szerződésed?
Egy gyors IT-állapotfelmérés nem csak a rendszert nézi meg — hanem azt is, hogy az SLA-d valóban lefedi-e a kockázataidat.

4. Nincs helyettesítés — single point of failure

Van egy IT-s, aki „mindig kéznél van". De mi történik, ha szabadságon van, beteg, vagy egyszerűen nem elérhető? Ha az SLA-ban nincs helyettesítési rend, akkor a szolgáltatód sebezhetőségéből a te céged sebezhetősége lesz.

  • Következmény: egyetlen ember kiesése napokig tartó vákuumot okozhat — pont akkor, amikor a legnagyobb szükség lenne a támogatásra.
  • Mit kérj helyette: írásos helyettesítési rendet, csapatalapú supportot, és konkrét elérhetőségeket több személyre.

5. Az SLA csak munkaidőben értelmezett — miközben a leállás nem kérdez

A legtöbb alap SLA hétköznap, munkaidőben érvényes. Ez rendben van — amíg a szervered is csak munkaidőben áll le. A valóságban a leállások gyakran hétvégén, éjszaka, vagy ünnepnapon történnek. Ha az SLA-d nem fedi le ezeket az időszakokat, a legkritikusabb helyzetben állsz védelem nélkül.

  • Következmény: hétvégi leállás esetén hétfőig senki nem foglalkozik a problémával — miközben te ügyfeleket veszítesz.
  • Mit kérj helyette: legalább a kritikus hibákra vonatkozó, munkaidőn kívüli elérhetőséget. Ha a céged termelése vagy ügyfélszolgálata hétvégén is fut, a professzionális IT-üzemeltetés kiterjesztett elérhetőséget is tartalmaz.

Vezetői checklist: tíz kérdés, amit tegyél fel az SLA-ddal kapcsolatban

Nem kell IT-szakértőnek lenned ahhoz, hogy megítéld a szerződésed minőségét. Ha az alábbi kérdések közül háromra sem tudsz egyértelmű „igen"-t mondani, ideje újratárgyalni:

  • Van írásban rögzített válaszidő — órában, nem szavakban?
  • A válaszidő mellett megoldási idő is szerepel a szerződésben?
  • Definiálva vannak a prioritási szintek, és te is ismered őket?
  • Tudod, hogy munkaidőn kívül mi történik kritikus hiba esetén?
  • Van rendszeres státuszjelentés — vagy csak akkor hallasz az IT-ről, ha baj van?
  • Van helyettesítés, ha az elsődleges kapcsolattartó nem elérhető?
  • Tudod, hol és hogyan kell bejelentened a hibát (telefon, email, ticketrendszer)?
  • Kapsz rendszeres — összefoglalót arról, hogy a szolgáltató teljesítette-e az SLA-t?
  • Van meghatározva, mi történik, ha az SLA nem teljesül (kompenzáció, eszkaláció)?
  • Az SLA-d friss — az utolsó évben volt felülvizsgálva, és tükrözi a jelenlegi rendszered?
⚠️ Ha a fenti kérdések többségére nem tudsz válaszolni — az nem szégyen. De a következő leállásnál már nem a szolgáltatód felelőssége lesz, hanem a tiéd, hogy nem kérdeztél rá időben. Az SLA proaktív eszköz — használd úgy.

Az SLA nem papír — hanem a céged biztonsági öve

Nem azért van, hogy a fiókban legyen. Hanem azért, hogy amikor valami elromlik — és előbb-utóbb elromlik valami — legyen egy világos keret: ki mit csinál, mennyi időn belül, és mi történik, ha nem sikerül.

A jó SLA nem bonyolult. Nem kell jogi végzettség hozzá. De igenis kell, hogy értsd, amit aláírsz — mert a leállás költségét nem a szolgáltató fizeti, hanem a céged.

Nem biztos, hogy az SLA-d véd

Kérj egy rövid, kötelezettségmentes IT-állapotfelmérést — megnézzük, hogy a jelenlegi szerződésed és rendszered valóban fedezi-e a kockázataidat.

Állapotfelmérés kérése

Kapcsolódó cikkek: