Legutóbbi cikkem az RPA projektek sikeréhez kulcsfontosságú tényezőkről szólt, ez alkalommal pedig olyan feltételekről írok, amelyek fennállása esetén a biztos összeomlás várhat ránk a robotok fejlesztései során. Így ezek megelőzésére már akkor figyelmet tudunk fordítani, amikor még csak kezdetlegesen jelennek meg a projektjeinkben.

Nem tudjuk összepárosítani az üzleti igényeket a technológiai lehetőségekkel

A fejlesztések megkezdése előtt rendkívül fontos, hogy legalább egy szakértőnk átfogóan megértse az üzleti oldalról érkező igényeket, és azokat sikeresen összehangolja a technológia nyújtotta lehetőségekkel.

Kifejezetten rossz felállás, ha az üzleti elemzőink kizárólag az üzleti oldalról rendelkeznek szaktudással, míg a fejlesztőink csupán a technológiai vonulatát értik a robotizálásnak, és nincs olyan szakértőnk a szervezetben, aki a két tudás közötti szakadékot át tudná hidalni.

Tapasztalataim szerint ahol a tudás áthidalása nem történik meg a felek között, legtöbbször annak tudható be, hogy a robotfejlesztők számára rendkívül korlátozottan biztosítanak lehetőséget az üzleti oldallal történő kommunikációra. Ezt azzal indokolják, hogy a kapcsolattartás és az igények felmérése, megértése, átadása kizárólag az üzleti elemzők feladata. Így az üzleti elemzők kvázi akadályként funkcionáltak ahelyett, hogy a megértést segítették volna elő, annak ellenére, hogy kulcsfontosságú tartalmak vesztek el a kommunikáció során, részben a félreértésekből, részben pedig a meg nem értésekből kifolyólag.

A probléma megoldása viszonylag egyszerű. Amikor ez felmerül, a fejlesztőknek lehetőséget kell teremteni arra, hogy szükség esetén közvetlenül kommunikálhassanak az üzleti oldal szakértőivel. Utóbbiak ezt a folyamatot a mindennapok során végzik, el tudják mondani a fejlesztőknek a folyamatlépések minden vonatkozását.

Sokat ígérünk, de alulteljesítünk

Ez egy klasszikus hiba, amikor a pontatlan becsléseink visszaütnek ránk. A projekt elején ugyanis nem biztosítottuk a tudásáthidalást, azaz nem értjük a folyamat lényegét, és/vagy egyáltalán nem egy stabil folyamatot választottunk ki a robotizáláshoz. Így feltérképezni sem kifejezetten tudjuk a lépéseit.

A UiPath jól átgondolt Robotmegoldás Tervezési útmutatójának talán egyik legfontosabb üzenete, hogy a fejlesztési idők becslése a legnehezebb feladat. Azt ugyanis olyan megoldásra kellene megadni, amelyet még sohasem készítettek el azelőtt, így viszonyítási alap híján csak számos bizonytalan komponenssel rendelkezünk.

A három legnagyobb hiba, amelyet ilyenkor elkövethetünk:

1. Felállítjuk a becslést és a fejlesztés hatókörét még azelőtt, hogy bárki olyan látta volna a folyamatdokumentációt, aki magas szintű robotfejlesztési szaktudással rendelkezik. A hatókörök és határidők felállításánál a folyamatos bólogatás a vállalaton belüli politikai erőviszonyoktól függetlenül nem a legcélravezetőbb megközelítés, inkább a biztos kudarc garanciája.
2. Az egyes lépések fejlesztési komplexitása helyett a becsléseket a folyamatlépések száma alapján határozzuk meg, pedig nem minden lépést ugyanolyan egyszerű automatizálni.
3. A robotfejlesztők képességeit/gyorsaságát és a vállalaton belüli bürokrácia szintjét nem vettük figyelembe akkor, amikor a puffer-időket kalkuláltuk. Ez okból kifolyólag az RPA robotok építése számos szervezet számára nem sprint, hanem maraton.

Ezt a problémát már nem annyira egyszerű megoldani. Szükség van egy robottervező szakemberre, aki érti az üzleti és a technológiai oldal szempontjait is, aki pontosan be tudja határolni a projektek folyamatokon belüli hatókörét, és meg tudja becsülni a fejlesztési időket is.

Nem a megfelelő eszközt választottuk

Jelenleg 3 vezető robotfejlesztő eszközt (Blue Prism, UiPath, Automation Anywhere) találhatunk a piacon, azonban egyikük sem univerzális eszköz. Ha csupán egyikükkel rendelkezünk, azzal  igencsak korlátozzuk az automatizálás-optimalizálási lehetőségeinket. Természetesen minden probléma csak egy szögnek tűnik, ha csak egy kalapácsunk van a megoldására. Ám egy svájci bicskával sem állunk neki füvet nyírni adott esetben, bármennyire is sokoldalú az eszközünk első ránézésre.

A folyamat komplexitása és logisztikája határozza meg azt, hogy mennyire fejlett eszközre van szükségünk. Az eszközválasztás során még figyelembe kell vennünk, hogy milyen rendszereket használunk a folyamat során, mennyire van szükség rugalmas és skálázható megoldásra, illetve mennyire komplex bemeneti adatokkal és kimeneti eredményekkel kell operálnia a robotunknak.

Ennek megoldása már kifejezetten nehéz. Olyan szakemberre van hozzá szükség, aki tisztában van a legfőbb eszközök képességeivel, és aki meg tudja állapítani, hogy az egyes folyamatokat mely eszközzel lehetne a leghatékonyabban automatizálni.

Elkendőzzük a valóságot

Véleményem szerint mind közül ez a körülmény okozza a legtöbb bonyodalmat az RPA fejlesztések során. Katasztrofális következményei szoktak lenni annak, ha kiderül, hogy elkendőztük a projektek valós státuszát.

Tegyük fel, hogy:

1. A folyamat feltérképezésénél súlyos hibákat vétettünk, így a robotfejlesztők egyáltalán nem értik azt a folyamatot, amelyet automatizálniuk kellene.
2. A határidő a folyamatosan felmerülő problémák miatt így már nem tartható, valaminrt a fejlesztők továbbra sem kapnak lehetőséget arra, hogy az üzleti oldallal rendszeresen és közvetlenül egyeztessenek a gyors megoldás érdekében.
3. A projekt hatóköre időközben már elcsúszott, így a robotterveinket is kidobhatjuk a lomtárba, de ezt már csak két héttel a projekt indulása után vettük észre, amikorra már a robot felét le kellett volna fejlesztenünk.
4. Ezt követően realizáljuk, hogy a választott RPA eszközünk nem alkalmas arra, hogy megfelelően kezelje azokat a rendszereket és alkalmazásokat, amelyekre rá akarjuk építeni a robotunkat.

Miután a fentiek bekövetkeztek, valami megmagyarázhatatlan oknál fogva továbbra is zöld státusz jelentik meg a jelentéseinkben, és egyetlen nappal sem tolódott el a projekt záródátuma, annak ellenére, hogy már teljesen nyilvánvaló, hogy azt nem lehet betartani.

Az igazat megvallva az elkendőzést nagyon nehéz beazonosítani a projektcsapaton kívülről. Hüvelykujjszabályként azonban elmondható, hogy ha a projektek túl jól mennek ahhoz, hogy ezt el is higgyük, valószínűleg nem csalnak a megérzéseink: valaki elkendőzi a valós státuszt, így előtörhet majd egy látens probléma.

A legagilisabb megközelítés ilyen esetben az lenne, hogy a projektek fejlesztőit félúton megkérjük, hogy mutassák be az eddig elkészült robotkomponenseket működés közben. Amennyiben ezt nem tudják megtenni, úgy biztosra vehetjük, hogy a határidő betartásával baj lesz.

A problémát a természeténél fogva nagyon nehéz megoldani, mert az a következményektől való félelemből fakad. Amennyiben nem kivitelezhető opció, hogy bizalomra építsük csapataink hozzáállását, érdemes segítséget kérnünk egy olyan szakembertől, aki objektívan fel tudja mérni az egyes projektek valós státuszát.

Sprintelni akarunk, mielőtt járni tanulnánk

 Az RPA nem az azonnali nagy győzelmek terepe. Azt követően, hogy néhány apró folyamaton keresztül bebizonyítottuk a koncepció életképességét, sok szervezet akkora önbizalmat szerez hirtelen, hogy egyből hozzá is látnak a legmagasabb komplexitású folyamataik automatizálásához, attól a ténytől függetlenül, hogy a legtöbb fejlesztőjük épphogy csak megtanulta az RPA eszközök alapszintű használatát, és még nem állt fel a szervezeten belüli folyamat (ún. leszállítási metodológia) arra, hogy hogyan kell az elejétől a végéig lefejleszteni egy robotmegoldást.

Már az elején hibásan lefejleszteni egy nagy és magas komplexitású folyamatot 3 dolgot eredményezhet:

1. Alacsony morál az üzleti és az RPA oldalon is, mivel nincsenek sikertörténeteik, viszont az elhibázott fejlesztések javítása jelentős időt és energiát emészt fel, és senki sem elégedett az elért eredményekkel.
2. Rossz alapokat teremtünk a jövőbeli projekteknek. Mivel nem kezdtünk piciben, a fejlesztőknek nem volt idejük arra, hogy kísérletezzenek a fejlesztői eszközökkel, és hogy elsajátítsák az eszköz használatának legjobb módjait. Ez középszerű kompetenciát és alacsony eszközértést eredményez, ami nem kifejezetten szerencsés kombináció.
3. Mivel a fejlesztések során a robotkomponensek újrahasznosíthatósága, illetve strukturálása nem volt szempont (hiszen azt sem tudták, hogy ilyen létezik), a fejlesztői csapat folyamatosan le fogja fejleszteni ugyanazokat a komponenseket újra és újra. Ezzel nem érünk el fejlesztési megtakarítást a jövőben.

A megoldás nehézsége ez esetben jelentősen függ attól, hogy ezeket a hibákat már elkövettük-e vagy sem. Amennyiben még nem követtük el, akkor nagyon egyszerű, csupán biztosítanunk kell, hogy kicsiben indítsuk el az RPA programot. Amennyiben már elkövettük, akkor álljunk meg, és lépjünk kettőt hátra! Alakítsuk ki a leszállítási metodológiánkat, képezzük ki az RPA csapatunkat, stabilizáljuk az infrastruktúránkat, javítsuk meg rendesen vagy elsüllyedt költségként állítsuk le teljesen az elején elrontott robotokat! Ezt követően újra nekiláthatunk az új projektek beindításához.

Összefoglalva

A fentiekből arra a következtetésre juthatunk, hogy az RPA projektek nem azért omlanak össze, mert az agilis módszertant nem használtuk a fejlesztések során. A projektjeink főként azért dőlnek össze, mert a módszertannak teljesen hiányoznak bizonyos alapvető elemei, azok, amelyek anélkül is megállnák a helyüket, hogy elsősorban az agilitásra gondolnánk.

A szerző az IFUA Horváth & Partners vezető tanácsadója