Mennyibe kerül a folyamatfejlesztés valójában?

Egy webshop rendelései reggel érkeznek be, majd valaki kézzel rögzíti őket az ügyviteli rendszerben. A raktár egy másik táblázatból dolgozik, a számlázás pedig csak akkor indulhat, ha minden adatot ellenőriztek. Amikor felmerül a kérdés, hogy mennyibe kerül folyamatfejlesztés, sok vezető valójában nem egy projekt árát szeretné tudni. Azt próbálja felmérni, mennyit ér meg, hogy ez a napi, ismétlődő bizonytalanság megszűnjön.

A rövid válasz: nincs értelmes egységár. Egy folyamatfejlesztési munka lehet célzott, néhány hetes beavatkozás, de lehet több rendszert, részleget és kritikus üzleti működést érintő, több lépcsős fejlesztési program is. A költséget nem önmagában a használt technológia, hanem az határozza meg, hogy mit kell megérteni, újratervezni, összekapcsolni, bevezetni és hosszú távon üzemben tartani.

Mitől függ, mennyibe kerül a folyamatfejlesztés?

A legnagyobb különbséget általában nem az okozza, hogy kell-e fejlesztés, hanem az, hogy mennyire tiszta maga a folyamat. Egy vállalatnál például a rendelés teljesítése látszólag egyszerű: rendelés, készletellenőrzés, kiszállítás, számlázás. A gyakorlatban azonban lehetnek kivételek, egyedi árak, részszállítások, visszaigazolási szabályok, külső logisztikai partnerek és olyan manuális ellenőrzések, amelyekről csak egy-két tapasztalt munkatárs tud.

Ha ezeket a kivételeket nem tárják fel a munka elején, a későbbi projekt drágább lesz. Nem azért, mert valaki rosszul becsült, hanem mert a tényleges működés csak fejlesztés közben válik láthatóvá. Ezért az első költségtényező a feltárás mélysége: mennyi interjú, adatelemzés, folyamatábra, rendszervizsgálat és közös döntés szükséges ahhoz, hogy a kiinduló helyzet valóban egyértelmű legyen.

A második tényező az érintett rendszerek száma és állapota. Egy jól dokumentált, korszerű rendszerhez kapcsolódni más feladat, mint egy régi ügyviteli alkalmazásból, Excel-táblákból és e-mailes jóváhagyásokból megbízható információáramlást kialakítani. A rendszerintegráció költsége nem csak az adatátadásról szól. Kezelni kell az adatminőséget, a hibákat, a jogosultságokat, az ismételt futásokat és azt is, mi történik akkor, ha valamelyik rendszer átmenetileg nem elérhető.

Harmadik tényező az üzleti kockázat. Egy belső heti riport előállításának egyszerűsítése általában kisebb kockázatú feladat. Egy termelési rendelés, raktárkészlet, számlázás vagy ügyfélkiszolgálás folyamatának módosítása már nem az. Itt a hibás működés közvetlenül késedelmet, bevételkiesést, készlethiányt vagy ügyfélpanaszt okozhat. A tesztelés, az átállási terv, a visszaállítás lehetősége és az üzemeltetési kontroll ezért a projekt értékes, de megkerülhetetlen része.

Tipikus költségszintek és a mögöttük lévő munka

Magyarországi középvállalati környezetben egy célzott folyamatfelmérés és fejlesztési terv jellemzően néhány százezer forinttól néhány millió forintig terjedhet. Ez nem pusztán egy dokumentum ára. Jó esetben választ ad arra, hol keletkezik a legtöbb ismételt munka, hol vesznek el információk, mely lépések feleslegesek, és mely fejlesztési irány hozhat mérhető eredményt a legkisebb kockázattal.

Egy körülhatárolt javítás - például egy riportadatok automatizált összegyűjtése, egy jóváhagyási folyamat rendbetétele vagy két rendszer megbízható összekapcsolása - gyakran néhány millió forintos nagyságrend. A pontos összeg attól függ, hogy létezik-e használható interfész, mennyire tiszták az adatok, és szükséges-e egyedi kezelőfelület vagy csak a háttérfolyamatot kell kialakítani.

A több részleget érintő átalakítások, ahol rendelési, raktári, számlázási, gyártási vagy logisztikai folyamatok kapcsolódnak össze, jellemzően többmilliós, akár több tízmilliós programok. Ezeknél félrevezető kizárólag a fejlesztési napidíjat nézni. A teljes költség része az üzleti tervezés, az architektúra, az adatmigráció, a tesztelés, a felhasználói bevezetés, a dokumentáció és az éles működés támogatása is.

Az ár tehát nem attól lesz kedvező, hogy az első ajánlatban alacsony szám szerepel. Attól lesz kezelhető, hogy a hatókör, a felelősségek és az eredménykritériumok világosak. Egy olcsón induló, de bizonytalan projekt könnyen többe kerülhet, mint egy alaposan előkészített fejlesztés.

A rejtett költség: a változatlan működés ára

A folyamatfejlesztés költségéről szóló döntésben gyakran kimarad a másik oldal: mennyibe kerül nem változtatni. Ha három munkatárs naponta egy-egy órát tölt adatok másolásával, ellenőrzésével és egyeztetésével, az éves szinten már jelentős kapacitás. Ehhez hozzáadódnak a hibajavítások, a késői információk, a vezetői riportok körüli bizonytalanság és az a helyzet, amikor egy szabadságon lévő kolléga nélkül megáll egy kritikus munkafolyamat.

Nem minden manuális lépést kell megszüntetni. Sok esetben szükség van emberi döntésre, ügyfélismeretre vagy szakmai kontrollra. A kérdés inkább az, hogy az ember döntést hoz-e, vagy rendszerek között közvetít adatot. Az utóbbi hosszú távon drága, hibára érzékeny és nehezen skálázható működést eredményez.

Érdemes azt is vizsgálni, hogyan változik a probléma növekedés mellett. Egy napi tíz rendelésnél még működhet a kézi egyeztetés. Napi száz rendelésnél ugyanez már külön adminisztrációs feladatkört, folyamatos tűzoltást és egyre több kivételt jelenthet. Ilyenkor nem egyszerűen munkaórák szaporodnak, hanem romlik az átláthatóság és a vezetői kontroll is.

Hol lehet túl sokat költeni?

A leggyakoribb hiba, amikor a vállalat egy rendszert vagy technológiát választ ki, mielőtt pontosan meghatározná a megoldandó üzleti problémát. Egy új ERP, egyedi szoftver vagy AI-alapú dokumentumfeldolgozás lehet indokolt, de nem attól lesz értékes, hogy korszerű. Ha egy hibás vagy feleslegesen bonyolult folyamatot gyorsítanak fel, a vállalat csak gyorsabban állít elő hibát és kivételt.

Túlzott költséget okozhat az is, ha mindent egyszerre akarnak megoldani. A teljes működés újratervezése néha valóban szükséges, de sok szervezetnél egyetlen információs töréspont megszüntetése adja a leggyorsabb eredményt. Például ha a webshop, a készlet és a számlázás között megbízhatóan átjutnak az adatok, máris megszűnhet több napi kézi feladat és számos hibaforrás.

A fokozatos megközelítés nem egyenlő azzal, hogy a vállalat terv nélkül halad. Épp ellenkezőleg: szükség van egy olyan célarchitektúrára, amely megmutatja, mely fejlesztések épülnek egymásra, és mely ideiglenes megoldásokból nem szabad tartós függőséget létrehozni.

Milyen ajánlat alapján lehet jól dönteni?

Egy használható ajánlat nem csak egy végösszeget tartalmaz. Egyértelművé teszi, mi tartozik a feladatba, milyen feltételezésekkel készült a becslés, mely rendszerek és szereplők érintettek, milyen eredmény várható, és mi marad a vállalat felelőssége. A bizonytalanságokat nem elrejti, hanem kezeli.

Különösen összetett folyamatoknál érdemes a munkát feltárási és megvalósítási szakaszra bontani. Így a vezetés nem egy feltételezésekre épülő teljes projektet hagy jóvá, hanem először a döntéshez szükséges tényeket szerzi meg. A második szakaszban már pontosabb hatókörrel, reálisabb ütemezéssel és kisebb üzleti kockázattal lehet továbbmenni.

A CGAT megközelítésében ezért a technológiai döntés a folyamat megértése után következik. Néha az eredmény integráció vagy automatizálás, máskor egy egyszerűbb munkarend, tisztább felelősségi kör vagy megbízhatóbb adatkezelés. A jó fejlesztés nem feltétlenül a legnagyobb projekt, hanem az, amelyik tartósan csökkenti a működési bizonytalanságot.

A folyamatfejlesztés akkor válik jó üzleti döntéssé, amikor nem azt kérdezzük, mennyibe kerül egy rendszer, hanem azt: melyik napi súrlódást érdemes megszüntetni ahhoz, hogy a növekedés ne több adminisztrációt, hanem kiszámíthatóbb működést hozzon.