Che cos’è, funzionamento e utilità della RPA provvisoria

Definizione e contesti di applicazione

Nell’ambito della Robotic Process Automation, per RPA provvisoria si intende la realizzazione di uno o più programmi informatici i quali:

• interagiscono con altri programmi non necessariamente predisposti per tale interazione
• non sono necessariamente sviluppati in modo sinergico con i programmi con cui interagiscono (ad esempio tipicamente la squadra degli sviluppatori di un’automazione che interagisce con un sito web esterno all’azienda non coopera allo sviluppo di quest’ultimo né tantomeno viene informata su eventuali modifiche)

Queste proprietà implicano una connotazione ragionevolmente temporanea e/o instabile della soluzione di RPA, in quanto, a meno di prevedere, catturare ed inseguire in continuazione e rischiosamente le evoluzioni dei programmi con cui interagiscono, è opportuno adottare prima possibile una soluzione più robusta e duratura.

Un altro aspetto da considerare è il contesto in cui il programma di RPA provvisoria può andare ad interagire. Si può avere un contesto RPA-favorevole, in cui si può ottenere pieno accesso ad esempio ad ambienti di test dei programmi da automatizzare oppure alle loro analisi funzionali, se non addirittura alle basi dati (questo avviene, ad esempio, all’interno di aziende medie e grandi in cui il comparto IT, che ha prodotto o gestito i programmi da automatizzare, mette a disposizione queste risorse). Si può avere invece un contesto RPA-non favorevole, come ad esempio l’interazione con un software per il quale non si ha a disposizione nessuna delle succitate risorse o peggio ancora in cui tale software presenta pochi appigli tecnici (come elementi grafici non etichettati univocamente) oppure si ha una sola credenziale di accesso e solamente in ambiente di produzione, per cui diventa complicato testare l’automazione in fase di sviluppo.

Utilità e usi impropri

La RPA provvisoria, se ben applicata, risulta utile in due macro categorie di applicazione.

La prima, come estensione del concetto di “prova di fattibilità” (Proof Of Concept), in un contesto RPA-favorevole. Tante volte si pensa che automatizzare un processo apporti notevoli benefici, in termini ad esempio di rapidità, sicurezza e quindi, in sostanza, un risparmio di impiego di forza lavoro, misurabile in FTE (full-time equivalent). Se si vuole avere la certezza che una automazione robusta e duratura sia un buon investimento, si può provare ad adottare la RPA provvisoria come strumento dimostrativo, partendo dal presupposto che si possa mettere in piedi un’automazione in molto meno tempo rispetto alla programmazione “tradizionale”, a prescindere dalla qualità del risultato finale. Tale prototipo, anche qualora fosse saturo di debiti tecnici, permetterebbe di misurare nel brevissimo periodo e con rigore l’effettivo risparmio di FTE, a supporto della decisione di attivare immediatamente o meno l’implementazione di un software alla maniera tradizionale (o di API) che consolidi i comprovati benefici sulla produttività.

La seconda categoria è RPA come soluzione tampone. Il caso si dirama in più esempi:

• un’attività da svolgere una tantum, specie se con scadenze stringenti
• un’attività da svolgere imprescindibilmente e immediatamente
• un’attività in cui si interagisce con applicativi extra-aziendali che non espongono API

In questi casi è auspicabile vagliare una soluzione di RPA provvisoria che, talvolta anche nei contesti meno favorevoli, dà risultati accettabili e ha una modalità di sviluppo e rilascio Nel caso dell’attività una tantum, il prodotto RPA può essere dismesso subito dopo la conclusione della stessa. Nel caso dell’attività imprescindibile, il prodotto RPA, rilasciato in tempi brevi, darà il tempo agli sviluppatori “tradizionali” di creare il programma definitivo che normalmente richiede tempi di sviluppo lunghi. Infine, nel caso di attività su applicativi extra-aziendali, in attesa che i produttori di questi creino apposite API o che si valuti l’opportunità di rimpiazzare il prodotto con uno dotato di API, l’interazione attraverso una soluzione RPA può tentare di dare un po’ di respiro all’operatività quotidiana.

Un discorso a parte va fatto per gli usi impropri. La soluzione RPA ingolosisce facilmente gli addetti ai lavori, che cadono nel tranello di paventare risoluzioni miracolistiche e istantanee di problemi magari annosi, delicati e complessi. L’apparente semplicità con cui ci si può approcciare a prodotti commerciali di RPA, dà la sensazione di avere a portata di mano uno strumento agile, potente e rapido col rischio di trascurare aspetti cruciali quali modularità, scalabilità, sicurezza, stabilità, durabilità e affidabilità.

E’ sufficiente che si verifichi uno solo di questi tre presupposti per farne uso improprio:

1. adoperare la RPA provvisoria come soluzione definitiva
2. adoperare la RPA in contesti in cui la stessa è inadeguata
3. in un’ottica di uso massiccio di RPA, non stabilire solide metodologie di sviluppo né utilizzare strumenti di armonizzazione e controllo delle automazioni

Le conseguenze dell’uso improprio possono essere molteplici. Innanzitutto occorre fare delle distinzioni qualitative e quantitative. Ad esempio, dal punto di vista qualitativo, un conto è affidare lo svolgimento di una attività inadeguata o rischiosa (presupposto numero 2) ad un programma RPA e un conto invece è affidarsi ad un software su misura, che rispetti i necessari requisiti. Dal punto di vista quantitativo, un conto è, fatta l’analisi rischi/benefici, decidere di affidare ad un programma RPA lo svolgimento di una sola attività inadeguata o rischiosa e un altro conto è decidere di affidare molteplici attività, anche solo mediamente inadeguate o rischiose. Difatti rilevare, correggere errori e correre ai ripari in tempi congrui rispetto alla aspettative di tempestività della RPA è un’attività onerosa, specie se riguarda un gran numero di programmi operanti ed ancor peggio in presenza del presupposto numero 3 (no metodologie / strumenti di controllo etc.).

Il presupposto numero 1 è il più subdolo perché, a ben riflettere, può portare ad un disastro irrecuperabile. I programmi non RPA possono essere “indipendenti”, cioè autoconsistenti, in quanto non dipendono dall’interazione con nessun altro programma. O perlomeno se interagiscono con un altro programma, lo fanno a mezzo di API delle quali, per definizione, vengono rese note in anticipo eventuali modifiche od evoluzioni, così da avere il tempo di modificare e far evolvere a sua volta il programma che le utilizza. I programmi RPA, invece, sono “dipendenti” da altri programmi ma a scatola chiusa.

Per questa ragione, mentre per i programmi non RPA la frequenza di errori e blocchi è sparsamente distribuita nella linea temporale, paradossalmente può accadere per tutti o molti dei programmi RPA contemporaneamente che avvengano modifiche sui programmi da cui dipendono, senza naturalmente alcun preavviso, causando di fatto una situazione ingestibile. Se la RPA provvisoria viene utilizzata come soluzione definitiva, accade che la quantità di automatismi operanti sia sempre maggiore e, in proporzione a questa quantità crescente, lo scenario di disastro può diventare irrecuperabile. Naturalmente aumentare il numero dei programmatori RPA con l’aumento degli automatismi gestiti non è una soluzione al problema: il raddoppio dei programmatori non implica il dimezzamento del tempo di risoluzione dei problemi, in quanto non si tratta di attività “meccaniche” e “schematiche” bensì di attività dipendenti da ingegno, intuizione, competenza, fortuna ed altri fattori difficilmente quantificabili. L’unica soluzione al problema è limitare, con criteri di buon senso e di progressivo sviluppo di “nuovo” a dismissione di “vecchio”, il numero massimo di programmi RPA gestiti, mantenendo così la caratterizzazione provvisoria della RPA stessa di cui si è parlato.

A proposito infine del presupposto numero 3, è interessante coniare un termine, poco accademico e molto spregiativo, ma utile forse a tenere a mente rischi e pericoli di questo abuso di RPA: i “manualismi“. Si tratta di una storpiatura del termine “automatismo” e subentra quando l’interazione tra un programma e un altro richiede un intervento umano, più o meno costante, più o meno oneroso. E’ piuttosto frequente che con regolare cadenza un programma RPA si “blocchi” o dia errori, soprattutto se non viene sviluppato e gestito nel modo corretto ed è tipicamente altrettanto frequente adottare come soluzione, seppure poco brillante ed efficace, il continuo intervento umano per sbloccare, aggiustare, riavviare eccetera.

Il manualismo può giovare a mascherare problemi strutturali e connaturati ad una cattiva applicazione della RPA ma ha come limite la qualità scadente dell’artefatto e soprattutto quantità e frequenze eccessive di problemi da risolvere. Combinando insieme il fatto che la RPA permette di abbattere l’impiego di risorse umane e nel contempo non vieta di rendere metodico un suo cattivo uso, certe situazioni possono degenerare facilmente da un momento all’altro creando vere e proprie crisi: ad esempio può accadere che gli sviluppatori RPA perdono il controllo della situazione, non riuscendo più a gestire la quantità di interventi manutentivi, e contemporaneamente non ci sono abbastanza impiegati operativi per rimpiazzare in via temporanea gli automatismi (o, meglio, i manualismi) con il lavoro manuale.

 

Riferimenti

Robotic Process Automation, un approccio sostenibile – giancarlomangiagli.it