Trendek, melyek meghatározzák az üzleti célú alkalmazások költségeit és megtérülésüket

Néhány éve még magától értetődő volt, hogy egy vállalatirányítási rendszer bevezetése egyszeri, nagy összegű IT beruházást jelent, a megrendeléstől a tényleges használatba vételig negyedtől, akár 3 évig terjedő átfutási idővel. Amit aztán némi rendszeres, állandó licenckövetési és támogatási díj mellett néhány (2-20) év múlva talán megtérült a beruházás, és elkezdett tiszta hasznot termelni. A bevezetés kötött követelményekre épült, kötött áron, minden kiszámítható volt.

Miért is volt mindez így?

Az előre gyártott, testre szabható telepített szoftvereknek (SAP, Dynamics AX, stb.) már az alapcsomagja is széleskörű, több üzleti terület (pénzügy, értékesítés, gyártás,marketing, stb.) igényeit viszonylag jól kielégítő funkcionalitást nyújtott. Az egyes területek a programban is szorosan kapcsolódtak egymáshoz az üzleti folyamatok hű leképezése érdekében. A hosszabb bevezetési időt jellemzően az egyedi átalakítások indokolták, melyekkel a cégek elérhették, hogy a teljesen sajátos (a szoftvergyártó sztenderd megoldásától eltérő) folyamataik is megfelelő informatikai támogatást kapjanak. A vállalati folyamatok átláthatóbbá váltak azáltal, hogy az üzleti működést a program kész funkcióihoz kellett rendelni a bevezetési projekt során.

Hol vannak a rejtett költségek? – Azárnyoldal

A nagy szoftvergyártók egymással versengve egyre több funkcionalitást fejlesztettek a temékeikbe „a több jobb” jelmondattal, így a kész szoftver egyre kisebb részét használta egy-egy konkrét cég a saját működésében. Ettől függetlenül a gyártói fejlesztés árát ki kellett fizetni valakinek, így a nagy ERP szoftverek árai emelkedni kezdtek.A programok egyre bonyolódó belső összefüggésrendszere a tanácsadók, fejlesztők tanulási görbéjét is elnyújtotta a sok új funkció miatt. Ugyanez a bonyolultság a tervezési fázisra és az egyedi fejlesztésekre is átgyűrűzött, további munkaórákat égetve el mind a bevezetésben, mind később, a különféle verziójú rendszerek támogatásában.

Az egyedi fejlesztések emellett sajátos csapdát alakítottak ki: kialakításukkor az üzlet igényeit támogatva, annak folyamatait konzerválni kezdték. Képzeljük csak el a következő, szokásos beszélgetést:
 

• Üzlet:- „Szeretnénk módosítani a tevékenységünket egy kicsit. Jobban járnánk, ha …”

• IT:- „A programunk így működik, ne csináljuk máshogy, mert azt nem támogatja!”

• Üzlet:- „Akkor kérjünk fejlesztést, hiszen kapunk a programhoz támogatást is!”

• Támogató:- „Egy rakás összefüggő, egyedi funkció közé kell egy újabbat úgy betenni, hogy ne romoljon el semmi más. Alaposan át kell nézni a függőségeket és tesztelni az eredményt, mielőtt kiadjuk a módosítást felhasználásra. Hány óra is lesz ez? ...”

• Üzlet:- „Mi kerül egy egyszerű funkción ennyibe?! Na jó, még így is megtérül 1-2 éven belül, kérjük.”

• IT:- „Sajnos a havi keretbe ez már nem fér bele. Az éves IT költségvetést pedig elköltöttük és nem léphetjük túl.”

• Üzlet:- „Rendben, akkor csináljuk úgy, mint eddig. Még mindig jobb, mint a program nélkül kézzel.”

Így némely cég mindaddig – akár egy évtizeden át is – használta az ERP-jét különösebb változtatások nélkül, míg az teljesen élhetetlenné nem vált a változó üzleti környezetben (vagy a hardvere elavulása miatt). Az időközben elmaradt üzleti haszon nem könnyen számszerűsíthető. Pedig ez csak a felvezetés.
 

Amikor ERP cserére kerül sor, a cég mikkel szembesül? - Töréspont

• Adott a szakembergárdája, mely egy évtizede többé-kevésbé ugyanazt, ugyanúgy teszi, hiszen az ERP a teljes működést átszövi (és fixálja). Óriási lesz az ellenállás, ha rájuk próbálnak erőltetni valamit, ami nem megszokott – például híján van az elmúlt évtized apró, egyedi kényelmi funkcióinak. Egyszerűen azért, mert a kollégák elszoktak a változásoktól.

• Van új verzió a megszokott programból – ami nyomokban tartalmazza a régit, de a sok gyári újdonság miatt a használatához teljesen új felmérés és bevezetés szükséges, tetézve a megszokott egyedi kényelmi funkciók újrafejlesztésének költségével. Az alapára ugyan időközben jelentősen nőtt, de a felhasználók régi igényei végre megvalósulhatnak. A kollégák elfogadják, mert ismerősen működik, nem kell felforgatniuk az életüket.

• Elérhető más gyártó terméke, ami önmagában hasonlóan drága, mint a megszokott program új verziója, viszont a régi program által „idomított”, beégett üzleti folyamatok nem feltétlenül vannak összhangban az új program lehetőségeivel. Ez könnyen tovább egyedi fejlesztéseket eredményez, immár az új rendszerben.

A fenti helyzetet valaha is megtapasztalt cégek döntéshozói természetesen alternatívákat keresnek a jövőbeli hasonló esetek kivédésére, a szoftvergyártók pedig ezen új igények szerint alakítják kínálatukat. Nézzük csak, mik is manapság a divatos témák:

Telemetria

A központilag monitorozott rendszerek előnye a használóik számára, hogy könnyű bennük azonosítani a hibákat, gyenge pontokat, és ezekre még a komolyabb problémák felmerülése előtt megoldás adható. Egyúttal a gyártó láthatja, hogy mely funkciók továbbfejlesztésére érdemes hangsúlyt fektetni, melyeket használják széleskörűen. Az alig használt modulok kivonhatóak a forgalomból, így csökkentve a komplexitást, aminek a közvetett költségnövelő hatásait fent láthattuk. Mellékesen a licencelés is sokkal könnyebben ellenőrizhető.

Modulokra bontott licencelés, avagy az appok kora

Túl drága a „mindent-bele” szoftvercsomag, aminek kis részét használja? Fizessen kevesebbet csak a használt részeiért! A gyártónak ez azért éri meg, mert alacsonyabb áron többen veszik meg egy termékét, és a későbbiekben a meglevő vevői is szívesebben bővítik a felhasznált funkcionalitást újabb, gyári vagy harmadik fél által kínált részekkel, modulokkal, újabb nevükön appokkal. Felhasználóként az elsőre alacsonyabbnak tűnő egységáron túl, az az igazi előny, hogy egyes üzleti folyamatait különféle gyártók, különféle termékeivel támogathatja és ezeket egyenként cserélheti. Mitől más ez, mint 20-25 évvel ezelőtt a szigetrendszerek korában? Most a „szigetek” együttműködésre épülnek – hiszen a szétválasztásuk utólag, mesterségesen történt. A különféle gyártók termékei közti adatcsere is sokat fejlődött, sztenderdizálódott időközben.

Bővítmények – szoftver LEGO® mintára

Ha a modulokra bontást úgy képzeljük el, mint egy-egy piaci szegmenshez (pl. gyártók, nagyker., kisker., szolgáltatók, stb.) való specializáltabb alkalmazkodást, akkor a bővítmények az ezen belüli, még részletekbe menőbb működéseket támogatják. Mindezt úgy, hogy a kész megoldások, esetünkben bővítmények kialakítási költsége nagyrészt egyszeri, így minél többen alkalmazzák és veszik meg, annál olcsóbbá válhat –szemben az egyedi fejlesztésekkel. A különféle appokból aztán a LEGO® elemekhez hasonlóan építhető fel szinte bármilyen üzleti folyamat támogatása. (A hasonlat azért is találó, mert a fenti játékból sem építhető meg dolgok tökéletes hasonmása, csak valami hasonló.)

Korlátozott testreszabhatóság

Míg régen némely dobozos program teljesen átírható volt, most meghatározott szabályok korlátozzák a lehetséges módosítások körét, módját. Ennek oka a következő: A LEGO®-hoz hasonlóan a szoftver összetevőkben is vannak kapcsolódási pontok, melyek megléte szükséges az együttműködéshez. Ez önmagában nem jelenti, hogy valaki ne alakíthatna ki saját elemet/egyedi fejlesztést – a korlátozás a gyárilag kiadott részekre vonatkozik, ahol így biztosítható, hogy a számtalan különféle, ezekhez szervesen kapcsolódó, harmadik felek által készített bővítmény az átalakítások után is az elvárások szerint fog működni az alappal egységben, tetszőleges kombinációjukban is.

Kényszerített változások

Hiába a sok új fejlesztés, ha ezt nem veszik használatba, nem kezd profitot termelni senkinek. A fentiekben láttuk, hogy a halogatás csak nehezebbé teszi az újdonságok elfogadását, mind mentalitásban, mind árban. Ráadásul a szoftvergyártó számára kisebb kockázat negyedévente, vagy akár havonta elfogadtatni egy-egy kis változtatást az ügyfeleivel, mint 5-10-évente egy teljes rendszer cserét, ahol szinte egyenlő eséllyel indul a versenytársa is. Felhasználói oldalról örülhetünk az újabb és újabb funkcióknak, hibajavításoknak. A korlátozott testreszabhatóság itt egy további előnyt tartogat – az új gyártói verzió jó eséllyel illeszkedik mindenhez, ami a korábbi verziójához illeszkedett, így megkímélhetjük cégünket a további nagy ERP bevezetésektől: LEGO® építményünket nem kell újraépíteni, ha az alap változik, csak egyben leemelni a régiről, és rátenni az újra.

Havi díj – bérelni vagy venni?

Egy nagy ERP bevezetés komoly beruházás, egyben nagy kockázat és elköteleződés is. Ügyfélként sokkal megnyugtatóbb, ha „kevesebb forog kockán”: legrosszabb esetben az eltelt idő során használt szolgáltatás fizetendő ki, nem egy szoftver teljes élettartamra kalkulált ára. A szoftvergyártó pedig örülhet, hogy ügyfelei stabilan fizetik a havidíjat, nem ragadnak le további fizetés nélküli régi verziók mellett, magukra zárva a fent bemutatott csapdát. A havi díj koncepciója a bővítményeknél, appoknál még jobban beválik: ezek egyszerűsége lehetővé teszi, hogy minimális időfordítással és költséggel kipróbáljuk, skálázzuk, vagy kidobjuk ezeket az üzleti folyamataink változása esetén.

A fenti változásokhoz az ERP rendszereket bevezető támogató cégek is próbálnak alkalmazkodni különféle módokon. Némely cég a régi verziók régi módszertan szerinti életben tartására fókuszál, mások saját bővítményeket fejlesztenek, egyesek a tanácsadási szolgáltatások javítására, bővítésére helyezik a hangsúlyt. Valamennyi stratégia indokolható, de érdemes ügyfélként is tisztában lenni ezekkel, mert eltérő szemléletmódot hordoznak, így eltérő javaslatokat kaphatunk a támogatónktól.
 

Régi verziók életben tartása

Rövid távon a legegyszerűbb és legolcsóbb megoldásként kínálkozik, hiszen ami 10 éve működik, azt miért dobnánk ki? Tanácsadóként is könnyű és olcsó megoldás ez, hiszen nem kell alkalmazkodni a változásokhoz – mindaddig, míg az ügyfeleket sikerül erről meggyőzni.

Specializálódás

Bár az egyes szoftverek, bővítmények önmagukban egyszerűbbé válnak, gyorsan növekvő számuk és lehetséges kombinációik működése a fent írt komplexitási veszélyeket továbbra is hordozza. Ez azonban egyszerűen korlátozható olyan módon, hogy egy tanácsadó cég nem próbál mindenhez teljes mértékig érteni, ehelyett specializálódni kezd piaci szektorokra, esetleg technológiákra. Ezt a megközelítést jól mutatja, hogy egy adott cég mely területeken van tisztában a legújabb trendekkel.

Saját bővítmények

Amennyiben egy tanácsadó cég fejlesztéseket, testreszabásokat is végez, kézenfekvő számára, hogy újrafelhasználható megoldásokat, bővítményeket készítsen, figyelembe véve azok jelentősen egyszerűsödő üzembe helyezését – így gyorsabb megtérülését.

Tanácsadási szolgáltatások javítása

A felhasználói oldaltól mind kevésbé várható el, hogy tisztában legyen a technológia gyorsuló változásaival. Ehelyett ezt a szakértelmet jogosan a támogatók kell, hogy képviseljék, olyan módon, hogy a felhasználók kifejezetten üzleti igényeire javasoljanak konkrét megoldást. Ugyanakkor ez a megoldás szélesebb perspektívájú a megszokottnál, hiszen lényegesen több, és minőségileg más eszköz (szoftverkomponens) áll rendelkezésre manapság, mint akár néhány éve. Gondoljunk csak például a gépi képfelismerés és –értelmezés ma már minden telefonban jelenlevő technológiájára. A legjobb megoldás megtalálása gyakoribb egyeztetést, szorosabb együttműködést igényel mind az igények megfogalmazása, mind a kínált lehetőségek kiértékelése során.

Gyakorlati tanácsként a következőkben összegezzük a fentieket:
 

• Az üzleti igények fejlesztését ne éves fix IT költségkerettel próbáljuk korlátozni, hanem esetileg, előzetes megtérülés számítás alapján.

• A hosszú átfutási idő nagy kockázatot jelent. Ehelyett törekedjünk agilis elvű, többlépcsős bevezetésre, maximum néhány hónapos ciklusokkal.

• Az egyedi fejlesztési igények esetében mérlegeljük, hogy az üzleti folyamat milyen mértékben válik függővé a megoldástól. Törekedjünk a lecserélhetőségre!

• Üzleti igényeket fogalmazzunk meg, ne technikaiakat! Mérlegeljünk különféle megoldási módokat egy adott problémára, például az üzletmenet átalakítását, kulcsrakész bővítmény/program alkalmazását, egyedi fejlesztést, megtérülési idő és üzleti rugalmasság szerint is.

• Azonosítsuk a támogatónk stratégiáját.

• Törekedjünk arra, hogy az üzleti igényeket megfogalmazó felhasználók gyakran egyeztessenek a támogatóikkal az igényeikről, problémáikról.

Bízunk benne, hogy cikkünk átolvasása rávilágított olyan trendekre, ezek okaira és következményeire, melyek az üzleti célú alkalmazásoknak nem csak a költségeit, de megtérülésüket is jelentősen meghatározzák. Ismeretükben szélesebb látókörű és megalapozottabb döntések születhetnek.

Kollégáink szívesen állnak rendelkezésére IT-szakmai, üzleti folyamatokkal kapcsolatos vagy akár a IT-stratégiai kérdések kapcsán is. Meggyőződésünk, hogy amellett, hogy Ön és a cége helyzetét, elvárásait Ön ismeri leginkább, az IT-világ változásainak követése támasztotta tehertől nagyrészt megszabadíthatjuk, akár egy rövid beszélgetés, akár hosszú távú együttműködés formájában.

Oroz Róbert

Expert AX developer, consultant

Qualysoft Informatikai Zrt.