Gestão de Pendências, RFIs e Não Conformidades

A gestão de pendências, RFIs e não conformidades é uma camada de governança necessária para impedir que questões técnicas se dispersem entre e-mails, atas, mensagens, planilhas e documentos isolados. Em projetos, obras, contratos e comissionamentos, uma ocorrência só está efetivamente controlada quando possui origem identificável, classificação, responsável, prazo, vínculo com o objeto técnico, evidência de tratamento e critério de encerramento.

Pendência, RFI e não conformidade não são sinônimos. Uma pendência representa algo que precisa ser resolvido para que uma atividade, documento, entrega ou decisão possa avançar. Uma RFI — Request for Information formaliza uma dúvida, inconsistência ou necessidade de esclarecimento. Uma não conformidade registra o desvio entre uma condição observada e um requisito aplicável, seja ele de projeto, especificação, contrato, norma, procedimento ou critério de aceite. Misturar essas categorias reduz a capacidade de priorizar, analisar causa, responsabilizar e medir desempenho.

O problema também não se resolve apenas criando um formulário. A engenharia precisa definir quais eventos devem ser registrados, como são classificados, quem pode abrir, responder, aprovar ou encerrar cada item, quais documentos e ativos precisam ser relacionados, quais evidências comprovam a solução e em que situações a ocorrência deve ser escalonada. Sem essa arquitetura, o sistema pode acumular centenas de registros sem produzir controle real.

A solução deve, portanto, funcionar como um sistema de controle técnico: transformar ocorrências dispersas em registros estruturados, estabelecer responsabilidade e tempo de resposta, preservar a trilha de decisão e permitir que o encerramento seja sustentado por evidências verificáveis.

Condição observada	Risco ou limitação	Resposta de engenharia
Pendências registradas em múltiplas planilhas e canais	Perda de itens, duplicidade e ausência de visão consolidada	Cadastro único, identificador, taxonomia e vínculo com projeto, contrato, documento ou ativo
RFIs sem prazo ou responsável claro	Bloqueio de frentes, decisões informais e atraso acumulado	Workflow com ownership, SLA, escalonamento e rastreabilidade da resposta
Não conformidades encerradas apenas por declaração	Reincidência, aceite sem evidência e exposição contratual	Critério de fechamento, evidência objetiva e verificação de eficácia
Muitos itens vencidos tratados da mesma forma	Falta de foco sobre ocorrências realmente críticas	Classificação por criticidade, impacto, urgência, dependência e efeito no caminho crítico
Correções executadas sem preservar causa e decisão	Baixa capacidade de aprendizado e repetição de falhas	Registro de causa, ação, aprovação, evidência, lição aprendida e histórico

Arquitetura da solução

A arquitetura deve começar pela definição do objeto de controle. Em uma organização de engenharia, uma ocorrência pode estar relacionada a um projeto, contrato, ordem de serviço, disciplina, pacote de trabalho, documento, revisão, equipamento, sistema, fornecedor, inspeção ou marco de comissionamento. Esses vínculos não são meros campos cadastrais: permitem entender contexto, impacto, dependências e recorrência.

O segundo elemento é o estado do registro. Uma ocorrência normalmente percorre etapas como abertura, triagem, análise, resposta, execução da ação, verificação e encerramento. O fluxo precisa distinguir o que está aguardando informação, o que depende de decisão do cliente, o que está sob responsabilidade de fornecedor, o que bloqueia uma atividade e o que permanece aberto apenas para acompanhamento. Estados genéricos como “aberto” e “fechado” escondem informação operacional relevante.

Também é necessária uma camada de governança sobre papéis e autoridade. Quem identifica uma condição não necessariamente possui autoridade para definir a solução. Quem executa uma ação não deve, em situações críticas, ser a única pessoa responsável por confirmar sua eficácia. A segregação entre emissor, responsável, verificador e aprovador precisa refletir criticidade, impacto contratual e natureza técnica da ocorrência.

Critérios de classificação e priorização

Tipo, origem e requisito associado

A primeira decisão é classificar corretamente o evento. Uma RFI deve registrar qual informação está ausente ou conflitante e qual decisão depende da resposta. Uma não conformidade deve indicar qual requisito foi violado e qual evidência demonstra o desvio. Uma pendência deve deixar claro qual atividade, entrega ou decisão permanece incompleta. Essa distinção melhora relatórios, responsabilidades e critérios de encerramento.

A origem também precisa ser preservada. Inspeções de campo, revisões de projeto, reuniões, testes, FAT, SAT, auditorias documentais, comissionamento, medições e solicitações de mudança geram ocorrências com naturezas distintas. Registrar a origem permite analisar concentração de problemas por fase, disciplina, fornecedor ou tipo de atividade.

Criticidade, impacto e urgência

Prioridade não deve ser definida apenas por quem abriu o registro. A metodologia pode considerar segurança, conformidade, continuidade operacional, impacto em prazo, custo, qualidade, disponibilidade, risco contratual e dependências. Um item de baixo custo pode ser crítico se bloquear energização, teste integrado ou emissão de documentação necessária para o aceite.

A criticidade também precisa ser revisável. Uma pendência inicialmente secundária pode se tornar crítica quando se aproxima de um marco contratual ou quando passa a bloquear outras atividades. O sistema deve permitir reclassificação controlada, preservando quem alterou, quando alterou e qual justificativa sustentou a decisão.

Responsabilidade, prazo e escalonamento

Cada ocorrência precisa possuir um responsável por conduzir o tratamento, sem confundir esse papel com todas as pessoas envolvidas. Copiar dezenas de participantes não cria accountability. A arquitetura deve definir ownership, participantes consultados, aprovadores e partes que precisam apenas ser informadas.

Os prazos podem variar conforme tipo e criticidade. RFIs que bloqueiam obra ou fabricação exigem tratamento diferente de itens documentais de encerramento. Regras de aging, alertas e escalonamento permitem identificar itens que permanecem sem ação, respostas vencidas e ocorrências reincidentes. O objetivo não é apenas cobrar prazo, mas evitar que pequenos atrasos locais se acumulem e afetem o caminho crítico do empreendimento.

Fluxo de tratamento e tomada de decisão

Abertura e triagem

O registro inicial precisa conter informação suficiente para que outra pessoa compreenda o problema sem depender de contexto informal. Descrição objetiva, local, disciplina, documento de referência, requisito envolvido, evidências, impacto conhecido e solicitante são dados mínimos frequentes. Fotografias, trechos de documentos, desenhos marcados e resultados de testes podem complementar a ocorrência.

A triagem verifica duplicidade, classificação, competência do responsável e necessidade de contenção imediata. Em não conformidades que envolvem segurança, dano ao ativo ou risco de propagação, pode ser necessário interromper a atividade ou estabelecer uma ação de contenção antes mesmo de concluir a análise de causa.

Análise, resposta e aprovação

Uma resposta tecnicamente adequada não é necessariamente uma solução aprovada. Dependendo do contexto, a correção pode alterar projeto, especificação, método executivo, custo, prazo ou configuração do ativo. Nesses casos, a ocorrência deve se integrar aos mecanismos de controle de mudança, revisão documental e gestão contratual.

RFIs também precisam preservar a decisão produzida. Respostas dadas em reuniões ou mensagens devem ser formalizadas quando alteram interpretação de requisito, autorizam solução alternativa ou afetam outras disciplinas. A rastreabilidade protege tanto quem solicita quanto quem responde, porque permite recuperar a base da decisão no futuro.

Implementação e verificação de eficácia

Após a execução da ação, o registro precisa demonstrar o resultado. Uma fotografia pode ser evidência suficiente para determinadas correções físicas simples, mas é inadequada quando o requisito depende de medição, ensaio, cálculo, revisão de documento ou teste funcional. O tipo de evidência deve ser proporcional ao critério que se pretende comprovar.

Em não conformidades relevantes, o encerramento pode exigir verificação independente. Corrigir o sintoma sem eliminar a causa aumenta a probabilidade de reincidência. A análise deve avaliar se a ação foi aplicada apenas ao item observado ou se existem outras unidades, documentos ou sistemas sujeitos ao mesmo mecanismo de falha.

Integração com documentos, contratos e configuração

A gestão de ocorrências perde valor quando funciona isolada do restante da informação de engenharia. Uma RFI relacionada a um desenho deve apontar para a revisão correspondente. Uma não conformidade referente a um equipamento precisa estar associada ao ativo e ao requisito aplicável. Uma pendência contratual deve permitir identificar o pacote, fornecedor, entrega ou obrigação envolvida.

Esse vínculo reduz ambiguidades e permite impacto reverso. Se uma revisão documental altera a solução discutida em uma RFI, é possível identificar os registros relacionados. Se uma não conformidade exige alteração de projeto, a emissão do novo documento passa a ser parte da condição de encerramento. Se uma pendência impede comissionamento, ela deve aparecer na visão do sistema ou subsistema afetado.

Em ambientes digitais, integrações com GED, plataformas de projetos, sistemas de inspeção e ferramentas de gestão podem reduzir recadastramento. Entretanto, a automação só é útil quando a taxonomia, os papéis e os critérios estão definidos. Integrar processos mal estruturados apenas acelera inconsistências.

Indicadores, aging e análise de recorrência

A quantidade total de registros abertos é um indicador insuficiente. A governança precisa observar distribuição por criticidade, idade, responsável, disciplina, fornecedor, origem, tipo, etapa do projeto e condição de prazo. Um backlog estável pode esconder deterioração quando itens antigos e críticos permanecem sem solução enquanto ocorrências simples são fechadas rapidamente.

O aging ajuda a entender há quanto tempo cada item permanece em determinada condição. Quando combinado com SLA e criticidade, permite diferenciar atraso administrativo de risco real para o empreendimento. Tendências de reincidência e concentração também podem indicar falhas de processo, especificação incompleta, baixa qualidade documental, problema de fornecedor ou deficiência de supervisão.

Indicadores devem apoiar decisão, não apenas apresentação executiva. Se o relatório não muda priorização, alocação de recursos, escalonamento ou ação corretiva, provavelmente está medindo algo pouco útil. A solução deve estabelecer quais métricas acionam intervenção e quais servem apenas como histórico.

Ciclo de vida da solução

A implantação começa pelo diagnóstico do processo atual: onde as ocorrências surgem, em quais ferramentas são registradas, como são distribuídas, quais informações se perdem e como ocorre o encerramento. Em seguida são definidos taxonomia, papéis, estados, critérios de criticidade, SLA, regras de escalonamento, campos obrigatórios e evidências.

Depois da modelagem, o fluxo pode ser implantado em uma plataforma existente, no ENGiOS ou em sistema integrado ao ambiente digital da organização. A entrada em produção deve incluir migração criteriosa dos registros ativos, treinamento, definição de responsabilidades e monitoramento inicial. Importar indiscriminadamente históricos sem qualidade pode contaminar o novo processo com duplicidades e dados sem utilidade.

Na operação, a governança precisa revisar indicadores, categorias, tempos de resposta, gargalos e reincidências. Processos mudam com contratos, equipes e maturidade organizacional; por isso, workflow e taxonomia precisam possuir controle de versão e critérios para evolução.

Verificação, encerramento e evidências

O principal teste da solução é a qualidade do encerramento. Um registro não deve ser fechado porque “a equipe informou que resolveu”, mas porque a condição de aceite definida foi atendida. Isso exige compatibilidade entre o requisito original, a ação executada e a evidência apresentada.

Em projetos e obras, o fechamento pode depender de revisão aprovada, inspeção, medição, teste, relatório fotográfico, certificado, cálculo, atualização de desenho, aceite de responsável técnico ou conclusão de ação contratual. Em comissionamento, uma pendência pode migrar para punch list desde que critérios, responsável e prazo permaneçam controlados e que sua criticidade permita essa transição.

A auditoria da base deve conseguir reconstruir a história do item: quando surgiu, quem classificou, quem respondeu, quais decisões ocorreram, quais documentos mudaram, quais evidências foram apresentadas e quem autorizou o encerramento. Essa cadeia é especialmente importante quando a ocorrência possui impacto técnico, financeiro ou contratual.

Considerações de Engenharia

Fechar rápido não significa resolver bem

Metas de redução de backlog podem induzir encerramentos prematuros. A métrica precisa considerar qualidade, criticidade e reincidência, e não apenas quantidade de itens fechados.

Nem toda ocorrência exige análise de causa formal

Aplicar metodologias complexas a qualquer desvio aumenta burocracia. A profundidade da análise deve ser proporcional a risco, recorrência, impacto e criticidade.

RFI não deve substituir projeto ou controle de mudança

Uma resposta de RFI pode esclarecer informação, mas alterações materiais precisam chegar aos documentos e registros de configuração adequados. Caso contrário, a equipe passa a operar com decisões válidas apenas em mensagens ou sistemas paralelos.

A plataforma não corrige governança indefinida

Ferramentas conseguem automatizar estados, alertas e aprovações, mas não decidem sozinhas quem possui autoridade, qual evidência é suficiente ou quando um risco deve ser escalado. Essas regras pertencem à engenharia e à governança do empreendimento.

Aplicações e serviços que materializam a solução

A solução é aplicável a projetos multidisciplinares, fiscalização de obras, Owner’s Engineering, gestão de contratos, fabricação de equipamentos, inspeções, comissionamento, implantação de sistemas, operação assistida e manutenção. Quanto maior o número de partes envolvidas e de interfaces entre disciplinas, maior o risco de uma ocorrência desaparecer entre fronteiras organizacionais.

Quando o problema está na ausência de processo, o ponto de entrada pode ser um Diagnóstico e Otimização de Processos de Engenharia. Em organizações que precisam estruturar papéis, fóruns, critérios e responsabilidades de forma mais ampla, a solução se conecta à Estruturação da Gestão de Engenharia e à Governança Técnica e Estruturação de Technical Authority.

Durante implantação e encerramento de empreendimentos, a rastreabilidade das ocorrências também se relaciona ao Comissionamento de Equipamentos e à Auditoria Técnica de Data Book e Documentação Final de Engenharia, porque pendências, desvios, testes e evidências precisam convergir para um aceite tecnicamente defensável.

Modelo de contratação

A estruturação pode começar por uma avaliação do processo existente, amostragem de registros, entrevistas com as áreas envolvidas e análise das ferramentas utilizadas. O diagnóstico identifica lacunas de classificação, ownership, SLA, integração documental, critérios de fechamento e qualidade das evidências.

A partir desse levantamento podem ser definidos modelo de dados, taxonomia, matriz de criticidade, workflow, matriz de responsabilidades, regras de escalonamento, indicadores, dashboards e critérios de auditoria. Quando necessário, a engenharia pode apoiar a implantação na plataforma escolhida e acompanhar o período inicial de operação para ajustar gargalos e exceções.

O resultado esperado não é simplesmente um novo repositório de pendências, mas um processo em que cada ocorrência relevante possa ser rastreada desde sua identificação até a comprovação de que o requisito associado foi efetivamente atendido.