Folyamattámogató és workflow rendszer

Két külön kategória: folyamattámogatás és vállalatirányítás

A magyar középvállalati IT-stacket jellemzően egy ERP, néhány Excel és valamilyen feladatkezelő tartja össze. Ez sokáig működik, aztán jön egy pont, ahol a raktáros, a sofőr vagy az iskolatitkár napi munkája elakad, mert a piaci szoftver nem arra a folyamatra készült, ami nálad valóban zajlik.

Amikor valaki azzal keres meg minket, hogy „kellene egy új workflow rendszer", először szét kell szálazni, mi is a valódi igény. A tapasztalatunk szerint két különálló kategória létezik.

Egyedi ügyviteli rendszer
Standardabb, nyilvántartó jellegű, a cég egészére vonatkozó megoldás, ami a vezetők számára ad fontos adatokat: CRM, ERP, PIM, számlázó, BI, kontrolling. A működését jogszabályok és szabványok határozzák meg (NAV, GDPR, számviteli előírások), és sokan dolgoznak benne: az ERP-be megy be a rendelés, abból számláz a könyvelő. Bővebben az egyedi ügyviteli rendszer oldalon.

Folyamattámogató rendszer
A cégre szabott operatív működést szolgáló rendszer. A konkrét napi munkát szolgálja: vonalkódolvasó app a raktárosnak, sofőr kioszk a fuvarozó kollégának, útvonaltervező a diszpécsernek, rendelési felület a közétkeztetési titkárnak. A háttérben pedig az az üzleti logika, ami a folyamatot mozgatja és a többi rendszerrel adatot cserél. A vezető ezeket a felületeket nem használja, gyakran be sem lép a rendszerbe.

Az iparágban ugyanez a megoldás több néven fut. Workflow rendszer vagy workflow szoftver, amikor a jóváhagyási láncokon és a státuszkezelésen van a hangsúly. Folyamatautomatizálás vagy feladatautomatizálás, ha a kézi lépéseket szervezzük szoftverbe. Business process management, magyarul folyamatmenedzsment vagy folyamatirányítás ott, ahol a vállalati folyamatok teljes modellje a kiindulópont. Ügykezelő rendszer, amikor egy-egy ügy végigkövetése a cél. Mi mindezt a folyamattámogató kategóriába soroljuk, mert a közös bennük a napi működésre szabott célrendszer.

A két kategória között van átfedés. Egy ERP-modul jóváhagyási lánca már határterület, és a folyamattámogató rendszerek is szinte mindig kapcsolódnak az ügyviteli réteghez a törzsadaton, számlázáson vagy riporton keresztül.

Sofőr a fülkéből, kézi eszközön zárja le a fuvart a workflow rendszer terepi felületén.

Négy tipikus belépési pont egy workflow rendszer fejlesztéséhez

Az operatív folyamatok akkor kerülnek szoftverbe, amikor a napi munka már láthatóan akadozik. Leggyakrabban négy jellemző ponton keresnek meg minket.

Operatív felület a frontvonalban, ami a piaci termékből hiányzik. A raktáros vonalkódolvasóval a kezében jár ki-be a telepre, vonalkódot olvas, mennyiséget és lokációt rögzít. . A sofőr a fülkéből, kézi eszközről frissíti az útvonalat és zárja le a fuvart. Az iskolatitkár az értekezlet után pillanatok alatt összeszedi a heti rendelést. A dobozos ERP raktármoduljának van „mobil" verziója, csak épp a napi tempót nem bírja, a céges egyedi szabályokat nem támogatja, és a felhasználói élmény is hagy kívánnivalót maga után.
Jóváhagyási lánc a céged saját logikájára. A standard feladatkezelők és az általános workflow platformok csak a vázat adják. Amikor a beszerzési igényhez három aláíró kell, amikor egy szerződésnél a jogász, a pénzügy és a kontrolling máshogy szól bele attól függően, hogy hazai vagy külföldi a partner, vagy amikor a gyártáselőkészítés hat állomáson megy végig saját szabálymátrixszal, ott jönnek elő a dobozos platformok korlátai.
Iparágspecifikus célfunkciók, amelyekre nincs jó piaci termék. Ide tartozik az útvonaltervező nem szabványos megkötésekkel (sofőr pihenőidő, jövedéki szabályok, vegyes szállítási mód), a constraint programming alapú gyártás- és termelésirányítási ütemezés, a raktári pick&pack folyamat vagy a HACCP-ellenőrző app. Itt az erőforrás optimalizálás maga a feladat, és pont ez az, amit egy általános eszköz nem tud kezelni.
Versenyelőny egy speciális belső folyamatból. Gyakran épp az a jól optimalizált belső folyamat adja a versenyelőnyödet, amiről más nem tud, vagy amit nem alkalmaz: olcsóbb operáció, nagyobb árrés. Ha lenne rá dobozos termék, mindenki azt használná, ezért itt az üzleti folyamat automatizálás egyedi úton éri meg. A folyamat optimalizálás ilyenkor maga a projekt célja.

A make or buy mérlegelés a folyamatautomatizálásban

Mielőtt egyedi szoftvert ajánlanánk, mindig ugyanaz az első kérdés: van-e piaci termék a problémádra? Egyedi fejlesztő cégként is ezt valljuk.

„Hiába foglalkozom egyedi szoftverfejlesztéssel, azt mondom, ha valamilyen problémádra elérhető termék a piacon, akkor vedd meg azt és ne kezdj egyedi szoftver projektbe. Ha nem tökéletesen felel meg, még akkor is tedd ezt, legalább pár száz dollárért tudni fogod, hogy mire van valójában szükséged, hol szorít ténylegesen az a cipő!"
- Máriás Zsigmond, LogiNet CEO

A folyamattámogató kategóriában ez a mérlegelés különösen fontos. Az ügyviteli rendszerek piaca (CRM, ERP, BI) telített, sok szállító versenyez, így ott a mérleg általában a kész termék felé billen. Itt szűkebb a kínálat: ami van (JIRA, Asana, Trello, Monday, dobozos bpm rendszer vagy folyamatmenedzsment rendszer, beépített ERP-workflow-modul), az az általános feladatkezelés és a kanban szintű workflow management rétegét adja. A sofőr kioszkot vagy az élelmiszerbiztonsági audit felületet nem. Ezért sokszor egyszerűen nincs olyan termék, ami a fő használati esetedet lefedné.

A mérlegelést ettől függetlenül végigcsináljuk. Először végignézzük, van-e az iparágadra szabott piaci szállító vagy testre szabható workflow engine, és csak akkor javasoljuk az egyedi utat, ha a kész kínálat korlátozná a működésedet. A tanácsadás szolgáltatásunk pontosan ezt a döntést segíti a projekt elején.

A workflow rendszer öt visszatérő rétege

Egy konkrét operatív folyamatot támogatunk, és közben együttműködünk a meglévő rendszereiddel. A megoldás anélkül áll össze, hogy újra kellene húznod a teljes IT-stackedet; a legtöbb projektben ez az öt réteg tér vissza.

Ergonomikus felület
Az első kérdés mindig az, hogy hol és hogyan dolgozik a kolléga: asztali gépnél, mobilon, tableten, kioszkon, esetleg egy kézzel, kesztyűben, poros környezetben? A felület tipikusan mobilra hangolt, kontrasztos, és ott, ahol a hálózat gyenge, offline toleranciával működik. A modern frontend stack adja az alapot, de a tervezés a használati helyzetből indul.

Szerepkör-modell az operációhoz igazítva
Adatfeltöltő, ellenőrző, jóváhagyó, lezáró, kivételkezelő, supervisor, helyettesítő. Mindegyik mást lát, mást csinálhat, és más a napi tempója, ezért a kollégákkal együtt, a helyszínen tervezünk. A feladat kiosztás és a határidő kezelés szabályait is szerepkörönként állítjuk be, a supervisor pedig egy workflow dashboardon látja, hol torlódik a sor.

Workflow réteg, státuszkezelés, audit
A munkafolyamat automatizálás lényege maga a folyamatmodell: állapotok, átmenetek, jóváhagyások, értesítések, eszkalációk, audit-történet.. Itt válik a folyamatvezérlésed konkrét, ellenőrizhető állapotgéppé: minden átmenetnek van gazdája és időbélyege.

A ma papíron, e-mailben vagy Excelben futó folyamatokból így lesz kontrollált adatfolyam: ki látta, ki hagyta jóvá, mikor, milyen állapotban. A jóváhagyandó megrendelés, szerződés vagy szállítólevél a folyamattal együtt mozog, tehát a dokumentumkezelés is a workflow része lesz: a papír alapú köröztetésből elektronikus dokumentumkezelés válik, verzióval és audit-nyommal. A státuszkezelés innentől azt is jelenti, hogy bármikor tudható, egy konkrét ügy hol tart és kinél áll.

Integráció az ügyviteli rendszerrel
A folyamattámogató rendszer ritkán áll önmagában. A meglévő ERP-vel, számlázóval, CRM-mel kapcsolatban van: onnan kap terméket, partnerlistát, kategóriát, és visszaküld lezárt feladatokat, eseményeket, riportadatokat. A törzsadat az ERP-ben marad, ott a forrásigazság, és a törzsadat kezelés is ott történik. Az adatszinkronizáció vagy közvetlen API-kapcsolaton, vagy egy middleware-rétegen keresztül zajlik; erről bővebben a rendszerintegráció oldalon.

Modern, terheléstűrő háttér
Frontend Vue 3 vagy React, mobilra native shell (Capacitor, React Native) ott, ahol natív funkcióra van szükség. Backend a terheléstől és a domaintől függően Python/Django, Go vagy Node.js, az adatbázis PostgreSQL vagy MariaDB. Ezek a rendszerek gyakran kapnak hirtelen terhelést (reggel 6-os műszakváltás, hétfői jóváhagyási hullám), és a backendnek ezt bírnia kell.

Futurisztikus szakember kézi folyamattámogató eszközzel

Hol húzzuk meg a határt

Az általános kanban eszközökre és feladatkezelőkre már van jó piaci termék, ezért ezekbe nem kezdünk bele. Ha az általános feladatkezelés a gondod, vedd meg az Asanát vagy hasonlót; a tanácsadás pontosan ezekben a döntésekben segít.

Az ERP-det is megtartod. A folyamattámogató rendszer a meglévő ügyviteli stack mellé épül, és a vállalati működés többi részét érintetlenül hagyja. Ha az ügyviteli rétegben (CRM, kontrolling, BI) van a fő problémád, az egyedi ügyviteli rendszer oldalon olvashatsz erről több információt.

„Sose becsüljük alá a szoftveres célmegoldás erejét. A sikeres szoftverek közös tulajdonsága, hogy a kezdet kezdetén valakinek szüksége volt egy szoftverre egy igazi probléma megoldásához. Ha egy kis szoftver azt megoldotta, lehetett az bármilyen primitív, sikeres volt és volt lehetősége fejlődni."
- Máriás Zsigmond, LogiNet CEO

Először egy konkrét operatív problémát oldunk meg: egy folyamat, egy felület, egy szerepkör. Az igények erre épülnek rá, és a rendszer ebből az irányból nő tovább.

A projektfolyamat öt szakasza

A projekt a gyakorlati folyamatok megértésével kezdődik, jóval az első kódsor előtt.

1. Tanácsadás és shadowing (3-6 hét)
A vezetőség többnyire csak a tüneteket látja: lassú rendelésleadás, hibás leltár. A valódi okot szinte mindig akkor találjuk meg, amikor megfigyeljük a kollégák hétköznapi munkáját. Ebből 1-2 hét a tényleges shadowing, és itt dől el, hogy folyamattámogató rendszer, egyedi ügyviteli rendszer vagy a kettő keveréke a jó válasz. Ebben a szakaszban kap kiemelt szerepet a tanácsadás és a rendszer audit.

2. Specifikáció prototípussal
A specifikáció egy kattintható prototípuson keresztül a legérthetőbb. A műszaki és üzleti specifikáció együtt készül, de az ergonómiát a kollégákkal teszteljük, mielőtt egyetlen sor éles kód is megszületne. A használati élmény kihagyásának konkrét üzleti ára van: operátori időben, hibázásban, frusztrációban, végső soron lassuló termelékenységben.

3. Lépésenkénti fejlesztés
Először egy felület, egy szerepkör, egy workflow. Élesedik, teszteljük, visszajelzést kap, finomodik, aztán jön a következő. A büdzséd a megkülönböztető operatív logikádra fordítódik. .

4. Élesedés és átállás
Az élesítés ritkán egynapos, főleg ha a régi folyamat papíron vagy Excelben fut. Jellemzően párhuzamosan fut a régi és az új, összehasonlítjuk az eredményeket, és csak akkor állunk át, ha minden adatpont egyezik és az új rendszer beállt a kollégák tempójához.

5. Üzemeltetés és support
Az üzemeltetés transzparens SLA-val és folyamatos terméktámogatással folytatódik. Itt az operatív támogatás különösen fontos, mert a kollégák napi munkája függ tőle: preventív patchelés, monitoring, gyors válaszidő, mindez egy kézből. Választható, hogy a támogatás nálunk marad, vagy a dokumentáció átadásával a saját csapatod veszi át.

Saját példa: a JIRA-t megvettük, a Forecastify-t megírtuk

Házon belül a JIRA-t és a GitLabot használjuk a fejlesztéshez: issue tracking, kód review, build pipeline, release management. Ezek operatív folyamatok, van rájuk jó piaci termék, ezért a workflow menedzsment ezen részét nem találjuk fel újra.

A saját, szoftverprojektekre szabott kontrollingunkra viszont megírtuk a Forecastify-t, mert ott a kínálat nem fedte le az igényünket. A Forecastify egyébként a kontrolling területéhez tartozik, tehát ügyviteli rendszer.

Ugyanezt a mérlegelést végezzük el a te projektedben is, a tanácsadási fázisban.

Ügyfélpélda: roll container kocsik digitális követése a Rossmann raktárában

A Rossmann országos logisztikai központjából napi szinten indulnak a kamionok a boltokba, roll container kocsikra rakott áruval. A kocsikat targoncák töltik fel a polcok mellől, majd harminc kapu közül a megfelelőhöz kell tolni őket, mert minden kapu egy adott kamionhoz tartozik.

A napi munka szűk keresztmetszete
A kapuhoz tolásnál korábban csak emberi kontroll működött, szúrópróbaszerű ellenőrzéssel, és a szállítási nap állásáról sem volt élő kép. A rossz kapuhoz került kocsi azt jelenti, hogy az egyik bolt polcáról hiányzik a termék, a másikba viszont többlet érkezik.

A megoldás
Android alkalmazást fejlesztettünk a Rossmann meglévő Zebra kézi eszközparkjára. A raktári dolgozók ezzel rögzítik a kocsik mozgását: melyik pályára és melyik kapura került a kocsi, mikor vonják ki a forgalomból, mennyi göngyöleg van kint. A címkét is ott nyomtatják, ahol állnak, mert az eszköz közvetlenül kapcsolódik a raktári hőnyomtatókhoz. A csoportvezetők webes workflow dashboardon követik fázisonként a rakodást, és üzletenként látják a göngyölegegyenleget. A státuszkezelést és az üzleti logikát a Java backend viszi, a felületeket Vue.

Integráció és terepi visszajelzés
A backend a meglévő nagyraktári rendszerből veszi át a kiszedési adatokat, így a törzsadat ott marad, ahol eddig is volt; az adatszinkronizáció időzítve és eseményre indítva fut. A kapunál RFID-érzékelő áll: ha a kocsi rossz kamionhoz kerül, a dolgozó azonnal hangjelzést és vizuális visszajelzést kap, még a rakodás előtt.

Az eredmény
A tesztüzemben a hibás roll containerek száma az eredeti hibák körülbelül 10 százalékára csökkent, a boltok pedig automatikus értesítést kaptak az induló szállítmányról. A tesztüzem néhány hónap után lezárult, az élesítés az új logisztikai központban következik.

A projektről bővebben a Rossmann RC app esettanulmányban olvashatsz

A LogiNet mérnökök egy folyamattámogató rendszer architektúráját tervezik a budapesti irodában.

A csapat és a háttér

100+ IT-szakember, 19 év folyamatos piaci jelenlét, 120+ megvalósult projekt. Magyar tulajdonú cég vagyunk, magyar mérnöki csapattal.

Nagyvállalati ügyfeleink (Auchan, Vodafone) mellett közepes cégeknek is építünk folyamattámogató rendszert, az e-commerce, oktatási, közétkeztetési, fuvarozási, kereskedelmi és pénzügyi szektorban.

Ezek a projektek két kulcskompetenciát ötvöznek. Az egyik az ergonómiatervezés: a használati élmény üzleti döntés, ezt jellemzően a testvércégünkkel, a 22.design-nal közösen végezzük. A másik a rendszerintegráció, hiszen a folyamattámogató rendszer élő kapcsolatban áll a meglévő ügyviteli rendszerrel.

A saját döntéseinkben is végigcsináljuk a make or buy mérlegelést: a JIRA-t és a GitLabot megvettük, a Forecastify-t megépítettük. Ezt az őszinte mérlegelést hozzuk a te projektedbe is.

Fix költségvetést és betartott határidőket vállalunk.

Beszéljünk a projektedről.

Gyakran ismételt kérdések a folyamattámogató és workflow rendszerekről

❓ Mi a különbség a folyamattámogató rendszer és az ügyviteli rendszer között?
A folyamattámogató rendszer cégre szabott operatív célrendszer (vonalkódolvasó app, sofőr kioszk, JIRA, GitLab), amit a napi munkát végző kollégák használnak; a vezetők gyakran be sem lépnek. Az egyedi ügyviteli rendszer standardabb kategória (CRM, ERP, PIM, BI, kontrolling, riport), ami a cég egészére vonatkozik, és a vezetők számára ad fontos adatokat. A két kategória átfedhet, például egy ERP belső jóváhagyási lánca már határterület. A konkrét elhatárolás a tanácsadási fázisban dől el.

✅ Mikor érdemes egyedi workflow rendszert építeni a JIRA, az Asana vagy a Trello helyett?
Akkor, ha a piaci feladatkezelő vagy a beépített ERP-workflow-modul a céged operatív folyamatára már kevés. Tipikus jelek: a kollégák papíron vagy Excelenben dolgoznak; a piaci platform mobilverziója a napi tempót nem bírja; az iparágspecifikus szabályaid (sofőr pihenőidő, jövedéki termékszabály, HACCP-előírás) nem férnek be a dobozos keretbe. Ha viszont az általános feladatkezelés a problémád, vedd meg a JIRA-t: mi is azt használjuk.

⚖️ Milyen méretű cégeknek szól ez a megoldás?
Közepes méretű cégtől (30-50 fő) felfelé, ahol az operatív folyamatok komplexitása túlnőtt az Excel- és e-mail-szintű kezelésen. Tipikus ügyfélméret 50-500 fő. Iparágfüggetlen, de ott billen át leggyakrabban egyedi fejlesztésre a döntés, ahol a napi munka erősen specifikus: logisztika, közétkeztetés, gyártás, raktározás, terepi szolgáltatás, élelmiszerbiztonság, fuvarozás.

⚡ Mennyi időt vesz igénybe egy ilyen projekt?
A komplexitástól függ. A feltárási (3-6 hét shadowinggal) és a specifikációs szakasz együtt 1,5-3 hónap. A fejlesztés középkomplex projektnél 4-7 hónap, komplex projektnél 7-12 hónap. Az élesedés és átállás további 1-2 hónap. Egy fókuszált modul (egy felület, egy workflow) lényegesen rövidebb, akár 2-3 hónap. A bevezető megbeszélés után, a scope pontosítását követően adunk indikatív ajánlatot.

➕ Mi történik az ERP-mmel és a többi ügyviteli rendszeremmel?
Maradnak. A folyamattámogató rendszer melléjük épül. A két rendszer közötti adatszinkronizáció vagy közvetlen API-kapcsolaton, vagy egy middleware-rétegen keresztül zajlik. Az ERP-ben lévő törzsadat marad a forrásigazság, és a törzsadat kezelés is ott történik. A folyamattámogató rendszer ehhez az adathoz kapcsolódik, és visszaküldi a lezárt feladatokat, eseményeket, riportadatokat.

⚙️ Milyen technológiai stacken dolgoztok?
A választás a projekt jellegétől függ.
Frontend: Vue 3 vagy React, Tailwind CSS, mobilfelületekhez Capacitor vagy React Native ott, ahol natív funkcióra (kamera, vonalkódolvasó, GPS, offline cache) van szükség.
Backend: Python/Django (gyors fejlesztés, gazdag admin réteg), Go (nagy teljesítményű API-k, párhuzamos feldolgozás), Node.js.
Adatbázis: PostgreSQL, MariaDB. Hosting: Hetzner Cloud, AWS, GCP, DigitalOcean vagy saját infrastruktúra.

⚓ Az operatív kollégákkal hogyan dolgoztok?
A tervezési fázisban shadowingot végzünk: egy-két napot a raktárban, a sofőr fülkéjében, a konyhában, a gyártósoron. A specifikáció kattintható prototípuson validálódik, és a fejlesztési ciklus első iterációja már a kollégák kezébe kerül. Az ergonómiatervezés gyakran a testvércégünkkel, a 22.design-nal közösen történik, mert a használati élmény üzleti döntés.

♾️ A projekt után ki üzemelteti a rendszert?
Választható. Vagy a LogiNet üzemeltetés és support szolgáltatása fut tovább transzparens SLA-val (egy folyamattámogató rendszernél a gyors válaszidő különösen fontos, mert a kollégák napi munkája függ tőle), vagy a saját csapatod veszi át a dokumentáció átadásával és tudásátadási folyamattal.

▶️ Tudtok segíteni a dokumentumok jóváhagyási körében is?
Igen, amennyiben a dokumentum egy folyamathoz kötődik. A jóváhagyandó megrendelés, szerződés vagy szállítólevél a workflow részeként mozog: verzió, jóváhagyó, időbélyeg, audit-nyom. A papíron futó ügymenetből így lesz elektronikus dokumentumkezelés. Önálló iktató- vagy archiváló rendszert nem építünk; ha ez a fő igényed, a tanácsadási fázisban megnézzük, melyik piaci termék való hozzá.

A napi munkát már nem támogatja jól a jelenlegi rendszered?

Írd le, hol akadnak el a kollégák, milyen manuális lépések lassítják a munkát, vagy melyik speciális folyamatot nem fedi le a piaci szoftver. Megnézzük, hogy kész workflow eszköz vagy egyedi folyamattámogató rendszer a jobb megoldás.

írj nekünk! →

Kapcsolódó tartalmak

Amikor a napi folyamatokon túl az ügyviteli rendszeredet is tovább kell fejleszteni

CRM, PIM, BI és kontrolling → egyedi ügyviteli réteg a meglévő ERP rendszered mellett.

A folyamattámogató rendszer az operatív munkát segíti, míg az ügyviteli rendszer a vállalat egészén átívelő adatkezelést és üzleti funkciókat szolgálja ki. Egyedi megoldásra akkor lehet szükség, ha például a kontrolling, a riporting vagy az iparágspecifikus üzleti szabályok már nem férnek bele a kész rendszerbe.

Megnézem

Mit érdemes fejleszteni, és mikor jobb egy kész rendszer?

Build or Buy, architektúra és technológiaválasztás → döntsd el még a fejlesztés előtt, melyik irány működik nálad.

IT tanácsadás segítünk feltárni az üzleti probléma valódi okait, segítünk eldönteni, hogy kész rendszerre, egyedi fejlesztésre vagy a kettő kombinációjára van-e szükség. Javaslatot hozunk konkrét architektúra, megfelelő technológiára és megvalósítási roadmapet készítünk.

Megnézem

Rendszerintegráció service for folyamatt. és ügyviteli servicepage

Hogyan kötheted össze a különálló üzleti rendszereidet?

ERP, CRM, számlázás, logisztika és egyedi rendszerek → megbízható adatkapcsolatok manuális munka nélkül.

A rendszerintegráció során a különálló üzleti alkalmazások automatikusan cserélnek adatot egymással. Az API-k és adatfolyamok megtervezésétől a partneroldali koordináción át az integrációs tesztelésig terjed a feladatunk, ha szükséges pedig egyedi middleware-t fejlesztünk.

Megnézem