Práve samozrejmé pravidlá treba spresniť

Najnebezpečnejšie podmienky bývajú tie, ktorým každý rozumie.

„Keď budú všetky úlohy hotové, upozorni vlastníka procesu.“

Na porade táto veta nepotrebuje vysvetlenie. Každý približne vie, čo znamená „všetky“, čo znamená „hotové“ aj koho treba upozorniť. Práve preto pôsobí ako požiadavka, ktorú možno bez veľkého rozmýšľania premeniť na niekoľko riadkov kódu.

Lenže softvér nepracuje s tým, čo veta „približne znamená“. Potrebuje presne vedieť, ktoré úlohy sa počítajú, ku ktorej verzii procesu patria, koho zodpovednosť je rozhodujúca, ktoré stavy znamenajú koniec a čo sa má stať, ak sa už dokončená úloha znovu otvorí.

Z jednoduchej notifikácie sa tak stal dobrý príklad podmienky, ktorá bola zrozumiteľná dovtedy, kým ju nebolo potrebné definovať presne.

„Všetky“ je množina, ktorú treba najprv definovať #

Aplikácia pracuje s procesným záznamom, ku ktorému vznikajú úlohy pre viacerých používateľov. Zároveň podporuje revízie: ak sa počas procesu zmenia požiadavky, vznikne nová revízia a nové úlohy patria už k nej.

To okamžite mení význam slova „všetky“.

Úlohy zo starej revízie síce zostávajú v histórii, ale nemajú ovplyvňovať rozhodovanie o aktuálnom stave práce. Pri vytvorení novej revízie sa rozpracované úlohy predchádzajúcej revízie systémovo uzavrú a nová revízia dostane vlastnú množinu úloh.

Kontrola preto nemôže jednoducho prehľadávať všetky úlohy patriace k procesnému záznamu. Musí pracovať iba s úlohami aktuálnej revízie.

To je prvé spresnenie vety, ktorej predtým „každý rozumel“.

Ani „všetky úlohy“ neznamenali všetky úlohy #

Účel notifikácie bol konkrétny: vlastník procesu mal dostať správu vo chvíli, keď už nečakal na prácu ostatných a mohol pokračovať ďalším krokom.

Úlohy, za ktoré zodpovedal samotný vlastník procesu, sa preto do tejto podmienky nemali započítavať.

To je podstatný rozdiel.

Systém nemal zisťovať:

Sú hotové všetky úlohy?

Mal zisťovať:

Zostala ešte otvorená úloha, za ktorú zodpovedá niekto iný než vlastník procesu?

Tieto dve otázky znejú podobne, ale nie sú totožné.

Proces mohol stále obsahovať otvorené úlohy vlastníka a notifikácia bola napriek tomu správna. Jej význam totiž nebol „celý proces je hotový“, ale „už nečakáš na ostatných“.

Zodpovedná osoba nie je to isté ako riešiteľ #

Ďalšie spresnenie vyplynulo zo samotného modelu úloh.

Jedna úloha mala jedného zodpovedného používateľa, ale mohla mať viacerých riešiteľov. Vlastník procesu teda mohol byť na úlohe uvedený ako jeden z riešiteľov, hoci za jej dokončenie zodpovedal niekto iný.

Ak by sa pravidlo pozeralo iba na zoznam účastníkov, mohlo by takúto úlohu nesprávne vyradiť.

Rozhodujúca preto nebola otázka „pracuje na tejto úlohe aj vlastník?“, ale „kto za túto úlohu zodpovedá?“.

Ak bol vlastník iba riešiteľom a zodpovedal iný používateľ, úloha sa stále počítala.

Aj toto je typická vlastnosť zdanlivo samozrejmých pravidiel: prirodzený jazyk používa slová ako „moja úloha“, „jeho úloha“ alebo „robí na nej“, ale dátový model musí presne rozlišovať medzi účasťou a zodpovednosťou.

„Hotová“ tiež nie je jeden stav #

Potom prišlo slovo „hotové“.

Bežným koncovým stavom bola úspešne dokončená úloha. Proces však poznal aj situáciu, keď používateľ úlohu vedome zamietol.

Výsledok je z businessového pohľadu odlišný, ale z pohľadu čakania majú obe situácie spoločnú vlastnosť: úloha už nevyžaduje ďalšie spracovanie.

Kontrola preto nemohla byť postavená na jednoduchej podmienke:

stav = dokončená

Musela pracovať s významom stavov:

úloha už nie je aktívna

Zároveň existoval aj stav systémového uzavretia. Ten vznikal napríklad pri vytvorení novej revízie, keď staré rozpracované úlohy už nemali pokračovať.

Takéto uzavretie však neznamená, že používateľ svoju prácu dokončil. Znamená iba to, že úloha stratila význam v novom kontexte procesu.

Preto nebolo možné všetky koncové stavy automaticky považovať za ekvivalentné.

Stav úlohy sám o sebe nestačil. Dôležité bolo aj to, prečo sa doň úloha dostala a ku ktorej revízii patrila.

Aj nula otvorených úloh môže byť nesprávny výsledok #

Potom sa objavil prípad, ktorý je technicky nenápadný, ale veľmi dobre ukazuje rozdiel medzi logikou programu a významom procesu.

Predstavme si, že vlastník nemá v aktuálnej revízii žiadnu úlohu, za ktorú by zodpovedal niekto iný.

Počet otvorených relevantných úloh je nula.

Formálne by sa dalo povedať, že všetky relevantné úlohy sú dokončené. Veď neexistuje žiadna, ktorá by dokončená nebola.

Lenže e-mail s informáciou, že „ostatní dokončili svoju prácu“, by bol nezmyselný. Žiadna práca ostatných totiž neexistovala.

Do pravidla preto patrila ďalšia podmienka: musí existovať aspoň jedna relevantná úloha.

Je to malý detail, ale veľmi dobrý príklad toho, prečo matematicky pravdivá podmienka nemusí byť businessovo pravdivou informáciou.

Stav nestačí. Dôležitá je aj udalosť #

Ani presná definícia množiny a koncových stavov ešte nestačila.

Bolo potrebné rozhodnúť, kedy sa má podmienka vyhodnotiť.

Jednou možnosťou by bolo pravidelne kontrolovať databázu a hľadať procesy, pri ktorých už sú všetky relevantné úlohy dokončené. Bez ďalšej evidencie by však systém mohol posielať tú istú správu opakovane.

V tomto prípade dávalo väčší zmysel kontrolovať podmienku pri skutočnom prechode úlohy do relevantného koncového stavu.

Keď sa úloha uzavrela, systém sa pozrel na všetky relevantné úlohy aktuálnej revízie. Ak už nezostala žiadna otvorená, vlastník dostal notifikáciu.

Aj tu však bolo treba odlíšiť používateľskú udalosť od technickej.

Ak úlohu automaticky uzavrel systém napríklad kvôli vzniku novej revízie, nešlo o okamih, keď niekto dokončil svoju prácu. Takáto zmena preto nemala spustiť rovnakú notifikáciu.

Opäť sa ukázalo, že samotný výsledný stav nestačí. Význam mala aj cesta, ktorou k nemu systém dospel.

„Hotovo“ nemusí zostať hotovo #

Pri procesoch navyše neplatí, že raz splnená podmienka zostane navždy pravdivá.

Dokončená úloha môže byť znovu otvorená. Neskôr môže vzniknúť ďalšia relevantná úloha.

V tom okamihu už veta „ostatní majú všetko hotové“ opäť neplatí.

Ak sa následne posledná otvorená úloha znovu uzavrie, notifikácia má opäť význam.

Preto nebolo vhodné uvažovať o stave typu:

all_tasks_completed = true

ako o jednorazovom a definitívnom príznaku procesu.

„Všetko je hotové“ je odvodená vlastnosť aktuálneho stavu dát. Môže byť chvíľu pravdivá, potom nepravdivá a neskôr znovu pravdivá.

To je ďalší dôvod, prečo sa podobné businessové skratky oplatí chápať ako pravidlá, nie ako jednoduché uložené flagy.

Z jednej vety vzniklo presné pravidlo #

Po odstránení konkrétnych názvov stavov a entít sa výsledná logika dá zhrnúť približne takto:

relevantné úlohy =
    úlohy aktuálnej revízie
    za ktoré zodpovedá niekto iný než vlastník procesu

práca ostatných je dokončená =
    existuje aspoň jedna relevantná úloha
    a každá relevantná úloha je v prípustnom koncovom stave

notifikovať vlastníka =
    úloha práve reálne prešla do relevantného koncového stavu
    a práca ostatných je dokončená
    a samotný proces už nie je uzavretý alebo zamietnutý

Až teraz je pôvodná požiadavka dostatočne presná na implementáciu a testovanie.

Pritom businessové zadanie sa nezmenilo.

Stále ide o vetu:

Keď budú všetci ostatní hotoví, upozorni vlastníka.

Rozdiel je iba v tom, že význam slov „všetci“, „hotoví“ a „keď“ už nie je ponechaný na intuíciu.

Synchronizácia procesu je business logika #

Podobné pravidlo nie je špecifické pre jednu aplikáciu.

Objaví sa všade, kde paralelne prebieha viac činností a ďalší krok závisí od ich dokončenia: pri schvaľovaní objednávok, onboardingu zamestnanca, príprave výroby, kontrole dokumentácie alebo spracovaní reklamácie.

Aj štandard BPMN 2.0 pracuje so synchronizáciou paralelných vetiev ako s explicitnou súčasťou procesného modelu. Napríklad paralelná brána nepokračuje podľa intuitívneho pocitu, že „už je asi všetko hotové“, ale podľa presne definovanej sémantiky čaká na príslušné vstupné vetvy.

V podnikovej aplikácii býva problém ešte zložitejší, pretože množina činností nemusí byť statická. Úlohy pribúdajú, menia revíziu, zanikajú alebo sa opätovne otvárajú.

Preto je často nebezpečné ukladať výsledok podobného pravidla ako jednoduchý príznak a neskôr mu slepo veriť. Spoľahlivejšie je mať presne definovaný význam podmienky a podľa potreby ho odvodzovať z aktuálnych dát.

Najťažšie bývajú práve samozrejmé vety #

Samotná databázová kontrola, či zostala otvorená relevantná úloha, nie je technicky mimoriadne zložitá.

Ťažšie bolo rozhodnúť, čo je relevantná úloha, čo znamená koncový stav, koho zodpovednosť sa sleduje a pri akej udalosti má výsledok význam.

A práve preto sú podmienky, ktorým „každý rozumie“, často nebezpečné.

Nikto sa pri nich prirodzene nepýta na definície. Pôsobia dostatočne jasne na to, aby sa rovno implementovali.

Softvér však nakoniec donúti všetky nevyslovené predpoklady pomenovať.

„Všetky úlohy sú hotové“ preto nie je jedna podmienka.

Je to skratka pre celé business pravidlo. A kód by mal vzniknúť až vtedy, keď je jasné, čo táto skratka naozaj znamená.

Zdroje a ďalšie čítanie #

• Object Management Group: Business Process Model and Notation (BPMN), Version 2.0.2