Amikor egy cég új belső rendszert vagy ügyfélszolgáló felületet tervez, szinte mindig felmerül ugyanaz a kérdés. Vegyünk egy kész terméket, építsünk egy ismert keretrendszerre (például WordPressre egy tartalmi oldalhoz), vagy írjunk egyedi szoftvert nulláról. A hiba az, ha ezt technológiai kérdésként kezeljük, pedig valójában arról szól, mennyire illeszkedik a cég folyamata ahhoz, amit a kész rendszer feltételez a folyamatról.
Kész rendszer
Egy kész rendszer (pl. egy közkedvelt projektmenedzsment- vagy számlázóprogram) akkor jó választás, ha a folyamat, amit támogatnia kell, közel áll ahhoz, amit a legtöbb hasonló cég csinál. Ilyenkor a testreszabás minimális, a bevezetés gyors, és a karbantartást a gyártó viseli.
A hátránya pontosan ugyanez. Ha a folyamat egy ponton eltér a megszokottól, a kész rendszer vagy nem engedi meg az eltérést, vagy csak nehézkes kerülőúton. A kerülőutak pedig gyűlnek, egy táblázat a rendszer mellett, egy külön e-mail-kör, egy mező, amibe „ideiglenesen” mást írnak. Amikor ezekből több van, mint amennyit a csapat fejben tart, a kész rendszer már nem spórol, hanem költséget termel.
Érdemes még két dolgot előre megnézni. Kijönnek-e belőle az adatok, ha egyszer váltani kell, és mennyibe kerül a licenc akkor, ha háromszor annyian használják, mint ma.
Keretrendszerre épülő megoldás
A keretrendszerre épülő megoldás (mint egy WordPress-oldal egyedi funkciókkal, vagy egy Laravel-alapú belső admin) középutat kínál, mert a keretrendszer hozza a gerincet (bejelentkezés, adatkezelés, admin felület), a cég egyedi logikája pedig arra épül rá.
Ez akkor a jó választás, ha a folyamat nagyobbik része szabványos, és van egy jól körülhatárolható rész, ami tényleg más, mint bárki másnál. A kulcsszó a körülhatárolható. Ha az „egyedi rész” végigfut a rendszer minden képernyőjén, akkor valójában nem kiegészítés, hanem maga a rendszer, és a keretrendszer inkább akadály lesz, mint alap.
Egyedi fejlesztés
Az egyedi fejlesztés akkor éri meg, ha a folyamat maga a versenyelőny, vagyis ha a cég azért jobb a piacon, mert máshogy dolgozik, és ezt egy kész rendszer nem tudja lekövetni anélkül, hogy visszakényszerítené a céget a szabványos folyamatra.
Ez a legdrágább és leglassabb út, de az egyetlen, ahol a szoftver a cég saját módszerét erősíti, nem pedig egy általános módszerre kényszeríti rá. Az „egyedi” nem jelenti azt, hogy mindent nulláról írunk. A rendszer alsó rétege (jogosultság, felhasználók, naplózás) ott is ugyanaz, mint bárhol máshol, és az egyediség a fölötte lévő rétegben van.
Hogyan dönts
Négy kérdés általában elég a döntéshez:
- Miben térünk el? Ha a válasz „szinte semmiben, csak a szóhasználatban”, akkor kész rendszer kell.
- Az eltérés körülhatárolható? Ha igen, a keretrendszerre épülő megoldás felé mutat.
- Az eltérés adja a versenyelőnyt? Ha igen, az egyedi fejlesztés árát ez fizeti vissza.
- Mi történik három év múlva? Kijönnek az adatok? Kit hívunk, ha elromlik? Egy döntés akkor jó, ha a folytatása is elképzelhető.
A leggyakoribb hiba
Nem az, hogy valaki rosszul választ, hanem az, hogy a kérdést fordítva teszi fel. Előbb dől el a technológia, és utána próbálják hozzáigazítani a folyamatot. Ilyenkor a rendszer bevezetése után derül ki, hogy a napi munka nem fér bele, és a cég vagy a szoftvert kerüli meg, vagy a saját, jól működő gyakorlatát adja fel.
