Egyedi szoftver vagy kész megoldás (SaaS)?

A Mesterséges Intelligencia Központ Kft. budapesti szoftverfejlesztő cég szerint a kész szoftver (SaaS) elég, ha lefedi a folyamatokat; az egyedi akkor éri meg, ha a működés eltér a szokásostól, vagy a szoftver maga az üzleti előny.

Lényeg: Ha egy kész termék a folyamatok nagy részét fejlesztés nélkül lefedi, és a cég vállalhatja, hogy igazodik hozzá, a kész megoldás a gyorsabb út. Ha a működés eltér attól, amire a kész termékek épülnek, sok rendszert kell összekötni, vagy az adatok és a továbbfejlesztés feletti rendelkezés stratégiai kérdés, az egyedi fejlesztés éri meg. Gyakran a kettő együtt a jó válasz: kész alap, egyedi kiegészítéssel.

Mit jelent az egyedi szoftver, a kész szoftver és a SaaS?

A három fogalom két különböző kérdésre felel: az egyik az, hogy kinek készült a szoftver, a másik az, hogy hogyan jut el a felhasználóhoz.

Egyedi szoftver: egy adott cég igényeire, megrendelésre fejlesztett program. Azt tudja, amit a megrendelő a specifikációban kért, úgy, ahogyan ott dolgoznak, és a továbbfejlesztés irányáról is a megrendelő dönt.
Kész (dobozos) szoftver: sok ügyfélnek készülő termék, amelyet a cég licencel, és jellemzően a saját gépein vagy szerverén telepít és üzemeltet. Beállításokkal alakítható, a működés logikáját azonban a gyártó határozza meg.
SaaS (Software as a Service, szoftver mint szolgáltatás): kész szoftver, amelyet a gyártó a saját felhőjében futtat, a cég pedig előfizetéssel, böngészőből vagy programozási felületen keresztül használja. A programozási felület (API, application programming interface) az a csatlakozási pont, amelyen két program emberi közreműködés nélkül adatot cserél.

Az amerikai Nemzeti Szabványügyi és Technológiai Intézet (NIST) felhőfogalma szerint SaaS esetén a felhasználó a szolgáltató felhőben futó alkalmazását használja, és nem kezeli a mögötte álló infrastruktúrát (a hálózatot, a szervereket, az operációs rendszert, a tárolást), sőt az egyes alkalmazásfunkciókat sem, legfeljebb korlátozott, felhasználószintű beállításokat (NIST SP 800-145). Ez a SaaS ereje és korlátja egyszerre: a gyártó leveszi az üzemeltetés terhét a cég válláról, de azt is ő dönti el, mi változik a termékben, és mikor.

A harmadik út: kész alap, egyedi kiegészítéssel

A döntés ritkán „vagy–vagy”. Sok cégnél az a járható út, hogy a szokásos feladatokra (könyvelés, levelezés, irodai munka) marad a kész termék, és ott készül egyedi fejlesztés, ahol a cég valóban másképp működik, mint a többi. A hibrid megoldás leggyakoribb formái:

Integráció: egyedi program köti össze a kész rendszereket API-n vagy webhookon keresztül, így az adatot nem kell kézzel átmásolni. A webhook olyan automatikus értesítés, amelyet egy rendszer egy esemény bekövetkeztekor küld a másiknak, például amikor új rendelés érkezik.
Egyedi modul: a kész rendszer mellé saját alkalmazás készül arra a folyamatra, amelyet a kész termék nem fed le, például egy sajátos árazási szabályra, egy gyártásütemezésre vagy egy ágazati nyilvántartásra.
Saját felület a kész rendszer fölött: az ügyfelek vagy a terepen dolgozó munkatársak egyszerű, a feladatukra szabott felületet kapnak, a háttérben pedig a kész rendszer dolgozik.

A hibrid út előnye, hogy a cég csak azért fizet fejlesztést, ami valóban egyedi. A hátránya, hogy az egyedi részeknek követniük kell a kész rendszer felületének változásait, ezért az integrációba naplózás és hibajelzés kell, és valakinek gondoskodnia kell a karbantartásáról. A rendszerek összekötéséről és az ismétlődő munka gépesítéséről a Folyamatautomatizálás oldalon írunk.

Döntési szempontok egy táblázatban

Szempont	A kész szoftver (SaaS) felé billen, ha…	Az egyedi fejlesztés felé billen, ha…
Illeszkedés a folyamatokhoz	a folyamat szokásos, és a cég vállalja, hogy a szoftverhez igazodik	a cég eltér a szokásostól, és ezt az eltérést meg akarja tartani
Versenyelőny	a terület nem különbözteti meg a céget a versenytársaktól	a szoftver maga az üzleti előny, vagy annak a hordozója
Integrációk száma	kevés rendszerhez kell kapcsolódni, és van hozzájuk kész összekötő	sok rendszert kell összekötni, vagy nincs hozzájuk kész összekötő
Adatok és kilépés	a gyártó teljes, géppel olvasható exportot ad, és a kilépés feltételei világosak	az adatmodell és a rendszer feletti rendelkezés stratégiai kérdés
Felhasználók és licencmodell	kevés felhasználó és kiszámítható létszám	sok vagy gyorsan bővülő felhasználói kör, ahol a felhasználónkénti díj meghatározó
Indulási sebesség	gyorsan kell működnie, és a kész funkciók elegendők	az indulás kivárhatja a fejlesztést, vagy szakaszosan is indulhat
Ki tartja karban?	nincs saját informatikai kapacitás, és elég a gyártó karbantartása	van, aki üzemelteti: saját csapat vagy szerződött fejlesztő
Adatok helye és megfelelés	a gyártó adattárolási helye és szerződése megfelel az elvárásoknak	az adatnak meghatározott helyen kell maradnia, vagy szigorú szakmai előírás vonatkozik rá

Nem kell minden sorban ugyanarra az oldalra jutni. Ha a szempontok többsége a kész termék felé billen, érdemes azzal indulni. Ha viszont a súlyos sorok (az illeszkedés, a versenyelőny és az integrációk) az egyedi fejlesztés felé mutatnak, ott érdemes mélyebben tervezni, és legalább egy funkciócsoportra konkrét összevetést készíteni.

Mitől függ a teljes birtoklási költség?

A teljes birtoklási költség (angolul total cost of ownership, röviden TCO) a szoftver teljes használati idejére vetített ráfordítás, nemcsak az indulás ára. A két út költségszerkezete eltér, ezért egyetlen év összevetése félrevezető lehet: a tervezett használati időre érdemes nézni.

Kész szoftvernél és SaaS-nál a költséget jellemzően ezek alakítják:

az előfizetés, amely gyakran a felhasználók számával és a választott csomaggal együtt nő;
a kiegészítő modulok és a magasabb csomagok, ha egy szükséges funkció csak ott érhető el;
a bevezetés, a beállítás és a munkatársak betanítása;
az integrációk és a testreszabás, amelyeket gyakran külön partner végez;
a kilépés: az adatok kimentése és átköltöztetése, ha egyszer váltani kell.

Egyedi szoftvernél:

a fejlesztés, amely elsősorban a szoftver funkcionális méretén múlik;
az üzemeltetés: a tárhely, a felügyelet és a biztonsági frissítések;
a karbantartás és a továbbfejlesztés, ahogy a cég igényei változnak;
a tudás megőrzése: dokumentáció és teljes forráskód, hogy a rendszer ne egyetlen emberen múljon.

Az egyedi fejlesztés költsége akkor tervezhető, ha a terjedelmet mérik, nem érzésre becsülik. Mi a fejlesztés funkcionális méretét COSMIC funkciópontban (ISO/IEC 19761) mérjük, és ebből készül az ajánlat és az ütemezés; a módszert az Árazás oldal írja le. Hogy hosszú távon melyik út kerül kevesebbe, az a felhasználók számán, a változások gyakoriságán és az integrációk mennyiségén múlik. Erre nincs általános válasz, csak a konkrét esetre készült számítás.

Gyártói függőség és adathordozhatóság

Gyártói függőségről (angolul vendor lock-in) akkor beszélünk, ha a váltás egy másik termékre olyan nehéz vagy költséges, hogy a cég gyakorlatilag nem tud kilépni. Az oka lehet zárt adatformátum, hiányos export, sok, csak az adott termékhez kötött beállítás vagy egy nehezen felmondható szerződés.

Az Európai Unió adatrendelete (Data Act, az (EU) 2023/2854 rendelet) 2025. szeptember 12-től alkalmazandó, és külön fejezetben szabályozza az adatkezelési szolgáltatások közötti váltást; a preambuluma a SaaS-t is ezek közé sorolja. A rendelet szövege többek között ezt írja elő (ellenőrizve: 2026. október 17.):

A váltás feltételeit írásbeli szerződésben kell rögzíteni, és a váltás megindításához szükséges felmondási idő legfeljebb két hónap lehet (25. cikk).
A váltást kérésre, indokolatlan késedelem nélkül, legfeljebb 30 naptári napos átmeneti időszakon belül kell lehetővé tenni, és ez alatt a szolgáltatásnak tovább kell működnie; ha ez technikailag nem kivitelezhető, a szolgáltató indokolással legfeljebb hét hónapos átmeneti időszakot jelölhet meg (25. cikk).
A szerződésnek tételesen fel kell sorolnia az átvihető adatokat, és legalább 30 naptári napos időszakot kell biztosítania az adatok visszanyerésére (25. cikk).
2027. január 12-től a szolgáltató nem számíthat fel díjat a váltási folyamatért; addig csak csökkentett díjat, amely nem haladhatja meg a váltáshoz közvetlenül kapcsolódó költségeit (29. cikk).

Fontos kivétel, hogy a díjakra vonatkozó szabály és egyes technikai kötelezettségek nem vonatkoznak azokra a szolgáltatásokra, amelyek fő jellemzőit nagyrészt egyetlen ügyfél igényeire szabták, és amelyeket nem kínálnak széles körben (31. cikk). Ha a kész rendszer a cég megbízásából személyes adatokat kezel, az általános adatvédelmi rendelet (GDPR) is kötelezi a szolgáltatót: a szolgáltatás végén az adatkezelő döntése szerint minden személyes adatot töröl vagy visszaad (GDPR, 28. cikk (3) bekezdés g) pont). Ez tájékoztatás, nem jogi tanács.

A jogszabály a feltételeken javít, a kilépést viszont a cégnek kell megterveznie, lehetőleg már a választáskor. Érdemes megnézni:

milyen formátumban adható ki az összes adat, például CSV-ben (vesszővel tagolt szövegfájl), JSON-ban (géppel olvasható, szerkezetes szövegformátum) vagy adatbázis-mentésként, és benne vannak-e a csatolmányok, a megjegyzések és a módosítási napló;
van-e dokumentált API, amelyen az adatok folyamatosan is kinyerhetők;
egy próbaexporttal ellenőrizhető-e, hogy az adatok egy másik rendszerbe betölthetők;
mit mond a szerződés a felmondásról, a váltás díjáról és az adatok törléséről.

Kié a forráskód?

Kész szoftvernél és SaaS-nál a cég használati jogot vásárol: a forráskód a gyártónál marad, és a termék sorsáról, például új funkciókról, árváltozásról vagy a termék megszűnéséről, a gyártó dönt. Ez önmagában nem baj, ha a termék stabil, és az adatok kivihetők.

Egyedi fejlesztésnél a forráskód és a felhasználási jogok kérdését a szerződés rendezi, ezért érdemes kifejezetten rögzíteni, kié a kód, megkapja-e a megrendelő a teljes forráskódot és a dokumentációt, és továbbfejleszthető-e a rendszer más fejlesztővel. A forráskódról és a felhasználási jogokról nálunk is a szerződés rendelkezik. A szerződés további fontos pontjairól a Hogyan válasszunk szoftverfejlesztő céget? cikkben írunk.

Rendszertípusonként más a mérlegelés

A fenti szempontok általánosak, de egy-egy rendszertípusnál más a súlyuk. Vállalatirányítási rendszernél a testreszabás és a frissíthetőség viszonya a döntő kérdés; erről az Egyedi ERP vagy testreszabott kész ERP? cikkben írunk. Ügyfélkezelő rendszernél a sajátos értékesítési folyamat és a felhasználónkénti licenc számít sokat (lásd a Mikor éri meg egyedi CRM-et fejleszteni? cikket). Webáruháznál a bérelt platformok gyors indulása áll szemben a szabad bővíthetőséggel, erről a Webshop: bérelt rendszer vagy egyedi fejlesztés? cikk szól. Az üzleti rendszerek fejlesztéséről általában az Üzleti szoftverek oldalon olvashat.

Döntési ellenőrzőlista

Az alábbi kérdésekre adott válaszok többnyire maguktól kijelölik az utat:

Le tudjuk-e írni a folyamatot olyan részletesen, hogy egy kész termék bemutatóján tételesen ellenőrizzük?
A folyamat mekkora részét fedi le a kész termék beállításokkal, fejlesztés nélkül?
Ez a terület különbözteti meg a céget a versenytársaktól, vagy minden cégnél hasonlóan működik?
Hány rendszerhez kell kapcsolódni, és van-e ezekhez kész, a gyártó által támogatott összekötő?
Hány felhasználó dolgozik majd a rendszerben néhány év múlva, és hogyan változik ezzel az előfizetés?
Teljes, géppel olvasható exportot kapunk-e, és kipróbáltuk-e egy próbaexporttal?
Hol tárolják és hol dolgozzák fel az adatokat, és ez megfelel-e a cég adatvédelmi és szakmai elvárásainak?
Ki üzemelteti és fejleszti tovább a rendszert, és mi történik, ha ez a partner kiesik?
Mennyi idő áll rendelkezésre az indulásig, és indulhat-e a rendszer szakaszosan?

Tipikus hibák

A funkciólisták összevetése a folyamat helyett: két termék ugyanazt a funkciót ígérheti, a különbség abban van, hogyan illeszkedik a cég napi munkájához. Érdemes a saját, valós eseteken végigmenni a bemutatón.
Csak az első év költségének összevetése: az előfizetés a létszámmal nő, az egyedi rendszer üzemeltetése és továbbfejlesztése pedig az évek során jelentkezik.
A kilépés elfelejtése: az adatexportot a választáskor kell ellenőrizni, nem a felmondáskor.
Túl sok testreszabás egy kész termékben: egy ponton túl a sokszorosan testreszabott kész rendszer frissítése több munkával jár, mint egy jól elválasztott egyedi modul karbantartása.
Mindent egyszerre lecserélni: a szakaszos átállás (előbb egy modul, aztán a következő) kisebb kockázat, mint egy nagy, egyszeri váltás.

Gyakori kérdések

Mikor éri meg egyedi szoftvert fejleszteni?

Akkor, ha a cég működése eltér attól, amire a kész termékek épülnek, és ezt az eltérést meg akarja tartani; ha sok rendszert kell összekötni, és nincs hozzájuk kész összekötő; vagy ha a szoftver maga az üzleti előny. Ha egy kész termék a folyamatok nagy részét fejlesztés nélkül lefedi, általában az a gyorsabb út. Ezt az első egyeztetésen meg is mondjuk.

Drágább-e hosszú távon az egyedi szoftver?

Nem feltétlenül, de nem is automatikusan olcsóbb. A kész szoftver előfizetése a felhasználók számával és a csomagokkal együtt nő, az egyedi rendszernél pedig az üzemeltetés és a továbbfejlesztés jelent folyamatos költséget. Hogy melyik kerül kevesebbe, az a tervezett használati időn, a létszámon, az integrációkon és a változások gyakoriságán múlik; ezt a konkrét esetre érdemes kiszámolni.

Mi lesz az adatainkkal, ha lemondjuk a SaaS-t?

Ez elsősorban a szerződésen múlik, ezért már a választáskor érdemes megnézni. Az uniós adatrendelet szerint a szerződésnek tételesen meg kell határoznia az átvihető adatokat, és legalább 30 naptári napot kell biztosítania a kimentésükre; a személyes adatokat pedig a GDPR szerint a szolgáltatás végén az adatkezelő döntése szerint törölni kell vagy vissza kell adni. A gyakorlatban egy próbaexport mutatja meg, mennyire használhatók az adatok egy másik rendszerben.

Lehet a kettőt kombinálni?

Igen, és sok cégnél ez a járható út: a kész rendszer marad a szokásos feladatokra, egyedi integráció köti össze a többi rendszerrel, és egyedi modul készül arra, amiben a cég más. Ennek feltétele, hogy a kész rendszer dokumentált API-n keresztül elérhető legyen.

Kié lesz a forráskód?

Kész szoftvernél és SaaS-nál a forráskód a gyártóé, a cég használati jogot kap. Egyedi fejlesztésnél a forráskódról és a felhasználási jogokról a szerződés rendelkezik, nálunk is.

Hogyan segítünk?

A Mesterséges Intelligencia Központ Kft. egyedi szoftvert fejleszt, és kész rendszereket köt össze. Ahol valódi munkát spórol, mesterséges intelligenciával is dolgozunk: az OpenAI (ChatGPT), az Anthropic (Claude) és a Google (Gemini) nyelvi modelljeit kötjük be a meglévő rendszerekbe. Az első egyeztetés díjmentes, és ilyenkor azt is megmondjuk, ha egy kész termék elég. Ha egyedi fejlesztés kell, a funkcionális méretét COSMIC funkciópontban mérjük, és ebből készül az ajánlat és az ütemezés. Kérésre titoktartási szerződést (NDA) kötünk, és átadás után az üzemeltetést és a karbantartást is vállaljuk. A forráskódról és a felhasználási jogokról a szerződés rendelkezik.

Részletek az Egyedi szoftverfejlesztés oldalon. Ha a saját helyzetükről beszélnének velünk, írjanak nekünk a Kapcsolat oldalon megadott elérhetőségeken.