Az ERP testreszabások költsége
Miért kell (?) a testreszabás és miért kerüljük el

Jelen bejegyzésben a testreszabási költséget vesszük át, mert ez olyan nagy téma, hogy annak érdemes vele külön foglalkoznunk.

2022-10-19_11-28-17.jpg

Mi is az a testreszabás?

A testreszabás az amitől az ERP rendszerünk tökéletesen megfelel az igényeinek, de összeségében véve az iparági tapasztalatok azt mutatják, hogy a nap végén sokkal többet ártanak mint használnak. Ahhoz, hogy ezt megértsük nézzük meg milyen típusai vannak, és azok milyen előnyökkel és hátrányokkal járnak.

  • A rendszer bizonylatainak testreszabása
  • Az ERP folyamatainak módosítása a mi egyedi működésünkhöz.
  • Az ERP illesztése a mi egyedi rendszereinkhez.
  • Egyedi riportok készítése
  • Lokalizácíó

A testreszabást (customization) ne tévesszük össze a konfigurálással (configuration), testreszabás az, ha módosítunk a rendszer valamely folyamatán, hogy nálunk ne úgy működjön mint ahogy az ki lett találva. Konfiguráció meg mondjuk az amikor beállítjuk levelezünk adatait, vagy valutákat és bankunkat és az ehhez hasonló műveletek.

A rendszer bizonylatainak testreszabása

Az ERP rendszerek bizonylatokat és dokumentumokat állítanak el, legyen az gyártási munkalap, számla, szállítólevél, illetve a rendelések dokumentációi. Ezen dokumentumok jellemzően minden ERP rendszerben megtalálhatóak, és jobbára meglelnek a standard igéneknek. Természetesen elképzelhető, hogy mi egy-egy kisebb módosítást kérünk, például egy cikk paraméter megjelenítését a számlán, vagy a szállítólevelén a csomagolási egységek feltüntetését. Ezeknek a kéréseknek meg kell legyenek oldhatóak konfigurációval, mint ahogy a többnyelvűség is. Ha a választott ERP rendszer szállítója ezeket az alap dolgokat testreszabásként valósítja meg nekünk, akkor nem jó ERP választottunk…

Persze vannak olyan kérések -főleg az ajánlatok tekintetében- amikor egy kép, vagy komolyabb dokumentáció válik szükségessé. De ekkor azért gondoljuk át, hogy jók e folymataink? Hiszen ekkor lehet, hogy olyan információkat szeretnénk közölni partnerrel amit már korábban a tudomására kellett volna hozni, főleg ha szerződés partner.

Az ERP folyamatainak módosítása a mi egyedi működésünkhöz.

Nincs két egyformán dolgozó cég, mindenhol vannak olyan egyedi folyamatok (például jóváhagyások) amelyek különböznek más cégek folyamataitól. De ennek ellenére mégis az a célszerű, hogy ahol lehet mi alkalmazkodjunk az ERP-hez és ne ragaszkodjunk annak átalakításához. Azok a folyamatok, amelyek implementálva vannak az ilyen rendszerekben, átgondolt és sokat próbált működés alapján készültek olyanra amilyenek. Gyakori az, hogy egy gyártóvállalat irodai folyamatai nagyon különböznek más hasonló vállalatok működésétől, amit tulajdonképpen semmi nem indokol. Hiszen az ilyen vállalatok az értéket a gyártásban teremtik, az irodában pontosan az történik mint minden más cégnél. Azaz próbáljak kapacitásokat a lehető legjobban kihasználni, az alapanyagokat a legolcsóbban beszerezni, úgy hogy azok rendelkezésre álljanak amikor szükségesek. Továbbá a vevői elégedettségre törekedni a megfelelő profittartalom és pontosság mellett.

Szóval, ha ezektől eltérünk akkor rengeteg problémát veszünk a nyakunkba, hiszen az ERP rendszerek átgondolt folyamatainak megváltoztatása sok helyen, okoz nekünk problémát. Vegyünk egy egyszerű példát: Valamiért a vevőrendelés visszaigazolását egy vezetői jóváhagyáshoz kötjük. Egyszerű eset, hiszen csak be kell vezetni egy új mezőt „jóváhagyva igen/nem”. Igen ám, de ez az egyszerű módosítás rengeteg galibát okoz, mert rendszer működésé során nincs arra felkészítve, hogy vannak olyan rendelések rögzítve amelyek nem kel figyelembe venni. Az anyagszükséglet számol velük és beszerzést javasol rá, hopp akkor máris bele kell nyúlni oda is. A „várható készletet” mutató riportok is tévedni kezdenek, akkor azokba is bele kell nyúlni. Az eladásokat mutató riportok is hibáznak, azt is javítani kell. Arról nem is beszélve hogy számtalan helyen a rendszerben módosításokat kell végezni, ne lehessen gyártást kiírni nem jóváhagyott rendelésre, ne lehessen számlát, szállítólevelet, stb… kiállítani. Folytathatnánk felsorolást, de tisztán látszik, hogy egy kis plusz mező hatalmas galibát okoz.

A fenti példából két dolog következik, ami gyakorta tapasztalnak a felhasználók. Ha a szolgáltató nem látja át módosítás következményeit (sajnos van ilyen is) akkor gyorsan megcsinálja a módosítást, és hibák a felhasználónál jelentkeznek, aki úgy fogja érezni, hogy az ERP nem jól működik. Jelezi hibát, amit majd javítanak, majd nemsokra rá egy újabb hibát talál, ami tovább növeli a ERP-vel szembeni ellenállást, és igy tovább amig a folyamat kerek nem lesz… A másik következmény az, hogy a szolgáltató átlátja azt hogy egy ilyen pici mező is nagy galibát okoz és akkor a testreszabásra adott ajánlat okoz felháborodást, hogy „egy mező felrakása miért ilyen drága és sokára készül el?”

Hogy lehet ezt elkerülni? Meg kell vizsgálni, hogy egy ilyen átalakítás TÉNYLEG szükségese-e? Az aki csinálja a rendelés visszaigazolás rögzítését miért nem tudja jóváhagyni? Ha nincs meg információja akkor adjuk meg neki azt! Ha csak az információgazda rendelkezik elegendő tudással, akkor miért nem ő igazol vissza? Hiszen egy jó ERP-ben ez 2 kattintás….

Persze érthető, hogy sokszor a termelésvezető (aki mondjuk jóváhagy) nem „számítógépes” ember, nem ért hozzá, vagy csak egyszerűen túlságosan elfoglalt. De ekkor gondolkodjunk el azon, hogy tudjunk e úgy érdemben digitalizálni a vállalatunkat, hogy a kulcsemberek ebben nem vesznek aktívan részt. A válasz: nem tudjuk, ami az egyik leggyakoribb oka a sikertelen ERP projekteknek. Hiszen megpróbálunk valamit úgy modernizálni, hogy a kulcsszereplőket a régi környezetükben hagyjuk. Mintha vennék egy új német autót, és azt mondanám a szállítónak, hogy alakítsa át a részemre úgy, hogy régi japán kocsim motorja legyen benne, mert azt már megszokták a kollégák.

Az ERP illesztése a mi egyedi rendszereinkhez

Az ilyen illesztése igen gyakori kérések, de itt is találhatunk kirívóan rossz példákat. Mitől lehet rossz ötlet egy illesztés? Attól, hogy nem integrált rendszerünk lesz. Ha az új ERP-nk tud valamit, amire már van megoldásunk akkor dobjuk mi a régi megoldást. Igen ez drasztikus, de ez egyetlen módszer, amivel hosszútávon is fenttartható rendszer alakítható ki. Hiszen ha két rendszer interfésszelünk, akkor könnyen lehet, hogy valamely rendszer változásakor mindkettőhöz hozzá kell nyúlni. És az ilyen problémák mindig meglepetés szerűek lesznek, amit senki nem szeret. Van olyan móri fémipari cég ahol nyolc ilyen rendszer működik, és feladat ez lett volna, hogy ezeket a szigeteket ölelje tengerszerűen az új ERP, és adjon hozzá egy új funkcionalitást. Lehetetlen feladat. Főleg akkor ha az ügyfél arrogáns és azt gondolja, hogy ért a mi szakmánkhoz. Ebben a konkrét esetben a kereskedő konkrétan azt lódította, hogy a bemutatott rendszer nem is tudja a kért funkcionalitást, csak hogy véget érjen a bemutató…

Akkor, hogy lehet ezt jól csinálni, mire kell figyelni? Arra, hogy az a rendszer, amit mi megakarunk tartani, és elvárjuk hogy kommunikáljon az új ERP-nkel, tényleg olyan érteket teremtsen a számunkra amiért megéri vállalni a nehézségeket. Például az egyedi mérőgépünk eredményei kerüljenek be a gyártási rendelések alá. Amennyiben egy olyan rendszerkapcsolatról beszélük ami megszokott, akkor viszont sokkal levesebb nehézséggel találkozunk, mert akkor általában ezek a szigetek jól fel vannak készítve a kapcsolódásra. Például termelésirányítási rendszer és a könyvelési rendszer kapcsolata, vagy a számviteli gondolkodású ERP és MES kapcsolata. Bár ez utóbbi esetben javasolt inkább egy olyan rendszer választása ami ezt egyben tudja, de sokszor a gyártó leányvállalat már készen kapja a ERP-jét, és neki kell megoldani a gyártást egy külön rendszerben.

Egyedi riportok készítése

Egy jó ERP rendszereben benne kell legyen azok a standard riportok, amelyekkel a napi és szokványos feladatkörökben dolgozó kollégákat megfelelő és jó minőségű adattal lehet ellátni a döntéseik meghozása érdekében. Legyen az erőforrástervezéshez a kapacitás kihasználás, a vevői rendelések állapota, a készletek mindenféle vizsgálata, számlák és szállítók nyilvántartása. Amennyiben ezeket riportokat a szolgáltató külön testreszabásként adja nekünk, akkor kezdjünk el gondolkozni, hogy jó rendszert választottunk e vállalatunk számára.

Természetesen lehetnek és kellenek is egyedi riportok, ami egyedi tevekénységünkre vonatkozó adatokat mutatnak meg a számunkra. Ilyenek lehetnek például az olyan adatok felhasználásával készült kimutatások, amelyek, kívülről (interfészen) érkeznek a rendszerbe. Vagy egy jogos testreszabás következtében keletkezett egyedi adatokat mutatnak meg.

Verzióváltás

A hagyományos (nem felhős) ERP rendszerek esetében pár évente frissíteni kell a rendszert, amely ciklus régebben 6-8 év volt, de mostanában ez már 4-6 év. Maga verzióváltás is önmagában is megér egy külön cikket, de csak a testreszabások szempontjából vizsgálva az mondhatóak el, hogy verzióváltáskor a testreszabások nagy részét újra kell implementálni. Miért van ez? Azért mert mint korábban láttuk egy kis módosítás is érintheti teljes rendszert és az újabb verzióban biztosan másképp kell már ugyanazt a problémát megoldani. Sőt az újabb verziók minden esetben több funkcionalitással rendelkeznek, ezért nagy eséllyel még több helyen kell az adott problémát kezelni. Továbbá az interfészeket is nagyrészt újra kell implementálni, az egyedi riportokat is meg kell vizsgálni, hiszen változhat az adatszerkezet a háttérben.

A másik sok esetben előforduló gond, az hogy a testreszabások sok esetben valami alapvető hiányosságot pótolnak (nem megfelelő rendszer lett választva?). Amely tökéletlenséget a rendszer fejlesztői is igyekeznek az új verzióban pótolni, és biztosak lehetünk abban, hogy mindenképpen másképp mint ahogy a mi testreszabásunkban volt. Ezért vagy újra kell tanulni, a most kapott megoldást, vagy újra kell implementálni a testreszabást….

Lokalizáció

Nem a klasszikus testreszabások közé sorolandó, hiszen minden ERP rendszert alakítani kell helyi törvényi, nyelvi és szabályozási környezetnek megfelelően. Főleg a pénzügyi és számviteli funkciók esetében. Amennyiben ezeket a lokalizációkat a szolgáltató nem licenszként hanem testreszabásként kínálja nekünk, akkor szintén kezdjünk el gondolkozni, hogy jó rendszert választottunk e vállalatunk számára.

Konklúzió

Sajnos nem minden szolgáltató tud mindent megoldani testreszabással, hiszen ha rendszert gyártó céggel tárgyalunk akkor ő hozzáfér a teljes rendszerhez, viszont ha egy disztribúcióval akkor nekik korlátozott eszközeik vannak, mert nem férnek hozzá ahhoz ami a motorháztető alatt van.

A fentiek alapján mindenki számára világossá válhatott, hogy a testreszabás nem jó, a testreszabást nem szeretjük, a testreszabást kerülni kell. Mert állandó problémákat okoz, mindemelett folyamatos költséget jelent számunkra és a szolgáltató számára is. Arról nem is beszélve, hogy a programozói bérek folyamatos emelkedése miatt a testreszabások egyre drágábbak és fenttartási költségük is növekszik.

Mi megoldás? Először is gondosan válasszunk rendszert magunknak, figyelve arra, hogy az lehető legjobban illeszkedjen az igényiinkhez. Másrészt törekedjünk az olyan rendszerek alkalmazására amelyek konfigurációval megoldanak minden beállítást. Mert úgy egyszerűbben kezelhető rendszert kapunk, nagyságrendekkel kisebb költségek mellett.

ERP-Blog
2022

A bejegyzés trackback címe:

https://erp-blog.blog.hu/api/trackback/id/tr5917957710

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.
süti beállítások módosítása