Torna al blog BIM e IFC
Consegna e ISO 19650 · 2026-08-07 · 10 min
Criteri di accettazione IFC: come accettare o rifiutare un modello senza discutere
"Questo modello è inutilizzabile" contro "il modello va bene" è una discussione senza fine. Una tabella di accettazione di una pagina, concordata prima della prima consegna, la trasforma in un controllo di cinque minuti con un esito documentato.
Criteri di accettazione IFC: come accettare o rifiutare un modello senza discutere — IFC Viewer Online article cover
In ogni progetto arriva il momento in cui un coordinatore apre un modello consegnato, passa venti minuti a scoprire che non è utilizzabile, e scrive un'email che inizia con "purtroppo". Ciò che accade dopo dipende quasi interamente da una cosa: se qualcuno ha scritto, in anticipo, com'è fatta una consegna accettabile.
Se lo ha fatto, l'email è breve, fattuale e non controversa. Se non lo ha fatto, l'email è la prima mossa di una trattativa su quali standard si applichino, e verrà rimessa in discussione a ogni gate per il resto del progetto.
L'accettazione è una checklist, non un'opinione
Il cambio di prospettiva è piccolo e cambia tutto. Revisionare una consegna non significa valutare la qualità — significa applicare criteri concordati a un file. Questo ha tre conseguenze che vale la pena rendere esplicite:
- Il revisore non ha bisogno di altra autorità oltre alla tabella concordata. Non sta giudicando la competenza dell'autore del modello; sta riportando un risultato.
- L'autore può prevedere l'esito prima di consegnare. Tutto ciò che è prevedibile si può prevenire, ed è proprio questo il punto.
- Il disaccordo, quando avviene, riguarda i criteri — una conversazione che si può avere una volta, con calma, invece che ogni mese nel bel mezzo di una consegna.
Non puoi rifiutare una consegna perché non rispetta uno standard che chi l'ha inviata non ha mai accettato. Puoi rifiutarla solo perché non rispetta quello che avete concordato entrambi.
La tabella dei criteri di accettazione
Questo è l'artefatto. Dieci righe, una pagina, allegata al BEP o all'EIR. La terza colonna è vuota apposta — il progetto la compila prima della prima consegna, ed è in quell'atto di compilazione che avviene il vero accordo.
| Criterio | Rifiuta se… | Posizione di progetto |
|---|
| Integrità strutturale | Qualsiasi rilievo di schema o spaziale di gravità errore | Rifiuta / accetta con nota |
| Health Score | Sotto la soglia concordata | Soglia: __ /100 |
| Copertura dei controlli | Qualsiasi controllo segnalato come non eseguito o fallito | Rifiuta / richiede una nuova esecuzione |
| Stabilità degli identificatori | Turnover dei GUID sopra una percentuale concordata tra le revisioni | Turnover massimo: __ % |
| Nomenclatura | Il nome del file non segue la convenzione concordata | Rifiuta / rinomina e registra |
| Georeferenziazione | Modello non sul punto di riferimento condiviso del progetto | Rifiuta |
| Unità di misura | Unità di lunghezza non metriche | Rifiuta |
| Classificazione | Elementi senza un riferimento di classificazione | Si applica dalla fase: __ |
| Set di proprietà | Pset richiesti mancanti per il livello di fabbisogno informativo dichiarato | Elenco Pset: __ |
| Spazi | Spazi senza nome, nome esteso o superficie | Si applica dalla fase: __ |
Il suo scopo non è essere severa — è essere decisa. Una tabella permissiva su cui tutti sono d'accordo batte una tabella severa arrivata insieme all'email di rifiuto.Le prime tre righe sono quelle che pesano di più, e sono anche quelle più spesso omesse. Le clausole che le inseriscono nel BEP fin dall'inizio sono trattate in Le clausole del BEP che prevengono davvero le consegne IFC scadenti.
La riga 3 merita una sezione a parte: la copertura dei controlli
La maggior parte delle tabelle di accettazione controlla i risultati di un'esecuzione di validazione. Quasi nessuna controlla se l'esecuzione sia davvero avvenuta, e questo è un buco abbastanza grande da farci passare una consegna intera.
Un controllo che non è stato eseguito appare identico a un controllo superato: entrambi producono zero rilievi. Un file grande va in timeout, un worker va in crash, un controllo che dipende dalla geometria si arrende silenziosamente — e il report torna pulito con un punteggio perfetto. La consegna viene accettata, essendo stata controllata solo di nome.
| Stato di copertura | Cosa significa | Azione di accettazione |
|---|
| Eseguito | Il controllo si è completato. Zero rilievi significa zero rilievi. | Fidati del risultato. |
| Non eseguito | Tentato ma senza produrre un esito — di solito un timeout o un'esecuzione annullata. | Riesegui prima di accettare. Non leggerlo mai come un superamento. |
| Fallito | Il controllo ha generato un errore. | Segnalalo. Un punteggio calcolato su controlli falliti non è paragonabile a un'esecuzione pulita. |
Revisionare una consegna in cinque minuti
- Apri il container ed esegui il rule set di progetto. Meno di un minuto per la maggior parte dei modelli disciplinari.
- Controlla prima la copertura, poi i risultati. Se qualcosa non è stato eseguito, fermati — non hai ancora una revisione.
- Leggi il punteggio rispetto alla soglia, poi i rilievi di gravità errore. Tutto il resto è una nota, non un gate.
- Confrontalo con la revisione precedente. I nuovi rilievi sono la notizia; quelli risolti sono la prova che l'ultima revisione è stata seguita.
- Registra l'esito nel transmittal o nel commento della CDE — punteggio, rule set, copertura, e qualsiasi rilievo accettato per accordo.
Il passo 1 è la stessa routine che chi invia dovrebbe aver eseguito prima di consegnare; come controllare un modello IFC prima della consegna la illustra dal lato di chi invia. Quando entrambe le parti eseguono gli stessi controlli, la revisione smette di essere un'ispezione e diventa una conferma.
Come scrivere il rifiuto
Il registro conta quanto il contenuto, perché chi lo riceve è di solito in ritardo sui tempi e raramente colpevole personalmente. Tre regole: nomina il criterio, non il modello. Dai la causa, non solo il sintomo. Di' cosa resta bloccato e per quanto tempo.
Hi {name},
We've run the agreed pre-acceptance check on {filename} (rev {n}) and it
comes back at {score}/100, below the {threshold} we set in clause {x} of
the BEP.
The two findings driving that are:
- {rule id} — {plain description} ({n} elements)
- {rule id} — {plain description} ({n} elements)
Both look like export settings rather than modelling, so they should be
quick — the report is attached with the element references.
We'll hold coordination on this container until the next issue.
Nota cosa manca: qualsiasi aggettivo sul modello, e qualsiasi speculazione sul perché sia successo. Un numero, due identificatori di regola, una causa probabile e una conseguenza. È un messaggio da cui nessuno deve difendersi, ed è per questo che viene messo in pratica invece che degenerare.
Quando accettare un modello che non ha superato il controllo
A volte la risposta giusta è comunque sì — le informazioni mancanti sono fuori dal livello di fabbisogno informativo per quella fase, oppure un fornitore non ha ancora consegnato, oppure l'alternativa è fermare il progetto. Accettare una consegna che non ha superato il controllo è una decisione legittima. Accettarla in silenzio no.
Un rilievo derogato ha bisogno di tre cose allegate: un motivo, una persona che ha concordato, e una data. È tutta la differenza tra un rilievo accettato e un rilievo ignorato, ed è ciò che impedisce che lo stesso problema venga riscoperto come una crisi due fasi più tardi.
Quelle deroghe vanno nel transmittal, insieme al report e a tutto il resto che viaggia con il container — vedi cosa consegnare insieme a un modello IFC.
Criteri di accettazione IFC: come accettare o rifiutare un modello senza discutere