Rosszul működő ERP okainak feltárása

Mit jelent valójában az, hogy „rosszul működik az ERP”?

Ez több különböző helyzetet jelenthet.

Például:

• a rendszer hibás eredményt ad;
• az adat nem megbízható;
• túl sok kézi beavatkozás szükséges;
• a dolgozók rendszeresen megkerülik az ERP-t;
• ugyanazt az adatot több helyen rögzítik;
• a folyamat túl lassú;
• az ERP nem támogat egy fontos üzleti esetet;
• a rendszer támogatná, de nincs megfelelően konfigurálva;
• vagy a vállalat működése időközben megváltozott, miközben a rendszer nem követte ezt.

Ezeket nem érdemes egyetlen kategóriába sorolni.

Más megoldást igényel egy szoftverhiba, egy rossz törzsadat, egy hibás üzleti szabály és egy rosszul kialakított folyamat.

Ezért az első feladat az okok szétválasztása.

1. Ne általános problémából induljon ki, hanem konkrét üzleti esetből

A „készlet rossz” még nem vizsgálható állítás.

Ehelyett érdemes kiválasztani egy konkrét esetet.

Például:

Egy adott rendelésnél az ERP 120 darab elérhető készletet mutatott, miközben ténylegesen csak 80 darab volt kiadható.

Ezután már meghatározható:

• melyik termékről volt szó;
• melyik rendelés érintett;
• mikor történt az esemény;
• milyen készletállapotot vártunk;
• mit mutatott ténylegesen a rendszer;
• kik használták vagy módosították az adatot;
• és milyen események előzték meg az eltérést.

Az általános panasz helyett visszakövethető üzleti eseményre van szükség.

2. Határozza meg a várt és a tényleges eredményt

Minden vizsgálható problémához két dolgot kell egyértelműen megfogalmazni:

Mi lett volna a helyes eredmény?

és

Mi történt ténylegesen?

Ha ez a különbség nincs pontosan meghatározva, akkor azt sem lehet eldönteni, hogy a későbbi javítás valóban megoldotta-e a problémát.

Például:

Várt eredmény:

A részben kiszállított rendelés fennmaradó mennyisége továbbra is foglalásban marad.

Tényleges eredmény:

A részszállítás után a teljes foglalás felszabadul.

Ez már konkrét, reprodukálható működési eltérés.

3. Kövesse végig az adat teljes útját

Az ERP-ben megjelenő hibás adat nem feltétlenül az ERP-ben keletkezett.

Érdemes végigkövetni:

adat keletkezése → rögzítés → módosítás → feldolgozás → integráció → üzleti szabály → megjelenítés → felhasználói döntés

Minden ponton más típusú hiba keletkezhet.

Vizsgálni kell például:

• honnan származott az eredeti adat;
• mikor került a rendszerbe;
• ki rögzítette vagy módosította;
• milyen üzleti szabály dolgozta fel;
• történt-e import vagy integráció;
• milyen konfiguráció volt érvényben;
• történt-e manuális beavatkozás;
• és melyik rendszer vagy adatforrás tekinthető irányadónak.

A képernyőn látható hibás eredmény gyakran egy korábbi esemény következménye.

4. Hasonlítsa össze hibás és helyes esettel

Az egyik legerősebb vizsgálati módszer egy hibás és egy helyesen lefutott üzleti eset összehasonlítása.

Ha látszólag ugyanolyan két rendelés közül az egyik megfelelően, a másik hibásan működik, akkor a különbség értékes információ.

Érdemes összehasonlítani például:

• a törzsadatokat;
• a vevő vagy termék beállításait;
• a rendelés típusát;
• a jogosultságokat;
• az időpontokat;
• az integrációs eseményeket;
• az ár- és kedvezményszabályokat;
• a készletállapotot;
• a felhasználói lépéseket;
• valamint az alkalmazott kivételeket.

A cél annak meghatározása:

mi az a körülmény, amely a hibás esetet megkülönbözteti a helyestől?

5. Válassza szét a lehetséges okokat

A Kyntrax megközelítésében a „rosszul működik az ERP” problémát érdemes több külön rétegben vizsgálni.

Folyamat

A rendszer azt valósítja meg, amit kértek tőle, csak maga a folyamat hibás?

Például fölösleges jóváhagyási pont vagy indokolatlan kézi lépés lassítja a működést.

Adat

A rendszer megfelelően dolgozik, de hibás, hiányos vagy késői adatból?

Például:

• rossz mértékegység;
• hibás ár;
• hiányzó beszállítási idő;
• elavult vevői adat;
• pontatlan készletinformáció.

Üzleti szabály

Pontosan meghatározott-e, hogy a rendszernek milyen feltételek mellett mit kell tennie?

Előfordulhat, hogy két munkatárs ugyanarra az üzleti helyzetre két különböző „helyes” választ ad.

Ilyenkor nem feltétlenül technikai problémáról van szó.

Konfiguráció

Képes lenne az ERP a szükséges működésre, csak nincs megfelelően beállítva?

Ez különösen fontos, mert egy konfigurációs probléma miatt felesleges lehet komplett rendszerprojektet indítani.

Jogosultság és szerepkör

A megfelelő ember megfelelő időben hozzáfér-e a megfelelő funkcióhoz és információhoz?

A túl szűk és a túl tág jogosultság egyaránt működési problémát okozhat.

Integráció

Megfelelően jut-e át az adat egyik rendszerből a másikba?

Vizsgálni kell többek között:

• kimaradt eseményt;
• késést;
• duplikációt;
• sorrendhibát;
• hibás adattérképezést;
• sikertelen feldolgozást.

Felhasználói működés

A rendszer használata megfelel-e a kialakított működésnek?

Itt nem arról van szó, hogy automatikusan a felhasználót kell hibáztatni.

Ha a munkatársak rendszeresen ugyanazt a kerülőutat alkalmazzák, annak általában oka van.

A kerülőút maga is működési bizonyíték.

Szoftverkorlát vagy szoftverhiba

És természetesen előfordulhat az is, hogy valóban maga a rendszer:

• hibásan működik;
• nem képes támogatni a szükséges folyamatot;
• technológiailag elavult;
• nem skálázható;
• vagy ésszerű keretek között már nem alakítható tovább.

De ezt érdemes bizonyítani, nem feltételezni.

Nem minden Excel az ERP kudarca — de minden kerülőút kérdést érdemel

Ha egy vállalat kulcsfontosságú folyamatokat Excelben kezel az ERP mellett, az fontos jelzés.

De önmagában még nem bizonyítja, hogy rossz az ERP.

Meg kell kérdezni:

• Miért jött létre ez a táblázat?
• Milyen funkciót lát el?
• Milyen adatot tartalmaz, amely az ERP-ben nincs?
• Ki tartja karban?
• Melyik adatforrás az irányadó?
• Mi történne, ha a táblázat megszűnne?
• Valóban rendszerkorlátot kerül meg, vagy egy rossz folyamatot tart életben?

Az ilyen párhuzamos megoldások sokszor pontosan megmutatják, hol vált szét a hivatalos rendszer és a tényleges működés.

Milyen bizonyítékokra érdemes támaszkodni?

Egy ERP-probléma vizsgálatakor az emlékezet vagy a felhasználói benyomás önmagában kevés.

Érdemes konkrét működési nyomokat keresni.

A cél nem egyszerűen bizonyítékot találni arra, hogy „az ERP rossz”.

A cél annak meghatározása, melyik ok magyarázza legjobban a tényleges eltérést.

Szemléltető példa

Tegyük fel, hogy ugyanaz a rendelés kétszer jelenik meg az ERP-ben.

A tünet egyértelmű:

duplikált rendelés.

Ennek azonban több oka lehet.

1. Integrációs probléma

A külső rendszer kétszer küldte el ugyanazt az eseményt.

2. Hibás feldolgozási logika

Az ERP ugyanazt az eseményt kétszer dolgozta fel.

3. Felhasználói újrarögzítés

Az első import eredményét a felhasználó nem látta időben, ezért manuálisan újra létrehozta a rendelést.

4. Folyamatprobléma

Nincs egyértelmű szabály arra, mikor tekinthető egy importált rendelés elfogadottnak.

A képernyőn mind a négy eset ugyanúgy nézhet ki:

két rendelés van egy helyett.

A szükséges javítás mégis teljesen más.

Ezért:

azonos tünet nem jelent azonos okot.

Miért veszélyes túl gyorsan az ERP-t hibáztatni?

Mert könnyen rossz problémára születik drága megoldás.

Ha például a készletinformáció azért pontatlan, mert:

• a fizikai mozgásokat késve rögzítik;
• több párhuzamos készletnyilvántartás létezik;
• nincs egyértelmű foglalási szabály;
• vagy a rendelésmódosítások nem jutnak el időben a raktárhoz,

akkor egy új ERP önmagában nem feltétlenül oldja meg a problémát.

A vállalat akár úgy is lecserélheti a rendszerét, hogy közben ugyanazt a működési hibát költözteti át egy új platformra.

Ez az ERP-csere egyik legdrágább lehetséges tévedése.

Mikor indokolt javítani, és mikor lehet indokolt ERP-t cserélni?

A rendszer lecserélése akkor válik megalapozott lehetőséggé, ha bizonyítható, hogy a vállalat kritikus működési igénye és az ERP reális képessége között olyan rés van, amely ésszerűen nem zárható.

Például akkor, ha a rendszer:

• egy kritikus üzleti folyamatot nem képes megfelelően támogatni;
• szükséges integrációt nem képes megbízhatóan kezelni;
• üzletileg szükséges változtatásokat csak aránytalan költséggel lehet megvalósítani;
• technológiai korlátai akadályozzák a vállalat működését;
• vagy fenntartása nagyobb üzleti kockázatot jelent, mint a csere.

Ezzel szemben önmagában egy:

• hibás törzsadat;
• rossz konfiguráció;
• tisztázatlan folyamat;
• jogosultsági probléma;
• vagy javítható integrációs hiba

még nem bizonyítja, hogy új ERP-re van szükség.

ERP-cseréről nem elégedetlenség, hanem bizonyított működési rés alapján érdemes dönteni.

Hogyan ellenőrizhető, hogy valóban megtaláltuk az okot?

Egy valószínű magyarázat még nem bizonyított gyökérok.

A feltételezett okot ellenőrizni kell.

Ideális esetben:

1. reprodukálható az eredeti probléma;
2. azonosítható az azt kiváltó körülmény;
3. a körülmény kontrollált megváltoztatásával a probléma megszűnik;
4. az eredeti üzleti eset helyesen fut le;
5. a kapcsolódó kivételek sem sérülnek;
6. és a javítás nem hoz létre új problémát máshol.

Ez különbözteti meg a valódi okfeltárást attól, hogy valamit egyszerűen „átállítottunk, és most működni látszik”.

Mikor tekinthető lezártnak egy ERP-probléma?

Nem akkor, amikor eltűnik a hibaüzenet.

Hanem amikor meghatározható:

• mi volt a tünet;
• mi volt a várt működés;
• mi volt a tényleges működés;
• mi okozta az eltérést;
• milyen változtatás történt;
• hogyan ellenőriztük;
• és milyen eredmény bizonyítja, hogy a probléma megszűnt.

Ha ezek közül az ok nem ismert, akkor lehet, hogy a tünet eltűnt, de a probléma nincs valóban megoldva.

A Mirror szoftverhibakereső szolgáltatás?

Nem.

A Kyntrax Mirror nem forráskódszintű debugger, és nem helyettesíti az ERP gyártójának vagy fejlesztőjének technikai hibavizsgálatát.

A Mirror feladata más:

a vállalati működés összefüggéseinek feltárása.

Vizsgálja többek között:

• a folyamatokat;
• az információáramlást;
• az adatforrásokat;
• a szerepeket és felelősségeket;
• a döntési pontokat;
• a rendszeren kívüli működést;
• a kivételeket;
• és az ERP körül kialakult kerülőutakat.

Ha a vizsgálat alapján technikai rendszerhiba valószínűsíthető, annak részletes forráskód-, adatbázis- vagy infrastruktúraszintű vizsgálata már külön technikai feladat.

A fontos különbség:

a Mirror nem azt próbálja bizonyítani, hogy az ERP hibás.

Azt próbálja meghatározni, hol van a működési probléma valódi oka.

Mit ad az ERP-probléma működési diagnózisa?

Egy megfelelő vizsgálat után elkülöníthetővé válhat:

• mi valódi szoftverhiba;
• mi konfigurációs probléma;
• mi adatprobléma;
• mi integrációs hiba;
• mi folyamatprobléma;
• mi felelősségi vagy szabályozási kérdés;
• és mely esetben van tényleges rendszerképesség-hiány.

Ez alapot ad annak eldöntéséhez, hogy a következő lépés:

• folyamatjavítás;
• adatkorrekció;
• konfiguráció;
• integrációjavítás;
• oktatás;
• rendszerfejlesztés;
• vagy ERP-csere legyen.

A Kyntrax megközelítése

A Kyntrax nem abból indul ki, hogy a panasz megnevezte a probléma okát.

Ha egy vállalat azt mondja:

„rossz az ERP”

a következő kérdés nem az, hogy:

„mire cseréljük?”

Hanem az, hogy:

„pontosan mi nem működik, hol keletkezik az eltérés, és mi bizonyítja az okát?”

A Kyntrax Mirror a vállalati működés egészében keresi az összefüggéseket.

Nem különálló szoftverként vizsgálja az ERP-t, hanem annak a működési rendszernek a részeként, amelyben emberek, folyamatok, adatok, szabályok és más technológiák együtt dolgoznak.

Ez teszi lehetővé, hogy a következő döntés ne feltételezésen alapuljon.

Előbb az okot kell bizonyítani. Utána lehet eldönteni, mit érdemes megváltoztatni.