Když se v informačním systému něco pokazí, bývá jedna příčina po ruce velmi rychle: chyba uživatele. Někdo zadal špatný údaj, vybral nesprávnou možnost, přehlédl upozornění, něco smazal nebo nedodržel stanovený postup. Často lze poměrně snadno určit i konkrétní okamžik, kdy k chybě došlo. Takové zjištění může být úplně správné. Samo o sobě však vysvětluje překvapivě málo.
Pokud zaměstnanec vybere nesprávný typ dokumentu a systém kvůli tomu spustí jiný proces, bezprostřední příčinu známe. Uživatel provedl jinou volbu, než měl. Z toho ale ještě nevíme, proč ji provedl. Znal správný postup? Rozuměl významu jednotlivých možností? Měl v danou chvíli potřebné informace? Pouze se přehlédl? Nebo mu systém nabídl možnost, která v dané situaci vůbec nedávala smysl?
A především: šlo o ojedinělou náhodu, nebo o chybu, která se za podobných okolností může opakovat?
Právě tady vzniká problém s výrazem „chyba uživatele“. Dobře označuje člověka, který provedl poslední chybný krok. Podstatně hůře vysvětluje řetězec okolností, které k němu vedly. Pokud se z označení viníka současně stane konec analýzy, může být přesná informace zároveň velmi pohodlnou výmluvou.
Stejná chyba může mít úplně jinou příčinu
Představme si jednoduchou situaci. Uživatel měl zvolit možnost A, ale zvolil možnost B. Z pohledu provozního záznamu se případ zdá jasný: systém provedl přesně to, co mu člověk zadal, technická závada se neprokázala a aplikace se chovala podle specifikace.
Jenže samotná volba B mohla vzniknout několika velmi odlišnými způsoby.
Člověk mohl správný postup dobře znát a jednoduše kliknout vedle. Mohl být vyrušen, pracovat ve spěchu nebo zaměnit dvě podobné položky. V takovém případě mu další vysvětlení správného postupu pravděpodobně příliš nepomůže – znal jej už před chybou.
Jindy člověk udělá přesně to, co udělat chtěl, jen špatně pochopí význam své volby. Název položky pro něj znamená něco jiného, nezná její důsledek nebo nerozumí pravidlu, podle kterého se má rozhodnout. Tady už může dávat smysl lepší vysvětlení, úprava názvu nebo školení.
A pak existuje situace, kdy uživatel správný postup zná, ale vědomě jej nedodrží. Chce si práci zjednodušit, obejít omezení nebo ušetřit několik kroků. To samozřejmě otevírá otázku jeho odpovědnosti. Pokud však stejným způsobem obchází oficiální postup půl oddělení, stojí za to zjistit také proč.
Všechny tyto případy mohou být v záznamu o incidentu popsány stejně: „uživatel zvolil nesprávnou možnost“. Přesto by bylo zvláštní reagovat na každý z nich stejným opatřením.
Stejný chybný výsledek zkrátka ještě neznamená stejnou příčinu.
Do toho vstupuje ještě jedna věc: uživatel obvykle nepracuje se systémem tak, jak mu rozumí jeho vývojář.
Vývojář zná datový model, jednotlivé stavy procesu a technický význam funkcí. Běžný uživatel většinu z toho znát nepotřebuje. Vytváří si vlastní představu podle toho, co vidí a co se naučil při předchozím používání.
Pokud tlačítko působí jako „Uložit“, očekává uložení. Pokud dvě obrazovky vypadají stejně, očekává podobné chování. A pokud se určitá operace opakovaně chovala jedním způsobem, bude stejný výsledek očekávat i příště.
Takový předpoklad může být technicky chybný a z pohledu uživatele současně zcela logický.
To se výrazně projevuje u systémů, které vznikaly postupně. Jedna část aplikace je starší, další přibyla později a jinou vytvořil odlišný tým nebo dodavatel. Jednotlivé části pak mohou používat jinou logiku a stejné pojmy nemusí mít všude totožný význam. Uživatel udělá chybu právě proto, že správně použije zkušenost, kterou ho naučila jiná část stejného systému.
Z provozního pohledu opět provedl nesprávnou volbu. Při hlubší analýze však může jít o problém konzistence návrhu.
Člověk někdy rozhoduje o něčem, o čem rozhodovat nemusí
Ještě zajímavější situace nastává ve chvíli, kdy informační systém přenese na uživatele rozhodnutí, které dokáže spolehlivě odvodit sám.
V některých procesech například člověk ručně vybírá technickou kategorii, přestože aplikace už zná všechny údaje potřebné k jejímu určení. Uživatel tak dostane další políčko, další povinnost a další příležitost udělat chybu, aniž by do rozhodnutí přinášel vlastní úsudek nebo informaci, kterou systém nemá.
Dokud všichni vybírají správně, problém zůstává skrytý. Jednou se však někdo splete, následuje vysvětlení správného postupu, připomene se metodika a možná přibude další snímek do školící prezentace. Za nějakou dobu udělá stejnou chybu někdo jiný a celý postup se zopakuje.
Organizace tak může dlouhodobě školit lidi, aby správně prováděli rozhodnutí, které původně vůbec nemuselo být lidským rozhodnutím.
Podobně je tomu u kontrol. Má-li systém k dispozici údaj A i údaj B a z jejich kombinace dokáže podle jednoznačného pravidla určit, zda je vše v pořádku, nemusí být vždy rozumné ponechávat kontrolu výhradně na člověku. Ten musí pokaždé oba údaje porovnat a vzpomenout si, co má následovat. Aplikace přitom může stejnou kontrolu provádět konzistentně a bez závislosti na momentální pozornosti uživatele.
To samozřejmě neznamená, že má být automatizováno všechno. V řadě situací potřebujeme lidský úsudek právě proto, že rozhodnutí závisí na významu, kontextu nebo okolnostech, které systém nezná. Člověk může rozpoznat výjimku, již žádné jednoduché pravidlo nepokryje.
Tam, kde však existuje jednoznačný správný výsledek odvoditelný z údajů, které už systém má, stojí za to položit otázku: proč má správnost takového kroku dlouhodobě záviset především na lidské pozornosti?
Opakující se chyby ukazují na systém i proces
Každý někdy klikne jinam, než chtěl. Jeden incident proto sám o sobě o kvalitě návrhu systému mnoho nevypovídá. Mnohem zajímavější jsou opakující se vzorce.
Pokud jeden nový zaměstnanec nemůže najít určitou funkci, mohl ji jednoduše přehlédnout. Pokud ji pravidelně hledají různí noví zaměstnanci, máme už jinou informaci. Podobně je tomu s nesprávným vyplňováním údajů. Jeden člověk mohl špatně pochopit návod. Jestli stejnou položku dlouhodobě vyplňují obdobně chybně různí lidé, stojí za to podívat se také na samotnou položku.
Možná má nejasný název. Možná se stejný pojem v organizaci používá ve více významech. Nebo uživatel v okamžiku vyplňování ještě potřebnou informaci vůbec nemá.
Samotný počet chyb samozřejmě nestačí. Důležitá je jejich četnost vzhledem k počtu prováděných úkonů, okolnosti, za kterých vznikají, i to, zda se stejný problém objevuje u různých uživatelů. Právě opakování za podobných podmínek oslabuje vysvětlení založené pouze na individuální nepozornosti.
Příčina přitom nemusí ležet přímo v aplikaci. Celá skupina mohla dostat nekvalitní školení, interní předpis může obsahovat nejasné pravidlo nebo si lidé mezi sebou předávají nesprávný pracovní návyk. Opakování chyby tedy automaticky neukazuje na dodavatele systému. Ukazuje především na potřebu zjistit, co mají jednotlivé případy společného.
Podobně zajímavé jsou obezličky, které si uživatelé kolem informačních systémů vytvářejí. Pomocný Excel. Papírek vedle monitoru. Vlastní seznam rozpracovaných případů. Tabulka, do které si oddělení přepisuje údaje z hlavního systému.
Z pohledu formálního procesu mohou být podobné nástroje problematické. Vzniká duplicitní evidence, informace se mohou rozcházet a část práce se přesouvá mimo kontrolované prostředí.
Ještě před jejich zákazem bych se ale podíval na důvod, proč vznikly.
Pokud si pracovník vede vlastní seznam rozpracovaných případů, přestože všechny existují v oficiálním systému, může jít o osobní zvyk. Stejně tak to ale může znamenat, že mu systém neumí jednoduše ukázat věci, které potřebuje každé ráno vidět. Jestli si zaměstnanci na papír zapisují pořadí několika kroků, možná si nepamatují školení. Možná je však proces natolik složitý, že bez podobné pomůcky při méně častém použití tápou.
Pomocná evidence tak může být sama problémem a současně stopou vedoucí k problému někde jinde. Způsob, jakým lidé systém obcházejí, často ukazuje, co jim v něm chybí.
A někdy problém nevzniká ani v rozhraní, ani v používání systému. Vznikl už v procesu, který informační systém pouze převzal.
Pokud organizace vyžaduje, aby člověk zadával stejný údaj do několika různých aplikací, roste riziko, že se hodnoty časem rozejdou. Pokud proces vyžaduje ruční přepis kódu mezi odděleními, vytváří tím další příležitost k omylu. A jestli pracovník musí na základě řady okolností ručně volit jeden z mnoha stavů, může být skutečný problém podstatně hlubší než kvalita rozbalovací nabídky.
Informační systém může velmi přesně digitalizovat i proces, který vytvářel chyby už před digitalizací.
Při opakovaných chybách proto nestačí zkoumat pouze to, co uživatel vidí na obrazovce. Stojí za to ptát se také, proč daný krok vůbec provádí. Někdy je nejlepší úpravou chybového místa jeho úplné odstranění.
Cenné jsou přitom nejen incidenty, při kterých už vznikla škoda. Zajímat by nás měly i situace, kdy se člověk spletl a nic vážného se nestalo. Vybral nesprávného adresáta, ale všiml si toho před odesláním. Zadal chybný údaj a před dokončením jej opravil. Spustil nesprávnou operaci a dokázal ji okamžitě vrátit.
Takové případy se do evidence incidentů často vůbec nedostanou právě proto, že jejich konečný výsledek byl správný. Přesto ukazují místa, kde problém vzniknout mohl.
Pokud různí lidé opakovaně udělají stejnou chybu a pokaždé ji včas zachytí, dostáváme důležitou informaci ještě předtím, než se stejný omyl jednou spojí s méně příznivými okolnostmi.
Školení, kontroly a prevence nejsou vždy správná odpověď
Po uživatelské chybě se velmi často objeví návrh na školení. Je to logická reakce: pokud člověk něco neví, má se to naučit. Další školení ale dává smysl především tehdy, když skutečnou příčinou problému opravdu byla chybějící znalost.
Pokud zaměstnanec jednou za čas provádí složitý proces s řadou kroků a výjimek, můžeme po něm požadovat, aby si vše pamatoval, a pravidelně jej školit. Můžeme také vytvořit rozsáhlou metodiku, ke které se bude před každým použitím vracet. U odborně složitých činností to někdy jinak nejde.
Jindy však pouze přenášíme složitost systému do hlavy jeho uživatele a následně ji řešíme stále propracovanějšími návody.
Časem může vzniknout pozoruhodný řetězec. Systém má určitý nedostatek. Kvůli němu vznikne složitější pracovní postup. K postupu přibude metodika, k metodice školení a na základě opakujících se chyb další doplňující instrukce. Původní slabé místo přitom zůstává stejné.
Takový stav může být racionální, pokud by technická úprava byla nepřiměřeně nákladná nebo by přinesla jiné problémy. Mělo by však jít o vědomé rozhodnutí po porovnání nákladů a přínosů. Lidská práce, opakovaná školení, řešení incidentů a čas věnovaný složitým postupům mají také svou cenu, jen bývá rozložena do mnoha drobných položek.
Podobně opatrně je vhodné zacházet s přidáváním dalších potvrzení a upozornění. Po incidentu je lákavé vložit před problematický krok dialog s otázkou, zda uživatel skutečně chce pokračovat. Pokud to nestačí, přidá se další potvrzení nebo povinné zaškrtnutí, že si něco přečetl.
Jednotlivě vypadají tyto pojistky rozumně. Při každodenním používání však mohou ztrácet svou sílu. Jestli člověk opakovaně potvrzuje upozornění, která se téměř vždy týkají správného a očekávaného úkonu, naučí se je vnímat jako další krok na cestě k cíli. Ve chvíli, kdy se mezi nimi jednou objeví skutečně důležité varování, může s ním naložit úplně stejně.
Samotná existence potvrzovacího dialogu proto ještě nevytváří účinnou kontrolu. Větší smysl dává přizpůsobit sílu ochrany možnému následku. Opravitelný překlep zaslouží jiný přístup než nevratný zásah do dat. Odeslání konceptu kolegovi představuje jiné riziko než zveřejnění informace. Změna vlastního uživatelského nastavení má jiné důsledky než zásah do prostředí celé organizace.
A někdy je vhodnější chybu nezakázat, ale umožnit ji snadno napravit.
Koš u odstraněných souborů je jednoduchý příklad. Místo toho, aby uživatel každé jednotlivé odstranění několikrát potvrzoval, lze vytvořit mezistav, ze kterého je možné položku po určitou dobu obnovit. Jinde lze odložit odeslání, uchovávat předchozí verze, umožnit návrat poslední operace nebo před definitivním krokem zobrazit jasný náhled výsledku.
Člověk pak stále může udělat chybu, ale její cena bude výrazně nižší.
Od lidí někdy vyžadujeme prakticky bezchybný výkon i tam, kde bychom mohli místo dalšího omezení snížit následky běžného omylu. Rozumně navržený systém nemusí zabránit každému chybnému kliknutí. Měl by však rozlišovat mezi chybou, kterou lze bez problémů vrátit, a chybou s vážným nebo nevratným následkem.
Čím závažnější může být následek běžného omylu, tím větší smysl má přemýšlet nejen o tom, jak mu zabránit, ale také jak jej zachytit a omezit jeho dopady.
Odpovědnost uživatele se tím neztrácí
Z podobných úvah lze snadno dojít k opačnému extrému a každou chybu člověka přenést na systém, proces nebo organizaci. Takový přístup by dával stejně málo smyslu jako automatické ukončení analýzy větou „chyba uživatele“.
Uživatel může pravidlo znát, rozumět jeho významu a vědomě je porušit. Může ignorovat jasné upozornění, obejít bezpečnostní mechanismus nebo pracovat způsobem, o kterém dobře ví, že vytváří riziko. Za svoji práci samozřejmě odpovídá.
Důležité je oddělit dvě otázky, které spolu souvisejí, ale nejsou totožné.
První zní: Kdo odpovídá za konkrétní jednání?
Druhá: Co můžeme změnit, aby se stejná situace opakovala méně často nebo měla menší následky?
Odpověď může být u každé otázky jiná. Zaměstnanec mohl udělat zjevnou chybu a nést za ni odpovědnost. Současně může být rozumné upravit oprávnění, pracovní postup nebo aplikaci, protože tím snížíme pravděpodobnost stejného problému u dalšího člověka.
Jedno druhé neruší. Bezpečnostní pás také nepřesouvá odpovědnost za řízení automobilu z řidiče na výrobce. Pouze počítá s tím, že i při odpovědném chování mohou vzniknout chyby a nehody, a omezuje jejich následky.
Podobně by měl informační systém počítat s běžnými vlastnostmi lidí, kteří jej používají. Pozornost kolísá, člověk se někdy přehlédne, něco špatně pochopí nebo jedná podle zkušenosti, která v nové situaci neplatí.
Otázka odpovědnosti za konkrétní případ proto sama o sobě neřeší otázku, zda mohl být systém nebo proces navržen lépe.
Co tedy znamená „chyba uživatele“?
Po každém překlepu samozřejmě nemá smysl provádět rozsáhlou analýzu příčin. Lidé se budou plést a snaha odstranit i zcela ojedinělé drobné chyby může stát podstatně více než jejich následky.
U závažného nebo opakujícího se problému bych ale u věty „chyba uživatele“ nekončil.
Zajímal by mě rozdíl mezi tím, co člověk udělal, a tím, co si v danou chvíli myslel, že dělá. Znal správný postup? Rozuměl významu své volby? Mohl předvídat její důsledek? Dělají podobnou chybu i další lidé? Vytvářejí si kolem procesu vlastní pomůcky? Dokáže systém chybu rozpoznat z údajů, které už má? Lze výsledek snadno vrátit? A odpovídá případná pojistka skutečné závažnosti rizika?
Teprve potom lze zvolit rozumnou nápravu.
Někdy jí bude školení. Jindy změna názvu nebo uspořádání obrazovky, automatická kontrola, jiné oprávnění, možnost návratu nebo úprava pracovního postupu. A někdy skutečně nebude potřeba dělat vůbec nic: člověk jednou udělal běžnou chybu, její dopad byl malý a další pojistka by vytvářela více problémů, než kolik by jich vyřešila.
I to je správný výsledek analýzy. Rozdíl spočívá v tom, že jsme k němu došli po zhodnocení problému, nikoli automaticky ve chvíli, kdy jsme zjistili, kdo klikl jako poslední.
„Chyba uživatele“ tedy může přesně popsat, co se stalo. Jako vysvětlení získává skutečnou hodnotu teprve ve chvíli, kdy rozumíme také tomu, proč se to stalo.
Dobře navržený informační systém nemusí zabránit každému lidskému pochybení. Je však rozumné navrhovat jej s vědomím, že lidé občas něco přehlédnou, špatně pochopí nebo udělají jinak, než zamýšleli.
Podstatné není pouze to, zda uživatel udělá chybu. Podstatné je také to, zda z ní systém udělá drobnou, snadno napravitelnou nepříjemnost, nebo skutečný problém.