Kedy sa v banke oplatí workflow engine a kedy stačí stavový stĺpec

Pred založením Sibo Consulting v roku 2017 som pracoval na IT projektoch pre banky a finančné inštitúcie na Slovensku a v Nemecku. Procesy ako otváranie účtov, firemné úvery či vymáhanie pohľadávok som videl bežať na workflow engine podľa BPMN aj bez neho, len ako stav žiadosti v databáze. Obe cesty fungujú, rozdiel je v tom, kedy ktorá začne stáť viac, než prináša. Z tej skúsenosti vzniklo rozhodovacie pravidlo, ktoré dnes v Sibo Consulting používame pri návrhu systémov so schvaľovaním. Článok je pre architektov, vedúcich vývoja a vlastníkov procesov, ktorí stoja pred touto voľbou.

Čo je BPMN a čo engine naozaj robí

BPMN (Business Process Model and Notation) je štandard skupiny OMG. Aktuálna formálna verzia je 2.0.2 z roku 2014. Ako medzinárodná norma ISO/IEC 19510:2013 bola prevzatá verzia 2.0.1. Štandard definuje notáciu aj sémantiku vykonávania, takže ten istý diagram môže slúžiť ako dokumentácia pre biznis aj ako spustiteľný model. Samotný diagram však nič nespúšťa, to robí engine. Jeho prínos je v tom, čo za vás rieši počas behu:

• Stav a perzistencia: v čakacích bodoch (úloha pre človeka, časovač, čakanie na správu) engine uloží stav inštancie do databázy, takže proces prežije reštart aj nasadenie novej verzie aplikácie a môže čakať dni či týždne.
• Časovače a termíny: lehoty, pripomienky a opakované kontroly sú súčasťou modelu, nie samostatné plánované úlohy roztrúsené po kóde.
• Eskalácie a hraničné udalosti: ak úloha nie je vybavená do termínu, proces pokračuje inou vetvou, napríklad k nadriadenému, bez ručného zásahu.
• Kompenzácie: ak neskorší krok zlyhá, model určuje, ktoré dokončené kroky treba vrátiť a akou akciou. Kompenzácia nie je databázový rollback, ale ďalšia obchodná akcia, napríklad storno rezervácie.
• Úlohy pre ľudí: pridelenie role alebo skupine, prevzatie, formulár, zástup.
• História a audit: kto ktorú úlohu kedy prevzal a dokončil, ktoré premenné sa zmenili a ktorou vetvou proces išiel. Úroveň detailu a dobu uchovania treba nastaviť vedome, lebo história rastie s každou inštanciou.
• Verzovanie: nová verzia definície sa nasadí vedľa starej a bežiace inštancie pokračujú vo verzii, v ktorej začali. Presun bežiacich inštancií na novú verziu (migrácia) nástroje podporujú, ale len v určitých medziach a s mapovaním aktivít.

Pre rozhodovacie pravidlá existuje samostatný štandard OMG, DMN (Decision Model and Notation). Rozhodovacia tabuľka, napríklad do akej výšky úveru stačí jeden schvaľovateľ a kedy treba úverový výbor, sa dá upravovať a testovať oddelene od priebehu procesu. Bežné nástroje BPMN obsahujú aj DMN, no rozhodovacie tabuľky sa dajú použiť aj bez nich.

Kritériá: kedy sa engine oplatí

Žiadne kritérium samo nerozhoduje. Podľa našej skúsenosti sa engine začína oplácať, keď platí viacero z nich naraz. Ak platí jedno, zvyčajne stačí jednoduchšie riešenie.

• Účastníci: na procese sa podieľa viac rolí (zvyčajne od troch vyššie), úloha prechádza medzi nimi tam aj späť a treba vedieť, na kom práve leží.
• Trvanie: proces trvá dni až mesiace, čaká na dokumenty od klienta, na externé systémy alebo na ľudí a musí prežiť reštarty a nasadenia.
• Termíny: lehoty, pripomienky a eskalácie sú podstatou procesu, nie výnimkou. Ručne programované časovače sa ťažko testujú a ešte ťažšie menia.
• Audit: regulátor, interný audit alebo compliance sa pýta, kto čo kedy schválil a ktorou cestou žiadosť išla, a odpoveď má byť dostupná bez skladania z logov.
• Paralelné vetvy: posúdenie rizika, právne preverenie a ocenenie zábezpeky bežia súčasne a proces čaká na všetky alebo na prvé zamietnutie.
• Zmeny procesu: proces sa mení častejšie ako zvyšok aplikácie. Aj pri nasadenom engine mení spustiteľný model zvyčajne vývojár s analytikom, nie biznis sám. Engine skracuje cestu zmeny, neodstraňuje vývoj ani testovanie.

Kedy stačí stavový stĺpec a ako ho urobiť poriadne

Ak má proces niekoľko stavov, jedného vlastníka, krátke trvanie a mení sa len spolu s kódom, engine prináša viac prevádzky než úžitku. Stavový stĺpec však neznamená textové pole, do ktorého ktokoľvek zapíše čokoľvek. Minimum, ktoré sa osvedčilo:

• Uzavretý zoznam stavov (enum alebo číselník s obmedzením v databáze), žiadne voľné reťazce.
• Povolené prechody definované v jednej funkcii v kóde, stav sa mení výhradne cez ňu.
• Tabuľka histórie, do ktorej sa iba pridáva: pôvodný stav, nový stav, kto, kedy a prečo. Toto je audit, ktorý stĺpec sám neposkytne.
• Ochrana proti súbežnej zmene, napríklad optimistické zamykanie cez číslo verzie riadku, aby dvaja schvaľovatelia neposunuli žiadosť naraz.
• Termíny ako dáta: dátum splatnosti úlohy v riadku a jedna plánovaná úloha, ktorá ich kontroluje, namiesto časovačov roztrúsených po kóde.

Keď toto minimum začnú rozrastať paralelné stavy, výnimky z prechodov a ďalšie plánované úlohy, je to signál, že proces prerastá stĺpec.

Medzi stĺpcom a BPMN: ďalšie možnosti

Knižnica stavového automatu dáva explicitné stavy, prechody a podmienky v kóde bez samostatnej infraštruktúry. Perzistenciu, časovače a audit si však riešite sami. Platformy na durable execution (napríklad Temporal) opisujú proces ako bežný kód, ktorého priebeh sa ukladá ako história udalostí a po výpadku sa obnoví jej prehratím. Dobre zvládajú dlhé procesy, opakovania a kompenzácie, ale kód procesu musí byť deterministický a zmeny pri bežiacich inštanciách treba verzovať mechanizmami platformy. Diagram pre biznis ani štandardné úlohy pre ľudí tam nie sú, čo je pri procesoch s mnohými ľudskými krokmi podstatný rozdiel. BPMN engine dáva najväčší zmysel, keď je model spoločným jazykom s biznisom a ľudské úlohy tvoria veľkú časť procesu.

Nástroje na trhu k októbru 2026

Pri procese, ktorý má v banke bežať roky, patrí licencia a podporný cyklus produktu medzi rozhodovacie kritériá rovnako ako funkcie. Situácia sa za posledné dva roky výrazne zmenila:

• Camunda 7 Community Edition skončila v októbri 2025: posledná komunitná verzia 7.24 vyšla 14. októbra 2025 a bezpečnostné opravy pre ňu už nevychádzajú. Platená Enterprise edícia má podľa výrobcu podporu do apríla 2030. Z komunitného kódu vznikli forky, napríklad Operaton pod licenciou Apache 2.0.
• Camunda 8 je postavená na inom engine (Zeebe), takže prechod zo 7 je migrácia, nie aktualizácia. Od verzie 8.6 (október 2024) vyžaduje Self-Managed nasadenie vrátane Zeebe na produkčné použitie platenú licenciu, bezplatne sa dá používať na vývoj. Zdrojový kód je dostupný pod Camunda License 1.0.
• Flowable má engine pod licenciou Apache 2.0 s podporou BPMN, CMMN (riadenie prípadov) a DMN. Výrobca ponúka aj komerčné produkty.
• jBPM, Drools a Kogito prešli pod Apache Software Foundation ako projekt Apache KIE, ktorý je stále v inkubátore. Prvé vydanie pod ASF (10.0.0) vyšlo v decembri 2024, verzia 10.2.0 v apríli 2026.

Nehodnotíme, ktorý je lepší, lebo to závisí od existujúcej technológie, prevádzkového modelu a rozpočtu. Licenciu pre produkciu, horizont podpory a cestu migrácie však treba overiť skôr, než na engine nasadíte prvý proces.

Náklady omylu v oboch smeroch

Engine pre jednoduchý proces znamená ďalšiu infraštruktúru s monitoringom, zálohami a aktualizáciami, prípadne licenciu, ďalší nástroj na ladenie a testy, ktoré musia pokryť aplikáciu aj model. Stavový stĺpec pre zložitý proces znamená opak: po roku nikto nevie, prečo je žiadosť v stave 7, logika prechodov je rozptýlená v podmienkach po celej aplikácii, eskalácie sa riešia e-mailom a odpoveď pre audítora sa skladá z logov. Prvý omyl je drahší na začiatku, druhý sa predražuje postupne a zvyčajne sa odhalí pri audite alebo pri väčšej zmene procesu.

Ako prejsť zo stĺpca na engine, keď proces vyrastie

• Najprv nakreslite skutočný priebeh v BPMN vrátane výnimiek, ktoré dnes riešia ľudia mimo systému. Často sa ukáže, že kód a realita sa rozišli.
• Doménové dáta (žiadosť, klient, zábezpeka) nechajte v databáze aplikácie. Engine drží stav procesu a odkaz na žiadosť, nie kópiu dát.
• Nové prípady spúšťajte na engine, rozbehnuté nechajte dobehnúť v starom režime. Hromadný presun bežiacich prípadov s mapovaním stavov na aktivity modelu robte len vtedy, keď by dobeh trval neúnosne dlho.
• Počas prechodu sledujte obe cesty a porovnávajte, či sa žiadna žiadosť nestratila medzi systémami.
• Pôvodnú tabuľku histórie nemažte, audit starších prípadov sa z nej bude čítať ešte roky.
• Začnite jedným procesom. Na prvom sa tím naučí modelovať, testovať a prevádzkovať a ďalšie potom idú rýchlejšie.

Typické chyby pri nasadzovaní workflow enginu

• Modelovanie každej drobnosti: každá validácia či volanie služby ako samostatný krok. Diagram prestane byť čitateľný a biznis ho prestane používať. Do modelu patria obchodné kroky, čakania a rozhodnutia, technické detaily patria do kódu.
• Logika v skriptoch diagramu: výpočty a podmienky písané ako skripty alebo výrazy priamo v modeli sa ťažko testujú, ladia a revidujú. Lepšie je volať otestovaný kód a rozhodnutia presunúť do DMN tabuliek.
• Neriešené verzovanie bežiacich inštancií: zmena modelu bez stratégie pre rozbehnuté prípady vedie k tomu, že v produkcii bežia súčasne viaceré verzie a nikto presne nevie, ktoré a prečo.
• Veľké dáta v premenných procesu: celé dokumenty v premenných zaťažujú databázu enginu aj jeho históriu. V procese stačia identifikátory a údaje potrebné na rozhodnutie.
• Engine ako integračná zbernica: orchestrácia desiatok systémov cez model namiesto jasných rozhraní. Engine riadi proces, nenahrádza integračnú vrstvu.

Odporúčanie

Nakreslite proces v BPMN aj vtedy, keď engine nepoužijete. Diagram je spoločný jazyk s biznisom a ukáže zložitosť skôr, než ju objavíte v kóde. Potom prejdite kritériá: ak proces trvá dlho, zapája viac rolí, má termíny a audit sa pýta na každý krok, engine sa zvyčajne oplatí a spolu s ním treba hneď vybrať licenčný a podporný model. Ak nie, urobte poriadny stavový stĺpec s históriou a prechodmi na jednom mieste a vopred si určte signály, podľa ktorých spoznáte, že proces z neho vyrastá.