Hogyan épül fel egy olyan rendszer, amely egyszerre biztosít üzleti agilitást és szabályozói megfelelőséget?
A beszerzési és szállítómenedzsment szoftverek piacán a funkciók listája könnyen összehasonlítható — workflow, jóváhagyás, riportok. Ami nehezebben látható, de hosszú távon meghatározó: hogyan épül fel a rendszer belülről? Milyen garanciákat ad a platform szintjén, és mit bíz a felhasználói konfigurációra?
A különbség nem elméleti. A szabályozott iparágakban — pénzügy, gyártás, gyógyszeripar, közigazgatás — minden beszerzési döntésnek auditálhatónak kell lennie. A DORA (Digital Operational Resilience Act), a NIS2 és a GDPR konkrét követelményeket támaszt: ki látta az adatot, ki döntött, milyen szabály alapján, és mindez visszakereshető-e két év múlva. Ha ezek a garanciák az alkalmazás szintjén vannak megoldva — folyamatonként, blokkonként, külön-külön —, akkor minden új funkció újabb compliance-kockázatot jelent. Ha viszont a platform szintjén vannak megoldva egyszer, akkor az üzleti felhasználó szabadon konfigurálhat anélkül, hogy a biztonsági garanciák sérülnének.
A Fluenta One egy cloud-native, multi-tenant B2B SaaS platform, amelynek architektúrája erre a szétválasztásra épül. A teljes infrastruktúra az EU-ban (Azure North Europe) üzemel, kizárólagos EU adatrezidenciával.
A platform kétféle folyamatot különböztet meg, és ez a megkülönböztetés meghatározza az architektúra felépítését.
Vertikális folyamatok az üzleti értékteremtés elsődleges csatornái. Konkrét üzleti célt követnek: egyértelmű kezdőpont, végpont, mérhető kimenet. Példák: Procure-to-Pay (beszerzéstől a kifizetésig), Order-to-Cash (megrendeléstől a bevételig), Contract Lifecycle Management (szerződés teljes életciklusa). Ezek a folyamatok tranzakciós állapotot kezelnek — egy beszerzési kérés, egy ajánlat, egy szerződés.
Horizontális folyamatok a szervezet keresztfunkcionális képességrétege. Önmagukban nem teremtenek üzleti értéket, de minden vertikális folyamat rajtuk alapul. Példák: szállítói validáció, jogosultságkezelés, megfelelőségi ellenőrzés. Ezek rendszerszintű állapotot kezelnek — egy partner aktív-e, egy szabály hatályos-e.
A Fluenta One a horizontális folyamatokat platform szinten, natívan kezeli. Ez azt jelenti, hogy amikor egy vertikális folyamat (pl. beszerzési kérés jóváhagyása) elakad, mert egy szállító adóazonosítója lejárt, a platform automatikusan elindítja a megfelelő horizontális folyamatot (szállítói validáció), majd a sikeres lezárás után folytatja az eredeti vertikális folyamatot.
A rendszer két rétegre tagolódik, amelyek tisztán elkülönülnek egymástól — és ezzel együtt a felelősségi körök is.
L0 — Platform Layer: az IT és a Fluenta felelőssége. Ez a réteg a biztonsági korlátokat garantálja, amelyeket senki nem törhet át. Ide tartozik minden, ami a biztonságot, az adat-izolációt és az auditálhatóságot biztosítja:
A business user soha nem módosítja közvetlenül az L0 réteget — és ez a lényeg. Az L0 kontrollok automatikusan érvényesek minden folyamatra, amelyet az L1 rétegben konfigurálnak.
L1 — Business Logic Layer: a beszerzés szabadsága. Itt konfigurálhatók a folyamatok anélkül, hogy az IT-t kellene bevonni minden módosításhoz. Drag-and-drop szerkesztőfelület a Fluenta Business Designerben, konfigurálható blokkok, döntési táblák, form builder. Az L1 blokkok az L0 szolgáltatásokat használják transzparensen — a felhasználónak nem kell tudnia, hogy a háttérben policy engine fut, audit log íródik, és a tenant-ek adatai el vannak választva.
A gyakorlati következmény: a beszerzési csapat önállóan módosíthat egy jóváhagyási szintet vagy hozzáadhat egy új form mezőt, és a platform szintű biztonsági garanciák automatikusan érvényben maradnak. Nem kell minden változáshoz IT ticket, de a compliance kontrollok nem sérülhetnek.
A Fluenta One L1 rétegében a folyamatok Smart Block-okból épülnek. Minden Smart Block belülről egy vagy több BPMN (üzleti folyamatmodellezési szabvány) lépés összecsomagolva; kívülről egy konfigurálható doboz a drag-and-drop felületen.
A blokkok hat kategóriába sorolhatók:
Minden blokk konfigurációja no-code módon történik: trigger típus, artifact template, artifact mód (létrehozás, módosítás, olvasás), opcionális timer eszkalációs útvonallal, külső connector integráció. A konfiguráló nem ír kódot — blokkok közötti kapcsolatokat definiál.
Az egyedi építés mellett a Fluenta One Blueprint rendszere lehetővé teszi, hogy teljes, production-ready folyamatcsomagokat telepítsünk egy tenantba egyetlen lépéssel.
Egy Blueprint tartalmazza a teljes BPMN orchestration folyamatot Smart Block-okból összeállítva; az előre definiált artifact template-eket (beszerzési kérés, ajánlat, szerződés); a user task form-okat mező-szintű konfigurációval; a döntési táblákat (összeghatár → jóváhagyói szint, prioritás → SLA); az értesítési sablonokat; az eszkalációs konfigurációt; és a szerepkör-alapú jogosultságokat.
A Blueprint Adoption során a tenant admin kiválaszt egy blueprint-et, a rendszer létrehozza annak teljes másolatát a tenantban. Innentől szabadon testreszabható: blokkok hozzáadása, form mezők módosítása, jóváhagyási szintek átállítása, connectorok cseréje. A blueprint indulási pont, nem merev sablon — de mindkét út ugyanazokat az L0 platform garanciákat kapja.
Néhány példa: a Sourcing Blueprint a kéréstől a szerződésig vezeti végig a folyamatot, a Quoter Blueprint egyszerűsített árajánlat-kérést biztosít kisebb értékű beszerzésekhez, a Supplier Qualification Blueprint a szállítói minősítést, dokumentum begyűjtést és compliance ellenőrzést kezeli.
A hagyományos workflow rendszerek dokumentumokat mozgatnak — fájlokat, amelyeket meg kell nyitni, ki kell bontani, kézzel kell feldolgozni. A Fluenta One-ban a Business Artifact (üzleti adatcsomag) strukturált rekord, amely a folyamaton végighalad, és minden lépésnél gazdagodik.
Az artifact három tulajdonsággal rendelkezik, amelyek audit szempontból kritikusak:
Lekérdezhető — nem kell fájlokat kibontani vagy e-mail láncokat túrni. Az adat strukturáltan lekérdezhető: hány beszerzést hagytak jóvá 10M Ft felett Q3-ban? A válasz másodpercek alatt megvan.
Összeállítható — az egyik lépés kimenete automatikusan input a következő lépéshez. Az igénylés összege elindítja a döntési motort, amely meghatározza a jóváhagyási ágat — emberi beavatkozás nélkül.
Utólag módosíthatatlan és verzionált — minden módosítás új verziót hoz létre, az előző megmarad. Míg egy Excelben bárki átírhat egy cellát utólag, az artifact garantálja, hogy amit az auditor lát, az a megmásíthatatlan valóság.
A verziókezelés kétszintű. Minor verzió (v1.1, v1.2) minden folyamaton belüli módosításnál, major verzió (v1.0 → v2.0) kizárólag akkor, amikor az artifact egy új process instance tulajdonába kerül. Ez a modell biztosítja, hogy az auditor bármikor visszakövethesse, mi történt az adattal, mikor, ki által.
A szabályozott iparágak jellemzően több felet érintő folyamatokat igényelnek. Egy sourcing folyamatban a vevő és a szállítók együtt dolgoznak, de az adataik elkülönítve kell hogy maradjanak. A hagyományos megoldások — emailezés, közös portál, egyedi integráció — egyik sem ad egyszerre audit trailt és valódi adatszeparációt.
A Fluenta One-ban a cross-tenant együttműködés nem utólagos kiegészítés — az architektúra természetes következménye. A CrossTenantGateway garantálja, hogy minden cross-tenant kérés kontrolláltan halad át a rendszeren: a szenzitív mezők automatikusan maszkolásra (elrejtésre) kerülnek a célszervezet felé, a hozzáférés időkorlátozott tokenekkel történik, és mindkét fél szempontjából teljes audit trail keletkezik.
Három adat-hozzáférési minta támogatott. A Form Copy egyszerű adatcserét biztosít: a form definíció és az indító adatok másolódnak a célszervezetbe, ahol saját példányt töltenek ki. A Service Gateway valós idejű megosztott adathoz használható, például ajánlattételnél vagy aukciónál. A Granted Project ad-hoc megosztást tesz lehetővé partner vagy leányvállalat viszonyban.
A valós idejű kommunikációt a Fluenta Messenger biztosítja: szervezeti határokon átívelő üzenetváltás, Collaboration Room-ok közös munkához, és tenant-közi értesítések — mindezt az L0 biztonsági garanciákkal.
A Fluenta One három döntési motort biztosít, mert nem minden döntés egyforma. A beszerzési vezető szempontjából a lényeg: a rendszer automatikusan a megfelelő típusú módszert alkalmazza az adott problémára.
Szigorú szabályok egyértelmű esetekre (DMN Engine). Ha az összeg 5M Ft felett van, a CFO jóváhagyása szükséges. Ha a prioritás "sürgős", az SLA 24 óra. Ezek a szabályok döntési táblákban konfigurálhatók, kód nélkül, és a kimenet mindig kiszámítható — ugyanaz az input mindig ugyanazt az outputot adja (determinisztikus, azaz reprodukálható és auditálható).
Összetett megfelelőségi logika (Policy Based Decision Engine). 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ó —, a szabálytáblák nem elegendők. A policy engine a teljes kontextust figyelembe veszi, de a kimenet továbbra is determinisztikus: visszakövethető, hogy milyen szabály alapján született a döntés.
Intelligens elemzés komplex problémákra (AI Decision Engine). Dokumentumelemzés, kockázatbecslés, anomáliadetekció — ahol mintázatokat kell felismerni, nem szabályokat követni. Az AI motor valószínűségen alapuló javaslatot tesz, de minden aktiválásnál artifact-szintű rekord keletkezik: milyen input alapján, milyen kimenettel, mikor. Az AI segít, de a kontroll és a felelősség megmarad.
A motorok közötti választás a folyamattervezéskor történik: a konfiguráló határozza meg, melyik motor aktiválódjon az adott döntési pontnál.
Egy konkrét forgatókönyv segít megérteni, hogyan működik mindez együtt. Egy procurement manager benyújt egy 15M Ft-os beszerzési kérést:
Az egész folyamat alatt a felhasználó csak a saját feladatait látja — a platform szintű kontrollok automatikusan működnek.
A platform több compliance keretrendszernek felel meg:
A tenant izoláció platform szinten garantált — nem alkalmazás szinten, ahol megkerülhető lenne. A gyakorlatban ez azt jelenti, hogy egy tenant soha nem láthatja egy másik tenant adatait, még hibás konfiguráció esetén sem, mert az elkülönítés az adatbázis szintjén (Row-Level Security, azaz sorszintű hozzáférés-vezérlés) és a policy engine szintjén egyaránt érvényesül.
A hálózati biztonság Zero Trust modellt alkalmaz: minden kommunikáció hitelesített és titkosított, a rendszer nem bízik semmiben alapértelmezetten. A pod-to-pod kommunikáció mTLS-sel védett, az adatbázisok private endpoint-okon keresztül érhetők el, és a production környezetben WAF (Web Application Firewall) működik.
A Fluenta One architektúrájának központi elve: a biztonsági garanciák platform szinten vannak megoldva, nem folyamatonként. Az L0 réteg — az IT és a Fluenta felelőssége — biztosítja a tenant izolációt, az audit logot, a jogosultságkezelést és a titkosítást. Az L1 réteg — a beszerzés szabadsága — az üzleti logikát hordozza: Smart Block-ok, Blueprint-ek, artifact-ok, döntési táblák.
Ez a szétválasztás azt jelenti, hogy a beszerzési csapat önállóan konfigurálhat folyamatokat, és a platform szintű biztonsági garanciák automatikusan érvényben maradnak. A compliance nem utólagos ráépítés, amelyet minden audit előtt külön össze kell gyűjteni — hanem az architektúra természetes következménye, amely minden pillanatban működik.