Aplicativo NCR com tarefas CAPA para rastrear defeitos até o encerramento

O que um processo NCR e CAPA realmente resolvem

Um relatório de não conformidade (NCR) registra algo que não atendeu a um requisito. Esse requisito pode ser um desenho, uma especificação, uma instrução de trabalho ou a expectativa do cliente. O objetivo não é culpar alguém, e sim capturar os fatos enquanto estão frescos para evitar que o mesmo problema se repita.

CAPA significa Ação Corretiva e Preventiva. É o que ocorre depois que o NCR é registrado: investiga-se por que aconteceu, corrige-se o problema imediato e coloca-se uma medida preventiva. Em um bom sistema, o NCR é o gatilho e a CAPA é o acompanhamento.

Juntos, NCR e CAPA ajudam em problemas práticos: capturar problemas de forma consistente, atribuir responsabilidades claras, concluir trabalhos no prazo com datas de vencimento, manter decisões rastreáveis e evitar repetição.

Os gatilhos comuns são fáceis de identificar quando você começa a procurá-los: uma reclamação de cliente, uma checagem em processo que falhou, uma rejeição na inspeção final ou um problema com fornecedor, como certificados de material errados. Mesmo quase-erros (near misses) merecem um NCR quando o custo de repetir o erro é alto.

Um exemplo simples: um lote falha em uma checagem dimensional. O NCR registra o número da peça, lote, medição, fotos e quem encontrou. A CAPA então atribui análise da causa raiz, ação corretiva (contenção e correção), prevenção (mudança de processo ou treinamento) e verificação antes do encerramento.

O que registrar em um NCR (campos que importam)

Um NCR é mais útil quando captura apenas o que ajuda alguém a tomar uma decisão: o que aconteceu, qual a dimensão do problema e o que fazer a seguir. Se o formulário parece um questionário, as pessoas vão pulá-lo ou escrever “ver e-mail”.

A maioria das equipes se sai bem com cinco grupos de campos:

• Identificação: fábrica ou linha, data/hora, reportante, turno e onde foi encontrado (recebimento, em processo, final, campo).
• Detalhes do item: produto, número da peça, revisão, fornecedor (se relevante) e lote.
• Detalhes do defeito: descrição em palavras simples, categoria, severidade/prioridade, quantidade afetada e como foi detectado.
• Contenção imediata: o que foi feito de imediato (segurar, separar, retrabalho, substituir), quem aprovou e onde o material suspeito está agora.
• Vínculos de rastreabilidade: PO, ordem de trabalho, pedido do cliente, números de série apenas quando realmente necessários.

Anexos importam mais que textos longos. Uma foto de uma carcaça trincada, mais a nota de inspeção mostrando uma medição fora da tolerância, pode poupar horas depois. Para problemas com fornecedores, inclua o documento do fornecedor ou certificado como upload.

Exemplo: um inspetor de recebimento sinaliza 12 unidades do lote B-104. O NCR registra o PO, revisão da peça, severidade “alta” e contenção “segurar na prateleira de quarentena Q2”. Isso já é suficiente para que o próximo responsável inicie a análise da causa raiz sem correr atrás de contexto.

Mapear um NCR simples para o fluxo CAPA antes de construir

Antes de criar telas, concorde com um fluxo simples que todos possam seguir. Um fluxo claro evita dois problemas comuns: NCRs que ficam parados e CAPAs abertas para cada pequeno problema.

Comece com um conjunto pequeno de status que reflitam como o trabalho realmente avança, por exemplo: Rascunho, Enviado, Contenção, RCA, CAPA, Verificação, Encerrado. Mantenha nomes familiares para que operadores, qualidade e gestores os interpretem da mesma forma.

Decida quem pode mover um NCR para frente e torne as regras explícitas. Por exemplo: o reportante pode salvar e enviar; qualidade pode aceitar e encaminhar; produção pode completar tarefas de contenção; qualidade de fornecedor pode conduzir RCA de fornecedor; e a gestão pode aprovar encerramentos de alto risco.

Adicione algumas “portas” para garantir que as informações certas existam antes de mudanças de status. Mantenha o mínimo, mas seja estrito onde importa:

• Não inicie a RCA até que a contenção esteja registrada (o que foi colocado em quarentena, retrabalhado e o que é seguro para enviar).
• Não inicie a CAPA até haver uma declaração de causa raiz com evidências, não apenas sintomas.

Decida também quando abrir CAPA versus encerrar como um problema menor. Uma regra simples funciona bem: abra CAPA se o defeito for repetido, impactar cliente, envolver segurança ou ser sistêmico no fornecedor. Se for um caso isolado e totalmente contido com baixo risco de recorrência, encerre com uma justificativa curta.

Planeje aprovações cedo. Muitas equipes usam uma cadeia leve: qualidade aprova o registro do NCR, produção confirma viabilidade, qualidade de fornecedor confirma compromissos do fornecedor e a gestão assina o risco e o encerramento.

Papéis, propriedade e permissões que as pessoas vão aceitar

Se as pessoas não confiarem nos papéis e regras, elas vão contornar o sistema. Mantenha simples: um proprietário claro para cada NCR e tarefas que possam ser delegadas sem perder responsabilidade.

Um modelo prático de papéis:

• Reportante: registra o defeito e evidências.
• Proprietário da qualidade: assume o NCR de ponta a ponta e decide os próximos passos.
• Atribuídos: completam passos de análise da causa raiz e tarefas de ação, e anexam provas.
• Aprovador: assina portas chave como contenção, ações e encerramento.
• Visualizador: acesso apenas leitura para gestores, auditores ou outras equipes.

Mantenha a propriedade com uma pessoa (frequentemente Quality). Deixe que ela reatribua tarefas, mas evite reatribuir o próprio NCR, a menos que haja uma razão forte. Isso facilita responder perguntas de auditoria depois.

As permissões devem refletir o trabalho real:

• Após a submissão, o reportante não pode editar fatos centrais (data, produto, tipo de defeito), mas pode adicionar comentários.
• Só o proprietário da qualidade pode mudar status, prazos e disposição.
• Atribuídos podem editar apenas suas próprias tarefas, não o NCR inteiro.
• Aprovadores podem aprovar ou rejeitar, e devem comentar ao rejeitar.

Um rastro de auditoria não é opcional. Registre quem mudou o quê e quando para status, prazos, atribuições e campos chave. Capture o “por quê” para mudanças sensíveis, como mover um prazo.

Para fornecedores e partes externas, mantenha o acesso simples: ou dê acesso limitado apenas às tarefas que lhes foram designadas, ou use um procurador interno (geralmente Supplier Quality) que registre as atualizações do fornecedor.

Passo a passo: construa as telas e dados centrais do NCR

Comece pelos dados. Se as tabelas estiverem claras, as telas ficam mais fáceis.

Um conjunto prático de objetos é: NCR (o relatório), Item NCR (o que falhou, onde e quantos), Tarefa (trabalho a ser feito), Comentário (discussão) e Anexo (fotos, PDFs, medições). Um NCR geralmente tem muitos itens, tarefas, comentários e arquivos. Tarefas devem sempre apontar de volta ao NCR para que as pessoas possam ir do trabalho ao contexto em um clique.

Construa os dados e telas principais

Uma ordem simples de construção:

• Crie objetos: NCR, Item NCR, Tarefa, Comentário, Anexo.
• Adicione relacionamentos: NCR -> Itens/Tarefas/Comentários/Anexos (um-para-muitos).
• Construa três telas: Lista de NCR (filtros + busca), Criar NCR (formulário curto), Detalhes do NCR (tudo em um lugar).
• Adicione proteções para ações de status (por exemplo, bloquear “Em revisão” até que haja pelo menos um Item NCR).
• Permita criação e atribuição de tarefas a partir da página de Detalhes do NCR.

Mantenha Criar NCR curto. Capture apenas o necessário para iniciar o trabalho: número da peça, descrição do defeito, local, severidade, detectado por, data. Preencha o restante na página de Detalhes.

Adicione mudanças de status e validações

Use regras de fluxo de trabalho para controlar mudanças de status com checagens básicas. Quando alguém submeter, valide campos obrigatórios, defina o status e registre o horário de submissão. Quando alguém encerrar, confirme se todas as tarefas obrigatórias estão completas e se as notas de encerramento estão presentes.

Exemplo: um operador registra um NCR por carcaças riscadas. O supervisor abre o NCR, adiciona duas tarefas (contenção e investigação), atribui responsáveis e anexa uma foto. O registro permanece legível porque tarefas, comentários e arquivos vivem sob o mesmo NCR.

Tarefas de análise da causa raiz que levam a respostas reais

A análise da causa raiz falha quando é tratada como uma única caixa de texto. Um padrão melhor é um pequeno conjunto de tipos de tarefa RCA repetíveis, cada um com um resultado claro que outra pessoa pode verificar.

Escolha de 3 a 5 tipos de tarefa RCA que cubram a maioria dos defeitos e mantenha-os consistentes:

• Resumo 5 Porquês (cadeia curta mais o porquê final)
• Rascunho de diagrama de espinha de peixe (pessoas, método, máquina, material, ambiente, medição)
• Checagem de dados (medições, histórico de lotes, resultados de testes)
• Revisão de processo (passo a passo, onde pode falhar)
• Declaração do operador (o que foi observado, quando, em quais condições)

Escreva tarefas que possam ser marcadas como feitas ou não. “Investigar problema” é vago demais. “Confirmar faixa de torque usada no Lote 24 e anexar o log de torque” é verificável.

Exija evidência em cada tarefa RCA, seja um anexo ou uma nota curta. Depois mantenha um campo estruturado “Causa raiz” que force clareza, por exemplo: Causa (o que falhou), Porquê (o que permitiu) e Prova (qual evidência sustenta).

Adicione uma porta que impeça ações prematuras: a RCA deve ser aprovada antes do início das tarefas CAPA.

Um teste útil: se alguém novo puder seguir a evidência e reproduzir o raciocínio, a RCA está cumprindo seu papel.

Tarefas CAPA: ações corretivas, prevenção, verificação, encerramento

Ações corretivas e preventivas parecem semelhantes, mas na prática são diferentes. Ação corretiva remove a causa deste problema específico (corrigir agora). A ação preventiva reduz a chance de repetição em produtos, linhas ou locais.

Mantenha ações corretivas e preventivas separadas no seu app NCR/CAPA. Caso contrário, as equipes fecham a CAPA com um remendo rápido e o problema repete no mês seguinte.

Os campos que tornam ações reais

Escreva cada ação de modo que uma pessoa nova possa executá-la sem adivinhar. Alguns campos são suficientes:

• Proprietário da ação (uma pessoa responsável)
• Data de vencimento (e uma razão se mudar)
• Critérios de aceitação (o que significa “feito”)
• Prova exigida (foto, resultado de teste, documento atualizado, registro de treinamento)
• Área impactada (produto, etapa do processo, fornecedor, cliente)

Verificação e efetividade (etapas que a maioria das equipes pula)

Verificação é a checagem imediata: fizemos o que dissemos e atende aos critérios de aceitação? Atribua um verificador que não seja o proprietário quando possível, e torne a prova obrigatória.

Revisão de efetividade vem depois: a mudança se manteve ao longo do tempo? Defina uma janela baseada no risco, frequentemente 30 a 90 dias. Por exemplo, se o NCR foi “rótulos borrando após embalagem”, a efetividade pode ser “zero borrões nos últimos 500 unidades” ou “nenhuma reclamação de cliente em 60 dias”.

O encerramento deve ser regra, não sentimento. Encerre apenas quando todas as ações estiverem verificadas, a revisão de efetividade estiver concluída (ou formalmente dispensada com uma razão) e as aprovações exigidas estiverem registradas.

Prazos, lembretes e escalonamento sem incomodar

Prazos só funcionam quando parecem justos. Se toda tarefa vence “amanhã”, as pessoas deixam de confiar no sistema e começam a ignorá-lo. Defina padrões sensíveis por severidade e permita que os proprietários ajustem com uma razão clara.

Um ponto de partida simples que muitas equipes aceitam:

• Crítico: contenção em 24 horas, RCA em 3 dias, CAPA em 14 dias
• Major: contenção em 3 dias, RCA em 7 dias, CAPA em 30 dias
• Minor: contenção em 7 dias, RCA em 14 dias, CAPA em 60 dias

Mantenha lembretes discretos e previsíveis: uma mensagem alguns dias antes do vencimento e outra na data de vencimento. Se uma tarefa já está “em progresso” com um comentário, evite lembretes diários.

O escalonamento deve evitar risco parado, não envergonhar pessoas. Mantenha vinculado à ação:

• Notificar o proprietário do NCR quando uma tarefa tiver 2 dias de atraso
• Notificar o gerente do proprietário da tarefa aos 7 dias de atraso
• Exigir nova data de vencimento e uma razão para continuar
• Bloquear encerramento até que a verificação exigida esteja completa

Para evitar um backlog silencioso, torne “atrasado” difícil de ignorar. Mostre contagens de tarefas vencidas na tela inicial de cada papel: proprietários de tarefas veem as suas, proprietários de NCR veem tudo pelo qual são responsáveis.

Também monitore tempo de ciclo para melhorar o processo, não apenas perseguir datas: submetido até contido, contido até RCA, e RCA até encerramento.

Painéis e trilhas de auditoria para controle diário

Um bom painel faz o sistema parecer calmo. As pessoas veem o que precisa de atenção hoje, e os gestores detectam risco antes que vire um achado de auditoria.

Comece com uma lista de NCR que qualquer um possa usar rapidamente, com filtros consistentes entre telas. Filtros comuns incluem status, severidade, produto/área de processo, fornecedor (se aplicável) e proprietário atual.

Depois adicione uma visão do gestor que responda três perguntas: O que está atrasado? O que está ficando velho? O que está se repetindo? Blocos úteis são tarefas RCA e CAPA vencidas, NCRs envelhecidos (por exemplo, abertos há mais de 30 dias) e principais categorias de defeito por contagem e severidade. Se você só puder acompanhar uma tendência, acompanhe questões recorrentes por categoria e linha de produto.

Trilhas de auditoria devem ser nativas. Para cada NCR e item CAPA, capture um histórico do que mudou, quem mudou e quando. No mínimo, registre mudanças de status (incluindo reaberturas), aprovações, comentários e anexos, alterações de prazo (com razão) e reatribuições de proprietário.

Para relatórios mais limpos e auditorias mais fáceis, use listas controladas para severidade, categoria do defeito, método de causa raiz e disposição. Texto livre ainda importa, mas não deve ser a única fonte de verdade.

Exemplo: um defeito desde a descoberta até CAPA encerrada

Um inspetor de recebimento encontra que 12 de 200 suportes de inox têm rebarbas em uma aresta que podem cortar um operador. Ela registra um NCR, adiciona fotos, o número do lote do fornecedor e marca como risco de segurança.

O líder de qualidade revisa no mesmo dia e decide a contenção: colocar o lote em quarentena, parar a ordem de trabalho que usa os suportes e avisar produção e compras. Uma nota curta sai para o chão: “Não usar lote L-4821. Peças na área de Hold A.”

A análise da causa raiz começa como um pequeno conjunto de tarefas com proprietários claros:

• Revisar registros de inspeção de recebimento das últimas 3 remessas (Técnico de Qualidade, vencimento Qua)
• Pedir ao fornecedor o histórico de mudanças de processo e último log de manutenção de ferramenta (Comprador, vencimento Qui)
• Sessão 5 Porquês com QC e recebimento, registrar uma declaração de causa raiz (Líder de Qualidade, vencimento Sex)

Na sexta, a equipe concorda com a declaração de causa raiz: “O fornecedor mudou a roda de desbaste e pulou a checagem da primeira peça, permitindo que rebarbas passassem sem detecção.”

Tarefas CAPA são atribuídas com prazos e evidências esperadas:

• Corretiva: fornecedor atualiza o checklist de primeira peça e treina operadores (Supplier QA, vencimento +7 dias, anexar registro de treinamento)
• Preventiva: adicionar checagem de gabarito no recebimento para altura de rebarba em suportes (Líder de Qualidade, vencimento +10 dias, anexar instrução de trabalho atualizada)
• Verificação: inspecionar os próximos 3 lotes com amostragem mais rigorosa e registrar resultados (Inspetor de Recebimento, vencimento +30 dias, anexar logs de inspeção)

O encerramento acontece apenas após a verificação passar. O aprovador marca a CAPA como “Efetiva”, anexa o relatório final de inspeção e o checklist assinado do fornecedor, e encerra o NCR com um rastro de auditoria claro.

Erros comuns ao configurar rastreamento NCR e CAPA

O maior erro é tornar o registro tão difícil que as pessoas param de reportar. Se seu formulário de NCR pede a história completa da causa raiz desde o início, você terá entradas incompletas ou nada. Mantenha o primeiro passo focado no que aconteceu, onde, quando e quem notou. Adicione detalhes profundos depois como tarefas.

Em segundo lugar vem a propriedade. Quando um NCR é atribuído para “a equipe”, geralmente significa “ninguém”. Cada registro precisa de um proprietário nomeado em cada etapa, mesmo que várias pessoas contribuam.

Regras confusas criam caos. Se severidade for um sentimento, defeitos similares são tratados de formas diferentes e auditorias ficam bagunçadas. Defina níveis de severidade com exemplos simples e seja explícito sobre quando CAPA é necessária (problemas repetidos, impacto no cliente, risco de segurança ou quebra de processo).

Alguns erros que silenciosamente quebram o rastreamento NCR/CAPA:

• Permitir que usuários encerrem investigação ou tarefas de ação sem evidência.
• Misturar ações corretivas e preventivas de modo que não seja possível distinguir o que consertou hoje do que evita repetições.
• Definir prazos sem lembretes ou escalonamento, permitindo que ações atrasadas se tornem norma.

Outra falha comum é encerrar itens com base na atividade, não em resultados. “Ação concluída” não é o mesmo que “efetividade verificada”. Torne a verificação uma etapa obrigatória com resultado claro de passou/falhou.

Checklist rápido e próximos passos para começar a construir

Um aplicativo NCR simples com tarefas CAPA funciona melhor quando cada registro responde: o que aconteceu, quem é o responsável, o que vence a seguir e qual prova mostra que foi corrigido.

Mantenha seu primeiro build focado:

• Essenciais do NCR: descrição do defeito, produto/lote, data encontrada, local, reportante, severidade, contenção imediata
• Fluxo de status claro: Novo, Em revisão, RCA em progresso, CAPA em progresso, Verificação, Encerrado
• Propriedade e prazos: um responsável por etapa, com prazos visíveis
• Evidências e aprovações: fotos/arquivos, notas de investigação, campos de aprovação, assinatura de encerramento
• Rastreabilidade: vínculos entre NCR, tarefas RCA, ações e resultados de verificação

Comece pequeno com um piloto em uma linha, um site ou uma família de produtos por 2 a 3 semanas. Você vai aprender quais campos as pessoas pulam, quais status as confundem e onde as entregas travam.

Decida cedo onde o app vai rodar. Nuvem costuma ser mais rápido para um piloto. Exportar código-fonte ou self-hosting pode servir a times com regras rígidas de TI ou dados, mas é mais fácil se decidir isso antes de travar notificações e regras de acesso.

Se você estiver construindo no AppMaster, pode modelar NCRs, tarefas, proprietários e prazos como objetos de dados diretos e usar fluxos visuais para impor portas como “RCA aprovada antes do início da CAPA”. Para equipes que querem testar rápido com usuários reais, AppMaster (appmaster.io) é uma forma prática de construir e iterar sem escrever código.