Üdvözlöm a kedves Olvasókat! Giller Tamás vagyok, a www.erpblog.hu vállalatirányítási rendszerekkel, CRM-rendszerekkel, valamint IT-projektmenedzsmenttel foglalkozó blog szerkesztője. Korábbi írásaimban már volt szó projektmenedzsmentről, ERP-rendszerek kiválasztásáról, valamint az ERP-rendszerek áráról is. Ezekben a cikkekben bemutattam az utat, hogyan lehet a legmegfelelőbb ERP-rendszert megtalálni. De valljuk be, hogy a hazai vállalatirányítási, ügyviteli rendszerek bevezetésének számottevő része nem azzal az eredménnyel zárul, mint amit a megrendelő kitűzött maga elé, tehát a projektek egy része sikertelen.
Mit lehet ilyenkor tenni? Először is körültekintően – objektíven, érzelmektől mentesen – meg kell vizsgálni, hogy miért sikertelen a projekt, miért érzi úgy a megrendelő, hogy nem azt kapta, amit elvárt. Mi okozza az elégedetlenséget? Mik a problémák forrásai? Ez már komoly kihívás, hiszen ha valaki elégedetlen, akkor elégedetlenségét a nagyobb hatás elérése érdekében olyan dolgokkal is felnagyíthatja, amivel amúgy nem is feltétlenül elégedetlen. Mutatok néhány olyan példát, ami tipikusan elégedetlenségre adhat okot.
Időbeni csúszás
A szerződés megkötésekor általában kijelölésre kerül az éles indulás időpontja, az ún. go-live. Az éles indulás előtti hetekben egy végső megbeszélésen a vállalkozónak be kell mutatnia az elkészült fejlesztéseket, módosításokat, hogy a megrendelő eldönthesse, az elkészült funkcionalitásokkal vállalja-e az éles indulás kockázatát. Előfordulhat, hogy az éles indulás időpontját el kell(ene) tolni, mert az átalakított rendszer még nem alkalmas arra, hogy kiszolgálja a megrendelő üzleti folyamatait.
- Probléma oka: az időbeni csúszásnak több oka is lehet. Például ha a megrendelő nem megfelelő módon készítette el az igényspecifikációt a vállalkozó felé. Így a fejlesztések során olyan új információk merülhetnek fel, amelyek lényegesen megnövelik a fejlesztési tervet.
Általános hiba, hogy ilyenkor a vállalkozó nem jelzi azonnal a megrendelő felé, hogy az új információk miatt csúszás várható, és amennyiben az éles indulás időpontjához ragaszkodik, akkor jelölje meg azokat a funkciókat, amelyekre az éles induláshoz nincs szükség, vagy mellőzhetőek. Másik ok, hogy a vállalkozó nem megfelelően tervezte meg a funkciókat, és sokkal tovább tart a fejlesztés, mint gondolták. Ilyenkor a vállalkozó felelőssége, hogy akár túlmunka árán is megvalósítsa a fejlesztést. Amennyiben ezek a problémák nem kerülnek megfelelően kommunikálásra, akkor az éles indulás előtti utolsó bemutató elég rosszul is elsülhet.
- Megoldás: a fejlesztés során folyamatos kommunikáció. Ha már ott vagyunk az utolsó megbeszélésen, ahol dönteni kell, lesz-e éles indulás vagy sem, akkor pontosan meg kell határozni, hogy hova jutott a fejlesztés, ez elégséges-e a megrendelőnek, vagy sem. Hol hibázott a vállalkozó, és hol a megrendelő? Ezek alapján gyors akcióterv kell arra, hogy a hátralévő időt hogyan tudjuk a lehető legnagyobb mértékben a projektre fordítani, hogy ha nem is 100%-os elvárással, de megfelelő mértékben teljesüljenek az ügyféligények az éles indulásra. A megrendelőnek is tisztában kell lennie azzal, hogy olyan funkciók, amelyeket majd az éles indulás után csak egy hónappal fognak használni, nem szükségesek a projekt ezen szakaszában.
Tévesen megvalósított funkciók
A fejlesztés során, majd a későbbi bevezetés közben is kiderülhetnek olyan dolgok, amely alapján a megrendelő azt mondja, ő nem is azt rendelte meg, ami elkészült. Ezen problémák kezelése igen nehéz.
- Probléma oka: nem megfelelő igényfelmérés, igényspecifikáció. Nem megfelelő tesztelés mindkét fél részéről. Nem megfelelő átadás, oktatás. Hiszen ezen alkalmak egyikén sem derült ki, hogy probléma van, vagy ha kiderült, akkor valószínűleg már későn. Oka lehet a problémának, hogy a vállalkozó nem ismeri megfelelő módon az adott üzleti területet, ahova fejleszteni kell. Ezért is szoktam javasolni, hogy olyan ERP-szolgáltatót válasszunk, aki ismeri az iparágat, ahol a cégünk tevékenykedik. Oka lehet, hogy a megrendelő nem megfelelően fogalmaz és csak vágyai vannak, illetve olyan megrendelést kér, amely matematikailag, programozási szempontból nagyon nehezen valósítható meg és nagyon sok ún. adhoc-dolog befolyásolja az üzleti működést.
- Megoldás: válasszon olyan ERP-szállítót, aki ismeri az iparágat, ahol az Ön cége működik. A vállalkozó egy adott megrendeléskor írásban küldje vissza a megrendelőnek, hogy mit értett meg a fejlesztési igényből, mi fog megvalósulni és hogyan. A megrendelő minden részletet tárjon az ERP-szolgáltató elé. Ha már megtörtént a baj és a funkció rosszul készült el, akkor meg kell próbálni a lehető leggyorsabban, legköltséghatékonyabban korrigálni. A fejlesztő cég feladata, hogy a fejlesztési rész szakaszába is beavassa a megrendelőt. A közös tesztelés szintén nagyon célravezető lehet.
Elmaradt beállítások
A vevő legtöbbször elképzel valamilyen működést a rendszer kapcsán, még az is lehet, hogy szóban erről történik valamilyen tájékoztatás a rendszert szolgáltató felé, de a rendszertervbe (ami alapján a szolgáltató cég majd elvégzi a beállításokat) ez nem kerül bele. Az éles indulás után nem foglalkozik továbbra sem senki ezzel az üzleti igénnyel, majd a bevezetést követő pár hónapon belül a vevőnek eszébe jut ez a dolog, és akkor derül ki, hogy nem történt meg annak az üzleti funkciónak a beállítása – így lehetséges, hogy közvetett módon anyagi kár is keletkezett (pl. 5%-kal olcsóbban ment ki minden árajánlat, mint kellett volna).
- Probléma oka: nem megfelelő kommunikáció a két fél között, írásbeliség hiánya. Éles indulás utáni átvétel hiánya.
- Megoldás: A szükséges beállítások elvégzése, valamint a jövőre vonatkozóan tisztázni kell, hogy minden új beállítás, funkcióváltoztatási kérés csak írásban, a megfelelő csatornákon keresztül történhet.
Elmaradt funkciófejlesztések
Rosszabb a helyzet, hogyha egy olyan üzleti funkció nem kerül lefejlesztésre, amire a megrendelőnek kiemelten szüksége van, de azt gondolta, hogy a rendszer arra alapból képes, mert számára ez derült ki a bemutatók során.
- Probléma oka: nem megfelelő kommunikáció a két fél között. A megrendelő nem nézett utána eléggé az általa választott ERP-rendszernek (tesztelések, pilotprojekt), de az is lehet, hogy a szállító téves vagy félreérthető információkat adott át a rendszerről a megrendelőnek.
- Megoldás: a hiányzó funkciót nyilván le kell fejleszteni, de itt újabb konfliktus alakulhat ki (és ez tovább növelheti a megrendelő elégedetlenségét), hogy kit terhel a fejlesztés költsége.
Anyagi problémák
Általában ezek a problémák a legjelentősebbek. A gondot az okozza, hogy a megrendelő vásárol egy vállalatirányítási rendszert adott funkcionalitásokkal (nagyon sok minden bizonyára hiányzik belőle), a vállalkozó pedig elad egy vállalatirányítási rendszert az adott funkcionalitásokkal – de a jövőre egyikük sem gondol.
A bevezetésig persze meg lehet egyezni, hogy vannak bizonyos üzleti funkciók, amelyek a megrendelőnek szükségesek, és a vállalkozó az üzletért bevállalja, hogy árcsökkentett díjon vagy akár ingyen lefejleszti azokat. De ezek után is sorra jöhetnek azok az új vagy megváltozott üzleti igények, amelyek alapján mindig módosítani kell a rendszert. A szaknyelv ezeket új igényeknek (new request) és változtatási kéréseknek (change request) nevezi. Ezek mindig fizetős fejlesztések.
Egyetlen ingyenes fejlesztés létezik: a hibajavítás (bug report). A megrendelő viszont egy nem létező funkciót legtöbbször hibaként tálal. Azt mondja, hogy hibát szeretne jelezni, és aztán leírja, hogy például nem tud megfelelő formátumú adásvételi szerződést nyomtatni. Azért nem tud, mert olyan riport nincs is az adott rendszerben. Az is előfordulhat, hogy az ügyfél azzal hozakodik elő, hogy egy ekkora vállalatirányítási rendszertől – amelyet úgy reklámoztak, hogy széles körben paraméterezhető – elvárható, hogy ilyen szinten lehessen paraméterezni. Illetve akkor ennek a megoldásának költségét vállalja át a vállalkozó, mert úgymond elvárható lenne a rendszertől. És el is érkeztünk a problémához: megy a vita, hogy a vállalkozó minden plusz fejlesztésért pénzt kér (amihez joga van), a megrendelő pedig elégedetlen, mert fizetnie kell, pedig azt gondolta, hogy a vásárlás után minden ingyen lesz.
- Probléma oka: ennek a problémának nagyon sok és összetett oka lehet. A megrendelő nem nézte meg eléggé a rendszert, nem a számára legmegfelelőbbet választotta. A vállalkozó tévesen tájékoztatta a megrendelőt a paraméterezési, beállítási lehetőségekről. Nem tisztázták, hogy mi számít új fejlesztésnek, változtatásnak, illetve hibajavításnak. Nem tisztázták, hogy amennyiben van havi fizetendő díj a rendszer mellé, akkor az mit tartalmaz, milyen fejlesztéseket, konzultációkat.
- Megoldás: A fenti dolgoknak a figyelembe vétele, még a szerződés megkötése előtt. Amennyiben anyagi vitára kerül sor, akkor továbbra is ajánlom mindkét félnek a kompromisszumkészséget: egy hajóban eveznek, és a vállalkozónak mérlegelnie kell, hogy egy esetlegesen ingyen készített új funkció mekkora hozzáadott értéket jelenthet a rendszerében, ami által még eladhatóbb lesz. A megrendelőnek pedig tudatosan kell rendszert választania, és amennyire lehet, alkalmazkodnia kell a rendszerben lévő funkciókhoz, adottságokhoz. Amennyiben ezt nem akarja, akkor egyedi szoftvert kell fejleszteni – de annak a költsége még nagyobb lesz.
Ezekből a problémákból, helyzetekből is láthatjuk, hogy milyen fontos a legmegfelelőbb ERP-rendszer és a legmegfelelőbb szállító kiválasztása. Egy balul sikerült projektből nagyon nehéz kikecmeregni. Akkor már nem mondhatjuk, hogy mi nem vagyunk hibásak, mert az esetek jelentős százalékában mindkét fél kivette a részét abból, hogy sikertelen lett a bevezetés.
Egy teljes csere, egy teljesen új ERP-bevezetés nagyon jelentős terhet róna a megrendelőre, így a megegyezés a legkézenfekvőbb megoldás. A megrendelőnek arra is fel kell készülnie, hogy az alkalmazottjai visszasírják a régi rendszert, mert azt tudták használni, az új rendszer használata pedig komoly nehézségeket is okozhat. Fontos, hogy ez az elégedetlenség, amely abból ered, hogy megszokták a kollégáink a régi elavult rendszert, ne vezessen odáig, hogy a teljes cég elégedetlenséget érez olyan dologért, ami valójában nincs is. Ezt a megrendelőnek tudatosan kezelnie kell.
