A kérdés nem csak az:

mennyibe kerül az ERP?

Hanem:

mihez képest mondjuk majd, hogy jobb lett?

Mi a baseline?

A baseline a változtatás előtti, meghatározott módon mért kiindulási állapot.

Nem egyetlen szám.

Egy használható baseline meghatározza:

mit mérünk;

hogyan mérjük;

melyik adatforrásból;

milyen időszakban;

milyen gyakorisággal;

milyen definíció szerint;

és ki felel a mérés hitelességéért.

Ha például az ERP-projekt egyik célja a rendelésfeldolgozás gyorsítása, akkor a „gyorsabb lesz” nem mérhető cél.

Ehhez először tudni kell:

mennyi most a rendelés átfutási ideje?

Hol kezdjük mérni?

Hol fejezzük be?

Átlagot vagy mediánt használunk?

Beletartozik-e a várakozás?

Mi történik a részszállításokkal?

Hogyan kezeljük a kivételeket?

A mérési definíció legalább olyan fontos, mint maga a szám.

Miért nem elég a projekt költségvetése?

Egy ERP bevezetésének költsége viszonylag könnyen összesíthető:

licenc;

implementáció;

integráció;

adatmigráció;

tanácsadás;

belső munkaidő;

oktatás;

infrastruktúra;

üzemeltetés.

A haszon azonban ritkán jelenik meg egyetlen sorban.

Megjelenhet például:

rövidebb átfutási időben;

kevesebb manuális munkában;

kevesebb újramunkában;

pontosabb készletben;

kevesebb hibában;

gyorsabb pénzügyi zárásban;

jobb szállítási megbízhatóságban;

alacsonyabb készletszintben;

kevesebb sürgős beavatkozásban;

vagy nagyobb feldolgozható üzleti volumenben.

Ezek közül azonban csak azt lehet érdemben változásként értelmezni, amelyről tudjuk, milyen állapotból indult.

Az ROI és a benefits realization nem ugyanaz

Az üzleti tervben számított ROI előretekintő becslés.

A ténylegesen megvalósult üzleti eredmény utólag mérhető.

A kettőt nem szabad összekeverni.

Egy projekt indulásakor becsülhetjük, hogy az automatizáció évente 3 000 munkaórát takarít meg.

A rendszer bevezetése után viszont már azt kell mérni:

valóban csökkent-e a munkaidő;

mely folyamatokban;

mennyivel;

mi történt a felszabadult kapacitással;

és a változás valóban az ERP-hez köthető-e.

A PMI Benefits Realization Management keretrendszere ezért a tervezett előnyök mellett külön hangsúlyt helyez a mérőszámokra, KPI-kra, mérési eljárásokra, felelősségekre és a megvalósult előnyök későbbi ellenőrzésére.

Mit érdemes mérni még a bevezetés előtt?

Nem létezik minden vállalatra azonos ERP-mérőszámkészlet.

A mérésnek az adott projekt céljából kell következnie.

Egy kereskedelmi vállalatnál például releváns lehet:

rendelés átfutási ideje;

szállítási pontosság;

készletpontosság;

készletforgás;

manuális adatbevitelek száma;

rendelésenkénti kézi beavatkozás;

újramunka;

hibás számlák;

készlethiány miatt módosított rendelések;

vagy reklamációk kezelési ideje.

Egy gyártócégnél más mutatók is fontosak lehetnek:

termelési átfutás;

terv–tény eltérés;

anyaghiány okozta várakozás;

munkalap- vagy műveleti hibák;

selejt;

utómunka;

gépi és emberi várakozási idő.

A kérdés minden esetben ugyanaz:

milyen üzleti eredményt várunk a változtatástól, és milyen megfigyelhető mutató bizonyítaná, hogy ez valóban megtörtént?

A rejtett költség gyakran fontosabb, mint a látványos hiba

Tegyük fel, hogy egy dolgozó minden rendelés után öt percet tölt azzal, hogy két rendszer adatait összevesse.

Öt perc jelentéktelennek tűnik.

Napi 100 rendelésnél azonban ez már:

500 perc.

Több mint nyolc munkaóra.

Minden munkanapon.

A probléma nem feltétlenül jelenik meg külön költségsoron.

A vállalat mégis kifizeti.

Ugyanez igaz az újramunkára, várakozásra, kézi ellenőrzésre, ismételt adatbevitelre és hibajavításra.

Ezért a baseline-nak nemcsak pénzügyi mutatókat kell tartalmaznia.

A működés idejét és erőforrásigényét is láthatóvá kell tennie.

Szemléltető példa

Egy vállalat új ERP-t vezet be azzal a céllal, hogy gyorsítsa az order-to-cash folyamatot.

Egy év múlva a vezetés megkérdezi:

megérte?

A rendszer működik.

A számlák elkészülnek.

A dolgozók használják.

De senki nem mérte a korábbi átfutási időt.

Nem tudjuk, mennyi manuális beavatkozás történt korábban.

Nem tudjuk, mennyi történik most.

Nem ismerjük a korábbi hibaarányt.

Ebben az esetben lehet véleményt mondani.

Lehet elégedettséget mérni.

De megbízható működési megtérülési állítást már sokkal nehezebb alátámasztani.

Ez szemléltető példa, nem ügyféleredmény.

A go-live nem a mérés vége

Ez különösen fontos.

Az ERP hatása időben változik.

Közvetlenül a bevezetés után a teljesítmény akár romolhat is:

az emberek tanulják a rendszert;

hibák kerülnek felszínre;

adatproblémák jelenhetnek meg;

folyamatokat kell finomítani.

Gerhard Jurasek 2026-os ERP benefit-management kutatása négy ipari vállalatot vizsgált. A kutatás kvalitatív részében 44 végfelhasználóval és ERP-tanácsadóval készült interjú, a kvantitatív részben pedig 12 KPI havi alakulását elemezték 24 hónapon keresztül a go-live után. A kutatás egyik fontos eredménye, hogy az ERP előnyeinek realizálása időfüggő folyamat, és a go-live önmagában nem tekinthető a benefits realization végpontjának.

Ezért egyetlen „előtte–utána” pillanatfelvétel is félrevezető lehet.

A baseline önmagában sem bizonyít okságot

Ez fontos korlát.

Tegyük fel, hogy az ERP bevezetése után 15%-kal javul a szállítási pontosság.

Ez még nem automatikusan jelenti azt, hogy:

az ERP 15%-kal javította a szállítási pontosságot.

Közben történhetett:

szervezeti átalakítás;

beszállítóváltás;

készletszint-emelés;

új logisztikai partner;

termékportfólió-változás;

létszámváltozás;

vagy piaci keresletcsökkenés.

A baseline tehát szükséges a hiteles összehasonlításhoz, de önmagában nem mindig elég az oksági hozzárendeléshez.

Ezért a mérési tervnek a jelentős párhuzamos változásokat is dokumentálnia kell.

Mikor kell kialakítani a mérési rendszert?

Nem a projekt végén.

És lehetőleg nem közvetlenül a go-live előtt.

A releváns üzleti mutatókat akkor kell meghatározni, amikor a vállalat még a jelenlegi állapotát működteti.

Így van lehetőség megfigyelni:

a normál ingadozást;

szezonalitást;

különböző rendeléstípusokat;

kivételeket;

és az adatminőséget.

Nincs minden vállalatra érvényes univerzális baseline-időszak.

A szükséges időtartamot a folyamat frekvenciája, változékonysága és szezonalitása határozza meg.

Hogyan kapcsolódik ez a Kyntraxhoz?

A Kyntrax Mirror feltárja a jelenlegi működést.

Nemcsak azt, hogy mi történik, hanem azt is, hol van:

várakozás;

újramunka;

manuális lépés;

információs rés;

ismételt adatbevitel;

hiba;

vagy mérhető működési veszteség.

A Kyntrax Compass ezekből már célállapotot és prioritásokat képezhet.

A Tunnel pedig lehetőséget ad arra, hogy a változtatás ne egyszerre, hanem kontrollált lépésekben történjen.

Így a kérdés nem pusztán az:

elkészült-e az ERP?

Hanem:

a vállalat működése a meghatározott mutatók szerint jobb lett-e?

Mit állapít meg ez az anyag?

ERP-megtérülési állítás megfelelő kiindulási mérés nélkül nem ellenőrizhető megbízhatóan.

A baseline ugyanakkor nem bizonyít önmagában okságot, és nem garantál pozitív ROI-t.

A szerepe az, hogy a változtatás eredménye ne pusztán benyomásokhoz, hanem előre meghatározott és visszaellenőrizhető működési mutatókhoz legyen viszonyítható.

Kapcsolódó Kyntrax Tudástár: ERP-bevezetés vagy -csere előtti folyamatfelmérés · ERP-problémák okainak diagnosztikája · Üzleti diagnosztika digitalizáció előtt · Folyamatdiagnosztika kereskedelmi KKV-knál

Szakmai háttér

Project Management Institute: Benefits Realization Management Framework. A keretrendszer a tervezett előnyöket mérhető KPI-okhoz, mérési eljárásokhoz és felelősségekhez köti. Keretrendszer

Jurasek, G. (2026): Benefit Management for ERP systems, Journal of Universal Computer Science, 32(6), 826–850. DOI: 10.3897/jucs.165524.