Miért olyan nehéz egy vállalat digitális transzformációja?
Egy külföldi tulajdonú multinacionális cég újonnan megvásárolt leányvállalatánál, a Jászságban, a gyártó-cellákhoz üzemi monitorokat telepítettünk, amelyeken egyetlen BI dashboard ment folyamatosan – az aktuális gyártócella teljesítménye. Bizonyos helyeken egyetlen ember dolgozott a cellában, máshol egy kis csapat végezte a munkát, és a monitorokon a második esetben a csapat egyesített teljesítménye volt vizualizálva. A leegyszerűsített nézeten grafikonon ábrázolt és számmal is megjelenített értékek körül zöld, sárga és piros színnel jeleztük, hogy az adott cella teljesítménye a norma szerint mennyire jó tartományban van, ugyanis a munkavállalók csak a zöld zónában eltöltött munkavégzés után kapták a teljesítménybérüket.
Az első napokban a gyártó-cellák túlnyomó része sárga és piros színben pompázott, de néhány hét alatt a dashboardok elkezdtek kizöldülni. Először az egyedül dolgozók teljesítették csak a normát, majd hamarosan a csapatok együttműködése is elég hatékonnyá vált ahhoz, hogy a zöld szín megjelenjen a grafikon körül. Mindeközben természetesen rengeteg dráma történt a HR-en. Sok dolgozó elment a cégtől, viszont ez a termékenységnek jót tett, ugyanis a kilépők helyére érkező új munkatársak már az új rendszerbe szocializálódtak.
Három hónap elteltével már csak kivételes esetekben ment sárgába a teljesítményérték, az összes gyártó-cella monitorja zöld színben úszott.
Ekkor a menedzsment jelentősen megemelte a norma szinteket minden tevékenységi területen, és ez azt jelentette, hogy a kijelzőkön újra a piros szín uralkodott. Arról sajnos nincs információm, hogy a háttérben ezt hogyan követték le kommunikációval a munkatársak felé, az azonban biztos, hogy jelenleg ebben a magyar gyárban pontosan olyan kiemelkedő termelékenységgel termelnek a magyar munkavállalók, mint a svéd vagy a német gyárakban.
“It's OK to have your eggs in one basket as long as you control what happens to that basket. “
Az üzleti intelligencia rendszer (Business Intelligence – BI) olyan szoftver, amely feldolgozza az üzleti adatokat, és felhasználóbarát nézetekben (ún. műszerfalak, diagramok és grafikonok segítségével) jeleníti meg azokat. Tágabb értelemben a BI [bíáj] eszközök adatfeldolgozást végeznek, amely segítségével adatelemzés és tudásmenedzsment valósítható meg a vállalatban. A BI az az “adat-kombájn”, ami betakarítja a vállalat egyes területeiről a megképződött és rögzített adatokat (pl. ERP adatbázis, beléptető rendszer, webes szoftverek, külső illesztések adatbázisai, Excelek), és információt készít belőlük. Manapság ezek az adat-kombájnok már “megőrlik a búzát, megsütik a kenyeret, sőt az ebédet is feltálalják”, azaz a vállalatban elérhető adatokból részletes és könnyen értelmezhető információt szolgáltatnak a vezetőknek a stratégiai és taktikai döntéseikhez.
Mi ezt most Excelben csináljuk…
Az Excel egy kis cégben működhet BI eszközként, azonban egy könnyen elérhető méret után már biztosan a növekedés gátja lesz. Ennek legfontosabb oka, hogy “az Excel nem adatbázis”, de a következőkben adunk egy ennél részletesebb magyarázatot.
Ha az Excel és a vele analóg egyéb szoftverek egy nap sztrájkba lépnének, és nem indulnának el, akkor a világ néhány perc alatt teljes káoszba sűllyedne. A gazdasági és pénzügyi folyamatok olyan nagy része megy még mindig Excelben, hogy jelenleg biztosan ez a legfontosabb üzleti rendszer. Nem véletlen, hogy egy vállalatvezető általában először Excelben kezdi el követni a folyamatait: ebben készíti az árkalkulációját, a tervezését és az önköltségszámítását is. Az Excel, mint eszköz az A komplexitási szinten általában elegendő, viszont a B komplexitási szinten kezdenek előjönni azok az akadályok és problémák, amik a C komplexitási szinten már biztosan tarthatatlanok lesznek.
Az Excel főbb korlátait az alábbiakban gyűjtöttük össze:
- Adatmennyiség. Egy alap Excel vagy spreadsheet korlátozott a rekordok és oszlopok számában. Van ugyan megoldása a Microsoftnak ennek feloldására, azonban az “Excel erdők” előbb-utóbb – a hardver-környezet fejlesztése mellett is – kezelhetetelen lassúságba és bonyolultságba fulladnak.
- Biztonság. Excelben az adatok, a számítások és a képletek logikája is egyetlen fájlban kerül tárolásra. Aki ehhez hozzájut, minden információ a rendelkezésére áll ahhoz, hogy visszafejtse akár az üzleti logikát is.
- Jogosultságkezelés. Az ERP-ben mező és tábla szinten meghatározható, hogy a rendszer mely felhasználója milyen adatokat láthat, míg az Excelben autentikáció hiányában erre nincs lehetőség. Az ERP-ben és a BI-ban könnyen elrejthetők például a bérügyi adatok egy részleg felhasználói elől, akik épp ugyanabból az adatforrásból dolgoznak, mint egy másik részleg felhasználója, aki viszont jogosult látni az elemi adatokat is.
- Érintett területek. Gyakorta előfordul, hogy adataink függnek még valamitől, ami meglehet, hogy egy másik Excelben vagy másik adatbázisban található. Annak érdekében, hogy egy egyszerű Excelben is használni tudjuk ezeket a “külső” adatforrásokat, ahhoz vagy be kell kötni és átmozgatni az adatokat egy adott formában/formátumban, vagy kinyerni exporttal, és statikusan a saját adataink mellé tenni. Például, ha szükségem van minden nap egy beléptető rendszer adataira, amelyek egy relációs adatbázisban vannak tárolva, elég nehézkes megoldani, hogy Excelbe átkerüljenek a megfelelő adatok mellé ezek az információk.
- Összefüggések követése. Egy Excelben a legkisebb módosítás is felboríthat több tucat vagy akár az összes számítást, amit végzünk. Például törlésnél még csak nem is figyelmeztet, hogy kapcsolódó ‘táblák’ vagy számított mezők építkeznek erre az adatra.
- Adatmódosítás/szcenáriók. Az Excelben hordozott adatok esetében, ha szcenáriókat akarunk lejátszani, vagy módosított formában akarunk kimutatni vagy számolni valamit, akkor vagy az eredeti adatokat kell módosítanunk, vagy le kell másoljuk az egészet az új variáció előállításához, ami körülményes, főleg ha több tucat változatot meg szeretnénk vizsgálni..
- Valósidejűség. Az Excel jó abban az esetben, ha valaki(k) folyamatosan vezeti(k) benne az adatokat. Általában múltbéli adatok kerülnek rögzítésre valamekkora késleltetéssel. Ha mindezt valós időben szeretnénk megoldani egy másik forrásból, ahonnan pl. egy automatizmus segítségével kerülnek be a valós idejű adatok, akkor egy Excel file mindaddig blokkolt, amíg valamilyen más szoftver éppen olvas belőle vagy ír bele. Tehát, ha a későbbiekben lenne ilyen tervünk bizonyos adatainkkal, úgy azokat nem érdemes Excelben tárolni.
- Adattisztítás probléma. Az Excel bármit elbír, mivel az adatbevitelnél nincs lehetőség adatbeviteli kontrollra (ami például ERP-ben megoldható). Ha az Excelt használjuk kontrolling eszközként, akkor nehezen tudunk ellenállni a kísértésnek, hogy adatfelvitelre is használjuk. Gyakran előfordul, hogy véletlenül szöveget írunk szám helyett, és akkor jön az adattisztítás fáradtságos folyamata, amikor után kell ellenőrizni, hogy valóban helyes-e minden adat, képlet az Excelben. Nagyon gyakori tünet, hogy a munkaidő nagyobb része megy el a hibák javítására egy szervezetben, mint a tényleges elemzésre.
Miért nem tudja az ERP a BI funkciókat?
Az ERP tranzakciókat kezelő rendszer, így a struktúrája, az adatok tárolási mechanizmusa (online transaction processing – OLTP) erre a feladatra lett optimalizálva. Az ERP rendszer nem alkalmas arra, hogy új, akár ad-hoc szempontok szerint rugalmasan és gyorsan kérjünk le információkat, mint ahogyan a BI rendszer éppen ebben hatékony, ahol “adatkockákban” tárolódnak az adatok (online analytical processing – OLAP) kifejezetten a lekérdezésre optimalizáltan.
Az ERP feladata, hogy az adatok bevitelét támogassa és biztosítsa. Tehát ezt a rendszert adatok felvitelére és tárolására tervezték, nem pedig dinamikus adatlekérésre. Természetesen van arra lehetőség, hogy az ügyviteli rendszerben egyedi kimutatásokat fejlesszünk, amelyek az adott ügyfél igénynek megfelelően mutatják meg az információt, azonban ezek a továbbiakban már kötöttek, a lefejlesztésük elég költséges és időigényes, ráadásul a kész kimutatások nem feltétlenül lesznek gyorsak, hiszen abból az adattárból dolgoznak, ahol nem az információkinyerés, hanem az adatbevitel az elsődleges.
A modern BI rendszerek ezzel szemben bármilyen vállalatirányítási rendszer adatbázisához képesek kapcsolódni, majd szinkronizáció segítségével átemelni onnan az adatokat saját, analitikai alapú adatbázisukba. Ettől kezdve pedig már rendelkezésére áll egy olyan platform, ahol villámgyorsan lekérdezhető új szempontok szerint bármilyen információ.
Legalábbis a SingleStore megjelenéséig így nézett ki a technológia, de ma már a Platformunk alatt olyan adatbáziskezelő van, ami egyidejűleg és valós időben tudja kiszolgálni a tranzakciós (ERP) és analitikus (BI) igényeket. Ez az egyik forradalmi változás az üzleti informatikában, amire már utaltunk a korábbi fejezetekben és ezért fog teljesen összeolvadni a jövőben a BI az ERP rendszerekkel. De ahhoz, hogy ennek a folyamatnak a jelentőségét megértsük, tisztában kell lennünk a BI használatával.
A kontrolling eszköze a BI
A BI nem helyettesíti, hanem ráépül az ERP rendszerre mint adatelemző és vezetői információs modul vagy réteg. Az ügyviteli folyamatokat ERP rendszerrel kell lekezelni, azonban ezekből adatokat, elemzéseket kinyerni már sokkal jobb minőségben (és olcsóbban) megoldható egy BI rendszer alkalmazásával. Miközben egy ERP rendszer esetén új kimutatás készítéséhez gyakran programozóra van szükség (ami sok pénz és idő), addig ugyanazt a kimutatást a BI-ban gyakran maga a felhasználó is el tudja készíteni, akár percek alatt.
Azt szokták mondani, hogy a vezető szempontjából az ERP a szükséges rossz, és a BI rendszerrel kiegészülve válik azzá, ami valódi megtérülést hordoz, és ekkor már van értelme a ROI számításnak is (lásd előző fejezet).
A BI használatba vételének vannak fokozatai
Az első lépcsőfok szinte mindig az adatok, mérőszámok grafikonos megjelenítése, amit angolul dashboarding-nak szoktak nevezni és műszerfal építésnek fordíthatunk. Fontos azonban, hogy olyan szolgáltató/tanácsadó partnert válassz, aki a többi lépcsőfokon is át tud vezetni, mert a színes garfikonok messze vannak a BI valódi üzleti hasznától és hatásosságától. Erről a sokállomásos utazásról szól az alábbi ábra, amit érdemes tanulmányozni mielőtt BI rendszert vagy szállítót választ ki egy vállalat.
Egy BI eszköz bevezetésének megtérülése biztos, miután a vállalat vezetői elkezdik használni. A termelékenységben szintlépést fog jelenteni egy jól kialakított BI, de hasonlóan az ERP bevezetéshez, itt is nagyon fontos, hogy ne csak technikai emberek, hanem kontrollingban jártas “feketeöves” logisztikai és pénzügyi szakemberek (tanácsadók) vezessék be a rendszert – különben csak színes grafikonok lesznek és semmi más.
A legjobb módszer annak mérésére, hogy a bevezető cég alkalmas-e feladatra, az (bővített) önköltségszámítás vagy más néven utókalkuláció modellezésének kialakítása, ami – tevékenységtől függetlenül – minden vállalatnál tartogat kihívásokat.
Önköltségszámítás
Egy kisebb cégben a termékek önköltségének kiszámítására gyakran úgy tekintenek, mint egy szükséges rosszra, amit a törvényi előírások szerint meg kell csinálni. A vállalkozás növekedésével párhuzamosan azonban nő azon igény is, hogy az önköltségszámítás eredményét a vállalat egyre több területen felhasználja.
Sok vállalkozás vezetője nem is gondol arra, hogy belátható időn belül lehetséges részletes, közvetett önköltséget számítani (akár termékenként), és vizsgálni az önköltségszámítás hatását a vevőnként keletkezett haszon vonatkozásában is.
A Dyntell ügyfelei között találunk olyan mezőgazdasági termelő és konzervipari céget, ahol az önköltségszámítás tekintetében már a negyedik modellt vezették be az évek során, fokozatosan tökéletesítve a módszertant, hogy egyszerre feleljen meg a törvényi előírásoknak, illetve a belső felhasználás igényeinek. A cél minden modell esetén az volt, hogy meghatározzuk, mennyibe kerül egy termék előállítása, viszont az út és a pontosság, ahogyan elértük a célt, időközben változott.
A BI-on alapuló kontrolling rendszer lehetőséget biztosít a termelési szerkezethez történő rugalmas alkalmazkodásra: az ügyfelünknél nem egyszer fordult elő, hogy új csomagológépet vásároltak, azonban ennek a gépnek a költségei csak bizonyos termékeket terheltek és a BI-ban megvalósított önköltségszámítási modell rugalmassága biztosította az új elem beépítését.
Természetesen, Excel táblák sokaságával és különféle (páldául vállalatirányítási) rendszerekből történő lekérdezéssel is megoldható a termékszintű önköltségszámítás, azonban BI esetén az önköltségszámítási modell felállítása után egy gombnyomásra előáll az utókalkulációs tábla, ami termékenként tartalmazhatja az önköltségi ár egyes elemeit, akár több ezer termék esetén is.
Amennyiben adott egy jól kiszámolt önköltségi ár, lehetőségek tárháza nyílik meg az eredmények további felhasználására:
- vizsgálhatjuk a vevőnként keletkezett hasznot figyelembe véve, hogy maga a vevő, vagy a vevő megtartása mennyi plusz költséget jelent számunkra,
- pontosan be tudjuk hangolni a termék árát, akár vevőnként külön-külön,
- végezhetünk gyártásoptimalizálást, kiderülhet, hogy az a gép, amin gyártunk, lényegesen megnöveli a termékünk árát, és ezért nem vagyunk kellően versenyképesek,
- a nyereségmaximalizálás érdekében figyelembe vehetjük az eredményeket a termék ára vagy termék portfólió összeállításánál.
A különböző költségelemek sokrétű felosztása manuálisan munkaigényes, viszont BI rendszer alkalmazásával az alapadatok rögzítésén kívül minden automatizálható, nem beszélve arról, hogy mennyivel pontosabb és zökkenőmentesebb a folyamat, mint a rengeteg manuális munkát igénylő Exceles megoldás.
Függetlenül attól, hogy milyen tevékenységű vállalat utókalkulációs modelljét építjük, az első feladat az utókalkuláció alapegységének és szintjeinek meghatározása, ami lehet:
- cikk-, termékszintű
- gyártási rendelés szintű
- termékcsoport szintű
- vevői rendelés szintű
- szerződés szintű
A modell építésénél dönthetünk az utókalkuláció szintjeiről, és akár több szintű utókalkulációs árat is meghatározhatunk:
- közvetlen önköltség
- technológiai önköltség
- gyártási önköltség
- szűkített önköltség
- teljes önköltség
A következő lépés, hogy meghatározzuk azokat a költségeket, amelyeket figyelembe kell vennünk az utókalkuláció-számításnál, amelyek az alábbiak lehetnek:
- anyagköltség
- bér- és járulékköltség
- kooperációs munkadíjak
- szerszámköltség
- gépköltségek, pl. amortizáció, karbantartás
- víz, áram, gáz díjak
- bérleti díj
- karbantartási költségek
- csomagolási díjak
- belső, külső logisztikai költségek
- üzemegységek általános költségei
- minőségbiztosítási költségek
- stb.
Ugyancsak a modell lényeges eleme, hogy megállapítsuk a függőségeket és az osztási/vetítési arányokat, amelyek a legkülönbözőbbek lehetnek.
A modell megvalósítását követően a felhasználó feladatai átalakulnak: nem azzal tölt órákat, hogy Excel táblák kapcsolt hálózatát a vállalat több területi képviselőjének az adatszolgáltatása alapján előállítsa (és örülhet, ha valamit lát a végén), hanem az értékes időt az eredmény elemzésével és az esetleges hibák javításával töltheti. A hiba javítását követően egy adatszinkronizáció hatására azonnal megmutatja, hogy milyen hatása volt a javításnak, és az új eredmények azonnal rendelkezésre állnak.
Az utókalkulációnk csak akkor pontos, ha az adminisztráció is pontos!
Ahol nincs lehetőség szigorú anyagkönyvelésre, ott a tömeg kihozatali hányad számolásával lehet megkerülni a problémát (adott tömegű alapanyagból kijön-e norma közeli tömegű késztermék). Ebben az esetben a BI abban segít, hogy “Mi lenne, ha” típusú szcenárió elemzésekkel kikísérletezzük a megfelelő időtávot (és egyéb paramétereket), amiben vizsgálódunk.
BI hatékonyság-növelési ötletek
A BI egy “svájci bicska”: sok mindenre használható.
Az alábbiakban szeretnék néhány olyan területet kiemelni, ami nem feltétlenül a scope-ja egy alap BI bevezetésnek, de nagyon hasznos lehet, ha ezeket is beveszed a megvalósítandó dashboardok körébe, ha releváns a cégedben.
Ármeghatározás
Az ármeghatározás és árváltoztatás alapja az önköltségszámításból érkező információ, hiszen fontos, hogy megfelelő profit-tartalom legyen elérhető az egyes termékek értékesítésével. Ha elegendő adatunk van, akkor az ár meghatározására a múltbeli értékesítési adatok alapján célszerű árérzékenység számítási módszert alkalmazni. Ennek segítségével lehet ugyanis belőni azt az optimális értékesítési árat, amiből a legnagyobb profit realizálható (például csökkentsük az árrést, mert akkor sokkal többet fognak venni – de persze csak a minimális profit tartalomig –, vagy növeljük az árat, mert ezt a terméket magasabb áron is meg fogják vásárolni).
Az árérzékenység-elemzés során általában kiderül, hogy vannak olyan termékek a portfólióban, amelyeket olcsóbban értékesítünk a kelleténél, és ezért jelentős profittól esünk el nap mint nap.
Az árérzékenység mérése kulcsfontosságú a legtöbb iparágban, különösen az FMCG, vagyis a gyorsan fogyó fogyasztási termékek körében. A közgazdaságtanban a keresleti függvény árrugalmasságán keresztül határozzák meg a mértékét, vagyis azt, hogy az árváltozás miként befolyásolja egy adott termék iránt a keresletet. A magas rugalmasság azt jelenti, hogy a fogyasztók magasabb árak mellett is hajlandók vásárolni, míg rugalmatlanság esetén egy kisebb áremelkedés is jelentősen visszaveti a vásárlást. Amit mi keresünk, az az “egyensúlyi ár”, vagyis az a pont, ahol a bevétel maximalizálása érdekében a kereslet találkozik a kínálattal.
Legtöbb esetben az ár és a mennyiség időben történő megváltozása között fordítottan arányos kapcsolat áll fenn. Ha az ár emelkedik, az értékesítés volumene csökken, és fordítva. Legtöbbször a lineáris modellek jól illeszkednek a pontokhoz, azonban szinte minden nagyobb adatbázisban számos olyan cikket találunk az adatelemzések során, melyeknek az ára gond nélkül növelhető, és sok esetben javaslunk enyhe árcsökkentést is az értékesítési vezetőknek. Láttunk olyan extrém esetet, ahol az eladási ár több mint 100%-kal növelhető volt, és ezzel több tízmilliós plusz árrést hozott a kereskedő vállalatnak egyetlen nyár alatt.
A kapott eredményeket azonban mindig óvatosan kell kezelni, mert a keresletre ható összes paraméter nyilván nem vizsgálható ebben az egyszerű statisztikai modellben.
Vevőminősítő-rendszer, azaz a vevői viselkedések elemzése
A vevők minősítése azért fontos, mert a vállalat minden munkatársának illik tudnia, hogy aki telefonon keresi, az a legfontosabb vevők közé tartozik-e, hiszen ebben az esetben más elbánásban kell részesüljön, mint az, aki évente csupán egyszer vásárol, és azt is több hetes késéssel fizeti ki.
Ahogy nő egy vállalat, előbb-utóbb kialakul egy vevőminősítő-rendszer. Kezdetben lehet, hogy ezt a vevői viselkedés alapján alakítják ki, de ahogy telnek-múlnak az évek, a frissítés már csak bizonyos paraméterek mentén történik meg (ha egyáltalán megtörténik).
Érdekes kísérlet volt, amikor egy széles vevőkörrel rendelkező nagyvállalati ügyfelünktől azt a megbízást kaptuk, hogy ügyfelei viselkedése alapján validáljuk az aktuális ügyfélminősítő rendszerüket, és ezzel együtt készítsünk egy új, megbízhatóbb partner osztályozó rendszert. Ehhez megvizsgáltuk a vásárlók fizetési viselkedését, mind gyakoriságban, mind pontosságban, valamint a vásárlói kosarakat értékben és mennyiségben. Ennek eredményeként jött ki egy teljes (~10.000 partner) céges partner elemzés, ahol akár egyesével is van lehetőségünk a változókat elemezni. E szempontok szerinti csoportosítás szemléletesen vizualizálható egy háromdimenziós grafikonon.
A következő dashboardon pedig a vásárlások gyakoriságát láthatjuk, ahol meghatározott algoritmusok alapján tudunk riasztást küldeni azon vevőkről, akik kezdenek lemorzsolódni (azaz nem tőlünk vásárolni) vagy már le is morzsolódtak. Célzott megkeresésekkel érdemes lehet ezeket a partnereket felkeresni, megnézni, hogy mivel elégedetlenek, és megpróbálni “visszaédesgetni” őket.
Automatikus ajánlat generálás
A videón bemutatott Excel fájl a BI részére forrásként szolgál, amely látható, hogy egyetlen sort tartalmaz adatokkal. Ebből épül fel a BI-ban a kimutatások között a Dyntell elnevezésű riport. Egy kattintással és előnézet választással a rendszer pillanatok alatt generált egy 10 oldalas ajánlatot a megadott adatokból.
Ilyen és ehhez hasonló automatizmusokkal jelentős munkaidőt lehet megtakarítani.
Az előző példánkban a GINOP 3.2.2 pályázathoz volt szükséges készítenünk ajánlatokat. Egy ajánlat elkészítése egy senior kollégának átlagosan 1-1,5 órát vesz igénybe. Ebben az időszakban a Dyntellnek több mint 200 ajánlatot kellett kiadnia. Pontosan kiszámolva, egy kollégánknak ezeket összesen 200-300 munkaórába került volna előállítania, azonban ezzel a megoldással ez az idő lecsökkent nagyjából 10-20 órára. Ehhez mindössze annyi dolga volt az értékesítő kollégának, hogy az Excelbe feltöltötte a szükséges adatokat, majd a rendszer az adatok felhasználásával másodpercek alatt legenerálta egyenként az összes pályázati anyagot.
Dinamikus készletszint meghatározás mesterséges intelligenciával
Dinamikus készletszint meghatározásnak nevezzük azt a folyamatot, amikor figyelembe vesszük a cikkek fogyását szezonálisan, és a rendszer jelzi, ha növelni vagy csökkenteni kell a készletszintet. Ez minden készletgazdálkodással foglalkozó cégnél kulcsfontosságú, hiszen ha túl keveset raktározunk az adott cikkből (alapanyag/termék), akkor nem fogjuk tudni kiszolgálni a vevőinket, ha pedig túl sokat, akkor feleslegesen kötünk le pénzt a készletben. Ez utóbbi hibába előszeretettel esnek bele azok a magyar KKV-k, ahol nagy nyereséggel tudják eladni a termékeiket. Azonban számos döbbent tekintettel találkoztam már, amikor a BI-ban megmutattuk, hogy a busás profitot hogyan apasztják le a raktározási és pénz lekötésénél adódó (ún. opportunity) költségek.
A legmarkánsabban ez a hatás a rövid szavatossági idejű (short shelf-life) termékeknél látszik. Ide elsősorban az élelmiszer gyártók és kereskedők tartoznak. Egy sütőüzemben a tapasztalt gyártástervező a szezonalitás és a vevői keretrendelések alapján tervezi a gyártást, de még a legegyszerűbb mesterséges intelligencia algoritmus is hatékonyabb lehet nála, ami elég messzire és elég részletesen tud “belenézni” a múlt adataiba.
A fenti dashboardon egy amerikai reggeliző lánc bizonyos cikkeinek előrejelzését láthatjuk, ahol a múltbeli adatok mellett az adott terület gazdasági és földrajzi adataival való korrelációt is figyelembe vettük. A 10 étteremnél nagyobb láncoknál, ahol előre elkészítik az ételt (pékség, reggeliző hely, salátabár stb.) évente 100.000 dollár (azaz 30 millió Ft) nagyságrendű megtakarítást lehet elérni minden esetben, mert nem kell a nap végén a kukába dobni a naponta túlgyártott termékeket.
Meglepődnénk, hogy mennyi minden függ az adott lokáción lévő időjárástól, sőt, attól is, hogy éppen milyen holdfázisban vagyunk. A fenti műszerfalon sárga színnel jelöltük az előrejelzett fogyási mennyiségeket, a kék vonal pedig azt jelzi, hogy a valóságban mennyi fogyott az adott termékből. A grafikonokon jól látszik, hogy általában 80-90%-os pontosságú előrejelzés adható, ami lényegesen jobb, mint az étteremvezető tapasztalat- (és ösztön-) alapú becslése.
Riasztások (Alerting)
A riasztások, vagy workflow, egy kulcsfontosságú funkció, amit sem az Excel, sem az ERP rendszerek nem tudnak rugalmasan megvalósítani. Segítségével bármely KPI-hoz (mutatóhoz) beállítható, hogy amikor az elér egy alsó vagy felső határértéket (továbbá más kapcsolódó paramétereket is megadhatunk), riasztást vagy jelentést küldjön emailben.
Ezt a képességet monitorozó rendszernek is nevezhetnénk, azonban ezzel beszűkítjük az alkalmazási lehetőségeket. Egy ilyen modul lehetőséget nyújt ad-hoc ellenőrzések gyors beépítésére is, pl. vizsgálható, hogy egy adott területen milyen alapossággal töltik az ERP adatait, és a felületesebb kollégák direkt üzenetet kapnak arról, hogy hogyan lehet az adminisztráció minőségén javítani az esetükben.
A riasztásokat nem csupán a rendszer felhasználói kaphatják meg, hanem bárki, akit címzettként definiálunk. Ezáltal a működési folyamatainkban olyan szabályrendszert tudunk összeállítani, amely adatokon nyugszik és valós időben történik.
Egyes BI eszközökben workflow is építhető ilyen módon, vagyis ha kiváltódik egy alert, akkor az további folyamati lépéseket indíthat el attól függően, hogy milyen más információk állnak rendelkezésre, vagy milyen opciót választ a felhasználó. Erre példa a bejövő számla kifizetésének engedélyeztetése, ahol a számla összegétől, jogcímétől függően más-más részlegek, más-más szintű vezetői jogosultak az ellenjegyzésre.
Ha a BI eszközünk előrejelzésre (predikcióra) is képes, akkor az adatok folyamatos figyelésének hatására nem utólag, a probléma bekövetkeztekor, hanem akár már előtte is kaphatunk riasztást az adatok irányáról és természetéről, amelyek alapján a megfelelő intézkedésekkel időben elkerülhető egy valódi és nagyobb probléma. A riasztási rendszer ugyanis hozzáfér a BI által generált előrejelzésekhez, ahol a múltbeli adatok alapján látszik a trend, és ha például a trend azt mutatja, hogy az áramfogyasztás néhány percen belül kritikus szintet fog elérni, akkor még időben tud a rendszer egy azonnali üzenetet küldeni az energetikusnak, hogy lépjen közbe.
Érdemes végigböngészni az alábbi pdf-et, amit a bevezetéskor szoktunk az ügyfeleinknek átadni. Ezek az alertek már sokszáz millió forintot takarítottak meg ügyfeleinknek.
Előrejelzés
A mindennapi életben is tapasztaljuk, hogy bizonyos események, folyamatok előrejelezhetők. Ilyenkor a korábban történt eseményekre, adatokra alapozunk. Elég nagy biztonsággal mondhatjuk azt például, hogy holnap is fel fog kelni a nap. Ha a vállalati adatokat szeretnénk előrejelzni, akkor biztosan érzékelni fogjuk a trendet, vagyis azt az irányt, ahogyan a vizsgált adatok éppen változnak – ennek előrejelzése ún. regressziós módszerekkel valósítható meg.
A gazdaságban szintén fontos a szezonalitás, ami az időben ciklikus folyamatokra jellemző. Egy jó regressziós módszer ezt is figyelembe tudja venni, amennyiben a múlt adataiban ez tükröződik.
Az is valószínű, hogy az adott folyamat nem független, hanem más folyamatoktól, eseményektől függ, ezért fontos a predikciónál a korreláció vizsgálata más folyamatokkal.
A következőkben az előrejelzésről olvasható egy hosszabb leírás, amely segít megérteni a predikció működését:
https://dyntell.com/mesterseges-intelligencia-es-big-data-a-cegvezetesben/
Tervezés
A sokat tapasztalt vezetők mondják, hogy az különbözteti meg a kisvállalkozást a vállalattól, hogy a vállalatban már van tervezés – a vállalkozásban még nincs.
A tervezési folyamat alapja a pénzügyi tervezés, ahol bevétel- és költségsoronként kell megadni a tervszámokat (általában az előző évek adatai alapján), majd ezt kell azután lebontani az erőforrásokra (vagyis, hogy az adott bevételt milyen és mennyi erőforrással leszünk képesek megvalósítani). A terv biztosít kiindulási alapot a motivációs rendszernek, hiszen a tervben szereplő mérőszámok elérése esetén teljesít jól a szervezet, ekkor lehet prémiumot adni a vezetőknek és a munkatársaknak. A terv akkor számonkérhető, ha minél szélesebb körben megosztottuk a szervezettel, és a vezetőket bevontuk az elkészítésébe.
Térjünk vissza még egy pillanatra a fejezet elején a multi történetére, ahol a gyártóüzemben monitorokat helyeztek el. Ennél a vállalatnál a csoportos teljesítménybér-rendszer bevezetéséhez és működtetéséhez meg kellett határozni, milyen mérőszámot kell elérjen a munkatárs egy adott napon, egy konkrét munkafeladatban, (és azt is, hogy ezzel mekkora profitot termel a vállalatnak, és abból mekkora részt kaphat meg ösztönző formájában). Ahhoz, hogy egy hasonlóan komplex rendszer felálljon, szükséges a részletes tervezőrendszer megléte.
A szoftverfejlesztő cégünknél a kontrolling rendszer összeszedi az egyes értékláncok vonatkozásában, hogy egy munkatárs a tervhez képest a megadott időpontig hogyan teljesített. A hatékonyság lényege, hogy a motivált kolléga minden egyes nap végén képes legyen eldönteni, hogy jó napja volt vagy rossz napja volt. Mindez tervezés és kifinomult kontrolling rendszer nélkül nem tud működni.
A pénzügyi tervszámok teljesítése mellett fontos, hogy a minőség felett is őrködjünk, hiszen pusztán a profit növelésével nem feltétlenül jár együtt az elégedett ügyfél. Hosszú évek finomhangolása során kialakulhat a vállalati tervezésben egy olyan súlyok-ellensúlyok rendszere, amely képes megfelelően támogatni bennünket a jó minőség elérésében és megtartásában, és ezzel együtt hatékonyan tartja a működést.
Nem minden BI eszközben elérhető a tervezés funkcionalitás, pedig nagyon hasznos, ha a valós (tény) adataink kontrollja mellett a terv adataink teljesülését is nyomon tudjuk követni.
Váratlan események, folyamatok természetesen bármikor megzavarhatják a legprecízebben összeállított tervet is – ezt például a COVID időszakban testközelből tapasztalhattuk meg -, azonban egy BI Tervezés modul képes arra, hogy tény adatok segítségével újratervezést készítsünk, illetve akár kezeljünk több terv-változatot (szcenáriót).
Általánosan igaz a tervezési folyamatra, hogy elég időigényes és aprólékos, ugyanis:
– ki kell gyűjteni a tényadatokat,
– majd olyan struktúrába szükséges szervezni őket, hogy minél jobban támogassa az átlátható tervezést.
Nem kis munka egyik feladat sem, ezt teszi egyszerűvé/egyszerűbbé a BI Tervezés modulja.
Tervezési módszerek
Top-down és bottom-up tervezés
A „top-down” és a „bottom-up” tervezés két különböző megközelítést jelent az üzleti tervezésben. A tervezés felépítésének irányát fejezik ki: felülről lefelé vagy alulról felfelé.
- Top-Down tervezés:
- A top-down tervezés esetén felülről kezdjük a folyamatot a tulajdonosi és/vagy menedzsment céloktól.
- Az első lépésben meghatározásra kerülnek a terv fő számai. Például: a bevétel az infláció és a iparági növekedés figyelembevételével legyen 25%-al több mint az előző évben, és a profitnál is érjünk el egy 15%-os növekedést.
- Ezt követően az egyes terv-elemeket (fenti példában a bevételt és a kiadásokat) tovább bontják, és így haladnak lefelé az alapelemekhez.
- A tervezés folyamán a tervezők az absztrakt szintű tervezéstől indulnak el, majd fokozatosan haladnak a konkrétabb részletek felé.
- Bottom-Up tervezés:
- Bottom-up tervezésnél a tervezési folyamat a legalacsonyabb szintű részekkel/részletekkel kezdődik, majd ezeket építik össze magasabb szintű rendszerré.
- Például az értékesítésnél megtervezik, hogy az előző éves tényadatok alapján a kereskedelmi forgalom várhatóan mennyi lesz az adott évben az egyes cikkekből vagy cikkcsoportokból.
- Ezt követően minden területről, részlegről begyűjtik a tervadatokat, és egyesítik a számokat.
- A tervezés során a részletektől indulnak el, és haladnak feljebb a magasabb absztrakciós szintek felé.
Mindkét megközelítésnek vannak előnyei és hátrányai. A top-down tervezés segíthet az áttekinthetőségben és a magasabb szintű célok megértésében, míg a bottom-up tervezés részletesebb betekintést nyújthat az alacsony szintű részletekbe. Sok esetben a tervezés során mindkét módszer kombinálható, hogy kihasználják az előnyöket, és minimalizálják a hátrányokat, ezt hívjuk ellenáramú tervezésnek.
Ellenáramú tervezés
Az ellenáramú tervezésnél a tervezési folyamat két irányból indul el a szervezetben: a tulajdonosok is megadják a keretszámokat, és az alsó szintekről is elindul a tervezési folyamat. A két tervet összevetik, és a tulajdonosok – ha meggyőzik őket – módosíthatják az eredeti számokat, majd egy tisztán top-down tervezéssel zárják a tervezést. Egy összetett szervezetben számos iteráció lehetséges az ellenáramú tervezésnél, ami meglehetősen elnyújthatja a tervezési folyamatot. Így általában sokkal valószínűbb, hogy a terv egy konszenzuson nyugvó elfogadása történik, ami nagyon fontos a tulajdonosi és végrehajtó szintek motiváltságának megtartásában.
- Null-bázisú tervezés és tény adatokon alapuló tervezés
A tervezési formák másik csoportosítási szempontja, hogy milyen kiinduló adataink vannak. A null-bázisú tervezés azt jelenti, hogy a tervezés során nem a megelőző tényadatokra alapozunk, hanem gyakorlatilag “nulláról” alkotjuk meg a tervet. Ezt a tervezési módszertant induló vállalkozásnál vagy egy újonnan piacra lépő terméknél szokták alkalmazni.
Sokkal fáradtságosabb, de sokkal pontosabb tervezést tesz lehetővé, ha a tényadatokat összegyűjtjük, és az összefüggések feltárásával, analitikusan tervezzük meg a következő üzleti időszakot.
Terv-tény előrejelzés-riasztás
A tervezésre és előrejelzésre is képes BI-ok legütősebb funkciója, amikor gondolkodnak helyettünk, és egyúttal ez az alapja a mesterséges intelligencia integrációjának is a vállalati döntések folyamatába.
Például ha megvan az adott havi tervünk, akkor a BI-ban a tervszámok mellé tudjuk tenni a tényadatokat. Tudjuk azt például, hogy szeptember 21-ig mennyi bevételt teljesített egy adott értékesítőnk a szeptemberi tervhez képest. A BI képes megvizsgálni az elmúlt évek szeptemberi adatainak mintázatait, számol az éves trendekkel, és meghatározza, hogy ha szeptember 21-én még csak 6,2 millió Ft bevétel jött be az adott értékesítő csatornáján, akkor nem lesz meg a havi 9,5 milliós terv (az adatok múltbeli mintázata persze azt is mutathatná, hogy a kitűzött cél még elérhető, mivel az előző évek tanúsága szerint a szeptember vége mindig nagyon erős). A BI a beállításoknak megfelelően ekkor automatikus üzenetet küld az értékesítési vezetőnek, csatolva a kalkuláció részleteit. Ez alapján a vezető időben meg tudja nézni az elemzést, és meg tudja beszélni az adott értékesítővel a probléma okát.
Blokklánc
Ha a kontrollról beszélünk, fontos megemlítenünk azokat a technológiákat, amelyek globálisan segítenek a folyamatok kontrolljában, mint például a blokklánc vagy a blockchain (https://hu.wikipedia.org/wiki/Blokkl%C3%A1nc#).
Blockchain technológiát (az ún. tokeneket) a másolás megakadályozására, a tulajdon vagy a hitelesség igazolására, tranzakciók nyomonkövetésére, adatbiztonság növelésére használják az üzleti szoftvereknél.
Mivel a számlák esetén az e-számlánál inkább a PKI azonosítás (https://www.hwsw.hu/hirek/40563/pki—-avagy-mit-takar-a-publikus-kulcsu-infrastruktura.html) az elterjedt (amely esetében egy auditált token-kibocsátó szervezet működik), a blokkláncok alkalmazása inkább a szállítólevelek vagy szerződések esetén lehetne releváns.
Nem véletlen a feltételes mód, ugyanis azok a vállalatok, akik bizonylatcserét folytatnak, jelenleg általánosságban az EDI technológiát (http://edi.hu/index.php/mi-az-edi) használják. A szerződések esetében pedig komoly kavarodást okozna a KKVk körében, ha közös megegyezéssel nem lehetne visszanyúlni és megváltoztatni a szerződéses feltételeket.
Mindezek ellenére a blockchain technológia egyre terjed, és mivel az automatizált, gyorsabb és kényelmesebb folyamatok felé halad a világ, biztosak lehetünk benne, hogy előbb-utóbb meghódítja a blockchain a magyar üzleti világot is.
A BI beolvadása az ERP rendszerbe
Ennek a fejezetnek a végén azt szeretnénk megmutatni, hogy a jövő mit tartogat a számunkra a kontrolling területén. Az biztosan kijelenthető, hogy a BI esetében valóban forradalmi átalakulás van folyamatban.
A vállalatok jelenleg egyfajta szoftveres nagyítóként használják a BI rendszereket, amelyek segítségével a folyamataikat, értékláncaikat elemzik, és az elemzések eredményeire támaszkodva folyamatosan finomhangolják azok működését. A jelenlegi architektúrák azonban csak arra adnak lehetőséget, hogy a mai nap a tegnapi, illetve a múlt adatait tudjuk teljes körűen elemezni. Ennek oka elsősorban az eddigi paradigmában rejlik: az ERP tranzakciós adatbázisba (OLTP) menti az adatokat, míg a BI csak adatkockákból (OLAP) tud táplálkozni, ezért – rendszerint sokórás éjszakánkénti – szinkronizáció (extract-transform-load – ETL) viszi át a tranzakciós rendszerekből az adatokat a BI adatkockáiba. Alternatívaként használják a memóriában tárolt adatbázist, de ez csak kis adatmennyiségeknél nyújt megoldást a problémára, és ez sem valós idejű.
A múltat feldolgozó rendszerekből ugyanazért nem lehet vállalatot vezetni, mint amiért nem lehet autót vezetni kizárólag visszapillantó tükörbe nézve. Ugyanis a vállalati döntéshozó így csak azt látja, hogy mit kellett volna tegnap tenni ahhoz, hogy a vállalat működése hatékonyabb legyen, viszont a valós idejű folyamatok szabályozásában nincs hathatós segítsége. Tehát az a rendszer, ami a vezetésben hivatott segíteni bennünket, jelenleg visszapillantó tükörként funkcionál – pusztán abban tud segíteni, hogy mi mellett haladtunk el, abban nem igazán, hogy éppen mire kell figyeljünk.
SingleStoreDB feloldja az előbbi problémát, azaz valós időben lehet például készletforgás chartokat elemezni. Sokkal fontosabb eredmény azonban, hogy a mesterséges intelligencia gépi tanuló algoritmusai képesek valós adatokon futni, így valós idejű kontrollt adnak az üzleti folyamatokhoz (hiszen a gépi tanulásnak is általában adatkockákra van szüksége, és nem tranzakciós adatbázisra). Ez lehetővé teszi a vállalatok gyorsabb reagálását a változásokra, amely egy a jelenlegi nagyon változó világunkban létfontosságú, továbbá valós döntési segítséget tud adni az üzleti szoftver a középvezetők számára. Mindez elindíthatja azt a robbanást, amire már évtizedek óta vár mindenki az iparágban, és amiről a következő részben fogunk írni.