Mi történik, ha nem működik? 6 tipikus hiba és a megoldásuk

Hiba lesz, és ezt jobb előre tudni. A kézi munka sem hibátlan: Panko 2000-ben közölt áttekintése a kézzel épített táblázatok ellenőrzéseit gyűjtötte össze, és a hibás cellák aránya a vizsgálatok többségében 1 és 2,5% között volt. A kutatás táblázatokat vizsgált, teljes üzleti folyamatokat és mai gépi munkát nem. Képzeld el a saját cégedet: hány táblázatot, kézzel átvitt adatot és kézzel írt számlát nézett át utoljára valaki figyelmesen? Ha a gép vagy ember téved, a kérdés az, hogy gyorsan kiderül-e. A hibát nem tudod teljesen kizárni, de azt elérheted, hogy gyorsan kiderüljön, és könnyen javítható legyen.

Ez a cikk 6 tipikus hibát mutat be az automatizálásnál. Mindegyiknél leírja, hogyan néz ki, és mi a javítás. Ha még nem mérted a kiinduló állapotot, kezdd a KPI cikkünkkel, hogy lásd, mihez képest romlott vagy javult az eredmény. Azt, hogy a hibák melyik szakaszban szoktak előjönni, az Így néz ki egy céges bevezetés hétről hétre cikkben írjuk le.

A 6 tipikus hiba

1. A hozzáférések késnek

Így néz ki: A szabályok készen vannak, de a CRM-hez, a számlázóhoz vagy a levelezéshez még nincs engedély, ezért a munka áll. Az engedélyezés gyakran az ügyfél oldalán akad el (informatika, jogosultságok), és az ilyen várakozás órákat visz el a projektből.

Javítás: Kérd el a hozzáféréseket már a feltárás elején. A listát mi összeállítjuk, így neked nem kell kitalálnod, mire lesz szükség.

2. A külső szoftver korlátai

Így néz ki: A szoftvernek, amellyel a folyamat dolgozik, nincs külső kapcsolódási lehetősége (API, azaz programozott hozzáférés), vagy a lehetőség korlátos: például óránként csak bizonyos számú hívást enged. Nem minden állítható át kapcsolódáson keresztül, egyes beállításokhoz a felületet kell használni. Ha nincs kapcsolódás, a rendszer a felületen át is dolgozhat, mintha ember kattintgatna, de ez törékenyebb.

Javítás: Ezt a feltáráskor megnézzük, még az építés előtt. Ez dönti el, hogyan építjük meg, és hogy kell-e erősebb hibakezelés. Az 5 kérdéses szűrő is ezzel a kérdéssel indul.

3. A gép téved

Így néz ki: Az AI rossz kategóriába sorol egy levelet, vagy félreért egy adatsort. Az AI például csak azt azonosítja, melyik oszlop mit tartalmaz, a sorokat pedig szabályalapú kód ellenőrzi, mert az mindig ugyanúgy dönt. Ha két érték ellentmond egymásnak (például a saját szabály szerinti pontszám és az AI pontszáma erősen eltér), a rendszer e-mailben emberi ellenőrzést kér.

Javítás: Ahol egy szabállyal eldönthető, ott szabály dolgozzon, az AI csak ott, ahol szükség van rá. Az elején ember hagyja jóvá az eredményt, és az AI-s döntésnél legalább egy hónap finomhangolással számolj. Hogy mikor engedheted el a jóváhagyást, azt a KPI cikkünk 6. mérőszáma mutatja.

4. A hiba észrevétlen marad

Így néz ki: Egy futás hibára fut, és senki nem tud róla. Napokkal később derül ki, hogy az érdeklődők nem kaptak választ, vagy a számlák nem mentek ki. Az a legveszélyesebb hiba, amelyet senki nem vesz észre, ezért minden hibának legyen kimenete: értesítés, napló vagy jóváhagyásra váró üzenet.

Javítás: Állíts be azonnali értesítést e-mailben vagy chaten, és építsd fel a rendszert kis, külön ellenőrizhető részekre, hogy gyorsan kiderüljön, hol akadt el. A rendszer hiba esetén is mindig választ küld annak, aki elindította a futást, így sosem marad néma. Külső AI-szolgáltatás kiesésére tartalék modellt és riasztást is érdemes tervezni.

5. Egy kivétel nincs leírva

Így néz ki: A gép a leírt szabály szerint dolgozik, de a mindennapokban előjön egy eset, amelyet senki nem mondott ki. Egy kuponrendszernél például a vásárlónak kommunikált lejárat eltért a valóditól, így a gép csak az egyik változat szerint tudott dolgozni. Szóban elmondani a feladatot kevés: az átadáshoz eredmény, mozgástér, ellenőrzés és határidő kell.

Javítás: A feltáráskor kérdezd meg a kollégáidtól, mikor tér el a szokásos menettől a folyamat. Az éles indulás első heteiben ember hagyja jóvá az eredményt, ekkor derülnek ki a kivételek, és kerülnek a szabályba. A rögzítéshez használd az egyoldalas átadási lapot.

6. Nincs gazdája a rendszernek

Így néz ki: A rendszer elkészül, de senki nem érzi a sajátjának. A hibalistát nem nézi senki, és a csapat lassan visszatér a régi módszerhez.

Javítás: Jelölj ki egy gazdát, aki hetente negyedórát átnézi, mi ment félre. Mondd el a kollégáknak, mit kapnak a rendszertől, és kérdezd meg őket, mi akasztja meg a használatot. A 10. mérőszám mutatja meg, az esetek hány százaléka megy át valóban a rendszeren.

Mi legyen a tartalék?

Már az indulás előtt döntsétek el, mi a tartalék, ha a rendszer hibázik: ki szól, és hogyan megy tovább a munka jóváhagyással vagy kézzel. Ezt 3 fokozatban érdemes megtervezni: 1) a rendszer tovább dolgozik, de minden eredményt ember hagy jóvá, 2) csak a legegyszerűbb esetek mennek a gépen, 3) átmenetileg a régi kézi menet működik, amíg a javítás tart. Kérd a fejlesztőtől, hogy ezek között gyorsan lehessen váltani.

A javítás sorrendje: először azt nézd meg, melyik szabály vagy kivétel okozta a hibát. Utána az adatot (hibás vagy hiányos volt-e) és a kapcsolatot a külső szoftverrel. A modell cseréje csak ezek után jön szóba.

Mit csinálj a héten?

A héten ezt érdemes megcsinálni:

1. Kérdezd meg a fejlesztőt, hova megy az értesítés, ha egy futás hibára fut, és ki kapja meg.
2. Írd fel a folyamat 5 leggyakoribb kivételét, és add át a fejlesztőnek a feltáráshoz.
3. Döntsd el, ki viszi tovább a munkát jóváhagyással vagy kézzel, ha a rendszer leáll.
4. Mérd le, hány hibát találsz most a kézi munkában (lásd a KPI cikket), hogy legyen mihez mérni.
5. Jelölj ki egy gazdát, és tedd be a naptárba a heti negyedórás hibaátnézést.

Források

• Panko, R. R.: Spreadsheet Errors: What We Know. What We Think We Can Do. EuSpRIG Spreadsheet Risk Symposium, 2000