OLVASÁSI IDŐ: 6 PERC
Van néhány olyan kérdés a robotizált folyamatautomatizálással (RPA*) kapcsolatban, amelyet még mindig nem sikerült megfejtenem, mivel a kérdésekre adott válaszok – véleményem szerint – nem egyértelműek. Néhány ilyen kérdés: Ki is pontosan az ügyfél, amikor RPA-megoldásokról beszélünk? Kinek az igényeit kell kielégíteni? Vannak-e magasabb szintű elvek, amelyekhez ragaszkodnunk kellene az ügyfél kívánságai ellenére is? Van egyáltalán valaki, aki megfelelően használja az agilis módszertant az RPA-projektjeiben? Egyáltalán, lehet-e az agilitást bármilyen módon hasznosítani az RPA-ban?
Hadd mutassam be a gondolatmenetemet, így talán érthetőbbé válik, miért is gondolom, hogy ezekre a kérdésekre adott válaszok határozzák meg az RPA-projektekben szállított minőséget.
Az elmúlt néhány évben a szoftverfejlesztési projektek jelenlegi gyakorlatának kritikájával kapcsolatban kerestem információt arról, hogyan is használják ezek a projektek az agilis módszertant. A különböző források egy dologban többnyire egyetértenek: még mindig nem értjük annak lényegét, hogy miért is fogalmazták meg eredetileg az Agilis Kiáltványt. A kulcsgondolat e Kiáltvány mögött az, hogy ha csupán még ötlet szinten létezik a termékünk, akkor erre az ötletre egész egyszerűen nem lehet teljeskörű megoldást építeni .
Így annak érdekében, hogy elkerüljük azt a problémát, hogy az ügyfél számára eleve elavult, vagy értéktelen megoldást szállítsunk le, elkezdünk kis lépésekben szállítani egy minimálisan életképes termék (Minimum Viable Product, „MVP”) alapján, és figyeljük, hogyan reagálnak az ügyfelek/felhasználók az éppen lefejlesztett funkciókra. Emellett adatokat gyűjtünk arról, hogy milyen gyakran használják, vagy hogy megfelelően tudják-e használni a funkciókat, ha egyáltalán megfelel az igényeiknek az adott fejlesztés.
Ehhez képest azonban két alapvető különbség is akad, amikor RPA-ról beszélünk:
- Szinte soha nem kell homályos ötletekre támaszkodunk. Van egy folyamat a kezünkben, amellyel valószínűleg már évek óta dolgoznak, még ha azt nem is dokumentálták és a folyamati tudás szájról-szájra terjed, mint egy népdal.
- Nincsen egyértelműen definiálva a felhasználó, akinek a megoldás meg kellene feleljen.
Ki az ügyfél?
Egy RPA-kezdeményezésnek (is) számos érintettje van. Ott a projektszponzor. A folyamatoknak vannak gazdáik, a folyamatok megvalósításával foglalkozó részlegek és valószínűleg van egy belsős RPA-csapat, amely a megoldásokat üzemelteti. Mindegyiküknek megvan a maga elképzelése arról, hogyan kellene kinéznie egy robotnak. Ha valamennyiük elképzeléseit bele akarjuk építeni a megoldásunkba, akkor a projekt szállítási ideje könnyen megtöbbszöröződhet, miközben érdemi többletérték nem keletkezik.
Ez az a pont, ahol két agilis alapelvet be kell vezetnünk:
(1) csak olyan funkciókat építsünk, amelyeket használni fognak és elengedhetetlen az érintettek számára,
(2) előszőr építsünk egy MVP-t, és később folytassuk a többi funkció fejlesztésével.
Tényleg az éjszaka kellős közepén akarnak riportot kapni a feldolgozatlan tételekről, miközben amikor másnap reggel megérkeznek az irodába, a megoldás már azokat a tételeket is feldolgozta? Tényleg ki kell színezni az Excel táblát, ami nyers adatokat tartalmaz egy weboldalról? Tízből kilenc esetben már nincs szükségük ezekre, amikor elkezdik látni, hogy az MVP remekül működik. Tapasztalatom szerint, ha mégis meggyőz minket az ügyfél arról, hogy nekik erre a funkcióra tényleg szükségük van, kb. 75% az esély arra, hogy végül mégsem fogják azt használni. Tehát nem kell túlságosan flancos megoldásokat létrehozni, a folyamatok túlnyomó többségéhez bőven elegendő egy jól működő MVP.
Felmerülhet bennünk a kérdés: mi számít egyáltalán a folyamatrobotizációban MVP-nek és a folyamatok mely szintjén kell azt alkalmazni? A teljes folyamatra? Annak egy részfolyamatára? Egy részfolyamat egy részére? Hol is kellene megállnunk? Nos, én általában azt szoktam tenni, hogy a folyamatokat olyan darabokra bontom, amelyek önmagukban is hasznos, értelmes eredményt produkálnak és megkeresem a mögöttük álló legfontosabb üzleti elvásárt, amely általában pénzügyi, vagy működési elveken alapul.
Üzleti elvárások és elvek, mint ügyfelek?
Az előző mondat talán kissé hosszú és zavaros volt, hadd fejtsem ki részletesebben. Vegyünk egy hatalmas folyamatot, mint például a fogyasztási hitelfolyamat. Daraboljuk azt fel értelmes eredményterméket előállító szakaszokra, mint például hitelkérelem, hitelbírálat, hitelfolyósítás stb. Keressük meg az ezek mögött álló legfontosabb üzleti elvárásokat. Például a hitelfolyósítás fő célja az, hogy az ügyfelek – pozitív hitelbírálatot követően – a megadott bankszámlaszámukra megkapják az igényelt összeget. Ha így teszünk a fő üzleti elvárások lehetnek a mi legfontosabb RPA „ügyfeleink” és elkerülhetjük a hosszas vitákat a senki által nem olvasott Excel riport celláinak színezéséről.
Az üzleti elvárások és elvek kiszolgálása hálás feladat, mivel az azokból fakadó követelmények egyrészt alapjában véve egyszerűek és egyértelműek (pl.: az ügyfél kapja meg a pénzt), másrészt jól definiált törvényekben és egyéb szabályozásokban gyökereznek. Az üzleti elvárásokat és elveket hidegen hagyja, mennyire sikerült évek alatt elbonyolítani a működést, viszont segíthetnek minket az egyszerűbb végrehajtás kialakításában. Miután a legtöbb vállalat a nap végén mégiscsak a lehető legegyszerűbben kell(ene) működjön az alapvető üzleti célok elérése érdekében, a folyamati szakértők és érintettek jellemzően képesek elengedni a korábbi gyakorlatot.
Javaslatom szerint tehát egy RPA MVP-nek csak az alapvető üzleti elvárások eléréséhez feltétlenül szükséges lépésekből szabad állnia, s a fő irányelvek folyamatos szem előtt tartásával kell azt létrehoznunk. Természetesen az RPA-megoldásnak fenntarthatónak is kell lennie: könnyen üzemeltethetőnek és karbantarthatónak, de ennek eléréséhez már rendelkezésre állnak a legjobb gyakorlatok.
Mi a helyzet az agilitással?
A kedves olvasó ezen pontig két agilis szállítási módról olvashatott: az MVP-ről és arról, hogy csak olyan funkciókat építsünk, amelyek szükségesek és hasznosak.
Az agilis módszertan több szakmai terület szoros együttműködését ösztönzi a szállítás során, ami az RPA implementációk terén is igen hasznosnak bizonyul, hiszen a fejlesztéskor több, a folyamatok végrehajtásával kapcsolatos kérdés is felmerülhet (még akkor is, ha folyamataink amúgy megfelelően dokumentáltak).
Ha sikerült értelmes darabokra szednünk a folyamatokat, ahogyan azt korábban említettem, akkor alkalmazhatjuk a folyamatos szállítást ezekre a folyamatrészekre, de nem szabad a megoldásokat korábban bemutatni, vagy átadni, mint ahogy azok képesek lennének a vállalat számára értelmes eredményt produkálni. Például miért érdekelne bárkit is egy olyan robotmegoldás, amely csak a tranzakció lezárásához szükséges adatok felét tudja rögzíteni? Nem igazán lenne hasznos, miközben rengeteg időt vesztegethetnénk el azzal, hogy a (rész)megoldást bemutatható állapotra hozzuk.
Ezt a cikket gondolatébresztőnek szántam arra vonatkozóan, hogyan tehetnénk mindenkit boldoggá azzal, hogy olyan megoldásokat fejlesztünk, amelyek alapvetően csak azt teszik, amire az üzleti folyamatok eredetileg is hivatottak voltak, anélkül, hogy teljesen felesleges funkciókat építenénk a megoldásainkban. Így időt takaríthatnánk meg és optimális komplexitási szintet tarthatnánk fenn a szállítások során.
Tapasztalatom szerint az RPA-projektek soha véget nem érő történetekké válhatnak, hacsak nem tartjuk szemünket a projektek scope-ján, ahelyett, hogy megpróbálnánk teljesíteni minden kívánságot, ami csak elénk kerül. Legyünk karcsúak, legyünk agilisek, de ami a legfontosabb: legyünk észnél.
Ha elakadt Önöknél a robotizáció, vagy most vágnának bele és szeretnék elsőre jól csinálni vegye fel velünk a kapcsolatot!
*Robotic Process Automation (Folyamatrobotizálás)
Fordította: Krizsán Olivér
Eredeti cikk: https://www.linkedin.com/pulse/do-we-need-fight-off-rpa-projects-scope-balint-laszlo-papp/