A BPM technológiák már évtizedek óta rendelkezésre állnak, hogy megkönnyítsék az üzleti folyamatok kezelését, bizonyos rendszerek integrációját, illetve, hogy lehetővé tegyék egyes tevékenységek automatizálását. Az RPA technológia ezzel szemben csupán néhány éve kezdett szélesebb körben is elterjedni, a BPM – workflow – technológiák szállítói viszont többnyire vagy valamilyen értelmetlen megoldást, vagy konkurenciát láttak benne. A helyzet mára megváltozott és a legtöbb BPM szállító tisztában van vele, hogy az RPA nem ellenfele, hanem kiegészítője a workflow rendszereknek. Miért és hogyan következett be ez a fordulat és milyen tanulságokat vonhatunk le ebből?
Kezdetben vala a workflow…
Ahogy már említettük, mire az RPA technológiák egyáltalán megjelentek a piacon, a workflow rendszerek és a kapcsolódó szolgáltatások piaca már bőven érettnek volt mondható. Az RPA rendszerek “valós”, tehát nem kísérleti, megjelenését nagyjából néhány évvel ezelőttre tehetjük. Ezen a ponton a legtöbb vállalatnál már használtak valamilyen BPM megoldást akár integrációkkal, további szatellit rendszerekkel – mint például dokumentumkezelés, vonalkódtechnológia, OCR, stb. – kiegészítve. Sokféle teljesen eltérő tudású, megbízhatóságú vagy bonyolultságú workflow rendszer létezett már akkoriban is, egy azonban mindenben közös tulajdonságnak mondható: a workflow rendszerek automatizált feladataikat kizárólag szerver oldalon végzik, nincs lehetőség a klienseken – azaz az egyes felhasználók számítógépein – végzett tevékenységek automatizálására ezekkel az eszközökkel.
…majd az RPA
Épp fentiek miatt indultak el a különféle RPA szállítók saját megoldásaikkal: az egyik legnagyobb szállító, a UiPath esetében – a legenda szerint – olyan kliens oldali automatizáció indította el a fejlesztést, ami alapvetően bizonyos Windows-makrók használatán alapszik. Egy magára valamit is adó informatikus ugyanakkor nem adja a nevét Windows makró alapú működéshez, hiszen ily módon egy szakmailag alacsony tartalmú, nem kellően megbízható, a robosztus megoldásokat kívánó vállalati működésben nagyon nehezen értelmezhető produktumot lehet csak előállítani ily módon. Épp emiatt a UiPath-nál ekkor célul tűzték ki, hogy olyan megoldással álljanak elő, ami a gyakorlatban ugyanazokat a feladatokat – az ügyintézők teendőit – ránézésre ugyanúgy végzi el, mint az előbb említett makró, működése azonban stabil, felépítése robosztus, kezelése pedig egyszerű, minimális programozási tudást igénylő feladat. Így született meg a UiPath RPA megoldása, ami nem csupán beváltotta a hozzá fűzött reményeket, hanem magasan túl is szárnyalta azokat, így válhatott néhány és alatt a UiPath a világ egyik legnagyobb RPA szállítójává.
A BPM piac reakciója – kezdetben
A BPM szállítók természetesen reagáltak az RPA megoldások megjelenésére. Nem feltétlenül nyilvánosan, vagy túlzott hangerővel, de eleinte leginkább egy kvázi lesajnáló legyintés volt jellemző: ugyan már, ez egy sima Windows makró, különben is meg lehet oldani minden ilyesfélét szerver oldalról, workflow-val. Aztán az idő – és a piaci térhódítás – előre haladtával hamar észrevették, hogy az RPA jelenséggel kénytelenek foglalkozni: értelemszerűen egyre több meglévő ügyfélnél merült fel, hogy azokat a tevékenységeket, amiket valamilyen okból nem sikerült workflow rendszerrel automatizáltan kezelni, RPA-val lenne célszerű megoldani. Ezen a ponton már a workflow szállítók is bizonyos kényszerhelyzetbe kerültek – adott esetben nem tehették meg, hogy ne foglalkozzanak az RPA megoldásokkal. Ekkor kezdett talán elterjedni az a nézet, miszerint az RPA megoldások konkurenciát jelentenek a workflow-nak: első ránézésre talán lehetnek is olyan feladatok, amiket mindkét rendszerrel meg lehet oldani, így a workflow szállítók amellett, hogy elkezdték komolyan venni az RPA megoldásokat, már versenytársnak is tekintették. Szükség volt néhány év elteltére illetve megfelelő számú use case kialakulására ahhoz, hogy e nézet változhasson: hiszen a gyakorlat igazolta, hogy a két különféle megoldás elsősorban integráltan működik az elvárások szerint és ebben a konstellációban hozza a legjobb eredményt az automatizáció és a hatékonyságnövelés terén.
A mostani helyzet
Jelenleg, azaz 2020 kezdetén már a legtöbb hozzáértő szereplő számára nyilvánvaló, hogy a kétféle megoldás nem helyettesítheti egymást, illetve nem is versenyeznek egymással. Sokkal inkább kiegészítik egymást, magasabb szintű üzleti automatizációt lehetővé téve, mint külön-külön. Illetve egy nagyon fontos, tényszerű kommunikációs elem is megjelent az RPA szállítók oldalán, nevesül, hogy a sikeres RPA bevezetés előfeltétele, hogy az üzleti folyamatok megfelelően definiáltak, rendszerben kezeltek legyenek. E nélkül az RPA megoldások bevezetése nem lehet sikeres, hiszen ahhoz, hogy megállapíthassuk, mely tevékenységeket és hogyan célszerű RPA-val automatizálni szükséges, hogy tisztában legyünk üzleti folyamatainkkal, méghozzá részleteiben. Ez azonban csak az első lépés, hiszen a folyamatok feltérképezését követően mindenképp célszerű optimalizálni is azokat, így nem a meglévő, esetlegesen kevésbé hatékony működést betonozzuk be különféle rendszerekkel, hanem a tevékenységekben rejlő tartalékot is kihasználhatjuk. Amikor ez megtörtént és rendszerbe foglaltuk folyamatainkat – workflow rendszer segítségével – akkor fordulhatunk rá az RPA megoldás bevezetésére, célszerűen integráltan a workflow rendszerrel. Így amikor egy üzleti folyamat bizonyos lépéséhez – vagy lépéseihez – szoftverrobot munkavégzése szükséges, a workflow-n keresztül teljesen automatikusan megtörténhet a kvázi “feladatkiosztás” a robot számára. Miután a robot elvégezte feladatát, “visszajelez” a workflow-nak, a teljes üzleti folyamat pedig immár tovább léphet, tartalmazva azokat az adatokat, döntéseket vagy egyéb eredményeket, amik a robot munkavégzéséből származnak.
Tényleg ilyen egyszerű lenne?
Röviden: nem. A végső működést tekintve és az eredményt látva talán nem feltűnő, hogy milyen magasszintű technológiai megoldások alkalmazására volt szükség ahhoz, hogy bizonyos automatizációk stabilan, megbízhatóan, integráltan valósuljanak meg. Hiszen a workflow rendszerhez való kapcsolódás számos kihívás elé állíthatja a fejlesztőket: milyen szabványos API-t használjunk az integrációhoz, hogyan csatlakozzunk, hogyan lesz mindez biztonságos? Melyik a legkevésbé költséges, mégis hatékony, kényelmes megoldás?
Amennyiben a rendszerek bevezetése – kiegészítése során – ezek egyszeri kérdések, úgy megoldásuk sem lesz szabványos, vagy széleskörben elterjedt, tesztelt. Ez természetesen később hibákhoz, nem megfelelő működéshez, leállásokhoz vezethet.
Ma már azonban elérhető olyan integrált megoldás, amiben a két szoftver integrációja teljes körűen, alapos tesztelést követően, nagy tapasztalattal lett kialakítva – ilyen az RPA Workflow megoldása is, ahol az xFLOWer workflow rendszerhez kapcsolódik a UiPath RPA megoldása, így komplex, minden helyzetben megbízható, rugalmas megoldást kínálva az üzleti automatizációs kihívások nagyrészére.