Vedere l'invisibile: progettare workflow come radiotelescopi organizzativi

Calogero (Kàlos) Bonasia

Questo saggio propone un framework teorico originale per la progettazione di workflow che integra la semiotica organizzativa di Karl Weick, i pattern formali di Wil van der Aalst, il design centrato sull'umano di Donald Norman e il pensiero sistemico di Donella Meadows. L'obiettivo è rifondare concettualmente la disciplina della workflow design, liberandola dalla prigione del "management scientifico" taylorista e restituendole la sua vera natura: uno strumento di sensemaking collettivo.

Un framework semiotico per il sensemaking dei processi digitali

Da quando lavoro con i sistemi informativi: ciò che non si vede non significa che non esista, ma soltanto che non abbiamo ancora costruito lo strumento giusto per percepirlo. Così come le onde radio attraversano continuamente lo spazio intorno a noi, portando informazioni, segnali, messaggi. Eppure restano invisibili, inudibili, impercettibili ai nostri sensi biologici. Solo costruendo un dispositivo appropriato – un'antenna, un ricevitore, un demodulatore – possiamo rendere manifesto ciò che era latente, trasformare il silenzio cosmico in informazione comprensibile.

ciò che non si vede non significa che non esista, ma soltanto che non abbiamo ancora costruito lo strumento giusto per percepirlo

Questa intuizione – che chiamerò il principio del radiotelescopio epistemologico – attraversa discipline apparentemente distanti. La professoressa Amelia Carolina Sparavigna docente al Politecnico di Torino l'ha applicata recentemente alla diagnostica medica e industriale, usando autoencoder per "vedere l'invisibile" nei suoni respiratori patologici o negli spettri vibrazionali anomali[^1]. La sua ricerca dimostra che distinguere il segnale dal rumore è un problema epistemologico: cosa significa "normale" e come riconosciamo ciò che da questo si discosta?

Questa domanda mi ha accompagnato per diverso tempo, quando mi trovavo di fronte a un'organizzazione che mi chiedeva di "disegnare un workflow per Jira". La domanda reale è: quale parte della realtà organizzativa vogliamo rendere visibile? Quali segnali deboli vogliamo amplificare? Quale rumore vogliamo filtrare?

Un workflow ben progettato è un radiotelescopio organizzativo: un dispositivo semiotico che trasforma i processi invisibili in pattern leggibili, che permette a un'organizzazione di vedere se stessa mentre lavora, di distinguere il segnale (il lavoro che genera valore) dal rumore (le inefficienze, le eccezioni, i workaround). Come un radiotelescopio non calibrato correttamente produce solo interferenze, un workflow mal progettato genera soltanto dati privi di significato, metriche falsate, report che servono solo per abbellire graficamente qualche presentazione in PowerPoint.

[^1]: Amelia Carolina Sparavigna, Gemini (Modello Linguistico di Google), "Il suono del respiro e l'AI", Zenodo, 2025, DOI: 10.5281/zenodo.17806231.

Il problema fondamentale: l'illusione della trasparenza

La maggior parte dei project manager crede che il lavoro sia naturalmente visibile. Se qualcuno sta "facendo qualcosa", questo qualcosa dovrebbe essere ovvio, misurabile, tracciabile. È un'illusione pericolosa, figlia di un'epistemologia ingenua che confonde "ciò che accade" con "ciò che riusciamo a vedere di ciò che accade".

Karl Weick, nel suo magistrale Sensemaking in Organizations, ci ricorda che la realtà organizzativa è un costrutto sociale continuamente negoziato[^2]. Le organizzazioni creano retroattivamente la propria struttura e i propri processi, dando senso a posteriori a ciò che è accaduto. Il sensemaking – il processo attraverso il quale gli individui e i gruppi costruiscono significato condiviso a partire da eventi ambigui – è l'attività fondamentale che permette alle organizzazioni di esistere come entità coordinate.

Un workflow è un dispositivo di enactment: contribuisce a far esistere il processo nel momento stesso in cui pretende di descriverlo. Quando introduco uno stato "Code Review" in un workflow di sviluppo software, sto creando le condizioni affinché quella fase venga percepita come distinta, nominata, misurabile, e quindi reale per i membri del team.

Ogni workflow design è un atto di costruzione della realtà organizzativa

Questo ha conseguenze pratiche profonde. Ogni workflow design è un atto di costruzione della realtà organizzativa. Gli stati che scelgo, i nomi che assegno, le transizioni che permetto o proibisco: tutto questo plasma il modo in cui il team comprenderà il proprio lavoro, ne parlerà, lo negozierà.

Wil van der Aalst e colleghi, nel loro Workflow Patterns: The Definitive Guide, hanno catalogato sistematicamente le strutture ricorrenti nei processi di business, creando un linguaggio formale per descrivere sequenze, parallelismi, scelte, iterazioni[^3]. I loro pattern – dal semplice sequence pattern al complesso milestone pattern – forniscono gli elementi costitutivi per costruire workflow espressivi. Van der Aalst si occupa della sintassi. I pattern ci dicono come modellare determinate strutture di controllo, non perché scegliere una struttura invece di un'altra, né quali conseguenze cognitive e sociali avrà quella scelta sul team che dovrà usare il workflow.

Serve un framework più ampio, che connetta la formalizzazione tecnica dei pattern con la comprensione delle dinamiche organizzative e cognitive. Un framework che riconosca che progettare workflow è progettare percezioni.

[^2]: Karl E. Weick, Sensemaking in Organizations, Sage Publications, 1995, ISBN 9780803971776. [^3]: Nick Russell, Wil M.P. van der Aalst, Arthur H.M. ter Hofstede, Workflow Patterns: The Definitive Guide, MIT Press, 2016, ISBN 9780262029827.

Il framework del radiotelescopio organizzativo

Propongo di pensare ai workflow come radiotelescopi organizzativi: dispositivi progettati per rendere percepibili fenomeni che altrimenti resterebbero invisibili. Questa metafora suggerisce un insieme di principi progettuali radicalmente diversi da quelli che guidano il design tradizionale dei workflow.

Primo principio: sensibilità al segnale

Un radiotelescopio è progettato per essere sensibile a specifiche frequenze, per isolare determinate bande dello spettro elettromagnetico. Allo stesso modo, un workflow deve essere progettato per rendere visibili specifici aspetti del processo.

La tentazione comune è creare workflow onnicomprensivi: stati per ogni possibile micro-fase, transizioni per ogni eventualità, campi custom per ogni informazione che "potrebbe servire". Il risultato è un sistema sovraccarico di informazione irrilevante – rumore che copre il segnale.

Negli anni ho configurato workflow per contesti estremamente diversi: dal manifatturiero al luxury retail, dall'aerospaziale alla pubblica amministrazione. Ogni contesto aveva domande diverse. In progetti per il settore bancario, la domanda critica era "chi ha toccato questo ticket e quando?" – tracciabilità per audit e compliance. In progetti per il retail di lusso, la domanda era "questo sviluppo è pronto per il deployment in produzione prima del lancio della collezione?" – sincronizzazione con cicli di business. Nel primo caso, il workflow doveva rendere visibile la catena di custodia; nel secondo, lo stato di readiness rispetto a milestone esterne.

Progettare la sensibilità del workflow significa chiedersi: quale domanda deve permettermi di rispondere? È la differenza tra un sensore che registra temperature casuali e un termometro calibrato su una scala rilevante per decisioni specifiche.

Questo principio collima con ciò che Donella Meadows chiama "information feedback loops" nel suo Thinking in Systems[^4]. Un sistema – e un'organizzazione è un sistema – funziona bene quando le informazioni giuste raggiungono i decision-makers giusti al momento giusto. Un workflow mal progettato interrompe questi loop: genera dati che nessuno legge, nasconde informazioni critiche in campi che nessuno compila, crea metriche che nessuno comprende.

[^4]: Donella H. Meadows, Diana Wright (ed.), Thinking in Systems: A Primer, Chelsea Green Publishing, 2008, ISBN 9781603580557.

Secondo principio: distinzione segnale/rumore

I radiotelescopi usano sofisticati algoritmi di filtraggio per distinguere i segnali cosmici dal rumore di fondo. La maggior parte di ciò che captano è interferenza: disturbi elettromagnetici terrestri, radiazioni di fondo, artefatti strumentali. Il segnale interessante è sempre una piccola frazione del totale.

Qui emerge un parallelismo illuminante con il lavoro della professoressa Sparavigna sugli autoencoder per l'anomaly detection. Nella sua ricerca sulla diagnostica respiratoria, utilizza autoencoder addestrati esclusivamente su suoni "normali" per identificare patologie[^5]. Quando l'autoencoder incontra un suono anomalo – un crepitio patologico, un wheezing – l'alto errore di ricostruzione segnala un errore semantico: il dato in input non aderisce alle caratteristiche apprese dello stato di normalità. L'autoencoder impara cosa significa "normale", e segnala tutto ciò che da questo si discosta.

Analogamente, in un processo di lavoro reale, la maggior parte delle attività sono rumore operazionale: attese, sincronizzazioni, micro-task amministrativi, workaround per problemi contingenti. Il lavoro di valore – ciò che effettivamente trasforma input in output utili per il cliente o per l'organizzazione – è una frazione sorprendentemente piccola del tempo totale.

Un workflow dovrebbe essere progettato per isolare questo segnale. Renderlo riconoscibile, permettere di misurarlo separatamente. Come l'autoencoder descritto negli studi della professoressa Amelia Sparavigna addestrato sulla normalità rileva qualsiasi deviazione – anche patologie mai viste prima – un workflow progettato sul "flusso normale" dovrebbe automaticamente rivelare eccezioni impreviste: nuovi tipi di blocco, pattern di lavoro emergenti, disfunzioni inedite.

In un progetto di supporto applicativo per il settore luxury, ho analizzato diciotto mesi di dati su attività completate. L'analisi ha rivelato che oltre la metà del workload derivava da modifiche richieste dal cliente (scope changes) durante l'esecuzione. Questo dato era invisibile nel workflow originale: tutte le attività erano trattate come equivalenti, indipendentemente dal fatto che fossero pianificate o reattive. Ridisegnando il workflow per distinguere "planned work" da "client-driven changes", abbiamo reso visibile un pattern che stava erodendo sistematicamente la capacità predittiva del team.

Questo è sensemaking in azione: abbiamo creato uno strumento che rendeva i cambiamenti misurabili, discutibili, gestibili. Il workflow ha trasformato un'intuizione vaga ("il cliente cambia sempre idea") in un fatto quantificabile che poteva essere portato nelle negoziazioni contrattuali.

[^5]: Amelia Carolina Sparavigna, Gemini (Modello Linguistico di Google), "Il suono del respiro e l'AI", Zenodo, 2025, DOI: 10.5281/zenodo.17806231.

Terzo principio: calibrazione contestuale

Un radiotelescopio deve essere calibrato per l'ambiente specifico in cui opera. La stessa antenna che funziona perfettamente nel deserto del New Mexico riceverebbe solo interferenze se collocato nel centro di una qualunque città. La calibrazione corretta si basa su considerazioni riguardo l'ambiente elettromagnetico locale, i disturbi specifici, le caratteristiche della localizzazione.

Un workflow esiste all'interno di una specifica ecologia organizzativa: una cultura aziendale, una distribuzione di competenze, una configurazione di potere, un insieme di sistemi tecnici interconnessi. Ignorare questo contesto produce workflow teoricamente eleganti ma praticamente inutilizzabili.

Don Norman, nel suo The Design of Everyday Things, introduce il concetto di gulf of execution e gulf of evaluation[^6]: il divario tra l'intenzione dell'utente e le azioni permesse dal sistema (gulf of execution), e il divario tra lo stato del sistema e la comprensione che l'utente ne ha (gulf of evaluation). Un workflow mal progettato crea entrambi i golfi: rende difficile per gli utenti fare ciò che vogliono fare (troppi stati, transizioni poco chiare, campi obbligatori inutili), e rende impossibile capire lo stato reale del lavoro guardando il workflow (stati ambigui, metriche fuorvianti).

In un contesto dove il team è piccolo (3-5 persone) e altamente collaborativo, un workflow minimalista con 4-5 stati può essere perfetto: le persone si coordinano informalmente, il workflow serve solo a mantenere traccia dello stato aggregato. Lo stesso workflow in un contesto enterprise con cinquanta o più persone distribuite geograficamente sarebbe catastrofico: servono stati intermedi per l'handover tra ruoli, transizioni vincolate da permission, campi obbligatori per forzare la documentazione.

Lavorando con il settore bancario ho imparato questo principio. L'iter burocratico richiede passaggi formali, approvazioni gerarchiche, motivazioni scritte di ogni decisione – perché quei processi sono soggetti a audit esterni e controlli di legalità. La calibrazione contestuale richiede di comprendere quali vincoli normativi, culturali, politici plasmano le pratiche di lavoro.

[^6]: Donald A. Norman, The Design of Everyday Things (Revised and Expanded Edition), Basic Books, 2013, ISBN 9780465050659.

Quarto principio: risoluzione appropriata

I radiotelescopi hanno differenti gradi di risoluzione. Un survey telescope mappa ampie porzioni di cielo con bassa risoluzione, identificando oggetti interessanti. Un telescopio dedicato poi li osserva con altissima risoluzione, rivelando dettagli invisibili al survey. Entrambi sono necessari; nessuno dei due potrebbe sostituire l'altro.

Analogamente, workflow diversi servono livelli di risoluzione diversi. Un workflow per Epic (iniziative strategiche) deve avere bassa risoluzione: pochi stati, transizioni semplici, focus sul valore di business. Un workflow per Task (attività operative quotidiane) può avere risoluzione più alta: più stati intermedi, tracking dettagliato del progresso.

L'errore comune è usare lo stesso workflow per tutte le tipologie di issue. Ho visto Epic con quindici stati che includevano "Unit Testing" e "Code Review" – stati che non hanno senso a quel livello di astrazione. E ho visto Task con tre stati generici ("To Do", "In Progress", "Done") che nascondono completamente la complessità dell'esecuzione.

La risoluzione appropriata deriva da una domanda semplice: a quale scala temporale e organizzativa si situa questo tipo di lavoro? Epic che durano mesi non possono essere tracciati con la stessa granularità di Task che durano ore. La risoluzione deve corrispondere alla frequenza delle decisioni che verranno prese basandosi su quelle informazioni.

Quinto principio: interpretabilità del segnale

I dati grezzi raccolti da un radiotelescopio sono inutili senza interpretazione. Serve un modello teorico che spieghi cosa significano certe frequenze, certe modulazioni. L'interpretazione trasforma il segnale in conoscenza.

Un workflow genera dati: timestamp, transizioni, assegnazioni, durate. Questi dati sono interpretabili solo se il workflow ha una semantica chiara. Se uno stato si chiama "In Progress", cosa significa? L'attività è stata avviata? Qualcuno ci sta lavorando attivamente? È in attesa di input esterni? L'ambiguità semantica rende i dati generati dal workflow fondamentalmente non interpretabili.

Nella ricerca sugli autoencoder si spiega che l'errore di ricostruzione è una metrica diretta e trasparente: un valore alto significa semplicemente "questo dato è estraneo al dominio appreso"[^7]. Questa interpretabilità è cruciale per la diagnostica: un medico deve capire perché il sistema segnala un'anomalia.

Analogamente, le metriche di workflow ben progettate devono essere direttamente interpretabili. Un alto tempo di permanenza in uno stato significa "c'è un collo di bottiglia qui"; un'alta percentuale di transizioni di ritorno significa "il processo ha problemi di qualità"; un alto rapporto tra lavoro pianificato e non pianificato significa "gli scope changes stanno erodendo la capacità predittiva". Metriche chiare generano sensemaking; metriche opache generano confusione.

Questo è particolarmente critico per il cycle time (tempo dall'inizio alla fine di un work item), che sembra una metrica oggettiva. Ma cosa significa "inizio"? La creazione dell'issue? La prima transizione da "To Do" a "In Progress"? E cosa significa "fine"? Quando va in "Done"? Quando viene deployato in production? Quando il cliente accetta il deliverable?

Senza una semantica condivisa e rigorosa degli stati, il cycle time è solo un numero privo di significato. In progetti diversi con workflow diversi, quel numero misura cose completamente diverse, rendendo impossibili confronti o benchmark.

La progettazione per interpretabilità richiede che ogni stato abbia una definizione operazionale precisa: una descrizione esplicita di cosa deve essere vero perché un work item sia legittimamente in quello stato. Questa è la "Definition of Done" estesa a ogni stato del workflow.

[^7]: Amelia Carolina Sparavigna, Gemini (Modello Linguistico di Google), "A Deep Learning Approach for Acoustic Anomaly Detection: The Encoder as a Semantic Feature Extractor for Industrial Machinery Sound", Zenodo, 2025, DOI: 10.5281/zenodo.17787427.

I punti di leva: dove intervenire nei sistemi workflow

Donella Meadows, poco prima della sua morte, pubblicò un saggio che è diventato un classico del pensiero sistemico: "Leverage Points: Places to Intervene in a System"[^8]. Identificava dodici punti in cui interventi relativamente piccoli in un sistema possono produrre cambiamenti disproportionati. I punti più efficaci – ma anche i meno ovvi e i più difficili da manipolare – riguardano i paradigmi e i mental model che generano il sistema stesso.

Applicando questo framework ai workflow, scopriamo che la maggior parte dei project manager interviene nei punti di leva meno efficaci: aggiungono stati, modificano transizioni, creano campi custom. Sono interventi al livello più basso della gerarchia di Meadows – modifiche ai parametri del sistema. Funzionano, producono cambiamenti marginali.

I punti di leva più potenti per migliorare i workflow sono altrove:

[^8]: Donella H. Meadows, "Leverage Points: Places to Intervene in a System", Whole Earth Review, 1997. Poi incluso in Thinking in Systems, 2008.

Modificare i feedback loop

Un sistema si auto-regola attraverso feedback loop: informazioni che ritornano al decisore permettendogli di correggere la rotta. Un workflow crea feedback loop quando rende visibili ai team le conseguenze delle loro azioni.

Esempio: in un workflow senza distinzione tra lavoro pianificato e modifiche richieste dal cliente, il team non riceve mai feedback sul fatto che accettare ogni richiesta di modifica sta erodendo la loro capacità di completare il lavoro pianificato. Il sistema non ha meccanismi auto-correttivi.

Introdurre quella distinzione crea un feedback loop: il team vede il rapporto cambiare settimana dopo settimana. Quando raggiunge il 60-70% di workload reattivo, diventa evidente che serve rinegoziare il contratto o i termini di ingaggio. Il workflow genera l'informazione che permette la correzione.

Cambiare le regole del sistema

Le regole – chi può fare cosa, quando, a quali condizioni – determinano il comportamento del sistema. Nei workflow, le regole sono incarnate in conditions, validators, permissions.

Un esempio potente: molti workflow permettono a chiunque di "riaprire" issue chiuse. Sembra una regola flessibile e pragmatica. Genera comportamenti disfunzionali: invece di creare nuovo work item quando emerge nuovo lavoro, si riapre il vecchio. Questo inquina i dati storici, rende impossibile misurare il cycle time reale, nasconde l'accumulo di "rework" che segnala problemi di qualità.

Cambiare la regola – proibire la riapertura, forzare la creazione di nuovo issue collegato – cambia radicalmente il comportamento del sistema. Rende visibile un pattern (la quantità di rework) che prima era nascosto.

Modificare l'accesso all'informazione

Chi può vedere quali informazioni quando? Questa è una leva poderosamente sottovalutata. Molti workflow sono progettati assumendo che "più trasparenza = meglio". Questo non è sempre vero.

In alcuni contesti (pubblica amministrazione, settori regolamentati), la visibilità indiscriminata crea problemi. Un work item che contiene dati personali sensibili non può essere visibile a tutti. In altri contesti, la segmentazione eccessiva dell'informazione crea silos e impedisce il coordinamento.

Progettare chi vede cosa richiede di comprendere le strutture di potere dell'organizzazione. L'informazione è potere; controllare l'accesso all'informazione è controllare chi può agire. Un workflow che rende visibili a tutti i tempi di lavorazione individuali può generare pressioni sociali costruttive (nessuno vuol essere il collo di bottiglia) oppure distruttive (gaming delle metriche, competizione tossica). Il risultato dipende dalla cultura organizzativa preesistente.

Cambiare i paradigmi

Molto più difficile è cambiare i paradigmi: i presupposti fondamentali che strutturano la percezione della realtà.

Il paradigma dominante nel workflow design è che il workflow serve a controllare le persone. Gli stati definiscono cosa le persone possono o non possono fare; le transizioni limitano i movimenti; i validator forzano comportamenti. È un paradigma discendente dal management scientifico taylorista: l'organizzazione come macchina, i lavoratori come ingranaggi da disciplinare.

Il paradigma alternativo che propongo: il workflow serve a generare sensemaking collettivo. Gli stati nominano fasi del processo precedentemente implicite, permettendo al team di parlarne; le transizioni rivelano handover e dipendenze; i dati raccolti creano una rappresentazione condivisa della realtà che facilita il coordinamento.

Il primo paradigma genera workflow punitivi: molti controlli, poca flessibilità, focus sul compliance. Il secondo genera workflow abilitanti: stati chiari, transizioni intuitive, focus sull'apprendimento.

Cambiare il paradigma richiede di cambiare le domande che ci poniamo durante il design. Non "come impedisco alle persone di fare X?" ma "come rendo visibile X in modo che il team possa decidere collettivamente se è un problema?". Non "come forzo comportamento Y?" ma "come creo condizioni in cui Y è la scelta più naturale?".

Pattern anti-sensemaking: quando i workflow oscurano invece di rivelare

Così come van der Aalst ha catalogato workflow patterns efficaci, possiamo identificare anti-pattern ricorrenti che distruggono la capacità di sensemaking dei workflow. Questi pattern sono diffusissimi – li ritrovo in almeno il 60% dei workflow che mi vengono sottoposti per revisione – e rappresentano i modi più comuni in cui i workflow falliscono nella loro funzione semiotica.

Anti-pattern 1: "l'eufemismo semantico"

Stati con nomi vaghi, confortevoli, privi di contenuto operazionale. "In Progress", "In Lavorazione", "Work in Progress", "Doing", "Active": tutti modi per dire "qualcuno dovrebbe occuparsene, forse".

Il problema è che sono semanticamente collassati: non permettono di distinguere tra "ho iniziato a lavorarci attivamente", "sto aspettando input esterni", "è bloccato ma non posso metterlo formalmente in stato Blocked", "l'ho aperto per sbaglio e non ho voglia di chiuderlo". Tutte queste situazioni profondamente diverse vengono compresse nello stesso stato indistinto.

Il risultato: metriche di "work in progress" che mentono, perché aggregano attività attivamente lavorate con attività dimenticate in un limbo.

La cura: stati con predicati verificabili. Non "In Development", ma "Code Writing" + "Code Review" + "Automated Testing". Ogni stato descrive un'attività specifica, con un owner chiaro e una definizione di completamento. Se non riesci a dire "questa attività è in Code Writing perché X, Y, Z", allora "Code Writing" è un eufemismo semantico.

Anti-pattern 2: "il labirinto delle eccezioni"

Workflow che includono transizioni per gestire ogni possibile caso eccezionale. Il risultato: da ogni stato partono 7-8 transizioni, rendendo impossibile capire qual è il flusso normale.

Questo pattern nasce da un'idea sbagliata di completezza: l'idea che un workflow "completo" deve permettere di gestire ogni eventualità. Le eccezioni, per definizione, sono rare e imprevedibili. Tentare di modellarle tutte produce un grafo di stati e transizioni incomprensibile.

Qui ritorna utile l'intuizione della Sparavigna sullo sbilanciamento come risorsa: nella diagnostica respiratoria, il dataset ICBHI contiene molti più campioni "normali" che patologici. Questo sbilanciamento, che rappresenterebbe un problema per i modelli di classificazione supervisionata tradizionali, diventa un vantaggio per l'anomaly detection tramite autoencoder. L'addestramento esclusivo sulla normalità permette al modello di rilevare deviazioni patologiche, anche quelle mai viste prima[^9].

Analogamente, nei workflow organizzativi, il "flusso normale" è sempre preponderante rispetto alle eccezioni. Un workflow dovrebbe essere progettato sul flusso standard, lasciando che le eccezioni emergano come deviazioni misurabili. Lo sbilanciamento naturale tra casi normali ed eccezionali è una proprietà da sfruttare per il design.

La soluzione più efficace potrebbe essere quella di progettare workflow per il flusso normale (80% dei casi) + meccanismi espliciti per eccezioni (stato "Exception" o "Needs Resolution"). Le eccezioni escono temporaneamente dal flusso standard, vengono gestite manualmente, e poi rientrano. Questo mantiene il workflow principale leggibile e rende visibile il tasso di eccezioni – un segnale importante di problemi nel processo.

[^9]: Amelia Carolina Sparavigna, Gemini (Modello Linguistico di Google), "Il suono del respiro e l'AI", Zenodo, 2025, DOI: 10.5281/zenodo.17806231.

Anti-pattern 3: "il parking lot ontologico"

Stati usati come categorie invece che come fasi. "Cliente X", "Alta Priorità", "Team Alpha", "Q4 2024": questi sono attributi del work item, non stati del processo.

Il sintomo: work item che rimangono nello stesso "stato" per settimane o mesi. Ma come può un'attività rimanere nella stessa fase per due mesi e continuare a progredire? Quello è una label mascherata da stato.

Questo pattern distrugge la capacità del workflow di rivelare il progresso reale. Le metriche di cycle time diventano prive di senso. L'analisi dei colli di bottiglia è impossibile.

Soluzione: distinguere rigorosamente tra stati (fasi del processo) e attributi (proprietà del work item). Stati: "Requirements", "Design", "Implementation", "Testing". Attributi: Priority field, Team field, Release field, Customer field. Gli attributi vanno in campi custom.

Anti-pattern 4: "il buco nero della conclusione"

Stato "Done" o "Closed" da cui però partono transizioni di ritorno. Se da Done puoi tornare a In Progress, allora Done non è done.

Questo pattern nasce da una comprensibile esigenza operativa: a volte emerge nuovo lavoro su qualcosa che pensavamo completato. Gestirlo riaprendo l'issue originale è una soluzione comoda ma deleteria. Distrugge la tracciabilità storica: quel work item che risulta chiuso il 15 gennaio, in realtà è stato riaperto il 3 febbraio e richiuso il 10 febbraio. Rende impossibile calcolare metriche affidabili. E, soprattutto, nasconde un pattern importante: la quantità di rework.

La cura: stati finali sono finali. Nessuna transizione di ritorno. Se emerge nuovo lavoro, si crea nuovo work item collegato al precedente (relazione "follow-up" o "caused by"). Questo mantiene la tracciabilità, preserva le metriche storiche, e rende visibile il rework come fenomeno misurabile.

Anti-pattern 5: "la transizione fantasma"

Transizioni che esistono nel workflow ma non vengono mai usate (o vengono usate <1% delle volte). Sono lì "perché non si sa mai", "in caso servisse", "l'abbiamo messa per sicurezza".

Il problema è che queste transizioni inutilizzate generano incertezza cognitiva: "devo usare questa transizione in questo caso specifico?". Inoltre, la loro presenza nasconde qual è il flusso normale – se ci sono 6 transizioni possibili da uno stato, qual è quella che dovrei usare di default?

Progettare per l'uso reale, quindi. Iniziare con workflow minimali. Aggiungere transizioni solo quando emerge evidenza empirica che servono. Rimuovere transizioni che non vengono usate.

Anti-pattern 6: "l'interrogatorio obbligatorio"

Transizioni che richiedono la compilazione di 6-8 campi obbligatori. Ogni transizione diventa un form da riempire, rallentando drasticamente il flusso.

Questo pattern nasce dal desiderio di raccogliere "dati completi". Viola un principio fondamentale del design centrato sull'umano: ogni richiesta di informazione ha un costo cognitivo. Chiedere 8 campi quando ne servirebbero 2 genera frustrazione, resistenza, e alla fine gaming del sistema (le persone inseriranno dati fittizi pur di procedere).

Soluzione: parsimonia nei campi obbligatori. Massimo 2-3 per transizione, e solo se quell'informazione è assolutamente critica per decisioni immediate. Le informazioni "nice to have" vanno in campi opzionali.

Anti-pattern 7: "il mosaico di workflow"

Usare workflow diversi per issue types che seguono processi sostanzialmente identici. Ho visto organizzazioni con quindici workflow diversi, uno per ogni sfumatura di tipo di issue, dove le differenze erano cosmetiche.

Il problema: mantenere quindici workflow coerenti è impossibile. Si evolvono in modo divergente. Le persone non sanno quale usare. Le metriche diventano incomparabili.

Soluzione: workflow condivisi per famiglie di processi omogenei. Meglio un workflow un po' generico che serve bene cinque tipologie di issue, che cinque workflow leggermente diversi tra loro che creano frammentazione.

Progettare per il sensemaking: metodologia operativa

Fin qui teoria. Ma come si traduce concretamente in pratica progettuale? Presento qui un metodo in cinque fasi che ho sviluppato e raffinato configurando workflow per oltre novanta organizzazioni.

Fase 1: ascolto epistemologico

La raccolta delle specifiche deve essere un processo di esplorazione epistemologica: capire come le persone nell'organizzazione costruiscono significato intorno al loro lavoro.

Le domande sono diverse da quelle di un'analisi tradizionale:

Non "quali sono i passaggi del processo?", ma "quando sapete che un'attività è davvero iniziata?"
Non "chi fa cosa?", ma "quando qualcosa va storto, a chi vi rivolgete?"
Non "quanto tempo dura ogni fase?", ma "quali attività vi sembrano durare troppo e perché?"
Non "quali informazioni servono?", ma "quale decisione non potete prendere per mancanza di informazioni?"

Queste domande rivelano la struttura tacita del processo: le assunzioni implicite, i rituali non scritti, i criteri informali di qualità che governano il lavoro reale. È questa struttura tacita che il workflow deve rendere esplicita.

Fase 2: mappatura dei segnali critici

Serve identificare quali sono i segnali critici – gli eventi, le transizioni, le condizioni che hanno impatto su decisioni importanti.

Un segnale critico è tale se risponde positivamente ad almeno una di queste domande:

Se non sapessimo questo, prenderemmo decisioni sbagliate?
Se questo evento non accadesse, il processo fallirebbe?
Se questo dato fosse impreciso, si propagherebbero errori a valle?

Gli stati del workflow devono corrispondere ai momenti in cui si generano o si consumano segnali critici. Transizioni devono corrispondere a eventi che cambiano lo stato informativo del sistema.

Fase 3: progettazione della semantica degli stati

Ogni stato deve avere una definizione operazionale rigorosa. Uso questo template:

Nome stato: [verbo attivo + sostantivo, es. "Reviewing Code"] Condizioni di ingresso: [cosa deve essere vero per entrare in questo stato] Attività caratteristica: [cosa si fa tipicamente in questo stato] Output atteso: [cosa viene prodotto] Condizioni di uscita: [cosa deve essere vero per uscire da questo stato] Owner: [chi è responsabile del work item in questo stato]

Esempio per stato "Code Review":

Condizioni di ingresso: Codice committato su branch, build automatica passata, unit test > 80% coverage
Attività caratteristica: Revisione del codice da parte di almeno un tech lead
Output atteso: Feedback scritto, approvazione o richiesta di modifiche
Condizioni di uscita: Almeno un'approvazione esplicita e nessun "request changes" aperto
Owner: Tech Lead del team

Questa definizione rigorosa elimina l'ambiguità semantica e rende il workflow interpretabile.

Fase 4: minimizzazione delle transizioni

Il principio guida: ogni transizione deve corrispondere a un handover reale o a un cambio di stato significativo. Se una transizione esiste solo "per flessibilità" ma non corrisponde a nulla di reale nel processo, va eliminata.

Procedimento:

Disegnare il workflow con solo le transizioni del "happy path" (flusso normale, nessuna eccezione)
Identificare i tre tipi di eccezione più frequenti (dati storici o stime)
Aggiungere transizioni solo per quelle tre eccezioni
Tutto il resto va in uno stato generico "Exception" che esce temporaneamente dal flusso

Un workflow ben progettato ha tipicamente 5-10 stati e 10-20 transizioni. Se supera questi numeri, è quasi certamente sovra-complesso.

Fase 5: validazione tramite simulazione

Prima di implementare, simulare il workflow con casi reali passati. Procedimento:

Raccogliere 10-15 work item completati recentemente
Per ciascuno, ricostruire il percorso che avrebbe seguito nel nuovo workflow
Identificare:
- Casi in cui non è chiaro quale stato usare (ambiguità semantica)
- Casi in cui serve una transizione che non esiste (incompletezza)
- Casi in cui esistono transizioni che non vengono mai usate (complessità superflua)

La simulazione fa emergere problemi che sulla carta non sono evidenti. È molto più economico iterare sul design prima dell'implementazione che dover rifare il workflow dopo che è in produzione.

Convergenze epistemologiche: oltre la metafora

Il framework del radiotelescopio organizzativo rappresenta una struttura epistemologica profonda che attraversa discipline apparentemente distanti.

Il lavoro della Sparavigna sugli autoencoder per l'anomaly detection dimostra che lo stesso principio – distinguere normale da anomalo attraverso la misurazione della somiglianza semantica – si applica fluidamente dalla spettroscopia dei minerali[^10] all'analisi dei suoni industriali alla diagnostica respiratoria. Questa generalità suggerisce che si tratta di un principio epistemologico fondamentale.

Parallelamente, i principi di workflow design proposti in questo saggio – sensibilità al segnale, distinzione segnale/rumore, calibrazione contestuale, risoluzione appropriata, interpretabilità – si applicano a contesti vastamente diversi: dal manifatturiero alla pubblica amministrazione, dallo sviluppo software alla gestione di campagne marketing. La struttura profonda del problema è la stessa: rendere visibile l'invisibile, distinguere normale da anomalo, trasformare dati ambigui in conoscenza azionabile.

Questa convergenza suggerisce l'esistenza di quella che potremmo chiamare una semiotica generale dei dispositivi di rivelazione: un insieme di principi che governa la progettazione di qualsiasi strumento – tecnico, organizzativo, concettuale – il cui scopo è rendere percepibile ciò che altrimenti resterebbe nascosto.

Sia l'autoencoder diagnostico che il workflow organizzativo sono strumenti di sensemaking: dispositivi che trasformano il caos in ordine percepibile, che permettono di nominare, misurare, discutere fenomeni precedentemente ineffabili. Entrambi operano costruendo una rappresentazione della "normalità" e rilevando deviazioni per contrasto. Entrambi valorizzano metriche semplici e interpretabili rispetto a modelli complessi e opachi. Entrambi riconoscono che lo sbilanciamento tra casi normali ed eccezionali è una risorsa.

[^10]: Amelia Carolina Sparavigna, Gemini (Modello Linguistico di Google), "Unveiling Hidden Bonds: A Deep Autoencoder Framework for the Autonomous Isolation and Archetype Generation of Crystallization Water in Mineral ATR-IR Spectroscopy", Zenodo, 2025, DOI: 10.5281/zenodo.17711908.

Conclusione: verso una pratica riflessiva del workflow design

I workflow mal progettati sono inefficaci e costringono le persone a conformarsi a rappresentazioni distorte del loro lavoro, a compilare campi che nessuno leggerà mai, a navigare labirinti di stati e transizioni che oscurano invece di rivelare. Generano frustrazione, alienazione, cinismo. "Il sistema non funziona" diventa la giustificazione per ogni workaround, ogni scorciatoia, ogni abbandono della disciplina di processo.

I workflow ben progettati sono invisibili. Il team li usa senza pensarci, perché rispecchiano naturalmente il loro modo di lavorare. Gli stati hanno nomi che collimano con il linguaggio che il team usa spontaneamente. Le transizioni corrispondono ai momenti reali di handover e cambio di responsabilità. Le metriche generate rispondono a domande che le persone si pongono effettivamente. Il workflow facilita il coordinamento e rende visibile il progresso.

Raggiungere questa invisibilità virtuosa richiede umiltà epistemologica: riconoscere che il workflow contribuisce a far esistere il processo. Richiede ascolto profondo: capire come le persone costruiscono significato. Richiede parsimonia: progettare per il flusso normale, accettare che le eccezioni esisteranno sempre. E richiede iterazione: nessun workflow nasce perfetto, deve evolvere attraverso cicli di feedback e aggiustamento.

Soprattutto, richiede un cambio di paradigma: smettere di pensare ai workflow come strumenti di controllo e iniziare a pensarli come strumenti di sensemaking collettivo. Significa progettare workflow che rendono le persone più intelligenti, più coordinate, più capaci di vedere cosa sta accadendo. Workflow che non limitano, controllano, riducono a esecutori di procedure predefinite.

Il framework del radiotelescopio organizzativo proposto in questo saggio integra insights da discipline diverse – systems thinking, semiotica organizzativa, workflow patterns, design centrato sull'umano, anomaly detection – in un insieme coerente di principi progettuali. È una lente attraverso cui guardare i problemi di workflow design con maggiore profondità.

Questo framework può essere utile a project manager, process designers, system architects che si trovano ogni giorno a dover progettare workflow. Può aiutarli a porre le domande giuste, a evitare gli anti-pattern più comuni, a creare workflow che generino significato invece di distruggerlo.

L'obiettivo è elevare il workflow design da "configurazione tecnica" a disciplina riflessiva: un'arte e una scienza che riconosce la propria responsabilità etica e epistemologica. Perché ogni workflow che progettiamo plasma il modo in cui decine o centinaia di persone comprenderanno e sperimenteranno il proprio lavoro.

Vedere l'invisibile è questione di costruire gli strumenti giusti, farsi le domande giuste, e avere l'umiltà di ascoltare ciò che quegli strumenti rivelano. Anche quando ciò che rivelano non è quello che ci aspettavamo.

Bibliografia

Amelia Carolina Sparavigna, Gemini (Modello Linguistico di Google), "Il suono del respiro e l'AI", Zenodo, 2025, DOI: 10.5281/zenodo.17806231.
Karl E. Weick, Sensemaking in Organizations, Sage Publications, 1995, ISBN 9780803971776.
Nick Russell, Wil M.P. van der Aalst, Arthur H.M. ter Hofstede, Workflow Patterns: The Definitive Guide, MIT Press, 2016, ISBN 9780262029827.
Donella H. Meadows, Diana Wright (ed.), Thinking in Systems: A Primer, Chelsea Green Publishing, 2008, ISBN 9781603580557.
Donald A. Norman, The Design of Everyday Things (Revised and Expanded Edition), Basic Books, 2013, ISBN 9780465050659.
Amelia Carolina Sparavigna, Gemini (Modello Linguistico di Google), "A Deep Learning Approach for Acoustic Anomaly Detection: The Encoder as a Semantic Feature Extractor for Industrial Machinery Sound", Zenodo, 2025, DOI: 10.5281/zenodo.17787427.
Amelia Carolina Sparavigna, Gemini (Modello Linguistico di Google), "Unveiling Hidden Bonds: A Deep Autoencoder Framework for the Autonomous Isolation and Archetype Generation of Crystallization Water in Mineral ATR-IR Spectroscopy", Zenodo, 2025, DOI: 10.5281/zenodo.17711908.
Amelia Carolina Sparavigna, Gemini (Modello Linguistico di Google), "Dalla Spettroscopia Raman alla Certificazione Strutturale: L'Autoencoder Denso e gli Pseudo-Spettri come Criteri di Idoneità del Biochar per la Mitigazione Climatica e Ambientale", Zenodo, 2025, DOI: 10.5281/zenodo.17560586.
Wil M.P. van der Aalst, Kees van Hee, Workflow Management: Models, Methods, and Systems, MIT Press, 2004, ISBN 9780262011891.

Pubblicato il 22 dicembre 2025