Molti anni fa, in una base militare americana in Sicilia, mi sono imbattuto in un documento che, a prima vista, rappresentava l'antitesi perfetta di quel principio. Mi trovavo a Sigonella nei primi anni Novanta. Supervisionavo, tra l'altro, la schedulazione per la costruzione di un nuovo complesso destinato alle telecomunicazioni satellitari, un edificio che avrebbe ospitato le apparecchiature di una stazione di terra SATCOM.
Le imponenti parabole destinate alle comunicazioni satellitari, strutture che a un osservatore non esperto potrebbero apparire simili ai radiotelescopi ma che in realtà sono progettate per la trasmissione di dati verso i satelliti piuttosto che per l’osservazione astronomica, erano orientate verso il cielo siciliano con la meticolosità di un professionista esperto: un agricoltore di grande esperienza, o un sicario della Mafia…
Il loro compito era trasmettere e ricevere in banda Ku e in banda X, mantenendo il link con i transponder in orbita geostazionaria a trentaseimila chilometri di quota: uplink, downlink, handover fra satelliti, il ciclo ininterrotto della comunicazione militare via spazio.
Quel complesso, oggi, è pienamente operativo. Attraverso le sue antenne passano i segnali che guidano i velivoli senza pilota che decollano dalla pista di Sigonella e raggiungono destinazioni che i giornali raccontano con un misto di reticenza e inquietudine. Ma questa è un'altra storia.
Il documento in mio possesso era una specifica tecnica del Naval Facilities Engineering Command (NAVFAC) della United States Navy, relativa alla pianificazione dei progetti costruttivi nelle basi americane all’estero. Circa venti pagine, contenenti prescrizioni dettagliate in merito alla preparazione, presentazione, aggiornamento e documentazione del cronoprogramma di cantiere, utilizzando Primavera Project Planner, il software leader nel settore della pianificazione nell’edilizia pubblica americana all’epoca e che, nella sua evoluzione in Primavera P6, continua a ricoprire un ruolo predominante anche oggi nel settore IT, a me più familiare.
Lo schedulatore seguiva rigide regole. Ogni deviazione comportava il rigetto. Anche il formato di stampa dei diagrammi era definito: dimensioni, orientamento, colori e attività sul percorso critico. Il calendario dei giorni non lavorativi doveva essere costruito sulla base dei dati meteorologici storici della zona, come un radioastronomo che calibra il proprio strumento sul rumore di fondo specifico del sito di osservazione. Il look-ahead settimanale andava consegnato ogni lunedì all'alba, in tre copie cartacee e una copia elettronica, con la puntualità di un bollettino meteo di stazione.
Chi non ha familiarità con la burocrazia militare americana potrebbe trovare il livello di dettaglio eccessivo. Chi la conosce sa che è appena sufficiente.
Nell’amministrazione federale degli Stati Uniti, si ripone una fiducia assoluta nel potere della documentazione formale. Si ritiene che la meticolosa registrazione di ogni procedura e decisione garantisca un controllo capillare e, di conseguenza, l’eliminazione di qualsiasi errore o imprevisto. Tuttavia, la persistenza di problematiche operative, talvolta addirittura aggravate dalla complessità burocratica, rappresenta un paradosso che il sistema sembra incapace di riconoscere, forse a causa della necessità di una specifica prescrizione per la sua identificazione e risoluzione.
Il documento più noioso del mondo, si potrebbe pensare. E in effetti, nella sua superficie testuale, lo era. Scritto nel linguaggio burocratico-prescrittivo più puro che l'amministrazione federale americana abbia saputo produrre, un linguaggio la cui funzione primaria era eliminare ogni ambiguità interpretativa, ogni spazio di discrezionalità, ogni possibilità che due esseri umani ragionevoli potessero leggere la stessa frase e intenderla in modo diverso.
Un linguaggio giuridico, presumibilmente concepito per i contesti giudiziari, data la frequente necessità di risolvere controversie contrattuali nell’ambito dell’edilizia pubblica statunitense attraverso un intervento giudiziario, spesso da parte di magistrati privi di specifica competenza nel settore. Tuttavia, a distanza di trent’anni dalla lettura di tali documenti, con la prospettiva maturata attraverso tre decenni di progettazione di flussi di lavoro per organizzazioni di diversa natura, emerge un elemento di rilevanza contemporanea. Al di là della sua natura prescrittiva, la specifica del NAVFAC conteneva, in forma embrionale e inconsapevole, la medesima preoccupazione epistemologica che animava il mio ricevitore a onde corte: rendere manifesta l’informazione altrimenti latente.
La differenza fondamentale sta nel paradigma con cui si persegue questa ossessione. Il ricevitore a onde corte è uno strumento di percezione: amplia la capacità sensoriale, permette di cogliere segnali già presenti e lascia libero di interpretarli. La specifica del NAVFAC era uno strumento di controllo: stabilisce cosa osservare, come rappresentarlo, quando comunicarlo e a chi. Il primo strumento apre un mondo, il secondo lo recinta. Questa distinzione, fondamentale per ciò che segue, un giorno forse la racconterò meglio in un libro.
Karl Weick, nel suo magistrale Sensemaking in Organizations, ha mostrato che la realtà organizzativa è un costrutto sociale continuamente negoziato: le organizzazioni creano retroattivamente la propria struttura, dando senso a posteriori a ciò che è accaduto.
Un flusso di lavoro, in questa prospettiva, contribuisce a far esistere il processo nel momento stesso in cui pretende di descriverlo. Quando introduco uno stato "revisione del codice" in un flusso di sviluppo software, sto creando le condizioni affinché quella fase venga percepita come distinta, nominata, misurabile, e quindi reale per i membri del gruppo di lavoro.
Gli stati che si scelgono, i nomi che si assegnano, le transizioni che si permettono o si proibiscono: tutto questo plasma il modo in cui le persone comprenderanno il proprio lavoro, ne parleranno, lo negozieranno. Ogni progettazione di un flusso di lavoro è, che lo si sappia o meno, un atto di costruzione della realtà organizzativa.
La specifica del NAVFAC operava lo stesso meccanismo, con una differenza cruciale: lo faceva senza saperlo. Quando prescriveva che ogni attività del cronoprogramma dovesse essere identificata con un Activity ID, un Activity Name, una Original Duration in Work Days, una Remaining Duration, una percentuale di completamento fisico, una Start Date, una Finish Date e un Total Float, stava costruendo un linguaggio per descrivere la realtà del cantiere.
E ogni linguaggio, come Weick insegna, è simultaneamente una lente e un vincolo: rende visibili certi aspetti della realtà e ne oscura altri. L'Activity ID rendeva visibile l'identità dell'attività. Il Total Float rendeva visibile il margine temporale disponibile.
La percentuale di completamento fisico rendeva visibile il progresso. Il significato dell'attività per chi la eseguiva, la qualità delle relazioni fra le squadre che si avvicendavano sul cantiere, la conoscenza tacita che il capocantiere possedeva e che nessun campo del software di schedulazione poteva catturare: tutto questo restava invisibile, anzi, veniva attivamente espulso dal campo di osservazione.
Come un ricevitore radio che filtra le frequenze indesiderate, la specifica scartava il segnale umano come fosse QRM, interferenza da eliminare.
Antonio Scala ha ampliato l’intuizione di Weick all’ambito dell’infosfera digitale, dimostrando la presenza di una dinamica analoga nei sistemi algoritmici. La sua concezione di topologia non-euclidea dell’informazione evidenzia un aspetto che il linguaggio convenzionale della progettazione dei processi non è in grado di rappresentare: nello spazio informativo di un’organizzazione, la distanza tra due contenuti è variabile in base ai percorsi che li connettono.
Due stati di un flusso possono essere vicini concettualmente e appartenere alla stessa fase, ma risultare remoti operativamente per un gruppo che non prevede quella transizione. La geometria del flusso di lavoro emerge dall’uso, dalle transizioni effettive, dagli stati adiacenti nella pratica e dai percorsi naturali per ripetizione.
Nel suo libro “Thinking in Systems”, Donella Meadows spiega che i sistemi complessi funzionano bene quando le informazioni giuste arrivano alle persone giuste al momento giusto. Un cronoprogramma mal progettato, come un flusso di lavoro mal progettato, interrompe questi circuiti, generando dati ignorati, nascondendo informazioni critiche e producendo metriche incomprensibili.
La specifica del NAVFAC cercava di risolvere questo problema imponendo la compilazione obbligatoria di ogni campo, la consegna di ogni report e il rispetto di ogni formato. Questo approccio, seppur logico, confonde dato e informazione: un dato è ciò che viene registrato, un’informazione è un dato che modifica la comprensione. Milioni di dati non generano automaticamente comprensione.
In tre decenni di pratica e riflessione, ho individuato cinque principi progettuali per flussi di lavoro che generano conoscenza. Li chiamo principi del radiotelescopio organizzativo. Sorprendentemente, li ho trovati, seppur deformati e compressi, anche nella specifica del NAVFAC.
Il principio della sensibilità al segnale insegna che un radiotelescopio è progettato per captare frequenze specifiche, isolando determinate bande dello spettro elettromagnetico. Allo stesso modo, un flusso di lavoro deve essere selettivo, evidenziando gli aspetti cruciali per le decisioni e scartando il resto. Creare flussi onnicomprensivi è rischioso, come un ricevitore radio senza filtri che produce solo un sibilo.
La specifica NAVFAC definiva il Longest Path come il percorso critico del progetto, la sequenza di attività che ne determinava la durata. Le attività sul Longest Path erano il segnale, mentre le altre erano il contesto. Definiva inoltre “Near Critical” le attività con Total Float entro quattordici giorni dal massimo del Longest Path, e stabiliva che attività critiche e near-critical non superassero il venti per cento del totale.
Questa regola di sensibilità indicava che se più del venti per cento delle attività risultava critico, il cronoprogramma era troppo dettagliato e andava scomposto in attività più piccole per migliorare la chiarezza.
Ho maturato esperienza nella gestione di progetti IT nel settore bancario, dove la domanda fondamentale a cui il flusso doveva rispondere era “chi ha interagito con questa attività e in quale momento?”, al fine di garantire la tracciabilità necessaria per la conformità normativa. In progetti per il settore del lusso, la domanda principale era “sarà questo sviluppo completato in tempo per il lancio della collezione?”, per assicurare la sincronizzazione con i cicli commerciali.
A Sigonella, la domanda era differente: “il cronoprogramma del contractor è compatibile con le finestre operative della base?”, poiché un cantiere in una base militare attiva deve rispettare vincoli di sicurezza, di frequenza radio e di accesso che un cantiere civile non considera. Progettare la sensibilità del flusso implica, prima di qualsiasi configurazione, la definizione della domanda a cui lo strumento deve consentire di rispondere.