Üzleti intelligencia rendszerek bevezetése

Üzleti folyamatok újraszervezése

 

Induljunk ki a vállalkozás mikro-gazdasági rendszerének sematikus ábrájából:

1. ábra. A mikro-gazdasági rendszerének sematikus ábrája

 

A költségelemzés azt a kérdést vizsgálja, hogy a bemeneti erőforrások milyen arányban oszlanak meg a használati érték, a többletérték és a kimenő információ között, így ha a költséggazdálkodás vizsgálata a cél, akkor egy újabb elemmel kell kiegészíteni a fenti ábrát. A veszteséggel.

2. ábra. A mikro-gazdasági rendszer vesztesége

 

A vizsgálatot pedig ki kell terjeszteni azzal a kérdéssel, hogy a bemeneti erőforrások milyen hányadban kerülnek a veszteségbe. Azaz az erőforrások egy része semmilyen vagy csekély kapcsolatban van az eredménnyel. Az, hogy egy olyan folyamatot, amelynek nincs felírható kapcsolata az eredménnyel hova sorolunk tökéletesen szubjektív döntés. Ugyanakkor ezek a döntések alapjaiban befolyásolják a cég sikerét. Ha például a veszteségek közé soroljuk az adókat (ugyanis ma Magyarországon ez semmilyen kapcsolatban nincs az eredménnyel), akkor a legjobb költségcsökkentési megoldás az offshore cég létrehozása. Aztán érdekes kérdés például a marketing költség. Ha a folyamtok szervezése jó, akkor egészen pontosan meg lehet mondani, hogy melyik termékre, termékcsoportra, brandre vagy régióra esetleg imázsra kell terhelni a költséget, de például azt hogy szükség volt-e rá, azt már nagyon nehéz mérni. Ráadásul az is egészen biztos, hogy nem a marketingeseket kell megkérdezni.

A veszteségek megszüntetése azonban szintén erőforrást (energiát, időt és anyagot) azaz pénzt igényel ezért egyáltalán nem természetes, hogy egy veszteséget meg akarunk-e vagy meg tudunk–e szüntetni.

Mindehhez persze nem ártana tudni, hogy hol, mekkora veszteségekkel dolgozunk.

 

Ehhez az kell, hogy a komplex gazdasági folyamatot kezdjük el felbontani elemi folyamatokra, majd meg kell vizsgálni a folyamatok összefüggéseit és erőforrás szükségletét.

Azonban még a legegyszerűbb gazdálkodási egység is feldolgozhatatlanul bonyolult, ezért modelleket kell készíteni, amelyek többé-kevésbé használhatóan írják le a gazdasági folyamatokat.

Az ERP rendszerek általában rendelkeznek költséggazdálkodási modullal. Valójában minden rendszer más és más modellel próbálja megközelíteni a valóságot, de mindegyik csak közelít. Aztán léteznek önálló költséggazdálkodási rendszerek, amelyek az ERP rendszertől függetlenül – szigetként – működnek. Ezek általában sokkal jobb modellt használnak, de ezek értelemszerűen nincsenek integrálva az ERP rendszerbe.

 

Az üzleti intelligencia egy egészen új színt hoz a költségelemzésbe. A BI lehetővé teszi tetszőleges költséggazdálkodási modell felállítását, ugyanakkor az ERP rendszer adatbázisán dolgozik.

Igaz, hogy ekkor viszont nem áll rendelkezésünkre egy kidolgozott modell.

Az is igaz, hogy ekkor a cég tevékenységéhez legjobban illeszkedő modell állítható fel.

 

Véleményem szerint az üzleti intelligencia rendszerekkel akkor lehet komoly eredményt elérni, ha a rendszer kiépítése párhuzamosan folyik az üzleti folyamatok elemzésével és újraszervezésével. A KKV szektorban tehát nem maga a BI rendszer, hanem a hibák feltárását és az újraszervezést is tartalmazó teljes folyamat teszi igazán sikeressé a projektet.

 

 

Ebben a sorozatban az üzleti intelligencián alapuló költségelemezést mutatom be, mégpedig kifejezetten gyakorlati megközelítésben.

 

A költségelemzési modell felállítása rögtön egy kemény megszorítással kezdődik. A költséggazdálkodási adatokat kénytelenek vagyunk a könyvelési rendszerből venni, de a könyvelés nem képes mérésre és nem képes a folyamat-specifikus adatok tárolására és feldolgozására sem. A könyvelés gyakorlatilag egyetlen mértékkel dolgozik: a pénzösszeggel, de az erőforrás adatok nem képezhetőek le az árra.

Amit a könyvelésben az erőforrásokból látunk azok a bizonylatok (pl. számlák, bérszámfejtési bizonylatok, stb.) rögzített értékei. A nem teljesen szokványos tevékenységet végező cégek vezetési rendszerében ezért speciális alrendszerek vannak, amik általában nem jelentenek integrált megoldást. De azt is meg kell jegyezni, hogy a legtöbb ERP rendszer például egyáltalán nem kezel bérszámfejtést, holott ez egy alapvetően fontos gazdálkodási adat és csak személyre bontott adatokból lehet elemzést készíteni. Aztán szükség lehet olyan adatokra is, amit semmilyen ERP rendszer nem kezel (-:

Az ilyen feladatoknál jön ki a BI rendszer egyik igazi előnye, a rendszerfüggetlenség.

 

Maradjunk annál, hogy a költségeket számlák (és egyéb hasonló bizonylatok) modellezik. A gazdaságelemzéshez arra van szükség, hogy minden költségtételhez pontosan meg tudjuk mondani, hogy mikor, hol és milyen célból keletkezett. Ezeket az adatokat a bizonylatok esetén a bizonylat tételei hordozzák (pl. a számlatételek). A cégvezetési rendszerekben viszont az adatoknak három jól elkülöníthető szintjéről kell beszélni. Ezek a bizonylatok szintje, az analitikák szintje és a szintetikák szintje. A bizonylatok szintje azonban csak kézzel kezelhető, ezért ha az elemzés során vissza kell nyúlni a bizonylatok szintjére, akkor már baj van. Ez megoldható 5-10 bizonylatnál, de 50 000-nél nem. Ha olyan ERP rendszerrel dolgozunk, amely megőrizte a hagyományos szintetikai szintet, akkor az elemzésnél vissza kell lépnünk az analitikák szintjére (hiszen csak ott van pl. számlatétel), ami meglehetősen nehézkessé teszi BI rendszer fejlesztését. Megjegyzem a korszerű rendszerekben klasszikus szintetikus könyvelés már egyáltalán nincs. Ezekkel könnyű dolgozni.

 

Az elemzéshez szükség van tehát egy olyan objektumra (jó esetben maga a főkönyv), ami egységesen tartja nyilván a gazdasági események analitikus adatait. Ha ezt nem teszi meg az ERP rendszer, akkor ezt a BI szintjén kell megoldani.

Ez az objektum teszi majd lehetővé az intelligens „Eredmény beszámoló” használatát, amelynél minden tételnek utána tudunk járni és a lefúrásokkal az „Árbevétel összesen” vagy „Költség összesen” szintről akár az alapbizonylat szintjére is le tudunk jutni.

 

Sajnos a tapasztalatom szerint az első lépés azonban mindig a BI rendszer felállítását akadályozó hibák feltárása és kijavítása kell hogy legyen. Ezt a folyamatot az előzetes felmérésben nem végezzük el, ekkor a hibás tételeket egyszerűen töröljük, a szerencsétlenül kialakított megoldásokat pedig elfedjük. Az adattisztítás során is csak technikai hibákat javítunk (pl. árva tételek törlése, alapértelmezések bevezetése, kódhibák feltárása, stb.) Az éles rendszerben nem nyúlunk bele.

Ettől azért olyan nagyon nem kell félni, mert végül is a cég működik, a könyvvizsgáló, az APEH elfogadta az adatokat tehát ha nekik jó volt, akkor indulásként nekünk is jó lesz. Ennek megfelelően az indulás érdekében nyugodtan kitörölhetjük a működést gátló adatokat, csak tisztában kell lenni azzal, hogy nem fogunk egyezni főkönyvvel. Gondoljunk például arra, hogy egy több milliós főkönyvben szoktunk találni olyan tételeket, amihez nincs főkönyvi szám. Hát nem mindegy hogy kitöröljük-e?

A kérdésről itt láthatunk egy videót.

 

Ha az alapvető hibákat kijavítottuk és a BI rendszer el tud indulni, akkor a könyvelésünk segítségével már koncentrálhatunk arra, hogy mikor mit, milyen mennyiségben szereztünk be. A továbbiakban mondjuk azt, hogy ez az esemény rendelkezik három dimenzióval (teljesítési idő, beszállító, termék vagy szolgáltatáskód) és egy mértékkel, az árral. Ezt mindig kiegészítjük a mennyiséggel, amit legtöbbször az analitikából kell kivadászni.

Nem tudjuk azonban, hogy milyen szervezeti egység, ki és mire szerezte be az erőforrást. Azaz megjelent három új dimenzió.

Ami nincs rajta a számlán.

A nem számlás költségek esetén ugyancsak hiányoznak ezek az adatok, de pl. a bérszámfejtés esetén sokkal jobb a helyzet, ott szinte mindig minden adatot pontosan tudunk.

 

Itt lép fel a második komoly probléma. Most egy olyan művelet következik, amely során a bizonylatról a fenti adatokat meg kell állapítani. Ez a kontírozás. Hagyományosan a kontírozás csak a költségnemere (6-os 7-es esetén a helyekre és a költségviselőkre) értendő, itt azonban a dimenziókra kell kiterjeszteni. A tapasztalat azt mutatja, hogy nem kerül hozzánk olyan ügyfél, ahol 6-7-es könyvelés folyik, ezzel tehát nem foglalkozok.

 

Érdekes kérdés az is, hogy a rendszerben hova tudjuk beírni az új dimenziókat. A költségnemek minden programban benne vannak, ezzel nincs gond. De az, hogy melyik szervezethez ill. munkatárshoz kapcsolódik a tétel annak rögzítése már nem triviális. A jobb rendszerek kezelnek projekteket, munkaszámokat, sarzsokat, stb. akár ezek is felhasználhatóak, bar ezek új önálló dimenziók. Használhatjuk a 6-os - 7-est is, de ezt nem szeretjük. És végezetül vannak rendszerek, amelyek önálló, tetszőlegesen felhasználható dimenziókat biztosítanak erre a célra. Az általam ismert nagyrendszerek mindegyike ilyen.

A BI erőssége, hogy teljesen mindegy, hogy hova rögzítjük a kontírozási adatokat, mindenhonnan fel tudjuk dolgozni. Nekünk akár egy Excel tábla is jó.

 

Ha van hol rögzíteni a dimenziókat, akkor már csak az a kérdés, hogy mit kell odaírni. Azt, hogy a számlatételen található kakas-rugó-dugó-csap (esetleg a kanyarfúró vagy a hangyacsont) hova könyvelendő azt egy kontírozó aligha tudja felelősséggel kitalálni. Ugyancsak sűrű pislogást eredményez az a kérdés, hogy melyik projekthez tartozik és ki rendelte meg, stb.

Az, hogy ezek az adatok korrektül rendelkezésre álljanak gyakran a folyamat újraszervezését igényli, ami része kell hogy legyen a projektnek.

 

A dimenziókra való kontírozás nehézségeit szemléltesse ez a valós eset:

A vizsgált cég egy dimenzión azt rögzíti, hogy az esemény az árbevételhez kapcsolódik. Ennek megfelelően minden kimenőszámlánál gondosan rögzítik, hogy az egy kimenő számla. Már ha el nem felejtik. A 9-es számlaosztály 64 028 tételéből így 56 848 helyen rögzítették, hogy az egy bevétel, mindössze 2710 helyen felejtettek el valamit beírni, de volt 27 „egyéb” is.

Egy további dimenziót tartanak fent a költséghelyek rögzítésére. Ezeknek a száma 67. Egy újabb dimenzión rögzítik a „munkatársakat”, ezeknek a száma 82.

Viszont az eltérő költséghely-munkatárs kombinációk száma: 411. Van olyan munkatárs, aki több mint egy tucat költséghelyhez tartozik.

Ennél a cégnél például valószínűleg az egész adminisztrációt újra kellene szervezni.

A dimenziók kontírozásánál célszerű néhány alapszabályt betartani. Például azt, hogy ami kijön a rögzített adatokból azt sohasem szabad kézzel ismét rögzíteni. Ez nem csak felesleges munka, hanem jószerével használhatatlanná teszi a rögzített adatokat. Ugyancsak óvakodni kell attól, hogy olyan adatokat rögzítsünk, aminek van logikai kapcsolata egy másik már rögzített adattal. Például nem szabad rögzíteni költséghelyet és munkatársat akkor, ha a munkatársak költséghelyhez tartozhatnak.

 

További probléma, hogy ha elegendően pontosan akarjuk leírni majd a költségviszonyokat, akkor nem is elegendő egy sík kódolási rendszer, amely csak felsorolja a fontosabb költséghelyeket.

 

Ennek megoldására javaslom a strukturált, többdimenziós költségkódok bevezetését. Ezt is egy példával közelítsük meg.

A legfelső szinten, maga a cég van.

1 Jövőépítő Művek

A következő szint a cég szervezeti felépítését mutatja.

1.0 Nincs felosztva. Ide lehet kontírozni az olyan költségtételeket, amiket nem tudunk egy osztályhoz sem rendelni. Például a cég imázs növelésére fordított összegeket.

1.1.0 Cégvezetés. Nincs felosztva. Ez egy szervezeti egység. Ide kontírozzuk azokat a költségeket, amelyeket a cégvezetés teljes szervezetére fordítottunk. Ilyen például a kávéfőző.

1.1.1 Vezér Viktor. Ő az ügyvezető igazgató. Azaz munkatárs. Ide kontírozhatjuk azokat a tételeket, amik az ügyvezető személyes költségei. Ide érthetjük a kerítésnek való kolbászt, a személyi használatú gépkocsi költségeit és a fizetését valamint ennek költségeit is.

1.1.2.0 Titkárság. Nincs felosztva. A titkárság egy önálló szervezeti egység a cégvezetésen belül. Ide azok az összegek kontírozhatóak, amelyek csak a titkárság szervezeti egységre vonatkoznak, de nem terhelhető rá a titkárság egy konkrét munkatársára. Ilyen például a papír daráló költsége.

1.1.2.1 Nagy Juliska. A titkárság egyik munkatársa. Juliska személyes költségei kontírozandók ide. Elsősorban a bérek és bérköltségek.

1.1.2.2 Kis Piroska. A titkárság másik munkatársa. Piroska személyes költségei kontírozandók ide. Elsősorban a bérek és bérköltségek.

1.2.0 Gazdasági igazgatás. A második szervezeti egység.

Stb…………………..

Egyébként ezeknek a kódoknak a használata koránt sem bonyolult, hiszen a rögzítésnél általában elegendő a természetes név megadása vagy kiválasztása (Cégvezetés, Juliska, stb.).

A többdimenziós kódolással valójában tetszőleges pontossággal le lehet írni a céget, de szükség esetén visszaléphetünk vele akár a sík kódolásra is, amikor egyszerűen felsoroljuk a fontosabbnak vélt költséghelyeket. Az egyszerűbb felbontásnak (modellnek) az indulásnál lehet szerepe, de lássuk be, semmi nem indokolja, hogy a költséghelyek megadásánál elveszítsük a szervezeti struktúrát.

A többdimenziós kódolás lehetőséget ad az eszközök azonosítására is. Ennek megfelelően pl. a Cégvezetés költséghelynek lehet ilyen tagja is:

1.1.1.1 GXZ 013. Az ügyvezető személygépkocsija. Ide kontírozhatjuk a jármű költségeit is.

1.1.1.2 AZF-234. Az ügyvezető személyes használatú lépegető exkavátorának a költségei.

 

Ugyancsak a többdimenziós kódolást tudjuk használni a költségnemek csoportosításánál is. A költségnemek multidimenziós felosztása szintén fix, tehát nem kontírozási, hanem tervezési feladat.

Pl. lehet ilyen:

1. Bevételek

      1.1 Az alaptevékenység bevételei

      1.2 Egyéb bevételek

2. Kiadások

            2.1 Adók

            2.2 Bérek

            Stb.

Ez tehát nem más mint a számlatükör egy speciális megjelenítése, amely kifejezetten az cégvezetés számára van kialakítva. (Egyébként pontosan ilyen például a klasszikus eredmény-kimutatás vagy a mérleg is.)

 

 

Az első modell

 

Első lépésben tekintsünk meg egy nagyon egyszerű modellt. Az erőforrásokat számlák és egyéb bizonylatok azonosítják. A bizonylatokat kontírozzuk költségnem és költséghely szerint. A kontírozásnál többdimenziós rendszert használunk. A bizonylatok natív módon tartalmazzák az idő, beszállító, termék/szolgáltatás dimenziókat, az ár és mennyiség mértékeket. Ezeket egészítjük ki a kontírozás során a többdimenziós költséghely és költségnem dimenziókkal.

Példa a többdimenziós kontírozásra.

Két számlán legyen egy-egy tétel. Az egyik egy kávéfőző, a másik egy defekt javítás a főnök autóján. A kávéfőzőt az egész Cégvezetés használni fogja, de a defektjavítás csak a főnők autójához tartozik. Ennek megfelelően a kontírozás:

Kávéfőző

Költségnem: mondjuk 5114. A kontírozásnál az 5114-et kell választani. Ezt a kiválasztásos költségnem kontírozást minden rendszer tudja.

Költséghely: 1.1.0 ami a Cégvezetés fel nem osztott költsége. A kontírozásnál - ha az ERP rendszerünk elég intelligens, akkor egyszerűen a Cégvezetést kell választani, ha nem az, akkor az 1.1.0 kódot be kell írnunk.

Ill. a gumijavítás

Költségnem: mondjuk 529

Költséghely: 1.1.1.1 ami a GXZ 013 frsz. gépkocsi multidimenziós kódja. Ez jó esetben a GXZ013 választásával kontírozható.

 

A rögzítést követően a „kockán” kiépített struktúrák segítségével a megadott számlaértékek összegei megjelennek a „Jövőépítő művek” költségei között, a Cégvezetés költségei között ill. az Igazgató és a gépjármű költségei között megjelenik a gumijavítás.  Így:

 

Végezetül teljesen kibontva

3. ábra. Lefúrás a szervezeti szintek irányába.

 

A "lefúrás" úgy történt, hogy mindig a + jelre kattintottam.

 

A költségnemek esetében az értékek megjelennek a Kiadások, az Anyagköltségek között ill. értéküknek megfelelően a két konkrét számlaszámon. Tehát kiindulva a költség összesen szintről le tudunk fúrni a személyi használatú gépkocsi költségéig, majd meg tudjuk nézni magát a számlát is.

4. ábra. Lefúrás a költségek irányába.

 

A kontírozást tehát a végpontra végeztük (egy adott főkönyvi számlaszámra és egy adott költséghelyre), de lekérdezni már tetszőleges összefüggésben lehet.

 

Mindezt akár az ERP rendszer akár egy Excel tábla alapján is el tudjuk végezni (a példában 4 Excel táblánk volt, amelyet egy SQL adatbázisba olvastunk be). Ez azért fontos, mert lehető teszi a gyakorlatilag büntetlen kísérletezést, mind az adatainkkal, mind a személyi állományunkkal.

 

Érdemes észrevenni, hogy például a marketing költség pontosabb kontírozásához be kell majd vezetni egy új dimenziót a kódba (még multibb lesz) éspedig a költség viselőjét, azaz a termékcsoportot vagy a brandet vagy bármit. Ekkor már nem csak azt fogjuk azonosítani, hogy a marketing osztály költségéről van szó, hanem azt is, hogy pontosan mire költöttük.

Hasonló a helyzet az eredmény oldalon is. Itt a gazdasági eseményeket a kimenőszámlákkal azonosítjuk. A számlák natív módon hordozzák az idő, a vevő, a termék/szolgáltatás dimenziókat, az ár és mennyiség mértékeket.

Itt lehet némi probléma a kereskedők és kereskedelmi ügynökök azonosításával. Az ERP rendszerek nagy része a vevőket eleve dimenzionálja és azonosítja a vevőhöz rendelt kereskedő személyét. Az is lehetséges, hogy ez csak egy önálló CMS rendszerből olvasható ki, ami nem probléma. Ha a rendszer az eladásokat menedzselő kereskedőt nem azonosítja, akkor a kimenőszámlát is kontírozni kell és ebben a folyamatban kell rögzíteni annak a kereskedőnek a nevét, akihez a siker rendelhető.

Ez esetben erre is fent kell tartani egy dimenziót.

 

Ebben a modellben csak a költségek és bevételek költséghelyek és költségnemek közötti felosztása elemezhető. Miután ebben a modellben még nem osztunk fel a ráfordításokat a szervezeti egységek között itt csak arra kérdésre kapunk választ, hogy közvetlenül mennyibe kerül egy szervezeti egység vagy eszköz működtetése illetve egy munkatársunk. Mindez azt fogja eredményezni, hogy túl sok tétel lesz a fel nem osztott pontokon (pl. a közműdíjak mind a cég legfelső szintű fel nem osztott pontján lesznek). A végső cél persze az, hogy a kiadásokat a lehető legpontosabban hozzárendeljük a bevételekhez, amihez legcélszerűbb a tevékenység alapú költségelemzés (Activity Based Costing– ABC) valamelyik megoldásának alkalmazása lesz.

Ennek ellenére ez az egyszerű modell is igen érdekes következtetésekre ad lehetőséget. Sőt, mindaddig nem szabad továbblépni, amíg az ezen a szinten feltárt hibákat ki nem javítottuk.

 

Következő cikk:

A többdimenziós kódoláson alapuló költség és bevételelemzés gyakorlati megvalósítása. Ebben egy „Költség kockát” állítunk össze, amelyen az mutatható be, hogy egy ilyen egyszerű modellel is milyen érdekes eredményre lehet jutni.


Kupán Károly

UnitedIT Informatikai Kft.

Kupan.Karoly@UnitedIT.hu

 

Ugrás a lap tetejére