Pratica

Il pilot che funzionava troppo bene

I pilot riescono e i deployment falliscono. Non è lo strumento che cambia, è l'ambiente che lo portava.

Seguiamo un pilot, dall'inizio alla sua fine ingannevole. Una direzione giuridica sceglie uno strumento promettente e lo affida a una piccola squadra per tre mesi. Cinque persone, motivate, che si parlano tutti i giorni. Provano lo strumento su un perimetro ristretto, aggiustano i loro usi strada facendo, si trasmettono oralmente le buone pratiche, si correggono a vicenda. Alla fine del trimestre, il bilancio è eccellente: guadagni di tempo misurabili, entusiasmo reale, ritorno sull'investimento evidente. La decisione cade, logica: si generalizza.

Sei mesi dopo il deployment su larga scala, la constatazione è tutt'altra. L'uso non è esploso come il pilot lasciava sperare; ha ristagnato, poi è rifluito. Gli utenti si servono dello strumento per qualche compito semplice e tornano ai loro metodi tradizionali per il resto. Lo strumento è ancora lì, sotto licenza, ma non è più al centro. Nessuno capisce bene perché, poiché è esattamente lo stesso strumento che aveva funzionato così bene in pilot.

Ed è proprio lì che si nasconde la risposta. Lo strumento è lo stesso; l'ambiente, invece, è completamente cambiato. In pilot, la coerenza non era tenuta dallo strumento, era tenuta dalle cinque persone attorno a esso. Il contesto era condiviso naturalmente perché tutti lavoravano sullo stesso perimetro. Il coordinamento era diretto perché bastava girarsi verso il vicino. Le regole d'uso erano informali perché una piccola squadra può aggiustarsi senza procedura. Lo strumento era immerso in un ambiente di coerenza che gli esseri umani producevano attorno a esso, senza nemmeno rendersene conto.

In pilot, non sono gli strumenti a tenere la coerenza. Sono gli esseri umani attorno a essi.

La rete umana che sparisce su larga scala

Quando si mette in campo questo stesso strumento alla scala di uno studio o di una direzione intera, questa rete umana sparisce. Le pratiche si moltiplicano e divergono. Gli utenti non si conoscono più, non si coordinano più direttamente. Le regole informali che bastavano a cinque diventano ingestibili a duecento. Il contesto cessa di essere condiviso spontaneamente. Lo strumento, invece, non è cambiato di un byte, ma l'ambiente che lo rendeva utile ha cessato di esistere. Si è generalizzato lo strumento senza poter generalizzare ciò che lo faceva funzionare.

Bisogna vedere bene che questa rete umana era invisibile proprio perché funzionava. Nessuno, in pilot, si diceva « io tengo la coerenza della squadra »; ciascuno lo faceva naturalmente, senza nominarlo, come un respiro. È questa invisibilità a intrappolare l'organizzazione: ciò che ha visto riuscire in pilot non era lo strumento solo, era lo strumento avvolto in un lavoro umano di coerenza così naturale da non essere mai stato percepito come un ingrediente del successo. Si generalizza ciò che si è visto, lo strumento, lasciandosi alle spalle ciò che non si è visto, l'involucro.

Il pilot non prova lo strumento. Prova lo strumento circondato da esseri umani che ne compensano le mancanze.

Ciò che la piccola dimensione offre gratuitamente

Per capire perché il pilot inganni sistematicamente, bisogna vedere tutto ciò che la piccola dimensione di una squadra fornisce senza fatturare. Cinque persone che si parlano tutti i giorni condividono un contesto senza sforzo: ciò che una sa, le altre lo imparano di passaggio, in una conversazione di corridoio, un'osservazione ad alta voce. Si coordinano senza procedura: basta girarsi verso il vicino. Si correggono senza dispositivo: una deriva si vede e si segnala immediatamente. Tutto ciò è gratuito, istantaneo, e perfettamente invisibile, perché prodotto dalla sola prossimità delle persone.

Questa gratuità è una trappola metodologica, perché falsa la misura. Quando si valuta un pilot, si attribuisce allo strumento tutto il guadagno osservato, mentre una parte considerevole di quel guadagno viene dall'ambiente gratuito che la piccola dimensione ha fornito. Si misura lo strumento più il suo involucro, e si attribuisce il risultato allo strumento solo. È un errore di imputazione: si accredita il componente visibile di un risultato prodotto dal componente invisibile, e si prende una decisione di generalizzazione sulla fede di questa falsa imputazione.

Il pilot soffre dunque di un bias strutturale che nessun rigore di esecuzione corregge. Si può condurre il pilot con la più grande cura, misurare precisamente i guadagni, documentare gli usi: finché si svolge a piccola scala, continuerà a misurare lo strumento in un ambiente che non esisterà più su larga scala. Non è un difetto di metodo che un metodo migliore risolverebbe; è un limite inerente al dispositivo del pilot stesso, che per costruzione prova in condizioni non riproducibili.

Le quattro funzioni che il pilot maschera

Si può spingere l'analisi più in là e nominare ciò che il pilot maschera esattamente. In una piccola squadra, quattro funzioni invisibili sono assicurate in permanenza dalle persone. Qualcuno sa sempre a che punto è la pratica. Qualcuno ricorda ciò che è stato deciso la settimana scorsa. Qualcuno individua che un uso devia dalla regola comune. Qualcuno tiene a mente chi ha il diritto di vedere cosa. Queste quattro funzioni non sono scritte da nessuna parte, non costano nulla di apparente, e sono tuttavia il basamento che rende lo strumento utile. Il pilot non le prova, perché sono fornite gratuitamente dalla piccola dimensione della squadra.

Su larga scala, queste quattro funzioni non spariscono: diventano impossibili da assicurare a mano. Nessuno può più sapere a che punto è ciascuna delle trecento pratiche, né ricordare le decisioni di tutte le squadre, né sorvegliare tutti gli usi, né tenere mentalmente la mappa dei permessi. Ciò che era gratuito in pilot diventa, su larga scala, o fuori prezzo, o semplicemente assente. Ed è la loro assenza, non un difetto dello strumento, a far crollare l'uso. Lo strumento si ritrova nudo, privato dell'involucro che lo rendeva utile, e la sua prestazione grezza, da sola, non basta a tenere il lavoro reale.

Ecco perché il fallimento del deployment non è un fallimento dello strumento, e cambiare strumento non cambierà nulla. Ciò che manca al deployment è uno strato organizzativo che prenda in carico, su larga scala, ciò che la piccola squadra assicurava a mano: il contesto condiviso, la coerenza metodologica, il coordinamento degli usi, la tracciabilità, la governance. A cinque, queste funzioni possono riposare sulle persone. A duecento, devono essere portate dall'architettura, o non sono portate da nessuno.

A cinque, la coerenza riposa sulle persone. A duecento, deve essere portata dall'architettura, o da nessuno.

C'è una ragione per cui queste quattro funzioni non si lasciano semplicemente ricreare con della procedura, una volta su larga scala. Si potrebbe credere che basti scrivere regole, nominare responsabili, formalizzare ciò che era informale. Ma ciò che le cinque persone facevano era continuo, contestuale, adattivo: non seguivano una regola, giudicavano in situazione. Trasformare questo in procedura produce una burocrazia pesante che cattura male ciò che pretende di sostituire, e che nessuno segue a duecento. Queste funzioni non si ri-formalizzano; si ri-strumentano, affidando a uno strato ciò che la procedura non saprà mai tenere.

Perché il ciclo si ripete per anni

C'è un dettaglio psicologico che aggrava il malinteso, e vale la pena di nominarlo. Il pilot riuscito crea un'attesa, quasi una promessa implicita fatta all'organizzazione: se cinque persone hanno guadagnato tanto tempo, trecento ne guadagneranno proporzionalmente di più. Questa estrapolazione pare evidente, ed è falsa, perché presuppone che il guadagno venga dallo strumento solo, mentre veniva dallo strumento più l'ambiente di coerenza che le cinque persone producevano gratuitamente. Si estrapola il numeratore dimenticando il denominatore.

Ecco perché il fallimento del deployment è così spesso vissuto come un tradimento, e così raramente compreso. I dirigenti hanno visto il pilot con i loro occhi; sanno che lo strumento funziona, poiché l'hanno constatato. Quando l'uso crolla su larga scala, cercano un colpevole: un difetto di formazione, una resistenza delle squadre, una cattiva scelta di strumento. Cambiano strumento, rilanciano un pilot, che riesce di nuovo, ridistribuiscono, e falliscono di nuovo. Il ciclo può durare anni, perché la vera causa, l'assenza di strato, non è mai nominata.

Uscire da questo ciclo presuppone un cambiamento di sguardo su cosa sia un pilot. Un pilot non prova che uno strumento terrà su larga scala; prova soltanto che è buono in un ambiente in cui degli esseri umani tengono la coerenza al suo posto. È un'informazione utile, ma parziale, e confonderla con una prova di deployment è l'errore più costoso del mercato attuale. Il buon pilot non è quello che prova lo strumento solo, ma quello che prova lo strumento sotto lo strato di orchestrazione che lo accompagnerà su larga scala.

Un pilot non prova che uno strumento terrà su larga scala. Prova che è buono quando degli esseri umani tengono la coerenza al suo posto.

Provare l'oggetto giusto

È esattamente il ruolo per cui MAX è stato concepito: una Legal Semantic Layer che mantiene su larga scala ciò che i pilot tengono a piccola scala in modo informale. Uno strato che trasforma il passaggio dal pilot al deployment, oggi vissuto come una regressione inspiegata, in un cambiamento di regime padroneggiato. Il pilot riusciva perché degli esseri umani tenevano la coerenza; il deployment riesce quando uno strato la tiene al loro posto. Non è un supplemento allo strumento, è ciò che mancava tra il pilot e la scala.

Questo spostamento cambia il modo stesso di condurre un pilot. Un pilot utile non è più quello che mette cinque persone motivate attorno a uno strumento per vedere se se ne servono bene, poiché se ne serviranno sempre bene a cinque. È quello che prova lo strumento nelle condizioni del deployment reale: senza la rete umana, sotto lo strato che dovrà tenere la coerenza su larga scala. Un tale pilot predice qualcosa; l'altro predice solo la propria riuscita, in condizioni che non si riprodurranno mai.

La prossima generazione di organizzazioni non giudicherà dunque più uno strumento sulla sua prestazione in pilot, che non prova quasi nulla, ma sulla sua capacità di tenere una volta che lo strato di orchestrazione è in atto. Il pilot resterà utile per valutare un mattone; cesserà di essere confuso con una prova di deployment. E il giorno in cui questa distinzione sarà acquisita, il ciclo dei pilot riusciti e dei deployment falliti, che costa al mercato anni e budget interi, cesserà finalmente di ripetersi.

Gli strumenti non hanno fallito su larga scala. L'architettura che avrebbe dovuto circondarli non è mai esistita.