Öt eset, amikor a kimutatás rossz számot mutatott — és hogyan derült ki a forrásadatból

Ez a cikk öt valós esetet mutat be egy több telephelyes kereskedő és szolgáltató cég rendszereiből, anonimizálva: mit mutatott a kimutatás, mi volt mögötte, hogyan derült ki, és milyen ellenőrzést építettünk be azóta. Ha a cégénél a riport készítése már automatizált, ez a cikk arról szól, hogy a gép is rossz számot ad, ha rossz adatot kap — és hogyan lehet ezt olcsón észrevenni. Ha még kézzel készül, a riport-réteg felépítéséről szóló cikk a kiindulópont, ez itt a folytatása.

Miért ad rossz számot a kimutatás, ha a képlet jó?

Egy kimutatás három dologból áll: a forrásadatból, a besorolásból és a számításból. A számítást mindenki ellenőrzi, mert az látszik: ha egy összeg nem stimmel, kiderül. A másik kettőt szinte senki, mert azok a rendszer mélyén vannak, és a riport nem mutatja, honnan jött a szám.

Az öt eset, amit alább végigveszünk, négy gyökérokra megy vissza. Nem ott rögzítik, ahol a riport nézi: a csapat egy másik rendszerben vagy e-mailben dolgozik, a vállalatirányítási rendszer üres marad, a mutató pedig nullát vagy töredéket mutat. Rossz kategóriába rögzítik: a munka bekerül, de olyan kóddal, amit a riport nem számol. A besorolás nem követi a változást: jön egy új termékváltozat vagy egy új státusz, és a hozzárendelési tábla csendben kihagyja. A kézi lista elcsúszik: valaki hetente frissíti a táblázatot, és egy idő után a táblázat és a valóság két külön világ.

Egyik sem képlethiba, ezért egyik sem derül ki a riport ellenőrzéséből. Csak abból derül ki, ha a riportot visszavezetjük a forrásra, és megnézzük, hogy amit a szám állít, az a forrásban is úgy van-e. Ez az, amit a legtöbb cégnél soha senki nem csinál meg, mert nincs rá idő. Az automatizált riport-réteg pont ezt teszi lehetővé: a gép minden futásnál újra tud egyeztetni.

1. eset: a havi készletleltár, ami 27 téves és 10 hiányzó tételt fogott

A készletről minden hónapban kézzel készült egy Excel: melyik tétel hol van, milyen státuszban, mennyi az értéke. A tábla gondos volt, a készítője tapasztalt, és senki nem gondolta, hogy baj lenne vele. Amikor a vállalatirányítási rendszer adatbázisából automatikusan is elkészítettük ugyanezt a leltárt három nézetben (új készlet, bemutató tételek, használt tételek), és a kettőt egymás mellé tettük, a különbség 37 tétel volt.

Huszonhét tétel a kézi listán más státuszban vagy más helyen szerepelt, mint a rendszerben. Tíz tétel a kézi listáról egyszerűen hiányzott: bent volt a rendszerben, de a táblázatból kimaradt, mert az utolsó frissítés óta érkezett, és senki nem vitte át. Egyik hiba sem volt szándékos, és egyik sem volt nagy önmagában. Együtt viszont azt jelentették, hogy a havi készletérték, amire a vezetés döntéseket alapozott, nem a valóságot mutatta.

A javítás iránya fordított volt. A leltár alapja a rendszerből generált pillanatkép lett, a kézi lista pedig ellenőrző szerepet kapott: az automata egyeztető minden hónapban felsorolja, hol tér el a két forrás, és csak az eltéréseket kell embernek megnéznie. A kézi munka az egyeztetés-listára szűkült: embernek csak az eltéréseket kell megnéznie, és mindegyiknél meg lehet nézni az okot is.

Tanulság: ahol egy kézi lista él párhuzamosan egy rendszerrel, ott a két forrás mindig elcsúszik. Nem az a kérdés, hogy elcsúszik-e, hanem hogy ki és mikor veszi észre.

2. eset: a heti partner-riport és a besorolás, ami nem követte az új típust

Egy partner felé hetente kötelező riportot kell küldeni a készletről, a partner saját Excel-sablonjában. Ez a műfaj a legcsendesebb hibaosztály otthona: ha egy tétel nem fér bele a besorolásba, nem hibaüzenet lesz belőle és nem üres sor, hanem egyszerűen nem szerepel a riportban. A fájl megérkezik, a sorösszeg stimmel, a partner dolgozik belőle.

A gyökérok egy új termékváltozat volt: a rendszerben megjelent egy új típus, a riport besorolási táblája viszont nem ismerte, ezért a hozzá tartozó tételeket nem tudta hova tenni. A javítás közben derült ki a második csapda is: a típusnevek több különböző helyre voltak beégetve, tehát egy helyen javítani kevés. Amíg nem mindegyik pont ugyanabból a besorolásból dolgozik, a riport tovább téved, csak kisebbet.

Két dolog változott utána. Egy: a besorolás egyetlen helyre került, ahonnan minden riport dolgozik, így egy új típus egy sorral felvehető. Kettő, és ez a fontosabb: a riport nem küld semmit, ha besorolatlan tételt talál. Riaszt, és megvárja, hogy valaki felvegye a hiányzó sort. Inkább ne menjen ki egy riport, mint hogy hiányos menjen ki egy partnerhez, aki abból dolgozik.

Ez az elv (inkább ne küldjön semmit, mint rosszat) azóta minden automatánkban ott van. Egy automata, amelyik mindig zöld, gyanúsabb, mint az, amelyik néha szól.

3. eset: a mutató, ami a forgalom 14,5 százalékát látta

Egy szervizterületen a vezetés egy adott munkatípus forgalmát követte: mennyi jött be belőle, hogyan alakul hónapról hónapra. A rendszerben minden munkalapnak van egy munkajelleg-kódja, és a riport erre a kódra szűrt. A számok alacsonyak voltak, de nem gyanúsan alacsonyak: nőttek, csökkentek, úgy viselkedtek, mint egy valódi mutató.

Egy részletes legyűjtésnél derült ki, hogy az érintett munkalapoknak csak 18,6 százaléka volt a „helyes” munkajelleg-kódon. A többi egy általános kódon futott, mert a munkafelvételnél az volt az alapértelmezés, és senki nem állította át. A riport tehát nem a munkatípus forgalmát mérte, hanem azt, hogy a kollégák milyen gyakran veszik a fáradságot a kód átállítására. A valódi forgalomnak nagyjából a hetedét látta: 14,5 százalékot.

Ezt a hibát semmilyen riport-ellenőrzés nem fogta volna meg, mert a riport pontosan azt számolta, amit kértek tőle. Csak úgy derült ki, hogy a munkalapokat egyesével, a teljes tételsorral együtt húztuk le, és a kódtól függetlenül néztük meg, mi van rajtuk.

A javítás két lépés: a mutató definíciója a tételsorra épül (mi van a munkalapon), nem a fejléc kódjára (minek jelölték); és a rögzítési fegyelem visszakerült a vezetéshez, mint döntés, mert azt gép nem tudja pótolni. Tanulság: egy folyamat-audit első kérdése nem az, hogy mit mér a riport, hanem hogy hol és milyen kóddal rögzítik, amit mérni akarunk.

4. és 5. eset: a státusz-szín és a partnertörzs

A hamis piros. Egy értékesítési dashboardon három szín jelezte a folyamatok állapotát: piros a lejárt határidő, sárga a mai, zöld a későbbi. A piros oszlop négy hónapon át keveset mutatott, és a vezetés ehhez igazította a beavatkozást. Amikor a definíciót a forrásrendszer kódjából olvastuk ki, kiderült, hogy a dashboard piros-feltétele nem a rendszer határidő-logikájából jött, hanem egy korábbi illesztésből, amely „a felülettel egyezett”: az eredeti rendszer képernyőjén látott színt próbálta utánozni egy saját szűrővel. Egy mintanapon három kollégánál a felület 3, 0 és 0 tételt mutatott; a valóságban 14, 9 és 15 tétel volt lejárt határidős. A teljes esetet — a definíció kiolvasását, a javítást és a jelmagyarázatot — a státusz-színekről szóló cikkünk írja le.

Tanulság: az, hogy egy illesztés a képernyővel egyezik, nem definíció. A definíciót a forrásrendszer szabályából kell kiolvasni, dokumentálni, és a dashboardon mellé írni, hogy mit jelent a szín.

A törzs. Egy kampány előkészítésénél lehúztuk a partnertörzset: 44 507 partner. Az e-mail-címek 35,7 százaléka hibás volt: elgépelt domain, hiányzó karakter, két cím egy mezőben, vagy egy helyőrző, amit valaki évekkel korábban beírt, hogy a rendszer tovább engedje. Egy kampány, amely erre a törzsre épül, minden harmadik üzenetet a semmibe küld, és a visszapattanások miatt a maradék kézbesítését is rontja.

Itt a javítás nem riport-kérdés volt, hanem törzsadat-kérdés: a hibás címek gépi szűrése, a nyilvánvaló elgépelések javítási javaslata, a helyőrzők eltávolítása, és javaslat arra, hogy a rögzítő felület ne fogadjon el érvénytelen formátumot. A tisztítás maga program, nem egyetlen lefutás: a hibaosztályok szerinti pontos bontás a tisztítás első lépésének a terméke, nem a felmérésé. A kampány-lista összeállításánál viszont már fut a formátum-ellenőrzés, így a formátumhibás címek a kiküldés előtt kiesnek. A hibaosztályokról és a tisztítási szabályokról a partnertörzs-tisztítás cikkünk szól.

Hogyan vesszük észre: négy ellenőrzés, amit minden riportba beépítünk

Az öt eset közös pontja, hogy egyiket sem a riport olvasója vette észre, hanem egy forrás-oldali ellenőrzés. Ezekből lett a négy szabály, amit azóta minden riport-automatánkba beépítünk. Egyik sem drága; a legtöbb egy plusz lekérdezés és egy feltétel.

A négy ellenőrzés sorrendje nem mindegy. A forrás-egyeztetéssel érdemes kezdeni, mert az mutatja meg, hogy egyáltalán van-e baj, és mekkora. Utána jön a besorolatlan-tétel őr, mert az a jövőbeli hibákat fogja meg, nem a meglévőket: egy új típus, egy új státusz, egy új kód bármikor érkezhet, és a riport nem tud róla. A független újraszámolás ennél drágább, mert külön kódot jelent ugyanarra a mutatóra, ezért csak a legfontosabb néhány számnál éri meg — cserébe ez az egyetlen ellenőrzés, amelyik magának a riport-logikának a hibáját is megtalálja. A riasztás tesztje pedig azért kerül a végére, mert az előző három mind riasztásra épül: ha a riasztás nem ér célba, a másik három csendben dolgozik a semmiért.

A negyedik a legkellemetlenebb, mert azt mutatja meg, hogy a „minden zöld” állapot maga is lehet hiba. Egy riasztás, amely sosem szólal meg, vagy azért nem szól, mert nincs mi miatt, vagy azért, mert el van törve. Ezt csak úgy lehet eldönteni, ha időnként szándékosan elrontunk valamit, és megnézzük, szól-e.

Ha a cégénél a riportok kézzel készülnek, ezek az ellenőrzések a gyakorlatban nem futnak, mert nincs rájuk idő: a kézi riport valódi költségéről szóló cikkben pont ez a rejtett tétel. Az automatizált riport-réteg legnagyobb haszna nem is a sebesség: az, hogy minden futásnál jut idő az egyeztetésre.

Gyakori kérdések

Miért nem a képletben van a hiba, ha rossz a riport?

Mert a képletet mindenki ellenőrzi, a forrást és a besorolást szinte senki. Az öt bemutatott esetben a számítás mindig helyes volt: a rögzítés hiányzott vagy rossz kódon történt, a besorolási tábla nem követte az új típust, vagy egy kézi lista csúszott el a rendszertől.

Hogyan derül ki, hogy egy kimutatás rossz számot mutat?

Forrás-egyeztetéssel: a riport egy sorát visszavezetjük a rendszer nyers adatáig, és megnézzük, ugyanaz-e. Egy másik jó módszer a független újraszámolás, amikor egy külön script a nyers adatból újraszámolja a fő mutatókat. Egy első forrás-egyeztetés jellemzően több eltérést is hoz — a cikkben bemutatott leltárnál egyetlen körben 37-et.

Mennyi munka egy forrás-egyeztetés bevezetése?

Egy már automatizált riportnál egy plusz lekérdezés és egy feltétel: a riport minden futásnál összeveti a két forrást, és eltérés-listát ad. Kézi riportnál a bevezetés az automatizálással együtt éri meg; a szabályok a cikk táblázatában vannak.

Mit tegyek, ha a csapat nem a vállalatirányítási rendszerben rögzít?

Először mérje meg, mekkora a rés: a munkatípus-forgalom példájában a munkalapok 18,6 százaléka volt a helyes kódon. Utána döntse el vezetőként, hogy a rögzítési fegyelem vagy a mutató definíciója változik. A mutatót a tételsorra lehet építeni a fejléc-kód helyett; a fegyelmet gép nem pótolja.

Automatizálható a riport, ha a forrásadat hibás?

Igen, de akkor a gép ugyanazt a hibát gyorsabban gyártja. Ezért az automatizált riport-réteg része a forrás-egyeztetés és a besorolatlan-tétel őr: a riport nem megy ki, ha olyan tételt talál, amit nem tud besorolni, és riaszt, ha a két forrás eltér.

Mi az első lépés, ha nem bízom a saját riportjaimban?

A cikk végén lévő öt kérdés a legfontosabb kimutatásra. Ha a válaszok nyugtalanítóak, egy folyamat-audit a három legfontosabb riportot vezeti vissza a forrásig, tételes eltérés-listával és javaslattal arra, mit érdemes automatizálni és mit rögzítési szabállyal rendezni.

A következő lépés: öt kérdés a saját riportjához

Nem kell audit ahhoz, hogy az első ellenőrzést megcsinálja. Vegye a legfontosabb heti vagy havi kimutatását, és válaszoljon öt kérdésre.

1. Honnan jön a szám? Melyik rendszerből, melyik mezőből, milyen szűrővel. Ha ezt nem tudja két mondatban leírni, a riport nem ellenőrizhető.

2. Ott rögzítik, ahol a riport nézi? Kérdezze meg azt, aki a munkát csinálja, hova írja be. Ha a válasz „hát, általában a rendszerbe, de…”, ott a rés.

3. Mi történik egy új típussal, státusszal, termékkel? Ha a válasz „valakinek fel kell vennie a táblába”, akkor a riport a következő új típusnál csendben kihagy valamit.

4. Mikor egyeztették utoljára a forrással? Ha a válasz „soha” vagy „bevezetéskor”, az első egyeztetés majdnem biztosan hoz eltéréseket — a fenti leltárnál 37 tétel volt.

5. Mikor szólt utoljára a riasztás? Ha soha, döntse el, hogy ez jó hír vagy eltört riasztás. Egy szándékos hibával öt perc alatt kideríthető.

Ha a válaszok nyugtalanítóak, ez pontosan az, amivel egy folyamat-audit kezdődik: a legfontosabb három kimutatás visszavezetése a forrásig, az eltérések tételes listája, és javaslat arra, mit érdemes automatizálni és mit érdemes rögzítési szabállyal rendezni. A folyamat és az ár az AI-audit árak oldalon van; a riport-réteg felépítéséről a riport-automatizálás szolgáltatás oldal szól. Ha csak a nagyságrend érdekli, a kalkulátor két perc.