Hónap: 2021 január

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/

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/

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/