OLVASÁSI IDŐ: 7 PERC
Miután már írtam arról, szerintem hogyan érdemes minőségi robotokat fejleszteni, itt az ideje összeszedni, hogy jellemzően mely okok miatt bukhat el egy RPA* projekt – így talán idejekorán felismerhetőek lesznek a kockázatok és megfelelő megelőző lépésekkel sok fejfájástól megkímélhetjük magunkat.
Nem sikerül összhangba hozni a technológiát és az üzleti követelményeket
Kritikus fontosságúnak tartom, hogy még a robotfejlesztés megkezdése előtt legyen legalább egy olyan személy, aki érti az összes üzleti elvárást és képes azokat a rendelkezésre álló robotizációs technológiával kombinálni.
Nem szerencsés az a kiindulási helyzet, melyben az üzleti elemzők csak a projekt “üzleti részét” értik, míg a fejlesztők kizárólag a “technológiai megoldásra” koncentrálnak és a kettő között semmi és senki nem képez hidat.
A gyakorlatban azt láttam, hogy a “Megértés hídja” jellemzően azért nem tudott kialakulni, mert a fejlesztők nemigen férhettek hozzá közvetlenül az üzleti szakértők tudásához mondván, hogy “az üzleti követelményeket az üzleti elemzőnek kell lefordítania az informatika nyelvére és punktum”. Ily módon azonban az elemzők a megértés elősegítése helyett gyakran csak az információ áramlás akadozásához járultak hozzá, miközben a “fordítás” közben kulcsfontosságú üzenetek vesztek el az éterben…
A megoldás roppant egyszerű: az agilitásról való elmélkedés helyett segítsük elő, hogy a fejlesztők minél gyakrabban fordulhassanak kérdéseikkel az üzleti szakértőkhöz, hiszen utóbbiak azok, akik végrehajtják a kérdéses folyamatot és segíthetnek a fejlesztőknek megérteni az egyes lépések üzleti vonatkozásait is.
Nagyot ígérni, majd alulteljesíteni
Ez egy klasszikusnak mondható hiba, ami jellemzően vagy abból fakad, hogy – a folyamat és az elvárások megértése hiányában – pontatlanul becsüljük meg a várható hasznokat és ráfordításokat, vagy még csak stabilnak mondható, automatizálható folyamattal sem rendelkezünk.
A UiPath nagyon jó meglátásokkal segíti a Solution Designereket abban, hogyan is érdemes megbecsülni egy robot létrehozásának erőforrás-igényét. Az RPA platform fejlesztő cég szakértői ugyanakkor hangsúlyozzák mennyire nehéz meghatározni valaminek az erőforrás szükségletét, melyet számos bizonytalan tényező mozgat (és amely korábban még sohasem létezett…).
Különösen “kedvelem”, amikor az alábbi három ősbűn valamelyikével találkozok:
1. Meghatározzák a scope-ot és megbecsülik az erőforrás-igényt még azelőtt, hogy egy, a technológiában jártas szakember egyáltalán látta volna a célfolyamatot. Bólogatókra bízni a scope-olást és a projekt ütemezését garantált bukást fog eredményezni (bármennyire is nyomják a gázpedált a “vállalati politikusok”…).
2. Az erőforrásbecslést a folyamati lépések száma és nem azok komplexitása alapján végzik el.
3. Az ütemezés tervezésekor figyelmen kívül hagyják az RPA fejlesztők képességeit és a szervezeti bürökráciát. A legtöbb szervezetben jellemzően ezek miatt válik a robotfejlesztés sprint helyett maratoni futássá.
A problémára nincs egyszerű megoldás, a legjobb, ha a scope-olást és erőforrásbecslést olyan Solution Designerre bízzuk, aki átlátja a robotfejlesztés üzleti és technológiai aspektusait is (és nem kényszerítjük becslésekre pár mondatos feladat definíció alapján).
Nem a megfelelő eszközt választjuk
A globális piacon jelenleg három vezető RPA szoftver szállító is van (UiPath, Blue Prism and Automation Anywhere), ugyanakkor egyik sem nyújt minden robotizációs projekthez tökéletesen illeszkedő eszközt. Amennyiben egyetlen eszköz mellett köteleződünk el, az behatárolhatja optimalizációs lehetőségeinket. Ahogy mondani szokták mindent szögnek néz az, akinek kalapács van a kezében, ezért javaslom tartsunk magunknál svájci bicskát is, jól fog még az jönni (csak ne kezdjünk el vele füvet vágni)!
A folyamat jellege meghatározza milyen komplexitású eszközre van szükségünk az automatizáláshoz. Az automatizált rendszerek működési sajátosságain és a robot skálázhatósága terén fennálló elvárásokon túl a folyamat inputjainak és outputjainak komplexitását is érdemes figyelembe vennünk a megfelelő RPA eszköz kiválasztásakor.
A megoldás itt relatíve nehéz: olyasvalakire van szükségünk, aki ismeri mindhárom (na jó, legalább kettő fentebb említett) eszköz alapvető képességeit és össze tudja vetni azokat az automatizálni kívánt folyamatok támasztotta elvárásokkal.
A kirúzsozott malac esete
Azt kell mondjam, hogy a cikkben felvonultatott hibák közül a most következő okozza a legtöbb gondot az RPA projektekben. Amikor kiderül, hogy a dolgok állását a projekt során igencsak megszépítették, az jellemzően katasztrofális következményekkel jár.
Képzeljünk el egy elkapkodott folyamat- és igényfelmérést, melynek végén a fejlesztők nem értik a folyamatot, melyet automatizálniuk kell(ene). A felmerülő tengernyi probléma fényében a határidő nem reális, a fejlesztőket ennek ellenére nem engedik direktben egyeztetni az üzleti szakértőkkel (így esély sincs a gyors megoldásra). A scope a fejlesztés közben megváltozott, tehát a Solution Design mehet is a kukába, ám ezt csak két hét csúszással sikerült közölni, amikorra is a megoldás már félig le van fejlesztve. Mindennek tetejébe a kiválasztott RPA eszköz alkalmatlannak bizonyul az adott folyamat teljeskörű automatizációjára, így a fejlesztők vadul szkriptelnek, hogy betömjék az eszköz funkcionalitásán tátongó méretes lyukakat.
A fenti botladozás ellenére a projekt státusza valahogy még mindig ZÖLD, a határidő – bár nyilvánvalóan tarthatatlan – egy napot sem moccant és a kommunikáció az alábbi mémmel jól összefoglalható módon zajlik:
Őszintén szólva a szépítést és széltolást a projektcsapaton kívülről felismerni önmagában egy kihívás. Ha a zsigereinkben azt érezzük, hogy minden túl jól megy ahhoz, hogy igaz legyen, akkor valószínűleg nem tévedünk: valaki(k) valamit kiszínez(nek) és a felszín alatt rossz folyamatok zajlanak.
Minimális agilitást magunkra erőltetve kérdezzük meg a fejlesztőt a határideje felé félúton, hogy tud-e nekünk bármi működőképeset demózni a rábízott robotfunkcióból! Ha nem tud értékelhető előrehaladást felmutatni biztosak lehetünk benne, hogy valaki valamit nem jól csinál…
Kifejezetten nehéz megoldani az ilyen helyzeteket, mégpedig azért, mert a probléma gyökéroka a félelem. Hacsak nem tudunk az egész csapatban érvényesülő kölcsönös bizalmat kiépíteni és fenntartani, kénytelenek leszünk olyasvalakivel testközelből monitoroztatni a haladást, aki képes a teljesítményt valamelyest objektíven megítélni.
Előbb járni kellene megtanulni, aztán sprintelni
Az RPA nem az azonnali “aranyeső” terepe. Mégis előfordul, hogy egy kisebb pilot projektet követően a szervezet annyira elbízza magát, hogy rögtön a legbonyolultabb folyamatait jelöli ki automatizációra, miközben a fejlesztői még éppen hogy csak megtanulták használni az RPA eszközt, a leszállítási módszertant pedig még senki sem képes rutinszerűen alkalmazni.
Jó nagy, komplex, bugoktól hemzsegő robotmegoldások erőltetett bevezetése tipikusan három következménnyel szokott járni:
1. A lelkesedést mind az üzleti, mind az RPA oldalon apátia váltja fel, mert elmaradnak a sikersztorik és az idő nagy részét a robotok toldozása teszi ki.
2. Szilárd alapok hiánya: mivel nem kicsiben kezdték, a fejlesztőknek nem volt idejük kísérletezni az eszközzel és elsajátítani a legjobb gyakorlatokat. Következésképp közepes kompetenciájuk alacsony eszközismerettel párosul, ami nagyon rossz kombináció.
3. Mivel a strukturáltság és újrahasznosíthatóság nem voltak szempontok (hiszen nem is tudtak ezen szempontok létezéséről!), az RPA csapatnak újra és újra le kell fejlesztenie egyes komponenseket, ami egy az egyben ablakon kidobott idő.
A megoldás alapvetően attól függ, hogy már beleestünk-e ebbe a hibába, vagy még csak épp most készülünk elkövetni. Ha van még rá lehetőség, mindössze annyit kell tennünk, hogy kicsiben kezdünk robotizálni, odafigyelünk az alapok lefektetésére és némi türelmet erőltetünk magunkra. Amennyiben RPA programunk már erősen bukdácsol, lépjünk vissza kettőt, rakjuk rendbe a módszertanunkat és biztosítsunk extra időt a csapatnak a tudásbeli hiányosságok felszámolására. Új projektekkel csakis az infrastruktúra és az éles robotfolyamatok stabilizálását követően induljunk el!
Dióhéjban
Fentieket röviden úgy foglalhatjuk össze, hogy az RPA projektek jellemzően nem azért feneklenek meg, mert nem az Agilis Módszertant alkalmazták a fejlesztés során. A probléma általában véve inkább az, hogy megfeledkeztek egy-egy olyan kulcsfontosságú agilis módszertani elemről, melyet egyébként az agilitás ismeretének teljes hiányában is logikus lett volna alkalmazni. Ha Ön is szembesült a cikkben sorolt nehézségekkel, vagy kérdése van a folyamatok robotizálásával kapcsolatban írjon csapatunknak!
*Robotic Process Automation (Folyamatrobotizálás)
Fordította: Krizsán Olivér
Eredeti cikk: https://www.linkedin.com/pulse/rpa-project-has-collapsed-why-balint-laszlo-papp/
