shelidonAugust 9, 2019Leave a Comment

Non riprendo quasi mai in mano ciò che ho scritto in passato, a meno di non dover rettificare delle inesattezze: gli articoli sono figli del loro tempo, cercate di verificare sempre le date e fate la tara ad articoli vecchi, perché potrebbero parlare di strumenti ormai defunti (Flux.io, per dirne una) o di strumenti che da allora sono profondamente cambiati. Tempo fa, scrissi un paio di revisioni poco lusinghiere di BIM360docs (qui e qui) e non ho ancora avuto tempo né modo di tornare sull’argomento. Oggi, all’alba di un workshop da un cliente, è da tempo doveroso per me tornare sull’argomento.

Cosa è cambiato?

Tutto. O quasi.

Tralasciando tutti i discorsi teorici sulla natura del Common Data Environment, che ormai ci escono dagli occhi e che eventualmente potete trovate qui, consideriamo due forme di CDE:

• quelli che consentono una condivisione asincrona (il vecchio Level 2), in cui modelli e documenti vengono caricati in momenti pianificati del processo;
• quelli che consentono una condivisione sincrona, un flusso in tempo reale di modelli e documenti (il vecchio Level 3).

A questo schema, aggiungiamo che ogni fase del processo ha bisogno di strumenti con funzionalità specifiche, ecco il panorama di strumenti messi a sistema nella suite BIM360, così come viene descritta da Autodesk:

Di questi, al momento sto utilizzando solo due parti:

• BIM360design è andato a sostituire Collaboration for Revit, con un sistema di sinronizzazione in cloud che consente la collaborazione in tempo reale, da remoto, sullo stesso modello.
  E se è vero che rimangono valide le consuete raccomandazioni in termini di contratti, responsabilità e qualità della connessione, lo strumento è ormai utilizzabile senza troppi problemi. Se avete un team decentralizzato, è più o meno l’unica alternativa valida sul mercato, a meno di lavorare di fino con la suddivisione del modello. Come sistema di condivisione sincrona, per lo meno.
• BIM360docs è ora un documentale complesso ma intuitivo, con una serie di funzionalità estremamente utili per revisioni e RFI e la possibilità di impostare workflow personalizzati.

BIM360docs

1. Pubblicazione di un modello

La pubblicazione di un modello sulla piattaforma BIM360docs può essere fatta direttamente da Revit, una volta effettuato il log-in con un account Autodesk collegato al prodotto. Nel mio caso, per la prima volta nella storia di questo blog, è passata la CIA con il pennarello nero a punta spessa: si tratta dell’account del cliente e questa volta sono davvero dati sensibili.

Troverete due pulsanti nuovi al tab Collaborate, accanto alla consultazione della History e alla funzione per ripristinare il Backup:

• Manage Cloud Models;
• Publish Settings.

Con Publish Settings è possibile selezionare quali tavole vengono automaticamente estratte sulla piattaforma, funzionalità già presente in Collaboration for Revit e che naturalmente fa risparmiare una quantità enorme di tempo ai team in fase di consegna (ammesso che da qualche parte ci sia qualcuno cu importa qualcosa).

2. Funzionamento Base

BIM360docs, in sintesi, è una piattaforma di gestione documentale con integrazione sia desktop che mobile, una versione offline e online, per consentire l’accesso da qualunque momento (e non è forse il vostro sogno poter visualizzare modelli di Revit anche dalla spiaggia?). Si interfaccia sia con file in formato nativo Revit, sia con file in formato di interscambio (IFC) sia con file di altro formato (pdf, immagini) in modo decisamente più efficiente rispetto all’ultima volta che ne ho parlato.

Volendo sintetizzare i suoi quattro ambiti di azione, consente di:

• Pubblicare;
• Condividere;
• Visualizzare;
• Commentare.

Se siete dall’altra parte della barriccata, non avete Revit, non avete un account BIM360 e quasi fate fatica a ricordare dove avete messo il computer, niente panico: un admin dall’altro lato vi può invitare e riceverete una mail simile a questa:

3. Gestione dei Progetti

BIM360 organizza la sua vita (e la nostra) intorno al concetto di Progetto, cui aggancia le varie funzionalità della suite che sono state attivate per quel progetto. Vi troverete quindi davanti a qualcosa del genere:

La parte che ci interessa al momento è quella legata al Document Management,

4. Tipologie di Account

La piattaforma consente di impostare fondamentalmente due tipologie di account:

• Account Admin, the King of the Mountain, cui è consentito:
  • Creare nuovi progetti;
  • Invitare nuovi utenti;
  • Invitare nuovi membri al progetto e gestirli;
  • Gestire le aziende associate agli utenti.
• Project Admin, the little king of the mountain, cui è consentito:
  • Invitare nuovi membri al progetto e gestirli.
• Paesant, che possono alternativamente accedere a diverse parti della suite, ovvero quelle parti che avete visto nel menu di sopra:
  • Document Management;
  • Project Management;
  • Design Collaboration;
  • Model Coordination;
  • Field Management.

I membri invitati dall’admin vengono raggruppati all’interno di un tab, visibile all’admin, e diventano quindi membri del suo team, ma non sono ancora associati al progetto. Li ha comprati, insomma, ma se li sta tenendo in tasca.
I membri invitati non ricevono una notifica quando invitati nella sezione del team di questo admin, ma il project admin potrà invitare ad un progetto solo gli utenti già presenti in questa sezione.

La grande differenza tra Admin e Project Admin, quindi, è la possibilità del primo di:

• Aggiungere un utente;
• Aggiungere un nuovo account admin;
• Importare un elenco utenti da uno spreadsheet;
• Abilitare o disabilitare un utente;
• Esportare in csv l’elenco utenti.

Ogni membro ha associato uno status, ovvero:

• Attivo (ha un account Autodesk);
• Inattivo (la mail indicata non esiste in natura);
• Pending (la mail indicata non è associata a un account Autodesk)

A ogni membro può essere associata un’azienda di riferimento (Company), ma è prima necessario crearle nella sezione specifica.

La sezione specifica di gestione di un progetto, visibile solo al Project Admin ed all’Account Admin, è invece quella in cui si possono gestire:

• Members: il project admin o l’account admin aggiungono gli utenti che possono accedere al progetto, associandoli a un’azienda (Company) e identificando per loro un ruolo che può essere au sa volta di “project admin” e consentendo o meno l’accesso agli altri tab. Un utente può avere 1 o più ruoli. Se un utente ha più di un ruolo, come appaltatore e sovrintendente, la selezione di entrambi i ruoli offre più opzioni quando si impostano le autorizzazioni per gli utenti.
• Companies: l’elenco delle aziende associate al progetto.
• Services, un pannello da cui è possibile:
  • Visualizzare/modificare i Project Admin;
  • Visualizzare la cronologia di gestione documentale (Document Management).
• Profile, da cui è possibile modificare le informazioni di profilo del progetto inserite durante il processo di creazione;
• Workflow, che consente di creare, a livello di singolo progetto, dei processi di revisione.

5. Plans vs. Project Files

Un’intuizione curiosa, anche se possibile fonte di confusione, è quella di suddividere lo spazio in due macro-categorie con funzionalità e comportamenti diversi:

• Plans;
• Project Files.

Il primo spazio si configura come uno spazio di lavoro, che gestisce ad esempio solo alcune categorie di formati “editabili” (PDF, DWF, RVT, IFC e DWG), non supporta i pdf multipagina ma li spacchetta in singoli file, supporta l’OCR per estrarre metadati dal cartiglio di pdf non vettoriali, estrae automaticamente gli Sheet dai file di Revit che vengono caricati, crea collegamenti ipertestuali tra file sui callout e supporta il confronto tra due versioni dello stesso documento.

Il secondo spazio, viceversa, è uno spazio di pubblicazione: gestisce qualunque tipo di file e supporta i pdf multipagina, non esporta automaticamente gli sheet, non supporta l’OCR.

6. Markups, Issues e RFI

Certamente una delle funzioni più interessanti è la possibilità di utilizzare la piattaforma per interagire in diversi modi con i documenti, creando:

• marukp
• issues
• RFI.

Il Markup è la vecchia nuvoletta: è possibile inserire note, frecce, testi all’interno di un Markup e poi renderlo visibile al mondo, o tenersi il commento per sé.
Ogni markup mostra di base informazioni circa l’autore e la data in cui è stato posizionato, ma poco altro.

Davvero interessanti invece sono le Issues, che consentono una gestione altamente più raffinata dei commenti. Senza entrare troppo nel dettaglio circa il loro funzionamento, questo è ciò che trovo davvero interessante:

• La tipologia, un campo obbligatorio che richiede di categorizzare il problema spaziando da:
  • Commissioning;
  • Coordination:
    • Clash o General Coordination;
  • Design:
    • Building Code, Client Feedback, Design, Existing Conditions, Requirement Change, Work to Complete;
  • Observation:
    • Observation, Quality, Safety.
  • Punch List:
    • Pre-Punch List, Punch List.
  • Qualty;
  • Safety:
    • Safety, Safety Infraction.
• La possibilità di assegnare la Issue non solo a una persona specifica, ma anche a un ruolo (es: è un problema da BIM Coordinator ma non so bene quale) o a un’azienda (es: è un problema degli strutturisti, ma tirino pure a sorte tra di loro);
• La possibilità di assegnare una Root Cause (una causa a monte del problema) classificata tra:
  • Coordination (Coordinamento):
    • Constructability (è tutto molto bello, ma non si può costruire); Design Coordination (è tutto molto bello, ma è incompatibile con quello che ha progettato qualcun altro); o Design Deficiency (è tutto molto bello ma, ripensandoci, anche no);
  • Design (Progettazione):
    • Code Compliance (è tutto molto bello, ma non è a norma); Documentation Conflict (è tutto molto bello, ma in un’altra tavola è diverso); o Documentation Incomplete (è tutto molto bello, ma mi manca una sezione).
  • Quality:
    • Communication; Coordination; Design Change; Design Flaw; Housekeeping; Inadequate Training (decisamente il mio preferito); Incomplete Work; Installation; Manufacturer Defect; Natural Disaster; Planning; Trade Damage; Weather; Workmanship;
  • Safety:
    • Equipment:
      • Improper Equipment; Improper maintenance; lack of inspection;
    • Human:
      • Failed to identify unsafe condition; Fatigue; Human Error; Ignorance of procedure (un’altra delle mie preferite); Ignorance of use of PPE; Lack of coordination; Lack of skill or training; Mental Stress (un’altra veramente bella);
    • Management:
      • Desgn Deficiency; Improper Housekeeping; Insufficient planning; Lack of coordination; Lack of procedure; Lack of protective safety equipment; Work permit not followed.
    • Material:
      • Material component failure; Wrong Material.

In aggiunta, come parte del modulo di Project Management, molto interessante è la possibilità di integrare gli RFI sulla piattaforma. Vengono creati attraverso delle schede molto simili alle issue ma, anziché essere assegnate con flessibilità, il loro viaggio segue quelli che vengono definiti workflow, ovvero dei passaggi predefiniti. I workflow sono un’altra funzione interessante, che fondamentalmente consente di fare di BIM360docs un CDE workflow-based, ovvero di impostare flussi di lavoro che è necessario seguire per i processi di revisione.

7. Workflow

7.1 Creazione

La creazione di un nuovo workflow di approvazione avviene nel tab Project Admin, alla sezione Document Management, nella porzione Services (che al mercato mio padre comprò).

Per creare un approval workflow, sarà necessario scegliere un template che fondamentalmente determina a quanti e quali gradi di approvazione il documento deve essere sottoposto quando si troverà ad attraversare quel workflow. Al momento sono presenti due tipi di template con una serie di sotto-tipi:

• Approvazioni di un singolo, da 1 a 6 step;

• Approvazioni di un gruppo, da 2 a 4 step.

La differenza tra le approvazioni singole, da 2 in su, non è particolarmente significativa: si tratta solo di aggiungere strati e strati, fino a quando vi sarete dimenticati qual era il documento che stavate cercando di far approvare. Particolarmente adatto per le pubbliche amministrazioni o per chi non vuole mai vedere costruito il proprio progetto.

Più articolati e interessanti sono i workwlow che prevedono approvazioni di gruppo:

• Two Step Group Approval prevede:
  • che vi sia una prima revisione da parte di un gruppo di persone;
  • che l’approvazione finale sia affidata a un singolo.

• Three Step Group Approval prevede:
  • che ci sia un individuo con un po’ di sale in zucca all’inizio del processo;
  • che la revisione di mezzo sia affidata a un gruppo;
  • che un altro individuo abbia il compito di mettere la firma finale.

• Four Step Group Approval è simile a quello di gruppo in tre fasi, ma prevede la presenza di un secondo individuo che controlli il primo (perché del primo non ci fidavamo poi così tanto).

La cosa significativa ad emergere è che, chiaramente, Autodesk non crede nella possilità di un gruppo di persone di mettere l’approvazione finale a qualcosa. Forse Andrew sta cercando di dire qualcosa al suo consiglio di amministrazione.

7.2 Utilizzo di un workflow

Selezionando un qualsiasi documento all’interno di una cartella del progetto, è possibile segnalare che tale documento deve essere soggetto a revisione e si può quindi assegnare un Workflow di riferimento tra quelli che abbiamo faticosamente creato prima.
L’operazione può essere effettua solo da chi è stato indicato come Initiator nella creazione del Workflow, quindi se avete sbagliato a indicare la persona che dà inizio a tutto, nulla avrà inizio. Come spesso accade.

Se invece tutto è andato per il verso giusto, l’Initiator seleziona chi dovrà effettuare la revisione scegliendo tra la lista dei revisori indicati sempre in fase di creazione del Workflow: al revisore verrà quindi inviata una mail con la buona notizia.

Se la revisione non è l’ultima del workflow, si parla di Revisore. Se è l’ultima, ovviamente, si parla di Approvatore.

Il Revisore/Approvatore visualizza il documento e, se vuole effettivamente procedere alla revisione deve selezionare Start Review. Può aggiungere markup o commenti, visualizzare markup o commenti precedenti, il loro storico ecc. BIM360docs prevede tre status per un documento:

• Approvato;
• Rifiutato;
• Approvato con commento.

Purtroppo non è (ancora) possibile replicare gli status di norme un pochino più articolate, come quella inglese o quella italiana.

Una volta approvato (o meno) il file, si procede selezionando Submit Review cioè si invia la revisione, oppure:

• Release task, per sbolognarela patata bollente a qualcun altro e assegnare ad un altro utente il compito di portare avanti la revisione;
• End review, per concludere la revisione senza esito, rimandare il problema a domani e uscire a bere con gli amici.

Se il Workflow lo prevede, alla conclusione della revisione il file verrà automaticamente copiato nella cartella che si era indicata in fase di creazione. Un’altra funzionalità estremamente utile per spostare di comparto i documenti.

Lavorandoci con modelli complessi, saltuariamente emergono ancora dei glitch (modelli che non generano le tavole, tavole vuote, qualche problema con i link, comportamento bizzarro degli IFC) ma nel complesso devo dire che rispetto alle prime prove è diventato decisamente un bellissimo strumento, assolutamente non paragonabile a Vault come flessibilità e performance, e non faccio troppa fatica a vederlo diventare uno strumento indispensabile. Provatelo: potete richiedere una demo a questa pagina.