Az ABC módszer használata üzleti intelligencia megoldásokkal

(ABC = tevékenység alapú költségszámítási módszer)

V1.05

Tartalomjegyzék:

 

Bevezetés

 

Az anyagot az ABC eljárás oktatási segédanyagának szánjuk, melynek célja a módszer áttekintő ismertetése, így átmenetet képez a marketing szintű ismertetés és a tervezési és elemzési példák között.

Az anyag meglehetősen terjedelmes, de arra számítunk, hogy olvasója kifejezetten érdeklődik a téma iránt. A leírás bemutatja magát a módszertant, az üzleti intelligencia módszerrel megvalósított implementációt, az ABC módszer továbbfejlesztését és a távlati fejlesztési lehetőségeket. A következő szint már a felméréshez szükséges riportok levezetési technikáját mutatja be, amely már semmilyen kitekintést nem tartalmaz, így azon a szinten összefüggések már nem ismerhetőek fel..

 

 

Az Activity Based Costing módszer bemutatása

 

Az elmúlt évtizedben a közvetlen költségek nyilvántartása és feldolgozhatósága látványos fejlődésen ment keresztül, ami Ez elsősorban a HAPCII és a minőségbiztosítási követelmények teljesítésének érdekében történt. Ez a közvetlen költségek gazdaságelemzésében új perspektívákat nyitott.

 

Továbbra is nagy gond azonban az általános költségek megjelenítése az önköltségben, amit a hagyományos költségfelosztás az alábbi módon kezelt:

1. ábra. A hagyományos költségelemzés sematikus ábrája

 

A hagyományos költségfelosztás lépései:

A fix költségeket a könyvelés felelősségi egységekre bontva gyűjti, majd a második lépésben valamilyen algoritmus szerint felosztják a szolgáltatórészlegek költségeit a termelőrészlegek között. A harmadik lépésben a termelőrészlegek költségeit az általuk legyártott termékekhez rendelik hozzá. A termékeken lévő költségtömeget a legyártott darabszámmal osztva kapjuk meg az önköltséget. A módszer sokszor nagyon pontatlan, de még ennél is nagyobb hibája, hogy eltünteti a veszteségforrásokat, elfedi a hibás működést és annak okait. Ha például egy fuvarozási szolgáltatással foglalkozó cég esetén a kihasználatlanul álló járművek költségét (amortizáció, karbantartás, tárolás, stb.) is ráterheljük a szolgáltatásárunkra (tonna/kilométer-re), akkor a hagyományos önköltségszámításnál  az jön ki, hogy nagyon drágán dolgozunk, holott a probléma valójában az, hogy felesleges kapacitást tartunk fent.

 

Olyan költségelemzésre lenne szükség, amely világosan rámutat, hogy mi mennyibe kerül és feltárja a működés hibáit. Nagy lépés ebbe az irányba az ABC (Activity-based Costing) elemezés, amelynek sematikus ábrája a következő:

2. ábra. Az ABC eljárás logikája

 

A költségelemzés most is azt a kérdést vizsgálja, hogy a bemeneti erőforrások milyen arányban oszlanak meg a a költségviselők (költségobjektumok) között. Azonban ebben a megoldásban a költségeket nem szervezeti egységekhez (felelősségvállalási egységekhez, költségcentrumokhoz) rendeljük, hanem tevékenységekhez és mindig csak annyit, amennyi az adott tevékenységhez valóban szükséges. Ezt követően meghatározzuk, hogy mely termék (szolgáltatás, egyéb objektum) milyen tevékenységeket milyen arányban vett igénybe.

Valójában az eljárás során az általános költségek egy részét - az értékteremtési láncban betöltött szerepük figyelembevételével - közvetlenköltségekké alakítjuk, így lényegesen pontosabb tükrözi az előállításához szükséges erőforrások mennyiségét és értékét.

Minden vállalkozásnak erőforrásokat kell fordítani arra is, hogy megtartsa a vevőit, új vevőket szerezzen ill. megtarthassa a termékeinek és szolgáltatásainak a piaci jelenlétét. Ezek ugyanolyan fontosságú költségobjektumok, mint a termékek. Ez a költségobjektum azonban nem kapcsolódik sem egy termékhez sem egy szolgáltatáshoz, ezek önálló költségobjektumot képeznek és hiba lenne ezeket a költségeket a termékek között felosztani.

Hasonló a helyzet a termékek piacra hozatalához szükséges csatornák fenntartásával, ezeknek a költségeit sem jó a termékek között szétosztani. Ugyanakkor fontos kérdés, hogy mennyibe kerül egy-egy csatorna (bolt, WEB shop, területi képviselő, ügynök, stb.) fenntartása.

Az erőforrások egy része azonban nem épül  be sehova, hanem veszteségként jelenik meg. A veszteség lehet anyagjellegű veszteség. Pl. ha ellopnak 100 kg kakas-rugó-dugó-csapot, akkor talán mégse kellene azt a késztermékekre terhelni, hiszen abból egy darab sincs bennük. Ezek a cég működése szempontjából vesztességek. Ugyancsak probléma az is pl. ha egy nagy, drága gép munkaidejének egy részében áll. Ha gép teljes költségét (béreket, lízing díjakat, amortizációt, fenntartást, stb.) ráterheljük a végtermékre, akkor minden bizonnyal alaposan meghamisítjuk a termék tényleges költségét.

A veszteségek feltárása a gazdálkodás központi kérdése így nagy hiba lenne ezeket  a költségeket a termékekre terhelve eltüntetni szem elől.

A veszteségek meghatározását a klasszikus ABC eljárás nem szolgáltatja.

 

Bár a pontosabb kimutatások érdekében bevezettünk új költségviselőket, ennek ellenére az elemzés során mi szeretnénk eldönteni, hogy a termékköltségbe milyen tételek szerepeljenek és azt hogyan elemezzük, ezért magát az elemzést az üzleti intelligencia eszközrendszerével létrehozott "Költségkockában" fogjuk tanulmányozni.

 

Nézzük meg pontosabban, hogyan zajlik ez az ABC folyamat.

 

A tevékenységalapú költségszámítás logikai felépítése

3. ábra. Az ABC módszer felépítése

 

A módszerben - ragaszkodva a hagyományokhoz - megkülönböztethetjük az általános és a közvetlen költségeket, bár az elemzési fázisban könnyűszerrel megvizsgálhatjuk, hogy melyik költség milyen összefüggésben van a legyártott termékek számával, ezért ezek a fogalmak elvesztik jelentőségüket. Az elemzés szempontjából a számlaosztály szerinti felbontás is lényegtelenné vált hiszen mindenhol azt akarjuk nyilvántartani, hogy miért volt szükség a költségre.

Mindenestre első lépésben meg kell határozni, hogy mely erőforrásoknak van fix költsége. Ez elsősorban a főkönyv alapján történik, de már itt számolunk azzal,  hogy a főkönyv struktúrája nem fog egyezni az erőforrások struktúrájával .                                                                                               

Az ábrán látható, hogy a módszer nem igényli a szervezeti egységek szerinti feldolgozást (nem ábrázolunk szervezeti egységeket), ennek ellenére minden (általam ismert) rendszer használja a szervezeti egységeket, aminek az az oka, hogy a meglévő gyakorlat folytatásaként és az oszd meg és uralkodj elv következtében a bevezetés így lényegesen egyszerűbb.

 

Második lépésben össze kell gyűjteni a tevékenységeket. A tevékenységek teljes száma akár elképesztően nagy is lehet. Erre azonban az önköltségszámítás esetén nincs igazán szűkség, hozzávetőleg 70-80 tevékenység után a figyelembe vett tevékenységek számának növelése nem lesz arányban sem a pontossággal sem az értékelés nehézségének növekedésével. Ezeknek feltárása és a tevékenységek összevonása a gyakorlatban azért problémás, mert a munkatársak a munkakörük fontosságát a tevékenységek számában látják.  Ha a cél a költségek csökkentése és az újraszervezés, akkor célszerű pontosan felmérni a tevékenységeket.

A tevékenységjegyzék összeállítása is sokkal egyszerűbb ha a folyamatot mindig egy szervezeti egységre és ezen belül erőforrásokra és munkakörre szűkítjük le.

 

Harmadik lépésben a költségeket fel kell osztani a tevékenységek között. Miután egy erőforrás sok tevékenységben szerepelhet, az erőforráson lévő költség általában egy halmozott érték.  Ennek felosztása úgy történhet, hogy minden Erőforrás - Tevékenység előforduláshoz pontosan meghatározzuk, hogy a tevékenység az erőforrás hányad részét veszi igénybe, ez milyen felosztási módszerrel határozható meg és milyen konkrét érték tartozik hozzá. A felosztási arányok meghatározása becslésekkel, kérdőívekkel és interjúkkal történik, de alkalmazható a mintavételezés is. Számos erőforrás-tevékenység páros esetén objektív mérőszámok is rendelkezésre állnak. Van néhány tipikus mérőszám, úgymint az alapterület - ami pl. a takarítási költségek esetén használható, légköbméter a fűtési költségek felosztásához, a munkaállomások száma az informatikai költségek felosztásához, stb.

Célszerű az erőforrásokat már induláskor osztályozni és felbontani humán erőforrásra, anyag jellegű erőforrásra és indirekt erőforrásra amelyeknél nem állapítható meg ok-okozati összefüggés az erőforrás és a tevékenység között.

 

Az erőforrásokat a hozzárendelhetőség szempontjából is csoportosítani kell.

4. ábra. A hozzárendelések fajtái

 

Vannak olyan erőforrások, amelyeknél az ok-okozati összefüggés olyan erős, hogy nincs min rágódni, ezeket direktben hozzárendeljük a megfelelő termékhez. Van ahol drivert kell alkalmazni, azaz meg kell mondani, hogy mi a felosztás alapja és a konkrét értéke. Aztán van olyan, ahol nem tudunk drivert megfogalmazni, mert nincs ok-okozati összefüggés vagy az nagyon bonyolult. Ezeknek az értékét meghasaljuk.

 

Az adatok összegyűjtését követi a felosztás. A felosztás úgy történik, hogy minden erőforrás - tevékenység pároshoz a tevékenységnél feltárt attribútumok alapján kiszámoljuk a konkrét értéket, amit a tevékenységre "számlázunk". Ehhez már tartozhat elszámolási időszak, így a költségelemezés időben is lehetséges. A költségokozók konkrét értékét több dokumentumból szokás összevadászni (főkönyv, bérszámfejtés, szakági nyilvántartások, stb.).

 

A második nagy fejezet a tevékenységeken lévő költségek felosztása a költségviselők között. Ehhez mindenekelőtt számba kell venni a költségviselőket. Költségviselő minden lehet, termék szolgáltatás, vevő, eszköz, folyamat. Bármi aminek a költségére kíváncsiak vagyunk.

 

A tevékenységeken lévő költségek felosztása a költségviselők között a "Tevékenység - Költségviselő" hozzárendelésben valósul meg. Az értékek forrása legtöbbször a gyártási munkalapok, a raktárjegyek, termelési adatok, szervezeti és egyéb cégadatok, stb.

Az eljárás nagyon hasonló az erőforrásdriverek eljárásához, csak ezeket nem az erőforrásokhoz, hanem a tevékenységekhez kell rendelni.

 

A tevékenységeket már az azonosítás / kigyűjtés pillanatában tovább kell osztályozni, hogy a felosztás egyszerűbb legyen.

  • Lesz olyan tevékenység, melyek egy-egy termékhez, mint típushoz tartoznak. Ezek a termékszintű tevékenységek (terméktervezés és fejlesztés, folyamatok műszaki tervezése, műszaki fejlesztés).

  • Lesz olyan, amely egy gyártási egységhez (sorozat, sarzs, LOT, projekt, stb.) tartozik (Batch level). Ezek a kötegszintű tevékenységek (átállítások, anyagmozgatás, felügyelet).

  • Lesznek olyan tevékenységek, amelyek nem oszthatóak fel (ill. nem célszerű felosztani) sem a termékek sem a sorozatok között. Ezek az üzem szintű tevékenységek (üzemvezetés, épületek karbantartása, fűtés, világítás, stb.)

  • Lesznek tételszintű tevékenységek (Unit level) amely költségviselő (pl. termék) minden példányához hozzátartozik (közvetlen munka, alapanyagok, gépköltség, energia)

Ugyancsak a kigyűjtés során kell meghatározni, hogy milyen típusú drivert kell alkalmazni, azaz, hogy a felosztás során mi a vetítési alap.

Ez lehet:

Mennyiségarányos:

  • Közvetlen munkaóra, vagy gépóra.

  • Közvetlen anyagköltség.

  • Munkaterület arányos.

  • Ügyletszám-függő.

  • Átállításokkal, beállításokkal arányos.

  • Rendelésfogadás.

  • Anyagkezeléssel arányos.

  • Felügyelettel, ellenőrzéssel arányos.

Termékfüggő:

  • Fizikai jellemzők (méret, súly, felület).

  • Komplexitás: alkatrészek száma, finomsága.

Értékesítési, igazgatási, egyéb általános:

  • Katalógus mérete és változások.

  • Elosztási hálózat használattal arányos .

  • Tőkebefektetéssel arányos .

A kellően pontos önköltség meghatározásnál a tranzakció jellegű tételek feldolgozása fontosabb mint a mennyiségi tételek figyelembevétele.

 

A hagyományos önköltségszámítás - annak ellenére, hogy a költségtömeg tartalmaz közvetlen költséget és általános költséget is - a költségtömeget veszi alapul.

Az ABC eljárás végeredményben azt okozza, hogy a korábban elszámolás-technikai kényszerből általános költségként kezelt költségek egy részét - valós tartalmuknak megfelelően - már  közvetlen költségként tudja kezelni, de további nagy erénye, hogy azokat a költségeket amelyeknél nincs ok-okozati összefüggés a költség és a termék között nem is veszi figyelembe az önköltségszámítás során, hanem önállóan elemezhető költségobjektumként jeleníti meg.

5. ábra. Az ABC módszer lényege

 

Az eljárás 5-15%-al pontosabb, mint a hagyományos eljárás, mert az általános költségeknek azt a részét, amely valójában a közvetlen költségekhez tartozik, sikerült a helyére tenni, azokat a költségeket pedig, amelyeknél a költség és a végtermék között nincs ok-okozati összefüggés leválasztottuk az önköltségről. Az irodalom gyakran említ 30%-os pontosságnövekedést is. Nem kell kétségbe vonni, mert ha a cég nagyon rossz, akkor ilyen is elképzelhető.

 

 

Számolási példa

 

Az, hogy miért működik ez ilyen jól egy egyszerű példán is belátható. Gyártsunk két terméket ugyanazon a gépen. A "Temék-A" termékből 95 darabot készítünk, a "Termék-B" ből 5 darabot. A két termékből a bevétel 100 eFt. A termék előállításának a költségtömege 90 eFt.  Ennél pontosabban nem tudunk számolni, mert ugyanaz az erőforrás okozza mindkét terméknél a költséget. Ebből 900 Ft önköltség jön ki mindkét termékre, mert a termékenként nem tudunk önköltséget számolni.

 

 

Következő lépésben a termékek és a cég megmaradására fordított költségeket valamint az értékesítésre fordított csatornaköltségeket leválasztjuk a költségtömegről. Ezek a költségek ugyanis nem épülnek be sem az "A" sem a "B" termékbe, így az önköltségben szerepeltetni hiba lenne.

 

 

Ebben a megközelítésben a közvetlen költségünk már csak 80 eFt, így az önköltség már 11%-al pontosabb.

 

Harmadik lépésben az erőforráson futó tevékenységek alapján választjuk szét a költségeket. Két tevékenységünk van (T1, T2), de a "B" termék csak a T2 tevékenységet veszi igénybe.

 

 

A költségeket a tevékenységekre bontva már világosan látszik, hogy a "B" termék hót veszteséges. Ezt korábban azért nem lehetett észrevenni, mert a nagy példányszámban gyártott "A" termék a hátán elviszi a gazdaságtalan "B" terméket. A pontosság ez esetben nem csak 12.5%-al nőtt, de az eljárás a gazdaságtalan terméket is megmutatta.

Fel kell azonban hívni a figyelmet arra, hogy ez semmi esetre sem jelenti automatikusan azt, hogy a "B" termék gyártásával le kell állni.

 

 

A szervezeti egységek bevezetése

 

Az elmondottakból látszik, hogy az ABC módszer nem igényli a szervezeti egységek használatát. Egy erőforrás költség minden további nélkül leosztható tevékenységre a szervezeti egység használata nélkül is. Ennek ellenére a szervezeti egység használata mindenképpen célszerű, aminek egyik oka az, hogy a cég munkatársai szervezeti egységben élnek és gondolkoznak, így használatukkal lényegesen egyszerűbb a modell felállítása és a módszer bevezetése.

A másik ok az lehet, hogy az érték teremtése mindig az emberhez kapcsolódik és nem az eszközökhöz, annak ellenére, hogy a legtöbb ERP rendszerben az eszköz az elsődleges. Ennél sokkal konkrétabb az az igény, hogy minden költségnek legyen gazdája, azaz tudjuk megkérdezni, hogy ez miért annyi amennyi és a tervtől való eltérés számon kérhető legyen.

 

Az első lépésben tehát a költségeket szervezeti egységekhez kell rendelni. Ezzel a szolgáltatással minden ERP rendszer rendelkezik. Ennek megfelelően az alábbi módon módosul az ABC eljárás vázlata:

 

6. ábra. Szervezeti egységek és az erőforrások kapcsolata

 

A szervezetek esetén meg kell különböztetnünk a támogató és a termelő szervezet. Támogató szervezet közvetlenül nem vesz részt a profit termelő folyamatokban, de tevékenységük (általában) nélkülözhetetlen a profittermelő folyamatok fenntartásában. Ilyen például a cégvezetés, informatika, könyvelés, épület üzemeltetés, stb.

Így a klasszikus koncepcióban megjelennek tehát a vertikális bontások, mert a támogató szervezetekhez tartozó tevékenységek költségét fel kell osztani a termelő tevékenységek között.

Az alábbi példában három tevékenység költségét osztjuk rá a termelés egy tevékenységére:

 

9. ábra. Támogató egységek költségfelosztása

 

Ebben a példában első lépésben a Munkaállomás karbantartás tevékenység költségét könyveljük rá a többi tevékenységre, mégpedig a munkaállomások száma alapján. A programozó munkahelyen egy gép található, az IT-hez egy gép tartozik a munkákhoz, három gép van a könyvelésen és három a termelésben az 1. termék gyártásánál. Ennek kezelésére egy globális támogatási-driver sor szolgál, amely a gépek arányában ráosztják az informatika (munkaállomás karbantartás) költségét a többi, számítógépet használó tevékenységre.

A második lépésben a számlakönyvelés tevékenység költségeit osztjuk szét. Ez számlaszám alapján történik, amely az ERP rendszerből ki is olvasható. Ez a driver már viszi magával a könyvelésen lévő informatikai költséget.

A harmadik lépés már csak a gyártásra terheli a programozás és ennek járulékos költségeit. Az, hogy konkrétan mit, milyen elvek és eljárások alapján osztunk szét az a modell alkotáskor kerül meghatározásra.

 

A fenti ábrán a piros nyilak jól mutatják, hogy ezek a driverek valójában végigvezetnek azon az úton, amelyen egy erőforrásköltség egy termékbe (költségobjektumba) épül be.

 

Gondot az okoz, hogy pl. a fenti esetben az informatikai osztály költségei terhelik a könyvelést, de a könyvelés is terheli az informatikai osztály költségét. Két lehetőség van, vagy kiszámítjuk az egyensúlyi állapotot, vagy sorrendet állítunk fel a szervezeti egységek tevékenységei között. Döntés kérdése, de alapértelmezésben mindig egy sorrend szerint osztjuk fel a támogató költségeket.

 

 

Tevékenységek számának korlátozása

 

Általában az mondható, hogy 70-80 tevékenység már megfelelő eredményt hoz, olyan 150 tevékenység a hagyományos megoldások esetén az áttekinthetőség küszöbértéke. Néhány száz tevékenység kezelése gyakorlatilag lehetetlen a hagyományos megoldásokban.

 

Az Üzleti Intelligencia segítségével azonban van lehetőség egyszerűen, de ennek ellenére tetszőlegesen pontosan leírni a szervezetet. A célunk egy olyan leíró rendszer kialakítása, amely áttekintő szinten és teljes részletességgel is képes leírni egy cég valós struktúráját, beleértve az erőforrásokat és a tevékenységeket is.

 

 

 

 

A Üzleti Intelligencia alapú implementáció

 

A modell

 

A valóságos működés leírására modelleket használunk, ezért kulcskérdés a leírás, a modell bonyolultsága. Egyszerűnek tekinthető egy atomreaktor működésének a pontos leírása, de megoldhatatlanul bonyolult pl. egy kétszemélyes Bt. leírása. Ezért a valóságos működésből mindig annyi elemet, tevékenységet, jelenséget hagyunk el, hogy a maradék kezelhetővé váljék. Modellt alkotunk. A modell helyes megválasztása nagyon fontos. Ha a modell túl bonyolult, akkor drága esetleg használhatatlan lesz, ha túl egyszerű, akkor esetleg nem látja el a feladatát.

Amit alább bemutatok az egy konkrét modell. A BI hatalmas előnye, hogy viszonylag egyszerű a modell módosítása és testre szabása, így szabadon vehetünk fel új elemeket a modellbe és hagyhatunk el a konkrét esetben nem releváns elemeket.

 

A cégleíró DNS bevezetése

 

Ahhoz, hogy költséggazdálkodásról, költségelemzésről beszélhessünk nagyon kell ismerni a cégünket. Tudnunk kell hol, mi történik és miért, azaz miért és milyen cél érdekébe keletkeznek költségek.

Pontosan ezért az egész folyamatot a cég leírásával kezdjük. Ez persze nem egy egyszerű dolog, ezért úgy kell megoldani, hogy módunk legyen áttekintő formában is dolgozni vele, de ha szükséges akkor pontosan vizsgálhassunk egy-egy részterületet.

 

Minden élő szervezet rendelkezik egy olyan zárt leírási formával, amely részleteiben tárolja az élő szervezet felépítését és működését. Ennek mintájára megpróbálunk megkonstruálni egy olyan leírást, amely cég összes fontos adatát egy egységben és kellően részletesen tartalmazza. Miután ez a leírás részleteiben is tartalmazza a cég folyamatait, ezért elemezhető formában fogja tartalmazni a tevékenységek költségeit is.

 

 

A modell első eleme a szervezet humán nézete

 

Minden cég felépítésének alapvető eleme a szervezeti egységekből álló szervezeti felépítés. A cég leírásához kiterjesztett szervezeti egységet használunk amely magába foglalja a munkatársakat is, azaz a kiterjesztett leírásban maga a szervezeti egység, a szervezet vezetője és a munkatársak is megjelennek. Ez a felépítés lehetővé teszi, hogy a szervezethez fel nem osztott költségeket rendeljünk, de azt is hogy pl. külön figyelhessük a vezetők költségeit és szükség esetén akár munkatárs szinten figyeljük a költségeket, ami például a területi képviselők esetében gyakorlatilag mindig alapkövetelmény. Elvárásnak tekintjük azt is, hogy meg lehessen indulni egy nagyvonalú, szintetizáló felosztásból és úgy tudjunk egy-egy részterületet nagy mélységben utólag feldolgozni, hogy nem nehezítjük más területek munkáját.

 

A cégleíró objektumnak az első adatcsoportja így a szervezet leírása lesz, amire itt látható egy példa:

10. ábra. A műszaki osztály szervezeti felépítése.

 

A kódok ismeretére nincs szükség, a szervezet minden szinten a natív nevével azonosítható. Ennek segítségével fel nem osztott költséget könyvelhetünk pl. a Műszaki osztályra, de személyi költséget könyvelhetünk Noszty Ferencre is és általa üzemeltetett járműre.  A kiterjesztett szervezeti egységet a natív megnevezése segítségével a kontírozáskor adjuk meg a főkönyv számára.

A szervezeti egységet egy strukturált kódrendszer írja le.

 

A szervezeti egységek leírására a rendelkezésre álló szabványok egyikét használjuk. Szervezeti leírás több nézetben is készíthető, használhatjuk pl. a szervezet kódját, a munkatársak nevét esetleg az erőforrások nevét.

A demóadatokhoz tartozó szervezeti felépítés egy részlete:

 

 

A szervezet felmérése és leírása

 

Az ERP rendszerek szervezeti felépítése egy jó kiindulási pont, de mindig kiegészítésre szorul. Ezt követően fel kell mérni a cég valóságos szervezeti felépítését ill. ha van érvényben lévő szervezeti diagram, akkor ellenőrizni kell, hogy megfelel-e a valóságnak. A másik alapdokumentum az "állománytábla", amely a kommunikációs adatokat is tartalmazza, így a kapcsolattartás elektronikus szinten folyhat. A kapcsolatot mindig az elektronikusan elérhető legalsó szinten igyekszünk tartani.

A szervezeti felépítést olyan szabványos formátumban tároljuk, amely alkalmas a közvetlen grafikus megjelenítésre is.

 

 

Topológiai leírás

 

A cégleírás másik meghatározó dimenziója a topológiai leírás. A topológiai leírás a cég fizikai kiterjedését rögzíti gyakorlatilag tetszőlegesen mély bontásban. A tipikus topológia elemek a telephely / épület / emelet / helység /eszköz. Az eszköz tipikuson gyártógépek, irodai gépek és egyéb rögzített elhelyezésű eszközök lehetnek, amelyek alapértelmezésből kiadják az "állóeszköz" leltár tételeit és elhelyezkedésüket.

11. ábra Topológia struktúra

 

A fenti topológiai struktúra azt mutatja, hogy a Budapesti telephely "A" épületének az első emeleti csarnokában van egy Morbidelli megmunkáló központ, és van 2 munkaállomás.  Ha ezekhez az eszközökhöz anyagot, alkatrészt vagy szolgáltatást veszünk igénybe, akkor a kontírozásnál mindössze annyit kell írni a költséghely mezőbe, hogy pl. UIwks23. Ekkor a rendszer tudni fogja, hogy Budapesten, az "A" épületben az első emeleten a csarnokban és ezen a gépen keletkezett költség, ami az üzleti intelligencia rendszerben meg fog jelenni akkor is ha az egész cég költségét vizsgáljuk és akkor is ha csak az "A" épületét és így tovább.  

Minden cég rendelkezik olyan eszközökkel is, amelyek nincsenek topológiai ponthoz rögzítve. Ezek az eszközök nem tartoznak topológiai ponthoz csak a szervezet egészéhez, amit a "Nem rezidens" névvel jelölhetünk.

 

A szervezet és a topológia összekapcsolódik, ugyanis minden munkatársnak fizikailag is van helye a cégnél és minden személyi és fel nem osztott költség egyidejűleg tartozik egy szervezeti egységhez és egy topológiai ponthoz is. Van lehetőség arra is, hogy egy topológiai pont ne személyhez tartozzon, hanem gyűjtő szervezeti egységhez, de akkor nem fog teljesülni, hogy minden költséghez tartozzon egy költséggazda, egy munkatárs, akit el tudok számoltatni..

 

Demó cégünknél, a "Jövő építő műveknél" a Csarnokban egy megmunkáló központ, a megmunkáló központ kezelője és egy tervezőmérnök található. Ők a termeléshez tartoznak. A csarnokot a ClearPadló nevű cég takarítja potom 370 eFt-ért. És mindez 2012 március havában történt.

A cég leírója tehát az alábbi részletet fogja tartalmazni:

12. ábra. A cégleíró első két szegmense

 

A fenti ábrán a topológiára szűrve Budapest "A" épületének első emeletén található csarnokban lévő munkahely elemeket írtuk ki. A kimutatáson csak azok az elemek jelennek meg, amelyhez márciusban költségek is tartoztak.

A topológiai leírást célszerű kiegészíteni a topológia adataival is. Ilyen tipikus adat egy egy helységek alapterülete, légköbmétere vagy energiafogyasztása. Ezeket a költségfelosztásnál lehet használni, ilyen pl. a takarítási költség az alapterülettel arányos, a fűtés a légköbméterrel, energiafogyasztás esetén a helységben található elektromos eszközök és azok átlagos terhelése a mérvadó.

Persze a helyes alapelv az mégiscsak az, hogy ami mérhető azt mérni kell.

 

 

A topológia felmérése és leírása

 

Az ERP rendszerek ezeket az adatokat nem tartalmazzák. Ha bizonyos tevékenységeket kezelni szeretnénk (takarítás, fűtésköltség, stb.), akkor mindenképpen szükség van a helységek adataira és ekkor már célszerű ezeket az adatokat topológia formában kezelni, de a topológia leírásban kezeljük a gyártó,- és egyéb eszközöket is. Persze az induláshoz elegendő lehet egy egyszerű eszközfelsorolás is, de strukturált adatfelvétel mindenképpen célszerű. A felmérés jó kiindulópontja egy digitális alaprajz lenne, azonban ez ritka mint a fehérholló.

A felmérés legegyszerűbben egy ügyesen megszerkesztett kérdőívvel történik. A kérdőív kiértékelése azért problémás mert gyakran nincs a cégeknél egységes névhasználat, az eszközöknek nincs azonosítója, a helységeken nincs név tábla ill. az ajtókon nincs ajtószám.  Ami azért érthetetlen, mert kifejezetten megnehezíti az új belépők beilleszkedését.

A demóiskolánk topológiája a következő:

 

 

A munkahely

 

Ez a leírás kezeli a munkahelyeket. Egy munkahelyet munkatársak, eszközök és külső szolgáltatások csoportjával azonosítunk. A munkahelynek a munkatárs elengedhetetlen eleme, de a munkahely tartalmazhat fizikailag távol eső objektumokat is. Létre lehet hozni csoportos munkahelyeket, pl. szalagokat, brigádokat, stb. Erre akkor van szükség, ha ugyanazt a tevékenységet többen is végzik. A munkahely fogalmának a felmérésben, az adatgyűjtésben és a költségek elemzésében is alapvető fontossága van.

 

 

 

A szervezeti leírás bővítése

 

A fenti leírással kellő pontossággal leírható a cég, de még nem tartalmazza a környezettel való kapcsolatot. A cégen belül számos tevékenységet nem a cég munkatársai, hanem külsősök végeznek. A cég leírását ezért ki kell terjeszteni a külső partnerekre is.

Az alábbi példában a BérAdmin Kft. a bérszámfejtési rendszer rendszerkövetője, a KönyvAdmin Kft.-k a pedig az ERP rendszeré. Ez így fog megjelenni:

13. ábra. A külsősök megjelenése a kiterjesztett szervezeti leírásban

 

Ezekre a kiterjesztett szervezeti elemekre könyvelni is lehet, ami természetesen meg fog jelenni a felette lévő szinteken.

 

 

Erőforrásköltségek könyvelése

 

Ebben a modellben erőforrásnak tekintünk mindent, amire könyvelni lehet. A munkahely minden eleme egy erőforrásnak tekinthető. Ha sikerült bevezetni az erőforrás könyvelést akkor minden költségelemhez a kontírozás során rögzítésre kerül az erőforrás natív neve is (pl. Noszty Ferenc, GYX-001, KönyvAdmin Kft., amely egy legördülő menüből választható ki). A költségelemzés alapja, hogy pontosan ismerjük a költségek keletkezését, ezért a multi dimenziós kódolás bevezetése hatalmas ugrás az elemzés felé vezető úton, bár nélkülözhető.

A költséghelyre történő kontírozás minden rendszerben adott, eltérés csak abban van, hogy ezt  a rendszer mennyire kulturáltan csinálja.

 

Az erőforrásokat szervezeti egységek szerint rendeztük el, ami azt is jelenti, hogy az alkalmazott modellben egy erőforrás csak egy szervezeti egységhez tartozhat.

7. ábra. Egy erőforrás nem tartozhat több szervezethez.

 

Ennek van egy gyakorlati következménye is. A KKV szektorban sokszor előfordul, hogy egy munkatársunk több munkakört lát el. Ekkor ezt a munkatársat mindkét helyen fel kell venni a szervezeti felépítésben mégpedig megkülönböztető névvel.  Ez azonban elkerülhető a kiegészítő tevékenységet valóban tevékenységként kezeljük és nem rendeljük hozzá egy önálló erőforráshoz.

 

Az erőforrásneveket a felmérés feldolgozása automatikusan állítja elő. Az erőforrás jegyzék munkatársakat, szervezeti egységeket, külső vállalkozókat, épületeket és eszközöket egyaránt tartalmazhat.

 

15 ábra. A demórendszerben használt erőforrásnevek

 

A kontírozás során a dimenzió vagy a költséghely mezőben az erőforráslistából kell kiválasztani a megfelelő éréket, ezért sokat segítenek a jól megadott, egyértelmű, "beszélő" nevek. Miután a legtöbb cégnél használnak költséghely dimenziót ez semmi újdonságot vagy többletmunkát nem jelent a könyvelés számára.

 

A dolog érdekessége, hogy ha a költséghely kódrendszer szerencsésen volt összeállítva, akkor kézbevétel nélkül lehet áttérni a multidimenziós cégleíró használatára.

 

 

Az erőforrásadatok betöltése

 

A költségek a könyvelésből és a bérszámfejtési rendszerből érkeznek. Az adatok újra rögzítése szóba sem jöhet, ezért kulcsfontosságú, hogy a lehető legkevesebb munkával tudjuk átvenni őket. Ha a vállalatirányítási adatbázist MS-SQL esetleg Oracle adatbázis kezelő tartalmazza, akkor az adatok beavatkozás nélkül beolvashatók. Egyéb rendszerek esetén Excel vagy ACCESS feladásra van szükség és azokat a teljesítmény adatokat, amelyek nem az ERP rendszerből érkezik szintén Excel vagy ACCESS adatbázisban fogadjuk.

 

 

Az erőforrásköltségek és az erőforrások összerendelése

 

A betöltés folyamata:

16. ábra. Az erőforrásadatok betöltése

 

Az adatok származhatnak közvetlenül a vállalatirányítási rendszerből (ERP-ből) ill. bérszámfejtésből. A vállalatirányítási rendszer ill. a feladások adatait egy szabványos (interface) felületre olvassuk be. Az interface felületen lévő költségadatokat egy BetöltőDriver teszi át az erőforrásokra. A BetöltőDriver egy eljárásból és egy adatbázisból áll, működése során rendezi vagy szét is bontja a főkönyvi ill. bérszámfejtési költségeket erőforrásköltségekre.

A rendszer tartalmaz standard betöltési megoldásokat is, de a bevezetés feltehetőleg mindig igényelni fog újabb, a céghez pontosan illeszkedő driverek megírását, ami egyébként alapfolyamat.

 

A bérszámfejtési állományra azért van szükség mert még nem láttam olyan főkönyvi rendszer, amely a béreket analitikusan tartaná nyilván. Ennek ellenére tipikus megoldás az is, hogy a béradatok a főkönyvi bérszámlák felosztásával kerül feldolgozásra, ez elegendő pontosságot biztosít az önköltségszámításhoz, de nem elég pontos a költséggazdálkodáshoz.

 

Kevésbé szerencsés esetben a költségek a forrásban (főkönyv, bérszámfejtés) nem abban a struktúrában vannak tárolva mint az erőforrásaink. Ez fordul elő pl. akkor ha az erőforrásunk valójában egy erőforráscsoport, pl. ha egy gyárban van egy szalag, amely mellett mindenki ugyanazt a tevékenységet végzi. Ilyenkor semmi szükség a munkatársak egyenkénti kezelésére. A másik zavar az lehet, hogy egy főkönyvi számon sok erőforrás költsége össze van vonva. Ilyenkor szét kell bontani a költséget erőforrások szerint. Mindez egy külön illesztő réteget igényel az erőforrás és az adatforrás közé.

17. ábra. Erőforrásköltség elő feldolgozása

 

Az ábrán található telefonközpont adatbázis pl. arra használható, hogy a kimenő hívások alapján osszuk fel a telefonköltséget. A feladások átvételére ill. a külső adatok átvételére ugyanaz a betöltő driver használható mint az interfész adatok erőforrásokra történő könyvelésénél.

 

 

Az erőforrásköltségek feltöltése

 

A betöltő driver egy egyszerű utasítás sorozat, amely azt mondja meg, hogy melyik főkönyvi számon található költséget melyik erőforráshoz kell rendelni. Ha használjuk a multidimenziós kódokat és az erőforrás könyvelést, akkor a driver nagyon egyszerű.  A drivert egy egyszerű Excel táblában célszerű megtervezni.

 

A példában szereplő első két driver-tag a szabványos interfész felületről betölti az erőforrásokba az összes olyan költséget, amely erőforrásra volt kikontírozva. Ezek standard driverek. Ha az ERP és/vagy a bér rendszer ugyanazon a gépen  van ill. hálózatról elérhető, akkor a globális betöltő drivereket megelőzi két interface driver, ami az ERP/bérszámfejtési rendszerből veszi tölti át az adatokat a szabványos interface felületre. Ezek ERP függő driverek amit a nevében is jelzünk, pl.: Axapta-SQL-ERP, Babér-SQL-BÉR.

A következő driverrel egy erőforrás költségét 20-80 arányban megosztjuk két másik erőforrás között, mert Bellováry Noémi két munkakört lát el és ezt nem tevékenységszinten szeretnénk kezelni.

A Std-Takarítás, Std-Fűtőmű és a Std-Villanyszámal a globális driverekre példa. Ezek a felosztási paramétereket a topológiai adatokból veszi. A Std-Takarítás pl. a takarítási költségeket az alapterület alapján osztja fel. A költséget a ClearPadló nevű erőforrásból veszi (ami egy külső vállalkozás), az alapterületeket pedig a topológiából. A következő driver csoport négy munkatársból állít össze egy erőforrás csoportot. Ilyenkor az első munkatárs a költséggazda.

Az hogy milyen drivereket használunk a modelltől függ, a takarítás, stb. költségek felosztása pl. történhet a tevékenység driver szintjén is.

 

Ezen a ponton akár meg is lehet állni, mert itt már minden költség minden szempont szerint elemezhető, de csak főkönyvi/bérszámfejtési és erőforrásszinten.

Megkérdezhetjük például, mennyibe került 2012.1. negyedévében nekünk a gazdasági igazgatás munkahelyei:

 

18. ábra Lekérdezési példa

 

De át is rendezhetjük a költség típusa szerint:

19. ábra. Szűkítés a külsős cégek kihagyásához

 

Tehát már ezen a ponton is nagy az előrelépés a költséggazdálkodásban.

 

 

Költségnem

 

A cégleírója tetszőleges pontossággal leírja a cég felépítését és kijelöli azokat a pontokat, ahol költségek keletkeznek. A költségek típusára eddig annyit mondtunk, hogy lehet személyi költség, anyag / eszköz költség vagy külső szolgáltatás költsége. Valójában ennél sokkal nagyobb lehetőségünk van, mert létrehozhatunk egy egész költségstruktúrát is. Ez lehet akár a hagyományos számlatükör is, de tervezhetünk egészen egyedi struktúrát is. A legjobb megoldás mindenképpen az, hogy a számlatükörre képezzük le az gazdálkodás  és elemzés orientált struktúránkat. Valójában így keletkezett a már említett hármas besorolás is. De pl. így gyűjthetjük össze az összes adó jellegű kötelezettséget pl. egy "Sarc" nevű egységbe is vagy emelhetünk ki kulcsfontosságú költségnemeket (pl. üzemanyagköltség). Ez a megoldás arra ad lehetőséget, hogy úgy vezessünk be önálló, a cég üzleti tevékenységhez pontosan illeszkedő költség kategóriákat, hogy ne tartozzon hozzá adatbeviteli feladat. A megoldás további előnye, hogy a könyvelők is a megszokott fogalmaikat használhatják. A számlatükör kezelése alapszolgáltatás - azaz a főkönyvi számlaszámok alapján is vizsgálhatjuk a gazdasági eseményeket. Ehhez tartozik egy újabb betöltő driver, amely az ERP rendszerből átveszi, ellenőrzi és szabványosítja a számlatükröt (pl.: a WD-számlatükör nevű driver a Windirect rendszer számlatükrét szabja a standardhoz).

 

Az elszámolási időszak

 

A költségek esetén azt is meg kell adnunk, hogy a költség mikor keletkezett. Természetesen ez az adat is rögzítési többlet nélkül, a főkönyvből kerül betöltésre.

Azt mindenképpen észre kell venni, hogy a szervezeti és a topológiai struktúrának nincs időfüggvénye, azaz ezek időbeni változását nem tartjuk nyilván, de a driverek tartalmazhatunk egy skope intervallumot, ami arra használható, hogy a driverek változtatása ne zavarja meg a korábban definiált drivereket.

Elszámolási időszakot nem kell megadni, mert a költségek tartalmazzák a teljesítési időt a BI rendszer pedig rendelkezik egy idő dimenzióval, amely tetszőleges időpontok vagy tartományok beállítására képes.

 

 

Tevékenységek

 

A kiterjesztett szervezeti pontokhoz (a munkahelyekhez) tevékenységek rendelhetőek. Egy szervezeti ponton több tevékenység is végezhető. A tevékenység strukturált, leírása tetszőlegesen pontos lehet. Ha pl. nem akarjuk részleteiben vizsgálni a könyvelést, akkor egyszerűen csak azt a tevékenységet vesszük fel, hogy "Könyvelési tevékenység". Ha valamilyen oknál fogva ennél pontosabban akarjuk látni a folyamatait és költségeit, akkor tovább bontjuk pl. számlakönyvelésre, bankkönyvelésre, bérszámfejtésre, pénztárra, stb. Sőt ezeket is bonthatjuk tovább pl. kimenő- és bemenő számla könyvelésre, ami tovább bontható elemei műveletekre. Már indulásnál készíthetünk teljes mélységű leírást, de azt is megtehetjük, hogy utólag fokozatosan pontosítjuk a tevékenységet.

20. ábra. Tevékenységek

 

A fenti ábrán a "Front kialakítás" nevű gyártási tevékenység jól mutatja a tevékenység fajtákat. A tervezés, a megmunkáló központ programozása és a null széria lefuttatása olyan tevékenység, amelyet minden termék ill. termékvariáns esetén egyszer kell elvégezni, tehát ezt a költséget magához a termékhez kell hozzárendelni. Ez a tevékenység és költsége akkor jelenik meg, amikor új termék keletkezik ill. meglévő terméken végzünk ráncfelvarrást. A gyártás előkészítés egy sorozathoz van hozzárendelve értéke független a sorozat nagyságától (Batch level). Ha azonban a termelés elindításához anyagmozgatás is tartozik (pl. az előtte lévő művelet messze van és onnan ide kell mozgatni az anyagot, akkor egy anyagmozgatás is bekerül ebbe a láncba aminek értéke már az előállított termék egyedek számával arányos. Maga a gyártás és kész munkadarab elszállítása a következő művelethez szintén egyedszám függő (Unit level).

Bár kétségtelen, hogy ezek a felosztások a tevékenységhez tartoznak, az ezekhez szükséges időszakonként változó adatokat feldolgozása ritkán úszható meg adatrögzítés nélkül. Adatrögzítésre pl. olyankor nem kerül sor, amikor egy pontos elemzésre van szükség és az intelligens megmunkáló központ elektronikus formában nyilvántartja működés összes fontos adatát.

 

 

Tevékenységek felmérése és leírása

 

A tevékenységeket munkahelyenként célszerű összegyűjteni, erre a célra egy kérdőívet használunk. Egy tájékoztató megbeszélés során elmondjuk a felmérés szempontjait, majd összegyűjtjük a kérdőíveket, rögzítjük a tevékenységeket és beolvassuk a rendszerbe. Az ismert belső szoláltatások esetén (pl. informatika) több száz tételből álló teljes tevékenység jegyéket biztosítunk és azt kérjük, hogy egy hosszabb ideig írják be, hogy mely tevékenységre hány órát fordítottak. A hiányzó tevékenységet persze a munkatársnak kell beírnia. Ez az eljárás meglehetősen hasznos, mert nem csak arról keletkezik képünk, hogy egy adott munkahelyen milyen tevékenység folyik, hanem arról is, hogy mi a tevékenységek aránya. Igencsak hasznos az az információ is, hogy mely alaptevékenységet nem végzik el az adott munkahelyen.

Ezen a ponton jelenik meg az intelligens eszközök előnye. Az hogy pl. hány számlát rögzített a könyvelő az értelemszerűen mindig kiolvasható az ERP rendszerből, de pl. annak közlése, hogy egy adott gép hány órát működött, azt milyen fordulatszámon tette, az már csak a jó minőségű eszközök erénye.

 

 

A munkakör

 

Amikor a munkahelyhez hozzárendeljük az ott folyó tevékenységet, akkor a munkakörhöz közelálló objektumot kapunk. A munkakör egységes leírása tartalmazza a munkakör azonosítóját a Munkahelyet és a munkahelyen folyó tevékenységeket:

 

21. ábra. A munkakör leírója

A fenti modellben az erőforrás (ami jelen esetben maga Kőcserepy Vilma) költségeit egyenletesen osztottuk fel a tevékenységek között. Ez így egy rossz modell, ugyanis könnyen elérhető az az információ is, hogy hány kimenő és bemenő számla került feldolgozásra, és ezek aránya egy sokkal jobb felosztást eredményez.

 

Ezzel ismét egy nagy egység végére érkeztünk.

Leírtuk a teljes humán szervezetet, ezt kiegészítettük a cég épületeinek és eszközeinek területi elhelyezkedésének adataival. Ezzel leírtuk, hogy a cégen belül milyen munkahelyek vannak, beleértve a munkahelyhez tartozó munkatársakat, a felügyeletük alatt lévő eszközöket és külső vállalkozókat. Kezeltük továbbá az erőforrások költségtömegét, a költségek típusát és a keletkezésük idejét is.

Végezetül kiegészítettük a munkahelyen folyó tevékenység leírásával, azaz meghatároztuk a munkaköröket.

 

 

Az erőforrások költségeinek felosztása tevékenységek között

 

A felosztás abból áll, hogy az erőforrásokon található költséget ráírjuk az erőforráshoz tartozó tevékenységekre. Azt a leírást, amely ennek a részleteit tartalmazza erőforrás drivernek vagy költség-okozónak nevezzük.

Ahhoz, hogy a felosztás elvégezhető legyen a drivernek meg kell mondania, hogy a költséget

  • melyik erőforrásról,

  • melyik tevékenységre,

  • milyen eljárással,

  • milyen értékek alapján kell felosztani.

A drivernek tehát van egy fix leíró része és van/lehet egy elszámoló időszaktól függő konkrét értéke. Az első rész azt mondja meg, hogy mivel mit kell csinálni, a második azt, hogy milyen értékkel kell operálni. A driver tehát "erőforrás - tevékenység" párosok halmazát jelenti.

 

Hasonlóan a betöltéshez - ezt a felosztást is driverek végzik el. Itt is megszerkeszthetőek a hagyományos driverek, azaz melyik erőforrást, melyik tevékenységre, milyen eljárással lehet felosztani és itt is használhatóak globális driverek, amelyek egy lépésben sok felosztást tudnak kezelni. A globális driverek elsősorban a munkahelyekhez kapcsolódnak. ilyen pl. a "FelosztásTevékenységre" nevű globális eljárás:

 

22. ábra. Egy globális erőforrás driver

 

A fenti driver részlet pl. az alábbiakat végzi el. Az első két sor le van tiltva, a következő sor a Kőcserepy Vilma nevű erőforráson lévő költségeket a teljesítménytábla alapján osztja fel a táblában megadott tevékenységek között a tevékenységre fordított órák szerint. A tábla tartalmazza az összes tevékenységet ami az adott munkahelyen (számlakönyvelés) végezni lehet, Vilma pedig minden nap bejegyezte, hogy melyik tevékenységre hány órát fordított. Egy hosszabb - rövidebb idő múlva ezt abba lehet hagyni és a kialakult arányokat alapul lehet venni ehhez a munkahelyhez.

A többi driver tétel az erőforráson lévő költséget a munkahelyhez tartozó főtevékenységekhez egyenletesen rendeli hozzá.

 

Azt lehet mondani, hogy ha a szokásosnál nagyobb pontosságot szeretnénk elérni, akkor nagyon testreszabott felosztási algoritmusokat kell készíteni, aminek elvi kizáró oka nincs, de idő és költségigényes. Törekedni kell arra, hogy a felosztás csak olyan adattal történjék, amely az ERP rendszerből kiolvasható, ami sokszor nem teljesíthető, de törekedni azért lehet rá.

A driverhez célszerű tájékoztató elemeket is hozzárendelni, amely pontosan leírja a driver célját és hogy a paraméterek mit tartalmaznak és mi az természetes egységük.

 

 

Összefoglalás

 

A költségek felosztása a tevékenységek között önállóan is használható eljárást jelent, melynek eredményekképpen le tudjuk írni a céget és meg tudjuk állapítani, hogy mely tevékenység milyen költséget jelent.

A megoldás két részből állt: van egy fix leíró adathalmazunk, amellyel megadtuk a költségtárolókat (pl. főkönyvi számokat), leírtuk a munkahelyeket, ahol munkatársak, külső szolgáltatók és épületek ill. eszközök találhatóak, leírtuk hogy melyik  munkahelyen milyen tevékenység folyik. Rögzített adat továbbá az, hogy melyik erőforrás költségét melyik tevékenységre kell könyvelni.

Automatikus folyamat a forrásadatbázisban található költségek betöltése (esetleg csoportosítása vagy felosztása) az erőforrásokba, a felosztáshoz szükséges teljesítményadat adat betöltése az erőforrás driverbe végezetül maga a költségek felosztása.

 

23. ábra. Költségek felosztása a tevékenységek között

 

A cég és a költségek leírásánál egy olyan strukturált kódrendszert használtunk, amely egységesen kezeli a szervezetet, a topológiát és az erőforrásokat, a tevékenységeket, a költségnemeket és a költségek keletkezésének időpontját.

23/a. ábra. A cégleíró DNS felépítése

 

Mindezek eredményeképpen tudni fogjuk, hogy mely tevékenység mennyibe kerül és rendelkezésre áll egy olyan rendszer, amely a költségeket gyakorlatilag minden értelmezhető szempontból képes vizsgálni.

Lehetőség van néhány hasznos továbbfejlesztésre. A szabványos inteface felületet ki lehet egészíteni a Std-Számlatükör és a Std-Számla egységekkel. Egy driverrel betölthető a szálatükör és a ki és bemenőszámlák is. Ekkor az elemzés kiegészül azzal, hogy egy költség vizsgálatakor magát a számlaadatokat is megnézhetjük.

Ez a leírás költség oldalán jeleni meg:

23/b. ábra. Főkönyvi szám és a számlák elemzésével bővített szolgáltatás.

 

Ez azért nem része az alap modellnek, mert nem minden ERP rendszer használható erre.

 

 

Költségviselők

 

A Költségviselők kiterjesztett értelmezésébe minden beletartozhat aminek a költségére kíváncsiak vagyunk, de azért van néhány tipikus eleme, pl. termékek, szolgáltatások, termék és a cég megtartására irányuló (vonal alatti) költségek, csatorna költségek. Ha lehet számolni, akkor ide lehet még venni a veszteségeket és a felosztatlan költségeket .

24. ábra. A költségviselők első szintje

 

A klasszikus ABC modellt első lépésben három új elemmel egészítjük ki:

 

5. ábra. A továbbfejlesztett ABC módszer lényege

 

Ha a cél a költségek csökkentése, akkor az első szempont mindig a veszteségek csökkentése. Ehhez értelemszerűen legalább azt kellene tudni, hogy hol keletkezik veszteség. Ennek meghatározása meglehetősen bonyolult, ezért az alapmódszer ezt nem is biztosítja. Ugyancsak új elemként hozzuk be a fel nem osztott költségek költségviselőjét. A költségek csökkentését a veszteségek elemzése után itt kell folytatni, mert ha semmi ok-okozati összefüggést nem fedezünk fel a költség és a termelés között akkor azt bizony érdemes részletesebben megvizsgálni. Némi iróniával ide sorolható az összes adó is, mert ma az égvilágon semmi összefüggés nincs az adó és a gazdasági tevékenység között.

 

A költségviselők is lehetnek strukturáltak, ami lehetővé teszi az áttekintő és a részletes elemzést. Az alábbiakban egy öt egység mély struktúrát látunk, amely a tagok előtti + jelre kattintva nyílott fokozatosan ki.

25. ábra. Költségviselők ötödik szintje

 

Költségviselőnek azonban bármit felvehetek, aminek kíváncsi vagyok a költségére.

26. ábra. Költségviselők kiterjesztés

 

A fenti ábrán a könyvelés összevont szolgáltatásait tekintjük költségviselőnek és arra vagyunk kíváncsiak, hogy ezek mennyibe kerülnek a cégnek.

 

 

A tevékenységköltségek felosztása költségviselőre

 

A felosztást végző drivert "Tevékenység drivernek" nevezzük és logikailag pontosan úgy működik, ahogyan az erőforrás driver csak a forrása egy tevékenység és célobjektuma egy költségobjektum. A nehézséget az okozza, hogy a költségobjektumok nagy száma esetén a driver tagok száma is nagyon nagy lehet. Itt is a fentiekben leírt megállapítás az érvényes, vagy kevéssé strukturáljuk a költségobjektumokat vagy minden adatot el kell érnünk az ERP rendszerből.

 

 

27. ábra A tevékenységköltségek felosztása költségviselőkre

 

Első lépésben tehát a tevékenységeket szűk szakmai szempontok alapján osztjuk fel a költségviselők között. Ekkor a tevékenységek nem tartalmazzák azokat a költségeket, amelyek nem közvetlenül a tevékenységekhez hanem a tevékenység gyakorlásához kell.

 

 

A tevékenységdriver felépítése

 

A tevékenységdriver felépítése és működése megegyezik a betöltő és az erőforrás driverek felépítésével. Ugyanúgy rendelkezésre áll az összes alapdriver, de itt is elsősorban a globális driverek használatára kell törekedni.

 

A Csoport(+) eljárás a megadott tevékenység és alatta lévő tevékenységek költségeit könyveli a megadott költségviselőre. A hárma tevékenység a égvezetés. Ezt minden költségviselőre egyenletesen könyveljük el.

 

 

Összefoglalás

 

Ezen a ponton a cég leírása a következő struktúrában történik:

 

Ez a struktúra a cég összes információját hordozza, ezért a költségek nagyon sokrétűen elemezhetőek.

 

 

Önköltségszámítás

 

Az előző lépésben keletkezik a költségviselőkre könyvelt költségtömeg. A költségtömeg és a legyártott darabszám hányadosa az egy termékre jutó önköltség. A számítás pontossága szempontjából kívánatos, hogy a mennyiség és a költség összetartozzon. Ez tökéletesen biztosított, ha az ERP rendszer a HPCII rendszer követelményét kielégíti, de általában kellő pontossággal számítható a termelési dokumentáció (esetleg a készárú raktár bevételi jegyei) alapján is. Végszükség esetén a kimenőszámlák mennyiségi adatait használjuk.

 

Az üzleti intelligencián alapuló megoldás lehetővé teszi, hogy elemezzük az önköltség mennyiség szerinti alakulását. Ez látható az alábbi ábrán:

 

 

Az X-tengely a legyártott mennyiséget az Y-tengely az önköltséget tartalmazza. Látható, hogy ebben a mintában az önköltség folyamatosan csökken a mennyiség növekedése esetén, de az is nyilvánvaló, hogy a közepes tartományban valami súlyos hiba van.

Ezt tehát tovább kell vizsgálni, ezért megnézzük a az önköltség és a mennyiség havi alakulását:

 

 

Látszik, hogy a hiba az első három hónapban, és azon belül a költségtömegben keresendő.

 

 

Valóban, a költségtömeg első három havi értéke hibás. Ennek több oka is lehet. Első lépésben azt kell megvizsgálni, hogy nem követtünk-e el hibát amikor a főkönyvi számokról az erőforrásokra könyveltünk. Ez azért oldható meg egyszerűen, mert egy mozdulattal kikérhetjük a költségviselőhöz tartozó erőforrásokat. Ha ez rendben van akkor megnézzük a tevékenységeket, ha ez is rendben van, akkor elkönyvelésről van szó. Jelen esetben az első három hónapban egy elkönyvelés volt. Azért nagyon fontos, hogy a gazdaságelemzésnél nem támaszkodunk az 5-ös, 6-os, 7-es, és 8-as számalosztályokra, mert így a kontírozási hibák könnyen javíthatóak és nem igényeljük a könyvelés javítását.

 

Az önköltség időbeli szórása egy nagyon fontos teljesítménymutató.

 

Ha csak kevés termék vagy szolgáltatás van, akkor a driverek segítségével a tevékenységek költségét közvetlenül a termékre lehet könyvelni így a legyártott darabszám ismeretében meg lehet adni a termék önköltségét. Ekkor egy termék egy költségviselő.

Ha több száz vagy több ezer termék van, akkor ez a módszer nem használható, valamilyen közelítő eljárásra van szükség. Ilyen lehet például a vezértermék vagy az előkalkulált önköltség használata termék driverként.

Ez így nézhet ki:

28. ábra. Termék driver

 

Ekkor a költségviselőnek egy vezérterméket ill. termékcsoportot tekintünk. Sok estben ekkor is eljuthatunk az egyes termékek önköltségéhez. Ha rendelkezésünkre áll az, hogy a vezértermék (termékcsoport) milyen termékekhez tartozik, ismert a vezértermék előkalkulált költsége valamint minden terméknek ismerjük az előkalkulált költségét és mindez kiolvasható az ERP rendszerből, akkor kármennyi terméknek számolható az önköltsége.

 

A termékdriverek

 

A termékdriverek megfelelnek az egységes felépítésnek. Tartalmaznak felosztási tagokat, de megjelenik egy új tag is, amely a költségtömeget osztja el a termékek darabszámával.

 

 

Ezeket a drivereket általában Excel táblákban célszerű összeállítani. A táblák kitöltésénél a kódok nevét lehet használni.  Bár egy kontroller mindig tud a kódokkal is dolgozni, ennek ellenére igen fontos, hogy a táblák tartalmazzanak egy érthető leírást is.

 

 

Termék és vevőmegtartás költségobjektum

 

Hasonló probléma merül fel a többi költségobjektum esetében is. A marketing és PR költségek esetén a fejlettebb cégeknél általában van arra mód, hogy egy-egy vevőcsoport marketingjét elkülönítve lehessen vizsgálni. Azonban annak vizsgálatához, hogy egy konkrét vevőre mennyit költöttük ahhoz az szükséges, hogy rendelkezésre álljon minden kampány esetén, hogy az kiket érintett.  A marketing és PR tevékenység általában kampányban történik, a kampány tevékenységeket tartalmaz, a költségobjektum maga a kampány, amely tovább osztható pl. az alábbiak szerint kialakított vevőcsoportok szerint.

Pl.:

 

29. ábra. Vonal alatti projektek célterülete

 

A kampányoknak fajtánként eltérő célja van. Van olyan amelyiknek az a feladata, hogy az ismeretlen potenciális vevők egy részéről alapadatokat szerezzünk. Aztán szervezhetünk olyan kampányt, amelyik célja CRM adatok gyűjtése. Ha van CRM adatunk, akkor már olyan kampány is indítható, amely eredményképpen a potenciális vevő ajánlatot kér. De az igazi érték a befolyásolók feltárása. Az érdeklődőből némi ráfordítással már aktív vevőt fabrikálhatunk. Azonban vevőket elveszteni is fogunk. Az elveszett vevők egy részét - a rossz vevőket - nem kell visszaszerezni, ez boldogítsa csak a konkurenciát. A másik részére viszont olyan kampányokat kell szervezni amellyel visszacsábíthatjuk őket.

Elemzéssel azt tudjuk megmutatni, hogy mekkora költségek árán sikerült a vevőszegmenseket alakítani, azaz mekkora költségből tudunk egy érdeklődőt, vevőt megszerezni. Azt is megtudjuk, hogy marketing eljárások hatékonyak-e, melyiket kell erősíteni és melyikeket abbahagyni.

Az elemzéshez arra van szükség, hogy a kampányokat mindig azonosítsuk és nevezzük meg. Ez a költséghely (erőforrás) mellett rendelkezésre álló projektazonosítóval történik. Ebben az adatmezőben tartjuk a hagyományos projektazonosítókat, a sarzs azonosítókat, a LOT számokat, stb. Az ilyen költségeknél a költséghelyre és a projektre egyszerre kell könyvelni. A tevékenységeket ugyanolyan eljárással lehet felosztani, mint bármelyik más belső szolgáltatást, itt is vehetünk fel pontos tevékenységarányokat, de a becslési eljárásokat is használhatjuk.

A vevőre bontott kimutatásokhoz CRM adatbázis kell, de ennek interfészét még nem készítettük el.

 

Nem okoz viszont gondot a klasszikus mutatók képzése (Vevők átfutási ideje, Szállítók átfutási ideje, Vevőállomány aránya a szállítóállományhoz, stb.)

 

 

Csatorna költségek

 

A csatornaköltségek leválasztása nem igényel semmilyen extra megoldást, a leválasztás a helyes kontírozás mellett automatikusan történik meg. A csatorna struktúrákat úgy kell kialakítani, hogy minden értékesítési megoldás elemezhető legyen és a struktúrának feltétlen le kell húzódni egészen az értékesítő munkatársakig, mert az önköltséget munkatárs szinten kell számolni.

A csatornaköltségek számolása általában összekapcsolódik az értékesítés elemzéssel. Az értékesítési adatkocka tartalmazza a Grossprofitot, amit sok rendszernél nekünk kell kiszámolni a költség kocka segítségével. Ez az anyag egy olyan valós esetet mutat be, ahol teljes összetettségében jelenik meg az értékesítés, a csatornaköltség és a kapacitásveszteség jelensége.

 

 

Veszteségek

 

A veszteségek becslése önálló témakör amihez az input adatokat bővíteni kell a technológiai adatokkal. A veszteségszámítás alapja az a gondolat, hogy mindazokat az anyagokat, amelyek a végtermékbe nem épülnek be, de költségként valamilyen formában megjelentek azokat válasszuk le a termék önköltségről. Ennek sok formája lehet (lopások, megsemmisülés, soron kívüli amortizáció, stb.) de van egy kiemelt jelentőségű módja is: a normától való eltérés számítása. Ekkor a norma alapján képzett felhasználást vetjük össze a tényleges felhasználással. A kapacitás veszteség számolására a korábban említett példa alkalmas.

 

 

Összefoglalás

 

A fent eljárással tetszőleges pontossággal írtuk le a munkahelyeket és a munkaköröket. Elszámolási időszakonként felosztottuk az erőforráson található költséget, amelyet a főkönyvből ill. egyéb nyilvántartásból töltöttünk be. A driverek segítségével leírtuk a cég idő szerinti teljesítményét és a teljesítmények arányában osztottuk fel a költségeket. Bizonyos költségek esetén nem végeztünk felosztást, hanem felosztatlanul egy tételben gyűjtöttük ki.

 

 

Az On-Line analízis ügyfél oldala

 

A tevékenység struktúra vizsgálatához kiválasztottuk a költségösszeget és a tevékenység struktúrát. Ekkor a struktúra felső szintje, a főtevékenységek költségtömege jelenik meg.

 

Ha egy tevékenységet részleteiben is meg szeretnénk jeleníteni, akkor lefúrunk a költségek részleteibe. A könyvelési tevékenység előtt található + jelre kattintva érjük el a következő bontást, majd ismét a + jelre kattintva jutunk még lejjebb. Gyakorlatilag a kedvünk szerinti mélységig bonthatjuk a költségeket, a rendszer megbirkózik a kezelésével.

 

 

A költségek alakulását az idő függvényében is vizsgálhatjuk. Most a szűrés mezőbe kiválasztjuk az 2012-es évet,  oszlopfejlécnek kijelöljük a hónapokat, a tevékenység marad a sorban. Az eredményt rögtön ki is rajzoljuk.

 

 

Az önköltség vizsgálata egy önálló Excel munkafüzetben történik, miután ez elkülönül a fenti on-line elemzéstől. Ezt úgy mondjuk, önálló "kocka". Az alább bemutatott példában fiktív számok vannak, de a valós helyzetekben sem ritka a meghökkentően magas költség. Ez úgy keletkezik, hogy pl. egy rosszul szervezett pénztárban igen magas lehet a kapacitás veszteség, mert a bért fizetjük, a költségek megjönnek, de a kiállított bizonylatok száma alacsony lehet. Ez szükségszerűen eredménye az egy bizonylatra eső magas költséget.

 

 

Ugyanezzel a technikával elérhető "dimenziók":

  • Tetszőleges időpont vagy időtartomány.

  • Szervezet adatai

  • Topológia adatai.

  • Erőforrások adatai.

  • Tevékenységek adatai.

  • Költségviselők adatai

  • Számlák adatai

  • Számlatükör adatai.

 

A rendszer nyitása

 

Az implementáció egy SQL szerveren futó ABM motorból és az erre épülő MS-SSAS rendszerből áll. Az ABM motor éjszakánként átveszi és tisztítja az adatokat, futtatja le a drivereket és ellenőrzi az eredményt. A feltárt hibák az "ALERT" kockában tekinthetőek meg. Maga az SQL scriptekből álló motor a felhasználó számára nem elérhető és ugyanez a helyzet a standard driverekkel. Azonban minden driver futtatása előtt és után meghív egy felhasználói scriptet, amely lehetőséget biztosít a saját fejlesztésű driverek használatára. A driverek megírásához szükséges interfészek leírása a rendszer részét képezik.

A felhasználó így tetszőlegesen átszabhatja a modelleket és elkészítheti a saját megoldását. A felhasználói drivereket tartalmazó processzeket a frissítések során sohasem módosítjuk.

A feldolgozás folyamata:


A rendszer nyitása
 

A standard tisztítást követően történik meg a felhasználói tisztító algoritmus meghívása, de csak abban az esetben ha a standard algoritmus betölthetőnek találta az adatokat. Ha az adatokat nem lehet betölteni (pl. sérült az adatbázis), akkor a betöltés leáll. Az adattisztítást követően a Standard betöltő driver a szabványos interfészbe tölti az adatokat, majd elvégzi a szükséges átalakításokat. A szabványos betöltő driver előtt és után meghívjuk a felhasználói betöltő drivereket. A felhasználói driverek használata/létezése nem kötelező. Ha a standard driverek közül semmit sem használunk akkor a teljes egészében a felhasználó kezében van a vezérlés.

A szabványosság és a nyitottság elve mindenhol érvényesül:

A felhasználói pre és post erőforrás és tevékenységdriverek használata

 

 

Mi hozza a költségek megtakarítását

 

Lehet, hogy furcsa, de az első jelentős megtakarítást a cégleíró felállítása hozza. Ennek a megszerkesztésénél nem csak az bukik ki, hogy melyik tevékenységeknek és melyik költségeknek nincs gondozója, hanem nyilvánvalóvá vállnak az alapvető szervezési hibák is. A munkahely szint felállítása könyvelési és erőforrás szinten is teljes körű költségelemzést tesz lehetővé. A munkakörök kialakítás után már az is elemezhető, hogy egy egy tevékenység mennyibe kerül.

Érdekes hatása lehet annak is, hogy az egyes osztályok szembesülnek azzal, hogy más osztályok milyen áron, milyen minőségű szolgáltatást nyújtanak. Megtudjuk továbbá, hogy mely vevő mennyi is ér nekünk, mennyit költöttünk rá és mekkora eredményt hozott. Nem utolsó sorban azt elemezhetjük hogy a belső szolgáltatások mennyibe kerülnek a cégnél.

A megtakarítást azonban csak az hozza ha a feltárt hibákat kijavítják és ha a hibás igényekre azt tudják mondani, hogy NEM. Az egész hókuszpókusz csak ennek megkönnyítésére való.

 

Ezt a szemléletet összességében nevezhetjük ABM-nek, ami az aktivitás alapú menedzsment.

 

 

Mi az elterjedés gátja

 

Bár ezek az elemzések ma még a milliós nagyságrendben vannak, a megtérülés olyan gyors és az árbevételhez képest ez olyan kis tétel, hogy az ár nem szabhat határt az elterjedésnek a KKV szektorban sem. A lassú terjedés okokai között talán az egyik legérdekesebb, hogy a KKV szektor cégeinek egy jelentős részében úgy vélik, hogy náluk már nincs lehetőség a költséget csökkentésére. Ezzel a szemlélettel nehéz mit kezdeni. A legnagyobb akadály azonban az, hogy valójában a teljes cég ellenérdekelt az ABM eljárás bevezetésében. A munkatársak egy része az elbocsátástól fél, másik része attól tart, hogy a magas költségeket az eddigi gyenge munkájukkal magyarázzák majd, aggódnak a teljesítménymutatók bevezetése és a folyamatos ellenőrzése okán és mindenki szeretné elkerülni, hogy ugyanannyi bért több munkáért kapjon. Ezek azonban csak megnehezítik a bevezetést, de annak nem akadályai.  Tipikusnak mondható, hogy a KKV szektorban nincs kontroller pozíció, de ennél sokkal rosszabb, ha van és a könyvelésnek van alárendelve. Ez biztos jele a hibás beidegződésnek.

A sikerhez az kell, hogy a felső vezetés meggyőződhessen arról, hogy a feladat megoldható, a költségek valóban csökkenthetőek és az eredmény fenntartható. A megoldást a strukturált oktatásban látjuk, amely felsővezetői operatív szintű, kontrolling és kontroller szintű informatikai modulokat tartalmaz.

 

 

A klasszikus módszer továbbfejlesztése

 

Kétségtelen, hogy a klasszikus módszer alkalmas az önköltség sokkal pontosabb meghatározására. A KKV szektorban azonban az önköltségszámításra nem igazán van igény. Ennek az lehet az oka, hogy az önköltségszámítás költséges, terheli a cég erőforrásait, de az eredménnyel kezdeni nem sokat lehet. A KKV szektor cégei nincsenek abban a helyzetben, hogy alakítani tudják a piaci igényeket, aminek egyik következménye az, hogy az uralkodó árképzési mechanizmusuk mindig a referenciaár módszer. Akármilyen önköltséggel tudnak gyártani vagy szolgáltatni, a piac az adott minőséghez tartozó piaci ártartományából fog választani. Ha az önköltségszámítás azt mutatja, hogy a gyártás nem nyereséges esetleg veszteséges, a cégnek akkor is meg kell jelennie a piacon a veszteséges termékkel, ugyanis, ha nem gyárt semmit, akkor a vesztesége sokkal nagyobb lesz, mert költségek egy jelentős része fix költség (munkabér, lízingdíj, kamat, fenntartási költség, előírt karbantartás, stb.), ami így is úgy is megjelenik a költségek között.

Tehát az önköltség rövidtávon nem releváns információ.

 

Amire szükség van, az annak meghatározása, hogy miért magas a költség.

A klasszikus ABC módszer lényege az, hogy a költségeket a tevékenységhez rendeljük, a tevékenységet pedig már sokkal szelektívebben lehet a termékekhez és szolgáltatásokhoz rendelni, így a termék önköltség valóban azt a költséget tartalmazza ami egy-egy termékhez hozzá tartozik. Ez igaz. A klasszikus módszernek azonban az a gyengéje, hogy semmit sem mond arról, hogy az így hozzárendelt költség rendelkezik-e piaci realitással, ugyanis a piacon ilyen termék vagy szolgáltatás nem található. Hiába osztjuk fel nagyon pontosan a terhelés alapján a termékek között pl. a bankkönyvelés költségét, ha egyszer a piacon nincs olyan szolgáltatás, hogy bankkönyvelés. De ugyanez igaz az összes támogató folyamatra vagy a gyártás fix költségeire is.

Ezért a támogató szolgáltatások költségét nem terheljük rá a termelés tevékenységeire, hanem a költségobjektum szinten önálló, piacon megvásárolható termékekre ill. szolgáltatásokra alakítjuk. Ezzel a belső szolgáltatások ára összehasonlítható lesz a piacon megvásárolható szolgáltatások árával és minőségével.

Ekkor az ABC séma így módosul:

30. ábra. A belső szolgáltatások leképezése termékekre

 

A tevékenységi szint és a költségviselői szint közötti driverek semmiben sem térnek el a szokásos driverektől (ezeket használjuk a betöltés és az erőforrásköltsége felosztása során is). Az eltérés annyi, hogy pontosan meghatározzuk a belső szolgáltatások - piaccal összehasonlítható árát.

A fentiek értelmében pl. az üzemeltetést négyzetméter árra kell leképezni és össze kell hasonlítani a piacon található üzemeltetési árakkal. Érdekesség kedvéért megemlítem, hogy az így keletkezett ár a piaci ár akár tízszerese is lehet.

És itt van a módszer lényege. Igaz ugyan, hogy megismerhető egy-egy támogató szervezet költségtömege, de az, hogy ezért mennyiségben, minőségben és piaci értékben milyen szolgáltatást nyújt az általában nem ismert és a klasszikus ABC eljárás sem tudja megmutatni.

 

 

Szakterületi önköltség és üzemi önköltség

 

A bemutatott eljárás a támogató tevékenységek költségeit nem osztja fel a termelés és a többi támogató tevékenység között. Az így kapott önköltség kizárólag a szakmai tevékenységek alapján került meghatározásra.

Azonban sokszor igény van arra is, hogy meghatározzuk egy-egy kiszolgáló tevékenység teljes önköltségét, ahol már figyelembe vesszük a többi kiszolgáló tevékenység költséghatását a vizsgált támogató szervezetre. Azaz pl. a könyvelési termékek (számlakönyvelés, bérszámfejtés, pénztárkezelés) önköltségénél figyelembe kell vennünk, hogy a könyvelés működéséhez szükség van az IT támogatásra, a üzemeltetési szolgáltatásokra (porta, fűtés, világítás, stb.) vagy pl. a felsővezetői szolgáltatásokra.

A dolog érdekessége, hogy ez egyetlen globális driverrel megoldható, aminek magyarázata az erőforrások végtermékre vetített költséghányadának kiszámolásában van.

 

 

Riport minták

 

A riportokat úgy célszerű elkészíteni, hogy egy Excel kimutatásban legyen az összes ill. az összes összetartozó kimutatás. Ezeket a kimutatásokat ritkán kell megváltoztatni, de a módosításuk magától értetődő, semmilyen különleges szaktudást nem igényel. Annak is van helye, hogy esetleg levédjük az oldalt.

Ettől független Excel munkalapon célszerű megjeleníteni a ad-hoc teszteket és a ALERT kockát, amely a hibákat tartalmazza.

Az alábbi ábrák mintául szolgálnak a kimutatásköteget személyre szabva szokás összeállítani. Ez a demó most egy virtuális iskolát mutat be. Az egyes ábrák nem ugyanabból az adatbázisból készültek.

 

A bruttó nyereség egy alapvető fontosságú kimutatás. A kimutatás feltételbe bármi megadható (szervezet, telephely, bármi), de célszerűen az időszak (pl.: év) mindig szerepel. A kimutatás azonban csak olyan mezőket jelenít meg, amihez érték (költség vagy árbevétel) tartozik. Az ábrán látható egyenleg egy közönséges Excel művelet, azaz az on-line kimutatás mezőivel műveletet lehet végezni. A bevétel ill. kiadás mezők tartalmát a "Betöltő driver" határozza meg, jelen esetben az ötös és nyolcas számlaosztály bizonyos elemei és a 9-es számlaosztály belföldi árbevétel alcsoportjai szerepelnek az elemzésben. Hogy a főkönyvi, bérszámfejtési tételek közül mi kerül feldolgozásra az a modellalkotás során dől el.

 

 

Költségkategóriák:

 

 

A kategóriák egy tetszőleges csoportosítást tartalmazhatnak, amelynek a célja az, hogy a tevékenységhez jól illeszkedő csoportokat leshessen képezni. Ilyen felhasználói csoportosítás rendelhető a számlatükörhöz is (valójában ilyen a mérleg is), de ez most nem az, ez most a költséghez magához van rendelve, készülve arra, hogy esetleg a számlatükröt nem fogja tartalmazni a modell.

 

 

Főkönyvi kimutatások:

 

Ugyanaz a kimutatás a főkönyvi számok szerint megjelenítve egészen más is lehet, mint a saját csoportosítással készült ábra. Van aki főkönyvi számokban szeret gondolkozni. Ez az övé. A könyvelők a számla neve helyett általában a számla számot kérik. Ez két kattintással oldható meg.

Ilyen riportot nem szabad készíteni! Ezen a  riporton ugyanis nincs rajta a vizsgált időszak, ami súlyos félreértésekre  ad lehetőséget. Rá kell tenni.

 

 

Lízingköltségek:

 

 

A kimutatásokban szereplő tételek lefúrásokkal mélyebb szinten is elemezhetőek. Itt arra voltunk kíváncsiak, hogy az előző kimutatás lízing tétele milyen elemekből tevődik össze. A standard kimutatásban ilyen részlet csak akkor szerepel, ha valamilyen oknál fogva kiemelt tétel.

 

Erőforrásköltségek

 

 

Az ABC elemzésben az erőforrás egy alapfogalom. Ha sikerül az erőforrás-könyvelést bevezetni, amikor a kontírozás során az erőforrást is megadják, akkor a költségelemzés pontossága ugrásszerűen nő. Az ábra az erőforrásokra könyvelt költségek érték sorrendjében mutatja a költségviszonyokat.

A kimutatások az első n legnagyobb (legkisebb) tételre is szűkíthetőek.

 

 

Tevékenységköltségek:

 

 

Az ábra egy-egy tevékenység összes költségét tartalmazza, függetlenül attól, hogy mely erőforráshoz vagy költségviselőhöz tartozik. A szűrőfeltételek segítségével a kimutatás erőforrások és költségviselők elemzésére is használható.

 

 

Költségviselők összköltsége:

 

 

A kimutatás a költségviselők nettó költségtömegét mutatja, tehát a költségviselőkre nincs ráosztva a kiszolgáló tevékenységek költségei.

 

 

Költségviselők költsége:

 

 

A mezők előtt látható'+' jel mutatja, hogy a mező lefúrási lehetőséget tartalmaz. Most arra voltunk kíváncsiak, hogy az oktatási költségek milyen képzéseket tartalmaznak.

 

 

Üzemanyagköltség:

 

 

Kijelöltünk két személygépkocsit mert látni szeretnénk az üzemanyag fogyasztásuk éves alakulását. Rengeteg ilyen és ehhez hasonló kimutatás készíthető. Az ábra jól mutatja a munkatársak felhasználási szokásait. Az ilyen kimutatásokkal nagyon óvatosan kell bánni. (Az ábra egyébként teljesen valós!)

 

 

Szervezetek költségei:

 

 

Az erőforrás magában hordozza a szervezeti adatokat is ezért a szervezetek költségviszonyai automatikus keletkeznek az erőforrás-könyvelésből.

 

 

A költségek területi eloszlása:

 

 

Az erőforrások a topológiai adatokat is tartalmazhatják. Ez esetben a területi költség eloszlás is automatikusan keletkezik. A topológiai adatok nyilvántartása nem kötelező.

 

 

Nettó önköltség:

 

 

Szükség esetén azok a költségek, amelyekhez nem tartozik bevétel kiszűrhető a listából. Ezt a szűrést jelöli a "Sorcímkék" mező mellett található szűrő ikon.

A lista a kiszolgáló tevékenységek önköltségét is tartalmazza. Ilyenkor ha nem nyilvánvaló a vetítési alap, akkor azt célszerű kiíratni.

 

 

Bruttó önköltség:

 

 

A bruttó önköltség már tartalmazza a kiszolgáló területeknek azokat a tevékenységeit is, amely valójában ok-okozati összefüggés szerint hozzárendelhető egy termékhez vagy szolgáltatáshoz.

 

 

Az adattündér:

 

 

Az össze kimutatás ennek az adattündérnek nevezett objektummal készült. A kimutatás készítése abból áll, hogy az adatbázis bármelyik mezőjét ráhúzzuk a Pivot tábla valamelyik elemére.

A kimutatás még igen nagy adatbázisok esetén is azonnal megjelenik, ennek az az oka, hogy a válaszok jelentő részét éjszaka kiszámolja a rendszer.

 

 

 

A távlati fejlesztési lehetőségek

 

Az eljárás egyik érdekessége, hogy az egymást követő lépések során automatikusan kialakul egy olyan szekvencia, amely a cég egész életét számsorozatok formájában tárolja:

 

 

Ez úgy is megfogalmazható, hogy ez az adatsorozat a cég születésének, fejlődésének, növekedésének és anyagforgalmának az összes adatát tárolja és miután ez az objektum kizárólag számokkal megadott azonosítókat tartalmaz, lehetőség nyílik bonyolult, üzleti intelligencián alapuló elemzésére. Arra lehet számítani, hogy ugyanúgy, ahogy az emberi DNS vizsgálata alkalmas a szervezet sajátosságainak, erősségének és bizonyos betegségeinek a felismerésére, ugyanúgy egy ilyen, a cég felépítését és működését leíró objektum is alkalmas lesz a cég betegségeinek és a benne lévő potenciáloknak a felismerésére. Ráadásul a szekvenciákban tárolt információ már nem kötődik a sem a cég  operációs rendszereihez, sem a konkrét vállalatirányítási rendszerhez, ezért mód van egységes teljesítmény mutatók kialakítására, elemzési eljárások fejlesztésére vagy statisztikai módszerek kidolgozására.

Érdekes kérdés az adatok személytelensége is. Várható, de még bizonyításra szorul, hogy az adatok elemzéséhez nem lesz szükség a szekvenciákat megnevező szótárakra. Azaz nem nevezzük néven az objektumokat és a szereplőket. Ez nem kevesebbet jelent, mint azt, hogy a sikerben az egyén szerepénél sokkal nagyobb a kölcsönhatások szerepe, ami viszont már kiolvasható a fenti számsorból. Ez valószínűleg működni fog, felvetés képen gondoljunk arra, hogy milyen jól elműködik vagy négymilliárd éve a természetes kiválasztódás, anélkül, hogy a DNS szekvenciák neve és szerepe fel lenne jegyezve az Alpok bal felső sarkában.

 

Az eltérő  iparágak CégleíróDNS-i szerkezetükben eltérőek lesznek, de ugyanabból az elemekből építkeznek. Ez sem igazán meglepő, a természet is így működik. Ha nem akarunk az anyahajók gyártásából következtetést levonni a szakiskolák működésére, akkor ez várhatóan itt sem okoz majd problémát.

 

Egyszerű üzleti kérdések eldöntéséhez nincs szükség ilyen bonyolult apparátusra, ezek a kérdések az ERP rendszeren belül maradnak. De ha olyan kérdésekre keresünk választ, hogy szabad-e ennek a cégnek a részvényeit megvenni, hitelképes-e a cég egy adott távon, milyen minőségű a cég vezetése, sikkasztanak-e a cégnél, mekkorák a belső tartalékok, mik a legfontosabb újraszervezési feladatok, vagy ha egységes technikán alapuló gördülő forecastokat akarunk készíteni, akkor a hagyományos könyvelés már használhatatlan. Ennek elvi okát abban látom, hogy a változások felgyorsultak így a piac válaszideje összemérhető tartományba került az adóhatóságok által kikényszerítet elszámolási időszakkal. Miután statikus adatokkal dinamikus folyamatokat egyébként sem lehet jól jellemezni, a mérleg és az eredmény-kimutatás statikus adatain alapuló pénzügyi mutatók megalapozott döntésre alkalmatlanná váltak. Előtérbe kell kerülnie a vállalat dinamikáját is hordozó értékelési rendszereknek.

Ez pedig ilyen.

A megoldás másik igen nagy előnye, hogy az elemző közgazdászoknak elegendő egy elemzési környezetet és elemzési módszerkészletet elsajátítani és nem kell elmélyülniük az ERP és a bérszámfejtési rendszerek egyedi megoldásaiknak halmazában, ami jelentősen csökkentheti az elemzési költséget.

Persze a névre szóló, részletes elemzés már a natív neveket tartalmazó szótárak segítségével történhet.

A leírás egyébként tartalmazza a kettős könyvelés főkönyvi számait is.

 

A vállaltirányítási rendszerek sok olyan adatot nem tartalmaznak ami alapvetős fontosságú a cég megítélésében és amelyeket ezért önálló nyilvántartásként kell vezetnünk. Ezek felállítása idő és költségigényes, ugyanakkor nagyon fontos lenne, hogy a meglévő adatok alapján is el lehessen kezdeni az elemzést, amelyet a hibás működési terület újraszervezését követően egyre pontosabbá és pontosabbá lehet majd tenni. A helyzet nem olyan rossz. A termelés esetén az ERP rendszerekből valójában ki lehet olvasni a fontosabb alaptevékenységeket, a támogató szervezetek tevékenységéből csomagokat készítünk, a CégDNS pedig tartalmazza a teljes analitikát. A betöltő driverek az adatokat függetlenítik a vállaltirányítási rendszertől, a CégDNS induló verzióját pedig a csupasz ERP adatokból is elő lehet állítani,  így BI módszerekkel már meg lehet keresni az összefüggéseket az anyagok, technológiák, létszámadatok, a forgalmi adatok és az üzleti eredmény között.

 

Egy több éves CégDNS meglehetősen nagy adatbázist alkot majd, de a mai számítógépek és a mai üzleti intelligencia rendszerek már képesek ezeket kezelni.

 

A sikerhez szükség van néhány komoly követelmény kielégítésére.

  • A DNS struktúrát gyorsan és olcsón kell feltárni, a feltárás nem terhelheti jelentősen a céget.

    • A betöltő driverek megalkotása nem gond, ebben ugyanis az ERP gyártók is érdekeltek.

    • A CégDNS előállítására egy önálló, könnyen használható eszközt lehet/kell fejleszteni.

    • Az egységes szekvencia szerkezet kialakítására módszert kell kifejleszteni.

    • Olcsó és gyors módszert kell kifejleszteni az erőforrások feltárására és a driverek adatainak meghatározására.

    • A felmérést és a dokumentálást BI alapokon álló ellenőrző és javító eljárásokkal kell támogatni.

    • A felmérésnek és a dokumentálásnak a költségét a KKV szektorban 100 eFt-os nagyságrendre kell csökkenteni.

  • A rendszernek észre kell venni a cég működésében bekövetkező változásokat és arra reagálnia kell.

  • Szabványokat kell bevezetni a szerkezet és a működési szekvenciák összemérhetőségére.

  • A rendszernek alkalmasnak kell lenni a fontos és nem fontos jelenségek felismerésére.

Elsősorban azonban sok cégleíró objektumra lenne szükség.

 

A követelmények teljesítésének egy része egyszerű fejlesztési és szervezési feladat, a standard fő-teljesítménymutatók megfogalmazása és megalkotása közgazdasági és informatikai szakmai feladat,  de az igazán hasznos üzleti intelligencia eljárások egy része még a közgazdasági és informatikai alapkutatás területéhez tartozik.

 

Tartalomjegyzék:

 


            Kupán Károly

          BI-Control LTD

Kupan.Karoly@BI-Control.hu

 (UnitedIT Informatikai Kft.)

 

 Az "ABM csoport" alapítója.

 

Ugrás a lap tetejére