Kategóriák
Uncategorized

Haszontalan folyamatok

– egy RPA Pipeline kialakításának tévhitei

OLVASÁSI IDŐ: 5 PERC

Nem titok, hogy mielőtt elkezdtem volna foglalkozni a robotizált folyamat-automatizálással (RPA), több multinál is dolgoztam, főként mid- és back office területeken, és pontosan ugyanolyan feladatokat végeztem akkoriban, amilyeneket ma már automatizálni javaslok.

Az inkább robotoknak való folyamatokkal kapcsolatos gyakorlati tapasztalataim alapján azt tanácsolom az RPA-csapatoknak jobban vizsgálják meg, hogy egy adott feladatot egyáltalán miért is kell elvégezni. Ha a folyamat egy nagyobb értéklánc szerves része, akkor azt az automatizálást megelőzően először meg kell „tisztítani”, vagyis konszolidálni és standardizálni szükséges. Jaj nekünk, ha ezeket a lépéseket nem egy digitális transzformáció keretében tesszük meg, mert akkor a végén könnyen fenntarthatatlan robotmegoldásokkal, vagy akár egész RPA programmal „lehetünk gazdagabbak” – miközben ez egyáltalán nem a technológia hibája.

Az automatizálás előtt megtett lépések ugyanolyan kritikusak, mint a folyamataink végrehajtásához szükséges algoritmus (robot) meghatározása, megtervezése és megépítése. De vajon mindezek mellett elég alaposak vagyunk-e ahhoz, hogy a folyamatok valódi értékére koncentráljunk, vagy csak úgy öncélúan automatizálunk, mert azt csinálni kell? Hadd meséljek el néhány történetet az RPA előtti karrieremből:

Igen, szeretem kijavítani ugyanazt a hibát… minden, egyes, hónapban!

Alig emlékszem a folyamat konkrét részleteire, de a probléma lényege az volt, hogy a forrásadót egy adott számla helyett tévesen egy másik számlára könyvelték le… Tehát az én feladatom az lett volna, hogy havonta ellenőrizzem azt a főkönyvi számlát a hibás könyvelés miatt és könyveljem le jól, hogy az összeg utólag a megfelelő számlán jelenjen meg…

Nekem pedig az járt a fejemben, hogy mennyire kell tudatlannak lennünk ahhoz, hogy ne találjuk meg a hiba forrását és ne azt szüntessük meg, ahelyett, hogy pluszmunkával foltozgatnánk a problémát? Szóval 3 e-mailt kellett csupán küldenem, hogy kiderüljön a probléma gyökere: a hibát vétő személy nem is tudta, hogy valamit rosszul csinál, mert neki egyszerűen csak az a számla volt beállítva alapértelmezettnek, amikor a tranzakciót végrehajtotta. Megváltoztatták a folyamatot a saját oldalukon és puff, eggyel kevesebb feladattal kellett foglalkoznom.

Számold ki az értékét!

Ez egy klasszikus… Azt a feladatot kaptam, hogy a havi értékeléshez egyenként számoljam ki körülbelül 150 üzletkötés értékét. Kb. 1,5-3 percig tartott egy-egy üzletkötés kalkulációja a szerver számítási kapacitásától és az ügylet összetettségétől függően. Sejthető, hogy ez akkoriban nem volt a kedvenc folyamatom, ráadásul ezt már évekkel előttem is csinálták emberek, ugyanilyen módszerrel… Nem tudtam elfogadni a valóságot, hogy ez a legjobb módja annak, hogy az ilyen ügyletek korrigálatlan értékét megkapjuk. Ezért felvettem egy hibajegyet, annak reményében, hogy az Informatika egy jobb módszerrel képes lesz ezeket az értékeket előállítani számomra.

Meglepetés: az Informatika tudott egy jobb módszert! Mint kiderült, a rendszer már minden zárási ciklusban kiszámolta a keresett értékeket, így összesen kb. 3 percig tartott, hogy megkapjuk az eredményt. Képzeljük csak el, hogy egy másfél órás beszélgetés egy informatikussal évi 60 órát takarított meg és igazából semmilyen automatizációt nem kellett használnom, csak egy FKERES függvényt az Excelben. Ennyit az elmúlt 5 évben elpazarolt 300+ óráról…

Halló! Itt vagy?

El kellett küldenem néhány riportot egyes társterületeknek, mivel úgy gondoltuk, hogy ezek lényeges információkkal járulnak hozzá a munkájukhoz. Nos, mindig is kissé szkeptikus voltam az olyan állandó riportokkal kapcsolatban, amelyek céljáról, vagy címzettjeiről semmit sem tudtam. Így egy nap úgy döntöttem, hogy a következő kérést helyezem el az e-mailek tetejére: „Ha a jövőben is szükséged lesz erre a riportra, kérlek jelezd nekem!”.

„Megdöbbentő módon” négyből 3-an nem válaszoltak, így tudtam, hogy nekik már nincs szükségük az adott riportokra. A 4. csak ennyit írt: „Jó ég, ezt még mindig küldöd? Már nem is emlékszem, hogy miért volt erre szükségünk korábban! :)”. Semmi gond barátom, 30 perccel kevesebb munka nekem.

Hibás mérőszámok

Folytathatnám még az ilyen történeteket, de azt hiszem, most már érthető, mire akarok kilyukadni: a tény, hogy egy folyamat létezik, nem jelenti azt, hogy van értelmes célja, vagy hogy szükségszerűen olyan értéket teremt, amely igazolja annak költségeit. Ezért bátorítok mindenkit, aki úgy gondolja, hogy az RPA előnyeinek mérésére szolgáló egyetlen igazságforrás a megtakarított munkaórák száma, hogy értékelje át a mérőszámait.

Milyen értéket sorakoztatnál fel a folyamataid mellett? Milyen lehetséges következményekkel járna, ha leállítanád a folyamatot? Vannak-e a végrehajtásra alternatív megoldások?

Egy folyamat értéke megegyezik az általa létrehozott előnyök és az elkerülni kívánt kedvezőtlen következmények értékével.

A fentebb megidézett folyamatoknak bizonyára volt munkaerő költsége. Ha figyelembe vesszük, hogy egy hónap végi zárást 5 munkanap alatt kellett elvégezni és ezt 4 napra lehetett volna rövidíteni automatizációval, akkor egy egész napnyi munkaidőt nyertünk volna! De inkább költenél pénzt robotok építésére és működtetésére, melyek valódi értéket nem teremtő folyamatokat hajtanak végre, vagy néhány telefonhívás és email árán inkább teljesen megszüntetnéd ugyanezen folyamatokat?

Mindezek miatt kell felülvizsgálnunk, átértékelnünk és átszerveznünk az end-to-end folyamatainkat, ahelyett, hogy csak úgy robotokat dobálnánk a feladatokra. Az előbbi felbecsülhetetlenül értékes…az utóbbi megbecsülhetően eredménytelen…

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/processes-value-rpa-pipeline-creation-fallacy-balint-laszlo-papp/

Kategóriák
Uncategorized

A kevesebb több?

Hogyan határozzuk meg RPA-projektünk scope-ját

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:

  1. 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.
  2. 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/

Kategóriák
Uncategorized

Karcsúsított robotok – A Lean szerepe az RPA-ban

OLVASÁSI IDŐ: 6 PERC

A robotizált folyamatautomatizálás mint technológia és a Lean Six Sigma módszertan együttes alkalmazása kézenfekvő megoldást kínál a folyamati szűk keresztmetszetek megszüntetésére, a kapacitás és a feldolgozási sebesség növelésére, valamint a hibák számának csökkentésére. Viszont az már korántsem egyértelmű, hogyan is használjuk a Lean módszereket az RPA*-megoldások építése során, vagy, hogy az RPA miként használhatja azokat saját eredményességének javítására. Mindazonáltal érdemes némi gondolatot szentelni a témának.

1. Makroszintű folyamatok

Gyakori tévhit, hogy az RPA csak a feladatok automatizálására alkalmazható. Ha ez igaz lenne, akkor nem robotizált folyamatautomatizálás lenne a becsületes neve, hanem robotizált feladatautomatizálás és nem is a vakszerencsének köszönhetjük, hogy nem az utóbbi lett a definíció. Egy adott RPA-csapatnak tudnia kell, hogy a megoldásaik hogyan illeszthetőek be az üzleti folyamatok szélesebb körébe.

Így nem csak azokat a feladatokat kell lefejleszteniük, amelyeket az üzleti terület automatizálni szeretne, hanem a front-to-back folyamatok módosításánál is irányt kell mutatniuk. Ezáltal a vállalat elkerülheti, hogy megragadjon a silószerű működés szintjén és az egész rendszer pont azzal a csigalassúsággal mozogjon tovább, mint korábban.

2. Mikroszintű folyamatok

A makróról a mikroszintre váltva fókuszunkat, a robotmegoldások által célzott tevékenységeknek is a lehető „legkarcsúbbnak” (leannek) kell lenniük. A robotnak szinte soha nem célszerű 100%-osan leutánoznia a folyamatot úgy, ahogy egy ember hajtaná végre, s ennek két jó oka is van: a robot vagy többet tud (API hívások, gyorsabb feldolgozás), vagy kevesebbet (improvizálás hiánya, nem egyértelmű helyzetek kezelése), mint embertársai. Nézzük mit kell figyelembe vennünk, amikor felmérjük, dokumentáljuk a folyamatainkat és megtervezzük rá a megoldásainkat.

2/A Vissza az alapokhoz

Messze nem elég annyit tudni a folyamatokról, mint az azt éppen végző személy. Leggyakrabban ugyanis nem igazán értik, hogy miért így lettek kialakítva a feladatok, ahogyan a jelenlegi állapotukban végrehajtják őket. Robotfejlesztőként nagyobb tudással kell, hogy rendelkezzünk, hiszen mi az adott folyamattal szembeni alapvető üzleti elvárások teljesítését célozzuk.

Az alapvető üzleti elvárások mindig a legegyszerűbb „lenyomatai” egy folyamatnak, amelyeket folyamatosan szem előtt kell tartanunk. Lehet, hogy az évek során ezek a feladatok különböző okok miatt megváltoztak, le kell hát azokat porolnunk és megnézni, hogy miért így tervezték meg őket és hogy egyáltalán még mindig szükség van-e a végrehajtásukra.

Ha megtaláljuk a folyamat lényegét, akkor nem kell felesleges vitákba bocsátkoznunk (például milyen színű legyen a betű, amikor a megoldás figyelmeztető e-maileket küld), hanem újragondolhatjuk az egész felépítést. Nem gondolná az ember, de vannak olyan dokumentálatlan folyamatok, ahol a döntési pontokat nem tudják felidézni a helyes a végrehajtási sorrendben, emiatt a folyamat logikai hibáit magunknak kell kijavítanunk, hogy az végül megfeleljen az alapvető üzleti elvárásoknak.

2/B Skálázhatóság

„Mindent is automatizálni akarunk!” – Lassítsunk egy kicsit, erre valószínűleg nincs sem elég pénz, sem elég idő. Akkor automatizáljuk csak az alap folyamatot, a hibaágakat és a kivételeket pedig ne is kezeljük? Ez sem ilyen egyszerű. Vegyük figyelembe a 80-20-as szabályt: a folyamati szcenáriók 20%-a a feldolgozott tételek több mint 80%-á kezelni fogja. Ha ez nem igaz, akkor sajnos a folyamatunk nem standardizált (tervezzük szépen újra!), vagy nem standardizálható. Akármelyik is a válasz, ilyen körülmények között nem célszerű erőltetni az automatizálást.

Tehát, a fejlesztési idő és büdzsé megtakarítása érdekében arra kell koncentrálnunk, hogy alaposan feltárjuk és dokumentáljuk ezt a bizonyos 20%-ot. Ha ez megvan, már csak arról kell gondoskodnunk, hogy a fennmaradt részt eljuttassuk emberi feldolgozásra (és ne essenek le tételek az asztal alá). A robot „feladatkörének” megfelelő lehatárolása nemcsak időt takarít meg, hanem a karbantartást is fenntarthatóbbá teszi (hiszen nem kell meggyőződnünk arról, hogy a megoldásunk képes-e megfelelően feldolgozni a legrosszabb esetben is évtizedenként egyszer előforduló tételeket…).

2/C Technológiai optimalizáció

A robotizált megoldások jobb IT integrációjának és képességeinek köszönhetően újragondolhatjuk egy-egy folyamat lefutásának módját. Például egyetlen ember sem fog hatékonyan kommunikálni egy alkalmazással API-hívásokkal és ebből XML/JSON formátumú fájlt összeállítani, ahelyett, hogy az applikáció felületét használná. A Captchák sem véletlenül bukkannak fel adott felületeken, az adatszolgáltatók gyakran arra kényszerítik a szervezeteket, hogy feliratkozzanak az általuk webservice-n keresztül nyújtott tartalomra.

Az Excel fájlokat sem szabadna piszkálnunk az Excel felületen keresztül, és nem szabadna ezt megtennünk az Access adatbázisokkal vagy bármely más, megfelelő interfésszel rendelkező Microsoft termékkel sem. Az RPA-megoldásoknak csak jól strukturált inputokkal szabad dolgozniuk és ugyanígy csak jól strukturált outputokat kellene előállítaniuk. Ha ennek elérése érdekében meg tudjuk tisztítani egy input fájl formátumát, akkor ezt mindenképp tegyük meg. A rendezetlen fájlok vagy adatstruktúrák nem elfogadhatóak.

2/D Billentyűleütések optimalizálása

Véleményem szerint talán ez adhatja hozzá a legkevesebb értéket a megoldásainkhoz, de ettől függetlenül mégis csak ad valami pluszt. A billentyűleütés-optimalizálás akkor valósítható meg, ha jobban ismerjük az alaprendszerek képességeit, mint az a személy, aki az adott feladatokat végrehajtja bennük. A rendszereken belüli gyorsbillentyűk ismerete akkor jön elő, amikor hasonló részfeladatokat automatizálunk különböző folyamatok között és egy üzleti terület jobban tudja, hogy hogyan kell ezekkel operálni, mint egy másik. Az újrafelhasználható robotkomponensek nagy szerepet játszanak a fejlesztők hatékonyságának növelésében az ilyen esetekben.

3. Leszállítási módszertan

Amikor a robotizált folyamatautomatizálásról beszélünk, nem csak az automatizálandó üzleti folyamatokat kell vizsgálnunk, hanem az RPA által használt leszállítási metodológiát is, amellyel a robotizált megoldások azonosítását, tervezését, fejlesztését, tesztelését, telepítését, üzemeltetését és karbantartását kezeljük.

Valahol igaz az, hogy minden egyes „átadási pont” csökkentheti a végső megoldás minőségét. Ez egyszerűen az információvesztés, vagy az automatizálandó folyamat teljes koncepciójának félreértése miatt van. A saját megoldásaink jobb dokumentálása csak egy része a megoldásnak, a szerepkörök összevonásával csökkenthető átadás-átvételek száma egy másik módja a leszállítások felgyorsításának. Természetesen egy solution designer és egy üzleti elemző szerepkör kombinációjának megvannak a maga költségei, de az ebből származó előnyök – véleményem szerint – legalább kétszeresen meghaladják ezt a költséget, mivel a karbantartási költségek hosszútávon jelentősen alacsonyabbak lesznek.

Nem csak a minőségromlást kell elkerülnünk, hanem minden egyes szakaszban a minőség növekedésére kell összpontosítanunk azáltal, hogy a folyamatot jobban dokumentáljuk, mint ahogyan azt korábban részletezték, a folyamattervezés jelenlegi állapotánál jobb robotizált megoldást tervezük és jobban fejlesztjük, mint ahogy azt korábban tették. Mindezek lehetővé teszik, hogy stabilabb működést érjünk el, mint az RPA használata előtt.

Összefoglalva, még ha nem is használjuk a Lean módszertant a klasszikus formájában, annak alapvető gondolatisága akkor is kritikus az RPA sikere szempontjábó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/what-should-lean-rpa-balint-laszlo-papp/

Kategóriák
Uncategorized

Távozóban a válság: maradnak-e a robotok?

OLVASÁSI IDŐ: 5 PERC

A legnagyobb kérdés a Robotic Process Automation (RPA) iparág számára manapság az, hogy a válság üzemmódot lassacskán elhagyó vállalatok milyen konklúzióval a tarsolyukban fognak hozzá működésük (újra)rendezéséhez. Vajon az egekbe emelkedik, vagy a porba hull a robot munkaerő?

Magam mindig is válságálló technológiaként tartottam számon az RPA-t, melytől joggal várható, hogy a (működési) krízissel szembesülő vállalatok számára az elsők között nyújtson megoldást. Ideje áttekinteni, hogy fals reményeket tápláltam, vagy látnoki képességről tettem tanúbizonyságot!

Mi történt az irodai munkavégzéssel?

Eltekintek most az otthoni munkavégzés jelenlegi kiterjedtségének az elemzésétől (megteszik ezt mások), inkább azt érdemes megvizsgálnunk milyen kihívásokat támasztott az a helyzet, amikor tömegeknek kellett egyik napról a másikra home office-ba vonulnia (köztük jómagamnak is).

A tapasztalataim és a sajtóbeli hírek alapján a vállalatok nagyobb része nem volt felkészülve ezen típusú és ilyen mértékű üzletmenet folytonossági kihívásra. A legkevésbé talán a szolgáltatóközpontok szenvedték meg az alkalmazkodást, mivel egyrészt a működési modelljüknek eleve része a távoli foglalkoztatás, másrészt folyamataikat javarészt papírmentessé tették az elmúlt években. Mindezek mellett a pandémia esetleges további eszkalációja esetén ők is kihívásokkal szembesülnek (betegség miatt kieső munkaerő, munkaszervezés és kontroll megtartása stb.).

A vállalatok (országok?) nagy része viszont alacsonyabb digitalizációs érettségi szint mellett szembesült azzal, hogy hirtelen újra kell szerveznie a csapatait, újra kell gondolnia a papír alapú folyamatait, a szolgáltatási szintjeit (SLA) és egyáltalán: fel kell szerelnie a kollégákat az otthoni munkavégzéshez szükséges eszközökkel. Legyünk őszinték: a legtöbb vállalatot ez a szituáció felkészületlenül érte.

Hogyan érintette mindez az RPA-t?

Az azonnali hatás javarészt két dologtól függött: mennyire volt felkészült az adott vállalat RPA-csapata, és a felsővezetés az RPA-ra, mint üzletkritikus befektetésre tekintett-e. Nem titok, hogy számos vállalat érdemi eredményt nem termelő miniprojektekig jutott csak a robotizációval, vagy jelentéktelen tesztelgetés mellett vigyázott rá, hogy folyamati szinten ne generáljon valódi fejlődést…

Ne feledkezzünk meg ugyanakkor azokról sem, akik a kezdetektől az RPA szervezeti szintű kiterjesztésében gondolkodtak, s ehhez le is rakták az alapokat: a jól felkészült csapatot, kiváló infrastruktúrát és egy átgondolt módszertant. Mindezek lehetővé tették számukra, hogy elérjék első kisebb-nagyobb sikereiket.

A felsővezetés komoly elköteleződését nem élvező RPA programoknak nemcsak a büdzséje sérült, hanem a projektportfóliója is, emiatt gyakorlatilag a puszta létezés határán táncoltak (táncolnak). Azok, akik házukat sziklára építették ugyanakkor megtalálták a válságban érintett kritikus folyamatokat és robotokkal támogatták meg a szervezetet a túlélésért folytatott küzdelemben (hazai viszonylatban ilyen téma volt például a hitelmoratóriummal kapcsolatos tömeges megkeresések feldolgozása, melyre több bank is robotokat fejlesztett).

Itt vannak továbbá azok a cégek, akik eddig arra vártak, hogy eléggé beérjen a technológia ahhoz, hogy megfontolják a bevezetését. Jelentem az RPA beérett.

Mi fog megváltozni?

Az RPA körökbeli rossz vicc szerint a robotok – az emberekkel ellentétben – nem vesznek ki szabadságot, de még betegszabira sem mennek soha. Ez a csak részben igaz, kissé bántó megjegyzés egy fontos pontra világított rá a globális járvány okozta válság közepette: az üzleti tevékenységek nagy része a kollégák vállán nyugszik, utóbbiak egészsége pedig – s így munkavégzési képessége – sajnos nem sérthetetlen…

Ezen felismerésből fakadóan a legtöbb üzleti döntéshozó fejében – helyesen – átalakult az RPA hasznosságáról, megtérüléséről kialakult kép. A többség által nyomon követett humán munkaóra megtakarításon túl a hasznok között megjelent végre legalább két kiemelten fontos szempont:

  1. Az üzleti folyamat értéke: mi a teljes pénzügyi hatása annak, ha a folyamatot nem tudjuk ellátni.
  2. A folyamatot végrehajtó kollégák helyettesítésének teljes költsége: a toborzásra és kiválasztásra fordított idő és költség, a betanítás/elbocsátás költsége stb.

Fenti megfontolásokat szem előtt tartva máris más megvilágításba kerül az az amúgy délelőttönként 2 órában ellátható folyamat, melyet ugyan évi 6 millió forintos bérezés mellett végez egy kolléga, ugyanakkor biztosítja, hogy a cége ne kerüljön cash zavarba, vagy hogy a szabályozó hatóság ne bírságolja százmillióra a vállalatot…

Most már tényleg ideje elkezdeni digitalizálni…

Az RPA szintlépéséhez strukturált adatokra van szükségünk, melyeket alaposan – gyakran műveleti szinten – átgondolt folyamatokkal mozgathatunk, transzformálhatunk. A digitalizált adat már ma is a papírmentes irodák rendelkezésére áll, a többiek számára azonban további kihívásokat tartogat.

Az első lépések a megoldás felé ezek lehetnek:

  • Alakítsunk ki papírmentes folyamatokat, hogy az adatokat digitális formátumban kezelhessük (digitális transzformáció), vagy ennek hiányában a struktúrált adatok előállítására alkalmazzunk intelligens dokumentum feldolgozó eszközöket (digitalizáció)!
  • Dokumentáljuk folyamatainkat műveleti szinten (igen: kattint, beír, beszúr…) és kiemelten figyeljünk a döntési pontok és különböző szcenáriók rögzítésére!

Az egyes üzleti folyamatok céljának beható ismerete és a megfelelő eszközök hiányában semmit értelme az automatizáció “optimális módján” gondolkodnunk, a létrehozni kívánt robotmegoldásról már nem is beszélve…

Mi jön eztán?

Ahogyan a mindig kritikus Phil Fehrst írta, sok vállalatnál az RPA meghalt. Ennek általános okát abban látom, hogy a technológia képességének negyedét sem sikerült kiaknázniuk. Az RPA hasznáról és megtérüléséről megváltozó felfogásnak köszönhetően a “halott” RPA programok most talán kapnak egy második esélyt. Ezúttal azonban – remélhetőleg – meg lesz a felsővezetői elköteleződés, így az RPA kezdeményezések résztvevőinek felkészültségén múlik majd, hogy az RPA sikert arat, vagy végképp elbukik.

Amennyiben érdekli, hogy a robotizáció miben segítheti a működésüket a megváltozott környezetben lépjen kapcsolatba velünk!

Eredeti cikk: https://www.linkedin.com/pulse/crisis-has-come-whats-rpa-balint-laszlo-papp/

Kategóriák
Uncategorized

Robotok a kispadon

OLVASÁSI IDŐ: 5 PERC

Szeretek robotizációs szakemberekkel megismerkedni és szívesen publikálok is a témában, melynek egészen egyszerű oka van: betekintést nyerek abba, mennyire (nem) jól kezeljük jelenleg a folyamatrobotizációt. Azt kell mondjam, hogy az RPA* programok idehaza – a számos szakértői visszajelzés és a posztjaim generálta reakciók alapján – a mai napig nem igazán tudtak magas szintre lépni.

Meglátásom szerint az elakadás jellemző oka az, hogy ritkán sikerül jól összerakni az általam csak “RPA szentháromságnak” nevezett keretetrendszert, vagyis a Módszertant, az Infrastruktúrát és a Szakértő csapatot.

Módszertan

Bár a vezető RPA platform szállítók kulcsrakész implementációs módszertant biztosítanak számunkra, mi mégis hajlamosak vagyunk feltalálni a spanyolviaszt, csak azért, hogy okosabbnak érezhessük magunkat.

A robotfejlesztés szükségszerűen jelentős dokumentációs feladattal jár együtt és minden egyes dokumentumnak megvan a maga rendeltetése. A Folyamatdefiníciós dokumentum (FDD) az automatizált folyamat referenciadokumentuma, mely üzletmenet folytonossági tervet is tartalmaz arra az esetre, ha probléma merülne fel a robottal kapcsolatban. A Megoldásterv dokumentum (MTD) egyrészt a fejlesztendő megoldás egyfajta tervrajza, másrészt a megvalósított robotmegoldásról készített pillanatfelvétel.

Az említett dokumentumok mellőzéséhez a gyorsabb előrehaladás illúziója társulhat, de csakúgy mint az energia, a feladat sem vész el, csak átalakul… Alapos dokumentáció hiányában sok időt fogunk eltölteni a robotmegoldásunk szálainak visszafejtegetésével, hogy megértsük miért  is úgy alakítottuk ki azokat. Ian Barkin RPA szakértő már egyenesen az “RPA oknyomozó” szakma létrejöttét vízionálja és őszintén szólva nem igazán tudok vitatkozni vele ezügyben (rövid angol nyelvű videó itt).

Találkoztam már a gyakorlatban olyan RPA programmal, melyben erősen hanyagolták a dokumentálást és mikor megkérdeztem miért, válaszként – a vállrándítás mellett – csak annyit mondtak, hogy “inkább agilisan csináljuk”…

Összességében úgy látom, hogy több RPA kezdeményezéssel az a legfőbb gond, hogy nem fektetnek kellő hangsúlyt a tervezési és tesztelési feladatokra, csak a fejlesztésre koncentrálnak igazán. Ezt figyelembe véve furcsa, hogy aztán meglepődnek, mikor a robotjaik alig akarnak elkészülni, vagy élesben messze nem úgy futnak, ahogy azt elvárják…

Infrastruktúra

Bárcsak azt mondhatnám, hogy sok jól összerakott robotizációs infrastruktúrát láttam már életemben, mert higgyék el: létezik ilyen! Hiába biztosítanak azonban a vezető RPA platform szállítók részletes infrastruktúra telepítési útmutatót, hogy valóban stabil és biztonságos robotizációs környezetet alakíthassunk ki magunknak, a legváltozatosabb rossz megoldásokba volt már szerencsém belefutni, csak a példa kedvéért:

  • Nyitott irodai környezetben nem zárolt desktop számítógépről elérhető robot irányító alkalmazás (Robot Control Room) – aki arra tévedt kedve szerint futtathatta, vagy leállíthatta a robotokat.
  • Csak éles környezet alkalmazása, melyben a fejlesztést és tesztelést is végezték – a fejlesztők simán hozzáfértek a vállalat éles alkalmazásainak adatbázisaihoz.
  • Licenszspórolás céljából telepítettek ingyenes ún. community RPA szoftver verziót – emiatt alapvető robotfunkcionalitásokat egyáltalán nem, vagy csak jelentős bonyodalmak árán tudtak megvalósítani.

Hangsúlyozom, hogy az összes fenti helyzet és kockázat elkerülhető, az eszközök és a lehetőség ehhez 100%-ban adottak. A biztonság, a stabilitás és a skálázhatóság a jól megépített infrastruktúra elsőszámú ismérvei, egyiket sem javaslom feláldozni a spórolás és lustaság oltárán.

Szakértő csapat

Az RPA egy technológia, ugyanakkor emberekről szól, akik együttműködnek azért, hogy egy értékteremtő megoldást hozzanak létre. Az Üzleti szakértők, Folyamatgazdák, Üzleti elemzők, Megoldás tervezők és a Fejlesztők mind kulcsszereplői az alkotó folyamatnak. Ez a lánc is annyira erős csak, amennyire a leggyengébb láncszem, így bármely szereplő felkészületlensége, vagy épp érdektelensége komoly gondot okozhat számunkra.

Az Üzleti szakértők szállítják az automatizációs ötletek javát és nekik kell nagy részletességgel bemutatniuk az automatizálandó folyamatot, hogy minden lényeges információt rögzíteni tudjunk. Az ő bevonódásuk nélkül a robotizációs roadmapünk könnyen elsivatagosodhat.

A Folyamatgazdák ismerik az adott folyamat mögött húzódó alapvető üzleti célokat és megfontolásokat, így ha felmerül a folyamat végrehajtásának egy jobb módja ők tudják megítélni, hogy az általunk javasolt változtatások sértik-e az üzleti célokat, vagy azok valóban javítani tudják a teljesítményt.

Az Üzleti elemzők rögzítik a folyamati információkat és az üzleti igényeket, nekik kell feltenniük a robot megtervezéséhez elengedhetetlen kérdéseket. Az ő alapvető tudásbeli hiányosságuk a feladat gyenge megértésében és gyatra dokumentációban ölt testet, ami végül az üzlettel folytatott további egyeztetési köröket fog eredményezni.

A Megoldás tervezők készítik el a robotmegoldás “tervrajzát” az Üzleti elemzők által megszerzett tudás alapján. Ha nem ismerik alaposan a fejlesztéshez használt eszköz képességeit, akkor az általuk összeállított terv szerény minőségű lesz, melyet egy (junior) fejlesztő a fejlesztés során nem fog tudni ellensúlyozni, a bukás így garantált.

A robotot magát az RPA fejlesztők készítik el, ezért kritikus fontosságú, hogy kívülről-belülről ismerjék az alkalmazott RPA eszközt. Ha nincsenek tisztában a fejlesztési lépésekkel, a kivételkezeléssel és az általában vett jó gyakorlatokkal, akkor a leszállított robot – az alapos tervezés ellenére is – gyér minőségű lesz.

Az erőteljes bevonás, a szükséges kompetenciák megléte és az egyes szereplők közötti együttműködés mind elengedhetetlen részei a sikernek. Próbáljuk meg elkerülni ezeket a tipikus hibákat, hogy végül ne kelljen totális katasztrófával szembenéznünk!

Útravaló

A folyamatrobotizáció – kiváltképp Magyarországon – egyelőre nem igazán tudott szintet ugrani a cikkben felsorakoztatott okok miatt. Több elsőként indított RPA programnak először vissza kell lépnie, hogy rendbe rakja az alapokat, mielőtt magasabb szintre léphetne. A felgyülemlett tapasztalatokat felhasználva a jövőbeli programok gyorsabban fejlődhetnek, azt gondolom az RPA továbbra is ígéretes jövő előtt áll!

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/why-rpa-suffers-scale-balint-laszlo-papp/

Kategóriák
Uncategorized

Összeomlott az RPA projektem, de miért?

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/

Kategóriák
Uncategorized

Miért ne építenénk robotokat kiemelkedő minőségben?

OLVASÁSI IDŐ: 6 PERC

Bár a folyamatrobotizációs technológia (Robotic Process Automation, RPA) jó ideje elérhető már és az élenjáró RPA szoftverek érett fejlődési ciklusukba léptek, sok szervezet továbbra sem találja a módját, hogyan tudna rövid időn belül olyan jó minőségű robotokat építeni, melyek megbízhatóan teljesítik az üzleti elvárásokat.

Az igazán meggyőző robotmegoldásokat úgy hozhatjuk létre, ha számos sikertényezőt egyidejűleg tartunk szem előtt nemcsak a robotizáció előkészítésének és megvalósításának, hanem annak fenntartási szakaszában is.

1. sikertényező: képzés, képzés és még több képzés

Először is szükségünk van nagy jártassággal bíró üzleti elemzőkre és RPA fejlesztőkre, akik képesek felismerni az automatizációs lehetőségeket és az esetleges buktatókat is. Nekik nem csupán a megbízható megoldás lefejlesztésére kell képesnek lenniük, hanem tudniuk kell, hogyan optimalizálják azt a lehető legjobb eredmény elérése érdekében.

A gyors eredmények hajszolása közben könnyű megfeledkezni a képzésről, ami jelemzően félresikerült megoldásokhoz vezet, emiatt óva intek a “learning by doing” megközelítés mantrázásától. Egy robot kialakítása hasonlít egy ház felépítéséhez: az eszközök és módszerek alapvető ismerete nélkül nem leszünk képesek olyasmit létrehozni, ami előbb, vagy utóbb ne omlana össze.

2. sikertényező: a jó minőségű terv

Tételezzük fel, hogy összeállítottuk magasan képzett RPA szakemberekből álló csapatunkat. Az ő első céljuk az, hogy legalább olyan jól (vagy jobban!) megértsék az automatizálni kívánt folyamatot, mint az azt végrehajtó üzleti terület.

A folyamat megértését, mint egyfajta utazást, az összkép felvázolásával érdemes kezdeni. Hol helyezkedik el a folyamat a szervezet fő értékáramán belül? Melyek a végrehajtással szemben támasztott fő elvárások és szolgáltatási szintek? Az automatizált folyamat függőségben áll-e egyéb folyamatokkal? Ha igen, ki tudunk-e aknázni ezek között fennálló szinergikus hatásokat?

 

 

Az összkép megadja számunkra a további munka kereteit, de önmagában nem elegendő a sikeres automatizáláshoz – mélyebbre kell ásnunk! A folyamatlépéseket a teljes egyértelműség céljával, a szükséges legalacsonyabb részletezettségi szinten dokumentáljuk. Utóbbit úgy képzeljük el, hogy ha átadjuk a dokumentációt egy, a folyamatot még hírből sem ismerő embernek, akkor neki az alapján kérdésfelvetés nélkül végre kell tudnia hajtani a folyamatot! Ismerjük fel: ha a végrehajtónak kérdeznie kell, akkor nem voltunk elég alaposak, hiszen a robotnak nem dolga és nincs is lehetősége kérdezni, pláne nem fog improvizálni, hogy kitöltse az általunk hátrahagyott “hézagokat”…

A megfelelően dokumentált folyamat jó kiindulási alapot jelent ahhoz, hogy megtervezzük az üzleti elvárásoknak megfelelő robotot. A tervezés során érdemes az alábbi három – az egyik vezető RPA szoftverszállító cég által megfogalmazott – alapelvet használnunk:

1. Önállóan helyreáll: szinte elkerülhetetlen, hogy robotunk működés közben egyszer-egyszer hibára fusson, ekkor magától képesnek kell lennie folytatnia a feldolgozást onnan, ahol azt abbahagyta.

2. Skálázható: a robotizált folyamatot tudnunk kell párhuzamosan több robottal is futtatni anélkül, hogy azok a végrehajtás közben bármilyen módon akadályoznák egymást.

3. Újrahasznosítható: igen valószínű, hogy egy-egy rendszerünket idővel több robotfolyamat is használni fogja. A felesleges többletmunka elkerülése végett a robotkomponenseket úgy építsük meg, hogy azokat a későbbiekben egyszerűen újra fel tudjuk használni egy másik folyamatban is!

 

Fenti megfontolások talán maguktól értetődőnek tűnnek, tapasztalataim szerint mégis számos robotmegoldás esetében sérülnek kisebb-nagyobb mértékben. Azért is érdemes ezen elveket újra és újra tudatosítanunk magunkban, mert ha a megoldás tervezése során megfeledkezünk róluk, később már nagyon nehéz lesz beépítenünk őket a robotunkba!

3. sikertényező: gyors és hatásos kommunikáció a fejlesztés során

Mostanra helyén van szakértő csapatunk és rendelkezünk egy jó minőségű elméleti tervvel a robotmegoldásra vonatkozóan, belevághatunk végre a robot fejlesztésébe! Bármilyen alaposak is voltunk a tervezéskor mindig találkozni fogunk előre nem látható problémákkal, melyeket egyszerre kell nagy körültekintéssel és gyorsan megoldanunk.

Ez az a pillanat, amikor valóban agilisan kell eljárnunk, különben a robot fejlesztése jelentős késedelmet szenvedhet. A problémákat azonnal asztalra kell tennünk, időben megvitatnunk a probléma súlyosságának megfelelő megoldási lehetőségeket és olykor helyben döntést is kell hoznunk! Tapasztalatom szerint az RPA projektek elakadásának egyik fő oka a pontatlan és elégtelen kommunikáció egyrészt az érintett területekkel, másrészt néha még csapaton belül sem jutnak el kritikus információk a megfelelő időben a megfelelő személyhekhez! Következésképpen a robot fejlesztése lelassul, áthidalhatatlan információhiány esetén egyszerűen leáll.

4. sikertényező: kiváló robotmegoldást csak minőségi infrastruktúrán tudunk futtatni

Honnan tudhatjuk, hogy a robotmegoldásunkat sikerült megfelelő minőségben kialakítanunk? Nos, ennek legfontosabb ismérve, hogy a robot az elvárásaink szerint, azaz pontosan, stabilan és megbízhatóan fut. A használt rendszerek által okozott ismert hibákból a robot egyszerűen visszaáll, az üzleti igénylő által meghatározott kivételekből pedig csak indokolt mennyiséget generál (ezen kivételes eseteket speciális feltételek miatt a kollégáknak kell feldolgozni).

Ezt az állapotot ideális esetben a tesztelési fázis végére elértük, még azelőtt, hogy a robotmegoldásunk “élesbe menne”. Bár a munka jelentős részét már elvégeztük úgy gondolom, hogy a robot monitoring és karbantartás a minőségbiztosításnak legalább olyan fontos eleme, mint a korábbiakban felsorolt lépések. A folyamatos fejlesztés, a kisebb hibák javítása közel 100%-os megbízhatóságú robotot eredményezhetnek, melynek köszönhetően csökkenthető a robothibák elemzésére fordított idő és energia.

A kívánt megbízhatóságot csakis olyan magas minőségű infrastruktúrára alapozva érhetjük el, ami képessé teszi a robot fejlesztőket és üzemeltetőket a gyors cselekvésre, illetve beavatkozásra. Az alapvető feltételek között említhetjük az egész infrastruktúrára kiterjedő alapos szoftver installáció elvégzését, a magas követelményi elvárásoknak megfelelő jogosultság kezelést és a robot desktopokhoz történő szabályozott hozzáférés kialakítását.

Összefoglaló

A robotfejlesztés sikerességét azzal növelhetjük a leginkább, ha a tevékenységünket megfelelő infrastruktúrára alapozzuk, összeállítunk egy jól képzett csapatot, melynek tagjai hajlandóak és képesek mély folyamat-ismeretet szerezni és nem félnek szembenézni a menet közben felmerülő problémákkal, végül készítünk egy alapos és átfogó tervet, hogy a csapatnak ne kelljen improvizálnia a fejlesztés első percétől kezdve.

Az általam tárgyalt sikertényezők nem alkotnak mindenre kiterjedő receptet, ugyanakkor remélem hasznosnak bizonyulnak majd az olvasó jövőbeli projektjeihez. Ha kérdése, vagy javaslata van a robotok építésére vonatkozóan lépjen kapcsolatba csapatunkkal!

Fordította: Krizsán Olivér

Eredeti cikk: https://www.linkedin.com/pulse/how-build-exceptional-rpa-solutions-balint-laszlo-papp/