Data Pubblicazione:

BIM: quello che i software non dicono

BIM: quello che i software non dicono

citelli-bim1.JPG
France in 2000 year (XXI century). Building Site. France,  paper card by Jean-Marc Côté.

C’è un trend ricorrente nelle discussioni relative al BIM e alla digitalizzazione del settore delle costruzioni: algoritmi, automazione, AI. 
Sembra che da un momento all’altro progettisti, project manager, cost controller e le relative specializzazioni, saranno sostituiti da processi completamente automatizzati.

Inoltre, nel medesimo dibattito, la retorica dominante è quella secondo la quale questa sostituzione si configuri come una totale depurazione dalla soggettività (e da ciò che questa tutela), in nome di un approccio oggettivo totalizzante, vera soluzione ai problemi dell’industria.

Creando tutta questa aspettativa, il digitale come panacea di ogni male, inevitabilmente si rischia di fare un buco nell’acqua enorme: la digitalizzazione in sé, se non è supportata da un know-how disciplinare, è NULLA.

Qualsiasi automazione su base algoritmica, ad esempio, si compone di una serie di scelte molto specifiche disposte in fila l’una all’altra, che sono tutt’altro che oggettive, anzi, contengono moltissimo del modo di programmare (pensare) dell’operatore, del modo che ha di scomporre il problema. 
Inoltre, anche l’algoritmo più oggettivo (sempre che esista) ha bisogno di input coerenti per dare risultati affidabili: in cucina qualsiasi ricetta, anche se utilizza un evoluto robot, ha bisogno che gli ingredienti siano nelle giuste proporzioni. Della stessa categoria di robot ce ne sono di migliori e peggiori in termini di prodotto finale, anche a parità di ingredienti. Così è un algoritmo.

Nell’ambito delle costruzioni questo tipo di logica, nei processi in atto come nei processi futuri, possiamo trovarla sotto due forme principali: la prima, i software, pacchetti più o meno chiusi di funzioni che permettono di eseguire i più svariati task; la seconda, gli algoritmi custom, messi a disposizione anche dei progettisti, sulla base di programmazione visuale (Grasshopper, DynamoBIM etc) o di programmazione pura nei suoi vari linguaggi (da C# a Python fino a JS).

Scrivere software e algoritmi con l’intenzione di automatizzare in modo radicale le professioni sopracitate è senz’altro interessante e soprattutto sensato, ma enfatizzare eccessivamente la loro capacità di sostituire il professionista in scelte tutt’altro che oggettive rischia di provocare gravi danni.

Per molto tempo infatti le case software hanno evitato di inserire all’interno dei loro programmi funzionalità troppo specifiche per alcuni task molto ricorrenti nella pratica professionale (si pensi alle dimostrazioni analitiche di qualsivoglia requisito normativo da rispettare), proprio per evitare di assumersi in modo implicito delle responsabilità che giustamente competono ai professionisti. 

Molti di questi aspetti possono giovare ampiamente della digitalizzazione, ma sono altrettanti i casi in cui soluzioni software semplicistiche forniscono risultati molto poco affidabili. 
È il caso di due aspetti particolarmente peculiari del processo e della volontà di integrarli ad ogni costo nel BIM (in senso estremamente stretto): l’aspetto energetico e l’aspetto computistico.
Per l’aspetto energetico in termini di risultati numerici, per quello computistico proprio in termini metodologici. 
Un tranello in cui bisogna cercare di non cadere è quello dell’interoperabilità, mantra spesso abusato, soluzione preconfezionata in grado di soddisfare poche esigenze, se non compresa e indagata in profondità: nel caso dei due esempi di cui sopra si tratta principalmente di gbXML e IFC.
Per coloro che possono compiere sforzi tecnici virtuosi le soluzioni ci sono, e risiedono in quell’approccio algoritmico capace di modifica delle condizioni proprie dei software, in modo da veicolare quei due formati su binari più sicuri e affidabili. 

È evidente quindi, che l’identità delle professioni dell’AEC sta cambiando, si sta evolvendo, ma senza la capacità critica che il confronto con procedure tradizionali o manuali ci può fornire, l’evoluzione andrà in una direzione pericolosa.
Confronto che non deve però condurre a un errore frequente, che consiste nella volontà di adattare l’uso di nuove tecnologie alla produzione di un output ormai obsoleto, seguendo processi tradizionali riportati semplicemente in digitale, un po' come in alcune di quelle belle immagini, raccolte in un libro da Isaac Asimov, su come nel 1899 immaginavano l'anno 2000.

citelli-bim2.JPG
  France in 2000 year (XXI century). Electric scrubbing. France, paper card by Jean-Marc Côté.

Per uscire vincenti da questo processo, evidentemente lontano da una qualsiasi stabilizzazione, si dovrà capire che il valore sta nell'evolversi e non nel sostituire la propria professionalità con delle competenze meramente strumentali; nell’essere capaci di reinventare il modo di fare le cose oltre agli strumenti con cui farle.

Il mondo delle costruzioni deve metabolizzare queste evoluzioni e le loro implicazioni, perché molto probabilmente si troverà a dover fronteggiare cambiamenti di una portata difficilmente quantificabile ad oggi: i progressi degli ultimi anni nel campo dell’intelligenza artificiale sono sotto gli occhi di tutti.

Probabilmente, il miglior modo che abbiamo per farci trovare pronti a questi cambiamenti è la costruzione di un sistema di dati ampio, non necessariamente coerente come sarebbe auspicabile che fosse, che ci consenta di trarre i benefici che altri settori cominciano già ora ad avere.
Fino ad allora, la logica algoritmica può essere una grande alleata solo se capiamo che al suo interno non compie scelte, ma rileva corrispondenze; non prende decisioni, ma segue delle precise condizioni.

Diverso sarà (forse) in un mondo di intelligenze artificiali sufficientemente evolute ma, fino a che non si scardinerà la contrapposizione tra realtà e valore computazionale, saremo sempre noi, in modo diretto o indiretto, a fornire gli input, con la soggettività e tutti i limiti che ci rendono umani.


Cittelli Paolo-p-500x.jpeg

 

 

 

 

 

Paolo Citelli - Architetto, lavora come BIM Manager per Lombardini22 della quale ha curato l’implementazione BIM e la formazione. Partecipa al tavolo di lavoro della norma UNI 11337 ed è membro del BIM User Group Italy (BUG).

Il tavolo della norma UNI 11337:2017 si onora di annoverare tra i suoi partecipanti una significativa rappresentanza di giovani professionisti i quali collaborano oggi con i più importanti studi nazionali e sono impegnati in alcuni tra i già interessanti progetti di ingegneria ed architettura contemporanei. Il tavolo normativo oltre a raccogliere le loro esperienze vuole essere anche un utile momento di confronto per loro verso ogni altra realtà ed esigenza della filiera. I differenti punti di vista sono la forza delle norme consensuali e volontarie. Se il BIM è collaborazione e sistema di lavoro collaborativo, il confronto con gli altri: valori, voleri, capacità, conoscenze ed interessi, tipico delle sistema normativo non cogente (UNI, CEN, ISO), è allora il “BIM”.

 

Per scaricare l’articolo devi essere iscritto.

Iscriviti Accedi