Problémás erp bevezetés? Hívja az erp projekt doktort!

Vegye észre: ha rosszul megy a projekt - és rendeljen független projekt auditot, mielőtt bekövetkezik a katasztrófa!

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.

problemas_erp_bevezetes_hivja_az_erp_projekt_doktort_screenshot_20161216112422_1_nfh.jpg
Nagyításhoz kattintson a képre.

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 www.erp-consulting.hu 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. 19 év alatt mintegy 100 ERP projektben szerzett tapasztalatait magyar és nemzetközi tulajdonú termelő és szolgáltató cégeknél hasznosítja. Az     "ERP doktor - projektaudit" szolgáltatásunk érdekli? Írjon az info@erp-consulting.hu e-mail címre.

Kommentek

comments powered by Disqus
Ezt olvasta már?

Kipukkan a megosztáslufi? »