Design for six sigma

flexM4I > abordagens e  práticas > business intelligence (BI) and analytics > Design for six sigma (versão 2.3)
Autoria: Henrique Rozenfeld ([email protected])

O DFSS surgiu da metodologia de qualidade Seis Sigma e estabelece processos alternativos ao Define-Measure-Analyze-Improve-Control (DMAIC) voltados ao desenvolvimento (design) de novos produtos e/ou processos de fabricação, com a aplicação de técnicas estatísticas para “projetar corretamente pela primeira vez” minimizando o efeito de fontes de vulnerabilidades do design que podem se propagar para a produção e fase de uso dos produtos.
Esta seção é introdutória voltada para os níveis de detalhamento básico e executivo. 

Definição

O DFSS (Design for Six Sigma) é uma metodologia de desenvolvimento (design) de novos produtos e/ou processos de fabricação, que desde o início tem o objetivo de alcançar uma redução significativa da quantidade de não conformidades e variações no produto e na produção, utilizando diversas ferramentas, com foco na aplicação de técnicas estatísticas. 

O DFSS ajuda a atender a “voz do negócio”  (voice of the business) ao gerar lucros por meio dos produtos, ao satisfazer a “voz do cliente” (VOCvoice of customer) ao entregar valor por meio de novos produtos (Creveling  et al., 2003).

O DFSS traz para o desenvolvimento de produtos os conceitos de six-sigma (Echeveste et al., 2016).

O objetivo do DFSS é “projetar corretamente pela primeira vez” antecipando o efeito das seguintes fontes de vulnerabilidades de design (Yang & El-Haik, 2009):

  • vulnerabilidades conceituais que são estabelecidas devido à violação de axiomas e princípios de design e
  • vulnerabilidades operacionais devido à falta de robustez no ambiente de uso. A eliminação ou redução das vulnerabilidades operacionais é o objetivo das iniciativas de qualidade, incluindo o Seis Sigma.

Origem

O DFSS surgiu das metodologias de qualidade Seis Sigma e Define-Measure-Analyze-Improve-Control (DMAIC), que foram originalmente desenvolvidas pela Motorola para melhorar sistematicamente os processos eliminando defeitos.

Segundo Mettas (2010), ao contrário de seus predecessores tradicionais Seis Sigma/DMAIC, que geralmente se concentram em resolver problemas de fabricação existentes (ou seja, “apagar incêndios”), o DFSS visa evitar a ocorrência de problemas futuros. Para isso, o DFSS adota uma abordagem proativa para a resolução de problemas e envolve os esforços da empresa, em um estágio inicial ,para reduzir problemas que possam ocorrer (ou seja, “prevenção de incêndios”).

Mettas (2010) trata do Design for Reliability (DFR – Design para Confiabilidade) e destaca sua diferença em relação ao DFSS. Enquanto o DFSS busca atender aos CTQs (Critical to Quality), nem todos esses requisitos se tornam parâmetros críticos. Apenas aqueles que podem resultar em falhas são traduzidos em parâmetros de confiabilidade (CTRs), devendo ser avaliados por técnicas específicas de DFR. Para mais detalhes, consulte o verbete sobre Design for Reliability no glossário da flexM4i.

Processos – etapas

O DFSS parte de uma compreensão das expectativas e necessidades dos clientes para definir questões críticas para a qualidade (CTQ – critical to quality) nas fases iniciais de desenvolvimento. Ou seja, todos os processos consideram o CTQ. 

Assim como o Seis Sigma/DMAIC, o DFSS divide o desenvolvimento em dois processos (Echeveste et al., 2016):

  • para o desenvolvimento tecnológico, o DFSS utiliza, o I2DOV (invent, innovate,development, optimize and verify) e
  • para o desenvolvimento comercial, o DFSS utiliza, o CDOV (concept, design, optimize and verify).

Esses dois exemplos podem ser realmente associados ao desenvolvimento tecnológico e comercial. Mas não existe consenso na literatura sobre a classificação das demais variações do DFSS nesse mesmo critério. A maior parte desses acrônimos surgiu como adaptações organizacionais em contextos específicos, razão pela qual optamos por apresentá-los em lista única, sem distinção rígida entre processos tecnológicos e comerciais.

Staudter et al. (2009) descrevem o processo DMADV  (define, measure, analyze, design, verify) no contexto da aplicação conjunta do DFFS com o lean design.

Uma variação do DMADV é o IDDOV (identify, define, development, optimize e verify), que coloca uma ênfase na otimização (Fioravanti, 2005). Existe também o IDOV (identify, design, optimize e verify).

Yang & El-Haik (2009) descrevem o processo ICOV (identify requirements, characterize the design, optimize the design, verify the design). O “characterize the design”, que comumente é denominado de “define (D) no processo IDOV, inclui:

  • traduzir os requisitos dos clientes (CTS: critical-to-satisfaction) em requisitos funcionais do produto / processo;
  • gerar alternativas de design;
  • avaliar as alternativas de design.

No próximo tópico descrevemos de forma sucinta as características dessas variações do DMAIC.

Características de variações de processos de DFSS

  • DMADOV: Define, Measure, Analyze, Design, Optimize, Verify
    Variante que preserva a lógica analítica do Six Sigma no desenvolvimento de ofertas. Boa para novos produtos comerciais com requisitos de qualidade críticos.
  • DMEDI: Define, Measure, Explore, Develop, Implement
    Enfatiza a fase de exploração de alternativas antes do desenvolvimento e implementação. Aplicado quando ainda há diversos caminhos de solução possíveis.
  • I2DOV: Identify, Invent, Design, Optimize, Verify
    Focado na criação de soluções tecnológicas inovadoras. A ênfase está em inventar antes de projetar, adequado a contextos de alta incerteza tecnológica.
  • DDOV: Define, Design, Optimize, Verify
    Variante compacta, usada quando o problema já está bem definido, reduzindo o esforço exploratório.
  • PIDOV: Plan, Identify, Design, Optimize, Verify
    Dá ênfase ao planejamento inicial, estruturando cronogramas e recursos desde o início do desenvolvimento tecnológico
  • DMADIC: Define, Measure, Analyze, Design, Implement, Control
    Derivação mais próxima do DMAIC, porém aplicada ao design. A lógica é detalhar estatisticamente antes de implementar e controlar a solução.
  • DCCDI: Define, Customer, Concept, Design, Implement
    Reforça a centralidade da voz do cliente (Customer) e traduz diretamente essa visão em conceitos de design.
  • DCOV: Define, Characterize, Optimize, Verify
    Destaca a fase de caracterização para entender melhor parâmetros críticos do produto/mercado antes de otimizar e validar.
  • CDOV: Concept, Design, Optimize, Verify
    Muito usado para novos produtos/serviços no mercado. Começa com conceito de negócio, passa ao design e valida sua viabilidade.
  • DMADV: Define, Measure, Analyze, Design, Verify
    Bastante conhecido, combina análise quantitativa com verificação final. Focado em assegurar robustez de produtos e serviços antes do lançamento.
  • IDDOV: Identify, Define, Design, Optimize, Verify
    Acrescenta a etapa de definição, dando mais rigor na tradução das necessidades do cliente em requisitos técnicos.
  • IDOV: Identify, Design, Optimize, Verify
    Estrutura simples e voltada a desenvolvimento de tecnologia ou produto com foco em desempenho técnico e validação da robustez.
  • ICOV: Identify, Characterize, Optimize, Verify
    Variante próxima do DCOV, mas começa com identificação de oportunidades/necessidades de mercado, caracterizando antes de otimizar.

Comparação de alguns processos

O quadro a seguir apresenta uma comparação entre alguns desses processos para o desenvolvimento comercial. Algumas etapas de processos diferentes abrangem atividades de outras etapas. 

Quadro 1165: quadro de alguns processos de DFSS (clique na imagem para abrir em uma outra aba)

Essas etapas de processo servem para estruturar atividades e ferramentas do DFSS. Não devem ser utilizadas como fases de um projeto, que é um conceito de gestão de projeto. Consulte a definição de fase de um projeto no glossário.

As etapas destacadas no quadro anterior estão sucintamente descritas no próximo tópico.

Etapas dos processos de DFSS

Utilizamos como referência o quadro 1165 do tópico anterior. Descrevemos as etapas que caracterizam de uma forma mais completa esses processos, sem descrever duas vezes a mesma etapa que faz parte de mais de um processo.

Identify (IDOV/IDDOV)
Etapa voltada para a identificação das necessidades do cliente e das oportunidades de mercado ou tecnológicas. Inclui a coleta de informações da voz do cliente (VOC), análise de lacunas de mercado, estudo de tendências e benchmarking. No caso de contextos tecnológicos, envolve também identificar restrições técnicas e requisitos regulatórios que irão direcionar o desenvolvimento.

Define (DMADV)
Consiste em delimitar claramente o escopo do projeto, traduzindo as necessidades identificadas em requisitos críticos para a qualidade (CTQs). Nessa fase, definem-se também objetivos estratégicos, cronograma macro, recursos envolvidos e indicadores de desempenho que servirão de referência para medir o sucesso do projeto.

Measure (DMADV)
Dedicada a coletar dados e estabelecer a linha de base do desempenho atual ou da situação inicial. Inclui o mapeamento de processos existentes, a mensuração de variáveis-chave, a validação de sistemas de medição (quando aplicável) e a priorização de requisitos segundo sua importância para o cliente.

Analyze (DMADV)
Etapa analítica, onde os dados coletados são utilizados para identificar causas fundamentais, avaliar alternativas de solução e projetar cenários futuros. São aplicadas ferramentas estatísticas e de modelagem para validar hipóteses e direcionar decisões de design.

Concept (CDOV)
Etapa inicial do desenvolvimento comercial, em que se geram conceitos de produto ou serviço que atendam aos CTQs. Nesta etapa podemos aplicar a House of Quality (QFD) para traduzir VOC/CTQs em características de engenharia, comparar conceitos alternativos e definir metas do projeto conceitual. Inclui também uma análise inicial de viabilidade técnica e econômica, e a seleção da melhor proposta para avançar às fases seguintes.

Design (CDOV)
Responsável pela tradução do conceito em um projeto detalhado, envolvendo a definição de especificações de produto/serviço, modelagem de processos de entrega, prototipagem e análise de riscos. Aqui detalhamos as especificações, tolerâncias, aplicamos DfX, FMEA e plano de controle. Se adotado QFD em cascata, realizam-se os desdobramentos para partes, processos de fabricação e montagem.

Observe no quadro,  que em outros processos as etapas de “concept” e “design” são unificadas em uma única fase, denominada “design” ou “development”. 

Optimize (CDOV)
Concentra-se em refinar o design e os processos por meio de experimentação, simulações e ferramentas como DOE (Design of Experiments). O objetivo é maximizar desempenho, minimizar variabilidade e garantir robustez frente a diferentes condições de uso ou produção.

Verify (CDOV)
Etapa final, voltada para validar se o produto/serviço atende aos CTQs e aos objetivos definidos. Inclui testes-piloto, validações em campo, análises de confiabilidade e auditorias de conformidade. O foco é assegurar que a solução está pronta para implementação plena, sem comprometer a satisfação do cliente ou a performance do negócio.

Protótipos somente agora?

Nas etapas de “Optimize” e “Verify”são criados os protótipos que serão ensaiados. Nas versões mais atuais de design / desenvolvimento, já na etapa de “Concept”, frequentemente, são criados protótipos de baixa fidelidade, ou MVP, para validar o product-market fit.

Essa variação depende do nível de incerteza da inovação. Perante incertezas, precisamos testar o conceito o mais cedo possível. Em inovações incrementais ou variantes de uma plataforma, podemos prototipar somente nas fases posteriores, após o detalhamento. Mas mesmo nesses casos, as hipóteses de valor e de mercado precisam ser validadas.

Na etapa de “Verify”, avaliamos ainda se os produtos resultantes do processo produtivo atendem aos CTQs, ou seja, avaliamos, homologamos ou certificamos dessa forma o processo produtivo.

Ferramentas

Segundo Echeveste et al. (2016), a base do DFSS é a integração de ferramentas como desdobramento da função de qualidade (QFD), a matriz de Pugh, com ferramentas estatísticas de análise multivariada e design of experiments (DOE). Outros exemplos de ferramentas que podem ser aplicadas no DFF são: design axiomático, Design for X (DfX),  método Taguchi, design de tolerância (tolerance design), Análise De Modos De Falha (FMEA) e Metodologia de Superfície de Resposta para otimização de uma única ou múltiplas respostas. 

Ao combinar essas ferramentas, as necessidades dos clientes são identificadas, das quais derivam os requisitos e os parâmetros do sistema de engenharia que aumentam a eficácia do produto e do serviço aos olhos do cliente e de todas as outras pessoas.

Para Creveling et al. (2003), o principal desafio no uso do DFSS no desenvolvimento de produtos é usar a ferramenta certa no momento certo ao longo do ciclo de desenvolvimento do produto. As ferramentas aplicadas ao DFSS são bem-sucedidas se estiverem relacionadas com os objetivos das atividades do desenvolvimento de produtos, considerando capacidade, estratégia e métricas voltadas para o cliente.

Trata parcialmente da confiabilidade?

Segundo Mettas (2010), normalmente, em um programa DFSS, apenas uma pequena parte das CTQs (critical to quality) está relacionada à confiabilidade (CTR – critical do reliability) e, portanto, a confiabilidade não recebe atenção central no DFSS. O DFSS raramente aborda problemas de longo prazo (após a fabricação) que possam surgir no produto (por exemplo, problemas de fadiga complexos ou desgaste elétrico, problemas químicos, efeitos em cascata de falhas, interações de nível de sistema).

Este ponto é polêmico. Como vimos no tópico “DOE como ponto comum entre design for six sigma e design for reliability”, o DFSS também pode aplicar a ferramenta “Design of experiments (DOE)”. Isso significa que se os ruídos das condições de aplicação do produto forem identificados, considerados e modelados nos experimentos (testes dos produtos), provavelmente a sua robustez será maior. Ou seja, a sua confiabilidade será maior (taxa de falhas menor e aceitável). Porém, como mostra a ilustração da figura abaixo, outras ferramentas de design for reliability (design para confiabilidade) precisariam ser empregadas.

Figura 944: principais ferramentas do design for six sigma (DFSS) e do Design for reliability (DfR)
Fonte: adaptação de Metas (2010)

Difusão em empresas brasileiras

Echeveste et al. (2016) desenvolveram um estudo para discutir como empresas brasileiras estão conduzindo programas para aplicar o six sigma no desenvolvimento de produtos, ou seja, para aplicar o DFSS. Foram avaliadas onze empresas.

Algumas das principais conclusões deste estudo são:

  • Projetos que aplicam o DFSS poderiam ser considerados no balanceamento de projeto como critério de priorização durante o planejamento do portfólio;
  • Apesar dos esforços já realizados pelas empresas na difusão e emprego de técnicas estatísticas, esse emprego não é visto como algo simples, o que limita o seu uso potencial. Portanto, a recomendação é que a aplicação de DFSS deve ser expandida treinando mais pessoas nas suas ferramentas;
  • A aplicação de quaisquer dos processos de DFSS deveria ser incorporada na empresa para que o estabelecimento de objetivos e decisões sejam baseados em procedimentos técnicos e menos empiricamente (tentativa e erro);
  • O conhecimento do DFSS pode construir uma cultura de resolução de problemas como parte da rotina das empresas brasileiras para promover avanços tecnológicos por meio do entendimento dos fenômenos que embasam a entrega de valor dos produtos.
O artigo apresenta uma tabela que compara os principais temas de aplicação do six sigma comparando a teoria com a realidade prática encontrada nas empresas avaliadas.

Referências

Creveling C, Slutsky J, Antis D (2003) Design for Six Sigma in technology and product development. Prentice Hall Professional, Upper Saddle River

Echeveste, M. E., Rozenfeld, H., & Sonego, M. (2016). Potential application of Six Sigma tool in the integrated product development process. Journal of the Brazilian Society of Mechanical Sciences and Engineering, 38(8), 2499–2511. https://doi.org/10.1007/s40430-016-0503-0

Fioravanti, A. (2005). Aplicação da metodologia ‘Design for Six Sigma’ (DFSS) em projetos automotivos. Dissertação de Mestrado, Escola Politécnica, Universidade de São Paulo, São Paulo. doi:10.11606/D.3.2005.tde-26122014-174443. Recuperado em 2024-08-27, de www.teses.usp.br

Mettas, A. (2010). Design for reliability: Overview of the process and applicable techniques. International Journal of Performability Engineering, 6(6), 577–586.

Staudter, C., Mollenhauer, J. P., Renata, R., Roenpage, O., Von Hugo, C., & Hamalides, A. (2009). Design for Six sigma+ lean toolset: implementing innovations successfully. Berlin, Heidelberg: Springer Berlin Heidelberg.

Wikipedia contributors. (2023, April 19). Design for Six Sigma. In Wikipedia, The Free Encyclopedia. Disponível em: https://en.wikipedia.org/w/index.php?title=Design_for_Six_Sigma&oldid=1150650753 Acesso em: 15 agosto 2023

Yang, K., & El-Haik, B. S. (2009). Design for six sigma: a roadmap for product development. McGraw-Hill Education.

#printfriendly a { color: blue !important; text-decoration: underline !important; } #printfriendly i, #printfriendly em { color: purple !important; } @media print { .break-page-before { page-break-before: always !important; } h1 { page-break-before: always !important; font-size: 32px !important; } div.no-page-break-before h1, div.no-break-page-before h1 { page-break-before: avoid !important; } }