Mi a költség azután, hogy elkészül? Egy egyedi rendszer három évének tételes kiadásai

Miért marad ki a fenntartás a döntésből

Az ajánlatkérés szinte mindig egyetlen számra összpontosít: mennyibe kerül megcsináltatni. Ez érthető, mert ez az összeg szerepel a beruházási tervben, és ezt kell jóváhagyatni. A rendszer viszont az átadás napjától kezdve fut: egy szerveren, egy adatbázison, külső szolgáltatáshoz kapcsolódva, felhasználói munkamenetekkel. Ezek a tételek attól függetlenül terhelnek havonta, hogy a fejlesztés befejeződött.

Az átadás utáni kiadás három csoportra bontható. Az első a szolgáltatói díj: futtatókörnyezet, adatbázis, tartós tároló, domain, mentés tárhelye. A második a harmadik féltől vásárolt szolgáltatás díja: számlázószolgáltatás, tranzakciós e-mail-küldés, térképszolgáltatás, SMS, gépi tanuláson alapuló szövegfeldolgozás. A harmadik az emberi munka: hibajavítás, biztonsági karbantartás, verziófrissítés, adatmentés visszatöltésének kipróbálása. Az első két csoport számla alapján kiszámítható és előre betervezhető. A meglepetés majdnem mindig a harmadikban keletkezik.

A félreértés forrása ritkán az összeg nagysága. Sokkal gyakrabban a besorolás okozza: a Megrendelő abban a hitben van, hogy amit fizet, az mindent lefed, vagy éppen fordítva, hogy semmi nem jár a szállítás mellé. Ezért kell a szerződésben külön soron szerepelnie a garanciális hibajavításnak és az opcionálisan megvásárolható üzemeltetésnek. Ha ez a két dolog összemosódik, a vita nem elkerülhető, csak elhalasztott: az első olyan bejelentésnél megérkezik, amelynek besorolásában a felek nem értenek egyet.

A tételek soronként (2026. augusztusi árszint)

Az alábbi sávok tájékoztató jellegűek, és szándékosan dátumozottak. A felhőszolgáltatói díjak jellemzően devizában vannak nyilvántartva, a szolgáltatói árlisták évente változnak, a fogyasztásalapú tételek pedig a tényleges terheléstől függnek. A szerződés előtt minden esetben tételes kalkuláció készül a várható felhasználói létszámmal, adatmennyiséggel és külső kapcsolódási pontokkal számolva.

A sávok alsó széle egy egyszerű, néhány felhasználós belső rendszerre igaz, kevés külső kapcsolódással és munkaidős használattal. A felső szél egy több telephelyet kiszolgáló, több külső szolgáltatással összekötött, napi több ezer tranzakciót kezelő rendszerre vonatkozik. A kettő között a különbség nem a szoftver minőségében van, hanem a terhelésben és a kapcsolódási pontok számában.

Két sor érdemel külön magyarázatot. A mentés önmagában olcsó: a tárhely díja néhány ezer forint havonta. Ami valóban pénzbe kerül, az a visszatöltési próba, vagyis amikor a mentésből egy különálló környezetben ténylegesen újra felépül a rendszer, és valaki ellenőrzi, hogy az adat teljes és használható. Az a mentés, amelyet soha nem töltöttek vissza, nem mentés, hanem feltételezés. Évi egy-két próba reális gyakoriság, alkalmanként fél-egy mérnöknap.

A felügyelet szintén félreérthető tétel. Az alapszintje egy automatikus figyelés, amely riaszt, ha a rendszer nem válaszol vagy a hibaarány megugrik. Ez önmagában nem jelent emberi készenlétet. Hogy a riasztás után ki, mikor és milyen határidővel kezd dolgozni, az kizárólag szerződéses vállalás kérdése, és pontosan így, számszerűen kell rögzíteni. Aki számokat mond rá szerződés nélkül, az becslést ad, nem garanciát.

Mi jár a szállítással, és mi az, ami opció

A garanciális hibajavítás azt jelenti, hogy a rendszer a szerződésben és a specifikációban rögzített módon működik, és ha ettől eltér, a szállító díjmentesen javítja. Ennek van kezdete és vége: jellemzően 6–12 hónap az átadástól számítva, a pontos időtartamot pedig a szerződés rögzíti. A garanciális hibajavítás nem megvásárolható szolgáltatás, hanem a szállító szerződéses helytállási kötelezettsége, ezért nem előfizetés kérdése: akkor is fennáll, ha a Megrendelő nem vásárol üzemeltetési csomagot.

A vállalás pontos jogi minősítése — hogy az adott kötelezettség jótállásnak vagy kellékszavatosságnak minősül-e, és ez milyen határidőkkel és bizonyítási renddel jár — szerződésfüggő, és jogi kérdés. A Fabrio nem nyújt jogi tanácsadást; ebben a kérdésben a szerződést előkészítő jogi tanácsadó álláspontja irányadó. Ami a Megrendelő szempontjából gyakorlati követelmény: a hibajavítási kötelezettség tartalma, időtartama és a bejelentés rendje írásban, a szerződés szövegében szerepeljen.

Az üzemeltetés ezzel szemben megvásárolható szolgáltatás. Ahol van saját informatikai csapat, vagy a rendszer üzeme egyszerű, ott a Megrendelő dönthet úgy, hogy nem kéri a csomagot, és a felmerülő teendőt eseti megrendeléssel oldja meg. Ez teljesen legitim út. A választás akkor rossz, ha nem tudatos: ha senki nem felel a frissítésekért és a mentés ellenőrzéséért, a romlás nem azonnal jelentkezik, hanem fokozatosan. Az elmaradt biztonsági frissítés, a soha vissza nem töltött mentés és a felgyűlő apró hibák hatása jellemzően akkor válik láthatóvá, amikor a helyreállítás már önálló, tervezett munka.

A határvonal a gyakorlatban a következő módon húzható meg.

• Garanciális hibajavítás körébe tartozik: a specifikációtól eltérő működés, a hibás számítás, a lefagyó vagy hibára futó felület, a jogosultsági rés, továbbá minden olyan hiba, amely az átadott funkció rendeltetésszerű használatát akadályozza.
• Nem tartozik bele: új igény vagy új funkció, korábban nem szerepelt jelentés, jogszabályváltozás miatti módosítás, új munkatárs betanítása, adatimport egy másik rendszerből, a Megrendelő oldalán történt beállítási hiba.
• Határeset, amelyet a szerződésben előre rendezni kell: ha egy külső szolgáltatás megváltoztatja a saját kapcsolódási felületét, és emiatt kell módosítani. Ez nem a szállító hibája, de nem is a Megrendelő mulasztása. A tisztességes megoldás egy előre nevesített keret erre a célra.
• Nem része a garanciának a szolgáltatói infrastruktúra díja. A szerver és a tárhely számláját akkor is ki kell fizetni, ha a rendszer hibátlanul működik.

A havidíjsávok tartalma

A nyilvános havidíjak azért vannak sávokba osztva, mert a különbség nem a jóindulaton múlik, hanem azon, hogy hány rendszerelemet, hány külső kapcsolódási pontot és mekkora adatmennyiséget kell felügyelni. Az alábbi táblázat azt mutatja, mi indokol egy adott sávot. A verziófrissítés, a biztonsági karbantartás és a mentés ellenőrzésének munkadíja a rendszerüzemeltetési sávok mindegyikében benne van — ezért kerül a hároméves példában a csomagos oszlopban a csomag terhére.

Amit egyik sáv sem tartalmaz automatikusan: az érdemi továbbfejlesztés. A kisebb módosítás — egy mezőnév, egy jogosultsági beállítás, egy jelentésoszlop — a változtatási keretet tartalmazó sávokban, tehát a 200 e Ft-os havidíjtól felfelé, a keret terhére készül; az ez alatti sávokban eseti megrendelés tárgya, óradíjas elszámolással. Egy új modul, egy új integráció vagy egy jelentősebb átalakítás minden sávban külön ajánlat alapján készül. A havidíj tehát mennyiségileg körülhatárolt változtatási keretet fedez. Ha egy ajánlat korlátlan jövőbeli fejlesztést ígér a havidíj terhére, érdemes megkérdezni, milyen mennyiségi korlát tartozik hozzá, és mi történik akkor, ha a megrendelt munka ezt a korlátot meghaladja.

A díjba beépített betanítófelület itt válik pénzben mérhetővé. Ha a rendszer magában hordozza a saját használati leírását, az új munkatárs betanítása jellemzően kevesebb szállítói munkaórát igényel, és a támogatási kérdések egy része a felületen belül megválaszolható. Ez nem jelenti azt, hogy a betanítás díjmentes: a csoportos oktatás, a helyszíni betanítás és az egyedi oktatási anyag a fenti felsorolás szerint továbbra is külön tétel, a havidíjon kívül.

Három év két forgatókönyvben

A nagyságrend egy konkrét eseten mutatható be. Az alapadatok: egyedi belső rendszer 6 millió forintos bevezetési árral, három modullal, két külső kapcsolódással, húsz felhasználóval. Az első évben garanciális hibajavítás jár hozzá. A kérdés az, hogyan alakul a hároméves teljes költség aszerint, hogy a Megrendelő saját erőből üzemelteti, vagy üzemeltetési csomagot vásárol. Az alábbi táblázat mindkét változatot a fenti éves tételekből építi fel, erre az egy rendszerprofilra szűkített értékekkel, három évre összegezve.

A sorok a fenti éves tételeket a következő módon vonják össze. Az „Infrastruktúra, tárolás, mentés és felügyelet” sor a szolgáltatói számlákat fogja egybe: futtatókörnyezet, adatbázis, objektumtár, domain, tanúsítvány, a mentés tárhelye és az automatikus felügyelet díja. Ezeket a számlákat az üzemeltetési csomag nem váltja ki, ezért szerepelnek mindkét oszlopban. A saját üzemű oszlopban ugyanebbe a sorba tartozik a visszatöltési próba évi egy-két alkalmának munkadíja is; a csomagos oszlopban ez a munka a csomag terhére készül, ott tehát a sor csak a szolgáltatói számlákat tartalmazza. A két tartalom közötti különbség a sáv szélességén belül marad, ezért szerepel mindkét oszlopban ugyanaz az összeg — kettős számbavétel nincs benne. A „Harmadik féltől vásárolt szolgáltatás” sor a tranzakciós e-mail-küldés díját is magában foglalja. A hibajavítási sor két évre szól, mert az első évet a garanciális hibajavítás fedi.

A két oszlop között a különbség nem pusztán pénzügyi. A saját üzemű változat olcsóbb, de feltételez egy belső felelőst, aki figyeli a frissítéseket, ellenőrzi a mentést, és tudja, kit kell hívni, ha baj van. Ha nincs ilyen ember, a látszólagos megtakarítás az első komolyabb kiesésnél elveszik.

A táblázat számaiból néhány használható arányszám vezethető le, mindig a 6 millió forintos bevezetési árhoz mérve. Saját üzemben, a sáv alsó végén — zavartalan működés, ritka változtatási igény és kijelölt belső felelős mellett — a visszatérő kiadás évi 0,83 millió forint, vagyis a bevezetési ár nagyjából 14 százaléka. Ugyanennél a rendszernél, a sáv felső végén — nagyobb adatmennyiség, sűrűbb változtatási igény, terheltebb futtatókörnyezet mellett — a visszatérő kiadás évi 2,23 millió forint, azaz körülbelül 37 százalék. Teljes körű üzemeltetési csomaggal — amelyben a hibajavítás és a karbantartás munkadíja is benne van — a visszatérő kiadás évi 2,8–3,5 millió forint, ami a bevezetési ár 47–58 százaléka. Hároméves összegben ez azt jelenti, hogy a teljes költség saját üzemben a bevezetési ár körülbelül 140–212 százaléka, üzemeltetési csomaggal pedig 240–275 százaléka. Ez nem rejtett költség, hanem az üzem ára, és pontosan ezért kell a beruházási döntést hároméves összegre hozni, nem egyetlen számra.

Érdemes ezt összevetni a dobozos rendszerek szokásos arányaival. Ott a licencdíj a teljes ERP-költség 20–30 százaléka, a bevezetés díja a licencdíj 100–200 százaléka, az éves karbantartás pedig a licencdíj 15–22 százaléka. Egy 10 millió forintos licencdíj mellett a bevezetés önmagában 10–20 millió forint, az éves karbantartás pedig 1,5–2,2 millió forint. Ezekkel együtt, a további tételeket — adatmigráció, oktatás, infrastruktúra, több év karbantartása — is beszámítva a teljes ERP-költség 33–50 millió forintra jön ki, amelynek a licencdíj a 20–30 százaléka. A licencmodellben a karbantartási díj a rendszer teljes élettartama alatt visszatér, előfizetéses konstrukcióban pedig maga a licencdíj is folyamatosan terhel. Egyedi fejlesztésnél licencdíj nincs, így a hároméves összeg más szerkezetű: nagyobb hányada egyszeri, kisebb hányada visszatérő. Ez önmagában nem teszi olcsóbbá az egyedi utat — azt jelenti, hogy a két ajánlat csak azonos időtávra és azonos tartalommal összegezve hasonlítható össze.

Mi mozdítja a sávot felfelé és lefelé

A fenti sávok szélessége nem bizonytalanság, hanem valós különbség. Az alábbi tényezők mutatják meg, hogy egy adott rendszer a sáv melyik végéhez kerül közelebb. A tervezési szakaszban ezek többsége még befolyásolható, az átadás után már jóval nehezebben.

Van egy tétel, amely minden másnál erősebben tolja felfelé a költséget: a munkaidőn túli elvárás. Amíg a rendszer hétköznap nyolctól ötig fontos, addig a hiba másnap reggel javítható. Amint éjjel-nappali működés a követelmény, emberi készenlétet kell finanszírozni, és ez nagyságrendileg más díjszint. Ezt a döntést érdemes tudatosan meghozni, nem a bevezetés utáni első éjszakai kiesés hevében.

• Felfelé mozdít: minden további külső integráció, mert nem csak megépíteni kell, hanem karbantartani is, amikor a másik fél változtat.
• Felfelé mozdít: a nagy és gyorsan növő adatmennyiség, különösen a feltöltött irat és a kép, mert a tárolás és a mentés díja ezzel arányosan nő.
• Felfelé mozdít: a munkaidőn túli vagy hétvégi elvárás, mert emberi készenlétet feltételez.
• Felfelé mozdít: a sok, egymástól eltérő jogosultságú felhasználói kör és a több telephely, mert a hibák felderítése és a beállítások karbantartása időigényesebb.
• Lefelé mozdít: a kevés külső kapcsolódási pont. Az a rendszer, amely csak a saját adatbázisával dolgozik, lényegesen olcsóbban tartható fenn.
• Lefelé mozdít: a kiszámítható, munkaidős használat és a stabilizált működés, ahol nincs havi rendszerességű változtatási igény.
• Lefelé mozdít: a beépített betanítófelület és a jó hibaüzenet, mert a felhasználóban felmerülő kérdések egy részét a felületen belül megválaszolja.
• Lefelé mozdít: ha a Megrendelő oldalán van egy kijelölt, hozzáértő kapcsolattartó, aki előszűri a bejelentéseket.

Amikor nem érdemes egyedit fejlesztetni

Az egyedi fejlesztés akkor térül meg, ha a működés valóban eltér a piacon kaphatótól, és ez az eltérés pénzben mérhető. Három esetben viszont határozottan rossz döntés, és ezt érdemes az ajánlatkérés előtt végiggondolni.

Az első: ha a feladatot egy kész, előfizetéses szoftver 90 százalékban lefedi. Egy ilyen szoftver éves díja gyakran kevesebb, mint az egyedi rendszer puszta üzemeltetése, és a fejlesztésért, a frissítésekért és a jogszabálykövetésért a szállító felel. A maradék 10 százalék miatt épített saját rendszer ára ritkán jön vissza. Ilyenkor a helyes lépés az, hogy a kész szoftver köré épül egy kis illesztés vagy automatizálás, ami jellemzően 500 e Ft-os nagyságrend egy folyamatra, nem több milliós rendszerépítés.

A második: ha a működés még nem állt össze. Egy formálódó, félévente átalakuló üzletmenetet nem érdemes szoftverbe önteni, mert a rendszer minden fordulónál átírásra szorul, és a változtatás költsége felemészti a hasznot. Ilyenkor a táblázat, bármilyen kényelmetlen, olcsóbb és gyorsabban alakítható.

A harmadik: ha nincs, aki használja. Egy rendszer, amelyet a napi munkát végző kollégák megkerülnek, teljes veszteség, függetlenül attól, milyen jól van megírva. Ha a bevezetés mellett nincs vezetői elköteleződés és nincs kijelölt belső felelős, jobb elhalasztani.

Végül az ajánlatok összehasonlításáról. Ugyanarra a feladatkörre érkező ajánlatok között többszörös eltérés is előfordulhat, és ez önmagában nem értelmezhető sem drágaságként, sem olcsóságként, mert az ajánlatok szerkezete eltér egymástól. Az összevetés csak akkor ad használható eredményt, ha minden ajánlat ugyanarra az időtávra és ugyanazzal a tartalommal kerül összegzésre: az egyszeri díj, a visszatérő havi vagy éves díj, a licencszerkezet, a felhasználószám szerinti bővülés díja, az adatmigráció, az oktatás és a kilépés feltételei együtt adják ki a valódi számot. Ehhez elegendő egy táblázat, amelyben minden ajánlat ugyanazokat a sorokat tölti ki; ahol egy sor üresen marad, ott nem olcsóbb az ajánlat, csak hiányos. Ez az összehasonlítás akkor is elvégezhető, ha a döntés végül nem a Fabrióra esik.