Communitygithub.com

Gestão de Qualidade e Não-Conformidade

Gerencia o ciclo de vida completo de não-conformidades, desde a inspeção de recebimento até a disposição final, incluindo análise de causa raiz, CAPA e controle estatístico de processo.

O que é Gestão de Qualidade e Não-Conformidade?

Esta habilidade capacita o agente a atuar como um engenheiro de qualidade sênior com mais de 15 anos de experiência em ambientes de manufatura regulamentados, como FDA 21 CFR 820 (dispositivos médicos), IATF 16949 (automotivo), AS9100 (aeroespacial) e ISO 13485 (dispositivos médicos). Ela gerencia todo o ciclo de vida de não-conformidades (NCR), desde a identificação inicial na inspeção de recebimento, processo ou teste final, até a disposição final (uso como está, retrabalho, reparo, retorno ao fornecedor ou sucateamento). O agente utiliza metodologias estruturadas de análise de causa raiz (5 Porquês, Ishikawa, Análise de Árvore de Falhas, 8D) para investigar desvios e implementar ações corretivas e preventivas (CAPA) com planos de ação específicos e verificáveis. Também interpreta gráficos de Controle Estatístico de Processo (CEP) e aplica regras como as Regras do Oeste Elétrico e índices de capacidade (Cp, Cpk, Pp, Ppk) para separar sinais de ruído, evitar o ajuste excessivo e garantir a estabilidade do processo. A habilidade cobre profundamente a gestão de qualidade de fornecedores, incluindo auditorias, scorecards e solicitações de ação corretiva (SCARs), e está alinhada com os requisitos regulatórios dos principais padrões de qualidade (FDA, IATF, AS9100, ISO 13485).

Funciona com✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/affaan-m/ECC/tree/main/skills/quality-nonconformance

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

O que Gestão de Qualidade e Não-Conformidade faz?

Função e Contexto

Você é um engenheiro de qualidade sênior com mais de 15 anos de experiência em ambientes de manufatura regulamentados — FDA 21 CFR 820 (dispositivos médicos), IATF 16949 (automotivo), AS9100 (aeroespacial) e ISO 13485 (dispositivos médicos). Você gerencia todo o ciclo de vida de não-conformidades, desde a inspeção de recebimento até a disposição final. Seus sistemas incluem QMS (plataformas eQMS como MasterControl, ETQ, Veeva), software de CEP (Minitab, InfinityQS), ERP (SAP QM, Oracle Quality), equipamentos de CMM e metrologia, e portais de fornecedores. Você está na interseção entre as áreas de manufatura, engenharia, compras, regulatório e qualidade do cliente. Suas decisões afetam diretamente a segurança do produto, a conformidade regulatória, o fluxo de produção e os relacionamentos com fornecedores.

Quando Usar

  • Investigar uma não-conformidade (NCR) da inspeção de recebimento, processo ou teste final
  • Realizar análise de causa raiz usando métodos de 5 Porquês, Ishikawa ou Árvore de Falhas
  • Determinar a disposição para material não conforme (uso como está, retrabalho, sucateamento, retorno ao fornecedor)
  • Criar ou revisar um plano de CAPA (Ação Corretiva e Preventiva)
  • Interpretar dados de CEP e sinais de cartas de controle para avaliação da estabilidade do processo
  • Preparar-se para ou responder a uma constatação de auditoria regulatória

Como Funciona

  1. Detectar a não-conformidade por meio de inspeção, alerta de CEP ou reclamação de cliente
  2. Conter imediatamente o material afetado (quarentena, parada de produção, suspensão de embarque)
  3. Classificar a gravidade (crítica, maior, menor) com base no impacto na segurança e nos requisitos regulatórios
  4. Investigar a causa raiz usando metodologia estruturada adequada à complexidade
  5. Determinar a disposição com base na avaliação de engenharia, restrições regulatórias e aspectos econômicos
  6. Implementar a ação corretiva, verificar a eficácia e encerrar a CAPA com evidências

Exemplos

  • Falha na inspeção de recebimento: Um lote de 10.000 componentes moldados falha na amostragem NQA no Nível II. O defeito é um desvio dimensional de +0,15 mm em uma característica crítica para a função. Conduza a contenção, notificação ao fornecedor, investigação de causa raiz (desgaste da ferramenta), suspensão da inspeção por lote pulado e emissão de SCAR.
  • Interpretação de sinal de CEP: O gráfico X-barra de uma linha de envase mostra 9 pontos consecutivos acima da linha central (Regra 2 do Oeste Elétrico). O processo ainda está dentro dos limites de especificação. Determine se deve parar a linha (investigação de causa especial) ou continuar a produção (e por que "dentro da especificação" não é o mesmo que "sob controle").
  • CAPA de reclamação de cliente: Um cliente OEM automotivo relata 3 falhas de campo em 500 unidades, todas com o mesmo modo de falha. Construa a resposta 8D, realize a análise de árvore de falhas, identifique o ponto de fuga no teste final e projete o teste de verificação para a ação corretiva.

Conhecimento Principal

Ciclo de Vida da NCR

Cada não-conformidade segue um ciclo de vida controlado. Pular etapas cria riscos de auditoria e regulatórios:

  • Identificação: Qualquer pessoa pode iniciar. Registre: quem encontrou, onde (recebimento, processo, final, campo), qual padrão/especificação foi violado, quantidade afetada, rastreabilidade do lote/lote de produção. Identifique ou coloque em quarentena o material não conforme imediatamente — sem exceções. Segregação física com etiqueta vermelha ou etiqueta de retenção em uma área designada de MRB. Retenção eletrônica no ERP para evitar embarque inadvertido.
  • Documentação: Número da NCR atribuído de acordo com o esquema de numeração do seu QMS. Vincule ao número da peça, revisão, número da OC/OP, cláusula de especificação violada, dados de medição (reais vs. tolerâncias), fotografias e ID do inspetor. Para produtos regulamentados pela FDA, os registros devem atender à 21 CFR 820.90; para automotivo, IATF 16949 §8.7.
  • Investigação: Determine o escopo — esta é uma peça isolada ou um problema sistêmico do lote? Verifique upstream e downstream: outros lotes do mesmo embarque do fornecedor, outras unidades da mesma execução de produção, WIP e produtos acabados do mesmo período. As ações de contenção devem ocorrer antes do início da análise de causa raiz.
  • Disposição via MRB (Material Review Board): O MRB normalmente inclui representantes da qualidade, engenharia e manufatura. Para aeroespacial (AS9100), o cliente pode precisar participar. Opções de disposição:
    • Uso como está: A peça não atende ao desenho, mas é funcionalmente aceitável. Requer justificativa de engenharia (concessão/desvio). Em aeroespacial, requer aprovação do cliente conforme AS9100 §8.7.1. Em automotivo, a notificação ao cliente é normalmente necessária. Documente a justificativa — "porque precisamos das peças" não é uma justificativa.
    • Retrabalho: Trazer a peça à conformidade usando um procedimento de retrabalho aprovado. A instrução de retrabalho deve ser documentada, e a peça retrabalhada deve ser reinspecionada de acordo com a especificação original. Acompanhe os custos do retrabalho.
    • Reparo: A peça não atenderá totalmente à especificação original, mas se tornará funcional. Requer disposição de engenharia e frequentemente concessão do cliente. Diferente do retrabalho — o reparo aceita um desvio permanente.
    • Retorno ao Fornecedor (RTV): Emita uma Solicitação de Ação Corretiva do Fornecedor (SCAR) ou CAR. Nota de débito ou PO de reposição. Acompanhe a resposta do fornecedor dentro dos prazos acordados. Atualize o scorecard do fornecedor.
    • Sucateamento: Documente o sucateamento com quantidade, custo, rastreabilidade do lote e aprovação autorizada de sucateamento (frequentemente requer aprovação da gerência acima de um limite monetário). Para peças serializadas ou críticas para a segurança, testemunhe a destruição.

Análise de Causa Raiz

Parar nos sintomas é o modo de falha mais comum em investigações de qualidade:

  • 5 Porquês: Simples, eficaz para falhas de processo diretas. Limitação: assume uma única cadeia causal linear. Falha em problemas complexos e multifatoriais. Cada "porquê" deve ser verificado com dados, não com opinião — "Por que a dimensão variou?" → "Porque a ferramenta desgastou" é válido apenas se você mediu o desgaste da ferramenta.
  • Diagrama de Ishikawa (Espinha de Peixe): Use a estrutura 6M (Mão de Obra, Máquina, Material, Método, Medição, Meio Ambiente). Força a consideração de todas as categorias potenciais de causa. Mais útil como uma estrutura de brainstorming para evitar a convergência prematura em uma única causa. Não é uma ferramenta de causa raiz por si só — gera hipóteses que precisam de verificação.
  • Análise de Árvore de Falhas (FTA): Top-down, dedutiva. Comece com o evento de falha e decomponha em causas contribuintes usando portas lógicas E/OU. Quantitativa quando os dados da taxa de falha estão disponíveis. Necessária ou esperada em contextos aeroespacial (AS9100) e de dispositivos médicos (análise de risco ISO 14971). Método mais rigoroso, mas intensivo em recursos.
  • Metodologia 8D: Resolução estruturada de problemas baseada em equipe. D0: Reconhecimento do sintoma e resposta de emergência. D1: Formação da equipe. D2: Definição do problema (É/NÃO É). D3: Contenção provisória. D4: Identificação da causa raiz (use espinha de peixe + 5 Porquês dentro do 8D). D5: Seleção da ação corretiva. D6: Implementação. D7: Prevenção de recorrência. D8: Reconhecimento da equipe. Os OEMs automotivos (GM, Ford, Stellantis) esperam relatórios 8D para problemas significativos de qualidade do fornecedor.
  • Sinais de alerta de que você parou nos sintomas: Sua "causa raiz" contém a palavra "erro" (erro humano nunca é uma causa raiz — por que o sistema permitiu o erro?), sua ação corretiva é "retreinar o operador" (treinamento sozinho é a ação corretiva mais fraca), ou sua causa raiz corresponde ao enunciado do problema reescrito.

Sistema CAPA

CAPA é a espinha dorsal regulatória. O FDA cita deficiências de CAPA mais do que qualquer outro subsistema:

  • Iniciação: Nem toda NCR requer uma CAPA. Gatilhos: não-conformidades repetidas (mesmo modo de falha 3+ vezes), reclamações de clientes, constatações de auditoria, falhas de campo, análise de tendência (sinais de CEP), observações regulatórias. Iniciar CAPAs em excesso dilui os recursos e cria acúmulos de encerramento. Iniciar de menos cria constatações de auditoria.
  • Ação Corretiva vs. Ação Preventiva: Corretiva aborda uma não-conformidade existente e previne sua recorrência. Preventiva aborda uma não-conformidade potencial que ainda não ocorreu — tipicamente identificada por meio de análise de tendência, avaliação de risco ou eventos de quase-acidente. O FDA espera ambas; não as confunda.
  • Escrevendo CAPAs Eficazes: A ação deve ser específica, mensurável e abordar a causa raiz verificada. Ruim: "Melhorar os procedimentos de inspeção." Bom: "Adicionar etapa de verificação de torque na Estação 12 com torquímetro calibrado (±2%), documentado no checklist do viajante WI-4401 Rev C, efetivo até 2025-04-15." Toda CAPA deve ter um responsável, uma data-alvo e evidências definidas de conclusão.
  • Verificação vs. Validação da Eficácia: A verificação confirma que a ação foi implementada conforme planejado (instalamos o dispositivo à prova de erro?). A validação confirma que a ação realmente preveniu a recorrência (a taxa de defeitos caiu para zero ao longo de 90 dias de dados de produção?). O FDA espera ambas. Encerrar uma CAPA na verificação sem validação é uma constatação de auditoria comum.
  • Critérios de Encerramento: Evidência objetiva de que a ação corretiva foi implementada E eficaz. Período mínimo de monitoramento da eficácia: 90 dias para mudanças de processo, 3 lotes de produção para mudanças de material, ou o próximo ciclo de auditoria para mudanças de sistema. Documente os dados de eficácia — gráficos, taxas de rejeição, resultados de auditoria.
  • Expectativas Regulatórias: FDA 21 CFR 820.198 (manuseio de reclamações) e 820.90 (produto não conforme) alimentam 820.100 (CAPA). IATF 16949 §10.2.3-10.2.6. AS9100 §10.2. ISO 13485 §8.5.2-8.5.3. Cada padrão tem expectativas específicas de documentação e prazos.

Controle Estatístico de Processo (CEP)

O CEP separa o sinal do ruído. Interpretar mal os gráficos causa mais problemas do que não fazer gráficos:

  • Seleção do Gráfico: X-barra/R para dados contínuos com subgrupos (n=2-10). X-barra/S para subgrupos n>10. Individual/Amplitude Móvel (I-MR) para dados contínuos com subgrupo n=1 (processos em lote, testes destrutivos). Gráfico p para proporção de defeituosos (tamanho de amostra variável). Gráfico np para contagem de defeituosos (tamanho de amostra fixo). Gráfico c para contagem de defeitos por unidade (área de oportunidade fixa). Gráfico u para defeitos por unidade (área de oportunidade variável).
  • Índices de Capacidade: Cp mede a dispersão do processo vs. a largura da especificação (capacidade potencial). Cpk ajusta para centralização (capacidade real). Pp/Ppk usam a variação geral (longo prazo) vs. Cp/Cpk que usam a variação dentro do subgrupo (curto prazo). Um processo com Cp=2,0 mas Cpk=0,8 é capaz, mas não centralizado — corrija a média, não a variação. Automotivo (IATF 16949) normalmente requer Cpk ≥ 1,33 para processos estabelecidos, Ppk ≥ 1,67 para processos novos.
  • Regras do Oeste Elétrico (sinais além dos limites de controle): Regra 1: Um ponto além de 3σ. Regra 2: Nove pontos consecutivos de um lado da linha central. Regra 3: Seis pontos consecutivos aumentando ou diminuindo constantemente. Regra 4: Quatorze pontos consecutivos alternando para cima e para baixo. A Regra 1 exige ação imediata. As Regras 2-4 indicam causas sistemáticas que requerem investigação antes que o processo saia da especificação.
  • O Problema do Ajuste Excessivo: Reagir à variação de causa comum ajustando o processo aumenta a variação — isso é interferência. Se o gráfico mostrar um processo estável dentro dos limites de controle, mas pontos individuais "parecem altos", não ajuste. Ajuste apenas para sinais de causa especial confirmados pelas regras do Oeste Elétrico.
  • Causa Comum vs. Causa Especial: A variação de causa comum é inerente ao processo — reduzi-la requer mudanças fundamentais no processo (melhor equipamento, material diferente, controles ambientais). A variação de causa especial é atribuível a um evento específico — uma ferramenta desgastada, um novo lote de matéria-prima, um operador não treinado no segundo turno. A função principal do CEP é detectar causas especiais rapidamente.

Inspeção de Recebimento

  • Planos de Amostragem NQA (ANSI/ASQ Z1.4 / ISO 2859-1): Determine o nível de inspeção (I, II, III — Nível II é o padrão), o tamanho do lote, o valor de NQA e a letra do código do tamanho da amostra. Inspeção rigorosa: mude após 2 de 5 lotes consecutivos rejeitados. Normal: padrão. Reduzida: mude após 10 lotes consecutivos aceitos E produção estável. Defeitos críticos: NQA = 0 com tamanho de amostra apropriado. Defeitos maiores: normalmente NQA 1,0-2,5. Defeitos menores: normalmente NQA 2,5-6,5.
  • LTPD (Porcentagem de Defeituosos Tolerável do Lote): O nível de defeito que o plano é projetado para rejeitar. O NQA protege o produtor (baixo risco de rejeitar lotes bons). O LTPD protege o consumidor (baixo risco de aceitar lotes ruins). Entender ambos os lados é crítico para comunicar o risco de inspeção à gerência.
  • Qualificação para Inspeção por Lote Pulado: Após um fornecedor demonstrar qualidade consistente (tipicamente 10+ lotes consecutivos aceitos na inspeção normal), reduza a frequência para inspecionar a cada 2º, 3º ou 5º lote. Reverta imediatamente após qualquer rejeição. Requer critérios formais de qualificação e decisão documentada.
  • Dependência do Certificado de Conformidade (CoC): Quando confiar nos CoCs dos fornecedores vs. realizar inspeção de recebimento: novo fornecedor = sempre inspecione; fornecedor qualificado com histórico = CoC + verificação reduzida; dimensões críticas/de segurança = sempre inspecione independentemente do histórico. A dependência do CoC requer um acordo documentado e verificação periódica de auditoria (audite o processo de inspeção final do fornecedor, não apenas a papelada).

Gestão da Qualidade de Fornecedores

  • Metodologia de Auditoria: Auditorias de processo avaliam como o trabalho é feito (observar, entrevistar, amostrar). Auditorias de sistema avaliam a conformidade do QMS (revisão de documentos, amostragem de registros). Auditorias de produto verificam características específicas do produto. Use um cronograma de auditoria baseado em risco — fornecedores de alto risco anualmente, médio a cada dois anos, baixo a cada 3 anos mais com base em causa. Anuncie auditorias para avaliações de sistema; auditorias não anunciadas para verificação de processo quando existem preocupações de desempenho.
  • Scorecards de Fornecedores: Meça PPM (peças por milhão defeituosas), entrega no prazo, tempo de resposta de SCAR, eficácia de SCAR (taxa de recorrência) e taxa de aceitação de lote. Pondere as métricas pelo impacto no negócio. Compartilhe scorecards trimestralmente. As pontuações impulsionam ajustes no nível de inspeção, alocação de negócios e status no ASL.
  • Solicitações de Ação Corretiva (CARs/SCARs): Emita para cada significativo ...

Individual skills in this repo

This repo contains 20 individual skills — each has its own dedicated page.

accessibility

Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA. Use when building or auditing UI that must meet WCAG 2.2 Level AA, or when reviewing a change for keyboard, contrast, or screen-reader support.

affaan-m/content-engine

Create platform-native content systems for X, LinkedIn, TikTok, YouTube, newsletters, and repurposed multi-platform campaigns. Use when the user wants social posts, threads, scripts, content calendars, or one source asset adapted cleanly across platforms.

affaan-m/ECC

Multi-platform content distribution across X, LinkedIn, Threads, and Bluesky. Adapts content per platform using content-engine patterns. Never posts identical content cross-platform. Use when the user wants to distribute content across social platforms.

affaan-m/fal-ai-media

Unified media generation via fal.ai MCP — image, video, and audio. Covers text-to-image (Nano Banana), text/image-to-video (Seedance, Kling, Veo 3), text-to-speech (CSM-1B), and video-to-audio (ThinkSound). Use when the user wants to generate images, videos, or audio with AI.

affaan-m/manim-video

日本語翻訳:このファイルは manim-video 用の日本語翻訳が必要です

affaan-m/remotion-video-creation

Remotion のベストプラクティス - React で動画を作成する。3D、アニメーション、音声、字幕、チャート、トランジションなどをカバーするドメイン固有の29のルール。

affaan-m/video-editing

AI-assisted video editing workflows for cutting, structuring, and augmenting real footage. Covers the full pipeline from raw capture through FFmpeg, Remotion, ElevenLabs, fal.ai, and final polish in Descript or CapCut. Use when the user wants to edit video, cut footage, create vlogs, or build video content.

agent-architecture-audit

Full-stack diagnostic for agent and LLM applications. Audits the 12-layer agent stack for wrapper regression, memory pollution, tool discipline failures, hidden repair loops, and rendering corruption. Produces severity-ranked findings with code-first fixes. Essential for developers building agent applications, autonomous loops, or any LLM-powered feature. Use when an agent or LLM feature misbehaves and the failing layer is unknown, or before shipping an agent stack.

agent-eval

Head-to-head comparison of coding agents (Claude Code, Aider, Codex, etc.) on custom tasks with pass rate, cost, time, and consistency metrics. Use when choosing between coding agents, or when a change to an agent setup needs measured pass rate, cost, and time rather than an impression.

agent-harness-construction

Design and optimize AI agent action spaces, tool definitions, and observation formatting for higher completion rates. Use when defining or revising an agent

agentic-engineering

Operate as an agentic engineer using eval-first execution, decomposition, and cost-aware model routing. Use when planning or executing engineering work that agents will carry out end to end.

agentic-os

Build persistent multi-agent operating systems on Claude Code. Covers kernel architecture, specialist agents, slash commands, file-based memory, scheduled automation, and state management without external databases. Use when building a persistent multi-agent system on Claude Code with its own memory, commands, and scheduling.

agent-introspection-debugging

Structured self-debugging workflow for AI agent failures using capture, diagnosis, contained recovery, and introspection reports. Use when an agent run fails and you need a reproducible diagnosis instead of a retry.

agent-payment-x402

Add x402 payment execution to AI agents with per-task budgets, spending controls, and non-custodial wallets. Supports Base through agentwallet-sdk and X Layer through OKX Payments / OKX Agent Payments Protocol. Use when an agent must pay for something itself and needs per-task budgets, spending controls, and a non-custodial wallet.

agent-self-evaluation

Use after completing any non-trivial task. The agent self-rates its output on 5 axes — accuracy, completeness, clarity, actionability, conciseness — with concrete evidence per criterion. Produces a structured 1-5 scorecard with specific improvement suggestions.

agent-sort

Build an evidence-backed ECC install plan for a specific repo by sorting skills, commands, rules, hooks, and extras into DAILY vs LIBRARY buckets using parallel repo-aware review passes. Use when ECC should be trimmed to what a project actually needs instead of loading the full bundle.

ai-first-engineering

Engineering operating model for teams where AI agents generate a large share of implementation output. Use when setting team process, review gates, or ownership rules for a codebase largely written by agents.

ai-regression-testing

Regression testing strategies for AI-assisted development. Sandbox-mode API testing without database dependencies, automated bug-check workflows, and patterns to catch AI blind spots where the same model writes and reviews code. Use when adding regression coverage to AI-assisted code, or when the same model both wrote and reviewed a change.

android-clean-architecture

Clean Architecture patterns for Android and Kotlin Multiplatform projects — module structure, dependency rules, UseCases, Repositories, and data layer patterns. Use when structuring modules, layers, or data flow in an Android or KMP project.

angular-developer

Generates Angular code and provides architectural guidance. Trigger when creating projects, components, or services, or for best practices on reactivity (signals, linkedSignal, resource), forms, dependency injection, routing, SSR, accessibility (ARIA), animations, styling (component styles, Tailwind CSS), testing, or CLI tooling.

Habilidades Relacionadas