6 raons per les quals els projectes de Robotic Process Automation (RPA) fracassen i com evitar-los

Foto de chuttersnap a Unsplash

Robotic Process Automation (RPA) és un tema temàtic en els camps d'automatització i AI. Essencialment, l’RPA és una eina de programari que aconsegueix l’automatització imitant accions humanes basades en regles i repetitives. RPA utilitza un robot o bot per automatitzar processos. Actualment, hi ha molts venedors de RPA a la indústria, i els principals agents són Automation Anywhere (AA), Blue Prism i UiPath. Si sou una petita empresa o estudiant que explora el camp RPA, la majoria dels venedors també proporcionen una versió comunitària de les seves eines que poden utilitzar-se lliurement.

La implementació de RPA segueix el cicle de vida del desenvolupament del sistema (SDLC). Aquest article detalla els possibles fracassos en un projecte de RPA que podrien ocórrer en les etapes del SDLC i com evitar-los.

Fases SDLC del projecte RPA
1. Planificació: Triar el procés adequat per automatitzar 2. Anàlisi: batalla dels requisits 3. Disseny: Com evitar la creació d'un disseny de solució dolenta 4. Desenvolupament: reconèixer les diferències de l'entorn per endavant 5. Provar: escenaris de prova que sovint no es poden perdre en l'RPA. projectes 6. Hyper-care: Què passa si el robot funciona amb massa freqüència?

1. Planificació: l'elecció del procés adequat per automatitzar

El primer pas d’un projecte de RPA és triar el procés adequat per automatitzar. La persona que realitzi la selecció i l'avaluació ha de familiaritzar-se amb els candidats al procés i amb l'eina RPA. Hi ha dos enfocaments per avaluar si un procés és factible per a RPA, que són els mètodes de dalt a baix i de baix a dalt.

Mètode de dalt a baix: triar un procés mitjançant la identificació dels avantatges relacionats amb el negoci
Mètode de fons: tria d'un procés avaluant la viabilitat relacionada amb la tècnica

El mètode de dalt a baix el fa normalment una persona directiva que és conscient i coneixedora del context del procés, com ara el nombre d’empleats implicats en el procés, l’acord actual de nivell de servei i l’impacte de RPA sobre l’altra. processos i unitats de negoci. Aquest mètode es fa generalment a un nivell molt alt, on la gent busca múltiples oportunitats de procés alhora.

D'altra banda, l'arquitecte o desenvolupador de solucions RPA el planteja de fons a dalt, que entén les funcions i la metodologia de desenvolupament de RPA. L’enfocament de fons a dalt inclou identificar la disponibilitat d’entorn, la seguretat i la disponibilitat del robot necessàries. Aquest enfocament només pot ocórrer en la fase d’anàlisi quan el desenvolupador reuneix els requisits.

L’accés a un procés amb els dos enfocaments assegura la viabilitat de la RPA i evita malgastar recursos en les properes activitats.

2. Anàlisi: els requisits de batalla

Quan s'ha seleccionat un procés per a RPA, ja podem començar a reunir els requisits. Si RPA és el primer projecte d'automatització de l'organització, és probable que la majoria dels grups d'interès / usuaris no estiguin familiaritzats amb la tecnologia. Per tant, l’analista empresarial de RPA ha de donar una introducció de RPA a les parts interessades pertinents. Seria més fàcil per a l’analista empresarial recollir els requeriments dels usuaris quan tingui coneixement del funcionament de la RPA i dels seus beneficis. Sovint, l’analista de negocis pot trobar que els usuaris es perden de certs passos i sortides requerits quan es discuteixen sobre requisits, ja que potser no coneixen l’automatització i fins a quin punt el robot RPA pot o no pot fer-ho.

Foto de James Pond a Unsplash

L’altre escenari al qual pot enfrontar-se un analista empresarial són les sol·licituds addicionals dels usuaris. La regla general si cal afegir requisits addicionals a l’àmbit és primer comprendre el temps que l’usuari dedica a l’àmbit addicional dia a dia; i el nombre d’usuaris que utilitzen les funcions del nou àmbit. L’analista empresarial també pot necessitar passar una bona quantitat de temps per analitzar els requisits addicionals. Un àmbit addicional pot afegir fàcilment l’esforç / temps necessaris per fer desenvolupament i proves.

Per tant, convé comunicar-se amb els usuaris sobre l’abast i com l’àmbit addicional pot dificultar la línia de desenvolupament.

3. Disseny: Com evitar crear un disseny de mala solució

Després d’haver entès els requisits, ha arribat el moment de crear un model per al nostre robot. Els robots RPA són tecnologies d’automatització dissenyades per reduir tasques de treball redundants als humans i, per tant, excel·lents per fer treballs repetitius i de baix valor.

La majoria dels robots RPA tenen quatre passos típics per automatitzar un procés, inclosos extreure i validar les entrades de dades, automatitzar el procés bàsic (per exemple, entrada de dades, càlculs) i generar sortides i resultats de dades.

Podeu llegir més informació sobre els quatre passos essencials aquí. Atès que els robots fan tasques repetitives, hi ha moltes llaçades i altres lògiques. En la fase de disseny, és important obtenir la lògica de codificació correcta per evitar problemes de disseny en el futur. Els exemples següents són algunes de les consideracions que hauria de tenir en compte l'arquitecte de solucions en crear el disseny de solucions en un projecte RPA:

Consells sobre disseny de solucions RPA: 1. La lògica principal de bucle per processar tots els registres (entrada de dades) hauria d’estar en lloc per a cada procés
2. El robot ha de generar resultats per a cada registre (entrada de dades), com ara "D'acord", "fallat" i les observacions si cal 
3. El robot ha de notificar a l'usuari quan hagi completat un procés mitjançant finestra emergent, correu electrònic, etc.
4. Planificació de tornada: si es produeix un error, torneu al pas X per continuar processant el següent registre
5. Planificació de tornada: si es produeix una fallada del sistema, atureu el procés i tanqueu l'aplicació abans que el robot surti
6. Assegureu-vos que totes les aplicacions usades estiguin tancades abans de la sortida del robot

Passar un temps suficient a la fase de disseny és crucial per assegurar un cicle de vida de desenvolupament RPA fluït. El document de disseny de solucions també ha d’enumerar totes les excepcions potencials que es produirien i explica com els robots han de gestionar les excepcions.

4. Desenvolupament: el reconeixement de les diferències entorn

Els robots RPA es basen en la interfície d’usuari (IU) per saber com i quan hauria d’introduir una tecla de drecera, fer clic o executar una funció. Les pantalles d’aplicació idèntiques en tots els entorns (Desenvolupament, proves d’acceptació d’usuaris (UAT) i específicament entorns de producció) ajudarien a fer el procés de desenvolupament més manejable. Tanmateix, els comportaments d’aplicació solen ser lleugerament diferents en cada entorn i quan s’utilitzen per diferents tipus d’usuaris. Així, el desenvolupador hauria de planificar amb plans de "contingència" quan s'identifiqui aquesta discrepància.

Foto de Kevin Ku a Unsplash

En els millors casos, l’arquitecte de solucions hauria d’haver identificat i tractat els problemes en la fase de disseny. Així, és possible que les discrepàncies només es trobin en el desenvolupament. Quan es produeixi una situació així, el desenvolupador hauria de discutir amb l'arquitecte de solucions per comprovar si és necessari un nou disseny de solucions i fer una anàlisi d'impacte en els altres passos del procés.

Una altra regla general quan es fa desenvolupament de RPA és escriure codis modularitzats i reutilitzar els mòduls tan sovint com calgui. Els desenvolupadors de RPA sovint poden enfrontar-se a situacions en què cal canviar el flux de processos a causa de requisits no oblidats o addicionals. Així, un codi modularitzat estalviaria temps ja que el desenvolupador només hauria de fer canvis a certes línies de codi per reflectir els canvis requerits.

5. Prova: prova d'escenaris que sovint es perden en els projectes de RPA

Hi ha dues àrees principals per provar els robots RPA: els relacionats amb els APR i els relacionats amb els requisits comercials. Si es fa una prova, és fàcil perdre’s les especificacions funcionals relacionades amb la tecnologia RPA, ja que pot no figurar explícitament als documents de disseny. A continuació, es presenten alguns escenaris de prova per a les dues àrees:

Escenaris relacionats amb RPA: Finestra, escenaris d'objectes no trobats - Múltiples robots executant el mateix procés alhora - Totes les aplicacions tancades abans de la sortida del robot. El fitxer de registre es desa i es pot llegir per a cada procés executat.
Escenaris relacionats amb l’empresa: escenari d’entrada de dades no proporcionada - Introduïu amb èxit el nom, l’edat i el perfil del client desat - El resultat del càlcul és correcte - Resultat d’error d’impressió si no es proporciona el nom i continuem el procés - Nombre de FTE guardat (KPI macro).

Els escenaris de prova s'apliquen a tots els entorns i haurien d'incloure, si és possible, la prova de tants escenaris negatius. En la fase UAT, els usuaris podrien veure la sortida "física" del robot i, sovint, poden sol·licitar canvis estètics quant a la manera de presentar la sortida. Per tant, els desenvolupadors sempre haurien de registrar-se amb els usuaris si estan satisfets amb els resultats de les proves.

6. Hiperesistència: què passa si el robot funciona amb fallidesa massa sovint?

Enhorabona! El vostre robot RPA ja s'ha desplegat. Ara només es tracta de controlar els robots per assegurar-se que estan executant el procés de forma desencadenada.

Podem definir un escenari com a "robot RPA mal funcionat" si el procés executat no aconseguia l'objectiu de resultats / indicadors de rendiment esperats (KPI) previst, normalment especificats a la carta del projecte.

Alguns exemples de KPI de RPA inclouen: 
- Nombre d’ETP estalviat (macro KPI) -% de temps / cursa que necessita intervenció humana - Nombre de registres a processar per hora / dia - Nombre de registres processats amb èxit pel robot

A banda de controlar el comportament dels robots i investigar les excepcions, sovint la gent no troba la possibilitat de gravar i mesurar l'eficàcia dels robots. Així, l’equip RPA hauria d’elaborar una llista de KPI per mesurar i recursos dedicats a comprendre i analitzar si la implementació de RPA té èxit.

En una nota lateral, es requereixen millores si els robots no funcionen tal com s'esperava o si hi envien massa excepcions a l'usuari. És típic desplegar un procés de 2 a 3 vegades a l’entorn de producció si es tracta del primer projecte RPA.

Foto de Phillip Glickman a Unsplash

Feliç automatitzant!