Miért számít igazán az IT-sek gyors reagálása? (És mit követelhetsz tőlük!)

Miért számít igazán az IT-sek gyors reagálása? (És mit követelhetsz tőlük!)

A legtöbb cég gondolkodás nélkül írja alá az IT-szolgáltatási szerződéseket. Pedig egy 30 perces válaszidő és egy 8 órás között óriási a különbség – ezres nagyságrendű veszteséget jelenthet. Nézzük meg, mi tesz egy jó SLA-t igazán hasznossá a számodra.

Miért fontosak tényleg az IT-támogatás válaszidői – és mit követelj!

Képzeld el: elromlik valami a cégnél, és csak vársz. Senki sem mozdul. Ez történik, ha nincs rendes szolgáltatási szint szerződésed (SLA). Pedig sok vállalat még csak nem is nézi meg, mit ír a papír.

Láttam már ilyet: teljes rendszert átadnak egy szolgáltatónak, de a részleteket kihagyják. Mint ha az autókulcsot odaadnád valakinek anélkül, hogy tudnád, mikor ér ide. Most elmagyarázom, milyen egy jó SLA – és miért éri meg foglalkozni vele.

Az első lépés, amit mindenki kihagy: hogyan kérj segítséget

Furcsa, de a kapcsolattartás módja dönti el, mennyire gyorsan kapsz választ. Sok SLA ezt titkolja, és te észre sem veszed.

Telefon? Gyorsabb. E-mail? Lassabb. Miért? A telefonon azonnal elmagyarázod a hibát, e-mailnél olvasni kell. Jó szerződés ezt egyértelműen megírja. Ha nem, akkor gyanús.

Vannak automatikus riasztások is. Ezek észlelik a hálózati gondot, mielőtt te észrevennéd. Szuper, ha gyorsan cselekszenek rá. Ha nem, hiába villog a rendszer.

A kulcs: értsd meg, mi a "kritikus" hiba

Ide törik össze a legtöbb SLA: nem határozzák meg, mi számít kritikusnak. Neked a levelezőszerver leállása világvége. Nekik csak egy jegy a sorban.

Okos megoldás: jelöld ki előre a legfontosabb rendszereket "kritikusként". Így tudják: ez nem maradhat. Kritikus esetben 30 percen belül hívjanak fel – ne e-mailt küldjenek –, és maradjanak a dolgon, míg meg nem javul.

Tapasztalatból mondom: egy cég backupját kritikusnak jelölte. Hiba esetén 28 perc alatt hívták őket. Egy másik nem tette, három napig csendben ment a katasztrófa. Tippelj, ki veszített több adatot?

A prioritási piramis: nem minden hiba egyforma

Ez a rész mutatja meg a szolgáltató igazi arcát. Általában lépcsőzetes a rendszer:

Kritikus: megáll a cég. 30 percen belül hívás, óránként frissítés. Javítás: 4 óra cél.

Fontos: komoly gond, de nem totális. Lassú kulcsrendszer vagy kisebb leállás. Első válasz: 2 munkanap. Javítás: 2 nap.

Közepes: idegesítő, de kezelhető. E-mailes jegyek ide kerülnek. Válasz: 1 munkanap. Javítás: max. 5 nap.

Alacsony: várhat. Akár 2 hét is lehet.

Tényleg: a legtöbb jegy közepes vagy alacsony. De baj, ha sürgős hibát e-mail miatt leminősítenek. Ezért számít, hogyan jelzed.

A valóság: mi van, ha beragad a dolog?

Minden SLA-ban van kiskapu a késésekre. Ha rád várnak, vagy szakértő szabadságon van, az idő nem számít. Ez néha jogos – ha te akadsz el, az a te hibád.

De sokan visszaélnek vele. Mindenre azt mondják: "rád vártunk", pedig te gyors voltál. Jó SLA pontosan meghatározza, mi számolható. Plusz: egyeztethetsz határidőket. Ha tudod, hogy kedden lassú vagy, mondd meg előre.

Mit tegyél most ezzel?

Első: olvasd el az SLA-dat. Unalmas, de nyomtasd ki, emeld ki az időket, jegyezd fel a kapcsolataidat.

Másod: sorold fel a kritikus rendszereket, add meg a vészszámokat. Ne gondold, hogy tudják, mi fontos neked.

Harmad: döntsd el a kommunikációt. Telefon sürgősségire, e-mail a többire.

Negyed: tanítsd meg a csapatnak. Kritikus = 30 perc, fontos = 2 óra, közepes = akár hét. Így nem lepődnek meg a nyomtatóhibánál.

Végül: mérd a teljesítményt. Ha késnek, írd fel. Ha ismétlődik, beszélj, mielőtt meghosszabbítod.

A lényeg

Az SLA a szolgáltató ígérete: ennyi idő alatt válaszolunk, így javítunk. A számok nem minden, a tisztaság az. Tudd, mire fizetsz.

Jók egyértelműek: priorizálás, időpontok, betartás. Közepesek dumálnak, rosszabbak ígérnek sokat, de kritikuskor eltűnnek.

Ne kockáztass a rendszereiddel. Szánj rá egy órát most. Meglepődhetsz – vagy kiakadsz a hiányokon. De okosabban döntesz, mint tegnap.

Címkék: ['sla', 'it support', 'network infrastructure', 'service agreements', 'business continuity', 'it security', 'response times']