Az éves költségvetések összeállítása során gyakran csak az azonnali, kézzelfoghatóbb beruházásokra, például új termékcsaládokra, logisztikai fejlesztésekre gondolnak, amelyek biztosnak tűnő eredményeket hoznak. Amíg nincsenek igazi fájdalompontok a meglevő, elavult ügyviteli rendszerek használata kapcsán, nem lépnek.
A nagy gyártók, mint az SAP vagy a Microsoft azonban a verziótámogatások lezárásával nyomást tudnak gyakorolni a felhasználókra. A régi SAP verziókra pl. 2025-ig adnak ki frissítéseket, a Microsoft a régi Dynamics NAV rendszereire pedig 2023 októberéig. Ez azt jelenti, hogy a gyártó eddig az időpontig azon ügyfeleinek, akik fizetik a szoftver karbantartást, elérhetővé teszi a törvényi követést és az új funkciókat is. Ezt követően azonban nem. Ilyenkor jön a kérdés: megtartsam a régi verziót (ismerve a kockázatokat), egy verzióváltási projektet indítsak, vagy vezessek be valami új rendszert. És persze a mikor is fontos tényező.
A verzió, b verzió, tervezni jó perverzió (by Geszti)
A magyar ERP bevezetések többségénél az egyik legalapvetőbb hiba, amit az elmúlt 21 évben láttam: agyonfejleszteni, magamra szabni, bármi áron.
Ennek gyakran nincs valódi racionális oka, csak a "mi így szoktuk ezt csinálni", a "régi is így nézett ki". És a szoftverbevezető cégeknek lássuk be, ez jó üzlet is: a sok-sok egyedi fejlesztéssel igazán jól magukhoz tudták kötni az ügyfeleiket. Ezek azonban lehetetlenné teszik az egyszerű, gyors verzióváltási projekteket.
A sok egyedi fejlesztést gyakorlatilag újra kéne íratni, ami bizony felérhet mind időtartamban, mind költségben egy teljesen új ERP rendszer beszerzésével. Ami átvezet egy másik dilemmához: valójában minden 8-10+ éves, sok egyedi fejlesztést tartalmazó ERP rendszer esetén vizsgáljuk meg, nem járnánk-e jobban egy új rendszer bevezetésével?
Tavasszal jártam egy gyártó cégnél, amelyik egy tizenöt éves német ERP szoftverrel bíbelődik, amihez nincs valós magyarországi szakértői bázis, és 1000 eurós napi díjért jön ide a német tanácsadó, bármilyen változási igény esetén. A menedzsment keményen küzd a tulajdonosok jóváhagyásáért, mert a napi operatív működést fenntartani az itthon oly gyakran változó szabályozási környezetet nem támogató, elavult ERP rendszerrel brutálisan nehéz feladat.
A tulaj mégis vár. Mert reménykedik abban, hogy egy verzió frissítés majd elég lesz, olcsóbb lesz. Utálom, hogy én vagyok a rossz hírek hozója, de tény: az biztosan nem oldja meg a problémákat.
Végül ennél a forgatókönyvnél, a megfelelő informatikai befektetések nélkül, a meglévő technológia egyre komolyabb korlátot jelent majd, és elérik azt a pontot, amikor már a veszteségek minimalizálása a cél.
Miközben ez megtörténik, a versenytársak, akik a technológiai haladás élére állnak, ezzel óriási lépéseket tesznek előre a gyártási ütemezésben, az alacsonyabb készletszintben, a rövidülő szállítási időben, az ügyfelek elégedettségében és végül a bevételekben és a profitban.
Aki szeretné ezt elkerülni, jobb, ha egy teljes körű, belső ERP rendszer kiválasztási projektet indít, ahol csupán az egyik vizsgálandó opció a verzióváltás adott szoftveren belül.
Bár úgy tűnhet, olcsóbb és kevésbé kockázatot semmit sem csinálni, valószínűleg ezek a vállalatok 5-10 éves távlatban többet költenek, és többet veszítenek is, mint bátrabb és proaktív versenytársaik.
Mikor kezdjünk verzió váltási projektbe?
Ha mégis úgy döntenénk, hogy nem vizsgálunk más opciókat, csak a régi ERP szoftverünk új verzióját vezetjük be, akkor is legyünk résen: az időzítés nagyon fontos. Az ERP piac terhelése rendkívül intenzív lett az elmúlt 2 évben, az ERP szolgáltató cégek többsége komoly erőforrás problémákkal küzd. Egyre magasabb áron adják a tanácsadói napi díjakat. Nyilvánvalóan a nagyobb, tőkeerős cégek gigaprojektjeire fogják a verziótámogatási időszak vége felé az erőforrásaikat tartalékolni.
Ezért a középvállalati körnek mindenképpen azt javaslom, 2019-ben legkésőbb álljanak neki a verzióváltási projektek előkészítésének, kérjenek be ajánlatokat. Halkan jegyzem meg, ehhez is érdemes külső, független ERP szakértői csapattal neki fogni.