Le decisioni che non si affidano all'AI

Ogni direzione che inizia a lavorare con l'AI si trova prima o poi davanti a questa domanda: quale decisione può prenderla un sistema, e quale decisione resta in mano a una persona. La domanda suona semplice. La risposta spesso non lo è, perché il confine non si trova nella decisione stessa ma in ciò che l'organizzazione ha organizzato attorno ad essa.

Perché questa domanda non si può rispondere con una lista

Non esiste una lista fissa di decisioni che per definizione devono restare umane. Un licenziamento, un rifiuto di credito, una valutazione medica: sono esempi spesso citati, ma il motivo per cui sono sensibili varia da organizzazione a organizzazione. Per un'istituzione si tratta di responsabilità giuridica, per un'altra dell'irreversibilità dell'esito, per una terza dell'assenza di un buon margine di errore. Chi copia una lista da un'altra organizzazione copia una risposta senza aver posto la domanda.

Ciò che funziona è invece analizzare la decisione stessa: qual è l'impatto se le cose vanno male, l'esito è recuperabile, e c'è qualcuno in grado di ricostruire e rendere conto dell'esito. Queste tre domande sono alla base di ciò che altrove viene chiamato regole per gli agenti: confini definiti che stabiliscono quando un sistema può procedere e quando deve fermarsi e coinvolgere una persona.

Perché questa è una questione organizzativa, non tecnica

La tentazione è grande di affidare questa domanda all'IT, come se fosse un'impostazione da configurare una volta per tutte. Non funziona, per un motivo semplice: una regola per gli agenti è affidabile solo se l'organizzazione che la circonda è a posto. Se nessuno sa chi è il proprietario di un processo, nessuno può stabilire chi è il punto di escalation. Se i dati non sono in ordine, un sistema non sa quando si trova di fronte a un'eccezione che richiede l'intervento umano. Le dimensioni fondamentali di un'organizzazione — governance, infrastruttura, gestione dei dati — vengono quindi prima della domanda su quali decisioni possano essere automatizzate. Senza questa base, ogni confine che traccia è un confine solo sulla carta.

Ecco perché questa domanda raramente vive in un solo punto dell'organizzazione. La direzione vede il rischio, il CIO vede la fattibilità tecnica, il responsabile del processo vede la pratica quotidiana. Come far convergere queste tre prospettive prima che il ritmo dell'automazione diventi motivo di disaccordo è descritto in come condurre il dialogo sul ritmo tra il consiglio di amministrazione e la direzione. Chi si pone questa domanda solo quando il primo progetto pilota è già in corso, se la pone troppo tardi.

Cosa fa e cosa non fa la misurazione della maturità

La misurazione della maturità di hybridresourcing rileva se un'organizzazione ha le basi per tracciare in modo significativo questo tipo di confini. Sette dimensioni, cinque livelli da baseline a intelligence, e un round di valutazione in cui più persone assegnano un punteggio indipendentemente l'una dall'altra. Questa dispersione è spesso l'elemento più utile: se un CHRO posiziona la maturità dei dati su activation e il CIO su baseline, si sa che prima deve avvenire un dialogo prima che venga scritta una regola che nessuno è in grado di eseguire.

Ciò che la misurazione non fa è dire quale decisione, nella vostra organizzazione, può essere automatizzata. Misura la prontezza, non l'idoneità di un compito specifico. Vi dice se l'organizzazione può sostenere ciò che l'AI è in grado di fare, non cosa l'AI rileverebbe concretamente. Questa distinzione tra sostenere e rilevare è la differenza tra sostenere l'AI e farsi rilevare l'AI, ed è una distinzione che questa pagina mantiene volutamente: un punteggio nella misurazione non è né una licenza né un divieto, è una fotografia dello stato in cui si trova l'organizzazione in questo momento.

Quella fotografia invecchia. Un'organizzazione che oggi ottiene un punteggio foundation per la gestione dei dati può trovarsi tra un anno su activation, oppure essere rimasta esattamente allo stesso punto. Quanto spesso sia utile ripetere la misurazione, e da cosa dipende, lo trovate in quanto spesso va ripetuta una misurazione della maturità. Una misurazione fatta una volta e poi finita in un cassetto ha poco valore; una misurazione che rimette in moto il dialogo nella direzione, invece, sì.

Cosa questo non risolve

La misurazione non risolve il disaccordo all'interno della vostra direzione. Lo rende visibile, e non è la stessa cosa. Se il vostro consiglio di amministrazione e la direzione sono già da tempo in disaccordo sul ritmo dell'adozione dell'AI, la causa spesso è più profonda della mancanza di dati: riguarda la propensione al rischio, chi viene ritenuto responsabile di cosa, cosa succede se qualcuno apre una finestra di chat e pensa di aver così introdotto l'AI in azienda. Ciò che non si vede se si conosce solo la finestra di chat è esattamente la parte dell'organizzazione a cui si riferisce questa domanda: l'infrastruttura, le regole, le persone che sanno quando un sistema deve fermarsi. Perché la vostra direzione è in disaccordo sul ritmo è illustrato in questa pagina, e spesso è più utile affrontare prima quel dialogo che aspettare che un progetto pilota si blocchi e la domanda torni comunque sul tavolo.

Dalla prontezza al compito

Questa pagina riguarda il confine che si traccia in anticipo: quale decisione resta in mano a una persona, indipendentemente da ciò che un sistema è tecnicamente in grado di fare. Non appena quel confine è definito approssimativamente, la domanda si sposta sul lavoro stesso: quali compiti all'interno di quel confine sono idonei a essere rilevati, e quale parte di una funzione resta lavoro umano indipendentemente dalla prontezza organizzativa. A questa domanda la misurazione della maturità non risponde. La scansione del lavoro di FTE TO AI calcola, per ciascun compito, quale parte del lavoro può essere rilevata dall'AI, e si collega così al punto in cui questa pagina si conclude: non se la vostra organizzazione è pronta, ma cosa c'è concretamente da rilevare non appena lo sarà.