Definizione, a cosa serve e applicazioni di RPA in informatica

Che cos’è la RPA

La RPA è in fondo una delle possibili soluzioni ai problemi di cattiva applicazione dell’informatica. Ad esempio quando accade che due o più procedure informatiche possono comunicare tra di loro solo per il tramite di un essere umano oppure quando quest’ultimo non può ottenere da una procedura informatica elaborazioni di informazioni nei tempi e nei modi congrui alle proprie esigenze operative.

I robot servono dunque a rimpiazzare l’uomo nello svolgimento di alcune attività. La finalità di tale rimpiazzo è soprattutto quella di garantire maggiore rapidità, sicurezza e precisione rispetto al lavoro umano, e tale finalità restringe il campo di applicabilità della robotica. Banalmente, non essendo ancora tecnologicamente in grado di compiere appieno ragionamenti, i robot non possono rimpiazzare del tutto l’uomo in attività intellettive. Invece possono rimpiazzarlo in lavori, ad esempio industriali, come le catene di montaggio, in cui le sequenze di azioni sono ripetitive, ben definite e controllabili.

Contro intuitivamente e paradossalmente, il recente avvento dell’era dell’informatizzazione ha portato l’essere umano a compiere nuovi tipi di azioni ripetitive e macchinose. Lo schema di queste azioni è sempre il medesimo e consta di due elementi. Il primo elemento è un programma informatico, che prende in input dei dati e restituisce in output dei risultati. Il secondo elemento è l’utilizzo del predetto programma, quindi l’atto di inserire dati in input e rilevare i dati in output. Fin dagli albori dell’informatica un programma può essere progettato per interagire con un altro programma oppure con un essere umano. Il primo caso (programma che interagisce con un altro programma) si può considerare sotto determinate condizioni una azione di Robotic Process Automation (automazione robotica di processo o processo robotico di automazione) e per questo motivo la RPA, in senso lato, esiste da quando esistono i programmi stessi (i quali sono correlati alla definizione di processo).

Applicazioni ed esempi di RPA

Un esempio basilare di RPA è lo schedulatore, che viene programmato per innescare processi secondo determinati criteri e condizioni. Un esempio più complesso e più vicino all’odierno sentire comune sulla RPA, è un programma che interagisce con un altro programma “imitando” le azioni umane. La differenza tra i due casi è data dal fatto che il primo programma è stato predisposto dal programmatore anche per essere usato da un altro programma mentre il secondo programma è stato predisposto per essere usato solo da un essere umano.

Ci possono essere vari casi in cui un programma informatico viene pensato e predisposto nativamente per essere usato solo da un essere umano. Ad esempio:

1. Un programma di videoconferenza. Sarebbe insensato che venisse predisposto per essere usato da un altro programma.
2. Un programma di ricerca e prenotazione di voli aerei. La restrizione all’uso al solo essere umano è un tentativo di evitare che, attraverso un programma, si possano catturare grandi quantità di informazioni con alto valore commerciale.
3. Un programma di interrogazione anagrafica, interno ad una azienda. L’analista funzionale che progetta questo programma, immaginando la finalità unicamente umana di utilizzo di tale software, fa in modo che l’interazione tra esso e gli utenti sia rapida e intuitiva.

Al di là del primo caso, in cui probabilmente non vi sarà mai un interesse di automazione, negli altri due casi (specifici ma facilmente generalizzabili) invece è piuttosto semplice che maturi questo interesse.

I siti internet di ricerca comparata di voli aerei, non fanno altro che applicare la RPA su altri siti internet che forniscono il servizio finale (ad esempio quelli delle compagnie aeree) per poi rielaborare i dati raccolti e fornire le migliori offerte all’utente. Questi altri siti internet (cioè programmi a tutti gli effetti) con cui interagiscono, come già detto, non sono nati per essere fruiti da altri programmi ma ciononostante sono prede di tentativi, spesso riusciti appieno, di cattura delle informazioni con RPA. Sono questi i casi che chiameremo RPA strutturale, ossia casi (nettamente in minoranza sul totale) in cui le metodologie di RPA sono tecnicamente insostituibili ed alla base stessa di un determinato software.

Il programma aziendale di interrogazione anagrafica, invece, è il tipico caso in cui, per la gestione di piccoli volumi di lavoro, l’idea di base di limitare la fruizione al solo essere umano copre per intero le esigenze aziendali e massimizza l’apporto tecnologico. Se l’addetto del comparto amministrativo necessita occasionalmente di dover interrogare una posizione anagrafica, il software dell’anagrafe deve facilitargli il compito e soddisfare appieno questa esigenza. Quando invece i volumi aziendali sono notevoli e richiedono frequenti interrogazioni, elaborazioni, riversamenti dei dati estratti su altre procedure eccetera, vengono fuori limiti e carenze del programma, che impattano pesantemente sulla produttività. Per far fronte a questo limite ci sono vari approcci, di seguito si analizzano i tre principali.

In primis un approccio ingegneristico, attuabile in fase di progettazione, basato sul seguente assunto: è impensabile per una azienda produttrice di software (non rivolto a piccole imprese), non corredare i programmi sviluppati ad uso umano da interfacce per la programmazione, quindi ad uso di altri software, che vengono definite Application Programming Interfaces (API). Se queste vengono progettate a monte, il costo di realizzazione è realmente minimo ma i benefici sono impareggiabilmente più alti. Pensare un prodotto anche come servizio consumabile da programmi è un indirizzo ormai diffuso capillarmente.

In secondo luogo c’è un approccio di reingegnerizzazione, valido per software già realizzati. Si basa sulla revisione del programma e sulla scelta di integrare nuove funzionalità che facciano fronte alle esigenze di lavorazioni di grandi volumi di dati direttamente da dentro il programma oppure di integrare delle API. Questa seconda opzione è vincente già nel medio periodo in quanto, via via che si dovesse far fronte a nuove esigenze, anziché rimettere mani alla modifica del programma per integrare ciò che manca (cosa che magari non viene mai fatta, data la complessità dell’intervento) è sufficiente costruire da zero con minimo sforzo piccoli programmi basati sul consumo delle API preesistenti. Infine il terzo ed ultimo approccio consiste nell’applicazione della cosiddetta RPA provvisoria.

 

Riferimenti

Robotic Process Automation, un approccio sostenibile – giancarlomangiagli.it