ERP: kockázatok és mellékhatások
Az, hogy milyen kockázatokkal kell számolni egy vállalatirányítási rendszer (ERP) bevezetésénél, önmagában egy erős, 100 oldalas téma lehetne. De az alábbiakat mindenképpen érdemes a vezetői teamnek, vagy abból az ERP teambe delegált tagoknak közösen végig gondolni.
Képesek vagyunk-e cégszinten projekteket sikeresen működtetni? Mik az előző projektjeink legnagyobb hibái? Hogyan tudjuk azokat elkerülni?
A hibás projektdöntéseket sok cégnél inkább elhallgatják, mint hogy tanulásra használnák. Fontos, hogy a projektjeinket objektíven értékeljük, és ne a személyi retorzió legyen a cél, hanem hogy a szervezet tanuljon a hibákból, fejlődjön.
Képesek vagyunk-e az igényeinket pontosan megfogalmazni, leírni, majd összvállalati szinten priorizálni?
Ez az egyik legnagyobb hibalehetőség ügyfél oldalról. Egyszerű példával szoktuk ezt szemléltetni: ha építkezés előtt mindig készíttetünk egy hozzáértő építésszel pontos tervrajzot, majd kivitelezési tervet, és csak ezután vágunk bele a kivitelezők versenyeztetésébe, miért tennénk ezt másként a cégünk egyik legfontosabb projektjénél? A dokumentált igényspecifikáció a projekt lelke. Ha szánunk rá időt és energiát, és nem 12 oldalas fércművet gyártottunk, akkor máris van esélyünk rá, hogy a projektünk ne kerüljön bele a képzeletbeli „Hogyan ne vezessünk be ERP rendszert?” kézikönyvbe.
Ha teljes funkcionalitású ERP rendszert szeretnénk egy lépésben bevezetni, akkor a teljes működésre vonatkozó üzleti folyamat áttekintése elengedhetetlen. Nem elég, ha a 3 éve a polcon porosodó SzMSz-t kimásoljuk, mert az élet azóta biztosan produkált változásokat. Amikor mi, az erp-consulting.hu szakértői dolgozunk, rendszeresen ellenőrizzük, hogy a szabályzatokban leírt és a valós folyamatok között mekkora az eltérés (GAP). Minél nagyobb a különbség, annál nagyobb a kockázat, hogy a szállítót elvisszük a málnásba az igények meghatározásánál, és máris kockázatos útra vittük a projektet. Azt írjuk le, és úgy, ahogy valójában működünk.
Mivel a cégek szeretnek fix áras projektekben megállapodni a szoftverszállítókkal, fontos, hogy ne árazzák be annak a kockázatát, hogy az ügyfél azt mondja a projekt közepén: „nem pont erre gondoltam”! Ehhez pedig egy pontos igényspecifikációt kell adnunk, amihez a belső BPR projekten (Üzleti folyamatok átalakítása) keresztül vezet az út.
Forrás: Computerworld