Rövid válasz: a legtöbb kkv-nak a legtöbb feladatra kész terméket érdemes venni, és csak ott fejleszteni, ahol a cég valóban más, mint a versenytársai. A számlázásban, a bérszámfejtésben, az irodai munkában ritkán vagy egyedi. Abban, ahogy a saját szolgáltatásodat előállítod, gyakran igen. A kettő között ott van egy harmadik út is: egy low-code vagy no-code platform, amely gyorsabb az egyedi fejlesztésnél, és rugalmasabb a dobozos terméknél.
A kérdés ritkán merül fel tisztán. Általában úgy kerül elő, hogy „a mostani rendszer nem tudja ezt”, és valaki azt mondja, „akkor fejlesszünk sajátot”. Ez néha jó döntés. Sokszor viszont csak egy drágább út ugyanahhoz a problémához.
Mit mondanak a tapasztalatok?
Az Egyesült Királyság kormányzati beszerzési útmutatója a legjobban megfogalmazott, semleges döntési szempontrendszer, amit ismerünk. Eszerint egyedi fejlesztés akkor indokolt, ha:
- az igény egyedi vagy ritka;
- kevés szállító tudja kielégíteni;
- a kész termékek nem igazíthatók vagy nem integrálhatók;
- a technológiát a szervezetnek magának kell birtokolnia;
- és a szervezet képes a fejlesztést irányítani.
Kész terméket akkor érdemes venni, ha az a beállításokkal, kevés testreszabással kielégíti az igények nagy részét. Az útmutató azt is kiemeli, hogy minden testreszabás drágítja a terméket, nehezíti a karbantartást, és korlátozza a frissítéseket.
A kormányzati szolgáltatási szabvány 11. pontja hozzáteszi: a döntésnél a technológia teljes életciklusára vetített költséget kell nézni, és kerülni kell a szállítóhoz kötöttséget.
A kockázat: a fekete hattyúk
Az egyedi fejlesztés legnagyobb kockázata nem az átlagos csúszás, hanem a ritka, de nagyon drága kisiklás. Bent Flyvbjerg és Alexander Budzier 1471 IT-projektet vizsgált. Az átlagos költségtúllépés 27% volt, ami még kezelhető. Minden hatodik projekt azonban „fekete hattyú” lett: átlagosan 200%-os költség- és közel 70%-os határidő-túllépéssel.
A Standish Group évtizedek óta készülő CHAOS-jelentéseiből két tanulság köszön vissza újra és újra: a kis projektek sokkal gyakrabban sikeresek, mint a nagyok, és az iteratív, agilis projektek sikerrátája jóval magasabb, mint a vízesés-modellűeké. A pontos számok a definíciók változása miatt óvatosan kezelendők, de az irány egyértelmű: kis, iteratív lépésekben kisebb a kockázat.
A három út
| Dobozos termék | Low-code / no-code platform | Egyedi fejlesztés | |
|---|---|---|---|
| Mikor jó | a folyamat iparági szabvány | egyedi folyamat, szabványos építőkockákból | valóban egyedi igény vagy versenyelőny |
| Időtartam | napok, hetek | hetek, hónapok | hónapok, évek |
| Kezdeti költség | alacsony | közepes | magas |
| Rugalmasság | alacsony | közepes–magas | magas |
| Karbantartás | a szállítóé | megosztott | a tiéd |
| Fő kockázat | a folyamatot kell a termékhez igazítani | a platformhoz kötöttség | csúszás, fekete hattyú |
A középső út sok kkv-nak a legjobb. A platform adja a felhasználókezelést, az adatbázist, az űrlapokat, a jogosultságokat és a riportokat, a cég folyamata pedig erre épül, programozás nélkül vagy kevés kóddal. Az ára a platformhoz kötöttség: érdemes előre megnézni, hogyan lehet az adatokat exportálni, és mi történik, ha a platform díjai vagy feltételei változnak.
Amit mi láttunk
A csapatunk két korábbi projektje jól mutatja a középső utat.
Vakcinagyártási kalkulátor. Egy nemzetközi állategészségügyi vállalat amerikai leányvállalatánál a kutatók és biomérnökök Excelben és papíron számolták a vakcinák összetételét, dózisát és előállítási folyamatát. QuickBase platformon kalkuláló és nyilvántartó rendszert fejlesztettünk, amely végigvezeti a felhasználót a folyamaton, és előre számolhatóvá teszi az erőforrásigényt, az átfutási időt és az alapanyag-fogyást. Hat hónap alatt élesedett, 20 kutató és mérnök használja.
Mobilos audit. Ugyanennél a vállalatnál az ügyfelek farmjain papíron auditálták a vakcinák tárolását és felhasználását. OutSystems low-code platformon webes és mobilos auditrendszer készült, Bureau Veritas integrációval, amelyből hivatalos tanúsítvány készül. A fejlesztés vezetését, a projektmenedzsmentet és az architektúrát a csapatunk adta. Négy országban, nyolc hónap alatt élesedett.
Egyik sem lett volna jó dobozos termékkel, mert a folyamat egyedi volt. És egyiket sem érte volna meg teljesen egyedi fejlesztésként, a nulláról megírni, mert a platform adta a gerinc nagy részét.
A teljes költség, nem az első ár
A kész termék ára előfizetés, az egyedi fejlesztésé projektár. A kettőt csak a teljes életciklusra vetítve lehet összehasonlítani. Öt tételt érdemes legalább öt évre végigszámolni:
- bevezetés vagy fejlesztés: a kezdeti munka;
- előfizetés vagy üzemeltetés: szerver, licenc, platformdíj;
- karbantartás és frissítés: biztonsági javítások, operációs rendszer- és böngészőváltozások, jogszabályváltozások;
- továbbfejlesztés: mert az igények változnak;
- kilépés: mennyibe kerül, ha egyszer váltani akarsz.
Az egyedi szoftver legnagyobb rejtett költsége a karbantartás. Egy kész termékben a szállító viseli a jogszabályváltozások, a biztonsági frissítések és az új böngészők költségét. Egy egyedi rendszerben te. Ha a szoftver számlázási, adózási vagy adatvédelmi szabályokat is érint, minden jogszabályváltozás egy újabb fejlesztési kört jelent, és ennek a határidejét nem te szabod meg.
Kié a kód?
Ez az a pont, amelyet a legtöbb kkv elfelejt a szerződésben. A magyar szerzői jogi törvény szerint:
- a szoftver vagyoni jogai átruházhatók (58. § (3) bekezdés);
- munkaviszonyban a munkáltató szerzi meg a munkavállaló által munkaköri kötelességként létrehozott mű vagyoni jogait, ha másként nem állapodnak meg (30. § (1) bekezdés);
- külső fejlesztőnél viszont semmi sem automatikus: a szerződésben kell rögzíteni, hogy a jogok átszállnak, vagy milyen felhasználási engedélyt kapsz.
Kész terméknél a jogszerű felhasználónak a törvény néhány alapjogot biztosít (például a használatot, a hibajavítást, a biztonsági másolatot), de a forráskód a gyártóé marad.
A gyakorlati teendő: egyedi fejlesztésnél a szerződésben legyen benne a forráskód átadása, a dokumentáció, a vagyoni jogok átruházása vagy kizárólagos engedély, és az, hogy az adatok a tieid. A brit útmutató emellett két évnél nem hosszabb kilépési lehetőséget és világos adat- és szellemi tulajdonjogi feltételeket javasol.
A gyakori negyedik út: kész termék plusz egyedi kiegészítés
A választás ritkán tiszta „vagy-vagy”. A leggyakoribb jó megoldás egy kkv-nál az, hogy a cég gerincét kész termék adja (ügyviteli rendszer, számlázás, irodai csomag), és csak a valóban egyedi részt építik hozzá külön, egy jól dokumentált integrációval.
Magyarországon a KSH adatai szerint a cégek közel fele már fizetős felhőszolgáltatásokat, vagyis jellemzően kész szoftvereket használ. A kérdés tehát egyre kevésbé az, hogy kész termék vagy egyedi rendszer, hanem az, hogy a kész termékek közé hol kell egy egyedi elem, és az hogyan kapcsolódik hozzájuk.
Ennek az a feltétele, hogy a kész termék nyitott legyen: legyen jól dokumentált programozói felülete (API), amelyen az adatok ki- és beáramolhatnak. Ezt a kiválasztásnál érdemes ugyanolyan súllyal nézni, mint a funkciókat.
Öt gyakori hiba
„Ilyet még senki nem csinált.” A legtöbb folyamat, amely elsőre egyedinek tűnik, egy már létező termékkategória egyik változata. Mielőtt fejlesztésbe kezdesz, keress rá alaposan, és kérdezz meg néhány szállítót.
A folyamat nincs leírva. Ha a fejlesztő a folyamatot a fejlesztés közben ismeri meg, a projekt a felfedezésről fog szólni, nem a fejlesztésről. Előbb a folyamat, aztán a szoftver.
Minden egyszerre. Az első változatba kerül minden ötlet, amely az évek során felgyűlt. Ez a fekete hattyú receptje. Az első változat legyen szűk, és működjön.
Nincs gazdája. Az egyedi rendszernek kell egy belső felelős, aki tudja, mire való, és dönt a továbbfejlesztésről. Különben a szoftver a fejlesztő cég termékévé válik, nem a tiédé.
A kilépés nincs megtervezve. Ha a fejlesztő cég megszűnik vagy elérhetetlenné válik, hozzáférsz a kódhoz, a dokumentációhoz és a szerverhez? Ha nem, a cég egy olyan rendszertől függ, amelyet senki nem tud karbantartani.
Öt kérdés a döntés előtt
- Ebben a folyamatban különbözünk a versenytársainktól? Ha nem, vegyél kész terméket.
- Meg tudjuk változtatni a folyamatot, hogy illeszkedjen egy kész termékhez? Ez gyakran olcsóbb, mint a terméket igazítani a folyamathoz.
- Van olyan platform, amelyen a folyamat programozás nélkül vagy kevés kóddal felépíthető? Ha igen, ez lehet a középső út.
- Ki fogja karbantartani öt év múlva? Ha erre nincs válasz, az egyedi fejlesztés kockázatos.
- Mi a kilépési terv? Hogyan kapod vissza az adataidat, ha váltani kell?
Mit tegyél most?
- Írd le a folyamatot, amelyre szoftvert keresel, a legbonyolultabb hétköznapi esetekkel. Egy-két oldal elég, de legyen benne, ki mit csinál, milyen adattal, és mi a gyakori kivétel.
- Nézz meg két-három kész terméket ugyanezekkel az esetekkel.
- Nézz meg egy platformalapú megoldást is, ha a kész termékek nem illeszkednek.
- Számold végig a teljes költséget öt évre, karbantartással és kilépéssel együtt.
- Egyedi fejlesztésnél bontsd kis lépésekre: először egy működő, szűk változat, aztán bővítés.
- Rögzítsd a szerződésben a forráskód, a dokumentáció és az adatok sorsát.
Ha nem vagy biztos benne, melyik út a jó, és szeretnéd, hogy valaki független szemmel átnézze az igényeidet, nézd meg a szoftverfejlesztési és az IT tanácsadási szolgáltatásunkat.
GYIK
Mikor éri meg egyedi szoftvert fejleszteni?
Ha az igény valóban egyedi, kevés szállító tudja kielégíteni, a kész termékek nem igazíthatók, és a cég képes a fejlesztést irányítani és hosszú távon karbantartani. Jellemzően ott, ahol a folyamat a versenyelőny része.
Mennyivel drágább az egyedi fejlesztés?
Ez a feladattól függ, de a kezdeti árnál fontosabb a teljes életciklus költsége, mert a karbantartás és a továbbfejlesztés a tiéd. A kockázat is nagyobb: egy nagy mintán minden hatodik IT-projekt átlagosan 200%-kal lépte túl a költségvetését.
Mi az a low-code vagy no-code platform?
Olyan fejlesztőkörnyezet, amelyben az alkalmazások nagy része vizuális eszközökkel, programozás nélkül vagy kevés kóddal épül fel. Az egyedi folyamat gyorsabban elkészül, mint teljesen egyedi fejlesztéssel, de a platformhoz kötöttség kockázatát mérlegelni kell.
Kié lesz a forráskód, ha külső céggel fejlesztetünk?
Csak az, amit a szerződés rögzít. A magyar szerzői jog szerint a szoftver vagyoni jogai átruházhatók, de ez külső fejlesztőnél nem automatikus. A szerződésben rögzítsd a jogok átruházását vagy a kizárólagos engedélyt, a forráskód és a dokumentáció átadását.
Hogyan csökkenthető az egyedi fejlesztés kockázata?
Kis, iteratív lépésekkel: először egy szűk, működő változat, amelyet a felhasználók kipróbálnak, és csak utána a bővítés. A kutatások szerint a kis projektek sokkal gyakrabban sikeresek, mint a nagyok.
Források
- GOV.UK – Define your purchasing strategy
- GOV.UK Service Manual – 11. Choose the right tools and technology
- Flyvbjerg, Budzier – Why Your IT Project Might Be Riskier Than You Think (arXiv 1304.0265)
- 1999. évi LXXVI. törvény a szerzői jogról
- OpenCommons – CHAOS Report on IT Project Outcomes
- Planning Planet – Successful Projects: What We Really Know
- HVG – Szanaszét van szakadva a magyar gazdaság, már ami a cégek fejlettségét illeti
