Magyar 
English (UK) 
Deutsch Cserélné meglévő ERP-rendszerét? Megmutatjuk, miért éri meg ilyenkor külső partner bevonása és hogyan kerülhetők el a legnagyobb hibák már a tervezés időszakában.
Röviden
KKV-knál különösen gyakori, hogy nincs kiforrott tesztelési módszertan, a tesztelés Excelben és azüzleti felhasználók vagy az IT projektek rendszeres résztvevőinek fejében él, a key userek pedig a napi munka mellett próbálják megoldani a feladatot. A tesztelés sokszor ad-hoc módon történik, nincsenek releasek, a fejlesztő „on the fly” javítja a kódot, a key-userek rögtön tesztelik. Mindezt akár 8-12 csapat (értékesítés, beszerzés, logisztika, termelés, pénzügy stb.) teszi párhuzamosan, egymás tesztadatát, tesztfolyamatát felülírva. Ehhez jönnek hozzá az ERP tanácsadók folyamatos paraméterezésibeállításai, és az üzemeltető kollegák ad-hoc jelleggel történő patch telepítései vagy a rendszer újraindításai.
Egy partner cég segíthet a tesztstratégia és tesztterv kialakításában, a tesztelési szintek és szerepkörök meghatározásában, valamint a belső csapat oktatásában és coachingjában, hogy a módszertan hosszú távon fenntartható legyen.
A tesztelésre szánt költség a projekt teljes büdzséjének csak egy része (jellemzően a teljes kiadás 20-30%-a), mégis kulcsfontosságú. Jóval kevesebbe kerül, mint egy csúszó bevezetés, egy hibás migráció vagy egy go-live utáni működési leállás és az ebből fakadó újabb tesztelési körök megvalósítása.
Tartalomjegyzék
Miért okoz gyakori nehézséget az új ERP-rendszer cseréje?
A KKV‑k ma egyszerre küzdenek kapacitáshiánnyal és gyorsuló üzleti elvárásokkal. Nagyon gyakori jelenség, hogy a korábbi RP-rendszerek elavultak, funkcionálisan korlátozottak és nehezen fejleszthetőek tovább. Sokszor felmerül, hogy biztos, hogy szükség van-e KKV-ként is ekkora rendszerre, van-e erre elég büdzsé, vagy hogy megoldható-e tesztelésük házon belül.
A DIHK felmérései szerint a digitalizációs projektek többségében a KKV‑k bevonnak külső IT‑szolgáltatókat. Bár van rá költségvetési keret, azt szinte teljes egészében az informatikai rendszerekre és azok bevezetésére költik, miközben a tesztelés szervezettségére már nem jut figyelem.
Márpedig átgondolt és fenntartható szoftverminőségbiztosítás nélkül nélkül könnyen szembetalálhatjuk magunkat olyan problémákkal, amik akár az egész bevezetés sikerét alááshatják.
Problémák, amik jó tesztelési módszertan nélkül nem fognak megoldódni
A leggyakoribb problémák ERP-bevezetésnél:
✘ a projekt csúszik, mert a tesztelés csak akkor történik, amikor épp jut rá idő
✘ nincs világos tesztterv
✘ nincs belépési-kilépési kritérium
✘ nincsenek meghatározott tesztciklusok, code-freeze-zel: folyamatos testreszabás és egyedi fejlesztés kiadása történik, menetközben különböző javító csomagok kerülnek telepítésre, ebből kifolyólag nehezen lekövethető, hogy melyik hiba mikor jelentkezett, mi okozta
✘ különböző szakterületek sokszor egymástól függetlenül tesztelnek, sokszor egymás tesztelési folyamatait, tesztadatait felülírva
✘ a hibakezelés tesztmenedzsment rendszer helyett táblázatokban, e-mailben és külön listákban zajlik
✘ hibás adatok kerülnek az új rendszerbe, mert az adatmigrációt technikailag ugyan lefuttatják, de nincs hozzá külön migrációs tesztstratégia és üzletileg is értelmezhető koncepció
✘ hiányzik a valós folyamatokra épülő go-live szimuláció, performancia ellenőrzés és roll-back plan, ezért go-live után akár a számlázás, a gyártás vagy a pénzügyi zárás is megállhat
Mi a megoldás ezekre?
A TestIT-nél minden projektünket egy átlátható tesztmódszertan felállításával kezdjük, és a tapasztalatunk szerint az említett problémákat is ez már nagy részben meg tudja előzni. Ilyenkor kell egy jól definiált tesztterv, strukturált hibakezelés, a kritikus üzleti folyamatokra felépített integrációs és felhasználói tesztek, migrációs ellenőrzőpontok, valamint objektív go-live felkészültségi mérce.
Miért kevés a belső tapasztalat ilyenkor?
ERP csere általában ritka esemény egy vállalat életében. Emiatt nem elvárható és nem is reális, hogy a vállalat birtokában legyen a komplex rendszerek cseréjéhez szükséges tudással, tapasztalattal. A key userek és üzleti szakértők, nem tesztmérnökök: pontosan tudják, mit akarnak, de nem feltétlenül tudják, hogyan kell úgy tesztelni, hogy abból döntésre alkalmas, mérhető információ legyen. A tesztelés ezen kívül nagy mennyiségű humán erőforrást emészt fel. Tudatos és szigorúan betartott tesztelési módszertan hiányában, időnyomás esetén gyakran a tesztelés esik áldozatául az erőforrásallokációnak. Pont emiatt a potenciálisan kialakuló szűkösség és beslő erőforrásátcsoportosítások miatt célszerű külső, skálázható tesztelési erőforrást bevonni. KKV‑nál elég egy kisebb, de professzionális alapszint, amely módszertant, eszközt és keretet ad.
Fontos kiemelni, hogy a key-userek továbbra is fontos szerepet játszanak a projektekben, hiszen az üzleti folyamatokat, a vállalati egyediségeket, szükséges törzsadat beállításokat ők ismerik a legjobban. Egy tapasztalt tesztelő abban tud segíteni, hogy a tesztelés hatékonyan működjön (pl.: így több teszteset tud egymásra épülni, csökkentve a tesztadatok, tesztelés előfeltételek megteremtésére szánt időt), és levegye a tesztesetek többszöri futtatásának terhét a key-userekről.
„Kicsiben” is működhet – Milyen lehetőségek vannak, ha szűk a céges büdzsé?
Gazdasági szempontból a tesztelés minősége döntő szerepet játszik abban, hogy az ERP‑beruházás mennyire térül meg, és mennyire határozza meg, mennyire váltja be a kezdeti reményeket. Egy hibásan paraméterezett vagy nem megfelelően letesztelt ERP hónapokkal elhúzódó projekthez vezethet (plusz tanácsadói napok, belső bérköltség, kifáradó key userek), go‑live utáni fennakadásokat okozhat (elmaradt szállítások, számlázási problémák, leálló gyártás), és akár utólagos „tűzoltásra” kényszeríthet (újabb körök a szállítóval, drága újratervezés).
Ezeknek a rejtett költségeknek már egy része is meghaladhatja azt az összeget, amit egy KKV‑léptékű, jól célzott tesztelési támogatásra kellene fordítani. Különösen igaz ez olyan átállásoknál, mint az SAP S/4HANA vagy a proALPHA bevezetés, ahol a folyamatok sok üzleti területet érintenek.
Minőségileg felkészített tesztelés nélkül az ERP‑projekt valójában drága és rizikós kísérlet: vagy jól sikerül, vagy újabb köröket kell rá költeni. A strukturált tesztmódszertan, a tesztmenedzsment‑eszköz és a kockázatalapú tesztterv azt biztosítja, hogy ugyanabból a projekt‑ és licencköltségből egy jóval magasabb üzleti biztonságú rendszer legyen az eredmény. Egyúttal egy objektív és transzparens képet ad a tesztelés állásáról, ami jól használható az ERP szállítóval szembeni érdekképviseletre (mi az, amit a szállítónak teljesítenie kell még ahhoz, hogy a rendszer élesbe tudjon menni vagy például tényszerűen alátámasztja, hogy kinek róható fel egy hiba).
Érdemes azt is látni, hogy a külsős tesztelési támogatás nem feltétlenül „luxusberuházás”. A Bitkom adatai szerint a német KKV‑k több mint fele már ma is vesz igénybe külső IT‑szolgáltatót digitalizációs projektekben, ezek egy része kifejezetten tesztelési, illetve szoftverminőség‑biztosítási tanácsadást is jelent.
ERP-bevezetési projektterv: Mikor és hol kapcsolódik be a tesztelés?
Sok projekttervben a tesztelés egyetlen helyen szerepel, és ez a legvége. Valójában az az ideális, ha már az igénymegfogalmazástól jelen van. Az alábbiakban egy példa látható arra, amikor a tervezés elején már reálisan mérik fel a fázisok várható időtartamát, és amelyben a tesztelés valóban sikeresen járul hozzá a projekthez, megvédve azt számos kockázattól.
Fontos: Ha az 1-3. fázisban nem gondolunk tudatosan a tesztelésre, a végén szinte elkerülhetetlen a kapkodás és a csúszás.
Valóban ennyi időbe telik az ERP-rendszer cseréje?
Bár sokan 1,5-2 évre becsülik egy ilyen projekt teljes átfutását, a TestIT több éves iparági tapasztalata az, hogy ez a gyakorlatban 3-4 év is lehet. Fontos azonban, hogy ez az idő két dologgal jelentősen csökkenthető: a partnercég korai bevonásával és a jó tervezéssel. Ha mindez megtörténik, könnyen elkerülhetők az optimista és pesszimista forgatókönyvek buktatói, felállhat egy valóban reális és tartható projektterv, és a megvalósítás fázisában már nagy eséllyel nem érik meglepetések a céget.
Hol tudunk időt spórolni?
A 3. és 4. fázis között idő takarítható meg. Ha megvárjuk a teljes koncepció lezárását az implementáció előtt, az sokat késlelthetii a projektet. A gördülő megközelítés, ahol az első modulok tervezése és konfigurációja párhuzamosan fut, gyorsabb haladást tesz lehetővé, de csak akkor, ha a tesztstratégia már a 3. fázisban elkészült.
A 4. és 5. fázis átfedése szintén bevett gyakorlat. Az egyes modulok tesztelése nem kell, hogy megvárja az összes többi modul implementációját. Az úgynevezett gördülő tesztelés azt jelenti, hogy az első kész modulok tesztelése már akkor elindul, amikor a többi még konfigurálás alatt van. Ez időt takarít meg, de módszertanilag igényesebb, és külső koordinációs támogatást indokol. Egy másik nagyon előnye ennek a megközelítésnek, hogy a munkatársak hamarabb megkezdik a tesztelést, tesztmenedzsment eszköz használatát, amely későbbi már több funkcióra kiterjedő tesztelési fázisok tesztjét gördülékenyebbé teszi.
Mely területeket tud támogatni a külső tesztelési szakértő?
Ha külső szakértővel dolgozunk, a megfelelő alapok lefektetéséhez és a végső értékeléskor is fontos szerepet kap a projektben a független partner. Ilyenkor az alábbi területeken vonódik vagy vonódhat be a munkába:
1. Tesztmódszertan kialakítása, a cég folyamataira szabva
Segít a gyakorlatban lefektetni azt, hogy:
- milyen tesztszinteket használunk (modul, integráció, felhasználói, go‑live szimuláció)
- ki mit csinál (RACI)
- hogyan írunk teszteseteket (egyszerű, de következetes sablon)
- hogyan kezeljük a hibákat (prioritások, státuszok)
2. Tesztterv összeállítása
Egy jól felépített tesztterv:
✔ illeszkedik a teljes ERP‑projekt ütemtervéhez
✔ előre megmondja, mikor, mit és ki tesztel
✔ tartalmazza a belépési-kilépési kritériumokat
✔ átláthatóvá teszi a kockázatokat és a várható tesztkörök számát.
3. Tesztmenedzsment-eszköz bevezetése
A következő szint egy, a KKV‑hoz illeszkedő eszköz (pl. Jira alapú megoldás, SpiraTeam) bevezetése, amely:
- kiváltja az Excel‑ és email‑alapú teszt‑ és hibakövetést
- egyetlen felületen ad képet a tesztelés állapotáról
- támogatja az átlátható riportolást a vezetés felé
4. Tesztelési coaching key usereknek és IT‑nak
A cél az, hogy a key userek megtanulják, hogyan írjanak használható, újrafelhasználható teszteseteket, és az IT‑csapat képes legyen önállóan menedzselni a tesztelést a későbbi rolloutoknál is. A coaching támogatás hosszú távon a cégben belső kompetenciát épít, és csökkenti a külső függőséget.
5. Go-live felkészültségi értékelés
Az első nagy go‑live előtt különösen fontos egy független, objektív nézőpont, ami:
- átnézi az eddigi teszteredményeket, lefedettséget, hibastatisztikákat
- kockázatalapon értékeli a nyitott hibákat
- ajánlást ad arra, hogy vállalható kockázat mellett indítható‑e a rendszer
Ez segít abban, hogy az ügyvezetés és az IT‑vezetés megérzés helyett mérhető adatokra és tapasztalatra támaszkodva döntsön.
A tesztmenedzsment a tesztelési folyamatok tervezését, végrehajtását, ellenőrzését…
Profi tesztelés ma már csak a megfelelő tesztmenedzsment eszközzel lehetséges
Egy profi külső tesztelői szolgáltató többféle tesztmenedzsment eszközt ismer, és segít megtalálni a projekthez és a céghez legjobban illő eszközt, valamint betanítani annak használatát a cégen belül is.
Sok esetben ilyenkor cserélik le az évek óta bejáratott Excel-táblázatos tesztelési metódust, amik rendszerint akkor buknak el, amikor a projekt egyre komplexebbé válik (több modul, több rollout, stb.). Egy Excel táblázatban vezetett teszteléshez aránytalan mennyiségű fegyelem és idő kell. Egy KKV‑barát tesztmenedzsment-eszköz viszont rövid időn belül behozza az árát a csökkenő csúszásokban és hibákban.
PRO ÉS KONTRA: Excel vs. tesztmenedzsment-eszköz
Szempont | Excel‑lista | Tesztmenedzsment-eszköz (pl. Jira, SpiraTeam) |
Átláthatóság | 1-2 tábláig kezelhető, afelett kaotikussá válik | Központi nézet, kereshető, szűrhető, projekt‑szintű átlátás |
Verziózás | Több változat, emailben küldözgetve | Beépített verziókezelés, módosítási napló |
Hibakezelés | Tesztesetek és hibák keverednek, manuális státuszok | Strukturált hibajegyek, státuszok, felelősök |
Státuszjelentés | Kézi összesítések, nagy hibalehetőség | Gombnyomásra riport, vezetői dashboard |
Regressziós tesztek | Sok másolás-beillesztés, nehézkes újrafelhasználás | Tesztcsomagok, ismételt futtatás 1 kattintással |
Több rollout, több ország | Minden rolloutnak külön Excelcsomag | Több projekt, több verzió kezeléseegy rendszerben |
Bevezetési ráfordítás | Azonnal indul, de magas rejtett emberidő-költség | 1-2 hónap bevezetés, utána jelentős idő- és kockázatcsökkenés |
Amit még tudni érdemes: RACI-mátrix – Ki mit csinál a tesztelésben?
Az egyik legnagyobb buktató, amikor nem világos, hogy ki miért felel a tesztelésben az ERP-szoftver bevezetésekor. Az alábbi egyszerűsített RACI‑mátrix csak a tesztelési feladatokra fókuszál. A külső tesztelési partner összehangolja és keretbe foglalja az IT és az üzlet szerepét, így a vezetés nem benyomások alapján, hanem átlátható, számszerűsített kockázati kép alapján dönthet.
Rövid checklist IT‑vezetőknek ERP‑átállás előtt
Ha Öntől kérdezné meg a cég menedzsmentje, hogy a bevezetés alatt álló új ERP rendszer élesíthető-e mi alapján tudná azt mondani, hogy igen vagy nem?
- Van‑e írásos tesztstratégia és tesztterv, amit az IT és az üzlet is ismer?
- Kijelölték‑e, ki a végső felelős a tesztelésért (nem csak a projekt egészéért)?
- Használnak‑e valamilyen tesztmenedzsment-eszközt, vagy mindent Excelben követnek?
- A key userek kaptak‑e tesztelési módszertani támogatást?
- A kritikus folyamatok (rendelés-kiszállítás-számlázás-könyvelés, gyártás, készletkezelés) végigmentek‑e legalább egy teljes integrációs és felhasználói tesztkörön?
- Volt‑e már go‑live szimuláció élethű tesztadatokkal?
- Létezik‑e visszaállási terv, ha az első napokban komoly probléma lép fel?
- Tud‑e ma számokkal alátámasztott választ adni arra a kérdésre, hogy milyen kockázattal indulnak el?
Ha jelenleg ERP‑bevezetés vagy váltás előtt áll, és felismeri ezekben saját helyzetét, kérjen tőlünk egy rövid állapotfelmérést a tesztelési kockázatok feltárására.
ERP-rendszer tesztelése – Első ingyenes konzultáció a TestIT-nél
Az első ingyenes konzultációt követően javaslatot teszünk egy rövid állapotfelmérési projektre, melynek keretében:
- lefektetjük a bevezetés nagyvonalú ütemezését és scope-ját
- átbeszéljük a szükséges rendszerintegrációkat
- meghatározzuk a projektben részt vevő területek számát, nagyságát, főbb folyamatait, melyeket az ERP rendszernek támogatnia kell
- megismerjük a vállalat jelenlegi tesztelési módszertanát, folyamatát, tesztmenedzsment eszközét
- amennyiben van meglévő teszteset, ezeket szúrópróbaszerűen átnézzük
A felmérést átadott dokumentációk átolvasásával és szakértőkkel (projektvezető, IT üzemeltető, fontosabb területek key-userei, tesztmenedzser) történtő egyeztetések keretében végezük el
Az állapotfelmérés eredményeként:
✔ Összefoglaljuk a jelenlegi tesztelési folyamatok érettségét, megfogalmazva a fejlesztési pontokat.
✔ Javaslatot teszünk a szükséges tesztelési szintekre.
✔ Nagyvonalú becslést adunk a teszteléshez szükséges időre, és tesztelési csapat méretére vonatkozóan.
✔ Megfogalmazunk egy nagyvonalú ütemezést a tesztelési feladatokra vonatkozóan
FAQ
Mennyi ideig tart egy ERP‑bevezetés KKV‑knál?
A bevezetés hossza a cég méretétől, a modulok számától és az egyedi fejlesztések arányától függ, de KKV‑knál az igény megfogalmazásától a működő, éles rendszerig 2-4 évvel kell számolni. Ha a tesztelést túl rövidre vágják vagy túl későn kezdik el, akkor jellemzően a go‑live utáni időszak „hosszabbodik meg” váratlan hibajavításokkal.
Milyen feltételei az ERP‑bevezetésnek KKV‑knál és mik a tipikus problémák?
Alapfeltétel a világos üzleti cél (mitől lesz jobb a működés), a kijelölt folyamatgazdák és key userek, akik időt kapnak a projektre, valamint legalább egy alap tesztmódszertan és eszköz. A tipikus problémák: erőforráshiány, kiforratlan tesztelési gyakorlat, túlzott függés a szállítótól és az, hogy az ERP‑projektet pusztán IT‑projektként kezelik, holott a cég egész működését érinti.
Mely fázisokban a legkritikusabb a tesztelés?
Kiemelten fontos a tervezés fázisa, ahol eldől, mit és hogyan fogtok egyáltalán tesztelni. Majd az integrációs tesztfázis, ahol az interfészek és modulok közötti együttműködés sikeressége kederül, és legvégül a felhasználói tesztek (UAT) és a go‑live szimuláció, ahol a valós üzleti folyamatokat játsszuk végig. Ha ezek közül bármelyiket kihagyjuk vagy alulbecsüljük, a go‑live kockázata nagyságrendekkel nő.
