La RPA on-premises è morta. …O almeno dovrebbe esserlo!

Oggi vorrei raccontarti perché ritengo che la RPA on-premises dovrebbe essere evitata, se non totalmente lasciata nell’oblio. E per farlo, analizzerò uno degli svariati scenari che si vengono a creare nel momento in cui un’azienda decide di introdurre la RPA nei propri processi.

Nella fase di avvio di un nuovo progetto RPA, spesso succede che l’azienda decide di creare le macchine virtuali direttamente nel proprio CED, piuttosto che utilizzare un Cloud privato di RPA. Perché quindi non effettuare questo cambiamento senza affidarsi direttamente ad una società che fornisce RPA “as-a-service”? I motivi fondamentali sono legati alla solita frase… “Si è sempre fatto così!”

Non appena si avviereanno i lavori, nel caso peggiore ci si dovrà scontrare con una lista di limitazioni legate all’impossibilità di disporre di alcune condizioni che per i progetti RPA sono fortemente consigliati, se non in alcuni casi strettamente necessari. Alcune fra le frasi che possono essere dette durante gli incontri preliminari: “La macchina di questo ambiente non può navigare su internet!” oppure “La macchina non può avere questa porta aperta” o, ancora, “Non posso installare quel database, devo usare un altro DB”, “Non mi è possibile lavorare su cartelle condivise”. E via dicendo… coronando il tutto con un “Inoltre, non possiamo effettuare una connessione in consolle e quindi possiamo procedere solo in sessione di desktop remoto”… e la cosa divertente è che spesso si stupiscono che la sessione utente debba rimanere attiva affinché i Robot lavorino.

Inoltre, per garantire un corretto monitoraggio dei processi RPA, è utilissimo avere una connessione in sola visualizzazione così da non bloccare il processo dei robot e mantenere un continuo controllo. Su quest’ultimo punto molto spesso si trovano ostacoli con varie motivazioni, in alcune casi molto fantasiose.

Quanto menzionato fino ad ora avrà rallentato di diverse settimane tutto il progetto. Cosa comporta tutto questo? Senza dubbio l’insoddisfazione del cliente che, a quel punto, riterrà la RPA inefficiente, troppo complicata e soprattutto troppo lenta.

Dunque, per evitare quanto appena detto, la soluzione migliore è proprio quella di evitare l’installazione “fai da te” e dedicare il tutto ad un Cloud “RPA ready”. In quest’ultimo saranno già presenti delle macchine programmate per l’utilizzo di RPA o con un software già installato all’interno, ma, soprattutto, sarà già provvisto delle configurazioni, come ad esempio un software corretto, la possibilità di collegarsi in modo adeguato, il monitoraggio visivo della macchina, la scalabilità e così via.

Per sintetizzare, tutto questo rifletterebbe in pieno la flessibilità e l’efficienza che contraddistingue la RPA. Evitare che il progetto venga limitato o bloccato nei suoi aspetti farà sì che si ottengano a pieno i benefici che la RPA può apportare.

In conclusione, quindi, consiglio di avviare progetti RPA utilizzando Cloud “RPA ready” che permetterà ovviamente di testare e controllare il progetto in ogni sua angolazione per poi, una volta ottenuto il risultato (diciamo in un arco di sei mesi / un anno), poter avviare l’installazione on-premises.

PS: Di questo ed altri argomenti su come gestire ed introdurro progetti di RPA nella propria azienda ne parlo anche nel mio libro “RPA per tutti” disponibile su Amazon: