Workflow documentali nel CDE: come il file diventa il motore del processo informativo ISO 19650

Scopri i workflow documentali CDE ISO 19650 per gestire file, ruoli, revisioni e approvazioni con processi tracciati e ripetibili

Nel mondo AEC tradizionale, la gestione delle approvazioni di un documento di progetto segue tipicamente questo percorso: qualcuno prepara il file, lo allega a un’email, lo manda a chi deve verificarlo, aspetta una risposta, inoltra ad altri per commenti, raccoglie i feedback, carica una versione revisionata su un drive condiviso, manda un’altra email, aspetta l’approvazione formale.
È un processo fragile, non tracciato, facilmente dimenticato, dipendente dalla memoria individuale e totalmente inadatto a un progetto complesso con decine di discipline e centinaia di contenitori informativi in parallelo.

In un CDE conforme ai principi ISO 19650, i workflow documentali servono a superare questa logica: sono flussi operativi strutturati che guidano il contenitore informativo attraverso attività di verifica, revisione, approvazione, compilazione dati ed eventuale pubblicazione. Possono essere attivati dal caricamento di un file, da una nuova revisione, da un cambio di stato o da un’azione dell’utente, e sono composti da step sequenziali, responsabili, moduli associati, condizioni di avanzamento e notifiche.

Il punto centrale è che il file non è più solo un oggetto da archiviare, ma diventa l’innesco di un processo governato, tracciabile e ripetibile.

Se gli stati del contenitore indicano dove si trova l’informazione nel ciclo di vita — WIP, Shared, Published, Archived — il workflow documentale descrive come il contenitore avanza da uno stato all’altro, chi deve intervenire, quali controlli devono essere svolti e quali evidenze devono restare nell’audit trail.

In questo articolo entriamo nel dettaglio di cos’è un workflow documentale in un CDE, come si configura, quali pattern sono efficaci, e come le piattaforme CDE più mature trasformano il file in motore attivo del processo.

Il paradigma: dal file come oggetto al file come evento

Il salto concettuale che i workflow documentali introducono è radicale. Nel modello tradizionale, il file è un oggetto: esiste, viene letto, viene modificato, viene archiviato. Nel modello CDE ISO 19650, il file è un evento: il suo caricamento sottende un processo, il suo cambio di stato produce notifiche, la sua revisione attiva nuovi step.

Questo paradigma ha implicazioni operative profonde.

Il file attiva un workflow

Una piattaforma CDE evoluta trasforma ogni documento in un elemento attivo del processo. Il file caricato attiva un workflow — un flusso operativo strutturato che guida verifiche, controlli, approvazioni e compilazioni.

Gli utenti possono scegliere tra workflow predefiniti, configurati in base ai processi dell’organizzazione, e avviarli con un’azione semplice. Una volta lanciato, il workflow viene collegato direttamente al contenitore informativo e ne accompagna tutte le fasi operative, con visualizzazione chiara dello stato di avanzamento.

Ogni step ha un soggetto coinvolto

Per ogni step del workflow vengono identificati i soggetti coinvolti, che ricevono una notifica e possono accedere immediatamente al file, alle istruzioni operative e alle attività di loro competenza. Nessuna ambiguità su “chi fa cosa”: l’attività è assegnata in modo esplicito e tracciato.

Il processo è ripetibile e standardizzato

A differenza della gestione via email, un workflow definito nel CDE è ripetibile. La stessa procedura di verifica strutturale, per esempio, può essere applicata a tutti i contenitori informativi strutturali di tutti i progetti dell’organizzazione, garantendo coerenza di processo.

Anatomia di un workflow documentale CDE

Un workflow documentale in un CDE conforme ISO 19650 è composto da elementi strutturali ricorrenti. Comprenderli è il primo passo per progettare workflow efficaci.

Il trigger: cosa attiva il workflow

Il trigger è l’evento che fa partire il processo. Può essere:

caricamento di un nuovo contenitore informativo – il trigger più comune. Il file viene depositato in una cartella del CDE e questo attiva il workflow associato a quel tipo di contenuto;
caricamento di una nuova revisione – una variante specifica: il file esiste già, ma il caricamento di una nuova versione attiva un nuovo ciclo di verifica;
cambio manuale di stato – il Task Team dichiara il contenitore “pronto per Shared” e questo fa partire il processo di verifica interdisciplinare;
scadenza temporale – alcuni workflow sono programmati su base temporale, per esempio una verifica periodica mensile di determinati contenuti;
azione di un utente – richiesta esplicita di approvazione, di revisione, di chiusura fase.

Gli step: le fasi del processo

Ogni workflow è composto da step sequenziali (o paralleli, in workflow più sofisticati). Ogni step ha:

un responsabile – un utente o un ruolo che deve agire;
un’azione prevista – verifica, revisione, approvazione, compilazione modulo;
una condizione di avanzamento – cosa deve accadere perché si passi allo step successivo;
un tempo massimo (opzionale) – SLA oltre il quale scatta un’escalation;
moduli associati (opzionale) – checklist, schede di verifica, dati strutturati da raccogliere.

Le transizioni: come si passa da uno step all’altro

Le transizioni non sono automatiche: sono il risultato di azioni esplicite da parte dei responsabili. In un workflow CRA tipico:

approva: il contenitore avanza allo step successivo;
richiedi modifiche: il contenitore torna al Task Team con commenti;
rifiuta: il workflow si chiude con esito negativo;
delega: la responsabilità dello step viene trasferita a un altro utente.

Ogni transizione lascia una traccia permanente nell’audit trail: chi, quando, con quale esito, con quali commenti.

I destinatari: chi riceve le notifiche

Il workflow deve identificare chiaramente chi notificare a ogni transizione. Un CDE evoluto gestisce questo automaticamente, inviando notifiche via email. Le notifiche devono essere contestuali: non solo “c’è qualcosa da fare”, ma “devi approvare il modello strutturale del blocco B rev. P03, entro il 30 del mese”.

L’output: cosa succede quando il workflow termina

Al termine, il workflow produce diversi output:

cambio di stato del contenitore (da WIP a Shared, da Shared a Published, ecc.);
registrazione nell’audit trail del percorso completato;
generazione del contenitore storicizzato degli stati;
notifiche di completamento a tutti gli stakeholder rilevanti.

Il processo CRA: Check, Review, Approve

Il cuore operativo di quasi ogni workflow documentale CDE è il processo CRA (Check, Review, Approve). Si articola in tre fasi consecutive, ciascuna con responsabilità e scopo distinti.

Check — la verifica tecnica

Il Check è la prima fase. È una verifica tecnica condotta dal Task Team produttore o da un suo referente (tipicamente il BIM Coordinator o gruppo incaricato). Lo scopo è assicurare che il contenitore informativo soddisfi i requisiti tecnici di base prima di essere esposto ad altri soggetti.

Cosa si verifica nel Check:

conformità ai naming convention del Capitolato Informativo;
completezza dei metadati obbligatori;
presenza di tutti gli elementi previsti dal LOIN per la fase;
eventuali validazioni automatiche (es. check IDS sui modelli IFC)

Il check viene eseguito dal responsabile tecnico del Task Team produttore. Se l’esito è positivo il contenitore passa a Review;  se l’esito è negativo il contenitore torna in lavorazione al Task Team con indicazioni di correzione.

Review — la revisione interdisciplinare

La Review è la fase di revisione interdisciplinare e di coordinamento. Il contenitore — ora in stato Shared — viene esposto agli altri Task Team e al soggetto incaricato principale per verifica di coerenza con gli altri contenitori del progetto.

Cosa si verifica nella Review:

coerenza interdisciplinare (clash detection se modello);
allineamento con altri contenitori correlati (es. coerenza tra architettonico e strutturale);
corrispondenza ai requisiti del Capitolato Informativo
raccolta di commenti, issue (tipicamente via BCF) e richieste di modifica.

La review viene eseguita da altri Task Team, Lead Appointed Party, eventualmente il soggetto proponente.

Se l’esito è positivo il contenitore passa ad Approve; se l’esito è negativo il contenitore torna al Task Team (rework) con le issue aperte.

Approve — l’approvazione formale

L’Approve è la fase finale e contrattuale. Il contenitore viene formalmente approvato dall’Appointing Party (o dal Lead Appointed Party se così previsto dal Capitolato Informativo) e può transitare allo stato Published.

Cosa si verifica nell’Approve:

completezza del processo CRA precedente;
risoluzione di tutte le issue aperte;
conformità contrattuale al Capitolato Informativo;
idoneità allo scopo dichiarato.

L’approvazione finale viene eseguita da Appointing Party o Lead Appointed Party secondo CI.

Se l’esito è positivo il contenitore diventa Published; se l’esito è negativo il contenitore torna alla Review o al Check a seconda della gravità delle carenze.

Variazioni del processo CRA

Il CRA classico a tre fasi non è l’unico schema possibile. In base alla natura del contenitore e alle regole del Capitolato Informativo, possono esistere:

CRA semplificato: Check + Approve, senza Review interdisciplinare (tipico per documenti interni non soggetti a coordinamento);
CRA esteso: Check + Review tecnica + Review qualitativa + Approve (per contenitori critici come modelli strutturali o impiantistici);
CRA con audit esterno: CRA + verifica di terza parte (per contenitori soggetti a validazione normativa esterna).

Workflow predefiniti: la libreria di processi dell’organizzazione

Una delle caratteristiche più potenti di un CDE maturo è la possibilità di definire una libreria di workflow predefiniti, ossia template di processo preconfigurati secondo le procedure standard dell’organizzazione.

Perché servono i workflow predefiniti?

Senza workflow predefiniti, ogni progetto ridefinirebbe da zero le procedure di verifica e approvazione, con tre conseguenze negative:

incoerenza tra progetti: ogni commessa avrebbe il suo processo;
spreco di tempo: ogni volta si reinventa la ruota;
rischio di non conformità: senza standardizzazione, è facile saltare step critici.

I workflow predefiniti rispondono a queste esigenze offrendo template riutilizzabili, configurati secondo le procedure dell’organizzazione e attivabili con un’azione semplice.

Esempi di workflow predefiniti tipici

Una libreria di workflow predefiniti in un’organizzazione AEC matura può includere:

workflow di verifica di un modello IFC disciplinare (architettonico, strutturale, MEP);
workflow di approvazione di un disegno tecnico (pianta, sezione, dettaglio costruttivo);
workflow di revisione di un documento contrattuale (capitolato, relazione tecnica, cronoprogramma);
workflow di collaudo di un elemento costruttivo (strutturale, impiantistico, antincendio);
workflow di handover al Facility Management;
workflow di gestione di varianti in corso d’opera;
workflow di validazione dati di sostenibilità (EPD, LCA, report CSRD).

Configurabilità vs standardizzazione

Il CDE deve bilanciare due esigenze contrapposte:

standardizzazione: i workflow devono essere coerenti all’interno dell’organizzazione;
configurabilità: i workflow devono poter essere adattati alle specificità di ogni progetto.

Workflow basati sui ruoli: standardizzare senza rigidità

Il vero salto di qualità di un CDE maturo è la gestione dei workflow basati sui ruoli — non sulle persone.

Il problema dei workflow basati sugli utenti

Un workflow configurato su utenti specifici ha un problema strutturale: è rigido e fragile. Se Mario è il verificatore strutturale e va in ferie, il workflow si blocca. Se Luisa cambia ruolo, il workflow va riconfigurato. Se il progetto passa di mano, tutto va ripensato.

I workflow basati sui ruoli

La soluzione è associare ogni step a una funzione logica anziché a una persona. I ruoli tipici:

BIM Manager: supervisione complessiva della gestione informativa;
BIM Coordinator: coordinamento disciplinare;
CDE Manager: gestione operativa dell’ambiente;
Information Manager: governance informativa complessiva;
Verificatore strutturale, MEP, architettonico: responsabili di disciplina;
Appointing Party Representative: rappresentante del committente.

Al momento dell’avvio del workflow, la piattaforma richiede di associare ogni ruolo alla persona corretta all’interno del team del progetto. Il template resta quindi standardizzato, l’applicazione è flessibile e adattabile.

Vantaggi operativi

resilienza: se la persona assegnata è assente, si può cambiare l’associazione ruolo-persona senza toccare il workflow;
scalabilità: lo stesso template può essere applicato a decine di progetti con team diversi;
conformità UNI 11337-7: la norma italiana sui ruoli BIM diventa il framework semantico dei workflow
semplicità di gestione: la configurazione operativa si riduce a una mappatura ruoli-persone.

Moduli associati ai workflow: la raccolta dati strutturata

Un workflow documentale CDE evoluto non si limita a gestire approvazioni: raccoglie dati strutturati lungo il processo. Il meccanismo sono i moduli (checklist digitali, schede di verifica, controlli di qualità) associati agli step del workflow.

Cosa sono i moduli?

Un modulo è un insieme strutturato di campi – testuali, numerici, booleani, a scelta multipla, con allegati – che raccoglie informazioni specifiche su un contenitore informativo in un determinato momento del suo ciclo di vita.

Esempi concreti:

modulo di verifica strutturale: compilato dal verificatore nello step di Check, con campi su normative di riferimento, coefficienti di sicurezza, conformità ai carichi di progetto;
modulo di collaudo antincendio: compilato al termine della fase costruttiva, con campi sui REI, sui compartimenti, sulle vie di esodo;
modulo di handover FM: compilato nell’ultima fase del progetto, con dati tecnici per la gestione operativa (manuali, manutenzione, fornitori, garanzie).

Visibilità condizionata per fase

La caratteristica distintiva è la visibilità condizionata: i moduli possono essere visibili o modificabili solo in determinate fasi del workflow, così da garantire che ogni utente operi esclusivamente sulle informazioni di propria competenza.

Il modulo di verifica strutturale è:

invisibile durante la fase WIP;
compilabile solo dal verificatore strutturale durante la fase di Check;
visibile in sola lettura ai Task Team nella fase di Review;
congelato e consultabile dopo l’approvazione.

Questo consente di gestire verifiche, compilazioni e validazioni in modo guidato, controllato e progressivo, passaggio dopo passaggio.

Moduli come condizione di avanzamento

In workflow più sofisticati, la compilazione di un modulo diventa condizione di avanzamento; senza la compilazione del modulo di verifica, il workflow non può progredire. Questo trasforma i moduli da semplici form a veri e propri gate di processo, garantendo che i dati critici siano raccolti prima dell’avanzamento.

Dal singolo modulo al database di progetto

I dati raccolti nei moduli non restano isolati nel singolo contenitore. Un CDE evoluto li aggrega a livello di progetto, rendendoli consultabili in forma tabellare, filtrabili, ordinabili e interrogabili. Questo è il passaggio dalla gestione documentale alla gestione intelligente delle informazioni.

Gestione delle revisioni: workflow e nuove versioni

Un tema spesso sottovalutato è come un CDE evoluto gestisce la relazione tra workflow e revisioni del contenitore informativo. Cosa succede quando viene caricata una nuova versione di un file mentre è in corso un workflow sulla versione precedente?

Il principio: il workflow si interrompe, la storia resta

Quando viene caricata una revisione aggiornata di un contenitore informativo, l’eventuale workflow in corso sulla versione precedente viene interrotto nello stato in cui si trova e rimane consultabile come riferimento storico. Sulla nuova versione può quindi partire un nuovo processo, coerente con il contenuto aggiornato del file.

Questo comportamento ha un valore normativo e operativo importante:

non si perde la tracciabilità del processo interrotto;
non si crea confusione tra workflow della vecchia e della nuova versione;
l’audit trail mantiene evidenza completa di cosa è successo a ogni revisione.

Esempio concreto

Il BIM Coordinator carica la versione 02 di un modello strutturale. Si attiva il workflow di verifica, che procede fino allo step di Review. In Review vengono rilevate incongruenze con il modello architettonico e il Task Team decide di rivedere il modello.

Carica la versione 03. A questo punto:

il workflow sulla versione 02 resta “interrotto in Review”, con tutti i commenti e le issue aperte consultabili come storico;
sulla versione 03 parte un nuovo workflow di verifica dall’inizio;
l’audit trail registra sia il percorso parziale della versione 02 sia il percorso nuovo della versione 03;
nessun dato viene perso, nessun processo viene mischiato.

Implicazioni per la scelta della piattaforma

Non tutte le piattaforme gestiscono correttamente questo scenario. Alcune sovrascrivono il workflow, altre lo mantengono ma senza collegarlo alla nuova versione, altre ancora lo eliminano silenziosamente. Un CDE conforme ISO 19650 deve garantire il comportamento corretto: interruzione tracciata, non cancellazione, consultabilità permanente dello storico.

Pattern di workflow ricorrenti nel settore AEC

Nel corso degli anni si sono consolidati alcuni pattern di workflow ricorrenti che rappresentano best practice riconosciute. Ecco i più diffusi.

Pattern 1 — Workflow CRA classico a tre step

Il workflow standard ISO 19650-2 :

Check (Task Team produttore) → verifica tecnica interna;
Review (altri Task Team + Lead Appointed Party) → revisione interdisciplinare;
Approve (Appointing Party) → approvazione formale.

Questo workflow viene utilizzato nel caso dei contenitori informativi destinati al passaggio dallo stato Shared allo stato Published, con valore contrattuale.

Pattern 2 — Workflow di validazione automatica IDS

È specifico per modelli IFC:

upload del modello IFC
validazione automatica IDS (trigger automatico)
check manuale se validazione positiva
notifica di correzione se validazione negativa

È opportuno utilizzare questo workflow per tutti i contenitori di tipo modello IFC in progetti che adottano standard IDS (raccomandato per progetti BIM complessi).

Pattern 3 — Workflow di firma digitale con marca temporale

È per documenti contrattuali:

check del documento;
review del Lead Appointed Party;
firma digitale da parte dell’Appointing Party;
apposizione della marca temporale;
pubblicazione con suitability code contrattuale;

Questo workflow va utilizzato per i contenitori informativi con valore contrattuale giuridicamente rilevante.

Pattern 4 — Workflow di rework loop strutturato

È per la gestione delle iterazioni:

workflow principale (es. CRA)
se rifiutato → apertura automatica di un sub-workflow di correzione con:

assegnazione al Task Team produttore;
lista delle issue da risolvere;
SLA di risposta;
verifica che tutte le issue siano state chiuse prima del ritorno al workflow principale.

Questo workflow è per progetti complessi con alta probabilità di iterazioni (es. nuove costruzioni complesse, infrastrutture).

Pattern 5 — Workflow di approvazione parallela

Quando più soggetti devono approvare contemporaneamente senza dipendenza sequenziale:

upload del contenitore;
invio parallelo a verificatore A + verificatore B + verificatore C;
raccolta delle approvazioni con gestione dei conflitti;
approvazione finale solo se tutti hanno approvato.

Questo workflow è adatto ai contenitori che richiedono validazione multi-disciplinare (es. un documento di coordinamento, una variante complessa).

Pattern 6 — Workflow di handover al Facility Management

Al termine del progetto:

completeness check sui contenitori Published;
validazione dei dati tecnici per il FM;
compilazione moduli di handover (manuali, garanzie, manutenzione);
archiviazione definitiva.

Questo workflow è per la fase finale del progetto, il passaggio dalla costruzione alla gestione operativa.

Strumenti gratuiti per progettare i tuoi workflow

Per applicare concretamente quanto descritto, abbiamo preparato due strumenti gratuiti che puoi usare subito:

Scarica il pack di template di workflow in PDF: 6 template pronti all’uso basati sui pattern descritti (CRA classico, validazione IDS, firma digitale, rework loop, approvazione parallela, handover FM). Ogni template include step, ruoli, moduli e condizioni di avanzamento, con diagrammi e indicazioni di adattamento.

Prova il workflow builder interattivo: componi il tuo workflow personalizzato: aggiungi step, assegna ruoli, associa moduli, configura transizioni. Vedi in tempo reale il flusso generato e scarica la configurazione in formato leggibile.

Come un CDE evoluto implementa i workflow documentali

Non tutte le piattaforme CDE gestiscono i workflow allo stesso modo. Le implementazioni più mature si distinguono per alcune caratteristiche operative che fanno la differenza nell’uso quotidiano.

Configurazione visuale dei workflow

Una piattaforma evoluta permette di configurare i workflow visivamente con editor drag & drop, diagrammi di flusso modificabili, anteprima del processo — invece di richiedere la scrittura di regole complesse o di file di configurazione. Questo rende la configurazione accessibile ai BIM Manager e ai CDE Manager, senza richiedere competenze di sviluppo software.

Libreria di workflow riutilizzabili

Una piattaforma matura offre una libreria di workflow preconfigurati e permette all’organizzazione di crearne di propri, salvarli come template e riutilizzarli su più progetti.

Integrazione con moduli strutturati

Il workflow deve poter attivare moduli negli step appropriati, con logica condizionata (visibili, compilabili, obbligatori). La piattaforma deve gestire la compilazione dei moduli come parte integrante del processo, non come funzione separata.

Audit trail completo e non modificabile

Ogni workflow genera un audit trail completo: chi ha agito, quando, con quale esito, con quali commenti. Questo log deve essere immutabile — nemmeno l’amministratore deve poterlo alterare — e esportabile per audit esterni, contenziosi, verifiche di terza parte.

Integrazione con l’ecosistema di app

In ecosistemi maturi, il workflow non è un silo: si integra con le app specialistiche della piattaforma. Un workflow di verifica di un modello IFC può attivare clash detection, issue tracking BCF, confronto tra revisioni, validazione IDS. Questo trasforma il workflow in un vero orchestratore di processo.

Il CDE come ecosistema: i workflow nelle piattaforme reale

Nell’ecosistema usBIM di ACCA, la gestione dei workflow documentali è il cuore operativo di usBIM.platform, il CDE conforme ISO 19650. Ogni contenitore informativo caricato può attivare un workflow, con visualizzazione chiara dello stato di avanzamento, identificazione dei soggetti coinvolti per ogni step, notifiche automatiche, moduli associati con visibilità condizionata per fase, gestione coerente delle revisioni con storicizzazione dei workflow interrotti.

Attorno alla piattaforma, le app specialistiche si integrano come azioni eseguibili all’interno degli step del workflow:

usBIM.clash per la clash detection attivata nello step di Review;
usBIM.bcf per la gestione delle issue aperte durante la Review con lo standard BCF;
usBIM.compare per il confronto automatico tra revisioni quando parte un nuovo workflow;
usBIM.dataquality per la validazione automatica IDS dei modelli IFC conforme ai requisiti del Capitolato Informativo fondamentale per workflow di tipo “Pattern 2 (validazione automatica IDS)”
usBIM.writer, usBIM.editor per l’editing di documenti nelle fasi di WIP e di rework
usBIM.facility per i workflow di handover al Facility Management.

La filosofia è quella di rendere il workflow non solo un processo di approvazione, ma un orchestratore di tutte le attività tecniche necessarie alla produzione e validazione del contenitore informativo. Un workflow di verifica strutturale non è solo “qualcuno approva”: è una sequenza di azioni concrete (clash, validazione IDS, issue tracking, confronto revisioni, verifica LOIN, compilazione modulo strutturale) orchestrate dalla piattaforma.

Errori comuni nell’implementazione dei workflow documentali

L’esperienza mostra che alcuni errori si ripetono con frequenza preoccupante. Conoscerli aiuta a evitarli.

replicare i processi email nel CDE: molte organizzazioni, al primo approccio con il CDE, configurano workflow che replicano passo per passo i processi via email esistenti. Il risultato è un workflow inutilmente complesso, pieno di step ridondanti, che non sfrutta le capacità di automazione della piattaforma. La corretta strategia è ripensare il processo sfruttando il paradigma CDE, non trasporlo acriticamente;
workflow troppo rigidi: workflow con troppi step, troppe condizioni obbligatorie, troppi passaggi formali tendono a generare frustrazione degli utenti e a incentivare il bypass del sistema (es. gli utenti si mandano file via email per “accelerare”). Un workflow efficace è il più semplice possibile ma non più semplice del necessario; 
non definire i tempi: workflow che non rispettano tempi di risposta e criteri di accettazione definiti nell’EIR e nel pGI tendono a bloccarsi perché “non c’è urgenza”;
assegnazione a utenti singoli anziché ruoli: come già detto assegnare step a utenti specifici anziché a ruoli produce workflow fragili. È uno degli errori più comuni nelle prime implementazioni di un CDE.
moduli troppo lunghi o non obbligatori: un modulo di 50 campi viene compilato in modo superficiale. Un modulo opzionale non viene compilato affatto. La best practice è pochi campi, chiaramente obbligatori, con validazione automatica dove possibile.
mancata formazione degli utenti: il workflow più sofisticato è inutile se gli utenti non sanno usarlo. L’implementazione di workflow CDE richiede formazione strutturata dei team, non solo documentazione. Il ROI della formazione è altissimo nei primi 3-6 mesi di adozione;
nessuna revisione periodica dei workflow: i workflow devono essere revisionati periodicamente in base ai dati di utilizzo: dove si bloccano, quanto durano, quali step generano più rework. Senza questa iterazione, i workflow diventano obsoleti e inefficaci.

Domande frequenti (FAQ)

Cos’è un workflow documentale in un CDE?

Un workflow documentale in un CDE conforme ISO 19650 è un flusso operativo strutturato attivato dal caricamento di un contenitore informativo, che guida attività di verifica, revisione, approvazione e compilazione dati. È composto da step sequenziali con responsabili, moduli, condizioni di avanzamento e notifiche automatiche, e realizza operativamente il processo CRA (Check, Review, Approve) normato dalla ISO 19650-2.

Cos’è il processo CRA (Check, Review, Approve)?

Il CRA è il processo di verifica, revisione e approvazione per il passaggio dei contenitori informativi da WIP a Shared a Published:

check: verifica tecnica interna del Task Team;
review: revisione interdisciplinare;
approve: approvazione formale dell’Appointing Party. Ogni fase ha responsabili, condizioni di avanzamento e può produrre rework verso le fasi precedenti.

Come si attiva un workflow in un CDE?

Un workflow in un CDE conforme può essere attivato da: caricamento di un nuovo contenitore informativo, caricamento di una nuova revisione, cambio manuale di stato, scadenza temporale, azione esplicita di un utente.

Qual è la differenza tra workflow basati sugli utenti e workflow basati sui ruoli?

Un workflow basato sugli utenti assegna gli step a persone specifiche (es. “Mario deve approvare”). È rigido: se Mario è assente il workflow si blocca. Un workflow basato sui ruoli assegna gli step a funzioni logiche (es. “il verificatore strutturale deve approvare”). Al momento dell’avvio, la piattaforma chiede di associare il ruolo alla persona corretta. È più resiliente, scalabile e riutilizzabile tra progetti.

Cosa sono i moduli associati ai workflow?

I moduli sono insiemi strutturati di campi (checklist, schede di verifica, controlli) associati agli step di un workflow. Raccolgono dati strutturati lungo il processo. In un CDE evoluto hanno visibilità condizionata per fase: sono visibili o compilabili solo nelle fasi di competenza di ciascun utente. I moduli possono essere obbligatori per l’avanzamento del workflow, trasformandosi in gate di processo.

Cosa succede al workflow quando si carica una nuova versione?

Quando viene caricata una nuova versione di un contenitore informativo, l’eventuale workflow in corso sulla versione precedente viene interrotto nello stato in cui si trova e rimane consultabile come riferimento storico. Sulla nuova versione parte un nuovo workflow coerente con il contenuto aggiornato. L’audit trail conserva entrambi i percorsi, garantendo piena tracciabilità.

Si possono avere workflow predefiniti riutilizzabili?

Sì. Una piattaforma CDE evoluta offre una libreria di workflow predefiniti — template preconfigurati secondo le procedure dell’organizzazione — attivabili con un’azione semplice. I template sono tipicamente parametrici: i ruoli e alcune variabili (tempi massimi, moduli opzionali) vengono personalizzate al momento dell’avvio, preservando la standardizzazione del processo e la flessibilità applicativa.

Quali sono i pattern di workflow più diffusi nel settore AEC?

I pattern ricorrenti includono: CRA classico a tre step (Check, Review, Approve), workflow di validazione automatica IDS per modelli IFC, workflow di firma digitale per documenti contrattuali, workflow di rework loop per la gestione delle iterazioni, workflow di approvazione parallela per contenuti multi-disciplinari, workflow di handover al Facility Management per la fase finale del progetto.

Come si integrano i workflow con le app specialistiche del CDE?

In un ecosistema maturo, gli step del workflow possono attivare app specialistiche: clash detection, validazione IDS, issue tracking BCF, confronto tra revisioni, editing documentale, firma digitale. Il workflow diventa così un orchestratore di processo che coordina non solo approvazioni ma anche attività tecniche. È il livello più avanzato di integrazione.

Cosa è l’audit trail di un workflow?

L’audit trail è la registrazione permanente e non modificabile di tutte le azioni svolte durante un workflow: chi ha agito, quando, con quale esito, con quali commenti. È il fondamento della tracciabilità richiesta dalla ISO 19650 ed è indispensabile per audit di conformità, contenziosi contrattuali e verifiche di terza parte. Un CDE conforme garantisce che l’audit trail sia immutabile e esportabile.

È possibile modificare un workflow già avviato?

Dipende dalla piattaforma e dalla fase. In generale, un workflow in corso non dovrebbe essere modificato strutturalmente perché questo comprometterebbe la tracciabilità. Alcune piattaforme permettono piccole modifiche (es. sostituire la persona associata a un ruolo) mantenendo la traccia. Modifiche strutturali richiedono tipicamente la chiusura del workflow e l’avvio di uno nuovo.

Come si valuta l’efficacia di un workflow?

L’efficacia di un workflow si valuta analizzando metriche operative: tempo medio di completamento, numero di rework, percentuale di SLA rispettati, punti di blocco ricorrenti, carico di lavoro per ruolo. Un CDE maturo fornisce queste metriche attraverso la dashboard di progetto, permettendo di iterare sui workflow in base a dati oggettivi.

Glossario essenziale

Approve – fase finale del processo CRA: approvazione formale del contenitore da parte dell’Appointing Party.
Audit trail – registrazione permanente e non modificabile delle azioni svolte durante un workflow.
BCF – BIM Collaboration Format. Standard openBIM per la gestione delle issue.
Check – Prima fase del processo CRA: verifica tecnica interna del Task Team produttore.
CRA – Check, Review, Approve. Processo di verifica, revisione e approvazione normato dalla ISO 19650-2.
Gate di processo – Condizione obbligatoria (es. compilazione modulo) che deve essere soddisfatta per l’avanzamento del workflow.
Modulo – Insieme strutturato di campi associato a uno step del workflow per la raccolta di dati strutturati.
Review – Seconda fase del processo CRA: revisione interdisciplinare del contenitore.
Rework loop – Percorso di ritorno del contenitore a fasi precedenti dopo il rilievo di non conformità.
SLA – Service Level Agreement. Tempo massimo definito per il completamento di uno step.
Step – Fase elementare di un workflow, con responsabile, azione prevista e condizione di avanzamento.
Template di workflow – Workflow preconfigurato, riutilizzabile e parametrico, salvato nella libreria dell’organizzazione.
Transizione – Passaggio da uno step al successivo in un workflow, determinato da un’azione esplicita.
Trigger – Evento che attiva automaticamente un workflow (upload file, revisione, scadenza, ecc.).
Workflow predefinito – Template di workflow preconfigurato secondo le procedure dell’organizzazione.

 

 

Fonte: Read More