Kedy má systém používateľa zastaviť a kedy iba upozorniť

Používateľ chce pokračovať. Systém mu oznámi, že podmienka nie je splnená, a operáciu zablokuje. Technicky všetko funguje presne podľa zadania — lenže používateľ má v tomto konkrétnom prípade dobrý dôvod pokračovať.

Práve tu sa ukazuje rozdiel medzi systémom, ktorý iba mechanicky presadzuje pravidlá, a systémom, ktorý rozumne podporuje reálny proces. Nie každá odchýlka je chyba a nie každé „malo by byť splnené“ znamená „bezpodmienečne zakázať pokračovanie“.

Pri návrhu procesnej aplikácie preto nestačí rozhodnúť, čo sa má kontrolovať. Rovnako dôležité je rozhodnúť, čo má systém urobiť, keď kontrola neprejde.

Jedna validácia, dva úplne odlišné významy #

V aplikácii sa pred niektorými operáciami kontrolovalo viacero podmienok. Na technickej úrovni vyzerali podobne: systém zistí aktuálny stav, porovná ho s očakávaným a rozhodne, či podmienka platí.

Podstatný rozdiel však nebol v kóde, ale vo význame pravidla.

Prvá skupina podmienok hovorila v podstate toto: ak pravidlo neplatí, operácia by vytvorila stav, ktorý systém nesmie pripustiť.

Druhá skupina hovorila niečo iné: za normálnych okolností by pravidlo platiť malo, ale v reálnej prevádzke môže existovať legitímny dôvod pokračovať aj bez neho.

Ak systém tieto dve situácie nerozlišuje, veľmi ľahko vznikne zdanlivo dôsledná aplikácia, ktorá však nezodpovedá tomu, ako proces skutočne funguje.

Rozlíšenie medzi hard stop a soft stop nie je nič neobvyklé. Napríklad Infor Workforce Management používa rovnaké pojmy pri validačných pravidlách: hard stop transakciu nepovolí, zatiaľ čo soft stop zobrazí upozornenie a po jeho potvrdení môže používateľ pokračovať.

Kedy je blokácia správna #

Blokujúca validácia dáva zmysel tam, kde systém vie s dostatočnou istotou povedať, že pokračovanie je neprípustné.

Typickým príkladom môže byť pokus o prechod do stavu, ktorý z aktuálneho stavu vôbec nie je dovolený. Podobne môže ísť o operáciu bez povinného referenčného záznamu alebo o situáciu, pri ktorej by pokračovanie vytvorilo vnútorný rozpor v dátach.

V takom prípade nie je úlohou systému upozorniť používateľa na riziko. Jeho úlohou je chrániť konzistenciu procesu.

Tlačidlo „Aj tak pokračovať“ by tu nedávalo zmysel. Používateľ totiž nemá robiť rozhodnutie, či chce vytvoriť neplatný stav.

Nie každé procesné pravidlo je absolútne #

Inak vyzerajú podmienky, ktoré opisujú očakávaný priebeh procesu.

Niečo malo byť dokončené. Určitá informácia mala byť k dispozícii. Predchádzajúci krok mal za normálnych okolností prebehnúť. Systém však nemusí vedieť všetko, čo vie človek, ktorý konkrétnu situáciu rieši.

Práve tu môže byť hard blokácia príliš silná.

Ak sa legitímna výnimka vyskytne raz za niekoľko týždňov, aplikácia stále musí vedieť, čo s ňou urobiť. Používateľ sa vtedy nesmie dostať do situácie, keď správny pracovný postup existuje, ale systém mu ho zakazuje len preto, že jeho dátový model nedokáže zachytiť celý kontext reality.

Výsledkom potom často nie je dokonalejší proces. Operácia sa odloží, začne sa riešiť mimo systému, používateľ sa obráti na administrátora alebo sa nájde spôsob, ako formálne splniť kontrolu bez toho, aby dáta lepšie opisovali skutočnosť.

Výskum hard-stop mechanizmov v zdravotníckych informačných systémoch ukazuje rovnaký základný problém vo výrazne kritickejšom prostredí: prísne blokácie môžu byť veľmi účinné, ale pri nevhodnom použití boli pozorované aj obchádzanie blokovaného workflow a oneskorenia. Autori systematického prehľadu preto odporúčajú hard stopy používať uvážene.

Nejde o to prenášať pravidlá zo zdravotníctva do podnikovej aplikácie. Zaujímavý je všeobecný princíp: čím silnejší zásah systému do rozhodovania používateľa, tým presnejšie musí byť definované, kedy je tento zásah oprávnený.

Soft stop nemá znamenať obyčajné „OK“ #

Druhá možnosť preto nebola odstrániť validáciu. Kontrola zostala, zmenil sa však jej výsledok.

Ak nebola splnená podmienka, ktorú bolo možné v odôvodnenom prípade prekročiť, systém používateľovi ukázal, čo presne chýba a aký je skutočný stav. Namiesto slepého zákazu dostal možnosť rozhodnúť sa, či operáciu zruší alebo vedome pokračuje napriek upozorneniu.

To je podstatný rozdiel oproti bežnému informačnému dialógu.

Dobrý soft stop nemá hovoriť iba:

„Podmienka nie je splnená. Pokračovať?“

Používateľ potrebuje vedieť, ktorá podmienka zlyhala, aký stav systém očakával, aký stav zistil a čo znamená pokračovanie.

Potvrdenie potom nie je kliknutie potrebné na odstránenie prekážajúceho okna. Je to súčasť rozhodnutia.

Ani upozornení nesmie byť priveľa #

Z toho však nevyplýva, že všetky blokácie treba nahradiť upozorneniami.

Aj upozornenie má svoju cenu. Preruší prácu a žiada od používateľa pozornosť. Ak sa objavuje často a väčšinou po ňom stačí kliknúť na „Pokračovať“, používateľ sa naučí robiť presne to.

Výskum používateľského správania pri bezpečnostných upozorneniach ukázal, že opakované vystavovanie rovnakým varovaniam vedie k habituácii: pozornosť používateľov k nim postupne klesá.

Pre procesnú aplikáciu z toho vyplýva ešte tretia kategória. Niektoré podmienky nemajú byť ani hard stop, ani soft stop. Ak používateľ v danej chvíli nepotrebuje reagovať, môže byť vhodnejšia nenápadná informácia — alebo žiadne upozornenie.

Cieľom nie je maximalizovať počet kontrolných dialógov. Cieľom je, aby používateľ spozornel práve vtedy, keď na jeho rozhodnutí skutočne záleží.

Výnimka musí zostať dohľadateľná #

Možnosť pokračovať napriek nesplnenej podmienke zároveň nesmie znamenať, že systém nad situáciou stratí kontrolu.

Ak používateľ vedome prekročí kontrolné pravidlo, táto informácia je sama osebe súčasťou procesu.

V histórii preto môže zostať zaznamenané, kto pokračoval, kedy sa tak stalo, ktorá podmienka nebola splnená, aký bol v danom okamihu skutočný stav a prípadne aký dôvod používateľ uviedol.

Audit potom neodpovedá iba na otázku „čo sa stalo“, ale aj na dôležitejšiu otázku: vedel systém o odchýlke a kto rozhodol, že sa napriek nej pokračuje?

Takýto spôsob evidencie zodpovedá aj všeobecným princípom auditných záznamov. NIST pri obsahu auditného záznamu uvádza okrem typu a času udalosti aj jej výsledok a identitu subjektu spojeného s udalosťou. Audit trail definuje ako chronologický záznam umožňujúci spätne rekonštruovať priebeh udalostí.

Rozhodnutie nie je technické #

Pri návrhu validačného pravidla sa preto osvedčuje nezačínať otázkou, ako sa zobrazí chybová hláška. Najprv treba rozhodnúť, čo pravidlo v procese vlastne znamená.

Výsledná implementácia tak nerozdeľovala kontroly podľa toho, ako ľahko sa dajú naprogramovať, ale podľa dôsledku ich porušenia.

Kritické pravidlo chránilo systém a operáciu zastavilo. Kontrolné pravidlo upozornilo na odchýlku, ale nechalo konečné rozhodnutie človeku a toto rozhodnutie zachovalo v histórii.

To je malý rozdiel v používateľskom rozhraní, ale pomerne zásadný rozdiel v návrhu procesu.

Systém nemá rozhodovať tam, kde nemá dosť informácií #

Pri digitalizácii je lákavé premeniť každé slovné „musí“ z procesného popisu na podmienku v kóde. Tak vzniká pocit, že systém zabezpečí dodržiavanie procesu.

V skutočnosti treba pri každom takom pravidle položiť ešte jednu otázku: je toto skutočne absolútne pravidlo, alebo iba očakávaný normálny stav?

Ak je pokračovanie objektívne neplatné, systém má používateľa zastaviť.

Ak však rozhodnutie závisí od okolností, ktoré aplikácia nedokáže úplne poznať, môže byť lepšie odchýlku jasne pomenovať, vyžiadať vedomé rozhodnutie a zaznamenať ho.

Dobrý procesný systém totiž nemá iba presadzovať pravidlá. Má vedieť aj to, ktoré rozhodnutia patria systému a ktoré ešte stále človeku.

Zdroje a ďalšie čítanie #

• Infor Workforce Management: Shift Edit Validation callout
• Powers et al.: Efficacy and unintended consequences of hard-stop alerts in electronic health record systems: a systematic review
• Vance et al.: Your memory is working against you: How eye tracking and memory explain habituation to security warnings
• NIST: SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems and Organizations
• NIST Computer Security Resource Center: Audit trail