Dove l'automazione va storta: 6 modelli di guasto e come progettare in base ad essi

La maggior parte dei progetti di automazione falliscono in modi prevedibili, senza sorprese tecniche. Si ripetono gli stessi sei modelli: automatizzare un processo interrotto, ignorare le eccezioni, spedire senza monitoraggio, costruire fragili robot per lo screen-scraping, trattare il modello come l’intero sistema e saltare il passaggio umano. Ciascuno ha una correzione di progettazione nota. La versione breve è automatizzare un processo che effettivamente comprendi, progettare per i casi che non si adattano al percorso felice, osservare l'oggetto in produzione e decidere in anticipo chi lo possiede quando si rompe. Se si eseguono correttamente queste quattro cose, la maggior parte delle modalità di errore non verranno mai visualizzate. I modelli seguenti nominano ciascuno di essi, spiegano come si presenta una volta che dati reali e persone reali incontrano il sistema e forniscono la correzione da applicare prima di scrivere qualsiasi codice.

Perché i progetti di automazione falliscono così spesso?

Di solito falliscono per ragioni organizzative, non algoritmiche. La tecnologia funziona in una demo, poi incontra dati reali, eccezioni reali e persone reali che non hanno mai accettato di cambiare il loro modo di lavorare. I sondaggi di settore rilevano ripetutamente che la maggior parte delle iniziative di automazione e AI si bloccano prima di fornire un valore duraturo e le ragioni sono coerenti. Il processo non è mai stato ben compreso, nessuno possedeva il risultato o il sistema non aveva modo di gestire gli input che avrebbe effettivamente ricevuto. I modelli seguenti sono le forme specifiche che assume il fallimento.

Quali sono i sei modelli di fallimento e come progettarli in base a ciascuno di essi?

1. Automazione di un processo interrotto. Accelerare un processo errato produce semplicemente risultati negativi più rapidamente, che ora sono più difficili da vedere perché sono eseguiti da una macchina. La soluzione è mappare e correggere il processo prima di codificarlo. Rimuovi la fase di approvazione ridondante, correggi l'immissione di dati che causa rielaborazioni a valle, quindi automatizza ciò che rimane. La nostra guida sull'automazione dei processi aziendali illustra come eseguire questa operazione nell'ordine corretto.

2. Nessuna gestione delle eccezioni. I team costruiscono il percorso felice perché questo è ciò che ha mostrato la demo. In produzione, un fornitore invia un PDF in un nuovo formato, un campo è vuoto, un API scade e l'intero ciclo si interrompe o, peggio, elabora silenziosamente la cosa sbagliata. Progettare per le eccezioni fin dall'inizio. Decidi per ogni passaggio cosa succede quando l'input non è corretto, manca o è ambiguo: riprova, indirizza a una persona o interrompi ad alta voce. Un sistema che sa quando non sa vale più di uno che è fiduciosamente sbagliato.

3. Nessun monitoraggio o osservabilità. Un'automazione che nessuno controlla è una responsabilità in attesa di emergere. Può andare alla deriva, fallire parzialmente o fermarsi silenziosamente e lo scopri da un cliente piuttosto che da una dashboard. Strumentalo prima di spedirlo. Registra ogni esecuzione, monitora i tassi di successo e di eccezioni, avvisa quando i volumi o i tassi di errore escono dai limiti normali e mantieni una traccia di controllo di ciò che il sistema ha deciso e perché. Se non puoi vedere cosa ha fatto, non puoi fidarti di esso.

4. RPA fragile su un'interfaccia utente fragile. L'automazione robotica dei processi che fa clic sulle schermate si interrompe nel momento in cui un fornitore sposta un pulsante o cambia il layout di una pagina. È veloce da costruire e costoso da mantenere. Preferisci il punto di integrazione più stabile disponibile: un vero API, un database o un feed di file, in quest'ordine. Riserva l'automazione a livello di schermo ai sistemi che effettivamente non offrono altro accesso e tratta questi robot come la parte che con maggiore probabilità necessita di manutenzione.

5. Trattare il modello come un sistema intero. Un modello capace è un componente, non una soluzione. Collegare un modello linguistico direttamente a un utente senza convalida, senza barriere e senza fallback produce un sistema che è impressionante finché non è sbagliato in un modo che ti costa. Avvolgi il modello nell'impianto idraulico. Convalidare i suoi risultati, limitare ciò su cui può agire, registrare le sue decisioni e definire cosa succede quando la fiducia è bassa. Questo è uno dei motivi principali per cui i prototipi promettenti si bloccano, un tema che trattiamo in Piloti pilota di AI che non raggiungono mai la produzione.

6. Nessun passaggio di consegne da parte di esseri umani. La piena autonomia è il valore predefinito sbagliato per qualsiasi cosa consequenziale. Se non esiste un percorso chiaro che consenta a una persona di rivedere i casi limite, correggere gli errori e prendere il controllo quando il sistema è incerto, il primo caso difficile diventa una crisi. Progettare deliberatamente il passaggio di consegne. Decidi quali decisioni necessitano di un coinvolgimento umano, rendi visibile la coda dei casi segnalati e assicurati che la restituzione a una persona sia una modalità operativa normale, non un'emergenza.

Come si fa a capire se un'automazione è progettata ben prima di realizzarla?

Prima di impegnarti, esegui il progetto attraverso una breve lista di controllo. Le risposte espongono precocemente la maggior parte dei modelli di cui sopra, quando è ancora economico risolverli.

Domanda da porre	Risposta debole	Risposta forte
Comprendiamo il processo attuale?	"Lo scopriremo mentre automatizziamo."	Un processo mappato con volumi ed eccezioni noti.
Cosa succede ai casi che non si adattano?	"Gestisce il caso standard."	Routing definito per tentativi, eccezioni e input ambigui.
Come sapremo che sta funzionando?	"Qualcuno se ne accorgerà se si rompe."	Registrazione, metriche, avvisi e traccia di controllo in atto.
Con cosa si integra?	"Si fa clic attraverso l'interfaccia web."	Un API, un database o un feed di file stabile, ove possibile.
Chi lo possiede quando è sbagliato?	"Funziona da solo."	Un proprietario nominato e un percorso di consegna umano funzionante.

Rispondere a queste domande prima di scrivere una sola riga di codice è la fase di audit del nostro lavoro di automazione dei processi.

Il pratico asporto

I modelli di guasto sono prevedibili, così come lo sono anche le domande di progettazione. Prima di automatizzare qualsiasi cosa, assicurati di comprendere il processo, di aver pianificato gli input che non si comporteranno, di poter vedere cosa sta facendo il sistema una volta eseguito e di sapere chi interviene quando ottiene qualcosa di sbagliato. La maggior parte degli errori di automazione sono semplicemente una di queste domande lasciate senza risposta finché la produzione non ha risposto per te.