Készen kapható rendszer vagy egyedi fejlesztés: hogyan dönts

„Kész szoftver vagy egyedi fejlesztés” nem olyan kérdés, amire van egy általánosan helyes válasz — mindkettő létezik, mert mindkettő jó megoldás, csak nem ugyanarra a problémára. A hiba, amit a leggyakrabban látunk, nem a rossz választás, hanem az, hogy a kérdést sosem teszik fel tudatosan: a cég egyszerűen azzal folytatja, amit három éve elkezdett, anélkül hogy megnézné, még mindig illik-e rá.

Mikor elég a készen kapható

Ha a folyamatod standard — értékesítési csővezeték, számlázás, ügyfélszolgálati jegykezelés —, egy bevált, széles körben használt rendszer szinte mindig gyorsabb és olcsóbb, mint nulláról építeni. Ezerszám tesztelték már más cégeken, és ezt a munkát újra elvégezni a saját projektedért ritkán éri meg. Az egyértelmű jel a maradásra: ha az egyetlen panasz az, hogy „a felület nem elég szép” vagy „hiányzik egy apró funkció”, azt szinte mindig testreszabás vagy integráció oldja meg, nem a teljes rendszer újraírása.

Mikor kezd nem működni

Más a helyzet, amikor az üzleti folyamat maga a termék, nem csak egy kisegítő funkció az értékesítés körül. Például amikor a cég iparág-specifikus státuszláncon vezeti végig a megrendeléseket, amit egyetlen kész rendszer sem tervezett eleve be, és a megkerülő út egyedi mezőkön és automatizációkon keresztül olyan bonyolulttá válik, hogy nehezebb karbantartani, mint újraírni. Vagy amikor a jogosultságoknak finomabbnak kell lenniük, mint „adminisztrátor és felhasználó” — olyan szerepkörökre van szükség, amelyek pontosan a cég struktúráját tükrözik, naplózással arról, ki mikor mit módosított. A kész rendszerek ezt is tudják gyakran, de sokszor csak a drága csomagban, ahol olyan funkciókért fizetsz, amiket sosem használsz, egyetlen olyanért, amire szükséged van.

Hogyan néz ki a különbség a gyakorlatban

Helyzet	Kész rendszer	Egyedi fejlesztés
Standard értékesítési folyamat	Dobozból is megfelel	Felesleges
Iparág-specifikus megrendelés-státuszok	Egyedi mezőkkel megkerülhető, de törékeny	A folyamatot közvetlenül tükrözi
Finom jogosultsági szintek, naplózással	Gyakran csak drága csomagban	Kezdettől a feladatra tervezve
Az adatnak a cégnél kell maradnia	A szolgáltató feltételeitől függ	A cég birtokolja a kódot és az adatbázist is

Amit a „hibrid” út valójában jelent

A választás nem mindig fekete-fehér. Sok cégnél a legjobb megoldás egy bevált rendszer megtartása arra, amire jó — mondjuk könyvelés vagy standard ügyfélkezelés —, és egy vékony, egyedi réteg építése oda, ahol a folyamat már nem fér bele. Ez integrációs feladat: a kész rendszer és az egyedi réteg között adatnak kell folynia automatikusan, emberi másolás-beillesztés nélkül. A döntés így nem „minden kész vagy minden egyedi”, hanem pontosan annyi egyedi munka, amennyi a valódi eltéréshez szükséges.

Hogyan közelítünk hozzá

Nem kóddal kezdünk. Az első lépés egy discovery-beszélgetés: végigmegyünk a jelenlegi folyamaton lépésről lépésre — ki mit csinál, milyen adat kell az egyes lépéseknél, mi kerül bele a vezetői riportba. Ez nem elvont prezentáció, hanem írott specifikáció, amit egy hónap múlva is vissza lehet olvasni és érteni, miben állapodtunk meg. Utána iteratívan fejlesztünk: nem „fél év múlva jövünk a kész termékkel”, hanem működő verzió kéthetente, amit meg lehet nézni és irányt lehet korrigálni, ha valami félrement.

A jogosultságok, szerepkörök és a módosítási napló nem utólag kerül be a rendszerbe, hanem már az első iterációtól kezdve, mert ezt utólag hozzáadni szinte mindig fájdalmasabb, mint eleve betervezni. Ugyanez igaz az adatexportra: ha a vezetésnek heti riport kell egy meghatározott formátumban, ennek a rendszer részének kell lennie, nem heti kézi munkának.

Mi történik a régi rendszerből átvitt adattal

Az áttérés ritkán jelent tiszta lapot — évek alatt felhalmozódott kontaktok, tranzakciótörténet, megjegyzések vannak a régi rendszerben. Ezt nem lehet egyszerű CSV-exporttal és -importtal átvinni: a mezők nem esnek egybe egy az egyben, van, ahol duplikáció keletkezett, van, ahol a régi rendszerben felgyűlt szemét, amit nem érdemes tovább vinni. Az adatátvitelt külön, explicit fázisként kezeljük, nem a projekt végén mellékesen elintézett feladatként — ellenőrzéssel, hogy az átvitel után valóban ugyanazok az üzletek és ugyanazok az ügyfelek szerepelnek, nem egy hozzávetőleges másolat.

Milyen jelek árulkodnak arról, hogy már kinőtted a kész rendszert

Nem mindig egyetlen nagy pillanatban derül ki, hogy egy kész rendszer már nem elég — inkább apró jelek halmozódnak. Ha a csapat rendszeresen táblázatokban vagy külön dokumentumokban tartja azt, aminek a rendszerben lenne a helye, mert a rendszer nem engedi úgy rögzíteni, ahogy a folyamat valójában működik, az jel. Ha minden új munkatárs betanítása azzal kezdődik, hogy “ezt a részt igazából nem a rendszerben csináljuk, hanem…”, az is jel. És ha a rendszer bővítése minden alkalommal egy külső fejlesztő bevonását igényli, mert a beépített testreszabási lehetőségek elfogytak, az már nem testreszabás — az egy egyedi fejlesztési projekt, csak épp egy másik cég termékére építve, amit nem birtokolsz.

Egyik jel önmagában nem indok a váltásra. De ha több is igaz egyszerre, érdemes leülni és őszintén felmérni, mennyibe kerül ez a rejtett munka most, és mennyibe kerülne, ha a folyamat közvetlenül a rendszer része lenne.

A szabály, ami alapján döntünk

Nem javasolunk egyedi fejlesztést, ha a problémát egy olcsóbb testreszabás is megoldja a kész rendszeren — még akkor sem, ha nekünk kedvezőbb lenne a teljes projekt. És fordítva: nem javasoljuk a maradást egy előfizetésen, ha a folyamat valóban nem fér bele, és a megkerülő megoldások már drágábbak, mint egy közvetlen fejlesztés lenne.

Ha nem vagy biztos benne, melyik irányba érdemes nézni, mesélj a folyamatról, és őszintén megmondjuk, mi tűnik ésszerűbbnek a te esetedben. Arról, hogyan épülnek nálunk az ilyen rendszerek, a munkáink oldalon és az egyedi szoftver oldalon olvashatsz bővebben, a mobilapp-fejlesztés áráról pedig ebben a cikkben.

A kész rendszer azt kérdezi: beleférsz-e a dobozba. Az egyedi fejlesztés azt: megéri-e neked a saját dobozt megépíteni.