Entenda o que é BEP BIM, como estruturar um Plano de Execução BIM, diferenças entre BEP preliminar e confirmado e sua conexão com EIR, CDE, TIDP e MIDP.
Confira!
Um empreendimento pode contratar arquitetura, estrutura, elétrica, hidráulica e HVAC em BIM e ainda assim começar desorganizado. Todos podem usar softwares compatíveis e produzir modelos tridimensionais, mas, se ninguém tiver definido responsabilidades, coordenadas, estrutura de arquivos, estratégia de federação, regras de troca, marcos de entrega, critérios de revisão e ambiente de dados, a produção será digital sem necessariamente ser coordenada.
O BEP BIM — BIM Execution Plan, ou Plano de Execução BIM — é o plano que transforma requisitos de informação em uma forma acordada de trabalho para a equipe de entrega. Ele explica como a gestão da informação será conduzida: quem produz o quê, como os modelos e documentos serão organizados, como as informações serão trocadas e verificadas, quais tecnologias serão usadas, como ocorrerá a federação e quais responsabilidades sustentam cada entrega.
Na ABNT NBR ISO 19650-2, o BEP é tratado dentro do processo de gestão da informação da fase de entrega. Isso é importante porque evita uma interpretação comum, porém limitada: BEP não é uma lista de softwares nem um manual genérico de modelagem. Ele deve responder ao contexto, aos requisitos e à estrutura real de cada empreendimento.
O que é BEP BIM e qual problema ele resolve
A função do BEP é estabelecer como a equipe de entrega pretende atender aos requisitos de informação do empreendimento e como organizará sua própria produção para fazê-lo. Na prática, ele cria uma ponte entre aquilo que o contratante precisa receber e os métodos, responsabilidades e recursos que serão mobilizados pelas equipes para produzir essa informação.
Considere um exemplo. O contratante exige um modelo federado para uma revisão de projeto. Arquitetura utiliza uma origem de coordenadas, instalações elétricas outra e HVAC trabalha com um arquivo que foi deslocado manualmente para facilitar a modelagem. Todos os modelos existem; nenhum está necessariamente "errado" quando analisado isoladamente. Na federação, porém, eles não compartilham uma referência espacial confiável. O problema não é falta de BIM, mas falta de uma regra acordada antes da produção.
O mesmo vale para nomenclatura, versões, níveis de informação, formatos de troca, aprovação, uso do CDE e tratamento de interferências. Quando essas decisões são tomadas apenas depois que os problemas aparecem, a coordenação passa a funcionar de maneira reativa.
O BEP deve reduzir essa ambiguidade. Ele registra a estratégia da equipe e estabelece uma base comum para produção colaborativa, coordenação e entrega da informação.
Quais decisões o BEP precisa retirar da informalidade
Em muitos empreendimentos, as decisões mais críticas não estão ausentes: elas existem, mas estão espalhadas em reuniões, mensagens, hábitos de cada projetista e combinações verbais. O problema aparece quando uma equipe entende uma regra de um jeito e outra trabalha com uma premissa diferente. O BEP deve transformar essas combinações em critérios verificáveis.
| Decisão que costuma ficar implícita | Risco quando não é formalizada | Como o BEP deve tratar |
|---|---|---|
| Origem e sistema de coordenadas | modelos deslocados ou incompatíveis na federação | referência espacial oficial, unidades, ponto-base e procedimento de verificação |
| Responsável por cada elemento | duplicidade de modelagem ou lacunas de autoria | matriz de responsabilidades e limites de cada disciplina |
| Revisão válida para coordenação | clashes identificados em arquivos obsoletos | estado, revisão, data de corte e regra de publicação no CDE |
| Nível de informação esperado | modelo visualmente detalhado, mas insuficiente para a decisão | requisito de informação vinculado ao uso e ao marco de entrega |
| Formato e versão de troca | perda de propriedades ou geometria na interoperabilidade | formato, versão, parâmetros obrigatórios e teste de importação/exportação |
Um exemplo frequente ocorre na elétrica. A equipe modela eletrocalhas e quadros em uma disciplina, enquanto arquitetura reserva shafts e espaços técnicos em outra. Se o BEP não definir quem é responsável pela geometria de referência, quem valida os espaços e em qual marco cada modelo deve estar disponível para coordenação, um clash pode aparecer tarde demais. O software apenas revela uma decisão de interface que nunca foi formalizada.
BEP não substitui projeto, cronograma ou requisitos
O BEP se relaciona com outros instrumentos, mas não deve absorver funções que pertencem a eles. Os requisitos de informação definem o que precisa ser respondido ou entregue; o cronograma organiza o empreendimento no tempo; os projetos definem soluções técnicas; o BEP organiza como a equipe produzirá e gerenciará a informação necessária para essas entregas.
Por isso, um BEP robusto não é necessariamente um documento enorme. Seu valor está em tornar explícitas decisões que, se permanecerem implícitas, tendem a gerar retrabalho, incompatibilidades, duplicidade de informação e discussões sobre responsabilidade.
BIM sem regra comum ainda pode produzir descoordenação.
Modelos podem estar corretos de forma isolada e ainda falhar quando precisam ser federados, revisados ou entregues. O BEP cria uma base comum antes que a coordenação vire correção de problemas.
Veja como a Coordenação de Projetos organiza responsabilidades e interfaces
BEP preliminar e BEP confirmado: por que existem dois momentos
A ABNT NBR ISO 19650-2 posiciona o BEP em dois momentos diferentes do processo. Essa distinção é útil porque separa aquilo que a equipe propõe fazer daquilo que efetivamente será confirmado após a contratação.
BEP preliminar na resposta ao convite
Antes do compromisso, a potencial parte fornecedora líder estrutura um BEP preliminar como parte de sua resposta. Nesse momento, o documento deve demonstrar como a equipe pretende gerenciar a informação e se possui competência, capacidade, pessoas e infraestrutura compatíveis com o que está sendo solicitado.
A norma relaciona a esse BEP preliminar elementos como estratégia de entrega da informação, objetivos de colaboração, visão geral da estrutura da equipe, estratégia de federação, matriz macro de responsabilidades, métodos e procedimentos de produção da informação, padrões necessários e tecnologia prevista.
Isso transforma o BEP também em um instrumento de avaliação. Dois proponentes podem declarar que trabalham em BIM, mas apresentar abordagens completamente diferentes para coordenação, interoperabilidade, governança e entrega.
BEP confirmado após o compromisso
Depois da contratação, a equipe de entrega confirma e refina o BEP. Os nomes e funções são consolidados, a estratégia pode ser atualizada, métodos e procedimentos são confirmados, ajustes aos padrões de informação são acordados e a infraestrutura tecnológica é formalizada.
É também nessa etapa que o plano deixa de ser apenas uma proposta de abordagem e passa a se conectar diretamente a instrumentos operacionais de produção e entrega, como a matriz detalhada de responsabilidades, os TIDPs e o MIDP.
Essa evolução é essencial: um BEP não deveria ser congelado antes de a equipe real, os compromissos e as condições de produção estarem definidos.
| Aspecto | BEP preliminar | BEP confirmado |
|---|---|---|
| Momento | resposta ao convite ou processo de contratação | após o compromisso, com a equipe mobilizada |
| Objetivo | demonstrar abordagem, competência e capacidade para atender aos requisitos | governar efetivamente a produção e a gestão da informação |
| Responsabilidades | estrutura e matriz macro propostas | papéis confirmados e matriz detalhada de responsabilidades |
| Tecnologia | softwares, versões e infraestrutura previstos | ambiente e recursos efetivamente configurados e testados |
| Entrega da informação | estratégia e abordagem propostas | conexão com TIDPs, MIDP, marcos, revisão e aceite |
Essa diferença também é importante para o contratante. Um BEP preliminar bem estruturado permite avaliar se a proposta é tecnicamente coerente antes da contratação. Já o BEP confirmado deve permitir controlar se aquilo que foi prometido está efetivamente sendo aplicado. Assim, o documento deixa de ser apenas parte da proposta e passa a funcionar como referência de governança durante a execução.
O BEP preliminar demonstra capacidade; o BEP confirmado governa a execução.
A distinção evita tratar uma proposta de método como se já fosse a configuração definitiva do projeto. Pessoas, responsabilidades, padrões e recursos precisam ser confirmados após o compromisso.
O que deve conter um Plano de Execução BIM
Não existe uma lista universal capaz de substituir a análise do empreendimento. O conteúdo precisa ser proporcional ao escopo, aos requisitos e à complexidade da informação. Ainda assim, alguns grupos de decisão aparecem de forma recorrente em um BEP tecnicamente consistente.
| Bloco de decisão | O que precisa ficar claro |
| Objetivos e requisitos | quais usos da informação precisam ser atendidos e quais entregas são esperadas |
| Organização e responsabilidades | papéis, equipes de tarefa, responsáveis por modelos, documentos e gestão da informação |
| Estratégia de federação | como modelos e contêineres serão divididos, relacionados e integrados |
| Padrões de informação | convenções, nomenclatura, classificação, coordenadas, unidades, metadados e nível necessário de informação |
| Produção e coordenação | métodos de autoria, revisão, compatibilização, detecção e tratamento de interferências |
| Trocas e formatos | formatos nativos e abertos, versões, critérios de interoperabilidade e regras de importação/exportação |
| CDE e estados da informação | onde a informação será produzida, compartilhada, publicada e arquivada, e quem pode alterar cada estado |
| Tecnologia | softwares, versões, hardware, infraestrutura e ferramentas de coordenação |
| Entregas | marcos, responsáveis, critérios de revisão, autorização e aceitação |
O conteúdo do BEP precisa ser verificável
Um BEP pode parecer completo e ainda ser pouco útil se suas regras não puderem ser verificadas. Frases como “os modelos serão coordenados periodicamente”, “a nomenclatura seguirá padrão do projeto” ou “os arquivos serão compartilhados no CDE” são insuficientes quando não definem frequência, responsável, convenção, estado da informação ou critério de aceite.
Uma regra operacional deve permitir responder, no mínimo: quem executa, sobre qual informação, em que momento, por qual método e como se comprova que a atividade foi concluída. Se o plano disser que haverá coordenação semanal, por exemplo, deve ficar claro quais modelos entram no ciclo, qual é a data de corte, quem federa, como os apontamentos são registrados, qual prazo existe para tratamento e qual versão alimentará o ciclo seguinte.
O mesmo princípio vale para o nível necessário de informação. Pedir genericamente “LOD 300” para todas as disciplinas pode gerar excesso de modelagem em alguns elementos e falta de informação em outros. O BEP deve conectar a informação ao uso pretendido: coordenação geométrica, quantitativos, análise, planejamento, fabricação, construção, As-Built ou operação exigem dados diferentes e em momentos diferentes.
Estratégia de federação e responsabilidade precisam conversar
Um erro frequente é definir que haverá "modelo federado" sem estabelecer como os modelos serão decompostos e quem responde por cada parte. A federação não é apenas juntar arquivos em um visualizador. Ela depende de limites de autoria, referências espaciais, identificadores, responsabilidades e regras de atualização.
Se uma mesma informação é modelada por duas disciplinas sem definição de autoria, a federação pode revelar duplicidade — mas o problema já nasceu antes, na organização da produção.
Software não pode ser a estrutura do BEP
Revit, Civil 3D, Archicad, Tekla, Navisworks, Solibri e outras ferramentas podem fazer parte da estratégia tecnológica, mas um BEP que se resume a listar softwares não responde às questões de gestão da informação. A pergunta central não é "qual programa será utilizado?", e sim qual processo precisa funcionar e de que maneira a tecnologia o suportará.
Essa lógica também torna o BEP mais resiliente. Ferramentas podem mudar durante o ciclo do projeto; responsabilidades, requisitos, critérios de troca e objetivos de informação continuam precisando ser preservados.
O BEP deve ser proporcional ao risco e à complexidade
Nem todo empreendimento precisa de um documento com a mesma extensão. Um projeto com duas disciplinas, equipe conhecida e poucas entregas pode operar com um BEP mais enxuto. Já um empreendimento multidisciplinar, com vários contratos, plataformas diferentes, entregas faseadas e informação destinada à construção ou operação exige regras muito mais detalhadas.
A complexidade aumenta especialmente quando existem muitos pontos de interface: equipes externas, modelos produzidos em softwares distintos, coordenação por terceiros, dados destinados a orçamento ou planejamento, requisitos de segurança da informação, necessidade de modelos federados frequentes ou entrega final para gestão de ativos. Nesses casos, ambiguidades pequenas podem gerar efeitos em cadeia.
| Condição do projeto | Ênfase recomendada no BEP |
|---|---|
| Poucas disciplinas e equipe integrada | responsabilidades, referências, nomenclatura, CDE e marcos essenciais |
| Múltiplas disciplinas e projetistas independentes | federação, matriz de responsabilidades, coordenação, formatos e gestão de interfaces |
| Vários contratos ou fornecedores | requisitos de troca, governança, aceitação, TIDP/MIDP e controle de mudanças |
| Uso de BIM para obra, quantitativos ou planejamento | nível necessário de informação, qualidade dos dados, usos dos modelos e marcos de validação |
| Entrega para operação ou As-Built | estrutura de dados, classificação, requisitos do ativo, rastreabilidade e continuidade da informação |
Um bom BEP descreve processos, não apenas softwares.
Ferramentas suportam o trabalho, mas federação, responsabilidades, padrões de informação, revisão, troca e aceite precisam continuar claros mesmo quando a tecnologia muda.
Conheça a solução de Ambiente Comum de Dados e Gestão da Informação BIM
Como elaborar e implementar o BEP no projeto
A elaboração deve partir dos requisitos e das condições reais de entrega, e não de um template preenchido mecanicamente. Uma sequência prática pode ser organizada em seis etapas.
1. Ler os requisitos antes de definir o método
A equipe precisa compreender quais informações o contratante necessita, em quais pontos de decisão, com quais critérios de aceitação e em quais datas. Sem isso, o BEP corre o risco de padronizar processos que não respondem ao uso pretendido da informação.
2. Mapear equipes, papéis e entregáveis
Arquitetura, estrutura, elétrica, HVAC e demais disciplinas precisam ser relacionadas aos modelos, documentos e dados sob sua responsabilidade. A matriz macro pode começar nesse nível e ser posteriormente refinada em uma matriz detalhada.
3. Definir federação, referências e padrões
É necessário estabelecer divisão dos modelos, coordenadas, unidades, nomenclatura, classificação, convenções e regras mínimas de consistência. Essa etapa cria as condições para que as diferentes equipes consigam produzir separadamente e integrar informação sem reconstruir referências a cada ciclo.
4. Definir produção, revisão e troca da informação
O BEP deve explicar como a informação sai do trabalho em andamento, é revisada, compartilhada, coordenada, autorizada e entregue. Isso inclui CDE, formatos, interoperabilidade, revisão e tratamento de apontamentos.
5. Conectar responsabilidades a TIDP e MIDP
Na lógica da ISO 19650-2, cada equipe de tarefa estabelece seu TIDP — Task Information Delivery Plan, organizando os contêineres de informação que produzirá, responsáveis, dependências, nível necessário de informação, duração e datas de entrega. A parte fornecedora líder combina esses planos em um MIDP — Master Information Delivery Plan.
Esse é o ponto em que a estratégia do BEP se converte em planejamento concreto de entregas de informação.
6. Mobilizar, testar e ajustar
Antes de confiar o projeto inteiro a um fluxo novo, é recomendável testar software, infraestrutura, CDE, formatos, métodos de produção e trocas de informação. Um piloto simples pode revelar incompatibilidades de versão, perda de propriedades em exportações, coordenadas incorretas ou limitações de acesso antes que essas falhas se multipliquem.
Imagine descobrir no primeiro marco de coordenação que o IFC de uma disciplina perde propriedades essenciais exigidas pelo contratante. Descobrir isso depois de três meses de produção gera retrabalho; descobrir durante a mobilização permite corrigir o processo.
O BEP também precisa de controle de mudanças
Depois de aprovado, o BEP não deve ser tratado como documento imutável. Projetos mudam: novas disciplinas entram, responsabilidades são redistribuídas, versões de software são atualizadas, o contratante altera um requisito de informação e novos marcos podem ser introduzidos. O problema não é a mudança; é mudar a regra sem controlar o impacto.
Uma alteração aparentemente simples de versão de software, por exemplo, pode afetar compatibilidade de plugins, exportação IFC, formatos nativos e a capacidade de outra equipe abrir o arquivo. Alterar a estrutura de nomenclatura no meio do projeto pode quebrar filtros, automações e rastreabilidade no CDE. Trocar a responsabilidade por determinado modelo exige refletir a mudança na matriz e nos planos de entrega.
Por isso, o BEP deve possuir revisão controlada, responsável por aprovação, histórico de alterações e mecanismo de comunicação às equipes. Em projetos mais complexos, mudanças relevantes também precisam ser avaliadas quanto a impacto em prazo, custo, interoperabilidade, qualidade e entregas de informação.
Teste o fluxo antes de escalar a produção.
Mobilização e testes de troca podem revelar perda de propriedades, incompatibilidades de versão, falhas de coordenadas ou limitações do CDE antes que o problema contamine meses de produção.
Veja como a classificação da informação sustenta padrões consistentes em BIM
Como o BEP se conecta a EIR, CDE, TIDP, MIDP e coordenação BIM
O BEP ganha valor quando é entendido como parte de um sistema de gestão da informação, e não como documento isolado.
Uma forma simples de visualizar a relação é:
requisitos de informação → estratégia de execução no BEP → responsabilidades → TIDPs → MIDP → produção colaborativa → coordenação → revisão e aceite → entrega da informação.
O EIR — Exchange Information Requirements, quando aplicável ao compromisso, expressa requisitos de troca de informação da parte requerente. O BEP responde com a abordagem da equipe para atendê-los. O CDE — Common Data Environment fornece o ambiente governado para os contêineres de informação circularem entre estados. TIDP e MIDP transformam responsabilidades e marcos em planos de entrega.
| Instrumento | Pergunta principal que responde | Relação com o BEP |
|---|---|---|
| EIR / requisitos de troca | que informação o contratante precisa receber e sob quais critérios? | o BEP descreve a abordagem da equipe para atender aos requisitos |
| BEP | como a equipe organizará a gestão e a produção da informação? | estrutura pessoas, métodos, padrões, tecnologia e governança |
| TIDP | o que cada equipe de tarefa entregará, quando e por quem? | desdobra responsabilidades do BEP em entregas operacionais |
| MIDP | como as entregas das equipes formam o plano mestre de informação? | consolida os TIDPs e alinha dependências e marcos |
| CDE | onde e sob qual estado a informação é produzida, compartilhada e publicada? | materializa o fluxo de informação definido pelo processo |
Esses instrumentos não devem ser produzidos como documentos independentes que apenas coexistem. Se o BEP atribui à equipe elétrica a responsabilidade por determinado modelo, essa responsabilidade precisa aparecer no TIDP correspondente. Se o TIDP prevê uma entrega em determinada data, ela precisa ser compatível com o MIDP e com o marco em que outra disciplina depende daquela informação. Se o fluxo determina revisão antes do compartilhamento, o CDE deve suportar e registrar esse estado.
A coordenação BIM utiliza essa base para trabalhar com informação produzida segundo regras conhecidas. A compatibilização e o Clash Detection tornam-se mais eficientes quando os modelos têm autoria definida, coordenadas consistentes, versão controlada, finalidade conhecida e critérios claros de compartilhamento.
Exemplo: do requisito à reunião de coordenação
Suponha que o contratante precise validar, no fim de uma etapa, se as principais rotas de instalações cabem nos espaços técnicos previstos antes de liberar o detalhamento executivo. Esse é o objetivo de informação. A partir dele, o BEP precisa definir quais modelos participarão da federação, qual precisão geométrica é necessária, quais sistemas devem estar modelados, quais coordenadas serão usadas e qual revisão estará apta para coordenação.
O TIDP da elétrica pode prever a entrega do modelo de eletrocalhas e quadros até determinada data; HVAC terá sua própria entrega de dutos e equipamentos; arquitetura precisa disponibilizar shafts, forros e áreas técnicas antes desses modelos. O MIDP consolida as dependências e mostra que uma disciplina atrasada pode inviabilizar a revisão federada, mesmo que as demais estejam em dia.
No CDE, cada equipe publica a revisão indicada para compartilhamento. O coordenador federa somente essas versões, executa as verificações previstas, registra os apontamentos e devolve as questões às equipes responsáveis. No ciclo seguinte, os modelos corrigidos entram novamente no fluxo. Assim, a reunião de coordenação deixa de ser o lugar onde se descobre qual arquivo é o certo e passa a ser o momento de tomar decisões de engenharia sobre informação previamente organizada.
Esse exemplo mostra por que BEP, CDE, TIDP, MIDP e coordenação não são temas separados. Eles formam partes diferentes do mesmo sistema de produção e governança da informação.
Um BEP ruim pode existir e o projeto continuar sem governança
O documento perde valor quando é copiado de outro empreendimento, preenchido apenas para atender a uma exigência contratual ou escrito sem participação das equipes que executarão o trabalho.
Sinais frequentes de baixa maturidade incluem regras genéricas que ninguém aplica, responsabilidades sem responsáveis nominados, softwares incompatíveis, ausência de estratégia de federação, CDE tratado como simples pasta compartilhada, cronogramas de informação desconectados do projeto e critérios de aceite indefinidos.
| Sinal de um BEP fraco | Consequência provável | Ajuste necessário |
|---|---|---|
| template copiado sem adaptação | regras que não correspondem ao contrato ou à equipe | partir dos requisitos e do contexto real do empreendimento |
| responsabilidades genéricas | disputa sobre autoria, revisão e solução de interfaces | relacionar entregáveis, equipes e responsáveis de forma explícita |
| lista de softwares sem teste de troca | falhas de interoperabilidade descobertas durante a produção | definir formatos, versões e testes de mobilização |
| CDE tratado como pasta | perda de controle sobre revisão, estado e autorização | definir workflow, permissões, metadados e estados da informação |
| entregas sem critério de aceite | discussão subjetiva sobre o que significa “modelo concluído” | vincular requisitos, nível de informação e evidências de conformidade |
O teste mais simples é perguntar: se um novo projetista entrar hoje, o BEP permite entender como produzir, nomear, coordenar, revisar, compartilhar e entregar sua informação? Se a resposta depender de uma reunião para explicar tudo o que o documento não registra, o BEP ainda não está cumprindo sua função.
O BEP também deve se manter conectado à evolução do projeto. Mudanças de escopo, composição da equipe, estratégia tecnológica ou requisitos de informação podem exigir atualização controlada. Governança não significa imobilidade; significa que as mudanças são deliberadas, registradas e comunicadas.
BEP não deve terminar na assinatura do documento.
Seu valor aparece quando a estratégia se converte em responsabilidades, TIDPs, MIDP, produção colaborativa, coordenação e entregas verificáveis ao longo do projeto.
Conclusão
O Plano de Execução BIM é um instrumento de gestão da informação aplicado à execução do empreendimento. Seu valor não está em reunir terminologia BIM, mas em converter requisitos em responsabilidades, métodos, padrões, fluxos, tecnologia e entregas que possam ser efetivamente praticados pelas equipes.
Um BEP bem estruturado ajuda a evitar que várias disciplinas trabalhem em paralelo com regras incompatíveis e somente descubram as divergências na federação ou no aceite. Ele cria uma referência comum para produção, coordenação e entrega, conecta-se ao CDE, à matriz de responsabilidades, aos TIDPs e ao MIDP e pode ser testado já na mobilização.
Para contratantes e equipes de engenharia, a pergunta mais útil não é se o empreendimento "tem um BEP", mas se esse plano realmente permite governar a informação necessária para tomar decisões, coordenar projetos e receber entregáveis utilizáveis.
Referências técnicas
[1] ISO 19650-2:2018 — Information management using BIM — Part 2: Delivery phase of the assets.
[2] BIM Fórum Brasil — Coletânea Gerenciamento e Coordenação de Projetos em BIM.
Perguntas frequentes
BEP é o BIM Execution Plan, ou Plano de Execução BIM. Ele descreve como a equipe de entrega conduzirá a gestão da informação do empreendimento, incluindo responsabilidades, padrões, federação, métodos de produção, tecnologia, trocas e entregas.
Sim. BEP é a sigla internacional de BIM Execution Plan, traduzido no Brasil como Plano de Execução BIM.
Não existe uma obrigatoriedade universal para todo empreendimento. Sua exigência depende do contrato, dos requisitos do contratante e do modelo de gestão adotado. Quando a ISO 19650-2 é aplicada ao processo de gestão da informação, o BEP integra esse fluxo.
O EIR expressa requisitos de troca de informação da parte requerente. O BEP apresenta como a equipe de entrega pretende organizar pessoas, processos, padrões e tecnologia para atender aos requisitos aplicáveis.
O conteúdo varia conforme o projeto, mas normalmente inclui objetivos, responsabilidades, estratégia de federação, padrões de informação, coordenadas e nomenclatura, métodos de produção e revisão, CDE, formatos de troca, tecnologia, marcos e critérios de entrega.
O BEP preliminar é preparado antes do compromisso para demonstrar a estratégia, capacidade e abordagem da equipe. Após a contratação, o BEP é confirmado e refinado de acordo com as equipes, responsabilidades, padrões, métodos e recursos efetivamente adotados.
O TIDP planeja as entregas de informação de cada equipe de tarefa. O MIDP consolida esses planos no nível da equipe de entrega. Eles transformam responsabilidades e marcos em um planejamento operacional de contêineres de informação.
A tecnologia faz parte do BEP, especialmente versões, infraestrutura e interoperabilidade, mas o plano não deve ser estruturado apenas em torno de softwares. Processos, responsabilidades, requisitos e critérios de troca são mais importantes.
Sim, quando mudanças de escopo, equipe, requisitos, tecnologia ou processo alterarem a forma de produção e gestão da informação. As atualizações devem ser controladas e comunicadas às partes envolvidas.
Um bom teste é verificar se as equipes conseguem usar o documento para entender responsabilidades, padrões, federação, revisão, CDE, trocas e entregas sem depender de regras informais que só existem na memória de alguns participantes.
Materiais técnicos complementares
Soluções
- Ambiente Comum de Dados e Gestão da Informação BIM
- Gestão de Requisitos, Evidências e Critérios de Aceite
- Governança de Projetos
Serviços
Guias técnicos
- Guia Completo de BIM e Compatibilização de Projetos
- Guia Completo de Compatibilização de Projetos
- Gerenciamento de Projetos
Whitepapers
- Owner’s Engineering: framework executivo para contratação, governança e aceite
- Governança Técnica Digital para Empresas de Engenharia
- Contratação de Engenharia Consultiva com Rastreabilidade e Governança
Artigos técnicos
- Gestão da Informação em BIM: como aplicar a ISO 19650
- Classificação da Informação em BIM: como aplicar a NBR 15965
- Coordenação de Projetos de Engenharia
- Clash Detection em Projetos BIM
- Compatibilização de Projetos em BIM
eBook
