A robot is hibázik hisz ő is csak egy ember (a háttérben)

Ha egy RPA robot hibázik akkor a kétkedők máris bizonyítottnak látják, hogy bizony ez a szép új technológia náluk nem működik. Ők megmondták az elején… No de azért egyáltalán nem mindegy miért is hibázott a robot.

Adott egy körülbelül 2 éve stabilan üzemelő 6-8 folyamatból álló RPA fejlesztés. Viszonylag kis UIPath infrastruktúrával, ami egy darab Orchestratort és 4 robotot jelent. Minden robotnak egy Win10-es virtuális gépe a servernek mi más, mint egy Windows server, az adatbázis meg elfér egy már meglévő SQL kiszolgálón. Nem sok, de mindent tud, ami kell pillanatnyilag. Mi vagyunk a szoftver beszállítók, a gépeket a cég üzemelteti.

rpa robot

Mégis mi baj lehet? Nagyritkán ledobja a láncot, de ha belerúgunk egyet működik tovább zokszó nélkül. Közben azért persze változnak a folyamatok is. Itt egy kis reszelgetés, ott egy pici átírás, új folyamatok kilátásban, minden szép és jó. A céget közben megeszi egy nagyobb cápa, de semmi nem változik lényegesen. Bár voltak “egetverő” ötletek, hogy kik kezeljék a robotokat, hála istennek ezek nem valósultak meg, marad a jól bevált csapat. Minden jól és flottul működik továbbra is. Majd jön az infrastruktúra migrálása. Hiszen a nagyhalnak sokkal jobb az infrastruktúrája, és különben is minek kettőt fentartani. És itt kezdődnek a problémák. A kapcsolat a robotok és az Orchrestrator között néha megszakad, az alkalmazások elérése instabil és válaszideje kicsit nagyobb lett. De azért viszonylag jól tűrik a robotok a migrálásból adódó problémákat. Nem is rossz ez a UIPath… Majd egyszer csak minden előjel nélkül leállnak a robotok. Persze hétvégén, mikor máskor, és a hiba egyszerűen érthetetlen. Nincs semmi visszajelzés az Orchestratorban, csak annyi hogy “Job failed”. A robot kapcsolódása az Orcestratorhoz megvan, de elindulni mégsem tud. Ráadásul egy szót sem hajlandó mondani arról, hogy miért. A másik robot meg fut, viszont nem logol semmit sem arról éppen mit csinál. Na nesze neked UIPath, egyből a dicséret után!? Ilyenkor ugye mit tesz egyszeri emberünk, nekiáll feltúrni az internetet. Az megvan hogyan lehet újraindítani a logolást, de vajon mitől állt le? És a másik miért nem indul? Aztán hirtelen ötlettől vezérelve megnéztünk olyasmit is, amit 1000 éve nem néztem már az itthoni gépeimen sem. Mennyi a szabad tárterület? Khhhh… 5 azaz öt MB… Akkor ez okozhat néminemű problémát. Hirtelenjében gyorsan töröltük a nem használt felhasználói fiókokat, és így 1-2 GB szabad területet létrehozva láss csodát! Minden fut, szalad, van log és működnek a robotok. Mint kiderült, senki nem törődött a robotok gépeivel mert nem volt a feladatkörében a migrálás után. Így egy rossz beállítás miatt a gépek “megették” az összes tárhelyet és leálltak, mint minden más alkalmazás is.

rpa

Tehát az, hogy egy RPA projekt működik, nem csak és kizárólag az technológián és az RPA csapaton múlik. A csoportok közötti kommunikáció, és a feladatkörök tisztázása legalább ilyen fontos. Mint minden más sikeres projektnél is. Egy sikertelen RPA projekt pedig legritkább esetben a technológia sikertelensége. Ráadásul a “rossz hír keltése” is milyen egyszerű, hiszen aki nem lát bele csak annyit vett észre, hogy a beígért hatékony robotok leálltak.

 

szoftverfejlesztés mobilitás emobilitás rpa marketing automatizálás blog hírek

A Grape-ről röviden, elismerések

Széleskörű technológiai fejlesztések, digitalizáció, üzleti intelligencia és tesztelési szolgáltatások
Grapesolutions_4rpa cikk .pdf

 

150+ szakértő munkatárs

100+ egyedi üzleti alkalmazás fejlesztve

91%-os visszatérő ügyfélelégedettségi ráta

grape_logo-01