Workflow documentali CDE ISO 19650 guida operativa

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.

Schema di un workflow documentale CDE

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…