Ritka, hogy egy rendszert egyáltalán nem kell az adott vállalat igényeihez szabni, hanem úgy jó, ahogy azt a fejlesztők kitatlálták. Egy 2013-as felmérés, melyet az amerikai Panorama Consulting Solutions készített, azt mutatta ki, hogy az ügyfelek szinte mindegyike – a válaszadók 90 százaléka – igényelt kisebb-nagyobb módosítást az alaprendszeren. Arról azonban megoszlanak a vélemények, mennyire előnyös ez a lehetőség...
A téma május 7-8-án a CIO Hungaryn is terítékre kerül. Ön már regisztrált?
Néhány éve sajtóvisszhangot is kapott a dán központú Maersk Line esete. A szállítmányozási cég az SAP ERP Financials bevezetése során olyannyira hozzáigazított az egyes részlegi igényeihez, hogy gyakorlatilag a felismerhetetlenségig megváltoztatva az eredeti rendszert. Csakhogy ez az egész projekt úgy ahogy van, megbukott. Végül kénytelenek voltak a rendszert gyakorlatilag a nulláról újra implementálni, és kialakítani a vállalaton belül az ERP-funkcionalitást. Emellett be kellett vezetni a részlegek által kért változtatások szigorú tesztelését is azok automatikus elfogadása és alkalmazása helyett. Ez persze jó reklám volt az ERP szállítójának, mivel igazolta, hogy nem feltétlenül rossz az, ami a rendszereében látszólag talán ellentmond a rendszert bevezető vállalat folyamatainak. És persze jó reklám az összes ERP-szállítónak.
Mint az alábbi grafikonból jól látható, a cégek jelentős része óvatos a testre szabással kapcsolatban: 36 százalékuk esetében a kód kevesebb mint 10 százalékát kell módosítani a bevezetés folyamán, és további 10 százalékuk nyilatkozott úgy, hogy egyáltalán nem igényel módosításokat. Érdekes, hogy a Panorama Consulting felmérése szerint mindössze a válaszadók 4 százaléka vág bele olyan jelentős változtatásokba, amihez módisítani kell a kód több mint felét. Az egyedi fejlesztések aránya pedig elenyésző.
Sokváltozós történet
Egyáltalán nem mindegy, hogy milyen mértékű változtatásról van szó. A leglátványosabb, de az általános működést talán legkevésbé befolyásoló művelet a kezelői felület (user interface – UI) egyéni kialakítása. Lényegesen fajsúlyosabb változást jelent a riportok, dokumentumok és űrlapok testreszabása, és legalább ekkora hatással vannak a munkafolyamatokat érintő módosítások is. Említést érdemel még a harmadik féltől származó (3rd party) alkalmazásokkal való integráció, illetve a meglévő funkcionalitás kiterjesztése és módosítása.
Már az is kaotikus működést eredményezhet, ha csak egy-egy területen történnek mélyreható változások, hát még az, amikor több (vagy minden) téren belenyúlnak egy ERP-rendszer „lelkébe”. De nem csak a folyamatok összehangolása miatt lehet problémás a testreszabás, egy prózai – pontosabban technikai – ok is, ami a „szétkonfigurálás” ellen szól: mint minden rendszernek, az ERP-megoldásoknak is szükségük van frissítésekre. Csakhogy az egyéni beállítások nem feltétlenül kompatibilisek a frissítésekkel. Ettől aztán egy frissítés felrakása akár meg is akaszthatja az addig többé-kevésbé zökkenőmentesen működő rendszer működését, amit csak újabb – igencsak erőforrás-igényes – testre szabási procedúrával lehet helyrehozni.
A kulcs a megfontolt testre szabás: csak akkor és azt szabad/kell módosítani, amikor és amit feltétlenül szükséges, és csak azokon a területeken, melyek kézzelfogható és jelentős előnyt nyújtanak a vállalatnak. Legalábbis ez volt a vezérlőelv a közelmúltig; a fejlesztők ugyanis folyamatosan igyekeznek ügyfeleik igényeihez alkalmazkodni. Így a frissebb verziók már rugalmasabbak, könnyebben konfigurálhatók elődeikhez képest. A Unit4 például épp azzal hirdeti ERP rendszerét, hogy modulárisan építkezik, és az egyes modulok egyenként testre szabhatóak.
Jelentősen csökkenthető a testreszabásból bekövetkező problémák száma és mértéke iparág-specifikus szoftverek (szolgáltatások) alkalmazásával. A vállalati erőforrás-menedzsmenttel foglalkozó fejlesztők jelentős része különböző funkcionalitást képes nyújtani az egyes szektorok képviselőinek, legyen szó pénzügyi, kereskedelmi, kormányzati stb. szervezetről. Az igazán proaktív CIO-k viszont nyomon követik azt is, milyen funkcionalitással bővül a közeljövőben az általuk használt megoldás következő változata. Adott esetben elegendő lehet pusztán megvárni a verziófrissítést, és a rendszer "patkolása" helyett alaphelyzetben elérhető lesz a kívánt funkcionalitás.
Segítő kezek
Természetesen a legnagyobb segítséget a testreszabásban a fejlesztő nyújthatja – ezt a szolgáltatást minden nagyobb vendor fel is szokta kínálni ügyfeleinek az alapnak tekinthető bevezetési szolgáltatás és technikai támogatás mellett. Sok szállító az ERP-eszközéhez egyéni fejlesztői szolgáltatást is kínál, ami azt is biztosítja, hogy a változtatásokra is lesz terméktámogatás.
Az ügyfelek kegyeinek elnyeréséért folytatott harcban egyébként olyan, egészen meghökkentőnek tűnő eszközök is felbukkannak, mint külső, harmadik fél által készített forráskódrészlet feldolgozása és a központi ERP-megoldásba való beemelése.
Természetesen mindent nem oldhat meg a partner. A belső folyamatoknak is támogatniuk kell az ERP-változáskezelést. Gyakran előfordul, hogy a vállalatok nem hagynak elég teret – időt és pénzt – erre, abból indulva ki, hogy az alaprendszer megfelelő lesz céljaiknak, állítja a fent említett felmérést készítő Panorama Consulting Solutions alapítója és vezetője, Eric Kimberling. A felismerés pedig keserű: a testreszabást előre meg kell(ett volna) tervezni. A következmények is előre megjósolhatók: vagy leáll a projekt, vagy olyan káosz születik belőle végül, mint a fent említett Maersk Line esetében.
A NIS2-megfelelőség néhány technológiai aspektusa
A legtöbb vállalatnál a megfeleléshez fejleszteni kell a védelmi rendszerek kulcselemeit is.
CIO KUTATÁS
TECHNOLÓGIÁK ÉS/VAGY KOMPETENCIÁK?
Az Ön véleményére is számítunk a Corvinus Egyetem Adatelemzés és Informatika Intézetével közös kutatásunkban »
Kérjük, segítse munkánkat egy 10-15 perces kérdőív megválaszolásával!
Nyílt forráskód: valóban ingyenes, de használatának szigorú szabályai vannak