Hogyan tervezzünk kis kockázatú fejlesztéseket

Egy webshop rendelései megérkeznek, de valakinek minden reggel át kell másolnia őket az ügyviteli rendszerbe. A raktár más készletadatot lát, mint az értékesítés, péntekenként pedig három ember gyűjti össze a vezetői riport számait. Ilyen helyzetben a hogyan tervezzünk kis kockázatú fejlesztéseket kérdése nem elsősorban technológiai feladat. Először azt kell megérteni, hogyan lett a napi működés ennyire függő a kézi átvitelektől, táblázatoktól és egyes kollégák tudásától.

A kockázat csökkentése nem azt jelenti, hogy a vállalat ne változtasson. Azt jelenti, hogy a változásnak világos üzleti oka, jól körülhatárolt határa és ellenőrizhető következménye van. Egy jól megtervezett kisebb fejlesztés közben is működőképes marad a cég: a számlák elkészülnek, a rendelések teljesülnek, a termelés nem áll le, és az érintett munkatársak tudják, mi történik.

A fejlesztés kockázata gyakran már a folyamatban benne van

Sok szervezet ott követ el hibát, hogy egy bosszantó tünetre azonnal rendszert vagy automatizálást keres. Ha a számlázás késik, új számlázómodult kérnek. Ha nincs jó riport, új dashboardot. Ha túl sok az e-mail, bevezetnének egy új munkafolyamat-kezelőt.

Ezek a megoldások indokoltak lehetnek, de nem mindig. Elképzelhető például, hogy a számlázás azért késik, mert a rendelési adatok három különböző helyen szerepelnek, és nincs tisztázva, melyik a hiteles forrás. A dashboard pedig csak gyorsabban mutatná meg ugyanazokat a hibás vagy késve rögzített adatokat.

A legnagyobb működési kockázat gyakran nem maga a régi rendszer. Hanem az a folyamat, amelyben emberek szolgálnak kapcsolatként rendszerek, osztályok és információforrások között. Ha egy munkatárs szabadságra megy, a folyamat lelassul. Ha elír egy cikkszámot, a hiba továbbhalad a raktárba, a számlázásba vagy az ügyfélkommunikációba. Ha egy táblázat tulajdonosa nem elérhető, senki sem biztos abban, melyik verziót kell használni.

Ezért kis kockázatú fejlesztést nem egy képernyővel vagy egy technológiával érdemes kezdeni, hanem egy konkrét üzleti folyamattal.

Hogyan tervezzünk kis kockázatú fejlesztéseket a gyakorlatban?

A jó kiindulópont egy olyan folyamat, amely elég fájdalmas ahhoz, hogy megérje javítani, de elég jól körülhatárolható ahhoz, hogy ne nyissa ki egyszerre az egész vállalat működését. Ilyen lehet a webshoprendelések átadása a raktárnak, a beszállítói dokumentumok feldolgozása, a szervizigények nyilvántartása vagy egy rendszeresen kézzel összeállított vezetői riport.

A kiválasztott folyamatnál érdemes végigkövetni, mi történik valójában. Nem azt, amit az eljárásrend mond, hanem amit a kollégák nap mint nap csinálnak. Honnan érkezik az információ? Ki ellenőrzi? Hányszor írják be ugyanazt az adatot? Hol várakozik egy feladat jóváhagyásra? Melyik lépésnél telefonálnak vagy írnak e-mailt azért, mert a rendszerből nem derül ki valami?

A folyamat feltérképezése sokszor gyorsan felszínre hozza, hogy egy lépésnek már nincs valódi célja. Lehet, hogy egy táblázatot évekkel korábban azért vezettek be, mert az akkori rendszer nem tudott egy adatot kezelni. Közben a rendszer változott, a táblázat viszont megmaradt, és ma már csak plusz ellenőrzést, másolást és bizonytalanságot termel.

A fejlesztési cél legyen üzleti nyelven megfogalmazható. Nem az a cél, hogy „integráljuk a rendszereket”, hanem például az, hogy a webshopos rendelés adatai kézi rögzítés nélkül, ellenőrizhetően eljussanak a teljesítésért felelős csapathoz. Nem az, hogy „készítsünk AI-megoldást”, hanem hogy a beérkező dokumentumokból a kollégák gyorsabban találják meg azokat az adatokat, amelyekre döntéshez szükségük van.

Kisebb hatókör, valódi eredmény

A túl nagy első lépés kiszámíthatatlanná teszi a projektet. Ha egy fejlesztés egyszerre érinti az értékesítést, a raktárt, a beszerzést, a számlázást és a pénzügyet, a döntések száma gyorsan nő. Minden kivétel, régi szabály és eltérő munkamód újabb egyeztetést igényel. Mire a megoldás elkészülne, maga az üzleti igény is megváltozhat.

Érdemes inkább egy olyan első szakaszt kialakítani, amely önmagában is értéket ad. Például ne a teljes rendeléskezelési láncot alakítsák át elsőként. Először csak azt biztosítsák, hogy a webshopból érkező rendelések egységes formában, automatikusan megjelenjenek a belső operációs rendszerben. A következő szakaszban lehet kezelni a készletfoglalást, majd a fuvarozói átadást vagy az ügyfélértesítéseket.

Ez nem lassabb megközelítés. Gyakran gyorsabban hoz kézzelfogható eredményt, miközben csökkenti annak esélyét, hogy egy feltételezés miatt az egész projekt rossz irányba induljon. Az első szakasz használata közben ugyanis kiderül, hogy az eredeti elképzelés helyes volt-e, és milyen kivételekkel kell valójában számolni.

A hatókör szűkítése nem jelentheti azt, hogy figyelmen kívül hagyjuk a későbbi bővítést. A megoldásnak úgy kell illeszkednie a rendszerkörnyezetbe, hogy később ne kelljen eldobni. Ezért már az elején tisztázni kell az adatgazdákat, a rendszerkapcsolatokat, a jogosultságokat és azt, mi számít hivatalos üzleti adatnak.

A kockázatot mérési pontokkal lehet kezelni

Egy fejlesztés akkor irányítható, ha a vezetés nem csak azt látja, hogy „készül”, hanem azt is, hogy javul-e tőle a működés. Ehhez nem szükséges bonyolult mutatórendszer. Egy rendelési folyamatnál lehet mérni a kézi adatbevitelre fordított időt, a hibás rendelések számát, az átfutási időt és azt, mennyi kivételt kell embernek kezelnie.

A mérésnek a változtatás előtt is el kell kezdődnie. Ha nincs kiinduló érték, később csak benyomások alapján lehet vitatkozni arról, hogy megérte-e a fejlesztés. Az is előfordulhat, hogy az új folyamat eleinte lassabbnak tűnik, mert láthatóvá tesz olyan ellenőrzéseket, amelyeket korábban informálisan vagy következetlenül végeztek el. Ez nem feltétlenül kudarc. Meg kell érteni, hogy a lassulás átmeneti tanulási hatás, szükséges kontroll vagy valódi tervezési probléma.

A siker feltételeit előre ki kell mondani. Például: a napi rendelések 95 százaléka kézi másolás nélkül feldolgozható; a raktár ugyanazt az állapotot látja, mint az ügyfélszolgálat; a pénzügyi riport elkészítése három óráról harminc percre csökken. A konkrét cél segít eldönteni, mikor lehet továbblépni, és mikor kell még javítani.

Bevezetés: nem a telepítés napján dől el minden

A technikailag elkészült megoldás még nem feltétlenül működő üzleti megoldás. A bevezetés során derül ki, hogy a kivételes esetek, a felelősségi körök és a napi munkaritmus valóban kezelhető-e. Ezért célszerű először korlátozott körben használni az új folyamatot: egy termékcsoportnál, egy telephelyen, egy ügyféltípusnál vagy egy kijelölt csapatnál.

A párhuzamos működés bizonyos esetekben indokolt, de nem szabad korlátlan ideig fenntartani. Ha a régi és az új folyamat túl sokáig együtt él, a munkatársak kétszer dolgoznak, az adatok eltérhetnek, és senki sem tudja, melyik rendszernek higgyen. Jobb előre meghatározni, meddig tart az ellenőrzött próbaidőszak, ki hagyja jóvá az eredményét, és milyen feltétel teljesülésekor válik az új eljárás az elsődlegessé.

A visszaállítási terv szintén a kockázatkezelés része. Nem azért kell, mert a fejlesztésnek várhatóan hibáznia kell, hanem mert az üzletmenetet védeni kell. Ha egy integráció hibás adatot küld, tudni kell, hogyan állítható meg, hogyan azonosíthatók az érintett tranzakciók, és ki dönt a korrekcióról. Egy jól dokumentált visszaállítási lehetőség magabiztosabbá teszi a bevezetést is.

Az emberek tudása ne maradjon rejtett rendszerkomponens

A növekvő vállalatokban gyakori, hogy egy kulcsember fejben tartja a kivételeket: melyik vevőnek milyen formátumban kell dokumentumot küldeni, melyik beszállító adatait kell külön ellenőrizni, vagy miért nem szabad egy bizonyos rendelést automatikusan átadni. Ez értékes tapasztalat, de üzleti kockázat, ha csak egy embernél létezik.

A kis kockázatú fejlesztés célja nem az, hogy ezt a kollégát kiváltsa. Inkább az, hogy a tudása ellenőrizhető szabályokban, látható státuszokban és közösen használható munkafolyamatban jelenjen meg. Így ő kevesebb időt tölt ismétlődő adminisztrációval, és többet azzal, ahol valóban mérlegelésre, ügyfélismeretre vagy szakmai döntésre van szükség.

A dokumentáció legyen rövid, de használható. Egy új folyamatnál a csapatnak tudnia kell, mi változott, mit kell tennie hiba esetén, kihez fordulhat, és milyen adatot nem módosíthat szabadon. A működési felelősség tisztázása legalább olyan fontos, mint maga a fejlesztési feladatlista.

A legjobb első fejlesztés nem feltétlenül a leglátványosabb. Gyakran az az értékes, amelyik megszüntet egy napi félórás másolást, láthatóvá tesz egy elakadt rendelést, vagy függetleníti a folyamatot egyetlen táblázattól. Ezek a lépések nemcsak időt takarítanak meg: bizonyítékot adnak arra, hogy a vállalat működése kontrolláltan, a következő nagy ugrás kockázata nélkül is fejleszthető.