Szinte már közhely, hogy ma már minden vállalat – iparágtól függetlenül – valójában szoftvercég. Egyre gyakrabban jelenik meg a szoftver a termékben (lásd Szaratov vs intelligens hűtő), de még egy csőgyártó üzemnek is szüksége van folyamatait segítő szoftverekre. Mivel azonban a piac gyorsan változik, és azt ezeknek a szoftvereknek is le kell követniük, egyre gyakrabban vetődik fel a kérdés: vásároljunk vagy fejlesszünk?

A tanácsadóknál sokáig az volt az ökölszabály, hogy a sztenderd folyamatokért felelős szoftvereket vedd meg, a kulcseszközöket, melyek a versenyelőnyödet adják, fejleszd magad. A megfontolás emögött az volt, hogy a stratégiai eszközök legyenek a vállalat kezében, mert ez biztosítja, hogy akkor és úgy módosíthassák, amikor és ahogyan a piac változása megköveteli. Ami meg (majdnem) szabványos folyamat, ahhoz gazdaságosabb venni valamilyen sztenderd szoftvert.
 

Ezt a dilemmát a tanácsadók számszerűsítették is: ha egy szoftver a vállalat által támasztott kritériumok 80 százalékát teljesíti, vedd meg, mert akkor jársz jobban. A szoftverszolgáltatások (SaaS) terjedésével ez még inkább igaznak tűnt, hiszen még a karbantartási, üzemeltetési költségeken is lehetett faragni.

A Forrester egy idei kutatása (amihez többek között megkérdezték az EPAM egyik vezetőjét, Fejes Balázst; a cég oldaláról a tanulmány is letölthető) azonban kicsit új megvilágításba helyezi ezt a dilemmát. A kutatás szerint a tiszta modellek a legritkább esetben léteznek, így a legtöbb cégnél a fenti érvek sem feltétlenül validak. Először is kicsi annak a valószínűsége, hogy egy ún. COTS (commercial off-the-shelf) szoftver úgy ahogy van, megfeleljen az adott vállalat igényeinek. Másrészt a belső fejlesztéseknél is egyre inkább arra törekszenek a vállalatok, hogy újrahasznosítsanak monden lehetséges elemet a korábbi fejlesztéseikből. A Forrester szerint ezért nem a buy–build, hanem a customize–compose fogalompár írja le legpontosabban a dilemmát.

Mi a baj a sztenderd szoftverekkel?

1. Alábecsüli vállalatok egyediségét. Régebben az volt a mondás, hogy a COST szoftverek a vállalati működés bevált gyakorlatainak egyfajta esszenciáját sűrítik, ezért érdemes a belső folyamatokat a szoftverhez igazítani. A valóság azonban az, hogy cég és cég között (még azonos iparágban is) óriási a különbség (hasonlítsuk össze mondjuk az Apple-t a Samsunggal az Amazonnal és az Oracle-lel, vagy a Deutsche Telekomot a Vodafone-nal...). Ha egy vállalat jól működik, a belső folyamati az idők során letisztulnak, és a vállalati működés csak ott jellemző módját mutatják. Ez érték, amit csak úgy lehet megőrizni, ha a támogató szoftvereket igazítjuk a folyamatokhoz, és nem viszont.

2. A COST szoftverek többségében megjelenik az a feltételezés, hogy a környezet (belső és külső) bizonyos keretei hosszú ideig állandóak. De aztán jött 2020 elején a globális járvány, és kiderült: akár egyik pillanatról a másikra is borulhat a piaci környezet és a belső folyamatok. Erre az a vállalat tudott gyorsan reagálni, amelynek magas szintű volt a testreszabási képessége. Talán nem is kell hangsúlyozni, milyen előnyt jelentett, ha valaki saját fejlesztésű szoftvereszközöket használt.

3. A costumizáció is értékes fejlesztői erőforrást köt le.

4. A COST szoftverek testre szabása is végeláthatatlan folyamat, ugyanis gyakran vezet a későbbiekben kompatibilitási problémákhoz. Egyes frissítések lenullázhatják a hozzáfejlesztéseket, amiket esetleg újra kell írni.

5. Fölösleges funkciók vannak benne. A sztenderd megoldások szükségszerűen sokkal több funkciót tartalmaznak, mint amennyire adott felhasználónak szüksége van (a Wordöt használják a titkárnők egy szerződés legépelésére, de a szoftver alkalmas komolyabb kiadványok elkészítésére is...). A fölösleg lefaragása egyes vállalati szoftvereknél költségkérdés is, hiszen befolyásolhatja a szoftverért fizetendő licencdíjat.

Akkor inkább minden fejlesszünk magunk?

Értelemszerűen ez képtelenség. Amellett, hogy fölöslegesen égetnénk az amúgy is szűkös erőforrásokat, bizonyos sztenderd funkciókra sokkal jobb megoldásokat kapunk közel használatra készen a piacon, mint amilyent le tudnánk fejleszteni. És amúgy a belső fejlesztéseknek is vannak negatívumai.

1. Drága és időigényes. Professzionális fejlesztőket igényel, és még a legjobb fejlesztési módszertant követő, agilis szervezetekben is komoly feszültség forrása lehet az igény és eredmény közötti eltérés.

2. Az IT-csapatban általában nehéz zökkenőmentesen átvinni a projektalapon működő fejlesztést a folyamatos üzemeltetésbe. Ezen még a DevOps-megközelítés sem feltétlenül segít (a problémáról érdemes meghallgatni egy korábbi podcastunkat).

3. Az esetleges problémák megoldásához nem áll rendelkezésre egy széles felhasználói bázis. (A fontosabb vállalati szoftverek köré felhasználói közösség szerveződnek – HOUG, SAP User Groupok stb. –, ahol a vállalatok megoszthatják egymással tapasztalataikat.)

Jövőálló illeszkedési modell kell

A Forrester szerint egyre jobban érzékelhető az elmozdulás a customize–compose megközelítés irányába. A kutatócég fel is vázol egy modellt, hogyan mozognak a vállalatok a két végpont között üzleti területenként (lásd az ábrát).
 

A testreszabás és az összeállítás dinamikája

(Forrás: Forrester)

Az elmúlt évtized felszínre hozott több olyan technológiát is, amely segíti ezt. A sztenderd megoldások elmozdultak a felhőszolgáltatások irányába, egyre több ilyen alkalmazásnak jelenik meg a natív felhős változata. Az azokhoz való rugalmasabb illeszkedést pedig low-code/no-code platformok vagy a mikroszolgáltatásokra épülő IT-architektúra segíti.

A tanulmány három tanácsban sűríti össze a kutatás tapasztalatait.

1. Csak olyan modern alkalmazásokat és szoftvercsomagokat szabad vásárolni, melyeket könnyen lehet adaptálni.

2. Érdemes további fejlesztőket felvenni, vagy ha az nem megy, olyan tanácsadókat, akik képesek koordinálni a külső fejlesztő csapatokat.

3. Low-code platformokkal be lehet vonni az üzleti oldalt a fejlesztésbe, és meghonosítsani egy permanens fejlesztési kultúrát.