Equipe Cheetah Racing de Formula SAE UNIFEI Universidade Federal de Itajub

Estruturao Terica do Processo de Desenvolvimento de Produtos da Equipe Cheetah Racing de FSAE

Por Ricieri Lima de Oliveira

Sumrio 1. Introduo 2. O Processo de Desenvolvimento de Produto 2.1 Contextualizao 2.2 Etapas do nosso processo 2.3 Implementao gradativa baseada em melhoria contnua 2.4 Indicador para a situao atual do PDP da equipe 2.5 Importncia da gesto do conhecimento para as futuras geraes 2.6 Fontes de informao 3. Engenharia de sistemas e diviso da equipe 3.1 Engenharia de Sistemas e a diviso da equipe 3.2 Design Strucure Matrix 3.3 Modularizao e Robustez 3.4 Fontes de informao 4. A Gesto do conhecimento no Frmula SAE 4.1 Como guardamos conhecimento? 4.2 Fontes de informao 5. Lean Development 5.1 Principais Conceitos e aplicaes 5.2 Lean uma cultura, no uma caixa de ferramentas! 5.3 Fontes de informao 6. Ferramentas do Lean PDP 6.1 O que usamos e por qu? 6.2 Fontes de informao 7. DFMA, FMEA e books 7.1 DFMA O que e como aplicar? 7.2 FMEA O que e como aplicar? 7.3 Books De onde surgiram, como utilizar, para que servem e possveis melhorias. 7.4 Fontes de informao 8. Design for six sigma 8.1 Etapas principais e adaptaes ao Formula 8.2 Fontes de informao 9. Otimizao multi-objetiva e modeFRONTIER 9.1 O que e como utilizar? 9.2 Fontes de informao 10. Melhoria contnua e motivao 10.1 Melhore este documento 10.2 Motive seu subsistema 10.3 Fontes de informao

1. Introduo Este material tem por objetivo sistematizar os principais conceitos e passos do processo de desenvolvimento de produtos da equipe. O enfoque principal dele a aplicao prtica da teoria, para uma anlise terica mais profunda sobre os assuntos, aconselha-se a leitura do material presente nas referncias da Gesto Interna. Este material dever ser editado ao decorrer do tempo pelos capites da equipe de desenvolvimento a medida que mais conhecimento seja capturado e avanos nas reas estudadas sejam feitos. Para tanto, ns contamos com voc, caro leitor. Este documento tambm dever servir como base de estudo para os novos integrantes e para possibilitar o entendimento do nosso trabalho por qualquer membro da equipe. Pensem na fora que este arquivo pode ter se for melhorado ao decorrer de muitos anos. Com um processo de desenvolvimento consistente e bem organizado, certamente teremos grandes chances de sucesso.

2. O processo de Desenvolvimento de Produto 2.1 Contextualizao

Processo de desenvolvimento de produto (ou PDP) consiste na sistematizao e organizao de todas as etapas necessrias para a criao de um determinado produto. O PDP o que garante a qualidade e a uniformidade do produto desde os passos mais bsicos (Definio) at o acabamento dos ltimos detalhes. Existem vrios modelos de PDP na literatura, mas a nossa necessidade principal encontrar um modelo que se adapte equipe, ou seja, um modelo que consiga pegar as melhores caractersticas de diferentes metodologias e fundi-las em algo consistente. importante ressaltar que a maioria dos modelos presentes na literatura funciona de maneira diferente na teoria e na prtica, visto que muitos destes livros foram escritos para aplicao em grandes empresas, que possuem muito mais recursos disponveis e uma estrutura organizacional mais adequada para a implantao dessas tcnicas. Contudo, existem vrias lies que podem ser extradas dessas referncias e adaptadas ao desenvolvimento do nosso prottipo. A implantao do nosso PDP est ligada ainda a algumas dificuldades que podem no so percebidas em um primeiro contato com os subsistemas: Modificao de cultura das pessoas: Os membros da rea tcnica do Frmula SAE (estrutura, direo, eletrnica e motor) so engenheiros muitas vezes j com alguma experincia em outros projetos especiais. A maioria das equipes da Unifei (seno todas) no possui um Processo de Desenvolvimento de Produto que orienta o projeto, o que implica na dificuldade na atuao da gesto do desenvolvimento em diferentes nveis que sero explorados ao longo deste documento. No se trata de descaso com a nossa subequipe, apenas a dificuldade que qualquer idia nova gera quando desenvolvida. Toda idia nova sempre encontrar resistncia e nosso trabalho explicar a importncia do que fazemos e as conseqncias negativas de no realizar um processo com inicio e fim. Aplicao prtica e dificuldade nos primeiros projetos: Como dito anteriormente, nem sempre a teoria dos livros funciona na prtica e antes que qualquer grande avano possa ser feito para sistematizar o processo de criao do carro, necessrio primeiro que consigamos traduzir o que est na teoria para as nossas aplicaes prticas do dia-a-dia. Neste material estar tabelado tudo que comprovadamente tem funcionado para as equipes de Formula SAE da Unifei ao longo dos anos e como isso tem sido feito. Portanto, essencial que esta apostila seja sempre atualizada com as experincias dos membros de cada ano. Problemas organizacionais: muito comum (principalmente em equipes novas) que ocorram problemas associados falta de sistematizao do trabalho, isso , falta de planejamento e de uma rotina que permita o desenvolvimento do produto sem queimar etapas ou relevar aspectos importantes. Isso tudo faz parte de uma experincia que deve ser consolidada com o

passar do tempo e essencial ento que haja uma boa gesto do conhecimento, de maneira que a equipe aprenda com os erros. Quanto tempo deve ser gasto nas etapas pr-projeto? Em quais reas as equipes devem gastar mais tempo de estudo? Como estruturar o cronograma de criao do carro sem conhecer 100% do processo? Como organizar horrios de reunies de maneira satisfatria aos membros? So perguntas de tpicos organizacionais como estas que pretendemos responder por meio da sistematizao do nosso processo. Excesso de ferramentas: Existem muitas ferramentas bastante teis que podem ser utilizadas para aumentar a qualidade do projeto. No material de referncia da equipe de desenvolvimento existem vrias dessas ferramentas. Contudo, nem todas elas funcionam no contexto da nossa equipe, visto que algumas exigem grande conhecimento do funcionamento dos sistemas do prottipo. Pode ocorrer ento que a equipe tente utilizar tantas ferramentas que no consiga tirar verdadeiro proveito de nenhuma. O papel de um membro da equipe de desenvolvimento de utilizar essas ferramentas em conjunto com os subsistemas e no simplesmente entregar um papel e pedir que seja preenchido. Um agente da gesto interna deve funcionar como algum responsvel prioritariamente pela integrao das sub-equipes e existem vrias tcnicas para conseguir realizar este objetivo. A maneira mais fcil de conseguir isso , sem dvida, a partir de uma estrutura voltada para o armazenamento e transmisso de conhecimento. Perda de conhecimento: Uma das metas principais da equipe de desenvolvimento garantir o estabelecimento de uma estrutura de armazenagem de conhecimento til ao longo dos anos. Para tanto, lana-se mo de vrios recursos do Processo de Desenvolvimento de Produtos Lean, que v como desperdcio a perda de conhecimento til (Ver Lean Development). Perda de conhecimento por desligamentos, reunies improdutivas, e problemas organizacionais so fatores crticos que afetam o bom desempenho da equipe como um todo. Queda de motivao: Um dos principais problemas dos subsistemas de qualquer equipe certamente a queda de motivao. Trata-se de um assunto extremamente complexo e difcil definir o que motiva ou desmotiva uma pessoa no ambiente de trabalho. O fato que quedas de motivao individuais tendem a prejudicar o conjunto e que se no controladas, geralmente acarretam desligamento de membros. O desligamento de membros pode ser uma verdadeira armadilha para uma equipe que no tem uma boa gesto de conhecimento.

Curiosidade: Note que a maioria seno todos os problemas organizacionais caracterizam desperdcio diretamente ou indiretamente para o Processo de Desenvolvimento de Produto (perda de conhecimento durante as etapas) Modificao de cultura: Uma cultura diferente por parte da equipe de desenvolvimento e da rea tcnica implica em esforos sendo feitos em sentido contrrio, o que desperdcio de conhecimento. Dificuldade de aplicao prtica: Se alguma coisa no aplicvel, ela no gera conhecimento til ao projeto. Problemas organizacionais: No saber qual a sua funo ou qual o prximo passo induz ao erro e ao retrabalho, ou seja, desperdcio. Excesso de ferramentas: Alm do tempo gasto com ferramentas que no sero

usadas, toma-se tempo na tentativa de implementao dessa ferramenta. O tempo poderia ser usado para gerar conhecimento til, caracterizando desperdcio. Perda de conhecimento: O prprio nome j diz tudo Queda de motivao: A queda de motivao de uma equipe facilmente leva a desligamentos. Qualquer pessoa que sai do projeto leva consigo alguma informao ou estudo que desenvolveu e que pode no estar disponvel para a prxima gerao.

CONCLUSO: Identificar os desperdcios durante o projeto so maneiras eficientes de aumentar a eficincia da equipe de desenvolvimento e simultaneamente trazer a gesto mais para o lado da cultura Lean. O processo para que isso seja possvel:

Encontrar desperdicio

Tomar ao corretiva

Verificar resultados

Garantir que o problema no volte

(Semelhante ao ciclo da melhoria contnua)

Exemplo da metodologia aplicada a um dos problemas: Perda de conhecimento 1) Encontrar desperdcio Como o prprio nome j diz, a perda de conhecimento durante os anos uma fonte de desperdcio direto para a equipe. Supondo que o capito de um subsistema saia no meio do ano que vem, temos uma estrutura que garante que os outros membros vo ser capazes de realizar o trabalho com a mesma qualidade de que quando era realizado anteriormente? Este membro levar consigo informaes importantes que o restante da equipe no possui?

2) Tomar ao corretiva J que este conhecimento poder ser perdido, devemos criar estruturas que permitam armazenar as informaes de projeto. Por que o membro escolheu a opo de projeto 1 em vez da opo de projeto 2? Quais as vantagens e desvantagens desse material em relao ao outro? Note que por mais que tenhamos uma estrutura capaz de armazenar muito conhecimento, nunca possvel a obteno de 100% de eficincia no armazenamento das informaes, j que dizer isso seria a mesma coisa que dizer que Engenheiros Mecnicos no so necessrios para o projeto de um carro. A soluo proposta na gesto de 2011 para este problema foi a criao dos documentos chamados books, que tem por objetivo armazenar informaes a respeito de decises de projeto, comparao entre alternativas, procedimentos de anlises, restries, processos de fabricao, dentre outros. 3) Verificar resultados A estrutura que utilizamos a partir de books est funcionando? O que pode ser melhorado? O mesmo modelo de documento pode ser aproveitado para todos os subsistemas? Encontrem mais perguntas como essas que permitam avaliar a eficincia da ao corretiva. Caso no se tenha conseguido obter a resoluo do problema, o que est impedindo que isso ocorra? Sugesto: Usar ferramenta dos cinco porqus para alcanar a causa-raz do problema. R book no funciona -> Por que? (1) Falta de conhecimento em termos de interfaces -> Por que? (2) No temos ferramentas e processos que permitam tal anlise -> Por que? (3) Falta de estudo sobre o assunto -> Por que? (4) No temos referncias suficientes -> Por que? (5) Falta de pesquisa / assunto muito difcil de ser encontrado Causa raiz do problema

4) Garantir que o problema no volte Quais as medidas que podem ser tomadas para garantir o desaparecimento da causa raiz do problema? Como mudar e garantir que as coisas continuem funcionando como desejamos? Soluo: Manter um banco de dados atualizados e com referncias que adicionem conhecimento a equipe. No existe O melhor livro. O melhor livro aquele que funciona pra voc. No descuidar do estudo em anlise de interferncias e mostrar aos subsistemas a razo do trabalho que fazemos em vez de simplesmente realiz-lo.

2.2 Etapas do nosso processo Este espao dedicado para a explicao do processo de desenvolvimento atual da equipe. Ele dever ser melhorado pelas prximas geraes e inserido aqui, de maneira que a comparao entre diferentes anos possa ser feita e os avanos medidos. Detalhes maiores sobre cada teoria aplicada devero ser adicionados a Apostila nos devidos captulos.

Ano: Membros da equipe de desenvolvimento:

2010 / 2011 Afonso Teberga Campos Guilherme Ribeiro da Silva (at meio de 2011) Renan Medes (at 11 de dezembro de 2011) Leandro Zanuni Garcia Ricieri Lima de Oliveira Natanael Srgio Rssi Fernandes Junior (at fim de 2010)

Etapas realizadas: Definio Finalizao Aplicao

Lean
Tcnicas de integrao de projeto

Diviso do carro em subsistemas: Estrutura, Direo, Motor e Eletrnica

Finalizao do projeto

Anlise de funes e componentes. Realizao da DSM do primeiro prottipo.

Otimizao multiobjetiva como geratriz de alternativas de projeto

Utilizao das checklists e atividades de ps-projeto

Criao de ferramentas para armazenagem de conhecimento / vrias alternativas

Concientizao da equipe em relao ao DFMA e aplicao

Construo

Alimentar book

Tcnicas de controle

Criao dos books e aperfeioamento

Anlise dos erros cometidos e suas causas: Solues

Possveis causas
Falha na captura de relaes

Metodologia ineficiente

Melhorar planilha de captura de relaes

Motivao em relao ao trabalho da equipe de desenvolvimento Problemas de dilogo entre equipes

Promover apresentaes / material tutorial

DSM no condizente

Fluxo de informao ineficiente

Falta de conhecimento

Inexperincia

Tempo de projeto / estudo

Abandonar tpico No aplicvel No adaptao s metodologias da literatura (DFSS, Lean PDP) Falta de conhecimento Adaptar para o uso na equipe

Estudar

Listagem de ferramentas e conceitos aplicados: Books (Captulo 5) DFMA (Captulo 8) Otimizao (Captulo 10) DSM (Captulo 4) Folhas A3 (Captulo 7) Estudo FMEA (Captulo 8)

2.3 Implementao gradativa baseada em melhoria contnua Como espera-se que o projeto v durar muitas geraes, essencial uma estrutura baseada na melhoria contnua e no aprendizado. Para isso, dever ocorrer uma gesto de conhecimento eficiente e a total conscientizao dos novos membros do importante papel da gesto do desenvolvimento na equipe Cheetah Racing. papel de cada capito garantir que estes conceitos sejam passados adiante e que o conhecimento da Gesto do Desenvolvimento no se perca ao longo das geraes.

Como melhorar este material (e conseqentemente conseguir um PDP mais consistente)? PDCA Fase Objetivo 1 Identificao do Definir problema e problema reconhecer sua importncia 2 Observao Investigar caractersticas do problema com viso ampla e sob vrios pontos de vista 3 Anlises Descobrir causas fundamentais 4 Plano de ao Conceber plano para bloquear causas fundamentais 5 Ao Bloquear as causas fundamentais 6 Verificao Verificar se o bloqueio foi efetivo 7 Bloqueio foi efetivo? (Sim: 8; No:2) 8 Padronizao Prevenir contra o reaparecimento do problema 9 Concluso Recapitular todo o processo de soluo do problema para trabalho futuro (Documentar).

D C

2.4 Processo de desenvolvimento de produto ideal O processo de desenvolvimento de produto ideal aquele que tentaremos atingir ao longo dos anos. No adianta tentar seguir alguns passos e ferramentas e dizer que temos um processo consistente. Um PDP eficiente poder ser obtido somente quando toda a equipe trabalhar sob a mesma cultura, quando todos estiverem voltados ao mesmo objetivo, respeitando as restries estabelecidas pela equipe de desenvolvimento e seguindo suas orientaes.

Leva-se um grande tempo para que se atinja esse estado e no meio do caminho, como j observado, pode ser que notemos que algumas partes do PDP ideal no aplicvel em aspectos prticos, necessitando adaptao. Tudo que j foi adaptado ao processo atual da equipe deve ser adicionado na seo (2.2). O processo de desenvolvimento ideal leva em conta todos os tpicos presentes neste material, ou seja, no discutiremos todos os temas nesta seo. Colocaremos aqui, em poucas linhas, os procedimentos do PDP e a ordem em que eles deveriam ser realizados. Baseando no DFSS: 1. Project Charter I Indentificao de mtodo Obteno 2. para obter da voz do Requerimentos necessidade cliente do cliente 1. Traduo dos CTS C 2. Gerar alternativas de Utilizar TRIZ design 3. Evoluir alternativas 1. Otimizar alternativas O 1. Testes e refinamento V Uso de evento integrante DOE Utilizar Otimizao Design para gerar Axiomtico alternativas Tcnica PUGH Taguchi / Design para tolerncia FMEA Books para gerar alternativas DFMA Simulao Design Robusto Adpatao para parmetros de engenharia Identificar parmetros criticos para a qualidade (CTQ, CTC)

Estabelece mtricas Mapeamento para os de interfaces parmetros

Otimizao multiobjetiva Verificao da capacidade do processo Propostas de melhorias ao processo

DFMEA

Checklists

As fontes de conhecimento utilizadas foram: Livro: TQC Controle da Qualidade Total (Falconi, 2 edio, disponvel na BIM)

2.5 Indicador para a situao atual do PDP da equipe Porcentagem do carro que est construdo De acordo com o ano anterior, quantos componentes do projeto atual j foram construdos ou projetados? Quanto tempo demorou para que isso fosse feito? Quais as razes nas diferenas de tempo gastos nessas reas do projeto de um ano para o outro? (Impossvel fazer para 2011 pois o primeiro projeto e no h maneira de realizar a comparao) Cumprimento do cronograma Verificar se as atividades propostas foram cumpridas. Organizar as atividades segundo um ciclo de cadncia (ver Lean Development), ou seja, orientado por meio de metas curtas e eventos integrantes. Para o cronograma 2011 ainda no utilizou-se o conceito de cadncia, mas podemos comear a implementar a partir de 2012 Atividade: Estudar sobre ciclo de cadncia, Accoutability Board e preparar uma apresentao sobre o conceito para os membros do Frmula SAE.

Cronograma frias 2011: 11 12 13 14 15 16 17 18 19 20 21 22 DIREO Fixao da bellcrank Fixao da barra estabilizadora Fixao da Cx de direo Fixao do amorecedor Fixao da coluna de direo ESTRUTURA Fixao da parede corta-fogo Fixao do apoio da cabea Fixao dos pontos do cinto Fixao da armao dos pedais Trelias jacking point POWERTRAIN Fixao do motor Fixao do eixo traseiro\coroa Fixao do coletor de admisso Fixao do coletor de exausto Fixao do pedal de embreagem e aceler. Fixao do passador de marcha mecnico(reserva)

Fixao dos tanques de leo e combustvel Fixao do protetor da corrente ELETRNICA Fixao do master switch do freio Fixao do display do 7 segmentos Fixao do LEDs de RPM Fixao do master switch geral Fixao do sensor da suspenso Fixao do sensor de rotao da roda Fixao dos componentes eletrnicos (mdulo) Implementar sistema da troca de marcha Clculo da vlvula injetora Definir dimenso do encaixe dos sensores Definir condicionador de sonda lambda 2.6 Importncia da Gesto do Conhecimento para as futuras geraes Como veremos adiante, fundamental que a equipe de desenvolvimento se baseie no armazenamento do conhecimento til para que as prximas geraes aprendam com os nosso erros e para que no soframos com o que ocorre com tantas equipes de projetos especiais. trabalho dos membros do nosso subsistema criar essa estrutura baseada em melhoria contnua. 2.7 Fontes de informao

3. Engenharia de Sistemas e a diviso da equipe Definio segundo Nasa Handbook:

Sistema: Conjunto de diferentes elementos que produzem juntos resultados no obtidos por elementos sozinhos. Exemplos desses elementos so pessoas, hardwares, softwares, documentos, etc. Resultado (resposta) de um sistema: Comportamento, propriedades, caractersticas e funes de um sistema. Agregao de valor em sistemas: o valor agregado pelo sistema como um todo, independente da participao de cada componente isoladamente. uma maneira de organizar os pensamentos de uma organizao de forma lgica, atendendo aos requerimentos dos stakeholders, que no caso do projeto so os juzes e os patrocinadores.

A aplicao da engenharia de sistemas no Formula SAE est muito ligada a procura de um projeto balanceado e seguro, que diminui o risco de aes contraditrias no sistema. funo dos membros da equipe de desenvolvimento cadenciar e otimizar as interfaces dos sistemas do veculo e os prprios sistemas como um todo. Alguns exemplos de funes de engenheiros de sistemas: Definir requisitos Decises trade-off Medir riscos entre sistemas Definir interfaces Desenvolver documentos de auxilio (no nosso caso, books)

Podemos dividir a gesto de um projeto complexo em duas reas distintas: Engenharia de sistemas e Controle de projeto

3.2 Design Strucuture Matrix