Capitolato informativo BIM, OGI e pGI: differenze, contenuti e flusso di gara

Capitolato informativo, offerta di gestione informativa e piano di gestione informativa sono i documenti che trasformano una generica richiesta BIM in un processo verificabile. Il capitolato informativo esprime le esigenze del committente; l’OGI descrive la risposta del concorrente; il pGI rende operative le modalità concordate con l’aggiudicatario.

Confonderli produce un effetto ricorrente: requisiti vaghi in gara e regole definite troppo tardi, quando gruppi, software e tempi sono già stati stabiliti. Questa guida spiega chi prepara i tre documenti, che cosa devono contenere e come collegarli senza duplicazioni.

I tre documenti nel flusso BIM

Il flusso è progressivo. L’OGI non dovrebbe riscrivere il capitolato, ma spiegare come il concorrente soddisfa i requisiti e quali miglioramenti propone. Il pGI non è una nuova offerta: sviluppa l’impostazione accettata, assegna responsabilità nominali, dettaglia consegne e procedure e diventa il riferimento operativo della commessa.

Che cos’è il capitolato informativo BIM

Il capitolato informativo, spesso abbreviato CI, è il documento con cui il committente definisce requisiti e regole del processo informativo. Negli appalti pubblici è predisposto dalla stazione appaltante e fa parte della documentazione di affidamento. Deve essere coordinato con disciplinare, capitolato speciale, contratto e documenti tecnici.

Un buon CI parte dagli usi delle informazioni. Se l’obiettivo è controllare interferenze, quantità e gestione futura, deve specificare quali modelli e dati rendono possibili tali attività, in quale fase e con quali criteri di accettazione. Chiedere “modelli completi” non è misurabile e induce i concorrenti a formulare ipotesi diverse.

Che cosa deve contenere il capitolato informativo

L’Allegato I.9 al Codice individua contenuti minimi: requisiti informativi strategici, generali e specifici, compreso il livello di fabbisogno informativo; modalità di produzione, gestione, trasmissione e archiviazione; caratteristiche dell’ACDat; regole su proprietà, accesso, validità, sicurezza, riservatezza e proprietà intellettuale; specifiche di interoperabilità.

Nella pratica il documento dovrebbe descrivere anche obiettivi e usi BIM, modelli disciplinari, sistema di coordinate, classificazioni, convenzioni di denominazione, formati nativi e aperti, calendario delle consegne, controlli e gestione delle anomalie. La struttura deve restare proporzionata. Un CI di cento pagine copiato da una grande infrastruttura può essere inadatto alla ristrutturazione di un piccolo edificio.

Requisiti informativi e livello di fabbisogno

Il committente deve chiedere informazioni utili a decisioni precise. Per una fase preliminare può bastare conoscere ingombri, prestazioni e quantità indicative; per l’approvvigionamento servono identificazioni più puntuali; per la manutenzione sono necessari dati verificati sui componenti installati.

Il livello di fabbisogno informativo riguarda geometria, attributi e documentazione. Non coincide con il massimo dettaglio possibile. Ogni requisito dovrebbe indicare perché l’informazione serve, chi la usa e quando viene controllata. Dati richiesti senza uno scopo aumentano lavoro e responsabilità senza produrre valore.

ACDat, formati e interoperabilità nel CI

Il capitolato deve spiegare come verrà usato l’ambiente di condivisione dei dati: accessi, stati, approvazioni, versioni, metadati, conservazione e supporto agli utenti. Se la piattaforma è già scelta, vanno fornite informazioni sufficienti a stimare attività e compatibilità; se sarà proposta dall’affidatario, devono essere stabiliti requisiti prestazionali e regole di proprietà e restituzione dei dati.

I formati aperti non devono essere indicati in modo rituale. Occorre definire quali informazioni debbano sopravvivere allo scambio e come verranno verificate. Un IFC può aprirsi correttamente e perdere codici, proprietà o relazioni necessarie. I criteri di accettazione devono quindi guardare al contenuto, non soltanto all’estensione del file.

Che cos’è l’OGI

L’offerta di gestione informativa è la risposta del concorrente al capitolato informativo. Secondo l’Allegato I.9 viene presentata in gara nelle procedure con offerta economicamente più vantaggiosa. Descrive organizzazione, competenze, strumenti e metodi con cui il concorrente intende soddisfare le richieste.

L’OGI dovrebbe mostrare una strategia credibile: organigramma, esperienze e responsabilità; flussi di coordinamento; ambiente dati; software e interoperabilità; controlli; modalità di consegna; eventuali proposte migliorative. Non deve promettere prestazioni irrealistiche soltanto per ottenere punteggio, perché i contenuti accettati confluiranno nel successivo piano e negli obblighi contrattuali.

Come valutare un’OGI senza premiare soltanto la forma

Una relazione ricca di immagini e termini tecnici non è necessariamente una buona offerta. La commissione dovrebbe valutare la coerenza tra requisiti, persone, strumenti, tempi e controlli. Se il concorrente propone verifiche settimanali, deve dimostrare di avere risorse e workflow compatibili. Se offre usi aggiuntivi, occorre capire quali risultati producano per la stazione appaltante.

I criteri di gara devono essere specifici e graduabili. Premiare genericamente “la qualità del BIM” rende difficile motivare i punteggi; è preferibile valutare aspetti identificabili, come strategia di coordinamento, qualità dello scambio aperto o gestione delle informazioni per l’esercizio.

Che cos’è il piano di gestione informativa

Il pGI è predisposto dall’aggiudicatario sulla base dell’OGI e delle condizioni contrattuali. Nell’assetto ordinario viene consegnato dopo la stipula e prima dell’esecuzione. In caso di avvio d’urgenza la stazione appaltante può richiederlo prima della stipula, secondo la disciplina della procedura.

Il piano rende eseguibile il processo. Indica nominativi e responsabilità, matrice degli scambi, modelli e contenitori, scadenze, codifica, coordinate, workflow ACDat, procedure di federazione e verifica, software e versioni, formati, gestione delle issue, sicurezza e consegne finali. Ogni regola dovrebbe essere abbastanza precisa da poter essere controllata.

Il pGI può essere aggiornato?

Sì. L’Allegato I.9 ammette aggiornamenti durante l’esecuzione. È normale che una commessa debba adattare strumenti, gruppi o calendario; la modifica non deve però avvenire informalmente. Vanno registrati motivo, versione, approvazione, decorrenza e impatto su costi, tempi e obblighi.

Una modifica del piano non può diventare il mezzo per ridurre requisiti contrattuali senza il corretto procedimento. Se cambia la sostanza della prestazione, occorre valutarla secondo contratto e Codice. Il versionamento nell’ACDat deve permettere di ricostruire quale piano fosse valido in ogni momento.

Esempio: progettazione e lavori di una scuola

La stazione appaltante vuole coordinare strutture e impianti, controllare quantità e ricevere dati per manutenzione. Nel CI definisce modelli, requisiti, scadenze, formati aperti, ACDat e criteri di verifica. Un concorrente presenta un’OGI con team, workflow e strumenti, spiegando come organizzerà riunioni e issue.

Dopo l’aggiudicazione, il pGI assegna i nominativi, dettaglia la matrice delle consegne, stabilisce coordinate e codici e descrive i test di interoperabilità. Durante il progetto emerge la necessità di una consegna aggiuntiva per il gestore: il piano viene aggiornato in modo tracciato. I tre documenti restano così collegati dall’obiettivo iniziale alla prestazione effettiva.

Le differenze nei lavori privati

Nel privato le denominazioni non sono sempre obbligatorie, ma il principio resta utile. Il committente esprime requisiti; il professionista o l’impresa propone il metodo; le parti concordano un piano operativo. Anche una ristrutturazione complessa beneficia di un documento breve che definisca modelli, formati, scadenze, proprietà e responsabilità.

La proporzionalità è decisiva. Per una casa unifamiliare possono bastare poche pagine chiare; per un ospedale o un portafoglio immobiliare servono procedure articolate. Eliminare la documentazione non riduce i rischi: li lascia impliciti e li fa emergere durante le contestazioni.

Errori frequenti

Il primo errore è redigere il CI dopo aver scelto software e modalità di lavoro: i requisiti finiscono per giustificare una soluzione già decisa. Il secondo è copiare elenchi di dati che nessuno userà. Il terzo è accettare un’OGI piena di promesse non misurabili. Il quarto è trasformare il pGI in un documento statico, ignorato dal gruppo.

Altri problemi nascono da incoerenze tra documenti, assenza di criteri di accettazione, ruoli nominali e mancata disciplina delle consegne finali. La verifica dovrebbe iniziare prima della gara e continuare per tutta la commessa.

Checklist di coerenza

• ogni obiettivo del committente genera requisiti e consegne identificabili;
• l’OGI risponde ai punti del CI senza lasciare ambiguità;
• il pGI conserva gli impegni offerti e li rende operativi;
• ruoli, ACDat, formati e controlli coincidono nei documenti contrattuali;
• aggiornamenti e approvazioni sono versionati e tracciati;
• le consegne finali sono utilizzabili dal committente e dal gestore.

Domande frequenti

OGI e pGI sono lo stesso documento?

No. L’OGI è la proposta presentata dal concorrente in gara; il pGI è il piano operativo sviluppato dall’aggiudicatario dopo il contratto e prima dell’esecuzione.

Il capitolato informativo deve indicare un software?

Dovrebbe descrivere requisiti e prestazioni, tutelando interoperabilità e concorrenza. Un prodotto specifico può essere indicato soltanto quando vi siano presupposti e motivazioni adeguate.

Il pGI può modificare l’offerta?

Deve svilupparla, non ridurla o sostituirla. Eventuali variazioni sostanziali richiedono la gestione prevista dal contratto e dalla normativa.

Questi documenti servono anche nel privato?

Sì, adattandoli alla scala. Rendono chiari obiettivi, responsabilità, scambi e proprietà delle informazioni anche quando il Codice dei contratti non si applica.

Conclusioni

CI, OGI e pGI costruiscono una catena di responsabilità. Il committente deve sapere che cosa chiede; il concorrente deve dimostrare come intende rispondere; l’aggiudicatario deve trasformare l’offerta in un processo controllabile. Quando i tre documenti sono coerenti, il BIM smette di essere una formula di gara e diventa uno strumento concreto per governare progetto, costruzione e consegne.