Cosa misura effettivamente la prontezza
La predisposizione all'automazione ha ben poco a che fare con la sofisticazione tecnica e quasi tutto a che fare con la possibilità di descrivere un processo. Un team in grado di stabilire cosa attiva un lavoro, di quali informazioni ha bisogno, quali sono le regole e chi possiede il risultato è pronto, qualunque sia il software che esegue. Un team che non può farlo non è ancora pronto e non esistono strumenti sostitutivi: un'automazione basata su un processo non documentato automatizza qualunque cosa abbia fatto l'ultima persona, comprese le parti che erano sbagliate.
I quattro aspetti esaminati da questo controllo
Le domande riguardano la chiarezza del processo, se i dati di cui un'automazione avrebbe bisogno siano raggiungibili tramite un'API anziché bloccati nel foglio di calcolo di qualcuno, se esiste un proprietario nominato che sarà ancora proprietario del flusso di lavoro sei mesi dopo il lancio e se esiste una metrica in base alla quale giudicarlo. La debolezza in ognuno di questi è risolvibile in poche settimane e vale la pena risolverla prima di una build piuttosto che durante essa, perché ognuno si trasforma in rielaborazione una volta che esiste il codice.
Cosa fare con un punteggio basso
Un punteggio basso è un risultato della valutazione, non un rifiuto. Di solito significa che il primo progetto dovrebbe essere più piccolo e più noioso del previsto: consolidare i canali su cui può arrivare una richiesta, scrivere a memoria le regole che qualcuno attualmente applica o rendere raggiungibili i dati di un sistema. Ognuno di questi ha valore di per sé e ciascuno rimuove un motivo per cui l'eventuale automazione avrebbe fallito. L'audit esiste per identificare quale sia, ed è la stessa conversazione se il punteggio risulta alto o basso.