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/
