A régi vállalati szoftverekben az üzletmenet is veszélybe kerülhet

Röviden

• A régi vállalati szoftverek gyakran tovább működnek, mint ameddig a fejlesztőik és az eredeti dokumentáció elérhetők.
• Az elveszett rendszerismeret miatt a karbantartás drágulhat, a rendszercsere pedig hosszú és költséges zsákutcává válhat.
• A vezetésnek előbb a működést és a függőségeket kell feltárnia, majd dönthet a korszerűsítésről vagy a cseréről.

Az első rendszerátvétel egy vállalati menzán, ebéd közben kezdődött. Egy ügyfél segítséget kért, mert egy fontos szoftver mögül eltűntek a fejlesztők. Bodrogközi László, a Neuron Software alapító-tulajdonosa és ügyvezetője először a legjobb szakemberét állította rá a feladatra. A rendszer átvétele sikerült, az ügyfél problémája megoldódott. A következő hasonló felkérésnél azonban már másként döntött. Felismerte, hogy a régi kód megértésével együtt a működés felelősségét is átveszik. Ezért kezdtek olyan módszertant építeni, amely nem egyetlen kiváló fejlesztő tudására támaszkodik. A történetet a DIG-IT Podcast 4. évadának 37. epizódjában idézte fel.

A régi vállalati szoftverek jelentős része éppen azért marad észrevétlen, mert hosszú ideje ellátja a feladatát. A háttérben azonban változnak az emberek, a beszállítók és az üzleti folyamatok. Mire a vezetés felismeri a függőséget, könnyen lehet, hogy már nincs kitől megkérdezni a rendszer működését. A legnagyobb veszteség ilyenkor nem feltétlenül a forráskód eltűnése, hanem a hozzá kapcsolódó üzleti tudás elvesztése. A szoftverátvétel ezért sokkal több karbantartási feladatnál. A vállalatnak vissza kell szereznie az ellenőrzést a működéséhez szükséges tudás, a változtatások és a kockázatok felett. A kérdés nem kizárólag technológiai, hanem vezetői felelősség is.

A régi vállalati szoftverek mögött gyakran eltűnik a tudás

Bodrogközi tapasztalatai szerint a rendszerátvételeknél általában nem teljesen reménytelen a helyzet. Többnyire megvan a forráskód, és jó esetben még a korábbi fejlesztővel is lehet beszélni. A dokumentáció viszont gyakran hiányos vagy elavult. Előfordult olyan átvételük is, amikor a rendelkezésre álló forráskód nem egyezett az utolsó működő változattal. Ekkor a program működéséből kellett visszafejteni a hiányzó részeket. Bodrogközi az adásban elmondta, hogy az átvevő csapatnak ilyenkor újra kell teremtenie a fenntartható működés feltételeit. Ebbe a dokumentáció elkészítése és a korábbi fejlesztőkkel folytatott egyeztetés is beletartozik.

Az elavult rendszerek megértésének nehézsége régóta kutatott probléma. Hajnal Ákos, a Magyar Tudományos Akadémia Számítástechnikai és Automatizálási Kutatóintézetének kutatója, valamint Forgács István, a budapesti 4D Soft Kft. szakembere a régi COBOL-rendszerek elemzését vizsgálta. A Journal of Software: Evolution and Process folyóiratban megjelent tanulmányuk olyan igény szerinti programelemzési eljárást mutatott be, amely kevesebb előzetes feldolgozást igényelhet. A módszer a program megfelelő részeinek elkülönítésével segítheti a hibakeresést és a működés megértését. A szerzők ipari méretű rendszereken szerzett előzetes tapasztalatokat is ismertettek. Ez nem bizonyítja, hogy bármely régi rendszer gyorsan feltérképezhető. Azt viszont megmutatja, hogy a forráskód célzott vizsgálatához önálló szakmai módszerek szükségesek.

A technikai adósság (technical debt) ennél szélesebb probléma. A korábbi fejlesztési kompromisszumok később megnehezíthetik a módosítást, a tesztelést és a biztonságos üzemeltetést. Samantha Thibodeau, az amerikai Marymount University kutatója a Safety and Security Advances folyóiratban 2026-ban megjelent szakirodalmi áttekintésében szervezeti kockázatként vizsgálta a technikai adósságot. Elemzése szerint a hiányos irányítás, a kommunikációs akadályok és a rejtett sérülékenységek egyaránt súlyosbíthatják a problémát. A technikai adósság tehát nem kizárólag a fejlesztők ügye. A vezetés döntései is befolyásolják, hogy a kockázat időben láthatóvá válik-e, vagy észrevétlenül halmozódik tovább.

A stabil működés még nem bizonyítja a biztonságot

Bodrogközi egy pilóta szemléletével magyarázza a megelőzés jelentőségét. Repülőoktatóként azt tartja fontosnak, hogy a pilóta ne kerüljön olyan helyzetbe, amelyből csak rendkívüli teljesítménnyel lehet kijutni. Ugyanezt a gondolkodást alkalmazza a szoftverek fenntartásánál is. Az adásban így fogalmazott: „A repülésben az a kulcs, hogy mindig előtte jársz a repülőgépnek, és nem az események után mész.” Példaként említette, hogy már két megmaradt fejlesztőnél érdemes foglalkozni az utánpótlással és a tudásátadással. Saját felméréseikre hivatkozva különösen kockázatosnak nevezte az utolsó szakemberek elvesztését. A megadott leirat azonban nem tartalmazza az elemzés módszertanát, ezért az időzítéssel kapcsolatos állítása nem kezelhető általános előrejelzésként.

A működő rendszer és a valóban ellenálló rendszer között lényeges különbség van. Egy alkalmazás hosszú ideig hibamentesnek tűnhet, miközben a mentések, a riasztások vagy a helyreállítási eljárások hiányosak. A DIG-IT Podcast üzletmenet-folytonosságról szóló korábbi adásában találó hasonlat hangzott el: „Az, hogy nem égett le a házam, az nem jelenti azt, hogy jó a füstjelzőm.” Ez a régi vállalati szoftverekre is érvényes megfigyelés. A korábbi sikeres üzemeltetés önmagában nem igazolja a helyreállíthatóságot. A vezetésnek ezért a működési kockázatokról is rendszeres képet kell kapnia. A digitális érettség és az IT-üzemeltetés kapcsolatáról szóló DIG-IT-cikk ugyanezt a felelősségi kérdést tárgyalja.

Mórocz Máté a Neuron Software módszertanának fejlődését konkrét időigényekkel érzékeltette. Elmondása szerint a korábban több hónapos elemzési és átadási folyamatot két, egyenként körülbelül húsz munkanapos szakaszra rövidítették. Bizonyos esetekben már négy napon belül meg tudják ítélni az átvétel feltételeit. Az adásban ismertetett számok a cég saját szolgáltatási tapasztalatait tükrözik. Nem függetlenül mért iparági átlagok, és nem jelentenek minden rendszerre vállalható határidőt. Üzleti szempontból mégis fontos a mögöttük álló gondolat. A kiszámítható átvétel csökkentheti a bizonytalanságot, és tervezhetőbbé teheti a felelősség átadását.

A rendszercsere előtt az üzleti folyamatot kell megérteni

A régi rendszer lecserélése sok vezető számára egyszerűbbnek tűnhet, mint további pénzt költeni a fenntartására. Bodrogközi azonban két különböző döntésként kezeli a szoftver átvételét és a későbbi kiváltását. Szerinte a teljes újrafejlesztés is lehet indokolt, de előbb pontosan fel kell tárni az üzleti működést. Az epizódban arra figyelmeztetett, hogy a fejlesztői kapacitás önmagában nem pótolja az üzleti elemzőket. Egy új alkalmazás megírható, de ettől még nem biztos, hogy a régi rendszer valamennyi szükséges feladatát ellátja. A hiányzó folyamatok később újabb fejlesztést és többletköltséget követelhetnek. Ilyenkor a technológiai csere a korábbi üzleti bizonytalanságot is továbbörökítheti.

Ezt a veszélyt egy független kutatás is alátámasztja. Tapani Rinta-Kahila, Esko Penttinen és Kalle Lyytinen a MIS Quarterly folyóiratban 2023-ban megjelent tanulmányukban egy gyártóüzem nehéz rendszercseréjét vizsgálták. A szerzők között a finn Aalto Egyetemhez kötődő kutatók is szerepelnek. Az esettanulmány szerint a szervezeti ellenállás és a rejtett technikai függőségek egymást erősíthetik. A részlegesen sikeres csere újabb technikai adósságot hozhat létre, miközben a régi rendszer továbbra is szükséges marad. Ez nem minden rendszercsere törvényszerű kimenetele. Arra azonban figyelmeztet, hogy az új szoftver bevezetése szervezeti változás is, nem pusztán fejlesztési projekt.

A teljes újraírás ráadásul mérhető műszaki kompromisszumokkal járhat. Emmanuel Nyenah és kutatótársai a Geoscientific Model Development folyóiratban 2025-ben a WaterGAP hidrológiai modell újraprogramozását ismertették. A fejlesztés javította a kód érthetőségét, karbantarthatóságát és továbbfejleszthetőségét. Ugyanakkor a C/C++ nyelvről Pythonra váltás megduplázta a futási időt. A kutatás egy tudományos modellről szól, nem vállalati ügyviteli alkalmazásról. Mégis világossá tesz egy fontos kompromisszumot. A korszerűbb szerkezet nem garantál minden teljesítménymutatóban javulást. A hibás informatikai döntések rejtett költségeiről szóló korábbi DIG-IT-elemzés ezért a rendszercserék értékeléséhez is hasznos szempontokat ad.

A mesterséges intelligencia segíthet megérteni a régi kódot

A mesterséges intelligencia (AI) új lehetőséget teremt a hiányos dokumentációval rendelkező rendszerek vizsgálatára. Samar Othman Alqahtani és Ahmed Ghoneim, két szaúd-arábiai egyetemhez kötődő kutató a 2026-os Applied Sciences-tanulmányban automatizált Java-modernizációs eljárást értékelt. A keretrendszer a szoftverminőséget, az üzleti értéket és a GPT-4 segítségével végzett kódátalakítást kapcsolta össze. Négy nyílt forráskódú rendszer nyolcvan metódusán 93,8 százalékos ellenőrzési megfelelési arányt értek el. A vizsgált minőségi mutató átlagosan 40,28 ponttal javult. Az eredmény biztató, de a vizsgálat korlátozott mintán történt. Nem bizonyítja, hogy az AI önállóan képes biztonságosan korszerűsíteni egy összetett vállalati rendszert.

Az automatizálás lehetőségeit magyar kutatási tapasztalatok is árnyalják. Szőke Gábor a 2017-ben az Acta Cyberneticában megjelent tanulmányában automatikus kódjavítási módszert mutatott be. A megoldást hat szoftverfejlesztő vállalat részvételével, két éven át tesztelték. Öt rendszerben, összesen több mint ötmillió kódsoron azonosítottak és javítottak ezres nagyságrendben problémás kódszerkezeteket. A vizsgálat a gépi tanulás mai eszközei előtt készült, és nem helyettesíti az üzleti követelmények feltárását. Arra viszont jó példa, hogy a karbantartás egyes részei automatizálhatók. A forráskód szerkezeti minősége és a vállalat tényleges üzleti igénye továbbra is két külön vizsgálati szempont.

A mesterséges intelligenciával támogatott, természetes nyelvű utasításokból történő programozás (vibe coding) szintén felmerült a podcastban. Bodrogközi szerint a Neuron Software nagyvállalati ügyfélkörében még nem jellemző, hogy ilyen módon készített alkalmazások támogassák az alapvető üzleti folyamatokat. A beszélgetésben ugyanakkor hangsúlyozták a közös kódbázis, az ellenőrzések és a tesztelés szerepét. A kérdés nem az, hogy ember vagy AI írta-e a programot. Sokkal fontosabb, hogy a szervezet képes-e megérteni, ellenőrizni és biztonságosan módosítani. A kontroll nélküli kód létrehozásának sebessége könnyen meghaladhatja a vállalat ellenőrzési képességét. Ez különösen akkor jelenthet gondot, ha az üzleti folyamatok dokumentációja eleve hiányos.

A tudás visszaszerzése vezetői döntés

A DIG-IT olvasata szerint a régi vállalati szoftverek körüli legfontosabb vezetői kérdés a kontroll visszaszerzése. A vezetésnek először azt kell megértenie, mely folyamatok függnek a rendszertől, és kinél található a működéshez szükséges tudás. Ezután válhat érdemi döntéssé a fenntartás, a fokozatos korszerűsítés vagy a teljes kiváltás. A beszállító kiválasztásakor ezért a vállalt felelősség és a tudásátadás feltételei legalább olyan lényegesek, mint az árajánlat. A feltárás önmagában is értéket teremthet, mert csökkentheti a kiszolgáltatottságot. A robotizáció teljes életciklusának költségeit vizsgáló korábbi cikkünk hasonló döntési problémát mutat be. A beruházás ára csak az egyik tétel, a hosszú távú működtetés feltételeit is ismerni kell.

A Neuron Software történetében a rendszerátvétel végül önálló üzleti képességgé fejlődött. A vendégek beszámolója szerint a vállalat 2025-ben mintegy 1,6 milliárd forintos árbevételt ért el, amely közel kétszerese volt az előző évinek. Bodrogközi ugyanakkor egy kiemelkedően nagy projekt hatására is felhívta a figyelmet. Ezért a növekedés nem tulajdonítható kizárólag a szoftverátvételi szolgáltatásnak. Az adásban elmondott történet inkább azt szemlélteti, hogy a következetesen fejlesztett szakmai módszertan üzleti lehetőséggé válhat. A megrendelő számára azonban nem a szolgáltató növekedése a döntő. Hanem az, hogy a saját rendszere továbbra is üzleti értéket termeljen, és ne váljon egyetlen ember vagy beszállító távozásának túszává.

Bodrogközi az adás végén egy olyan ügyfélről is beszélt, amelynek kritikus helyzetben segítettek. A vállalat korábban már kapott ajánlatot, de csak a baj bekövetkezésekor kérte a segítséget. A Neuron Software az ügyvezető elmondása szerint ekkor sem emelte meg a korábban ajánlott árat. Az eset nem az árazás általános szabályairól szól, hanem a döntések időzítéséről. A feltárt kockázat kezelése békeidőben több választási lehetőséget hagy a vállalatnak. A halogatás viszont könnyen olyan helyzetbe vezethet, amelyben már a működés fenntartása is rendkívüli erőfeszítést igényel. A teljes történet és a szoftverátvétel üzleti dilemmái a DIG-IT Podcast A kód, amit már senki nem ért című adásában hallgathatók meg.

DIG-IT Podcast szerkesztőség - All rights Reserved.