Capitolo 02
L'RPA è da tempo considerato un catalizzatore essenziale della trasformazione digitale. Nel 2021, Deloitte ha rilevato che il 78% delle organizzazioni ne stava eseguendo l'implementazione, con un ulteriore 16% che intendeva farlo nei tre anni successivi e appena il 6% che dichiarava di non averne pianificato l'adozione.²
Questa diffusione quasi universale è dovuta alla convincente proposta di valore dell'RPA. Nello scenario ideale, consente ai bot software di occuparsi delle attività banali e ripetitive, consentendo alle persone di dedicarsi ad attività lavorative di maggior valore e più piacevoli. L'RPA è veloce ed economicamente conveniente da implementare e non richiede lavoro di integrazione back-end perché l'automazione viene realizzata a livello dell'interfaccia utente.
Di conseguenza, i processi di business diventano più veloci, i tassi di errore crollano e i dipendenti sono più coinvolti. Inoltre i costi scendono, i ricavi aumentano e l'esperienza cliente migliora.
Il modo in cui l'RPA è implementata e distribuita è fondamentale per il successo
Questi esempi mostrano ciò che è possibile quando l'RPA viene implementata come parte di una strategia basata sul business che si prende il tempo necessario per analizzare i processi e identificare dove l'automazione può essere più efficace.
Ma per circa la metà delle organizzazioni che hanno implementato l'RPA, i risultati non sono stati così stellari.⁴ L'RPA non ha fornito per niente il ROI previsto oppure i primi successi non sono cresciuti fino a diventare un'ottimizzazione continua a livello aziendale.
Questo a volte può sembrare un problema del software. In quasi tutti i casi, però, il problema non è tanto la soluzione RPA quanto il modo in cui viene implementata.
In particolare, le basse barriere di accesso all'RPA si traducono spesso in una sua implementazione in un singolo dipartimento, per automatizzare specifiche attività che stanno vincolando il tempo dei dipendenti o che sembrano essere la causa di colli di bottiglia e inefficienze.
Immaginiamo ad esempio un'organizzazione che sta ricevendo lamentele dai fornitori per dei ritardi nei pagamenti. Il tempo dedicato a inserire manualmente i dati dalle fatture cartacee sembra essere un problema, così il dipartimento finanziario utilizza l'RPA per costruire un bot che scansioni le fatture e immetta i dettagli nel sistema finanziario SaaS.
Il bot funziona bene ma i tempi di esecuzione P2P (procure-to-pay) non sembrano migliorare. Alla fine, la persona che ha creato il bot lascia l'azienda. Nessun altro sa come tenerlo aggiornato così, quando il fornitore SaaS esegue il successivo aggiornamento del sistema finanziario, il bot smette di funzionare.
Modi in cui i progetti RPA possono fallire
Questo semplice esempio evidenzia diversi modi in cui le implementazioni RPA possono fallire:
È stata affrontata solo una parte del processo: Procure-to-Pay e Order-to-Cash sono alcuni dei processi più complessi nelle organizzazioni moderne, che coinvolgono molteplici dipartimenti e parti interessate esterne e comprendono lunghe catene di attività interdipendenti. Occuparsi solo di una parte del processo può portare un certo sollievo ma, se ci sono dei colli di bottiglia da qualche altra parte nel processo, il miglioramento complessivo può essere minimo o inesistente. Una correzione isolata a una sola parte del processo può anche creare nuovi problemi e colli di bottiglia a monte o a valle.
L'automazione è stata applicata a un processo sbagliato: questo processo coinvolgeva delle fatture cartacee, forse spedite per posta all'organizzazione, smistate nell'ufficio preposto, passate al contatto del cliente e magari perse per qualche tempo su una scrivania disordinata prima di essere fisicamente passate al dipartimento contabile. L'automazione dell'estrazione di dati da queste fatture ha fatto ben poco per accelerare l'intero ciclo P2P. L'intero processo doveva essere ripensato prima di applicare qualsiasi automazione.
I KPI non erano chiari: i capi dell'organizzazione sapevano che c'era un problema ma non avevano riflettuto a fondo su quale miglioramento volevano vedere. Invece di specificare un risultato desiderato e dei KPI misurabili, si sono limitati ad applicare l'RPA come un cerotto a una delle fonti di inefficienza più visibili. Facendo un passo indietro ed esaminando l'intero processo, avrebbero potuto individuare con precisione tutte le inefficienze, deciso come correggerle e calcolato il ROI di ciascuna correzione prima di agire.
L'utilizzo ad-hoc dello strumento ha reso l'automazione insostenibile: il bot è stato creato da una persona impegnata nel settore finanziario con un interesse per la tecnologia utilizzando uno strumento RPA a basso contenuto di codice. Ha trovato il software facile da usare, ma quella conoscenza è andata via con lui quando ha lasciato l'azienda. Non solo ne è conseguito che il bot ha smesso di funzionare, ma è stata anche un'opportunità mancata per ampliare l'uso dell'RPA per occuparsi di altre inefficienze.
Mancava una governance continua: poiché il bot era stato creato e implementato ad-hoc invece che come parte di una strategia di automazione, nessuno (e nessun sistema di monitoraggio) lo stava tenendo d'occhio, quindi nessuno poteva prevedere che un aggiornamento del sistema finanziario potesse farlo smettere di funzionare.
Cinque requisiti per il successo dell'RPA
Quello che manca nello scenario sopra delineato sono cinque elementi che avrebbero potuto determinare il successo dell'utilizzo dell'RPA, sia sul breve che sul lungo termine:
- Visibilità end-to-end di processi complessi come P2P che coinvolgono molteplici dipartimenti, sistemi, parti interessate e punti di contatto.
- Insight di dove si stavano verificando colli di bottiglia e inefficienze nell'organizzazione, perché si stavano verificando e come potevano essere corretti in modo ottimale.
- Modellazione dei processi esistenti e simulazione accurata delle eventuali modifiche ad essi apportate, per consentire la valutazione di qualsiasi automazione prima della sua implementazione.
- Calcoli del ROI per valutare l'entità del guadagno dell'organizzazione derivante dalla riprogettazione dei processi e dall'automazione di determinate attività.
- Monitoraggio continuo delle attività automatizzate e dei processi più ampi a cui contribuiscono, con dei sistemi di avviso impostati per individuare qualsiasi potenziale problema che si profili all'orizzonte.
L'aggiunta di queste elementi può sembrare molto impegnativa, e finora lo è stata. Il BPM (Business Process Modeling) tradizionale è un'attività ad alta intensità di lavoro che può richiedere mesi e comporta la mappatura e l'analisi manuali dei processi organizzativi per identificare dove si possono realizzare delle efficienze.
Ora, però, c'è un metodo molto più veloce e migliore per ottenere un insight delle inefficienze nascoste che frenano le organizzazioni, e sta già sbloccando miliardi di dollari di valore non sfruttato ogni anno per le aziende in tutto il mondo.
Ti presentiamo il process mining.
Capitolo 03
Porta visibilità, governance e scalabilità all'RPA con il process mining
Riferimenti
² https://www2.deloitte.com/bg/en/pages/about-deloitte/articles/Intelligent-Automation-Survey-2021.html (link esterno a ibm.com)
³ https://researchportal.vub.be/en/publications/the-economic-impact-of-standards-in-belgium (link esterno a ibm.com)
⁴ https://www.ey.com/en_us/consulting/five-design-principles-to-help-build-confidence-in-rpa-implement (link esterno a ibm.com)