Agile e Robotic Process Automation (RPA), parte 1

Nelle mie ultime esperienze ho avuto l’occasione di sperimentare l’applicazione dell’universo Agile all’interno di un contesto di sviluppo che guarda alla Robotic Process Automation (RPA).

Di cosa stiamo parlando nello specifico?

La Robotic Process Automation (RPA) raggruppa tutta una serie di tecnologie software che hanno lo scopo di automatizzare in modo profondo i processi di back office. Non stiamo quindi parlando di robot fisici o sistemi di alta intelligenza artificiale (almeno in quelli odierni), ma di agenti softwareche sono in grado di completare attività deterministiche e ripetitive che prima venivano effettuate da un operatore umano.

La cosa interessante è che, tipicamente, un robot“attraversa” diversi sistemi, mettendoli in correlazione attraverso lo scambio la gestione dei dati, per portare a casa un risultato unico, spesso la risposta ad un quesito (query) o un report aggregato.

Lo scopo principe di RPA è quindi quello di Mimare il comportamento umano, automatizzando un processo ben delineato che sia suddivisibile in attività e task atomici. Il tutto, ovviamente, con la capacità di ripeterlo all’infinito (fermo restando le condizioni abilitanti) e ottenere sempre un risultato in linea con le attese.

rpa process mimic

Tra i settori che stanno dimostrando maggiore interesse a questa tecnologia troviamo, ad esempio, quello finanziario dove il costo delle attività di back office rappresenta una parte importante delle proprie spese operative. Secondo una indagine condotta da Deloitte tramite il suo Global CPO Survey, la necessità di diminuire questa fetta di costi è la importante per il 30% dei Global Services Leaders.

Ma torniamo all’esperienza pratica.

La prima sfida da affrontare è stata quella di assemblare il team di lavoro (circa 10/11 persone): completamente in outsourcing, anche se co-localizzato per 4gg su 5, ad esclusione del PO (senza alcuna esperienza pregressa nel mondo Agile, ma grandissimo conoscitore dei processi specifici) e alcuni rappresentanti dell’IT interno, fondamentali per l’interconnessione coi sistemi interessati. Il resto del team era composto da 7 tecnici afferenti a tre diverse aziende fornitrici, con 4 esperti dell’ambito RPA e gli altri dei software e del dominio su cui attivare la mimica.

Si comprende quindi che mettere insieme fornitori diversi, con legittimi interessi diversi, e farli remare in una direzione unica non è proprio la cosa più semplice che si possa fare. Inoltre, il Team Lead apparteneva ad una degli outsourcer, per cui c’era un po' di diffidenza iniziale da parte degli altri. Fortunatamente lo stesso si è rilevato molto competente e con spiccate dote di Leadership, in relazione al contesto e alla sfida che eravamo posti, così come tutti i componenti del neo-team si sono dimostrati ottimi professionisti e interessati all’approccio.

Essendo una sorta di progetto “pilota/sperimentale”, la prima attività che ho messo in campo è stata quella di chiedere ai presenti di lavorare con strumenti per creare un primo sharing dell’iniziativa da realizzare (Product Canvas, Elevator Pitch, ecc). Tali attività sono state fondamentali per inquadrare meglio i diversi aspetti del prodotto e creare una prima azione di Team Building.

rpa board1

rpa board2

(le immagini sono volutamente di bassa qualità)

Fatto questa prima attività (che, come ben sappiamo è sempre on-going), tutto il team era allineato sugli obiettivi, sui constraintse sul perimetro d’azione. Il passo successivo è stato quello discutere degli aspetti cardini dell’Agile, utilizzando Scrum come framework ispiratore, anche per scelte calate dall’alto, ma con un’ampia libertà di adattamento.

La maggior parte delle tematiche erano nuove un po' per tutti, ad esclusione del Team Lead che aveva avuto esperienze in merito e che, su proposta del committente, ha accettato di imbarcarsi nel ruolo di Scrum Master. Complice la volontà generale di provare a fare qualcosa di nuovo, le resistenze rispetto all’adozione di Scrum sono state veramente minime, probabilmente grazie anche al lasso di tempo prospettato per il progetto di 6 mesi, cosa che però non ha portato ad una reazione di indifferenza (vabbè, tanto sta roba passa!), ma a una positiva-curiosità verso il tutto.

Nel prossimo post vi parlerò del primo Sprint e di cosa abbiamo imparato da esso.

 

Stay tuned J

agileiot logo  ac2 logodac dac dacdac dac psmii psmii safe cal1 less certazure fundamentals
mvp reconnect

Free Joomla templates by Ltheme