A kérdés, amit nem szeretnek
Honnan lett ennyi
Van egy kérdésem, amit minden ügynök bevezetésnél felteszek, és amire eddig egyetlen cégnél sem kaptam azonnali választ. Ha a rendszeretekben egy ügyfél hitelkerete tizenkétmillió forint, meg tudjátok mondani, hogyan lett pontosan ennyi.
A válasz általában két lépcsőben érkezik. Elsőre azt mondják, hogy nyilván valaki beírta. Aztán ránéznek a rendszerre, és látják, hogy a mező mellett annyi szerepel, ki módosította utoljára és mikor. Ez nem az adat útja. Ez egy lábnyom a legutolsó lépésről.
Ami hiányzik belőle, az minden, ami számít. Mekkora volt előtte. Mi váltotta ki a változást. Volt-e mögötte jóváhagyás, és ha igen, kitől. Egyszeri kivételként emelték meg egy konkrét ügylet miatt, vagy tartós döntés született róla. Van-e olyan dátum, ameddig ez az érték szólt.
Amíg emberek dolgoznak a rendszerben, ez a hiány nem okoz látható bajt. Az ügynöknél viszont azonnal falba ütközünk, és ezt a falat nem a modell képességei húzzák fel.
Két rendszerfelfogás
Állapotot tárolsz vagy folyamatot
A legtöbb vállalatirányítási rendszer állapotot tárol. Azt tudja, mennyi most a készlet, mennyi most az ár, mekkora most a keret. Minden módosítás felülírja a korábbi értéket. Ez logikus tervezés volt akkor, amikor a tárhely drága volt, és a cél a gyors kimutatás.
A folyamat alapú megközelítés fordítva működik. Nem az aktuális értéket őrzi elsődlegesen, hanem az eseményeket, amelyek odavezettek. Beérkezett egy megrendelés. Egy vezető jóváhagyott egy kivételt. Lejárt egy szerződéses feltétel. Az aktuális állapot ezekből az eseményekből számolódik ki, és bármikor visszafejthető, mert a lánc megmarad.
Ez a különbség sokáig könyvelési és auditálási témának számított. A pénzügyben régóta így gondolkodnak, hiszen egy főkönyvben sem törölnek tételt, hanem stornóznak és újat könyvelnek. A cégek működésének nagy része viszont sosem kapta meg ezt a fegyelmet. A törzsadat, az árazás, a partnerbesorolás, a raktári paraméterek szinte mindenhol állapotként élnek.
Egy élelmiszer nagykereskedésnél, ahol száznyolcvanan dolgoznak, ezt a különbséget egy raktári paraméteren keresztül értették meg. A minimális rendelési mennyiség egy terméknél kétszáz darab volt. Senki nem tudta megmondani, miért, mert az eredeti oka egy szállítói feltétel volt, ami két évvel korábban megszűnt. Az érték viszont ott maradt, és a beszerzés azóta is eszerint dolgozott.
Amiért az ügynöknél ez élesebb
Az ügynöknek nincs kihez fordulnia
Amikor egy tapasztalt kolléga meglát egy furcsa számot, elindít egy folyamatot a fejében. Eszébe jut, hogy ez az ügyfél tavaly problémás volt. Rákérdez a pénzügyön, ahol valaki emlékszik egy vezetői döntésre. Előkeres egy levelet. Fél óra alatt összerakja a történetet.
Az adat útja tehát létezett, csak nem a rendszerben. A szervezet emlékezetében volt, kollégák fejében, levelezésekben, egy tárgyalás jegyzetében. Az ügynök ehhez nem fér hozzá. Ő pontosan annyit tud, amennyit a rendszer leír neki, és ezért a rendszerbe rögzített nyomvonal mennyisége lesz a megbízhatóságának a felső határa.
Ezt a projektjeimben úgy szoktam megfogalmazni, hogy az ügynök nem attól lesz óvatos, hogy jól promptoltuk. Attól lesz óvatos, hogy van mit megnéznie. Ha nincs, akkor a legjobb modell is ugyanazt teszi, amit egy új munkatárs első napján tenne. Elhiszi, amit a képernyőn lát.
Azt tapasztaltam, hogy a cégek ezt a pontot rendszerint az első komolyabb hiba után értik meg, és nem előtte. Addig a beszélgetés a modellválasztásról szól.
A gyakorlatban
Mit jelent az, hogy az adat útja megmarad
Egy folyamat alapú rendszerben minden változás önálló bejegyzést kap. Ebben benne van, mi történt, mikor, mi váltotta ki, melyik szabály vagy dokumentum alapján, és ki felelt érte. Az érték nem egy mező, hanem ennek a láncnak a jelenlegi végpontja.
Ettől az ügynök képes lesz valamire, amire állapot alapú rendszerben nincs módja. Meg tudja nézni a döntése alapját, mielőtt cselekszik. Nem csak azt látja, hogy a keret tizenkétmillió, hanem azt is, hogy ezt egy egyszeri kivételként emelték meg egy tavalyi projekt miatt, és hogy ez a kivétel lejárt.
Egy kétszázötven fős gépipari beszállítónál pontosan ebbe futottunk bele. Egy rendelés jóváhagyó ügynököt indítottunk el, ami az elsőnek látszó feladatot végezte, összevetette a beérkező rendeléseket a partner keretével és a készlettel. Két hét után átengedett egy rendelést, ami nem fért volna bele. A vizsgálat során kiderült, hogy a keretet másfél évvel korábban emelték meg, egyetlen szállítmány kedvéért, és utána senki nem állította vissza. Az emberi kollégák ezt tudták, ezért nem is nézték a mezőt, hanem fejből dolgoztak.
A javítás nem az ügynökön történt. Rátettünk egy eseménynaplót arra a néhány mezőre, amit az ügynök használt, és a jóváhagyásokhoz bekerült egy érvényességi feltétel. Ettől kezdve az ügynöknek volt mit ellenőriznie, és a következő hasonló esetnél megállt, jelezte az ellentmondást és nem döntött helyettünk.
Ennek van egy másik oldala is, amiről ritkán esik szó. Ha a rendszer eseményekben gondolkodik, akkor az ügynök saját munkája is eseménnyé válik. Utólag megnézhető, mit tett, mire hivatkozva, és melyik lépését kell visszavonni, ha tévedett. Ez a visszavonhatóság az, ami miatt egy vezetőség egyáltalán mer hatáskört adni egy gépnek.
A következő lépcső
Amikor az ügynök nem csak olvas
A bevezetések többsége olvasási joggal indul, és ez helyes sorrend. Néhány hónap után viszont mindig felmerül, hogy az ügynök írjon is a rendszerbe. Rögzítsen rendelést, módosítson határidőt, állítson elő bizonylatot. Itt derül ki igazán, mit ér a folyamat alapú felépítés.
Állapot alapú rendszerben egy géppel beírt érték semmiben nem különbözik egy embertől származótól. Ha kiderül, hogy az ügynök három napig rosszul dolgozott, nincs mód arra, hogy csak az ő munkáját szedjük vissza. Vagy kézzel keresi meg valaki az összes érintett tételt, vagy marad minden úgy, ahogy van, és a cég együtt él a hibával.
Ha viszont minden művelet esemény, akkor az ügynök bejegyzései magukon viselik, hogy tőle származnak, melyik futásából, milyen bemenet alapján. Egy rossz szabály hatása visszakereshető és egy lépésben visszavonható. Ez tette lehetővé az egyik ügyfelemnél, hogy az első éles hónapot ne kelljen kockázatnak tekinteni, mert bármikor vissza tudtunk állni.
Van ennek egy csendesebb haszna is. Az ügynökök megszakadnak és újraindulnak, ez a működésük velejárója. Egy százfős ügyviteli szolgáltatónál a folyamat egy hálózati hiba után újraindult, és ugyanazt a számlázási lépést másodszor is elvégezte volna. Azért nem lett belőle kettős számla, mert a rendszer eseményként kezelte a műveletet, és felismerte, hogy ez a lépés ezzel a hivatkozással már megtörtént. Állapot alapon ez a védelem nem létezik, mert a rendszer csak azt látja, hogy egy számla létrehozható.
A megvalósítás
Ehhez nem kell rendszert cserélni
A leggyakoribb reakció erre az, hogy akkor tehát ERP csere kell, és ezzel a téma le is kerül az asztalról három évre. Én pont az ellenkező irányt szoktam javasolni, mert az ügynök nem az egész rendszert használja.
Nézd meg, milyen adatokra fog támaszkodni az a folyamat, amit gépre bíznál. Ez általában négy vagy öt mező. Egy jóváhagyó ügynöknél a partner besorolása, a keret, a fizetési feltétel, a készlet és a szállítási határidő. Nem a teljes törzsadatot kell rendbe tenni, hanem ezt az ötöt, és ezekre kell ráépíteni az eseménynaplót.
Ez a gyakorlatban egy jól körülhatárolt fejlesztés a meglévő rendszer mellé. Minden módosítás bekerül egy külön táblába a kiváltó okkal és a hivatkozott dokumentummal együtt, és az ügynök ezt a táblát is olvassa, nem csak az aktuális értéket. Az egyik ügyfelemnél ez két hét munka volt, és utána már nem az volt a kérdés, hogy megbízunk-e az ügynökben, hanem hogy melyik folyamatot vigyük rá legközelebb.
Ha viszont a cég amúgy is rendszercsere előtt áll, akkor ez a szempont most kerüljön be a kiírásba, mert egy ERP tizenöt évig marad. Három kérdés sokat elárul a szállítóról. Megőrzi-e a rendszer a mezők korábbi értékeit lekérdezhető formában. Rögzíti-e minden változáshoz a kiváltó okot és a hivatkozott bizonylatot. Elérhető-e mindez programozottan is, nem csak a felületen keresztül egy riportban.
A tárhely kérdését szokták még felhozni ellenérvként, és ez ma már nem állja meg a helyét. Egy közepes cég teljes éves eseménynaplója a törzsadatokra néhány gigabájt, ami a mai árakon elhanyagolható tétel a rendszer üzemeltetési költségén belül. Az az érv, ami harminc éve helytálló volt, mostanra csak szokásként maradt fenn.
A harmadik kérdésnél szoktak elbizonytalanodni. Sok rendszerben létezik változásnapló, de csak a képernyőn nézhető meg, emberi szemmel. Egy ügynöknek ez semmit nem ér.
Vezetői nézőpont
Megváltozott, hogy mire vesz egy cég ERP-t
Az elmúlt évtizedekben a vállalatirányítási rendszereket azért választották, hogy az emberek gyorsabban és kevesebb hibával dolgozzanak. A felület minősége, a riportok és a bevezetés hossza döntött. Ezek a szempontok nem szűntek meg, csak mellé került egy másik.
Mostantól az is számít, hogy a gép tudjon benne dolgozni. Ez a kettő nem ugyanaz, és néha ellentétes irányba húz. Az embernek a letisztult képernyő segít, ahol egy szám látszik. Az ügynöknek pont az kell, ami a letisztult képernyő mögül kimaradt.
Egy friss nemzetközi felmérés is ugyanazt a szakadékot mutatja, amit a projekteken látok. A vezetők a stratégiájukat felkészültnek érzik az AI-ra, az adatot és az infrastruktúrát viszont jóval kevésbé. A stratégia gyorsan megírható. Az adat útjának megőrzése viszont tervezési döntés, ami évekig hat.
Ezért nem tartom szerencsésnek, amikor egy cég előbb választ ügynök platformot, és csak utána néz rá a rendszerére. A platform hat hónap alatt lecserélhető. Az a döntés, hogy a működésetek nyoma megmarad-e, sokkal tovább kísér, és minden későbbi AI beruházás értéke ezen múlik.
kdconsulting.hu · [email protected]