Volt egy ügyfelünk — 180 fős magyar gyártó cég — aki azzal jött, hogy automatizálni szeretné a rendelés-feldolgozását. Heti 22 órát töltöttek kézi adatbeírással, Excel-táblák másolásával, e-mailek váltásával. Az ajánlatok, amiket bekértek, 18 és 45 millió forint között mozogtak.
Mi mást csináltunk. Nem ajánlatot adtunk, hanem kérdéseket tettünk fel. Egy napot töltöttünk velük — a folyamatot értve, nem a megoldást tervezve. És ami kiderült, az tipikus volt.
A tünet és az ok különbsége
A heti 22 óra valódi volt. De miért tartott 22 óráig? Az első válasz: "mert minden manuális." Ez tünet. A második válasz: "mert az ERP-ből ki kell exportálni, át kell másolni a CRM-be, onnan az ügyfélnek küldött táblázatba." Ez is tünet. A harmadik válasz után — miért kell háromfelé vinni ugyanazt az adatot? — jött az igazi ok: mert a három rendszer soha nem volt összekapcsolva, és senki nem döntötte el, melyik az egyetlen forrás az igazságnak.
Ez nem technikai probléma. Ez szervezeti döntés hiánya.
Az automatizáció a legjobb esetben megoldja a problémát. A legrosszabb esetben gyorsabban csinálja azt, ami egyébként sem kellene.
A 3 szűrő — sorrendben
A Footbridge minden folyamatra három kérdést tesz fel, ebben a sorrendben. Az első kérdés megválaszolása nélkül nem megyünk a másodikra.
1. Megszüntethető?
Ez a legkellemetlenebb kérdés, mert sokszor a válasz igen. Folyamatok azért léteznek, mert valaha valaki létrehozta őket — de az az ok, ami miatt létrehozták, már régen nem áll fenn. A folyamat él tovább, mert senki nem kérdőjelezte meg.
A fenti gyártó cégnél: a CRM-be való másolás csak azért történt, mert régen a sales csapat ott követte nyomon az ajánlatokat. De két éve bevezettük a projektmenedzsment-eszközt, ami ezt átvette. A CRM-be való másolás automatikusan, reflexből ment tovább — heti 6 óra munkával.
Ez a 6 óra nem volt automatizálható. Meg kellett szüntetni.
2. Áttervezhető?
Ha nem szüntethető meg, lehet-e egyszerűsíteni — automatizáció nélkül? Párhuzamossá tehető? A soros folyamat párhuzamossá tétele önmagában felezi az átfutási időt.
A leggyakoribb eset: jóváhagyási körök. Egy ajánlat kiment az ügyfélnek, visszajött módosítással, elment a pénzügynek, visszajött, elment a vezetőnek, visszajött. Négy-öt kör, mindegyik 1-2 napos várakozással. Ha ezek párhuzamosak — pénzügy és vezető egyszerre látja — az átfutási idő a felére csökken. Automatizáció nélkül.
3. Automatizálható?
Csak ami az első két szűrőn átment, az kap automatizációt. De ekkor már egy sokkal egyszerűbb, logikusabb folyamatra kerül az eszköz — és az eredmény tartós lesz.
A MoSCoW módszer: priorizálás automatizáció előtt
Mielőtt bármit automatizálunk, érdemes a MoSCoW módszerrel átgondolni, mit is akarunk valójában. A MoSCoW a PMI által is elismert priorizálási keretrendszer, amelyet az agilis projektek és a scope-meghatározás során egyaránt alkalmaznak.
- Must Have — Nélküle a projekt nem tud elindulni. Ez az egyetlen dolog, amit mindenképpen meg kell csinálni.
- Should Have — Fontos, de ha nem fér bele, a projekt még működik. Nagy értéket ad, de nem kritikus.
- Could Have — Jó lenne, ha megvalósul, de az elmaradása nem fáj. Ezek a "nice-to-have" elemek.
- Won't Have (this time) — Tudatosan kihagyjuk a mostani körből. Nem örökre, csak most.
Az automatizálandó folyamatokra alkalmazva: egy Must Have folyamat automatizálása előre viszi a munkát. Egy Won't Have folyamat automatizálása — bármennyire látványos is — csak energiát vesz el a valóban fontostól.
Gyors önellenőrzés: Az automatizálni tervezett folyamat Must Have vagy Should Have kategóriába esik? Ha Could Have vagy Won't Have — állj meg, és nézd meg, mi az, ami valóban blokkolja a haladást.
A Kano-modell és az "automatizáljuk, mert lehet" csapda
A Kano-modell — amelyet Noriaki Kano japán minőségkutató fejlesztett ki az 1980-as években — a funkciók és elvárások három szintjét különbözteti meg, és az automatizáció kapcsán is megvilágító erejű.
Az alapelvárások (Basic Needs) azok a dolgok, amelyek elmaradása azonnal elégedetlenséget okoz — de megléte sem okoz örömet. Ilyen egy számlafeldolgozó rendszernél: az adatok ne vesszenek el. Ez nem automatizálandó, ez alapkövetelmény.
A teljesítmény-attribútumok (Performance Attributes) azok, amelyek jobb teljesítménye direktben növeli az elégedettséget. Ha a számlafeldolgozás 15 napról 3 napra csökken — ez értéket teremt. Ide érdemes automatizációt vinni.
A meglepetés-elemek (Delighters) azok, amelyekre senki nem számított, de amint meglátja az ügyfél, azonnal szereti. Például: a rendszer automatikusan jelzi, ha egy partner kifizetési profilja megváltozik. Ezt senki nem kérte — de azonnal értékessé válik.
A csapda: sok szervezet az alapelvárásokra és meglepetés-elemekre optimalizál, miközben a valódi teljesítmény-attribútumok — ahol az automatizáció ténylegesen értéket teremt — elmaradnak.
Timeboxing: az automatizáció ütemezésének eszköze
Ha már eldöntöttük, mit automatizálunk, a megvalósítás ütemezése is kritikus. A timeboxing — egy PMI-keretrendszerből átvett technika — azt jelenti, hogy előre rögzített időkeretet adunk az automatizációs projektnek, és belátjuk: amit ebbe belefér, az megvalósul. Ami nem — az vagy a következő körre marad, vagy törlésre kerül.
Ennek az elvnek három előnye van az automatizáció kontextusában: először, megakadályozza a scope-creep-et — nem ragadunk bele az egyre bővülő funkcionalitásba. Másodszor, kikényszeríti a priorizálást — ha csak 3 hétünk van, mit csináljunk először? Harmadszor, korai eredményt ad — egy 3 hetes timebox végén látható valami, nem 6 hónap után.
A Footbridge "első híd" módszertana erre épül: 3 hét, fix scope, fix ár. Ami belefér, az megvalósul. A második híd csak akkor épül meg, ha az első megtérült.
Mikor érdemes automatizálni — összefoglalva
Automatizáció akkor hatékony, ha a folyamat: ismétlődő és kiszámítható, volumenproblémás (sok ismétlés, nem egyszeri elvégzés), emberi hibára érzékeny, és már egyszerű (az első két szűrőn átment).
Ha ezek közül bármelyik hiányzik, az automatizáció valószínűleg idő előtti. A legjobb automatizáció az, ami nem szükséges — mert a folyamatot már megszüntettük vagy átterveztük.
Az a projekt csapat, amelyik először kérdez és csak utána automatizál — kevesebbetkölt, gyorsabban ér eredményt, és tartósabb megoldást épít.