Tag Archive for: imprese

Quando faccio progetti (di strategia, di riorganizzazione del marketing, di introduzione dell’AI), un’interessante situazione nella quale mi imbatto (credo comune a molti e molte) è che ci sono alcune incomprensioni iniziali che non sono tecnologiche: le persone fanno fatica a identificare cosa vogliono risolvere (dove spesso il racconto è focalizzato su sintomi e soluzioni) e le organizzazioni non hanno deciso chi può decidere cosa (per cui c’è un momento di lentezza per capire qual è il giro del fumo).

Non è una novità e il fatto che si riproponga in contesti diversi, con strumenti diversi, in aziende di dimensioni diverse è per me interessante. L’AI adesso è solo l’ultimo sintomo, più visibile degli altri perché arriva con aspettative alte e risultati spesso deludenti.

Il risultato è prevedibile: si introducono strumenti senza rivedere i processi, si ottimizza localmente quello che si rompe sistemicamente, si crea nuovo muda (spreco) credendo di eliminarlo ¹.

Tre problemi concreti che trovo in sequenza, quasi sempre in quest’ordine.

Primo problema: non sai cosa stai risolvendo

L’errore più comune (nell’introduzione di qualsiasi strumento, AI inclusa) non è scegliere la soluzione sbagliata, ma è scegliere la soluzione prima di aver definito il problema.

Usiamo l’AI per fare le sintesi delle riunioni.

Bene. E quelle sintesi le usa qualcuno? Generano decisioni? Cambiano qualcosa?

No, ma almeno le abbiamo.

Questo è waste con un’interfaccia moderna. Nessuno strumento lo trasforma in valore, lo produce più velocemente (il famigerato AI Slop).

Prima di qualsiasi introduzione serve una domanda brutalmente semplice: qual è il problema che stiamo cercando di risolvere, e come fa questo strumento a risolverlo? Se la risposta è vaga, il problema non è ancora definito. E se il problema non è definito, qualsiasi soluzione è prematura. ²

Ma c’è un prerequisito ancora più a monte, che ho affrontato nel post precedente: per definire un problema con sufficiente precisione da poterlo delegare (a un collaboratore, a un team, a un sistema AI) hai bisogno di conoscenza dichiarativa, la capacità di descrivere quello che fai, i criteri con cui decidi, il risultato che vuoi ottenere. Chi non ha sviluppato questa competenza non riesce a identificare il problema in modo utilizzabile e finisce per delegare un compito che nemmeno lui sa definire con precisione ³.

C’è poi una seconda domanda da fare, che viene quasi mai fatta:

questo è un problema mio, del mio team, o dell’organizzazione?

Perché la risposta cambia completamente chi deve risolverlo, con quali strumenti e con quale livello di autonomia.

Secondo problema: non hai deciso chi può decidere cosa

Che si tratti di riorganizzare il marketing, introdurre un nuovo processo o adottare strumenti AI, il problema sottostante è quasi sempre lo stesso: manca una struttura chiara di governance. Chi può usare quali strumenti, per quali attività, con quali output attesi, con quale livello di autonomia non è sempre chiaro perché è parte (più frequentemente di quanto vorrei) di una conoscenza implicita, non dichiarata e che quindi deve essere trovata.

Senza questa struttura succedono due cose opposte e ugualmente dannose.

• La prima: le persone non agiscono perché non sanno se possono, se devono, se è appropriato.
• La seconda: le persone agiscono in modo non coordinato, producendo output incompatibili, processi ridondanti, e una frammentazione del lavoro che è peggio della situazione di partenza.

Quello che serve (e che poche organizzazioni hanno costruito in modo esplicito) è qualcosa che somiglia a una costituzione dell’autonomia ⁴: un insieme di principi chiari che definisce le aree in cui il problem solving locale è abilitato e le aree in cui serve coordinamento. Non un manuale operativo non una policy di 40 pagine. Un frame che risponde a: cosa puoi decidere da solo, cosa devi concordare, cosa non puoi fare senza autorizzazione esplicita.

Senza questo frame, ogni persona e ogni team risolve il problema come può, con gli strumenti che ha, secondo criteri che non sono condivisi. L’organizzazione diventa una collezione di ottimizzazioni locali che non si sommano mai in efficienza sistemica.

⁵

Terzo problema: il lavoro di orchestrazione frammenta l’attenzione

Quando nuovi strumenti entrano nel flusso di lavoro (e l’AI lo fa in modo particolarmente pervasivo) il lavoro cambia natura. Non scompare: si trasforma. Meno produzione diretta, più orchestrazione: definire il task, verificare l’output, correggere, iterare, integrare.

Questo sembra un miglioramento. In parte lo è, ma introduce un effetto collaterale che si rischia di sottovalutare: la frammentazione dell’attenzione.

Se ogni quindici minuti verifico l’output di un processo delegato (a un agente AI, a un collaboratore remoto, a un sistema automatizzato) sto lavorando su più cose contemporaneamente in modo strutturale (e ho già mostrato in un post precedente cosa produce il multitasking sul rendimento “Perché è pericoloso lavorare su più progetti”): il multitasking non è un’abilità. È un costo.

Il context switching non sparisce con l’AI, si moltiplica, perché le istanze di lavoro si moltiplicano.

Questo ha un’implicazione diretta su come organizzare il lavoro: non per attività, ma per blocchi di risultato.

La domanda non è “cosa faccio adesso?” ma “qual è il risultato che voglio avere al termine di questo blocco di tempo, e come organizzo gli strumenti per ottenerlo senza dover verificare ogni quindici minuti?” e oltretutto torniamo a un ripensamento profondo delle attività per evitare di rendere più inefficienti processi non pensati per l’AI.

Il focus si sposta ancor di più dall’attività all’impatto ovvero dal tempo lavorato al risultato prodotto. Non è una novità concettuale (è la logica del lavoro per obiettivi, degli OKR, di qualsiasi approccio che mette il risultato prima del processo).

Ma la moltiplicazione degli strumenti rende questa transizione non più opzionale.

⁶

Il problema dell’accountability che nessuno vuole affrontare

C’è un quarto problema, che non viene quasi mai nominato esplicitamente: è il più scomodo, ed è quello che rischia di avere le conseguenze più serie in particolare con l’AI, ma non solo.

Chi risponde quando qualcosa va storto?

Per rispondere con precisione, possiamo sfruttare uno strumento che il project management usa da decenni: una RAM, Responsibility Assignment Matrix, una matrice che mappa ruoli e responsabilità su attività o deliverable. Il PMBOK del PMI la definisce come strumento per illustrare le connessioni tra work package e membri del team di progetto ⁷.

La RACI (il tipo di RAM più usato) assegna a ogni attività quattro ruoli: chi esegue (Responsible), chi risponde del risultato (Accountable), chi viene consultato (Consulted), chi viene informato (Informed). Una regola fondamentale, ribadita dal PMBOK: per ogni attività deve esserci un solo Accountable. Non due. Non nessuno. Uno.

Ora prova ad applicare questa logica a un processo che include un sistema AI.

L’AI non può essere Accountable, per lo meno non nel senso tecnico del termine. Accountable significa rispondere del risultato, avere skin in the game, subire le conseguenze di una decisione sbagliata. Un sistema non risponde, non subisce conseguenze, non impara nel senso in cui impara una persona che ha sbagliato e ne porta il peso.

Questo non è un problema filosofico, è un problema operativo immediato.

In questo momento, tutta la responsabilità dell’output di un sistema AI ricade sull’operatore, la persona o l’organizzazione che ha scelto di usarlo, che lo ha configurato, che ha accettato il risultato. Anche quando il risultato è sbagliato. Anche quando l’errore era nel modello, nel training data, in una deriva che l’utente non aveva modo di prevedere.

Il parallelo più preciso è quello della guida autonoma. In caso di incidente, chi risponde? Il guidatore che non aveva le mani sul volante? Il produttore del software? La casa automobilistica? La risposta legale è ancora in costruzione, ma la risposta operativa attuale è che il guidatore è Accountable, perché era nella posizione di controllo.

Con l’AI in azienda funziona esattamente così. L’operatore risponde sempre. Anche se ha fatto “tutto bene”. La delega al sistema non riduce la responsabilità, la maschera, finché non emerge il problema.

Questo ha due implicazioni concrete che le organizzazioni quasi mai considerano esplicitamente.

1. Il livello di controllo iniziale non può essere basso. Un sistema AI non è un collaboratore che ha già dimostrato di meritare autonomia. È un sistema che deve guadagnarsi la fiducia attraverso output verificati, iterazioni corrette, perimetri testati. Il controllo non è inefficienza, ma è il costo necessario di un sistema che non può essere Accountable per sé stesso.
2. Il controllo non può probabilmente essere mai eliminato del tutto. Può essere ridotto, può essere spostato, può essere automatizzato in parte, ma la catena di accountability deve sempre terminare in una persona. Non in un sistema. Non in un processo. In qualcuno che può rispondere.

Questo è il motivo per cui introdurre qualsiasi strumento senza aver prima definito la governance dell’autonomia non è solo inefficiente. È un rischio che l’organizzazione sta assumendo senza averlo nominato (soprattutto in una narrazione dove adesso possiamo fare più cose: facciamo più cose, ma come le controlliamo senza diventare controllori a tempo pieno?).

Da dove si parte

Da tre domande, in quest’ordine.

La prima: qual è il problema che voglio risolvere? Torniamo sempre allo SMART: Specifico, misurabile, collegato a un risultato atteso. Se la risposta è vaga, il lavoro è ancora a monte e prima di rispondere serve la capacità di descrivere il proprio lavoro con sufficiente precisione dichiarativa.

Senza quella, il problem solving rimane procedurale: si agisce per intuizione, non per definizione ⁸ .

La seconda: chi è Accountable del risultato, e come lo verifico? Senza questa risposta l’organizzazione sta delegando responsabilità a qualcuno o qualcosa che non può tenerla.

La terza: come organizzo il lavoro per evitare che l’orchestrazione frammenti l’attenzione più di quanto lo strumento la liberi? Il guadagno di efficienza si perde se il context switching diventa strutturale.

L’AI è uno strumento potente, ma il problema che trovo spesso negli assessment non è mai lo strumento: è sempre la struttura che manca prima dello strumento e la struttura, come quasi sempre, non è un problema tecnologico ⁹.

Altri approfondimenti interessanti:

Report Deloitte – State of AI in the Enterprise – Solo il 21% delle imrpese ha pensato/impostato una governance per gli agenti AI

Riflessione di Sara Malaguti /Flowerista) – Cosa stai difendendo davvero? Ovvero, la Struttura