Este mapa mostra as seções que tratam do FMEA na flexM4i. No início de cada seção apresentamos este mapa para você se localizar. Se desejar, você pode baixar este mapa em pdf, que possui os links para todas as seções.

Figura 1073: mapa de seções sobre FMEA na flexM4i (clique na figura para baixar o mapa)

Os rótulos em itálico azul na figura indicam o nível de detalhamento do conteúdo.

O DRBFM foi desenvolvido pela Toyota Motor Corporation, pois a empresa percebeu que existia uma relação entre mudanças no produto e novas falhas, e que nem sempre a Toyota identificava todos os possíveis novos riscos de falhas devido às mudanças.

O DRBFM visa tornar visíveis todos os problemas latentes e assegurar que as medidas necessárias para corrigir estes problemas sejam todas implementadas. Este método foi chamado de Design Review Based on Failure Mode (DRBFM) – Revisão de Projeto baseada em Modos de Falha porque:

• utilizou a lógica do FMEA (failure mode) sem focar no cálculo do índice de priorização do risco, mas considerando a cadeia de falha: efeito – modo de falha – causa.
• a design review (revisão do design) refere-se ao processo sistemático de avaliação detalhada das mudanças propostas no design de um produto ou sistema.

The Toyota Product Development System

O sistema Toyota de produção (TPS – Toyota Production System), conhecido como Lean Manufacturing, ficou famoso na década de 1980 como um novo paradigma que fazia com que a indústria automotiva japonesa superasse a americana. Especialistas também concluíram que uma das fraquezas do baixo desempenho comparativo das indústrias automobilísticas americanas era a falta de integração entre o design de produto, design do processo de manufatura (planejamento de processo), marketing, suprimentos e compras (Sobek, Liker & Ward,1998).

Diversos trabalhos foram conduzidos na tentativa de decodificar o sistema Toyota de desenvolvimento de produtos. Os pesquisadores Morgan e Liker (Morgan, 2002; Morgan & Liker, 2006) da Universidade de Michigan, por exemplo, conduziram centenas de horas de entrevistas com engenheiros de desenvolvimento da Toyota no Japão e nos Estados Unidos, procurando responder a pergunta “Quais são os princípios que têm feito a Toyota ser tão bem-sucedida?” (Morgan & Liker, 2006, p.5).

Eles codificaram as práticas levantadas sob o título de The Toyota Product Development System: Integrating People, Process and Technology (Morgan & Liker, 2020). 

DRBFM não é citado no livro de Morgan & Liker (2020)

Morgan & Liker não citam em suas publicações o método DRBFM (Laurenti, 2010).

De acordo com Schorn (2005), o método DRBFM foi desenvolvido na Toyota Motor Corporation por Tatsuhiko Yoshimura, o qual foi, por 32 anos, responsável pela engenharia de confiabilidade na Toyota. Para Schorn (2005), Yoshimura dedicou uma grande parte da sua vida profissional à tarefa de evitar que problemas aparecessem.

Schorn (2005) relata que o próprio Yoshimura admite que, diante desta tarefa, esteve relativamente sozinho com muita frequência, e seus colegas de trabalho da Toyota que agiam de maneira “Troubleshooter” (solucionador de problemas) eram aparentemente os heróis da empresa: afinal eles resolviam os problemas assim que eles apareciam. Schorn (2005) comenta que o resumo de Yoshimura sobre essa experiência é similar ao resultado de um estudo do MIT: “Nobody ever gets credit for fixing problems that never happened” (Repenning & Sterman, 2001).

Parte da filosofia Mizen Boushi

Esse método é parte da filosofia Mizen Boushi (traduzido por “medidas de prevenção”), abreviada de GD3, que significa:

• Good Design: bom design
• Good Discussion: boa discussão sobre o design; e
• Good Dissection: boa revisão dos resultados.

O DRBFM é utilizado na filosofia Mizen Boushi para identificar, o mais cedo possível durante o desenvolvimento do produto, qualquer problema causado por modificações no projeto (design) (mudanças intencionais) e mudanças nas condições de uso (mudanças incidentais).

Conteúdo extraído do nosso glossário.

Alguns traduzem Mizen Boushi (em algumas publicações está como Mizen Bousi) como “medidas de prevenção”, mas segundo Shimizu, Otsuka & Noguchi (2010), um significado mais preciso seria “medidas de prevenção proativas”, complementando as medidas de prevenção recorrentes.

Uma sigla usada para Mizen Boushi é GD3 (também conhecida como cubo GD), que significa (Shimizu, Otsuka & Noguchi, 2010):  

• Good Design (bom projeto / design): desenvolver um design de um produto confiável e robusto (com a aplicação do design for reliability), que mantenha suas condições por muito tempo e possa ser uma referência para um novo design. Procura-se evitar introduzir muitas mudanças se for utilizado um design confiável e robusto como referência para um novo design. Assim, procura-se reduzir a complexidade da prevenção de erros (que tem de analisar com profundidade cada uma das mudanças).
• Good Discussion (boa discussão): discutir (até esgotar) e encontrar problemas latentes (potenciais) devido à diferença no design atual (com mudanças) em relação ao “bom design” (original, que foi modificado). Os designers não podem evitar desvios do “bom design” no caso de uma mudança do design atual (por exemplo vindo de uma engineering change order) ou de um novo design para atender novas demandas / requisitos do mercado. Os designers (na verdade um time multifuncional) devem então analisar as diferenças e encontrar os problemas potenciais que podem ser causados pelas mudanças usando a discussão com a expertise necessária.
• Good Design Review (boa revisão de projeto / design): processo específico para revisão de design, incluindo a identificação de problemas e a determinação de contramedidas para eles. As opiniões adquiridas nas reuniões realizadas são transformadas em ações corretivas, então é conduzida uma reunião de análise detalhada dos resultados adquiridos com os testes de validação, realizados com base em projetos-pilotos. Inclui a discussão (good discussion)

A próxima figura ilustra a posição do Mizen Boushi dentro do contexto de prevenção de problemas de confiabilidade.

Figura 1110: posicionamento do Mizen Boushi dentro do contexto de prevenção de problemas de confiabilidade

O conceito do Mizen Boushi é um ciclo:

• Devemos realizar um “bom design” (Good Design) com a aplicação de todas as ferramentas de confiabilidade, com base nos padrões e regras de design existentes.
• Em seguida acionamos os outros dois GDs, “boa discussão” e “boa revisão de design / projeto” para identificar problemas, preocupações, modos de falha potenciais, que procuramos resolver com ações para mitigar ou eliminar os riscos. 
• As especificações de design geram os documentos de processo que são utilizados na produção.
• Se surgirem problemas na produção, eles devem ser resolvidos pelos métodos de análise e solução de problemas (MASP), que utilizam, entre outros métodos, a análise de causa raiz.
• As soluções adotadas podem se tornar padrões e regras de design, assim como referências para serem utilizadas em novos desenvolvimentos.
• Em um novo desenvolvimento, devemos aplicar inicialmente (novamente) as medidas de prevenção recorrentes, baseadas nesses padrões, regras e referências, que podem ser armazenadas como boas práticas e lições aprendidas.
• Em seguida, devemos procurar por problemas potenciais, aplicando novamente o Mizen Boushi (ou o GD3).
• Nas alterações de design, como partimos de um design “estável”, devemos explorar com detalhes as possíveis falhas potenciais introduzidas pelas mudanças. Essas alterações podem vir de uma “engineering change order” ou de um projeto incremental, que toma como referência um projeto (design) existente, na verdade, um “good design”.

• Em cada mudança no design, forma, função, ajuste de qualquer item. Deve ser iniciado a partir de um FMEA já existente.
• Se não existir um FMEA, o DRBFM pode ser utilizado para avaliar as mudanças.

• Apesar da utilização de diversos métodos e ferramentas de confiabilidade, mudanças no design e no processo são introduzidas, que frequentemente causam falhas não previstas.
• O DRBFM é utilizado para realizar a prevenção proativa de mudanças no contexto do Mizen Boushi (GD3) e da obtenção de confiabilidade de produtos e processos.
• Em última análise, a aplicação do DRBFM contribui para a melhoria contínua da qualidade, obtenção de produtos mais confiáveis e, assim, para a melhoria da imagem da marca da empresa.

• Foco nas mudanças: O DRBFM baseia-se na premissa de que a maioria dos problemas de qualidade e falhas em um produto é o resultado de mudanças no design. Ao focar especificamente nas mudanças, o DRBFM visa identificar proativamente os riscos associados e implementar medidas para mitigá-los.
• Análise detalhada: Ao realizar uma “revisão de design”, os envolvidos se dedicam a uma análise minuciosa das mudanças de design propostas. Isso envolve não apenas entender a natureza da mudança, mas também discutir e prever os possíveis modos de falha que podem resultar dessas alterações. Essa abordagem detalhada ajuda a garantir que todos os aspectos de uma mudança sejam considerados e avaliados.
• Colaboração e comunicação: O termo “revisão” implica em um processo colaborativo e interdisciplinar. A metodologia DRBFM encoraja a participação de membros de diversas áreas (como design, engenharia, produção e qualidade) nas discussões sobre as mudanças de design. Esse processo de revisão facilita a comunicação eficaz entre as pessoas da equipe, promovendo a identificação conjunta de soluções para os potenciais modos de falha.
• Prevenção e melhoria contínua: O objetivo final da revisão de design no contexto do DRBFM é prevenir problemas de qualidade e falhas antes que eles ocorram. Além disso, ao focar na análise e discussão detalhada das mudanças, o DRBFM contribui para a cultura de melhoria contínua, incentivando as equipes a aprender com as revisões e a aplicar esses aprendizados em projetos futuros.

Como o DRBFM é um método da abordagem Mizen Boushi, os princípios desta abordagem, já apresentados, também são considerados princípios do DRBFM, ou seja, o GD3:

• Good Design
• Good Discussion
• Good Design Review

Esses princípios se sobrepõem aos princípios listados anteriormente.

No quadro a seguir mostramos um paralelo entre a terminologia adotada no FMEA e no DRBFM.

Quadro 1120: comparação entre as terminologias típicas do FMEA versus do DRBFM

Os termos relacionados com o DRBFM apresentados no quadro anterior surgiram em outra época, mas cada vez mais eles estão convergindo para os termos do FMEA. Por isso, na descrição das etapas e atividades, vamos utilizar indiferentemente esses termos, conforme alguns manuais de DRBFM de empresas que tivemos acesso.

No FMEA consideramos o grupo: modo de falha, efeito (do modo de falha) e causa (do modo de falha).

O manual da AIAG & VDA (2019) define esse grupo de cadeia de falha, representado na parte superior da próxima figura. Na parte inferior da figura mostramos a relação de causa e efeito entre esses três elementos.

Figura 1030: representação da cadeia de falha e da relação de causa e efeito entre os três elementos

Precisamos atentar que parece contra intuitivo colocar o modo de falha entre a causa e o efeito. É comum um usuário deste método citar uma causa e o efeito correspondente, mas não é esse o princípio do FMEA.

Por exemplo, imagine o caso de um eixo mecânico de um redutor: 

• A lubrificação inadequada da operação do eixo no redutor pode aumentar seu atrito com outras peças acopladas a ele (causa):
• A lubrificação inadequada pode causar um desgaste excessivo do eixo (modo de falha):
• O desgaste excessivo pode causar um aumento do ruído e vibração, afetando a operação da máquina, na qual o redutor está inserido. Os ruídos podem ter efeitos nocivos sobre a saúde do operador (efeito); ou
• O desgaste excessivo pode causar a necessidade de manutenção e substituição precoce, aumentando os custos operacionais. Este efeito pode causar uma grande insatisfação para o cliente (efeito).

Veja nesse exemplo, que a lubrificação inadequada está indiretamente relacionada com o aumento do ruído e vibração ou com a substituição precoce. Isso porque precisamos ter um elemento focal para realizar o FMEA.

Apresentamos a seguir cada um dos elementos dessa cadeia de falha.

Não existe um padrão de formulário para o desenvolvimento do DRBFM, como existe para o FMEA. Mesmo o formulário de FMEA pode ter variações, se não for utilizado no contexto do PPAP da IATF 16949.Há alguns formulários mais simplificados, voltados somente para a análise das mudanças, que é o foco principal do DRBFM.

Mas algumas empresas, que não precisam ser certificadas, utilizam um formulário de DRBFM mais completo.

Outras empresas, unificaram os formulários de FMEA e de DRBFM para facilitar. Assim, quando o formulário estiver sendo aplicado para FMEA ou para DRBFM, há um campo que você seleciona. A vantagem de utilizar um mesmo formulário está na facilidade de reutilização e quando o DRBFM apenas complementa um FMEA já existente. Isso porque há uma certa superposição entre as informações dos dois formulários.

Nesta seção trazemos dois formulários em uma mesma planilha Excel. Porém, para descrever as atividades vamos utilizar o formulário unificado.

O formulário está no material de apoio, identificado como MAP0059. Ele possui duas abas:

• formulário unificado (que usamos como referência nesta seção)
• formulário separado (que deixamos somente como uma ilustração)

Mas além do formulário principal, algumas atividades podem utilizar outros formulários, checklists e outras ferramentas, que apresentamos na descrição das atividades. 

O uso de softwares de FMEA integrados com o DRBFM simplificam o trabalho coordenado entre o desenvolvimento do DFMA e do DRBFM.

A implementação do DRBFM tem o objetivo de fazer com que este método seja utilizado recorrentemente na empresa. Uma vez implementado, ele é utilizado em cada projeto de desenvolvimento do DRBFM, cujas atividades são descritas nos próximos tópicos.

A implementação consiste em:

• entender o valor deste método (ver o tópico anterior “por que você deveria utilizar o DRBFM”;
• obter o comprometimento dos dirigentes;
• compartilhar lições aprendidas (reutilizar DRBFMs do passado);
• definir qual tipo de DRBFM será utilizado (formulário, etapas e atividades);
• estabelecer um procedimento padrão;
• integrar o procedimento estabelecido com o uso integrado (ou não) com o DFMEA e eventualmente com o PFMEA, dentro do conteúdo de um processo mais amplo de desenvolvimento de produtos;
• definir uma sistemática de classificação de armazenamento dos DRBFMs para que eles possam ser recuperados e reutilizados para itens semelhantes no futuro;
• definir e implementar um software de apoio ao desenvolvimento do DRBFM, que seja integrado com a obtenção do FMEA;
• definir e avaliar quais outros métodos e ferramentas podem / devem ser utilizados de forma integrada com o DRBFM (durante a descrição propomos alguns métodos);
• treinar as pessoas que estarão envolvidas com a aplicação do DRBFM.

Todas etapas e atividades descritas a seguir são realizadas a cada desenvolvimento de um DRBFM.

Quando se trata de uma montadora, podemos considerar no time, as seguintes pessoas:

• coordenador do projeto (project) e facilitador da aplicação do método DRBFM;
• engenheiro / designer responsável; 
• projetistas / designers e processistas;
• engenheiros de integração responsáveis pela arquitetura do produto;
• engenheiros de design com os fornecedores;
• responsáveis pelos testes, verificação e validação;
• responsáveis pelo design das interfaces;
• especialistas de diversas áreas afins para participar das revisões;
• representantes dos fornecedores envolvidos.

Em outros tipos de empresas, podemos definir um time mais enxuto. Mas, necessariamente, este trabalho precisa ser multidisciplinar.

Uma proposta para desenvolvimento do DRBFM é dividir o time em dois grupos:

• Grupo 1 – responsável pela etapa 1 – Análise das mudanças: somente o engenheiro / designer responsável com o auxílio do facilitador. Este grupo deve ter uma visão ampla do produto sendo analisado com experiência, pois ele realiza as atividades da análise das mudanças (veja anteriormente quais são essas atividades).
• Grupo 2 – responsável pela etapa 2 – Revisão detalhada e recomendação de ações: é o time completo com os membros listados acima. Avaliar se alguns membros não devem ser convidados apenas para sessões específicas.

Conhecer a estrutura do produto ou do processo, assim como a análise estrutural do método de FMEA, é uma referência para se extrair os itens que serão analisados. 

Normalmente, a estrutura de produtos ou processos é obtida durante  o desenvolvimento de produtos / processos. Além disso, como o DRBFM deve ser utilizado em mudanças, a estrutura já está documentada nos FMEAs já desenvolvidos. 

Mas se o FMEA não tiver sido anteriormente desenvolvido, parte-se da estrutura de produto disponível,

Esta atividade inicia com a identificação de pontos de mudança, com os seguintes objetivos:

• identificar a linha de base do design, bem como concentrar os esforços nas mudanças.
• apoia a equipe de desenvolvimento de produto na melhor compreensão dos modos de falha e preocupações (riscos) associados ao projeto (design) e processo de fabricação (process plan).
• priorizar as mudanças, concentrando-se primeiro nos itens de maior risco.

Podem ser utilizadas nesta atividade duas ferramentas:

• um checklist para identificar mudanças e
• tabela de comparação entre o design original e o novo

Checklist para identificar mudanças

A próxima figura apresenta este checklist, que você pode baixar no material adicional.

Figura 1111: checklist para identificar mudanças como passo inicial para a identificação dos  pontos de mudança
Corresponde ao material de apoio MF.MAP0057 (veja no tópico “material de apoio”).

As mudanças podem ocorrer no design (projeto), no fornecedor, nas condições de uso, no cliente, devido a um novo requisito, por causa de novas especificações internas ou normas e regulamentações etc.

Esse checklist pode servir como uma ferramenta de brainstorming para que não se esqueça de nada e se determine o que realmente mudou. Como o conceito de DRBFM considera que o início dos problemas está nas mudanças, se nós analisarmos com atenção essas mudanças, teremos praticado um bom design (Good Design – um dos 3 GDs no Mizen Boushi).

Como definir se a mudança foi intencional ou incidental?

Mudança Intencional: Refere-se a alterações deliberadas no design, especificações, materiais, componentes, condições de uso, ou qualquer outro aspecto de um produto ou sistema que foram planejadas e executadas com um propósito específico. Essas mudanças são feitas para melhorar o desempenho, a funcionalidade, a eficiência de custos, a conformidade com regulamentos, ou outros objetivos de design e de negócios.

Exemplos: Alterar o material de um componente para reduzir custos, modificar a forma de uma peça para melhorar a aerodinâmica, ou atualizar o software para adicionar novas funcionalidades.

Análise das mudanças intencionais: A equipe reconhece as mudanças que foram feitas por um motivo específico e pode discutir se os objetivos pretendidos dessas mudanças são alcançados sem introduzir novos problemas.

Mudança Incidental: Refere-se a alterações que ocorrem como consequência não intencional de outras mudanças ou de fatores externos. Essas mudanças podem não ter sido previstas ou planejadas e podem afetar o produto de maneiras inesperadas. Identificar mudanças incidentais é crucial para prevenir potenciais falhas, uma vez que elas podem introduzir riscos não reconhecidos durante o processo de design.

Exemplos: Uma alteração no material de um componente que inadvertidamente afeta sua resistência ao calor, ou uma mudança na localização de produção que impacta a consistência da qualidade do produto devido a diferenças no ambiente de fabricação.

Análise das mudanças incidentais: A equipe pode identificar e abordar as consequências não planejadas das mudanças, garantindo que todos os efeitos indiretos sejam considerados e que medidas preventivas sejam implementadas para mitigar potenciais falhas.

Comparação com o produto base

A tabela de comparação é elaborada baseando-se no checklist de identificação das mudanças, apresentado anteriormente. A próxima figura ilustra a tabela.

Figura 1112: tabela de comparação entre o design original e o novo design (clique na figura para abrir a visualização em outra aba)
Corresponde ao material de apoio MF.MAP0058 (veja no tópico “material de apoio”)

Deve-se solicitar que a equipe traga consigo desenhos, peças, especificações etc., tanto do design de base quanto do novo design proposto.

O preenchimento desta tabela envolve os seguintes passos (Allan, 2009):

• Estabelecer uma linha de base (referência com base no design anterior) e comparar com o novo design para  compreender profundamente as diferenças (mudanças);
• Documentar preocupações/impactos e identificar os membros da equipe multifuncional, que estarão envolvidos na determinação das ações para resolver os problemas. Porém, por enquanto, o foco é no entendimento profundo das diferenças e levantamento das preocupações, impactos e considerações.
• Atribuir um nível de risco (inicial), priorizar e definir uma estratégia de redução de risco tem sido eficaz (*).
• Apresentar a avaliação de risco à liderança para sua aprovação e compreensão.

Este pré-trabalho permite que o Engenheiro de Confiabilidade conduza a equipe ao workshop de Análise de Pontos de Mudança com a equipe multifuncional identificada, incluindo especialistas no assunto (*).

Observamos que esse trabalho preliminar, realizado antes da oficina de Análise de Pontos de Mudança, é mais eficaz do que começar com uma folha em branco, já que os engenheiros preferem criticar itens que foram esquecidos ou identificados incorretamente, propiciando um fórum para discussão Produtiva (*).

Então é possível identificar todas as mudanças intencionais e incidentais, evitando qualquer omissão que possa resultar em problemas de funcionalidade do produto

Após a análise inicial das mudanças, devemos listar os itens sendo modificados e suas funções no formulário do DRBFM.

Como descrito no tópico “Quantidade de mudanças”, como um dos cuidados a serem considerados no desenvolvimento do DRBFM, devemos nos limitar a poucas mudanças. No entanto, essa quantidade não é algo que se seleciona na análise do DRBFM. É um resultado da estratégia de desenvolvimento de produtos.

Uma prática adotada por algumas empresas, é que depois da análise, em time, dos pontos de mudanças, esse preenchimento inicial do formulário de DRBFM pode ser realizado por uma pessoa.

A próxima figura ilustra as colunas do formulário que devem ser preenchidas nesta atividade.

Figura 1113: colunas do formulário de DBFM para inserção do item do projeto / design que sofreu mudanças com relação ao projeto / design base

O preenchimento do item pode incorporar ou ser substituído pela descrição de uma interface entre itens, que pode ser a mudança realizada. Por isso, a análise descrita na atividade anterior é importante.

Algumas empresas não adotam o que apresentamos na atividade anterior de análise inicial das mudanças. Elas devem, então, descrever as mudanças com um nível de detalhamento apropriado para garantir que as pessoas que forem trabalhar com o formulário entendam qual foi a mudança. 

Se, todavia, a empresa utilizar as ferramentas que indicamos na atividade de análise inicial das mudanças, a descrição no formulário de DRBFM pode ser mais simplificada.

Para realizar esta atividade temos as seguintes informações disponíveis:

• da análise inicial das mudanças: item da mudança; palavra-chave da mudança; detalhes da mudança; preocupações, impactos e considerações (iniciais)
• da identificação do item sendo modificado e suas funções: item / interface da mudança e funções 

Devemos agora identificar todas as preocupações relacionadas às mudanças. É uma expansão das preocupações iniciais.

Os pontos preocupantes (concern points) devidos às mudanças refletem como as funções são afetadas negativamente pelas mudanças na perspectiva do cliente (perda da função ou valor para o cliente). 

Se durante a análise inicial das mudanças, o time tiver um conhecimento bem maduro do problema, pode ocorrer que as preocupações iniciais sejam suficientes para a realização desta atividade. Se for necessário analisar com um pouco mais de profundidade, o time pode utilizar uma matriz auxiliar que relacione as mudanças versus as funções. Isso porque uma mudança pode afetar mais de uma função. Essa matriz está ilustrada no quadro a seguir.

Quadro 1114: matriz mudanças versus funções 

A próxima figura ilustra as colunas do formulário que devem ser preenchidas nesta atividade.

Figura 1115: colunas do formulário de DBFM para inserção dos pontos preocupantes

A coluna “Alguma outra preocupação? (revisão)” é preenchida na reunião de revisão e não no primeiro momento.

Em seguida são identificados os efeitos (potenciais), ou seja, os impactos das preocupações potenciais. Veja que os termos são outros comparados com o FMEA, mas trata do mesmo fenômeno. No FMEA definimos efeitos como: “Efeitos são os resultados produzidos quando um modo de falha ocorre, ou seja, são as consequências de um modo de falha. É como um modo de falha seria experienciado e/ou percebido pelos stakeholders. A pergunta que se deve fazer aqui é: O que acontece, quais as consequências, no caso da ocorrência do modo de falha?.

É só substituir preocupações por modos de falha. Veja o quadro de comparação entre as terminologias típicas do FMEA versus do DRBFM, apresentado anteriormente. 

Utilizar os mesmos termos que o FMEA diminuiu a confusão associada à integração entre FMEA e DRBFM.

A próxima figura ilustra as colunas do formulário que devem ser preenchidas nesta atividade.

Figura 1116: colunas do formulário de DBFM para inserção dos efeitos

Esta atividade deve incluir os efeitos percebidos pelo cliente final ou cliente interno relacionado aos sistemas, subsistemas, componentes e serviços associados. Enfim, os efeitos devem considerar considerar outros stakeholders  envolvidos em todo o ciclo de vida do produto.

Índice de severidade

É determinado então então o índice de severidade do efeito. Algumas empresas definem tabelas específicas para o índice de severidade para o DRBFM diferentes das tabelas para o FMEA, o que consideramos um desperdício. Recomendamos o uso das tabelas já existentes para o FMEA, como as apresentadas na seção “Atividades do método de FMEA tradicional” ou na seção “Atividades do método de FMEA avançado”.

Classificação

Esta coluna serve para se adicionar alguma categoria às preocupações / falhas com o objetivo de se classificá-las em grupos e permitir filtrar a planilha para encontrar alguma informação. Frequentemente, essa classificação é utilizada quando há muitas falhas.

Quando o DRBFM é utilizado de forma integrada com o FMEA, a indicação é que não se analisem muitas preocupações. Neste caso, essa coluna não é utilizada. Este é um cuidado que devemos tomar se a empresa definir um mesmo formulário para o FMEA e o DRBFM.

Uma preocupação pode ter mais de uma causa. Novamente, a terminologia do método DRBFM é equivalente à do FMEA, que define a causa como sendo “os eventos ou estados que provocam os modos de falha”. A pergunta que se deve fazer aqui é “Por que o modo de falha ocorre?”

Algumas publicações sobre DRBFM citam que devem ser encontradas as causas raiz das preocupações.

Relação entre causa e modo de falha

Existe uma relação direta entre uma causa e seu modo de falha resultante. Ou seja, se a causa ocorre, então ocorre o modo de falha, como mostramos no tópico “Cadeia de falha” da seção principal de FMEA.

Identificar a(s) causa(s) raiz do modo de falha, com detalhes suficientes, permite a identificação de controles e planos de ação apropriados. Uma análise de causa potencial separada será realizada para cada causa se houver múltiplas causas.

Neste contexto é importante se identificar o mecanismo de falha intermediário entre a causa e o modo de falha, pois o mecanismo é o fenômeno (físico, químico, elétrico, térmico ou outro), que está por trás do modo de falha.

Índice de ocorrência 

É determinado então então a probabilidade de ocorrência da causa. Algumas empresas definem tabelas específicas para o índice de ocorrência para o DRBFM diferentes das tabelas para o FMEA, o que consideramos um desperdício. Recomendamos o uso das tabelas já existentes para o FMEA, como as apresentadas na seção “Atividades do método de FMEA tradicional” ou na seção “Atividades do método de FMEA avançado”.

A próxima figura ilustra as colunas do formulário que devem ser preenchidas nesta atividade.

Figura 1117: colunas do formulário de DBFM para inserção das causas

A coluna “Alguma outra causa a considerar? (revisão)” é preenchida na reunião de revisão e não no primeiro momento.

Na terminologia do DRBFM, nesta atividade, são listadas as medidas para eliminar os pontos preocupantes. Devem ser listadas as medidas atuais.

Usando a terminologia de FMEA, são os controles de prevenção e detecção atuais / existentes.

Índice de detecção

É determinado então então a probabilidade de detecção que os controles possuem para identificar o modo de falha ou a causa. Algumas empresas definem tabelas específicas para o índice de detecção para o DRBFM diferentes das tabelas para o FMEA, o que consideramos um desperdício. Recomendamos o uso das tabelas já existentes para o FMEA, como as apresentadas na seção “Atividades do método de FMEA tradicional” ou na seção “Atividades do método de FMEA avançado”.

A próxima figura ilustra as colunas do formulário que devem ser preenchidas nesta atividade.

Figura 1118: colunas do formulário de DBFM para inserção das medidas ou controles atuais para evitar as preocupações ou falhas

Neste ponto é bom salientar as diferentes versões dessas colunas, que refletem a lógica do FMEA.

No FMEA, há uma coluna para o controle de prevenção e outra para o controle de detecção. Isso porque o controle de prevenção é considerado quando se estabelece o valor da probabilidade de ocorrência da causa. Ou seja, o controle de prevenção está associado à causa. A probabilidade de ocorrência da causa considera a efetividade do controle de prevenção.

Assim, a probabilidade de detecção considera somente o controle de detecção e não o de prevenção.

Como o DRBFM tradicional analisa somente as mudanças, que devem ser poucas, e não faz sentido determinar o índice de ocorrência, não importa destacar em colunas separadas o que é controle de prevenção de controle de detecção. Mas é recomendado que se coloque entre parênteses, após o registro de um controle, um P (se for um controle de prevenção) ou um D (se for um controle de detecção).

As empresas que unificam os formulários de FMEA e de DRBFM (como discutido no tópico “Formulários de DRBFM”) criam somente uma coluna para ambos ou as duas colunas citadas.

Na figura 1118 acima, mostramos três colunas, que são do formulário MAP0059 de DRBFM. Essa divisão é encontrada em algumas propostas de formulários para o desenvolvimento do DRBFM. Nessa proposta:

•  os controles de design / projeto são de prevenção e são empregados durante o desenvolvimento, antes da construção de um protótipo funcional a ser testado.
• os controles de avaliação / testes representam os controles de prevenção atuais, que são empregados depois dos testes dos protótipos
• os controles da manufatura são os de detecção, usados quando o item estiver em produção.

Cada empresa deve adotar um layout de formulário de DRBFM alinhado com as suas práticas de análise de falhas.

A partir deste momento, iniciam as atividades da segunda etapa de desenvolvimento do DRBFM, a revisão do design.

Uma prática recomendada pelos manuais de DRBFM de algumas empresas é que a realização das atividades descritas até agora sejam realizadas por uma ou duas pessoas, visando aumentar a eficiência do processo. 

Nesses casos, o time responsável pelo DRBFM revisa todo o preenchimento anterior.

O(s) responsável(eis) inicia a sessão explicando em detalhes a proposta de alteração do produto. Protótipos físicos ou representações (maquetes) que refletem as alterações propostas são essenciais para garantir a compreensão e a promoção de uma boa discussão entre os membros da equipe. Modelos matemáticos e desenhos também são benéficos, mas todos os participantes devem ser capazes de visualizar facilmente as informações simultaneamente.

Essa revisão pode resultar na inserção de novas linhas no formulário ou na inserção de itens adicionais nas colunas marcadas com “(revisão)”?

É muito importante que nessa atividade sejam realizadas discussões rigorosas, que esgotem todas as possibilidades (Good Discussion do Mizen Boushi).

Novamente, por meio de uma discussão rigorosa, o time de revisão recomenda quais ações devem ser executadas para abordar possíveis preocupações e/ou causas, a fim de mitigar ou eliminar os riscos e melhorar a satisfação do cliente.

Esta atividade é semelhante às atividades:

• Planejamento e execução de ações do método de FMEA tradicional ou
• Otimização do método de FMEA avançado

A próxima figura ilustra as colunas do formulário que devem ser preenchidas nesta atividade.

Figura 1119: colunas do formulário de DBFM para inserção das ações recomendadas

Repare na figura anterior, que o template de formulário que estamos utilizando como exemplo também é dividido em três partes. Essas colunas devem ser compatíveis com as colunas dos controles de prevenção e detecção atuais. Mas cada empresa estabelece o seu formulário de DRBFM.

Coluna relacionada ao design

Nesta coluna, são documentadas ações de prevenção específicas que devem ser implementadas no design do produto para eliminar ou mitigar o risco de preocupações potenciais específicas:

• As ações de design propostas são suficientes para prevenir a ocorrência dessas preocupações potenciais?
• A mudança de design é a única solução viável?
• Existe outra maneira de eliminar a preocupação (modos de falha, causas e controles) potencial?
• As ações de design estão tecnicamente corretas?

Coluna relacionada à avaliação e testes

Nesta coluna, registram-se as ações de prevenção específicas a serem executadas na validação da mudança de design:

• Existe um modelo matemático que possa validar essa alteração?
• Onde devem ser aplicados os modelos matemáticos ?
• Há um teste de desenvolvimento que permita identificar esse modo de falha? É necessário desenvolver um novo teste?
• Existe um teste de desenvolvimento capaz de detectar essa preocupação potencial (modo de falha), incluindo testes realizados pelo fornecedor? Há necessidade de um novo teste?
• O método de avaliação especificado é adequado?

Coluna relacionada à manufatura

Nesta coluna, detalham-se as ações específicas de detecção que devem ser realizadas no processo de fabricação ou montagem (manufatura) dentro da empresa ou no fornecedor para eliminar ou mitigar o risco de preocupações (modos de falha, causas e efeitos) potenciais específicas.

• Foi considerada uma alteração no processo para eliminar essas preocupações potenciais
• A mudança demanda uma alteração no processo? Em caso afirmativo, qual é o impacto?
• Esta mudança exige alterações no design dos componentes do fornecedor, testes ou outras ações?

Definição de responsáveis

O time de revisão define as pessoas responsáveis pela execução das ações recomendadas, assim como as datas planejadas para a finalização das ações. Se nenhuma ação for necessária, deve-se preencher “Nenhuma” na célula apropriada.

Caso a empresa esteja utilizando os índices de severidade, ocorrência e detecção no DRBFM, eles devem ser atualizados após a finalização das ações.

Da mesma forma, o número de prioridade do risco (NPR) ou a prioridade da ação devem ser recalculados.

Após a execução das ações recomendadas, deve-se inserir os resultados na última coluna do formulário “Resultados das ações (status)”.

Provavelmente, o status inicial de uma ação é “planejada”. Depois da implementação da ação é “finalizada”. Podem existir status intermediários, tais como, “cancelada”.

Como a aplicação do DRBFM é integrada com a do DFMEA, as linhas correspondentes devem ser transferidas para o formulário do DRBFM quando completadas.

Essa atividade não agrega valor e por isso as empresas devem estabelecer uma dinâmica de trabalho nos seus procedimentos, que minimizem a burocracia.

Uma solução é aplicar softwares de FMEA & DRBFM, que já tratam as informações dos dois métodos de forma integrada. Os formulários citados tornam-se relatórios específicos nesses softwares. Principalmente o de FMEA para apresentar para os clientes dentro do contexto do PPAP e APQP da  IATF 16949:2016.

Segundo Kano & Shimizu (2001), durante a reunião, os membros da equipe deveriam utilizar a criatividade e atenção para identificar diversos fatores no debate sobre as preocupações (modos de falha) e suas causas relacionadas às mudanças.

Primeiramente, pense nas preocupações que podem resultar das mudanças antecipadas, colocando-se no lugar dos seus clientes. (Observe as mudanças feitas deliberadamente e aquelas resultantes delas.)

Considere as condições ambientais operacionais (estresses) e pense nos fatores, começando pelos materiais e avançando para as formas e processos de fabricação.

Tenha um debate sobre as causas das variações (como dimensões e fabricação).

Pense não apenas nos fatores mecânicos, mas também nos químicos, como:

• Corrosão elétrica (a formação de baterias locais devido ao contato entre metais diferentes e corrosão nos espaços: como a corrosão devido a uma atmosfera de ácidos ou álcalis)
• Efeitos de óleos e solventes e daqueles de vários aditivos e cargas
• Efeitos de produtos gerados pela deterioração (como óxidos)
• Para óleos e solventes, considere o estado de novos artigos e os efeitos da deterioração.

As variações no processo de fabricação também devem ser consideradas. Se os métodos de controle de material e as condições de fabricação podem afetar o desempenho dos componentes, deve-se ter um debate suficiente sobre os fatores relacionados ao processo de fabricação. Caso tais variações não forem identificadas no DRBFM, elas devem ser discutidas no FMEA de processo (PFMEA).

Apesar de termos listados a “Análise inicial das mudanças” como uma primeira atividade de desenvolvimento do DRBFM, a ser realizada pelo grupo 1 (designer responsável e facilitador), esta  atividade pode ser realizada diariamente por todos que estiverem envolvidos no desenvolvimento do produto, processos e serviços. 

Sempre que alguém perceber uma preocupação de um risco associado a uma mudança, ela(e) deve ter a possibilidade de reportar sem burocracia essa preocupação, para que ela seja posteriormente analisada tanto em uma sessão de DRBFM, como de uma maneira menos formal.

Em uma revisão técnica de projeto (design review) é comum ouvir as pessoas dizerem “essas reuniões servem somente para reportar o que foi realizado e como o projeto está”. Isso ocorre porque é colocado uma ênfase no aspecto administrativo de um design review (Kano  & Shimizu, 2001).

Segundo Kano & Shimizu (2001) … 

… essa ênfase administrativa “tem contribuído para estabelecer o conceito de revisão de design no processo de desenvolvimento; contudo, o resultado é a perda de significado, pelos profissionais envolvidos, na identificação das questões fundamentais das revisões de design”. Por isso, …

… eles recomendam o uso do DRBFM na revisão de design para que “os indivíduos reconheçam os problemas e implementem ações corretivas”. 

O DRBFM identifica todas as questões antecipadas para avançar no debate por meio de checklists e formulários. Como consequência, o design (projeto), a avaliação (testes), a fabricação (manufatura) e a garantia de qualidade dos itens estarão organicamente interligados, o que, presumivelmente, possibilitará adotar medidas de design preventivas contra problemas.

Muitas vezes não podemos controlar a quantidade de mudanças. Mas se estivermos realizando uma inovação incremental e, consequentemente, partindo de um projeto (design) existente e criando um novo projeto (design), conhecido como “carry-over” no jargão profissional, devemos nos preocupar com que quantidade de mudanças.

Se a quantidade de mudanças para um projeto “carry-over” for menor, “o time de desenvolvimento é capaz de se aprofundar na discussão sobre as mudanças” (Allan, 2009). Como Allan (2009) exemplifica:

“Por exemplo, se você fizer 20 alterações em seu design, não será capaz de se aprofundar adequadamente em cada uma dessas alterações. No entanto, se você fizer três alterações em seu design, terá a capacidade de se aprofundar e discutir minuciosamente cada alteração.”

Ser capaz de minimizar o número de alterações volta à premissa original de minimizar a quantidade de mudanças ao iniciar um novo design a partir de um design estável e robusto.

A determinação desses índices para o DRBFM é questionável. Se são poucas mudanças e todas devem ser analisadas em profundidade, por que determinar os índices de severidade, ocorrência e detecção?

Não iremos calcular o número de prioridade de risco (NPR) e nem a prioridade de ação, pois todas as preocupações e ações correspondentes devem ser identificadas e determinadas, respectivamente.

O uso do mesmo formulário pode induzir a esta prática. Por isso, quando a empresa estiver utilizando o FMEA integrado ao DRBFM, é importante definir o procedimento a ser utilizado. No entanto, há empresas que utilizam somente o formulário de DRBFM e não mais o de FMEA. Neste caso, não se trata mais de aplicar o DRBFM somente para mudanças.

“Os designers relutam em participar de uma revisão de design. “Eles nos apresentam todas essas reclamações infundadas, nos sobrecarregam com uma enorme quantidade de tarefas e não nos oferecem nenhum conselho útil. Se alguém alega compreender estas questões melhor do que nós, os designers, que se atrevam a falar!” É provável que esse seja o pensamento de tais designers. Enquanto os designers mantiverem essa mentalidade, uma revisão de design não terá sucesso” (Kano  & Shimizu, 2001).

Segundo Kano & Shimizu (2001), …

… ao participarem de uma sessão de DRBFM, os designers deveriam pensar: “isso vai estimular nossos cérebros e nos inspirar”. Eles devem organizar os itens da pauta para debate na sessão de DRBFM.

Caso alguma revisão de design não os tenha inspirado, devem considerar que a falha foi deles.

Ao realizar uma revisão de design com um fornecedor, alguns designers limitam-se a dizer “Está tudo bem!” independentemente do que o fornecedor apresente, pois esses designers estão excessivamente empenhados em enfatizar que seu sistema está livre de problemas. Tais revisões de design são um fracasso.

“O sucesso em uma sessão de DRBFM depende significativamente do coordenador da sessão. O coordenador deve criar um ambiente onde os participantes possam se sentir à vontade, mantendo um nível adequado de tensão para que as opiniões dos especialistas sejam suficientemente ouvidas, evitando assim discussões unilaterais. É crucial conduzir o debate, mantendo-se constantemente consciente da necessidade de concentrar a atenção dos participantes em um único ponto e, posteriormente, expandi-la para o espectro completo” (Kano  & Shimizu, 2001).

O debate no DRBFM não deve contar apenas com a participação dos designers / projetistas de componentes, mas também com representantes da áreas de materiais, testes, qualidade, manufatura e outras operações. Eles devem discutir as preocupações sob diversos pontos de vista e identificar os problemas. Ao participar de uma revisão de design, não se deve adotar uma postura passiva, pensando “Vou receber algumas sugestões”. Quando se está em uma sessão de DRBFM, deve-se estar preparado para pensar “Vou auxiliar os designers com minha própria expertise. Qualquer problema com este sistema seria de minha responsabilidade” (Kano  & Shimizu, 2001).

Um checklist pode ser usado para contribuir para o preenchimento do formulário de DRBFM. Checklist é algo a ser considerado. O drbfm é algo para definir requisitos para uma característica de um design (projeto) específico.

Preencher o formulário com frases amplas  e genéricas, tais como, “de acordo com os padrões (standards) de design” ou “realize testes de desempenho” deixa margem para ambiguidades.

Utilize, então, expressões mais concretas e específicas, tais como, “assegure um valor de rugosidade de 0,5 microns” ou “efetue a medição das dimensões e tolerâncias das peças deslizantes após o teste de durabilidade de operação”.

Como está no formulário do DRBFM, especifique um departamento responsável, uma pessoa responsável e um prazo para os itens discutidos em termos das ações corretivas. Identifique os itens a serem refletidos no design, avaliação (testes) e fabricação (manufatura).

Depois de completar as discussões detalhadas e a determinação de ações, veja quais itens devem ser complementados no DFMEA e PFMEA.

Esta atividade depende do procedimento de integração entre o FMEA e o DRFM, assim como a integração de ambos com o processo de desenvolvimento de produtos, que foram estabelecidos na atividade “Implementação do DRBFM”.

Verifique se os itens discutidos no DRBFM estão de fato refletidos nos desenhos e nos itens de avaliação e se eles efetivamente “previnem falhas”. Você deve responder às seguintes questões:

• os itens listados em “itens a serem refletidos no design” estão refletidos nos desenhos do componente?
• os itens listados em “itens a serem refletidos na avaliação (testes)” estão refletidos nos itens de avaliação e nas condições de avaliação? Uma avaliação real foi conduzida?
• os itens listados em “itens a serem refletidos no processo de fabricação” estão refletidos nos itens de controle e inspeção do processo de fabricação?

Na proposta de Allan (2019), aplicada na empresa Delphi Thermal Systems, são definidos três momentos de aplicação do DRBFM para uma mudança de design:

• depois da definição do conceito do produto – realizar a análise dos pontos de mudança (que a autora não considera como sendo a aplicação do DRBFM, mas nós consideramos como uma das primeiras atividades – análise inicial das mudanças)
• 1) depois do detalhamento do projeto (design) – aplicar o DRBFM para as mudanças
• 2) depois das construção do protótipo, dos testes e validação – aplicar o DRBTR (design review based on test results) para validar que todas as ações foram realizadas com sucesso
• 3) depois do produto já estar sendo produzido e entregue – aplicar o DRBD&P (design review based on design and process) para validar todo o processo comparando as peças que foram produzidas com o ferramental de produção com aquelas produzidas durante a fase de prototipagem e testes.

Procure pegar as peças em mãos para explorar todas as possibilidades de falhas. Como é uma mudança, comece com as peças do produto base, anterior. Se as mudanças forem significativas, avalie a possibilidade de imprimir a peça por meio da manufatura aditiva.

Explore os detalhes, veja em itens estruturais as partes internas, os reforços etc.

O checklist MAP0043 é utilizado na atividade “Identificação da estrutura”
MAP0043 – Checklist de possíveis informações de produto, processo, serviço para desenvolvimento do FMEA 

Checklist para identificar pontos de mudança a ser utilizado na atividade “Análise inicial das mudanças”.
MF.MAP0057 – DRBFM checklist identificação mudanças

A  tabela de comparação entre o design original e o novo design é baseada no checklist anterior e ser para identificar as mudanças
MF.MAP0058  – tabela de comparação entre o design original e o novo design

O formulário para desenvolvimento do DRBFM é composto por duas abas:

• formulário unificado (que usamos como referência nesta seção)
• formulário separado (que deixamos somente como uma ilustração)

MF.MAP0059 – formulário de DRBFM

Allan, L. Change (2009). Point Analysis and DRBFM: A Winning Combination. Reliability Edge, v.9, n.2, p.16-21. Disponível (versão atualizada) em: https://www.hbkworld.com/en/knowledge/resource-center/articles/change-point-analysis-and-drbfm-a-winning-combination Acesso em: 8 março 2024.

Dolsen, M., Legary, E., & Phillips, M. (2016). Mizen Boushi in Mass Production: A framework for maintaining reliability in a dynamic environment. Proceedings of the International Conference on Industrial Engineering and Operations Management, 886–896.

Haughey, B. (2019). Linking design reviews with FMEA to quickly mitigate the risk of change: Design review based on failure modes-drbfm. Proceedings – Annual Reliability and Maintainability Symposium, 2019-January, 1–5.

Kano, S., & Shimizu, H. (2001). A Guide to GD3 Activities and DRBFM Technique to Prevent Trouble. Ver. 5.0Vehicle Technology Dept, 1.

Laurenti, R. (2010). Sistematização de problemas e práticas da análise de falhas potenciais no processo de desenvolvimento de produtos. Dissertação de Mestrado, Escola de Engenharia de São Carlos, Universidade de São Paulo, São Carlos. Disponível em: https://www.teses.usp.br/teses/disponiveis/18/18156/tde-15092010-093659/pt-br.php Acesso em: 12 fevereiro 2024.

Morgan, J.M. (2002). High performance product development: a systems approach to a lean product development process. 408p. Doctoral Thesis (Doctor of Philosophy) – Industrial and Operations Engineering, University of Michigan, Michigan.

Morgan, J.M.; Liker, J.K. (2020). The Toyota Product Development System: Integrating People, Process and Technology: Productivity Press.

Repenning, N.P.; Sterman, J.D. (2001). Nobody Ever Gets Credit for Fixing Problems that Never Happened: Creating and Sustaining Process Improvement. California Management Review, v.43, p.64 – 88.

Shimizu, H., Otsuka, Y., & Noguchi, H. (2010). Design Review Based on Failure Mode to visualise reliability problems in the development stage of mechanical products. International Journal of Vehicle Design, 53(3), 149–165. https://doi.org/10.1504/IJVD.2010.033827 

Schorn, M. (2005). Entwicklung mit System: Wie Toyota von DRBFM profitiert. Management und Qualität, v.12, p.8-11.

Sobek, D.K.; Liker, J.K.; Ward, A.C. (1998). Another Look at How Toyota Integrates Product Development. Harvard Business Review, v.76, n.4, p.36 – 50.