Stati del contenitore informativo ISO 19650: guida completa a WIP, Shared, Published, Archived

Scopri gli stati del contenitore informativo ISO 19650, da WIP a Shared, Published e Archived, con guida PDF e simulatore interattivo

Chi lavora con un CDE conforme ISO 19650 si scontra prima o poi con una domanda apparentemente banale: “in che stato è questo file?”. La risposta non è tecnica. È normativa, contrattuale, operativa.

Gli stati del contenitore informativo sono le quattro fasi del ciclo di vita di un’informazione di progetto definite dalla norma ISO 19650: Work in Progress (WIP), Shared, Published, Archived. Ogni stato determina chi può vedere, modificare e utilizzare il contenitore informativo, con regole di transizione tracciate e autorizzate.

Capire come funzionano questi stati è il passaggio chiave per trasformare un CDE da semplice archivio a strumento di governance. In questo articolo spieghiamo in dettaglio cosa significa ogni stato, come avvengono le transizioni e come un CDE evoluto gestisce operativamente questi passaggi.

Se non hai letto il nostro articolo introduttivo al CDE conforme ISO 19650, ti consigliamo di partire da lì: qui entriamo nel dettaglio operativo di uno dei suoi aspetti più tecnici.

Il ciclo di vita del contenitore informativo: quattro stati, un processo

La ISO 19650-1 (§12) definisce quattro stati principali che ogni contenitore informativo attraversa durante il progetto. Non si tratta di una sequenza rigida: un contenitore può tornare a stati precedenti se vengono riscontrate carenze, e non tutti i contenitori arrivano fino all’archiviazione nello stesso momento.

Gli stati sono:

Work in Progress (WIP) – in lavorazione interna al team che produce il contenuto;
Shared – condiviso con altri team o discipline per coordinamento;
Published (o Published for use) – pubblicato e approvato per l’uso contrattuale;
Archived – archiviato come riferimento storico.

Ogni stato è caratterizzato da quattro elementi: chi ha accesso al contenitore, cosa può fare, come avviene la transizione allo stato successivo, perché il contenitore si trova in quella fase.

Lo schema generale del ciclo

La transizione tra stati avviene attraverso il processo CRA (Check, Review, Approve) – verifica, revisione e approvazione – normato dalla ISO 19650-2. Ogni transizione lascia una traccia nell’audit trail del CDE.

Stato 1 — Work in Progress (WIP): l’area di lavoro del team

Il Work in Progress è lo stato iniziale di ogni contenitore informativo. È lo spazio in cui il team che produce il contenuto – tipicamente un Task Team nella terminologia ISO 19650 – lavora liberamente senza esporre il materiale ad altri.

Chi accede al WIP

Solo i membri del Task Team che sta producendo il contenitore informativo. Altre discipline, il committente, il verificatore, gli altri team non hanno visibilità sul contenuto in WIP.

Cosa si può fare

Nel WIP il team mantiene il pieno controllo operativo sul contenitore informativo, con la libertà di:

creare, modificare, cancellare contenuti liberamente;
testare soluzioni, iterare, fare errori;
collaborare internamente al team senza formalità;
associare metadati preliminari ma non ancora definitivi.

Caratteristiche operative

Il WIP è l’unico stato in cui il contenitore informativo può essere cancellato (prima della condivisione formale). Una volta che il contenitore passa a Shared, ogni modifica produce una nuova revisione tracciata.

Suitability code tipico

Il codice di idoneità associato è generalmente S0 (Initial status) o equivalente, che indica che il contenitore non è ancora stato sottoposto a verifica interna.

La transizione verso Shared

Quando il Task Team ritiene che il contenitore sia pronto per essere condiviso con altre discipline, avvia il processo di check interno (auto-verifica tecnica). Solo dopo il check positivo il contenitore può transitare a Shared. Questa transizione è di norma autorizzata dal Task Team Manager o dal BIM Coordinator.

Stato 2 — Shared: la condivisione per coordinamento

Lo stato Shared segna il passaggio dall’uso interno all’uso interdisciplinare. Il contenitore è ora visibile agli altri team di progetto e al Lead Appointed Party (il soggetto coordinatore dell’intera commessa informativa).

Chi accede al contenitore Shared

Quando un contenitore passa allo stato Shared, la sua visibilità si estende a:

il Task Team che lo ha prodotto (con diritti di modifica limitati);
gli altri Task Team del progetto (in lettura, per coordinamento);
il Lead Appointed Party (per revisione e verifica);
il committente (Appointing Party) a seconda delle regole del Capitolato Informativo.

Cosa si può fare

Nello stato Shared il contenitore informativo diventa uno strumento di coordinamento tra discipline, quindi può essere utilizzato per:

consultare il contenitore per attività di coordinamento;
annotare, commentare, aprire issue (tipicamente via BCF);
verificare coerenza, clash detection, coordinamento disciplinare;
richiedere modifiche al Task Team produttore tramite il processo formale.

Nello stato Shared il contenuto non può essere usato per la costruzione o per decisioni contrattuali: è materiale di coordinamento, non materiale pubblicato.

Suitability code tipici

Lo stato Shared prevede diversi suitability code a seconda dello scopo della condivisione:

S1 – Suitable for Coordination (idoneo per coordinamento);
S2 – Suitable for Information (idoneo per informazione);
S3 – Suitable for Internal Review and Comment (idoneo per revisione interna e commenti);
S4 – Suitable for Stage Approval (idoneo per approvazione di fase);
S6/S7 – Suitable for PIM Authorization / AIM Authorization.

Ogni code ha implicazioni contrattuali e operative diverse, e deve essere coerente con la fase del progetto.

La transizione verso Published

Se il contenitore supera il processo di verifica e approvazione (Check, Review, Approve) condotto dal Lead Appointed Party e/o dall’Appointing Party, transita a Published. Se invece vengono riscontrate non conformità, il contenitore torna a WIP con le indicazioni di correzione (rework loop).

Stato 3 — Published: il contenitore approvato per l’uso

Lo stato Published segna l’approvazione ufficiale del contenitore informativo da parte dell’Appointing Party (il committente). Da questo momento il contenitore ha valore contrattuale e può essere utilizzato per le decisioni operative del progetto — progettazione esecutiva, costruzione, collaudi, gestione.

Chi accede al Published

L’accesso in lettura è tipicamente esteso a tutti i soggetti coinvolti nel progetto, secondo le regole del Capitolato Informativo. I diritti di modifica sono invece estremamente limitati: un contenitore Published non può essere modificato direttamente. Qualsiasi cambiamento richiede l’apertura di una nuova revisione, che ricomincia il ciclo dal WIP.

Cosa si può fare

Una volta raggiunto lo stato Published, il contenitore informativo assume un ruolo diverso rispetto alle fasi precedenti e si può:

utilizzare il contenitore per attività contrattuali, costruzione, gestione;
consultare in forma definitiva e autorevole;
citare in documenti contrattuali e comunicazioni formali;
NON modificare direttamente: serve aprire una nuova revisione.

Suitability code tipici

A1-AN – Authorized for [scope] (autorizzato per uno scopo specifico);
B1-BN – Partially signed-off (parzialmente approvato, con riserve);
CR – As Constructed Record (registrazione del costruito);
PR – Published Record (pubblicazione finale di archivio).

Il code specifica l’ambito di utilizzo autorizzato: ad esempio A1 può significare “Authorized for Construction”, CR “As-built record”, ecc.

Revision codes

Parallelamente ai suitability code, le revisioni del contenitore sono tracciate con revision codes:

P01, P02, P03… – revisioni in fase di progettazione (Pre-construction)
C01, C02, C03… – revisioni in fase di costruzione (Construction)

La combinazione di suitability code e revision code identifica univocamente lo stato semantico del contenitore: “S2-P03” significa “idoneo per informazione, terza revisione pre-costruzione”.

La transizione verso Archived

Al termine dell’uso operativo del contenitore informativo – tipicamente a fine fase di progetto o a fine commessa – il contenitore viene archiviato. Questo non significa rimuoverlo: significa congelarlo in uno stato di sola lettura permanente.

Stato 4 — Archived: il riferimento storico immutabile

Lo stato Archived conserva il contenitore informativo come riferimento storico. È lo stato finale del ciclo di vita, ma non implica obsolescenza: al contrario, rappresenta la memoria autorevole del progetto.

Chi accede all’Archived

L’accesso è tipicamente garantito in sola lettura a tutti i soggetti che avevano diritto di visibilità sul contenitore Published. L’archiviazione non elimina i diritti di consultazione, ma blocca qualsiasi modifica.

Cosa si può fare

Nello stato Archived il contenitore informativo perde ogni funzione operativa attiva e viene conservato come evidenza stabile del percorso informativo del progetto in cui si può:

consultare il contenitore per riferimento storico, audit, contenziosi;
esportare per trasferimenti a sistemi terzi (es. CAFM in fase di Facility Management);
NON modificare, NON cancellare: il contenitore è congelato.

Perché l’archiviazione è critica

Dal punto di vista normativo e contrattuale, lo stato Archived è l’evidenza oggettiva di ciò che è stato prodotto, approvato e utilizzato durante il progetto. È la base documentale per:

Audit di conformità (ISO 9001, ISO 19650-5, sicurezza)
Contenziosi contrattuali tra committente e parti incaricate
Verifiche di terza parte (collaudatori, enti di controllo)
Trasferimento informativo al Facility Management (handover)
Valutazione ambientale post-costruzione (LCA, EPD verification).

Come un CDE evoluto gestisce operativamente gli stati

La norma descrive gli stati, ma è la piattaforma CDE a renderli operativi. I comportamenti che differenziano un CDE maturo da una soluzione di cloud storage riguardano proprio la gestione degli stati.

Visualizzazione chiara dello stato

Ogni contenitore informativo deve esibire in modo immediato e non ambiguo il proprio stato attuale, con etichette testuali. Un CDE evoluto offre viste filtrabili per stato, così che il CDE Manager possa monitorare in tempo reale la distribuzione dei contenitori lungo il ciclo.

Transizioni regolate da workflow

Il passaggio tra stati non avviene per azione arbitraria: è il risultato di un workflow strutturato che il CDE attiva automaticamente. Il workflow identifica i soggetti coinvolti (per ruolo o per utente), li notifica, raccoglie le approvazioni e registra la transizione nell’audit trail.

Una piattaforma CDE evoluta permette di configurare workflow diversi per diversi tipi di contenitori: un modello IFC strutturale seguirà un workflow diverso da un documento contrattuale, e un CDE maturo consente di definire questi flussi in modo granulare.

Permessi condizionati allo stato

L’accesso e le azioni consentite dipendono dallo stato: un utente può avere diritti di modifica sul contenitore in WIP ma solo di lettura quando passa a Shared. Il CDE deve gestire questa matrice di permessi dinamica in modo automatico, senza richiedere interventi manuali a ogni transizione.

Versionamento coerente con gli stati

Ogni transizione di stato può generare una nuova versione del contenitore. In particolare, il ritorno da Shared a WIP dopo una revisione genera una nuova versione del contenuto mantenendo visibile la precedente come riferimento storico. Quando viene caricata una revisione, il workflow in corso sulla versione precedente viene interrotto nello stato in cui si trova e resta consultabile come archivio del processo. Sulla nuova versione può partire un nuovo processo coerente con il contenuto aggiornato.

Moduli associati agli stati

Un CDE evoluto permette di associare moduli strutturati (checklist, schede di verifica, validazioni tecniche) agli stati del contenitore. Un modulo può essere compilabile solo quando il contenitore è in Shared, oppure diventare obbligatorio prima di autorizzare il passaggio a Published. Questo consente di condizionare le transizioni alla raccolta di dati strutturati, non solo a un’approvazione generica.

Suitability codes: la guida di riferimento

I suitability codes sono il complemento semantico degli stati. Mentre lo stato dice “dove” si trova il contenitore nel ciclo, il suitability code dice “per cosa” è idoneo in quel momento.

Tabella completa dei suitability codes ISO 19650

Nota sulla variabilità

I suitability codes qui elencati sono quelli raccomandati dagli standard UK BIM Framework e ampiamente adottati come riferimento internazionale. La ISO 19650 non impone i codici esatti: ogni organizzazione o progetto può adottare una propria convenzione, purché definita nel Capitolato Informativo.

Revision codes: la tracciabilità delle versioni

Accanto ai suitability codes, i revision codes tracciano la versione del contenitore. La convenzione più diffusa:

P01, P02, P03… per revisioni in fase di progettazione (pre-construction);
C01, C02, C03… per revisioni in fase di costruzione (construction);
alcune organizzazioni aggiungono D01 per le revisioni dopo l’handover al committente (deployed).

La combinazione “Suitability – Revision” (es. “S2 – P03”, “A1 – C02”) identifica univocamente lo stato semantico del contenitore in un momento specifico.

Come vengono gestiti nel CDE

Un CDE evoluto genera automaticamente i revision code incrementandoli ad ogni nuova versione, evitando errori di denominazione manuale. Il sistema deve anche impedire la “riutilizzazione” di codici già usati (es. saltare da P01 a P03 senza passare per P02), per mantenere coerenza e tracciabilità.

Errori comuni nella gestione degli stati

Dopo anni di implementazione del CDE nei progetti AEC, emergono alcuni errori ricorrenti che è bene conoscere per evitarli:

Confondere Shared con Published: Shared non è pubblicato. Non ha valore contrattuale, non può essere usato per decisioni operative, non giustifica la costruzione. Usare un contenitore Shared come se fosse Published è una delle cause più frequenti di contenziosi.
Saltare la fase Shared: alcuni team caricano direttamente contenitori in stato Published senza passare per Shared. Questo elude il processo di coordinamento interdisciplinare e può portare a clash non rilevati, incongruenze tra discipline, mancato allineamento ai requisiti informativi.
Trattare l’archiviazione come cancellazione: il contenitore archiviato non va cancellato: va congelato in sola lettura. L’eliminazione definitiva può violare obblighi di conservazione contrattuali e normativi, e compromettere la capacità di difesa in caso di contenzioso.
Modificare direttamente il Published: un contenitore Published non può essere modificato; ogni cambiamento richiede una nuova revisione che ripercorre il ciclo. Modificare “silenziosamente” un contenitore Published (spesso per “piccole correzioni”) azzera la tracciabilità e mina la validità dell’intero processo informativo.
Permessi non coerenti con lo stato: consentire a un Task Team di modificare liberamente un contenitore Shared, o peggio Published, di un’altra disciplina è un errore grave di configurazione del CDE. I permessi devono essere condizionati allo stato e segregati per ruolo.

I 10 requisiti di una piattaforma CDE conforme ISO 19650

La gestione corretta degli stati è solo uno dei dieci requisiti fondamentali di una piattaforma CDE conforme. Se stai valutando una piattaforma o vuoi verificare la conformità di quella che stai usando, abbiamo preparato due strumenti gratuiti:

Scarica la guida operativa agli stati in PDF – Un documento di riferimento stampabile con tabella completa dei suitability codes, matrice dei permessi per stato, flowchart delle transizioni e casi d’uso.

Prova il simulatore interattivo degli stati — Visualizza il ciclo di vita del contenitore informativo, clicca su ogni stato per scoprire permessi, attori, codici e transizioni. Ideale per formazione del team e onboarding dei nuovi utenti.

Il CDE come ecosistema: la gestione degli stati nelle piattaforme reali

Le piattaforme CDE evolute implementano la gestione degli stati con modalità che vanno oltre la mera etichettatura. Nell’ecosistema usBIM di ACCA, ad esempio, usBIM.platform — il CDE conforme ISO 19650 — gestisce gli stati del contenitore informativo come elementi attivi del workflow, con transizioni regolate, visualizzazione chiara dello stato di avanzamento e tracciabilità completa.

Attorno a usBIM.platform l’ecosistema offre strumenti specifici per le attività che si svolgono nei diversi stati:

nel WIP il team collabora con app come usBIM.editor, usBIM.writer per la produzione e la modifica dei contenuti;
nello Shared entrano in gioco usBIM.clash per il coordinamento, usBIM.bcf  per l’issue tracking interdisciplinare, usBIM.compare per il confronto tra revisioni, usBIM.federation per la federazione dei modelli disciplinari;
per la qualità informativa che condiziona il passaggio allo stato Shared e Published interviene usBIM.dataquality con la validazione IDS secondo i requisiti del Capitolato Informativo;
nel Published e nell’Archived la piattaforma garantisce accesso in sola lettura, audit trail completo, versionamento coerente e export verso sistemi a valle (es. usBIM.maint per il Facility Management in fase di handover).

Il valore risiede nel fatto che gli stati non sono solo gestiti dalla piattaforma, ma orchestrati con le app specialistiche: ogni stato abilita automaticamente gli strumenti e i workflow appropriati, riducendo il rischio di errori operativi.

Domande frequenti (FAQ)

Cosa sono gli stati del contenitore informativo?

Gli stati del contenitore informativo sono le quattro fasi del ciclo di vita di un’informazione di progetto definite dalla ISO 19650: Work in Progress (WIP), Shared, Published, Archived. Ogni stato determina chi può vedere, modificare e utilizzare il contenitore, con regole di transizione tracciate e autorizzate.

Quali sono i quattro stati ISO 19650?

I quattro stati sono: Work in Progress (WIP), in lavorazione interna al team; Shared, condiviso per coordinamento interdisciplinare; Published, approvato per l’uso contrattuale; Archived, archiviato come riferimento storico immutabile.

Cosa significa WIP nel CDE?

WIP (Work in Progress) è lo stato iniziale del contenitore informativo, in cui solo il team produttore (Task Team) ha accesso. In questo stato si può modificare e cancellare liberamente il contenuto. È l’unico stato in cui il contenitore può essere eliminato prima della condivisione formale.

Qual è la differenza tra Shared e Published?

Il contenitore Shared è condiviso tra discipline per coordinamento ma non ha valore contrattuale. Il contenitore Published è approvato formalmente dal committente (Appointing Party) e può essere usato per decisioni operative, costruzione, contrattualizzazione. Shared non equivale a Published.

Cos’è il processo CRA?

Il CRA (Check, Review, Approve) è il processo di verifica, revisione e approvazione che regola le transizioni tra gli stati del contenitore informativo. È normato dalla ISO 19650-2 ed è il meccanismo attraverso il quale un contenitore passa da Shared a Published.

Un contenitore Published può essere modificato?

No, un contenitore informativo in stato Published non può essere modificato direttamente. Ogni cambiamento richiede l’apertura di una nuova revisione che ricomincia il ciclo dallo stato WIP. Questo garantisce la tracciabilità e l’immutabilità contrattuale delle versioni pubblicate.

Cosa succede quando si carica una nuova versione di un file nel CDE?

Quando viene caricata una nuova versione di un contenitore informativo, la versione precedente viene conservata nello storico. Se era in corso un workflow sulla versione precedente, questo viene tipicamente interrotto nello stato in cui si trova e resta consultabile come riferimento storico, mentre sulla nuova versione può partire un nuovo processo.

L’archiviazione nel CDE è la stessa cosa della cancellazione?

No, archiviare un contenitore informativo significa congelarlo in sola lettura permanente. Non va cancellato: il contenitore archiviato rappresenta l’evidenza oggettiva di ciò che è stato prodotto e approvato durante il progetto, ed è fondamentale per audit, contenziosi, trasferimenti al Facility Management.

Chi autorizza le transizioni tra stati?

Le autorizzazioni dipendono dalla transizione: il passaggio WIP → Shared è tipicamente autorizzato dal Task Team Manager o dal BIM Coordinator. Il passaggio Shared → Published è autorizzato dal Lead Appointed Party e/o dall’Appointing Party (committente). Il passaggio Published → Archived avviene secondo le regole del Capitolato Informativo, solitamente a fine fase o fine commessa.

Cosa sono i Task Team, Lead Appointed Party e Appointing Party?

Sono i tre livelli di ruoli informativi definiti dalla ISO 19650-1. L’Appointing Party è il committente che richiede le informazioni. Il Lead Appointed Party è il soggetto principale incaricato (es. general contractor) che coordina le altre parti. I Task Team sono i team di lavoro specifici che producono i contenitori informativi (es. team strutturale, team MEP).

Come si gestisce il rework di un contenitore informativo?

Se durante la verifica di un contenitore Shared vengono riscontrate non conformità, il contenitore torna allo stato WIP con le indicazioni di correzione. Il Task Team apporta le modifiche e rimette il contenitore in Shared come nuova revisione. Il ciclo CRA riparte. Tutto il percorso — incluso il workflow interrotto — resta consultabile nell’audit trail.

Come si visualizzano gli stati nel CDE?

Una piattaforma CDE evoluta deve mostrare lo stato di ogni contenitore informativo in modo immediato e non ambiguo, tipicamente con codici colore, etichette testuali e suitability code visibili direttamente nella lista dei file. Deve inoltre offrire viste filtrabili per stato e una dashboard di progetto con la distribuzione aggregata degli stati.

Cosa succede se un contenitore non raggiunge mai lo stato Published?

Non tutti i contenitori arrivano a Published. Alcuni possono restare in WIP o essere eliminati prima della condivisione. Altri possono essere condivisi ma poi superati da versioni successive che vengono pubblicate al loro posto. L’importante è che l’audit trail registri il percorso effettivamente seguito da ciascun contenitore.

Glossario essenziale

Appointing Party – Committente, soggetto che richiede le informazioni di progetto.

Archived – Stato finale del contenitore informativo: archiviato in sola lettura come riferimento storico.

CDE – Common Data Environment. Ambiente di Condivisione Dati conforme ISO 19650.

Contenitore informativo – Unità base di informazione nel CDE, con metadati strutturati.

CRA – Check, Review, Approve. Processo di verifica, revisione e approvazione.

Lead Appointed Party – Parte incaricata principale, coordinatore della commessa informativa.

Published – Stato del contenitore informativo approvato per uso contrattuale.

Revision code – Codice che identifica la versione del contenitore (P01, P02, C01, C02…).

Rework -Ritorno del contenitore allo stato WIP dopo una revisione negativa.

Shared – Stato del contenitore condiviso per coordinamento interdisciplinare.

Suitability code – Codice di idoneità che indica lo scopo d’uso del contenitore (S0-S7, A1-AN, B1-BN, CR, PR).

Task Team – Team di lavoro che produce un contenitore informativo specifico.

WIP – Work in Progress. Stato iniziale del contenitore, in lavorazione interna al team.

 

 

Fonte: Read More