Entenda o que é EDMS em engenharia e como controlar documentos, revisões, status, workflows, transmittals, MDR, fornecedores, As-Built e handover técnico.
Confira!
Um EDMS (Engineering Document Management System) é um sistema especializado para controlar documentos e informações técnicas de engenharia ao longo do ciclo de vida de projetos e ativos. Diferentemente de um repositório de arquivos ou de um GED corporativo genérico, o EDMS precisa lidar com documentos que mudam continuamente, circulam entre diversas organizações e possuem impacto direto sobre projeto, fabricação, suprimentos, construção, comissionamento, operação e manutenção.
Em um empreendimento de engenharia, não basta saber onde um desenho está armazenado. É necessário saber qual é o documento correto, qual revisão está vigente, qual status possui, quem o emitiu, quem o revisou, para quem foi transmitido, quais comentários recebeu, quais documentos dependem dele e se a versão disponível está autorizada para a finalidade pretendida.
Por isso, EDMS e document control são conceitos fortemente relacionados. O sistema fornece a infraestrutura de informação; o processo de controle documental define regras, responsabilidades, fluxos e critérios para que documentos técnicos sejam produzidos, revisados, aprovados, distribuídos, substituídos e arquivados de forma rastreável.
Essa especialização é particularmente relevante em projetos multidisciplinares, contratos EPC/EPCM, plantas industriais, infraestrutura, utilities, edificações complexas, data centers, energia e empreendimentos brownfield. Nesses contextos, desenhos, memoriais, especificações, listas, folhas de dados, documentos de fornecedores, modelos BIM, relatórios de ensaio e registros de campo precisam permanecer coordenados mesmo quando dezenas de empresas e centenas ou milhares de documentos evoluem simultaneamente.
O EDMS também não deve ser tratado como sinônimo automático de GED, CDE, PDM ou PLM. Essas plataformas podem compartilhar funcionalidades, mas possuem responsabilidades e objetos de gestão diferentes. O ponto central do EDMS é a governança do documento técnico de engenharia e de suas trocas, com controle de revisão, estado, workflow, distribuição, histórico e evidência.
Em termos práticos, um EDMS transforma o acervo técnico de um projeto em uma base controlada de informação, reduzindo o risco de execução com documento obsoleto, perda de comentários, distribuição sem registro, divergência entre disciplinas e entrega final sem rastreabilidade.
O que um EDMS controla em um projeto de engenharia
O objeto de um EDMS não é apenas o arquivo digital. O sistema deve controlar o documento como unidade de informação técnica, mantendo sua identidade e seu histórico independentemente de quantas revisões, formatos ou transmissões ocorram.
Em engenharia, um mesmo documento pode passar por sucessivas emissões para revisão interna, aprovação do cliente, cotação, fabricação, construção, comissionamento e operação. O arquivo muda, mas a identidade documental precisa permanecer estável.
| Objeto controlado | Exemplos | Controles esperados |
| Desenhos | plantas, diagramas, detalhes, unifilares, P&ID | código, disciplina, revisão, status, emissão, histórico |
| Documentos textuais | memoriais, especificações, procedimentos, relatórios | autoria, aprovação, versão, distribuição, vigência |
| Listas técnicas | lista de cabos, I/O list, equipamentos, materiais, cargas | revisão, dependências, consistência com desenhos |
| Folhas de dados | instrumentos, equipamentos, componentes | fornecedor, comentários, aprovação, revisão |
| Documentos de fornecedores | desenhos de fabricação, manuais, certificados | submittal, retorno, código de aprovação, prazo |
| Modelos e informação BIM | modelos disciplinares, federados e entregáveis | identificação, revisão, estado, classificação, troca |
| Registros de obra | RFI, relatórios, inspeções, testes | vínculo com contrato, sistema, tag, evidência |
| Documentação final | As-Built, Data Book, O&M, handover | completude, revisão final, aceite, transferência |
A Gestão de Documentos de Engenharia precisa, portanto, tratar o documento técnico como parte de um processo de engenharia, e não como um arquivo isolado em uma pasta.
EDMS, GED, CDE, PDM e PLM: qual a diferença?
A sobreposição entre siglas gera especificações ruins. Plataformas diferentes podem oferecer recursos parecidos, mas isso não significa que seus objetivos sejam equivalentes.
| Ambiente | Foco predominante | Objeto principal | Onde se diferencia |
| GED / DMS | gestão corporativa de documentos | contratos, administrativos, fiscais, registros, arquivos digitais | abrangência geral, sem necessariamente compreender fluxos de engenharia |
| EDMS | gestão de documentos técnicos de engenharia | desenhos, especificações, listas, documentos de fornecedores, registros técnicos | revisão, emissão, transmittal, MDR, vendor document control e ciclo de vida técnico |
| CDE | produção e troca controlada de informação em processos BIM | contêineres de informação | estados, compartilhamento, publicação, coordenação e governança conforme ISO 19650 |
| PDM | dados de produto e engenharia de produto | CAD, componentes, BOM, versões de produto | relação entre dados de produto, peças e estruturas de engenharia |
| PLM | ciclo de vida do produto | produto, configuração, requisitos, mudanças e dados associados | integração ampla do ciclo de vida do produto |
| File server / cloud storage | armazenamento e compartilhamento | arquivos | normalmente não oferece governança documental suficiente por si só |
O artigo sobre Gestão Eletrônica de Documentos trata a disciplina documental de forma corporativa e geral. O EDMS aprofunda a situação específica em que o documento é parte do processo de engenharia e precisa permanecer coordenado com projeto, contrato, fornecedores, obra e ativo.
Também existe interseção entre EDMS e CDE BIM, mas não identidade. Um CDE é estruturado em torno do processo colaborativo de gestão da informação. Um EDMS pode hospedar ou suportar parte desse processo, mas pode igualmente controlar documentação técnica fora de um fluxo BIM.
Quando revisão, status e distribuição ainda dependem de pastas, e-mails e planilhas paralelas, o problema não é apenas armazenamento: falta uma arquitetura de document control conectada ao processo de engenharia.
A arquitetura do document control
O document control começa antes da plataforma. Um EDMS somente funciona de forma consistente quando existe um modelo documental capaz de responder como cada documento será identificado, classificado, revisado, aprovado e distribuído.
Os elementos estruturantes normalmente incluem:
- codificação e identificação única dos documentos;
- disciplinas, áreas, sistemas, unidades e pacotes de trabalho;
- tipos documentais;
- responsáveis pela elaboração, verificação e aprovação;
- revisão e histórico de revisão;
- status ou finalidade de emissão;
- workflow de revisão e aprovação;
- controle de distribuição;
- transmittals e submittals;
- comentários e respostas;
- vínculos entre documentos relacionados;
- controle de documentos de fornecedores;
- Lista Mestra ou Master Document Register;
- trilha de auditoria;
- regras de retenção e arquivamento;
- requisitos para handover e documentação final.
A ausência dessa arquitetura costuma produzir um efeito conhecido: a empresa adquire uma plataforma robusta, mas continua dependendo de planilhas paralelas, e-mails, nomes de arquivos e conhecimento informal para saber qual documento utilizar.
Identificação e codificação documental
A identidade do documento precisa ser estável e inequívoca. O código não deve mudar a cada revisão nem depender exclusivamente do nome do arquivo.
Em projetos de engenharia, a codificação pode incorporar campos como empreendimento, unidade, área, disciplina, tipo documental, sistema, sequência ou origem. A quantidade de campos depende da complexidade e do padrão do contratante.
Um código documental adequado deve permitir distinguir documentos sem depender da leitura de seu conteúdo. Entretanto, codificação não substitui metadados. Forçar toda a informação para dentro do nome do arquivo ou código cria identificadores excessivamente longos e difíceis de manter.
O EDMS deve associar ao identificador os metadados necessários para recuperar e interpretar o documento. Essa lógica é coerente com a ABNT NBR ISO 15489-1:2018, que trata metadados como elementos essenciais para preservar contexto, conteúdo, estrutura, relações e eventos que ocorrem ao longo da existência de um documento de arquivo.
Revisão, versão e status não são a mesma coisa
Uma das fontes mais frequentes de erro em controle documental é misturar conceitos diferentes.
Revisão identifica uma alteração formal do conteúdo técnico emitido. Versão pode representar estados intermediários de edição ou controle interno do arquivo. Status indica a condição ou finalidade na qual o documento se encontra dentro do workflow.
Um desenho pode, por exemplo, estar na revisão B e possuir status “emitido para aprovação”. Após comentários, pode continuar no mesmo ciclo de trabalho até que uma nova revisão formal seja emitida. Da mesma forma, um arquivo salvo como final_v7_agora_final.pdf possui versões informais, mas não um processo confiável de revisão documental.
| Informação | Pergunta respondida |
| Código | qual documento é este? |
| Revisão | qual evolução formal do documento está sendo utilizada? |
| Status | para qual finalidade esta emissão está autorizada? |
| Data de emissão | quando a revisão/status foi formalmente emitida? |
| Autor | quem produziu a informação? |
| Verificador | quem realizou a checagem técnica prevista? |
| Aprovador | quem autorizou a emissão ou uso? |
| Transmittal | em qual comunicação formal o documento foi distribuído? |
Separar essas dimensões reduz ambiguidades e permite reconstruir a história documental posteriormente.
O ciclo de vida de um documento dentro do EDMS
Embora cada organização possa adotar nomenclatura própria, um fluxo documental robusto costuma seguir uma sequência controlada:
- Criação ou recebimento — o documento recebe identidade, origem e metadados.
- Trabalho em andamento — a equipe desenvolve o conteúdo sob controle interno.
- Verificação — o documento passa por checagem técnica e documental.
- Aprovação — a autoridade definida valida a emissão.
- Emissão — revisão e status são formalizados.
- Transmissão — o documento é enviado às partes previstas por meio rastreável.
- Comentários e retorno — observações são registradas e relacionadas à emissão correta.
- Revisão — alterações geram nova emissão formal conforme regras definidas.
- Substituição — a revisão anterior deixa de ser vigente sem perder seu histórico.
- Arquivamento ou handover — a documentação final é preservada e transferida ao ambiente de operação.
O EDMS deve impedir que etapas formais sejam simuladas apenas por troca de e-mails. E-mail pode ser um canal de notificação; não deveria ser a única evidência de emissão, aprovação e distribuição em um projeto crítico.
Workflow de revisão e aprovação
O workflow traduz responsabilidades em transições controladas. Ele define quem pode criar, revisar, comentar, aprovar, rejeitar, emitir e encerrar documentos.
Nem todo documento precisa seguir o mesmo fluxo. Um desenho executivo pode exigir elaboração, verificação, aprovação interna e aceite do cliente. Um relatório de inspeção pode exigir elaboração e aprovação técnica. Um documento de fornecedor pode exigir análise multidisciplinar antes da devolução.
Um EDMS deve permitir configurar fluxos proporcionais ao risco e ao tipo documental. Um workflow excessivamente rígido gera burocracia; um workflow permissivo demais perde governança.
O desenho do processo deve estabelecer, pelo menos, responsáveis, sequência de atividades, critérios de avanço, prazos, estados possíveis, tratamento de rejeições, substituição de responsáveis e registro das decisões.
Transmittal: a evidência da troca documental
O transmittal é o registro formal de uma transmissão de documentos entre partes. Ele responde o que foi enviado, por quem, para quem, quando, em qual revisão e com qual finalidade.
Essa evidência é crítica quando existem disputas sobre versões vigentes, prazo de análise, recebimento ou obrigação contratual. Sem transmittal, a organização pode possuir o arquivo, mas não conseguir demonstrar em qual contexto ele foi oficialmente distribuído.
Em um EDMS, o transmittal deve estar relacionado aos documentos e revisões que compõem a emissão. O sistema pode também registrar destinatários, data, assunto, finalidade, resposta esperada, prazo contratual e confirmação de recebimento.
Lista Mestra e Master Document Register (MDR)
A Lista Mestra de Documentos, frequentemente estruturada em projetos como Master Document Register (MDR), consolida o universo documental previsto e seu estado de controle.
Ela não é simplesmente uma listagem dos arquivos já produzidos. Em projetos estruturados, o MDR pode funcionar também como instrumento de planejamento da documentação, permitindo acompanhar o que deveria existir, responsável, datas previstas, datas reais, revisão corrente e situação de cada entregável.
| Campo típico do MDR | Função |
| código do documento | identificação única |
| título | descrição do entregável |
| disciplina | agrupamento técnico |
| tipo documental | classificação |
| responsável | parte encarregada da produção |
| revisão atual | revisão formal vigente |
| status | condição da emissão |
| data planejada | compromisso de entrega |
| data real | desempenho da entrega |
| transmittal | rastreabilidade da emissão |
| retorno do cliente | acompanhamento da análise |
| próxima ação | controle do ciclo pendente |
Em ambientes simples, a Lista Mestra pode existir em planilha controlada. Em projetos de maior porte, o EDMS deve utilizar o MDR como estrutura viva de planejamento e controle, evitando a duplicação manual de dados entre planilhas, e-mails e repositórios.
Como o MDR possui função operacional própria — planejamento, acompanhamento de status e controle do universo documental — o tema merece aprofundamento específico e não precisa ser esgotado dentro da discussão sobre EDMS.
Vendor Document Control em contratos EPC e EPCM
A documentação de fornecedores cria uma camada adicional de complexidade. Equipamentos e sistemas podem gerar desenhos de fabricação, datasheets, certificados, curvas, manuais, procedimentos, relatórios de testes, listas de sobressalentes e documentação final.
Esses documentos não são apenas anexos do procurement. Eles podem condicionar projeto, interfaces, fabricação, inspeção, instalação, comissionamento e manutenção.
O vendor document control precisa controlar o ciclo de submissão e retorno. Dependendo do contrato, um documento pode ser recebido, distribuído para análise técnica, consolidado, devolvido com código de aprovação e posteriormente reapresentado pelo fornecedor.
O EDMS deve preservar a relação entre submittal → comentários → resposta → nova revisão → aprovação final. Quando esse fluxo é controlado apenas por e-mail, é comum perder comentários, misturar versões ou atrasar decisões porque não existe visibilidade central do que está pendente.
Comentários, markups e resolução de pendências documentais
Receber comentários não é suficiente; eles precisam ser controlados até a resolução.
Um processo robusto deve manter relação entre o comentário e a revisão analisada, identificar autor, disciplina, data, responsabilidade pela resposta, situação e evidência de fechamento. Comentários conflitantes entre disciplinas também precisam ser reconciliados antes da emissão seguinte.
Em documentos gráficos, markups podem complementar o fluxo, mas devem permanecer vinculados à revisão correta. Um PDF marcado sem referência à versão de origem pode se tornar uma evidência ambígua.
Esse princípio se aproxima do Engineering Change Management: toda mudança precisa preservar contexto, impacto, decisão e rastreabilidade.
EDMS e As-Built
O As-Built depende de document control ao longo da execução. Tentar reconstruir toda a documentação somente no encerramento transforma o fechamento em um exercício de arqueologia documental.
Durante a obra, revisões de projeto, RFIs, instruções de campo, alterações aprovadas, redlines, documentos de fornecedores, testes e liberações modificam progressivamente a condição que será entregue. O EDMS deve permitir identificar quais documentos alimentam a revisão final e quais mudanças ainda precisam ser incorporadas.
O Guia Completo de As-Built em Engenharia trata essa documentação final como resultado de um processo de levantamento, atualização, validação e aceite. O EDMS funciona como uma das infraestruturas de rastreabilidade necessárias para sustentar esse resultado.
No fechamento, a revisão As-Built precisa estar claramente distinguida das revisões anteriores, com documentos substituídos preservados no histórico e entregáveis finais associados ao processo de aceite.
EDMS, Data Book e handover
O Data Book consolida documentação necessária ao encerramento, qualidade, comissionamento e entrega do empreendimento. O EDMS, por sua vez, controla os documentos ao longo de sua produção e circulação.
Essa relação pode ser resumida como:
produção documental → controle de revisão → aprovação → emissão → evidências → revisão final → consolidação do Data Book → handover.
O Data Book de Obra não deve ser montado como uma coleta tardia de PDFs. Quanto maior a rastreabilidade ao longo do projeto, menor a necessidade de localizar, renomear, validar e reconciliar documentos no encerramento.
Em projetos de missão crítica, o handover deve também considerar a continuidade da informação após a desmobilização das equipes temporárias. Um EDMS de projeto pode precisar transferir informação para GED corporativo, CDE operacional, EAM/CMMS, sistema de gestão de ativos ou repositório definitivo do proprietário.
O que a ABNT NBR ISO 15489-1 acrescenta ao EDMS
A ABNT NBR ISO 15489-1:2018 não é uma norma específica de EDMS de engenharia. Sua contribuição está nos princípios de gestão de documentos de arquivo aplicáveis a qualquer ambiente tecnológico.
A norma estabelece conceitos relacionados à produção, captura e gestão de documentos, políticas, responsabilidades, controles, metadados e processos ao longo do tempo. Também caracteriza documentos de arquivo confiáveis por atributos como autenticidade, confiabilidade, integridade e usabilidade.
Esses atributos são altamente relevantes para um EDMS. Um desenho pode estar armazenado e ainda assim ser inadequado se não for possível demonstrar sua origem, revisão, integridade, contexto e relação com o processo que o produziu.
A norma também reforça que metadados registram contexto, estrutura, relações e eventos que ocorrem ao longo da vida do documento. Em um EDMS, isso sustenta a ideia de que histórico de revisão, aprovação, emissão e distribuição não é informação acessória: faz parte do valor documental.
ABNT NBR ISO 30301:2026 e o sistema de gestão
A ABNT NBR ISO 30301:2026, segunda edição brasileira, substituiu a edição de 2016 e trata dos requisitos para um Sistema de Gestão de Documentos de Arquivo (SGDA).
Sua aplicação é mais ampla do que um EDMS, mas oferece uma distinção importante: sistema de gestão não é sinônimo de software. A organização precisa estabelecer contexto, política, responsabilidades, objetivos, planejamento, recursos, controles operacionais, avaliação e melhoria.
Essa lógica é diretamente aplicável à implantação de EDMS. Comprar uma licença não implementa document control. O software precisa operar dentro de um sistema de governança que determine quais documentos devem existir, quais requisitos precisam atender e como seu desempenho será medido.
A edição brasileira de 2026 incorporou mudanças na determinação de requisitos de documentos de arquivo e nos requisitos operacionais de processos, controles e sistemas, reforçando a necessidade de projetar o ambiente documental a partir das necessidades da organização.
EDMS e CDE na ABNT NBR ISO 19650
A série ABNT NBR ISO 19650 trata da gestão da informação em processos BIM. Ela não define EDMS como produto, mas oferece requisitos particularmente úteis para compreender identificação, estados, revisão, compartilhamento, publicação e troca controlada de informação.
Na ABNT NBR ISO 19650-2:2022, versão corrigida 2 de 2025, o Ambiente Comum de Dados (CDE) deve suportar a produção colaborativa e controlar os contêineres de informação. Entre os elementos previstos estão identificador único, atributos de estado, revisão, classificação, transições entre estados, registro de usuário/data e acesso controlado.
A ABNT NBR ISO 19650-4:2025 aprofunda a troca de informação. Ela estrutura decisões para aprovar informação para compartilhamento e autorizar/aceitar informação para publicação, além de critérios relacionados a conformidade, continuidade, comunicação, consistência e completude.
Esses conceitos se aproximam de funcionalidades de EDMS, mas a fronteira deve ser preservada:
- CDE é o ambiente/processo comum para produção e troca controlada de informação segundo a lógica da ISO 19650;
- EDMS é a plataforma especializada de controle documental de engenharia e pode cobrir desenhos, relatórios, vendor documents, transmittals e documentação técnica mesmo fora de um processo BIM;
- uma plataforma pode desempenhar simultaneamente funções de EDMS e CDE, desde que os requisitos de cada processo sejam efetivamente atendidos.
Para projetos BIM, a Gestão da Informação conforme ISO 19650 deve ser especificada de forma integrada ao document control, evitando dois ambientes paralelos que produzam fontes de verdade conflitantes.
Requisitos funcionais de um EDMS
Uma especificação técnica não deve pedir apenas “sistema para armazenar documentos”. Os requisitos funcionais precisam traduzir o processo de engenharia em comportamentos verificáveis.
| Família | Requisitos típicos |
| Identificação | código único, título, disciplina, tipo, área, sistema, tags |
| Metadados | campos obrigatórios, listas controladas, validação, herança e busca |
| Revisões | revisão vigente, histórico, comparação, substituição e bloqueio |
| Status | estados configuráveis e finalidade de emissão |
| Workflow | revisão, aprovação, rejeição, delegação, prazos e escalonamento |
| Transmittals | emissão formal, destinatários, revisão enviada, confirmação e histórico |
| MDR | planejamento, situação documental, datas e responsáveis |
| Vendor documents | submittals, códigos de retorno, comentários e reapresentações |
| Comentários | marcações, respostas, responsáveis e fechamento |
| Busca | metadados, conteúdo, código, título, filtros e relacionamentos |
| Auditoria | eventos, usuários, datas, alterações, downloads e permissões |
| Distribuição | listas controladas, notificações e acesso externo |
| Arquivamento | preservação de revisões substituídas e documentação final |
| Integrações | API, BIM/CDE, ERP, EAM/CMMS, e-mail e autenticação corporativa |
| Exportação | documentos, metadados, histórico e estrutura de relações |
A matriz de requisitos deve indicar também quais funções são obrigatórias, desejáveis ou futuras e como cada uma será demonstrada no aceite.
Requisitos não funcionais também precisam ser especificados
Um sistema pode possuir todas as telas necessárias e ainda falhar operacionalmente. Requisitos não funcionais determinam se o EDMS conseguirá sustentar a criticidade do processo.
Devem ser considerados disponibilidade, desempenho de pesquisa e download, capacidade para arquivos grandes, escalabilidade, segurança, backup, recuperação, retenção de logs, segregação de ambientes, autenticação, gestão de identidade, criptografia, continuidade, integração, portabilidade e suporte.
Em projetos com modelos BIM, nuvens de pontos ou grandes pacotes de fornecedores, limites de tamanho, sincronização e desempenho de transferência tornam-se requisitos de engenharia de informação, não apenas detalhes de TI.
A portabilidade merece tratamento explícito. O contratante precisa saber como recuperar documentos, metadados, histórico, vínculos e trilhas de auditoria caso a plataforma seja substituída ou o contrato seja encerrado.
Segurança e controle de acesso
EDMS concentra informação potencialmente sensível: projetos de infraestrutura crítica, plantas, layouts, documentos de segurança, especificações de ativos, informações comerciais e registros contratuais.
O modelo de acesso precisa ser definido por necessidade e responsabilidade. Permissões excessivamente amplas anulam parte da governança; permissões restritivas demais dificultam o trabalho e incentivam cópias locais não controladas.
Um modelo consistente pode combinar organização, projeto, disciplina, função, tipo documental, área, nível de informação e etapa do workflow. A trilha de auditoria deve registrar eventos capazes de reconstruir alterações relevantes e acessos conforme o risco do ambiente.
A segurança também deve alcançar compartilhamentos externos. Links públicos permanentes, anexos enviados fora do ambiente controlado e downloads sem política podem criar cópias paralelas impossíveis de governar.
Migração de acervo para um EDMS
Migrar uma pasta compartilhada para o EDMS sem saneamento apenas transfere desorganização para uma plataforma mais sofisticada.
Antes da carga, convém identificar duplicidades, documentos sem autoria, revisões conflitantes, arquivos corrompidos, nomenclaturas inconsistentes, lacunas de metadados e documentos sem valor operacional.
A sequência recomendada é:
- Inventariar o acervo de origem.
- Definir classificação e metadados.
- Identificar duplicidades e conflitos.
- Estabelecer a condição documental vigente quando comprovável.
- Mapear os documentos para a nova estrutura.
- Executar uma carga piloto.
- Validar quantidade, integridade e metadados.
- Realizar a transferência controlada.
- Preservar evidências da transferência.
- Concluir a transição para a nova fonte de informação.
Documentos cuja condição não pode ser comprovada devem ser identificados como tal. O sistema não deve transformar incerteza documental em falsa aparência de confiabilidade.
Como especificar um EDMS em Termo de Referência
Um Termo de Referência para EDMS precisa começar pelo processo e não pelo produto. A organização deve definir o problema documental, os tipos de projeto, usuários, organizações externas, volumes, formatos, workflows, integrações e requisitos de segurança antes de escolher tecnologia.
Uma especificação robusta deve incluir pelo menos:
| Tema | O que definir |
| escopo | projetos, ativos, áreas e organizações atendidas |
| usuários | perfis internos, externos, fornecedores e administradores |
| documentação | famílias de documentos e formatos |
| governança | papéis, responsabilidades e regras de document control |
| codificação | identificação e metadados obrigatórios |
| workflows | revisão, aprovação, emissão, retorno e fechamento |
| MDR | estrutura, atualização e indicadores |
| fornecedores | vendor document control e submittals |
| segurança | autenticação, perfis, logs e compartilhamento |
| integrações | APIs e sistemas corporativos |
| migração | origem, saneamento, carga e validação |
| disponibilidade | desempenho, continuidade e recuperação |
| portabilidade | exportação de documentos e metadados |
| treinamento | administradores, document controllers e usuários |
| aceite | casos de teste, evidências e critérios mensuráveis |
A Governança Documental e Sistema de Gestão de Documentos deve orientar a especificação da plataforma. Inverter essa lógica e começar por uma lista de funcionalidades de fornecedor tende a produzir aderência parcial aos processos reais.
Critérios de aceite de uma implantação de EDMS
O aceite deve provar que o sistema e os processos funcionam juntos. Demonstrar telas não é suficiente.
Casos de teste devem reproduzir situações reais, como criar um documento, atribuir metadados, submeter para revisão, rejeitar, corrigir, aprovar, emitir, transmitir, substituir por nova revisão, pesquisar o histórico e exportar a trilha correspondente.
Para vendor documents, o teste pode simular submissão do fornecedor, distribuição multidisciplinar, consolidação de comentários, devolução com código de aprovação, reapresentação e encerramento.
Também devem existir testes de permissões, recuperação de backup, exportação, integrações, desempenho e portabilidade conforme o escopo contratado.
O aceite pode ser organizado em três camadas:
- Configuração — estrutura, metadados, perfis e workflows conforme requisitos.
- Processo — fluxos completos com resultados e rastreabilidade esperados.
- Operação — usuários, suporte, documentação e continuidade prontos para uso real.
Erros recorrentes na implantação de EDMS
Confundir EDMS com armazenamento em nuvem. Centralização sem revisão, workflow e rastreabilidade continua sendo armazenamento.
Copiar a estrutura de pastas antiga para a nova plataforma. O problema documental é preservado em vez de ser resolvido.
Usar revisão apenas no nome do arquivo. O sistema perde capacidade de governar a identidade do documento e seu histórico.
Controlar o MDR em planilha paralela. A lista mestra passa a divergir da base documental e exige reconciliação manual.
Tratar e-mail como transmittal. A comunicação pode existir, mas a emissão formal fica fragmentada e difícil de auditar.
Não controlar documentos de fornecedores. Parte relevante da engenharia fica fora da fonte de verdade do projeto.
Ignorar o handover. O projeto termina com documentação organizada para a equipe temporária, mas inadequada à operação do ativo.
Especificar a ferramenta antes do processo. A organização passa a adaptar sua governança às limitações do produto.
Não testar exportação e portabilidade. A dependência tecnológica só é percebida no encerramento do contrato.
EDMS como infraestrutura de governança da informação de engenharia
A principal função de um EDMS não é reduzir o número de pastas. É controlar a confiabilidade da informação técnica utilizada para tomar decisões e executar trabalho de engenharia.
Quando identificação, revisão, status, workflow, distribuição, MDR, vendor documents e histórico funcionam como um único sistema, a organização consegue saber o que deveria existir, o que existe, qual documento está vigente, quem precisa agir e quais evidências sustentam cada emissão.
Essa governança conecta projeto, procurement, execução, comissionamento e operação. O documento deixa de ser um arquivo administrativo e passa a ser tratado como um ativo de informação relacionado ao empreendimento e ao ativo físico.
Um EDMS bem especificado não elimina a necessidade de engenharia, document controllers ou gestão da informação. Ele cria a infraestrutura para que esses papéis operem com processos consistentes, rastreáveis e auditáveis.
Referências técnicas
[1] ABNT. ABNT NBR ISO 15489-1:2018 — Informação e documentação — Gestão de documentos de arquivo — Parte 1: Conceitos e princípios. Adoção nacional da ISO 15489-1:2016.
[2] ABNT. ABNT NBR ISO 30301:2026 — Informação e documentação — Sistemas de gestão de documentos de arquivo — Requisitos. Segunda edição brasileira, adoção da ISO 30301:2019.
[3] ABNT. ABNT NBR ISO 19650-2:2022 — Organização e digitização da informação sobre edifícios e obras de engenharia civil, incluindo BIM — Parte 2: Fase de entrega de ativos. Versão corrigida 2:2025.
[4] ABNT. ABNT NBR ISO 19650-4:2025 — Organização e digitização da informação sobre edifícios e obras de engenharia civil, incluindo BIM — Parte 4: Troca de informação. Adoção da ISO 19650-4:2022.
Perguntas frequentes
EDMS é a sigla de Engineering Document Management System, um sistema especializado em controlar documentos técnicos de engenharia, incluindo identificação, metadados, revisões, status, workflows, transmittals, documentos de fornecedores, histórico e documentação final.
GED é uma disciplina ampla de gestão eletrônica de documentos corporativos. EDMS especializa esse controle para engenharia, onde desenhos, especificações, listas, vendor documents e outros entregáveis passam por revisões, aprovações e emissões técnicas contínuas.
Não. CDE é o Ambiente Comum de Dados associado ao processo colaborativo de gestão da informação, especialmente na série ISO 19650. Um EDMS é especializado em document control de engenharia. Uma mesma plataforma pode atender ambos os papéis se cumprir os respectivos requisitos.
MDR, ou Master Document Register, é o registro mestre utilizado para planejar e controlar o universo documental de um projeto. Pode conter código, título, disciplina, responsável, revisão, status, datas planejadas e reais, transmittals e situação de análise.
Transmittal é o registro formal da transmissão de documentos entre partes. Ele identifica quais documentos e revisões foram enviados, por quem, para quem, quando e com qual finalidade, preservando evidência da distribuição.
Não. Revisão representa uma alteração formal do conteúdo técnico; versão pode representar estados intermediários do arquivo; e status indica a condição ou finalidade da emissão, como revisão, aprovação, construção ou registro final.
Não. CAD e BIM são ambientes de autoria e modelagem. O EDMS controla os documentos e entregáveis produzidos ou trocados, podendo integrar-se às ferramentas de autoria e ao CDE conforme a arquitetura de informação do projeto.
O aceite deve testar processos completos, não apenas funcionalidades isoladas. Devem ser verificados criação, metadados, workflow, aprovação, emissão, transmittal, revisão, pesquisa, auditoria, permissões, exportação, integrações, migração e continuidade conforme os requisitos contratados.
Materiais técnicos complementares
Soluções relacionadas
- Gestão de Documentos de Engenharia: GED, EDMS, revisões e rastreabilidade
- Governança Documental e Sistema de Gestão de Documentos
- Gestão de Requisitos, Evidências e Critérios de Aceite
Controle documental, execução e entrega
- Gestão Eletrônica de Documentos: conceitos, riscos e boas práticas
- CDE BIM: o que é um Ambiente Comum de Dados e como funciona na ISO 19650
- Gestão da Informação em BIM: como aplicar a ISO 19650
- MIDP e TIDP no BIM: planejamento e controle das entregas de informação
- Processos e Governança em Projetos de Engenharia
- Engineering Change Management (ECM) em Projetos de Engenharia
- Procurement em Projetos de Engenharia: etapas, critérios e gestão de fornecedores
- Projeto Executivo de Engenharia: detalhamento e entregáveis
- Data Book de Obra: estrutura, documentos e critérios de aceite
- Recebimento Provisório e Definitivo em Engenharia
- Encerramento de Projetos de Engenharia: termo de aceite e documentação final
- Operação Assistida em Engenharia: transição, estabilização e encerramento
- Guia Completo de As-Built em Engenharia
- Projeto As-Built em Engenharia
- ENGiOS — Plataforma de Gestão Técnica para Empresas de Engenharia