Egyedi szoftver fejlesztés ára

Az egyedi szoftver fejlesztés árát nem lehet megbízhatóan egyetlen fix összeggel megadni. Egy néhány funkcióból álló belső alkalmazás és egy több részleget kiszolgáló, külső rendszerekkel összekapcsolt vállalati megoldás fejlesztési igénye között nagyságrendi különbség lehet.

A költséget elsősorban az határozza meg, mekkora problémát kell megoldania a rendszernek, hány üzleti folyamatot kezel, milyen funkciókat kell megvalósítani, milyen más rendszerekkel kommunikál, és milyen megbízhatósági, biztonsági vagy teljesítménybeli követelményeknek kell megfelelnie.

Éppen ezért egy egyedi szoftverfejlesztési projekt esetében az érdemi árajánlat előtt először a feladatot kell körülhatárolni. Minél több a nyitott kérdés, annál nagyobb bizonytalanság kerül az idő- és költségbecslésbe.

Miért nincs általános árlista az egyedi szoftverekre?

Kész szoftvernél egy már létező terméket vásárolunk vagy fizetünk elő rá. Egyedi fejlesztésnél viszont magának a megoldásnak a megtervezése és elkészítése is része a projektnek. Ezért félrevezető lenne azt mondani, hogy egy CRM, ügyviteli rendszer vagy belső adminisztrációs alkalmazás ennyibe vagy annyiba kerül. Két látszólag hasonló rendszer mögött egészen eltérő követelmények lehetnek.

Egy egyszerű ügyfélkezelőben például elegendő lehet a cégek, kapcsolattartók és feladatok nyilvántartása. Egy másik vállalkozásnak ugyanebben a rendszerben szüksége lehet jogosultsági szintekre, automatikus értesítésekre, ajánlatkezelésre, dokumentumokra, kimutatásokra, számlázási kapcsolatra és külső API-kra is.

Már ez a különbség jól mutatja, miért lehet egy vállalkozásra szabott szoftver költsége csak a követelmények ismeretében becsülhető érdemben.

Az első nagy árképző tényező a projekt terjedelme

A fejlesztés költségére közvetlenül hat, hogy pontosan mi kerül bele az első verzióba. A projekt terjedelmét – vagyis a scope-ot – nem pusztán a funkciók száma határozza meg. Egyetlen funkció mögött is lehet jelentős fejlesztési munka.

Vegyünk egy egyszerűnek tűnő példát: „a felhasználó tölthessen fel dokumentumokat”. Ehhez rögtön több kérdés kapcsolódik. Milyen fájlokat lehet feltölteni? Mekkora lehet a maximális méret? Ki fér hozzájuk? Szükséges verziókezelés? Törölhetők? Naplózni kell a műveleteket? Kell keresés? Hol tároljuk a fájlokat? Mi történjen sikertelen feltöltéskor?

A funkció egyetlen mondatban leírható, a megvalósítás viszont már több technikai és üzleti döntést igényel. Ezért a fejlesztési költség becslésénél nem érdemes kizárólag funkciókat számolni. A mögöttük lévő működést kell feltárni.

Minél bizonytalanabbak az igények, annál bizonytalanabb az ár

Az egyik leggyakoribb probléma, amikor már a projekt elején pontos árat szeretnénk kapni egy még pontatlanul meghatározott rendszerre. Ha a specifikáció annyi, hogy „szükségünk van egy saját CRM-re”, abból még nem lehet megbízhatóan megmondani a fejlesztés várható munkamennyiségét.

Először azt kell megérteni, hogyan dolgozik a vállalkozás. Honnan érkezik egy érdeklődő? Ki kezeli? Milyen státuszokon halad keresztül? Milyen információkat kell tárolni? Mikor történik automatikus művelet? Ki milyen adatokat láthat? Hol keletkezik dokumentum? Mi történik lezárt értékesítés után?

A CRM bevezetésének lépéseinél is hasonló okból lényeges a folyamatok feltérképezése: a technológiát annak alapján lehet jól kialakítani, ahogyan a vállalkozás ténylegesen működik. A rosszul meghatározott követelmények később módosításokat, újratervezést és többletfejlesztést okozhatnak. A szoftverfejlesztési életciklusban ezért a követelmények tisztázása, a tervezés, a fejlesztés, a tesztelés, a bevezetés és a későbbi karbantartás egyaránt a teljes ráfordítás része.

A kész rendszer testreszabása és az egyedi fejlesztés nem ugyanaz

Egy üzleti problémára nem automatikusan saját szoftver a megfelelő válasz. Ha a vállalkozás igényeit egy kész rendszer megfelelően lefedi, gyakran gazdaságosabb annak bevezetése és konfigurálása. Egy általános ERP rendszer vagy piacon elérhető CRM sok esetben rengeteg olyan funkciót biztosít, amelyet saját fejlesztésben felesleges lenne újra elkészíteni.

Az egyedi fejlesztés akkor kerül előtérbe, amikor a vállalkozás folyamatai, üzleti szabályai vagy integrációs igényei már nem kezelhetők jól kész megoldással. Ez lehet például egy speciális gyártási folyamat, egyedi ajánlatképzés, saját jóváhagyási rendszer vagy több meglévő alkalmazás adatainak egységes kezelése.

Ilyenkor az egyedi szoftver szükségességét nem önmagában a technológia indokolja, hanem az, hogy a vállalkozás működését egy általános termék már csak komoly kompromisszumokkal tudná támogatni.

A felhasználók és jogosultságok száma is növelheti a komplexitást

Tíz felhasználó önmagában nem feltétlenül jelent egyszerűbb rendszert, mint száz. Sokszor fontosabb, hogy hány különböző szerepkört kell kezelni. Egy alap alkalmazásban minden belépett felhasználó ugyanazokat a funkciókat érheti el. Egy összetettebb vállalati rendszerben viszont lehet értékesítő, vezető, pénzügyes, ügyfélszolgálatos, adminisztrátor és külső partner, eltérő hozzáférési jogokkal.

Nem elég azt meghatározni, hogy ki melyik menüpontot látja. Adatszinten is szabályozni kellhet a hozzáférést. Egy értékesítő például csak a saját ügyfeleit láthatja, a csoportvezető az egész csapatét, míg a pénzügy kizárólag bizonyos pénzügyi információkhoz férhet hozzá. Az ilyen szabályok tervezést, fejlesztést és tesztelést igényelnek, ezért a jogosultsági rendszer összetettsége közvetlenül hat a projekt költségére.

Az adminisztrációs felület sem „jár automatikusan” a rendszerhez

Egy üzleti alkalmazásnak általában van olyan része, amelyet nem a végfelhasználók, hanem a rendszer kezelői használnak. Egy megfelelő adminisztrációs felület önmagában is komoly funkciókészlet lehet. Kezelni kellhet benne felhasználókat, jogosultságokat, törzsadatokat, rendszerbeállításokat, dokumentumokat vagy akár üzleti szabályokat.

Minél több mindent szeretne a vállalkozás fejlesztői beavatkozás nélkül módosítani, annál több konfigurációs lehetőséget kell beépíteni. Ez kezdetben növelheti a fejlesztési költséget, később viszont csökkentheti az apró módosításokhoz szükséges fejlesztői munkát.

Az integrációk gyakran a költségbecslés legnehezebb részei

Egy új üzleti rendszer ritkán működik teljesen elszigetelten. Kapcsolódhat például:

• CRM-hez;

• ERP-hez;

• számlázóprogramhoz;

• webáruházhoz;

• bankkártyás fizetéshez;

• dokumentumkezelőhöz;

• levelezési szolgáltatáshoz;

• külső adatbázishoz;

• más vállalati alkalmazásokhoz.

Minden ilyen kapcsolat külön feladat. Meg kell ismerni a külső rendszer interfészét, azonosítási módját, adatstruktúráját, korlátozásait és hibakezelését. A becslés során ezért az integrációkat és az alkalmazások közötti függőségeket külön célszerű felmérni; az AWS becslési útmutatója is önálló ráfordításként kezeli többek között az API-integrációkat, adatbázis-kapcsolatokat és külső függőségeket.

Egy egyszerű adatátadás és egy kétirányú, közel valós idejű szinkronizáció között jelentős különbség van.

Jó példa erre az automatizált számlázás. Ha az üzleti rendszernek egy másik szolgáltatás felé kell számlázási adatokat továbbítania, már azt is meg kell határozni, mi indítja a folyamatot, milyen adatokat küldünk át, és mi történik sikertelen kommunikáció esetén.

Az adatmodell összetettsége a háttérben növeli a munkát

A felhasználó a kész rendszerben képernyőket és mezőket lát. A háttérben viszont az adatok közötti kapcsolatokat is meg kell tervezni. Egy ügyfélhez tartozhat több kapcsolattartó, telephely, szerződés, ajánlat, projekt, számla és feladat. Egy projektnek lehet több felelőse. Egy dokumentum több üzleti objektumhoz kapcsolódhat.

Minél összetettebbek ezek a kapcsolatok, annál nagyobb figyelmet igényel az adatmodell kialakítása. Egy ügyviteli rendszer esetében ezért az adatkezelés és a folyamatok logikája legalább olyan fontos, mint maga a felhasználói felület. A rosszul kialakított adatmodell később megnehezítheti a riportokat, integrációkat és továbbfejlesztést is.

A felhő használata sem jelenti azt, hogy nincs infrastruktúraköltség

Az üzleti alkalmazásnak valahol futnia kell, az adatokat pedig tárolni kell. Felhőalapú rendszer esetében a vállalkozásnak nem feltétlenül kell saját fizikai szervert üzemeltetnie, de ettől még lehetnek rendszeres infrastruktúra-költségek. A számítási kapacitás, adatbázis, fájltárolás, adatforgalom, biztonsági mentések, naplózás és más szolgáltatások használata költséget jelenthet.

Az adattárolás felhőben ezért nem pusztán technológiai kérdés. A rendszer várható terhelését és adatmennyiségét a költségtervezésnél is figyelembe kell venni. Más igénye van egy húszfős belső adminisztrációs alkalmazásnak és egy folyamatosan nagy mennyiségű adatot feldolgozó szolgáltatásnak.

A UX és a felület kidolgozottsága szintén befolyásolja az árat

Egy belső rendszer esetében is számít, mennyire könnyű használni a felületet. Ha egy gyakori művelethez tíz kattintás szükséges három helyett, az napi több száz használat mellett már érzékelhető működési veszteséget okozhat. Ezért a felhasználói felület megtervezése nem egyszerűen esztétikai feladat.

Komplexebb rendszernél külön UI/UX tervezési szakaszra is szükség lehet, amelyben még a programozás előtt kialakulnak a fő felhasználói útvonalak és képernyők. A bizonytalanabb funkciók esetében egy prototípus segítségével korábban ellenőrizhető, hogy a tervezett működés érthető-e a felhasználóknak. Az iteratív prototípusok és a korai felhasználói visszajelzés csökkenthetik annak kockázatát, hogy csak a kész rendszer használatakor derüljenek ki alapvető problémák.

A tesztelés valódi része a fejlesztési költségnek

A szoftver attól még nincs kész, hogy a funkciókat leprogramozták. Ellenőrizni kell, hogy megfelelően működnek-e, együtt is helyesen viselkednek-e, és a módosítások nem rontották-e el a rendszer korábban elkészült részeit.

A projekt jellegétől függően szükség lehet egységtesztekre, integrációs tesztekre, rendszer- és elfogadási tesztelésre, teljesítményvizsgálatra vagy biztonsági ellenőrzésekre. A tesztelés a szoftverfejlesztési életciklus önálló része, és a komplexebb rendszereknél jelentős ráfordítást jelenthet.

A hibák dokumentálása és követése szintén része a folyamatnak. Egy jól kialakított hibakövetési rendszer segít abban, hogy a feltárt problémák állapota, prioritása és javítása követhető legyen. Az árajánlat összehasonlításakor ezért érdemes megnézni, pontosan milyen tesztelés szerepel benne.

Az MVP csökkentheti az első beruházás méretét

Gyakori hiba, hogy az első verzióba minden elképzelhető funkciót bele szeretnénk tenni. Ez növeli a fejlesztési időt, a költséget és annak kockázatát is, hogy olyan funkciók készülnek el, amelyeket később alig használnak. Egy MVP más logikát követ. Az első verzió azokat a funkciókat tartalmazza, amelyek már elegendők a legfontosabb üzleti folyamat működtetéséhez és a megoldás gyakorlati kipróbálásához.

Ez nem azt jelenti, hogy rosszabb minőségű szoftvert kell készíteni. A funkcionális terjedelmet kell tudatosan szűkíteni. Ha például egy új értékesítési rendszer hosszú távon húsz különböző funkciót kaphat, nem biztos, hogy mind a húsz szükséges az első éles verzióhoz. Az alap ügyfél-, ajánlat- és feladatkezelés elkészülhet előbb, a ritkábban használt funkciók pedig későbbi fejlesztési ütembe kerülhetnek.

A fejlesztési módszer is hatással van a költség kontrollálhatóságára

Egy teljesen előre specifikált projektben könnyebb fix keretekről beszélni, ha a követelmények valóban stabilak. Üzleti rendszereknél azonban a fejlesztés során gyakran derülnek ki új részletek. A felhasználók kipróbálják az elkészült funkciókat, és pontosabban meg tudják mondani, mire van szükségük.

Ilyen helyzetben az iteratív fejlesztés praktikusabb lehet: a rendszer kisebb egységekben készül, amelyek rendszeresen ellenőrizhetők. Ez azonban azt is jelenti, hogy a költség kontrolljának alapja a prioritások kezelése. Ha minden új ötlet automatikusan bekerül a projektbe, könnyen kialakulhat scope creep: a projekt terjedelme folyamatosan nő, vele együtt pedig az idő- és költségigény is. A rosszul definiált követelmények és a scope kontrolljának hiánya a fejlesztési költségek növekedésének ismert forrása.

Saját csapat vagy kiszervezett fejlesztés?

A költséget az is befolyásolja, hogyan áll össze a fejlesztőcsapat. Saját csapatnál nemcsak a fejlesztők bérével kell számolni. Toborzás, munkaeszközök, vezetés, szabadságok, képzés és a szükséges különböző kompetenciák biztosítása is a teljes költség része.

Külső partnernél ezek egy része a szolgáltatás díjába épül be. A kiszervezett szoftverfejlesztés különösen akkor lehet ésszerű megoldás, ha a vállalkozásnak nincs folyamatosan szüksége teljes belső fejlesztőcsapatra, de egy adott projekthez többféle szakértelem kell. Az összehasonlításnál ezért nem egy fejlesztő óradíját érdemes egy külső projekt árával szembeállítani, hanem a két megoldás teljes költségét és kockázatait.

A fejlesztés ára nem ér véget az élesítéssel

A szoftver életciklusa az indulással nem zárul le. Idővel megváltozhatnak a vállalkozás folyamatai, külső szolgáltatások API-jai, böngészők, operációs rendszerek vagy biztonsági követelmények. Új funkciókra is szükség lehet, és a használat során olyan hibák derülhetnek ki, amelyek tesztkörnyezetben nem jelentkeztek.

A karbantartás ezért a teljes szoftverköltség része. A szoftverfejlesztési életciklusban az üzembe helyezés utáni javítások, frissítések és optimalizálások önálló fenntartási feladatot jelentenek.

Üzletileg kritikus rendszernél azt is érdemes előre rögzíteni, milyen támogatás jár az alkalmazáshoz, milyen gyorsan kezdődik meg egy probléma kivizsgálása, és milyen rendelkezésre állási vállalások vannak. Ezeket egy megfelelő SLA teheti egyértelművé.

Hogyan lehet pontosabb árajánlatot kapni?

A legjobb ajánlatkérés nem azzal kezdődik, hogy „mennyibe kerül egy ilyen rendszer?”, hanem azzal, hogy minél egyértelműbben leírjuk a megoldandó problémát. Nem szükséges kész műszaki specifikációval érkezni. Az viszont sokat segít, ha ismert:

• kik fogják használni a rendszert;

• milyen problémát kell megoldania;

• melyek a legfontosabb üzleti folyamatok;

• milyen adatokat kezel;

• milyen jogosultságokra van szükség;

• milyen meglévő rendszerekhez kell kapcsolódnia;

• mely funkciók szükségesek az induláshoz;

• mely funkciók halaszthatók későbbre;

• vannak-e speciális biztonsági vagy teljesítménykövetelmények;

• milyen támogatásra lesz szükség az indulás után.

Ha például a cél egy értékesítési rendszer, érdemes már az első egyeztetésen végigvenni az érdeklődő beérkezésétől az ajánlatadáson és utánkövetésen át egészen a lezárt értékesítésig tartó folyamatot. Így nem egy általános „CRM ára” kérdésre kell válaszolni, hanem konkrét üzleti folyamatokra lehet fejlesztési becslést készíteni.

Mikor térülhet meg az egyedi szoftver magasabb induló költsége?

Egyedi rendszert nem azért célszerű fejleszteni, mert technikailag megoldható, hanem azért, mert üzletileg indokolható. Ha egy feladatot egy kedvező árú kész rendszer megfelelően kezel, a saját fejlesztés valószínűleg nem jó befektetés.

Más a helyzet, ha a vállalkozás működésének jelentős része manuális adatmásolásból, párhuzamos Excel-táblákból, egymással nem kommunikáló programokból vagy nehezen követhető adminisztrációból áll. Ilyenkor az egyedi rendszer értékét nem csak az határozza meg, mennyibe kerül elkészíteni, hanem az is, milyen működési problémát vált ki.

A digitális transzformáció akkor hoz valódi üzleti eredményt, ha a technológia a folyamatokat teszi egyszerűbbé, gyorsabbá vagy jobban ellenőrizhetővé. Ezért az egyedi szoftver árának értékelésekor érdemes két kérdést egymás mellé tenni:

Mennyibe kerül a rendszer elkészítése?

és

Mennyibe kerül a vállalkozásnak, ha a jelenlegi problémát nem oldja meg?

Ha az első kérdésre szeretnénk pontos választ kapni, a következő lépés nem egy általános árlista keresése, hanem a projekt terjedelmének meghatározása. Egy jól körülhatárolt első verzió, tisztázott integrációk és egyértelmű üzleti prioritások alapján már olyan fejlesztési becslés készíthető, amely valódi döntési alapot ad.