A folyamatoptimalizálási projekt teljes útmutatója

Valaki minden reggel letölti a webshop rendeléseit, átmásolja őket egy táblázatba, majd továbbküldi a raktárnak. Délután egy másik kolléga ugyanezeket az adatokat rögzíti a számlázóban. A munka megszokottá vált, mégis egyre több időt, egyeztetést és hibajavítást igényel. A folyamatoptimalizálási projekt teljes útmutatója nem azzal kezdődik, hogy milyen rendszert kell megvenni, hanem azzal, hogy pontosan megértsük: mi történik ma, miért történik így, és mi akadályozza a megbízhatóbb működést.

Egy jól vezetett projekt nem egyszerűen gyorsabbá tesz néhány feladatot. Láthatóvá teszi a munkafolyamatokat, csökkenti az egyes emberektől való függést, javítja az adatok minőségét, és olyan működési alapot ad, amely a növekedéssel sem esik szét.

Mikor indokolt folyamatoptimalizálási projektet indítani?

A legtöbb vállalat nem azért kezd bele, mert szereti a folyamatábrákat. Hanem azért, mert a napi működés egy ponton elkezd túl sok figyelmet kérni a vezetőktől. Az értékesítés növekszik, de vele együtt nő az adminisztráció is. A havi vezetői riport elkészítése napokig tart. A raktár, a pénzügy és az ügyfélszolgálat eltérő információkból dolgozik. Egy szabadságon lévő munkatárs nélkül pedig megáll egy kritikus ügyintézési lépés.

Ezek nem elszigetelt emberi hibák. Általában annak a jelei, hogy a korábban még működő munkamódszer már nem illeszkedik a vállalat méretéhez, ügyfélszámához vagy rendszerkörnyezetéhez.

Különösen indokolt a vizsgálat, ha a munkatársak ugyanazt az adatot több helyen rögzítik, a részlegek e-mailben és táblázatokban adják át egymásnak a feladatokat, vagy a vezetés nem tud gyorsan megbízható választ kapni alapvető működési kérdésekre. Ilyen kérdés lehet például, hogy hol állnak a rendelések, melyik termékcsoport késik rendszeresen, vagy mennyi idő telik el egy ajánlatkérés és a teljesítés között.

A folyamatoptimalizálási projekt teljes útmutatója a valós működéssel kezdődik

Az első hiba, amit érdemes elkerülni, a feltételezésekre épülő tervezés. A hivatalos folyamatleírás gyakran nem mutatja meg, hogyan készül el ténylegesen egy rendelés, egy gyártási utasítás vagy egy reklamáció kezelése. A valódi folyamatban lehetnek telefonhívások, személyes egyeztetések, privát táblázatok és olyan ellenőrzések, amelyekről csak az adott munkatárs tud.

Ezért az első szakasz célja nem a megoldás kiválasztása, hanem a jelenlegi működés feltárása. Egy rendeléstől vagy ügyféligénytől indulva végig kell követni, milyen lépéseken halad át a munka, ki felel az egyes pontokért, milyen rendszerek és dokumentumok érintettek, illetve hol várakozik az információ.

A jó feltárás nem csak azt kérdezi, hogy „ki csinálja ezt?”, hanem azt is, hogy miért szükséges ez a lépés. Valóban kell-e minden rendelést kézzel ellenőrizni? Miért kerül ugyanaz az ügyféladat három rendszerbe? Miért csak pénteken derül ki, hogy egy beszállítói információ hiányzik? Egy régi kontroll lehet indokolt, de az is lehet, hogy egy korábbi rendszerhiba vagy egy rég megszűnt üzleti kockázat miatt maradt a folyamatban.

A folyamat nem egyenlő az osztályokkal

Sok fejlesztési kezdeményezés azért akad el, mert részlegenként vizsgálja a munkát. A pénzügy saját problémát lát, a raktár másikat, az értékesítés pedig egy harmadikat. Az ügyfél vagy a rendelés viszont ezek között a területek között mozog. Ha az átadás pontatlan, késedelmes vagy manuális, az egész folyamat romlik, hiába dolgozik jól külön-külön minden csapat.

A vizsgálatnak ezért végponttól végpontig kell gondolkodnia. Egy webshopos rendelés például a vásárlással indul, de érintheti a készletinformációt, az ERP-t, a számlázást, a komissiózást, a futárszolgálatot, az ügyfélértesítést és a pénzügyi egyeztetést is. A problémát gyakran nem egyetlen rendszer okozza, hanem az, hogy az információk között emberek végzik el az összekötést.

A szűk keresztmetszetek rangsorolása

Egy alapos felmérés rendszerint több tucat javítási lehetőséget tár fel. Nem kell mindent egyszerre megoldani. Sőt, a túl széles projekt gyakran azért veszít lendületet, mert túl sok folyamatot, rendszert és érintettet próbál egyszerre megváltoztatni.

A prioritásokat üzleti hatás alapján érdemes kijelölni. Mekkora időráfordítást okoz egy probléma? Hányszor fordul elő? Mekkora a hibakockázat? Érinti-e az ügyfélélményt, a bevételt, a készletet vagy a szabályozói megfelelést? Mi történik, ha a folyamatot ismerő egyetlen munkatárs kiesik?

Nem mindig a leglátványosabb fejlesztés hozza a legnagyobb eredményt. Előfordulhat, hogy egy egyszerű, de naponta százszor végzett adatellenőrzés megszüntetése több kapacitást szabadít fel, mint egy összetett, hosszú bevezetésű rendszerprojekt. Más esetben viszont egy kritikus gyártási vagy logisztikai átadás megbízhatósága fontosabb, mint a megtakarított percek száma.

A döntéshez érdemes minden fejlesztési jelöltet ugyanazon szempontok szerint értékelni: várható üzleti eredmény, bevezetési ráfordítás, technikai kockázat, függőségek és változáskezelési igény. Így a vezetés nem benyomások, hanem összehasonlítható információk alapján tud sorrendet felállítani.

Előbb egyszerűsítés, utána technológia

A rosszul működő folyamat automatizálása csak gyorsabban termeli a rossz eredményt. Ha egy munkatárs három rendszerből gyűjt adatot egy heti jelentéshez, elsőként azt kell megérteni, mely adatokra van valóban szükség, ki használja őket, és miért nincs egyértelmű adatforrásuk.

Lehet, hogy a helyes válasz egy jóváhagyási lépés elhagyása. Lehet szerepkörök és felelősségek tisztázása, egységes adatmegadás vagy egy mérési pont beépítése. Csak ezután lehet eldönteni, hogy rendszerintegráció, workflow-automatizálás, egyedi alkalmazás, riportingmegoldás vagy meglévő rendszer átalakítása indokolt-e.

A technológiai választás mindig helyzetfüggő. Egy 30 fős kereskedelmi vállalatnál nem feltétlenül indokolt egy nagyvállalati rendszer bevezetése, ha néhány kritikus adatkapcsolat és a rendelésfeldolgozás rendbetétele oldja meg a problémát. Ugyanakkor egy gyorsan növekvő gyártó vagy többcsatornás kereskedő számára a rövid távú, kézi kerülőmegoldások később komoly működési kockázatot jelenthetnek.

Tervezés, felelősség és kontroll

A megvalósítás előtt egyértelműen rögzíteni kell, hogyan néz ki a jövőbeli folyamat. Nem elég annyit mondani, hogy „a rendszer majd automatikusan átadja az adatot”. Tudni kell, mi indítja el az átadást, melyik rendszer a hiteles adatforrás, mi történik hiányos adat esetén, ki kap értesítést, és hogyan lehet visszakeresni egy hibás vagy elakadt ügyet.

Ez különösen fontos olyan környezetben, ahol pénzügyi, készlet-, gyártási vagy ügyféladatok mozognak a rendszerek között. A működésnek ellenőrizhetőnek kell lennie. Egy integráció akkor jó, ha nemcsak normál helyzetben működik, hanem hiba esetén is látható, kezelhető és helyreállítható.

A projektgazda üzleti oldalról felel azért, hogy a változás valódi problémát oldjon meg. Az érintett munkatársak pedig nem pusztán tesztelők: ők tudják megmutatni, hol ütközik a terv a napi valósággal. Ha az új folyamat több kivételt kezel, mint a régi, vagy többletmunkát terhel rájuk, azt még az éles indulás előtt fel kell tárni.

Mérni kell, hogy valóban jobb lett-e a működés

A siker nem az élesítés napján dől el. Akkor derül ki, hogy egy fejlesztés eredményes-e, amikor a vállalat össze tudja hasonlítani a korábbi és az új működést. Érdemes már a projekt elején meghatározni néhány üzleti mérőszámot: átfutási idő, hibaarány, manuális érintések száma, függő feladatok mennyisége, készleteltérés, ügyfélválaszidő vagy riportkészítésre fordított munkaóra.

Nem minden eredmény azonnal számszerűsíthető. Az is érték, ha egy folyamat átláthatóbbá válik, egy új kolléga gyorsabban betanul, vagy a vezetőnek nem kell több embertől információt kérnie ugyanahhoz a döntéshez. Ezek azonban akkor maradnak tartós eredmények, ha a folyamatnak van gazdája, dokumentált szabálya és rendszeres felülvizsgálata.

A legjobb következő lépés általában nem egy nagy technológiai döntés. Válasszanak ki egy olyan visszatérő folyamatot, amely naponta időt visz el, több területet érint, és rendszeresen hibát vagy késést okoz. Kövessék végig elejétől a végéig, kérdezzék meg, miért létezik minden egyes lépés, majd csak ezután döntsenek arról, mit érdemes megváltoztatni. Innen indul a kiszámíthatóbb működés.