DALICIO GUIGUER FILHO

CO-DESENVOLVIMENTO DE PRODUTO UM ESTUDO NA INDSTRIA AUTOMOTIVA.

Trabalho apresentado Escola Politcnica da Universidade de So Paulo, para obteno do Ttulo de Mestre em Engenharia.

So Paulo 2005

DALICIO GUIGUER FILHO

CO-DESENVOLVIMENTO DE PRODUTO UM ESTUDO NA INDSTRIA AUTOMOTIVA.

Trabalho apresentado Escola Politcnica da Universidade de So Paulo, para obteno do Ttulo de Mestre em Engenharia.

rea de concentrao: Engenharia Automotiva

Orientador: Prof. Dr. Paulo Carlos Kaminski

So Paulo 2005

Guiguer Filho, Dalicio Co-desenvolvimento de produto: um estudo na indstria automotiva / D. Guiguer Filho. -- So Paulo, 2005. 103 p. Trabalho de curso (Mestrado Profissionalizante em Engenharia Automotiva). Escola Politcnica da Universidade de So Paulo.

FICHA CATALOGRFICA 1.Projeto automotivo 2.Desenvolvimento de produto I.Universidade de So Paulo. Escola Politcnica. II.t.

II

AGRADECIMENTOS
Ao Professor Paulo Kaminski, orientador deste trabalho, por todo suporte e apoio recebido.

Ao Professor Dieter Pfau pela colaborao durante o perodo que estive na Alemanha.

Aos Professores Paulo Alt e Fernando Laugeni pelas informaes que suportaram minha deciso quanto ao curso de mestrado.

Ao meu filho, Thiago, por ter me recompensado com a alegria do seu nascimento em 22 de fevereiro de 2005.

A minha esposa Rejane, pelo incentivo e compreenso durante o tempo que dediquei ao curso de mestrado.

Aos meus pais, Dalicio e Leda, pelo incentivo recebido.

Aos demais professores do curso e a todos que, diretamente ou indiretamente, colaboraram na execuo deste trabalho.

III

RESUMO

A crescente tendncia de participao dos fornecedores no processo de desenvolvimento de produto da indstria automotiva, faz com que o estudo desta parceria se torne importante, tanto para as montadoras quanto para os fornecedores. O principal objetivo desta parceria a utilizao da capacidade de engenharia dos fornecedores (know-how), permitindo assim, a incorporao de novas tecnologias ao veculo e a reduo dos custos de desenvolvimento das montadoras. Observa-se cada vez mais dentro da montadora, discusses sobre o co-desenvolvimento (co-design) nos projetos automotivos, nveis de integrao com o fornecedor, fase do projeto adequada para o envolvimento dos fornecedores, o nvel adequado de detalhamento das especificaes tcnicas utilizadas como referncia inicial pelos fornecedores, a definio das responsabilidades de cada parceiro e o prprio processo para realizao do desenvolvimento em parceria. O presente trabalho explora de que forma tais questes so atualmente abordadas na subsidiria brasileira de uma montadora, atravs do estudo de seus processos e ferramentas e da comparao com as informaes disponveis na bibliografia e estudadas no meio acadmico. Com este trabalho, pretende-se fornecer informaes que possam auxiliar montadoras e fornecedores na melhoria de seus processos internos de desenvolvimento de produto, principalmente nas questes relativas ao co-desenvolvimento (co-design).

IV

ABSTRACT

The increasing trend of suppliers participation in the automotive industry product development process makes the study of this partnership important for automakers and suppliers. The main objective of this partnership is to take advantage of suppliers engineering capability (know-how) in order to bring new technologies to the vehicle and reduce automakers development costs. It is becoming more and more common inside automakers, discussions regarding co-design in automotive projects, supplier integration levels, suitable project phase to get suppliers involved, suitable level of details for automakers technical specifications used as initial reference by suppliers, the responsibilities definition of each partner and the process to perform development in a partnership relation. This work explores how these issues are currently addressed in a Brazilian automaker subsidiary, through the study of its processes and tools and the comparison with the information available in the bibliography and studied academically. Finally, this work intends to provide information that can assist automakers and suppliers to improve their internal product development processes, mainly regarding co-design.

SUMRIO
LISTA DE TABELAS LISTA DE FIGURAS

1 INTRODUO............................................................................................

2 RELACIONAMENTO CLIENTE-FORNECEDOR.................................... 2.1 Relacionamento Cliente-Fornecedor no Desenvolvimento de Produtos........................................................................................... 2.2 Vantagens do Co-desenvolvimento...................................................... 2.3 Dificuldades do Co-desenvolvimento.................................................. 2.4 Desafios do Co-desenvolvimento......................................................... 2.5 Participao do Co-desenvolvimento na Indstria Automotiva........... 2.6 Anlises e Concluses..........................................................................

4 6 7 8 11 13

3 DESENVOLVIMENTO DE PRODUTO..................................................... 3.1 Categorizao do Projeto..................................................................... 3.2 Desenvolvimento de Produto, Produo e Consumo........................... 3.3 Processo de Desenvolvimento de Produto........................................... 3.4 Processo de Desenvolvimento de Produto segundo o APQP............... 3.5 Participao de Fornecedores no Desenvolvimento............................. 3.6 Anlises e Concluses..........................................................................

15 15 19 21 26 33 40

4 ESTRATGIA DA MONTADORA PARA O CO-DESENVOLVIMENTO........................................................................ 4.1 Estratgia Global da Montadora .......................................................... 4.2 Classificao quanto ao Nvel de Integrao Permitido....................... 4.3 Distribuio dos Recursos de Projeto................................................... 4.4 Potencial de Participao do Fornecedor no Desenvolvimento........... 4.5 Anlises e Concluses.......................................................................... 42 42 45 47 51 55

VI

5 CO-DESENVOLVIMENTO E O PROCESSO

DE 57 59 63 66 69 74 76

DESENVOLVIMENTO DE PRODUTO..................................................... 5.1 Processo de Desenvolvimento de Veculo........................................... 5.2 Equipe de Desenvolvimento de Produto.............................................. 5.3 Processo de Co-Desenvolvimento........................................................ 5.4 Especificao do Sistema, Sub-Sistema ou Componente.................... 5.5 Definio do Custo-Objetivo............................................................... 5.6 Seleo do Fornecedor......................................................................... 5.7 Gesto do Desenvolvimento do Sistema, Sub-Sistema ou Componente......................................................................................... 5.8 Anlises e Concluses..........................................................................

78 82

6 DISCUSSES FINAIS................................................................................. 6.1 Relacionamento Cliente-Fornecedor.................................................... 6.2 Processo Integrado de Desenvolvimento de Produto e Fornecimento. 6.3 Caractersticas do Co-Desenvolvimento..............................................

92 92 93 95

7 CONCLUSES E CONSIDERAES FINAIS.........................................

99

REFERNCIAS BIBLIOGRFICAS................................................................

101

VII

LISTA DE FIGURAS
Figura 1.1 Estrutura do trabalho........................................................................ Figura 2.1 Relao cliente-fornecedor assimtrica............................................ Figura 2.2 Relao cliente-fornecedor simtrica ou equivalente....................... Figura 2.3 Atividades de um processo integrado de desenvolvimento de produto e fornecimento.................................................................... Figura 2.4 Classificao dos componentes produzidos pelos fornecedores...... Figura 2.5 Distribuio percentual dos componentes da lista de materiais em funo do nvel permitido de co-desenvolvimento........................... Figura 3.1 Funil de desenvolvimento................................................................. Figura 3.2 Categorias primrias de projetos de desenvolvimento..................... Figura 3.3 Desenvolvimento de produto como uma simulao do consumo.... Figura 3.4 Ciclo de produo e consumo........................................................... Figura 3.5 Fases do processo de desenvolvimento de produto.......................... Figura 3.6 Espiral de projeto.............................................................................. Figura 3.7 Fases do PDP segundo o APQP....................................................... Figura 3.8 Fluxo de informao sumarizado do APQP..................................... Figura 3.9 Fluxo de informao para componentes proprietrios de fornecedor......................................................................................... Figura 3.10 Fluxo de informao para componentes caixa-preta................... Figura 3.11 Fluxo de informao para componentes funcionais controlados no detalhe........................................................................................ Figura 3.12 Fluxo de informao para componentes de carroceria controlados no detalhe....................................................................................... Figura 4.1 Estratgia global da montadora para o co-desenvolvimento........... Figura 4.2 Capacitao da base de fornecedores............................................... Figura 4.3 Distribuio dos recursos de projeto................................................ Figura 4.4 Distribuio dos recursos de engenharia........................................ Figura 4.5 Participao do co-desenvolvimento no total do projeto................ Figura 4.6 Procedncia dos componentes.......................................................... 38 42 43 49 50 50 52 37 34 36 13 15 16 19 20 21 23 27 33 9 12 2 5 6

VIII

Figura 4.7 Nvel de integrao permitido dentre os componentes comprados no padronizados............................................................................... Figura 4.8 Potencial de co-desenvolvimento segundo a estratgia da empresa. Figura 4.9 Proposta de formato para o cdigo de pea (part number).............. Figura 5.1 Exemplo de integrao com o fornecedor........................................ Figura 5.2 Comparao de teste real com resultado de simulao.................... Figura 5.3 Sub-processos do processo de desenvolvimento de veculo (VDP). Figura 5.4 Ilustrao do processo de desenvolvimento de veculo (VDP)........ Figura 5.5 Estrutura matricial das equipes de desenvolvimento de produto..... Figura 5.6 Representao da interao entre as reas funcionais...................... Figura 5.7 Etapas do co-desenvolvimento e seus fatores de influncia............. Figura 5.8 Cadeia de especificaes no desenvolvimento de um veculo......... Figura 5.9 Necessidade de especificaes quantitativas em funo do estgio do relacionamento cliente-fornecedor............................................... Figura 5.10 Estrutura das especificaes dos sub-sistemas e componentes na montadora estudada........................................................................ Figura 5.11 Exemplo de matriz de responsabilidades........................................ Figura 5.12 Representao esquemtica da definio do custo-objetivo de componentes comprados................................................................. Figura 5.13 Processo de seleo dos fornecedores............................................ Figura 5.14 Modelo de lista de pendncias........................................................ Figura 5.15 Envolvimento do fornecedor em funo do processo de seleo de fornecedores adotado.................................................................. Figura 6.1 Posicionamento da montadora estudada quanto ao relacionamento cliente-fornecedor............................................................................. 92 86 75 76 80 71 73 71 53 54 56 58 58 59 60 64 65 68 69

IX

LISTA DE TABELAS
Tabela 3.1 Exemplos de atividades tpicas na espiral de projetos..................... Tabela 3.2 Quadro-resumo da fase de planejamento......................................... Tabela 3.3 Quadro-resumo da fase de desenvolvimento e projeto do produto.. Tabela 3.4 Quadro-resumo da fase de desenvolvimento e projeto do processo Tabela 3.5 Quadro-resumo da fase de validao do produto e do processo...... Tabela 3.6 Quadro-resumo da fase de avaliao, re-alimentao do processo e aes corretivas............................................................................. Tabela 3.7 Participao do fornecedor em funo do relacionamento.............. Tabela 4.1 Integrao com o fornecedor............................................................ Tabela 4.2 Responsabilidades em funo do nvel de integrao...................... Tabela 4.3 Exemplos de classificao quanto ao nvel de integrao................ Tabela 4.4 Relao entre a modificao e o recurso para co-desenvolvimento. Tabela 5.1 Exemplos de requisitos descritos nos diversos nveis de especificao.................................................................................... Tabela 5.2 Formulrios de verificao previstos no APQP............................... Tabela 5.3 Atividades do plano de projeto com envolvimento do fornecedor.. Tabela 5.4 Observaes e sugestes quanto ao processo de desenvolvimento de produto (PDP)............................................................................. Tabela 5.5 Observaes e sugestes quanto organizao do trabalho............ Tabela 5.6 Observaes e sugestes quanto s especificaes tcnicas............ Tabela 5.7 Observaes e sugestes quanto definio do custo-objetivo....... Tabela 5.8 Observaes e sugestes quanto seleo dos fornecedores........... Tabela 5.9 Observaes e sugestes quanto gesto do co-desenvolvimento.. Tabela 6.1 Atividades do IPDS na montadora estudada Gesto do Desenvolvimento............................................................................. Tabela 6.2 Atividades do IPDS na montadora estudada Gesto da Interface com o Fornecedor............................................................................. Tabela 6.3 Atividades do IPDS na montadora estudada Gesto do Projeto... Tabela 6.4 Atividades do IPDS na montadora estudada Gesto do Produto.. Tabela 6.5 Observaes quanto s caractersticas do co-desenvolvimento na montadora estudada.......................................................................... 96 94 94 95 93 88 88 89 90 91 91 70 78 79 32 39 44 46 46 47 24 28 29 30 31

LISTA DE ABREVIATURAS E SIGLAS

APQP Advanced Product Quality Planning (Planejamento Avanado da Qualidade do Produto) BOM Bill of Material (Lista de Material) CAD Computer Aided Design (Projeto Auxiliado por Computador) CAE Computer Aided Engineering (Engenharia Auxiliada por Computador) DFM / DFA Design for Manufacturability / Design for Assembly (Projeto orientado Manufatura / Projeto orientado Montagem) DFMEA Design Failure Mode and Effects Analysis (Anlise do Modo de Falha e Efeito para o Projeto) DMU Digital Mock-Up (Modelo Digital) FDM Fused Deposition Modelling (Modelamento por Deposio Fuso) IPDS Integrated Product Development and Sourcing (Processo Integrado de Desenvolvimento de Produto e

Fornecimento) PDP Product Development Process (Processo de Desenvolvimento do Produto) PDT Product Development Team (Equipe de Desenvolvimento de Produto) PFMEA Process Failure Mode and Effects Analysis (Anlise do Modo de Falha e Efeito para o Processo) PPAP Production Part Approval Process (Processo de Aprovao de Pea de Produo) STL Stereolithography (Estereolitografia) VDP Vehicle Development Process (Processo de Desenvolvimento de Veculo)

XI

VR

Virtual Reality (Realidade Virtual)

1 INTRODUO

Com a crescente tendncia de participao dos fornecedores no processo de desenvolvimento de produto na indstria automotiva, o estudo desta parceria torna-se importante, tanto para as montadoras quanto para os fornecedores. O principal objetivo desta parceria a utilizao da capacidade de engenharia (know-how) dos fornecedores, permitindo assim, a incorporao de novas tecnologias ao veculo e a reduo dos custos de desenvolvimento das montadoras. Os aspectos relacionados a esta gesto so abrangentes, incluindo-se a dimenso da participao do co-desenvolvimento (co-design) nos projetos automotivos, os nveis de integrao com o fornecedor, a fase do projeto adequada para a participao dos fornecedores, o nvel adequado de detalhamento das especificaes tcnicas utilizadas como referncia inicial pelos fornecedores, a definio das responsabilidades de cada parceiro e o prprio processo para realizao do desenvolvimento em parceria. Em funo destes aspectos, tanto o processo de desenvolvimento de produto da montadora como o do fornecedor, devem ser adaptados e complementados, evitando-se assim, desgastes comerciais, atrasos desnecessrios, custos adicionais no planejados e falta de qualidade no produto final. O objetivo deste trabalho estudar os processos e ferramentas existentes em uma montadora, identificando de que forma os aspectos citados so atualmente abordados em seus processos internos, buscando-se assim, oportunidades de melhoria atravs da comparao dos processos e ferramentas identificados, com os disponveis na bibliografia e estudados no meio acadmico. O presente trabalho est estruturado em sete captulos, onde h uma introduo ao assunto e uma reviso da literatura nos captulos 1, 2 e 3. Na seqncia, o captulo 4 apresenta o estudo da estratgia da montadora para o codesenvolvimento (co-design) e o captulo 5 apresenta o estudo do processo de desenvolvimento de produto da montadora e sua relao com os aspectos do codesenvolvimento (co-design). Finalmente, o captulo 6 traz uma discusso adicional de alguns aspectos observados durante este estudo e o captulo 7 apresenta as concluses e consideraes finais. A figura 1.1 ilustra a estrutura do presente trabalho.

Reviso da Literatura

Parcerias

Estratgias

Estudo na Montadora

Co-Design

Processos

PDP

Prticas

Anlises, Concluses e Recomendaes

Figura 1.1 Estrutura do trabalho

Por fim, pretende-se com esse trabalho, fornecer informaes que possam auxiliar montadoras e fornecedores na melhoria de seus processos internos de desenvolvimento de produto, principalmente nas questes relativas ao codesenvolvimento (co-design).

2 RELACIONAMENTO CLIENTE-FORNECEDOR

Em uma abordagem convencional, as empresas consideravam seus fornecedores como quase adversrios, tendo como idia central que estes estavam sempre querendo auferir o mximo lucro e por isso era necessrio um processo com vrias cotaes, envolvendo vrios fornecedores concorrentes, alm de detalhadas e dispendiosas inspees no recebimento do produto (MARTINS e ALT, 2003). Ao longo dos ltimos anos tem-se observado uma evoluo nesse relacionamento, procurando o desenvolvimento de um grau de confiana mtua baseado em uma relao caracterizada como ganha-ganha, que se convencionou chamar de parceria. Segundo MARTINS e ALT (2003), na parceria, o fornecedor participa no projeto do produto, na anlise e melhoria do processo produtivo do cliente, garante a qualidade e abre sua planilha de formao de custos e preos, tendo como retribuio um contrato de fornecimento por um perodo normalmente igual ao da vida do produto que fornece. MERLI (1994) define como comakership quando esta relao de parceria atinge um alto grau de evoluo. Ainda segundo MERLI (1994), a evoluo no relacionamento clientefornecedor passa por quatro nveis distintos, a saber:

a) Primeiro nvel - Abordagem convencional Slogan de referncia: Os fornecedores so pontos de venda onde compramos pelo melhor preo. (MERLI, 1994). Neste nvel de relacionamento, prioriza-se o preo e as condies so impostas pela empresa com maior poder. O cliente desconfia da qualidade do fornecedor, realizando um maior controle sobre os recebimentos.

b) Segundo nvel - Melhoria da qualidade Slogan de referncia: Fazer a qualidade junto aos fornecedores. (MERLI, 1994). Prioriza-se a qualidade, iniciando-se um relacionamento mais duradouro com um nmero mais reduzido de fornecedores.

c) Terceiro nvel - Integrao operacional Slogan de referncia: O processo produtivo comea na casa do fornecedor. (MERLI, 1994). Na integrao operacional, prioriza-se o controle e a capabilidade dos processos. Tambm, existe um certo grau de participao do fornecedor no projeto do produto (co-desenvolvimento) e do processo do cliente, alm de eventualmente desenvolvimento. ambos realizarem investimentos conjuntos em

d) Quarto nvel - Integrao estratgica Slogan de referncia: Fazer negcios juntos. (MERLI, 1994). Atingido esse nvel de relacionamento, tem-se uma parceria de negcios com uma ampla participao do fornecedor no projeto do produto (co-desenvolvimento) e do processo do cliente, acordos sobre estratgias e polticas em nvel mximo, gerenciamento comum dos procedimentos de negcios e sistemas integrados de qualidade.

2.1 Relacionamento Cliente-Fornecedor no Desenvolvimento de Produtos

A parceria cliente-fornecedor quando direcionada para o desenvolvimento de produtos usualmente definida como co-desenvolvimento ou co-design. A consolidao do processo de co-desenvolvimento vem modificando a relao clientefornecedor e incorporando vantagens e riscos para ambos parceiros. Segundo WOGNUM et al (2002), quando comparado com a situao de anos atrs, as atribuies dos fornecedores se modificaram profundamente, sendo as principais mudanas citadas abaixo:

a) Aumento do valor agregado Os fornecedores deixaram de ser meros fabricantes de componentes e passaram a ter a atribuio do desenvolvimento desses componentes, agregando valor ao produto entregue aos seus clientes (montadoras). Em paralelo, as montadoras (clientes) passaram a requisitar de seus fornecedores no apenas os componentes, mas sim o sistema ou sub-sistema completo, o que gera um valor agregado ainda mais alto.

b) Relacionamentos de parcerias mais duradouros Tradicionalmente, os contratos de fornecimento eram de um ou dois anos, o que permitia que durante o ciclo de vida de um produto vrias empresas fornecessem um mesmo componente. Como no co-desenvolvimento, o fornecedor envolvido desde a fase de projeto, existe uma maior complexidade para uma troca de fornecedor (parceiro), o que faz com que essa relao de parceria normalmente se estenda por todo ciclo de vida do produto.

c) Maior interdependncia entre os parceiros Uma vez que com o co-desenvolvimento, o fornecedor passa agregar um valor maior em seu componente e a ter uma relao de parceria mais duradoura com seu cliente (montadora), este por sua vez passa a ser mais dependente do conhecimento (know-how) do fornecedor sobre o componente. Sem o co-desenvolvimento, essa dependncia bem menor, pois apenas como fabricante de um componente, o fornecedor segue as especificaes do cliente (montadora) e por sua vez a montadora tem uma oferta muito maior de fornecedores disponveis para apenas produzir o componente.

Em funo dessas mudanas, a relao de poder tradicionalmente assimtrica, onde a parte mais forte, normalmente o cliente, impunha os requisitos para a outra parte (figura 2.1), se modificou para uma relao de equivalncia (simtrica), onde ambas as partes podem influir nas condies do processo de co-desenvolvimento (figura 2.2).

Cliente influencia Fornecedor

Cliente

Fornecedor

Figura 2.1 Relao cliente-fornecedor assimtrica (WOGNUM et al, 2002)

Influncia de ambas as partes

Cliente

Fornecedor

Figura 2.2 Relao cliente-fornecedor simtrica ou equivalente (WOGNUM et al, 2002)

2.2 Vantagens do Co-desenvolvimento

Durante a dcada de 1990 a 2000, diversos estudos foram realizados sobre o co-desenvolvimento. Tais estudos mostraram que se integrando melhor com seus fornecedores, as montadoras japonesas foram capazes de projetar e desenvolver automveis em uma cadncia mais rpida, com maiores inovaes tecnolgicas e com menos esforo em termos de horas de desenvolvimento e engenheiros envolvidos (WYNSTRA et al, 2001). Isso foi resultado do uso do conhecimento adicional e especializado do fornecedor, que permite o desenvolvimento do produto com maior eficincia, menos informaes iniciais (inputs), menos custos de desenvolvimento, menos horas de engenharia, menos alteraes no projeto e ainda com maiores resultados (outputs), tais como: um melhor produto, um produto com maiores inovaes e um tempo menor de introduo do produto no mercado (CLARK, 1989 apud WYNSTRA et al, 2001). Apesar do recente interesse pelo processo de co-desenvolvimento, dados mostram que j em 1958 a Toyota utilizava engenheiros residentes de seus fornecedores em seu processo de desenvolvimento (NISHIGUCHI, 1994 apud WYNSTRA et al, 2001). Segundo WOGNUM et al (2002), o co-desenvolvimento oferece a possibilidade de acesso rpido ao conhecimento especializado do fornecedor, permitindo compartilhar os custos e os riscos. Tambm, com a viso pelo lado dos fornecedores, CHUNG e KIM (2003) demonstraram em seu estudo que o co-desenvolvimento tem impactado no desempenho dos fornecedores, levando, por exemplo, a um maior nvel de inovao, constatado atravs de um nmero maior de patentes depositadas pelos fornecedores que trabalham em parceria com seus clientes no desenvolvimento de produtos.

2.3 Dificuldades do Co-desenvolvimento

Por outro lado, dois estudos americanos de meados dos anos 90 mostraram evidncias de que o co-desenvolvimento nem sempre benfico. O primeiro estudo mostrou que o envolvimento do fornecedor na fase inicial do processo de desenvolvimento, com grande responsabilidade atribuda ao fornecedor pelo desenvolvimento de seu componente, no trouxe reduo no custo de

desenvolvimento, reduo no perodo de desenvolvimento (lead-time) e nem to pouco um nvel mais alto de qualidade no produto final (HARTLEY, 1994; HARTLEY et al, 1997; McCUTCHEON et al, 1997 apud WYNSTRA et al , 2001). O segundo estudo tambm mostrou que o co-desenvolvimento resultou em custos mais altos para o produto e para o desenvolvimento, alm de uma pior performance do produto e um perodo maior de desenvolvimento (BIROU, 1994 apud WYNSTRA et al, 2001). Tambm, segundo WYNSTRA et al (2001), existem trs fontes de problemas para um relacionamento de parceria, onde esteja presente a integrao entre os processos de desenvolvimento de produto e fornecimento do componente (codesenvolvimento), a saber:

a) O relacionamento como fonte dos problemas Consideram-se problemas em funo do relacionamento, os

problemas que no podem ser primariamente atribudos apenas ao fornecedor ou montadora. Tipicamente, problemas como a falta de comunicao e confiana, podem conduzir a acordos no totalmente claros, criando divergncia entre as expectativas da montadora e do fornecedor e com isso, impactando negativamente na eficincia do co-desenvolvimento. Por exemplo, a falha de comunicao durante o processo de definio de responsabilidades com relao ao desenvolvimento do produto, pode levar o fornecedor a gerar premissas incorretas da dimenso de suas

responsabilidades, o que por sua vez, pode impactar em sua estratgia e investimentos. Um exemplo mais simples, porm tambm comum, de falta de comunicao, a descoberta tardia de que os sistemas de CAD so incompatveis ou que existem padres diferentes para os desenhos e outras informaes tcnicas.

b) O fornecedor como fonte dos problemas O fornecedor se torna a fonte dos problemas, quando no h a capacitao necessria para assumir o processo de desenvolvimento de produto em parceria (co-desenvolvimento), ou quando o fornecedor no dispe do tempo, da mo-de-obra ou do capital necessrio ao codesenvolvimento, ou ainda, quando o fornecedor tem um interesse limitado em trabalhar com aquela montadora, pois esta representa uma parcela pequena de seu potencial total de vendas.

c) A montadora como fonte dos problemas A fonte dos problemas pode ser a prpria montadora, quando suas questes internas passam a afetar o processo de co-desenvolvimento, como por exemplo, a falta de um processo claro de desenvolvimento de produto, ou melhor, a falta de uma estratgia clara de como e quando os fornecedores devem ser envolvidos nesse processo. Tais questes, podem levar a montadora a selecionar um fornecedor com capacidade limitada de inovao, ou ainda, utilizar o co-desenvolvimento para um componente em que essa estratgia no necessria ou no benfica.

2.4 Desafios do Co-desenvolvimento

Esta aparente contradio nos resultados dos estudos com relao s vantagens e dificuldades no processo de co-desenvolvimento de produto mostra a natureza complexa desse relacionamento. WYNSTRA et al (2001) propem trs condies para o sucesso de um processo de co-desenvolvimento, a saber:

a) Identificar as tarefas e processos especficos que faro parte do codesenvolvimento, colocando maior foco na integrao dos processos de desenvolvimento de produto e fornecimento;

b) Formar uma organizao que suporte a execuo de tais tarefas e processos;

c) Alocar pessoas nessa organizao que tenham os conhecimentos tcnicos, comerciais e sociais necessrios.

A figura 2.3 apresenta as atividades de um processo integrado de desenvolvimento de produto e fornecimento (IPDS).

Tempo Gesto do Desenvolvimento - Determinar quais tecnologias devem ser mantidas ou desenvolvidas
internamente e quais externamente; - Estabelecer polticas para o envolvimento de fornecedores; - Estabelecer polticas para as atividades dos departamentos internos em um processo integrado de desenvolvimento de produto e fornecimento; - Comunicar as polticas internamente e externamente; - Monitorar o mercado de fornecedores para desenvolvimentos tcnicos; - Pr-selecionar fornecedores para colaborao em desenvolvimento de produto; - Motivar os fornecedores a manterem ou construrem uma base de conhecimentos ou desenvolverem certos produtos; - Explorar a capacidade tcnica dos fornecedores; - Avaliar o desempenho dos fornecedores quanto ao desenvolvimento, inclusive na sua pontuao geral;

Gesto da Interface com o Fornecedor

Gesto do Projeto
Desenvolvimento do Conceito

Projeto Bsico

Detalhamento Engenharia

Piloto e Incio de Produo

- Selecionar fornecedores para o envolvimento no projeto de desenvolvimento; - Determinar a extenso do envolvimento do fornecedor; - Determinar o momento do envolvimento do fornecedor; - Coordenar as atividades do desenvolvimento; - Coordenar as atividades do projeto bsico; - Coordenar as atividades de engenharia; -Coordenar a prototipagem e o incio de produo;

Gesto do Produto - Fornecer informao sobre os novos produtos e/ou tecnologias;

- Sugerir alternativas de fornecedores, produtos e/ou tecnologias; - Avaliar os projetos de produtos; - Promover a padronizao e a simplificao;

Figura 2.3 Atividades de um processo integrado de desenvolvimento de produto e fornecimento (WYNSTRA et al, 2001)

10

WOGNUM et al (2002) mostram em seu trabalho os desafios para os gerentes de cada uma das organizaes (clientes e fornecedores), atribuindo o sucesso do co-desenvolvimento principalmente comunicao e ao alinhamento organizacional entre os parceiros, com o objetivo de se manter uma relao equilibrada. Os principais desafios para os gerentes das empresas fornecedoras e para os gerentes das empresas clientes, extrados da pesquisa de WOGNUM et al (2002), so citados abaixo:

a) Desafios para os gerentes das empresas fornecedoras

Os fornecedores no so suficientemente pr-ativos na abordagem dos clientes;

Os fornecedores tm muito pouca experincia no gerenciamento dos riscos envolvidos e na seleo e execuo de contratos de longo prazo;

Os fornecedores tm muito pouco conhecimento e experincia em projeto;

Existe pouca padronizao na execuo de atividades necessrias para mais de um cliente.

b) Desafios para os gerentes das empresas clientes

Os clientes ainda tm dificuldade em selecionar os fornecedores adequados;

As atividades no remuneradas solicitadas pelo cliente ao fornecedor s vezes ficam fora do contexto da realidade;

Os clientes tm o questionamento sobre quais atividades podem ser direcionadas ao fornecedor e quais devem permanecer internas sua empresa, sob o risco de perda de conhecimento estratgico;

Os clientes esto pouco cientes da necessidade de adaptarem suas organizaes a nova realidade.

Um aspecto importante a seleo de fornecedores adequados ao desenvolvimento em parceria, o que tem sido um desafio s iniciativas de codesenvolvimento. PETERSEN et al (2003) concluram em seu estudo sobre a integrao de fornecedores no processo de desenvolvimento de novos produtos, que

11

uma avaliao detalhada e formal dos potenciais fornecedores fundamental para o sucesso do desenvolvimento em parceria. Apenas fornecedores de confiana e com histrico positivo deveriam ser considerados no processo de seleo para um desenvolvimento em conjunto, segundo o estudo deles. SARKIS e TALLURI (2002) propuseram um processo analtico, definindo os fatores e critrios a serem considerados na seleo de fornecedores, visando minimizar o risco de se ter fornecedores sem as condies adequadas para a parceria, o que pode impactar negativamente no desenvolvimento do novo produto.

2.5 Participao do Co-desenvolvimento na Indstria Automotiva

LEVERICK e COOPER (1998) estudaram a participao dos fornecedores no desenvolvimento de produto na indstria automotiva do Reino Unido, constatando uma prtica extensiva de co-desenvolvimento, onde, por exemplo, 72% dos fornecedores entrevistados declararam ter responsabilidades pelo desenvolvimento do produto a ser fornecido para montadora. Por outro lado, BEECHAM e CORDEYHAYES (1998) estudando tambm a indstria automotiva do Reino Unido, revelaram que a transferncia de conhecimento (know-how) dependia do grau de parceria, classificando os fornecedores em uma escala de autnomo at integrado, sendo que uma parceria plena s ocorre com os fornecedores integrados, enquanto que fornecedores classificados como autnomos podem realizar apenas uma parceria informal. Os estudos realizados por CLARK e FUJIMOTO (1991) compararam a participao dos fornecedores no desenvolvimento dos componentes do veculo nas indstrias norte-americanas, europias e japonesas, demonstrando que a indstria japonesa j adotava um maior nvel de co-desenvolvimento. A figura 2.4, extrada destes estudos, mostra a distribuio percentual do custo total de material em funo do nvel de participao do fornecedor no desenvolvimento do componente, segundo a classificao de CLARK e FUJIMOTO (vide captulo 3). Por essa classificao, consideram-se componentes proprietrios de fornecedor (supplier proprietary parts), aqueles em que o fornecedor tem o controle do desenvolvimento desde o conceito at a produo; componentes caixa-preta (black box parts), aqueles nos quais h uma co-participao entre a montadora e o fornecedor no esforo de desenvolvimento; e

12

componentes controlados no detalhe (detail-controlled parts), aqueles em que a montadora detm a maior parte do esforo de desenvolvimento.

Estados Unidos

7%

39%

54%

Europa

3% 16%

81%

Japo

8%

62%

30%

0%

20%

40%

60%

80%

100%

Proprietrios de Fornecedor

Caixa-preta

Controlados no Detalhe

Figura 2.4 Classificao dos componentes produzidos pelos fornecedores (CLARK e FUJIMOTO, 1991)

No estudo realizado para este trabalho, constatou-se que 65% dos componentes presentes na lista de materiais (BOM) de um veculo luxo (sedan mdio) e 73% dos componentes de um veculo bsico (hatchback 5 portas), so classificados como componentes para os quais permitido algum nvel de participao do fornecedor no desenvolvimento (co-desenvolvimento), segundo a estratgia da montadora estudada (vide captulo 4). A figura 2.5 mostra a distribuio percentual dos componentes da lista de materiais de dois veculos desta montadora em funo do nvel permitido de co-desenvolvimento, o que representa o potencial para participao de fornecedores no desenvolvimento dos componentes para os veculos desta empresa.

13

Veculo Bsico

73%

27%

Veculo Luxo

65%

35%

Permite co-desenvolvimento

No permite co-desenvolvimento

Figura 2.5 Distribuio percentual dos componentes da lista de materiais em funo do nvel permitido de co-desenvolvimento

2.6 Anlises e Concluses

A competitividade no mercado automotivo atual e a crescente reduo no ciclo de vida do produto, fazem com que as montadoras busquem um processo de desenvolvimento de veculo (VDP) cada vez mais rpido. Onde havia um padro de 48 meses ao final da dcada de 1990, hoje h um padro de 24, 20 e at 18 meses para o desenvolvimento de um veculo. Esta realidade, tem direcionado os esforos das montadoras na incorporao de novas ferramentas e atualizao de seus processos internos, dentre os quais a melhoria na gesto do processo de parceria com seus fornecedores. O custo para se manter uma estrutura de engenharia na montadora capacitada a desenvolver todos os componentes internamente, em tempo adequado e com tecnologia atualizada seria muito alto, mas por outro lado as montadoras no podem correr o risco de perder o controle tecnolgico de seu produto, razo pela qual uma engenharia capacitada e de tamanho adequado fundamental, inclusive para uma boa gesto do co-desenvolvimento. Percebe-se que a maior parte dos componentes existentes na lista de materiais (BOM) de veculos atuais permite algum nvel de co-desenvolvimento, segundo a

14

estratgia do fabricante (figura 2.5), o que evidencia o potencial de participao dos fornecedores no desenvolvimento do veculo. No mais se discute as vantagens e desvantagens de se ter um processo de parceria no desenvolvimento do produto, uma vez que esse processo (codesenvolvimento) j uma realidade e encontra-se em um estgio irreversvel. Discutem-se sim, quais seriam as melhores prticas para a gesto deste processo, quando e como os fornecedores devem ser envolvidos e qual deve ser o nvel de controle e conhecimento da montadora sobre os diversos sistemas do automvel. O modelo apresentado por WYSTRA et al (2001) e mostrado neste captulo (figura 2.3), reflete bem a necessidade de uma gesto integrada entre o processo de desenvolvimento de produto e o processo de fornecimento do componente (IPDS), visando maximizar os efeitos positivos (vantagens) do co-desenvolvimento.

15

3 DESENVOLVIMENTO DE PRODUTO

CLARK e WHEELWRIGHT (1993) apresentam como objetivo de qualquer projeto de desenvolvimento de produto ou processo, a transformao de uma idia ou conceito em realidade, atravs de um produto que atenda s necessidades do mercado de uma forma vivel em termos econmicos e de produo. O processo de desenvolvimento de produto (PDP) pode ser ilustrado de uma forma simplificada como um funil, que transforma idias em realidade (produto). Na entrada so apresentadas vrias idias a serem investigadas, das quais so selecionadas as mais promissoras e finalmente uma vivel para um projeto de desenvolvimento de produto. A partir dessa fase, se ganha velocidade, alocando-se os recursos necessrios para se completar o desenvolvimento do produto e ter uma rpida introduo deste no mercado. A figura 3.1 mostra esse conceito, onde os quadrados brancos indicam idias para investigao e os quadrados pretos idias que so desenvolvidas ou aplicadas.

Figura 3.1 Funil de desenvolvimento (CLARK e WHEELWRIGHT, 1993)

3.1 Categorizao do Projeto

A identificao da categoria de um projeto, no s informa a real dimenso do projeto, bem como auxilia em seu planejamento e execuo, uma vez que cada categoria de projeto ir demandar um nvel diferente de alocao ou disponibilizao

16

de recursos. Apesar de diferentes dimenses poderem ser utilizadas para a categorizao de projetos, a mais usual o grau de alterao necessrio em funo do projeto (CLARK e WHEELWRIGHT, 1993; WHEELWRIGHT e CLARK, 1992). A figura 3.2 define as categorias primrias de projetos de desenvolvimento em funo do grau de alterao no produto e no processo de fabricao.

Figura 3.2 Categorias primrias de projetos de desenvolvimento (CLARK e WHEELWRIGHT, 1993)

De forma resumida, as categorias de projetos de desenvolvimento segundo CLARK e WHEELWRIGHT (1993) so:

17

a) Projetos derivativos ou incrementais Nesta categoria, so includos os projetos de desenvolvimento de produto ou processo que so derivados, hbridos ou melhorias aplicadas a produtos ou processos existentes, tal como um projeto de reduo de custos para uma verso existente de um produto ou um projeto de melhoria de um processo de produo existente. Observa-se na figura 3.2, que projetos dessa categoria trazem pequenas alteraes no produto com pouca ou nenhuma alterao no processo, ou pequenas alteraes no processo com pouca ou nenhuma alterao no produto, ou ainda pequenas alteraes em ambas dimenses. Devido utilizao de produtos ou processos j existentes, projetos dessa categoria demandam nveis substancialmente menores de recursos quando comparados s demais categorias.

b) Projetos de plataforma ou nova gerao Os projetos de plataforma ou nova gerao situam-se entre os derivativos ou incrementais e os projetos inovativos ou radicais. Esses projetos so a base para uma famlia de produtos ou processos que sero utilizados durante anos e por isso demandam muito mais recursos que os projetos derivativos ou incrementais. Como tais projetos representam um novo sistema ou soluo para os clientes, alteraes significativas no produto, no processo ou em ambos, so necessrias.

c) Projetos inovativos ou radicais Quando categorizados como inovativos ou radicais, os projetos envolvem alteraes muito significativas no produto, no processo ou em ambas dimenses. Se bem sucedidos, esses projetos introduzem um novo produto-chave ou processo-chave e podem criar um novo tipo de produto ou colocar a empresa em um segmento novo de negcio. Em projetos inovativos ou radicais, maior foco colocado no produto, uma vez que usualmente ele introduz uma nova aplicao ou funo. Entretanto, tais projetos normalmente envolvem tambm significativo desenvolvimento de processo e por isso, informaes avanadas sobre

18

fbricas existentes, equipamentos existentes e outras condies impostas, so fundamentais para o sucesso de projetos desta categoria.

d) Projetos de pesquisa e desenvolvimento avanado Os projetos de pesquisa e desenvolvimento avanado ficam fora da fronteira que engloba os projetos comerciais (categorias a, b e c), uma vez que tais projetos se destinam criao de conhecimento (know-how) para futuros desenvolvimentos comerciais. Usualmente, as empresas conduzem os projetos de pesquisa ou desenvolvimento avanado com um grupo separado de pessoas, que buscam tecnologia para aplicao em um futuro produto comercializvel.

e) Projetos em aliana ou parceria Esta categoria de projeto representa uma maneira diferente de se conduzir o desenvolvimento, no bastando mensurar o grau de alterao no produto ou no processo. De fato, qualquer projeto pode ser feito em parceria, desde uma pesquisa ou desenvolvimento avanado at o desenvolvimento de um simples componente. De qualquer forma, ao invs da empresa fornecer sozinha os recursos para o todo desenvolvimento do projeto, o parceiro fornece parte significativa ou at todo o recurso necessrio, alm de tambm poder gerenciar a execuo do projeto. Freqentemente, as empresas se utilizam de parceiros quando seus prprios recursos no so suficientes para o desenvolvimento necessrio ou quando oportunidades estratgicas foram identificadas por outra empresa, geralmente menor, que ento adquirida ou torna-se parceira da primeira.

Alm do grau de alterao no produto e no processo de fabricao, pode-se ainda, considerar o grau de alterao do segmento de mercado da empresa, como uma terceira dimenso para categorizao de projetos. Uma vez que a categoria de um projeto auxilia em seu planejamento e execuo, direcionando o volume de recursos necessrios, a inteno da empresa em modificar seu mercado-alvo, por exemplo, atravs do lanamento de um novo produto para um segmento de mercado diferente, mesmo que a tecnologia deste produto seja dominada pela empresa, poder

19

acarretar uma demanda maior de recursos em relao a um projeto de mesma categoria para um segmento de mercado j conhecido pela empresa.

3.2 Desenvolvimento de Produto, Produo e Consumo

Segundo CLARK e FUJIMOTO (1991), de uma forma mais ampla, o desenvolvimento de um produto pode ser visto como a simulao da experincia futura do consumidor, ou seja, atravs das ferramentas disponveis, os engenheiros tentam antever o que o futuro consumidor experimentar ao utilizar o produto. A figura 3.3 ilustra essa viso, mostrando que o processo de desenvolvimento do produto, processo de produo e processo de consumo, esto integrados em um sistema mais amplo, por onde circulam informaes.

Figura 3.3 Desenvolvimento de produto como uma simulao do consumo (CLARK e FUJIMOTO, 1991)

20

Uma outra maneira de representar esta interligao de processos atravs do ciclo de produo e consumo mostrado na figura 3.4. De uma forma geral, todo produto pode ser associado a este ciclo, ou seja, seu projeto dever ser compatvel com as fases de produo, distribuio, consumo e recuperao. Durante o projeto do produto deve-se buscar o equilbrio entre estas fases do ciclo, assumindo-se compromissos face s exigncias, muitas vezes conflitantes, de cada uma das fases. Basicamente, o projeto do produto direcionado s necessidades do consumidor, mas deve satisfazer s exigncias do fabricante, que quem financia o projeto. O consumidor quer aparncia, funcionalidade, durabilidade, etc. J o fabricante, busca por facilidade de fabricao, uso de poucos recursos na fabricao (baixo custo), etc. Por outro lado, o distribuidor quer facilidade de transporte, de armazenagem, atratividade para venda, etc. O recuperador quer facilidade para reciclar componentes e materiais. Todos querem lucro e a sociedade deseja produtos que no degradem o meio ambiente KAMINSKI (2000).

Figura 3.4 Ciclo de produo e consumo (KAMINSKI, 2000)

21

3.3 Processo de Desenvolvimento de Produto

A partir da representao do sistema integrado de desenvolvimento de produto, produo e consumo (figura 3.3), foi extrado apenas o processo de desenvolvimento de produto (PDP) para uma discusso mais detalhada de suas fases. A figura 3.5 mostra as fases do processo de desenvolvimento de produto (PDP).

Figura 3.5 Fases do processo de desenvolvimento de produto (CLARK e FUJIMOTO, 1991)

a) Fase 1: Conceito do produto Nesta fase busca-se uma caracterizao geral do produto, incluindo-se informaes sobre as necessidades do mercado, competidores, tecnologias disponveis, riscos e viabilidade econmica. Tambm se procura definir as caractersticas de funcionalidade e tecnolgica do produto, podendo ou no incluir alguns detalhes tcnicos mais especficos (BACON et al, 1994 apud TOLEDO et al, 2002). Tambm nesta fase, pode-se fazer uso de modelos preliminares de estilo, visando suportar o estabelecimento de objetivos tcnicos preliminares, os estudos preliminares de lay-out e os estudos preliminares de viabilidade do processo (CLARK e FUJIMOTO, 1991).

b) Fase 2: Planejamento do produto Nesta fase deve-se obter o detalhamento do produto anteriormente conceituado, em termos de especificaes de projeto, escolha dos componentes principais, lay-out e estudo de viabilidade do processo, podendo ainda se fazer uso de modelos de argila (clay model) e/ou modelo fsico (mock-up) para avaliao do produto (CLARK e FUJIMOTO, 1991).

22

c) Fase 3: Projeto do produto No projeto do produto, as informaes obtidas durante as fases de conceituao e planejamento do produto, so transformadas em desenhos com caractersticas reais, que podem ser validadas, atravs dos prottipos construdos durante esta fase (CLARK e FUJIMOTO, 1991).

d) Fase 4: Projeto do processo Durante o projeto do processo, as informaes do projeto do produto so utilizadas para a concretizao dos meios necessrios produo do produto, ou seja, maquinrios, ferramentais, etc. Atravs de uma linha-piloto ou uma planta-piloto, onde uma unidade-piloto do produto

experimentalmente produzida, pode-se avaliar e validar o projeto do processo (CLARK e FUJIMOTO, 1991).

e) Fase 5: Processo de produo Nesta fase inicia-se a pr-produo do produto, objetivando avaliar e validar o processo de produo em condies normais de operao, assim podendo identificar e realizar acertos finais no processo de fabricao, antes do lanamento do produto (TOLEDO, 2002; CLARK e FUJIMOTO, 1991).

Na prtica, porm, h uma sobreposio entre estas fases, que aqui so apresentadas em uma seqncia lgica, uma vez que a natureza do processo de desenvolvimento de produto exige uma maior interatividade (AMARAL, 1997 apud TOLEDO, 2002). O conceito de espiral de projeto apresentado por KAMINSKI (2000) mostra essa natureza mais interativa e menos sequencial do processo de desenvolvimento de produto (PDP), onde para cada espiral h um refinamento maior do projeto at se convergir para a configurao final do produto. A figura 3.6 ilustra uma espiral de projeto exemplificando o

desenvolvimento de um componente automotivo em parceria com um fornecedor (co-desenvolvimento). Nota-se que diversas reas funcionais da empresa interagem durante o processo de desenvolvimento do componente, sendo que cada ponto numerado na interseco da espiral com a linha radial, significa uma interao com a rea representada por essa linha radial.

23

A tabela 3.1 relaciona exemplos de atividades tpicas para cada interao (pontos numerados), considerando o processo de co-desenvolvimento (parceria com fornecedor) de um novo componente automotivo. Para elaborao da tabela 3.1 foi assumido que esse novo componente tenha implicaes em diversas reas funcionais da montadora, inclusive na rea de Estilo, ou seja, representa um item de aparncia para o cliente do veculo. Por ltimo, tambm foi assumido um processo de desenvolvimento de forma ampla e vista pelo lado da montadora.

Figura 3.6 Espiral de projeto (KAMINSKI, 2000 - Adaptado pelo autor)

24

Tabela 3.1 Exemplos de atividades tpicas na espiral de projetos Interao 1 Atividades A Qualidade realiza o levantamento do histrico dos principais problemas encontrados com componentes similares no passado. 2 O Estilo apresenta a proposta inicial de aparncia para o novo componente, por exemplo, atravs de um croqui. 3 A Engenharia de Produto inicia os estudos de conceito do novo componente, atravs de componentes similares j utilizados internamente ou nos competidores (benchmark). Tambm faz estudos quanto aos recursos (internos e externos) necessrios para o desenvolvimento e a validao do novo componente, bem como, estabelece um cronograma preliminar para o desenvolvimento. 4 A rea de Custos, baseada no conceito do novo componente e em informaes de desenvolvimentos anteriores similares, inicia seus estudos para estabelecer o custo-objetivo e o investimento-objetivo (ferramental) para o novo componente. 5 A Engenharia de Processo verifica os impactos para a montagem na fbrica do novo componente, considerando a necessidade de novos dispositivos, eventual adaptao de outros e estabelecendo os principais requisitos de processo a serem considerados no projeto do novo componente. 6 A rea de Compras prepara uma lista preliminar dos potencias fornecedores para o tipo de componente em questo, considerando tambm, a situao atual da relao comercial com os fornecedores. 7 A rea de Validao e Testes relaciona os testes habituais para o tipo de componente em questo, considerando seus procedimentos e experincias de desenvolvimento anteriores. 8 A Qualidade pesquisa a situao atual do nvel de qualidade para os potenciais fornecedores, considerando questes como a estabilidade e capacidade produtiva destes potenciais fornecedores.

25

A Engenharia de Produto compila as informaes obtidas (interao 1 a 8), emitindo a especificao do novo componente com suas principais caractersticas tcnicas (dimensional, material, interface com o veculo, etc.) e os requisitos do projeto (cronograma preliminar, matriz de responsabilidades, etc.).

10

A rea de Custos, agora com uma especificao mais detalhada do novo componente, estabelece o custo-objetivo e o investimentoobjetivo (ferramental) a ser utilizado no processo de cotao.

11

A rea de Compras inicia um processo de cotao baseado nas especificaes tcnicas e requisitos do projeto do novo componente, convidando os potencias fornecedores para apresentarem suas propostas e solues em reunies de reviso tcnica (Technical Reviews).

12

Os fornecedores participantes do processo de cotao, preparam suas propostas tcnicas e comerciais, incluindo um plano de desenvolvimento componente. (cronograma) e validao para o novo

13 16

Durante as reunies de reviso tcnica (Technical Reviews) com cada fornecedor, as propostas so discutidas e debatidas com a participao das reas da montadora envolvidas no processo.

17

A rea de Compras oficializa o fornecedor responsvel pelo desenvolvimento do novo componente.

18

O fornecedor prepara a especificao tcnica detalhada do novo componente e inicia suas atividades de desenvolvimento.

19 22

As

atividades

de

desenvolvimento

do

componente

so

acompanhadas por uma equipe multifuncional da montadora, normalmente liderada pela Engenharia de Produto. Detalhes do projeto do componente, tais como sua interface com o veculo, suas caractersticas a serem controladas e o prprio andamento do plano de desenvolvimento (cronograma) e validao, so exaustivamente discutidos. Tambm, durante este ciclo de interaes, so aplicadas as ferramentas de qualidade de projeto (DFA / DFM, DFMEA, PFMEA, etc.), alm de ser preparado o desenho do componente.

26

23

O fornecedor apresenta amostras do componente para validao no veculo, aprovao de aparncia, etc.

24

A rea de Validao e Testes realiza os testes necessrios e emite os respectivos relatrios de validao.

25

A Qualidade verifica o processo de produo para o novo componente com a finalidade de aprovar a capacidade e estabilidade deste processo (PPAP).

26 27

O Estilo realiza a aprovao de aparncia do novo componente. A Engenharia de Produto faz a liberao final do novo componente para incio de produo.

28

A Engenharia de Processo verifica a montagem do novo componente em fbrica, atravs de uma corrida-piloto (pilot run).

3.4 Processo de Desenvolvimento de Produto segundo o APQP

Em se tratando de indstria automotiva, se torna importante citar o APQP (Advanced Product Quality Planning), documento elaborado em conjunto pela Chrysler, Ford e General Motors, com o objetivo de estabelecer uma referncia para o desenvolvimento de produtos da indstria automotiva. O manual de referncia do APQP parte integrante do sistema QS-9000, e portanto seguido pelos fornecedores certificados por este sistema de normas. No manual de referncia Advanced Product Quality Planning (APQP) and Control Plan encontram-se diretrizes gerais e recomendaes de como o fornecedor deve preparar o plano de desenvolvimento do componente, alm de verificaes sugeridas (checklist), modelos de formulrios padronizados e outros mecanismos formais para acompanhamento do projeto. Um objetivo especfico do APQP a garantia do atendimento das necessidades e expectativas do cliente de acordo com os prazos estabelecidos, sendo apresentado para isso, um modelo de processo de desenvolvimento do produto (PDP) com cinco fases, como ilustra a figura 3.7.

27

Figura 3.7 Fases do PDP segundo o APQP (APQP, 1994)

Cada uma das fases tratada em uma seco do manual, sendo que as informaes de sada (outputs) da fase anterior, so as informaes de entrada (inputs) da fase seguinte. As tabelas 3.2, 3.3, 3.4, 3.5 e 3.6 trazem um quadro-resumo para cada uma das fases, mostrando, de uma forma resumida, o contedo principal do APQP.

28

Tabela 3.2 Quadro-resumo da fase de planejamento (Adaptado pelo autor do APQP, 1994) 1. Planejamento Entradas

Sadas

Voz do cliente (pesquisa de mercado, histrico de garantia, informaes de qualidade e experincia da equipe);

Metas do projeto; Metas de qualidade e confiabilidade; Lista preliminar de material (BOM); Fluxograma preliminar do processo; Lista preliminar de caractersticas especiais do produto e do processo;

Plano de negcio e estratgia de mercado;

Informaes dos competidores sobre o produto e o processo (benchmark);

Plano de garantia do produto; Compromisso da gerncia.

Suposies para o produto e o processo;

Estudos produto;

de

confiabilidade

do

Informaes do cliente.

29

Tabela 3.3 Quadro-resumo da fase de desenvolvimento e projeto do produto (Adaptado pelo autor do APQP, 1994) 2. Desenvolvimento e projeto do produto Entradas

Sadas

Metas do projeto; Metas de qualidade e confiabilidade; Lista preliminar de material (BOM); Fluxograma preliminar do processo; Lista preliminar de caractersticas especiais do produto e do processo;

Anlise do modo de falha e efeito para o projeto (DFMEA);

Projeto orientado manufatura e montagem (DFM / DFA);

Verificaes de projeto; Revises de projeto (gates); Construo de prottipos; Desenhos de engenharia, in-

Plano de garantia do produto; Compromisso da gerncia.

cluindo modelos matemticos;

Especificaes de engenharia; Especificaes de materiais; Requisitos relativos a novos e

equipamentos, fbricas;

ferramentais

Caractersticas

especiais

do

produto e do processo;

Requisitos

relativos

equi-

pamentos de testes e controle de produo (gages);

Compromisso de viabilidade com consenso da equipe e da gerncia.

30

Tabela 3.4 Quadro-resumo da fase de desenvolvimento e projeto do processo (Adaptado pelo autor do APQP, 1994) 3. Desenvolvimento e projeto do processo Entradas

Sadas

Anlise do modo de falha e efeito para o projeto (DFMEA);

Estudo de embalagem padronizada do cliente;

Projeto orientado manufatura e montagem (DFM / DFA);

Reviso do sistema de qualidade do produto/processo;

Verificaes de projeto; Revises de projeto (gates); Construo de prottipos; Desenhos de engenharia, incluindo modelos matemticos;

Fluxograma do processo; Lay-out de fbrica; Matriz de caractersticas, relacionando parmetros do processo e postos de fabricao;

Especificaes de engenharia; Especificaes de materiais; Requisitos relativos a novos equipamentos, ferramentais e fbricas;

Anlise do modo de falha e efeito para o processo (PFMEA);

Plano

de

controle

do

pr-

lanamento;

Caractersticas especiais do produto e do processo;

Instrues de processo; Plano para avaliao do sistema de medio (acuracidade, repe-

Requisitos relativos a equipamentos de testes e controle de produo (gages);

tibilidade, correlao, etc.); Plano para o estudo preliminar de capacidade do processo;

Compromisso de viabilidade com consenso da equipe e da gerncia.

Especificaes de embalagens; Compromisso da gerncia.

31

Tabela 3.5 Quadro-resumo da fase de validao do produto e do processo (Adaptado pelo autor do APQP, 1994) 4. Validao do produto e do processo Entradas

Sadas

Estudo de embalagem padronizada do cliente;

Corrida-piloto de produo; Avaliao medio; dos sistemas de

Reviso do sistema de qualidade do produto/processo;

Estudo preliminar de capacidade do processo;

Fluxograma do processo; Lay-out de fbrica; Matriz de caractersticas, rela

Aprovao de pea de produo; Teste de validao da produo; Avaliao da embalagem; Plano de controle da produo; Aprovao (sign off) do plano de qualidade;

cionando parmetros do processo e postos de fabricao;

Anlise do modo de falha e efeito para o processo (PFMEA);

Plano

de

controle

do

pr-

Compromisso da gerncia.

lanamento;

Instrues de processo; Plano para avaliao do sistema de medio (acuracidade, repetibilidade, correlao, etc.);

Plano para o estudo preliminar de capacidade do processo;

Especificaes de embalagens; Compromisso da gerncia.

32

Tabela 3.6 Quadro-resumo da fase de avaliao, re-alimentao do processo e aes corretivas (Adaptado pelo autor do APQP, 1994) 5. Avaliao, re-alimentao do processo e aes corretivas Entradas

Sadas

Corrida-piloto de produo; Avaliao dos sistemas de medio; Estudo preliminar de capacidade do processo;

Reduo da variao do processo; Satisfao do cliente; Entrega das peas e servio, buscando oportunidades de

Aprovao de pea de produo; Teste de validao da produo; Avaliao da embalagem; Plano de controle da produo; Aprovao (sign off) do plano de qualidade;

melhoria contnua.

Compromisso da gerncia.

A figura 3.8 sintetiza os quadros-resumo apresentados, apresentando uma viso geral do processo de desenvolvimento de produto segundo o APQP.

33

Figura 3.8 Fluxo de informao sumarizado do APQP 3.5 Participao de Fornecedores no Desenvolvimento

A participao de fornecedores no projeto e no desenvolvimento de componentes automotivos pode variar em funo da estratgia de negcio da montadora e tambm de diferenas regionais. Em seu estudo, CLARK e FUJIMOTO (1991), apresentam um fluxo de informao para cada nvel de participao do fornecedor no desenvolvimento. As figuras 3.9, 3.10, 3.11 e 3.12 ilustram tais fluxos em funo do nvel de participao do fornecedor.

34

a) Componentes proprietrios de fornecedor (supplier proprietary parts) So componentes padronizados, para os quais o fornecedor tem o controle do conceito at a produo. Normalmente, so oferecidos e vendidos s montadoras atravs de catlogos. Como tais componentes podem ser utilizados por vrias montadoras, tem-se um ganho devido economia de escala. Por outro lado, a montadora no tem controle sobre o contedo da tecnologia utilizada, o que pode gerar problemas devido qualidade do projeto (CLARK e FUJIMOTO, 1991). Componentes como baterias e velas so exemplos tpicos, porm at componentes genricos como pneus e equipamentos de som tendem a ser desenvolvidos segundo a especificao da montadora. CLARK e FUJIMOTO (1991) constataram em seu estudo, que menos de 10% do custo total de material do veculo, so relativos a componentes proprietrios de fornecedor.

Figura 3.9 Fluxo de informao para componentes proprietrios de fornecedor (CLARK e FUJIMOTO, 1991)

35

b) Componentes caixa-preta (black box parts) Os componentes caixa-preta so aqueles nos quais h uma coparticipao entre A a montadora montadora e o fornecedor seus no esforo de de

desenvolvimento.

fornece

requisitos

custo,

performance, superfcies exteriores da pea (se for o caso), detalhes da interface com o veculo e outras informaes bsicas do projeto, ficando a cargo do fornecedor o detalhamento do projeto, o desenvolvimento e validao dos componentes-prottipos, etc. Os componentes desta categoria, permitem que a montadora utilize o conhecimento de engenharia (know-how) e a mo-de-obra do fornecedor, mantendo o controle do projeto bsico e da integrao do veculo. O quanto o fornecedor tem de conhecimento de engenharia (know-how) acumulado faz seu diferencial competitivo. Sendo tambm o fornecedor de produo, toda a experincia acumulada durante o desenvolvimento do componente aproveitada na deteco de potenciais problemas de produo, melhorando a qualidade do componente. Por outro lado, riscos como o de o projeto bsico e idias de estilo chegarem aos competidores atravs do fornecedor, da montadora perder o controle tecnolgico de componentes-chave ou de alguma perda no poder de negociao pela dependncia do conhecimento de engenharia do fornecedor, devem ser considerados em se tratando de componentes caixa-preta. A opo pelos componentes caixa-preta no significa o abandono de toda engenharia envolvida naquele componente, motivo pelo qual alguns fazem distino entre componentes caixa-preta (black box) e caixa-cinza (gray box), em funo do nvel de conhecimento da montadora sobre os detalhes internos do projeto do componente (CLARK e FUJIMOTO, 1991).

36

Figura 3.10 Fluxo de informao para componentes caixa-preta (CLARK e FUJIMOTO, 1991)

c) Componentes controlados no detalhe (detail-controlled parts) Classificam-se como componentes controlados no detalhe, aqueles em que a montadora detm a maior parte do esforo de desenvolvimento, incluindo-se a especificao tcnica e o desenho do componente. O fornecedor fica responsvel pela engenharia de processo e pela produo, porm seguindo o desenho fornecido pela montadora. Em alguns casos, o fornecedor tambm pode ser responsvel pela fabricao dos prottipos. No caso de componentes da carroceria, algumas montadoras tambm ficam com a responsabilidade pela engenharia de processo e construo dos ferramentais, que so concedidos ao fornecedor, ficando este, responsvel apenas pela produo seriada. Os componentes desta categoria, trazem como vantagens montadora, a preservao do detalhe e da capacidade tecnolgica, o controle sobre o projeto do componente e sua qualidade, alm de preservar o poder de negociao em relao ao preo do componente praticado pelo fornecedor.

37

Por outro lado, a montadora fica obrigada a manter uma complexa estrutura de engenharia, criando dificuldades para concentrar seus esforos na engenharia do veculo como um todo. Tambm, existe o risco de a montadora perder a competio tecnolgica, relativa ao componente, para um fornecedor que mantm seu foco na tecnologia especfica daquele componente (CLARK e FUJIMOTO, 1991).

Figura 3.11 Fluxo de informao para componentes funcionais controlados no detalhe (CLARK e FUJIMOTO, 1991)

38

Figura 3.12 Fluxo de informao para componentes de carroceria controlados no detalhe (CLARK e FUJIMOTO, 1991)

Segundo KAMATH e LIKER (1994) apud CORSWANT e TUNLV (2002), o nvel de participao do fornecedor no projeto do componente, depende principalmente de sua habilidade em trazer para si, parte do processo de desenvolvimento. A tabela 3.7 representa o nvel de participao do fornecedor em funo da evoluo no relacionamento cliente-fornecedor.

39

Tabela 3.7 Participao do fornecedor em funo do relacionamento (KAMATH e LIKER, 1994 apud CORSWANT e TUNLV, 2002) Estgio do relacionamento cliente-fornecedor Contratual Responsabilidade pelo projeto Complexidade do produto Fornecimento das especificaes Influncia do fornecedor nas especificaes Fase de envolvimento do fornecedor Responsabilidade sobre o teste do componente Capacidade tecnolgica do fornecedor Baixa Mdia Alta Autnomo Pequena Moderada Grande Completa Prottipo Ps-conceitual Conceitual Nenhuma Iniciante Cliente Cliente e Fornecedor Componentes Simples Projeto completo Montagem simples Especificaes detalhadas Apresenta suas capacidades Prconceitual Negociada Colabora Montagem complexa Especificaes crticas Todo subsistema Fornecedor Fornecedor Maduro Parceiro

Conceito

Como pode ser observado na tabela acima, o fornecedor passa a ter maior participao no desenvolvimento nos estgios parceiro e maduro de relacionamento. No estgio iniciante, a responsabilidade pelo projeto conjunta, porm o fornecedor j o responsvel pelas especificaes detalhadas do componente, o que j demonstra certa participao no desenvolvimento. Enquanto que no estgio contratual, no h participao do fornecedor no desenvolvimento.

40

Segundo

KESSELER

(1997),

as

principais

caractersticas

do

co-

desenvolvimento (co-design), so:

Solicitaes ao fornecedor so feitas antecipadamente, incluindo-se o preo-objetivo e a descrio funcional do produto;

A seleo do fornecedor baseada em uma deciso da rea de projeto, no sendo somente uma deciso da rea de compras, tradicionalmente; como

Existe a transferncia de conhecimento (know-how) ao fornecedor; Poucos fornecedores so selecionados por produto (um ou dois); Representantes do fornecedor participam da equipe de desenvolvimento da montadora;

Existe a nomeao de um gerente de projeto no fornecedor; O fornecedor tem autonomia na escolha dos mtodos e tcnicas a serem utilizadas no desenvolvimento do produto, porm fica obrigado a declarar claramente cada escolha;

Comunicao intensa entre a montadora e o fornecedor; Possibilidade de a montadora alterar os requisitos do projeto durante o desenvolvimento, porm sendo tais mudanas acordadas entre ambos;

Integrao antecipada dos aspectos financeiros no estudo tcnico do projeto;

Validao dos resultados obtidos como um processo contnuo ou interativo, tendo como objetivo maior, a melhoria do produto e do processo, e no sendo uma maneira de se punir uma baixa performance.

3.6 Anlises e Concluses

Em um contexto onde o desenvolvimento do veculo passa a ser distribudo em vrios fornecedores, atravs do co-desenvolvimento de seus componentes, tornase necessrio homogeneizao dos conceitos relativos ao processo de desenvolvimento de produto (PDP). Complementado a reviso da literatura iniciada nos captulos anteriores, este captulo teve como objetivo sumarizar os conceitos sobre o processo de

41

desenvolvimento de produto, que de alguma forma se relacionam ou esto inseridos em um desenvolvimento em parceria (co-desenvolvimento). O modelo geral do funil de desenvolvimento (CLARK e WHEELWRIGHT, 1993), as categorias primrias dos projetos de desenvolvimento (CLARK e WHEELWRIGHT, 1993) e a integrao entre o processo de desenvolvimento de produto, processo de produo e processo de consumo (CLARK e FUJIMOTO, 1991; KAMINSKI, 2000) introduzem conceitos gerais quanto ao desenvolvimento de produto. Por outro lado, a classificao do componente pelo nvel de participao do fornecedor no projeto (CLARK e FUJIMOTO, 1991) e o processo interativo demonstrado pelo modelo da espiral de projeto (KAMINSKI, 2000) tm uso direto no processo de gesto de co-desenvolvimento, como ser visto nos captulos seguintes. Os quadros-resumo apresentados nas tabelas 3.2 a 3.6 so uma forma sintetizada de se compreender o processo de desenvolvimento de produto conforme o manual de referncia do APQP, que utilizado como diretriz bsica no desenvolvimento de componentes automotivos pelos fornecedores certificados pela QS-9000. Ao trmino do captulo discutido o nvel de participao do fornecedor no projeto do componente em funo do estgio do relacionamento cliente-fornecedor (KAMATH e LIKER, 1994 apud CORSWANT e TUNLV, 2002) e o codesenvolvimento (co-design) caracterizado segundo KESSELER (1997), concluindo assim a reviso da literatura e criando os fundamentos para as discusses dos prximos captulos.

42

4 ESTRATGIA DA MONTADORA PARA O CO-DESENVOLVIMENTO

Este captulo estuda a estratgia relacionada integrao com os fornecedores (co-desenvolvimento), buscando evidncias de seu uso na distribuio dos recursos de projeto para veculos em fase de planejamento e na participao do co-desenvolvimento em veculos em fase de produo.

4.1 Estratgia Global da Montadora

Observa-se que a subsidiria brasileira segue a orientao da matriz, a qual definiu e vem implementando uma estratgia de integrao com os fornecedores desde o final da dcada de 1990, atravs do programa Global Supplier Leveraging, que dentre outras iniciativas, busca comunicar aos fornecedores a estratgia global da montadora para o co-desenvolvimento de produto. A figura 4.1 mostra uma viso geral desta estratgia.
Ambiente

Presso competitiva Melhor capacitao dos fornecedores

Componentes classificados em funo da importncia estratgica Componentes parcialmente desenvolvidos internamente Componentes totalmente desenvolvidos internamente

Utilizao da capacidade dos fornecedores

Recursos ($)

Melhoria das competncias internas

Reduo do custo estrutural

Vantagem competitiva

Clientes Satisfeitos

Figura 4.1 Estratgia global da montadora para o co-desenvolvimento (REED, 2003 - Traduzido e adaptado pelo autor)

43

Em um ambiente de alta presso competitiva e onde j era percebida uma melhor capacitao tcnica da base de fornecedores, quando comparado com a situao de alguns anos atrs, a montadora classificou os componentes, sub-sistemas e sistemas do veculo em funo da importncia estratgica de cada um para o negcio da empresa. A partir desta classificao, foi possvel decidir para quais componentes a montadora deveria manter internamente toda a competncia de desenvolvimento e para quais a montadora poderia manter parcialmente esta competncia, utilizando sua base de fornecedores para o desenvolvimento em parceria destes componentes, subsistemas e sistemas. Esta definio quanto utilizao da capacidade dos fornecedores, levaria necessidade de investimento na base de fornecedores, buscando o amadurecimento das parcerias e a transferncia de conhecimentos especficos sobre projeto veicular da montadora para seus fornecedores, como ilustrado na figura 4.2.

Estado Inicial

Viso

Fornecedor

Montadora

Fornecedor

Montadora

Figura 4.2 Capacitao da base de fornecedores (REED, 2003 - Traduzido e adaptado pelo autor)

Este processo de capacitao dos fornecedores incluiria a transferncia de conhecimento nas mais diversas reas do desenvolvimento do produto, tais como: processos de gesto de projetos (VDP, APQP, etc.), ferramentas para modelamento e simulao virtual (CAD, CAE, DMU, etc.), ferramentas de qualidade (DFMEA, PFMEA, DFA, DFM, etc.) e principalmente o conhecimento quanto interao do componente, sub-sistema ou sistema a ser fornecido com o restante do veculo. A utilizao da capacidade dos fornecedores reduziria o custo estrutural e permitiria a migrao de recursos para a melhoria das competncias internas da montadora, ou seja, a busca por uma melhor qualidade, uma melhor tecnologia e um menor custo

44

para o produto, criando assim uma vantagem competitiva e tendo como resultado clientes mais satisfeitos. A tabela 4.1 compara o cenrio tradicional com o cenrio que considera a integrao dos fornecedores, conforme a estratgia global da montadora para o co-desenvolvimento.

Tabela 4.1 Integrao com o fornecedor (REED, 2003) Cenrio Tradicional Cenrio com Integrao dos Fornecedores Objetivo de custo para o veculo definido Custo-objetivo baseado nas cotaes. pela plataforma e alocado para cada sistema, sub-sistema e componente. Montadora fornece especificaes Montadora fornece especificao tcnica funcional, requisitos de mercado e estilo, juntamente com o pacote de cotao. Fornecedores submetem propostas de como eles podem atingir os requisitos do programa e o objetivo de custo para o sistema, sub-sistema ou componente.

tcnicas detalhadas aos fornecedores.

Fornecedores cotam o preo baseado nas especificaes detalhadas das montadoras.

Fornecedores desenvolvem apenas Fornecedores desenvolvem componentes, componentes. sub-sistemas e sistemas.

Montadora responsvel sempre por Fornecedores podem preparar documentos liderar a equipe de desenvolvimento para liberao de engenharia e tambm de produto (PDT) ou um sub-grupo liderarem equipes de desenvolvimento de desta equipe. Montadora responsvel por testar e validar. produto (PDT) ou sub-grupos da equipe. Fornecedores so responsveis pelas

anlises, testes e validaes em seus sistemas, sub-sistemas ou componentes. A relao montadora-fornecedor

A relao montadora-fornecedor tambm baseada em objetivos mtuos e o baseada em contratos de negcio. trabalho em conjunto encorajado e suportado pela montadora.

45

4.2 Classificao quanto ao Nvel de Integrao Permitido

A montadora objeto do estudo classificou em nveis de integrao permitidos (co-desenvolvimento) cada sistema, sub-sistema e componente do veculo em funo da importncia estratgica de cada um para o negcio da empresa, atribuindo as responsabilidades a cada parceiro (montadora ou fornecedor) em funo deste nvel de integrao. O grau de participao do fornecedor no desenvolvimento do sistema, sub-sistema ou componente a ser fornecido varia conforme este nvel de integrao permitido, o qual categorizado em Nvel I, Nvel II, Nvel II e Nvel IV.

a) Nvel I No h integrao com o fornecedor para os componentes de Nvel I, sendo a montadora responsvel por todas as atividades de engenharia. Os fornecedores ou a prpria manufatura da montadora produzem os componentes a partir dos desenhos e especificaes de projeto da montadora.

b) Nvel II Os fornecedores so responsveis pelas atividades de engenharia e produo dos componentes, ficando a montadora responsvel pela integrao dos componentes nos sub-sistemas ou sistemas e pelas atividades de engenharia do sub-sistema ou sistema.

c) Nvel III Os fornecedores so responsveis pelas atividades de engenharia e produo dos sub-sistemas ou sistemas, ficando a montadora responsvel pela integrao dos sub-sistemas ou sistemas ao veculo.

d) Nvel IV Os fornecedores so responsveis pelas atividades de engenharia, produo e integrao dos componentes, sub-sistemas ou sistemas ao veculo, ficando a montadora responsvel apenas pela engenharia do veculo.

Entende-se como responsabilidade pela engenharia, a responsabilidade pelo projeto, anlise, desenvolvimento e validao de um sistema, sub-sistema ou componente. A

46

tabela 4.2 relaciona a responsabilidade ao nvel de integrao permitido, segundo a estratgia da empresa.

Tabela 4.2 Responsabilidades em funo do nvel de integrao (REED, 2003 - Traduzido e adaptado pelo autor) Responsabilidade Engenharia do veculo Integrao do sub-sistema ou sistema ao veculo Engenharia do sub-sistema ou sistema e tambm a integrao do componente no sub-sistema ou sistema Engenharia do componente Montadora Fornecedor Fornecedor Fornecedor Montadora Montadora Fornecedor Fornecedor Nvel I Montadora Montadora Nvel II Montadora Montadora Nvel III Montadora Montadora Nvel IV Montadora Fornecedor

J a tabela 4.3 exemplifica a classificao dos sistemas, sub-sistemas ou componentes em funo do nvel permitido de integrao (co-desenvolvimento).

Tabela 4.3 Exemplos de classificao quanto ao nvel de integrao (REED, 2003 - Traduzido e adaptado pelo autor) Nvel de Integrao

Exemplos Maior parte da estrutura de carroceria; Painis da carroceria; Pra-choques; Cobertura plstica dos pra-choques, etc. Motor; Transmisso; Controle e diagnstico do powertrain; Estrutura do chassi; Suspenso e freios; Molduras externas; Arquitetura eltrica; Maior parte dos sistemas eltricos, etc.

Nvel I

Nvel II

47

Escapamento, volante de direo e pneus; Radiador e sistema de arrefecimento; Bancos e cintos de segurana; Painel de instrumentos e console; Espelhos retrovisores e emblemas; Iluminao externa e interna; Chicotes, interruptores, bateria e alternador; Sistema de limpadores, etc. Calotas; Rodas; Buzina, etc.

Nvel III

Nvel IV

4.3 Distribuio dos Recursos de Projeto

A alocao de recurso para pagamento a fornecedores pelo desenvolvimento de um sistema, sub-sistema ou componente depende do nvel de modificao do mesmo. A tabela 4.4 relaciona o nvel de modificao com a possibilidade ou no de se alocar recurso para o co-desenvolvimento do componente em questo.

Tabela 4.4 Relao entre a modificao e o recurso para co-desenvolvimento Nvel I1 Idntico 1 Descrio Componente fornecido atualmente. Usa exatamente os mesmos ferramentais, processos e equipamentos de montagem. Variao de um componente fornecido atualmente. I2 Idntico 2 Requer alteraes mnimas nos ferramentais de seus sub-componentes, no afetando os dispositivos e equipamentos de montagem. Variao de um componente fornecido atualmente. M1 Modificado 1 Re-utiliza a maior parte dos ferramentais de seus sub-componentes, evitando investimento significativo no componente. No afeta os equipamentos de montagem. Alocado conforme a solicitao da Engenharia (*) No considerado Recurso No considerado

48

Variao de um componente fornecido atualmente. Requer alteraes significativas nos ferramentais de M2 Modificado 2 seus sub-componentes. Re-utiliza a maior parte dos dispositivos de montagem, evitando investimento significativo no processo de produo. No afeta os equipamentos de montagem. Variao de um componente fornecido atualmente N1 Novo 1 com soluo de engenharia conhecida. Requer novo conjunto de ferramentais e dispositivos, porm re-utiliza os equipamentos e processos de montagem. Componente no fornecido atualmente e com soluo de engenharia desconhecida para a N2 Novo 2 empresa. Requer novo conjunto de ferramentais e dispositivos. Pode requerer novos equipamentos e processos de montagem.
(*)

Alocado conforme a solicitao da Engenharia (*)

Alocado conforme a solicitao da Engenharia (*)

Alocado conforme a solicitao da Engenharia (*)

Exceto para Legacy Commodities.

Recursos

somente

so

alocados

para

pagamento

fornecedores

pelo

desenvolvimento do produto quando a modificao for superior ao nvel M1 e conforme a solicitao de co-desenvolvimento feita na especificao de engenharia. Excetuam-se, tambm, os casos em que devido ao tempo de uso da tecnologia, a base de fornecedores j absorveu o custo estrutural para desenvolver aquele tipo de componente (Legacy Commodities), tais como: sistema de exausto, sistema de combustvel, freio, coluna de direo, volante, iluminao, espelho retrovisor, limpador de pra-brisa, conjunto de instrumentos do painel (cluster), interruptores, radio, bateria, alternador, buzina, etc. A partir de um estudo feito sobre a distribuio dos recursos alocados para os projetos aprovados aps o ano de 2000 na subsidiria brasileira da montadora estudada, notou-se que apesar do recurso total destinado ao projeto de um veculo

49

variar muito em funo da categoria do projeto (novo, re-estilizao ou ornamentao), sua distribuio percentual se manteve. A figura 4.3 mostra a distribuio percentual tpica destes recursos, onde se considerou como Investimentos todos os recursos destinados confeco dos ferramentais da montadora, ferramentais alocados em fornecedores e alteraes da planta de montagem e se considerou como Outras Despesas todos os recursos destinados s despesas de pr-produo, divulgao, lanamento e capacitao para o ps-vendas.

62%

22%

3% 1% 11%

Investimentos Despesas com Engenharia de Produto Despesas com Criao/Estilo Despesas com Engenharia de Manufatura Outras Despesas

Figura 4.3 Distribuio dos recursos de projeto

A partir dos 22% alocados como Despesas com Engenharia de Produto, obteve-se a distribuio mostrada na figura 4.4, onde os recursos alocados para codesenvolvimento representam 12% do total alocado para Engenharia de Produto.

50

34%

36%

12% Co-Desenvolvimento

1%

Desenvolvimento Interno (Eng. da Montadora) Materiais para Desenvolvimento e Testes Outros

Figura 4.4 Distribuio dos recursos de engenharia

J a figura 4.5 mostra os recursos alocados para co-desenvolvimento em relao ao total de recursos do projeto.

97%

3%

Co-Desenvolvimento (Servios de Engenharia)

Outros Investimentos e Despesas

Figura 4.5 Participao do co-desenvolvimento no total do projeto

Nota-se que os recursos alocados para pagamento a fornecedores por desenvolvimento de produto representam cerca de 3% dos recursos totais alocados ao projeto, porm 12% dos recursos alocados como Despesas com Engenharia de Produto. A partir desta informao, pode-se perceber que mesmo representando uma parcela razovel dos recursos alocados para Engenharia de Produto (12%), tal

51

parcela se torna menos significativa frente aos recursos totais do projeto. Como os projetos da montadora estudada tendem a requerer um nvel de modificao mais baixo (mximo M2 ou N1) para a maioria dos componentes, esta informao tambm evidencia o critrio na alocao de recursos para co-desenvolvimento, o qual tenta evitar que recursos financeiros sejam transferidos ao fornecedor mais de uma vez pelo desenvolvimento de um mesmo componente ou que se destinem recursos financeiros ao fornecedor quando o custo de desenvolvimento do componente j esteja absorvido no custo estrutural do fornecedor (Legacy Commodities).

4.4 Potencial de Participao do Fornecedor no Desenvolvimento

Analisando-se a rvore de estrutura do produto, pode-se categorizar os componentes segundo sua procedncia, como mostrado abaixo:

a) Componentes comprados no padronizados Entende-se por componentes comprados no padronizados aqueles que foram desenvolvidos especificamente para a montadora, seja no projeto do veculo em questo, seja em projetos anteriores com posterior reutilizao do sistema, sub-sistema ou componente no projeto do veculo em questo. Tais componentes seriam classificados como caixa-preta (black box) ou componentes controlados no detalhe, segundo o critrio de CLARK e FUJIMOTO (1991). Cabe lembrar que os componentes caixa-preta (black box) tambm podem ser denominados caixa-cinza (gray box) em funo do grau de conhecimento da montadora sobre os detalhes internos de seu projeto.

b) Componentes comprados padronizados Os componentes comprados padronizados so aqueles oferecidos no mercado e utilizados por vrias montadoras, recebendo a classificao de componentes proprietrios de fornecedor, segundo CLARK e FUJIMOTO (1991).

c) Componentes manufaturados J os componentes manufaturados so aqueles fabricados

internamente pela montadora e correspondem, na maioria das vezes, aos itens

52

de projeto mais complexos e de maior importncia estratgica para a montadora.

A figura 4.6 mostra a distribuio percentual dos componentes presentes na lista de materiais (BOM) de um veculo luxo (sedan mdio) e de um veculo bsico (hatchback pequeno) em produo, onde se nota a clara predominncia de componentes comprados no padronizados.

Veculo Bsico

77%

18%

5%

Veculo Luxo

71%

20%

9%

Comprados (no padronizados) Manufaturados

Comprados (padronizados)

Figura 4.6 Procedncia dos componentes

Considerando-se apenas os componentes comprados no padronizados, ou seja, aqueles que foram desenvolvidos especificamente para a montadora em questo, e atribuindo-se a eles a classificao da montadora quanto ao nvel de integrao permitido (co-desenvolvimento), obtm-se que mais de 90% dos componentes comprados no padronizados permitem seu desenvolvimento em parceria (co-desenvolvimento), como mostra a figura 4.7.

53

Veculo Bsico

95%

5%

Veculo Luxo

91%

9%

Nveis II, III e IV

Nvel I

Figura 4.7 Nvel de integrao permitido dentre os componentes comprados no padronizados

Nota-se, ento, que cerca de 90% dos componentes comprados no padronizados seriam classificados como caixa-preta (black box) ou caixa-cinza (gray box), segundo a classificao de CLARK e FUJIMOTO, sendo o restante dos componentes comprados no padronizados, classificados como controlados no detalhe, ou seja, seu desenvolvimento seria de responsabilidade exclusiva da montadora. Atribuindo-se apenas a classificao da montadora quanto ao nvel de integrao permitido (co-desenvolvimento) ao universo dos componentes presentes nas listas de materiais (BOM), tem-se o potencial de participao do fornecedor no desenvolvimento destes componentes em funo da estratgia da empresa, o qual ficou entre 60% e 70% do total de componentes do veculo, como mostra a figura 4.8.

54

Veculo Bsico

73%

27%

Veculo Luxo

65%

35%

Permite co-desenvolvimento

No permite co-desenvolvimento

Figura 4.8 Potencial de co-desenvolvimento segundo a estratgia da empresa

Observa-se que uma proporo entre 60% e 70% dos componentes presentes na lista de materiais (BOM) so classificados com os nveis II, III e IV pela estratgia da empresa, ou seja, permitem a participao de seus fornecedores no esforo de desenvolvimento e seriam classificados como componentes caixa-preta (black box) ou caixa-cinza (gray box), segundo a classificao de CLARK e FUJIMOTO (1991). J os 30% a 40% restantes so os componentes comprados no padronizados classificados como nvel I (componentes controlados no detalhe), os componentes comprados padronizados (componentes proprietrios de fornecedor) e os componentes manufaturados internamente, que em sua maioria, tambm so componentes controlados no detalhe, segundo a classificao de CLARK e FUJIMOTO (1991).

55

4.5 Anlises e Concluses

A classificao dos componentes pelo nvel de participao do fornecedor no esforo de desenvolvimento (CLARK e FUJIMOTO, 1991), a busca pela evoluo no estgio do relacionamento cliente-fornecedor (KAMATH e LIKER, 1994 apud CORSWANT e TUNLV, 2002) e a transferncia de conhecimento ao fornecedor (KESSELER, 1997) so aspectos presentes na estratgia da empresa estudada. O critrio na alocao dos recursos do projeto destinados ao codesenvolvimento em funo do nvel de modificao, visa evitar que recursos financeiros sejam transferidos ao fornecedor mais de uma vez pelo desenvolvimento de um mesmo sistema, sub-sistema ou componente. J o conceito de Legacy Commodities tenta evitar a destinao de recursos financeiros ao fornecedor por um desenvolvimento que j tenha seu custo de engenharia includo na composio do custo do componente a ser fornecido. Percebe-se que o critrio do nvel de modificao incorpora o conceito de categorias primrias de projetos apresentado no estudo de CLARK e WHEELWRIGHT (1993). No estudo da lista de materiais (BOM) de veculos em produo, constatou-se que uma proporo de 60% a 70% dos componentes presentes nestas listas, poderia ter seu desenvolvimento em parceria com o fornecedor pela classificao da empresa, ou seja, seriam classificados como componentes caixa-preta (black box) ou caixacinza (gray box) no critrio de CLARK e FUJIMOTO (1991). Nota-se que no estudo de CLARK e FUJIMOTO (1991) apresentada uma proporo de componentes caixa-preta (black box) de 62% na indstria japonesa, 16% na europia e 39% na norte-americana, porm deve-se observar que estas propores traduzem a relao do custo dos componentes classificados como caixa-preta (black box) com o custo total de material produtivo das indstrias pesquisadas na poca, enquanto que a proporo de 60% a 70% obtida no presente estudo, traduz a relao entre o nmero de componentes que permitem seu desenvolvimento em parceria (Nveis II, III e IV) com o total de componentes na lista de materiais (BOM), no sendo possvel uma correlao entre ambos os resultados. Ainda como uma recomendao, pode-se sugerir que a classificao quanto ao nvel de integrao permitido passe a ser um atributo do registro da pea na lista de materiais (BOM), direcionando assim, o tipo de relao cliente-fornecedor que se busca para aquele sistema, sub-sistema ou componente. O prprio cdigo da pea

56

(part number) poderia trazer esta informao, como ilustra a figura 4.9, que mostra o conceito atual e uma proposta para o formato do cdigo de pea.

Formato Atual

d 1

d 2

d 3

d 4

d 5

d 6

d 7

d 8

Bloco de Cdigos

Seqncia de Criao

Cdigo do Sistema ou SubSistema

Seqncia de Criao

Formato Proposto

d 1

d 2

d 3

d 4

d 5

d 6

d 7

d 8

Centro Responsvel

Nvel de Integrao Permitido

Figura 4.9 Proposta de formato para o cdigo de pea (part number)

O dgito d1 (centro responsvel) traria a informao do centro de engenharia responsvel pelo desenho da pea. Os dgitos d2 e d3 trariam o cdigo do sistema ou sub-sistema do veculo onde a pea utilizada ou um cdigo geral para as peas com uso em vrios sistemas e sub-sistemas (elementos de fixao, etc.). O dgito d4 traria a informao do nvel de integrao permitido (1, 2, 3 ou 4) para a pea em questo e os dgitos d5, d6, d7 e d8, a seqncia de criao de novas peas para o sistema ou sub-sistema determinado por d2 e d3.

57

5 CO-DESENVOLVIMENTO E O PROCESSO DE DESENVOLVIMENTO DE PRODUTO

Devido ao aumento da competitividade no mercado automotivo atual, as montadoras vem sendo obrigadas a implementar um processo de desenvolvimento de veculo (VDP) cada vez mais curto, objetivando atender crescente reduo do ciclo de vida do produto no mercado. Ao final da dcada de 1990 aceitava-se um padro de 48 meses para o processo de desenvolvimento de veculo (VDP) e hoje se consideram padres de 24, 20 e at 18 meses para o desenvolvimento de um veculo. Esta realidade direciona os esforos das montadoras na incorporao de novas ferramentas e implementao de novos processos de gesto, onde se podem destacar as seguintes iniciativas:

a) Integrao com os fornecedores O uso do conhecimento de engenharia (know-how) do fornecedor permite o desenvolvimento paralelo de vrios componentes, sub-sistemas e sistemas do veculo, sem a necessidade da montadora incorporar o custo da estrutura de engenharia, que seria necessria para realizar os mesmos desenvolvimentos paralelos internamente. Com isso, obtm-se uma reduo na durao do processo de desenvolvimento de veculo (VDP), alm da incorporao de novas tecnologias aos sistemas veiculares em funo da especializao dos fornecedores.

a) Utilizao de anlises virtuais Nota-se a intensificao da utilizao de anlises virtuais visando reduo da necessidade de prottipos fsicos e tendo como conseqncia um menor custo e um menor tempo (lead-time) de desenvolvimento. O aprimoramento dos sistemas CAE (Computer Aided Engineering) e a utilizao de prottipos virtuais, atravs do DMU (Digital Mock-Up) e VR (Virtual Reality) so as principais iniciativas neste campo.

b) Reduo do tempo de prototipagem Reduzir o tempo de fabricao de prottipos de componentes, visando a rpida verificao de sua montagem e funcionalidade, tem sido possvel

58

atravs

de

ferramentas

de

prototipagem

rpida,

tais

como:

STL

(Stereolithography), FDM (Fused Deposition Modelling), etc.

figura

5.1

exemplifica

integrao

com

fornecedor

(co-

desenvolvimento), onde um modelo virtual desenvolvido pelo fornecedor para o componente de sua responsabilidade (air bag) foi incorporado ao modelo de simulao do veculo completo da montadora.

Figura 5.1 Exemplo de integrao com o fornecedor

J a figura 5.2 ilustra a utilizao de anlises virtuais, comparando os resultados do teste de impacto real (crash test) com o simulado previamente (virtual).

Figura 5.2 Comparao de teste real com resultado de simulao

Neste captulo estudada a interao entre o co-desenvolvimento e o processo de desenvolvimento de produto (PDP) aplicado subsidiria brasileira da montadora objeto deste estudo.

59

5.1 Processo de Desenvolvimento de Veculo

Analogamente ao processo de desenvolvimento de produto (PDP) apresentado por CLARK e FUJIMOTO (1991), denomina-se de processo de desenvolvimento de veculo (VDP) o conjunto de atividades necessrias ao desenvolvimento de um novo veculo. De uma forma mais ampla, pode-se incluir o Desenvolvimento Avanado como uma fase do processo de desenvolvimento de veculo (VDP), porm uma prtica da indstria automobilstica considerar a durao do processo de desenvolvimento de veculo (VDP) como o perodo entre o evento Incio do Programa e o evento Incio de Produo, uma vez que a informao da viabilidade econmica do projeto (business case) s est completa ao trmino do Desenvolvimento Avanado. A figura 5.3 mostra esta situao em uma linha de tempo.

Figura 5.3 Sub-processos do processo de desenvolvimento de veculo (VDP)

Durante o perodo de Desenvolvimento Avanado busca-se a caracterizao geral do novo veculo, incluindo-se informaes das necessidades do mercado, potenciais concorrentes e viabilidade econmica do projeto. Tambm se criam alternativas de temas de estilo para o veculo, bem como solues preliminares de engenharia. Ao trmino do Desenvolvimento Avanado, tem-se a seleo do tema de estilo e o estudo da viabilidade econmica do projeto (business case), que sendo favorvel, leva ao incio efetivo de um programa para o desenvolvimento do veculo em questo. Pode-se associar este perodo de Desenvolvimento Avanado com as fases de Conceito do Produto e Planejamento do Produto descritas no estudo de CLARK e FUJIMOTO (1991). De uma forma simplificada, pode-se dividir o processo de desenvolvimento de veculo (VDP) em trs fases de desenvolvimento e trs fases de construo e validao de prottipos, alm da fase de Desenvolvimento Avanado apresentada.

60

A figura 5.4 ilustra o processo de desenvolvimento de veculo (VDP), conforme observado na empresa objeto deste estudo.

Figura 5.4 Ilustrao do processo de desenvolvimento de veculo (VDP)

a) Desenvolvimento do Estilo Esta fase uma continuao do trabalho iniciado na fase de Desenvolvimento Avanado, onde um tema de estilo foi selecionado dentre trs a nove alternativas avaliadas. Porm, durante a fase de

Desenvolvimento do Estilo h uma grande interao com a Engenharia de Produto e de Processo, uma vez que ao trmino desta fase, todas as superfcies de estilo, ou seja, as superfcies exteriores e interiores que afetam a aparncia do produto, devem estar finalizadas e liberadas para o uso da organizao. Antes do evento Superfcies Finais de Estilo, que marca o trmino desta fase, existem outros eventos intermedirios, onde superfcies preliminares so progressivamente liberadas para o uso da Engenharia de Produto e Processos, de modo a permitir o desenvolvimento necessrio para a construo dos prottipos.

61

b) Desenvolvimento do Produto Esta fase compreende o perodo entre o Incio do Programa e o Trmino da Validao do Produto, porm, tal como a fase de Desenvolvimento do Estilo, aproveita os estudos preliminares de engenharia realizados durante o Desenvolvimento Avanado. O objetivo desta fase gerar as especificaes tcnicas, os modelos matemticos e os desenhos de engenharia necessrios para a fabricao do veculo, bem como construir e testar os prottipos necessrios para uma completa validao do produto ao trmino desta fase. Nota-se tambm, uma interao com o Estilo at que todas as superfcies aparentes estejam finalizadas e com a Engenharia de Processo at o produto esteja completamente validado. Entre os eventos Incio das Liberaes de Engenharia e Trmino das Liberaes de Engenharia, tambm existem eventos intermedirios, onde informaes de engenharia so progressivamente liberadas para a construo dos prottipos e para estudos do processo de fabricao.

c) Desenvolvimento do Processo A fase de Desenvolvimento do Processo se inicia em paralelo com as fases de Desenvolvimento do Estilo e Desenvolvimento do Produto, atravs da avaliao da viabilidade para se fabricar o produto que est sendo concebido. Porm, o objetivo desta fase concretizar as informaes geradas durante o Desenvolvimento do Produto em ferramentais, maquinrios, instalaes fabris e instrues de processo, de forma a garantir um processo produtivo adequado para a demanda esperada do veculo. Tambm, durante esta fase existe uma interao com o Estilo e com a Engenharia de Produto, que se estende at o trmino da fase de Desenvolvimento do Produto. Entretanto, a fase de Desenvolvimento do Processo compreende tambm as atividades de validao do processo e por isso se estende at o evento Trmino da Validao do Processo.

Pode-se

relacionar

as

fases

de

Desenvolvimento

do

Estilo

Desenvolvimento do Produto do processo de desenvolvimento de veculo (VDP) com a fase de Projeto do Produto apresentada por CLARK e FUJIMOTO (1991), bem como a fase de Desenvolvimento do Processo com a fase de Projeto do

62

Processo do processo de desenvolvimento de produto (PDP) descrito por CLARK e FUJIMOTO (1991). J as trs fases de prottipos compreendem a obteno do material necessrio, a construo dos prottipos e tambm sua validao, considerando porm, o grau de evoluo do projeto em funo da progressividade das informaes geradas nas fases de desenvolvimento, como sumarizado a seguir:

a) Veculos de Arquitetura Os veculos construdos durante esta fase, tambm conhecidos como veculos conceituais ou veculos mula, servem para avaliar alguns sistemas, sub-sistemas ou componentes, gerando as informaes necessrias ao prosseguimento do desenvolvimento. Tipicamente, pode-se avaliar o desenvolvimento do chassi, o envelope do pneu, o conceito da arquitetura eltrica e a montagem de componentes crticos (mock-ups) em veculos conceituais estticos, deixando-se a construo de um veculo de arquitetura no esttico para o perodo aps o evento Incio das Liberaes de Engenharia, o que torna possvel, por exemplo, a construo de um veculo mula para avaliao do sistema de arrefecimento, uma vez que maiores detalhes das superfcies externas do veculo passam a ser conhecidos.

b) Veculos de Integrao J os veculos de integrao evoluem em contedo at o evento Trmino das Liberaes de Engenharia, servindo de base ao

desenvolvimento e validao de todos os sistemas, sub-sistemas e componentes do projeto, motivo pelo qual esta fase se estende at o evento Trmino da Validao do Produto.

c) Veculos Piloto Os veculos piloto so veculos para validao do processo produtivo, tambm sendo utilizados na obteno de aprovaes finais ou homologaes de rgos oficiais. De forma anloga aos veculos de integrao, h uma evoluo dos veculos piloto at o evento Trmino da Validao do Processo, a partir do qual se inicia a avaliao do processo de produo em condies normais de operao, ou seja, utilizando-se componentes

63

comprados aprovados (Final PPAP) pela Engenharia de Qualidade de Fornecedores e componentes manufaturados internamente aprovados com os mesmos critrios de qualidade dos componentes normais de produo.

A seleo do fornecedor em uma etapa inicial do processo de desenvolvimento uma das caractersticas do co-desenvolvimento (co-design) apresentadas por KESSELER (1997), porm tal definio estratgica para a montadora, pois implica em alguns riscos, tais como: o projeto bsico e idias de estilo chegarem aos competidores atravs dos fornecedores ou a montadora ter maior dificuldade na negociao comercial em funo dos fornecedores j estarem participando do desenvolvimento. Por outro lado, o incio de um processo interativo de troca de informaes com os fornecedores logo nas primeiras etapas do projeto, permite a utilizao de seu conhecimento (know-how) na definio das tecnologias a serem aplicadas e na elaborao de especificaes tcnicas de melhor qualidade. Nota-se que o processo de desenvolvimento de veculo (VDP) apresentado, no define como um evento o envolvimento dos fornecedores, uma vez que esta deciso tomada individualmente para cada sistema, sub-sistema ou componente a ser desenvolvido em parceria. Tipicamente, considera-se a necessidade de informaes para a fase de Desenvolvimento de Estilo e a criticidade quanto ao tempo de desenvolvimento do componente (lead time), em funo do incio da construo dos prottipos, como fatores-chave para um envolvimento antecipado de um fornecedor.

5.2 Equipe de Desenvolvimento de Produto

Durante as fases de Desenvolvimento de Estilo, Desenvolvimento do Produto e Desenvolvimento do Processo existe uma forte interao entre diversas reas funcionais, tais como: Marketing, Estilo, Engenharia de Produto, Engenharia de Processos, Finanas (Custos), Materiais (Compras), Qualidade e Servios (PsVendas). Com o objetivo de facilitar este processo interativo, a empresa estudada divide o veculo em sete sistemas e forma uma equipe de desenvolvimento de produto (PDT) para cada um destes, tal como ilustrado pela estrutura matricial mostrada na figura 5.5.

64

Figura 5.5 Estrutura matricial das equipes de desenvolvimento de produto

Participam das equipes de desenvolvimento de produto, um representante de cada rea funcional, sendo este consultado sempre que alguma deciso ou informao sobre qualquer sub-sistema ou componente, cujo desenvolvimento de responsabilidade da equipe, envolver sua rea funcional. Um dos participantes definido como o lder da equipe de desenvolvimento (PDT Leader) e passa a ser o responsvel por acompanhar e reportar ao Planejamento (Plataforma) o andamento do desenvolvimento dos sub-sistemas e componentes, pelos quais sua equipe de desenvolvimento de produto (PDT) responsvel. Em reunies peridicas agendadas com a gerncia da plataforma, os lderes de equipe (PDT Leader) discutem o cronograma de desenvolvimento, metas de qualidade, metas de custo e dificuldades que no puderam ser resolvidas dentro da equipe de desenvolvimento (PDT). Por outro lado, cabe ao representante de cada rea funcional distribuir as atividades

65

solicitadas na equipe de desenvolvimento (PDT) para outros colaboradores dentro de sua rea funcional que estejam envolvidos com o mesmo programa. Por exemplo, o representante da Engenharia de Produto deve distribuir as informaes e decises obtidas na equipe de desenvolvimento de produto (PDT) a cada engenheiro responsvel pelo desenvolvimento de um sub-sistema ou componente que esteja vinculado quela equipe de desenvolvimento (PDT), bem como, coletar os assuntos que necessitam de uma informao ou deciso da equipe de desenvolvimento de produto (PDT). Pode-se representar o desenvolvimento dos sub-sistemas e componentes dentro de uma equipe de desenvolvimento de produto (PDT) em uma espiral de projetos, onde interao entre cada rea funcional e o projeto do componente representada pela interseco da espiral (projeto) com uma das linhas radiais (rea funcional), como ilustrado pela figura 5.6.

Figura 5.6 Representao da interao entre as reas funcionais

66

Na prtica, porm, nota-se que estabelecida uma rede de relacionamentos interligando os colaboradores de cada rea funcional que estejam envolvidos com o desenvolvimento de um mesmo sub-sistema ou componente, evitando-se assim, que a equipe de desenvolvimento de produto (PDT) torne-se um gargalo para o andamento do projeto do componente em questo, quando h a necessidade de troca de informao entre as diversas reas funcionais. Em funo de vrios fornecedores estarem envolvidos no desenvolvimento de vrios sub-sistemas e componentes, cuja responsabilidade de uma mesma equipe de desenvolvimento de produto (PDT), estes no so includos como membros diretos de cada uma das sete equipes de desenvolvimento (PDT), porm participam da rede de relacionamento que interliga os colaboradores de cada rea funcional. Esta participao pode ser direta, no caso em que o fornecedor designa um Engenheiro Residente para trabalhar na montadora durante o desenvolvimento de um sub-sistema ou componente, ou indireta, quando a participao do fornecedor atravs do Engenheiro de Produto da montadora.

5.3 Processo de Co-Desenvolvimento

O processo de desenvolvimento em parceria com um fornecedor (codesenvolvimento), observado na empresa objeto deste estudo, pode ser dividido em seis etapas distintas, a saber:

a) Seleo da tecnologia Nesta etapa, busca-se definir o conceito e a tecnologia que ser empregada no desenvolvimento de um novo sistema, sub-sistema ou componente. O conhecimento sobre inovaes, adquirido atravs de visitas aos fornecedores, seminrios tcnicos, estudos comparativos com a concorrncia (benchmarking), etc. e o histrico de qualidade do sistema ou componente atual, so fatores de influncia na deciso do conceito do novo sistema ou componente.

b) Elaborao da especificao O estilo de especificao adotado, mais funcional ou mais quantitativo (NELLORE, 2001), influencia diretamente no potencial de contribuio do

67

fornecedor ao projeto. Especificaes mais quantitativas so mais restritivas e podem se tornar um fator limitante utilizao de novas tecnologias e solues de conhecimento do fornecedor. Por outro lado, especificaes muito abertas podem resultar em produtos que no correspondem ao esperado no momento da elaborao da especificao. Tipicamente, referncias de especificaes anteriores, mscaras padronizadas e normas tcnicas (externas ou internas) so fatores de influncia durante a etapa de elaborao da especificao.

c) Definio do custo-objetivo Nesta etapa, os objetivos de custo do programa devem ser transformados em um valor de custo-objetivo para cada sistema, sub-sistema ou componente, que ser desenvolvido, garantindo-se assim, que o custo do novo veculo seja coerente com a estratgia da empresa para este produto. Alm do prprio objetivo de custo do programa, as caractersticas tcnicas e funcionais do novo sistema ou componente, so os fatores de influncia na definio deste custo.

d) Seleo do fornecedor A seleo do fornecedor influenciada diretamente pela proposta tcnica e comercial apresentada e pelo histrico de cada fornecedor que participa do processo de seleo.

e) Desenvolvimento do componente A etapa de desenvolvimento do componente influenciada pelo processo de desenvolvimento de produto (PDP) adotado no fornecedor e pelo processo de desenvolvimento de veculo (VDP) adotado na montadora. Razo pela qual, buscou-se padronizar o processo de desenvolvimento de produto (PDP) dos fornecedores automotivos, atravs do APQP, como discutido no captulo trs.

f) Integrao e validao no veculo Finalmente, a etapa de integrao e validao no veculo tem influncia direta do processo de desenvolvimento de veculo (VDP) da

68

montadora, pois este define o plano e o cronograma para validao em veculos dos diversos sistemas, sub-sistemas e componentes desenvolvidos em parceria com os fornecedores. A figura 5.7 ilustra estas etapas e os fatores de influncia a elas relacionados.

Figura 5.7 Etapas do co-desenvolvimento e seus fatores de influncia

No decorrer deste captulo, sero discutidas mais detalhadamente estas etapas e seus aspectos especficos.

69

5.4 Especificao do Sistema, Sub-Sistema ou Componente

Em seu estudo sobre gesto da relao cliente-fornecedor na indstria automotiva, NELLORE (2001) destaca a importncia da especificao e apresenta a cadeia de especificaes utilizadas no processo de desenvolvimento de veculos (VDP). A figura 5.8 ilustra esta cadeia, onde os fornecedores exercem influncia na elaborao das especificaes dos sub-sistemas e dos componentes.

Figura 5.8 Cadeia de especificaes no desenvolvimento de um veculo (NELLORE, 2001 - Traduzido e adaptado pelo autor)

A especificao do segmento de mercado e a especificao inicial do veculo representam o incio da cadeia e descrevem as caractersticas do mercado e arquitetura do veculo a ser desenvolvido. A especificao do veculo descreve as caractersticas de performance do veculo e seus sistemas, detalhando a arquitetura a ser utilizada. J as especificaes dos sub-sistemas e dos componentes traduzem os requisitos da especificao do veculo em nvel de componentes e podem ser influenciadas pelos fornecedores. A tabela 5.1 exemplifica alguns requisitos de Servios (after-sales) descritos nos diversos nveis de especificao da cadeia apresentada por NELLORE (2001).

70

Tabela 5.1 Exemplos de requisitos descritos nos diversos nveis de especificao (NELLORE, 2001 - Traduzido e adaptado pelo autor) Especificao

Exemplos de Requisitos O veculo deve rodar 30.000 km sem qualquer manuteno;

Especificao tcnica do veculo

O veculo deve operar com um determinado tipo de leo;

Deve haver fcil acesso ao ponto de carga do refrigerante utilizado no sistema de ar condicionado;

Especificao tcnica do sub-sistema

As ferramentas presentes no veculo devem ser suficientes para as operaes realizadas no sistema;

Devem

ser

utilizados

somente

os

parafusos

Especificao tcnica do componente

padronizados na fixao do componente de forma que todos os parafusos possam ser soltos ou apertados somente com as ferramentas presentes no veculo;

Na montadora estudada para este trabalho, nota-se que o envolvimento do fornecedor na elaborao das especificaes tcnicas dos sub-sistemas e componentes predominantemente indireto, ou seja, se faz atravs das informaes obtidas pelos membros da equipe de desenvolvimento (PDT) da montadora, seja em reunies tcnicas com os potenciais fornecedores, seja atravs de visitas e seminrios. Observa-se, tambm, que alguns fornecedores reconhecem esta caracterstica do processo de co-desenvolvimento e por isso investem no mais somente na divulgao de seus produtos, mas sim na divulgao de suas capacidades de engenharia e conhecimentos tecnolgicos (know-how), pois atravs desta estratgia podem aumentar o potencial de participao em um novo projeto ou negcio quando ainda este se encontra em fase conceitual ou de elaborao das especificaes tcnicas. Ainda segundo NELLORE (2001), o grau de necessidade de informaes quantitativas nas especificaes pode ser relacionado ao estgio do relacionamento cliente-fornecedor, ou seja, na medida em que este relacionamento evolui, h uma menor necessidade de informaes quantitativas, tornando as especificaes mais funcionais, como ilustra a figura 5.9.

71

Figura 5.9 Necessidade de especificaes quantitativas em funo do estgio do relacionamento cliente-fornecedor (NELLORE, 2001 - Traduzido e adaptado pelo autor)

Em se tratando de sistemas, sub-sistemas ou componentes, onde a estratgia da montadora estudada permite algum nvel de integrao com o fornecedor (codesenvolvimento), pode-se dizer que as especificaes tcnicas destes sub-sistemas e componentes seguem a estrutura apresentada na figura 5.10.

Figura 5.10 Estrutura das especificaes dos sub-sistemas e componentes na montadora estudada

72

De forma geral, as especificaes tendem a ser mais funcionais e menos quantitativas, e so compostas de trs blocos. Em um bloco comum a todas as especificaes so descritos a sistemtica de trabalho da montadora (estrutura das equipes de desenvolvimento, processos de alterao do projeto, processos de comunicao, etc.), bem como os recursos que o fornecedor deve possuir para ser considerado apto ao desenvolvimento em parceria (capacidade de engenharia, sistemas de simulao e desenho, processos de gesto de programas, etc.). Um segundo bloco, este especfico, por conter informaes relacionadas ao veculo no qual o sub-sistema ou componente ser utilizado, descreve dois tipos de informaes, a saber:

a) Informaes do programa Nesta parte da especificao so descritos os eventos e datas-chave presentes no processo de desenvolvimento de veculo (VDP) para o programa em questo, bem como, os nveis de prottipos que o fornecedor dever produzir para a validao em veculo (mock-ups, componentes de ferramental provisrio e componentes de ferramental definitivo) e sua respectiva quantidade necessria, alm de uma matriz de responsabilidades (RASI Chart), que define quais atividades devem ser realizadas pelo fornecedor e quais atividades sero realizadas pela montadora no decorrer do programa.

b) Informaes do componente Nesta parte da especificao so descritas as informaes de funcionalidade e desempenho (performance) requeridos para o componente, a interface entre o veculo e o componente, incluindo-se restries de envelope (3D), informaes do ambiente (temperatura, vibrao, etc.) que o componente deve suportar e informaes eltrica/eletrnicas (alimentao, consumo, protocolo de comunicao de dados, etc.), quando aplicvel. Tambm, nesta parte, so detalhados os testes requeridos para a validao do sub-sistema ou componente, sejam eles virtuais ou fsicos, exigidos por recomendao interna da montadora, do fornecedor ou pela legislao. Finalmente, so listadas as normas e documentos de referncia que devem ser observados no desenvolvimento do componente.

73

A ferramenta da matriz de responsabilidades (RASI Chart) tem uma importncia significativa para evitar uma interpretao incorreta da especificao quanto ao que deve ser feito por cada um dos envolvidos no desenvolvimento, o que foi considerado uma das trs fontes de problemas em desenvolvimentos em parceria (co-desenvolvimento) no estudo realizado por WYNSTRA et al (2001). A falta de uma clara definio de responsabilidades pode, por exemplo, criar divergncias entre as expectativas da montadora e do fornecedor, impactando na estratgia de investimentos dos envolvidos em funo de premissas incorretas da dimenso de suas responsabilidades (WYNSTRA et al, 2001). De forma geral, a matriz de responsabilidade mostra a lista de atividades necessrias na primeira coluna, relacionando cada envolvido com cada atividade, atravs da legenda RASI padronizada. Tipicamente, os envolvidos (Envolvido 1 at Envolvido N) so as reas funcionais e seus respectivos responsveis de cada uma das empresas, montadora e fornecedor, que interagem na realizao de cada atividade do projeto em parceria. A legenda RASI vem do acrnimo em ingls para Responsible / Approve / Support / Informed e pode ser interpretada da seguinte forma: A letra (R) identifica o responsvel pela execuo da atividade, a letra (A) o responsvel pela aprovao do resultado da atividade, a letra (S) o responsvel por fazer parte do trabalho necessrio execuo da atividade e a letra (I) identifica quem apenas ser informado sobre o andamento da atividade. A figura 5.11 exemplifica uma matriz de responsabilidades.

Atividades Envolvido 1 Atividade 1 Atividade 2 Atividade 3 Atividade 4 Atividade 5 ... Atividade N R A S I R /A ... R A R

Envolvidos Envolvido 2 ... ... ... ... ... ... ... ... Envolvido N S S I S I ... S

R/A R/A S ... A

Figura 5.11 Exemplo de matriz de responsabilidades

74

Para facilitar a etapa de elaborao da especificao tcnica dos sub-sistemas e componentes, a montadora estudada mantm modelos (templates) de especificao para cada sistema, sub-sistema e componente que permite algum nvel de integrao com o fornecedor (co-desenvolvimento), segundo a estratgia da empresa. Esta iniciativa ajuda a definir os requisitos para um projeto em particular, bem como reduz o tempo total de emisso das especificaes. Por outro lado, no elimina a necessidade de boas prticas de engenharia, uma vez que as informaes do bloco especfico (programa e componente) necessitam da ao direta dos engenheiros da montadora. Tambm, cabe a estes engenheiros re-alimentar o grupo responsvel pela atualizao destes modelos em funo de novas tecnologias e novos conceitos para o sub-sistema ou componente em questo. Tal discusso feita por conferncias peridicas entre os engenheiros responsveis por um mesmo sub-sistema ou componente nos diversos centros de engenharia da empresa. Esta sistemtica permite que o fornecedor exera uma influncia indireta nos modelos (templates) disponveis de especificaes, uma vez que as informaes compartilhadas com os engenheiros da montadora acabam por ser discutidas em uma destas conferncias, gerando retorno ao investimento feito pelos fornecedores na divulgao de tecnologias.

5.5 Definio do Custo-Objetivo

O custo-objetivo de um sistema, sub-sistema ou componente, que ter seu desenvolvimento em parceria com um fornecedor, serve de referncia para o processo de seleo do fornecedor e deve estar alinhado com os objetivos de custo para o veculo (programa). Na montadora estudada, este custo-objetivo por componente estabelecido pela rea de Finanas (custos) com o suporte da equipe de desenvolvimento de produto (PDT). Utiliza-se, como referncia inicial, uma pea atualmente em produo conceitualmente similar ao componente a ser desenvolvido. A partir do custo desta pea-referncia, adicionam-se ou subtraem-se valores em funo das caractersticas especficas do novo componente (solues de engenharia, massa, dimenso, materiais necessrios, etc.) conhecidas dentro da equipe de desenvolvimento de produto (PDT). A figura 5.12 uma representao esquemtica da definio deste custo-objetivo.

75

Figura 5.12 Representao esquemtica da definio do custo-objetivo de componentes comprados

O processo de adio e subtrao de custo a partir do custo de uma peareferncia apresenta um bom resultado quando as caractersticas, que diferem a peareferncia do componente a ser desenvolvido, so mensurveis e conhecidas, tais como: massa, dimenso e material utilizado. Por outro lado, quanto maior o nvel de inovao do novo componente, maior o grau de incerteza na atribuio do custoobjetivo, uma vez que se acaba por estimar o impacto das inovaes conceituais no custo, sem uma anlise mais profunda. Nota-se tambm, que existe um grande enfoque em documentar o conceito inicialmente estabelecido para o sub-sistema ou componente (concept sheet), juntamente com seu respectivo detalhamento de custo (cost breakdown), visando explicitar os valores adicionados e subtrados durante o processo de definio do custo-objetivo do novo componente. Tal prtica assume que o custo da peareferncia, presente no banco de dados da empresa, esteja correto, ou seja, represente o custo verdadeiro (custo real) do componente, o que nem sempre adequado, pois a pea-referncia pode estar super-custeada ou sub-custeada em funo das negociaes ocorridas durante seu processo de cotao. Por outro lado, tal documentao do conceito inicial tem auxiliado, no s na definio do custoobjetivo do componente para o processo de cotao, mas tambm na compreenso

76

das modificaes ocorridas no componente durante a evoluo do projeto do veculo, facilitando assim, as negociaes de custo aps o processo de seleo do fornecedor.

5.6 Seleo do Fornecedor

Segundo a observao feita na montadora estudada, esta segue um processo convencional de seleo de fornecedores, o qual pode ser representado em cinco etapas, como ilustra a figura 5.13.

Figura 5.13 Processo de seleo dos fornecedores

A partir da especificao tcnica emitida e do custo-objetivo definido para um novo sub-sistema ou componente, a rea comercial da montadora distribui pacotes de

77

cotao aos potenciais fornecedores, que foram pr-selecionados por critrios internos de atendimento, qualidade, flexibilidade, capacidade e custo. Estes potenciais fornecedores retornam com propostas tcnicas e comerciais, as quais so consolidadas em reunies especficas entre as reas comerciais e de engenharia da montadora e do potencial fornecedor. Ao trmino deste ciclo de reunies de consolidao de propostas (technical reviews) com os potenciais fornecedores, eventuais revises podem ser feitas no objetivo inicial de preo, porm este ainda deve se manter dentro do custo-objetivo definido para o sub-sistema ou componente em questo. Finalmente, h uma negociao final e a contratao do fornecedor selecionado. Nota-se que o efetivo envolvimento do fornecedor no projeto se inicia apenas aps sua contratao oficial, exceto por informaes obtidas de consultas informais aos engenheiros dos fornecedores sobre novas tecnologias e conceitos disponveis, que posteriormente podem ter sido aproveitadas na especificao tcnica. Tambm, como no h um evento explcito no processo de desenvolvimento de veculo (VDP) definindo o perodo onde devam ocorrer todos os processos de seleo de fornecedores (ver item 5.1), este acaba por ser estabelecido no cronograma-mestre de cada projeto (programa). Um plano de seleo de fornecedores (sourcing plan) elaborado dentro de cada equipe de desenvolvimento de produto (PDT) e compromissado entre a rea comercial e a rea de planejamento da plataforma. Entretanto, acaba-se por antecipar o processo de seleo dos fornecedores de sub-sistemas e componentes considerados crticos, seja em funo da necessidade de informao especfica para alguma fase subseqente do desenvolvimento do veculo, ou seja devido ao tempo total de desenvolvimento do componente (lead time) para o atendimento das fases de construo de veculos prottipos. Tipicamente, o tempo total para o processo de seleo de um fornecedor de vinte e uma semanas, sendo sete para a elaborao e emisso da especificao e quatorze para as demais etapas at a contratao do fornecedor selecionado.

78

5.7 Gesto do Desenvolvimento do Sistema, Sub-Sistema ou Componente

O desenvolvimento do sistema, sub-sistema ou componente compreende atividades no fornecedor e na montadora, sofrendo a influncia do processo de desenvolvimento de produto (PDP) adotado no fornecedor e do processo de desenvolvimento de veculo (VDP) adotado na montadora. Uma vez que a montadora estudada para este trabalho segue o manual de referncia Advanced Product Quality Planning (APQP) and Control Plan como guia para o desenvolvimento de produto em seus fornecedores, os formulrios de verificao (check lists) previstos neste manual so aplicados como ferramentas de planejamento e acompanhamento das atividades durante o co-desenvolvimento. Os oito formulrios de verificao (check list) do Apndice A do APQP (A-1 at A-8) so utilizados ao longo do desenvolvimento do plano de projeto (APQP Project Plan) e compreendem os aspectos listados na tabela 5.2.

Tabela 5.2 Formulrios de verificao previstos no APQP Formulrio de verificao (checklist) A-1 A-2 A-3 A-4 A-5 A-6 A-7 A-8 Utilizao FMEA de projeto (DFMEA). Reviso de projeto. Identificao de necessidade de novo equipamento, ferramental ou dispositivo de teste. Qualidade do produto e do processo. Layout de fbrica. Fluxo do processo de produo. FMEA de processo (PFMEA). Plano de controle do produto.

O plano de projeto (APQP Project Plan) um requisito especfico da montadora estudada, que complementa os requisitos de norma. Neste plano de projeto so relacionadas dezessete atividades, sendo que treze delas ocorrem aps a etapa de seleo do fornecedor, tendo sua evoluo verificada em quatro eventos de reviso (gate reviews) previstos no plano de projeto. Tais eventos ocorrem antes do

79

fornecedor enviar componentes para a validao em veculo na montadora, ou seja, antes da montagem dos veculos de arquitetura, integrao (ferramental provisrio e ferramental definitivo) e piloto. A tabela 5.3 relaciona as atividades do plano de projeto (APQP Project Plan) que tem o envolvimento do fornecedor com os respectivos eventos de reviso (gate reviews) onde estas so verificadas.

Tabela 5.3 Atividades do plano de projeto com envolvimento do fornecedor Atividade ER-1 1. Cronograma e lista de pendncias (Open Issues List) 2. Estudo de viabilidade 3. Fluxo do processo 4. DFMEA 5. Reviso do projeto (design reviews) 6. Reviso dos dispositivos e ferramentas 7. Relatrio de conformidade de pea- prottipo 8. PFMEA 9. Plano de controle do processo 10. Plano de controle para incio de produo 11. PPAP 12. Capacidade de produo (Run @ Rate) 13. Lies aprendidas (lessons learned) X X X X X X X X X X X X X Eventos de Reviso ER-2 X X X X X X X X X X X X X X X X X X X X X X ER-3 X X ER-4 X X X X

Nota-se que algumas atividades podem estar em estgios diferentes (planejamento, anlise, execuo, etc.) em cada um dos eventos de reviso (gate reviews), mas mesmo assim so verificadas conforme a tabela acima.

Cabe destacar que a ferramenta da lista de pendncias (Open Issues List), estabelecida pelo plano de projeto (APQP Project Plan) da montadora estudada, tem particular importncia para a fase de desenvolvimento do produto em parceria (codesenvolvimento), pois esta documenta a evoluo no desenvolvimento do subsistema ou componente em questo, sinalizando os problemas e aes necessrias

80

para se ter um bom resultado naquele processo de desenvolvimento em particular. Tipicamente, este documento utilizado como referncia nas reunies peridicas de acompanhamento realizadas dentro da equipe de desenvolvimento de produto (PDT), podendo tambm ser consultada durante negociaes comerciais com o fornecedor em funo de alteraes de projeto do sub-sistema ou componente em questo. A figura 5.14 mostra o modelo da lista de pendncias (Open Issues List), a qual preenchida e atualizada pelo fornecedor e verificada pelos engenheiros da montadora (produto e qualidade) no decorrer do projeto.

Figura 5.14 Modelo de lista de pendncias

Basicamente, este documento composto por um cabealho com informaes gerais (programa, fornecedor, planta, componente e pessoas de contato) e uma lista aberta, onde os assuntos e/ou pendncias so documentados durante o desenvolvimento do projeto. Nota-se que os campos (colunas) so auto-explicativos, cabendo apenas algum esclarecimento sobre as informaes de Severidade, Tipo e Indicador de Progresso. O campo Severidade mostra em que nvel das organizaes (fornecedor e/ou montadora) o assunto ou pendncia ser discutido. J, o campo Tipo classifica os assuntos ou pendncias em categorias, tais como: relativos ao projeto (fornecedor), ao projeto (montadora), ferramental, capacidade de produo,

81

liberao de informao de engenharia, processo de manufatura, compras, logstica, controle de produo, etc. Finalmente, o campo Indicador de Progresso revela a evoluo do assunto ou pendncia em questo, classificando o item ou pendncia em Item Identificado, Plano de Ao Proposto, Plano de Ao Implementado ou Item Resolvido.

Apesar da lista de pendncias (Open Issues List) ser uma ferramenta simples e um requisito do plano de projeto (APQP Project Plan) da montadora estudada, observa-se que no h uma disciplina no acompanhamento desta lista por parte dos engenheiros de produto da montadora. Por outro lado, como a lista de pendncias (Open Issues List) verificada pelo engenheiro de qualidade de fornecedores ao menos nos eventos de reviso (gate reviews) previstos no plano de projeto (APQP Project Plan), esta acaba, em parte dos casos, tendo seu foco mais direcionado aos assuntos de produo do sub-sistema ou componente em desenvolvimento. J quando ocorre o uso pleno desta ferramenta, documentando-se tambm os assuntos de desenvolvimento do produto (modificaes de projeto e suas razes, data de incio do ferramental, etc.), a experincia mostra que as negociaes comerciais so menos desgastantes quando alteraes no custo do componente e/ou investimentos adicionais em ferramentais so necessrios em funo de modificaes de projeto. Isto porque a lista de pendncias (Open Issues List) acaba esclarecendo o histrico das modificaes, o que permite julgar melhor quais modificaes realmente alteraram o custo do componente e quais modificaes realmente impactaram em algum dos ferramentais, considerando-se seu estgio de construo e a data da modificao. Do contrrio, h um maior desgaste para ambas as organizaes (montadora e fornecedor) na busca das ordens de modificao de produto emitidas pela engenharia da montadora, porm tais documentos esclarecem o contedo da modificao e suas razes, mas nem sempre, por exemplo, informam qual era o estgio do desenvolvimento quando da solicitao da modificao, dificultando, por exemplo, uma deciso ou acordo sobre o impacto da modificao no investimento em ferramentais.

82

5.8 Anlises e Concluses

O processo de desenvolvimento de veculo (VDP) uma aplicao especfica do processo de desenvolvimento de produto (PDP) apresentado por CLARK e FUJIMOTO (1991), onde alm das fases de Projeto do Produto e Projeto do Processo, ou seja, as fases de desenvolvimento, incluem-se fases especficas de construo e validao de prottipos. Apesar da seleo do fornecedor em uma etapa inicial do processo de desenvolvimento ser uma das caractersticas do codesenvolvimento (co-design) apresentadas por KESSELER (1997), nota-se que o processo de desenvolvimento de veculo (VDP) da montadora estudada no define um perodo onde devam ocorrer todos os processos de seleo e o conseqente envolvimento dos fornecedores no projeto. Um plano de seleo de fornecedores acaba sendo elaborado nas equipes de desenvolvimento de produto (PDT), tendo o compromisso das reas comercial e de planejamento da plataforma. Entretanto, tal plano considera a necessidade de informao especfica para as fases subseqentes do desenvolvimento ou o tempo de desenvolvimento do componente (lead time) em relao s fases de construo de veculos prottipos, como os fatores-chave para a antecipao de um processo de seleo e/ou envolvimento do fornecedor no projeto. Mesmo constatando-se que a estrutura matricial das equipes de

desenvolvimento de produto (PDT) facilita a interao entre as reas funcionais da organizao envolvidas com um projeto, nota-se que a rede informal de relacionamentos entre os colaboradores de cada rea funcional e os fornecedores evita que a estrutura formal destas equipes (PDT) torne-se um gargalo para o andamento do projeto. A experincia mostra que a participao direta nesta rede de relacionamentos, por exemplo, atravs de um Engenheiro Residente do fornecedor na montadora ou uma equipe do fornecedor dedicada ao projeto, cria uma sinergia positiva ao andamento do projeto em parceria. Com relao s etapas do processo de desenvolvimento de produto em parceria e seus fatores de influncia (ver item 5.3), pode-se dizer que a etapa de Seleo da tecnologia totalmente independente da existncia de um programa ou projeto de veculo em andamento, enquanto que a etapa de Elaborao da especificao parcialmente dependente de um programa ou projeto. J as demais etapas, ou seja, a Definio do custo-objetivo, a Seleo do fornecedor, o Desenvolvimento do componente e a Integrao e validao no veculo possuem

83

um maior grau de dependncia de informaes especficas de um programa ou projeto de veculo, conforme as prticas da empresa estudada. A constatao desta relao permite aos fornecedores realizarem um trabalho contnuo, mesmo quando no h um programa ou projeto especfico em andamento, visando influenciar, atravs de informaes sobre novos conceitos e/ou tecnologias, as futuras especificaes tcnicas que sero emitidas quando da existncia de um novo programa ou projeto de veculo. Em seu estudo sobre o papel das especificaes, NELLORE (2001) cita que o desenvolvimento integrado de componentes se inicia na elaborao da especificao, sendo que j neste estgio seria necessrio o envolvimento direto do nvel operacional de ambas as empresas (montadora e fornecedor). Entretanto, notase que na montadora estudada, tal envolvimento indireto, ou seja, atravs de informaes obtidas pelos engenheiros em contatos e/ou visitas aos fornecedores, pois um envolvimento direto necessitaria da definio de um fornecedor antes da emisso formal da especificao tcnica, o que no possvel em funo do processo de seleo de fornecedores adotado pela empresa. Tambm citado no estudo de NELLORE (2001) que alteraes nas especificaes so inevitveis em componentes caixa-preta (black box), sendo que o entendimento desta realidade por parte dos fornecedores, juntamente com a disposio de trabalhar em paralelo com o desenvolvimento de diversas propostas de solues antes de entrar em um maior detalhamento e estabelecer decises de projeto, reduzem o desgaste e a conseqente perda de tempo durante o processo de desenvolvimento. Isto pode ser constatado na prtica, pois a maior parte dos fornecedores de sub-sistemas e componentes, caracterizados como caixa-preta (black box) ou caixa-cinza (gray box), j aceitam uma especificao inicial menos detalhada no momento do processo de seleo de fornecedor, trabalhando posteriormente no detalhamento desta especificao durante o projeto. Apesar de pr-ativa, o que gera um efeito positivo no processo de elaborao da especificao (NELLORE, 2001), tal prtica pode ter efeitos colaterais negativos sobre futuras negociaes comerciais, onde se acaba relacionando diretamente a especificao inicial (preliminar) com o preo inicialmente proposto, considerando-se que toda variao em relao a esta especificao adicione custo ao componente ou necessite de maior investimento em ferramentais e/ou dispositivos de produo. A utilizao da matriz de

responsabilidades (RASI Chart), atribuindo a atividade de elaborao da

84

especificao detalhada ao fornecedor uma das formas de se evitar tais conflitos. Esta ferramenta tem significativa importncia para se ter uma clara definio das responsabilidades antes do incio efetivo de um projeto em parceria (codesenvolvimento). O estudo realizado por WYNSTRA et al (2001) mostra que a falta desta clara definio de responsabilidades uma das trs fontes de problemas em desenvolvimentos em parceria, pois cria divergncias entre as expectativas da montadora e do fornecedor, podendo impactar na estratgia de investimentos dos envolvidos em funo de premissas incorretas quanto dimenso de suas responsabilidades (WYNSTRA et al, 2001). Finalmente, ainda com relao ao tema das especificaes, observa-se que a prtica de se manter modelos (templates) de especificao para cada sistema, sub-sistema e componente, que permite algum nvel de integrao com o fornecedor (co-desenvolvimento), facilita a elaborao da especificao tcnica, mantendo a memria dos aprendizados anteriores e reduzindo seu tempo de emisso. Nota-se que o processo de definio do custo-objetivo para os novos componentes, atravs da adio e subtrao de custo a partir do custo de uma peareferncia, funciona eficientemente quando as diferenas tcnicas entre o novo componente e o de referncia so mensurveis (massa, dimenso, material utilizado, etc.). J quanto maior o nvel de inovao tecnolgica ou valor agregado (eletrnica embarcada, software, etc.) do novo componente, maior o grau de incerteza na definio do custo-objetivo por este processo. Este processo presume que o custo da pea-referncia esteja correto e represente o custo verdadeiro (custo real) do componente, o que nem sempre adequado, pois a pea-referncia pode estar supercusteada ou sub-custeada devido s negociaes comerciais ocorridas desde seu processo de cotao. Um processo mais amplo, envolvendo anlise de valor, anlise de custo dos sub-componentes, custo de produo e custo de transporte, buscando a identificao do custo real do componente, poderia ser incorporado na definio do custo-objetivo dos novos sub-sistemas e componentes. Por outro lado, tais anlises consomem considerveis recursos e necessitam de uma estrutura especfica para sua realizao, sob pena de se obter resultados distorcidos na falta de um nvel adequado de detalhamento. A aplicao destas anlises mais detalhadas na definio do custoobjetivo, visando se evitar o problema da acuracidade do custo da pea-referncia, necessitaria de uma classificao do tipo ABC, identificando os 20% dos subsistemas e componentes que correspondem a 80% do custo do veculo, a fim de se

85

evitar tal trabalho em componentes com baixa representatividade no custo total do veculo. Quanto ao processo de seleo dos fornecedores, nota-se que o processo convencional utilizado na montadora estudada no favorece o envolvimento do fornecedor logo nas primeiras etapas do projeto, pois necessita da elaborao e emisso de uma especificao tcnica para se iniciar. Com isso, a eficincia na utilizao do conhecimento (know-how) do fornecedor diminuda, mesmo que se realizem os processos de seleo de fornecedores em uma etapa inicial do processo de desenvolvimento do veculo (VDP). Uma vez que uma integrao estratgica plena com os fornecedores, tal como observado na rede de fornecedores com controle acionrio cruzado da indstria automobilstica japonesa (WOMACK et al, 1992), no comum nas montadoras ocidentais, a implementao de um conceito de competio de fornecedores poderia auxiliar com uma maior eficincia no uso dos conhecimentos (know-how) dos fornecedores. No conceito de competio de fornecedores haveria o envolvimento antecipado de at trs potenciais fornecedores, os quais receberiam os objetivos comerciais (custo) e tcnicos (desempenho) da montadora e passariam a desenvolver propostas tcnicas-comerciais, interagindo com a montadora durante o incio do processo de desenvolvimento de veculo (VDP), por exemplo, at a avaliao dos primeiros veculos conceituais (veculos mula). Neste momento, a montadora selecionaria a melhor proposta tcnica-comercial, a qual seria a base da especificao tcnica final do sub-sistema ou componente, definindo-se desta forma, o fornecedor ganhador da competio. A montadora obteria melhores solues tcnicas (custo e desempenho) para seus produtos e os fornecedores poderiam influenciar mais em aspectos do projeto dos veculos, os quais j estariam definidos pela especificao tcnica no caso da utilizao de um processo convencional de seleo de fornecedores. Por sua vez, esta influncia no projeto dos veculos permitiria aos fornecedores ter um maior grau de reutilizao de suas solues de engenharia, levando a um maior compartilhamento de subcomponentes e processos de produo, o que geraria uma vantagem competitiva. Por outro lado, a montadora teria que atuar na preveno do vazamento de informaes confidenciais e na definio de regras claras para os custos dos prottipos das solues propostas, enquanto que os fornecedores teriam que assumir o risco de utilizar sua estrutura de engenharia e conhecimentos (know-how) sem a garantia de um contrato de fornecimento. A figura 5.15 mostra a comparao de ambos os

86

processos de seleo, ilustrando onde os fornecedores passariam a participar no desenvolvimento do veculo em cada uma das situaes.

Figura 5.15 Envolvimento do fornecedor em funo do processo de seleo de fornecedores adotado

Com relao gesto do desenvolvimento do sub-sistema ou componente observa-se que a montadora estudada consegue gerenciar as atividades em parceria de uma maneira satisfatria, talvez em funo do prprio sistema do APQP. Nota-se tambm, que existe um desejo maior de colaborao nas fases de desenvolvimento e fornecimento (produo) do sub-sistema ou componente, ou seja, aps a seleo e contratao formal do fornecedor, o que natural pela pouca integrao estratgica entre as montadoras e seu parque de fornecedores na realidade da indstria ocidental.

87

Pode-se dizer que o aspecto que gera maior desgaste nesta relao a negociao comercial em funo de modificaes necessrias ao longo do projeto do sub-sistema ou componente. Algumas vezes, tais situaes chegam a afetar o desenvolvimento de um veculo, quando, por exemplo, no h como se obter peas na data estabelecida para a fase de integrao e validao em veculo. Como citado por NELLORE (2001), alteraes nas especificaes de componentes caixa-preta (black box) so inevitveis, o que justifica a necessidade de uma clara definio de responsabilidades (WYNSTRA et al, 2001), por exemplo, atravs do uso da matriz de responsabilidades (RASI Chart). Tambm, devido a esta mesma constatao, a documentao do histrico do desenvolvimento, atravs de uma lista de pendncias (Open Issues List), colabora no sentido de esclarecer e resolver rapidamente qualquer divergncia comercial, evitando-se impactos negativos ao processo de

desenvolvimento do veculo. Uma vez que a montadora estudada complementa o APQP com o plano de projeto (APQP Project Plan), e este estabelece a lista de pendncias (Open Issues List), seria razovel se empenhar em uma maior divulgao do APQP junto aos engenheiros de produto de ambas as organizaes (montadora e fornecedor) de forma que se fizesse um uso pleno desta ferramenta (lista de pendncias), incluindo-se os assuntos relativos ao desenvolvimento do sub-sistema ou componente. A difuso de tal prtica poderia facilitar as negociaes comerciais, tornando-as menos desgastantes quando da necessidade de alteraes no projeto do sub-sistema ou componente e evitando as situaes onde possa haver impactos negativos ao desenvolvimento do veculo. As tabelas 5.4 at 5.9 sumarizam estas observaes e trazem algumas sugestes para os principais aspectos notados durante este estudo.

88

Tabela 5.4 Observaes e sugestes quanto ao processo de desenvolvimento de produto (PDP) Processo de desenvolvimento de produto (PDP) Observaes

Sugestes

Utiliza um processo (VDP), que inclui as fases de construo e validao de prottipos;

Explicitar a elaborao do plano de seleo de fornecedores como uma fase do VDP;

O VDP no define o envolvimento dos fornecedores no projeto;

A durao do VDP depende da categoria do projeto;

Tabela 5.5 Observaes e sugestes quanto organizao do trabalho Organizao do trabalho Observaes

Sugestes de

Equipes produtos

de desenvolvimento (PDT)

organizadas

matricialmente;

Equipes (PDT) facilitam a interao entre as reas organizacionais;

Fornecedores

no

so

membros

Incentivar a formao de equipes dedicadas ao projeto dentro dos fornecedores;

diretos destas equipes (PDT);

Existe

uma

rede

informal entre

de os rea

relacionamentos colaboradores funcional;

Promover uma maior integrao das reas tcnicas de ambas as e

de

cada

organizaes

(montadora

Fornecedores podem participar desta rede de relacionamentos;

fornecedor), mesmo na ausncia de um projeto de veculo em andamento;

Uma equipe do fornecedor dedicada ao projeto cria uma sinergia positiva ao andamento do desenvolvimento em parceria;

89

Tabela 5.6 Observaes e sugestes quanto s especificaes tcnicas Especificaes tcnicas Observaes

Sugestes

Existe o uso de modelos (templates) para facilitar a elaborao e manter a memria de aprendizados anteriores;

Promover maior integrao tcnica com os fornecedores, tornando mais eficiente a seleo da tecnologia (conceito) do componente, mesmo na ausncia de um projeto especfico;

No h envolvimento direto do fornecedor em funo do processo de seleo de fornecedores da empresa;

Considerar o nvel de integrao permitido no modelo (template) das especificaes;

Pode

existir

um

envolvimento

indireto do fornecedor, atravs de informaes engenheiros da obtidas montadora pelos em

Promover maior divulgao quanto estratgia de integrao (nveis e responsabilidades), incluindo a

contatos, visitas e/ou seminrios organizados pelos fornecedores;

discusso sobre uma especificao mais funcional e menos detalhada;

A maior parte dos fornecedores de componentes caixa-cinza especificao caixa-preta j aceitam inicial ou uma menos

Deixar clara a responsabilidade da especificao final (detalhada) como uma atribuio do fornecedor (RASI Chart) para os componentes caixapreta ou caixa-cinza, evitando-se a relao direta entre a especificao inicial (preliminar) e a proposta de preo, a qual gera desgastes em negociaes comerciais;

detalhada, ou seja, mais funcional;

Utiliza-se a ferramenta da matriz de responsabilidades (RASI Chart) para evitar os efeitos negativos da falta de uma clara definio das

responsabilidades de cada parceiro;

90

Tabela 5.7 Observaes e sugestes quanto definio do custo-objetivo Definio do custo-objetivo Observaes

Sugestes

Utilizao de um mtodo de adio e subtrao de custo a partir do custo de uma pea de referncia;

Mtodo

eficiente

quando

as

diferenas tcnicas entre o novo componente e a pea de referncia so mensurveis (massa, dimenso, etc.);

Incorporar ferramentas de anlise de valor, anlise de custo dos subcomponentes e anlise de custo de produo e fornecimento, buscando identificar o custo real para os subsistemas ou componentes com maior influncia no custo total do veculo, os quais poderiam ser selecionados por um processo tipo ABC (20% dos itens que concentram 80% do custo total do veculo);

Este mtodo introduz um maior grau de incerteza quanto maior for o grau de inovao tecnolgica ou valor agregado (eletrnica embarcada,

software, etc.);

Mtodo presume que o custo da pea de referncia seja o custo verdadeiro (custo real) do componente,

desconsiderando as distores em funo de negociaes comerciais anteriores;

91

Tabela 5.8 Observaes e sugestes quanto seleo dos fornecedores Seleo dos fornecedores Observaes

Sugestes

Processo convencional, iniciando-se com a emisso de uma especificao tcnica pela montadora;

Plano de seleo de fornecedores poderia ter sua execuo definida explicitamente no VDP;

No favorece o envolvimento do fornecedor antes da formalizao de um contrato comercial;

Considerar envolvimento atravs de

antecipao dos um de

no

Plano de seleo de fornecedores prioriza a seleo e o envolvimento dos fornecedores em funo da necessidade especficas de para informaes as fases

fornecedores, processo de

competio

fornecedores,

enquanto no se atinge um grau de integrao estratgia que permita o uso do conhecimento de engenharia do fornecedor (know how) em uma fase conceitual do projeto do veculo;

subseqentes do PDP ou em funo do tempo de desenvolvimento do componente em relao s fases de construo de veculos prottipos;

Tabela 5.9 Observaes e sugestes quanto gesto do co-desenvolvimento Gesto do co-desenvolvimento Observaes

Sugestes

Utiliza as ferramentas do APQP; A lista de pendncias (Open Issues List) colabora no esclarecimento do histrico do projeto, favorecendo a soluo rpida de divergncias

Promover uma maior divulgao do APQP junto aos engenheiros de produto de ambas as organizaes (montadora e fornecedor), visando o uso pleno de ferramentas como a lista de pendncias (Opel Issues List), inclusive com os assuntos relativos ao desenvolvimento do sub-sistema ou componente;

comerciais em funo de alteraes de projeto;

Nota-se

maior

colaborao

do

fornecedor aps sua contratao formal;

92

6 DISCUSSES FINAIS

Os captulos 4 e 5 apresentaram, respectivamente, a estratgia da montadora para o co-desenvolvimento e como o co-desenvolvimento interage com o processo de desenvolvimento de produto da montadora estudada. Estes captulos, bem como os anteriores, terminam com algumas anlises e concluses, que relacionam o que foi observado com aspectos identificados na reviso bibliogrfica. Entretanto, torna-se importante uma discusso adicional sobre trs aspectos da reviso bibliogrfica, que no foram completamente explorados nos captulos anteriores.

6.1 Relacionamento Cliente-Fornecedor

Pode-se dizer que quanto evoluo do relacionamento cliente-fornecedor (MERLI, 1994) entre a montadora estudada e seu parque de fornecedores, o primeiro e segundo nvel (abordagem convencional e melhoria da qualidade, respectivamente) j foram superados, estando hoje, esta relao no terceiro nvel (integrao operacional) com alguma tendncia ao quarto nvel (integrao estratgica) em alguns casos. A figura 6.1 ilustra o posicionamento da montadora estudada em relao evoluo do relacionamento cliente-fornecedor com sua base de fornecedores, conforme a observao do autor deste trabalho.

Figura 6.1 Posicionamento da montadora estudada quanto ao relacionamento cliente-fornecedor

93

Justifica-se este posicionamento em funo do quarto nvel ser definido como uma parceria de negcios com ampla participao do fornecedor no projeto do produto, acordos sobre estratgias e polticas, alm do gerenciamento comum dos procedimentos de negcios, o que somente ocorre com fornecedores coligados, tal como a diviso de motores e transmisses da empresa. No geral, h uma integrao operacional (terceiro nvel), porm com um maior grau de utilizao do codesenvolvimento em funo da prpria estratgia da empresa, que incentiva o desenvolvimento em parceria.

6.2 Processo Integrado de Desenvolvimento de Produto e Fornecimento

Com relao s atividades do processo integrado de desenvolvimento de produto e fornecimento (IPDS) proposto por WYNSTRA et al (2001), as tabelas 6.1, 6.2, 6.3 e 6.4 trazem uma comparao entre cada atividade proposta no IPDS e o que praticado na montadora estudada, juntamente com uma avaliao (1 a 5) em funo das observaes do autor deste trabalho, onde 5 significa Sempre realiza a atividade, 4 significa Quase sempre realiza a atividade, 3 significa Realiza regularmente a atividade, 2 significa Quase nunca realiza a atividade e 1 significa Nunca realiza a atividade.

Tabela 6.1 Atividades do IPDS na montadora estudada Gesto do Desenvolvimento Gesto do Desenvolvimento Atividade

Avaliao 5 4

Determinar quais tecnologias devem ser mantidas ou desenvolvidas internamente e quais externamente;

Estabelecer polticas para o envolvimento de fornecedores; Estabelecer polticas para as atividades dos departamentos internos em um processo integrado de desenvolvimento de produto e fornecimento;

Comunicar as polticas internamente e externamente;

94

Tabela 6.2 Atividades do IPDS na montadora estudada Gesto da Interface com o Fornecedor Gesto da Interface com o Fornecedor Atividade

Avaliao 3

Monitorar o mercado de fornecedores para desenvolvimentos tcnicos;

Pr-selecionar fornecedores para colaborao em desenvolvimento de produto;

Motivar os fornecedores a manterem ou construrem uma base de conhecimentos ou desenvolverem certos produtos;

3 3 3

Explorar a capacidade tcnica dos fornecedores; Avaliar o desempenho dos fornecedores quanto ao desenvolvimento, inclusive na sua pontuao geral;

Tabela 6.3 Atividades do IPDS na montadora estudada Gesto do Projeto Gesto do Projeto Fase

Atividade Selecionar fornecedores para o envolvimento no projeto de desenvolvimento;

Avaliao 2

Desenvolvimento do Conceito

Determinar a extenso do envolvimento do fornecedor; Determinar o momento do envolvimento do fornecedor;

3 5 5 5

Coordenar as atividades do desenvolvimento; Coordenar as atividades do projeto bsico; Coordenar as atividades de engenharia; Coordenar a prototipagem e o incio de produo;

Projeto Bsico Detalhamento de Engenharia Piloto e Incio de Produo

95

Tabela 6.4 Atividades do IPDS na montadora estudada Gesto do Produto Gesto do Produto Atividade

Avaliao 3 3 4 4

Fornecer informaes sobre os novos produtos e/ou tecnologias; Sugerir alternativas de fornecedores, produtos e/ou tecnologias; Avaliar os projetos de produtos; Promover a padronizao e a simplificao;

Nota-se que, de forma geral, as atividades propostas pelo IPDS so executadas dentro da montadora estudada, cabendo comentar as atividades com avaliao 1 e 2, respectivamente, Nunca realiza a atividade e Quase nunca realiza a atividade. A atividade Comunicar as polticas internamente e externamente foi avaliada como 2, pois apesar de haverem polticas estabelecidas para o envolvimento dos fornecedores (Captulo 4), observa-se que sua divulgao externa e interna no abrangente. Tambm as atividades Selecionar fornecedores para o envolvimento no projeto de desenvolvimento e Determinar a extenso do envolvimento do fornecedor foram avaliadas como 2, pois apesar de serem realizadas, no ocorrem tipicamente na fase de desenvolvimento do conceito, como na proposta do IPDS, e sim durante o projeto bsico, o que leva a uma perda na incorporao de tecnologias e solues vindas dos fornecedores.

6.3 Caractersticas do Co-Desenvolvimento

Quanto s caractersticas do co-desenvolvimento (co-design) apresentadas por KESSELER (1997), a tabela 6.5 sumariza o que foi observado, pelo autor deste trabalho, durante este estudo.

96

Tabela 6.5 Observaes quanto s caractersticas do co-desenvolvimento na montadora estudada Caractersticas do co-desenvolvimento Observaes na montadora estudada

No h clara definio quanto ao momento em que os fornecedores

Solicitaes ao fornecedor so feitas antecipadamente, incluindo-se o preo-objetivo e a descrio funcional do produto;

devam ser envolvidos no VDP, porm utiliza-se o custo-objetivo e as especificaes tendem a ser mais funcionais para os componentes que permitem algum nvel de integrao pela estratgia da empresa.

A seleo do fornecedor baseada em uma deciso da rea de projeto, no sendo somente uma deciso da rea de compras, como tradicionalmente;

O processo de seleo liderado pela rea de compras, porm com a participao da Engenharia de Qualidade de Fornecedores e da Engenharia de Produto;

No diretamente, porm o fornecedor acaba absorvendo conhecimentos sobre a engenharia do veculo em funo da interface do sistema sob sua responsabilidade com os demais sistemas do veculo;

Existe a transferncia de conhecimento (know-how) ao fornecedor;

Poucos fornecedores so selecionados por produto (um ou dois);

Tipicamente, no h mais do que trs potenciais fornecedores para um sistema, que tenham capacidade para o desenvolvimento em parceria;

97

No h a participao direta nas equipes formais de desenvolvimento de produto da montadora (PDT),

Representantes do fornecedor participam da equipe de desenvolvimento da montadora;

mas tipicamente h uma grande interao com o engenheiro de produto da montadora e em alguns casos, um engenheiro residente do fornecedor trabalhando junto Engenharia de Produto da montadora;

Existe a nomeao de um gerente de projeto no fornecedor;

Normalmente, tem-se um gerente ou coordenador nomeado em cada fornecedor;

O fornecedor tem autonomia na escolha dos mtodos e tcnicas a serem utilizadas no desenvolvimento do produto, porm fica obrigado a declarar claramente cada escolha;

Existe esta autonomia do fornecedor;

Tipicamente, existem reunies peridicas de acompanhamento do

Comunicao intensa entre a montadora e o fornecedor;

projeto com a Engenharia de Produto e Engenharia de Qualidade de Fornecedores, alm de extensa comunicao informal (telefone, email, etc.);

Possibilidade de a montadora alterar os requisitos do projeto durante o desenvolvimento, porm sendo tais mudanas acordadas entre ambos;

Existe esta possibilidade para a montadora;

98

Pelo lado da montadora, isto ocorre apenas at a definio do custo-

Integrao antecipada dos aspectos financeiros no estudo tcnico do projeto;

objetivo, ou seja, sem o envolvimento do fornecedor, uma vez que o custo-objetivo e a especificao tcnica so prrequisitos ao processo de seleo de fornecedores;

Validao dos resultados obtidos como um processo contnuo ou interativo, tendo como objetivo maior, a melhoria do produto e do processo, e no sendo uma maneira de se punir uma baixa performance;

Caracterstica no observada;

Observa-se que, de maneira geral, h uma forte presena das caractersticas de codesenvolvimento citadas por KESSELER (1997) na montadora estudada, bem como, esta se preocupa em estabelecer estratgias e polticas para o desenvolvimento em parceria, tal como a definio dos nveis de integrao permitidos, onde nota-se relao direta com o estudo de CLARK e FUJIMOTO (1991) sobre os nveis de participao dos fornecedores no desenvolvimento.

99

7 CONCLUSES E CONSIDERAES FINAIS

De maneira geral, constata-se que h colaborao e cooperao dos fornecedores durante o desenvolvimento e o fornecimento do produto, porm aps a formalizao de um contrato e sempre havendo desgastes em negociaes comerciais quando alguma alterao do produto necessria. Esta vinculao entre a formalizao do contrato e a colaborao perfeitamente compreensvel em nossa realidade de mercado, porm nos remete a um relacionamento cliente-fornecedor de integrao operacional, segundo a classificao proposta por MERLI (1994), no havendo todas as vantagens da ampla participao dos fornecedores no projeto, tal como em um relacionamento em nvel de integrao estratgica.

Pode-se dizer que um avano na estratgia de co-desenvolvimento, que contribuiria na superao das dificuldades mostradas neste estudo (envolvimento antecipado dos fornecedores, especificaes mais funcionais, etc.) depende diretamente de uma maior integrao estratgica entre a montadora e seus fornecedores. Por outro lado, uma integrao estratgica plena, tal como observado na rede de fornecedores com controle acionrio cruzado da indstria automobilstica japonesa (WOMACK et al, 1992), no diretamente aplicvel realidade ocidental, uma vez que esta estratgia se origina de um ambiente econmico e cultural bem diferente do ocidental. As redes de empresas financeiras (Keiretsu), relacionando os fornecedores com as montadoras japonesas que se associam ou pertencem ao mesmo grupo financeiro (KESSELER, 1997), bem como a gesto dos esforos de desenvolvimento das montadoras e dos fornecedores japoneses pelo Japanese Ministry of Trade and Industry, inexistem na realidade ocidental. Como observado por KESSELER (1997), as empresas financeiramente relacionadas tendem a cooperar mais facilmente durante um desenvolvimento do que empresas totalmente independentes, o que gera uma vantagem competitiva ao modelo oriental no aspecto do co-desenvolvimento. A Toyota, por exemplo, utilizou-se da estratgia da associao de seus fornecedores, estimulando-os a trocarem idias entre si sobre seus projetos, uma vez que no havia competio interna no grupo de fornecedores de primeiro nvel, pois cada um era especializado em um tipo de componente (WOMACK et al, 1992). Sua estratgia no era integrar verticalmente os fornecedores em uma grande burocracia e nem desintegr-los em empresas

100

totalmente independentes. O objetivo era ter os fornecedores de primeiro nvel quase independentes, mantendo parte de seu controle acionrio e possibilitando o compartilhamento de recursos humanos. Consequentemente, tais fornecedores eram empresas com contabilidade autnoma, ou seja, centro de lucros reais, inclusive sendo estimuladas a trabalhar para outras montadoras e outros clientes no mercado, pois estes negcios externos contribuam para a elevao de suas margens de lucro (WOMACK et al, 1992). Um exemplo mais recente desta estratgia foi o projeto do veculo hbrido Toyota Prius, onde a Panasonic EV Energy Co., responsvel por desenvolver e fornecer as baterias de NiMH do veculo, foi fundada em 1996 com 40% de participao de capital da Toyota e seu chefe da diviso de desenvolvimento do carro eltrico, Sr. Yuichi Fujii, foi transferido para a Panasonic Energy, ocupando o cargo de vice-presidente executivo (YAMAGUCHI, 2005). Tais diferenas entre o ambiente ocidental e oriental explicam, em parte, a baixa integrao estratgica em nossa realidade, pois se torna complexo promov-la no modelo sugerido por MERLI (1994), ou seja, ter uma ampla participao do fornecedor no projeto do produto, acordos sobre estratgias e polticas e o gerenciamento comum dos procedimentos de negcios, apenas baseando-se nas relaes de mercado e no desejo de parceria. Neste ponto, cabe uma reflexo quanto a real necessidade da indstria automobilstica ocidental criar um relacionamento mais integrado entre suas montadoras e fornecedores. Ser que o nvel atual de integrao operacional, porm com uma estratgia estabelecida para o codesenvolvimento, como se notou neste estudo, j no adequado ao mercado ocidental ?

Finalmente, pode-se recomendar para futuros trabalhos, um estudo similar a este, ou seja, identificar a estratgia, os processos e as prticas relacionadas com o co-desenvolvimento em outras montadoras, permitindo assim, uma comparao das observaes. Tambm, pode-se sugerir uma investigao quanto s caractersticas de co-desenvolvimento presentes nas relaes entre um grupo de fornecedores (universo do estudo) e seus clientes (montadoras), buscando-se identificar se h integrao estratgica e como esta realizada.

101

RERNCIAS BIBLIOGRFICAS
AIAG AUTOMOTIVE INDUSTRY ACTION GROUP. APQP Advanced Product Quality Planning and Control Plan Reference Manual, 1994.

BEECHAM, M. A.; CORDEY-HAYES, M. Partnering and Knowledge Transfer in the U.K. Motor Industry. Technovation, Vol. 18, No. 3, p.191-205, 1998.

CHUNG, S.; KIM, G. M. Performance Effects of Partnership Between Manufacturers and Suppliers for New Product Development: The Suppliers Standpoint. Research Policy, No. 32, p.587-603, 2003.

CLARK, K. B.; FUJIMOTO, T. Product Development Performance: Strategy, Organization and Management in the World Auto Industry. Boston: Harvard Business School Press, 1991.

CLARK, K. B.; WHEELWRIGHT, S. C. Managing New Product and Process Development: Text and Cases. New York: The Free Press, 1993

CORSWANT, F.; TUNLV, C. Coordinating Customers and Proactive Suppliers: A Case Study of Supplier Collaboration in Product Development. Journal of Engineering and Technology Management, No. 19, p.249-261, 2002.

KAMINSKI, P. C. Desenvolvendo Produto com Planejamento, Criatividade e Qualidade. Rio de Janeiro: LTC Editora, 2000.

KESSELER, A. Evolution of Supplier Relations in European Automotive Industry: Product Development Challenge for a First Tier Supplier. Centre de Recherche en Gestion de lcole Polytechnique.Actes du Gerpisa, No. 19, 1997.

LEVERICK, F.; COOPER, R. Partnerships in the Motor Industry: Opportunities and Risks for Suppliers. Long Range Planning, Vol. 31, No. 1, p.72-81, 1998.

102

MARTINS, P. G.; ALT, P. C. Administrao de Materiais e Recursos Patrimoniais. So Paulo: Ed. Saraiva, 2003.

MERLI, G. Comakership: A nova estratgia para os suprimentos. Rio de Janeiro: Ed. Qualitymark, 1994.

NELLORE, R. Managing Buyer-Supplier Relations: The Winning Edge Through Specification Management. London and New York. Routledge, 2001.

PETERSEN, K. J.; HANDFIELD, R. B.; RAGATZ, G. L. A Model of Supplier Integration into New Product Development. Journal of Product Innovation Management, No. 20, p.284-299, 2003.

REED, E. Supplier Integration: Supplier Overview. Estados Unidos. Fevereiro de 2003. Material de treinamento aos fornecedores sobre a estratgia da montadora em relao integrao com fornecedores (co-desenvolvimento). Classificao: informativa (no confidencial). Disponvel na intranet da empresa. Acesso em: 27 de Janeiro de 2004.

SARKIS, J.; TALLURI, S. A Model for Strategic Supplier Selection. Journal of Supply Chain Management, Vol. 38, No. 1, p.18-38, 2002.

TOLEDO, J.C et al. Modelo de Referncia para Gesto do Processo de Desenvolvimento de Produto: Aplicaes na Indstria Brasileira de Autopeas. 2002. 335p. Relatrio Final de Projeto de Pesquisa Grupo de Estudo e Pesquisa em Qualidade, Departamento de Engenharia de Produo, Universidade Federal de So Carlos. So Carlos, 2002.

WHEELWRIGHT, S. C.; CLARK, K. B. Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency, and Quality. New York: The Free Press, 1992.

103

WOGNUM, P. M.; FISSCHER, O.; WEENINK, S. Balanced relationships: management of client-supplier relationships in product development.

Technovation, Vol. 22, p.341-351, 2002.

WOMACK, J. P.; JONES, D. T.; ROOS, D. A Mquina que Mudou o Mundo. Rio de Janeiro: Ed. Campos, 1992.

WYNSTRA, F.; VAN WEELE, A. J.; WEGGEMANN, M. Managing Supplier Involvement in Product Development: Three Critical Issues. European Management Journal, Vol. 19, No. 2, p.157-167, 2001.

YAMAGUCHI, J. Toyota Prius. Revista Engenharia Automotiva e Aeroespacial, No. 21, p. 14-21, 2005.