Az informatikai rendszerek üzembiztonsága ritkán kerül szóba, amíg minden simán megy. Pedig egy átlagos kkv számára egyetlen leállt nap nem csak bosszantó – azonnal pénzben mérhető veszteség: kiesett árbevétel, kárba ment munkaóra, és nem egyszer egy elégedetlen ügyfél, aki máshova fordul.

Miből áll össze egy leállás költsége?

A legkönnyebben látható tétel a kiesett árbevétel: amíg a rendszer nem működik, a megrendelések nem mennek ki, a számlák nem készülnek el, az ügyfelek nem érik el a céget. Ez azonban csak egy tétel a sok közül – egy leállás költsége valójában jóval több helyen csapódik le, mint amire elsőre gondolnánk.

A bérköltség akkor is megy, amikor a kollégák nem tudnak dolgozni. Egy tíz fős csapatnál egy elvesztett nap simán 8-10 munkaóra kárba veszett bérköltséget jelent, függetlenül attól, hogy közben egyetlen tétel sem készült el – a fizetést a hónap végén ugyanúgy ki kell fizetni.

A helyreállítás munkadíja külön tétel. Egy sürgősségi kiszállás vagy hétvégi/esti beavatkozás díja jellemzően magasabb a megszokott óradíjnál, és ha a hiba bonyolultabb, ez könnyen több óráig is eltarthat.

Az adatvesztés és az újrarögzítés költsége akkor jelenik meg, ha a legutóbbi mentés óta keletkezett adatokat (megrendelések, számlák, ügyféladatok) kézzel kell visszapótolni. Minél régebbi a mentés, annál több munkaóra megy el a visszaállításra – és előfordulhat, hogy egy-egy adat véglegesen elveszik.

A szerződéses kötbér akkor üt be, ha a leállás miatt egy vállalt határidőt nem tudunk tartani egy ügyfél felé. Ez a tétel azért különösen veszélyes, mert nem a leállás hosszától, hanem a szerződés szövegétől függ – egy félnapos csúszás is aktiválhat egy fix összegű kötbért.

Az ügyfélvesztés és a reputációs kár a legnehezebben megfogható, de gyakran a legdrágább tétel. Az az ügyfél, aki pont akkor próbálta elérni a céget, amikor nem sikerült neki, könnyen a versenytársat hívja fel helyette – és ez a veszteség sosem jelenik meg egyetlen tételként a könyvelésben, csak hónapokkal később, az elmaradó megrendelésekben.

A helyreállítás utáni torlódás is pénzbe kerül. A kiesett napot valahogy be kell pótolni: ez vagy túlórát jelent (ami plusz bérköltség), vagy azt, hogy a következő projektek csúsznak, ami további elégedetlenséget szülhet.

Végül érdemes számolni egy ritkább, de súlyos tétellel is: ha a leállás adatvesztéssel vagy adatszivárgással is jár, felmerülhet jogi és adatvédelmi kockázat (pl. ügyfeleket érintő személyes adatok esetén), amihez jogi tanácsadás és esetlegesen hatósági eljárás költsége is társulhat.

Hogyan számítsuk ki a saját kockázatunkat?

Vegyünk egy konkrét, hipotetikus példát: egy 12 fős, 120 millió forint éves árbevételű szolgáltató cég.

Az első tétel a kiesett árbevétel. Az éves árbevételt elosztva a munkanapok számával (kb. 250) megkapjuk a napi árbevételt: 120 000 000 / 250 ≈ 480 000 forint. Nem minden megrendelés vesz el véglegesen – egy részük másnap pótolható –, ezért célszerű egy 40-70%-os „valós veszteségi arányt” alkalmazni rá. Ez a cégnél napi 190 000-340 000 forint közötti, véglegesen elveszett árbevételt jelenthet.

A második tétel a kárba ment bérköltség. Ehhez a KSH legfrissebb, 2026. áprilisi adatát érdemes alapul venni, nem az átlagbért – a mediánbér ugyanis a „tipikus” magyar keresetet mutatja, az átlagbért torzító kiugróan magas fizetések nélkül. A bruttó mediánbér 2026 áprilisában 616 000 forint volt. A munkaadói oldalon ehhez jön a szociális hozzájárulási adó (kb. 13%), így a cég számára egy átlagos dolgozó teljes havi bérköltsége kb. 696 000 forint. A 12 fő napi bérköltsége így 696 000 × 12 / 21 munkanap ≈ 398 000 forint. Mivel a kollégák egy része ilyenkor is tud valamilyen pótfeladatot végezni, itt is érdemes egy 50-80%-os arányt számolni: napi 199 000-318 000 forint.

A harmadik tétel a helyreállítás munkadíja. Egy sürgősségi kiszállás óradíja jellemzően 30-50 ezer forint, és a hiba jellegétől függően 4-12 órás munkát is igénybe vehet – ez 120 000-600 000 forint közötti tételt jelent.

Csak ezt a három, könnyen számszerűsíthető tételt összeadva egy átlagos napon már 509 000-1 258 000 forint közötti közvetlen veszteségnél lehetünk – és ebben még nincs benne az adatvesztés pótlása, az esetleges kötbér, és az ügyfélvesztés hosszabb távú hatása, amelyek egy rosszabb esetben simán megduplázhatják ezt az összeget.

A pontos számok cégenként eltérnek, de a logika ugyanaz: vegyük végig a fenti tételeket a saját árbevételünkkel, bérköltségünkkel és szerződéseinkkel, és máris kapunk egy reális képet arról, mekkora az a kockázat, amit egy mentési rendszerrel, redundáns kialakítással vagy support-szerződéssel csökkenthetnénk.

Mitől függ, hogy ez két óra vagy két nap?

Itt jön a csavar: a leállás költsége nem elsősorban a hiba súlyosságától függ, hanem attól, mennyire vagyunk rá felkészülve. Egy meghibásodott merevlemez friss, naponta tesztelt mentéssel fél nap alatt helyreáll. Ugyanaz a hiba mentés nélkül – vagy egy évek óta nem tesztelt mentéssel, ami a gyakorlatban ugyanannyit ér, mint a semmi – simán egy hetes adatrekonstrukcióba torkollik. A support-szerződés reakcióideje hasonlóan döntő tényező: ha a szerződésben napokban mért reakcióidő szerepel, egy reggel bejelentett hiba akár másnapig is várhat a javításra – papíron mindenki betartja a vállalt határidőt, a cég mégis egy teljes munkanapot bukott.

Tévhitek

„Mi kicsi cég vagyunk, nálunk ez nem akkora tétel.” Pont fordítva igaz: egy nagyvállalatnál a leállás költsége sok emberen és sok rendszeren elosztva talán kisebb arányban érződik, egy 5-10 fős cégnél viszont egyetlen nap kiesése a havi kapacitás akár 20-25%-át is jelentheti.

„Az informatikai üzemeltetés egy kiadás, amit lehet csökkenteni, ha jól megy a cég.” Ez egy biztosítás logikája, nem egy szabadon elhagyható tétel – pont akkor látjuk meg a hiányát, amikor a legkevésbé van rá idő.

Mi következik ebből?

A kérdés nem az, hogy lesz-e egyszer leállás – ez egy elég hosszú időtávon statisztikailag majdnem biztos. A kérdés az, hogy ez a cégnél fél napos bosszúság, vagy egy hetes válsághelyzet. Ez utóbbi gyakran kizárólag azon dől el, hogy a mentés, a redundancia és a support-szerződés a baj előtt – és nem utána – kerül szóba.

Ha szeretné tudni, mi a saját kockázata, kérjen IT auditot: abakusz.hu/itaudit