Task-based, process-based és evidence-based megközelítések — és miért a BOAT a jövő
A szoftveripar workflow-kezelő eszközei három alapvető paradigma mentén fejlődtek ki. Mindhárom megközelítés más kérdésre ad választ, más elemet helyez középpontba, és más mértékben képes támogatni a szervezetek valós igényeit: a folyamatok konzisztenciáját, az átláthatóságot, a döntések nyomon követhetőségét, valamint a szervezetközi együttműködést.
Ezek az igények minden vállalatot érintenek, de különösen kritikusak a szabályozott iparágakban — bankok, biztosítók, közszféra —, ahol az audit és compliance elvárások jogi kötelezettségként jelennek meg.
A piac is ezt tükrözi. A Gartner 2023-ban átnevezte a BPM kategóriát iBPMS-ről BOAT-ra (Business Orchestration and Automation Technologies). A BOAT azonban nem pusztán egy átnevezés: azt jelzi, hogy a szoftver többé nem csak "folyamatábra", hanem aktív irányító központ, amely összehangolja a beszerzést az ERP-vel, a jogi rendszerekkel és az AI-képességekkel. A hangsúly a statikus folyamatmodellezésről az intelligens, event-driven (eseményvezérelt) orchestration-re — vagyis a rendszerek valós idejű összehangolására — helyeződik.
A központi elem a ticket (feladatjegy). A rendszer arra válaszol, hogy ki mit csinál. Minden feladat egy önálló egység: van rajta felelős, státusz, határidő. A ticketek közötti összefüggés gyenge — dashed link, epic, label —, de ezek nem kényszerítik ki a sorrendet vagy az adatáramlást.
Az audit trail (nyomvonal) lényegében a státuszváltások feljegyzései és a ticket kommentek. Ezek utólagosak és manuálisak: ha jön az auditor, screenshotokkal és exportokkal kell bizonyítani, hogy a folyamat szabályosan zajlott.
Tipikus eszközök: Jira, Asana, Linear, ClickUp, Monday, Trello.
A task-based szemlélet ott működik jól, ahol a kérdés egyszerű: elkészült vagy nem? Egy fejlesztési sprintben, egy marketing kampány checklistjében ez elegendő. De amint a kérdés az, hogy milyen szabály alapján döntöttünk, ki hagyta jóvá, milyen adatokra támaszkodva, és mindez visszakereshető-e hat hónappal később — a ticket-alapú megközelítés nem ad választ.
A központi elem a workflow instance (folyamatpéldány). A rendszer arra válaszol, hogy hogyan halad a folyamat. Szabványos folyamatmodellben definiált útvonal, feltételes elágazásokkal és automatikus lépésekkel. Erős konzisztenciát biztosít: minden beszerzési igény, szerződéskötés vagy szállítói onboarding ugyanazon a definiált útvonalon halad végig, automatikus audit nyomvonallal.
Tipikus eszközök: Camunda, Pega, ServiceNow, Kissflow, Bizagi.
A process-based szemlélet megmondja, hogyan halad a folyamat — de azt nem, hogy mi keletkezett közben. Ha az auditor megkérdezi, milyen adatok alapján született a döntés és hol van az adatcsomag — a válasz általában az, hogy az egy másik rendszerben van.
A központi elem az artifact — strukturált adatcsomag, amely egy folyamatlépés vagy döntés összes releváns információját tartalmazza: kitöltött mezők, jóváhagyások, hivatkozások, időbélyegek. Nem dokumentum a hagyományos értelemben, hanem gépileg lekérdezhető rekord. Amikor az auditor azt kérdezi, "mi alapján döntöttek?", az artifact az, amit egy gombnyomásra elő lehet állítani — a teljes bizonyíték-csomag.
Az evidence-based szemlélet erős a szabályozási megfelelés szempontjából: verzionált, immutable (utólag módosíthatatlan) adatrekordok, amelyek bizonyítják a döntési láncot. A gyengesége: a folyamat maga gyakran gyenge vagy kézzel összerakott.
Tipikus eszközök: ez a szemlélet ritkán jelenik meg egyetlen termékként — jellemzően több eszközből ad-hoc módon összerakva: DMS rendszerek (OpenText Documentum, SharePoint), GRC modulok, valamint CLM platformok evidence-kezelő funkciói (DocuSign CLM, Icertis).
Az evidence-based megközelítés pontosan tudja, milyen adat állt össze és ki döntött — verziónként, időbélyeggel, visszakereshetően. De ha arról van szó, hogy ez az adat hogyan jutott el A ponttól B pontig, milyen lépéseken át, milyen feltételek mentén — a válasz gyakran egy Excel-táblázat vagy egy kézzel összeállított e-mail-lánc.
A Fluenta One platform mindhárom szemlélet erősségeit ötvözi egyetlen, integrált megoldásban. Míg a Jira-ban egy beszerzés csak egy "cetli", a Fluenta One-ban élő folyamat, amelynek végén egy gombnyomásra előállítható az auditor számára a teljes bizonyíték-csomag. Ezt három alappillér teszi lehetővé.
Az orchestration (összehangolás) több, mint folyamatautomatizálás: olyan, mint egy karmester, aki nemcsak a saját zenekarát vezényli, hanem látja és összehangolja a külső rendszereket is — az ERP-t, a jogi platformot, a pénzügyi jóváhagyásokat. A Fluenta One workflow engine-je biztosítja, hogy minden üzleti folyamat (beszerzés, szerződéskötés, szállítói onboarding, compliance-ellenőrzés) egy definiált, újrafuttatható workflow-ként fut le. Feltételes elágazások, párhuzamos végrehajtási ágak, emberi task-ok és automatikus lépések kombinációjával a folyamat konzisztens és auditálható.
A Fluenta One artifact engine minden folyamatlépés eredményeként strukturált adatcsomagot generál. Az artifact három tulajdonsággal bír:
Queryable (lekérdezhető) — nem kell fájlokat kibontani vagy e-mail-láncokat túrni; az adat strukturáltan lekérdezhető. Például: hány beszerzést hagytak jóvá 10M Ft felett Q3-ban?
Composable (összeállítható) — az egyik lépés adatcsomagja automatikusan input a következő lépéshez. Az igénylés összege elindítja a döntési motort, ami meghatározza a jóváhagyási ágat.
Immutable (módosíthatatlan) + verzionált — minden adatcsomag módosíthatatlanul rögzül a folyamatpéldányhoz kötve. Nincs utólagos átírás, módosítás.
A Fluenta One architektúrája nem kényszerít minden döntést ugyanazon a motoron keresztül. Ehelyett három komplementer döntési mechanizmus kezeli a különböző helyzeteket:
DMN Engine (Decision Model and Notation 1.3) — üzleti szabálymotor, amely decision table-ökben (döntési táblákban) tárolja a szabályokat. Gyakorlatilag: ez az, ami megmondja, hogy 5 millió forint felett automatikusan kell-e a CFO jóváhagyása, vagy hogy melyik beszállítói kategória igényel háromajánlatos eljárást. Az admin felületről konfigurálható, nincs szükség fejlesztőre.
Policy-Based Decision Engine — a teljes workflow kontextus alapján irányítja a döntéseket, nem statikus if-then (ha-akkor) szabályok mentén. Akkor hasznos, amikor a döntés több tényezőtől függ egyszerre: szállító kockázati besorolása, szerződésérték, kategória, földrajzi lokáció. Determinisztikus és auditálható — minden döntés visszakövethető.
AI Decision Engine — erősen komplex, nem-determinisztikus problémákhoz. Az AI itt nem "fekete doboz": olyan, mint egy digitális asszisztens, aki elvégzi az elemzéseket és javaslatokat tesz, de a végső döntést a rögzített üzleti szabályok és az ember hozzák meg. Az AI segít, de a kontroll megmarad.
A szoftveriparban párhuzamos paradigmaváltás zajlik, amely az üzleti platformokra is közvetlen hatással van. Az AI-alapú (agentic) szoftverfejlesztésben három elv kristályosodik ki.
Először: a természetes nyelv elég szoftver készítéséhez, de nem elég üzleti döntések irányításához. Az AI képes működő kódot generálni angol nyelvű promptokból. De az üzleti szabályok — ki mit hagy jóvá, milyen feltételekkel, milyen felelősséggel — olyan precizitást igényelnek, amit a természetes nyelv nem tud biztosítani. Egy prompt nem auditálható, nem verzionált, és nem determinisztikus.
Másodszor: automatizált bizonyíték adatcsomagoknak (artifact-eknek) kell igazolniuk, hogy az implementáció megfelel a specifikációnak. Az AI-vezérelt világban a bizalom utólagos ellenőrzésből származik — gépi úton generált bizonyítékokból, hogy a kimenet megfelel a szabályoknak.
Harmadszor: a jövő multi-agent — egyes agentek végrehajtanak, mások ellenőriznek. A megbízhatóságot és az elszámoltathatóságot ez a szétválasztás tartja fenn.
A Fluenta One architektúrája pontosan ezekre az elvekre épül: a DMN Engine és Policy-Based Decision Engine determinisztikus üzleti logikát hajt végre; az AI Decision Engine független ellenőrzési vagy optimalizációs rétegként működhet; minden döntéshez automatikusan keletkezik strukturált artifact, ami bizonyítja a megfelelőséget.
A három workflow-paradigma a kirakós egy-egy darabját oldja meg: a task-based a ki-t követi nyomon, a process-based a hogyan-t, az evidence-based a mi-t. Egyikük sem válaszol önmagában mindhárom kérdésre.
A Fluenta One az a platform, ahol ez a három réteg — workflow orchestration, evidence-generálás és formális döntési logika — nem egymás mellé csavarozott modulok, hanem egyetlen architektúra. Az eredmény: minden üzleti folyamat egyszerre hajt végre, dokumentálja önmagát, és bizonyítja a saját megfelelőségét.