DE CE RPA NU ESTE DE AJUNS?

În acest articol ne propunem să identificăm punctele slabe ale roboților RPA și potențiale soluții pentru acestea.

Ce face un robot RPA?

Un robot RPA poate să opereze în orice aplicație software la fel ca un om sau chiar mai bine, cu o singură condiție, taskul să fie repetitiv. Și încă ceva, mediul în care operează să nu se schimbe (adică sa nu apară modificări în interfețe, ferestre noi etc.) Deci, roboții RPA sunt perfecți pentru taskuri repetitive în medii controlate. Asemănător roboților mecanici din fabrici, un robot RPA va executa același set de operațiuni la infinit, fără erori, rapid și eficient din punct de vedere al costurilor. Pe scurt, un robot RPA este foarte bun să execute taskuri simple. În cazul unor taskuri înlănțuite, dacă ultimul task eșuează întreaga secvență va trebui probabil reluată și asta va reduce eficiența procesului sau chiar va crea probleme (de exemplu o factură eronată din cauza unei erori dintr-un pas anterior nu poate fi ștearsă pur și simplu și generată din nou, ci probabil va trebui stornată).

Exemplu: Dacă una dintre activitățile unui angajat din departamentul de marketing este de a descarca fișe de produs de pe un site și apoi de a le tipări, atunci această activitate poate fi derulată de un robot RPA simplu și eficient fără nicio problemă.

Când robotul se încurcă?

Spuneam mai sus că în medii controlate totul funcționează perfect, dar în lumea reală apar perturbații iar roboții nu sunt suficient de inteligenți (încă!) ca să se poată adapta dinamic la schimbările din mediu. În exemplul de mai sus, site-ul de pe care angajatul descarcă fișele de produs, este posibil nu doar ca acesta fie căzut (rezolvare simplă pentru un robot) dar este posibil să sufere modificări, să apară ferestre noi, butoane noi, pop-uri sau schimbări ale link-urilor. Aceste lucruri pe care angajatul uman le-ar fi identificat vizual în câteva secunde pot genera probleme pentru robot și nu le va putea gestiona fără o ușoară reprogramare. Păi, o să spuneți că fiind în era tehnologiei „low-code” se pot reprograma ușor. Așa este, dar mentenanța a sute de roboți care trebuie reprogramați frecvent s-ar putea să nu mai fie la fel de simplă.

Și asta nu e tot! Hai să ne imaginăm că robotul trebuie să descarce toate fișele de produs din site-ul respectiv și că din cauza unei modificări pe site nu poate identifica corect existența unor  fișe noi de produs și o ia de la capăt descărcând și tipărind încă o data și încă odată…și cum taskul era setat să ruleze noaptea, dimineața veți găsi imprimanta fără hârtie sau toner, fișele de produs tipărite de câteva mii de ori și spațiul disponibil pe server consumat.

Paradoxul – folosim robiți ca să ținem în viață un cadavru software

Aplicațiile software au un ciclu de viață și la fel ca ființele vii după o vreme îmbătrânesc și mor. Dar, oamenilor le place predictibilitatea și – în general – se tem de nou. Așa că preferă să țină în viată un software muribund sperând că o să mai meargă o vreme. Și, în loc să îl înlocuim și să regândim procesele într-o soluție modernă, integrată prin API cu restul soluțiilor, folosim roboți RPA ca pe niște perfuzii cu care să ținem în viată ineficiența.

Exemplu: WMS-ul nostru este vechi, cei care l-au produs au vândut firma și au plecat, nu avem sursele dar avem un coleg la IT care știe cum să-l țină funcțional. Ne-am obișnuit cu el și chiar dacă mai dă erori, își face treaba. Așa că, am vrea să-l modernizăm cu niște roboți RPA ca să introducă datele în el automat și să și scoată niște Exceluri cu stocurile pe care, după ce le mai prelucrează Tanța un pic, să le importam în ERP.

Desigur că sunt și excepții și în unele cazuri chiar depindem de sisteme externe pe care nu le putem schimba și cu care nu putem comunica prin API (de exemplu diverse sisteme ale instituțiilor guvernamentale) și atunci folosirea unui robot RPA pentru transferul datelor devine o operațiune recomandată.

Oameni și roboți lucrând împreună?

În majoritatea cazurilor, procesele derulate în companii sunt complexe, interconectate și cu o doză mai mare de variabilitate și impredictibilitate decât cel din exemplul nostru. Într-o companie mică un angajat de la recepție derulează zeci de taskuri diferite care se schimbă de la o zi la alta și care sunt în legătură cu activitățile celorlalți colegi. Cum orchestrăm un proces în care un task început de un angajat uman este preluat de un robot, derulat până la un punct la care trebuie luată o decizie și apoi, în funcție de rezultatul deciziei, să continuăm procesul în mod manual sau automat? Pentru un astfel de spațiu virtual în care operează oameni și roboți este nevoie de un BPMS(Business Process Management Software) care să orchestreze procesul și care să permită transferul task-urilor de oameni la roboți și înapoi, dar și luarea deciziilor în mod automat atunci când acest lucru este posibil.

Un robot RPA nu poate schimba sau optimiza un proces, el doar executa un proces. Pe de altă parte, un BPM îmbunătățește performanța unei implementări a RPA, asigurându-se că procesul automatizat este optimizat și oferă rezultatele așteptate. Robotul RPA mimează activitatea umană, dar uneori cel mai înțelept mod de acțiune este reproiectarea completă a fluxului de activități și nu doar înlocuirea unui om cu un robot.

Exemplu: În unele cazuri companiile au implementat un robot RPA care „să ștampileze” documentele mai bine și mai repede decât un angajat uman fără să se gândească dacă ar putea să reproiecteze complet procesul astfel încât să nu mai fie nevoie de ștampilă. 

Concluzie

Roboții RPA sunt ușor de implementat și aduc beneficii imediate în termen de cost, eficiență sau timp de execuție dar nu reprezintă panaceul automatizărilor. Prin combinarea roboților RPA cu platforme de tip BPMS putem să potențăm capabilitățile ambelor sisteme și să construim soluții mai performante decât dacă le-am utiliza independent. Folosirea roboților fără reproiectarea proceselor poate duce la o soluție de tipul „digitalizarea birocrației”, dar despre asta o să vorbim într-un articol viitor.