Sokszor előfordul, hogy rengeteg árulkodó jel van egy ERP bevezetési projektben, de mégsem lép időben az ügyfél, pedig megfelelő változtatásokkal még menthető lenne a projekt.
A nemzetközi statisztikák siralmasak: minden második integrált vállalatirányítási rendszer bevezetés nem sikeres - vagy tovább tartott, vagy többe került, vagy az eredeti funkcionális igényeknek csak egy részét sikerült megvalósítani. A legrosszabb esetben ezek mindegyike bekövetkezik.
Elkerülhetőek ez a helyzetek?
Azt gondolom, igen. Megfelelő előkészítés, tapasztalt ügyfél oldali tanácsadó segítsége és gondos projektmenedzsment esetén.
Mit tegyünk, ha a csontjainkban érezzük, gond van a projekttel?
Válsághelyzetbe jutott, vagy "problémás" projektek esetében, ahol előfordul a jelentős határidő csúszás, költségtúllépés, ajánljuk az időközi Projekt auditot.
Mi az a projekt audit és mire jó?
A projektaudit célja a projektvezetés gyenge pontjainak feltárása (erőforrás, dokumentáció, kockázatkezelés, változásmenedzsment, minőségbiztosítás, információáramlás) és javaslattétel a gyengeségek kiküszöbölésére.
Hasonlóan, mint egy klinikán, a cél az audit során feltárt hiányosságok megállapítása, a diagnózis felállítása, és javaslat a gyengeségek "gyógyítására".
Lehet magát a teljes projektet auditálni, vagy csak az ERP rendszer funkcionalitását vizsgálni, vagy az egyéb rendszerekhez történő integráltságát.
Az alábbiakban a teljes körű projekt audittal foglalkozunk, felvillantva a legfontosabb vizsgálandó témákat.
A projekt audit jellemzően 3 fő területet vizsgál:
1. A szoftver kiválasztás
- A kiválasztási szakaszban a megfelelő rendszerek kerültek képbe?
- Az ügyfél pontosan és jól körül határolható módon írta le, mik a funkcionális igényei? A szállító számára egyértelmű volt a terjedelem?
- A tendereztetési dokumentáció megfelelő volt?
- A szerződéskötés előtt kiderültek olyan funkcionális lyukak az adott rendszer megismerése során, amelyek kritikusak?
- A szerződéskötés előtt a szoftver szállító kapott lehetőséget megismerni a cég sajátos folyamatait, a vezetői elvárásokat?
- Részletes, pontos árajánlatot kapott a cég? Az eredeti terjedelem mellé reális áron szerződött az ügyfél?
- Az ajánlatok értékelése minden szempontot figyelembe vett, vagy csak az árak ajánlottak választották a rendszert?
- Milyen párhuzamos projektek zajlottak az ügyfélnél?
- A szállítói szerződésekhez mellékletként csatolták a pontos műszaki tartalmat, a kialakítandó rendszer terjedelmét, a készítendő riportok és bizonylatok listáját stb.
- Jogász és független szakértő segítségével zajlottak a szerződéses tárgyalások?
Kérdőívekkel és személyes interjúkkal, valamint a projekt dokumentációjával lehet ezeket a kérdéseket feltárni. Ezek sok esetben kínos kérdések, számos közülük személyes felelősséget is feszeget. Fontos, hogy ne bűnbankot keressünk, hanem azonosítsuk be az összes olyan körülményt, mely a problémára kritikus hatással van.
2. Kivitelezési szakasz
- Megfelelő volt a projekt tervezési szakasza?
- Az ütemezés életszerű volt, vagy már alapvetően rohanósak voltak a határidők?
- Megfelelő mennyiségű és minőségű emberek ültek mindkét oldalon?
- Ügyfél oldalon van-e belsős vagy akár külsős tapasztalt ERP projekt vezető? (Itt a 10+ év tapasztalat, 20+ projekt az elvárható)
- Szállító oldalon megfelelően felkészült, dedikált projektvezetői, tanácsadói és fejlesztői erőforrás állt rendelkezésre?
- Változott-e jelentősen a projektszervezet a projekt során?
- Változott a két cég helyzete a projekt során?
- Az üzleti környezet változott a projekt során?
- Megfelelően előkészítettek a törzsadataink?
- Elég jó minőségűek az adataink?
- Megfelelőek voltak az oktatások? Visszamérték a munkatársak milyen szinten értették meg és képesek használni a szoftvert?
- Írásban zajlott a kommunikáció?
- A változtatási igények dokumentáltak?
Számos aprónak tűnő probléma, hiányosság és pontatlanság összeadódásából adódhat akár az is, hogy súlyos, kritikus hibák történnek egy projektben. "Cover your ass" - vagyis védd le a feneked: ez ügyfél oldalon is alapfeladat: ha gondunk adódik a projekttel, valamilyen határidő csúszást, vagy problémát észlelünk, azonnal és ÍRÁSBAN kérdezzük meg az okát, kérjünk pontos indoklást. A projekt státuszolásának elmaradása az egyik leggyakoribb ok, amiért félre mehetnek a projektek.
3. Projekt költségek
- Fixáras vagy ún. time/material alapú volt a szerződés?
- Mérföldkövekre bontott volt a projekt?
- Megfelelően szakaszolt volt a szerződés pénzügyileg is?
- Vállalt jóteljesítési garanciát a szállító?
- Van projekt felelősségbiztosítás a szoftvercégnek?
- Valódi teljesítések után történtek csak kifizetések?
- Ha nem volt a szakasz/mérföldkő teljesítése hibátlan, történt pénzügyi visszatartás?
- A szükséges fejlesztések átvétele előtt történt tesztelés?
Természetesen a kialakult helyzettől, a probléma súlyosságától függően számos egyéb szempont vizsgálata szükséges lehet, ezek azonban jelentősen túlmutatnak egy cikk terjedelmén.
A független ERP szakértő által készített ERP projekt audit dokumentált jelentéssel zárul.
Érdemes utólag is auditálni egy ERP projektet?
Lezárult projektek esetén a projekteredményeket vetjük össze az eredeti tervekkel, így visszamérve a projekt sikerét, hatékonyságát.
Ilyenkor már ritkán van lehetőség a projekt eredeti céljainak elérésére, inkább pénzügyi kompenzáció vagy szolgáltatásjavítási (szerződéses SLA-k, hibajavítás, ügyfélszolgálat, rendelkezésre állás stb.) lehetőség van. A jogi úton történő probléma rendezés előtt azonban érdemes a szállítóval személyesen egyeztetni, akár egy független ERP szakértő által mediált formában.
Gyakran kapunk felkéréseket utólagos auditra akkor is, amikor a megvásárolt rendszert ugyan szeretné az ügyfél megtartani, de a szállítóval már véglegesen megromlott a viszony, és szolgáltató partnert szeretne cserélni. Erre azonban csak akkor van lehetőség, ha a szoftver nem ún. egyszállítós rendszer. Ha azonban ilyen ERP-t választottunk, akkor a helyzet megoldása csak egy új ERP rendszer bevezetése lehet. Ilyenkor persze nem árt levonni a tanulságokat, hogy a következő projektünkben ezek a hibák ne fordulhassanak elő többet. Ahogy az egyik külföldi tanácsadó kollégám mondta egyszer egy IT vezetőnek: "az ERP projekt legnagyobb kockázata a karriered lehet."
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.