Az interneten az ERP rendszerbevezetések statisztikái után kutatva azt látjuk, hogy az ERP bevezetések ötöde nem sikeres. Sok tanácsadó cég készít ERP riportokat, melyek bár viszonylag kis merítésből dolgoznak és ezért a különböző számok között elég nagy a szórás, de a trendek azért tetten érhetők.
~20% a sikertelen projektek aránya, ez régebbi riportokkal összehasonlítva csökkenő tendenciát mutat. Ugyan ennyi azoknak az aránya, akik nem tudják megítélni a projekt sikerességét, ezért ezeket a bevezetéseket is sorolhatjuk a sikertelen kategóriába, mert a rendszer ugyan működik, de ezek szerint nem jár kimutatható üzleti előnnyel.
~70% választaná újra ugyan azt a megoldást, ez növekvő tendenciát mutat. Ebből, arra következtethetünk, hogy maguk a megoldások alapvetően kiszolgálják az igényeket.
De ha nem a megoldások képességei, akkor mik a sikertelen ERP bevezetések fő okai? Egy ERP bevezetés sikerét valóban nehéz értékelni, ha:
Ha ez az ok, akkor annak a gyökere az, hogy az ERP bevezetéseket jellemzően nem üzletfejlesztési, hanem IT projektként kezelik, pedig egy ERP bevezetésnek a vállalat új működési minősége a célja, súlyos szervezeti változásokat követelve, gyakran ellenérdekeket szülve a szervezeten belül. Mivel egy ERP bevezetése a legkomplexebb projektek között van, ezért érthető, hogy nem sikerülhet kompromisszumok nélkül, hiszen a bevezetés során nagyon sok szempontra kell figyelemmel lennünk.
Megtérülés
A bevezetés licensz és tanácsadási/fejlesztési költségeivel az ajánlatkérést követően mindenki tisztában van, de a megtérülést kevesen ellenőrzik, ha mégis, akkor jellemzően utólag, nem előzetesen. A bevezetést követő támogatási és upgrade költségeket, valamint a belső erőforrás és hardver költségeket is figyelembe kell venni, amikor azt kalkuláljuk, hogy mennyibe kerül a rendszer működtetése hosszú távon. Ha ez elmarad, az erősen torzítja a rendszer megtérülését.
Stratégia
Minden ilyen volumenű változásnak stratégia indíttatásúnak kellene lenni, és a projekt során, minden döntésnél vizsgálni kell a lehetséges irányok és stratégiai célok összhangját. Ezzel garantáljuk azt, hogy a bevezetés elérje a célját.
Fejlesztési tervek
Minden bizonnyal vannak különféle fejlesztési tervek, akár szervezeti egységenként is, de ezek a tervek sok esetben nincsenek összhangba hozva a projekt céljaival, pedig bizonyosan lesznek kapcsolódási pontok. Ezek figyelembevételével biztosíthatjuk, hogy minden érintett terület profitálhasson a bevezetésből.
Csapatok, szervezeti egységek
Minden szervezeti egységet be kell tudni vonni a projektbe, olyan embereket kell a bevezető csapatba delegálni, akiknek rálátása van az adott szervezeten belüli folyamatokra és nem hátrány, ha konstruktív javaslatokkal a változásoknak sem állnak ellen.
Felhasználói igények
Ne feledjük, hogy végső soron a felhasználók működtetik az egész rendszert, így rajtuk áll, hogy éles indulást követően mennyire lesz zökkenőmentes a működés. A végfelhasználó elégedettsége kiemelt fontosságú.
Változások
Elkerülhetetlen, hogy egy ERP bevezetése a szervezetet, üzleti folyamatokat, informatikai kultúrát is változtatásra kényszerítsen, ezek ellenállást fognak szülni, melyeket kezelésére már külön iparág szakosodott. Az érintettek korai bevonásával ez az ellenállás jelentősen csökkenthető.
Érték szemlélet
Minden vállalkozás valamilyen terméket állít elő a vevői számára, legyen az akár megfogható árucikk, akár szolgáltatás – a cél mindig az, hogy ezek a termékek a lehető legjobb minőségben, optimális folyamatokon keresztül a vásárló maximális megelégedettségére juttassuk el. Ezt kell támogatni az ERP rendszerben kezelt folyamatoknak is, a lehető legkisebb adminisztratív többletmunkával.
Minőség
A költség és az idő mellett ez a projekt harmadik sarokpontja, ezek csak egymás rovására növelhető, illetve csökkenthetők. Ne várjunk el kiemelkedő bevezetési minőséget, ha a legolcsóbb megoldást vagy bevezető partnert választjuk.
Kommunikáció
A projekt eredménye szempontjából vannak érintettek és érdeklődők, mind szervezeten belül és kívül is. Ők mind profitálni szeretnének az eredményből és mivel mind hatással lehetnek az üzletre, a véleményüket érdemes figyelembe venni. Pl. a vevőink nagyobb rálátást szeretnének a rendelési folyamatukra, a szállítóink szeretnék látni a készletek fogyását, hogy az alapján optimalizálhassák a gyártásukat.
Ha valakinek ezek alapján máris elment a kedve attól, hogy belevágjon, megnyugtathatom, ez nem is olyan bonyolult. A siker kulcsa a fókuszáltság:
1. Célok meghatározása
A projekt döntések sorozata lesz, a jól meghatározott célokra bármikor támaszkodhatunk, ha egy döntés során elbizonytalanodnánk. A cél meghatározása nem csak az utólagos mérhetőséget biztosítja, hanem szamárvezetőként segít minket a teljes projekt életciklusa alatt. A stratégiai indíttatású célok jelentenek a szervezet egésze számára olyan – jól kommunikálható – motivációt, mely nélkül egy komplex projekt ritkán lehet sikeres. A külső indíttatású vagy lágy célok nem jelentenek elegendő motivációt ahhoz, hogy sikeresen végig vigyük a projektet (ezek a projekt végén egyébként is nehezen mérhetők).

2. Cél eléréséhez szükséges képességek meghatározása
Ha adott a cél, akkor az eléréséhez szükséges üzleti képességek lebonthatók követelményekre. Ezt érdemes több lépésben elvégezni:
Felülről lefelé haladva nőhet a kompromisszumkészség, vagyis a hajlam a sztenderd megoldásokhoz való alkalmazkodásra. Minél nagyobb ez a hajlam, annál több költséget spórolhatunk mind rövid (testreszabások, egyedi fejlesztések), mind hosszú távon (támogatási keret, upgrade).
3. Architektúra kialakítása
Miután összeállítottuk a követelményeket, érdemes a funkciócsoportokat szétválasztani statikus és dinamikus igényekre.
- Statikus igénybe sorolhatunk olyan funkció területeket, melyek várhatóan nem fognak nagymértékben változni a következő 5 évben (ilyen lehet pl. a pénzügy, könyvelés funkcionalitás)
- A dinamikus követelmények a piac és a vevői igények várható változásai miatt rugalmasabb beavatkozásokat igényelnek, tipikusan ilyen funkció csoportok a customer facing megoldások
A dinamikus követelményeket kiszolgáló IT megoldásoknak könnyen módosíthatóknak kell lenniük, akár folyamat szinten is és ha a célunk pl. a forgalom növelése volt új csatornák nyitásával, akkor a megoldásnak akár napi szinten skálázhatónak, integráció tekintetében pedig gyorsan testreszabhatónak kell lenni (pl. egy új csatornán érkező rendelések rendszerbe integrálásával nem várakozhatunk hónapokig). Könnyű belátni, hogy a felhőben elhelyezett megoldás külső kapcsolatainak átalakításánál, a saját belső hálózatunkat nem kell módosítani, így azok gyorsabban, költséghatékonyabban integrálhatók.
Ezt felismerve a nagy ERP gyártók már jó ideje igyekeznek az ügyfeleiket a felhőbe csábítani, láthatóan sikerrel. A felhő technológiáknak megvan az az előnyük, hogy a mögöttük lévő infrastruktúra dinamikusan skálázható és a rendelkezésre állásuk szerződéses SLA-k alapján garantált. Emellett az ügyfél által is elvégezhető testreszabási lehetőségek tárháza is folyamatosan bővül.
4. Felhasználói igények
Csak itt kezdjük el vizsgálni a megoldásokat, ezek lesznek a nem-funkcionális követelmények. Ide tartoznak a felhasználói igények mellett a biztonsági, technológiai és egyéb megfelelőségi követelmények. Ezen a ponton kezdjük csak el vizsgálni az egyes megoldásokat. A funkcionális és nem-funkcionális, valamint kereskedelmi és támogatási követelményeink alapján már leszűrhettük a lehetséges megoldás szállítókat néhány szóba jöhető rendszerre. Ha ezek összemérhetők, akkor a különbséget a rendszerek és a bevezető partnerek képességei jelenthetik.
A nem funkcionális követelmények meghatározásához gondoljuk át mire lesz szükségük a felhasználóknak a hatékony munkavégzéshez. Pl:
- Adjunk teret a felhasználók kreativitásának azzal, hogy nem betonozunk be bizonyos folyamatlépéseket
- Testreszabható, komfortos és ’tetszetős’ felhasználói felület
- Optimális minőségű oktatás, mely nem csak a funkciókat mutatja be, hanem kontextusba is helyezi a folyamatok lépéseit, céljait, hatását
- Jól használható felhasználói és üzemeltetői dokumentáció, példa eseteken keresztül segítve a megértést
- Felhasználói támogatás, mind vállalaton belül, mind a támogató partner felől
- + extra képessége a szállítónak, ha BPR előzte meg a rendszer bevezetését, ennek eredményei dokumentáltan és naprakészen a felhasználók rendelkezésére állnak. Jó példa erre egy olyan többszintű, a teljes vállalati működést lefedő folyamat modell, melynek legalsó szintjén a felhasználók által a rendszerben elvégzendő folyamatlépések vannak kifejtve, képernyőképekkel, példa esetekkel.
A fenti szempontok figyelembevételével összeállított követelményeink birtokában már magabiztosan vághatunk bele a megfelelő megoldás kiválasztásába, annak megnyugtató tudatában, hogy a tipikus hibákat elkerültük. A következő tanácsokat lehet még érdemes megfogadni a bevezetési kockázatok enyhítésére:
Nem kell teljes funkcionalitással indulni, szakaszolva felhasználhatjuk a tapasztalatokat.
Az a cél, hogy végül a felhasználók csak értékteremtő munkát végezzenek. A teljes bevezetési folyamatot szakaszokra bonthatjuk, nem kell minden esetben teljes funkcionalitással elindítani a rendszert. A szakaszolt indulás előnye, hogy a használati tapasztalatok alapján a következő szakaszok finomhangolhatók, a használat során előállt adatok elemzéséből leszűrt információk alapján.
Minél előbb vonjuk be a felhasználókat, annál kisebb ellenállást kell majd leküzdenünk.
Ennek legjobb módja, a korai, sztenderd rendszeroktatás. Ezzel csökkenthetjük is a szükséges testreszabások arányát és növelhetjük az elköteleződést. A felhasználói frusztrációk elkerülése érdekében olyan felhasználói útmutatókat alakítsunk ki, melyek folyamat orientáltak és példa eseteken keresztül segítik a megértést. A későbbi módosítások során ezeket karban is kell tartani. Nagymértékben csökkentik a felhasználói frusztrációt a hibaelkerülő megoldások, mint az adatvalidációk és különféle automatizmusok.
Fogadjuk el és alkalmazzuk a legjobb gyakorlatokat, hogy időt és költséget csökkentsünk.
A bevezetéssel a projekt ugyan lezárult, de a munka nem ért véget, hiszen a világ változik, az igények változnak, az üzletet fejleszteni kell, egyre több folyamat automatizálható, annak érdekében, hogy a felhasználóknak csak az értékteremtő, kreatív munkájukkal foglalkozhassanak.
Szerző

Pap Norbert
Szenior tanácsadó
Technológiai tanácsadás
+36 1 428 6800