Ma il mio Capitolato Informativo fa schifo?

Domanda legittima. Dato che settimana scorsa ho scritto due righe a proposito dei riferimenti normativi obsoleti, qualcuno ha pensato che potesse essere una buona idea mandarmi il suo capitolato informativo per sapere se fosse ben fatto oppure no. A prescindere dal fatto che un lavoro di revisione ben fatto è, appunto, un lavoro, ecco alcune linee guida rapide per capire se il vostro consulente vi ha consegnato un buon lavoro oppure se state mettendo a base di gara un documento che urla vendetta al cospetto di dio.

Checklist

• Obiettivi di progetto e usi del modello. Questa è una cosa che non dovrebbe mai mancare, che in soldoni si traduce in:
  • perché abbiamo deciso che il progetto dovrà essere in BIM? La risposta a questa domanda dovrebbe essere migliore di “perché è obbligatorio” e i motivi di solito sono collegati agli obiettivi del progetto: il miglioramento dell’efficienza energetica, la gestione del rischio antincendio, lo sfruttamento di particolari risorse sul territorio sono tutti obiettivi comuni che trovano riscontro in BIM.
  • cosa vogliamo essere in grado di fare con il modello? Una volta messi a fuoco gli obiettivi, questa porzione si occupa della loro traduzione in operazioni pratiche richieste sul modello: se l’obiettivo è la verifica di conformità normativa, l’uso potrebbe essere la verifica dei RAI.

Nota: nel capitolato potete anche non essere così specifici, anzi, vi consiglio di non farlo a meno che non abbiate già un’infrastruttura interna tramite la quale sarete voi a portare avanti operazioni di analisi o di estrazione dati dai modelli ricevuti. Aspettatevi però, nell’offerta, una declinazione un po’ più puntuale di usi a partire dai vostri obiettivi ad alto livello.

• Fabbisogno informativo e Livelli di Sviluppo degli Oggetti. Ripetete con me: i LOD dipendono dagli usi del modello. Dire “al LOD 400 bisogna modellare le armature” non significa assolutamente niente, perché al LOD 400 non bisogna fare assolutamente niente. Il principio è enunciato chiaramente nell’introduzione della guida ai LOD sviluppata da anni dal BIM forum (la Bibbia del Professionista Che Non Deve Chiedere Mai Due Soldi Per Comprarsi Le Norme) e viene preservato anche nelle norme nostrane. Anche in questo caso, come nel caso di obiettivi e usi, bisogna distinguere due ambiti:
  • Cosa voglio, come committenza, che i progettisti / costruttori facciano tramite quel BIM per il quale li sto pagando e come voglio che ci arrivino. Questi sono gli obiettivi inerenti alla fase di progettazione e costruzione (es: verifica di conformità normativa, estrazione quantità) e si declinano nei cosiddetti Livelli di Sviluppo (LOD) perché hanno bisogno di essere sviluppati progressivamente e verificati tramite milestone, altrimenti nessuno arriverà vivo alla fine del progetto.
  • Cosa serve a me, committente, in fase di consegna del modello di progetto (ad esempio per fare le verifiche di progetto), in itinere di costruzione (ad esempio per verificare e approvare gli Stati Avanzamento Lavori), in fase di consegna del modello di as-built (ad esempio per archiviare il modello dell’immobile in preparazione a interventi successivi) oppure in fase di consegna del modello per di gestione (che, come ricordiamo, è una cosa diversa dal modello di as-built). Questo concetto è ben riassunto dal principio di fabbisogno informativo, ovvero: “io, committente, alla consegna ho bisogno che il modello contenga oggetti geometricamente configurati in questo modo e contenenti i seguenti attributi compilati in quest’altro modo”.

Se al minimo il vostro capitolato deve contenere quindi un’indicazione vaga di cosa vogliamo venga fatto con il BIM in questo progetto e cosa contate di farci una volta che il modello vi sarà stato consegnato (ammesso che contiate di farci qualcosa), la sezione sui LOD dovrebbe contenere il come il contenuto del modello, generalmente discretizzato per categoria di oggetto, conta di supportare questi usi.

Se il vostro capitolato non contiene una sezione sugli usi, è perfettamente inutile avere una sezione sui LOD. Se la vostra sezione sui LOD è una tabellina generica che dice “esecutivo: LOD D; as-build: LOD F”, non siete messi molto meglio di così. Dovreste almeno riuscire a identificare delle caregorie sensibili per i vostri usi, sui quali gli offerenti dovranno dimostrare di saper porre la loro attenzione.

• Ambiente di Condivisione Dati (o Common Data Environment, per gli amici CDE se non fosse che di solito non ha amici). Abbiamo definito cosa (e perché) tramite gli usi del modello, abbiamo definito (o richiesto di definire) il come tramite Livelli di Sviluppo e/o Livelli di Fabisogno Informativo, rimane da definire il dove (che è anche un po’ un altro pezzo del come) e questa è la sezione in cui si parla delle piattaforme di distribuzione e condivisione del lavoro. Anche in questo caso, possiamo dividere il ragionamento in “interno all’offerente” e “in relazione alla committenza”, ricordandoci una cosa importante: l’Ambiente di Condivisione Dati non è una singola soluzione tecnologica, ma un insieme di soluzioni e, soprattutto, dei processi che armonizzano tra loro queste soluzioni. Nessuno cucina con una sola pentola: il senso di definire l’ambiente di condivisione dati è orientato a definire i flussi della cucina, per accertarsi che le pentole siano tutte a norma ma anche che il cuoco non si sia infilato le dita nel caso prima di passare con le mani le cose da una padella all’altra (tanto sappiamo tutti che lo fanno).
  • CDE di produzione e di condivisione interna: questa è la parte in cui architetto e strutturista dovranno dirvi come e con cosa si parleranno, come garantiranno che nessuno faccia lavoro inutile perché per sbaglio ha visto un’ipotesi progettuale non verificata (il famoso status WIP privato serve a questo), come vi garantiranno di consegnare solo prodotti coordinati. Avete diritto a sapere come avviene questa parte, da committenti, ma non avete diritto a vederne i prodotti.
  • CDE di condivisione e di consegna con la committenza: questa è la parte in cui andate a definire quali soluzioni tecnologiche state mettendo a disposizione per la condivisione con voi, per supportare i flussi di validazione e approvazione e, soprattutto, per la consegna finale delle informazioni nel rispetto delle normative vigenti.

La cattiva notizia è che, se siete una committenza, soprattutto una committenza pubblica, non potete mettere in carico all’offerente la fornitura dell’Ambiente di Condivisione Dati. Lo diciamo tipo dal 2016. E se è vero che nel DM 560 si parla di “adozione, anche a titolo non oneroso”, pur sempre di adozione si tratta, per quanto l’ANAC abbia specificato “è stata valutata anche la possibilità di demandare la messa a disposizione dell’ambiente di condivisione dati all’aggiudicatario”. La cosa è spiegata molto bene dall’avv. Batutta in questo articolo. Sempre l’ANAC, come ci ricorda l’avvocato, ha aggiunto: “Tuttavia, la necessità di conservare nel tempo il patrimonio informativo contenuto nell’ambiente di condivisione dei dati e di garantire l’accessibilità allo stesso anche dopo il completamento della prestazione professionale oggetto di affidamento, depone per il mantenimento in capo alla stazione appaltante della proprietà dell’ambiente di condivisione dati”. Non si tratta quindi di chiedere all’offerente di mettere in piedi una piattaforma per la durata della commessa, ma si tratta di chiedere all’offerente di regalarvi la piattaforma, vita natural durante o per lo meno per un periodo di utilizzo che dovrebbe essere ben definito da qualche parte. Tipo nell’atto organizzativo.

Non solo è una cosa che nessun offerente sano di mente dovrebbe accettare di proporvi, ma è anche in aperto contrasto con quanto definito da un altro testo normativo, troppo spesso dimenticato in ambito BIM, ovvero il Codice per l’Amministrazione Digitale (D.Lgs. 7 marzo 2005, n. 82). Nell’articolo 44 del codice, che richiama l’articolo 52 del d.P.R. 28 dicembre 2000, n. 445, tra le altre cose sancisce che: “il responsabile della conservazione [dei dati], può affidare, ai sensi dell’articolo 34, comma 1-bis, lettera b), la conservazione dei documenti informatici ad altri soggetti, pubblici o privati, che offrono idonee garanzie organizzative, e tecnologiche e di protezione dei dati personali”. L’articolo in questione, modificato dalla legge n. 120 del 2020, stabilisce che le pubbliche amministrazioni possono procedere alla conservazione dei documenti informatici anche “affidandola, in modo totale o parziale, nel rispetto della disciplina vigente, ad altri soggetti, pubblici o privati che possiedono i requisiti di qualità, di sicurezza e organizzazione individuati, nel rispetto della disciplina europea, nelle Linee guida di cui all’art 71 relative alla formazione, gestione e conservazione dei documenti informatici nonché in un regolamento sui criteri per la fornitura dei servizi di conservazione dei documenti informatici emanato da AgID, avuto riguardo all’esigenza di assicurare la conformità dei documenti conservati agli originali nonché la qualità e la sicurezza del sistema di conservazione”.

Risulta quindi evidente che l’affidatario può garantire il servizio e la conservazione digitale del materiale informativo assicurando autenticità, integrità, affidabilità, leggibilità, banana e reperibilità nel tempo per la durata dell’incarico, ma la garanzia del sistema di conservazione deve essere assorbita all’interno della Stazione Appaltante al termine della commessa, oppure formalizzata tramite separato conferimento d’incarico che identifichi l’affidatario come “Responsabile della Conservazione” (o equivalente), come previsto dagli standard AgID. Per quanto l’acquisizione della piattaforma possa essere non onerosa (LOL), mi sembra evidente che il suo mantenimento e la sua gestione debbano costituire incarico a parte, con garanzie e caratteristiche rigidamente normate. Occhio.

Definito cosa, come e dove, rimane da definire quando, ma mi aspetto che da qualche parte ci sia un cronoprogramma, quanto e chi. Partiamo dal chi.

• Organigramma e matrice di responsabilità. Due cose che nel vostro capitolato devono essere richieste, ma per la matrice di responsabilità potete anche presentare una base precompilata nelle parti che vi riguardano, ovvero nel coinvolgimento del RUP all’interno dei processi in analisi: deve essere informato? Consultato? Ci sono altre figure interne alla committenza di cui bisogna tenere conto? Questa è una buona cartina di tornasole: se non sapete quali sono i processi, come fate a sapere in quale misura dovete essere coinvolti? E se i processi sono correttamente mappati, almeno avete la possibilità di verificare che siate in grado di fornire un contributo coerente a processi nei quali dovete essere consultati.

Sul quanto, invece, ho poco da dire. Dovrebbe essere mappato altrove. Mi rimane però una considerazione a margine, rivolta principalmente agli offerenti ma di cui la committenza deve essere a conoscenza: il famigerato 10% non è il costo del BIM. O meglio, il 10% è un incremento percentuale dei corrispettivi di progettazione relativo agli extra costi che bisogna sostenere in un processo digitale ben fatto (ad esempio: dar da mangiare al BIM manager, che prima non avevate). Ma se il vostro processo progettuale non è digitalizzato, e avete intenzione di subappaltare all’esterno la produzione del modello, non vi salti in testa di appellarvi al decreto per fissare al 10% l’onorario dell’intera squadra esterna, perché il decreto potrebbe improvvisamente finirvi in luoghi non deputati alla sua conservazione. Il decreto infatti dà per scontato che voi lavoriate in BIM, internamente, e quindi fissa a quel 10% un extra-costo interno. Un modello sviluppato esternamente è, a tutti gli effetti, un progetto sviluppato una seconda volta, e costa molto di più.

Per il resto, in bocca al lupo.