Por que as mesmas interferências voltam toda semana?

A reunião semanal de coordenação BIM identificou clashes na semana passada. A equipe discutiu, atribuiu correções, saiu com a sensação de que "resolveu". Sete dias depois, a nova rodada de clash detection reporta as mesmas interferências — ou muito próximas. Alguém pergunta em voz alta: "isso a gente já não tinha discutido?". A resposta é sim. E na semana seguinte, provavelmente será sim de novo.

O problema costuma se manifestar em várias frentes ao mesmo tempo:

• Mesma interferência aparece em ciclos consecutivos — dois, três, cinco reuniões seguidas com o mesmo par de elementos brigando.
• Ninguém sabe quantos clashes foram fechados no ciclo anterior — métrica não existe, ou é reportada como "vários".
• BCF exportado nunca é reimportado — a lista sai da ferramenta, vira PDF ou printscreen, e nunca mais dialoga com o software de coordenação.
• Correção "resolvida" no viewer, não no modelo de trabalho — a disciplina mexeu no visualizador ou marcou como fechado sem reexportar o IFC atualizado.
• Reunião de 2h que produz zero decisões formalizadas — vira sessão de queixa mútua sem plano de ação com dono, prazo e critério.
• Coordenador se afoga em falsos positivos — relatório de clash com 5000+ hits sem filtragem por disciplina, tipo ou tolerance.

O clash detection roda. A ferramenta detecta. Mas o ciclo não fecha. E cada semana começa refazendo o trabalho da semana anterior.

1. 1

   "Isso a gente já discutiu semana passada" · a frase se repete em toda reunião de coordenação. É o sinal mais direto — o próprio grupo já reconhece a recorrência, mas o ciclo não fecha.

2. 2

   BCF exportado uma vez e nunca reimportado · o arquivo .bcf ou .bcfzip é gerado no Navisworks ou Solibri, circula por e-mail e morre. Nenhuma ferramenta compartilhada acompanha estado de issue.

3. 3

   Disciplina afirma "já corrigi" mas o clash volta · a correção foi feita no viewer, ou no modelo mas sem reexportação para a federação, ou ainda sobre versão antiga que já foi substituída.

4. 4

   Reunião de 2 horas com ata vazia · atas de coordenação registram presença e "modelos analisados" mas não trazem lista de issues abertas/fechadas com responsável e prazo.

5. 5

   Relatório de clash com milhares de hits · Navisworks ou Solibri devolve 3000-8000 clashes sem categorização. Coordenador tenta triar manualmente, desiste, mostra 20 em reunião.

6. 6

   Coordenação sobre versão desatualizada · a federação usada na reunião não é a última publicada — cada disciplina rodou export próprio em data diferente, sem versão canônica no CDE.

7. 7

   Sem responsável nomeado por issue · o clash aparece como "arquitetura x estrutura" — mas quem, especificamente, corrige? Sem pessoa nomeada, ninguém age.

8. 8

   Sem prazo formal para correção · issues abertas há semanas sem data-limite. Ficam "em aberto" indefinidamente até serem redescobertas em nova rodada.

9. 9

   Nenhuma métrica de coordenação circula · ninguém reporta clash count semanal, taxa de fechamento, tempo médio de resolução ou taxa de recorrência. O processo é opaco.

10. 10

    Reabertura recorrente de itens · atas registram "reabertura de item da semana X" com frequência — mas sem análise de por que a correção anterior falhou.

11. 11

    "Vamos resolver em obra" · a equipe começa a tratar interferência conhecida como algo que "a construtora resolve" — sinal de que a coordenação BIM perdeu credibilidade interna.

12. 12

    Ferramenta de detecção presa a uma máquina · só uma pessoa da equipe roda Navisworks ou Solibri. Se ela falta, a coordenação para. Sem colaboração real, sem histórico compartilhado.

1. 1

   Clash detection sem workflow de issue · a equipe rodou clash detection em Navisworks ou Solibri, exportou lista em PDF/planilha, mas nunca implantou um workflow formal (BCF ou equivalente) que acompanhe o estado de cada issue do surgimento ao fechamento verificado.

2. 2

   Ferramenta de coordenação sem plataforma openBIM compartilhada · a ferramenta de detecção (Solibri, Navisworks) roda em máquina única. Sem uma plataforma openBIM compartilhada de issue tracking (BIMcollab, Catenda Hub, Dalux, ACCA usBIM.platform, BCF Server), cada rodada de coordenação parte do zero — não há memória entre ciclos, nem interoperabilidade entre disciplinas que usam ferramentas de autoria diferentes.

3. 3

   BCF exportado mas nunca reimportado · a equipe conhece o formato BCF e até exporta, mas o arquivo circula por e-mail como anexo estático. Nunca volta pra ferramenta como fonte de atualização de estado — vira lista morta.

4. 4

   Correção sem re-teste · a disciplina declara "corrigido" com base em ajuste visual, sem que o coordenador rode nova detecção sobre o modelo atualizado. Fechamento é ato de palavra, não de evidência.

5. 5

   Papéis não definidos no ciclo de vida da issue · não está claro quem identifica, quem triagem, quem atribui, quem corrige, quem verifica, quem fecha. Cada etapa vira responsabilidade difusa — na prática, ninguém.

6. 6

   Reunião de coordenação sem pauta formal · a reunião não segue estrutura padronizada (revisão de fechadas → triagem de novas → atribuição → prazos → impedimentos). Vira "olhar o modelo junto" e produz zero decisão formalizada.

7. 7

   Sem filtragem nem categorização de clash · o output cru da ferramenta (5000+ clashes) chega bruto na reunião. Sem separar hard clash de soft clash, clearance de workflow, o coordenador se afoga em falsos positivos.

8. 8

   Tolerâncias mal definidas por par de disciplinas · clash sinalizado quando arquitetura e estrutura se sobrepõem em 1 mm gera ruído. Sem tolerance calibrada por par (arq×est, arq×MEP, MEP×MEP), o número de hits é ingerenciável.

9. 9

   Federação sobre versões inconsistentes · cada rodada de coordenação roda sobre uma federação diferente — versões pescadas de e-mail, drives pessoais, não do CDE em estado Published. Correção feita sobre versão obsoleta reaparece na próxima.

10. 10

    Sem análise de causa raiz na reincidência · quando um clash volta, ninguém pergunta "por que a correção anterior não pegou?". A issue é reaberta e reatribuída — mas a causa que produziu a reincidência (arquivo errado, coordenação desatualizada, comunicação falha) segue ativa.

11. 11

    BIM Manager sem mandato para bloquear entrega · coordenação BIM é vista como formalidade, não como gate. Sem autoridade para segurar submissão até issues críticas fecharem, o processo perde tração.

12. 12

    Cultura de "resolve em obra" · a organização historicamente delega interferências para a fase de execução. Coordenação BIM é tolerada como custo contratual, não como prevenção — e a operação da coordenação reflete essa desvalorização.

1. 1

   Interferências físicas em obra · clash que "morreu" na coordenação BIM aparece como interferência real em campo — parede batendo em duto, viga cortando eletroduto, cobertura sem espaço para equipamento. Custo de correção em obra é tipicamente 10× a 100× o custo em projeto.

2. 2

   Retrabalho pago por conta de alguém · quando o clash não fechado explode em obra, a disputa contratual começa — quem deveria ter identificado, quem deveria ter corrigido, quem paga. Sem trilha de coordenação clara, todos saem perdendo.

3. 3

   Perda de confiança da equipe no BIM · a percepção interna vira "clash detection não funciona". A organização conclui, injustamente, que a metodologia BIM não entrega valor — quando o que não entregou foi a governança, não o BIM.

4. 4

   Reunião semanal drena horas sem contrapartida · 4 pessoas × 2h × 4 semanas = 32h/mês de reunião. Sem decisões formalizadas, sem métricas, sem fechamento — 32h/mês de custo direto sem retorno mensurável.

5. 5

   Rejeição contratual de entrega · contratante público ou grande privado pode rejeitar medição por interferências não fechadas em modelo publicado. BEP e contrato passam a exigir evidência de fechamento — sem workflow, sem prova.

6. 6

   BIM 5D contaminado · quantitativos extraídos de modelo com clash pendente refletem a interferência — parede modelada duplicada, duto atravessando viga, elementos sobrepostos. Orçamento e medição partem de dados errados.

7. 7

   Ativo entregue sem histórico rastreável · o handover para operação recebe modelos as-built sem registro das decisões de coordenação. Auditoria retroativa (perícia, sinistro, reforma) fica sem base documental.

8. 8

   Perda de janela barata de correção · clash detectado em fase de projeto se corrige com edição de modelo. Detectado em obra, exige demolição, refazimento, aditivos. A janela barata é curta — e o workflow que a captura foi o que falhou.

9. 9

   Disputa contratual entre disciplinas · sem trilha formal de "quem foi avisado, quando, com que evidência", cada disciplina acusa a outra. O BIM Manager vira alvo por não ter tido ferramenta ou mandato para exigir cumprimento.

10. 10

    Coordenação vira teatro contratual · a equipe começa a produzir "evidência de coordenação" sem coordenar de fato — atas fabricadas, listas produzidas para pasta contratual, reuniões cerimoniais. O produto do trabalho vira o registro do trabalho, não o resultado.

Todos os testes abaixo podem ser executados pelo próprio BIM Manager, coordenador de projeto ou contratante como diligência interna. Não exigem consultor externo nem ferramenta paga além do que já está em uso.

Item                        | Ata 1 | Ata 2 | Ata 3 | Ata 4 | Ciclos
-------------------------------------------------------------------------
Parede ARQ × viga EST L2    |   X   |   X   |   X   |       |   3
Duto MEP × forro ARQ L5     |   X   |   X   |       |   X   |   3
Eletrocalha × tubulação     |       |   X   |   X   |   X   |   3
...

Ciclo   | BCF exportado? | BCF reimportado? | Issues sincronizadas?
---------------------------------------------------------------
Sem 1   | Sim (25 issues)|      Não          |         Não
Sem 2   | Sim (28 issues)|      Não          |         Não
Sem 3   | Sim (34 issues)|      Não          |         Não

O problema é considerado resolvido quando todos os itens abaixo forem verdadeiros:

Curto prazo (30 dias — recuperar tração):

1. Adotar BCF 2.1+ como formato canônico de intercâmbio de issue. Mesmo com ferramentas pontuais (Navisworks, Solibri), configurar export/import em BCF em todos os pontos onde issues circulam. Nada de PDF, printscreen ou planilha como veículo de coordenação.

2. Escolher uma plataforma openBIM de issue tracking compartilhada. Critério canônico: aceita apenas plataformas que operem em formato aberto (BCF nativo, IFC como entrada) — evitar dependência de formato proprietário. Opções que atendem: BIMcollab (padrão de mercado consolidado), Catenda Hub (openBIM native, colaboração em tempo real), Dalux (forte em campo e handover, mobile-first), ACCA usBIM.platform (suite openBIM integrada), BCF Server (open source, se a equipe tem apetite técnico). Instalar, dar acesso, migrar issues abertas.

3. Definir workflow mínimo com estados verificáveis. Estados canonizados (adaptar ao vocabulário da ferramenta): New → Assigned → Resolved → Verified → Closed. Cada transição requer ação nomeada e deixa registro imutável.

4. Nomear responsáveis por etapa do ciclo. Publicar em uma página: quem identifica (auto: coordenador BIM roda detecção), quem faz triagem (coordenador + BIM Manager), quem atribui (BIM Manager), quem corrige (disciplina, pessoa nomeada), quem verifica (coordenador), quem fecha formalmente (BIM Manager). Substituto para cada papel.

5. Instituir reunião BIM semanal com pauta fixa. Duração 45-60 min (não 2h). Agenda obrigatória: (a) revisão de issues fechadas no ciclo com evidência; (b) triagem de novas issues com atribuição e prazo; (c) revisão de issues em atraso com plano; (d) impedimentos; (e) métricas da semana. Ata publicada no CDE em ≤ 24h.

Médio prazo (60-90 dias — governança sustentável):

6. Categorizar e calibrar tolerâncias por par de disciplinas. Definir tolerance por combinação (arq×est, arq×MEP, MEP×MEP, intra-disciplina) e por tipo de clash (hard clash, clearance, duplicate, workflow). Documentar no BEP. Meta operacional: relatório de clash cru ≤ 500 hits por rodada, após filtro.

7. Automatizar checagens repetitivas com IDS ou rulesets. Regras que podem ser verificadas objetivamente (ex.: "porta não pode colidir com pilar", "eletroduto respeita 25 cm de raio de curvatura") viram checks automatizados — não entram como clash manual em reunião. Solibri rulesets, IDS 1.0 do buildingSMART, custom rules em Navisworks.

8. Publicar dashboard semanal com KPIs de coordenação. Métricas canonizadas: clash count total, novas issues, issues fechadas, tempo médio de fechamento (horas ou dias), taxa de reincidência entre ciclos, backlog por disciplina. Reporta ao PMO e à diretoria — cria pressão positiva sem depender de fiscalização caso a caso.

9. Vincular reabertura de issue à análise de causa raiz. Quando um clash volta, o fluxo obriga registrar: por que a correção anterior não pegou? (arquivo não reexportado / correção sobre versão antiga / entendimento errado do escopo / tolerance mudou). Sem análise, sem fechamento na segunda vez.

10. Formalizar coordenação BIM como gate de entrega. BEP e contrato declaram: submissão de entrega para o cliente exige, além do checklist técnico, evidência de fechamento das issues críticas (severidade alta, hard clash) da última rodada. BIM Manager tem autoridade formal para segurar submissão.

1. 1

   BEP declara workflow BCF, ferramenta e papéis explicitamente · não basta citar "coordenação BIM". O BEP precisa detalhar: qual formato de intercâmbio (BCF 2.1/3.0), qual plataforma compartilhada, quais estados de issue, quem atua em cada etapa, qual é a frequência de reunião, quais métricas são reportadas.

2. 2

   Setup de ferramenta no kick-off, não na semana 4 · a plataforma de issue tracking é instalada, configurada e acessível a todas as disciplinas antes da primeira rodada de clash detection. Sem "vamos usando o e-mail enquanto o BIMcollab não chega".

3. 3

   Federação parte do CDE, sempre · a rotina de coordenação puxa os IFCs da última versão publicada no CDE (estado Shared ou Published). Nunca de e-mail, WeTransfer, drive pessoal ou "aquele arquivo que a Maria mandou terça".

4. 4

   Correção exige re-exportação e commit da disciplina · nenhuma issue é marcada como resolvida sem que a disciplina responsável publique o modelo corrigido no CDE. Correção no viewer, no chat ou "no meu Revit local" não conta.

5. 5

   Filtragem e categorização antes da reunião · coordenador chega na reunião com output já triado: hard clash / soft clash / clearance / workflow, filtrado por par de disciplinas, com tolerance calibrada. Nunca com 5000 hits crus.

6. 6

   Métricas visíveis semanalmente · dashboard atualizado toda semana com clash count, taxa de fechamento, tempo médio, taxa de reincidência. Métrica ruim gera conversa; ausência de métrica gera opacidade.

7. 7

   BIM Manager conduz com mandato formal · não é papel decorativo. Precisa ter tempo semanal reservado, autoridade para exigir cumprimento e para segurar submissão quando issues críticas estão abertas. Sem mandato, sem processo.

8. 8

   Cultura: "clash fechado é clash re-verificado" · nenhuma issue é fechada por palavra. Fechamento requer nova rodada de detecção sobre o modelo corrigido e evidência anexada à issue. Lema explícito em reunião de kick-off e reforço trimestral.

9. 9

   Onboarding do workflow para novo membro · todo profissional que entra no projeto passa por 30 minutos de guia: qual ferramenta, qual workflow, quais são seus estados de issue, o que significa cada um. Sem exceção.

10. 10

    Auditoria trimestral de aderência ao workflow · a cada 3 meses, auditor interno (ou externo) amostra 20 issues fechadas e verifica se o ciclo completo foi seguido — com evidências. Relatório publicado. Não é fiscalização punitiva, é higiene de processo.

• ISO 19650-1:2018Organização e digitização da informação — princípios. Base para coordenação como parte da gestão da informação.
• ISO 19650-2:2018Fase de entrega dos ativos. Detalha responsabilidades e ciclo de vida da informação — incluindo coordenação.
• NBR ISO 19650-1/2Adoção brasileira ABNT da ISO 19650, com particularidades para contratação pública e LGPD.
• buildingSMART BCF 2.1BIM Collaboration Format v2.1 — formato canônico de intercâmbio de issue entre ferramentas BIM. Suportado nativamente por plataformas openBIM (BIMcollab, Catenda Hub, Dalux, ACCA usBIM.platform, Solibri, BCF Server).
• buildingSMART BCF 3.0BCF versão 3.0 — evolução do formato, com suporte a extensões, referências a projetos, comentários enriquecidos. Adoção crescente.
• ISO 16739-1:2024Industry Foundation Classes (IFC). Base geométrica e semântica sobre a qual o clash detection opera.
• buildingSMART IDS 1.0Information Delivery Specification — regras verificáveis sobre IFC. Base para automatizar checagens que hoje viram clash manual.
• EN 17412-1:2020Level of Information Need (LOIN) — define expectativas de LOD/LOI que impactam diretamente o tipo de clash detectável em cada fase.
• BIM Fórum LOD SpecificationReferência internacional para escopo geométrico esperado por LOD (100, 200, 300, 350, 400). Fundamento para calibrar tolerance de clash por fase.
• CIC BIM Protocol (UK)Modelo de aditivo contratual que vincula coordenação e fechamento de issues às entregas. Referência internacional para redação contratual brasileira.