Mikor ne készüljön egyedi szoftver — hat helyzet, amelyben kész termék a jobb választás

A döntés egyetlen kérdésen múlik

Az egyedi fejlesztés nagy elköteleződés. Egy egyedi belső rendszer 3 millió forinttól indul, egy egyedi ERP 30 millió forinttól, és mindkettő mellé üzemeltetés társul: havi 100, 200 vagy 300 ezer forint a rendszer méretétől függően, vállalati szinten 600 ezer forinttól. Minden ár nettó. Ekkora tétel mellett a valódi kérdés nem az, hogy jobb-e egy egyedi rendszer egy kész terméknél, hanem az, hogy az adott feladat egyáltalán egyedi-e.

Az elhatárolás egyszerűbb, mint amilyennek látszik. A fejlesztés akkor indokolt, ha a folyamat a vállalat sajátja: ha az árazás, a készletmozgás, a jóváhagyási rend vagy a partneri kapcsolat logikája máshol nem található meg ugyanígy. És akkor rossz döntés, ha a feladat tartalmát jogszabály írja elő, vagy ha a piac ugyanazt a feladatot már tömegesen, kiforrott termékkel megoldotta.

Érdemes hozzátenni: a kész termék sem ingyenes, különösen nagyobb szervezet esetén. Az iparági arány szerint a licencdíj a teljes ERP-költség 20–30 százaléka, a bevezetés 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 licenc mellé tehát ezekkel az arányokkal számolva 10–20 millió forint bevezetés és évi 1,5–2,2 millió forint karbantartás tartozik. A választás nem az „olcsó” és a „drága” között zajlik, hanem arról szól, hogy a továbbfejlesztés és a szabálykövetés terhét ki viseli.

Az alábbi hat helyzet mindegyikénél szerepel az is, mi jön a fejlesztés helyett: az első háromnál egy-egy kész eszköztípus, a negyediknél vizsgálati lépés és az azt kiszolgáló, könnyen átalakítható eszközök, az ötödiknél a szabványosított bevezetésű előfizetéses termék vagy a döntés elhalasztása, a hatodiknál pedig nem termék, hanem vizsgálati lépés, a meglévő eszköz beállításának és használatának felülvizsgálata. Márkanév szándékosan nem szerepel egyikben sem: egy konkrét termék megnevezése olyan szoftverért teremtene minőségi felelősséget, amelyet nem a Fabrio készít, és amelynek a piaca évente változik.

Első helyzet: jogszabálykövető terület

Bérszámfejtés, könyvelés, adóbevallás, munkaügyi nyilvántartás. Ezen a területen a szoftver tartalmát nem a vállalat határozza meg, hanem a mindenkori jogszabály. Az adókulcs, a járulékszabály, a bevallási nyomtatvány szerkezete évente, olykor év közben változik, és a változás nem opcionális.

Egyedi program esetén ez a követés fejlesztési feladattá válik. Minden szabálymódosítás önálló kör: elemzés, kódmódosítás, teszt, kiadás, határidővel és költséggel. A határidőt ilyenkor nem a fejlesztési kapacitás szabja meg, hanem a jogszabály hatálybalépése, tehát a munka akkor sem halasztható, ha a vállalatnál éppen csúcsidőszak van. Egy kész bérszámfejtő vagy könyvelőprogram gyártója ugyanezt a munkát üzletszerűen végzi, és sok felhasználó között osztja el a költségét: a különbség nem a kód minőségében van, hanem abban, hogy hány szereplő fizeti ugyanazt a szabálykövetést.

A másik szempont a kockázat természete. Egy hibásan számolt bér vagy egy hibás bevallás következménye nem szoftverhiba, hanem hatósági és munkajogi kockázat, amelyet a vállalat visel. Az ilyen kockázatot nem érdemes egy fejlesztési szerződés hatókörébe terelni.

Fontos kiírni: ez az írás nem jogi és nem adótanácsadás, a Fabrio pedig nem jogi és nem adótanácsadó, és nem vállal jogszabálykövetési vagy megfelelőségi kompetenciát. Ezekben a kérdésekben a könyvelő, a bérszámfejtő és a jogi tanácsadó álláspontja irányadó. Amit a fejlesztés ezen a területen ésszerűen vállalhat, az az összekötés: a saját nyilvántartásból származó adat gépi átadása a szakosított program felé, hogy ne kézi átgépeléssel kerüljön át.

• Helyette érdemes keresni: dedikált bérszámfejtő program, könyvelőprogram, bevallástámogató modul.
• A szerződésben nézendő pont: a gyártó vállalja-e írásban a jogszabálykövetést és a frissítés határidejét.
• A fejlesztés ésszerű szerepe itt: adatátadás és riportálás, nem a szabálykövető számítás újraírása.

Második helyzet: tömegesen megoldott feladat

Számlázás, levelezés, naptár, fájltárolás, videóhívás, egyszerű elektronikus aláírás, ügyfélszolgálati jegykezelés. Ezekre a feladatokra több tucat kiforrott, sok éve karbantartott termék létezik, jellemzően felhasználónkénti előfizetéses díjszabással. Ezeknek a termékeknek a funkciólistája évek alatt, sok felhasználói visszajelzésből állt össze; ennyi használati helyzetet egy induló egyedi fejlesztés nem tud rövid idő alatt lefedni.

Az összevetés iránya egyértelmű. Egy egyedi számlázómodul megírása önálló fejlesztési feladat, és az elkészülte után a karbantartás, a formátumváltás és a hibajavítás is a Megrendelőt terheli, évről évre. Ugyanez a funkció előfizetéssel, gyártói felelősséggel érhető el, és az előfizetés díja lényegesen kisebb tétel, mint a saját változat megírása és többéves karbantartása. Konkrét piaci díjszabás itt szándékosan nem szerepel: a csomagok és az árak termékenként és évente változnak, ellenőrizhető választ az adott gyártó aktuális árlistája ad.

A valódi megtakarítás nem ott keletkezik, hogy ezek a funkciók saját kódban készülnek el, hanem ott, hogy a meglévő nyilvántartás és a piaci szolgáltatás között megszűnik a kézi átgépelés. A Fabrio saját gyakorlata is ez: a számlázás egy piaci számlázószolgáltatás gépi kapcsolatán keresztül történik, nem újraírt számlázómotorral. Az elektronikus számla hatósági továbbítása is ezen a szolgáltatáson keresztül, közvetve valósul meg; saját hatósági adatszolgáltatási kapcsolat nem tartozik a vállalt körbe.

Az integráció ára ehhez mérhető: egy folyamat gépi összekötése 500 ezer forinttól, több folyamat együtt 2 millió forinttól indul, nettó. Összevetésül egy egyedi belső rendszer 3 millió forinttól kezdődik, havi 100 ezer forinttól induló üzemeltetéssel. Az összekötés tehát a saját árlistánk tételei szerint is alacsonyabb kiindulási tétel, mint egy piaci termék funkciójának újraírása és többéves karbantartása.

• Helyette érdemes keresni: előfizetéses számlázóprogram, levelező- és dokumentumcsomag, jegykezelő rendszer, elektronikus aláírási szolgáltatás.
• A fejlesztés ésszerű szerepe itt: a saját nyilvántartás és a piaci szolgáltatás gépi összekötése.

Harmadik és negyedik helyzet: a kis működés és a mozgó folyamat

A harmadik helyzet a néhány fős működés. A szoftver haszna két forrásból származik: az ismétlésből és a koordinációból. Ha öten dolgoznak egy folyamatban, és a szükséges tudás még elfér néhány fejben, akkor a koordináció költsége alacsony, a rendszernek pedig alig van miből megtérülnie. A küszöb nem a létszám önmagában, hanem az ismétlésszám: ha egy művelet havonta húszszor fordul elő és alkalmanként öt percet vesz igénybe, az évi húsz óra.

Ezt a húsz órát érdemes pénzben is kifejezni. Bármilyen reális belső óraköltséggel számolva az éves értéke jóval elmarad attól, amibe egy 3 millió forinttól induló rendszer bekerülése és a hozzá tartozó, havi 100 ezer forinttól kezdődő üzemeltetés kerül: a megtérülés ebben a nagyságrendben nem jön ki, még akkor sem, ha a művelet kellemetlen. A számítás iránya minden esetben ugyanez: a felszabaduló idő éves értéke áll szemben a bekerüléssel és az éves üzemeltetési díjjal.

Ilyenkor a mérethez illő eszköz a helyes válasz: jól felépített táblázat rögzített oszlopszerkezettel, egy előfizetéses feladatkezelő, közös naptár, megosztott dokumentumtár. Ez nem alacsonyabb rendű megoldás. A táblázatkezelő ott válik problémává, ahol egyszerre többen írják, ahol a történet visszakereshetősége számít, vagy ahol a hibás cella pénzben mérhető kárt okoz — addig viszont pontosan megfelelő eszköz.

A negyedik helyzet a kiforratlan vagy hetente változó folyamat. A szoftver természete az, hogy rögzíti a döntést: ha egy lépés sorrendje kódba kerül, a megváltoztatása fejlesztési kör lesz, egyeztetéssel és átfutási idővel. Egy még alakuló működésnél ez azt jelenti, hogy a rendszer a bevezetés hónapjában már elavult.

Ilyenkor a hasznos lépés a mérés. Három–hat hónapon át érdemes a folyamatot kézzel vagy könnyen átalakítható eszközzel futtatni, és közben írásban rögzíteni a lépést, a kivételt, a döntési pontot, valamint azt, hogy hány esetben tért el a gyakorlat a leírástól. A mérés eszköze itt is megnevezhető: előfizetéses feladatkezelő a lépések követésére, űrlappal töltött és táblázatban vezetett rögzítés az adatokra, valamint egy verziózott folyamatleíró dokumentum, amelyben a módosítás dátummal együtt látszik. Mindhárom átalakítható egy délelőtt alatt, ezért nem jelent külön költséget, ha a folyamat közben változik.

Ha fél év múlva a leírás nagyjából megáll, akkor van mit fejleszteni. Lehetséges kimenet az is, hogy a mérés végén nem fejlesztés indul, hanem maga a folyamat egyszerűsödik: a leírás készítése közben derül ki, hogy egy lépés elhagyható vagy összevonható. Ez is teljes értékű eredmény.

• A harmadik helyzetben helyette érdemes keresni: rögzített oszlopszerkezetű táblázat, előfizetéses feladatkezelő, közös naptár, megosztott dokumentumtár.
• A negyedik helyzetben helyette érdemes keresni: előfizetéses feladatkezelő, űrlappal töltött és táblázatban vezetett rögzítés, verziózott folyamatleíró dokumentum.
• A mérés eredménye mindkét esetben írásos folyamatleírás, amely fejlesztés nélkül is használható dokumentum.

Ötödik és hatodik helyzet: a hiányzó gazda és a puszta elégedetlenség

Az ötödik helyzet a hiányzó belső gazda. Egy egyedi rendszer bevezetése a Megrendelő oldalán is munka: döntés a szabályról és a kivételről, törzsadat-tisztítás, adatmigráció, tesztelés, betanulás, majd a régi gyakorlat lezárása. Ehhez kell egy megnevezett személy, aki dönteni tud a saját területén, és akinek erre valóban van ideje — nem többletfeladatként, a nap végére halasztva. Reális igény heti néhány óra a projekt teljes hossza alatt, az élesítés hetében ennél több.

Ha ilyen személy nincs, a következmény a dolog természetéből adódik: a szabályokról nincs, aki döntsön, és a régi gyakorlat lezárását nincs, aki kimondja. A rendszer így elkészül ugyan, a korábbi munkamenet viszont mellette tovább él, és fél év múlva két nyilvántartás létezik egy helyett. Ez nem a szoftveren múlik, és nem javítható több fejlesztéssel. Ha a gazda nem jelölhető ki, a helyes döntés a fejlesztés elhalasztása, vagy olyan kész termék választása, amelynél a bevezetés a szolgáltató oldalán szabványosított.

A hatodik helyzet a puszta elégedetlenség egy meglévő eszközzel. Az az állítás, hogy „a jelenlegi rendszer rossz”, önmagában nem indok a cserére, mert nem tartalmaz mérhető információt. Az elégedetlenség mögött beállítási vagy betanítási kérdés is állhat, nem feltétlenül termékhiba: bekapcsolatlan modul, rosszul felvett törzsadat, elmaradt oktatás, egyetlen rossz jogosultsági beállítás. Amíg ezek nincsenek kizárva, a csere ugyanazt a helyzetet hozhatja vissza egy másik termékkel.

Csere előtt érdemes végigvenni néhány konkrét kérdést: melyik az a három művelet, amely nevesítve lassú, és mennyi időt vesz igénybe; a hiba a szoftverben van vagy a beállításban; kapott-e a csapat érdemi oktatást a bevezetéskor; van-e megvásárolt, de használatba nem vett funkció; szólt-e valaki a gyártónak vagy a viszonteladónak. Egy több milliós csere nem oldja meg azt, amit két nap oktatás megoldana, viszont ugyanoda vezet a következő rendszerrel is.

• Az ötödik helyzetben helyette érdemes keresni: olyan előfizetéses termék, amelynél a bevezetés a szolgáltató oldalán szabványosított, vagy a döntés elhalasztása, amíg a belső gazda kijelölhető.
• A hatodik helyzetben helyette érdemes keresni: a beállítás felülvizsgálata, gyártói vagy viszonteladói támogatás, oktatási csomag, a megvásárolt, de használatba nem vett modulok bekapcsolása.
• Csere vagy fejlesztés csak akkor indokolt, ha ezek után is marad nevesített, időben vagy pénzben mérhető hiányosság.

Mikor viszont indokolt az egyedi út

Az egyedi fejlesztésnek van jól körülhatárolható helye. Az ide tartozó eseteknek közös jellemzőjük, hogy a vállalat működése nem véletlenül tér el a piaci termék logikájától: az eltérés maga az érték, és a kész termékben kivételként, kerülőúton vagy sehogy sem kezelhető.

A következő igények esetén lehet a saját rendszer többéves távon olcsóbb, mint a kész termék folyamatos testreszabása és kivételkezelése:

Még ezekben az esetekben is érdemes először megvizsgálni, hogy egy kész termék testreszabása vagy bővítménye nem elegendő-e. Az egyedi fejlesztés akkor nyer, ha az igény tartós, ha a folyamat naponta sokszor fut, és ha a vállalat a következő öt évben is ugyanezen az elven kíván dolgozni.

• Több cég vagy több telephely működik egy telepítésen, egymástól elkülönített adattal és külön jogosultsággal.
• A saját árazási vagy önköltségalapú kalkuláció a versenyhelyzet része, és nem fér bele egy kész termék árlistalogikájába.
• Saját készlet- vagy raktárlogika él, például vonalkódos azonosítással, a szokásostól eltérő kiszerelési vagy foglalási renddel.
• Ugyanaz az adat kettőnél több rendszerbe kerül be kézzel, és az érintett folyamatok annyira összefonódnak, hogy a pontonkénti összekötés helyett közös nyilvántartás a kezelhető megoldás.
• A jogosultságnak cégenként és szerepkörönként állíthatónak kell lennie, mert a kész termék merev szerepkörkiosztása nem fedi le a valós felelősséget.
• Állapotalapú munkafolyamat működik, ahol a lépés sorrendje, a jóváhagyás rendje és a visszaléptetés szabálya a vállalat sajátja.

A döntés mérésből jön, nem érzésből

A fenti hat helyzet szétválasztása néhány mérhető adaton múlik, és ezek a legtöbb vállalatnál két-három hét alatt összegyűjthetők. Nem szükséges hozzá külső szereplő; a mérés önállóan is elvégezhető, és a végeredménye akkor is hasznos, ha soha nem indul fejlesztés.

Az ajánlatkérésnél érdemes számolni azzal, hogy ugyanarra a feladatra kapott ajánlatok ára többszörösen eltérhet egymástól. Ennek oka nem elsősorban az árazás, hanem az, hogy pontos igényleírás nélkül minden ajánlatadó mást ért ugyanazon a feladaton: eltérő funkciókörre, adatmigrációra, integrációra és üzemeltetési tartalomra ad árat. Összehasonlítható ár csak azonos, írásba foglalt igényleírásra kérhető, ezért az igényleírás elkészítése a legolcsóbb lépés az egész folyamatban.

A fizetési szerkezet szintén a kockázat megosztásáról szól. Egymillió forint alatti projekt esetén 50/50 a bontás, fölötte 30 százalék előleg, mérföldkövekhez kötött részteljesítés és 20 százalék átadáskor. Ha egy ajánlat teljes összeget kér előre, vagy nem tartalmaz mérföldkövet, az önmagában is mérlegelendő jelzés.

A felmérés díja is ismert nagyságrend: weboldalaudit 200 ezer forint, rendszer- és folyamataudit 300–500 ezer forint, mindkettő nettó, és mindkettő díja beszámít a későbbi projekt árába. Ha a felmérés arra jut, hogy nem szükséges fejlesztés, az sem elveszett összeg: egy 300 ezer forintos vizsgálat ilyenkor egy több milliós, rossz irányú döntést előz meg.