Automatització i orquestració de serveis TIC. Serveis de RPA

Elaboració pròpia: la font és de pagament i no es reprodueix

Abast decidit per nosaltres: l'enunciat oficial no acota la matèria

Enunciat oficial. Automatització i orquestració de serveis TIC. Serveis de RPA.

1. Automatització i orquestració

• Automatització: execució d'una tasca sense intervenció humana.
• Orquestració: coordinació de múltiples tasques automatitzades, sistemes i decisions en un flux extrem a extrem, amb dependències, condicions, gestió d'errors i reintents.

Una tasca s'automatitza; un procés s'orquestra.

Nivells d'automatització a les TIC:

Beneficis: reducció d'errors humans, rapidesa i repetibilitat, traçabilitat i auditoria, alliberament de temps del personal per a tasques de més valor, i coherència entre entorns. Riscos: automatitzar un procés dolent el fa dolent més ràpidament; dependència de scripts sense manteniment; concentració de privilegis en comptes de servei.

Principi d'ITIL (Information Technology Infrastructure Library) 4: «optimitza i automatitza», en aquest ordre. Automatitzar un procés ineficient consolida la ineficiència: els millors processos a automatitzar són els simples i ben entesos, no els que mouen més gent ni els més crítics per al negoci.

1.1 BPM, BPMN, DMN i CMMN

BPM (Business Process Management, gestió de processos de negoci) és una disciplina, no una eina ni un producte: la disciplina per millorar un procés de negoci d'extrem a extrem fent-ne l'anàlisi, modelant-lo en diferents escenaris, executant-lo, monitoritzant-lo i aplicant-hi millora contínua. Els motors BPMN (Camunda, Flowable, Activiti, UC4/Automic) són el suport tècnic que l'implementa, no la disciplina en si.

BPMN (Business Process Model and Notation) és la notació estàndard de l'OMG (Object Management Group) per modelar processos —diagrames de flux amb esdeveniments, activitats i gateways—, adoptada com a norma ISO (International Organization for Standardization) / IEC (International Electrotechnical Commission) 19510. No és exclusiva d'un tipus de producte (ERP (Enterprise Resource Planning), CRM (Customer Relationship Management), BPM): serveix per modelar qualsevol sistema d'informació basat en procediments definits.

L'OMG manté un trio complementari de notacions, cadascuna per a un tipus de treball diferent:

La pregunta que separa les tres notacions és què és el que varia. Si el que està fixat és l'ordre dels passos, es modela en BPMN; si el que canvia és la regla que es decideix dins d'un pas, aquesta regla es treu fora i es modela en DMN; i si no hi ha ordre predefinit perquè el marca qui porta l'assumpte, es modela en CMMN. Separar la regla del flux és precisament el que aporta el DMN: la regla de negoci canvia sovint —un llindar, un barem—, i el procés que la invoca, no.

2. Planificació i orquestració de treballs: UC4/Automic

UC4 Automation Engine (avui Broadcom Automic Automation) és una plataforma de planificació i orquestració de treballs per lots i de processos de negoci molt implantada a l'administració pública i a entorns SAP.

2.1 Arquitectura

Pregunta literal: el component de UC4 que s'instal·la als servidors remots i hi executa les tasques és l'AGENT. El motor decideix; l'agent executa.

2.2 Objectes i conceptes

• Job (JOBS): unitat mínima executable — un script, un programa, un procés SAP, una consulta. És el que fa una tasca concreta en un sistema concret.
• Workflow (JOBP, job plan): contenidor que agrupa i encadena diversos objectes —jobs i altres workflows— definint-ne l'ordre, les dependències i les condicions d'execució.

Relació Job–Workflow: el workflow orquestra jobs; un job pot formar part de diversos workflows i un workflow pot contenir altres workflows (imbricació). El job és la unitat d'execució; el workflow, la unitat d'orquestració. Aquesta és la resposta correcta.

• Altres objectes: Schedule (JSCH) per a execucions periòdiques, Event (EVNT) per a disparadors, Calendar (CALE), Include (JOBI), Notification (CALL), Sync, Queue i Variables (VARA).
• Condicions i dependències: precondicions, postcondicions, condicions de dependència entre tasques, gestió de codis de retorn (return codes) i reintents.

3. RPA — Robotic Process Automation

RPA (Robotic Process Automation, automatització robotitzada de processos): tecnologia que utilitza robots de programari que imiten les accions d'un usuari humà sobre la interfície gràfica de les aplicacions per executar processos repetitius i basats en regles.

3.1 Com interactua amb els sistemes

Els robots RPA interactuen amb els sistemes informàtics de la mateixa manera que ho faria una persona: a través de la capa de presentació (la interfície d'usuari), fent clics, escrivint, llegint pantalles i navegant per menús. Per això no requereixen modificar les aplicacions existents ni integracions per API (Application Programming Interface, interfície de programació d'aplicacions), i poden treballar amb sistemes heretats que no ofereixen cap altra via d'integració.

Tècniques de reconeixement: selectors de l'arbre d'interfície (UI (User Interface) Automation, HTML (HyperText Markup Language) DOM (Document Object Model), Java Access Bridge), coordenades de pantalla, OCR (Optical Character Recognition, reconeixement òptic de caràcters) i reconeixement d'imatge. Complementàriament poden usar API, bases de dades i fitxers quan estan disponibles, cosa que sempre és preferible per robustesa.

3.2 Tipus

• RPA atès (attended): s'executa a l'escriptori de l'usuari i el complementa; el dispara la persona.
• RPA no atès (unattended): s'executa en servidors sense intervenció humana, planificat o per esdeveniments.
• RPA híbrid.

3.3 Quan és adequat i quan no

Bons candidats: processos d'alt volum, repetitius, basats en regles clares, amb dades estructurades, estables i que travessen múltiples sistemes sense integració.

Mals candidats: processos que exigeixen judici, que canvien sovint, amb entrades no estructurades, amb excepcions freqüents, o de volum baix (no compensa).

3.4 Casos d'ús típics a l'Administració

• Conciliació de dades entre sistemes desconnectats: copiar i verificar dades entre el registre d'entrada, el gestor d'expedients i sistemes de tercers (cadastre, padró) que no tenen API comuna.
• Extracció de dades de formularis i documents cap al sistema de gestió d'expedients, sovint combinada amb IDP per a entrades no estructurades.
• Altes, baixes i modificacions massives en aplicacions sense servei web propi (usuaris, permisos, dades de padró).
• Conciliació i tancament comptable, creuament de factures i pagaments.
• Generació i enviament massiu de notificacions i comunicacions a partir de dades ja validades.
• Migració de dades entre aplicacions heretades durant una substitució de sistema.

El denominador comú: sistemes legacy sense API amb els quals cal interactuar «com si fos una persona», i volum prou alt perquè valgui la pena.

3.5 Limitacions davant la IA

Limitació clau del RPA respecte dels sistemes amb IA (Intel·ligència Artificial): el RPA només executa regles predefinides i no aprèn ni s'adapta. No pot gestionar variabilitat, ambigüitat ni dades no estructurades, i qualsevol canvi a la interfície de l'aplicació (posició d'un camp, canvi d'etiqueta, nova versió) trenca el robot i obliga a reprogramar-lo. La IA, en canvi, generalitza a partir de dades i tolera la variació.

Altres limitacions: fragilitat davant canvis, dificultat d'escalar sense governança, deute tècnic acumulat («automatitzar el caos»), i el fet que el RPA no soluciona el problema de fons: és un pegat sobre la manca d'integració.

3.6 La combinació: automatització intel·ligent

• IPA (Intelligent Process Automation) o hiperautomatització: RPA + IA/ML (classificació, extracció) + IDP (Intelligent Document Processing, OCR + NLP (Natural Language Processing, processament del llenguatge natural)) + process mining + BPM.
• Process mining (Celonis, Disco, ProM): descobreix el procés real a partir dels registres d'esdeveniments dels sistemes, i identifica on hi ha valor a automatitzar. Task mining fa el mateix a l'escriptori.
• Agents d'IA: nova generació que executa tasques amb capacitat de raonament i ús d'eines, superant la rigidesa del RPA clàssic.

3.7 Plataformes

Sigui quin sigui el fabricant, una plataforma de RPA reparteix la feina en tres papers, i cadascun té el seu component:

Els noms canvien de fabricant a fabricant, però els tres papers no, i la confusió que cau a l'examen és sempre entre el primer i el tercer: qui dissenya el flux no és qui l'executa en màquines remotes.

UiPath, Automation Anywhere, Blue Prism, Microsoft Power Automate (Desktop), Robocorp, Automagica.

Arquitectura d'UiPath — component per component:

Dues preguntes literals: el component que dissenya i desenvolupa fluxos és Studio; el que executa robots en màquines remotes i els gestiona centralitzadament és l'Orchestrator.

3.8 Governança del RPA

• Centre d'excel·lència (CoE) que estandarditzi, revisi i mantingui els robots.
• Cicle de vida: identificació → avaluació de viabilitat i ROI (Return On Investment, retorn de la inversió) → disseny (PDD, Process Definition Document) → desenvolupament (SDD, Solution Design Document) → proves → desplegament → manteniment. El manteniment és la partida que més es subestima.

- Seguretat: els robots tenen credencials pròpies i sovint privilegis elevats —un robot és, a efectes de seguretat, un usuari més amb credencials, que sovint ningú revisa amb la mateixa disciplina que les d'una persona—. Cal magatzem de credencials (l'Orchestrator té Assets i Credential Store, integrable amb CyberArk), identitats nominatives per robot, principi de mínim privilegi i segregació de funcions —els mateixos requisits que l'ENS (Esquema Nacional de Seguretat) exigeix per al control d'accés (op.acc) de qualsevol identitat—, i registre d'auditoria complet. - Protecció de dades: si el robot tracta dades personals, l'organització continua sent responsable del tractament; cal incloure'l al registre d'activitats i valorar-ne l'impacte. Si el robot pren decisions automatitzades amb efectes sobre una persona, aplica l'RGPD, art. 22. - Continuïtat: què passa si el robot cau? Ha d'haver-hi procediment manual de reserva. - Fragilitat: es trenca amb qualsevol canvi de la pantalla que imita, i multiplica un error a velocitat de màquina si ningú el revisa: la governança no és un tràmit, és el que evita que un robot dolent faci mal ràpid.

3.9 RPA, automatització de workflow i iPaaS

L'automatització de flux de treball (workflow) és la que fa un motor de procés: executa un procés modelat prèviament —normalment en BPMN— encadenant tasques automàtiques i tasques humanes amb regles, aprovacions, terminis i excepcions. És la implementació tècnica de la disciplina BPM, i no s'ha de confondre amb ella: el BPM és la disciplina; el motor de workflow, l'eina que n'executa el model.

Les tres automatitzen, però a capes diferents i amb un mecanisme diferent:

iPaaS (Integration Platform as a Service, plataforma d'integració com a servei): servei al núvol que connecta aplicacions i fonts de dades entre si mitjançant API i connectors predefinits, sense necessitat d'infraestructura pròpia. No imita cap interfície ni orquestra tasques humanes: connecta sistemes. Comparteix amb el low-code l'enfocament visual amb poc codi, però no és RPA ni construeix aplicació nova → low-code i no-code.

El que les separa és per on entra l'automatisme al sistema de destinació, i per això la tria no és de gust:

• l'aplicació publica una API → la integració es fa per API i és feina de l'iPaaS;
• l'aplicació no publica cap API i només s'hi pot entrar per la pantalla → és feina del RPA;
• el que cal coordinar no són sistemes sinó passos, persones i aprovacions → és feina del motor de workflow.

D'aquí ve que el RPA es descrigui com un pegat davant la manca d'integració: el dia que el sistema publica una API, la integració el substitueix, mentre que el motor de workflow i l'iPaaS no competeixen entre si —resolen problemes diferents i sovint conviuen al mateix procés.

4. Automatització a l'ITSM i AIOps

• Autoservei i compliment automàtic de peticions → tema 18.
• Autoremediació (self-healing): l'esdeveniment dispara automàticament una acció de correcció (reiniciar un servei, ampliar disc, escalar instàncies) i registra l'incident.
• Canvis estàndard automatitzats: preautoritzats i executats per pipeline → tema 19.
• AIOps: aplicació d'IA a les operacions — reducció de soroll d'alertes, correlació, detecció d'anomalies, predicció de fallides i suggeriment de causa arrel → tema 23.
• ChatOps i assistents conversacionals per a l'atenció d'usuari.

5. Al sector públic

• Actuació administrativa automatitzada (Llei 40/2015, art. 41): acte o actuació realitzada íntegrament a través de mitjans electrònics en el marc d'un procediment administratiu i en la qual no hagi intervingut de forma directa un empleat públic. Aquesta definició és el criteri que decideix si un robot hi entra: un robot no atès que dicta l'acte hi entra; un robot que només prepara una proposta que després resol una persona, no —hi ha intervenció directa. Quan hi entra, cal establir prèviament l'òrgan competent per a la definició d'especificacions, programació, manteniment, supervisió i control de qualitat i, si escau, l'auditoria del sistema d'informació i del seu codi font, i indicar l'òrgan responsable a efectes d'impugnació. El règim general d'aquests articles el desenvolupa l'administració electrònica i els serveis digitals; aquí només el que li toca a un robot.
• Sistemes de signatura de l'actuació automatitzada (Llei 40/2015, art. 42) — en són dos, i cada Administració determina en quins supòsits fa servir cadascun: el segell electrònic de l'Administració, òrgan, organisme públic o entitat de dret públic, basat en un certificat electrònic reconegut o qualificat; i el CSV (Codi Segur de Verificació) vinculat a l'Administració, que permet en tot cas comprovar la integritat del document accedint a la seu electrònica. Un robot no signa amb el certificat d'una persona: signa amb el segell de l'òrgan.
• Transparència algorítmica: si l'automatització incorpora decisions basades en algoritmes, són aplicables l'RGPD, art. 22 (decisions individuals automatitzades) i la Mesura de govern d'IA municipal → temes 29 i 30.
• La contractació dels serveis de RPA ha de preveure la propietat dels robots i del codi, la reversibilitat i la documentació de manteniment, segons la Mesura de digitalització oberta.

Claus d'examen

• BPM no és una eina ni un ERP/CRM/BI (Business Intelligence): és la disciplina de millorar un procés d'extrem a extrem amb anàlisi, modelatge, execució i millora contínua (TS-TIC 2018, p. 10).
• BPMN són sigles de «Business Process Model and Notation», no «Protocol» ni «Networking» —el distractor confon la notació amb un protocol de xarxa (TS-TIC 2018, p. 24).
• UC4: l'Agent (no el «Runner» ni el «Client GUI» —Graphical User Interface—) és qui s'instal·la als servidors remots i executa (TS-TIC 2025 específic, p. 36); i un Job és una tasca individual, mentre que un Workflow és la seqüència de Jobs amb dependències (TS-TIC 2025 específic, p. 35).
• UiPath: Studio dissenya fluxos (TS-TIC 2025 pràctica, p. 25); Orchestrator executa i gestiona robots en remot de forma centralitzada (TS-TIC 2025 específic, p. 33).
• La limitació del RPA davant la IA és que no s'adapta a canvis sense reprogramació (TS-TIC 2025 específic, p. 34); i interactua per la interfície gràfica de l'usuari, no cridant API (TS-TIC 2025 pràctica, p. 28).
• Segons ITIL, els millors processos per automatitzar són els simples i ben entesos, no els que mouen més gent ni els més crítics per al negoci (TS-TIC 2021, p. 45).

Per recordar

• Automatització = una tasca; orquestració = un procés amb dependències. Primer optimitza, després automatitza.
• BPM és una disciplina de millora contínua (anàlisi, modelatge, execució, monitoratge); BPMN és la notació de l'OMG —norma ISO/IEC 19510— per modelar-la. El trio de l'OMG: BPMN el procés, DMN la decisió, CMMN el cas.
• UC4: el motor planifica, l'agent s'instal·la als servidors remots i executa. El Job és la unitat executable; el Workflow els agrupa i encadena definint ordre i dependències.
• El RPA interactua per la interfície d'usuari, com ho faria una persona: no cal modificar les aplicacions.
• RPA, workflow i iPaaS no són el mateix, i el que els separa és per on entren al sistema: el RPA per la pantalla (quan no hi ha API), el motor de workflow pel procés modelat (quan cal coordinar passos, persones i aprovacions), i l'iPaaS per l'API (quan dues aplicacions han d'intercanviar dades).
• Tota plataforma de RPA reparteix la feina en tres papers amb noms diferents segons el fabricant: disseny, robot que executa i orquestrador que desplega, planifica i custodia credencials. Qui dissenya no és qui executa en remot.
• Limitació del RPA respecte de la IA: només segueix regles predefinides, no aprèn, i es trenca si canvia la interfície.
• UiPath: Studio dissenya, Robot executa, Orchestrator gestiona i executa robots en màquines remotes de forma centralitzada.
• Els robots necessiten credencials pròpies, mínim privilegi i auditoria —el mateix op.acc que exigeix l'ENS per a qualsevol identitat—.
• És actuació administrativa automatitzada l'acte fet íntegrament per mitjans electrònics sense intervenció directa d'un empleat públic: cal òrgan competent per a especificacions, programació, manteniment, supervisió i control de qualitat, si escau auditoria del sistema i del seu codi font, i òrgan responsable a efectes d'impugnació.