A legtöbb ERP szoftvercég saját bevezetési módszertannal rendelkezik, mely leggyakrabban a Waterfall/vízesés módszertanra épül. A fázisok, a munkatermékek neve természetesen ebből következően lehet más, de a lényeg általában ugyanaz.
"Cover your ass" - vagyis fedezd le a feneked
Ezt még kezdő tanácsadó koromban tanította nekem egy tapasztalt svéd konzulens. Vagyis ahhoz, hogy a szoftvercég a későbbi vitákat megelőzze, igyekszik megfelelően dokumentálni a projekt minden egyes lépését. Ügyfélként azonban kétszer olyan fontos, hogy minden megállapodás, változtatási igény, alku stb. írásban legyen meg. Anélkül egy esetleges vita alkalmával nincs túl sok muníciónk. Vagyis a saját projektvezetőnk - és lehetőleg a mellé kinevezett projektasszisztens - legalább a saját hálózaton létrehozott könyvtárstruktúrában tároljon el minden dokumentumot, követve azok verzióváltozásait. Minden egyes megbeszélésről szülessen egy rövid emlékeztető, amit legalább e-mailben igazoljon vissza a szoftvercég projektvezetője. Amíg minden jól megy, persze ez nem látszik fontosnak, de egy vita esetén aranyat ér az előrelátásunk.
A felmérési fázis és a modellezési fázis
A szerződéskötés után jön a mélyebb ismerkedési fázis. Ekkor a szoftvercég modul vagy téma konzulensei igyekeznek a projekt szkópjának (terjedelmének) megfelelően felmérni az összes érintett folyamatot, ki- és bemeneti dokumentumot, bizonylatot. Nagyon sok kérdést tesznek fel, és gyakran már ekkor felvetnek megoldási lehetőségeket. Vagyis, hogy adott üzleti igényt A, B és C módon tudják megoldani. Megmutatják melyiknek mi az előnye, hátránya. Javaslom, hogy ilyenkor kérjünk írásos dokumentációt minden alternatíváról, hogy ne ad hoc döntések szülessenek, és rész folyamatokra optimalizáljunk, hanem a menedzsment közösen, a cég összesített igényeinek megfelelően optimalizáljunk. Mivel a szoftvercég fix áras szerződés esetén ellenérdekelt a sok konzulensi időt igénylő megoldásokban, érdemes ügyfél oldali, független szakértőt alkalmazni, aki segít nekünk eldönteni, mi számunkra a valóban legjobb megoldás.
A felmérési és modellezési fázis végén a szoftverszállító átad egy részletes dokumentációt, melynek alapján a cégvezetés döntési ponthoz kerül, hiszen a vállalat üzleti folyamatait kisebb vagy akár nagyobb mértékben érdemes/szükséges megváltoztatni ahhoz, hogy az új ERP rendszerünk adta lehetőségeket minél jobban ki tudjuk használni. (A modellezési szakaszra természetesen már egy letelepített ERP rendszerrel kell rendelkeznünk, megfelelő jogosultságokkal beállítva. Mivel a szoftverszállítók jellemzően a szerződéskötéskor már szeretik a licenc díjakat kiszámlázni felénk, jobb is, ha minél előbb letelepítésre kerül a rendszer, és az informatikusaink elkezdik "belakni" a rendszert.)
A döntésről, miszerint melyik folyamatot, szervezetet hogyan szeretnénk megváltoztatni természetesen - ezt mostanra szerintem mindenki tudja már - írásban tájékoztatjuk a szoftverszállító cég projektcsapatát.
Rendszer testre szabási fázis
Ebben a fázisban az elfogadott koncepcionális dokumentációnak megfelelően beállításra/paraméterezésre kerül a rendszer.
Ha szükség van fejlesztésekre, azok is jellemzően ebben a szakaszban készülnek el. A fejlesztések átadása hosszú folyamat, érdemes időben elkezdeni, hogy a szükséges tesztelésekre, kulcsfelhasználói és végfelhasználói oktatásokra maradjon elegendő idő.
A vállalati adatvagyon új rendszerbe történő integrálása, az adatmigráció főként a nagy tranzakciószámon, nagy partnerszámmal, sok termékkel pörgő cégek esetében hatalmas munka. Ennek kézben tartása mindenképpen ügyfél oldali feladat, érdemes azt átgondoltan, konkrét időterv mentén, kvázi mini alprojektként kezelni.
Mintatermi tesztelés
Ahhoz, hogy tesztelni tudjunk, előtte részletesen meg kell ismernünk a ránk szabott ERP rendszer működését, funkcionalitását, lehetőségeit. Kritikus pont, és a szerződéses szakaszban érdemes erre figyelni: a szoftvercégek nem szeretnek felhasználói leírást készíteni. Az ok egyszerű: iszonyú munkaigényes feladatól van szó. Ne hagyjuk, hogy ránk tolják ezt a feladatot, akár a szerződés mellékleteként tegyünk bele egy minta oktatási anyagot, hogy milyen szintű dokumentációt várunk el. Az ügyfél oldali tanácsadó segít majd ebben.
Ebben a szakaszban egyre több feladat hárul az ügyfél oldali kulcsfelhasználókra. Nem ritkán a munkaidejük akár 70-80 százalékát is kiteszik a tesztelési feladatok. Természetesen itt is minden tesztelést dokumentálunk, tesztelési jegyzőkönyv formájában. Teljesítésigazolást csak abban az esetben írjunk alá, ha minden, az adott fejlesztéshez kapcsolódó funkció tökéletesen működik. Érdemes figyelni arra is, hogy mindig egy kicsit tartsunk vissza a teljesítéshez képest a kifizetésekben is, ezzel is motiválva a szoftverszállítót a pontos munkára.
Éles-használat előkészítése
Ahhoz, hogy ne érjen minket meglepetés, folyamatosan kontrollálni kell, hogy hol tartunk az eredeti tervekhez képest, időben, költségben, feladatban. Az éles indulásra minden fontos feladattal közel hasonló szinten kell állnunk: az adatbázisokkal, a törzsadatokkal, paraméterezéssel, a fejlesztésekkel, és az oktatásokkal. Még soha nem láttam olyan projektet, ahol ez a szakasz mosolygósan és kényelmesen telt volna. Az igazság az, hogy ilyenkor már a legtöbb cégnél kimerülnek a kollégák, adódnak kérdések, félelmek, amik miatt sokan inkább átütemeznék az éles indulást. Ilyenkor is jól jön a tapasztalt ügyfél oldali projekt minőségbiztosító, aki segít nekünk helyes döntést hozni.
Ebben a szakaszban történik általában a végfelhasználók oktatása is. Ezt a feladatot általában a kulcsfelhasználók látják el, de érdemes a szoftverszállító helyszíni támogatását kérni ebben - gondoljunk erre már a szerződéskötési fázisban is!
Go live - Éles-használat kezdete
8-14 hónap akár, mire ide eljutunk. A legizgalmasabb pillanat, amikor a kollégák a teljesen új rendszert el kezdik a napi munka során "élesben" használni. Természetesen fontos, hogy pontos tervünk legyen erre a szakaszra is, hogy kinek mi a dolga, ha bármilyen probléma adódna. A szoftverszállítótól érdemes erre a szakaszra kiemelt támogatást venni, nem csupán az első pár hátra, hanem legalább 2 hónapra. Hiszen attól, hogy az első hónapban a logisztika, termelési folyamatok mennek, még a következő hónapban, amikor először készül pl. ÁFA bevallás ebből az új rendszerből, szükséges a szakértői támogatás.
Az éles indulást követő 60. nap környékén érdemes lezárni a projekt első szakaszát egy projektzáró értekezlettel. Minden nyitott kérdést le kell dokumentálni, és akár a projekt költségvetés egy részt visszatartani mindaddig, míg nem varrtunk el minden szálat. Ha minden rendben ment, itt a kiváló alkalom egy kis ünneplésre is, ahol egy projektzáró vacsora keretében minden érintett - ügyfél, szoftverszállító, ügyfél oldali tanácsadó - kicsit lelazulhat.
Egy ERP rendszer kicsit olyan, mint egy családi ház: mindig van vele feladat, soha nem szabad elhanyagolni, mert az a későbbiekben megbosszulhatja magát. A verziókövetések, törvényi változások, igényváltozások, újabb interfészek, modulok folyamatos feladatot adnak majd. Ha azonban eddig eljutottunk, már megedződtünk ahhoz, hogy ezt képesek legyünk sikeresen menedzselni.
A szerzőről:
Kulcsár Alexandra a Norex ERP technológia- és szállító-független informatikai tanácsadó oldal tulajdonosa, a Computerworld online ERP blogját vezető szakértője, a Magyar Startup Kézikönyv társszerzője. 20 év alatt mintegy 100+ ERP projektben szerzett tapasztalatait magyar és nemzetközi tulajdonú termelő és szolgáltató cégeknél hasznosítja. Kérdése van? Írjon az info@norexerp.hu e-mail címre.