Gli agenti di intelligenza artificiale funzionano bene in condizioni di normale operatività e falliscono in caso di eccezioni, che rappresentano proprio la parte più complessa di qualsiasi attività commerciale. Un ordine standard viene elaborato automaticamente; è con un ordine con consegna parziale, un cliente con un problema in sospeso e un accordo commerciale negoziato telefonicamente che diventa chiaro se l'automazione contribuisce o ostacola.
Nei processi che abbiamo mappato, questo insieme di casi "rari" rappresenta in genere tra 15% e 30% del volume. Non si tratta di un residuo: è un quarto dell'operazione e di solito concentra una proporzione molto maggiore di valore e rischio.
Perché non si possono insegnare in venti minuti. Una dimostrazione deve essere comprensibile, e le eccezioni sono, per definizione, ciò che non è comprensibile senza conoscere il settore.
Ciò crea una distorsione sistematica nelle decisioni di acquisto. Lo strumento viene valutato in base al semplice 70%, viene firmato e il difficile 30% appare in produzione, quando non si tratta più di una decisione di acquisto ma di un problema di progetto. È la stessa dinamica che abbiamo descritto quando parlavamo del purgatorio del pilotaL'episodio pilota, per sua stessa natura, evita tutto ciò che potrebbe rendere difficile la produzione.
C'è anche una ragione tecnica. Un modello linguistico non distingue tra "non lo so" e "non corrisponde a ciò che ho visto". Di fronte a un caso atipico, non si ferma: colma le lacune. Produce una risposta plausibile basata sugli schemi che conosce, e tale risposta ha lo stesso tono di certezza di quelle corrette. In un processo automatizzato, questa indistinguibile sicurezza è il problema, non le occasionali allucinazioni.
|
Tipo |
Esempio |
Come trattarlo |
|
Dati mancanti o contraddittori |
Il cliente risulta avere due diversi codici fiscali. |
Fermati e sali: non sceglierne mai uno |
|
Regola aziendale non scritta |
Condizione concordata verbalmente con un cliente |
Documentare la regola o escludere il cliente dal flusso |
|
Soglia superata |
Importo, volume o sconto fuori intervallo |
Validazione umana obbligatoria |
|
Stato incompatibile |
Ordine a un cliente con pagamento in sospeso |
Blocco con motivazione esplicita |
|
caso legalmente delicato |
Dati sanitari, minori, decisioni riguardanti le persone |
Fuori dalla portata dell'agente |
L'utilità di questa tabella non è teorica: è la sceneggiatura per una sessione di lavoro di due ore con le persone che stanno attualmente implementando il processo. La domanda da porre loro non è "come funziona il processo" - lo spiegheranno nella loro versione ideale - ma «"Parlami dell'ultimo caso che ti ha dato problemi."». In un pomeriggio, tre o quattro persone che rispondono a quella domanda riescono a produrre la mappa completa delle eccezioni.
L'aspetto più importante nella progettazione di un sistema automatizzato è ciò che accade in condizioni di incertezza. E affinché accada qualcosa, deve esserci la possibilità che il sistema segnali un'incertezza.
Ciò richiede tre decisioni di progettazione:
Definisci cosa si intende per condizione di arresto. Non un punteggio di affidabilità astratto, ma condizioni aziendali concrete: questi dati mancano, questo importo supera la soglia, questo cliente si trova in questa situazione. Le condizioni comprensibili a una persona sono quelle che possono essere verificate e discusse in un comitato.
Definire dove applicare la scalabilità. Una coda specifica, con un responsabile e una scadenza. Un'eccezione che viene inoltrata a una casella di posta generica non è stata risolta: è stata rinviata.
Definire quali informazioni accompagnano la misurazione. L'agente dovrebbe presentare un dossier preparato: cosa ha trovato, cosa manca e quali opzioni vede. È qui che risiede la maggior parte del risparmio di tempo, e questo si mantiene anche se la decisione finale viene presa da una persona.
Un sistema progettato in questo modo non automatizza il 100% del processo. Automatizza l'intero 70% e preparare i restanti 30%. In quasi tutti i casi che abbiamo misurato, questo produce un risparmio netto maggiore rispetto al tentativo di automatizzare il 100% e dover rivedere tutto a causa della sfiducia.
C'è una conseguenza culturale da prevedere. Quando l'indicatore presentato al comitato è la "percentuale di automazione", il team è incentivato a ridurre le escalation, e il modo più rapido per farlo è estendere l'ambito di competenza dell'operatore a casi che non dovrebbe gestire.
Pertanto, l'indicatore corretto non è la percentuale automatizzata, ma il costo totale per caso risolto correttamente. Un sistema che automatizza il 70% e si adatta bene al 30% è solitamente più economico di uno che automatizza il 95% e genera rilavorazioni, reclami e sfiducia nel 25%, che non avrebbe dovuto modificare.
Un tasso di crescita sano non è un tasso basso. È un tasso stabile e spiegabile.
Non c'è bisogno di riscriverlo. Il percorso usuale si compone di tre fasi e può essere eseguito senza interrompere l'operazione:
L'errore da evitare è cercare di implementare tutto in una volta. Un sistema con due livelli ben allineati è infinitamente più gestibile di uno con cinque livelli parzialmente allineati.
La mappatura delle eccezioni non è una fase preliminare del progetto di IA; è il progetto stesso. Se eseguita correttamente, produce quattro risultati che si reggono da soli, indipendentemente dal fatto che vengano successivamente automatizzati o meno:
Questo è esattamente il lavoro che facciamo prima di proporre qualsiasi automazione, ed è il motivo per cui insistiamo sul fatto che Innanzitutto si definisce il processo, poi lo si automatizza. . Non si tratta di una preferenza metodologica: è l'unico modo per sapere quale parte del processo può essere automatizzata senza scoprirlo in fase di produzione.
Quando un fornitore presenta una soluzione basata su agenti, chiedete una cosa specifica: che la demo includa il raro caso a tua scelta.
Non si tratta di un caso generico e raro. È un tuo caso, con i tuoi dati incompleti e le tue regole aziendali non scritte. La risposta a questa richiesta distingue chi ha costruito un sistema da chi ha creato una presentazione.
Se la risposta è che questo caso verrà affrontato in una fase successiva, saprete già dove si concentrerà lo sforamento dei costi del progetto.
Poiché un modello linguistico non distingue tra "non lo so" e "questo non corrisponde a ciò che ho visto", di fronte a un caso atipico, non si ferma, ma completa il processo. Produce una risposta plausibile con lo stesso tono di certezza di quelle corrette, rendendo l'errore difficile da individuare all'interno di un processo automatizzato.
Nei processi che abbiamo mappato, questi si verificano tipicamente tra 15% e 30% del volume, sebbene concentrino una proporzione maggiore del valore e del rischio. Non si tratta di un residuo statistico: è una parte sostanziale dell'operazione effettiva.
Invece di chiedere a chi lo implementa di descrivere il processo, chiedetegli di parlarvi dell'ultimo caso problematico. Con tre o quattro persone, è possibile ottenere una mappatura completa in una sola sessione. Le tipologie più comuni sono: dati mancanti o contraddittori, regole non scritte, superamento di una soglia, stato incompatibile e casi legalmente sensibili.
Fermarsi e risalire, con tre elementi definiti in anticipo: condizioni di arresto espresse in termini commerciali, una coda specifica con responsabile e scadenza, e un pacchetto informativo che include cosa è stato trovato, cosa manca e quali opzioni sono state individuate.
Normalmente no. Automatizzare l'intero processo 70% e preparare i restanti 30% di solito si traduce in un risparmio netto maggiore rispetto all'automazione del processo 95%, che genera rilavorazioni, reclami e sfiducia nei casi che non dovrebbero essere automatizzati. L'indicatore corretto è il costo per caso risolto con successo, non la percentuale di casi automatizzati.
Includete un caso di studio raro, scelto dal cliente, con i suoi dati incompleti e le sue regole aziendali non scritte. Se il fornitore rimanda tale caso a una fase successiva, è lì che si manifesterà lo sforamento dei costi del progetto.
|
Prima di automatizzare, mappiamo. Identifichiamo il processo effettivo, le regole non scritte e le eccezioni che impedirebbero qualsiasi automazione, e ti indichiamo quali parti meritano di essere automatizzate. Due ore di analisi senza impegno. Parliamone → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
