UNIVERSIDADE ESTADUAL DE CAMPINAS
Faculdade de Engenharia Mecânica
LEANDRO BARROS FORNASARO
Proposta de uma Metodologia Baseada na RSM
para Projeto do Produto
CAMPINAS
LEANDRO BARROS FORNASARO
Proposta de uma Metodologia Baseada na RSM
para Projeto do Produto
Orientadora: Prof(a). Dr(a). Ludmila Corrêa Alkmin e Silva Coorientador: Prof. Dr. Franco Giuseppe Dedini
CAMPINAS 2020
Dissertação apresentada à Faculdade de Engenharia Mecânica da Universidade Estadual de Campinas como parte dos requisitos exigidos para obtenção do título de Mestre em Engenharia Mecânica, na Área de Mecânica dos Sólidos e Projeto Mecânico.
ESTE TRABALHO CORRESPONDE À VERSÃO FINAL DA DISSERTAÇÃO DEFENDIDA PELO ALUNO LEANDRO BARROS FORNASARO E ORIENTADA PELA PROF(A). DR(A). LUDMILA CORRÊA ALKMIN E SILVA E COORIENTADA PELO PROF. DR. FRANCO GIUSEPPE DEDINI
UNIVERSIDADE ESTADUAL DE CAMPINAS FACULDADE DE ENGENHARIA MECÂNICA DISSERTAÇÃO DE MESTRADO ACADÊMICO
Proposta de uma Metodologia Baseada na RSM
para Projeto do Produto
Autor: Leandro Barros Fornasaro
Orientador: Prof(a). Dr(a). Ludmila Corrêa Alkmin e Silva Coorientador: Prof. Dr. Franco Giuseppe Dedini
A Banca Examinadora composta pelos membros abaixo aprovou esta Dissertação: Prof(a). Dr(a). Ludmila Corrêa Alkmin e Silva
Departamento de Sistemas Integrados Faculdade de Engenharia Mecânica Universidade Estadual de Campinas Prof. Dr. Helio Fiori de Castro
Departamento de Sistemas Integrados Faculdade de Engenharia Mecânica Universidade Estadual de Campinas Dr. Gustavo dos Santos Gioria Departamento Engenharia Central
Pesquisa e Desenvolvimento Schaeffler América do Sul Schaeffler Brasil Ltda.
A Ata de Defesa com as respectivas assinaturas dos membros encontra-se no SIGA/Sistema de Fluxo de Dissertação/Tese e na Secretaria do Programa da Unidade.
Agradecimentos
Este trabalho não poderia ser terminado sem a ajuda de diversas pessoas às quais presto minha homenagem:
À minha orientadora Dra. Ludmila Corrêa Alkmin e Silva pela sua disposição, apoio constante e total direcionamento.
Prof. Dr. Franco Giuseppe Dedini pela co-orientação nesse projeto, se mostrando um grande professor tanto nos quesitos disciplinares, quanto nos quesitos pessoais.
À equipe do LabSin pelo suporte nas entregas do projeto.
Ao Eng. Dr. Efrain Araújo Perini pelo companheirismo em todos os momentos
Aos meus pais pela preocupação e suporte constante.
À grande amiga Carla pela paciência em ler o trabalho várias vezes.
Resumo
O cenário dinâmico de projeto do produto e o crescimento da complexidade desses projetos resultam num aumento de parâmetros de riscos inter-relacionados visando auxiliar os processos de tomada de decisão. Neste contexto, este estudo tem como objetivo apresentar uma visão detalhada sobre a aplicação da metodologia RSM (Matriz de Estrutura de Riscos) que é uma variação da metodologia DSM (Matriz de Estrutura de Projeto) propondo um método para a sua aplicabilidade nas fases da metodologia de projeto no desenvolvimento do produto. Foram verificados possíveis oportunidades de integração, semelhança e diferença através da revisão deste método aplicado ao gerenciamento de riscos para o projeto de produtos. As revisões de literatura da RSM mostram grandes desenvolvimentos para gerenciamento de projetos e processos, mas poucos exemplos teóricos podem ser encontrados para a aplicação do método para projeto do produto. Dessa forma, a contribuição desse trabalho é sintetizar a RSM e a DSM em uma matriz MDM (Matriz de Domínio Múltiplo) permitindo correlacionar funções, componentes e riscos entre si. Os resultados obtidos com os estudos de caso mostraram quão vantajosa é a aplicação e constataram que o método pode ser considerado complementar aos modelos e ferramentas de projeto de produtos tradicionais gerando alguns benefícios, contudo, em trabalhos futuros, sugere-se a utilização de uma ponderação para que sejam obtidos melhores resultados.
Palavras-chave: Gerenciamento de Projetos, Metodologia de Projeto, Matriz de estrutura de Projeto, Gerenciamento de riscos.
Abstract
The dynamic scenario of product design and the complexity growth of these projects has led to increase in inter-related risk parameters in order to assist decision-making processes. In this context, this study aims to present a detailed evaluation on the application of the RSM (Risk Structure Matrix) methodology that is a variation of the DSM (Design Structure Matrix) methodology, in order to verify its applicability at product design methodology phases. The main goal was to verify opportunities of integration, similarity and difference through the review of this existing risk management method for product design. RSM literature reviews show major developments for project and process management, but few theoretical examples can be found for the application of the method for product design. Thus, the contribution of this work is to add the RSM and DSM in an MDM matrix (Multiple Domain Matrix) allowing to correlate functions, components and risks among each other. The results obtained with the case studies showed how advantageous is the application and found that the method can be considered complementary to the models and tools of traditional products design creating some benefits however in future works we suggest the use of a weighting for better results.
Key Words: Project Management, Design Methodology, Design Structure Matrix, Risk Structure Matrix.
Lista de Abreviaturas e Siglas
AHP - Analytic Hierarchy Process
ASME - American Society of Mechanical Engineers BOM - Bill of Material
CAD - Computer Aided Design CAE - Computer Aided Engineering DFMEA - Design FMEA
DFX - Design for Excellence DSM - Design Structure Matrix FAA - Federal Aviation Authority
FMEA - Failure Mode and Effects Analysis FRs - Requisitos Funcionais
FTA - Análise de Árvore de Falha
LabSin - Laboratório de Sistemas Integrados MDM - Multiple Domain Matrix
MIT - Massachusetts Institute of Technology MP – Matriz de Projetos
NASA - National Aeronautics and Space Administration NCs - Necessidades dos Consumidores
OBS - Organization Breakdown Structure PBS - Product Breakdown Structures PFMEA - Process FMEA
PMBoK - Project Management Body of Knowledge PMI - Project Management Institute
PPs – Parâmetros de Projeto
PRAM - Project Risk Analysis and Management QFD - Quality Function Deployment
RNM - Risk Numerical Matrix RSM - Risk Structure Matrix
VOC - Voz do Consumidor VPs – Variáveis de Projeto
Sumário
1 INTRODUÇÃO ... 12 1.1 Objetivos ... 14 1.2 Estrutura do trabalho ... 15 2 REVISÃO BIBLIOGRÁFICA ... 16 2.1 Metodologia de projeto ... 162.1.1 Metodologia de projeto no Brasil ... 19
2.1.2 Modelo de referência de metodologia de projeto ... 21
2.2 Fases relacionadas ao projeto do produto ... 25
2.2.1 Estudo de Viabilidade ... 25
2.2.2 Projeto Preliminar ... 35
2.2.3 Projeto Detalhado ... 37
2.3 FMEA ... 39
2.4 Análise de árvore de falha - FTA ... 41
2.5 Design Structure Matrix - DSM ... 43
2.5.1 Definição da Matriz DSM ... 47
2.5.2 Arquitetura do Sistema ... 51
2.5.3 Vantagens da DSM para modelagem da estrutura de sistemas ... 54
2.5.4 Abordagem da DSM através de modelagem estrutural e análise. ... 55
2.5.5 Tipos de Modelos de DSM ... 56
2.5.6 DSM do Produto ... 59
2.5 Exemplos de DSM do Produto e Análise ... 71
2.5.1 Motor Pratt & Whitney ... 72
2.5.2 Aplicação da Tecnologia NASA para tracer de Marte ... 73
2.5.3 Helicóptero de Mudança de propagação AgustaWestland ... 76
2.6 Risk Structure Matrix - RSM ... 78
2.7 Relacionamento entre DSM e RSM ... 87
3 METODOLOGIA E ESTUDOS DE CASO ... 91
3.1 Caracterização ... 91
3.2 Considerações para os estudos de caso ... 92
3.2.1 Escolha dos produtos para aplicação dos estudos de caso ... 93
3.3 Caso 1: Garrafas PET – Carbonatados ... 94 3.3.1 DSM ... 95 3.3.2 Requisitos Funcionais ... 96 3.3.3 RSM ... 97 3.3.4 MDM ... 100 3.4 Bomba de combustível ... 102 3.4.1 DSM ... 102 3.4.2 Requisitos Funcionais ... 108 3.4.3 RSM ... 109 3.4.4 MDM ... 110 3.5 Drones ... 114 3.5.1 DSM ... 114 3.5.2 Requisitos Funcionais ... 116 3.5.3 RSM ... 118 3.5.4 MDM ... 119
4 ANÁLISE DOS RESULTADOS ... 122
4.1 Nova proposta – Caso 3 ... 123
5 CONCLUSÕES E RECOMENDAÇÕES ... 136
Referências ... 139
ANEXO A- Fluxogramas das etapas da metodologia de projeto segundo Dedini (2019) ... 146
1 INTRODUÇÃO
A complexidade de um projeto dificulta sua compreensão e sua previsão tornando-se necessário controlar a progressão do projeto, mesmo quando informações completas e detalhadas sobre o sistema do projeto são conhecidas. Essa abordagem de complexidade do projeto proposta por Ludovic (2010) está compatível com as de Baccarini (1996), Marle (2008) e Vidal et al. (2008).
Considerando a definição de projeto do Project Management Institute (do inglês Instituto de Gerenciamento de Projetos) PMI (2013): um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado único e estendendo-se ao conceito prático de projeto de possuir um início e um fim definidos. Ambas as definições se encontram no momento em que as fases do projeto, juntamente com suas inter e intra dependências precisam ser identificadas.
A complexidade do projeto envolve tomada de decisões (Earl et al, 2001 e Vidal et
al, 2009), o que pode levar a problemas de comunicação e coordenação em um cenário
complexo. A incerteza e a instabilidade intrínsecas aos projetos aumentam a complexidade e reduzem a eficiência das decisões, levando ao aumento dos riscos.
White e Fortune (2002) mencionaram que há muitos argumentos de que projetos falham devido à gestão inadequada de riscos. Outros autores, como Grimaldi (2005) e Smith, Merritt (2002) afirmaram que o gerenciamento de risco é o fator crítico para garantir o sucesso do projeto.
Raz e Hillson (2005) comparam os principais padrões disponíveis de gerenciamento de risco. Por exemplo, o livro Conhecimento de Gerenciamento de Projetos, o Guia Project Management Body of Knowledge - PMBoK (do inglês Corpo de Conhecimento em Gerenciamento de Projetos), o Guia de Análise e Gerenciamento de Riscos e Guia o Project Risk Analysis and Management - PRAM (do inglês Análise e Gerenciamento de Risco do Projeto) verificaram que, apesar da variação na quantidade de processos entre eles, os mesmos principais processos de planejamento, identificação de riscos, análise, monitoramento e controle são abordados.
Lagat (2015) deixa explícito que estamos inseridos em um contexto atual com mercado competitivo no qual as empresas necessitam possuir agilidade de mercado para construir seu planejamento estratégico e garantir sua posição competitiva. Dedini (2018) afirma que para esse ambiente não existe regra única no desenvolvimento de um projeto, e sim a de vários caminhos com conceitos, métodos, técnicas e ferramentas, sendo necessário escolher a forma mais adequada e desenvolvê-la com empenho, estabelecendo metas, monitorando a execução e sendo criativo.
Para este trabalho, foram estudadas metodologias de agrupamento propostas por Ludovic (2010) e Eppinger (2012), que auxiliam a avaliação de riscos de projetos em cenários complexos, com foco nas interdependências dos riscos de projeto do produto. Dessa forma, o presente trabalho está direcionado para promover uma discussão e melhorar a compreensão sobre a aplicação da ferramenta Multiple Domain Matrix – MDM (do inglês Matriz de domínio múltiplo), utilizando os conceitos da Design Structure Matrix – DSM (do inglês, Matriz de Estrutura de Projeto) e Risk Structure Matrix - RSM (do inglês Matriz de Estrutura de Risco) considerando os aspectos de desenvolvimento do produto do LabSin (Laboratório de Sistemas Integrados) da UNICAMP. Para tal, realiza-se uma sistematização teórica para as etapas executadas na aplicação da ferramenta visando a aproximação destes dois cenários através dos modelos de referência considerados. Os modelos de referência baseiam-se nos conceitos descritos para o desenvolvimento deste trabalho de acordo com Dedini (2002), Delgado Neto (2009), guia PMBoK (2015), Eppinger (2012) e Marle (2016).
Para melhor compreensão do modelo proposto foram realizados 3 estudos de caso contextualizados em cenários empresariais diferentes e considerando produtos com características diferentes de funcionalidade. O principal motivo da realização dos estudos de caso foi a escassez de aplicações da RSM considerando um cenário de projeto do produto, e permitindo futuras discussões e aplicações da ferramenta.
Essa matriz de risco surgiu como uma complementação do trabalho de conclusão de curso de graduação sobre DSM (Fornazzari, 2014). Nesse trabalho anterior, apenas foi relacionado os componentes do produto. Portanto, as contribuições do presente trabalho ficam evidentes na apresentação da MDM, na qual inseriu-se a RSM,
possibilitando relacionarmos requisitos funcionais advindos das necessidades dos clientes, componentes do produto e riscos relacionados ao produto.
Após essas aplicações, as vantagens da matriz MDM e seu melhor cenário de aplicação são apresentados para discussão, análise, testes, sugestões de possíveis novas aplicações e ponderações.
1.1 Objetivos
O objetivo geral deste trabalho consiste em analisar as abordagens Gerenciamento de riscos, DSM, RSM e metodologia de projeto identificando os aspectos teóricos e práticos que tornam seus relacionamentos e aplicações claras, possibilitando a sugestão de uma ferramenta complementar as abordagens tradicionais e esclarecendo dúvidas sobre as aplicações que se fazem pouco presentes na bibliografia. Para tal, foi feito uso da MDM, um tipo de DSM que permite relacionar funções, componentes e, principalmente, riscos envolvidos.
Com o intuito de atender o objetivo geral deste trabalho foram desenvolvidos os seguintes objetivos específicos:
(a) Estruturar uma fundamentação teórica adequada que possibilite apresentação clara das abordagens entre DSM de funções e componentes, RSM, gerenciamento de riscos e metodologia de projeto;
(b) Elaboração teórica de sistematização entre as etapas da RSM e metodologia de projeto sugerindo possível relacionamento;
(c) Realização de estudos de caso que possibilitem a compreensão da abordagem prática considerando os aspectos de cada tipo de produto estudado, das vantagens e desvantagens da utilização da ferramenta, dos diferentes tipos de resultado encontrados.
1.2 Estrutura do trabalho
Esta dissertação está estruturada em 4 partes:
1. Revisão bibliográfica que aborda conceitos relacionados aos aspectos gerais de Projeto do Produto, DSM, Gerenciamento de Riscos, RSM e MDM;
2. A Metodologia adotada para o desenvolvimento desse trabalho baseou-se em duas sequencias utilizadas para a análise dos casos, chamadas de Passo a Passo A e B. São baseadas em coleta de informações, abordagem, objetivos, procedimentos técnicos e operacionalização. Foram aplicadas em três casos; 3. Resultados e Discussões com respectivas análises e considerações.
4. Conclusão e recomendações para trabalhos futuros que envolvem a temática apresentada.
2 REVISÃO BIBLIOGRÁFICA
Neste capítulo são abordados conceitos relativos a Metodologia de projeto, DSM e RSM. Primeiramente, descreve-se definições segundo vários autores, características e definições. Na sequência apresentam-se os mesmos conceitos identificando as principais abordagens utilizadas em processos de desenvolvimento do produto. Outros conceitos relevantes a respeito de método, técnica e ferramenta também são apresentados. Este capítulo objetiva fornecer subsídios teóricos para o desenvolvimento desta pesquisa propiciando a estruturação para comparação entre as abordagens teórica e prática.
2.1 Metodologia de projeto
O conceito “método” deriva etimologicamente do greco-latino e significa “caminho para alguma coisa”, “caminho para se chegar ao final” ou “andar ao longo de um caminho”. Pode-se definir metodologia de projeto como uma coleção de procedimentos, métodos e técnicas, com o objetivo de auxiliar projetistas em atividades de desenvolvimento de produto. Para se alcançar um bom processo de criação ou desenvolvimento de um produto manufaturado a partir de uma ideia é necessária a adoção de metodologias. A metodologia utilizada para projetar um produto varia de empresa e produto, todavia pode-se construir um roteiro generalista, exequível na grande maioria dos casos.
Asimow em 1962 foi o primeiro autor a abordar as atividades no processo de projeto de engenharia, em sua obra Introduction to design: fundamentals of engineering
design (do inglês Introdução ao projeto: fundamentos do projeto de engenharia). Esta
obra é considerada pioneira e de grande relevância histórica, pois muitos outros autores desenvolveram suas propostas tendo como referência a esta metodologia e estas restringiram-se a adaptações de conceitos ao contexto específico de desenvolvimento do projeto. Como por exemplo, Ertas e Jones (1993) afirmam que projeto de engenharia é o
procedimento utilizado no desenvolvimento de um sistema/componente ou processo, de forma à atender determinadas necessidades. É um processo de decisão, muitas vezes interativo, no qual as ciências básicas são aplicadas para converter recursos otimizados para o atendimento de um objetivo primário.
Em 1966, Woodson descreve de forma sistemática o desenvolvimento de projetos de engenharia, apresentado na época a melhor visão sobre o processo de projeto. No mesmo período, destacam-se os autores Pahl e Beitz, descrevendo a prática de projeto e sistematizando o processo de desenvolvimento do produto. As etapas definidas pela obra de Pahl e Beitz estão organizadas em: definição da tarefa, projeto conceitual, projeto preliminar e detalhado. O método de Pahl e Beitz é largamente adotado por muitas instituições educacionais em cursos de projeto e engenharia.
Seguindo a cronologia, em 1977 surge a metodologia VDI 2222 (VDI- Verein
Deutscher Ingenieure. Do alemão, Associação dos Engenheiros Alemães) baseada na
norma alemã, transformando-se em 1985 na VDI 2221. O texto é direcionado ao processo de desenvolvimento de produto consistindo em um procedimento geral de projeto e desenvolvimento de produtos técnicos. Representa um conhecimento de sistemática de projeto comum a pesquisadores da época, descomplicando o processo de projeto permitindo a divulgação do conhecimento e obtenção de bons resultados.
Em 1981 por Blanchard, B. S. e Fabrycky, W. J. com a obra Systems engineering
and analysis (do inglês, Engenharia e análise de sistemas), propõe o processo de projeto
com uma visão próxima da atual visão de engenharia simultânea, com foco no ciclo de vida do produto e para o consumidor. Os autores estruturaram esta metodologia em 6 fases, as quais são: projeto conceitual, projeto preliminar, projeto detalhado e desenvolvimento, produção e/ou construção, suporte do ciclo de vida e utilização e descarte.
Estudos realizados pela ASME (American Society of Mechanical Engineers. Do inglês, Sociedade Americana de Engenheiros Mecânicos), no período de 1985 e 1986, e por Wallace e Hales, em 1987, marcaram o cenário de países como Estados Unidos e Inglaterra, que associavam a causa da perda de competitividade de seus produtos a deficiências relacionadas a qualidade dos projetos dos produtos (Back et al., 2008). Segundo Cordeiro et al. (2015), os estudos foram um marco para estes países, pois
impulsionaram pesquisas na área de metodologia de projeto. Além disso, a ASME apresentou também recomendações e diretrizes para o ensino e pesquisa nessa área.
Os conceitos de engenharia simultânea, qualidade total, desenvolvimento integrado ou projeto para competitividade (Back et al., 2008) foram temas recorrentes desde Ullman (1992), Kusiak (1993) e Clausing (1994) ao descreverem metodologias de desenvolvimento de produtos tal qual Suh, Ertas e Jones (1993).
Segundo Evbuomwan et al. (1996), metodologia de projeto pode ser definida como uma coleção de procedimentos, ferramentas e técnicas para uso dos projetistas nas atividades de projeto.
Back (1997) apud Zirondi (2009, p.11) definem que o processo sistemático e estruturado de desenvolvimento de produto é também conhecido como metodologia de desenvolvimento de projeto. Suarez et al. (2009) afirma que, a implantação de metodologias de projeto adequadas no processo de desenvolvimento de produtos pode auxiliar a empresa na redução de perdas desde a concepção dos produtos.
Para Pahl et. al (2005), a metodologia de projeto é um procedimento planejado com indicações concretas de condutas a serem observadas no desenvolvimento e no projeto de sistemas técnicos, que resultaram de conhecimentos sobre projeto, psicologia cognitiva e experiência com diferentes aplicações. Portanto uma metodologia de projeto deverá:
• Ser aplicável em qualquer atividade de projeto independente do ramo; • Facilitar a busca de soluções, estimulando invenções e conhecimentos; • Ser compatível com conceitos, métodos e conhecimentos de outras
disciplinas;
• Não gerar soluções apenas por acaso; • Ser possível de ser ensinada e aprendida;
• Facilitar o trabalho, economizar tempo e evitar decisões erradas; • Facilitar o planejamento e controle do trabalho em equipe;
• Ser orientação e diretriz para os gerentes de projeto e equipes de desenvolvimento.
Rozenfeld et al. (2006) reuniu informações, métodos e ferramentas sobre todo o processo de desenvolvimento do produto e apresentou pontos de decisões, ou quality
gates, que aprovam resultados e autorizam a realização de revisões e alterações.
O processo de projeto de desenvolvimento de produto tem uma importância estratégica dentro da empresa, pois reside na interface entre empresa e mercado. A forma como a organização define, seleciona, prioriza e desenvolve o conjunto de projetos de produtos é um fator muito impactante, pois, atualmente, o mercado não só procura somente a entrega de produtos competitivos, mas também que o processo de desenvolvimento seja eficiente (Romeiro Filho et al., 2010).
2.1.1 Metodologia de projeto no Brasil
Nelson Back publicou em 1983 sua primeira publicação em português sobre metodologia de projeto de produtos industriais com o intuito de difusão e reconhecimento da área de projetos no cenário brasileiro. Back dividiu as etapas de projeto do produto nas fases de projeto informacional, projeto conceitual, projeto preliminar e projeto detalhado, conforme Figura 1.
Figura 1. Metodologia segundo Back (1983).
Back (1983) define que projeto de engenharia é uma atividade orientada para o atendimento das necessidades humanas, principalmente, daquelas que podem ser satisfeitas por fatores tecnológicos de nossa cultura. Metodologia é o estudo dos métodos
aplicados a soluções de problemas teóricos e práticos. O modelo proposto incorpora princípios e práticas de engenharia simultânea e de gerenciamento de projetos.
Segundo Back et al. (2008) foi em meados da década de 1970 que se iniciou na Alemanha um grande esforço de pesquisa por princípios, métodos e metodologias genéricas de projeto de produtos industriais resultando em obras com ampla visão do processo de projeto. Este cenário também desencadeou abordagens sobre o desenvolvimento integrado de produto ou de engenharia simultânea.
Diante deste panorama, Back et al., (2008) sintetiza que o desenvolvimento de metodologias de projeto de produtos apresenta três marcos importantes na sua evolução, os quais são: publicação dos trabalhos de Pahl e Beitz (1972-1974) na Alemanha, os trabalhos da ASME (1985, 1986) nos Estados Unidos, e a primeira obra em português publicada por Back (1983) no Brasil.
No contexto brasileiro, fazem-se presentes as pesquisas desenvolvidas pelo professor Dr. Franco Dedini a partir de 2000, no LabSin da UNICAMP.
As pesquisas sobre metodologia de projeto deste grupo de pesquisa foram evoluindo ao longo do tempo até culminar no modelo que será apresentado e utilizado no desenvolvimento deste trabalho. Nessa metodologia são destacadas três principais fases: estudo de viabilidade, projeto preliminar e projeto detalhado. Esta proposta é o processo focado no desenvolvimento do produto e no processo de projeto visando a simplificação da linguagem, documentação, além de contar com a contribuição do usuário.
De acordo com Delgado Neto (2009), também contribuidor do LabSin, um bom resultado em um projeto ocorre em função da capacidade técnica e criativa de quem resolve o problema, sendo assim a metodologia não é nada mais que um instrumento de trabalho que fornece um suporte lógico para o desenvolvimento do projeto. Neste cenário diversas propostas de metodologias surgem visando garantir os atributos dos produtos que atendam às necessidades dos consumidores, ao mesmo tempo em que a sistematização do processo de projeto aumenta a eficiência e velocidade de desenvolvimento.
Para se alcançar o sucesso de um produto vários fatores são determinantes. Conforme Certo e Peter (2005), dois fatores importantes são a vantagem competitiva
diferenciada (características do produto que o tornam superiores aos dos concorrentes) e simbolismo do produto (consumo pode depender mais do seu significado social do que de sua utilidade funcional). Também Agostinho (2015) aponta que inovação é um atributo essencial para o planejamento estratégico de uma organização, frente a competitividade de Mercado.
No desenvolvimento de um produto ocorre a transformação de informações desde o entendimento das necessidades dos clientes até a entrega do produto. Essas atividades de desenvolvimento devem ser realizadas por uma equipe multidisciplinar que interpreta e trata informações de requisitos, restrições e soluções simultaneamente ao longo do projeto. Portanto, o processo de desenvolvimento de um produto não é uma atividade simples de ser executada apesar de ser necessário agilidade de mercado.
2.1.2 Modelo de referência de metodologia de projeto
De maneira a se adaptar ao cenário competitivo atual e alcançar os objetivos estratégicos de uma determinada organização, as empresas estão concentrando seus esforços de forma mais intensa em metodologias de projetos aplicadas ao desenvolvimento de produtos auxiliando-as nos desafios de mercado global.
Para esse cenário, existem vários caminhos e regras com seus conceitos, métodos, técnicas e ferramentas. É necessário escolher o formato mais apropriado e desenvolvê-lo com comprometimento, estabelecendo objetivos, e monitorando a execução de forma criativa (Cordeiro et al., 2015). Dessa forma, a relação entre os conceitos de gerenciamento de projetos e projeto do produto se tornam essenciais.
A abordagem entre os universos de gerenciamento e metodologia devem ser mais intensos e integrados durante o desenvolvimento de um projeto, pois o compartilhamento de conhecimento é necessário. A integração e cooperação de todo o time é necessária para que não existam problemas de comunicação e falta de informação.
Cordeiro et al. (2015) afirma que o processo de desenvolvimento de produtos envolve pesquisa, planejamento e controle constante. Para que esse processo ocorra de
maneira ordenada, deve-se utilizar metodologias cuja função é auxiliar o projetista na tarefa de desenvolvimento do produto, através das necessidades dos clientes oriundas de mercado. A metodologia de projeto foi definida anteriormente como uma coleção de procedimentos, métodos e técnicas, a fim de ajudar os projetistas na atividade de desenvolvimento de produtos.
Portanto, projeto do produto são métodos aplicados no desenvolvimento para auxiliar o processo de criação cuja aplicação não garante o sucesso do projeto, mas aumenta as chances.
Pahl et al. (2007) descreve a metodologia de projeto como um procedimento planejado que é um resultado conjunto de conhecimento de projeto com psicologia cognitiva e know-how de diferentes aplicações. Roozenburg e Eekels (1995) afirmam que o projeto do produto consiste em um sistema de métodos, ou seja, um conjunto de procedimentos que são aplicados nas atividades do projeto. No entanto, Evbuomwan et
al. (1996) definem projeto de produto como uma coleção de procedimentos, ferramentas
e técnicas para projetistas durante o processo de projeto. Segundo Delgado Neto (2005), a metodologia utilizada para projetar um produto varia de produto e empresa, porém é possível a construção de um modelo genérico que pode ser aplicável a maioria dos casos. No início do projeto, muitos aspectos não estão claramente definidos, resultando na necessidade de ferramentas que apoiem o desenvolvimento do projeto; as metodologias. Para facilitar a organização de informações, geração de dados, análise de dados e escolha de soluções, a maioria desses métodos é aplicada ao projeto de produtos. No entanto, é necessário seguir uma sequência de etapas de desenvolvimento.
Neste trabalho, foi como referência para a abordagem de metodologia de projeto o modelo estruturado por Dedini (2002) apud Delgado Neto (2009), aplicada no LabSin da UNICAMP para o ensino de projetos na área de engenharia mecânica há 20 anos (Dedini e Cavalca, 2000). Cordeiro et al (2015) ressalta que este modelo possui um caráter abrangente, linguagem clara para que pessoas com pouca experiência na área de projetos possam utilizar e embasamento teórico em diversas abordagens renomadas, como por exemplo, os trabalhos de Asimow (1968), Pahl et al. (2005), entre outros. Vicentini (2010) realiza uma aplicação da abordagem no contexto da indústria têxtil, e segundo dados deste autor a aplicação da metodologia para fabricação de uma coleção
primavera-verão aumentou em 14,32% o faturamento líquido da empresa, além de as peças desenvolvidas com esta sistemática alcançarem índice de aceitação acima do esperado.
Segundo Dedini (2002), o processo de desenvolvimento de produtos industriais, é dividido em três fases sequenciais: Planejamento, Projeto de Produto e Implementação. Após as etapas concluídas, o projetista recebe um relatório com os conceitos fundamentais para o desenvolvimento do projeto. Na Figura 2, são mostradas as etapas das três fases do projeto do produto: estudo de viabilidade, projeto preliminar e projeto detalhado na forma de fluxograma.
O projeto de um componente ou sistema fornece, em cada caso, um desenvolvimento cronológico e metodológico que permite a criação de um modelo comum a quase todos os projetos. O gerenciamento de risco e a metodologia de projeto na Figura 2 têm um link com a fase de planejamento do gerenciamento de projetos e estudo de viabilidade para a metodologia de projeto. Eles se complementam e ambos são necessários considerando as abordagens de risco. O tema de análise de riscos será abordado posteriormente, porém a sinergia entre etapas já é verificada no trabalho de Cordeiro et al. (2015).
Figura 2. Etapas básicas de projeto do produto (baseado em Dedini 2002)
A metodologia de projeto adotada por Dedini (2002) segue um roteiro de etapas propostas que auxiliam nos aspectos de criação e permite uma revisão contínua de atividades do projeto, com o intuito de aumentar e assegurar a qualidade do desenvolvimento do projeto. Os fluxogramas para todas as fases podem ser encontrados nos Anexos A.1, A.2 e A.3.
Além disso, Delgado (2010) reforça que essa metodologia visa a geração de documentação por meio de relatórios, que são desenvolvidos em todas as fases do processo. A documentação do projeto possibilita a formulação de catálogos de conhecimento para futuras consultas em atividades de projetos contribuindo para o compartilhamento de conhecimento e experiências.
Seguindo essa lógica, Cordeiro et al. (2015) complementa que esta metodologia procura estabelecer um roteiro para todo o desenvolvimento do projeto, no qual no final de cada etapa, se alcance como resultado relatórios com conceitos fundamentais. Documentação, esta que deve ser conter informações e explicações que auxiliam o projetista no andamento do projeto ou desenvolvimento de novos projetos.
A seguir, as fases que são diretamente relacionadas ao projeto do produto serão detalhadas. Elas são: Estudo de Viabilidade, Projeto Preliminar e Projeto Detalhado. Cordeiro et al. (2015) afirma que neste processo existe certa independência relativa entre as fases, pois com a finalização do conjunto de atividades de uma fase e aceitação do resultado esta não será mais retomada, o que contribui para otimização do tempo de projeto.
2.2 Fases relacionadas ao projeto do produto
2.2.1 Estudo de Viabilidade
Fase inicial do processo de projeto do produto na qual se identifica o problema e define claramente, conforme compilado por Cordeiro et al. (2015): os dados de entrada, necessidade dos clientes, detalhamento de requisitos, identificação do problema central e princípio de soluções para as especificações identificadas. O entendimento do mercado e dos clientes permite o aumento da ciência de projetistas sobre o problema. Isso pode ser convertido em parâmetros de engenharia através de ferramentas de projeto dos produtos se tornando as primeiras informações importantes para se iniciar o estudo de viabilidade.
Uma das maneiras de identificar as exigências dos consumidores para os produtos é através da voz do consumidor - VOC, que por sua vez utiliza a ferramenta de metodologia de projeto, o QFD (Quality Function Deployment – do inglês, Desdobramento da função da qualidade) para captá-la, transformando as exigências e desejos dos
consumidores em requisitos de engenharia possibilitando o estabelecimento de metas e comparativo com os concorrentes (Volpato, 2010)
Delgado Neto (2009) aponta que a correta identificação da necessidade do cliente é um fator fundamental para justificar o investimento no projeto. Com a informação do que o cliente necessita, parte-se para exploração dos sistemas envolvidos, em que ocorre o estudo do problema do projeto através de diferentes abordagens, também considerando as informações tecnológicas disponíveis.
Permitindo a exploração de todas as variantes possíveis dentro desse contexto, Pahl et al. (2005), decompõe o produto de forma sistemática em uma função global e subfunções, com fluxos de energia, matéria e informação. E, através dessa abordagem funcional, é possível decompor o produto em funções mais simples que alcancem princípios físicos do projeto.
Com o conhecimento sobre os sistemas envolvidos fornecido através do mapeamento de suas respectivas funções, Cordeiro et al (2015) destaca o início da etapa do estudo das soluções alternativas, no qual faz-se necessária a utilização de conceitos de criatividade para criação ou aprimoramento de ideias. As ferramentas de criatividade irão auxiliar na expansão do número de soluções para o problema em questão, assim como possibilita o encontro de soluções alternativas e viáveis.
O processo criativo deve ser amplamente analisado para gerar o maior número possível de soluções alternativas. O resultado dessa fase, após uma filtragem, é um conjunto de soluções criativas com viabilidade técnica e econômica.
Para King e Schlicksupp (1999) as equipes precisam de ferramentas de criatividade para fomentar o pensamento criativo e para gerar ideias diferentes. As ferramentas de criatividade também fornecem novas formas de compreensão de todos os componentes de um problema visando o encontro de soluções inovadoras, além de entusiasmar a equipe no processo de solução.
Romeiro et al. (2010) menciona que a criatividade sem dúvidas representa um importante componente do projeto do produto, especialmente quando se trata das fases relacionadas a concepção de soluções técnicas.
Baxter (2011) diz que, a criatividade possibilita a criação de diferenças entre o produto da sua empresa em relação aos concorrentes, porém essas diferenças devem
ser perceptíveis pelo consumidor de forma que o produto desenvolvido se torne mais atraente ao mercado e uma forma de fazê-lo é aplicar a criatividade no projeto em conjunto com os conceitos das DFX (Design for Excellence, do inglês, Projeto para Excelência) que objetivam maximizar características como qualidade, segurança, ergonomia, meio ambiente, entre outros. Dentre algumas ferramentas de criatividade Dedini (2015) destaca: Brainstorming, Método 6.3.5, Analogias, Quadro Morfológico, entre outras.
Nesta etapa de estudo de viabilidade, percebe-se na prática dos estudos propostos por Dedini (2015) que as análises de viabilidade física aumentam o conhecimento prévio dos princípios de funcionamento do produto (alguns conceitos podem ser testados através de protótipos funcionais) e dos princípios financeiros (permitem avaliar e definir os investimentos necessários, custo e preço do produto, potencial de mercado e lucratividade).
Cordeiro et al (2015) estabelece que estas informações poderão justificar o investimento de tempo, orçamento e esforço para um conjunto de soluções de um projeto ainda na fase inicial. Em muitos casos estas informações ainda não estão disponíveis, então há a possibilidade de obtê-las através de dados históricos, utilização de softwares de simulação de cenários, entre outras formas de previsão.
No geral, o estudo de viabilidade estrutura conceitualmente e propõe uma série de soluções que atendam as especificações do projeto do produto alinhado com as necessidades dos clientes da melhor maneira possível. Além disso, são considerados os pontos de vista tecnológico e econômico. Dedini (2002), conclui essa fase confirmando que o resultado deve ser registrado num relatório de concepção do produto que possui diagramas, esquemas, tabelas e especificações escritas. Com o resultado do Estudo de Viabilidade é possível decidir se será dada sequência ao desenvolvimento das soluções propostas para as próximas fases do projeto. Neste contexto é importante destacar que um Estudo de Viabilidade bem executado minimiza as chances de retrabalho nas etapas subsequentes do projeto e para auxiliá-lo também podemos destacar o Projeto Axiomático.
2.2.1.1 Projeto Axiomático
A metodologia proposta por Suh (1993) também denominada Axiomatic Design (do inglês, Projeto Axiomático) procura delimitar o projeto de sistemas através de axiomas, que determinarão um projeto concebido de forma correta ou um projeto com probabilidade de falhas.
A ideia básica para o projeto axiomático foi lançada em meados de 1970 e publicada em 1990 (Suh, 1990). Isto foi realizado como parte de um esforço no MIT para tornar a matéria de projeto e fabricação uma disciplina acadêmica.
Apesar das práticas de projeto em diferentes campos, aparentemente serem distintas entre si, o Projeto Axiomático presume que exista uma linguagem comum de pensamento a todos os campos de criação.
O postulado básico da abordagem axiomática para o projeto é que existem axiomas fundamentais que governam o processo de projeto. Dois axiomas foram identificados por observação dos elementos comuns que todo bom projeto sempre tem presente, sendo este de produtos, de processos ou sistemas: axioma da Independência e o axioma da Informação.
O Axioma da Independência estabelece que a independência de Requisitos Funcionais (FRs) deveria ser sempre mantida. Onde o número de FRs é definido como o número mínimo de requisitos independentes que caracterizam o objeto de projeto.
O Axioma da Informação considera de todos projetos que satisfazem o primeiro axioma, o que tem alta probabilidade de sucesso é o que é viável com o menor número de informações.
Durante o processo de projeto, o produto que está sendo considerado pode ser relacionado a quatro domínios: domínio do usuário, domínio funcional, domínio físico e domínio do processo, conforme ilustrado na Figura 3.
O número de domínios permanece constante, mas a natureza dos elementos de projeto em cada domínio muda, dependendo do campo do problema (Gebala & Suh, 1992).
Figura 3. Os quatro domínios do projeto, (Dedini, 2019)
A literatura destaca a dificuldade na descoberta destas relações entre os quatro domínios e recomenda-se o chamado “Ziguezagueamento” como forma de preencher todos os níveis hierárquicos de cada domínio. A aplicação do projeto axiomático diminui o trabalho de projeto e conforme seus autorese tem as seguintes vantagens segundo Dedini (2019):
1. Provê um meio sistemático de projetar produtos e grandes sistemas; 2. Torna os projetistas humanos mais criativos;
3. Reduz a busca aleatória nos projetos;
4. Minimiza a iteratividade e o processo de tentativa e erro.
5. Determina as quais as melhores configurações para continuidade do projeto; 6. Cria uma arquitetura que captura completamente a funcionalidade do sistema e provê ampla documentação;
7. O computador apoia o poder criativo.
A seguir serão feitas considerações sobre cada um dos axiomas.
O Axioma da Independência busca manter a independência dos Requisitos Funcionais. Os requisitos funcionais {RFs} são definidos como as mínimas condições dos requisitos de independência que o projeto deveria satisfazer. Os {RFs} são a descrição da meta de projeto, funções obrigatórias que definem o produto e satisfazem as necessidades dos consumidores {NCs}.
Note-se que são as {RFs} que devem ser independentes e não as {NCs}. Além disso, a relação entre as RFs e PPs definem a matriz de Projeto (MP), assim como as Parametros de Projeto (PPs) e as Variáveis de processo (VPs) também.
A independência dos Requisitos Funcionais significa que cada elemento de um vetor RF será relacionado a um elemento do vetor PP. Podendo ser descrito na seguinte equação 01:
{RF} = [MP] x {PP} eq. 01
em que MP é a matriz de projeto definida como uma matriz onde os elementos internos estão em função de sua posição na própria matriz com i colunas e j linhas.
Para que haja garantia de independência das RFs, a Matriz deve ser diagonal ou triangular. Esta é uma garantia que cada parâmetro pode ser otimizado de forma independente sem afetar os demais parâmetros e requisitos funcionais do projeto. A Figura 4 mostra um esquema desta relação.
Figura 4. Relação entre as RF e as PP através da Matriz de Projeto (MP) (Dedini, 2019).
Os elementos binários da matriz de projeto, expressos em X e 0, indicam a presença ou ausência de uma relação entre um PP e associado RF. O X deve estar sempre presente na diagonal, significando que cada PP afeta seu RF associado, por exemplo, A11 = X indica que PP1 afeta RF1.
Para satisfazer a independência de um determinado conjunto de {RFs}, o número de {PPs} deve ser igual ao número de {RFs} e a matriz deve ser diagonal ou triangular.
• Quando [MP] é diagonal, cada um dos {FRs} pode ser satisfeito independentemente por meio de um PP. O projeto é chamado de “desacoplado”.
• Quando a matriz é triangular, a independência de {FRs} pode ser garantida se e somente se {PPs} é determinada sequência correta, e nesse caso o projeto é chamado de “Dissociado”.
• Quando o número de {PPs} é menor que o de {RFs} ou a matriz MP não pode assumir forma diagonal ou triangular o projeto é sempre “Acoplado”.
Todas as soluções podem ser viáveis, mas certamente algumas serão melhores e permitirão otimizações simples e econômicas. Estas em geral são aquelas que atendem os dois axiomas de forma mais completa e melhor. A Figura 5 mostra a representação matemática e gráfica dos três tipos de projetos.
Figura 5. Projetos desacoplados, projetos dissociados Adaptado de Cochran et al. (2000).
Projetos desacoplados, dissociados e acoplados são sucessivamente mais complexos em relação à otimização de qualquer um de seus parâmetros, como pode ser visto na Figura 5.
De uma forma mais clara, este axioma pode ser visto como uma forma de evitar efeitos secundários na determinação de um parâmetro de projeto. Com a independência cada parâmetro afetará apenas um requisito, assim torna mais fácil modificar um produto e atingir um resultado esperado.
Outro ponto do projeto axiomático é o Axioma da Informação, o qual busca minimizar os conteúdos de informação. A Informação é definida em termos de conteúdo de informação I que é relacionada com a probabilidade de satisfazer um dado RF. No caso geral de n RFs para um projeto desacoplado, I pode ser expresso por:
𝐼 = ∑[𝑙𝑜𝑔1 𝑝𝑖 ] 𝑛
𝑖=1 eq.2
em que pi é a probabilidade de PPi satisfazer RFi para os n elementos. I é a somatória de todas as relações para os n eventos. O axioma informação estabelece que o projeto que tem o menor I é o melhor projeto, devido a requer menor quantidade de informação para alcançar a meta do projeto.
Quando todas as a probabilidades são iguais a um a informação requerida é zero, o mínimo possível, pois se tem certeza que todas as PPs satisfazem completamente todas as RFs. Se as probabilidades forem sempre zero a informação requerida é infinita e existe a certeza que nenhuma PP vai satisfazer qualquer RF nesse projeto.
Em um projeto desacoplado ideal, o número de {FRs}, {DPs}, e {PVs} são iguais e as matrizes de projeto são diagonais.
A seguir estão os corolários, segundo Dedini (2018) que contribuem para o presente tópico:
• Corolário 1: Desacoplamento de Projetos Acoplados. Desacoplar ou separar partes ou aspectos de uma solução se as FRs são acopladas para que se tornem independentes no projeto proposto;
• Corolário 2: Minimizar o número de FRs e restrições (Suh, 2001). Esforçar-se para a máxima simplicidade do projeto como um todo ou maior simplicidade nas características físicas e funcionais. Problemas e custos de produção tem uma
relação direta com o sistema de manufatura e qualquer esforço feito para simplificar o sistema resultará em economias significativas (Black, 2001);
• Corolário 3: Integração das Partes Físicas. Integre características do projeto em uma única parte se as FRs podem ser independentemente satisfeitas na solução proposta (Suh, 2001);
• Corolário 4: Uso da Padronização. Usar partes padronizadas ou intercambiáveis se o uso das mesmas for consistente com as FRs e restrições (Suh, 2001); • Corolário 5: Uso da Simetria. Usar formas ou componentes simétricos se eles
forem consistentes com as FRs e restrições (Suh, 1998);
• Corolário 6: Maior Tolerância Possível. Especificar a maior tolerância permitida na definição das FRs (Suh, 2001). A especificação da maior tolerância possível reduz custos e desempenham papéis importantes na realização de um sistema de manufatura simples (Black, 2001);
• Corolário 7: Projetos Desacoplados com Menos Informação. Procurar um projeto desacoplado que requeira menos informação que um projeto acoplado para satisfazer o conjunto de FRs.
2.2.1.2 Análise Funcional
Seguindo a linha de funções como o projeto axiomático, varias técnicas de análise funcional são desenvolvidas. Pois para caracterizar perfeitamente um produto é necessário entender corretamente as funções com que este atenderá as demandas dos clientes. Muitas vezes o produto não existe e é difícil caracterizar funções para algo que nunca foi feito. No entanto, abstrair a necessidade básica do produto permite entender o que realmente se quer fazer. Segundo Dedini (2019), a abordagem funcional reduz o projeto a requisitos chamados funções. O processo de definir uma função requer habilidade, prática e a consciência de que a definição deve ser tal que amplie a oportunidade para pensar criativamente, gerando maior número de possibilidades.
Uma função pode ser definida com um verbo (atuando sobre algo) e um substantivo (objeto sobre o qual o verbo atua), por exemplo: amplificar corrente, armazenar energia, aplicar força, evitar vibração, fresar metal, suportar peso, transmitir torque, controlar ruído, entre outros. A escolha do substantivo deve ser tal que associe um parâmetro mensurável, em alguma uni unidade de medida, como tempo, custo, volume, etc.
A análise funcional é o processo para identificar as funções do sistema e as interfaces necessárias para atender o objetivo. Se não identificar todas as funções e as interfaces, o sistema desenvolvido não irá executar todas as funções e não irá funcionar da maneira desejada. Ela é baseada numa conduta sistemática que consiste em catalogar, definir, classificar, hierarquizar o conjunto das Funções de um produto ou de um serviço. A análise funcional tem suas origens na metodologia de análise de valor ou engenharia do valor desenvolvida por Lawrence Miles (1964). A análise do valor busca designar frações do custo do produto às funções do mesmo, então os custos das funções orientam os esforços de projeto.
Dedini (2019) afirma que existem três técnicas mais utilizadas para realizar a Análise Funcional: Árvore Funcional, Diagrama Fast, Desdobramento Funcional.
Para o desenvolvimento das funções neste trabalho, foi utilizada a técnica de Árvore Funcional devido a facilidade de visualizar as funções. Como vantagem constata-se a pequena ocorrência de não função e o estabelecimento correlação criada entre componentes do produto e requisitos funcionais. Essa aplicação poderá ser observada no estudo de caso 4. Os passos da Árvore Funcional segundo Dedini (2019) são:
1) Listar todas as funções do produto (brainstorming) – o que faz o produto? 2) Ordenar as funções: principais, básicas e secundárias.
3) Confirmar a precisão da árvore funcional, colocando as questões: Como? Porquê?
4) Descrever as funções do produto exaustivamente e ordená-las de forma sistemática.
As funções básicas são aquelas que o dispositivo, produto ou sistema a ser projetado deve satisfazer, não importa quais componentes físicos possam ser utilizados.
O nível do problema é decidido através do estabelecimento de um limite em torno de um subconjunto coerente das funções. A função secundária do produto ajuda na venda. As regras para execução são:
1) Cada função deve ser descrita por meio de verbo e substantivo.
2) Cada definição da função deve ser mais geral possível. No entanto, os níveis mais baixos devem ser menos gerais.
3) As funções de níveis inferiores devem fazer parte das funções de níveis superiores.
4) Funções de nível inferior devem desdobrar as funções de alto nível, perguntando “como” para um lado e “por que” para o outro.
2.2.2 Projeto Preliminar
Seguindo as etapas da metodologia de projeto, a próxima fase é o projeto preliminar. O objetivo principal dessa fase é analisar as soluções apresentadas no estudo de viabilidade. Nesta fase, modelagem matemática, simulação e otimização são realizadas, a fim de transformar a abordagem em um passo decisivo no processo. Todos os cálculos e dimensionamento fornecem suporte para encontrar a melhor opção através das simulações numéricas e, eventualmente, é possível reavaliar algumas ou todas as etapas do projeto. Um dos pontos-chave nessa fase é considerar adequadamente os parâmetros necessários e suas funções, garantindo que nada seja esquecido. O foco nesta etapa é o dimensionamento e a otimização das funções.
Conforme Vicentini (2010), nessa fase que são avaliados aspectos relacionados a materiais, processos construtivos, formas geométricas e otimização de caráter geral. A etapa inicial do Projeto Preliminar consiste em selecionar a melhor proposta dentre as sugeridas pelo Estudo de Viabilidade através de critérios pré-estabelecidos.
Segundo Cordeiro et al (2015), é correto quando é proposto que nesta etapa sejam comparados os atributos de cada proposta com o intuito de filtrar as mais promissoras considerando os aspectos de benefícios e dificuldades de execução. A experiência do
grupo é muito importante para auxiliar neste processo de decisão juntamente com métodos de votação ou matriz de avaliação.
Romeiro Filho et al. (2010) destaca a Matriz de Pugh visto que ela avalia as alternativas de projeto em relação às necessidades dos clientes e requisitos de projetos utilizando escalas de valores, orientando a equipe para solução que desempenha a melhor função. A partir da melhor solução selecionada, a proposta se modifica do campo de abstração para uma abordagem concreta também como na metodologia de projeto. Cordeiro et al (2015) afirma que com a formulação de modelos matemáticos, a modelagem permite estudar o funcionamento e simular o desempenho do sistema alinhado com as funções que o produto precisa apresentar. As atividades de modelagem e simulação podem ser realizadas com o apoio de ferramentas computacionais (CAD –
Computer Aided Design, do inglês Projeto Assistido por Computador e CAE – Computer Aided Engineering, do inglês Engenharia Assistida por Computador).
Romeiro Filho et al. (2010) comenta que nessa fase consideram-se todos os materiais possíveis para um determinado componente ou produto levando-se em consideração a sua função, requisitos de desempenho e restrições. As análises de sensibilidade e compatibilidade possibilitarão a determinação das variáveis mais críticas e possíveis interferências ou interações entre os diversos componentes ou partes do sistema. Na sequência são aplicadas técnicas de otimização que podem estar direcionadas tanto para o tratamento de parâmetros técnicos como para econômicos, com o intuito de obter uma solução ótima. Diante de todas estas informações torna-se necessário testar e prever o desempenho do produto para análise do seu comportamento sob várias condições de funcionamento.
Delgado Neto (2009) cita que na parte experimental, quando ocorre a execução de testes, são elaborados protótipos funcionais para testar características de desempenho, e protótipos em escala que possibilitam a verificação de problemas de montagem, acesso, assim como a aceitação estética do produto. Esta fase é muito importante, pois possibilita a detecção e correção de possíveis falhas de projeto relacionadas a matéria-prima, componentes, processo de fabricação e construção.
Cordeiro et al. (2015) propõe que a etapa final do Projeto Preliminar consiste no estudo de possíveis simplificações que podem ser realizadas no produto do projeto a fim de reduzir custos da alternativa proposta sem comprometer o aspecto de qualidade.
Por final, tem-se como resultado do Projeto Preliminar, alinhado com os conceitos de Dedini (2002), um produto com um memorial de cálculo técnico e econômico bem como informações sobre otimizações realizadas. Tal documentação deve possuir aspectos de funcionamento e parâmetros claramente definidos, especificação de material e memorial de cálculos sob o aspecto do conjunto do produto. Estas informações serão suficientes para o atendimento com excelência das funções mapeadas pelo Estudo de Viabilidade.
2.2.3 Projeto Detalhado
Segue-se para a terceira etapa da metodologia de projetos, Projeto Detalhado. Para Romeiro Filho et al. (2010), a etapa de Projeto detalhado é responsável pela especificação mais refinada do projeto voltada aos componentes, em que são consideradas as tolerâncias. Envolve um conjunto de desenhos completos e especificações de componentes, montagem, desenhos de instalação, protótipos, layout e definições de parâmetros de montagem. Nesta etapa, a solução escolhida no projeto preliminar será detalhada e testada, portanto, o foco desta fase é detalhamento, definição de tolerâncias e adaptação construtiva. Para Cordeiro et al. (2015), o Projeto Detalhado tem como objetivo detalhar a concepção do produto resultante do Estudo de Viabilidade e Projeto Preliminar gerando todas as especificações finais do produto para encaminhar para o processo de manufatura.
Delgado Neto (2009) afirma que, as etapas iniciais do Projeto Detalhado consistem na especificação de subsistemas e componentes. Esta etapa também inclui decisões sobre quais componentes do produto serão comprados ou fabricados, assim como também aspectos referentes ao desenvolvimento de fornecedores. Estas decisões por sua vez são influenciadas pelo cenário de tecnologia disponível.
A definição dos componentes possibilita a formulação de uma listagem de peças ou materiais bastante conhecida no meio empresarial pelo termo BOM (Bill of Material,
do inglês lista de materiais). Esta lista identifica o componente, especifica o material do
componente e o seu consumo, categorizam o componente por classe e apresentam o custo do referido componente, de acordo com sua cotação ou conhecimento tácito de projetos anteriores. Essas informações permitem estabelecer um roteiro de consumo de material e facilita o gerenciamento das informações do roteiro de fabricação.
Após estas definições, as partes são descritas em peças elementares que constroem os componentes. De acordo com Cordeiro et al. (2015) neste caso deve-se atentar para aspectos de compatibilidade e simplificação, que estão diretamente ligados a forma, dimensões e tolerâncias que possam vir a influenciar na montagem de produto.
Cordeiro et al (2015) continua sua abordagem demonstrando a necessidade da formulação dos desenhos detalhados tanto dos componentes específicos como desenhos direcionados para montagem. Assim, através dos desenhos, é possível construir protótipos em escala real que possibilitem a detecção de possíveis dificuldades de montagem ainda na fase de projeto e permitam revisões e adequações caso necessário. Dedini (2002) sugere que, paralelamente a estas atividades descritas, também deve-se atentar para a verificação e atendimento de normas e sistemas de padronização relacionados a qualidade, aos desenhos e aos meios de fabricação.
Após todas essas abordagens, ao final dessas atividades, pode-se liberar para fabricação o projeto de um produto detalhado com um relatório contendo a descrição completa de peças individualmente, incluindo seleção de materiais, dimensionamento de componentes, observações coletadas em testes, manuais técnicos e de aplicação. O relatório deve ter detalhes suficientes que dão todo suporte necessário a produção. Com este estudo também pode ser realizada uma estimativa realista dos custos envolvidos, que é extremamente importante para os tópicos dos capítulos posteriores.
2.3 FMEA
Considerando o a abordagem de riscos desse trabalho, deve-se destacar a seguinte ferramenta de metodologia de projeto consolidada para projeto do produto:
Failure Mode and Effects Analysis (FMEA), do inglês modo de falha e análise de efeitos.
Em algumas indústrias, sua aplicação é obrigatória, como na indústria automotiva pois, o método resume uma sistemática que relaciona componentes, funções e falhas de forma clara e com foco em resultado.
A ferramenta (Campos, 2004), conhecida como FMEA, é uma ferramenta que busca, em princípio, evitar, por meio da análise das falhas potenciais e propostas de ações de melhoria, que ocorram falhas no projeto do produto ou do processo. O objetivo básico da técnica é detectar falhas antes que se produza uma peça e/ou produto. Com sua utilização, pode-se diminuir às chances do produto ou processo falhar, aumentando sua confiabilidade.
A confiabilidade, tem se tornado cada vez mais importante para os consumidores, pois, a falha de um produto, mesmo que prontamente reparada pelo serviço de assistência técnica e totalmente coberta por termos de garantia, causa, no mínimo, uma insatisfação ao consumidor ao privá-lo do uso do produto por determinado tempo. Além disso, cada vez mais são lançados produtos em que determinados tipos de falhas podem ter consequências drásticas para o consumidor, tais como aviões e equipamentos hospitalares, nos quais o mau funcionamento pode significar até mesmo um risco de vida ao usuário.
Atualmente a FMEA é utilizada para diminuir as falhas de produtos e processos existentes, para diminuir a probabilidade de falha em processos administrativos, análises de fontes de risco em engenharia de segurança prevenção de falhas nos processos da indústria de alimentos, ou até mesmo pode ser exigida por montadoras automobilísticas como documento necessário a seus fornecedores. Este é um dos responsáveis pela divulgação da técnica, apesar de que, deve-se implantar a FMEA em uma empresa visando seus resultados e vantagens e não simplesmente atender a uma exigência.
As etapas e a maneira de realização da análise são as mesmas, ambas diferenciando-se somente quanto ao objetivo. Segundo Palady (2004), existem quatro tipos principais de FMEA. São eles:
1. FMEA de sistema (System FMEA): utilizado para analisar sistemas e subsistemas no início do desenvolvimento do conceito e do projeto. Um FMEA de sistema foca nos modos de falhas potenciais, casados por deficiências do sistema, das funções do sistema. Nas análises são incluídas interações entre sistemas e entre elementos (subsistemas) de um sistema;
2. FMEA de produto (Design FMEA – DFMEA): utilizado para analisar produtos antes de sua liberação para a fabricação. Um DFMEA foca em modos de falha causados por deficiências de projeto do produto;
3. FMEA de processo (Process FMEA – PFMEA): utilizado para analisar processos de fabricação e montagem. Um PFMEA é focado em modos de falha causados por deficiências de processo de fabricação ou montagem; e
4. FMEA de serviço (Service FMEA): utilizado para analisar serviços antes de eles chegarem ao consumidor. Um FMEA de serviço foca em modos de falha (tarefas, erros, enganos) causados por deficiências do sistema ou do processo.
Segundo Rozenfeld (2006), a FMEA pode ser aplicada seguindo as etapas: 1. Descrição dos objetivos e abrangência da análise: identifica quais produtos ou
processos serão analisados;
2. Formação dos grupos de trabalho: definem-se os integrantes do grupo, preferencialmente entre 4 a 6 pessoas, e multidisciplinar;
3. Planejamento das reuniões devem ser agendadas com antecedência e com o consentimento de todos os participantes para evitar interrupções;
4. Preparação da documentação.
As vantagens da FMEA ser aplicada são:
• Forma sistemática de catalogar informações sobre as falhas dos produtos/processos;
• Melhor conhecimento dos problemas nos produtos e processos;
• Ações de melhoria baseadas em dados e devidamente monitoradas (melhoria contínua);
• Diminuição de custos por meio da prevenção de ocorrência de falhas;
• Criação de uma cultura de prevenção de falhas, cooperação, trabalho em equipe e preocupação com a satisfação dos clientes.
Apesar da existência de uma ferramenta para identificação de falhas no fluxo de desenvolvimento de produto, um método baseado em matriz para modelagem com dependência pode melhorar a geração de funções e redes de falhas e consequentemente aumentar a eficiência, conforme mostrado por Maurer (2011). "O método baseado em matriz não deve substituir o procedimento estabelecido e a aplicação da ferramenta. De fato, ele será integrado à abordagem existente”.
A FMEA é de grande valia como precursora de uma análise através de Árvores de Falhas. O conhecimento adquirido durante a execução da FMEA ajuda bastante a etapa de construção da Árvore de Falhas, pois a análise sistemática de todos os modos de falhas e dos efeitos dessas falhas ajuda a evitar que modos de falhas importantes deixem de ser considerados ou que aqueles modos de falhas sem importância sejam modelados detalhadamente.
2.4 Análise de árvore de falha - FTA
O FTA faz o caminho inverso do método FMEA. Através de um fluxograma constituído por vários eventos e portas lógicas, parte-se de um efeito no sistema e chega-se às causas nos componentes. Essa causa está ligada a um modo de falha previamente descrito, por exemplo, em um FMEA. Geralmente, o FMEA e o FTA são utilizados em conjunto, entretanto, o FTA permite no projeto uma visão mais ampla e atualizada do projeto antes do Produto. (Dedini, 2019)
A análise de árvore de falha (FTA) é uma técnica de análise que modela visualmente como, relacionamentos lógicos entre falhas de equipamentos, erros humanos, e eventos externos podem ser combinados para causar acidentes específicos. Segundo Henley e Kumamoto (1981), a análise da árvore de falhas foi desenvolvida por H. A. Watson dos Laboratórios Bell Telephone em 1961-62. Os primeiros artigos publicados foram apresentados em 1965 no Simpósio de Segurança patrocinado pela Universidade de Washington e a Boeing Company.
A análise da árvore de falha é focada em eventos específicos, usualmente denominados de catastróficos, os mesmos da segurança empresarial e analisa as causas prováveis em termos de estrutura, fluxo do evento, de cima para baixo. Se construída corretamente, a árvore ajuda o gerenciamento de risco a determinar e classificar com precisão todos os caminhos pelos quais um evento pode percorrer.
Os benefícios no uso de uma Árvore de Falhas segundo Henley e Kumamoto (1981) são:
• Auxiliar a identificação dos modos de falha;
• Pontuar os aspectos importantes do sistema para a falha de interesse; • Fornecer auxílio gráfico para dar visibilidade às mudanças necessárias; • Fornecer opções para análise de confiabilidade quantitativa e qualitativa; • Permitir ao analista se concentrar em uma falha do sistema por vez.
De acordo com Dedini (2018), a importância da árvore da falha é que na análise de risco, pode-se saber em termos quantitativos a probabilidade de os eventos ocorrerem ao mesmo tempo, sendo independentes ou inter-relacionados.
As árvores de falha são mais adequadas para análise das causas de um evento conhecido em particular envolvendo um risco crítico. As árvores de falha não representam a passagem do tempo, sendo mais adequadas para eventos essencialmente aleatórios e oferecem uma abordagem extremamente flexível incorporando soluções quantitativas e qualitativas ou baseadas em simulações.
No presente trabalho não serão utilizados os conceitos de árvore de falha pois o foco está em desenvolver possíveis novas aplicações com a metodologia matricial, porém os conceitos auxiliaram no levatamento dos riscos.
