Üzleti intelligencia rendszerek bevezetése

Üzleti folyamatok újraszervezése - kontírozás

Az első rész itt olvasható.

Az elemzéseket mindig a jelenlegi helyzet áttekintésével kezdjük, melynek során a leendő partnertől – megfelelő titoktartási szerződés mellett - megkapjuk az adatbázist, amelyet ingyenesen megvizsgálunk. Ebben a fázisban semmit sem tudunk cégről és nem igazán tudjuk, hogy pontosan mit csinál. Az adatok azonban magukért beszélnek, bár ekkor a tévedés veszélye még nagy, mert még a felhasználói felületet sem tanulmányozzuk és nem áll rendelkezésre sem a számviteli politika sem a számlarend. Ez többek között azt jelenti, hogy nem tudjuk, hogy mi tekintendő lényeges hibának és mi lényegtelen hibának, és ekkor még nem ismerjük az éves és évközi zárás rendjét és a számlák vezetésének módját. Nem feledhetjük, hogy a hibák besorolása jelentősen eltér a könyvelés és az elemzés esetén, ami azt eredményezi, hogy az elemzési környezet felállítása rengeteg olyan hibát fog felszínre hozni, amelyet a számlapolitikai nem is tekint hibának. Azt egyértelműen meg lehet azonban állapítani, hogy a rendszer elemezhető-e, és azt is, hogy az elemzés milyen eredményt hozhat a megbízó számára.

És ilyenkor pontosan ez a cél.

Ehhez a vizsgálathoz azonban már fel kell állítani egy elemző környezetet. Ez az elemzési környezet lehetőséget ad az adatok csoportosítására, így mód van arra, hogy cég gazdasági vezetésének segítségével leválogassuk a félreértelmezett és ismeretlen adatokat és folyamatokat valamint a munka folytatása esetén gyorsan jussunk el az első használható kockáig. (Kockának nevezünk egy elemezhető adathalmazt.)

 

A most bemutatott adatokat valós adatok, amelyek úgy vannak torzítva, hogy a céget ne lehessen felismerni, azonban az adatok jellege megmaradt. Maguk az értékek persze nem mérvadóak.

 

Az első részben megterveztünk egy multidimenziós kódrendszert és ennek segítségével leírtuk a cég szerkezetét. A következő lépés a főkönyvhöz kapcsolódó kockák létrehozása, de már a létrehozással párhuzamosan meg kell kezdeni az adatok és cég üzleti folyamatainak elemzését. Az adatok és a folyamatok elemzése nem választható szét és igen gondosan kell eljárni, mert a KKV szektorban – a fent említett ok miatt - gyakran olyan mennyiségű probléma kerül felszínre, amely sokkolja a szakszemélyzetet és károsan befolyásolja a projektet.

A kedvezőtlen helyzetek kialakulásának elsősorban az lehet az oka, hogy egy ERP rendszer bevezetését sokszor gondolják informatikai és/vagy könyvelői feladatnak, pedig a valóság az, hogy ez kifejezetten gazdasági igazgatói és gazdaságelemzői feladat. Ha a bevezetést informatikai feladatnak gondoltuk, akkor az igazi eredményt hozó üzleti folyamatok újraszervezése valószínűleg elmaradt. Ilyenkor a cél ennek az újraszervezésnek az utólagos elvégzése, aminek a támogatását egy olyan speciális „eredmény-kimutatási” kocka elkészítésével kezdünk, amely azzal a képességgel rendelkezik, hogy az eredmény-kimutatás minden tétele tovább bontható és igen sok szempontból elemezhető.

 

Tekintsünk meg egy ilyen kocka bevezetésének első lépéseit és egészen az első újraszervezési igény megjelenéséig kövessük végig. Ez persze mindenhol más és más lesz, ugyanis ez a folyamat kifejezetten testre szabva történik.

 

 

A főkönyv adataiból kiindulva tehát elkészítjük az „Üzletmenet”, az Eredmény és a Mérleg kockát. Az Eredmény és Mérleg első szintje megegyezik a könyvelés ugyanilyen nevű kimutatásával, de módot ad arra, hogy a sorok mögötti részleteket is tanulmányozzuk.

Maguk a kockák egy Excel ikonként jelennek meg az igazgatók képernyőjén:

 

Most az üzletmenettel foglalkozunk.

Ennek már az első szintje is eltér a klasszikus eredmény-kimutatástól, ugyanis szívesebben indulunk ki egy összefoglaló nézetből.

  1. ábra. Üzletmenet kocka 1. szint

(A költségstruktúrát a „Sorcímkék”-re, az összeget az „Érték” mezőbe kell húzni. Így)

 

Miután az ábra nem tartalmazza a vizsgált időszakot, ez a kimutatás az összes év összes adatát tartalmazza. Ez pedig nem alkalmas következtetések levonására, tehát mindig célszerű kijelölni egy időszakot (napot, napokat, hónapot, hónapokat, stb.). Amikor teljesítménymutatókat készítünk, akkor általában egy adott időszak érdekel minket, továbbá az hogy az eredmény megfelel-e az időarányos tervnek. Most azonban nem ez a cél, hanem annak megmutatása hogyan keletkeznek a felhasználható adatok.

Az, hogy mi kerül a „Bevételek” és „Kiadások” rovatba az egy számlatükörhöz rendelt, felhasználó által szerkesztett segédtábla határozza meg. Pontosan úgy, ahogyan a könyvelés mérleg vagy eredmény-kimutatása kerül meghatározásra. Tehát magát a számlatükröt egészítjük ki. Természetesen az éles rendszertől függetlenül. Ez kimutatás-tervezési feladat. Az ábrában az üres mező azt mutatja, hogy a bevételek és kiadásokat tartalmazó tételeken kívül sok más tranzakciót (pl. pénzmozgást) is rögzít a főkönyv, ami sem bevételnek sem kiadásnak nem tekinthető. Adhatjuk esetleg az "Egyéb tranzakciók" nevet neki, vagy bármit, a névadás felhasználói feladat is lehet.

 

Az, hogy egy-egy sorhoz most milyen főkönyvi tételek tartoznak meg is tekinthető és ki is nyomtatható:

2. ábra. A jóváírt bevételek mögött lévő főkönyvi számlák megtekintése

(A „főkönyvi számlaszám neve” mezőt a sorfejlécre húztuk. Így.)

 

Ez lehetővé teszi az azonnali ellenőrzést. Most a főkönyvi számok nevét írattuk ki, mert a kimutatás vezetőknek szól, akik nem feltétlenül ismerik a főkönyvi számokat. Nem is ez a dolguk. Ugyanígy ellenőrizhető bármely másik tétel is. Egyszerűen ráhúztuk a számlaneveket a sorcímkékre, ennek következtében megjelenik, hogy az adott sor mely főkönyvi számlákból áll. A fenti kimutatást egy egyszerű szűrő beállításával értük el. Ha ezt nem tesszük akkor igencsak terjedelmes lesz a lista.

 

Tekintsünk rá a kiadási oldal egy lehetséges felépítésére. Olyan főkönyvi számokat gyűjtünk egy csoportba, amelyeknek a kezelése a csoporton belül hasonló eszközöket igényel. A felosztás lehet például ilyen:

3. ábra. A kiadási oldal egy lehetséges csoportosítása.

(A „Kiadások”-ban fúrunk le a + jelre kattintva)

 

Ebben a kimutatásban az "Adó", "Bér", "Anyag" és "Ráfordítás" csoportoknak vajmi kevés köze van  a könyvelés hasonló egységeihez. Első szinten az "Adó"-k esetében a deklarált adók helyet a cégre rákényszerített költségeket gyűjtjük össze (általában a "Sarc" nevet adjuk a csoportnak), a bér megjelölés a munkaerő összes költségét tartalmazza (beleértve a természetbeli juttatásokat és a rejtett bér elemeket), az anyag és ráfordítás pedig az összes egyéb költséget tartalmazza.  Itt tehát az a lényeg, hogy lehetőleg természetes neveket használjunk.

A fenti kimutatásban a kiadás előtt lévő + jelre, majd a „Normál" előtti jelre kattintva jelent meg ez a struktúra, amely a kiadások alkalmas üzleti bontását tartalmazza. Ezt mondjuk lefúrásnak. Azt, hogy milyen bontást tartalmaznak a szintek mindig a cég üzleti sajátosságainak függvénye, amelyet általában a gazdasági vezető határoz meg. Bár a BI mindig személyre szabott fejlesztés, de az áttekinthetőség azért meghatározza, hogy mit milyen csoportosításban érdemes megjeleníteni.

 

Érdekesség:

Ha a bevételeknél az adatokat tartozik/követel formában íratjuk ki, akkor lehetetlen nem észrevenni, hogy ebben a mintában a stornó, a jóváíró és a technikai tételek értéke rendkívül magas. A bevétel tartozik oldala és a kiadás követel oldala olyan magas, hogy szükségesnek látszik kiemelten vizsgálni és feltárni a mögötte lévő üzleti folyamatot. Ennek támogatása érdekében most beépítünk egy olyan szintet, amely kizárólag ennek a jelenségnek a vizsgálatára szolgál. Ha a jelenséget feltártuk és/vagy nem ítéltük hibának vagy a hibát kijavítottuk, akkor ezt a szintet néhány mozdulattal megszüntetjük.

 

4. ábra. Tartozik/Követel forma

(A Tartozik és a Követel mezőket húztuk az adatterületre. Így.)

 

Nézzük meg ennek időfüggését:

5. ábra. Lefúrás a következő szinte

(A bevételre történt leszűkítés és a bevétel kibontása)

 

Rögtön látszik, hogy az összes nyilvántartott év összes bevételével valami probléma biztosan van. Itt egy jelentős értékű elutasító (jóváíró, stornó, engedmények, stb.) tétel van. Ezzel mindenképpen foglalkozni kell és meg kell néznünk, hogy ez miből származhat. Ez az a pont, amikor ki kell íratnunk a bizonylat számát és szép csendben ki kell keresni a forrásdokumentumokat. Egy mozdulat.

 

Ha akár költségcsökkentés, akár bevételnövelés oldalon akarunk feltárni rejtett üzleti lehetőségeket, akkor ismernünk kell az üzleti folyamatokat. Alapvető fontosságú az is, hogy az üzleti folyamatok és a könyvelési tételek között egy-egy értelmű kapcsolat legyen. Ez azt jelenti, hogy minden üzleti folyamat legyen felismerhető a könyvelésben. Ez egy kő kemény feltétel. A fent ábrában pl. a „Csökkentő” tételeket nem tudtuk beazonosítani, de a többi tétel mögött rejlő üzleti folyamat sem világos.

 

Itt el kell oszlatni egy félreértést: a korszerű rendszerekben nincs szintetikus könyvelés!

 

Ezeknek a rendszereknek az elvi felépítése a következő:

6. ábra. Az ERP rendszerek moduláris felépítése

 

Az ERP rendszer alrendszereket tartalmaz. Minden alrendszer teljes-körűen lefedi a cég egy-egy üzleti területét. Az alrendszerekben lévő elemi gazdasági eseményeket a kontírozás sorolja be a főkönyvi (és ritkán üzleti) szempontok szerint, mégpedig úgy, hogy minden elemi eseményhez egy vagy több kontírozási tétel tartozik. A kontírozásokat egy napló oly módon rögzíti, hogy az esemény és a kontírozása egyértelműen össze van rendelve. Minden kontírozási tétel a „feladás” (amit nem feltétlenül látunk) során egy vagy több főkönyvi bejegyzést hoz létre. A főkönyvi bejegyzés egyértelműen össze van rendelve a kontírozási naplóval, az pedig az alrendszerrel. (Ezt jelöltem az azonos színnel.) Itt észre kell venni, hogy ez az eljárás okozza azt, hogy egy főkönyv a KKV szektorban is akár 3-4 millió bejegyzést tartalmazhat.

 

A kulcskérdés mindig az, hogyan működik a kontírozás. Erre három tipikus megoldás van:

 7. ábra. A kontírozási megoldások

 

Az automatikus megoldások rendkívül fejlettek lehetnek. Alább a Windirect ERP rendszer megoldása látható, amely gyakorlatilag megszerkeszti a kontírozásban szereplő főkönyvi számokat, miközben figyelembe veszi bizonylatot, a szervezeti egységet, a partner speciális kérésit, stb.

A pénztári események automatikus kontírozása

 8. ábra. Az automatikus kontírozás egy megvalósítása

 

Ez a rendszer igen jól működik, ámbár nagy hibája, hogy kétségbeesésbe kergeti a hagyományos iskolázottságú könyvelőket. Ebbe a kategóriába tartozik a nagyrendszerek technikai alrendszerének a kontírozása is, azaz a zárási, nyitási, amortizációs, stb. eseményeket a legtöbb rendszer automatikusan kontírozza. Az így kontírozott tételek hibamentesek, de az elemzési igényeket csak akkor elégíti ki, ha szabályokat úgy állítjuk össze, hogy a gazdasági események felismerhetőek legyenek.

 

A másik megoldás a gazdasági események listájának használata. Ekkor a gazdasági vezetés összegyűjti a cég gazdasági eseményeit és meghatározza (valamint dokumentálja) a kontírozását. Maga a kontírozás a megfelelő esemény kiválasztásából áll. Ha a kontírozási napló tartalmazza az alrendszer tételeinek és a kontírozási eseménynek az azonosítóját, akkor ez a megoldás is jó lehet. A hibalehetőséget az jelent, hogy a kiválasztásnál lehet tévedni. A tévedés az üzleti intelligencia eljárásokkal sokszor feltárható, de a KKV szektorban ez nem mondható költség-hatékonynak és nincs is rá igazán szükség. A működés mindig olyan szinten elemezhető, amilyen finom bontással rendelkezik az eseménylista és amennyire megbízható az események összeállítása. A szakirodalom több ezer gazdasági eseményt ismer, tehát komoly felelősség a cég számára optimális eseményrendszer kialakítása.

 

A harmadik megoldás a kézzel történő kontírozás. Gyakorlatilag az összes hiba és azonosíthatatlan gazdasági esemény ebből származik. Az élet megköveteli ennek a lehetőségnek a jelenlétét, de ha a számuk nagy, akkor a cég szervezettsége biztosan nem kielégítő (esetleg rossz rendszert választottunk vagy hibás a bevezetés).

Sok problémát tud okozni az eseményrendszerben történő nem elég körültekintő belenyúlás is, de ezek javíthatóak (csak pénz és idő kérdése).

 

No, álljunk meg a gazdasági esemény fogalmánál.

Szinte bármilyen rendszerhez nyúlunk azt fogjuk tapasztalni, hogy a gazdasági esemény azt jelenti, hogy milyen főkönyvi számokat kell kitölteni és hogy mivel. Erre mondjuk azt, hogy ez könyvelői szemlélet. A dolgok háttere az, hogy a kettős könyvelés évszázados elveken alapszik és akkor lett megfogalmazva, amikor kézzel könyveltek. Ennek megfelelően egyszerűnek és áttekinthetőnek kellett lennie. Az is volt.

A kettős könyvelés (és az ezen alapuló mérleg és eredmény) tehát a cég működésének egy modellje, mégpedig nagyon egyszerű modellje. (Az, hogy mégis egy nagyon bonyolult folyamattá vált a könyvelés, kizárólag a jogalkotó politikusok unintelligenciájának a következménye.) A másik érdekessége, hogy minden adatbázis-kezeléssel foglalkozó könyv első öt oldalán megtalálható, hogy egy adatot csak egy helyen tároljunk. Ezek után a kettős könyvelés úgy indul, hogy valamit két helyre írok be....

Lehet, hogy úgy rossz az egész ahogyan van?

Nem. Mindössze arról van szó, hogy a kettős könyvelés nem relációs adatbázissal dolgozik. Hogy is dolgozhatna azzal, hiszen ez valójában papíralapú rendszernek készült és csak ráerőltettük a - relációs adatbázisokat használó számítógépekre. A klasszikus főkönyv tehát egy időt, egy minőségi és egy mennyiségi adatot tartalmaz. A két azonosító adatra mondjuk azt, hogy dimenzió, a mennyiségi adatra pedig, hogy mérték. Ez tehát egy kétdimenziós egy mértéket tartalmazó modell.

Egy életszerű gazdasági esemény azonban egy rakás dimenziót és néhány mértéket szokott tartalmazni, ami pedig nem képezhető le a főkönyvi számok diszjunkt halmazára. Ezért a könyvelési rendszernek újabb dimenziókat kell tartalmaznia ahhoz, hogy alkalmas legyen az elemzésre. Ezzel már kísérletezett a kettős könyvelés is, ezért vezették be a 6-os és 7-es számlaosztályokat. Magunk között szólva - informatikai szempontból - a 8-as számlaosztály is egy csacskaság volt. A számítógépes rendszerek gyakran vezetnek be olyan azonosítókat, amely a gazdasági események jobb leírását célozzák meg. Ilyen például a munkaszám, sarzs szám, LOT szám, stb. Ezek újabb dimenziók, amiket akkor adunk meg, amikor a főkönyvhöz szüksége könyvelési eseményt adjuk meg. Az igazán jó rendszerek, azonban szabadon felhasználható dimenziókat is biztosítanak.

Amikor egy kockát létrehozunk, akkor valójában a dimenziók és mértékek egységét hozzuk egy nagyon könnyen kezelhető formára.

Ha a dimenziók okosan vannak kitöltve, akkor jól elemezhető a működés, ha nem, akkor az üzleti intelligencia elsősorban a helyes eseményrendszer kialakításánál nyújt segítséget.

 

Nézzünk megint egy konkrét példát:

Azt akarjuk megállapítani, hogy érdemes-e átállni az e-számlára. Az átállásnak van fix és változó költsége, és a postai számlaküldésnek is van költsége. Állapítsuk meg hogy mennyit költünk a számlák kiküldésére.

 

Ahonnan a példát vesszük, elkészítettünk már egy költség-kockát, ez valós, de megbuzeráltuk az összegeket.

A cégnél van egy önálló „Posta, futár” gazdasági eseménye, amelyikre ízibe beállítottunk egy szűrést (ezt mutatja a tölcsér). A lefúrás lehetővé tette, hogy megnézzük hova van lekönyvelve a „Posta, futár” azonosítóval ellátott esemény?

9. ábra. A „Posta, futár” azonosítóval ellátott esemény megjelenése az üzletmenet kockában

 

Nyilván nem fog vitát kiváltani az az kijelentés, hogy ezen még „finomítani” kell (-:

De nem ez a baj. Nekünk arra lenne szükségünk, hogy olyan eseményt találjunk, hogy a "Számlák postázása". Az jól látszik, hogy a cégnél megjelent a strukturálás iránti igény, de az is, hogy nem lett jó. Ráadásul ez egy önálló dimenziót foglal el, ami egyben a hibák forrása is. Ez a besorolás tehát tökéletesen használhatatlan. Marad a főkönyvi szám. Nem marad. Nem tudjuk megmondani, hogy a "Postai díjak" és a "Postaköltség" tartalmazza-e a számlák feladásának díját, ha igen, akkor ez mekkora.

Vajon jó lenne-e, ha alábontanánk a postai díjakat és létrehoznánk egy "Számla kiküldési költség" nevű számlaszámot. Ez csak akkor lenne alkalmas a számlák postázási költségének mérésére, ha egyúttal hoznánk egy intézkedést, hogy a postai számlán a számlák feladása egy önálló tétel legyen és magától értetődik, hogy a számlaleveleket is külön kellene kezelni. Ennek pedig sokrétű költsége van (nem fogja megérni).

Marad a természetes intelligencia használata. Néhány kattintással hozzunk létre egy új kimutatást. A dimenzió a régió, az ország  vagy amit akarunk, a mérték padig a nem készpénzes számlák száma. Ezt követően csak azt kell megtudni, hogy az egyes régiókat milyen költségen tudom elérni a számlalevéllel. Ennek meghatározásakor azt sem fogjuk elfelejteni, hogy a számla kiküldés költsége koránt sem a postai költség. De erről majd máskor.

 

Nézzünk egy másik példát.

Előzőleg abban bizonytalanodtunk el, hogy a postai díjak számlaszáma nem tartalmaz-e más eseményt is. Válasszunk ki most egy konkrét főkönyvi számlaszámot és nézzük meg, hogy milyen eseményeket kontíroztunk rá.

10. ábra. Az „EGYÉB ANYAG,BEREND.,FELSZER” főkönyvi számra kontírozott események

 

A „Nincs” azt jelenti, hogy nincs megadva a gazdasági esemény. Hát, itt is van mit megbeszélni a gazdasági igazgatóval. Eggyel mélyebbre fúrva azt is megnézhetjük, hogy konkrétan mit takar egy-egy tétel.

Tegyük ezt:

 

11. ábra. A „Reprezentáció” besoroláshoz tartozó számla tételének megnevezése

 

Kétségtelen, hogy van olyan munkakör, ahol ma már csak full extrás seprűvel lehet reprezentálni, de azért – biztos, ami biztos - itt is ki kellene kérni a gazdasági igazgató véleményét (-:

Megjegyzem némi furkálódás után az is kiderül, hogy az Üzemanyag xxx-999 egy konkrét gépkocsi üzemanyag előlege, ami azért szintén nem semmi besorolás.

 

Vagy vegyünk egy harmadik példát.

Ez az árbevételnél található technikai tételek egy részét mutatja be:

 

 

12. ábra. A technikai tételek

 

A leghelyesebb, ha erre csak azt mondjuk, hogy érdekes megoldás. Az tisztán látszik, hogy a gazdaságelemzés igénye ennél a cégnél már megjelent, de azért az is látszik, hogy nem sikerült az elképzelés. Egyébként egy ilyen esetben készítünk egy kimutatást, átadjuk és azt kérjük, hogy magyarázzák meg hogy mit látunk.

 

Itt sem az a baj, hogy esetleg hibás a kontírozás, hogy sok az elkönyvelés ill. áttekinthetetlenek a gazdasági események, hanem az, hogy a cég szervezettsége nem kielégítő, az ellenőrzési rendszerek nem működnek, ezért a könyvelés nem segíti elő a folyamatok elemzését és a hibás folyamatok kijavítását.

 

A gazdasági eseménynek olyannak kell lenni, hogy egy kívülálló ill. a cég vezetése és tulajdonosa is egyértelműen lássa, hogy milyen események történtek és milyen értékben.  Ha a kontírozás nem megbízható vagy nem kellően érthető, akkor esély sincs arra, hogy elemezni lehessen a folyamatokat. A példákból az is kiolvasható, hogy a BI bevezetésével a kontírozás a továbbiakban már nem az NAV kedvéért történik, az pedig csak sejthető, hogy a hagyományos NAV orientált kontírozást nem zavarjuk meg.

 

Megoldható, de komoly probléma lehet a bérszámfejtés. Ha a bérszámfejtésről nincs analitikus adatunk (nincs ilyen alrendszer), akkor gazdasági elemzésről nehéz beszélni. Az outsourcingban végzett bérszámfejtés esetén pedig a „feladás” mindössze fél tucat tétel szokott lenni. Ez így nem jó, ezt is meg kell oldani.

 

 

Ez az a pont, ahol le kell ülni cég gazdasági igazgatójával és be kell azonosítani, hogy milyen üzleti folyamatokat különböztetnek meg és egy-egy üzleti folyamatot hogyan könyvelnek le. Valójában ezt a számviteli politikának kell tartalmaznia, de ez általában korántsem kielégítő részletezettségű. Az adatbázisokat vizsgálva meg nagyon úgy tűnik, hogy a könyvelést még nem igazán érte el a minőségbiztosítás. Ráadásul a számviteli politikában megadott súlyos hiba az elemzés szempontjából általában egyáltalán nem hiba, viszont az elemzés szempontjából a működést kizáró hibák a számlapolitikában még a csekély hiba szintet sem éri el. Leginkább észre sem veszik.  Gondoljunk az adattisztítás fejezetben bemutatott főkönyvre, amelyben sok száz 2018-ra könyvelt tétel volt.

 

A gazdasági vezetővel való egyeztetés eredményeképpen az induló csoportosítás jelentősen megváltozhat, sőt az üzleti folyamatok tisztázása után bizonyos tételeket (pl. technikai tételeket) - az adattisztítás során - ki kell zárni az elemzésből.

Ismét hangsúlyozom ezt a gazdasági döntéshozó szerepkört sem a könyvelő, sem a kontroller nem veheti át.

 

Az ERP bevezetés talán legfontosabb kérdése az, hogy mit valósítunk meg számlatükör bontással, és mit dimenzionálással. Ha ezt a bevezetésnél nem elég körültekintően végeztük el, akkor az egészet lehet előröl kezdeni. Ha kezdeti felosztást a cég kinőtte, akkor az jó jel, mert már kialakult a jobb felosztáshoz szükséges tapasztalat.

 

Valójában itt kell megállni.

Körülbelül eddig tudunk eljutni az adatbázis előzetes és ingyenesen elvégzett áttekintésével. Az üzleti folyamatok azonosítása nélkül a továbblépés olyan veszélyeket rejt, amit nem jó vállalni, de már ezen a szinten is jól szemléltethető az on-line analízis lehetőségei.

 

 

Jelen esetben az adatbázis tulajdonosának azt fogom tanácsolni, hogy erősítse meg a gazdasági vezetést és kezdjék meg a könyvelés újraszervezését. A BI rendszer az újraszervezést a bevitt adatok ellenőrzésével (az adattisztítással) és az eredmények azonnali tesztelésével tudja támogatni. Az elemzés folytatása minden bizonnyal arra fog vezetni, hogy a korábbi évek elemzéséről le kell mondani, mert a javítás költsége nem fog megtérülni.

Jelen esetben azt is tanácsolom, hogy álljanak le minden informatikai fejlesztéssel. Ezek a fejlesztések most csak a káoszt növelik, mert egy eredendően hibás adatbázisra alapozzák őket.

 

 

Egyébként egy ilyen cégnél nagyon gyorsan megtérül az újraszervezés és gazdálkodás-elemzés költsége.

 

 

A most következő részben azt szemléltetjük, hogy milyen segítséget kaphatunk az üzleti intelligencia rendszertől, de ezekből most még nem vonhatunk le semmilyen következtetést, a szerepe mindössze az, hogy támogassa a folyamatok felismerését és azonosítását ill. a meglévő hibák és zavarok feltárását.

 

A következő lépésben megnézzük a bevételek idő szerinti eloszlását:

13. ábra. A bevételek évek szerinti eloszlása

(Az év nevű mezőt az oszlopterületre húzzuk. Így.)

 

Ebben az adatbázisban nyilván 2007 volt a bevezetési év, ahol még nem alakult ki a megfelelő könyvelési gyakorlat (nem ritka az a jelenség sem, hogy a rendszerben bent maradnak a tesztadatok, ami súlyos bevezetési hiba, de szinte mindig zavart okoz az, hogy az 1-es számlaosztály tételeit visszamenőleg is be viszik az amortizáció miatt).

A fenti esetben minden bizonnyal az elemzést 2008-tól lehet kezdeni. 2010 nem teljes év.

 

A 2008 előtti éveket célszerű kivenni az elemző adatbázisból (és ezt meg is tehetjük mert önálló, az éles adatoktól független adatbázison fut az elemzés). Most – a demóban - ezeket csak egyszerűen elrejtjük egy szűrés segítségével:

 

14. ábra. Szűrve a használható évekre és két eseménytípusra.

(A szűrőben beállítottuk, hogy csak a 2008, 2009 és 2010-es évek szerepeljenek a kimutatásban.)

 

Tehát tetszőlegesen vizsgálhatunk bármilyen időszakot, éveket, évet, hónapokat vagy napokat. Ez azért fontos mert ebben az adatbázisban például felismerhető havi és negyedéves elhatárolás is. Gyakori feladat az eltérő elszámolási időszakok kezelése is. A vevőlátogatásokra általában heti terveket készítenek, az értékesítés heti elszámolású míg a gazdasági teljesítmény értékelése tipikusan havi, negyedéves és éves. Ezeket tehát alapból kell tudni kezelni.

 

Miután ma már mindennaposnak mondható, hogy egy cég az több cég, ezért nézzük meg, hogy a magas stornó és jóváíró tételek száma melyik cégünknek a problémája.

15. ábra. A cégek szerinti eloszlás.

(A %-ok nem a BI kimutatás része, hanem a megfelelő mezőre kattintva egyszerűen kiszámoltuk a kimutatás melletti oszlopban.)

 

Bár ez a 4,5% stornózott érték meglehetősen magas, azért semmiképpen nem nevezhető tragikus hibának. Azért azonnal megnézném, hogy ki állította ki a számlákat, kik a vevők, milyen tételek vannak a számlán és megpróbálnám megállapítani, hogy van-e tendencia a sztornózásban. Az ábra – mint látható - csak egy évre vonatkozik.

Itt kell megemlíteni azt is, hogy ha cégek szerint konszolidált adatokkal akarunk dolgozni és a virtuális cégek esetén nyilván úgy akarunk dolgozni, akkor azonos felépítésű számlatükörre lenne szükség.

A fenti példában viszont a cégek számlatükrei 416 helyen térnek el egymástól.

 

Az események behatárolása igényelni fogja a számlák kézi ellenőrzését. Ez úgy támogatható, hogy egy újabb kattintással kiíratjuk a tisztázandó eseményhez tartozó számlákat:

16. ábra. Egy számla megkeresésének támogatása.

(A számlaazonosítót hozzáadjuk a kimutatáshoz. Így.)

 

A jóváírások és a stornók a cég működés szempontjából meglehetősen kritikusak. Ez lehet ugyan az üzleti stratégia része, de utalhat egyszerű hanyagságra, ami viszont biztosan megjelenik a cég többi üzleti folyamatában is. Mutathat azonban rosszindulatú folyamatot is, amely kárt okoz a cégnek és szándékosan vagy hanyagságból a jutalék rendszert is nagyon megzavarhatja. Igen fejlett jóindulattal megközelíthetjük ezt egyszerű zavarként, de a NAV pontosan azért szabályozza a stornózás folyamatát olyan rigorózusan, mert ők tudnak valamit.

Kétségtelen, hogy a stornózás a cég működésének egy nagyon jó mérőszáma. Egyszerre jellemzi a marketinget, a vállalkozást, a teljesítés, a minőségbiztosítás és az adminisztráció munkáját is.

 

A fenti ábra azt is mutatja, hogy milyen egyszerű a könyvelési adatokat együtt vizsgálni a számlázási adatokkal.

 

Egyszerűen lehet partnereket is vizsgálni:

17. ábra. Partnerek folyamatainak ellenőrzése.

(Egyszerűen behuzigáltuk a kívánatos mezőket a sorfejlécbe.)

 

Az árbevételi kocka tovább fúrható és elemezhető az értékesítés irányában is. A következő szinten a bevételek két fő folyamatra bontottuk, Főtevékenységre és Egyébre, de a bontás mindig a cég üzleti tevékenységéhez illeszkedik:

18. ábra. Az üzletmenet struktúra tetszőlegesen mély lehet.

 

A bontás a továbbiakban a termékszerkezethez igazodhat, bonthatunk például gazdasági eseményre, régióra, termékcsoportra vagy bármire amit pontosan meg lehet fogalmazni. A struktúra utolsó eleme célszerűen maga a számla.

 

Gyakorlatilag bármilyen létező adat szempontjából elemezhetjük a folyamatainkat:

19. ábra. Szinte bármilyen egyéb kimutatás készíthető.

(Partner-Üzletmenet-Idő struktúra)

 

Természetesen a klasszikus kimutatások is előállíthatóak néhány kattintással:

 

20. ábra. Szinte bármilyen egyéb kimutatás készíthető.

(Hagyományos főkönyvi kimutatás)

Az 5, 51, 511-es gyűjtőknek azért nincs neve, mert a bevezetésnél nem igazán szerencsésen konvertálták át a számlatükröt. Bevezetési hiba, ami az elemző adatbázisban egyszerűen javítható.

 

De szerkeszthetünk érdekesebb kimutatásokat is:

21. ábra. Egy adott év negyedéves áttekintő listája.

 

Itt például érdekes a villamos energia vagy a gázfogyasztás költsége. Itt bizony kikérném a számlákat.

 

De könnyedén tudunk összehasonlítani eltérő évek azonos időszakait is:

 22. ábra. Érdekes szűrések

 

Általánosságban az mondható, hogy ebben a fázisban a fix költségeket célszerű vizsgálni és mindig extrém értékeket kell keresni és elemezni, mert az esetek többségében az ilyenek mögött az üzleti folyamatok valamilyen érdekessége vagy zavara van. Ezek közül kell kiválasztani azt, amely a legerősebben hat az eredményre és mindig ezekkel kell kezdeni az üzleti folyamatok újraszervezését.

A másik kiemelten vizsgálandó feladat a nem megfelelő arányok keresése. A fenti ábrákon például érthetetlen az anyagköltség/ráfordítás aránya.

 

Összefoglalás

A cikk az on-line elemzés lehetőségeit mutatta be. Az online elemzések a tipikusan üzleti feltáró elemzések. Amivel a meglévő adatok segítségével speciális, könnyen használható, dinamikus kimutatásokat készíthetünk.

Ezek tipikusan:

  • Összegzett jelentés (dashboard report)

  • Elemző jelentés (analytical report)

  • Részletes jelentés (production report)

Az on-line elemzés kialakítását két fázisban javasoljuk:

  1. az elsőben az éles adatokkal ingyenesen készítünk egy demót, amely áttekintő képet ad az elérhető eredményről,

  2. a másodikban a megrendelést követően kiépítjük az éles on-line elemzést.

A gazdasági kimutatások ezen a szinten nem tartalmaznak megosztott költségegeket (csak akkor ha maga az ERP rendszer is tartalmazza)

A kimutatások a 2010-es MS Office segítségével készültek.

 

Kupán Károly

UnitedIT Informatikai Kft.

Kupan.Karoly@UnitedIT.hu

 

Ugrás a lap tetejére