Cosa conviene automatizzare per primo?
Il primo progetto dà il tono. Se funziona, le persone si fidano del prossimo. Se scegli qualcosa di confuso e raro, l’azienda può restarne delusa per anni. Ecco un modo semplice per decidere.
5 min di lettura. Aggiornato
Elenca ciò che porta via tempo
Chiedi a ogni team le tre attività che cederebbe volentieri. Segna quante volte capitano e quanto durano più o meno. Un’ora di domande vale più di un mese di ipotesi.
Dai un punteggio su dieci
Assegna a ogni attività fino a due punti per ciascuna voce:
- Volume: capita ogni giorno o ogni settimana.
- Regole chiare: un nuovo assunto potrebbe impararla da una pagina scritta.
- Esempi: puoi mostrare cento casi reali.
- Dati accessibili: i sistemi coinvolti esportano o si collegano.
- Errori innocui: uno sbaglio si può fermare prima che arrivi al cliente.
Buoni primi progetti
Questi di solito ottengono un buon punteggio:
- Inserire nell’ERP gli ordini ricevuti via email.
- Leggere le fatture fornitori e abbinarle agli ordini di acquisto.
- Ordinare una casella condivisa e preparare le risposte.
- Spostare dati tra due sistemi che non si parlano.
Cosa lasciare per dopo
Alcune cose vanno male come primo progetto, per quanto allettanti:
- Attività che capitano poche volte l’anno.
- Lavori le cui regole stanno nella testa di una sola persona.
- Qualsiasi cosa in cui un errore costa molto ed è difficile da vedere.
- Processi che stanno per cambiare comunque.
Sistema il processo prima di automatizzarlo
Automatizzare un processo confuso rende solo più veloce la confusione. Togli prima i passaggi inutili. Forse il problema si riduce ancora prima di costruire qualcosa.
Tieni piccola la prima fase
Punta a qualcosa che puoi provare con lavoro reale in poche settimane. All’inizio fallo girare accanto al processo manuale e confronta i risultati. Il nostro calcolatore dà un’idea del ritorno e la guida ai costi spiega cosa muove il prezzo.
Domande
Come scegliere tra due buoni candidati?
Scegli quello con gli errori più innocui. Un primo progetto deve poter sbagliare a basso costo mentre il team impara.
Servono prima dati puliti?
Non perfetti. Servono abbastanza esempi reali per provare e una persona che controlli ciò di cui il sistema non è sicuro.