Az adatok minősítése, adattisztítás

Még mielőtt hozzálátnánk az on-line analízis és a teljesítménymutatók összeállításának előkészítése azzal kezdődik, hogy megvizsgáljuk az adatok alkalmasak-e erre a célra.

Az adattisztítás azért érdemel kiemelkedő figyelmet, mert a cég működésére lehet belőle következtetni. Ekkor olyan mély információkhoz lehet jutni, ami egyéb eljárással nagyon költséges lenne.

Az adattisztítás hat feladatát tekintjük át:

•         Tervezési hibák korrigálása

•         Besorolási hibák korrigálása

•         A nem használt adatok kiszűrése

•         Extrém adatok kiszűrése

•         Működési hibák megvizsgálása

•         Egy hibajegyzék elemzése

A tervezési hibák korrigálása

Az alábbi ábrán egy terméktörzs látható.

Ebben a termék törzsadatban azonban nem csak termékek vannak, hanem szerepelnek itt a szolgáltatások és egyéb gazdasági események is. Ezt a táblát használja a rendszer, amikor beazonosítja a könyvelési tranzakció tárgyát, amely termék, szolgáltatás vagy gazdasági esemény lehet, de ez alapján történik a számla kiállítása is.

Ez nagyon nem jó az elemzésnél, mert az egyébként is nagy figyelmet igénylő tevékenységben feleslegesen terheli az elemzőt.

A fent látható tábla valójában nem is terméktörzs, sőt valódi terméktörzs itt nincs is. Természetesen ez a tervezési megoldás a napi munkát nem zavarja, az ERP rendszer felhasználója ezt észre sem veszi.

A megoldás ennek a táblának átalakítása és az eltérő adattípusok specifikus adatainak szétválogatása önálló táblákba. Ez teszi lehetővé azt, hogy pl. a termelés számára készült OLAP-kockában ne szereplejen könyvelési kifejezés.

A fenti ábra akár sokkal bonyolultabb is lehet, például megoldható, hogy a termékek struktúrákat képezzenek (garnitúra, gyártási egység, részegység, alkatrész, stb.).

Az adatok szétválogatása és besorolása azonban okozhat némi fejtörést.

Az adatbázis átalakítása rendszerfejlesztői feladat.

A nem használt adatok kiszűrése

Egy nagyobbacska rendszerben 1000 feletti adattábla is lehet tízezernyi mezővel. Az elemző rendszerek általában ennek a töredékét használják, ugyanis az ERP rendszereket úgy készítik, hogy egymástól nagyon távollévő adottságú és profilú cégek is tudják használni. Ha ennek egy konkrét telepítését nézzük, akkor a táblák egy jelentő része üres. Jogos az az igény, hogy ezek meg se jelenjenek az on-line elemzési rendszerben.

Ugyancsak az előkészítési fázisban lehet a mezőket átnevezni a ténylegesen használt nevükre, pl. a PRODUCTID mezőnév kaphatja a Termékazonosító nevet.

Ennek megfelelően az elemző csak olyan adatokkal találkozik, amelyet ténylegesen használ is, és sohasem találkozik a szoftverfejlesztők által adott, az elemzőnek semmitmondó adatokkal.

A besorolási hibák korrigálása

Részint az üzleti folyamatok egységes kezelése érdekében, részint információtechnikai megfontolásokból az ERP rendszerek üzemeltetése során törzsadatokat kell bevezetni. A rendszerek által nyilvántartott adatok törzsadatokból és forgalmi adatokból állnak. A törzsadatok használatának célja az azonos jellegű, gyakran használt adatok összegyűjtése, az egységes feldolgozás és a könnyű kezelhetőség biztosítása, ezért a gazdasági események feldolgozásához a rendszer a törzsadatokban rögzített alapadatokat veszi igénybe. A törzsadatokat azonban meglehetősen nehéz pontosan definiálni, mindössze annyit mondhatunk, hogy ezek olyan adatok, amelyek ritkán változnak.

Az ilyen ritkán váltózó adatok közé tartoznak a csoportok is (termékcsoport, eszköz csoport, anyagcsoport, vevőcsoport, beszállító csoport, stb.) Ezek szintén az egységes kezelés érdekében létrehozott csoportok, de ezek esetében az egységes üzleti megoldások jelentik a csoportképzés alapjait.

Egyes ERP rendszerek az általánosságra való törekvésük következtében olyan megoldásokat alkalmazna, amelyek jelentős hibaforrásnak tekinthetőek.

Tekintsük a következő példát:

Vizsgálni akarjuk egy kiválasztott termékcsoport üzleti eredményeit és a vizsgálat eredményeképpen döntést hozunk a csoport jövőjére vonatkozóan. Ha ebbe a csoportba több száz termék tartozik, akkor szó sem lehet a termékek egyedi kezeléséről, csak a csoport egészének az adataiból indulhatunk ki.

Az informatikai rendszerünk azonban a következő lehetőséget biztosítja: van egy terméktörzs (PRODUCT) és minden terméket két eljárással lehet csoportokba sorolni a PRODUCTGRUPNAME és PRODUCTGRUP táblák segítségével. Az első eljárás úgy van kialakítva, hogy egy termék sok termékcsoportba besorolható, a második úgy, hogy minden termék csak egy termékcsoporthoz tartozhat. A csoportokat viszont mindkét esetben tetszőlegesen hozhatjuk létre.

Tételezzük fel, hogy a táblák az alábbi módon lettek kitöltve:

Részlet a másik táblából:

Miután kapcsolat nincs köztük minden további nélkül megtehetjük, hogy az egyik eljárással egy terméket besoroljuk a „Tagi hitel” csoportba, a másik eljárással pedig „ALAPANYAG” csoportba. A rendszer el fogja fogadni, aminek az eredménye az lesz, hogy az elemzés eredménye attól fog függni, hogy melyik eljárást alkalmazzuk. Ennél nincs nagyobb hiba.

További probléma, hogy a csoporton belül sincs semmilyen ellenőrzés. Azaz ugyanazt a terméket be lehet sorolni pl. a „KÉSZTERMÉK”, az „ALAPANYAG” és a „GÖNGYÖLEG” csoportba. Mindez azt eredményezi, hogy egy ellenőrzés során egészen kábító hibák kerülhetnek elő, aminek kijavítása meglehetősen időigényes, ráadásul több szakember együttműködését igényli (nem könnyű ugyanis eldönteni, hogy az MZ/X nevű termék, most "Késztermék", "Alapanyag" vagy "Kimaradt a leltárból" csoportba tartozik, vagy esetleg mindegyikbe). Ugyanakkor ha egy döntést hozunk a meglévő „KÉSZTERMÉK” csoport alapján, miközben fontos termékek tévedésből nincsenek ide besorolva, továbbá vannak olyan besorolt termékek, amelyeknek köze sincs a késztermékekhez, akkor ez akár komoly üzleti veszteség forrása is lehet.

Visszatérve az indító felvetésre a „Göncök” nevű termékcsoport jövőjéről történő döntéskor többek között figyelembe vettük a FKT-1/A, a TN123/3 és a GAU-8/A kódú termékek forgalmát is. Ha Ön – mint az elemzést végző Kedves Olvasó – esetleg nem ismeri fejből mind a 20 000 terméket, akkor emlékeztetném, hogy a FKT-1/A kódjelű termék a „Főkötő”, a TN123/3 a „Tunika”, a GAU-8/A pedig a General Electric 30 mm-es, hétcsövű gépágyúja.

Ennek következtében ezekre a termékcsoportokra az elemzés során csak akkor támaszkodhatunk, ha előtte kijavítottuk az összes hibát, ami szinte biztos, hogy a csoportok újrafogalmazásával, az adatgazda kijelölésével és betanításával kezdődik.

A termék és vevőcsoportok pedig fontos elemei az elemzésnek, mert sok folyamatot csak csoportra érdemes vizsgálni.

 Az ilyen besorolási (és kódrendszer) hibákat néhány tízezer adat esetén szinte lehetetlen kijavítani.

Az extrém adatok kiszűrése

Tekintsük meg a következő ábrát:

Az ábra egy adott termek egy adott évben elért forgalmát mutatja. Az „X” tengelyen az egy tételben eladott mennyiség szerepel. Az bal oldali „Y” tengelyen az adott nagyságú tétel gyakorisága, azaz hány számlán található az adott tételnagyság. Az jobb oldali „Y” . tengelyen a mennyiséghez tartozó átlagár található.

A fekete egyenes a logaritmikus trend. (Az adatértékek nem valósak, de az arányok igen.)

A extrém adat abból származik, hogy nagy tételt kiskereskedelmi áron adtak el. Ez egy súlyos CRM hiba.

És tekintsük meg a következő ábrát is:

Az ábra egy adott termek egy adott évben elért forgalmát mutatja. Az „X” tengelyen az egy tételben eladott mennyiség az „Y” tengelyen a mennyiséghez tartozó átlagár található.

 A 1296 darabos tétel egységára azonban annyira rossz, hogy ez már biztosan meghamisítja az átlagok értékét és veszélyesen eltolja a trendet is.

A helyzet azonban sokkal bonyolultabb. Állapítsuk meg a vevőket, azaz húzzuk a vevőneveket a tételek mögé.

Megállapíthatjuk, hogy Tiportfejű Tihamér áldozat volt. Ha így teszünk akkor nagyot tévedünk. Tekintsük a következő ábrát, ahol az átlagárat a vevőkre képeztük (azaz egyszerűen eltávolítottuk a tételmennyiséget a kimutatásból).

Az ügyfél akinek jelentősen túlszámláztunk valójában alig vásárol magasabb áron mint a többiek. Ez tehát nem átvágás, nem elírás és nem tévedés, hanem üzlet. A számlák kompenzálják egymást. Ez az üzleti megoldás azonban a rövid időszakra számolt átlagokat tönkreteszi.

A gyakorlatban nehéz az extrém adatokat kezelni. Elvben nincs akadálya annak, hogy az adattisztítás során kiszórjuk az extrém tételeket, de akkor meg a forgalom szenved csorbát, nem beszélve a fenti esetre, ahol az üzlet részeként jelent meg extrém adat. Ha az extrém adatokat bent hagyjuk, akkor az nagyon jól mutatja a cég működési hibáit, ha kivesszük pontosabb következtetésre lesz lehetőségünk. A KKV szektorban feltehetőleg helyesebb a bevezetési szakaszban bent hagyni az extrém adatokat.

Az üzemi adatbázis semmiképpen sem módosítható. Az extrém értékek kihagyása közbenső adatbázisban oldható meg, ahova az adattisztítás első lépéseként átvisszük az éles adatbázist. Ezt következően meg kell határozni azt a tűrési szintet, ami kijelöli az extrém adatokat. Ez sem egyszerű feladat, de ezt követően a közbenső adatbázisból kitörölhetjük az extrém adatokat.

Ez fejlesztői feladat.

A működési hibák megvizsgálása

Tekintsük meg a következő ábrát:

Az ábra egy adott termek egy adott évben elért forgalmát mutatja. Az „X” tengelyen az egy tételben eladott mennyiség az „Y” tengelyen a mennyiséghez tartozó átlagár található.

Az ábra láttán azt a kérdést kell feltennünk, hogy szabad-e ebből az üzleti folyamatból bármilye következtetést levonni. Az hogy egy átlagos termék egységára az eladott mennyiségtől függetlenül több mint 400%-ot szór számos kérdést felvet. Mindenekelőtt azt, hogy nincs-e itt valami baj.

Mit lehet ilyenkor tenni? A legfontosabb teendő az, hogy az állásfoglalás előtt meg kell ismerni a teljes üzleti folyamatot. Azaz:

1. Be kell azonosítani a vevőket.

2. Be kell azonosítani az üzletkötőt.

3. Ki kell kerestetni az összes alapdokumentumot (számla, szerződés) és meg kell győződni arról, hogy az adatok megfelelnek az alapdokumentumnak. Ezzel kiszűrtük a rögzítési hibákat.

4. Ellenőrizni kell a termék fedezetszámítását. Ha nincs, akkor el kell készíteni.

5. Ellenőrizni kell a teljesítést a szállítólevél alapján.

6. Ellenőrizni kell a pénzügyi teljesítést a bankkivonatok alapján.

7. Meg kell interjúvolni az üzletkötőt.

Ha ily módon kellő áttekintésünk van a konkrét folyamat fölött, akkor össze kell hívni az érdekelteket, és tisztázni kell, hogy a feltárt eljárás megfelel-e cég üzleti érdekeinek. Egyébként lehet, hogy megfelel, de ez esetben kellő óvatossággal kell meghatározni az on-line analízis cégen belüli feladatát.

Ha felmerül az érdeksérelem, akkor ki kell keresni az összes hasonló esetet, meg kell találni a közös elemeket és megfelelő intézkedésekkel meg kell szüntetni a hibát. Ha nincs hiba, akkor az üzleti folyamatok újraszervezésére van szükség.

Ennek a folyamatnak a hatékony lebonyolításához az elemző rendszernek működnie kell, és az értékesítési kockának biztosítani kell az alábbi lehetőségeket:

• A tételszám-átlagos egységár diagram felvétele.

• Lefúrás a partnerek irányába.

• Lefúrás a számlaszámok irányába.

• Lefúrás a területi képviselők irányába.

• Lefúrás a bank irányába.

• Lefúrás a szállítólevelek irányába.

• Lefúrás a területi képviselők irányába.

Szűrési lehetőséget kell biztosítani:

• Az évekre (az idő struktúrára)

• A termékekre és termékcsoportokra.

Mindez azt igényli, hogy az adattisztítás előző fázisai már megtörténtek.

Egy hibajegyzék elemzése

Az elemzési adatbázis előállítása az éles adatbázis átmásolásával kezdődik és a kockák összeállításával ér véget. A teljes folyamatot végigkíséri az adatok feltárása és dokumentálása.

Az összegyűjtött hibák egy önálló, erre a célra létrehozott kocka segítségével elemezhetőek. A hibák felismerését és kigyűjtését végző algoritmus mindig egyedi fejlesztéssel készül. Célszerű minden szakterület minden adatcsoportját ellenőrizni. A mellékelt példa egy részterületet mutat be. Mindenek előtt fel kell hívnom a figyelmet arra, hogy az itt bemutatott anomáliák az ERP rendszer kezelőfelületéről nem láthatóak. A hibák feltárása és kijavítása elkerülhetetlen, mert ezek egy része egyszerűen lehetetlenné teszi az on-line elemzést.

Az első és utolsó sor az előfeldolgozás időszükségletét dokumentálja. A fenti kimutatás egy egyszerű gépen olyan fél millió számlatételt és 3 millió tételes főkönyvet ellenőrzött és dolgozott fel 25 perc alatt, de nem tartalmazza a kockák előállításának idejét (de az sem több 10 percnél). Tehát a KKV szektorban időrobbanási probléma nem nagyon van.

A verzió azért szükséges, mert a tisztítási és feldolgozási algoritmust a folyamat egyes szakaszaiban módosíthatjuk, ezért a jelentés tartalma és a számadatok változhatnak. Például egyes tételek (hibatípusokat) esetleg kiveszünk a jelentésből, esetleg leszűkítjük az utolsó két évre vagy az utolsó elszámolási időszakra, stb.

Fussunk át a tételeken:

1. 2003 előtti tételek. Valójában 1996-os tételeket is találtunk a 2003-ban telepített rendszerben. Ez lehet hibás és gondatlan bevezetés, de lehet komoly rendszer hiányosság is. Ilyenkor ellenőrizzük le, hogy egyáltalán lehet-e törölni időszakokat a rendszerből. Teljes tartományok törlése némely rendszerben a felhasználó számára lehetetlen. Az átmeni adatbázisban a kilógó tételeket töröljük.

2. 2010.12.31 utáni tételek. 2013-2018-as tételeket fogunk találni, amikor a sorok mögé kiíratjuk a dátumot. Maradjunk annyiban, hogy ez egy „sajátos hiba”, mert ezek a tételek kikerültek a könyvelésből. Mindenképpen be kell azonosítani, hogy miért keletkeznek ilyen tételek és a folyamatot esetleg szabályozni kell (felelősséget mindenképpen illik szabályozni). A kilógó tételeket az elemzésből töröljük.

3. A be és kimenő számlákon található partnernév nem egyezik a partnertörzsben található névvel. Ezeket ellenőrizni kell, mert ez nem feltétlen hiba. A hibák egy része arra utalhat, hogy nincs kellően szabályozva a törzsadatkezelés. Ellenőrizni kell, hogy van-e kijelölt adatgazda és tisztában van-e a feladatával. Csak figyelmeztetés, a hibákat nem is javítjuk. A problémát az okozza, hogy ugyanaz az adat kétszer van letárolva (egyszer a forgalmi adatok között, egyszer a törzsadatban). Ez egy olyan adattervezési hiba, amelyik törvényi alapokon nyugszik. Az adattárház adja a jó megoldást.

4. A főkönyvben nem létező partner van. Ez a főkönyv tartalmaz analitikus adatokat, így pl. a partnert. A hiba arra utal, hogy a főkönyvben olyan partner is szerepel, amelyik nincs benne a partnertörzsben. Az eredeti dokumentumok alapján lehet javítani a hibát. Az adattisztításban csak egy alapértelmezett partnert írunk be.

5. A számlákon van olyan számlatétel, amely nem nincs lekönyvelve. Nem javítható, mert eredményt módosítana, ezért töröljük.

6. Hiányzik a partner adószáma. A bejövő számlákon kötelező adat, a kimenő számlákon a vevő adószáma csak speciális esetekben kötelező. Törekedni kell az adószámok begyűjtésére és ellenőrzésére. Ellenőrizni kell, hogy a rendszer a bejövő számlák esetén vizsgálja-e az adószámot, ha nem, akkor ki kell dolgozni egy módszert a kérdés kezelésére. Csak figyelmeztetést küldünk, az adatokhoz nem nyúlunk.

7. Hibás stornózás. Az üzenet jelzi, hogy a stornózási szabályok sérültek. Minden stornózott számlához tartozni kell egy sztornózó számlának. A hibás tételeket töröljük.

8. Idegen karakter a főkönyvi számlaszámban. Tipikusa a „-” szokott lenni. A hibás tételeket töröljük.

9. Ismétlődik az adószám. Ellenőrizni kell, ha a cégbíróság által bejegyzett névváltozáshoz tartozik-e az ismétlődő adószám, ez esetben nem hiba, egyébként javítani kell. Figyelmeztetés.

10. A jóváíró tételek száma. Nem hiba. Azt kell megfontolni, hogy a jóváíró tételek száma összhangban van-e az elvárt ügyviteli fegyelemmel. Ha nincs, akkor meg kell vizsgálni a jóváíró tételek keletkezésének okát, és ki kell dolgozni egy új üzleti és/vagy ügyviteli megoldást.

11. Kézzel módosított rekord. Észre lehet venni, hogy hátulról belenyúltak az adatbázisba. Tisztázni kell, hogy korrektül szabályozva van-e a felelősség. Az árulkodó nyomokat eltüntetjük.

12. Stornózási adatok. Nem hiba. Azt kell megfontolni, hogy a stornózások száma nem túl magas-e. Ha igen, akkor tisztázni kell az okát, meg kell állapítani, hogy köthető-e személyhez vagy céghez.

Javítást csak az elemzéshez tartozó előkészítő adatbázisban végzünk. Az, hogy az egyes jelenségeket hogyan kezeljük, mindig a megbízóval való egyeztetés során dől el.

 Részletek megtekintés: