Qualche sera fa eravamo a cena dopo una lunga giornata di lavoro: Ilaria & Stefano, gli autori di questo Blog, ed alcuni colleghi.
Teoricamente avremmo dovuto parlare di altro ma alla fine ci siamo ritrovati a parlare di BIM e di come i potenziali utenti stanno avvicinandosi a quello che questo acronimo rappresenta, in Italia e non solo.
Tutti i commensali hanno convenuto che la maggior parte delle persone che ci chiedono del BIM oggi in realtà ci chiedono una “scatola”, un prodotto di nome “BIM”, una sorta di oggetto magico che migliori la situazione. Abbiamo chiamato questo oggetto magico BBB (the Big Box of BIM).![Big Box of BIM [BBB]](https://blogs.autodesk.com/dalbiminpoi/wp-content/uploads/sites/68/2016/02/shoe_box_by_amarao_san-d8o0wrj.png)
Abbiamo cercato di sorridere della situazione ma la realtà è alquanto preoccupante: dopo anni in cui facciamo seminari e partecipiamo a conferenze parlando del BIM come metodologia, come approccio, come soluzione che richiede si software ma anche processi ed organizzazione, ci ritroviamo in situazioni in cui anche “esperti” del settore ci chiedono le specifiche dei pc sui quali fare BIM.
E non ci consola il fatto che anche fuori dall’Italia ci siano situazioni analoghe: se dobbiamo prendere un termine di paragone preferiremmo scegliere degli esempi, come quelli del Nord Europa, dove il BIM è un paradigma ampiamente utilizzato, al punto da essere richiesto anche dalle pubbliche amministrazioni, per i risultati che produce in termini di risparmi economici e di qualità maggiore dei risultati.
Certo, è più facile vendere una “scatola” che non un metodo di lavoro. Questo deriva forse dalla situazione attuale in cui c’è una mancanza di “know-how” specifico nel mercato dell’architettura, dell’ingegneria e delle costruzioni (AEC). Ma noi siamo qui per questo, per aprire questa BBB e vedere quello che veramente c’è dentro: per aspera ad astra…
Sono molto d’accordo su educazione, casi pilota, esempi.
Che pero’ devono essere dettagliati.
Ci sono delle analogie – e delle differenze – con la diffusione del PLM negli anni 1990 – 2000 ed attuali.
Stesse situazioni, stesse frustrazioni. Qualche lezione appresa…
L’uso del PLM (inteso come Product Lifecycle Management = approccio metodologico e di sistemi informativi a supporto, non solo un software, tantomeno un “box”) si e’ affermato, almeno in parte, sia all’estero sia in Italia.
Non si e’ mai tolto pero’ la nomea di “cosa difficile”, “preoccupante”, “perche’ non basta un foglio Excel?”
Alcuni aspetti hanno aiutato:
1) Regolamenti, leggi, “compliance”, audit – Chiaro, bisogna tenere traccia di cosa sei e’ fatto per poter dimostrare che si e’ operato bene (ed in alcuni casi per evitare la galera). Esempi: aerospazio, nucleare, medical device, food. Hanno giocato un ruolo importante gli enti regolatori – che hanno imposto la tracciabilita’ dei dati e delle decisioni. Per il BIM qui c’e’ da investire.
2) La complessita’ dei prodotti, opzioni, varianti e’ cresciuta a dismisura ed ha forzato l’uso del PLM. Con 1000+ opzioni di prodotto (es. degli occhiali) non se ne esce senza una metodologia ed un sistema a supporto. Gli edifici e le infrastrutture hanno potenzialmente e di fatto un alta complessita’ sia come numero di componenti, sequenze di lavoro, attori coinvolti, storia di manutenzione. Tuttavia la percezione (per quanto avverto io) della complessita’ e’ ancora bassa. Si tende a “semplificare” , negando l’esigenza del affronto della complessita’ come opportunita’. Terra incognita. La lezione appresa dal PLM e’ che il lavoro di educazione sta alle Universita’, alle istituzioni, ai consulenti, alle societa’ di software. Ci vuole tempo e pazienza
3) Ad un cedrto punto (quasi subito) il PLM ha chiaramente differenziato, e reso interoperabile, i due aspetti logici di cui e’ composto. 1- “Authoring tool” dove si fa modellazione, calcoli, ecc; tipicamente strumenti personali che producono ed usano dati e file; e’ il contenuto. 2- “Data management tool” dove si immagazzinano, aggregano, combinano, i dati prodotti dall’ authoring tool e si aggiungono dati e processi utili alla gestione (es. attributi, approvazioni, viste, BOM, ecc., tecnicamenti a volte chiamati “metadati”). No accesso ai dati e file direttamente dall’authoring tool, ma solo attraverso il data management tool ed i metadati. Questa sepazione logica ed operativa ha fatto emergere (c’e’ voluto tempo) la chiarezza che l’authoring tool (es. il CAD 3D) ha SOLO il ruolo di produrre i dati (es. modelli 3D) ma e’ il data base tool che possiede i master data e glieli fornisce e li controlla. Questo ruolo di “master” ha lanciato i data base tool come indispensabili. Nel BIM non ho ancora visto questa chiarezza negli utenti, piuttosto un po’ di confusione. Che fare? Anche qui educazione, casi pilota, esempi. Penso che molto del lavoro sia da parte dei fornitori di sistemi e metodologia.
Buon lavoro.
Ciao ~ Dario
Grazie Dario del contributo: ritengo molto interessanti i tuoi argomenti e la tua esperienza con il mercato manifatturiero confrontata con l’odierno mondo del BIM.