Koľko stojí jedna výnimka z procesu?

Proces vyzerá jednoducho, kým pri jeho opisovaní nezaznie prvé „áno, ale“. Objednávka príde, systém ju skontroluje a odošle na spracovanie. Áno, ale niekedy chýba číslo zákazky. Okrem prípadu, keď je zákazník nový. A občas to kolegyňa vyrieši ručne.

Práve v týchto vetách sa často skrýva väčšina ceny automatizácie.

Happy path je tá lacná časť #

Takzvaný happy path je ideálny priebeh: všetky údaje sú správne, systémy odpovedajú a každé rozhodnutie má jednoznačný výsledok. Takýto proces sa dobre kreslí na prezentáciu a často aj pomerne ľahko programuje.

Reálna prevádzka však neposiela iba ideálne vstupy. Prichádzajú neúplné údaje, duplicity, neznáme formáty, oneskorené odpovede aj prípady, o ktorých rozhoduje človek podľa kontextu. Automatizácia musí vedieť, čo s nimi urobiť — alebo aspoň bezpečne priznať, že to nevie.

Preto dve firmy môžu automatizovať na pohľad rovnaký proces, no dostať úplne odlišné cenové ponuky. Jedna má päť jasných pravidiel. Druhá má päť pravidiel a tridsať spôsobov, ako ich obísť.

Výnimka nie je jeden ‘if’ #

V požiadavke môže výnimka znieť nevinne: „Ak suma nesedí, upozornite účtovníčku.“ V hotovom riešení však treba zodpovedať ďalšie otázky:

• Ako systém zistí, že suma nesedí?
• Aká odchýlka je ešte prijateľná?
• Koho má upozorniť a akým kanálom?
• Čo sa stane s rozpracovaným prípadom?
• Ako sa proces obnoví po rozhodnutí človeka?
• Čo ak nikto nezareaguje?
• Kde sa uloží rozhodnutie pre budúcu kontrolu?

Z jednej podmienky vznikol malý nový proces so stavmi, oprávneniami, notifikáciami, históriou a vlastnými chybovými situáciami.

Užitočný mentálny model preto vyzerá takto:

Cena výnimky = detekcia + rozhodnutie + spracovanie + obnova + dohľad + testovanie + údržba

Nie je to vzorec na výpočet ceny v eurách. Je to zoznam miest, na ktoré sa pri hrubom odhade ľahko zabudne.

Nie každá výnimka je rovnaká #

Zásadný rozdiel je medzi technickou a biznisovou výnimkou.

Technická výnimka vznikne, keď proces vie, čo má urobiť, ale nemôže: API neodpovedá, databáza je nedostupná, platnosť prístupu vypršala alebo sa súbor nedá otvoriť. Pri dočasnom probléme môže pomôcť opakovanie operácie, neskôr však treba proces ukončiť, zapísať chybu a upozorniť zodpovednú osobu.

Biznisová výnimka nastane, keď systémy fungujú, ale chýba jednoznačné rozhodnutie: dodávateľ nie je schválený, suma prekročila limit alebo k faktúre neexistuje objednávka. Tu retry nepomôže. Potrebujeme pravidlo, ďalšie údaje alebo človeka s právomocou rozhodnúť.

Aj oficiálne odporúčania pre spracovanie chýb v Power Automate oddeľujú alternatívny priebeh, opakovanie operácie, logovanie a notifikácie. Spoľahlivosť nevzniká pridaním jednej podmienky, ale návrhom celého správania po zlyhaní.

Faktúra, ktorá prestala byť jednoduchá #

Predstavme si automatické spracovanie prijatej faktúry:

Faktúra prišla → dodávateľ existuje → objednávka existuje → suma sedí → zaúčtovať.

Potom pridajme tri výnimky.

Chýba povinný údaj #

Systém faktúru odmietne a odošle pripravenú správu. Detekcia je jednoduchá, reakcia jednoznačná a prípad nemusí čakať v internom stave. Takáto výnimka môže byť relatívne lacná.

Suma sa líši od objednávky #

Rozdiel do určitej tolerancie sa môže prijať, vyšší rozdiel musí niekto schváliť. Už potrebujeme porovnať údaje z dvoch zdrojov, evidovať stav schvaľovania, určiť schvaľovateľa, poslať mu upozornenie a spracovať jeho rozhodnutie.

Suma nesedí, ale záleží na okolnostiach #

Rozhoduje typ zákazky, rámcová zmluva, konkrétny dodávateľ a predchádzajúca komunikácia. Zdanlivo jedna výnimka si zrazu pýta prístup k ďalším systémom, nové pravidlá a možno aj používateľské rozhranie. Jej riešenie môže byť väčšie než pôvodný automatický priebeh.

Jedna výnimka teda nemá jednotkovú cenu. Stojí toľko, koľko nového sveta musí systém poznať, aby ju vedel bezpečne vyriešiť.

Najrýchlejšie rastú kombinácie #

Samotný počet výnimiek ešte nehovorí všetko. Dôležité je, či sa môžu vyskytnúť naraz a navzájom meniť výsledok.

Čo má systém urobiť, ak je dodávateľ neznámy, objednávka chýba a suma zároveň prekračuje limit? Stačí jeden spoločný manuálny front, alebo má každá situácia inú prioritu a iného schvaľovateľa? Možno sa niektoré kontroly po prvej chybe už nemajú vykonať. Možno sa, naopak, majú zhromaždiť všetky problémy a oznámiť naraz.

S každou rozhodovacou vetvou rastie počet ciest, ktoré treba implementovať a overiť. Príbuzný princíp pozná softvérové inžinierstvo ako cyklomatickú zložitosť. Metodika štruktúrovaného testovania NIST používa počet nezávislých ciest riadenia pri určovaní testov. Nie je to cenový vzorec pre firemný proces, ale dobre vysvetľuje, prečo ďalšia vetva nepridáva iba ďalší riadok kódu: pridáva aj ďalší scenár, ktorý môže zlyhať.

Dobrá automatizácia nemusí pokryť všetko #

Snaha automatizovať sto percent prípadov býva drahá a niekedy aj nebezpečná. Posledných pár neštandardných situácií môže vyžadovať neúmerne veľa pravidiel, pričom sa vyskytnú iba niekoľkokrát ročne.

Rozumné riešenie môže byť jednoduchšie:

Bežné prípady spracuje systém. Nejednoznačné prípady bezpečne zastaví, zhromaždí k nim potrebné údaje a odovzdá ich človeku.

To nie je zlyhanie automatizácie. Je to vedomé rozdelenie práce podľa toho, v čom je lacnejší a spoľahlivejší stroj a v čom človek.

Pri každej výnimke existujú tri možnosti:

1. Automatizovať ju, ak je častá, ľahko rozpoznateľná a má stabilné pravidlá.
2. Odstrániť jej príčinu, napríklad povinným poľom, kontrolou už pri vstupe alebo zjednotením formátov.
3. Odovzdať ju človeku, ak je zriedkavá, nejednoznačná alebo má vysoké riziko nesprávneho rozhodnutia.

Najlacnejšia výnimka býva často tá, ktorá po úprave procesu vôbec nevznikne.

Čo zistiť ešte pred nacenením #

Pri analýze nestačí prejsť ideálny postup. Pri každom kroku sa treba pýtať: „Čo sa tu môže stať inak?“ Potom každú odpoveď preveriť cez niekoľko praktických otázok:

Takýto zoznam je užitočnejší než tvrdenie, že proces má desať krokov. Desať priamych krokov môže byť jednoduchších než tri kroky, pri ktorých každý začína slovami „záleží od situácie“.

Najdrahšia veta je „to sa občas robí inak“ #

Cenu automatizácie neurčuje iba to, čo systém robí v bežný deň. Určuje ju najmä to, čo má urobiť v nebežný deň — a ako bezpečne sa z neho vráti späť.

Preto sa pred automatizáciou nepýtajme iba „Ako proces funguje?“, ale hlavne „Čo všetko sa môže stať inak?“ Odpovede ukážu, ktoré výnimky sa oplatí programovať, ktoré treba odstrániť zmenou procesu a ktoré je rozumnejšie nechať človeku.

Výnimka napokon stojí toľko, koľko nového rozhodovania, nových ciest a budúcej starostlivosti kvôli nej vytvoríme.

Zdroje a ďalšie čítanie #

• Microsoft Power Automate: Employ robust error handling
• NIST: Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric