Az egyedi fejlesztésű szoftverek szerepe a közszférában

• Címke: szoftver, Vágujhelyi Ferenc, vitasarok

Összefoglalás

A közintézmények, az egyedi fejlesztési igényeiket magyar szoftver cégek munkájából vagy multinacionális cégek testre szabható "dobozos" megoldásaiból elégíthetik ki. Az első esetben a hozzáadott érték helyben keletkezik, és a hazai IKT szektort erősíti. A második esetben a leszállított és kifizetett érték jelentős része maga a "dobozos" szoftver, a helyi implementáció során, a hazai fejlesztéshez hasonlítva, csekély hozzáadott érték áll elő. Az első esetben a műszaki-támogatási szerződés a közintézmény valós igényeihez igazodik, a szolgáltatási díj helyi szakemberek munkáját fedezi. A második esetben a dobozos termékre gyakorlatilag kötelező a multinacionális céggel támogatási szerződést kötni a szállított megoldás tartós használatához. Egyre gyakoribb, hogy a helyi bevezetés során, helyi partner által előállított termékekre is a multinacionális cég köt támogatási szerződést (pl. egy-két év után elvéve a magyar partnertől ezt a jogot), annak ellenére, hogy a támogatás tárgyát képező hozzáadott értéket helyi partnere állította elő. Ha a gyakorlat fennmarad, a hazai szoftverfejlesztésre fordított források akkor is külföldre kerülnek, ha onnan tényleges fejlesztési szolgáltatás nem érkezik. A jelenség a globális szoftvercégek ügyfeleikre kivetett adójaként működik.

 

Mit tekintsünk egyedi szoftvernek?

A szoftver – a tárgyalt téma szempontjából– olyan szellemi termék, amely a felhasználókat segíti vagy képessé teszi előre specifikált feladatok megoldására. A szoftver a futtatására képes eszközön (hardver: számítógép, telefon, tablet, beágyazott rendszerek stb.) működik. A felhasználás helyén, azaz futtatáskor, gyakorlatilag csak a hardver számára értelmezhető módon jelenik meg, ezért belső működése a felhasználó előtt általában rejtve marad. Ebből fakadóan használója nem képes olyan módosítást (hibajavítást, továbbfejlesztést) végrehajtani rajta, melyre alkotója nem készítette fel. Minden ellenkező törekvéssel szemben az esetek nagyrészében akkor is jelentős informatikai szakértelem szükséges a módosításához, ha a alkotói törekedtek arra, hogy a szoftver minél rugalmasabb legyen, az az a termék minél inkább paraméterek segítségével vezérelhető legyen.

A közszférában, a kutatás-fejlesztési projekteken kívül, nem használnak saját célra fejlesztett, egyedi szoftvereket operációs rendszerként, hardver eszközök működtetésére (driverek) és széles körben használt, szabványos feladatok ellátására (pl. irodai alkalmazások, biztonsági és adatvédelmi rendszerek, informatikai rendszerek felügyelete és menedzsmentje). Egyedi szoftverekre a közigazgatás-specifikus funkciók ellátásához lehet szükség, bár ezen a területen is egyre szélesebb körben kínálnak „dobozos”, azaz nem speciálisan egy ügyfél igényeire szabott terméket. Ilyenkor a fejlesztő előre megalkotja (specifikálja és leprogramozza) a közfeladat ellátása során használt folyamatokat és objektumokat (pl. ügy, ügyfél, irat). Ugyanakkor az ilyen termékre jellemző, hogy minél szélesebb körben használható, annál általánosabb fogalmakkal dolgozik. A jelentős funkcionális területet megcélzó, sok ország jogrendjére illeszthető rendszerek ezért egyre jobban közelítenek az általános célú fejlesztési környezetekhez. Sokszor az ilyen rendszer csak annyiban különbözik az általános programnyelvektől, hogy előre definiált ügyviteli fogalmakat tartalmaz objektumokként. Egy ilyen esetben a munkafolyamat testre szabása, az objektum osztályok tulajdonságainak paraméterezése a programozáshoz hasonló bonyolultságú feladat, az előállt fejlesztési dokumentáció pedig szinte a megvalósított rendszer forráskódjának tekinthető. A felhasználói igények megvalósítása sokszor komplexebb rendszeren történik, mint egy programozási nyelv integrált fejlesztési környezete. Az ilyen esetekben elmosódik a határ a dobozos termék és az egyedi fejlesztésű szoftver között.

 

Az egyedi fejlesztésekhez kellenek-e egyedi szabályok?

A szoftver futtatása a termékben általában nem abban a megjelenési formájában történik, mint a kifejlesztése. A futtatható változat gyakorlatilag nem olvasható, nem módosítható. A termék specifikálása során jellemzően több ezer kérdésben kell döntést hozni, ezért ilyen nagyságrendben kell a fejlesztés tárgyaként előálló forráskódba beépíteni a jellemzőket. A termékkel kapcsolatos elvárások idővel változhatnak: módosul a jogszabályi környezet, kiderülhet, hogy az igények hibásan kerültek meghatározásra, de maga az informatikai környezet is változhat úgy, hogy a forráskódot módosítani kelljen. Ilyenkor ahhoz kell fordulni, aki a fejlesztői környezethez (benne a forráskóddal) hozzáfér. Mivel egyedi igények kielégítéséről beszélünk, a közintézménynek kifejlesztett ilyen rendszer másnak tipikusan nem értékesíthető, azaz a fejlesztés teljes költségét és hasznát is az egyetlen ügyfélnek kell állnia. Erkölcsi értelemben jogosnak tűnik a felvetés, hogy ha a vevő a teljes beruházást állja, úgy annak valamennyi terméke, köztük a forráskód, kerüljön a birtokába, legalább saját célú hasznosításra. A megközelítésnek sajnos vannak buktatói. Az egyik jellemző eset, hogy a fejlesztő olyan korábbi megoldást szerkesztett az egyedi programba, mely önmagában is komoly (a konkrét beruházás értékét jelentősen meghaladó) anyagi vagy erkölcsi értéket képvisel. Ilyen az, amikor pl. valamilyen egyszerű pénzforgalmi feladat megoldásához egy komplett banki számlavezető rendszert szerkesztenek be a megoldásba (forráskódba). Ha ezt a számlavezető rendszert korábban egy konkrét pénzintézetnek fejlesztették, akkor nem tekinthető dobozos terméknek. Fejlesztésének költsége ugyanakkor nagyságrendekkel nagyobb lehetett, mint annak a programnak az ára, melyhez utólag felhasználták. A másik ilyen probléma a termékbe bekerült szellemi alkotások megismerési jogának kérdése. A fejlesztők általában elfogadják, hogy a megrendelő, aki tipikusan nem versenytársuk, a forráskódon és a hozzá tartozó dokumentáción keresztül elvi lehetőségként, kibogarássza az alkalmazott módszert. Ezzel a képességgel egyébként a megrendelő általában nem rendelkezik. Pont ezen képesség hiánya miatt egy hozzáértő fejlesztőt akar majd keresni, ha módosítani kell a programon, de az eredeti szállító azt nem, vagy nem a közintézmény számára elfogadható feltételekkel vállalja. Ilyenkor a megrendelő természetesen nem kíván fejlesztő céggé alakulni, hanem más piaci szereplőt választ. A közbeszerzési szabályok miatt az eredeti szerző együttműködési készsége esetén is kötelezve van pályázat kiírására. Általában igaz, hogy az iparág specifikus „dobozos” eszközök esetén a szellemi alkotások védelme kevésbé merül fel, mivel a fejlesztést jobban jellemzi a paraméterezés fogalma, mint a kódolásé (programozásé). Az ilyen keretrendszert viszont tipikusan nem módosítja fejlesztője, hiszen akkor éppen „dobozossága” szűnne meg, de sokszor olyan fejlesztési platformot kínál hozzá mellyel gyakorlatilag programozható. Ilyenkor az ezen a platformon végzett fejlesztés eredménye tekinthető egyedinek, melyre ugyanúgy érvényesek a fenti kérdések.

 

A probléma tehát összetett. A közszférában működő megrendelő számára elfogadhatatlan kiszolgáltatottságot jelent, ha az egyedi fejlesztés forráskódjához nem férhet hozzá. Ezt tehát elő kell írni. Ha a szállító ennek tudatában végzi a fejlesztést, megoldást találhat a „beszerkesztett termék” és a versenytárs által megszerezhető műszaki titok problémájára. Felhasználhat pl. nyilvánosan, forráskóddal elérhető megoldást és azt szerkeszti be a titokban tartani kívánt saját megoldás helyett. Az ilyen, nyilvánosan elérhető megoldás lehet forráskód nélküli is, ha jól specifikált feladatot old meg és szabványos adatcserét valósít meg a paraméterek és az eredmények átadásánál. Ha a fejlesztő módszertani szabványokat alkalmaz, akkor erősen specifikált részfeladatok esetén saját maga is fejleszthet „dobozos” terméket, melyet mások is használhatnak a forráskód birtoklása nélkül. Az ilyen esetekben mindkét fél számára megfelelő garanciákat nyújthat, ha a forráskódot és a használatához szükséges fejlesztési dokumentációt közjegyzői letétbe helyezik azzal, hogy adott feltételek teljesülése esetén arra a megrendelő (saját célú) hozzáférési és felhasználási jogot szerez.

 

Gazdasági megfontolások

Ha a közszférába tartozó megrendelő (közintézmény) a fenti kérdésekre olyan választ talált, mely nem csökkentette nullára a potenciális pályázók körét, akkor még néhány, a fejlesztés időszakán túlmutató kérdésre is választ kell adnia. A használatba vételt követően az egyedileg kifejlesztett rendszer működése közben nem várt jelenségek fordulhatnak elő. Ne felejtsük el, hogy a rendszer egyedi, a vevő az első és egyetlen felhasználó. Ha a program hibájáról van szó, a szavatosságra vonatkozó szabályokat kell alkalmazni. Ha nem (pl. változó vagy hiányosan felmért körülmények, a vevő által hibásan biztosított működési infrastruktúra, a felhasználói vagy üzemeltetési szakértelem hiánya stb.), akkor igénybe kell venni a fejlesztő segítségét, melyet ki kell fizetni. A pénzügyi tervezhetőség és a közbeszerzési szabályok praktikusan a (műszaki) támogatási (support) szerződések irányába fordítják a feleket. Az ilyen megoldás az anyagi kockázatokat is – a biztosításokhoz hasonlóan – korlátok közé tereli. A tisztán egyedi fejlesztésű termékeket általában közepes méretű helyi cégek végzik. Mind a fejlesztés, mind a support árbevétele hozzájuk kerül, ezután és munkatársaik után maguk fizetik az adókat, járulékokat. A dobozos termékeket általában multinacionális cégek, külföldön fejlesztik, külföldi munkaerővel. Természetesen a support szolgáltatásokkal is ez a helyzet. Minimális helyi erőforrásra van szükség a módosító vagy javító csomagok telepítéséhez. A közintézmény a közpénzt külföldre fizeti ki, melynek egy részéből ezért – a helyi jogszabályok alapján  – külföldön lesz közpénz.

 

Az, hogy milyen megoldást választunk, visszahat a magyar nemzetgazdaság informatikai szegmensére. A multinacionális cégeknek jellemzően van magyar kirendeltségük, esetenként helyi szakemberrel megerősítve. Az ilyen szakember ismeri a terméket, képes a problémák feltárására és megoldására, ha arra a beállítások módosításával lehetősége van. Forráskódja a szoftverre ugyanis nincs! Maga a szakember sem programozó, inkább rendszermérnök, rosszabb esetben átképzett kereskedő. Komplex rendszereknél vannak magyar partnercégek is, de az alaprendszert érintő fejlesztési képességektől őket is távol tartják. A support költségek többnyire opcionálisak, de ez általában csak elvileg jelent tényleges választási lehetőséget. A külföldi fejlesztési központban folyamatosan zajlik a fejlesztés, melyben részben ismert hibákat javítanak ki, részben új funkciókkal ruházzák fel a szoftvert. Idővel a régi verziók támogatása megszűnik. Ha valakinek problémát okoz egy ismert hiba, de nincs támogatási szerződése, újra meg kell vásárolnia a terméket. Egyes cégek "nagylelkűen" megengedik, hogy a supporttal le nem fedett időszak utólagos (listaáron történő) kiegyenlítésével visszamenően folytonosnak tekintsék a támogatási jogviszonyt, így megkímélve az ügyfelet attól, hogy gyakorlatilag ugyanannak a terméknek a hibás verzióját használják. Az újabb és újabb verziókra való átállás többnyire a hardver környezet fokozott erkölcsi amortizációjával jár, hiszen a globális fejlesztési központban – érthetően – az akkor újnak számító hardver és alapszoftver környezetet veszik rendelkezésre állónak. Így ha az ügyfél tényleg csak egy zavaró hibától akar megszabadulni, azaz pontosan azt a funkcionalitást használja, mint az eredetileg megvásárolt verzióban, akkor vagy évekig fizeti a supportot, vagy újra megvásárolja a licencet, de jó eséllyel a hardver és alapszoftver környezetet is frissítenie kell. Így a magyar közszféra gyakorlatilag az érintett cégek adófizetőjévé válik.

 

Az egyedi szoftver fejlesztője persze ugyanúgy próbál support szerződéshez jutni, mint multinacionális társa, de a két eset eltéréseket mutat. Egyrészt az árazása nem globális, azaz azokat az erőforrásokat veszi számításba, melyeket ténylegesen a „terméken tart”. Viszont ha az ügyfél nem köt ilyen szerződést, biztos lehet benne, hogy a programot nem is fejlesztik. Ha ismertté válik egy hiba – supporttal vagy egyedi megrendelésre – a helyi fejlesztő egyedileg kijavítja. Ilyenkor jó eséllyel nem kell új hardver vagy új verziójú operációs rendszer és adatbázis kezelő a termék alá, mivel nem a világon felmerült valamennyi új igényt tartalmazza az új verzió, hanem csak a konkrét hiba javítását. Előfordulhat, hogy ki sem javítják, mert elment a fejlesztő, a cég megszűnt vagy egyszerűen más, jövedelmezőbb munka köti le az erőforrásait? Erre talán nincs is hazai példa, mert az ügyfélkapcsolat, a szoftverhez tartozó szolgáltatások és a támogatás önmagában is piaci érték. Ha a cég esetleg meg is szűnik, a terméket és kompetenciát meg fogja venni valaki, mert az belépő egy számára új piaci területre.

 

A multinacionális megoldásszállításnak van egy gyorsan terjedő szélsőséges példája. Ekkor a dobozos terméket szállító multinacionális cég értékesíti a licencet, kiviszi ennek értékét. Saját hazai képviselete vagy egy magyar partner elvégzi a bevezetéskor szükségessé váló fejlesztéseket, melynek ellenértékét itthon számlázza ki. Ilyenkor a hozzáadott érték itthon adózik, a munka hazai szakembereket tart el. A „dobozos” terméknek, a fent leírt módon „kikényszerített”, de végül is önként vállalt support díja „a szokásos módon” a globális fejlesztési központba távozik. Ott adózik és ott fejleszti az IT szektort. És most figyeljünk! A helyben, helyi cég által később végzett kiegészítő fejlesztés support díja is a multinacionális cég globális fejlesztési központjába megy! Itthoni szakemberek állították elő az értéket, és mégis. Az ideológia az mögötte, hogy a termék további fejlesztésekor majd figyelembe veszik, hogy az adott ügyfélnél milyen programozott megoldást használnak. Ennek nyilván nincs értelme, mert pl. az általános célú programnyelveket is fejlesztik, miközben a rajtuk írt több millió programot nem ismeri az újabb verziót kiadó cég/alapítvány/fejlesztési közösség. Ha ez a tendencia folytatódik, a magyar közszféra egyre több szoftverfejlesztésre szánt forrása áramlik ki az országból, tényleges ellenszolgáltatás nélkül, miközben a hazai IT szektor nem tudja eltartani a szakembereket, akik ezért külföldön keresnek és kapnak munkát. Ebben a rendkívül gyorsan fejlődő szakmában már néhány év is elég lehet ahhoz, hogy a legmodernebb technológiát tapasztalatból ismerő szakemberek eltűnjenek az országból. Innentől kezdve a felsőoktatás is nélkülözni kényszerül őket, megszűntetve a jól képzett utánpótlás lehetőségét is. Ezzel elvesztünk egy olyan műszaki, tudományos és gazdasági képességet, melyre méltán lehettünk büszkék az elmúlt évtizedekben.

Budapest, 2016. március 05. 

Vágujhelyi Ferenc

 

A témához kapcsolódó szakmai észrevételeiket, megjegyzéseiket az alábbi e-mail címen várjuk:
vitasarok@nhit.hu
 
Az észrevételek előzetes moderálást követően kerülnek fel oldalunkra!

NHIT Online Akadémia

Digital Hungary