Le aziende si aspettano molto dall'introduzione sempre più estesa dell'
automazione software nei loro processi. La
Robotic Process Automation (RPA) e lo sviluppo di assistenti software basati su tecniche di intelligenza artificiale sono in particolare due ambiti considerati promettenti praticamente
da chiunque. Ma
McKinsey lancia un avvertimento: le premesse dell'automazione software sono più che buone - anche il McKinsey Global Institute indica che è possibile automatizzare oltre il 30% dei task che occupano mediamente il 60% del tempo di un lavoratore - ma
implementarla è meno banale di quanto sembri.
Il punto, secondo McKinsey, è che creare "automi" davvero in linea con le specifiche esigenze di un processo aziendale
è comunque una forma di sviluppo software. Deve quindi confrontarsi con i consueti problemi che gli sviluppatori affrontano, in particolare la necessità ormai considerata irrinunciabile di seguire
cicli di sviluppo rapido e iterativo implementando versioni del software (in senso lato) sempre migliori. A questo va aggiunto che l'automazione software è un campo
particolarmente complesso, anche solo perché un medesimo automa software può dover essere adottato da dipartimenti diversi di un'impresa, impattando su un gran numero di persone con ruoli e responsabilità differenti.
McKinsey ritiene che queste esigenze mettano del tutto fuori gioco il già tanto criticato modello di sviluppo a cascata (waterfall), troppo lento e rigido. Ma anche il modello Agile
non è scontato che funzioni bene a priori, perché creare un modulo software che automatizzi un processo non è come sviluppare una generica applicazione.
Innanzitutto
non è detto che si possa scomporre un processo in componenti più piccoli e atomici, su cui i team di sviluppo si possano concentrare in maniera mirata. Anzi, di solito non è affatto possibile: i passi di un processo da automatizzare sono
strettamente legati fra loro, tanto che il processo o funziona nel suo complesso o non funziona affatto.
Inoltre, l'automazione software impatta in modo davvero rilevante sul modo di lavorare delle persone, il che
rende impraticabile un approccio con rilasci frequenti. Anche se una nuova versione di un automa può effettivamente portare un vantaggio operativo, il suo impatto organizzativo può essere tanto elevato da sconsigliarne l'adozione.
Proprio perché un progetto di automazione software dei processi riguarda moltissimi utenti con caratteristiche diverse,
è infine difficile definire un utente-tipo intorno al quale costruire il processo di sviluppo. Operativamente, per gli approcci che lo prevedono,
manca il cosiddetto "product owner" che rappresenti il complesso degli utenti e dialoghi con i team di sviluppo per guidarli come "esperto" della materia su cui si interviene.
Per McKinsey molti di questi ostacoli si possono superare con un approccio definito di "
agile automation". Si tratta di un approccio molto simile a quelli classici del modello Agile ma con alcune
caratteristiche specifiche. Tre in particolare: non partire dalla scomposizione del problema ma dalla
definizione completa del processo da automatizzare, non basarsi sui task specifici dei singoli utenti ma
sugli eventi che li scatenano e sui loro esiti attesi, non prevedere rilasci iterativi frequenti ma un
piano controllato e stabile di nuove versioni.