MARCIO CARDOSO MACHADO

PRINCPIOS ENXUTOS NO PROCESSO DE

DESENVOLVIMENTO DE PRODUTOS: PROPOSTA DE UMA
METODOLOGIA PARA IMPLEMENTAO

Tese apresentada Escola Politcnica

da Universidade de So Paulo para a
obteno do ttulo de Doutor em
Engenharia.

So Paulo
2006

MARCIO CARDOSO MACHADO

PRINCPIOS ENXUTOS NO PROCESSO DE DESENVOLVIMENTO

DE PRODUTOS: PROPOSTA DE UMA METODOLOGIA PARA
IMPLEMENTAO

Tese apresentada Escola Politcnica

da Universidade de So Paulo para a
obteno do ttulo de Doutor em
Engenharia.
rea de concentrao: Engenharia de
Produo.
Orientador: Prof. Dr. Nilton Nunes
Toledo.

So Paulo
2006

Este exemplar foi revisado e alterado em relao verso

original, sob responsabilidade nica do autor e com a anuncia
de seu orientador.
So Paulo, 26 de abril de 2006.

Assinatura do autor

Assinatura do orientador

FICHA CATALOGRFICA

Machado, Marcio Cardoso

Princpios enxutos no processo de desenvolvimento de produtos: proposta de uma metodologia para implementao / M.C.
Machado. -- So Paulo, 2006. Edio Revisada.
248 p.
Tese (Doutorado) - Escola Politcnica da Universidade de
So Paulo. Departamento de Engenharia de Produo.
1.Desenvolvimento de produtos 2.manufatura enxuta 3.Gesto da qualidade I.Universidade de So Paulo. Escola Politcnica. Departamento de Engenharia de Produo II.t.

 minha esposa Lilian, pelo apoio incondicional

em todos os momentos de minha vida. E a meus
filhos, Adriele, Dnica e Mrcio, razes de todo
meu esforo.

AGRADECIMENTOS
Os agradecimentos so destinados a todos aqueles que de alguma forma
contriburam para o alcance dos objetivos pretendidos por esta pesquisa. Cabe
ressaltar o apoio especial de algumas pessoas que com extrema boa vontade, me
ajudaram a percorrer este caminho.
A Deus, pela sade e paz com que desfrutei toda esta caminhada;
Ao amigo Prof. Dr. Nilton Nunes Toledo, por acreditar em minha proposta de
pesquisa e pela infinita simplicidade na transmisso de seus conhecimentos.
Oferecendo sua disponibilidade para orientao alm dos encontros formais no
Departamento de Engenharia de Produo, sua residncia, centro de convenes, ou
at um mesmo quarto de hospital, foram palcos de demoradas e agradveis conversas
sobre desenvolvimento de produtos;
A todos os integrantes das empresas pesquisadas que disponibilizaram parte
de seu tempo para que este trabalho pudesse ser levado a cabo;
Ao amigo e companheiro de trabalho Ribamar, pelo incomensurvel trabalho
de, ao longo de toda a redao desta tese, revisar os textos e oferecer sugestes que
iam alm de consideraes gramaticais ou ortogrficos;
Ao amigo Alexandre Lima Guerra, capito engenheiro da Fora Area
Brasileira, que, alm do incentivo para a realizao deste doutoramento, contribuiu
com opinies que muitas vezes eram colocadas em forma de bate-papo;
professora Dr Marly Monteiro de Carvalho que, com consideraes na
pr-qualificao e qualificao, auxiliou-me no refinamento do escopo da pesquisa.
Aos professores Drs. Abrahan Yu e Paulo Tromboni que, durante a disciplina
de Seminrios Avanados em Pesquisas de Desenvolvimento de Produtos, na FEA,
fizeram-me compreender a amplitude das reas de pesquisa em desenvolvimento de
produtos; e
A meus pais Mario e Marlene, por terem sempre me conduzido pelo caminho
da virtude e minhas irms Mnica e Mirian, pelo eterno incentivo.

RESUMO
A literatura revela que existe a oportunidade de se estudar formas de
gerenciamento da melhoria de desempenho para desenvolvimento de produtos, sendo
uma destas oportunidades a implementao dos princpios enxutos nesta atividade. O
objetivo geral desta tese foi propor uma metodologia que possibilite, de forma
estruturada, a utilizao dos princpios e prticas enxutas no mtodo de
desenvolvimento de produto. A metodologia apoiou-se no resultado dos seguintes
objetivos especficos: anlise das prticas industriais, verificao de seu alinhamento
com os princpios e prticas enxutas e identificao oportunidades de melhoria;
identificao dos principais modelos existentes para criao de valor em ambientes
outros que no o da manufatura; investigao mecanismos de integrao para a
equipe de desenvolvimento de produtos com base na mentalidade enxuta;
identificao de uma plataforma de gesto que auxilie na implementao dos
princpios enxutos no processo de desenvolvimento de produtos. O mtodo de estudo
de caso foi utilizado em trs empresas A, B e C para coletar informaes a
respeito do processo de desenvolvimento de produtos. Seus resultados permitiram
verificar o alinhamento de cada uma das empresas com as prticas enxutas, e a
conseqente verificao de sua aplicabilidade. As inferncias obtidas foram
classificas em funo dos seguintes aspectos: entendimento da empresa com relao
aos princpios enxutos aplicados ao processo de desenvolvimento de produtos,
identificao de valor, fluxo de valor, sistema puxado e perfeio. Pautada nestas
inferncias, foi elaborada uma proposta de metodologia para implementao de
princpios enxutos no processo de desenvolvimento de produtos visando a
conseqente melhoria do processo. A metodologia proposta foi aplicada a uma
quarta empresa D. Os resultados foram que a metodologia, de forma geral,
mostrou-se consistente com seus objetivos, dentre os quais o principal foi a melhoria
do processo de desenvolvimento de produtos.

ABSTRACT
In the literature, an opportunity appears to study performance improvement
management forms for product development. One of these opportunities is the
implementation of lean principles in this activity. The general objective of the thesis
was to propose a methodology, which enables the utilization of the lean principles
and practices in the product development method in a structured form. The
methodology was based upon the result of the following specific objectives: the
analysis of industrial practices, the verification of their alignment with the lean
principles and practices and the identification of improvement opportunities; the
identification of the main existing models for weighting creation in environments
other than manufacturing; an integration mechanism investigation for the product
development team, based on the lean mentality; and the identification of a
management platform, which helps in the implementation of the lean principles in
the product development process. The case study method was utilized in three
companies A, B and C in order to collect information with respect to the product
development process. The results enabled the verification of the alignment of each
one of the companies as to their lean practices and the consequent verification of
their applicability. The obtained inferences were classified according to the following
aspects: the understanding of the company with regard to the lean principles applied
to the product development process, the weighting identification, importance flow,
in-depth system used and perfection. A methodology proposal was drawn from these
inferences, for the implementation of the lean principles in the product development,
having in mind the consequent process improvement. The proposed methodology
was applied to a fourth company D. The results showed that in a general manner,
the methodology was consistent with its objectives, of which the main one was the
improvement of product development.

SUMRIO
1

INTRODUO ................................................................................................... 1
1.1

MOTIVAO PARA A PESQUISA...................................................................................... 4

1.2

O PROBLEMA DE PESQUISA.............................................................................................. 6

1.3

OBJETIVOS DA PESQUISA ................................................................................................. 8

1.3.1

OBJETIVO GERAL....................................................................................................... 8

1.3.2

OBJETIVOS ESPECFICOS ......................................................................................... 8

1.4

ESCOPO DA PESQUISA ....................................................................................................... 8

1.5

RESULTADOS E CONTRIBUIES ................................................................................. 10

1.6

ORGANIZAO DA TESE ................................................................................................. 11

PROBLEMAS DA INDSTRIA ..................................................................... 13

2.1

2.1.1

A EMPRESA M ........................................................................................................... 14

2.1.2

COMPETNCIA ESSENCIAL E O PROBLEMA ..................................................... 14

2.2

O DESENVOLVIMENTO DE PRODUTO NA XEROX..................................................... 19

2.2.1

PANORAMA DA EMPRESA E SEU PRODUTO ..................................................... 19

2.2.2

O DESENVOLVIMENTO DA IMPRESSORA E COLOCAO DO PROBLEMA.20

PROJETO DA PESQUISA .............................................................................. 24

3.1

O PROCESSO DE PESQUISA ............................................................................................. 26

3.2

REVISO DOS MTODOS DE PESQUISA....................................................................... 28

3.3

MTODOS E PROCEDIMENTOS APLICADOS NA PESQUISA .................................... 32

3.4

A ESTRUTURA DA PESQUISA ......................................................................................... 34

3.4.1

DEFINIO DO PROBLEMA ................................................................................... 35

3.4.2

DETALHAMENTO DA METODOLOGIA DE PESQUISA...................................... 36

3.4.3

CRITRIOS DE SELEO DOS CASOS ................................................................. 38

3.4.4

REVISO DA LITERATURA E DAS PRTICAS INDUSTRIAIS ......................... 40

3.4.5

COLETA E ANLISE DOS DADOS ......................................................................... 40

3.4.6

CONCLUSES, CONTRIBUIES E SUGESTES ............................................... 41

3.5

O DESENVOLVIMENTO DE UM PRODUTO NA EMPRESA M .................................... 13

VALIDADE DOS MTODOS DE PESQUISA APLICADOS ............................................ 42

REVISO TERICA ....................................................................................... 44

4.1

INTRODUO ..................................................................................................................... 44

4.2

DESENVOLVIMENTO DE PRODUTOS............................................................................ 44

4.2.1

A REPRESENTAO POR PROCESSOS NO DESENVOLVIMENTO DE

PRODUTOS................................................................................................................................. 47

4.2.2

DESENVOLVIMENTO

DE

PRODUTOS

REPRESENTADO

COM

ABORDAGEM DE DECOMPOSIO. .................................................................................... 52

4.2.3

A REPRESENTAO DO PDP COM BASE NO FLUXO DO VALOR.................. 56

4.2.4

A IMPORTNCIA DO DESENVOLVIMENTO DO PRODUTO............................. 59

4.2.5

A COMPLEXIDADE E AS TRS DIMENSES DO DESENVOLVIMENTO DO

PRODUTO ................................................................................................................................. 61
4.3

PRINCPIOS E PRTICAS ENXUTAS............................................................................... 64

4.3.1
4.4

O PENSAMENTO ENXUTO ............................................................................................... 67

4.4.1
4.5

A HISTRIA DO TERMO ENXUTO ........................................................................ 64

A DEFINIO DO PENSAMENTO ENXUTO......................................................... 67

OS CINCO PRINCPIOS ENXUTOS................................................................................... 72

4.5.1

O PRINCPIO DO VALOR ......................................................................................... 73

4.5.2

O PRINCPIO DO FLUXO DO VALOR .................................................................... 75

4.5.3

O PRINCPIO DO FLUXO.......................................................................................... 76

4.5.4

O PRINCPIO DO SISTEMA PUXADO .................................................................... 79

4.5.5

O PRINCPIO DA PERFEIO ................................................................................. 80

4.6

OS PRINCPIOS ENXUTOS NO

AMBIENTE

DE DESENVOLVIMENTO

DE

PRODUTOS..................................................................................................................................... 81
4.6.1

O PRINCPIO DO VALOR NO DESENVOLVIMENTO DE PRODUTOS.............. 81

4.6.2

PRINCPIO

DO

FLUXO

DE

VALOR

NO

PROCESSO

DE

DESENVOLVIMENTO DO PRODUTO.................................................................................... 89
4.6.3

PRINCPIO DO FLUXO NO PROCESSO DE DESENVOLVIMENTO DE

PRODUTO ................................................................................................................................. 92
4.6.4

PRINCPIO

DO

SISTEMA PUXADO

NO

DESENVOLVIMENTO

DE

PRODUTOS............................................................................................................................... 107
4.6.5

O PRINCPIO DA PERFEIO NO DESENVOLVIMENTO DE PRODUTO ...... 108

4.7

ENGENHARIA SIMULTNEA ........................................................................................ 109

4.8

ENGENHARIA SIMULTNEA SET-BASED ................................................................... 111

ESTUDOS DE CASO DAS PRTICAS INDUSTRIAIS ............................ 113

5.1

PERFIL DAS EMPRESAS E MTODOS DE COLETA DE DADOS .............................. 113

5.1.1

EMPRESA A.............................................................................................................. 113

5.1.2

EMPRESA B.............................................................................................................. 114

5.1.3

EMPRESA C.............................................................................................................. 114

5.2

RESUMO DAS RESPOSTAS OBTIDAS........................................................................... 115

5.3

RESPOSTAS

DETALHADAS

OBTIDAS

PAUTADAS

NO

FORMULRIO

DE

AVALIAO ................................................................................................................................ 117

5.3.1

O PROCESSO DE DESENVOLVIMENTO DE PRODUTOS FORMALIZADOS E

COMPREENDIDOS.................................................................................................................. 118
5.3.2

ENVOLVIMENTO DE STAKEHOLDERS ............................................................... 123

5.3.3

ELIMINAO DE INTERAES DESNECESSRIAS ....................................... 126

5.3.4

SIMPLIFICAO DO CICLO DE DESENVOLVIMENTO ................................... 131

5.3.5

PRODUTOS E PROCESSOS DESENVOLVIDOS SIMULTANEAMENTE.......... 136

5.4

CONSIDERAES SOBRE AS PRTICAS INDUSTRIAIS .......................................... 139

5.5

QUADRO RESUMO DAS PRINCIPAIS CONCLUSES OBTIDAS NA ANLISE

CRUZADA DOS ESTUDOS DE CASO....................................................................................... 142

BACKGROUND

TERICO

PARA

DESENVOLVIMENTO

DA

METODOLOGIA .................................................................................................. 143

6.1

O MODELO DE TRS FASES PARA CRIAO DE VALOR ....................................... 143

6.1.1

PRESSUPOSTOS ...................................................................................................... 145

6.1.2

IDENTIFICAO DO VALOR................................................................................ 145

6.1.3

PROPOSIO DO VALOR...................................................................................... 146

6.1.4

ENTREGA DO VALOR............................................................................................ 147

6.2

GERENCIAMENTO DE PROJETOS................................................................................. 148

6.2.1

O PROJETO............................................................................................................... 148

6.2.2

AS FUNES DE GERENCIAMENTO .................................................................. 149

6.2.3

GERENCIAMENTO DE PROJETO NO PROCESSO DE DESENVOLVIMENTO DE

PRODUTOS............................................................................................................................... 151
6.3

FERRAMENTAS

PARA

MAPEAMENTO

DO

FLUXO

DO

VALOR

EM

DESENVOLVIMENTO DE PRODUTOS .................................................................................... 154

6.3.1

GRFICO DE GANTT.............................................................................................. 154

6.3.2

MAPA WARD ........................................................................................................... 155

6.3.3

FLUXOGRAMA........................................................................................................ 157

6.3.4

LEARNING TO SEE (APRENDENDO A ENXERGAR) .......................................... 158

6.3.5

DINMICA DE SISTEMAS ..................................................................................... 161

6.3.6

MATRIZ DE ESTRUTURA DE PROJETO (DESIGN STRUCTURE MATRIX DSM)

............................................................................................................................... 162

6.4

MECANISMOS DE INTEGRAO.................................................................................. 163

6.4.1

INTEGRAO DE TIMES DE DESENVOLVIMENTO ........................................ 164

6.4.2

ESTRUTURA DE INTEGRAO ........................................................................... 165

METODOLOGIA

PARA

IMPLEMENTAO

DOS

PRINCPIOS

ENXUTOS NO PROCESSO DE DESENVOLVIMENTO DE PRODUTOS.. 169

7.1

A CONSTRUO DA METODOLOGIA ......................................................................... 169

7.1.1

A IDENTIFICAO DO VALOR............................................................................ 170

7.1.2

A PROPOSIO DO VALOR.................................................................................. 171

7.1.3

A ENTREGA DO VALOR ........................................................................................ 172

7.1.4

IMPLICAES GERENCIAIS................................................................................. 174

7.1.5

MAPEAMENTO DAS FASES DE CRIAO DE VALOR EM RELA-O AOS

PROCESSOS DE GERENCIAMENTO DE PROJETOS ......................................................... 177

7.2

DETALHAMENTO DA METODOLOGIA ....................................................................... 179

7.2.1

PASSO 1 .................................................................................................................... 179

7.2.2

PASSO 2 .................................................................................................................... 183

7.2.3

PASSO 3 .................................................................................................................... 187

7.2.4

PASSO 4 .................................................................................................................... 190

7.2.5

PASSO 5 .................................................................................................................... 191

7.2.6

PASSO 6 .................................................................................................................... 194

7.2.7

PASSO 7 .................................................................................................................... 196

7.2.8

ESFORO PARA A PERFEIO............................................................................ 198

7.2.9

ENCERRAMENTO DA APLICAO DA METODOLOGIA................................ 198

EXEMPLO DE APLICAO DA METODOLOGIA................................ 200

8.1

LIMITAES PARA APLICAO DA METODOLOGIA............................................. 200

8.2

DESCRIO DA EMPRESA D......................................................................................... 203

8.3

APLICAO DA METODOLOGIA PROPOSTA ............................................................ 204

8.4

AVALIAO DA METODOLOGIA PROPOSTA ........................................................... 217

CONCLUSES E RECOMENDAES ..................................................... 222

9.1

RESULTADOS, CONTRIBUIES E LIMITAES ..................................................... 224

9.2

RECOMENDAES PARA PESQUISAS FUTURAS ..................................................... 227

ANEXO A ............................................................................................................... 229

ANEXO B................................................................................................................ 236
BIBLIOGRAFIA.................................................................................................... 238

LISTA DE FIGURAS
Figura 1.1 Fases do ciclo de desenvolvimento do produto ....................................... 2
Figura 2.1 A comunicao entre a Empresa M e seu principal stakeholder. ......... 15
Figura 2.2 Diferenas entre as fendas dos parafusos Philips e Crosspoint............. 16
Figura 2.3 Porca autofreno com fixao por meio de rebites de uso comum na
indstria aeronutica. ................................................................................................. 17
Figura 2.4 Comparao entre um processo gerenciado e outro com falha de
gerenciamento ............................................................................................................ 18
Figura 2.5 Impressora profissional Docuprint 4025 ............................................... 19
Figura 2.6 Processo de desenvolvimento de produtos da Xerox centrado no time
TTM ........................................................................................................................... 21
Figura 3.1 Etapas do Projeto de Pesquisa ............................................................... 27
Figura 3.2 Passos da pesquisa, seguidos nesta tese................................................. 34
Figura 3.3 Estrutura para a pesquisa com estudo de casos mltiplos, aplicada na
primeira rodada de estudos de campo com as empresa A, B e C.............................. 39
Figura 4.1 Digrama de fluxo de sete estgios para o ciclo de desenvolvimento de
produto ....................................................................................................................... 48
Figura 4.2 O ciclo de desenvolvimento de produto ................................................ 49
Figura 4.3 As atividades de front-end englobando a fase de desenvolvimento do
conceito ...................................................................................................................... 50
Figura 4.4 Estrutura genrica para decomposio de um sistema de manufatura .. 52
Figura 4.5 Decomposio do Projeto de Desenvolvimento de Produtos PD3..... 53
Figura 4.6 Decomposio do Projeto do Sistema de Desenvolvimento de Produtos
.................................................................................................................................... 55
Figura 4.7 Representao do DP, com base no fluxo do valor .............................. 57

Figura 4.8 Incerteza nas medies de performance tcnicas no ciclo do produto .. 60

Figura 4.9 Gerenciando a criao de valor no desenvolvimento de produto .......... 62
Figura 4.10 Relao de valor para o cliente............................................................ 82
Figura 4.11 Relao de valor para o cliente com o atributo tempo......................... 82
Figura 4.12 Relao de valor para o cliente com o atributo custo expandido ........ 83
Figura 4.13 Relaes de valor para o empregado ................................................... 86
Figura 4.14 Modelo para integrao de mltiplas perspectivas de valor................ 88
Figura 4.15 Relao entre Fluxo de Valor, Valor e Produto................................... 91
Figura 4.16 Conceito de fluxo em desenvolvimento de produto ............................ 92
Figura 5.1 Macrofluxo do PDP da empresa A. ..................................................... 119
Figura 5.2 Representao do DIP da Empresa A.................................................. 120
Figura 5.3 Representao do PDP da Empresa B. ................................................ 121
Figura 5.4 PDP da Empresa B, excluindo as atividades administrativas.............. 122
Quadro 5.5 Macroprocesso do Ciclo de DP da Empresa B. ................................. 130
Figura 5.6 Representao do Ncleo Tcnico de Produto com seu engenheiro chefe
e respectivos gerentes de desenvolvimento de produto ........................................... 134
Figura 5.7 Representao simplificada da estrutura matricial para integrao dos
diferentes times de desenvolvimento. ...................................................................... 138
Figura 5.8 Grau de alinhamento das empresas A, B e C com os princpios e prticas
enxutas...................................................................................................................... 141
Figura 6.1 Modelo para criao ciclo do valor ..................................................... 144
Figura 6.2 Ligaes entre os grupos de processos ................................................ 152
Figura 6.3 Sobreposio dos grupos de processos ................................................ 153
Figura 6.4 Exemplo de Grfico de Gantt .............................................................. 154
Figura 6.5 Exemplo de Mapa Ward de Fluxo de Valor ........................................ 155

Figura 6.6 Exemplo de simbologia utilizada em fluxogramas.............................. 157

Figura 6.7 Exemplo de mapa de fluxo do valor Learnig to See............................ 159
Figura 6.8 Exemplo de mapa de dinmica de sistema. ......................................... 161
Figura 6.9 Exemplo de uma Matriz de Estrutura de Projeto................................. 163
Figura 6.10 Os trs nveis de integrao ............................................................... 166
Figura 6.11 Exemplo de composio de Time de Sistema ................................... 167
Figura 7.1 A criao de valor como um processo interativo e adaptativo ............ 170
Figura 7.2 O modelo de trs fases e o princpio do valor. .................................... 171
Figura 7.3 O modelo de trs fases e o princpio do valor e do fluxo do valor. ..... 172
Figura 7.4 O modelo de trs fases e os princpios: do valor, do fluxo do valor, do
fluxo e do sistema puxado........................................................................................ 173
Figura 7.5 O modelo de trs fases e os cinco princpios enxutos. ........................ 173
Figura 7.6 O esforo gerencial nas fases iniciais do ciclo de DP ......................... 174
Figura 7.7 Representao da necessidade de uma ferramenta de gesto para
implementao dos princpios enxutos no PDP....................................................... 175
Figura 7.8 Estrutura da metodologia proposta. ..................................................... 178
Figura 8.1 Tipos primrios de projeto de desenvolvimento.................................. 201
Figura 8.2 Regio de aplicao da metodologia proposta..................................... 202
Figura 8.3 Matriz de responsabilidade para aplicao da metodologia proposta. 205
Figura 8.4 A definio dos stakeholders pelo departamento de Desenvolvimento de
Produtos DP, antes e depois da aplicao da metodologia. .................................. 207
Figura 8.5: Esquema bsico do processo de melhoria ............................................. 209
Figura 8.6: A representao do PDP da empresa D antes da melhoria.................... 211
Figura 8.7: A representao do PDP da empresa D depois da melhoria.................. 212

LISTA DE TABELAS E QUADROS

Tabela 3.1 Caractersticas dos mtodos de pesquisa quantitativo e qualitativo...... 30
Tabela 3.2 Distino das caractersticas dos projetos qualitativos de pesquisa...... 31
Tabela 3.3 Alinhamento do propsito da pesquisa com a metodologia.................. 37
Tabela 4.1 Atividades funcionais sob a tica da integrao interfuncional............ 51
Tabela 4.2 Correlao entre as tcnicas de fluxo na manufatura e o
desenvolvimento de produtos................................................................................... 100
Tabela 4.3. Correlao entre categorias de desperdcios e tcnicas de fluxo. ......... 106
Tabela 4.4 - Comparao entre a aplicao dos princpios enxutos no ambiente de
manufatura e no desenvolvimento de produtos........................................................ 108
Tabela 4.5 Abordagens de Engenharia Simultnea e Princpios enxutos ............. 111
Quadro 5.1 Sumrio das questes relativas formalizao e compreenso do
processo de desenvolvimento de produtos, nas empresas A, B e C......................... 119
Quadro 5.2 Sumrio das questes relativas ao envolvimento dos stakeholders no
processo de desenvolvimento de produtos, nas empresas A, B e C......................... 123
Quadro 5.3 Sumrio das questes relativas ao fluxo de informaes no processo de
desenvolvimento de produtos, nas empresas A, B e C. ........................................... 127
Quadro 5.4 Sumrio das questes relativas simplificao do ciclo de
desenvolvimento de produtos, nas empresas A, B e C. ........................................... 132
Quadro 5.5 Sumrio das questes relativas ao desenvolvimento integrado de
produtos e processos, nas empresas A, B e C. ......................................................... 137
Quadro 5.6 Quadro resumo das principais concluses obtidas na anlise cruzada
dos estudos de caso. ................................................................................................. 142
Tabela 6.1 Categorizao de desperdcios ............................................................ 156
Tabela 6.2 Exemplos de mtricas em manufatura ................................................ 160
Quadro 7.1 Etapas do primeiro passo. .................................................................. 179

Quadro 7.2 Etapas do segundo passo.................................................................... 183

Quadro 7.3 Etapas do terceiro passo. .................................................................... 188
Quadro 7.4 Etapas do quarto passo. ...................................................................... 190
Quadro 7.5 Etapas do quinto passo. ...................................................................... 192
Quadro 7.6 Etapas do sexto passo......................................................................... 194
Quadro 7.7 Etapas do stimo passo....................................................................... 196
Quadro 8.1 As diferentes perspectivas de valor para cada um dos stakeholders.. 208
Quadro 8.2: Questes relacionadas com a avaliao da metodologia proposta....... 218

LISTA DE ABREVIATURAS
ACV Atividades que criam valor.
ANCV Atividades que no Criam Valor.
ANNCV Atividades Necessrias que No criam Valor.
AFV Anlise do Fluxo de Valor.
ATP Avaliao Tcnica de Performance.
BSC Balanced Scorecard.
CAD Computer Aided Design.
CAE Computer Aided Engineering.
CAM Computer Aided Machining.
CATIA Computer Aided Tri-dimensional Integrative Application.
CIM Computer Integrated Machining.
CPM Critical Path Method.
DIP Desenvolvimento Integrado de Produto.
DP Desenvolvimento de Produtos.
ET Especificao Tcnica.
EUA Estados Unidos da Amrica.
FAA Federal Aviation Administration.
FMIT Fabricao, Montagem, Integrao e Teste.
GDP Grupo de Desenvolvimento de Produtos.
IEEE - Institute of Electrical and Electronics Engineers.
JAA Joint Aviation Administration.
JIT Just-in-Time.
LAI Lean Aerospace Initiative.
LESAT Lean Self Assessment.
LTS Learning to See.
MFV Mapeamento do Fluxo de Valor.
MEP Matriz de Estrutura de Projeto.
MIT Massachusetts Institute of Technology.
NASA National Aeronautics and Space Administration.

PD3 - Product Development Design Decomposition.

PDMA Product Development Management Association.
PDP Processo de Desenvolvimento de Produtos.
PERT Program Evaluation and Review Technique.
Phd Philosophy Doctor.
PMI Project Management /institute.
PP Parmetro de Projeto.
RF Requisito Funcional.
ROI Return of Investment.
SGQ Sistema de Gesto da Qualidade.
STP Sistema Toyota de Produo.
TQM Total Quality Management.
TTM Time to Market.
VEA Valor Econmico Agregado.

INTRODUO
No gerenciamento de empresas, as mudanas ocorrem nos mais variados

setores, e surgem da necessidade dessas empresas acompanharem as instabilidades

provocadas pela acirrada concorrncia no mundo empresarial. Por decorrncia, se o
ambiente fosse estvel, no haveria necessidade de alteraes nas operaes e nem
nas atividades dos negcios.
Assim, tanto o ambiente interno quanto o externo constituem variveis
permanentes que influenciam o desenvolvimento das empresas ao longo do tempo.
Em resposta a esta atuao, o gerenciamento das operaes deve tambm se alterar, a
fim de que os objetivos e a lucratividade possam ser mantidos, mesmo em face de
mudanas situacionais enfrentadas pelas organizaes.
Neste ambiente intenso e dinmico, o desenvolvimento de novos produtos e
processos crescentemente tm se tornado o principal foco de competio
(Wheelwright e Clark, 1992). Esta nova competio industrial fortemente focada no
desenvolvimento de produto est sendo dirigida por foras que, nas ltimas dcadas,
tm surgido em muitas indstrias ao redor do mundo, sendo elas: o aparecimento de
uma intensa competio internacional, a criao de mercados segmentados com
consumidores sofisticados e as evolues tecnolgicas (Clark e Fujimoto, 1991).
O desenvolvimento do produto corresponde a uma srie de atividades
organizadas com o objetivo de transformar um conceito de produto em um produto
acabado tangvel que comea com a percepo de uma oportunidade de mercado e
termina com a produo, venda e entrega do produto (Ulrich e Eppinger, 2000).
Atividades de projeto do produto, projeto do processo e projeto do sistema de
manufatura so essenciais ao desenvolvimento do produto (Kim et.al., 2000). Estas
atividades afetam de forma significante o sucesso de um novo projeto de
desenvolvimento do produto que, eventualmente, molda a prosperidade de uma
empresa de manufatura.

Dentre as atividades essenciais, o projeto do produto tem sido reconhecido

como a que deve acontecer primeiro, seguida pela atividade de projeto do processo e,
finalmente, pela atividade de projeto do sistema de manufatura. Esta portanto a
seqncia natural da realizao de um conceito de produto em um produto acabado.
Segundo Ulrich e Eppinger (2000), o processo de desenvolvimento de
produto depende no s do produto que ser realizado, mas tambm da organizao
para este fim. Embora os processos de desenvolvimento tenham caractersticas que
os tornem particulares e os identifiquem dentre outros esforos de desenvolvimento,
as fases de qualquer processo de desenvolvimento podem ser categorizadas em uma
seqncia genrica para que sejam aplicadas nos mais diversos sistemas e
organizaes. Stanke (2001), cita que as fases do ciclo de vida do produto podem ser
identificadas na Figura 1.1.
Desenvolvimento do
conceito

Definio do
programa

Projeto
detalhado

Avaliao e
testes

Produo

Suporte e
operao

Disponibilidade

Ciclo de Desenvolvimento do Produto.

Figura 1.1 Fases do ciclo de desenvolvimento do produto

Fonte: Stanke (2001)
As sete fases do ciclo de desenvolvimento, de forma simplificada, so
seqenciais e, portanto, seguem uma ordem que comea com desenvolvimento do
conceito e termina com a disponibilidade do produto para o mercado. Mas, no
decorrer deste estudo, pode ser visto que isto no exclui a possibilidade de
simultaneidade entre as fases. Como exemplo, as fases podem se sobrepor de tal
forma que uma comece antes que a anterior tenha sido completamente terminada.
Destas fases, vrias pertencem especificamente ao processo de desenvolvimento do
produto. Assim, uma lista descritiva de alguns elementos representativos de cada fase
apresentada:

Desenvolvimento do conceito arquitetura de sistema, projeto

avanado, pesquisa de mercado, identificao das necessidades dos

usurios, desenvolvimento de tecnologia, estudos de viabilidade,

prottipos experimentais (tambm chamados de pr-prottipos por
Toledo (1994)),

Definio do Programa anlise econmica, identificao do usurio

final e/ou cliente, seleo de fornecedor, anlise de deciso entre
fabricar ou comprar, identificao dos principais marcos no processo,
alocao de recursos;

Projeto detalhado especificao do sistema, seleo de material,

identificao de tolerncias, definio do processo de produo,
projeto de ferramenta, teste de produo;

Avaliao e Testes teste de confiabilidade, vida e desempenho,

aprovao por organismos reguladores;

Produo operao do sistema de produo, aquisio dos

componentes/materiais;

Suporte e operao operao de campo, suporte (em servio),

sistemas de atualizao;

Disponibilidade consideraes do fim da vida incluindo a venda.

Das sete fases do ciclo de desenvolvimento, as quatro primeiras

Desenvolvimento do Conceito, Definio de Programa, Projeto Detalhado, e
Avaliao e Testes consistem no processo de desenvolvimento do produto. Em
muitos casos, o desenvolvimento do produto envolve mltiplos interessados
(stakeholders1) em cada fase do desenvolvimento. Conforme a complexidade do
sistema aumenta, mais stakeholders acabam se envolvendo, e o esforo para
gerenciar a organizao cresce (Stanke, 2001).

Considera-se um stakeholder todo grupo ou indivduo que afeta ou afetado pelo alcance dos
objetivos organizacionais. (Freeman R. E., 1984, apud Stanke, 2001).

No entanto esse esforo para o gerenciamento das diferentes necessidades dos

stakeholders e do respectivo valor2 que cada um dos evolvidos percebe na realizao
do produto implica na utilizao de uma abordagem que mantenha ou aumente o
desempenho do sistema de desenvolvimento do produto e, ao mesmo, tempo crie
valor de forma consistente para todos os envolvidos. Neste sentido, pesquisas tm
sido realizadas por vrios tericos (Browning, 1996; Chase, 2001; Douglas III, 2002;
McManus e Millard, 2002; Stanke, 2001; Slack, 1998; Bauch, 2004).
Conforme citam Stanke e Murman (2002),os conceitos bsicos da manufatura
enxuta, como por exemplo o foco nas atividades e processos que agregam valor e
conseqentemente reduzem o trabalho nas atividades que no agregam valor, tm se
expandido para patamares alm do cho de fbrica. Em um sentido mais amplo, os
conceitos enxutos so aplicveis no contexto empresarial.

1.1

MOTIVAO PARA A PESQUISA

Para Ulrich (2001), o interesse acadmico em projeto e desenvolvimento tem

aumentado substancialmente, pelo menos, na ltima dcada; o que era uma rea
isolada de investigao dentro dos departamentos de marketing e alguns
departamentos de engenharia tornou-se um campo de reconhecida ateno,
envolvendo pesquisadores dos departamentos de engenharia, de marketing,

de

projeto industrial, gerenciamento de operaes, de contabilidade e de estratgia,

dentre outros.
Assim, um dos direcionadores do interesse acadmico para o projeto e seu
desenvolvimento so desafios que se encontram face s prticas industriais. As
empresas acabam confrontando-se com uma ou mais das seguintes tendncias:

O aparecimento de produtos nos mais diferentes mercados est

aumentando, de forma que mais produtos esto sendo dirigidos a
segmentos de mercados cada vez menores;

Valor, para o contexto deste trabalho, ser detalhado no captulo 4.

A freqncia na introduo de produtos tem aumentado de forma

acelerada em muitos mercados;

Os lead times para desenvolvimento de produtos esto sendo

comprimidos;

Os produtos tm ciclo de vida cada vez menores no mercado;

A complexidade dos produtos tem aumentado;

Atividades de desenvolvimento de produtos e de produo so com

freqncia distribudas entre empresas, em lugar de uma nica firma
realiz-las de forma integrada (Ulrich, 2001).

Em face dos fatores, mercado segmentado, redues do tempo de ciclo, e

produtos mais complexos, surge a oportunidade de se estudar formas de
gerenciamento da melhoria de desempenho para desenvolvimento de produtos, e uma
destas oportunidades a implementao de princpios enxutos nesta atividade.
Neste sentido, muitos estudos tm sido realizados de forma a expandir a
aplicao dos princpios enxutos para contextos outros, que no os da manufatura.
Dentre esses contextos est o de desenvolvimento de produtos.
O primeiro princpio enxuto a especificao de valor; no entanto, no
processo de desenvolvimento de produtos o valor difcil de ser entendido. A
complexidade do processo, a distncia do consumidor final, a alternncia das
condies de mercado, o aparecimento de novas tecnologias e as incertezas de
performance tcnica, custo e programao tornam a definio de valor baseada nas
necessidades dos clientes uma tarefa de difcil execuo.
Trabalhos anteriores como os de Stanke (2001); Chase (2001) oferecem
modelos para a representao dessas complexidades, porm nota-se a ausncia de um
mtodo que de forma planejada e controlada, conduza o processo de
desenvolvimento de produtos a um estado considerado enxuto.
No que tange ao gerenciamento de um projeto de desenvolvimento, segundo
Krishnan e Ulrich (2001), as decises so tomadas com base nas prioridades relativas
dos objetivos de desenvolvimento, nas seqncias de tempos planejados das

atividades de desenvolvimento, nos principais marcos e prottipos de projeto, nos

mecanismos para coordenao entre os membros das equipes e nos meios de
monitoramento e controle de projeto.
No desenvolvimento de produtos, o desempenho , normalmente, medido
pelo tempo de desenvolvimento do produto, pelo custo do desenvolvimento, pelo
custo de manufatura e pela qualidade do produto ou pela sua atratividade no mercado
(Clark e Fujimoto, 1991; Griffin 1997).
Tcnicas formais de planejamento de projeto tais como: PERT e CPM so
amplamente utilizadas na indstria de construo, no planejamento de durao e
seqncia das atividades. Entretanto, o processo de desenvolvimento de produtos no
to facilmente modelado com estas tcnicas (Eppinger et. al., 1994).
At aqui, pode-se perceber que existem trabalhos cientficos relacionados
tanto com a rea de desenvolvimento de produtos como com os princpios e prticas
enxutas. Alguns poucos trabalhos relacionam-se com a modelagem da criao de
valor no processo de desenvolvimento de produtos. Percebe-se, porm, a ausncia
uma abordagem metodolgica que consiga transferir os benefcios do uso de
princpios e prticas enxutas para o ambiente especfico de desenvolvimento de
produtos.
No segundo captulo desta tese,

so descritos dois tipos de problemas

industriais originados pela falta da correta identificao do valor ou da identificao

do valor em momentos tardios, assim como pela dificuldade em fazer com que o
valor flua no processo de desenvolvimento de produto. Estes problemas reforaro o
problema de pesquisa, na medida que se poder observar na prtica, o que ocorre
quando as expectativas e necessidades dos interessados so consideradas de forma
incompleta ou, at mesmo, no sejam consideradas.

1.2

O PROBLEMA DE PESQUISA
Como foi discutido na seo anterior, existe um leque de pesquisas

relacionadas, tanto com o desenvolvimento de produtos como com a aplicabilidade

de princpios e prticas enxutas em ambientes diferentes da manufatura. Contudo,

no foram verificados estudos que identificassem como se pode utilizar uma
mentalidade enxuta nos ambiente externos manufatura, mais especificamente,
como se pode utilizar a mentalidade enxuta no processo de desenvolvimento de
produtos. Esta necessidade pode ser transformada nos seguintes problemas de
pesquisa:
(1)

Como os conceitos enxutos relacionam-se com o processo de

desenvolvimento de produtos?

(2)

Como possvel, sistematicamente, implementar esses conceitos?

Os problemas de pesquisa principais so muito genricos, o que impe

alguma dificuldade no sentido de solucion-los. Assim, sero subdivididos em outros
problemas que possam ser mais facilmente trabalhados e resolvidos. Desta forma,
podem ser identificar os seguintes subproblemas:
a- Como representar o processo de desenvolvimento de produtos?
b- Como entender os conceitos e princpios enxutos e de que forma
esto sendo aplicados em ambientes diferentes da manufatura?
c- Quais os principais modelos existentes na literatura para a criao
de valor no processo de desenvolvimento de produto?
d- Como uma nova estrutura gerencial pode ser utilizada para
introduzir os modelos existentes para criar valor no processo de
desenvolvimento de produtos?
A inteno que, por meio das investigaes para os subproblemas, ser
possvel solucionar o objetivo principal desta tese. Assim, captulos especficos
detalharo cada investigao aos subproblemas. O captulo 3 trata da metodologia de
pesquisa e discute de modo detalhado os problemas propostos e suas tentativas de
soluo.

1.3

1.3.1

OBJETIVOS DA PESQUISA

OBJETIVO GERAL
O objetivo geral desta tese , portanto, propor uma metodologia que

possibilite, de forma estruturada, o emprego de princpios e prticas enxutas no

mtodo de desenvolvimento de produto. A metodologia proposta ir apoiar-se no
resultado dos seguintes objetivos especficos:

1.3.2

OBJETIVOS ESPECFICOS
-

Analisar prticas industriais, verificar seu alinhamento com os

princpios e prticas enxutas e identificar oportunidades de melhoria;

Identificar os principais modelos existentes para criao de valor em

ambientes outros que no o da manufatura;

Investigar

mecanismos

de

integrao

para

equipe

de

desenvolvimento de produtos, como base na mentalidade enxuta;

-

Identificar uma plataforma de gesto que auxilie na implementao

dos princpios enxutos no processo de desenvolvimento de produtos;

1.4

ESCOPO DA PESQUISA
O objetivo desta pesquisa compreender o fenmeno da criao de valor no

ambiente de desenvolvimento de produtos e produzir uma metodologia que permita

s equipes a implementao dos princpios e prticas enxutos no processo de
desenvolvimento de produtos.
Desta forma, importante definir a atividade de desenvolvimento com base
no escopo desta tese:

1. Desenvolvimento de Produtos: conjunto de tarefas, desde a definio

do conceito at a validao do produto.
2. Processos

de

desenvolvimento

de

produtos:

realizao

do

desenvolvimento do produtos de forma a criar valor medida que

elimina desperdcios.
3. Resultado do Desenvolvimento de Produto: uma definio de produto
que permita a criao de valor desejado aos interessados
(stakeholders).
A fim de alcanar o objetivo proposto, e pautado nos objetivos especficos da
tese, um modelo para criao de valor utilizado como referncia. Este modelo
proposto por Lean Aerospace Initiative (LAI)3 pode ser dividido em trs etapas:

Etapa I Identificao do Valor4;

Etapa II Proposio do Valor;

Etapa III Entrega do Valor.

Os conceitos enxutos clssicos apresentados por Womack at. al. (1996)

incluem a identificao do valor para o cliente. Contudo, muitas das implementaes
dos princpios e prticas enxutas tm sido focadas apenas na terceira etapa do modelo
proposto pelo LAI e esto centradas na eliminao de desperdcios. Esforos deste
tipo so empreendidos no sentido de fazer certo as coisas

e podem servir ao

consumidor, porm ignoram outros stakeholders importantes para o desenvolvimento

do produto. O foco na fase da identificao do valor , portanto, imperativo para se
fazer certo as coisas ( Murman et. al., 2002 ).
O modelo de trs fases proposto tem sido utilizado nas pesquisas do Lean
Aerospace Initiative (LAI) para a anlise das descobertas relacionadas com o que se
pode chamar de Best Lifecicle Value6, com excelentes resultados (Murmane et. al.,
3

O Lean Aerospace Initiative (LAI) foi criado em 1993 e um consrcio entre a indstria, governo e
academia cujo objetivo auxiliar na transformao da indstria aeroespacial dos E.U.A.
4
Valor neste contexto pode ser entendido como a capacidade de produto ou servio em atender os
requisitos utilidade e custo, definidos pelo cliente (Slack, 1998).
5
Este conceito pode ser mais bem entendido em Murman et. al. (2002).
6
Ver Stanke (2001), que fez um extenso trabalho sobre a aplicao do modelo.

10

2002). Desta forma, o escopo deste trabalho no inclui a validao do modelo de trs
fases e, sim, a forma pela qual o modelo pode contribuir com a metodologia
proposta.

1.5

RESULTADOS E CONTRIBUIES
Nesta pesquisa, os resultados esperados podem ser classificados em duas

categorias: a primeira compe-se das concluses e inferncias originadas da

comparao entre a literatura pesquisada e as informaes e dados colhidos durante a
investigao das prticas industriais. Estas concluses relacionam-se com as
oportunidades de melhoria no projeto de desenvolvimento com base no emprego de
princpios e prticas enxutas. A segunda constitui-se no desenvolvimento de uma
estrutura que possibilite a aplicao dos insights, resultantes das inferncias obtidas
durante a primeira parte dos resultados.
Segundo Millard (2001), o time de pesquisa em desenvolvimento de produto
do Lean Aerospace Initiative (LAI) tem observado que vrias questes relacionadas
com a aplicao de princpios enxutos no desenvolvimento de produtos no esto
respondidas. Existem vrios gaps7 no que se refere ao conhecimento j produzido
sobre como o conceito enxuto pode ser utilizado nas atividades de engenharia.
Assim, as principais contribuies desta pesquisa para os estudos a respeitodo
gerenciamento do projeto de desenvolvimento so as seguintes:

Definio de uma viso integrada do projeto de desenvolvimento de

produtos, levando em conta as etapas de identificao de valor,
proposio do valor e entrega do valor. Isto se mostrou necessrio
visto que os esforos das pesquisas atuais tm contemplado sobretudo
a ltima etapa entrega de valor (Bauch, 2004; Browning, 1998;
McManus e Millard 2002; McNutt, 1998);

Ampliao do modelo de trs fases, para a incluso de uma fase inicial

de preparao, na qual so ajustadas as prioridades relativas dos

Gap para o contexto desta tese, refere-se s lacunas existentes nas pesquisas anteriormente realizadas
e que podem representar oportunidades para o desenvolvimento de novas pesquisas.

11

objetivos de desenvolvimento com base na criao de valor. Esta

alterao importante por dois motivos: primeiro, para incluir as
necessidades especficas das organizaes no que se refere ao
entendimento da mentalidade enxuta; segundo, porque a criao de
valor no processo de desenvolvimento de produtos s possvel
quando existe um acordo mtuo (tcito ou explcito) entre os
principais stakeholders (Murman et. al., 2002);

Identificao de uma seqncia para a implementao dos princpios

enxutos no processo de desenvolvimento de produtos, pois o modelo
de trs fases para a criao de valor cujo objetivo principal
oferecer uma representao simplificada da realidade um modelo
genrico de aplicao ampla nos mais diversos nveis organizacionais,
assim como no ciclo de desenvolvimento, como um todo (Stanke,
2001).

Desenvolvimento de uma estrutura metodolgica que auxilie a tomada

de deciso no projeto do processo de desenvolvimento. Esta estrutura
permitir que sejam definidas, com orientao para a criao de valor,
questes relacionadas com: tipo do desenvolvimento (ex.: stagegates); seqncia de atividades; planejamento de prottipos;
mecanismos de comunicao entre os membros das equipes de
desenvolvimento, e projetos de monitorao e controle.

1.6

ORGANIZAO DA TESE
Este estudo compreende oito captulos. No primeiro captulo, realizada a

introduo da pesquisa e em seu decorrer apresentada a motivao para a pesquisa

com uma clara proposio dos problemas.
O segundo captulo, enfatiza o problema proposto por esta tese por meio da
apresentao de dois exemplos da indstria que esto relacionados com problemas
encontrados no processo de desenvolvimento de produtos e que, de alguma forma,
poderiam ser resolvidos com a implementao dos princpios e prticas enxutas.

12

O terceiro captulo, procura descrever a metodologia de pesquisa adotada.

Para isto, feita uma breve reviso terica das metodologias existentes, e baseada
nelas apresentada a metodologia proposta.
O quarto captulo, oferece uma reviso da literatura que foi dividida nas
seguintes sees: desenvolvimento do produto, princpios e prticas enxutas e, em
face da escassez de material especfico sobre o assunto, apresentada uma breve
reviso dos autores que tratam dos princpios enxutos relacionados ao processo de
desenvolvimento de produtos.
O quinto captulo, faz uma reviso das prticas industriais relacionadas com a
criao de valor no processo de desenvolvimento de produtos. Para isto, utiliza um
formulrio para avaliao do alinhamento do processo de desenvolvimento de
produtos da empresa pesquisada com os princpios e prticas enxutos (Anexo A) em
trs empresas, com diferentes caractersticas.
O sexto captulo, oferece um background terico para elaborao da
metodologia. Neste backgound, constam uma reviso do modelo de trs fases, a
abordagem de gerenciamento de projetos e as ferramentas de integrao e de
mapeamento e anlise do fluxo de valor.
O stimo captulo, o principal da tese, pois dedicado a apresentao da
metodologia para a implementao dos princpios e prticas enxutas no processo de
desenvolvimento de produtos.
No oitavo captulo, descreve-se um exemplo de aplicao da metologia, com
as principais inferncias e concluses, assim como as limitaes para sua aplicao.
O nono captulo, destinado s consideraes, concluses e recomendaes.

13

PROBLEMAS DA INDSTRIA
Neste captulo, so apresentados dois exemplos do que pode acontecer se

durante o processo de desenvolvimento de produto a identificao das necessidades

dos principais stakeholders no for realizada o mais cedo possvel no processo. E
tambm, o que pode acontecer se as necessidades, corretamente identificadas no
incio do processo de desenvolvimento, no forem preservadas durante a realizao
do desenvolvimento. Os casos aqui apresentados, portanto, no pretendem oferecer
exemplos de engenharia simultnea, cujas decises sobre o congelamento das
especificaes foram feitas em momentos inoportunos; ao contrrio, revelam como a
falta da identificao e entrega de valor podem afetar profundamente o esforo
empreendido no processo de desenvolvimento. O primeiro caso mostra o esforo de
uma empresa para corrigir um erro no desenvolvimento de um acessrio para um
avio de emprego militar. O segundo revela como a Xerox Company conseguiu
reduzir pela metade o tempo de desenvolvimento de uma copiadora profissional,
sobretudo com o uso de times multifuncionais e quais os problemas advindos desse
esforo. Este captulo complementa o captulo 1, no sentido de destacar o problema
de pesquisa por meio de casos obtidos na indstria.

2.1

O DESENVOLVIMENTO DE UM PRODUTO NA EMPRESA M

Aqui apresentado o problema enfrentado pela empresa M durante o

desenvolvimento de uma pea para a indstria aeronutica militar, especialmente

durante a etapa de testes e homologao. O problema ocorreu pela falta de
comunicao entre a empresa M e os principais stakeholders. O presente caso foi
obtido por meio de uma investigao exploratria preliminar.

14

2.1.1

A EMPRESA M
A empresa M uma das principais do setor de desenvolvimento de

equipamentos de alta tecnologia para a indstria aeronutica e de defesa, dentre

outras. Parceira da principal indstria de avies do Brasil, tem sede na cidade de So
Jos dos Campos, So Paulo, principal plo industrial da indstria aeronutica
nacional; sua estrutura organizacional est distribuda nas seguintes reas:
administrativa, de manufatura, de projeto e de engenharia.

2.1.2

COMPETNCIA ESSENCIAL E O PROBLEMA

A principal competncia da empresa M est no desenvolvimento de

equipamento com base tecnolgica para a indstria Militar. Mas, suas atividades de
desenvolvimento no se restringem apenas a esta rea. Com um corpo de
engenheiros de vrias especialidades, a empresa prope-se a investir em outras reas,
tais como: automao industrial e controle de trfego veicular.
Neste caso especfico, a empresa M foi contratada para o desenvolvimento de
um lanador de msseis que seria realizado de forma incremental com base em uma
plataforma de um projeto j existente. A empresa contratante uma organizao
governamental e, por este motivo, tem sua estrutura verticalizada e com alguns
problemas de comunicao entre os departamentos.
A dificuldade de comunicao entre os departamentos internos da empresa
contratante levou a empresa M a estabelecer canais de comunicao paralelos com os
departamentos apresentados na Figura 2.1. As setas com linha contnua representam
os principais canais de comunicao, as linhas tracejadas representam fracos canais
de comunicao. At aqui, talvez no seja o maior problema. A iniciativa de
estabelecer diferentes canais de comunicao para suprir uma deficincia do cliente
pode ser entendida, como um procedimento importante para obteno dos dados
necessrios elaborao do projeto. Entretanto, como se poder ver adiante, o
processo de comunicao para envolvimento do cliente no processo de
desenvolvimento do produto falhou.

15

ORGANIZAO CONTRATANTE
rgos Interessados
Operador

Departamento de Material Blico

Empresa
M

Diretoria de Material
Aeronutico e Blico
Departamento de Engenharia

Departamento de
Manuteno

Figura 2.1 A comunicao entre a Empresa M e seu principal stakeholder.

O projeto de desenvolvimento consistia de uma parte eletrnica e outra

mecnica; seus principais problemas ocorreram na parte mecnica, mais
precisamente na estrutura do equipamento.
Aps a elaborao do projeto e ensaios do prottipo, um lote foi produzido e
entregue ao cliente para que este fizesse vos de experincia. Durante os vos, foram
detectadas algumas panes nos componentes desenvolvidos pela empresa M, o que
causou o primeiro retrabalho no equipamento. Face criticidade do equipamento
para o desempenho e segurana da aeronave, a empresa contratante nomeou uma
comisso para analisar o ocorrido. Como fruto desta anlise, verificaram-se os
seguintes problemas:
a)

determinada parte do reforo estrutural que deveria estar fixada

com rebites slidos, havia sido fixada com parafusos, procedimento
no usual na indstria aeronutica;

b)

a carenagem do equipamento que deveria ter sido fixada com

parafuso crosspoint (ver Figura 2.2) foi fixada com parafuso
philips, o que causa uma srie de problemas: primeiro, os demais

16

parafusos do conjunto maior so de formato crosspoint, padro em

toda a aeronave e isso exigiria que o executante da manuteno
utilizasse diferentes ferramentas para executar a mesma tarefa, o
que reduz a produtividade. Segundo, os parafusos philips, apesar da
semelhana com os parafusos crosspoint originais, no possuam a
mesma resistncia ao torque, o que, por sua vez, causava a
deformao da cabea do parafuso e terceiro, os parafusos
utilizados pela empresa M eram de rosca mtrica, diferentes dos
parafusos do conjunto maior cujas roscas eram do tipo americana,
ou seja, em polegadas.

Parafuso Philips

Parafuso Crosspoint

Figura 2.2 Diferenas entre as fendas dos parafusos Philips e Crosspoint.

c)

as porcas de fixao do parafuso eram fixas e no permitiam a

autofrenagem (Figura 2.3). Mecanismo este que garante o
travamento dos parafusos e impede o desprendimento da carenagem
durante o vo. A utilizao de porcas fixas e sem autofrenagem, de

17

forma semelhante ao parafuso phillips, no usual na indstria

aeronutica.
d)

no havia intercambialidade entre as partes do projeto desenvolvido

pela empresa, os pares eram casados, evitando que os
equipamentos pudessem ser utilizados por diferentes aeronaves.
Isto oferece um alto risco de indisponibilidade do avio, no caso de
uma possvel manuteno do equipamento.

Figura 2.3 Porca autofreno com fixao por meio de rebites de uso comum na
indstria aeronutica.

possvel observar que o gerenciamento do processo de desenvolvimento

falhou ao no identificar logo no incio padres de projeto estabelecidos para a
indstria aeronutica, sobretudo no que tange ao projeto estrutura. Esta falha de
gerenciamento provocou um retrabalho que trouxe grandes problemas empresa
contratante.
Quando o processo est sob controle, as interaes entre as fases tendem a
ocorrer em ciclos curtos, ou seja, com as etapas do processo que esto mais
prximas. Diferente do que ocorre quando o processo no est sob controle cujas
etapas mais a jusante retornam informaes de projeto s etapas que esto no incio
do processo.

18

Na Figura 2.4, pode-se comparar um processo gerenciado com um processo

com falhas de gerenciamento.

Feedback tardio

A
B

Etapas do
Processo

B
C

Fluxo da
informao

Times
Integrados de
Desenvolvimento

C
D

Sequencial
Processo com falha
Gerencial

D
E

E
F

F
Processo Gerenciado

Figura 2.4 Comparao entre um processo gerenciado e outro com falha de

gerenciamento
Fonte: McManus (2002)

19

2.2

O DESENVOLVIMENTO DE PRODUTO NA XEROX

Este caso foi obtido na literatura (Kim et. al, 2000 apud Kim, 2002) e

descreve um problema que um dos times de desenvolvimento da Xerox enfrentou

durante o desenvolvimento de impressoras profissionais, DocuPrint N 4025 (Figura
2.5).

Figura 2.5 Impressora profissional Docuprint 4025

Fonte: Kim (2002)

2.2.1

PANORAMA DA EMPRESA E SEU PRODUTO

A Xerox Corporation uma empresa que oferece solues na rea de

documentao, com o objetivo de aumentar a produtividade nos negcios das

organizaes. Suas atividades englobam: desenvolvimento, manufatura, vendas,
servio e financiamento de produtos e solues no que tange ao processamento de
documentos.
A linha de produtos digitais possui cinco categorias: produtos digitais
multifuncionais (preto e branco), impressoras (preto e branco), copiadoras e

20

impressoras coloridas, impressoras laser e outras. Alm disso, a empresa

comercializa e desenvolve produtos relacionados com envio de documento via
internet e lentes copiadoras. Os produtos Xerox, considerados estado-da-arte,
possuem as seguintes caractersticas: fcil utilizao, confiabilidade, qualidade da
cpia e ergonomia. Outra rea de atuao da empresa a venda de papis para
impresso, equipamentos de fax, scanners, computadores e plotters.
Em fevereiro de 2000, a Xerox introduziu no mercado uma nova srie de
impressoras denominadas DocuPrint N, uma famlia de cinco impressoras laser que
permite a impresso de 20 a 40 pginas por minuto, maior velocidade, melhor
manuseio com o papel e melhor produtividade, alm de mais valor do que as
impressoras de outras marcas (Kim, 2002).

2.2.2

O DESENVOLVIMENTO DA IMPRESSORA E COLOCAO DO

PROBLEMA.
O ramo impressoras profissionais pertence a um segmento maduro de

produtos, o qual possui claramente definidos lderes de mercado como, por exemplo,
a Hewlett-Packard (HP) e Lexmark. E, tambm, outros geis concorrentes, como a
Cnon e Ricoh. Neste mercado, a Xerox est desenvolvendo inovaes incrementais
nos produtos por meio da melhoria dos processos utilizados na cadeia de valor do
desenvolvimento do produto, que necessita de uma transformao organizacional.
Esta uma deciso estratgica tomada pela alta administrao. Acredita-se que por
meio da melhoria nos processos de desenvolvimento de produtos ser possvel obter
maior sucesso no que diz respeito percepo do cliente com relao ao valor
oferecido, o que conseqentemente proporcionaria uma reduo do ciclo de
desenvolvimento do produto e geraria uma maior lucratividade. Isto possvel por
intermdio da adoo de novas curvas tecnolgicas e da inovao incremental nos
atributos do produto que sero resultados da melhoria do processo de seu
desenvolvimento. O desenvolvimento de produtos por parte da concorrncia reduziu
de anos para meses, enquanto a complexidade e a novidade dos produtos tm

21

aumentado a baixos custos unitrios de manufatura. Isto se chama a era do

Faster,Better and Cheaper8.
O processo de desenvolvimento de produto da Xerox chamado processo
Time to Market (TTM). Este processo tem sido bem estabelecido e isto inclui a
formao de um time TTM, o qual rene na empresa os principais stakeholders
quando da definio de um novo conceito. O time liderado por um Gerente de
Produto e constitudo de participantes de vrias reas funcionais (ver figura 2.6).
Custumer (Requiriments and Needs)

Develop Corporate Strategy Vision

Develop Strategy Implementation Plan
Platform Characteristics

1. Develop and Validate

Program Concept.
2. Develop Program
Compliance Plan

Product Family and Products

1. Document Program
Economic Case.
2. Demonstrate Technology
and Value Chain Capability.

1. Def. Newness, Complexity

and Configuration Program
2. Dev. Value Chain and
Channel Plans & Preliminary
Integrated Program Plan

Develop Risk
Management Plan

Seek Approval and

Charter TTM Program
For Approved Program
Phase Gate Review

Compliance Strategy

Define Global Launch

Guidelines and Update
Integrated Program Plan

Value Chain

PRODUCT MANAGER

Channels Strategies
Strategy Implementation

PRODUCT STRATEGY
MANAGER

Plan Economic Case

Risk Assessment

FINANCE
REPRESENTATIVE

MARKETING
MANAGER

Life Cycle Mgmt Plan

DOCUMENTATION
MANAGER

TIME-TO-MARKET
TEAM
FIELD SERVICE
GLOBALIZATION
REPRESENTATIVE

MANAGER

CUSTOMER SUPPORT
MANAGER
EXTERNAL TEST
MANAGER

Secure Approval to Launch

Phase Gate Review

1. Complete Beta Tests

with Customers.
2. Update All Program Plans.

Define Business Case

and Program Time, Cost,
and Quality Metrics.

SYSTEMS ENGINEERING
REPRESENTATIVE

INDUSTRY DESIGN &

HUMAN FACTORS REPRESENTATIVE

LAUNCH
MANAGER

PRODUCT SUPPORT
ENGINEER

HARDWARE MANAGER
SOFTWARE MANAGER
CAE/CAD/CAM/CAT

Seek approval to Exit and

Proceed With Demonstration.
Phase 4
Phase Gate Review

Complete Technology
And Value Chain Readiness
Demonstrations
Seek Approval to Exit
and Proceed With
Design Phase P3.
Phase Gate Review

INTERNAL TEST
MANAGER

Develop, Implement, and

Validate Detailed Design
and Maintain Specifications

MANUFACTURING
MANAGER

Manufacturing
and Production
Implementation

Define
Program Plan

Define
Specifications

Update Business Case and

Program Time, Cost, and
Quality Metrics.

1. Conduct Integration Testing

2. Update global launch
guidelines and integrated
program plan.

Implement and Update

Detailed Program Plans.

Phase Gates - Management Review (Strategic, Schedule, Quality, Risk and Financial

Figura 2.6 Processo de desenvolvimento de produtos da Xerox centrado no time

TTM
Fonte:Kim (2002)
O time rene-se semanalmente durante todo o perodo de desenvolvimento do
produto, ou seja, desde a gerao do conceito at seu lanamento. A formao do
time TTM contribui para o alcance de dois objetivos: permite o envolvimento dos
que participam do processo, tanto a montante quanto a jusante e, portanto, as
decises so tomadas com base em um consenso de todos os stakeholders. Isto
8

Maiores detalhes em Murman et. al. (2002).

22

permite tambm que se desenvolvam processos simultaneamente, no sendo

necessria, desta forma, a espera seqencial entre as funes. O foco do time
estende-se passo a passo ao longo das etapas do processo lgico de desenvolvimento.
A idia central manter todos envolvidos no time TTM a fim de evitar
possveis problemas a jusante causados por decises tomadas a montante. A estrutura
atual est projetada de uma forma que os grupos funcionais conheam claramente o
momento em que lhes ser exigido agregar valor ao processo e tambm quando ir
adiante no sentido de entregar, o que lhes solicitado. Isto torna o processo diferente
da prtica seqencial da indstria. A Xerox espera que mantendo um grande nmero
de pessoas envolvidas com o time TTM, cada departamento funcional esteja bem
informado e, com isto, o custo total do ciclo de vida do produto, assim como o tempo
de desenvolvimento seja minimizado. Como resultado deste esforo, a famlia de
impressoras DocuPrint N4025 foi desenvolvida em oito meses, e o tempo mdio de
desenvolvimento de um produto deste era de, aproximadamente, 16 meses.
Contudo, o rpido desenvolvimento da famlia de produtos DocuPrint N ,
parcialmente, resultado da utilizao de mais homens-hora do que o planejado.
Segundo Kim et. al.(2000) apud Kim (2002), na especificao do projeto, foram
gastas 140% de horas alm do planejado. O time TTM gastou 63% mais homenshora do que havia sido planejado para a validao e 16% mais homens-hora na
integrao e testes. Isto tem origem em vrias causas, mas a principal delas foi a
perda da clara identificao do fluxo da informao entre as reas funcionais e o time
TTM. O fluxo no muito claro de informaes causou uma srie de pontos de
ineficincia. Primeiro, o nmero de representantes no time era maior do que o
necessrio: cerca de 25 durante o desenvolvimento do produto. Este nmero de
envolvidos prejudicou a eficincia das reunies do time e sua desvantagem pode ser
mais significante do que as vantagens advindas das corretas decises de projeto
realizadas em consenso pelo grupo. Mesmo que, segundo Clausing (1994), a
importncia da inundao de informaes para que se tenha certeza de que todas
as informaes estejam disponveis para o projetista do produto, Wheelwright e
Clark (1992) reforam que o desenvolvimento de projetos no necessita de uma

23

profunda integrao interfuncional quando as interfaces entre os departamentos

funcionais esto nitidamente definidas.
Durante o processo de desenvolvimento da impressora DocuPrint N4025,
foram gastos sete dias em cada fase de reviso do projeto. Existiam quatro fases de
reviso e, portanto, cerca de um ms foi gasto com processos de reviso do projeto.
Isto representa um oitavo do tempo total de desenvolvimento; sendo que, do ponto de
vista do consumidor, as revises no necessariamente agregam valor ao produto.
Considerando que, nas reunies, em cada um dos pontos de reviso do projeto, foram
necessrios 25 ou mais representantes, possvel observar uma grande ineficincia
no processo. Parte deste tempo, poderia ser evitada por meio da padronizao da
reviso dos processos, o que pode ser bem compreendido com base na metodologia
proposta nesta tese.
Para eliminar os focos de ineficincia acima mencionados, necessria uma
clara identificao do fluxo da informao entre cada elemento funcional. Isto
possvel por meio do mapeamento do valor no fluxo atual da informao, principal
matria-prima no desenvolvimento de produtos e a conseqente proposio de um
estado futuro para o fluxo de informaes. Como exemplo, pode-se citar que o
mapeamento e a anlise do fluxo de valor poderiam reduzir o nmero de revises de
projeto e, conseqentemente, diminuir o nmero de homens-hora gastos com estas
atividades.

24

PROJETO DA PESQUISA
A importncia do projeto de pesquisa tem sido o foco da ateno de muitos

pesquisadores. Robson (1993) apud Kim (2002), por exemplo, ressaltou o problema
que pesquisadores tpicos enfrentam quando tendem a utilizar sua abordagem
favorita sem considerar outras alternativas de pesquisa. Miles e Huberman (1984)
ressaltam que um projeto de pesquisa previamente estruturado auxilia na coleta
seletiva de dados e facilita a pesquisa em mltiplos campos.
Pode-se entender o projeto de pesquisa como sendo a estratgia pela qual se
pretende investigar o problema de pesquisa. Este projeto compreende: a estrutura
para os procedimentos que se pretende seguir, os dados que devero ser colhidos e a
anlise que se pretende fazer desses dados (Leedy e Ormrod, 2001). Pode-se dizer
que o projeto de pesquisa o planejamento da pesquisa ou o modelo pelo qual a
pesquisa desenvolver-se-.
Cooper e Emory (1995) ressaltam que existem muitas definies para projeto
de pesquisa, mas nenhuma delas consegue abranger os aspectos mais relevantes de
uma forma completa. Os autores citam os seguintes exemplos:
O projeto de pesquisa constitui um desenho tcnico no qual estaro as
diretrizes para coleta, medio e anlise dos dados. Ele auxilia os pesquisadores na
alocao de seus limitados recursos, utilizando-se da de um processo de escolhas: o
desenho inclui experimentos, entrevistas, observaes, anlise dos registros,
simulao ou alguma combinao destes? Os mtodos de coletas de dados e a
situao da pesquisa devem estar fortemente estruturados? Ser o estudo intensivo
de uma amostra menor mais eficiente do que um estudo menos intensivo em uma
amostra maior? A anlise dever ser basicamente quantitativa ou qualitativa?
Projeto de pesquisa o plano e a estrutura de investigao por meio dos
quais se pretende obter respostas para as questes de pesquisas. O plano o
esquema geral da pesquisa. Ele inclui a base do que o pesquisador dever fazer
para compor as hipteses e suas implicaes gerais na anlise final dos dados. A
estrutura o modelo, organizao, ou configurao das relaes entre as variveis
do estudo. Um projeto de pesquisa expressa tanto a estrutura do problema de
pesquisa quanto o plano de investigao utilizado para obter evidncias empricas
nas relaes do problema.

25

Para estes pesquisadores, o projeto de pesquisa importante a fim de reduzir

os esforos para coleta e anlise de dados e no uso apropriado de mtodos de
pesquisa.
Uma das questes comuns nos debates sobre os mtodos de pesquisa diz
respeito ao que significa uma pesquisa cientfica. Estes debates tm sido mais
enfticos no campo das cincias sociais que lidam com diferentes questes de
pesquisa e distintos tipos de dados coletados das cincias naturais. Patton (1978)
esclarece que a avaliao da pesquisa dominada pelo inquestionvel paradigma da
cincia natural a metodologia hipottico-dedutiva.
O autor ressalta que este dominante paradigma assume medidas quantitativas,
projeto experimental e anlises estatsticas paramtricas e multivariadas, como sendo
a base da boa cincia. Entretanto, esta abordagem tradicional mostra certa
limitao quando lida com problemas mais complexos em situaes do mundo real
com ambientes no controlados e confusos (Parlett e Hamilton, 1976). Patton (1978)
descreve a alternativa da abordagem qualitativa, como sendo baseada em entrevistas
abertas, observao e anlise holstica. Reichardt e Cook (1979) propem a utilizao
de uma abordagem flexvel que empregue diferentes mtodos, em funo de cada
situao. Yin (1994) tem a mesma viso.
A pesquisa apresentada nesta tese segue esta abordagem flexvel, tanto os
mtodos qualitativos como os quantitativos foram utilizados, este ltimo em menor
escala. Com isto, pretendeu-se atingir o seguinte:
1) Determinar quais as principais relaes entre os princpios e mtodos
enxutos e as prticas em processo de desenvolvimento de produtos; e
2) Propor uma metodologia para sistematicamente conduzir o processo de
desenvolvimento de produtos a um estado considerado enxuto.
Considerando as caractersticas da rea de pesquisa, mtodos qualitativos so
normalmente, mais utilizados que os quantitativos. Desta forma uma explicao
detalhada dos mtodos de pesquisa utilizados foi realizada.

26

Segundo Cooper e Emory (1995), quando se considera o escopo qualitativo

na pesquisa, diferentes abordagens podem ser utilizadas e adaptadas para a
investigao:
1.

Entrevistas profundas (normalmente realizadas por meio de

conversao ao invs da forma estruturada);

2.

Observao participativa (para ter, em primeira mo, o que os

participantes esto tendo como experincia);

3.

Filmes, fotografias e gravaes (com o objetivo de capturar o

ambiente de atuao do grupo em estudo);

4.

Estudos de caso (para anlise contextual profunda de alguns poucos

eventos ou condies);

5.

Pesquisa etnogrfica (para descobrir como a cultura de um

subgrupo pode descrever ou estruturar seu universo); e

6.

Anlise documental (para avaliar dados pblicos ou confidenciais

histricos ou contemporneos).

3.1

O PROCESSO DE PESQUISA
Existem vrias formas de se abordar um mesmo problema. Mas, um projeto

de pesquisa segue normalmente um formato bsico que resguarda as particularidades

das abordagens que sero utilizadas. Este formato bsico pode ser observado na
Figura 3.1.
A articulao entre as etapas da investigao, segundo Quivy e Campenhoudt
(1998) estabelecida atravs de por meio aes metodolgicas:
A ruptura que consiste precisamente em romper com os preconceitos e as
falsas evidncias que s nos do a iluso de compreender as coisas. , portanto, a
primeira ao que constitui processo.
A construo a partir da teoria gerada na ao anterior, possvel gerar as
proposies explicativas do fenmeno que se pretende estudar e prever qual o plano

27

de pesquisa ser definido, quais operaes sero aplicadas e as conseqncias que

logicamente se pode esperar no termo de observao. Sem esta construo no
haveria experimentao vlida. As proposies devem corresponder ao produto de
um trabalho racional fundamentado na lgica e em uma bagagem conceitual
validamente construda.

Ruptura

A pergunta de partida

A explorao
As
leituras

As entrevistas
exploratrias

Construo

O Problema

A construo do
modelo de anlise

Verificao

A observao

A anlise das
informaes

As concluses

Figura 3.1 Etapas do Projeto de Pesquisa

Fonte: Quivy e Campenhoudt (1998).

A Verificao uma proposio s tem direito ao estatuto cientfico na

medida que pode ser verificada por intermdio dos fatos. o teste pelos fatos
chamado de verificao ou experimentao e corresponde a terceira ao do
processo.

28

Entretanto, o processo apresentado na Figura 3.1 no termina ao se

completarem os passos propostos. A pesquisa , por natureza, cclica ou para ser
mais preciso, helicoidal. A resoluo do problema de pesquisa ou validao dos
pressupostos conduz ao trmino de um ciclo que raramente conclusivo. Ao
explorar-se os problemas de pesquisa, outros problemas mostrar-se-o, e exigiro
novas pesquisas.
Nem todos os pesquisadores seguiro o processo mostrado na Figura 3.1
exatamente na mesma seqncia. O processo s estabelece linhas gerais para a
pesquisa. Por exemplo, o levantamento do problema ou a gerao dos pressupostos
pode ser feito de forma simultnea reviso da literatura. Robson (1993) destaca este
aspecto por meio da seguinte afirmao:

O modelo de pesquisa com sua ordem e separao em uma seqncia linear

clara mais uma reconstruo guardada em textos do que uma explicao do
mtodo cientfico na prtica (...) Na vida real, a cincia no pode fugir da
turbulncia de outros aspectos do mundo real.

Desta forma, o autor afirma que a abordagem interpretativa tende a gerar

teorias e conceitos depois da coleta e anlise dos dados. Na abordagem interpretativa,
a coleta e a anlise dos dados no esto claramente separadas, ou seja, ambas podem
conduzir o processo de escolha dos dados que sero coletados e analisados em uma
prxima fase.

3.2

REVISO DOS MTODOS DE PESQUISA

Como apresentado anteriormente, o projeto de pesquisa um planejamento

global e sua abordagem similar entre as diferentes reas do conhecimento.

Entretato, mtodos especficos para coletar e analisar os dados podem ser
especificados de acordo com os objetivos da pesquisa, com as caractersticas dos
dados que sero coletados ou com a especificidade da disciplina.
Segundo Cooper e Emory (1995), os objetivos da explorao podem ser
alcanados por meio de diferentes tcnicas de coleta de dados. Tanto mtodos

29

quantitativos como qualitativos podem ser aplicados durante a fase de explorao.

Leedy e Ormrod (2001) acompanham o argumento e fazem distino entre os dois
tipos de estratgias de pesquisa: a quantitativa e a qualitativa. Em geral, a
quantitativa ou experimental utilizada para responder questes de relacionamento
entre variveis previamente medidas, com o objetivo de explicar, predizer e controlar
um fenmeno. Em contraste, a estratgia de pesquisa qualitativa tipicamente
aplicada para responder questes sobre fenmenos de natureza complexa,
freqentemente com o propsito de descrever o entendimento de um fenmeno do
ponto de vista dos participantes.
Normalmente, os mtodos quantitativos comeam com o estabelecimento de
hipteses que devero ser testadas. Em seguida, as variveis a serem estudadas so
isoladas, considerando que as variveis extrnsecas so controladas. Em geral, um
procedimento padronizado utilizado para coletar algum tipo de dado numrico e
mtodos estatsticos so empregados para construir concluses. Mtodos
quantitativos, com freqncia, terminam com a confirmao de que os dados
suportam ou no as hipteses testadas.
Por outro lado, mtodos qualitativos, freqentemente, iniciam com uma
questo de pesquisa inicial genrica ao invs de hipteses especficas (Leedy e
Ormrod, 2001). Um grande volume de dados verbais coletado de um pequeno
nmero de participantes e organizado de forma a propiciar coerncia. Ento, a
situao estudada fotografada por estas descries verbais. Um estudo qualitativo
encerra com tentativa de respostas ou de hipteses sobre o que se observa. Na tabela
abaixo esto destacadas as caractersticas destas duas abordagens.
Segundo Cooper e Emory (1995), qualidade a natureza ou caracterstica
essencial de alguma coisa, ao passo que quantidade o volume. Portanto, qualidade
o que, quantidade o quanto.
A categorizao dos mtodos de pesquisa em quantitativos e qualitativos
apresentada nos dados da Tabela 3.1, no , contudo, absoluta. Isto quer dizer que as
duas estratgias no podem ser claramente separadas. Reichardt e Cook (1979)
argumentam que um pesquisador pode fazer uso de ambas as estratgias em sua

30

pesquisa, j que alguns mtodos de pesquisa contemplam as duas e que existe uma
sobreposio entre elas.
A tcnica qualitativa de pesquisa, mais do que a quantitativa, possui alto grau
de flexibilidade no que se refere utilizao de ferramentas para coleta de dados e
para a explorao.
Tabela 3.1 Caractersticas dos mtodos de pesquisa quantitativo e qualitativo.
Questo

Quantitativa

Qual o propsito da pesquisa?

Qualitativa

Explicar e predizer

Descrever e explicar

Confirmar e validar

Explorar e interpretar

Testar a teoria

Construir teoria

Orientada a resultados

Orientada a processos

Qual a natureza do processo de Focado

pesquisa?
Variveis conhecidas

Holstico
Variveis desconhecidas

Diretrizes estabelecidas

Diretrizes flexveis

Projeto esttico

Projeto emergente

Livre de contexto

Ligado ao contexto

Viso impessoal

Viso pessoal

Grandes amostras.
Representativos.

Pequenas amostras.
Informativos.

Instrumentos padronizados

Entrevistas e observaes

Qual a lgica na anlise?

Anlise dedutiva

Anlise indutiva

Como as descobertas so
comunicadas?

Nmeros

Palavras

Estatstica, dados agregados.

Narrativas, citaes
individuais.

Quais os mtodos para a coleta

de dados?

Fonte: Adaptado de Leedy e Ormrod (2001).

Leedy e Ormrod (2001) diferenciam cinco categorias de mtodos de pesquisa
qualitativa: estudo de caso, etnografia, estudo fonomenolgico, estudo de campo e
anlise de contedo, cujas caractersticas no so tambm excludentes umas s
outras, existindo, portanto, sobreposies entre uma e outra. As caractersticas de

31

cada mtodo so apresentadas na Tabela 3.2. O campo de estudo desta tese recai
mais sobre uma estratgia qualitativa do que quantitativa, mesmo que ambas sejam
utilizadas.
Tabela 3.2 Distino das caractersticas dos projetos qualitativos de pesquisa
Projeto
Estudo de
Caso

Etnografia

Estudo
Fenomenolgico

Estudo de
Campo

Anlise de
contedo

Propsito

Foco

Mtodos de coleta de
dados

Entender uma
pessoa ou situao
(ou at mesmo
algumas) com
grande
profundidade

Um caso ou poucos

casos em seu


ambiente natural

Entender como
determinados
comportamentos
podem refletir na
cultura do grupo

Entender uma
experincia a partir
do ponto de vista
dos participantes

Propor uma teoria a

partir de dados
coletados em um
determinado local

Identificar as
caractersticas
especficas de um
material

Sntese a partir de
um panorama
do(s) caso(s)

Documentos
escritos ou
audiovisuais

Categorizao e
interpretao dos
dados em termos
de temas comuns

Um caso especfico

no qual um grupo
de pessoas


compartilha uma
cultura comum

Observao
participativa

Foco em eventos
significantes

Coleta de
documentos

Em
profundidade.

Amostra de 5-25
indivduos

Procura por
significados que
reflitam os vrios
aspectos da
experincia

Integrao dos
significados em
uma experincia
tpica

Mtodo prescrito e
sistemtico de
codificar os dados
em categorias
identificando interrelaes

Contnuo
entrelaamento
dos dados
coletados e
analisados

Tabulao da
freqncia de
cada caracterstica

Anlise inferencial
ou descritiva, de
acordo com a
necessidade de
responder a
questo de
pesquisa

Um fenmeno
particular, assim
como ele vivido e
percebido pelos
seres humanos

Aes e interaes

humanas, e como


estas resultam,
podendo influenciar
umas as outras

Qualquer
comunicao
verbal, visual ou
comportamental

Observaes

Mtodos para anlise

dos dados

Entrevistas

Entrevistas
estruturadas ou
no

Entrevistas
Outras fontes de
dados
relevantes

Identificao do
material
especfico que
ser analisado

Codificao do
material em
termos de
caractersticas
prdeterminadas
precisamente
definidas

fonte: Kim (2002).

32

Estudos com pesquisa qualitativa tipicamente servem para um ou mais

propsitos (Peshkin, 1993):
Descrio revela a natureza de certas situaes, locais, processos, relaes,
sistemas ou pessoas.
Interpretao permite que o pesquisador: consiga insights sobre a natureza
de um fenmeno particular, desenvolva novos conceitos ou perspectivas tericas
sobre o fenmeno, e/ou descubra o problema que existe baseado no fenmeno.
Verificao permite que o pesquisador teste a validade de certos
pressupostos, teorias ou generalizaes em contextos do mundo real.
Avaliao prov os meios pelos quais o pesquisador pode avaliar a eficcia
de determinadas polticas, prticas e inovaes.
Como se pode observar pelos exemplos da Tabela 3.2, existem caractersticas
especficas para cada projeto qualitativo de pesquisa. No entanto, estes mtodos,
como ressaltado anteriormente, no so mutuamente excludentes; ao contrrio, eles
podem contribuir de forma simultnea para o alcance dos objetivos da pesquisa. Isto
pode acontecer em diferentes momentos do andamento da pesquisa, por exemplo: um
estudo de campo na fase inicial e estudos de campo nas fases mais adiantadas do
projeto; ou uma pesquisa de anlise de contedo simultaneamente a uma pesquisa
etnogrfica.
Neste estudo, pretende-se justamente, apoiado em um embasamento terico
pertinente, fazer uso de mais de um mtodo ou projeto para alcanar os objetivos
propostos e, conseqentemente, oferecer possveis respostas aos problemas
apresentados. Detalhes sobre a metodologia utilizada sero abordados na seo 3.3
Mtodos e Procedimentos adotados deste captulo.

3.3

MTODOS E PROCEDIMENTOS APLICADOS NA PESQUISA

A interface entre o processo de desenvolvimento de produto e os princpios

enxutos da manufatura pode ser entendida por uma necessidade de identificar

variveis no processo de desenvolvimento de produto que facilite a implementao

33

de princpios e prticas enxutas, assim como o foi na manufatura. Como

conseqncia, uma srie de trabalhos tem sido realizada para identificar o
relacionamento de tais princpios e prticas no processo de desenvolvimento de
produtos. Mas, existe a carncia de uma abordagem estruturada para sua efetiva
implementao.
Conforme j explicitado no captulo 1, objetivos desta pesquisa so:
Objetivo Geral:
a) Propor uma metodologia para a Implementao de Princpios Enxutos no
Processo de Desenvolvimento de Produtos.
Objetivos Especficos:
a) Analisar prticas industriais, verificar seu alinhamento com os princpios
e prticas enxutas e identificar oportunidades de melhoria;
b) Identificar os principais modelos existentes para criao de valor em
ambientes outros que no o da manufatura;
c) Investigar mecanismos de integrao para a equipe de desenvolvimento
de produtos como base na mentalidade enxuta;
d) Identificar uma plataforma de gesto que auxilie na implementao dos
princpios enxutos no processo de desenvolvimento de produtos;
Confrontando as caractersticas citadas nos dados das Tabelas 3.1 e 3.2 e os
objetivos especficos a e b, a abordagem cientfica tradicional hipottico-dedutiva,
que se baseia em hipteses e teorias estabelecidas no parece ser apropriada. Isto
porque no existe uma teoria estabelecida disponvel que estabelea a forma pela
qual se possa conduzir o processo de desenvolvimento a um estado onde princpios e
prticas enxutas faam parte dessa atividade. Desenvolver uma metodologia que
conduza o processo de desenvolvimento a um estado futuro enxuto foi de fato o
objetivo desta pesquisa. Portanto, mtodos de pesquisas qualitativos so adotados
para gerar uma metodologia para implementao de princpios e prticas enxutas no
processo de desenvolvimento de produtos.

34

Na seleo do mtodo de pesquisa, outro fator considerado foi o tipo de dados

que devem ser coletados. Os dados e a metodologia de pesquisa so intrinsecamente
interdependentes (Leedy e Ormrod: 2001). Por esta razo, a metodologia de pesquisa
a ser usada para um particular problema de pesquisa deve sempre levar em conta a
natureza dos dados que sero coletados a fim de resolver o problema, cujas
caractersticas dos dados para esta pesquisa foram, primeiramente, a informao
verbal das prticas nas indstrias e as teorias acadmicas relacionadas. Desta forma,
a estratgia qualitativa foi mais apropriada do que as estratgias quantitativas, em
geral.

3.4

A ESTRUTURA DA PESQUISA
Esta pesquisa apresenta quatro passos principais.

Propor o Problema de Pesquisa

Cap. 1 e 2

1 Passo

Detalhamento da
Metodologia de
Pesquisa Cap. 3

Reviso da Literatura Cap. 4

Reviso da Prtica Industrial e

anlise dos casos Cap. 5

2 Passo

Background terico Cap. 6

Metodologia para implementao

de princpios Enxutos no PDP
Cap. 7

3 Passo

Aplicao, Anlise, Concluses,

Contribuies e Recomendaes
Cap. 8 e 9

4 Passo

Figura 3.2 Passos da pesquisa, seguidos nesta tese.

35

O primeiro passo, foi identificar os problemas e propor claramente o

problema de pesquisa, dividindo-o em subproblemas gerenciveis, cujos resultados
foram o problema de pesquisa e os respectivos subproblemas propostos. O segundo
passo, foi investigar solues na literatura acadmica e prticas industriais, seu
resultado foi a confirmao da falta de uma metodologia para resolver o problema
levantado na questo de pesquisa. O terceiro passo, foi desenvolver uma nova
metodologia para sistematicamente implementar princpios e prticas enxutas no
processo de desenvolvimento de produtos. O quarto e ltimo passo tratou da anlise
da metodologia proposta. Neste passo, foram propostas algumas discusses sobre as
novas descobertas sobre as interaes entre os princpios e prticas enxutas e o
desenvolvimento de produtos Os passos esto representados na Figura 3.2.

3.4.1

DEFINIO DO PROBLEMA
Como j mencionado no captulo 1, os principais problemas para esta

pesquisa foram divididos em duas partes:

(1) Como os princpios e prticas enxutas relacionam-se com o processo de
desenvolvimento de produtos?
(2) Como, sistematicamente, esses princpios e prticas enxutas podem ser
implementados no processo de desenvolvimento de produtos?
Como os problemas so genricos e, portanto, de difcil soluo, derivaram-se
os seguintes subproblemas:
a- Como representar o processo de desenvolvimento de produtos?
b- Como podem ser entendidos os conceitos e princpios enxutos, e
de que forma eles esto aplicados em ambientes diferentes do da
manufatura?
c- Quais so os principais modelos existentes na literatura para a
criao de valor no processo de desenvolvimento de produto?

36

d- Como uma nova metodologia pode ser utilizada para introduzir os

modelos existentes de forma a criar valor no processo de
desenvolvimento de produtos?
Desta forma, foram desenvolvidas tentativas de respostas para cada um dos
subproblemas. Por exemplo, ao terceiro subproblema, foi analisado o modelo de trs
fases para criao de valor na empresa elaborado pelo Lean Aerospace Initiative
MIT. Para o primeiro e segundo subproblemas, foi feita uma reviso da literatura
(captulo 4), onde foi possvel observar diferentes abordagens de distintos autores.
No quarto subproblema, pretendeu-se estudar como os princpios enxutos podem ser
sistematicamente implementados no processo de desenvolvimento de produtos, ao se
usar o modelo de trs fases, foi possvel entender de que forma os princpios enxutos
podem, possivelmente, ser implementados no processo de desenvolvimento de
produtos PDP. Como resultado foi desenvolvida uma metodologia (captulo 7) que
tem como embasamento a reviso da literatura e das prticas industriais.

3.4.2

DETALHAMENTO DA METODOLOGIA DE PESQUISA

Dentre os cinco mtodos de pesquisas apresentados nos dados Tabela 3.2 e

considerando o propsito de cada um deles, o estudo de caso e o estudo de campo

apresentaram mais afinidades com o tipo de pesquisa que se pretendeu nesta tese.
O estudo de campo difere do estudo de caso em termos de momento do
desenvolvimento da teoria; nele, evita-se a construo de uma teoria antes da coleta
de dados de forma a constru-la quando estes estiverem coligidos. O estudo de caso,
por sua vez, comea com o desenvolvimento de uma estrutura terica antes da coleta
de dados (Leedy e Ormrod, 2001). Warcker (1998) apud Voss et. al. (2002),
divergem de Leedy e Ormrod (2001) quando contrastam o mtodo do caso com os
mtodos analtico-conceituais: A diferena chave que o mtodo emprico de
estudo de caso utiliza os dados para a formao da teoria, o mtodo analticoconceitual realiza dedues a partir da teoria. Seguindo este raciocnio, Yin (1994)
prope que um estudo de caso, para obter sucesso, necessita da construo de uma
estrutura terica. Em face da semelhana entre os mtodos de estudo de campo e

37

estudo de caso, ser feita uma reviso detalhada do mtodo de estudo de caso a fim
de atender ambos os mtodos.
O estudo de caso, segundo Voss et. al. (2002), pode ser utilizado para
diferentes propsitos em pesquisa, tais como: explorao, construo de teoria, teste
da teoria e refinamento/extenso da teoria. Os dados da Tabela 3.3 revelam este
leque de aplicaes.

Tabela 3.3 Alinhamento do propsito da pesquisa com a metodologia.

Propsito

Questo de pesquisa

Estrutura da Pesquisa

Explorao
Revelar reas para pesquisa Existe algo interessante o bastante Estudos de caso profundos.
e desenvolvimento de teoria. para justificar a pesquisa?
Estudo de Campo longitudinal e
no focado.
Construo de Teoria
Identificar/descrever
variveis-chave.
Identificar por que estas
relaes existem.

Quais so as variveis-chave?

Poucos estudos de casos

focados.

Quais os padres ou ligaes entre

as variveis?
Estudos de campo em
profundidade?
Por que estas relaes existem?
Estudos em mltiplos sites.

Teste de Teoria
Testar as teorias
desenvolvidas em estgios
anteriores.
Predizer resultados futuros.

As teorias que foram geradas

Experimento.
sobrevivero aos testes com dados
Quase-experimento.
empricos?
Mltiplos estudos de caso.
Foi possvel captar o
comportamento previsto pela teoria Populao da amostra em
ou foi observado algum
grande escala?
comportamento novo no previsto?

Extenso/Refinamento da
Teoria
Para melhor estruturar as
teorias luz dos resultados
observados.

Quo generalizvel a teoria?

Experimento.

A teoria aplicvel?

Quase-experimento.
Mltiplos estudos de caso.
Populao da amostra em
grande escala?

Fonte: Voss et. al.(2002).

Um estudo de caso uma unidade de anlise na pesquisa de casos e pode ser

definido como:

38

Um estudo de caso uma histria sobre um fenmeno passado ou corrente,

construda atravs de mltiplas fontes de evidncias. Ele pode incluir dados da
observao direta e de sistemticas entrevistas, assim como de arquivos pblicos ou
particulares. De fato, qualquer fato relevante no fluxo de eventos que descreve um
fenmeno ser um dado relevante em um estudo de caso, desde que o contexto seja
importante (Leonard-Barton, 1990).

A pesquisa apresentada nesta tese foi, portanto, dividida em dois momentos: o

primeiro objetivou levantar dados e informaes necessrias relacionados com os
problemas e subproblemas propostos; o segundo, objetivou efetivamente o
desenvolvimento de uma metodologia para implementao de princpios enxutos no
processo de desenvolvimento de produtos com posterior anlise, consideraes e
concluses.
Neste sentido, pode-se dizer que o mtodo de estudo de campo seria mais
aplicvel ao primeiro momento da pesquisa e mtodo do estudo de caso segunda
parte. Contudo, na prtica os mtodos de estudo de campo e estudo de caso foram
utilizados simultaneamente. Os dados coletados com base nas entrevistas com
engenheiros e pessoal tcnico, observao direta e questionrio aberto, foram
comparados e empregados na construo da metodologia. Estes mesmos dados foram
usados posteriormente com os dados de uma quarta empresa, que serviram para o
refinamento da metodologia proposta. Robson (1993) apud kim (2002) destaca o
mesmo fenmeno na pesquisa onde o mundo real o centro da investigao:
difcil separar claramente os mtodos de pesquisa aplicados no mundo real.

3.4.3

CRITRIOS DE SELEO DOS CASOS

Para o primeiro momento da pesquisa, foram utilizados dados colhidos de trs

empresas: empresa A, empresa B e empresa C. As empresas foram

selecionadas

em

funo

do

grau

de

envolvimento

com

atividades

de

desenvolvimento de produtos. Outro critrio, foi o tipo de desenvolvimento de

produto, para tanto foi utilizado o modelo proposto por Wheelright e Clark (1994)
que classifica os tipos de desenvolvimento de produtos em funo do grau de
alterao no produto e processo, inicialmente buscou-se incluir uma empresa de cada

39

tipo de desenvolvimento. Ao final, porm, apenas trs empresas foram pesquisadas, o

que no permitiu a investigao em todos os contextos propostos inicialmente.
Estes dados com o embasamento terico desenvolvido serviram, no segundo
momento, para construo da metodologia proposta.

Seleo dos
casos
A, B e C.

Desenvolvimento da
estrutura
terica sobre
o Desenvolvimento de
Produtos
Enxuto.

Projetar
protocolo de
coleta de
dados.
Entrevistas
Observaes
Questinrios
etc.

Definio e Projeto

Empresa A

Escrever o
relatrio
Empresa A

Empresa B

Escrever o
relatrio
Empresa B

Empresa C

Escrever o
relatrio
Empresa C

Avaliao da
Ferramenta

Escrever o
relatrio da
Avaliao

Construir
concluses
cruzadas sobre
os casos

Anlise e reviso da estrutura terica

Elaborao da
metodologia

Relatrio
Conduo dos
demais casos
se necessrio

Relatrio dos
demais casos

Preparao, Coleta e Anlise.

Anlise e Concluso

Figura 3.3 Estrutura para a pesquisa com estudo de casos mltiplos, aplicada na
primeira rodada de estudos de campo com as empresa A, B e C.
Fonte: Baseado em Yin (1994).
O segundo momento da pesquisa foi dividido em duas partes; a primeira a
construo da metodologia proposta; a segunda a avaliao da metodologia.
Durante a elaborao da metodologia, foi detectada a necessidade de uma interao
no sentido de construir um background terico intrnseco construo da
metodologia (captulo 6). Para a segunda parte, avaliao da metodologia foi
selecionada a empresa D, cujos critrios de seleo foram os mesmos utilizados na
primeira etapa da pesquisa, acrescido do fato da empresa predispor-se implementar a

40

metodologia proposta. Nesta fase, a estrutura terica j estava consolidada e pronta

para ser aplicada e foram usados protocolos semelhantes queles utilizados para
coleta de dados da primeira rodada de casos, ou seja, entrevistas com engenheiros e
tcnicos, observao direta e questionrio com questes abertas a respeito da
metodologia proposta. Com base nos resultados obtidos, a metodologia proposta foi
ento, refinada. Esta segunda parte da pesquisa pde ser considerada como uma
validao de processo. A validao da metodologia proposta serviu para revelar que
a mesma oferece uma estrutura aplicvel na utilizao de princpios enxutos no
processo de desenvolvimento de produtos e a conseqente criao de valor.

3.4.4

REVISO DA LITERATURA E DAS PRTICAS INDUSTRIAIS

Para investigar solues existentes aos problemas de pesquisa, as

metodologias propostas na literatura e as prticas industriais foram estudadas e

exploradas. Assim, foi possvel considerar as implicaes entre o processo de
desenvolvimento de produtos e as prticas e princpios enxutos de forma a melhorar
seu desempenho global. Existem algumas abordagens aos problemas de pesquisa,
como, por exemplo, a utilizao da engenharia simultnea para a criao de valor
baseada na utilizao de times funcionais e execuo de atividades paralelas no
processo de desenvolvimento de produtos ou a transposio dos princpios enxutos
para o ambiente de desenvolvimento de produtos proposto por Slack (1998), no
entanto, estas abordagens apresentaram limitaes que sero mostradas durante a
reviso da literatura.

3.4.5

COLETA E ANLISE DOS DADOS

Os dados coletados baseados nas entrevistas com engenheiros e pessoal

tcnico, observao direta e questionrio, so comparados e utilizados na construo

da metodologia (Captulo 5). Tanto os dados primrios como os dados secundrios
foram utilizados nesta etapa. Os dados secundrios foram usados com base nos dados
coletados em fontes primrias.

41

Segundo Eisenhardt (1989), em pesquisa qualitativa, a etapa de anlise mais

efetiva quando se observa um pequeno conjunto de informaes simultaneamente
sua coleta do que quando se analisa um grande conjunto aps a coleta total de dados.
O processo de sobreposio da coleta e anlise de dados foi usado neste estudo, e
pode ser observado no captulo 5.
A anlise dos dados constitui-se de quatro atividades bsicas recomendas por
Miles e Huberman (1994). 1) Identificao de conceitos apoiados nos dados, 2)
Pautado nos conceitos agrupar os dados em categorias, 3) Codificar os dados de
acordo com categorias-chave em funo da estrutura analtica discutida
anteriormente e 4) desenvolver as categorias por meio de investigaes e da anlise
comparativa entre as empresas participantes.
Por meio da utilizao deste mtodo, foi possvel obter um consistente
entendimento das prticas do processo de desenvolvimento de produtos em cada uma
das empresas e a conseqente identificao das caractersticas que esto associadas
aos princpios enxutos.

3.4.6

CONCLUSES, CONTRIBUIES E SUGESTES

O objetivo da investigao foi responder pergunta de partida. Para tanto,

foram realizadas observaes que possibilitem o entendimento e conseqente

resposta a essa questo inicial. Por vezes, a realidade, mais rica e mais matizada
que os pressupostos ou hipteses que se elabora a seu respeito. Uma observao sria
leva a outros fatos alm dos esperados e outras relaes que no se deve
negligenciar. Portanto, a anlise das informaes tem uma segunda funo:
interpretar estes fatos inesperados e rever ou afirmar os pressupostos para que nas
concluses o investigador esteja em condies de sugerir aperfeioamentos de seu
modelo de anlise ou de propor pistas de reflexo e de investigao para o futuro.
(Quivy e Campenhoudt, 1998)

42

3.5

VALIDADE DOS MTODOS DE PESQUISA APLICADOS

A validade dos mtodos de pesquisa indica a preciso, significncia e

credibilidade do projeto de pesquisa como um todo (Leedy e Ormroud, 2001).

muito importante pensar na validade dos mtodos de pesquisa utilizados, uma vez
que os resultados da pesquisa somente sero significantes ou defensveis at onde
esta permitir.
Os autores citados acima distinguem dois tipos de validao de um estudo de
pesquisa: validao interna e validao externa.
A validao interna est relacionada com a capacidade do projeto e dos dados
para permitirem ao pesquisador concluses acuradas sobre relaes de causa e efeito.
Existem vrias formas de garantir a validade interna de um estudo de pesquisa. As
seguintes estratgias foram utilizadas para aumentar a probabilidade de que as
explicaes fornecidas pelos pesquisadores sobre de um problema estudado foram as
mais provveis, de acordo com as observaes por eles realizadas:

Estudos controlados em laboratrio conduzir um experimento em

laboratrio a fim de, cuidadosamente, regular as condies de ambiente,

Experimento double-blind tanto os participantes quanto os mtodos so

double-blind, de forma a comparar a eficincia de um grupo hipottico
com outro grupo,

Triangulao mltiplas fontes de dados so coletadas com a expectativa

de que estas possam convergir para a confirmao de uma hiptese ou
teoria.

Segundo esta afirmao, a estratgia de triangulao freqentemente

utilizada em pesquisa qualitativa. Seguiu-se, ento, nesta mesma direo para a
realizao deste estudo. Por meio do uso de mltiplos estudos de caso, com
diferentes mtodos de coleta de dados, o que incluiu observaes diretas, surveys, e
entrevistas, a validade interna para esta pesquisa pde ser garantida.
A validade externa de uma pesquisa est relacionada com o alcance que seus
resultados podem obter, alm dos limites do estudo realizado. Em outras palavras, ela

43

indica a extenso para outros contextos, da generalizao das concluses construdas.

Por esta razo, muitas vezes, a validade externa chamada simplesmente de
generalizao. Leedy e Ormroud (2001) apresentam trs estratgias utilizadas para
garantir a validade externa de um estudo de pesquisa:

Aplicao no Mundo Real a pesquisa conduzida no ambiente externo

e, mesmo no tendo o rigoroso controle de um laboratrio, pode oferecer
mais validade na medida que ela propicia resultados com aplicabilidade
mais ampla em outros contextos;

Amostra Representativa quando uma amostra estudada com o objetivo

de construir concluses sobre uma categoria para entender o todo, da qual
esta categoria faz parte; e

Replicao em um contexto diferente se duas pesquisas so conduzidas

em diferentes contextos e alcanam a mesma concluso, pode evidenciarse que as concluses tm validade e aplicabilidade entre diversos
contextos e situaes.

44

4.1

REVISO TERICA

INTRODUO
Nesta parte do trabalho, procurou-se revisar os pontos destacados pelos

subproblemas construdos no captulo 1. Com certeza, esta no ser uma tarefa fcil:
primeiro, em razo da grande literatura a respeito do tema Desenvolvimento de
Produto; segundo, pela escassez de literatura sobre a implementao especfica de
Princpios e Prticas Enxutas em ambientes que no sejam os da manufatura. Outra
questo importante sobre a reviso da literatura no contexto de desenvolvimento de
produtos repousa no fato de que o tema incorpora numerosas disciplinas de pesquisa,
tais como: melhoria de processos, engenharia de produto, organizao do trabalho,
formao de equipes, etc. (Gewin e Barrowman, 2002; Krishnan e Ulrich, 2001;
Griffin, 1997).
No incio de cada assunto da reviso da literatura, alguns termos foram
definidos com o objetivo de evitar dificuldades na interpretao de seu uso.

4.2

DESENVOLVIMENTO DE PRODUTOS
Com relao reviso da literatura a respeito de desenvolvimento de

produtos, o esforo no se dar no sentido de fazer uma reviso completa do tema.

Ao contrrio, procurou-se discutir pontos importantes dos trabalhos que foram
importantes para o entendimento do pensamento corrente sobre desenvolvimento de
produtos e que, portanto, foram referenciados nesta pesquisa.
Para iniciar esta reviso terica, foi discutida a definio de produto. Ulrich e
Eppinger (2000) que definem um produto como algo vendido por uma empresa aos
seus clientes e desenvolvimento do produto, como um conjunto de atividades que
tem incio com a percepo de uma oportunidade de mercado e termina na produo,

45

venda e entrega de um produto. Esta ser ento a definio genrica utilizada nesta
tese para desenvolvimento de produto.
Com relao definio de design, distintas vises so observadas na
literatura, poucos artigos o definem de forma estrita e, de fato, design pode ser visto
por meio de diferentes perspectivas (Pahl e Beitz, 1996) ou pelas distintas reas (Suh,
2001). Ulrich e Eppinger (2000) entendem design, como a definio da forma fsica
do produto que melhor atende a necessidade dos clientes. Phal e Beitz (1996) apud
Kim (2002) referem-se ao design como uma atividade de engenharia que: 1) afeta a
quase totalidade das reas relacionadas com a vida humana, 2) utiliza-se de leis da
cincia, 3) constri-se sobre experincias especiais, e 4) prov os pr-requisitos para
a realizao fsica do que se projetou no campo das idias. Em sua teoria de projeto
axiomtico, Suh (2001) define design como uma interao entre o que se quer
alcanar e como se quer alcanar. Para efeito desta tese, design do produto refere-se
ao arranjo conceitual dos elementos ou detalhes de um produto, que resultado da
interao entre os objetivos de um produto e suas respectivas solues. O termo
design do produto, ento, distinguir-se- de projeto do processo, pois o projeto
do processo ser usado para definir como se realizar fisicamente o que foi definido
do design do produto.
Existe uma vasta literatura disponvel sobre processos de desenvolvimento de
produtos. Clark e Fujimoto (1991) explicam o esforo de empresas do setor
automobilstico japons em seu processo de desenvolvimento de produtos quando
comparadas com empresas ocidentais. Ulrich e Eppinger (2000) oferecem uma
detalhada explanao sobre o processo de projeto do produto, assim como das
ferramentas utilizadas.,
Em detalhes, Sobek II (1997) compara Toyota e Chrysler em termos de
processos de desenvolvimento de produto e prope o conceito de set-based
concurrent engineering 9. Clausing (1994) recomenda a utilizao de um processo de
desenvolvimento de produto organizado e estruturado, em que oferecido um guia
passo a passo para a engenharia simultnea, assim como as ferramentas que sero
9

Ward, et. al.(1995), descrevem o projeto set-based como uma abordagem de soluo de problemas
na qual projetistas avaliam um conjunto de alternativas. Ver captulo 4 desta tese.

46

utilizadas em cada passo durante o processo de desenvolvimento de produtos. Meyer

e Lehnerd (1997) apresentam as vantagens de aplicar o conceito de plataforma de
produto quando comparado abordagem tradicional de desenvolvimento de produto
nico. Wheelwright e Clark (1992) sugerem uma estrutura de desenvolvimento de
produto que inclui questes organizacionais, tais como: cooperao interfuncional,
aprendizado e formao de competncias. Brown e Eisenhardt (1995) elaboraram
uma reviso dos artigos sobre desenvolvimento de produtos a qual tem sido, segundo
Liu (2003), a mais abrangente reviso de literatura feita nessa rea. O trabalho
categoriza a literatura sobre o tema em trs ramos: plano racional, rede de
comunicao e resoluo disciplinada de problemas. Brown e Eisenhardt (1995)
tambm desenvolveram um modelo que destaca a distino entre o desempenho do
processo e a eficincia do processo, assim como a importncia dos agentes, incluindo
os membros das equipes, lderes de projeto, gerenciamento snior, clientes e
fornecedores, os quais, com seus comportamentos, influenciam os resultados.
Krishnan e Ulrich (2001) fizeram uma reviso dos artigos sobre desenvolvimento de
produtos, revisitaram mais de duzentos artigos na rea de desenvolvimento de
produtos, e abriram trs frentes para sua pesquisa na literatura:

Projetos de desenvolvimento de produtos em uma nica empresa, o

que se ope vasta literatura que trata da inovao no que tange
indstria como um todo;

Foco no desenvolvimento de bens fsicos; e

Foco na literatura acadmica, revisando a literatura prtica somente

quando ela tenha sido influente para a comunidade acadmica.

Griffin (1997) sumariza os resultados obtidos durante cinco anos de pesquisa

e apresenta as descobertas do survey realizado pelo Product Development
Management Association (PDMA) sobre as melhores prticas em desenvolvimento
de novos produtos. Leonard-Barton (1990) examina as competncias essenciais de
uma firma, em particular, no que se refere interao dos projetos de
desenvolvimento de produtos e processos. Gerwin e Barrowman (2002) realizaram
uma avaliao das pesquisas relacionadas com o desenvolvimento integrado de

47

produtos, nas quais os autores procuraram seguir trs objetivos principais: o

primeiro, criticar a literatura existente sobre desenvolvimento integrado de produtos
concentrando-se nos problemas que ocorrem nas pesquisas empricas e nas
recomendaes de solues. O segundo, oferecer, talvez a primeira anlise
quantitativa entre as caractersticas do desenvolvimento integrado de produtos e
desempenho de projeto. O terceiro, sugerir temas para futuras pesquisas.
Ward et.al. (1995) examinaram o set-based concurrent engineering, por
meio de extensiva pesquisa estudos de caso e entrevistas apresentando o seguinte
argumento: que aparentemente sistemas ineficientes tm tornado a Toyota a mais
rpida e eficiente empresa no aspecto desenvolvimento de automveis. Cooper
(1983) tenta responder seguinte questo: quais passos deveriam ser tomados, no
gerenciamento de novos produtos industriais, de forma a melhorar o desempenho do
novo produto? Como resultado apresenta um modelo de sete estgios para o
desenvolvimento de novos produtos.
Estes, portanto, so alguns dos trabalhos importantes sobre o processo de
desenvolvimento de produtos e que, junto a outros mais, auxiliaram no
desenvolvimento desta tese. Esta breve relao de artigos no pretende esgotar todas
as publicaes sobre o tema, mas apenas destacar algumas das principais obras de
referncia para este trabalho.

4.2.1

A REPRESENTAO POR PROCESSOS NO DESENVOLVIMENTO DE

PRODUTOS
As

abordagens

por

processos

modelam

os

procedimentos

em

desenvolvimento de produto. Em geral, estas abordagens oferecem uma seqncia de

passos de desenvolvimento de produtos e descrevem as atividades que devem conter
cada passo. O modelo de Cooper (1983), por exemplo, composto de sete estgios
como representado na Figura 4.1.

48

Estgio I
Idia

Estgio II

Estgio III

Estgio IV

Estgio V

Estgio VI

Estgio VII

Avaliao
Preliminar

Conceito

Desenvolvimento

Teste de
prottipo

Teste de
Mercado

Lanamento

Figura 4.1 Digrama de fluxo de sete estgios para o ciclo de desenvolvimento de

produto
Fonte: Cooper (1983).

No modelo da Figura 4.1, Cooper (1983) identificou para cada estgio o que
chamou de Atividades de Mercado e Atividades Tcnicas e de Produo. As
atividades para cada estgio so:
O Estgio I Gerao de Idias e de Filtro Inicial (passa ou no passa)10.
O Estgio II Avaliao Tcnica Preliminar (Tcnica e de Produo), de
Avaliao Preliminar de Mercado (Mercado) e Avaliao preliminar (passa ou no
passa).
O estgio III Identificao do Conceito (Mercado), Gerao do Conceito
(Tcnica e de Produo), Teste do Conceito (Mercado) e Avaliao do Conceito
(passa ou no passa).
O estgio IV Desenvolvimento do Produto: projeto de engenharia e
prottipo (Tcnica e de Produo), Desenvolvimento do Plano de Mercado
(Mercado) e Avaliao (passa ou no passa).
Estgio V Teste Interno de Prottipo (Tcnica e de Produo), Teste de
Prottipo com Clientes (Mercado) e Avaliao (passa ou no passa).

10

Traduo livre do autor para a expresso go - no go.

49

Estgio VI Finalizao do Projeto e Prova de Produo (Tcnica e de

Produo), Finalizao do Plano de Marketing e Prova de Mercado (Mercado) e
Anlise de Negcio Pr-comercial (passa ou no passa).
Estgio VII Produo Total (Tcnica e de Produo), Lanamento no
Mercado (Mercado) e Avaliao e Controle Ps-lanamento.
Para Cooper (1983), o lanamento de um novo produto necessitar sempre da
assuno de um alto grau de risco. Mas muito pode ser aprendido a respeito do
gerenciamento eficaz do processo de desenvolvimento de produto, por meio de uma
reviso das experincias passadas. Nem todos os projetos de desenvolvimento de
produtos seguiro rigorosamente este modelo. Certamente elementos no observados
e circunstncias especiais ditaro passos adicionais, como a reciclagem dos passos
apresentados ou a eliminao de alguns passos.
A explanao de Cooper alinha-se com a proposta deste trabalho, qual seja:
envidar esforos no sentido de identificar uma metodologia que possa captar estas
condies circunstanciais e incorpor-las ao processo de desenvolvimento de
produtos.
Em trabalho mais recente, Ulrich e Eppinger (2000) modelaram o processo de
desenvolvimento de produtos em seis fases seqenciais, conforme apresentado na
Figura 4.2.

Fase 0
Planejamento

Fase 1
Desenvolvimento do
Conceito

Fase 2
Projeto em
nvel de
sistema

Fase 3
Projeto
Detalhado

Fase 4
Refinamento
e Teste

Fase 5
Produo e
Ramp-up

Figura 4.2 O ciclo de desenvolvimento de produto

Fonte: Ulrich e Eppinger (2000)

Assim como no modelo de Cooper, este modelo apresentado na Figura 4.2

tambm engloba, em cada fase, uma srie de atividades de processos de feed-back.

50

Como exemplo, Ulrich e Eppinger (2000) apresentam as atividades de front-end11

que englobam a fase de desenvolvimento do conceito. A Figura 4.3 d uma viso
detalhada desta fase:

Identificao
das
necessidades
do cliente

Estabelecer metas

Gerar
Conceito
de Produto

Selecionar
conceitos
de
Produtos

Testar
Conceito
de Produto

Ajustar
Especifica
-es
finais

Desenvolvimento do
plano
jusante

Anlise de Desempenho Econmica

Pesquisa de Produtos Concorrentes
Construir e Testar Modelos e Prottipos

Figura 4.3 As atividades de front-end englobando a fase de desenvolvimento do

conceito
Fonte: Ulrich e Eppinger (2000).

As abordagens orientadas para processo podem diferir em termos de detalhes

oferecidos na descrio dos passos no desenvolvimento do produto ou das
terminologias utilizadas. Contudo, do ponto de vista de que todas as abordagens
propem passos que devem ser tomados no desenvolvimento do produto e que
oferecem fundamentos baseados nas proposies, as abordagens orientadas a
processos so muito similares.
Estas abordagens, porm, no revelam como cada departamento funcional
deveria estar envolvido em cada etapa do processo. Em outras palavras, questes
organizacionais no so discutidas. Os dados tabela 4.1 mostra esta relao.

11

Conjunto de atividades iniciais e bsicas de um projeto de desenvolvimento de produto. Para

Krurana e Rosenthal, nesta fase, inclusive, que devem ser includas as consideraes sobre a cadeia
de valor agregado.

51

Tabela 4.1 Atividades funcionais sob a tica da integrao interfuncional

Fases do Desenvolvimento
Atividades
Funcionais

Desenvolvimento do
Conceito

Planejamento
do Produto

Engenharia Propor novas

tecnologias;
desenvolver
idias de
produtos;
construir
modelos;
conduzir
simulaes.

Escolher
componentes
e interagir
com
fornecedores;
elaborar
sistemas de
prprottipos;
definir
arquitetura de
produto.

Elaborar
projeto
detalhado do
produto e
interagir com
o processo;
construir
prottipos em
escala
natural,
conduzir teste
de prottipos.

Refinar
detalhes do
projeto do
produto;
participar da
elaborao
da segunda
fase de
prottipos.

Prever inputs
baseados no
Mercado;
propor e
investigar
conceitos de
produto.

Definir
parmetros
para os
consumidores
alvo;
desenvolver
estimativas
de vendas e
margens;
conduzir
interao
inicial com os
clientes.

Conduzir
testes de
prottipos
com os
clientes;
participar na
avaliao do
prottipo.

Manufatura Processar e
investigar
conceitos de
processo.

Desenvolver
estimativas
de custo;
definir
arquitetura de
processos;
conduzir
simulao de
processos;
validar
fornecedores.

Realizar
projeto
detalhado do
processo;
projetar e
desenvolver
ferramentas;
participar da
construo de
prottipos em
escala
natural.

Marketing

Preparao
Comercial

Introduo
no Mercado

Avaliar e
testar
unidadespiloto.

Avaliar
experincia
de campo
com o
produto.

Conduzir a
segunda fase
de testes com
clientes;
avaliar os
prottipos;
aplicar o
plano de
marketing;
estabelecer
plano de
distribuio.

Preparar
para
introduzir no
mercado,
treinar
foras de
venda; e
pessoa de
servios.

Preencher
canais de
distribuio;
vender e
promover;
interagir
com
clienteschave.

Teste das
ferramentas e
equipamentos
; elaborar a
segunda fase
de prottipos;
e destacar
novos
procedimentos.

Construir
unidade
piloto em
processo
comercial,
refinar
processo
com base
na
experincia
do piloto.

Conduzir a
planta ao
volume
pretendido
e atingir
alvos de
qualidade,
produo e
custo.

Desenvolvimento e projeto
detalhado
Fase I

Fase II

Fonte: adaptado de Wheelwright e Clark (1992).

52

4.2.2

O DESENVOLVIMENTO DE PRODUTOS REPRESENTADO COM A

ABORDAGEM DE DECOMPOSIO.
As abordagens de decomposio para representao de um determinado

sistema tm sido, com sucesso, implementadas para representar sistemas de

manufatura12. (Figura 4.4)
RF
PP

Qualidade

Soluo de
Problemas

Outputs
esperados

Reduo de
Atrasos

Custos
Operacionais

Investimentos

Figura 4.4 Estrutura genrica para decomposio de um sistema de manufatura

Fonte: Kim (2002).

Este sucesso tem estimulado o emprego da mesma abordagem ambiente de

desenvolvimento de produtos. Pesquisadores propuseram diferentes abordagens para
a decomposio do desenvolvimento de produtos:

Decomposio do Projeto de Desenvolvimento de Produtos PD3

(Bocanegra, 2001);

Decomposio do Projeto do sistema de Desenvolvimento de

Produtos (Lenz e Cochran, 2000).

O PD3 foi desenvolvido para oferecer uma forma padro de desenvolvimento

de produtos em uma empresa do ramo aeroespacial, assim, a decomposio utiliza

12

Para maiores detalhes da abordagem de decomposio no sistema de manufatura ver Cochran et. al.
(2000), Linck (2001), Duda (2001), e Arinez (2000).

53

requisitos funcionais e parmetros de projeto especficos para a indstria

aeroespacial. (Figura 4.5)

Product Development Design Decomposition (PD3)

RF-01
Uma definio
de produto e
processo que
atinja os requisitos
dos clientes
externos e
internos

NVEL 1

PP-01
Decomposio
enxuta de
desenvolvimento
de produtos

RF-011
Projetar um
produto funcional
que satisfaa as
necessidades
dos clientes
externos.

RF-012
Produzir produtos
que satisfaam
as necessidades
dos consumidores
internos.

RF-013
Reduzir o tempo
total de definio
processo e
definio do
produto

RF-014
Garantir que o
produto
lucrativo.

RF-015
Garantir a
melhoria
contnua.

PP-011
Processo para
satisfazer e
tornar claros os
requisitos
funcionais dos
produtos.

PP-012
Projetar um
produto que
seja
manufaturvel.

PP-013
Processos de
projeto
pedronizados

PP-014
Otimizar o
custo
total do
programa.

PP-015
Iniciativa de
melhoria do
processo.

RF-U2
Projetar o
produto para
alcanar
os requisitos dos
clientes.

RF-U1
Garantir que
os requisitos dos
clientes externos
so
compreendidos..

PP-U1
Processo para
identificar
avaliar os
requisitos dos
clientes.

RF-U3
Capacidade e
caractersticas do
projeto
validadas.

RF-U4
Garantir que as
obrigaes
contratuais so
alcanadas e
entregues..

PP-U3
Processo para
validao e teste
do projeto do
produto.

PP-U4
Processo para
garantir que so
atendidas todas
as necessidades
do cliente
previstas em
contrato.

RF-E1
Entender e
documentar
os processos de
manufatura
e sua
competncias.

RF-E2
Projetar o produto
em funo de
um processo de
manufatura
otimizado.

RF-T1
Garantir que a
data proposta ao
cliente ser
cumpridar

RF-T2
Minimizar
atividades e
tarefas que
no agregam
valor

RF-T3
Minimizar
o retrabalho no
processo de
desenvolvimento

RF-C1
Custo de
desenvolvimento
de produto
otimizado.

RF-C2
Minimizar o
custo indireto de
desenvolvimento
de produto.

PP-E1
Processo para
identificar e
documentar
competncias
de processo.

PP-E2
Processo para
garantir
(DFA/DFM)

PP-E3
Compilar e
documentar
validao e testes
de viabilidade
de produo.

PP-T1
Planejar o ciclo de
desenvolvimento
de forma que as
datas dos clientes
externos sejam
alcanadas

PP-T2
Processo para
minimizar o tempo
de espera e a
distncia
fsica

PP-T3
Processo para
envolver todos os
stakeholders no
momento
apropriado

PP-C1
Aplicar sistema de
gerencial
para controle e
programao de
custos

PP-C2
Processo para
eliminar tarefas
que no
agregam valor.

RF-E3
Validao
de que a
produo
factvel.
.

NVEL 2

RF-K1
Garantir que o
conhecimento
capturado,
identificado e
organizado de
forma precisa..

RF-K2
Permitir o
compartilhamento,
adoo e
utilizao da
imformao.

RF-K3
Melhorar a
eficincia dos
gerentes de
produto.

PP-K1
Iniciativa de
gerenciamento do
conhecimento da
empresa.

PP-K2
Base de dados
amigvel com
o usurio.

PP-K3
Times de trabalho
auto-dirigidos.

RF-U11
Evitar riscos de
falta de
entendimento da
base de requisitos

RF-U12
Saber o que
fazer quando ou
se os requisitos
dos cliente
mudarem.

RF-U21
Padro de
trabalho
alocados nos
sub-times de
acordo com suas
competncias.

RF-U22
Garantir que
os recursos
necessrios esto
disponveis no
processo de
projeto.

RF-U23
Projeto para
requisitos
alocados.

RF-U31
Dados de
projeto
validados

RF-U32
Subconjuntos
ou partes
validados

RF-U33
Validao da
documenao.

RF-E21
Plano de
montagem e
sub-montagem
otimizado..

RF-E22
Otimizar o
detalhamento
de montagem e
sub-montagem.

RF-E23
Especificar os
melhores
componentes e
materiais.

RF-T21
Minimizar
armazenamento
de informaes,
os projetos no
so feitos muito
cedo.

RF-T22
Minimizar
tempo de espera,
os projetos no
so feitos muito
tarde.

RF-T23
Minimizar a
distncia
percorrida.

RF-T31
Melhora a
comunicao
entre clientes,
membros do time
e fornecedores.

RF-T32
Minimizar a
quantidade de
reunies
desnecessrias
com os
fornecedores.

RF-T33
Minimizar o
tempo que se
leva para
autorizar uma
sugesto.

RF-C11
Oramento
otimizado para as
tarefas de
desenvolvimento
planejadas.

RF-C12
Fundos
apropriados para
as vrias fases
do
desenvolvimento..

RF-C13
Garantir que a
eficincia em
custos est
sendo alcanada.

RF-C21
Otimizar o
oramento para
as tarefas
indiretas.

RF-C22
Otimizar o
oramento para
os custos
administrativos..

RF-K11
Identificar o
conhecimento
a ser capturado.

RF-K12
Capturar o
conhecimento de
forma precisa.

RF-K21
Permitir o
compartilhamento
do conhecimento
pela empresa.

RF-K22
Garantir que os
trabalhadores
utilizem o novo
conhecimento.

PP-U11
Estudar e
entender o
contrato..

PP-U12
Entender as
bases da clausula
de mudana
no contrato.

PP-U21
Requisitos fluindo
no processo..

PP-U22
Organizar o time
e disponibilizar
as ferramentas
conforme
requerido.

PP-U23
Projeto detalhado
do produto..

PP-U31
Receber dados
da validao do
projeto e do plano
da produo
factvel..

PP-U32
Realizar a
validao dos
subconjuntos
e partes.

PP-U33
Transcrever
todas as
validaes em um
relatrio final.

PP-E21
Aplicar
competncias
timas de
montagem e
sub-montagem..

PP-E22
Integrar
tcnicas de DFA e
DFM para o
detalhamento
da montagem
e sub-montagem.

PP-E23
Processo de
Make or Buy.

PP-T21
Implementar
programao
de trabalho
just-in-time.

PP-T22
Ter disponvel,
para todos os
stakeholders e
membros do time,
o projeto
atualizado e os
recursos
disponveis

PP-T23
Co-alocao real,
dinmica e/ou
virtual.

PP-T31
Um ambiente que
promova uma
ampla
comunicao.

PP-T32
Uma ferramenta
que identifica
todos os
stakeholders
e suas
respectivas
programaes

PP-T33
Mtodo padro
para incorporar
novas
caractersticas no
projeto.

PP-C11
Procedimentos
para
apropriadamente
alocar o
oramento das
tarefas de
desenvolvimento

PP-C12
Distribuir o
oramento de
acordo com as
tarefas de
desenvolvimento
planejadas..

PP-C13
Conduzir revises
regulares nos
custos e
modificar o plano
de negcios
em funo das
mudanas.

PP-C21
Tarefas alinhadas
ao fluxo de forma
a evitar trabalho
indireto
desnecessrio.

PP-C22
Processo para
alocar
apropriadamente
os fundos para
custos
administrativos.

PP-K11
Processo para
identificar, de
forma precisa,
o conhecimento

PP-K12
Processo
padronizado para
capturar o
conhecimento
obtido em um
banco de dados
organizado.

PP-K21
Banco de dados
facilmente
acessvel.
(intranet)

DP-K22
Incluir o uso do
gerenciamento do
conhecimento
como um passo
necessrio na
definio de
processos..

Qualidade:
Clientes

Qualidade:
Manufatura

NVEL 3

NVEL 4

Programao

Reduo de
Custo

Melhoria
Contnua

Figura 4.5 Decomposio do Projeto de Desenvolvimento de Produtos PD3

Fonte: Bocanegra (2001).

O PD3 tem cinco requisitos funcionais (RFs) de primeiro nvel. Que so:
RF011 Projetar um produto funcional, que satisfaa os requisitos do cliente
externo;
FR012 Projetar um produto manufaturvel, que satisfaa as necessidades
dos clientes internos;
FR013 Reduzir o tempo total de definio do produto e do processo;
FR014 Garantir que o produto seja rentvel; e
FR015 Garantir a melhoria contnua.
Estes RFs do PD3 fazem uma analogia com a decomposio utilizada na
manufatura. Por exemplo, FR011 e FR012 so considerados como componentes da
ramificao relacionada com a qualidade, que levantam questes associadas a
satisfao de clientes internos (manufatura) e externos (compradores). FR013

54

considerado pertencente ramificao relacionada com a programao, que visa a

eliminar atrasos e reduzir estoque de material em processo. Desta forma o RF014 diz
respeito reduo de custo, pela eficiente utilizao de mo-de-obra direta e indireta,
e o RF015, pela melhoria contnua. Para cada RF, Bocanegra (2001) faz a
decomposio em outras RFs que chama de sub-RFs.
No contexto desta tese, a abordagem PD3 foi til na elaborao da
metodologia proposta por dois motivos: primeiro, porque foi elaborada no mbito da
indstria aeroespacial; segundo, porque oferece uma viso detalhada dos requisitos
componentes das dimenses qualidade, leadtime (tempo de entrega) e custo,
requisitos

estes

utilizados

para

compreenso

de

valor

no

processo

de

desenvolvimento de produtos.
A Decomposio do Projeto do Sistema de Desenvolvimento de Produtos
proposta por Lenz e Cochran (2000), parte do RF-A, que estabelece o seguinte:
definir e projetar um produto manufaturvel. Esta uma abordagem que se
centraliza na integrao das atividades de desenvolvimento de produtos, cujo
objetivo facilitar o processo de projeto de um sistema de desenvolvimento de
produto (ou seja, a organizao do desenvolvimento do produto) e elaborar um
ambiente neutro s questes de projeto. A abordagem de Lenz e Cochran (2000) est
estruturada em quatro ramificaes principais (Figura 4.6): qualidade total do
produto, leadtime de desenvolvimento, custo de operao no desenvolvimento e
investimento no desenvolvimento. Esta estrutura exatamente a mesma utilizada na
decomposio do sistema de manufatura, pois o PD3 usa em analogia com o sistema
de manufatura. Por exemplo, na abordagem de Decomposio do Projeto do Sistema
de Desenvolvimento de Produtos (Lenz e Cochran, 2000), o fluxo da informao
entre os elementos funcionais do desenvolvimento de produtos pode ser visto como o
fluxo de material entre mquinas de um sistema de manufatura.
Na ramificao da qualidade total da abordagem de Lenz e Cochran (2000), o
RF111 (maximizar a qualidade total do produto) satisfeito pelo Parmetro de
Projeto PP111 (arranjo de processo altamente coordenado). O termo coordenado
caracteriza o alinhamento e ajustamento das atividades organizacionais. Os autores
tambm afirmam que qualidade, em desenvolvimento de produto, obtida quando

55

todos os discretos processos de projeto incorporam as restries que limitam seu

escopo. Portanto, nesta perspectiva, qualidade pode ser obtida pela coordenao dos
processos ou atividades do desenvolvimento de produtos.

Qualidade Total
do produto

Tempo de
desenvolvimento

Custo
operacional

Investimento
Integrao
externa

Atividades
casadas
Integrao
interna

Configurao
das atividades
simultneas
de projeto

Figura 4.6 Decomposio do Projeto do Sistema de Desenvolvimento de Produtos

Fonte: Lenz e Cochran (2000).

Para garantir a integrao interna, Lenz e Cochran (2000) reforam a idia da

coordenao do fluxo da informao e do alinhamento das atividades de
desenvolvimento. A integrao por meio do fluxo da informao importante, porm
no oferecer o impacto necessrio no desempenho do desenvolvimento de produtos,
se a informao que dever fluir no for corretamente preparada e estabelecida. No
entanto, a forma como construir o contedo da informao no discutida pelos
autores.
Como se pode notar, a Decomposio do Projeto do Sistema de
Desenvolvimento de Produtos proposta por (Lenz e Cochran, 2000) est preocupada
em apresentar a coordenao das atividades de desenvolvimento e, nisso ela parece
adequada. Entretanto, no oferece respostas no que tange ao gerenciamento dessa
coordenao, ou mesmo, da gesto da implementao desta abordagem. Para esta

56

tese, o foco na contribuio desta abordagem contribuir para a implementao do

princpio do fluxo do valor no desenvolvimento e tambm para a implementao do
princpio do sistema puxado, princpio este de difcil entendimento no contexto de
desenvolvimento de produtos.

4.2.3

A REPRESENTAO DO PDP COM BASE NO FLUXO DO VALOR

A representao do processo de desenvolvimento de produtos aqui

apresentada resultado do trabalho realizado pelo Grupo de Trabalho em

Desenvolvimento de Produtos do Lean Aerospace Initiative LAI do MIT, que
um time multidisciplinar com representantes das industrias de: motores de aeronaves,
estrutura de aeronaves, espao e avinicos. O grupo modelou o processo de
desenvolvimento do produto em termos de fases, explorando suas interfaces,
fronteiras e sadas.
A Figura 4.6 oferece a representao do fluxo do valor em um processo de
desenvolvimento de produtos. Esta representao foi embasada pelo programa de
fases definido pelo IEEE (Institute of Electrical and Electronics Engineers), de
forma a permitir a comparao com outras definies de processos (ver seo 4.2.1).
O modelo proposto foi elaborado para que pudesse ser adaptado aos mais variados
tipos de programas de desenvolvimento.
O fluxo proposto no divide o desenvolvimento dos produtos no que se pode
chamar de fases discretas de programas. Ele procura dividi-lo em fases de dados do
produto que podem ou no ocorrer de modo simultneo com as fases do programa
associado.
Este conjunto de informaes pode ser usado de vrias formas: primeiro,
prov uma linguagem comum para a comunicao entre os mais variados tipos de
programas; segundo, oferece um meio de manter o foco no fluxo do valor por
intermdio das interfaces entre as fases dos programas. Alm do que, prov uma
forma de medir e comparar os processos de desenvolvimento de produtos.

57

Requisitos
do cliente

Negcio da
Empresa
Estratgias
Def.
Sistema

Restries

Requisitos
de Sistema

Atributos do

Projeto
Preliminar

Programa

Requisitos
de Projeto

Padres de
Projeto

Requisitos de

Projeto
Detalhado

Manufatura
FMIT

Padres de
Produo

Projeto
Qualificado

Produo
Produto

Padres de
Suporte

Assistncia
Tcnica
Sistema
Operacional
Valor para
o Cliente
Valor para
Risco

a Empresa

percebido pelo
cliente

Figura 4.7 Representao do Desenvolvimento do Produto, com base no fluxo do

valor
Fonte: LAI (2001).

A descrio da Figura 4.7 define algumas das metodologias que podem ser
utilizadas no mapeamento do fluxo do valor.
O fluxo do valor incia-se com a fase Definio do Sistema que tem como
input um conjunto de requisitos do cliente (basicamente: custo, programao,
desempenho), Posio de Negcios da Empresa (ROI desejado e gerenciamento de
portfolio), e a Posio do Risco para o Cliente. As restries (cultura, avaliaes e

58

treinamento) so aplicadas para que as necessidades dos clientes sejam convertidas

em requisitos de sistema.
A fase de Projeto Preliminar recebe os requisitos de sistema da fase de
Definio de Sistema e aplica os atributos de sistema para desenvolver um conjunto
de informaes de projeto (design-to package). Neste ponto, o risco operacional
mais bem definido de forma a incluir o risco de projeto ou o risco que o projeto do
sistema tem de no ser factvel em funo de restries tecnolgicas existentes. As
atividades desta fase estaro focadas na atenuao dos riscos de projeto.
A fase de Projeto Detalhado recebe o conjunto de informaes de projeto
geradas na fase de Projeto Preliminar e aplica padres de projeto para desenvolver
um conjunto de informaes de manufatura (build-to package). O risco de projeto
definido na fase de Projeto Preliminar ser atenuado durante este etapa, pela
utilizao de tecnologia e mltiplos conceitos de projeto. Com a reduo do risco de
projeto, o risco operacional mais bem definido, incluindo agora o risco de
manufatura e desempenho, ou seja: os riscos de no ser capaz de manufaturar um
produto, ou o risco de no obter o desempenho desejado. Anlises e simulaes
podem ser utilizadas para reduzir esses novos fatores de risco.
A fase FMIT (Fabricao, Montagem, Integrao e Teste) recebe o conjunto
de informaes de manufatura desenvolvido pela fase de Projeto Detalhado e aplica
padres de prototipagem e qualificao para qualificar o projeto. Neste momento, as
fases comeam a ter simultaneidade. Os resultados do teste de qualificao
alimentam diretamente o processo de detalhamento do Projeto. Esta fase tambm
serve como um teste para a reduo dos riscos de manufatura e desempenho. Nesta
reduo de riscos, fatores-chave so a realizao da prototipagem e a forma como
estes prottipos so utilizados no teste de qualificao13. O output desta fase a
qualificao do projeto.
A fase de Produo recebe o projeto qualificado e aplica padres de produo
para gerar um produto. Neste ponto, o risco, geralmente, associado s taxas de
produo.

59

A fase de Assistncia Tcnica prov os recursos necessrios para manter

operacional o sistema do cliente.
O output do processo, como um todo, o valor para o cliente (necessidades
satisfeitas em termos de custo, prazos e qualidade) e valor para a empresa (lucro
desejado, aperfeioamento do portfolio).
Esta representao do processo de desenvolvimento do produto, mesmo no
considerando a necessidade de outros stakeholders (empregados, subcontratados,
organismos homologadores, etc.), est diretamente relacionada com o contexto desta
tese, e pode ser utilizada para identificao do fluxo do valor na metodologia
proposta.

4.2.4

A IMPORTNCIA DO DESENVOLVIMENTO DO PRODUTO

O efetivo desenvolvimento de produtos tem se tornado uma competncia

essencial e tem diferenciado as empresas com foco no cliente das demais empresas
de uma determinada indstria. Os diferentes ambientes nos quais as empresas tm de
operar tornaram-se altamente competitivos, e como conseqncia muitas
organizaes tm se esforado para atender s demandas ambientais. No entanto,
muitas vezes, estas empresas tm fracassado (Morgan, 2002). Neste contexto, alguns
especialistas identificaram o desenvolvimento de produtos como de fundamental
importncia para a sobrevivncia das organizaes nesse ambiente. Segundo
Wheelwright e Clark (1992), existem trs foras fundamentais que criaram este
ambiente j citadas neste trabalho: a intensa competio internacional por
qualidade, custo e prazo; mercados fragmentados e rpidas mudanas tecnolgicas.
Pode-se concluir, portanto, que as empresas precisam diferenciar-se de suas
concorrente baseadas em sua relao com estas trs foras ambientais, e que os
clientes iro usar algum critrio para avaliar esta diferenciao entre os produtos
oferecidos pelas distintas empresas. Um desses critrios ser o valor do produto, ou
seja, a relao entre a utilidade do produto e a disposio do cliente em pagar por ele.
13

Para um melhor entendimento sobre a utilizao de prototipagem, consultar a tese de doutoramento

do Professor Nilton Nunes Toledo (Toledo: 1994) e Clark e Fujimoto (1991).

60

O estudo da criao de valor no processo de desenvolvimento de produtos

requer uma clara identificao, mas como se pde ver na seo 4.2, na literatura no
existe um consenso a respeito de uma definio nica. Desta forma, para efeito desta
tese, de forma genrica as etapas do processo de desenvolvimento do produto foram
definidas, como: conceito, projeto preliminar, projeto detalhado, avaliao e testes.
O processo de desenvolvimento de produtos fixa-se entre dois pontos crticos:
a documentao a respeito dos requisitos do produto gerada no fim do
desenvolvimento conceitual e o pacote de informaes para manufatura (build-to
package) que gerado no final da fase de avaliao e testes. Entre estes dois pontos,
ocorre a transformao das necessidades ou requisitos do cliente em um conjunto de

Incerteza de performance tcnica

instrues que permitir a produo do produto desejado.

Desenvolvimento do
Produto

Desenvolvimento do
conceito

Projeto
preliminar

Projeto
detalhado

Teste e
avaliao

Produo

Suporte

Figura 4.8 Incerteza nas medies de performance tcnicas no ciclo do produto

Fonte: Adaptado de Chase (2001).

A Figura 4.8 utiliza a incerteza14 em avaliaes tcnicas de performance

(ATPs) para ilustrar o processo. ATPs so introduzidas apoiadas na documentao
de requisitos de projeto (A). A incerteza acerca dos resultados esperados eliminada
com a finalizao dos documentos que serviram de apoio para a manufatura (B). Esta
14

A incerteza na ATP a varincia, ou amplitude, associada expectativa de desempenho do produto.

61

reduo de incerteza pode ser comparada criao de valor (Browning, 1998a;

Browning, 2001)
A reduo da incerteza, conforme ilustrado na Figura 4.8 uma das principais
questes que o gerenciamento precisa lidar. Em outras palavras, quando as ATPs
esto definidas, o gerenciamento perde a capacidade de mud-las sem incorrer em
aumentos de custo e programao (Chase, 2001).

4.2.5

COMPLEXIDADE

AS

TRS

DIMENSES

DO

DESENVOLVIMENTO DO PRODUTO
A complexidade do desenvolvimento do produto tem sido o grande obstculo
da maioria das metodologias de melhoria (Chase, 2001), que est alicerada em trs
dimenses do desenvolvimento do produto: produto, processo e arquiteturas
organizacionais. Por exemplo, o desenvolvimento de uma moderna aeronave envolve
dezenas de milhares de itens, milhares de tarefas e milhares de pessoas que se interrelacionam por diferentes organizaes funcionais e corporativas (Eppinger e Ulrich,
1995). O gerenciamento desta complexidade ocorre por meio do desdobramento do
sistema, conforme ilustrado na Figura 4.9. Sistemas complexos so sucessivamente
divididos em partes menos complexas, at que eles se tornem simples o suficiente
para serem dominados (NASA, 1995 apud Chase, 2001).

4.2.5.1 O Produto
A decomposio de um produto resulta em algo que se pode chamar de
arquitetura do produto, que, por sua vez, estabelecida durante a fase de projeto
preliminar. O mtodo para categorizar cada elemento desta arquitetura varia entre as
organizaes. Uma representao proposta a de (Eppinger, 2001), no qual o
desdobramento de um produto tem a seguinte hierarquia: sistema, subsistema e
componente. A seleo de uma arquitetura especfica para um produto pode ter
algumas implicaes, como por exemplo, afetar a desempenho do produto, as

62

alteraes, sua variedade do produto, a padronizao de componentes e a

manufaturabilidade (Ulrich e Eppinger, 1996).
O problema de determinar a arquitetura do produto ilustra o conflito entre o
valor para o produto e o valor para o processo. Ao produto, selecionar a melhor
arquitetura representa valor, entretanto, os resultados da deciso no sero
conhecidos at que seja tarde demais para que uma nova arquitetura seja proposta.
Portanto, o valor para o processo ou a seleo do melhor processo, deve ser
enfatizado no desenvolvimento do produto. Em manufatura, o produto pode ser
avaliado (como por exemplo, pela metodologia seis sigma15), mas em
desenvolvimento, o processo deve ser a base das avaliaes.

Arquitetura do
Produto

Arquitetura do
Processo

Valor

Arquitetura do
Organizacional

Figura 4.9 Gerenciando a criao de valor no desenvolvimento de produto

Fonte: Adaptado de Chase (2001).

4.2.5.2 O Processo
Quando se pensa no desdobramento do processo, comum raciocinar em
termos de diviso do trabalho. Nesta diviso, so representadas as atividades, no
nvel de equipe, e as tarefas, no que tange ao trabalho individual. Normalmente,

15

A metodologia seis sigma foi desenvolvida pela Motorola e tem como objetivo a reduo da
variabilidade no resultado entregue aos clientes, a uma taxa de falhas de 3,4 por milho.

63

vrios documentos esto relacionados com esta diviso do trabalho como, por
exemplo, estrutura de custos, programaes e requisitos de produtos. A associao
entre a arquitetura do processo com custo e a programao cria um ambiente propcio
a medies. Por este motivo, muitos dos esforos para a implementao de princpios
enxutos acabam focados mais no desenvolvimento de processos, do que no produto
ou na organizao (McManus e Harmon, 2001).

4.2.5.3 A Organizao
At recentemente, as empresas do setor aeroespacial eram organizaes
funcionais (Chase, 2001) a Embraer um destes exemplos16 onde os empregados
passam a maior parte de seu tempo ao lado de outros empregados que compartilham
a mesma rea de conhecimento de engenharia. Isto levava ou leva a alguns
problemas que podem ser citados: times de produto fracos e uma comunicao pobre
entre os setores. Uma abordagem focada em times de produto pode eliminar esses
problemas (Pomponi, 1998; Browning, 1997b; Browning, 1999; Thomson, 1997),
porm pode sacrificar a gerao de conhecimento nas diferentes reas. Este dilema
desperta o interesse pelo uso de estruturas matriciais que caracterizam, hoje, a maior
parte das indstrias aeroespaciais. Nas organizaes matriciais, empregados dividem
suas responsabilidades entre grupos funcionais (tais como grupos de aerodinmica,
estruturas e garantia da qualidade) que interagem por intermdio de times integrados
de desenvolvimento. Em um programa complexo, como o do Boeing 777, podem
existir mais de 200 times de desenvolvimento, os quais estaro envolvidos nas
diversas fases do ciclo de desenvolvimento do produto (Condit, 1996 apud Chase
2001).
No que se refere ao estudo do valor, os times integrados de desenvolvimento
so importantes, pois representam o ambiente onde distintos grupos funcionais
tomam decises conjuntas para o projeto do produto e para o plano de manufatura.
Estas decises conjuntas proporcionam a reduo da incerteza ou varincia das
Avaliaes Tcnicas de Performance (ATPs).
16

Ver caso da Embraer, narrado por Bernardes (2000).

64

4.3

4.3.1

PRINCPIOS E PRTICAS ENXUTAS

A HISTRIA DO TERMO ENXUTO

John Krafcit, ento um estudante da Sloan School of Management do MIT e

um pesquisador no Programa Internacional de Veculo Motor, foi o primeiro a usar o

termo sistema de produo enxuta. Em sua dissertao de mestrado, destacou que a
produo enxuta utilizava menos recurso quando comparada com a produo em
massa menos recursos humanos na fbrica, menos espao, menos investimento em
ferramentas e menos horas de engenharia para desenvolver um novo produto. Isto
torna possvel a produo de uma grande variedade de produtos de alta qualidade em
menos tempo. Mas, o termo produo enxuta foi introduzido para uma comunidade
mais ampla por James Womack, Daniel Jones e Dan Roos em A Mquina que
Mudou o Mundo. O livro resume um trabalho de cinco anos realizado pelo
Programa Internacional de Veculo Motor.
A mentalidade enxuta, oriunda desses esforos anteriores, est embasada na
eliminao de Muda que uma palavra japonesa cujo significado desperdcio.
Mais especificamente, o Muda relaciona-se com qualquer atividade humana que
absorve recursos e no cria valor.
Womack e Jones (2003) iniciam o captulo que trata sobre valor, com o
seguinte questionamento: por que to difcil comear do ponto certo, no que tange
definio de valor? Os prprios autores explicam: Parcialmente porque a maioria
dos produtores quer continuar produzindo o que sempre produziram e, parcialmente,
porque muitos consumidores s sabem solicitar algo que seja uma variante daquilo
que esto acostumados a obter. Desta forma, mesmo que represente um desafio,
valor, para efeito desta tese, ter a seguinte definio bsica: a capacidade de prover
a um cliente um produto que ele deseja no tempo certo, a um preo adequado e
conforme definido pelo cliente em cada caso.

65

A Mquina que Mudou o Mundo foi publicada em 1990 por Womack,

Roos e Jones, todos os trs membros do International Motor Vehicle Program do
MIT, alterou de forma radical o pensamento sobre a indstria automobilstica. A
partir deste trabalho, o maior e mais profundo estudo de caso j realizado na indstria
automobilstica, o conceito enxuto foi mundialmente conhecido. O objetivo deste
estudo de caso foi comparar diversas empresas que trabalhavam com o sistema
tradicional de produo de automveis com o Sistema Toyota de Produo (STP)
(Salzman, 2002).
O Sistema Toyota de Produo, agora muito associado ao termo enxuto ou,
at mesmo, ao o princpio Just-in-time, j havia sido desenvolvido pela indstria de
carros japonesa nos anos 50, quando esta indstria passava por um momento de crise.
Neste perodo, ficou claro para a indstria japonesa que a nica forma de escapar de
uma derrocada era a implementao drstica de mudanas na eficincia e
produtividade (Salzman, 2002).
Neste momento que surgiram as teorias e princpios da manufatura enxuta,
uma filosofia de produo que est focada no fluxo das atividades que agregam valor
e na eliminao do desperdcio nos processos com o objetivo de melhor atender a
demanda do cliente. Alm disso, representa uma abordagem consistente e holstica
que tem sua origem na cultura japonesa, podendo incluir, por exemplo, a atitude das
pessoas com relao a conservao de material, mas tambm representa a orientao
que esta cultura tem para o cl. Estes so fatores que facilitaram a implementao de
polticas de controle de material e tambm o trabalho em equipe, que fundamental
para o treinamento dos funcionrios e o gerenciamento da qualidade total (Salzman,
2002). Outro fator que exerceu importante papel foi a proximidade com
fornecedores, o que proporcionou entregas de matrias-primas em pequenos lotes e
com maior freqncia.
Com o avanar do tempo, os princpios da manufatura enxuta foram adotados
por diversos setores da indstria, tais como: aerospacial, produtos de consumo,
metalrgicas e produtos industriais (Spear e Bowen, 1999). Mesmo diante da
inexistncia de sigilo por parte da Toyota com relao s suas prticas, somente
algumas empresas de manufatura conseguiram gerenci-las no sentido de imit-las,

66

ou mesmo, implement-las. Isto no causa surpresa, pois, quando o Sistema Toyota

de Produo observado mais proximamente, torna-se possvel entender que o
sucesso desta abordagem no fruto apenas da implementao das prticas
identificadas, funes de controle e ferramentas, tais como: sistema puxado, kanban,
sinalizao andon ou quadros de controle visual. Ao contrrio, a abordagem fruto
da coerncia e harmonia entre a estrutura, a organizao e a mentalidade das pessoas
sobre como arranjar e realizar as tarefas. Spear e Bowen (1999) chamaram este
fenmeno de DNA do Sistema Toyota de Produo e sugerem um conjunto de
regras que o descrevam.
Como j citado por Spear e Bowen (1999), desde a publicao do estudo de
caso de A Mquina que Mudou o Mundo, em 1990, um grande esforo foi feito
por empresas no sentido de adotar os princpios da manufatura enxuta nos mais
diversos segmentos de negcios. A General Electric, por exemplo, procurou
implement-la de forma a entregar 100% de suas encomendas dentro do prazo.
Outras companhias conseguiram reduzir os espaos ocupados nas fbricas em 50% a
97,3% e/ou melhoraram seu tempo de ciclo em 60% a 80%. (Salzman, 2002)
Desde que se comeou a estudar a abordagem enxuta, gradualmente
percebeu-se que o sucesso do sistema no estava limitado apenas manufatura. Ele
poderia ser expandido a outros setores da organizao, proporcionando uma
potencial reduo de custos e melhorias de qualidade. Alinhado a esta idia, este
trabalho procura oferecer uma nova abordagem para o processo de desenvolvimento
de produtos. As pesquisas atuais lidam com a aplicabilidade de princpios e
ferramentas de melhoramento enxuto para diferentes reas de negcios, mas tentam
tambm se desenvolver e ir alm com novas idias baseadas na abordagem enxuta.
Uma dessas reas de negcios o desenvolvimento de produto, foco desta tese. Em
razo de sua natureza particular de alta incerteza e risco e baixa repetitividade,
quando comparado a processos de manufatura, a realizao dos princpios enxutos, a
aplicao de ferramentas especficas para este fim, assim como o desenvolvimento
de outras novas, tornam-se ainda mais desafiadoras.

67

4.4

O PENSAMENTO ENXUTO
No incio do ano de 1998, um grupo de gerentes, engenheiros e lderes de

fornecedores da indstria aeronutica realizaram um workshop sobre a integrao da

cadeia de suprimentos. Durante o evento, o grupo comeou a questionar sobre como
trabalhar o conceito enxuto com novos fornecedores: qual o primeiro passo a ser
tomado? O que viria depois? Ao ser indagado, um dos integrantes do grupo, Hajime
Ohba, no quis estabelecer uma receita de bolo. Ele disse o seguinte: enxuto no
um termo que representa uma lista de coisa a fazer e, sim, uma forma de pensar
(Murman at. al., 2002). Complementando esta afirmao, Ohba esclareceu que antes
de comear a pensar nos passos a serem tomados em direo a um estado
considerado enxuto, dever-se-ia interagir com cada fornecedor e entender como cada
um desses fornecedores enxerga seu prprio sistema produtivo. S aps esta
verificao que se poderia pensar em termos de como executar a implementao de
princpios e prticas enxutas.

4.4.1

A DEFINIO DO PENSAMENTO ENXUTO

A definio do termo enxuto, j tratada no captulo 4 desta tese, est centrada

em duas dimenses principais: eliminar os desperdcios e criar valor. Ambos, so

elementos essenciais que o pensamento enxuto deve incorporar. Centralizar
exclusivamente na eliminao dos desperdcios cortando custos insuficiente e
pode no ter o retorno esperado nas vendas. Por outro lado, focar exclusivamente na
criao de valor, torna-se igualmente insuficiente, pois, muitas das oportunidades de
melhoria s se tornam visveis aps o esforo para eliminao de desperdcios (como
o excesso de material estocado, inspees redundantes e engenharia seqencial).
Que tipo de pensamento deve ser orientado a estas dimenses? Segundo
Murman at. al. (2002), a definio o pensamento enxuto, que foi definido da
seguinte forma:

68

O pensamento enxuto um processo dinmico, orientado

pelo conhecimento e focado no cliente, atravs do qual todas
as pessoas em uma determinada empresa eliminam
desperdcios com o objetivo de criar valor (Murman et. al. ,
2002).

Ao se analisar esta definio, percebe-se a existncia de uma srie de

conceitos em cada uma de suas linhas. Desta forma, sero feitas breves
consideraes sobre cada um desses conceitos.

4.4.1.1 Processo Dinmico

O pensamento enxuto dinmico, evoluiu durante dcadas e continua
evoluindo. O conceito de melhoria contnua, tambm chamado de kaizen, tornou-se
uma das maiores crenas do sistema de produo enxuta que comeou com a Toyota
e continua sendo central para o pensamento enxuto. Em japons, kaizen significa
melhoria de desenvolvimento, baseado no conhecimento de qualquer pessoa
envolvida, gerentes ou operrios, e no apenas no dos experts. A melhoria contnua
um processo de soluo de problemas que requer utilizao de uma srie de
ferramentas, mtodos e prticas (crculos de controle da qualidade, TPP total
produtive maintenance, JIT Just-in-Time e Kanban). A abordagem kaizen, que
envolve o aprendizado por meio da realizao de atividades, utiliza a idia do
pensamento baseado em processos para o alcance do fluxo contnuo de melhorias.
Isto s possvel por intermdio da educao sistemtica dos trabalhadores e pela
conscientizao do trabalho em equipe. O importante a ser destacado aqui que a
idia de melhoria contnua no deve excluir a oportunidade de implementao de
melhorias completamente inovadoras. Ou seja, tanto a inovao como o kaizen so
elementos importantes para a sobrevivncia e crescimento de uma empresa
(Kilpatrick, 1997).

69

4.4.1.2 Orientao por Intermdio do Conhecimento

O pensamento enxuto exigir o esforo e as idias de toda a fora de trabalho,
isto porque a eliminao de desperdcios e a criao de valor no se daro de forma
eficiente sem os inputs da linha de frente dos trabalhadores, integrantes do time de
engenheiros de projeto, pessoal administrativo e qualquer outro que tenha contato
com o produto durante sua realizao, desenvolva projetos ou faa servios de
entrega. O que leva a reconhecer o papel crtico das pessoas, no apenas dos
processos na criao do valor (Pomponi, 1998).
Portanto, um aspecto chave do pensamento enxuto repousa na idia de que
todo conhecimento, informao e insights para a eliminao de desperdcios e
criao de valor, provenientes da fora de trabalho, clientes, fornecedores ou
qualquer outra fonte considerada devero ser apreciados. Conseqentemente, tornase necessrio investir em treinamento de habilidades tcnicas e sociais (processos de
grupo, comunicao, negociao, liderana, etc.). Estabelecer uma estrutura
disciplinada para o trabalho um dos fundamentos dos esforos de melhoria17.

4.4.1.3 Foco no Cliente

Em um sistema enxuto, o cliente prov orientaes que sero propagadas por
toda a empresa, representando o que se pode chamar de norte verdadeiro. As
necessidades e expectativas do cliente agem de forma a puxar as atividades da
empresa, desde o projeto do produto e manufatura at sua colocao no mercado e
posterior suporte18. Contudo, no uma idia abstrata de somente servir ao cliente,
mas, sim, um conjunto disciplinado de prticas de trabalho projetado para dar aos
clientes o produto ou servio certo, no tempo e preo adequado.
A idia do sistema puxado pode reduzir problemas operacionais de produo
como, por exemplo, a reduo do acmulo de produtos em processo. Com relao ao
processo de desenvolvimento de produtos, observar-se o impacto do foco no cliente

17
18

Para maiores detalhes, consultar Morgan (2002).

O conceito de sistema puxado foi introduzido no captulo 4 desta tese.

70

pela da variedade de novos produtos e pela necessidade de reduo do tempo de

desenvolvimento.

4.4.1.4 Eliminao de Desperdcios

Com o objetivo de centralizar suas atividades nos clientes, as empresas
precisam eliminar todas as formas de desperdcio. Tradicionalmente, estes
desperdcios incluem: superproduo, estoques de produtos em processo e passos a
mais no processo19. Eliminar desperdcios no importante apenas para cortar
custos, mas tambm para melhorar a qualidade, segurana e tempo de resposta s
mudanas de mercado.
Segundo Murman et. al. (2002), a ligao entre prtica enxuta e tempo de
resposta no , normalmente, apreciada e entendida. Mas, a eliminao de
desperdcios pode ser uma importante forma de reduo de tempo de ciclo, seja de
produo ou de desenvolvimento, por meio da eliminao de passos desnecessrios e
que no adicionam valor. Em uma empresa enxuta, eliminar aquilo que no agrega
valor, mais importante que a realizao de tarefas individuais. Em outras palavras,
processo enxuto no acelerar o trabalho, mas realiz-lo de uma forma mais
inteligente.

4.4.1.5 Criao de Valor

Empresas convivem com vrios agentes interessados em seus resultados, os
quais chamamos de stakeholders, Estes stakehlders podem ser: clientes externos e
internos, funcionrios em geral, fornecedores, acionistas e vrios outros, incluindo
comunidades e pblico em geral. Cada grupo de stakeholders tem as suas vises
relativas sobre valor que s vezes so comuns, s vezes complementares e algumas
vezes podem representar pontos de divergncia. Como exemplo podemos citar:
clientes, podem estar preocupados com a qualidade; sociedade e a fora de trabalho,
com a segurana; acionistas com os aumentos de demanda, este ltimo, pode ser

71

conflitante com a estabilidade de longo prazo desejada pela fora de trabalho e

comunidades.
Como observado no captulo 4 desta tese, as muitas dimenses de valor
promovem uma transformao do que seria o entendimento do conceito enxuto.
Porm, o que importa neste momento da pesquisa que o pensamento enxuto
envolve um aprendizado no que se refere visualizao do que valor. Uma
poderosa ferramenta para esta visualizao o mapeamento do fluxo do valor
tratado no item 6.4 deste trabalho que coloca as atividades que criam valor em um
determinado processo em seqncia, e todas aquelas que no criam valor so
consideradas desperdcios e, consequentemente, devem ser eliminadas. Portanto, a
mentalidade enxuta envolve tanto a eliminao de desperdcios quanto a
identificao de melhorias que auxiliaro na criao de valor para um ou mais
stakeholders.

19

Os desperdcios especficos no desenvolvimento de produtos foram detalhados no captulo 4 desta

tese. Para maiores informaes sobre a eliminao de desperdcios, consultar Bauch (2004).

72

4.5

OS CINCO PRINCPIOS ENXUTOS

Enxuto enxuto desde o momento que proporciona uma forma de fazer mais

com menos e cada vez menos. Isto significa dizer: utilizar menos esforo humano,
menos equipamento, menos tempo e menos espao, ao mesmo tempo em que realiza
produtos que os clientes realmente desejam, facilitando, desta forma, o aumento do
valor e simultaneamente a reduo de desperdcios. (Womack e Jones: 2003).
Importantes recomendaes contra desperdcios so obtidas em Womack e
Jones (2003), que sugerem uma forma de especificar valor, alinhar aes na melhor
seqncia, de forma a criar valor, conduzir, quando estas atividades so solicitadas,
sem interrupes para realiz-las de forma cada vez mais eficiente, eliminando,
consequentemente, atividades consideradas desperdcios. Comparada a outras
medies para racionalizar o fluxo do trabalho, que simplesmente reduzem tarefas,
esta abordagem cria outras novas tarefas e torna o trabalho mais satisfatrio s
pessoas por meio de feedback imediato de esforos para converter desperdcios em
valor.
Para Womack e Jones (2003), a aplicao dos cinco princpios enxutos nos
processos e em toda a empresa conduzir ao que eles chamam de estado "enxuto".
Este estado enxuto resultante da eliminao de desperdcios nas operaes, de tal
forma que os produtos possam ser desenvolvidos com uma mnima parcela dos
custos totais de material, tempo e esforo humano.
Estes princpios so:

Princpio do Valor: especificar de forma precisa o valor;

Princpio do Fluxo do Valor: identificar o fluxo do valor;

Princpio do Fluxo: fazer com que o valor identificado flua;

Princpio do Sistema Puxado: deixar que o consumidor puxe o valor; e

Princpio da Perfeio: esforo a perfeio.

73

4.5.1

O PRINCPIO DO VALOR
Para Bauch (2004), fornecer ao cliente o produto errado, seja este um bem ou

um servio, significa desperdcio, mesmo que o processo per se esteja sendo

realizado de forma correta ou no. Com o objetivo de prevenir este desperdcio, o
primeiro passo no pensamento enxuto deve ser uma anlise do contato com
consumidores especficos para entender suas necessidades particulares em
determinado momento e o quanto eles esto dispostos a pagar por isto. Uma vez que
as necessidades desses consumidores foram identificadas, torna-se mais fcil definir
o valor em termos de propriedades fsicas e preos especficos.
Para acompanhar este primeiro objetivo, devem ser ignorarados ativos e
tecnologias existentes e introduzir equipes mais fortes e dedicadas, ou seja, o foco
passa a ser nas pessoas. Mas, a realidade mostra, diferentemente, que a especificao
e a criao de valor aos clientes so subjugadas pelas necessidades imediatas dos
acionistas, prevalecendo as questes financeiras da alta gerncia. Outra questo
consiste no importante papel dos experts tcnicos, que podem resultar em projetos
complexos, customizados, com sofisticados delineamentos de tecnologia de
processo, que acabam excedendo o oramento dos clientes, alm do que, raramente,
alcanam suas reais necessidades. (Womack e Jones, 2003).
Embora seja quase irreal que empresas possam implementar tais mudanas
com sucesso do dia para noite, importante para elas consigam um claro
entendimento do que realmente so as necessidades dos consumidores. Tendo em
vista que os processos de negcios de uma empresa podem ser considerados como
uma extensa rede de trabalho, com relaes cliente/fornecedor, o princpio de valor
tambm pode ser aplicado aos clientes internos.
Womack e Jones (2003) enfatizam a necessidade de se expressar o valor em
termos de um produto especfico que atenda s necessidades dos clientes para um
determinado preo e em um tempo especfico. No sentido de se definir, o que se
entende por valor especificamente no processo de desenvolvimento de produto,
apropriado fazer uma reviso da literatura em diferentes contextos que no o de

74

desenvolvimento de produtos. De acordo com Ferreira (1993), o termo valor tem,

dentre vrias, as seguintes definies:
a) Qualidade pela qual determinada pessoa ou coisa estimvel em
maior ou menor grau; mrito ou merecimento intrnseco; valia;
b) Importncia de determinada coisa, estabelecida ou arbitrada de
antemo; e
c) Maior ou menor apreo que um indivduo tem a um determinado bem
ou servio, e que pode ser de uso ou de troca.
Com relao ao objetivo deste trabalho e baseado na definio (a) acima,
valor representa o quanto o bem ou o produto a ser produzido ser estimado pelo
consumidor. Isto s ser alcanado pela correta interpretao e traduo de suas
expectativas no processo de desenvolvimento do produto e, conseqentemente, no
produto que ser fruto deste desenvolvimento.
A afirmao (b) vai ao encontro deste trabalho no sentido que pressupe
aes proativas na determinao do que importante em um determinado produto.
Isto pode ser obtido com o uso de ferramentas especficas para determinao da
importncia relativa das necessidades dos consumidores no desenvolvimento do
produto.
Estas definies, incluindo a (c), representam a viso que se deve ter da real
utilidade do produto para um determinado propsito e importncia. Para efeito deste
trabalho, ser seguida uma definio inicial proposta por Slack:

Valor medida da importncia que um consumidor estabelece

para um determinado produto ou servio. E uma funo entre a
utilidade do produto em satisfazer a necessidade de um cliente, a
importncia relativa desta necessidade a ser satisfeita e o custo de
troca para o consumidor. (Slack, 1998, p. 71)

75

4.5.2

O PRINCPIO DO FLUXO DO VALOR

O prximo passo no pensamento enxuto identificar o fluxo atual de valor,

por exemplo, o conjunto de atividades exigidas para a produo de um produto,

independentemente se este seja um bem ou um servio ou uma combinao de
ambos. Este tipo de abordagem aplica-se aos trs maiores campos das atividades de
negcios (Womack e Jones, 2003).

Soluo de Problemas: desde o conceito, passando pelo projeto at o

lanamento;

Gerenciamento da Informao: desde o pedido, passando pelo

detalhamento de programao at a entrega do pedido; e

Transformao Fsica: desde a matria-prima at o produto acabado.

Para Bauch (2004), o ponto chave da anlise do fluxo de valor observar o

fluxo do valor por completo em cada produto ou famlia de produto, comeando com
o primeiro fornecedor da cadeia at o cliente final. Este procedimento est baseado
em uma viso holstica que vai alm de uma nica empresa. Uma vez que uma
empresa decide faz-lo, ela descobre vrias atividades que no agregam valor e que
podem ser chamadas de desperdcio.

Atividades de Criao de Valor (ACV): a pintura de um carro ou a

montagem de um parafuso;

Atividades Necessrias, mas que No Criam Valor (ANNCV): inspeo da

pintura para garantir a qualidade; e

Atividades que No Criam Valor (ANCV): Atividades que podem ser

eliminadas imediatamente.

Na literatura, este tipo de abordagem completa chamada Empresa Enxuta.

Uma das razes pelas quais as empresas ainda evitam esta abordagem est
relacionada com a confidencialidade e o temor de revelar informaes sobre
processos e custos internos que poderiam ser, de alguma forma, utilizados por
parceiros a montante ou a jusante. Concentrar-se no prprio negcio e no no fluxo

76

do valor como um todo, incluindo as conseqncias de suas atividades internas para

as demais empresas componentes do fluxo, o resultado deste temor.
Esta atitude tem provado ser muito perigosa em uma era em que as empresas
esto cada vez mais terceirizando ou subcontratando atividades em funo do
aumento da complexidade do produto e da reduo do tempo de ciclo. Este
desenvolvimento, ao contrrio, deveria exigir uma aliana voluntria de todas as
partes envolvidas com o intuito de avaliar cada passo na criao de valor, de forma a
detectar e prevenir rupturas no fluxo do valor (Womack e Jones, 2003).
Isto exige uma mudana de mentalidade acerca das relaes e redes de
trabalho nos negcios e o estabelecimento de algumas regras simples para regular
como as empresas interagem umas com as outras. A transparncia dos passos do
processo ao longo do fluxo do valor pode ser uma das questes-chave desde que no
ajude somente a sincronizar as atividades de criao de valor, mas permita tambm
aos participantes verificarem se as demais companhias esto agindo, conforme as
regras acordadas entre elas.
Para Slack (1998), o segundo princpio enxuto pode ser definido como o
conjunto de todas as aes exigidas para conduzir um produto por meio de um
gerenciamento crtico de tarefas de um negcio especfico. Uma importante distino
comparada com outras perspectivas de processo que o fluxo de valor focado em
um nico ou especfico produto, em oposio s perspectivas baseadas em processos
agregados.

4.5.3

O PRINCPIO DO FLUXO
Depois de especificar o valor, mapear o fluxo do valor e eliminar as

atividades que no agregam valor, o prximo passo no pensamento enxuto consiste

em fazer fluir as atividades que criam valor. Este um passo crtico, pois requer uma
mudana de mentalidade. Como exemplo, a idia de lotes que devem migrar para
uma idia de fluxo contnuo.

77

Uma das primeiras pessoas a perceber a importncia potencial do fluxo foi

Henry Ford e seus parceiros em 1913. Aplicando o princpio do fluxo contnuo na
linha de montagem, Ford pde reduzir o esforo da montagem do Modelo T da Ford
em 90%. Mesmo que este tenha sido um resultado significativo, foi apenas um caso
especial desde a abordagem de Ford:
Trabalhar somente quando os volumes de produo forem
elevados o suficiente para justificar linhas de montagem com alta
velocidade, quando os produtos utilizarem exatamente as mesmas
partes e quando o mesmo modelo tiver que ser produzido por
vrios anos. (Womack e Jones, 1996).

Em contraste, Bauch (2004) enfatiza que a introduo do fluxo contnuo na

produo de baixo volume quando somente algumas dzias ou centenas de um
certo produto so necessrias revela-se um grande desafio. Isto, porm, representa
um caso geral e descreve de forma mais precisa a situao real das demandas dos
clientes. Ainda, segundo Bauch (2004), alguns pesquisadores reconheceram este
desafio e trabalharam em estratgias e tcnicas para alcanar o fluxo contnuo na
produo de pequenos lotes, na maioria dos casos sem a utilizao de linhas de
montagem. Isto foi possvel por meio do domnio da troca rpida de ferramentas de
um produto para o prximo, e/ou miniaturando mquinas de forma que as etapas
processadas nos diferentes estgios de produo, tais como: modelagem, pintura,
montagem, etc. pudessem ser realizadas, fisicamente, mais prximas. Para isto
algumas pessoas envolvidas com as prticas enxutas aplicaram kaikaku, que uma
espcie de melhoria radical, comparado com o kaizen que significa melhoria
incremental contnua. Nestes casos, as atividades de produo para um determinado
produto foram rearranjadas de departamentos e produo em lotes para o fluxo
contnuo, que no s dobraram a produtividade como tambm reduziram de forma
substancial os erros e as sobras de material.
Mesmo que abordagens de reengenharia tenham tentado dar mais foco ao
processo de criao de valor no se preocupando com departamentos ou categorias
organizacionais, os conceitos ainda partem da idia de agregar e desagregar
processos. Por exemplo, as aes de emisso de pedidos realizadas para um conjunto
de produtos, ao invs de alinhar o fluxo completo para criao de valor de um

78

determinado produto (Womack e Jones, 1996). Com freqncia, vrias abordagens

esbarram nas barreiras organizacionais e no integram os fluxos de valor dos
parceiros a montante e a jusante do processo.
O objetivo do princpio do fluxo consiste em redefinir o trabalho ou funes,
departamentos e empresas, de forma que eles possam contribuir de forma positiva
para a criao de valor e alcanar as reais necessidades do processo em todos os
pontos do fluxo do valor. Tornando-o, assim, de interesse de todos (Womack e Jones,
1996).
Para realizar isto com sucesso, no requer somente focar em um determinado
produto ou servio e criar uma empresa enxuta para cada um. preciso repensar as
fronteiras tradicionais do trabalho, funes, departamentos, empresas, prticas e
ferramentas de um trabalho especfico, a fim de eliminar refluxos, desperdcios e
paradas de qualquer tipo e, ento, tornar o fluxo mais suave.
Uma vez que empregados e gerentes comeam e pensar em termos de fluxo e
aprender a v-lo, torna-se tambm possvel aplicar o fluxo para qualquer atividade
realizada. Em princpio, o procedimento em cada caso ser o mesmo (Womack e
Jones: 1996):

Concentrar-se no gerenciamento do fluxo de valor para um produto ou

servio especfico;

Eliminar barreiras organizacionais pela da criao de uma empresa

enxuta;

Realocar as ferramentas e utiliz-las com tamanho adequado; e

Aplicar o complemento total das tcnicas enxutas de forma que o valor

possa fluir continuamente.

A organizao do trabalho por lotes ou bateladas inibe este fluxo psicolgico;

assim, o trabalhador s consegue perceber uma parte da atividade, exatamente aquela
que ele executa. comum no se ter o conhecimento exato se esta parte da atividade
foi corretamente executada, ou mesmo, saber o status do sistema como um todo; ao
mesmo tempo em que as habilidades e concentrao exigidas do operador so

79

mnimas. Isto provoca freqentes interrupes de outras atividades pelas quais os

operadores tambm so responsveis. Como resultado, uma organizao que foca no
fluxo contnuo do trabalho e do valor, deve tambm se preocupar com o fluxo
psicolgico (Bauch, 2004). O desafio de sustentar no s um fluxo suave sem
interrupes, mas tambm o foco na perfeio, coloca o sistema em um estado de
tenso que exige concentrao por parte de cada trabalhador e/ou de todo o time
(Womack e Jones, 2003).

4.5.4

O PRINCPIO DO SISTEMA PUXADO

O pensamento enxuto, contudo, no se preocupa somente com a questo de

como prover os bens e servios desejados pelo cliente, ele volta-se tambm a provlos quando os clientes o desejarem.
A estratgia subjacente o princpio da produo puxada que significa
deixar o cliente puxar o produto da empresa quando necessrio, ao invs de empurrar
os produtos para o cliente, provocando o acumulo de estoque. Ainda que olhando
inicialmente ao cliente final, este princpio se aplica ao longo de todo o fluxo de
valor e, portanto, significa que nenhuma estao a montante do processo deve
produzir um bem ou um servio sem que antes a estao a jusante o solicite.
Para que isto ocorra essencial que o princpio do fluxo seja realizado, o qual
poder reduzir de forma significante os tempos de liberao no desenvolvimento de
produto, no processamento de ordens e na produo fsica. (Womack e Jones, 2003).
Isto cria alta flexibilidade e tambm habilidade para projetar, programar e produzir
exatamente o que os clientes desejam e quando eles desejam. Adicionalmente, o
curto tempo de resposta demanda do cliente possibilita aumentar o retorno sobre o
investimento e reduzir estoques a um nvel mnimo em um complexo ambiente de
produo e fluxo de valor.
Para Womack e Jones (2003), a chave deste princpio pode estar no rpido
ressuprimento para o prximo nvel no sistema, o que torna possvel a reordenao
em pequenos lotes. Ferramentas especiais para controlar este ressuprimento e
otimizar os inventrios so, por exemplo, o kanban e o JIT (just in time).

80

O que na teoria pode ser de fcil compreenso e entendimento na prtica pode

ser mais complicado e pode consumir um tempo razovel para implementao
(Bauch: 2004).

4.5.5

O PRINCPIO DA PERFEIO
O ltimo princpio enxuto alcanar a perfeio. Conseguir a perfeio

implica melhoria de processos e aumentos sucessivos de eficincia. Por exemplo, a

indstria aumenta com sucesso em 30% a eficincia de alguns processos, toda vez
que estes processos so revistos (Womack e Jones, 2003). Os autores tambm
argumentam que a transparncia e o acesso irrestrito a dados so os mais importantes
mecanismos para se alcanar a perfeio e que isto cria um ambiente onde se torna
fcil a descoberta de melhores formas de criar valor.
A perfeio , ento, o estado futuro do fluxo do valor depois da eliminao
de todos os mudas; a viso desenvolvida durante a aplicao dos quatro princpios
anteriores. A perfeio tambm pode ser entendida como o estado em que cada
atividade na empresa cria valor para o cliente. Este trabalho, no sentido de se
alcanar a perfeio, envolve a contnua execuo tanto de melhorias incrementais
(kaizen) como de melhorias radicais (kaikaku) no fluxo do valor. Isto pode ser
facilitado pelo desdobramento de polticas (Slack, 1998). Este desdobramento
envolve a direo e liderana da alta administrao no que tange seleo de
objetivos, projetos, recursos e programaes para a iniciativa de melhorias.
Assim, pode-se observar que os quatro princpios anteriores interagem entre
si, de forma que melhorias em um deles, freqentemente, conduziro melhoria dos
demais. Por exemplo, equipes de produto que esto diretamente em contato com
clientes encontram formas melhores e mais consistentes de definir valor para os
clientes e, portanto, tambm encontram novas formas de aperfeioar as tcnicas de
fluxo e de sistema puxado. Neste contexto, outro aspecto que diz respeito s novas
tecnologias em manufatura, que freqentemente revelam novas formas de aumentar o
valor e eliminar desperdcios.

81

4.6

OS PRINCPIOS ENXUTOS NO AMBIENTE DE DESENVOLVIMENTO

DE PRODUTOS
Esta talvez tenha sido a parte da tese que apresentou mais dificuldades em sua

elaborao. Isto se deveu ao fato de que o assunto representa uma linha de pesquisa
recente e, conseqentemente, com poucos trabalhos cientficos especficos sobre
princpios enxutos no processo de desenvolvimento de produtos. Por outro lado, esta
escassez lanou um desafio maior ao pesquisador, no sentido de, dentro das
limitaes que o tema imps, obter material relevante para compor o referencial
terico necessrio a esta pesquisa.
Um nmero significativo de exemplos de aplicao e discusso dos princpios
enxutos tem sido amplamente focado na rea da manufatura, sobretudo no que tange
ao fluxo de valor. Segundo Slack (1998)20, existem exemplos na indstria onde estes
princpios conseguiram transformar com sucesso empresas de manufatura.
Entretanto, os processos utilizados na manufatura e no processo de desenvolvimento
de produtos so diferentes, assim como existem diferenas no produto que estes
processos produzem. O problema a ser estudado como princpios enxutos, que tm
facilitado, na manufatura, a transio para um estado enxuto, podem ser aplicados de
forma efetiva no processo de desenvolvimento de produtos?
O objetivo desta etapa do trabalho foi ampliar o entendimento dos princpios
enxutos e de como estes se relacionam com o processo de desenvolvimento de
produtos. Como a perspectiva do cliente o ponto central para estes princpios, o
objetivo incluiu estabelecer o significado de valor do cliente no contexto especfico
de desenvolvimento de produtos.

4.6.1

O PRINCPIO DO VALOR NO DESENVOLVIMENTO DE PRODUTOS

Possibilidades mais pertinentes para a definio de valor no contexto de

desenvolvimento de produtos sero consideradas a partir deste ponto.

20

Principal referncia desta seo.

82

Existe um considervel consenso na definio de valor nos trabalhos que

tratam sobre valor no ambiente de negcios. Slack (1998) sugere uma relao de
valor como mostrado na Figura 4.10.
Valor para o
Cliente
Preo

Qualidade

Produto

Servio

Figura 4.10 Relao de valor para o cliente

Fonte: Slack (1998)

Shillito e DeMarle (1992) propuseram que valor uma funo em que tempo
deve ser considerado. Esta afirmao est consistente com a incluso da frase
durante um perodo especfico, na definio de Womack e Jones (2003) em Lean
Thinking. O tempo que um produto leva para chegar ao mercado tem uma forte
influncia no valor percebido do produto. Baseado nesta avaliao, o modelo da
Figura 4.11 pode ser modificado para incluir o tempo como um fator primrio na
concepo do valor.

Valor para o
Cliente

Preo

Qualidade

Produto

Tempo

Servio

Figura 4.11 Relao de valor para o cliente com o atributo tempo

Fonte: Adaptado de Slack (1998)

83

Adicionalmente, para aumentar a clareza a respeito do que se pode entender

por preo, este atributo deve ser redefinido como custo da aquisio. Desta forma,
ele pode ser colocado sob a tica do cliente e tanto o custo de aquisio como os
demais fatores envolvidos no ciclo do custo para o consumidor podem ser
contabilizados. Neste momento, os custos de Suporte e Obsolescncia devem ser
considerados em acrscimo ao custo de aquisio em razo do fato de que eles, de
forma significativa, so dirigidos pelas decises tomadas no processo de
desenvolvimento de produtos.

Valor para o
Cliente

Tempo

Qualidade

Produto

Servio

Custo da
Posse

Custo de
Aquisio

Custo de Suporte
e Obsolescncia

Figura 4.12 Relao de valor para o cliente com o atributo custo expandido
Fonte: Adaptado de Slack (1998)

Este modelo parece consistente com o critrio esboado por Womack e Jones
(2003) para expressar valor, pois est elaborado em termos de um produto especfico,
preo e tempo.

4.6.1.1 Outras Perspectivas de Valor

At este ponto, a perspectiva de valor tem estado relacionada com a
perspectiva do consumidor. Womack e Jones (2003) ressaltam que, nos trabalhos

84

mais recentes, este ponto tem sido o de nica importncia. Mas o fato que existem
outras perspectivas de valor, que podem influenciar o sucesso da implementao do
mapeamento do fluxo do valor e do pensamento enxuto na organizao para o
desenvolvimento do produto. Duas outras perspectivas so aquelas relacionadas com
os acionistas e os empregados. Por que considerar outras perspectivas? Donnavan et.
al. (1998) propem que o gerenciamento de processos deveria ser desenvolvido para,
simultaneamente, garantir a otimizao do valor para o investidor, cliente e
empregados.
Uma questo surge: se desejvel focar somente na melhoria do valor para o
cliente, sendo o valor para os acionistas e para os empregados uma consequncia
neste processo; ou se o cliente e a maximizao do sistema de valor como um todo se
beneficiariam com um foco mais amplo nas trs perspectivas. Mesmo se aceitar focar
que uma nica dimenso do valor suficiente, no existiria consenso na literatura de
negcios de onde aplicar este foco. Mesmo sendo o Pensamento Enxuto claramente
focado no valor cliente, existem outros pesquisadores, como Keen (1997) apud Slack
(1998) que acreditam que o valor do acionista dirige esta rea.
Em uma viso mais global, sugere-se que alm do consumidor, empregados e
acionistas existem outros stakeholders: fornecedores, comunidade e ambiente, em
geral, por exemplo, que podem ser considerados no processo de criao de valor.
Donnavan et. al. (1998) sugerem que as empresas de maior sucesso criam valor para
todos os stakeholders, originando situaes de sinergia onde o valor criado de
forma suficiente para que todos possam prosperar. A menos que os constituintes
primrios recebam valor suficiente, a empresa no prosperar, os clientes iro para os
concorrentes, investidores procuraro outros investimentos e os empregados, novas
opes de trabalho.
A capacidade de uma empresa em aprender, inovar e melhorar
est diretamente relacionada com o valor desta empresa. Isto ,
somente atravs da capacidade de lanar novos produtos, criar
mais valor para os clientes e melhorar continuamente a eficincia
das operaes que uma empresa pode penetrar em novos
mercados e aumentar vendas e margens em resumo: crescer e,
portanto, aumentar o valor para os acionistas. (Kaplan e Norton,
1992).

85

Isto implica que a perspectiva de aprendizado no perspectiva nica de

valor. Refere-se aos objetivos e medies de melhorias nas operaes, que do
suporte ao aumento do valor para clientes e demais stakeholders. O Balanced
Scorecard (BSC)

21

suporta estas mltiplas perspectivas de valor para clientes e

acionistas, porm no faz referncias ao valor para empregado. Segundo Slack

(1998), isto complementa o Pensamento Enxuto da seguinte forma:

Ambos compartilham o foco do valor no cliente;

Ambos reconhecem a necessidade de dedicar ateno s atividades

internas que suportaro a gerao de valor para o cliente (fluxo do valor
em termos enxutos);

A aplicao de princpios enxutos uma estratgia de melhoria motivada

pelos objetivos de aprendizado no BSC; e

A implementao do mapeamento do fluxo do valor cria uma

oportunidade de identificar os parmetros-chave de operao exigidos
para a criao do BSC.

Pesquisas recentes suportam mltiplas perspectivas de valor, e sua

decomposio para o cliente em atributos foi proposta para facilitar o entendimento e
os esforos de melhoria para criao desse valor. Quando o objetivo criar valor
para outros stakeholders primrios, torna-se necessrio compreender os atributos
nicos e o valor para cada perspectiva de valor; especificamente nas perspectivas do
cliente, dos acionistas e dos organismos reguladores.

4.6.1.2 Valor para o Empregado

A perspectiva de valor para o empregado pode ser decomposta de forma
anloga ao mtodo utilizado na decomposio do valor para o cliente. Donnavan et.
al. (1998) oferecem uma abordagem similar para definir o valor para o empregado,
assim como foi feito com o valor para o cliente. O valor que um empregado quer de
seu trabalho uma funo que leve em conta tanto as recompensas que este recebe
21

Para maiores detalhes sobre o BSC consultar Kaplan e Norton (1992).

86

da empresa como tambm a qualidade no trabalho. Neste caso, pode ser representado
como na figura 4.13.

Valor para o
Empregado

Qualidade no
trabalho

Compensaes

Figura 4.13 Relaes de valor para o empregado

Como a qualidade no trabalho e as compensaes fazem parte da perspectiva

do empregado, estas so mensuradas de forma relativa ao que existe no mercado de
trabalho. Compensaes incluem, alm do salrio, benefcios de planos de sade e
aposentadoria. Qualidade no trabalho inclui questes relacionadas com o
balanceamento entre a prpria atividade e a vida pessoal do funcionrio, treinamento
e desenvolvimento de habilidades, gerenciamento do desempenho e aumento de
oportunidades. Diferentes funcionrios tero distintas vises associadas com a
qualidade no trabalho, assim como ocorre com o cliente no que diz respeito a
qualidade do produto. Ao criar valor para os empregados, as empresas podem
desenvolver uma vantagem baseada nas pessoas e suas habilidades, conduzindo,
portanto, a uma vantagem no mercado.

4.6.1.3 Valor para o Acionista

O valor do processo de desenvolvimento de produto para os acionistas
relaciona-se com as vendas futuras e os lucros advindos da realizao de um produto.
Quanto maior for a margem alcanada por um produto, maior ser o valor para a
empresa. Ao contrrio das perspectivas de valor para o cliente e aos empregados, a
perspectiva por parte dos acionistas puramente econmica. O conceito de Valor

87

Econmico Agregado (VEA) estabelece que uma empresa somente crie valor,
quando suas receitas excederem o capital investido. (Slack, 1998)

4.6.1.4 Valor para Organismos Reguladores

At este ponto, o trabalho realizado por Slack (1998) contribui de forma
consistente para entendimento do princpio de valor no desenvolvimento de produtos.
Mas o autor no levou em considerao outro stakeholder que exerce importante
papel no desenvolvimento de produtos: os organismos reguladores. Liu (2003) fez
um levantamento, com mais de 140 respondentes, dos mais importantes processos ou
atividades no desenvolvimento de produtos. O processo de Obteno da
Homologao dos produtos nos organismos reguladores aparece em terceiro lugar,
atrs apenas dos processos de Teste do Produto e Validao dos Produtos.
Para Murman et. al. (2002), a indstria aeronutica, por exemplo, opera em
ambientes sciopolticos, regulatrios e institucionais complexos. O governo, por sua
vez tem tido papel significante na evoluo da indstria, pois, desde o incio age
como organismo regulador, cliente e facilitador de desenvolvimentos tecnolgicos.
Todavia, deve-se considerar que a importncia desse stakeholder reflete-se em outros
segmentos industriais, por exemplo: o farmacutico, o da construo civil e o
automobilstico.
Ainda observando a indstria aeronutica alguns importantes organismos
reguladores podem ser citados, como: o Federal Aviation Administration (FAA) nos
EUA, o Joint Aviation Administration (JAA) na Unio Europia e o Departamento de
Aviao Civil (DAC) no Brasi, que tm o objetivo de assegurar que todos os itens
produzidos e fornecidos pelas empresas do ramo aeronutico e comercializados em
suas respectivas jurisdies estejam de acordo com os padres e normas
estabelecidos (Machado, 2004).

88

4.6.1.5 As Ligaes entre as Perspectivas de Valor

A seguir, na Figura 4.14, h um modelo proposto por Slack (1998),
inicialmente, para a integrao entre os trs fluxos primrios de valor: clientes,
empregados e acionistas. Aps sua avaliao e para efeito desta tese dever ser
includo o Valor para os Organismos Reguladores. Nesta figura, os atributos
primrios para cada fluxo de valor so mostrados qualidade do produto, preo e
prazo, relacionados ao cliente; qualidade do trabalho e compensao, relacionados ao
empregado; e valor econmico agregado, relacionado ao acionista. Adicionalmente,
so mostradas ligaes entre esses atributos, que podem prover alguns insights sobre
as interaes dos fluxos de valor.

Valor para
o cliente

Demanda
(Volume)

Valor para
Organismos
Reguladores

Preo
Prazo

Qualidade
do produto

Custo

Vendas

LAIR

Produtividade

Qualidade
do trabalho

Valor para o
Empregado

Recompensa
Valor para
o Acionista

Investimento

Figura 4.14 Modelo para integrao de mltiplas perspectivas de valor

Fonte: Adaptado de Slack (1998).

89

A ligao entre valor para o cliente e valor para o acionista pode ser descrita
como segue: aumentado o valor para o cliente quando em comparao com a
concorrncia, gerar um aumento de demanda para o produto da empresa que
aumentar as vendas. As vendas aumentadas, menos os custos fixos e variveis
associados com a produo do produto, resultaro em um aumento de ganhos, antes
de juros e impostos. Finalmente, depois de serem considerados os juros e impostos e
o custo do capital, o valor econmico agregado propiciar um impacto no valor para
o acionista. O valor aumentado ao acionista estimula investimentos adicionais, tanto
em termos de oferta de produtos da empresa, como na fora de trabalho.
As melhorias resultante no produto e na qualidade de trabalho refletem de
forma direta no valor para o cliente e para o empregado. Integraes adicionais
propcias discusso so aquelas relacionadas compensao dos empregados. O
aumento da compensao melhora o valor para o empregado, enquanto o acrscimo
nos custos sofre um impacto negativo no valor para o cliente a para o acionista22.
Neste caso, existem muitos fatores que influenciam o aumento dos custos associados
ao incremento do retorno obtido e, tambm, o aumento da qualidade e produtividade
associados com o aumento do valor para o empregado. O impacto resultante no valor
para o cliente e para os acionistas depender da intensidade dessas interaes.

4.6.2

PRINCPIO

DO

FLUXO

DE

VALOR

NO

PROCESSO

DE

DESENVOLVIMENTO DO PRODUTO
Assim como utilizado na abordagem de definio de valor, outros recursos e
contextos podem propiciar insights sobre o que fluxo de valor no processo de
desenvolvimento de produto.
Algumas definies de fluxo, segundo Ferreira (1993):
a)

Ato ou modo de fluir;

b) Corrente, curso fluido em um conduto de trfego, numa rua, etc.;

c)
22

Movimento alternado (enchente e vazante) do mar para a praia;

Ver caso Xerox no captulo 2 desta tese.

90

d) Seqncia ou vicissitude de acontecimentos.

Baseado nas definies isoladas de valor e fluxo, Slack props a seguinte
definio para fluxo de valor:
Fluxo de Valor a sucesso ininterrupta das atividades de
desenvolvimento de produto ao longo das quais h contnua
adio de atributos do produto, incluindo: qualidade,
funcionalidade e utilidade, os quais conduzem diretamente s
necessidades do consumidor. Slack (1998).

Nesta definio, as palavras-chave para este estudo so: ininterrupta

sucesso, constante movimento e mesma direo que so a essncia do
pensamento enxuto e esto diretamente ligadas ao prximo princpio: fluxo.

4.6.2.1 Categorizao das Atividades do Fluxo de Valor

Segundo Bauch (2004), a aplicao do princpio do fluxo de valor aos
processos administrativos parece implicar o estado psicolgico dos empregados.
Womack e Jones (1996) destacam que em uma pesquisa realizada pelo psiclogo
Mihaly Csikentmihalyi, da Universidade de Chicago, as pessoas referem-se a estas
atividades como recompensadoras, pois esto associadas a um claro objetivo;
necessidade de concentrao; reduo de interrupes ou distraes; a um claro e
imediato feedback sobre o progresso para o alcance do objetivo e sensao de
desafio a percepo de que suas habilidades so adequadas e suficientes para as
tarefas que esto sob sua responsabilidade. Descobriu-se tambm se que as pessoas
ao experimentarem estas condies estaro psicologicamente satisfeitas.
Para Slack (1998), na transio para um estado enxuto, nem todos os passos
no fluxo de valor podem estar efetivamente criando valor. Assim como j citados
anteriormente por Bauch (2004) neste trabalho, Womack e Jones (2003)
estabeleceram categorias para os passos do processo, baseadas no potencial de
criao de valor. As categorias so:

Aes que criam valor para o cliente;

91

Aes que no criam valor para o cliente, mas que, por algum motivo, so
necessrias (Muda Tipo Um); e

Aes que no criam valor para o cliente e, portanto, podem ser

eliminadas (Muda Tipo Dois).

Existe a proposta de uma quarta categoria de aes que podem existir no

fluxo de valor de uma empresa. So as aes que no s no criam valor para o
cliente, como tambm podem reduzir o valor para o cliente. Isto pode ocorrer em
passos do processo onde o valor no completamente entendido e as intenes de
adicionar valor acabam de modo efetivo, tendo o efeito contrrio.

4.6.2.2 Relao entre Fluxo de Valor, Valor e Produto

A Figura 4.15 uma generalizao proposta por Slack (1998) do fluxo de
valor associado a um dado produto e sua relao com o princpio de valor
previamente definido. O fluxo de valor a sucesso de atividades ou processos, ou
passos que uma empresa utiliza para gerar valor para um determinado produto. Nesta
figura, leva-se em conta o fluxo de valor para a empresa como um todo, mas o foco
deste trabalho ser apenas no processo de desenvolvimento.

PRODUTO

Valor

Atividades

Valor

Desenvolvimento de
mercado

Valor

Valor

Desenvolvimento do
produto

Valor

Realizao
do produto

Valor

Operao e
suporte

Fluxo do Valor
Figura 4.15 Relao entre Fluxo de Valor, Valor e Produto
Fonte: Slack (1998).

92

necessrio o entendimento do fluxo de valor no processo de

desenvolvimento de produto e do tipo de ao para cada passo de forma a permitir a
eliminao do desperdcio e alcance de um desenvolvimento de produto enxuto.

4.6.3

PRINCPIO DO FLUXO NO PROCESSO DE DESENVOLVIMENTO DE

PRODUTO
Para Slack (1998), este terceiro princpio, o fluxo, definido como o

alinhamento da seqncia de atividades necessrias requeridas para alcanar um

fluxo de trabalho contnuo e til, sem interrupes, passos desnecessrios, lotes ou
estoques. A fim de ter sucesso em conseguir o fluxo do trabalho, preciso que
entender o fluxo de valor, associado ao fluxo do trabalho. Se o fluxo de valor no for
compreendido, ento, a ligao para o valor do cliente perdeu-se e as mudanas
realizadas no processo podem no proporcionar todas as melhorias desejadas.
Analisando o objeto de trabalho atual e o fluxo de valor associado a ele, podemos
observar que os objetos so feitos para fluir sem desperdcios, desde o incio at o
final do processo, respeitando fronteiras e barreiras. O objetivo do fluxo
centralizar-se em um produto especfico e faz-lo fluir pela empresa com o auxlio da
reavaliao dos processos de trabalho e de ferramentas para eliminar desperdcios.
Este conceito pode ser generalizado na Figura 4.16.

FLUXO DO PRODUTO

Valor

Valor

Definio do
Sistema

Valor

Projeto
Preliminar

Valor

Valor

Projeto
Detalhado

Valor
Fabricao,
Montagem,
Integrao e
teste

Figura 4.16 Conceito de fluxo em desenvolvimento de produto

Fonte: Slack (1998).

93

4.6.3.1 O Papel da Informao no Desenvolvimento de Produtos

Slack (1998) esclarece que para entender o fluxo no contexto de
desenvolvimento de produto, necessrio confrontar com o fluxo do produto na
manufatura. No ambiente de manufatura pode-se igualar o fluxo do produto ao fluxo
de material. No processo de desenvolvimento de produto, alm do fluxo de materiais
(modelos, prottipos, etc.) o produto que fluir ser, na maioria dos casos, a
informao. Se se aceitar que o produto bsico no processo de desenvolvimento de
produtos ser a informao, ento devero ser considerados todos os tipos de
informao que existem nesses processos. Assim, a informao no processo de
desenvolvimento de produto pode ser categorizada em diferentes reas.
Slack (1998) props quatro categorias de informao: sobre o produto,
informao a respeito do projeto, informao do processo e informao sobre o
negcio.

Informao sobre o produto est diretamente relacionada ao produto

que ser realizado, depois de completado seu processo de
desenvolvimento. O que inclui: transformao dos requisitos do
cliente em requisitos de componentes do produto e transformao de
requisitos dos componentes em parmetros de projeto. Estas so as
informaes necessrias para criar um produto fsico e gerenciar os
esforos tcnicos associados ao produto.

Informao de projeto est diretamente relacionada ao projeto ou

programa. Informao de projeto inclui: informao de planejamento
de recursos, informao de gerenciamento de custo e informao de
gerenciamento de programao.

Informao sobre os processos esta define como o processo de

desenvolvimento de produto deve ser executado e d aos funcionrios
a direo para acompanhamento de suas tarefas.

Informao de negcios est relacionada aos processos de

marketing, vendas e finanas.

94

Informao o produto que flui ou o objeto de trabalho que dever fluir de

forma ininterrupta no processo de desenvolvimento de produto. Na implementao
de princpios enxutos no processo de desenvolvimento de produtos, todos os quatro
tipos de informao estaro presentes no fluxo de valor.
Para Bauch (2004), assim como materiais, existem algumas propriedades
fundamentais que caracterizam a informao e, simultaneamente, determinam
algumas vantagens baseadas em sua correta utilizao. Isto inclui os seguintes
aspectos:

A informao um bem intangvel;

A informao til se o destinatrio necessitar desta informao para

realizao de suas atividades;

A informao no um bem gratuito; portanto, ela poder estar

associada a determinado preo;

O valor da informao est associado a um contexto e momento

particular;

O valor da informao poder alterar-se por meio da adio, seleo,

omisso e/ou concretizao; portanto, a informao aberta e
condensvel;

Existem diferentes atributos de qualidade de informao, tais como:

preciso, compleio, momento e confiabilidade;

A informao pode ser transportada com a velocidade da luz, mesmo

que o objeto com o qual ela esteja relacionada, no o possa;

O comprador de informaes apenas obtm cpias no papel das

mesmas, porm o direito exclusivo de utilizao ou, em particular, de
propriedade muito difcil de ser obtido;

A informao transferida por meio de cdigos; desta forma, para

compreend-la necessrio que exista um veculo comum de troca;

95

A obsolescncia da informao no causada pelo uso e, sim, pelo

uso intempestivo; e

Com Freqncia, a informao arbitrariamente dividida.

4.6.3.2 Os Sete Desperdcios da Informao

Existem alguns motivos pelos quais a informao acaba sendo desperdiada
ou mal-utilizada, estes foram classificados em sete categorias de desperdcios.
(McManus, 2002)
-

Superproduo:

criao

de

dados

informaes

desnecessrias, a disseminao indiscriminada da informao,

informaes que no so puxadas e, sim, empurradas ao longo
do processo;
-

Inventrio perda de controle, muita informao, retorno

complicado, informao obsoleta ou desatualizada;

Transporte incompatibilidade com canal, falhas de

comunicao, questes de segurana;

Movimentos Desnecessrios falta de acesso direto,

reformataes;

Espera envio tardio de informaes, informaes enviadas

muito cedo (conduzem a retrabalho);

Defeitos de Produto falta de revises, testes ou verificaes;

Processamento

produo

desnecessria,

excessivamente customizada, muitas interaes.

formatao

96

4.6.3.3 Exemplos de Muda23 no Desenvolvimento de Produto

Por decorrncia dos sete desperdcios da informao, diferentes tipos de muda
podem ser identificados no ambiente de desenvolvimento de produtos. Para tanto,
Slack (1998) utilizou como referncia a descrio de mudas proposta por Womack e
Jones (2003) para a manufatura. Na relao que segue, os exemplos de muda em
desenvolvimento de produto estaro sempre, aps a descrio do muda
correspondente na manufatura.

Muda de tempo de espera.

Muda de tempo de espera a diferena entre o tempo total de processamento

e o tempo exigido para atividades que criam valor. O fluxo de valor pode ser
considerado no fluxo durante esse perodo. Em um centro de manufatura, o set-up
pode ser considerado um exemplo desse tipo de desperdcio.

Exemplos de Muda de tempo de espera no Desenvolvimento de

Produto

Este tipo de muda ocorre claramente tanto no ambiente de desenvolvimento

de produto como na manufatura. Um exemplo pode ser: recolher uma informao
exatamente como esta gerada e precisar reformat-la de acordo com o padro de
algum, uma atividade sem valor que pode ser classificada como muda de tempo de
espera.

Muda de transporte

Muda de transporte est associada ao tempo que o produto permanece na

condio de transportado. O tempo de transporte aquele em que no ocorre
transformao fsica. O transporte o tempo sobre o qual no se agrega valor ao
produto; outro exemplo de muda de transporte o nmero de vezes em que o produto
retirado e deixado em algum lugar.

23

Exemplos de Muda de transporte no Desenvolvimento de Produto

Termo japons utilizado na abordagem enxuta para identificar tarefas que consomem recursos, mas
no criam valor.

97

Este tipo de muda verifica-se no ambiente de desenvolvimento de produto de

forma clara, assim como no ambiente de manufatura. Apesar de serem evidentes as
redues de muda no transporte, com o uso amplo de aparelhos de fax, correio
eletrnico, redes de computadores, ainda restam algumas fontes de Muda de
transporte em desenvolvimento de produtos. Pois, esta mesma tecnologia estabelece
um tipo de muda de tempo de espera: a incompatibilidade entre as diferentes
plataformas e software, que geram retrabalho em termos de reformatar e/ou reenviar
a informao.
Um exemplo desse tipo de muda pode ocorrer quando determinados desenhos
tcnicos elaborados em um certo software de CAD (Computer Aided Design)
precisam ser visualizados em um outro computador com uma verso mais nova do
software ou, at mesmo, em um outro tipo de software.

Muda de Inventrio

Muda de inventrio o desperdcio gerado pelos lotes de produtos semiacabados ou acabados que aguardam entre cada uma das fases dos processos. Estes
estoques de bens e recursos da empresa podem ser usados em outras atividades de
gerao de valor.

Exemplos de Muda de inventrio no Desenvolvimento de Produto

As filas no processo de desenvolvimento de produtos da mesma forma que na

manufatura podem ser vistas, como exemplo, possvel citar as filas de informao
empilhadas nas organizaes funcionais onde diferentes programas competem por
prioridade na execuo de tarefas. Desta forma possvel lidar com questes
similares de capacidade versus tamanho da fila. De fato, em razo da grande
variabilidade inerente ao processo de desenvolvimento de produto, o gerenciamento
ou eliminao de filas pode ser mais difcil do que no ambiente de manufatura.

Muda de Defeitos

Muda de defeitos est associado deteco de materiais com caractersticas

no conformes, sendo relacionado com os problemas de qualidade ou de retrabalho
do produto no sentido de corrigir um problema de qualidade. Este tipo de muda

98

bem entendido, sendo foco de outros esforos de melhoria na empresa, tais como:
Seis Sigma24 e TQM (Total Quality Management).

Exemplos de Muda de Defeitos no Desenvolvimento de Produto

Um exemplo clssico desse tipo de muda no ambiente de desenvolvimento de

produtos trata-se de erro ou falha de engenharia, isto ocorre quando alguns requisitos
so ultrapassados ou, at mesmo, no so considerados, nem so efetuadas as
anlises apropriadas ou as interfaces de sistema no so adequadamente
consideradas. Falhas tambm podem acontecer quando os processos padronizados e
estabelecidos no so seguidos e o aprendizado no retido. Da mesma forma que na
manufatura, quanto mais tarde o erro for percebido no processo, maior ser o muda.

Muda de Superproduo

Muda de superproduo est associado elevada quantidade produzida de um

determinado produto. Este muda associado ao conceito de produo empurrada,
cujos processos montante fazem fluir uma quantidade de produtos que independe
da necessidade dos processos a jusante. O tipo de muda est proximamente
relacionado com muda de inventrio, visto que a superproduo resulta,
normalmente, no aumento de inventrios.

Exemplos de Muda de Superproduo no Desenvolvimento de

Produto

Um exemplo de superproduo a disseminao indiscriminada de e-mails a

destinatrios que no esto relacionados diretamente com o fluxo do valor. Isto
resulta em um significante tempo perdido, no qual se gasta grande parte do tempo
selecionando e lendo mensagens desnecessrias, podendo resultar na sobrecarga de
informaes. Quando isto ocorre, algumas mensagens so descartadas ou sequer
lidas, resultando em uma potencial perda de informaes que poderiam ser
necessrias.

24

Ver Miyake (2002)

99

Muda de Superprocessamento

Este desperdcio est associado aos passos extras que so exigidos em razo
das ferramentas ou projetos de produtos pobres. A seleo das ferramentas pobres
pode resultar em um tempo maior de processamento, se comparado utilizao da
ferramenta correta.

Exemplos de Muda de Superprocessamento no Desenvolvimento de

Produto

Existe uma tendncia, quando da elaborao dos documentos de requisitos,

para comear o texto com uma reviso do que j foi feito no passado. Este processo
pode conduzir incorporao de requisitos ou lessons learned que no so
necessrias aos sucessivos clientes do processo.

4.6.3.4 Aplicao das Tcnicas de Fluxo

Na seo anterior foi, estabelecido que muitos desperdcios encontrados no
processo de desenvolvimento dos produtos esto classificados nas mesmas categorias
verificadas na manufatura. Baseado nesta similaridade, torna-se apropriado
investigar o conjunto de tcnicas que foram desenvolvidas pela manufatura para
combater tais desperdcios e sua aplicao em desenvolvimento de produtos. A
tabela abaixo elaborada por Slack (1998) apresenta alguns conceitos e tcnicas
utilizadas para criar o fluxo no ambiente de manufatura e oferece tambm
determinados comentrios de sua aplicabilidade no ambiente de Desenvolvimento de
Produtos.

100

Tabela 4.2 Correlao entre as tcnicas de fluxo na manufatura e o

desenvolvimento de produtos.
Tcnica de Fluxo na Manufatura

Contexto de Desenvolvimento de Produto

Capacidade Sistmica
O time deve incluir ao longo do fluxo do
valor membros que entendam as
competncias do sistema, de forma que o
produto possa fluir de forma suave do
incio ao fim do processo. A questo
chave que o entendimento do sistema
pelos membros possibilita que o produto
flua por todas as fases do processo. O
conhecimento parcial de apenas algumas
fases no permite a absoro dos
conceitos que iro manter o fluxo do
produto ao longo das fases.

Este conceito aproxima-se daqueles

relacionados com engenharia simultnea e
com os Times Integrados de Produto no
desenvolvimento de produtos. Esta
abordagem no desenvolvimento de
produtos aproxima os times durante o
projeto, proporcionando uma viso
multidisciplinar que trar a perspectiva de
fluxo de valor ao processo.

Tempo takt25
O conceito de tempo takt usado para
cadenciar a taxa de produo com a taxa
de demanda. Isto possibilita a eliminao
de muda de estoques e muda de
superproduo (assim como o muda de
subproduo).

25

O emprego de tempo takt no

desenvolvimento de produto no muito
bvio. Em ltima instncia ele pode ser
considerado como a durao do processo
de desenvolvimento de um novo produto.
Tempo takt, na manufatura, utilizado
para controle operacional e no se
identificou nenhum corolrio direto no
processo de desenvolvimento de produto.

O tempo takt corresponde ao tempo total disponvel para a produo dividido pela quantidade
demandada. Exemplos: se uma fbrica opera oito horas por dia (320 minutos) e a sua demanda diria
de 640 unidades, o tempo takt de 0,5 minutos (30 segundos). Se os clientes desejam quatro novos
produtos por ms, o tempo takt de uma semana.

101

Tcnica de Fluxo na Manufatura

Contexto de Desenvolvimento de Produto

Controle Visual
O controle visual utilizado para
garantir que os membros do time esto
cientes e para garantir o status da
operao e do fluxo do produto. Esta
visualizao facilita a operao do tempo
takt e permite um ajuste imediato,
quando necessrio, com a finalidade de
alcanar as mudanas na demanda dos
clientes.

Esta tcnica revelou-se importante no

alinhamento dos times e da organizao
como um todo para o alcance dos
objetivos, pode e aplicada no
desenvolvimento de produtos. Um
exemplo o emprego de sala de guerra
onde as informaes importantes para o
projeto so colocadas em um lugar onde
possam ser vistas por todos os integrantes
do time no curso normal de suas
atividades.
Informaes
como
programao do desenvolvimento do
produto, status do processo, pontos fortes
e pontos fracos do programa so
normalmente expostos. Sua utilizao,
porm, no facilitar a operao em tempo
takt, mas facilitar os ajustes na direo de
atingir os requisitos de mudana do
programa.

Just-in-time
Just-in-time (JIT) um sistema de
controle da manufatura utilizado para
movimentao de material na rea da
produo, de forma que se utilize para
isso um mnimo estoque. JIT exige
pequenos estoques de material em
processo e tipicamente usa a ferramenta
de kanban para o sistema de fluxo de
informaes, o que propiciar um
eficiente meio de movimentao dos
materiais. JIT eficiente na reduo de
muda de estoque e muda de perda de
tempo.

Assim como o tempo takt, a aplicao

desta tcnica de fluxo no ambiente de
desenvolvimento de produtos no foi
estabelecida.

102

Tcnica de Fluxo na Manufatura

Contexto de Desenvolvimento de Produto

Programao em Nveis
Programao por nvel utilizada como
um mtodo que pode criar e tornar mais
suave
as
programaes
dirias.
Tipicamente uma requisio mensal de
produo dividida em trabalhos dirios
para estabelecer requisitos dirios para a
produo; portanto, suavizando o fluxo.
Isto por que o JIT pode no ser
satisfatrio em um ambiente de
freqentes mudanas de demanda de
produo. A programao em nveis
facilita a implementao do JIT, por
meio do aumento da previsibilidade dos
requisitos de fluxo.

Existem mtodos de Programao em

Nvel no ambiente de desenvolvimento de
produtos, porm provvel que estes
sejam menos usados neste contexto. Isto
se deve ao fato de que mais fcil ajustar
a capacidade (mover e/ou acrescentar
pessoas), do que no ambiente de
manufatura onde a capacidade tambm
depende de mquinas, instalaes, etc.

Proximidade Fsica
As etapas da produo so arranjadas de
forma que fiquem prximas fisicamente
umas das outras e em uma seqncia que
elimine o muda de transporte.
Freqentemente, estes arranjos so
chamados clulas. Clulas so arranjadas
para minimizar as movimentaes dos
empregados. Desta forma eliminando
tambm mudas de movimento. Em um
sentido mais amplo, as instalaes dos
fornecedores tendem a estar prximas de
seus clientes, permitindo a integrao
dos processos e eliminao de
desperdcios.

Chamada
de
co-localizao,
a
aproximao da localizao fsica de
times de desenvolvimento de produto
facilita a coeso e a comunicao do time.
A co-localizao auxilia tambm na
eliminao das barreiras organizacionais,
assim como das barreiras entre
fornecedores e contratantes, alm de
facilitar a integrao de fluxos complexos
de informaes.

103

Tcnica de Fluxo na Manufatura

Contexto de Desenvolvimento de Produto

Fluxo Contnuo
Um processo ajustado de forma que o
produto flua passo a passo e sem
estoques. Isto , freqentemente,
chamado fluxo contnuo, pois elimina o
processamento por lotes e elimina os
mudas
de
estoques
associados.
Problemas de qualidade podem ser
identificados e corrigidos com base no
fluxo por etapas, em oposio idia de
descobrir um problema de qualidade em
um lote de produtos.

Assim como o tempo Takt e JIT, a

aplicabilidade
desta
tcnica
no
desenvolvimento
de
produto

questionvel. O desenvolvimento de
produtos no repetitivo da mesma forma
que a manufatura. Um corolrio potencial
para seu desenvolvimento o fluxo
simples do programa. Se uma organizao
de desenvolvimento de produto est
apefeioando programas mltiplos de
desenvolvimento de produtos e estes
ocorrem simultaneamente, a disputa por
recursos entre os programas pode
conduzir a atrasos no fluxo de
informaes, o que se propiciar em muda
de inventrio.

Processos Capazes26
A
implementao
completa
de
processos, equipamentos e funcionrios
capazes. Um processo capaz quando
elimina as variaes que conduzem aos
mudas de defeitos. A capacidade
verificada tanto por meio da certificao
de processos e equipamentos, como pelo
do treinamento de empregados.

26

Esta tcnica importante para os

processos administrativos. Equipamentos
no processo de desenvolvimento de
produtos podem ser imaginados em
termos de ferramentas analticas utilizadas
para desenvolver o projeto do produto.
Em razo de sua natureza no repetitiva,
no processo desenvolvimento de produtos
a identificao de mtricas e confirmao
da eficcia destas ferramentas torna-se
mais difcil, porm o mesmo nvel de
ateno deve ser despendido. A
competncia dos empregados est
normalmente relacionada com programas
apropriados
de
treinamento,
cuja
aplicao tambm importante no
processo de desenvolvimento de produtos
assim como na manufatura. Empresas
confiam grande parte de seu treinamento
na forma on-the-job.

Uma explicao clara e sucinta sobre processo capaz pode ser obtida em Carvalho (2002).

104

Tcnica de Fluxo na Manufatura

Contexto de Desenvolvimento de Produto

Padronizao do Trabalho
Processos de trabalho padronizados so
estabelecidos. Estes esto com os
processos capazes no que se refere a
reduo de variabilidades, que conduzem
a mudas de defeito. O processo de
trabalho padronizado prov as bases para
os processo documentados e a absoro
de lessons learned.

O trabalho padronizado usado no

desenvolvimento de produtos com o
mesmo propsito da manufatura. O
trabalho padronizado no desenvolvimento
de produtos pode envolver a definio de
ferramentas especficas, a definio
especfica de produtos, ou mesmo,
abordagens e verificao.

Treinamento Cruzado
Os membros dos times que possuem
habilidade cruzadas so empregados com
o objetivo de garantir a flexibilidade na
conduo das tarefas. Esta flexibilidade
pode ser instrumento para se evitar
quedas de recursos ao longo do processo,
que podem ocorrer em razo de vrias
causas. O treinamento cruzado permite
que os recursos possam ser alternados ao
longo
do
processo,
eliminando
potenciais mudas de tempo de espera,
para garantir a manuteno do fluxo
contnuo.

Membros dos times que possuem

habilidades cruzadas podem auxiliar nos
casos de variaes localizadas de
demanda, pela redistribuio do pessoal.
Duas perspectivas de desenvolvimento de
produtos vm mente quando se discute a
utilizao dos membros de equipes com
habilidades cruzadas: a primeira, que o
desenvolvimento
de
produtos

tipicamente executado por uma equipe de

engenheiros, tipo de curinga, com
profundas e amplas competncias. Esta
flexibilidade seria, portanto, algo que j
existe no desenvolvimento de produtos. A
segunda, muito se tem focado na
formao de generalistas para a criao
desta flexibilidade; assim como para
expandir a perspectiva do empregado
permitindo um melhor entendimento das
decises tomadas. Este foco, porm, tem
feito surgir questionamentos sobre eroso
das competncias especficas, cuja a
expanso tm implicado na reduo de
sua profundidade.

105

Tcnica de Fluxo na Manufatura

Contexto de Desenvolvimento de Produto

Total Productive Maintenance (TPM)

Total Productive Maintenance (TPM)
utilizada para garantir 100% de
disponibilidade dos equipamentos de
processo. A TPM elimina tanto o muda
de tempo, que surge em razo da quebra
de uma mquina, quanto o muda de
defeitos, que so originados em funo
do produto no conforme, que pode se
originar pelo desgaste da mquina ou da
ferramenta.

A
aplicao
desta
tcnica
no
desenvolvimento de produtos garantida.
Ferramentas de desenvolvimento de
produtos, incluindo softwares, ferramentas
de anlise e de projeto requerem
manuteno
para
garantir
sua
disponibilidade quando necessria para
que o fluxo do trabalho seja mantido.

Prova de Erro (Poka Yoke)

Alguns tipos de sistema so empregados
para permitir que os empregados
monitorem o trabalho por eles executado
e utilizem tcnicas que impeam erros. A
eliminao da possibilidade de erros
reduz os mudas de tempo de espera pela
eliminao de inspees dedicadas e
podem reduzir, tambm, muda de tempo
de espera pela identificao de
problemas de qualidade j no incio.

Novamente, o desenvolvimento de
produto seria beneficiado com o uso desta
tcnica. Alguns exemplos atuais podem
ser obtidos, particularmente, na rea de
ferramentas de controle numrico.

Fonte: Adaptada de Slack (1998).

4.6.3.5 Fluxo versus Muda

Os dados que foram apresentados, suportam a existncia dos mesmos tipos de
desperdcios tanto na manufatura como no processo de desenvolvimento de produto.
Adicionalmente, foi apresentada uma reviso das tcnicas de fluxo na manufatura
nas quais foi possvel identificar quais tcnicas podem ser aplicadas no
desenvolvimento de produtos com o propsito de eliminar desperdcios e facilitar o
fluxo do trabalho. A dados da tabela 4.3 correlacionam as categorias de desperdcio
com as tcnicas de fluxo que podem ser usadas para a reduo de desperdcios.

106

Competncia
Sistmica

X
X

Programao em
Nveis

X
X

Retardo

Complexidade

Movimento

Controle Visual

Proximidade Fsica

Superprocessamento

Defeitos

Inventrio

Transporte

Tempo de
espera

Tcnicas

Categorias

Superproduo

Tabela 4.3. Correlao entre categorias de desperdcios e tcnicas de fluxo.

Processos capazes

Padronizao do
trabalho

Treinamento Cruzado

TPM

prova de erro (Poka

Yoke)

Tempo Takt
Just in Time

X
X

Aplicao X
questionvel
Xem desenvolvimento de
produtos

Fluxo Contnuo

Fonte: Adaptada de Slack (1998).

A tabela tambm identifica as tcnicas que tm sua aplicabilidade

questionada no esforo de transio para um processo de desenvolvimento de
produto enxuto (rea sombreada). Estas mesmas tcnicas apresentam os mesmos
tipos de muda inventrio e superproduo. Visto que nenhuma outra tcnica est
relacionada diretamente com o muda de inventrio, alguma outra, possivelmente, a
tcnica de fluxo nico, ser exigida no ambiente de desenvolvimento de produtos de
forma a classificar este tipo de muda.
Esta seo introduziu o terceiro princpio: Fluxo. o conceito de ter a
informao como o produto ou o objeto de trabalho no processo de
desenvolvimento de produto foi, ento, ressaltado e o Fluxo definido, como o

107

alinhamento de todas as atividades necessrias para se alcanar um firme fluxo do

trabalho, sem interrupes, passos desnecessrios, lotes ou filas. O fluxo pode ser
alcanado pela eliminao de desperdcios no fluxo do valor das atividades do
processo de desenvolvimento de produtos.

4.6.4

O PRINCPIO DO SISTEMA PUXADO NO DESENVOLVIMENTO DE

PRODUTOS
A procura de analogias entre a produo puxada no ambiente de manufatura e

no ambiente de desenvolvimento de produtos foi considerada mais difcil do que nos

princpios de Valor, Fluxo de Valor e Fluxo. Desse modo, utilizando-se de um alto
nvel de abstrao, seria possvel construir um paralelo entre uma empresa que no
inicia um processo de desenvolvimento de um novo produto antes que um cliente (ou
um grupo de cliente) tenha indicado intenes de comprar o produto.
Um exemplo acontece quando a Pratt & Whitney retarda o lanamento de um
novo motor at que os clientes da aeronave e das linhas areas estejam engajados no
programa. Mas exemplos contrrios existem, cujas empresas optam por correr o risco
do desenvolvimento de um novo produto antes de ter o comprometimento dos
clientes, das indstrias de tecnologia de rpido avano. O lanamento de um novo
esforo de desenvolvimento de produto uma questo estratgica e, portanto, no se
encaixa perfeitamente no conceito de produo puxada.
No entanto, uma vez que a deciso tomada para iniciar o desenvolvimento
de um novo produto, existem vantagens em estruturar o programa e os processos de
forma que esta informao seja puxada atravs do processo, em oposio a empurrla atravs do processo? Existem algumas diferenas marcantes entre os processos de
manufatura e de desenvolvimento de produtos que so importantes nesta discusso.
O processo de manufatura, geralmente, seqencial - por natureza, no interativo e
repetitivo. Contrastando isto com o processo de desenvolvimento de produto, o qual,
geralmente, realizado em uma rede de trabalho, envolvendo tanto processos
seqenciais como em paralelo, que pode ser altamente interativo e, freqentemente,
no repetitivo (pelo menos, para as longas duraes dos projetos aeroespaciais).

108

Estas diferenas bsicas podem exigir o seguinte questionamento: possvel que o

mtodo de controle de processo chamado produo puxada seja aplicado no processo
de desenvolvimento de produto com o mesmo sucesso do ambiente de manufatura?

4.6.5

PRINCPIO

DA

PERFEIO

NO

DESENVOLVIMENTO

DE

PRODUTO
Conseguir a perfeio no ambiente de desenvolvimento de produtos, assim
como na manufatura, alcanar o estado futuro do fluxo do valor aps a eliminao
de mudas. No h uma forma padro ou padronizada para a melhoria do processo de
desenvolvimento do produto. O princpio da perfeio, provavelmente, tenha menos
novidade ou singularidade em relao a outras iniciativas de melhoria de processos
do que quando comparado com os outros quatro princpios, que so nicos perante a
viso enxuta.
Nas publicaes recentes na rea de negcios, existem abordagens que podem
ser utilizadas como apoio implementao dos conceitos enxutos. A abordagem de
gerenciamento por projetos27 uma dessas referncias e ser empregada quando da
elaborao da metodologia.
Os dados da tabela 4.4 comparam a aplicao dos princpios enxutos no
ambiente de manufatura e no desenvolvimento de produtos.
Tabela 4.4 - Comparao entre a aplicao dos princpios enxutos no ambiente de
manufatura e no desenvolvimento de produtos.
Manufatura
Definir valor

Visvel em cada etapa, meta

definida.

Desenvolvimento de Produtos
Difcil de se enxergar, metas emergentes.

Identificar o fluxo do Partes e material.

valor

Informao e conhecimento.

Fazer o processo
fluir

As interaes so desperdcios.

As interaes freqentemente so benficas.

Sistema Puxado

Dirigido pelo tempo takt.

Dirigido pelas necessidades da empresa.

Perfeio

Processo sem erros e repetvel.

Processo permite a inovao e reduz tempo

de ciclo.

27

Para maiores detalhes, consultar Kenzner (1998) e o guia PMI (2001).

109

4.7

ENGENHARIA SIMULTNEA
Conforme Clausing (1994), os produtos so tradicionalmente desenvolvidos

com base em projetos parciais, estruturados para produtos complexos por meio de
um planejamento por etapas e carregado de burocracias gerenciais que no
acrescentam o valor necessrio. O tradicional processo de desenvolvimento de
produtos freqentemente representado por casulos na organizao ou por meio da
seqncia de desenvolvimento ao estilo over-the-wall28.
No entanto, Clark e Fujimoto (1991) apontaram as desvantagens desta
abordagem tradicional: dificuldade em projetar com simplicidade e confiabilidade;
fracasso em atentar para questes como qualidade do produto manufaturado, no
processo de projeto; fracas consideraes sobre manufatura, longo tempo de
desenvolvimento, fraco envolvimento com fornecedores, e negligncias no que tange
ao melhoramento contnuo. A fim de vencer estas desvantagens relacionadas com o
processo de desenvolvimento de produtos tradicional, a engenharia simultnea
prope

realizao

de

processos

simultneos

desenvolvidos

por

times

multifuncionais de desenvolvimento.
A engenharia simultnea tem recebido muita ateno desde o incio dos anos
de 1980, porm esta ateno tem se intensificado a partir de 1988 (Clausing, 1994).
A idia de engenharia simultnea popularizou-se em funo do grande sucesso dos
produtores de automveis japoneses no mercado americano, na dcada de 80.
Na literatura sobre desenvolvimento de produtos, tornou-se uma premissa
bsica que a engenharia simultnea um requisito para o sucesso de uma
organizao para desenvolvimento de produtos (Clark e Fujimoto, 1991;
Wheelwright e Clark, 1992; Morgan, 2002). Basicamente, a engenharia simultnea
a prtica de executar, em paralelo, atividades que so necessrias ao
desenvolvimento de produtos.

28

Expresso que literalmente significa jogar por cima do muro, mas no contexto gerencial significa
passar adiante o produto ou atividade que est sendo realizada sem que se avalie a necessidade ou
disponibilidade do setor subseqente.

110

Desta forma, nesta abordagem a principal idia implcita est em estabelecer

a colaborao entre diferentes elementos funcionais de uma empresa durante o
processo de desenvolvimento de produtos. Com a finalidade de abordarem de forma
conjunta as questes, tanto de incio de projeto como a jusante do processo, para
oferecer ao mercado um produto de sucesso a um preo adequado.
Portanto, a execuo em paralelo de diferentes fases do processo de
desenvolvimento, pela colaborao de distintos grupos multifuncionais pode ser vista
como a essncia da engenharia simultnea.
Para o sucesso na implementao da engenharia simultnea, dois fatores
precisam ser observados: primeiro, ela objetiva a execuo em paralelo de atividades
de desenvolvimento ao invs de atividades seqenciais. Portanto, importante
definir as dependncias entre as atividades de projeto e organizar as atividades, de
acordo com estas dependncias e com o momento. Em outras palavras, a clara
identificao e o cuidadoso controle do fluxo de informaes entre as fases do
desenvolvimento so essenciais. Segundo, h um grande nmero de pessoas
envolvidas no desenvolvimento de produtos. Desta forma, torna-se importante
organiz-las, conforme o fluxo de informaes identificado. A partir do momento
que so pessoas que realizam as atividades atuais de desenvolvimento, relevante
organiz-las adequadamente para que as informaes alcancem-nas de forma livre e
no momento certo.
A tecnologia da informao tem propiciado o aumento da velocidade e a
disponibilidade da comunicao. A modelagem baseada em softwares de CAD
(Computer Aided Design) com as redes de computadores esto revolucionando a
capacidade de engenharia simultnea (Morgan, 2002). Contudo, mesmo sendo
necessria, a tecnologia insuficiente para fazer a integrao de atividades
funcionais e muito da literatura tem focado em solues organizacionais para a
soluo deste problema.
Alm do exposto, h na literatura sobre engenharia simultnea uma clara
evidncia do esforo para reduo do tempo de ciclo de desenvolvimento. Mas,
como observado no captulo 2, esta busca pela reduo do tempo de ciclo pode levar

111

eroso de outros objetivos de eficincia igualmente importantes. No caso da Xerox,

narrado no captulo 2, possvel perceber que o sucesso na reduo do tempo de
ciclo foi ofuscado pelo aumento de homens-hora utilizados, que ultrapassaram
sobremaneira o planejado.
Os dados da tabela 4.5 estabelecem as relaes entre a engenharia simultnea
e os princpios enxutos. Cabe ressaltar que as caractersticas citadas na tabela so
complementares.
Tabela 4.5 Abordagens de Engenharia Simultnea e Princpios enxutos
Engenharia Simultnea

Princpios Enxutos

Focada na integrao de diferentes Filosofia focada na eliminao de

funes, utilizando ferramentas formais e desperdcios e criao de valor.
mecanismos organizacionais de forma a
obter melhorias em termos de custo,
No oferece detalhes
especficos
qualidade e prazo.
necessrios a criao de valor no processo
de desenvolvimento de produtos, porm
Pode ou no contribuir para um processo prov tcnicas genricas para anlises
detalhadas.
enxuto.
No prov uma abordagem que foque Prov uma abordagem contextualizada e
explicitamente o fluxo do valor.
priorizada de alto nvel para a melhoria do
processo.

Fonte: Haque (2000).

A engenharia simultnea descreve uma estratgia de alto nvel para a

organizao de atividades de diferentes funes no processo de desenvolvimento de
produtos, h, contudo, questes relacionadas com abordagens especficas que,
atualmente, esto sendo desenvolvidas para a execuo do processo de engenharia e
para o projeto de tarefas. Uma dessas abordagens conhecida como set-based
concurrent engineering.

4.8

ENGENHARIA SIMULTNEA SET-BASED

Ward, at. al.(1995) descreve o projeto set-based, como uma abordagem de

soluo de problemas na qual projetistas avaliam um conjunto de alternativas. Como

112

o processo de desenvolvimento de produtos exige uma continuidade, este conjunto

de alternativas de soluo vai gradualmente sendo reduzido at que se obtenha uma
soluo final. Os autores contrastaram esta abordagem com a tradicional prtica de
melhorar e corrigir gradualmente um projeto nico at que se obtenha uma soluo
final satisfatria. Esta abordagem tradicional foi chamada pelos autores de pointbased.
Segundo as pesquisas de Ward at. al.(1995), o processo chamado de setbased

um

processo

relativamente

pouco

estruturado,

com

equipes

multidisciplinares no colocalizadas e sem dedicao exclusiva. Ou aspecto

interessante sobre a abordagem que, ao contrrio de congelar as especificaes o
mais cedo possvel, as mesmas so adiadas e as especificaes finais so enviadas
aos fornecedores o mais tarde possvel no processo. Na engenharia simultnea
tradicional, o objetivo reduzir o nmero de prottipos; porm, na Toyota, objeto de
estudo de Ward, at. al.(1995), os fornecedores trabalham no sentido de ampliar o
nmero de prottipos. O que muitas das vezes parece ser um contra-senso, tem na
verdade revelado indicadores que tornam o desempenho no desenvolvimento de
produtos na Toyota eficiente, quando comparado com outras empresas com
desenvolvimento convencional. Isto levou os pesquisadores a conclurem que este
o segundo paradoxo da Toyota, o primeiro seria o sistema de produo Just-in-Time
(JIT). Desta forma, a Toyota consistentemente entrega produtos de alta qualidade
mais rpido que seus concorrentes, Morgan (2002).

113

ESTUDOS DE CASO DAS PRTICAS INDUSTRIAIS

Neste captulo, sero apresentados os resultados das avaliaes relativas ao

processo de desenvolvimento de produtos realizadas nas empresas A, B e C. As

avaliaes objetivaram investigar qual o alinhamento das empresas com os princpios
enxutos, e para tanto foi utilizado um formulrio adaptado do Lean Self Assessment
(LESAT) proposto pelo MIT (Anexo A). Este formulrio est relacionado com as
questes de pesquisa elencadas no captulo um. Ao longo deste captulo, alm dos
resultados obtidos com a aplicao do questionrio, tambm ser apresentada uma
breve descrio do perfil de cada uma das empresas participantes, possibilitando,
ento, a compreenso das caractersticas do processo de desenvolvimento de
produtos destas empresas. medida que as respostas referentes s questes
principais dos formulrios forem apresentadas, anlises cruzadas dos casos tambm
sero construdas a fim de proporcionar validao interna ao processo de pesquisa.

5.1

5.1.1

PERFIL DAS EMPRESAS E MTODOS DE COLETA DE DADOS

EMPRESA A
A empresa A pertence indstria aeronutica brasileira, porm a sua atuao

se expande para alm das fronteiras do territrio nacional. Seus principais produtos
so aeronaves de transporte regional de passageiros e avies de emprego militar,
alem de atuar como fornecedora de partes para outras empresas da indstria
aeronutica internacional. Em funo de alguns critrios de confidencialidade as
informaes dos questionrios foram obtidas basicamente atravs de trs fontes: a
partir de entrevistas realizadas durante trs visitas fbrica, visitas estas que
ocorreram ao longo de seis meses; observao direta durante as mesmas visitas e
artigos e trabalhos cientficos sobre a empresa em questo. As entrevistas foram
realizadas com um engenheiro (Phd) representante do setor de ligao institucional e
com um engenheiro representante do setor desenvolvimento tecnolgico.

114

5.1.2

EMPRESA B
A empresa B governamental, sua principal atividade o desenvolvimento

de itens aeronuticos de reposio para a frota de avies da Fora Area Brasileira. O

processo de desenvolvimento de produtos nesta empresa tem como principais
caractersticas: um alto grau simultaneidade de produtos sendo desenvolvidos e
tambm uma quase-totalidade de desenvolvimento puxado a partir da necessidade
dos clientes. Para o preenchimento dos questionrios, foram realizadas visitas
mensais ao longo de um ano. Os entrevistados pertenciam alta administrao, ao
corpo de engenheiros e ao quadro tcnico.

5.1.3

EMPRESA C
A empresa C ligada ao setor automobilstico que reconhecidamente tem se

dedicado s atividades de desenvolvimento de produtos; destaca-se por ter sido, entre

as empresas concorrentes, a primeira que investiu, nos anos de 1970, em atividades
de engenharia do produto no Brasil. Da dcada de 70 at hoje, a empresa tem variado
substancialmente o escopo e alcance de suas atividades de engenharia de produto,
acompanhando sempre as estratgias de desenvolvimento adotadas pela corporao.
Os produtos desenvolvidos pela empresa C tm como caractersticas o
emprego de plataformas j existentes desenvolvidas fora do Brasil; desta forma, a
engenharia brasileira atua de forma marginal, fornecendo apenas informaes que
so particulares e especficas ao mercado brasileiro. Os produtos derivativos tm
atividades mais elaboradas da engenharia de produtos do Brasil, porm algumas
especificaes so previamente especificadas pela matriz.
As entrevistas foram realizadas com um gerente, responsvel pela reduo de
custos no processo de desenvolvimento de produtos. Os questionrios foram
respondidos pelo correio eletrnico e no foram realizadas visitas s empresas.
Algumas fontes de dados secundrios, como: artigos cientficos e dissertaes e teses
sobre a empresa tambm foram usados com o objetivo de fazer a triangulao das
informaes.

115

5.2

RESUMO DAS RESPOSTAS OBTIDAS

As respostas das empresas estudadas revelaram importantes diferenas, no

que diz respeito ao processo de desenvolvimento de produtos.

O primeiro ponto que se deve ressaltar a respeito dessas diferenas no
processo de desenvolvimento est relacionado com a complexidade dos produtos
desenvolvidos pelas distintas empresas. A empresa A desenvolve produtos de
complexidade maior e possui um processo de desenvolvimento mais alinhado com as
ferramentas sugeridas pela academia. A empresa B desenvolve produtos de
complexidade moderada a baixa e o alinhamento com as ferramentas sugeridas pela
academia ocasional. A empresa C dedica-se ao desenvolvimento de produtos
plataforma com grau de complexidade intermedirio quando comparada empresa A
e empresa B.
O

segundo

ponto

diz

respeito

ao

esforo

empreendido

para

desenvolvimento de produtos. As empresas reconhecem a importncia de um

processo de desenvolvimento de produtos formalizado, todas, de certa forma,
possuem um documento onde consta este processo. Mas, sua utilizao efetiva foi
mais bem observada na empresa A e C. Na empresa B, o uso dos passos constantes
no processo deveu-se, sobretudo pela necessidade de implementao de um sistema
da qualidade. Na empresa C, conforme relatado pelo entrevistado, embora haja um
processo amplamente conhecido e divulgado podem ser identificados diversos pontos
de ineficincia no processo de desenvolvimento de produtos.
A empresa A reconhecida e referenciada em vrios trabalhos acadmicos
em virtude de sua excelncia no desenvolvimento de produtos e, em especial, pela
sua competncia em integrao de sistemas complexos. A qualidade de seus produtos
tem sido reconhecida em todo o mundo. Desta forma, era esperado que a empresa A
implementasse muitas das ferramentas propostas pela academia e que so benchmark
para o processo de desenvolvimento de produtos. Alguns desses exemplos so a
utilizao de times integrados de desenvolvimento e abordagem sistmica de
desenvolvimento com o processo dividido em nove etapas e mecanismos
sofisticados de prototipagem. Estas ferramentas foram identificadas por meio de

116

visitas feitas empresa e de alguns trabalhos acadmicos consultados, que sero

referenciados ao longo deste captulo. A empresa A tambm possui um grupo
responsvel pela pesquisa de novas tecnologias para futura implementao em seus
processos, depois de analisada a viabilidade de implementao este conhecimento
disseminado e implementado.
No entanto a empresa A, no demonstrou uma atuao sistemtica no que
tange eliminao de desperdcios ao longo do processo de desenvolvimento do
produto. Isto no significa que estes desperdcios no ocorram e que a empresa no
esteja preocupada com esta melhoria, at porque a melhoria ocorre, porm, de forma
ocasional.
A empresa B possui caractersticas bem diferentes da empresa A. Na empresa
B, so desenvolvidos basicamente produtos que so componentes para uso em
aeronaves. Uma equipe multifuncional constituda sempre que um novo produto
precisa ser desenvolvido. Esta equipe, formada basicamente por engenheiros, limitase ao estudo preliminar da possibilidade tcnica de execuo do projeto. Depois desta
fase, o processo de desenvolvimento segue os passos previstos em um documento
formal, sem que necessariamente este processo seja revisado com a finalidade de
adequao aos mais diferentes produtos desenvolvidos pela empresa.
A empresa C possui um departamento, que foi concebido exatamente para
criao de alternativas de desenvolvimento de novos produtos, tanto no que se refere
ao emprego de materiais como s atividades do processo de desenvolvimento. Este
departamento, porm ainda est tendo algumas dificuldades de implementar
melhorias; primeiro, porque tem atuado em especial posteriori e segundo, pela
resistncia natural dos projetistas que, quando se trata do produto, no aceitam
facilmente as alteraes propostas, por exemplo, o emprego de um material em
substituio ao que havia sido anteriormente projetado.
Mesmo que nenhuma das empresas estudadas utilizasse, formalmente, um
processo de desenvolvimento enxuto, foi possvel observar que na empresa A vrios
princpios e prticas enxutas estavam presentes no processo de desenvolvimento. Na
empresa B, o entendimento do temo enxuto era limitado o que exigiu, para que se

117

pudesse dar incio s entrevistas e aplicao do formulrio, uma breve explanao

do significado e da aplicao da abordagem enxuta. Na empresa C, mesmo que
distante das prticas enxutos no processo de desenvolvimento foi identificado que
existem iniciativas de melhorias, baseadas inclusive nos princpios propostos pelo
professor Allen Ward.

5.3

RESPOSTAS DETALHADAS OBTIDAS PAUTADAS NO FORMULRIO

DE AVALIAO
O formulrio de avaliao do alinhamento do processo de desenvolvimento

de produtos das empresas estudadas com os princpios enxutos tem como linha de
investigao a seguinte premissa: as decises sobre o processo de desenvolvimento
de produto devem estar aliceradas em quantificaes e tradeoffs de valor, de forma
a incorporar os inputs dos stakeholders envolvidos.
O formulrio, alm de questionar sobre tpicos especficos, tambm permitiu
avaliar o grau de alinhamento das empresas com relao a este tpico e o estado
futuro desejado. O formulrio possibilitou ainda anotaes de evidncias do estado
atual e de oportunidades de melhorias.
As seguintes questes exploradas para cada tpico foram:
1. O processo de desenvolvimento de produto formalizado e
compreendido?
2. Os clientes e demais stakeholders (acionistas, funcionrios, etc.) so
regularmente envolvidos no processo de desenvolvimento?
3. As preocupaes iniciais dos stakeholders sobre o projeto e seu
desenvolvimento so consideradas e incorporadas no processo to
cedo quanto possvel?
4. As interaes desnecessrias no ciclo de desenvolvimento so
removidas?
5. O ciclo de desenvolvimento tem sido simplificado e alinhado ao
caminho crtico?

118

6. Produtos e processos so desenvolvidos de forma simultnea?

5.3.1

PROCESSO

DE

DESENVOLVIMENTO

DE

PRODUTOS

FORMALIZADOS E COMPREENDIDOS.
Esta primeira questo do formulrio de investigao procurou verificar se o
processo de desenvolvimento de produtos formalizado e compreendido. Como
exemplificado na Quadro 5.1, as empresas analisadas possuem um processo formal
para o desenvolvimento de produtos, porm utilizam diferentes etapas para sua
consecuo. Os engenheiros entrevistados, sem exceo, reforaram a importncia de
um processo formal e documentado.
O formulrio para coleta de informaes explorou as seguintes questes, no
que se relaciona com a formalizao e compreenso do processo de
desenvolvimento:
-

Existe um processo de desenvolvimento de produtos formalizado?

O processo seguido?

Os

participantes

compreendem

as

etapas

do

processo

de

desenvolvimento?
-

O processo revisado no sentido de obter melhorias no fluxo das

atividades que o compem?

Nesta etapa do formulrio, observou-se o alinhamento com o princpio do

fluxo e o princpio da perfeio.

119

Quadro 5.1 Sumrio das questes relativas formalizao e compreenso do

processo de desenvolvimento de produtos, nas empresas A, B e C.
Empresa

Existncia de um
processo formal

seguido? (se no
como se realiza o
PDP?)

Os participantes o
compreendem?

Quem participa do
processo de
melhoria?

Existe

O processo
seguido de acordo
com as etapas prestabelecidas.

Em funo da
complexidade do
produto desenvolvido
nem todos os
participantes tm
compreenso de todas
as suas etapas.

Existe uma equipe

responsvel pela
investigao de
novas tcnicas que
possam melhorar o
processo.

Existe

O processo
seguido de acordo
com as etapas prestabelecidas.

Os principais envolvidos
no processo de
desenvolvimento tm
compreenso de suas
etapas.

Todos os
participantes
podem participar
do processo de
melhorias que so
realizadas
ocasionalmente.

Existe

O processo e
seguido e pode ser
acompanhado
atravs de
documentao
especfica.

Segundo o entrevistado
o processo
amplamente conhecido
e divulgado.

Cabem a um setor
especfico as
atividades e
iniciativas de
melhoria.

Em seguida, so apresentados de forma mais detalhada os processos formais

de desenvolvimento de produtos de cada empresa.

5.3.1.1 Empresa A
O processo de desenvolvimento de produtos da empresa A j foi explorado
em vrios trabalhos acadmicos, considerado um modelo mais integrado, flexvel e
arquitetural em rede de informaes. Na Figura 5.1, pode-se observar as fases desse
processo:

Estudo
Preliminar

Concepo

Detalhamento

Prototipagem

Ensaios e
Certificao

Figura 5.1 Macrofluxo do processo de desenvolvimento de produtos da empresa A.

120

Estudo preliminar em que so realizadas as anlises de mercado e a

definio de algumas especificaes tcnicas.
Concepo ocorre o refinamento e a validao da configurao.
Detalhamento nesta etapa, so detalhados requisitos de sistemas e
comportamento aerodinmico.
Prototipagem so fabricados os prottipos.
Ensaios e Certificao certificar a aeronave aos rgos homologadores.
Para a empresa A, cada novo projeto uma oportunidade de implementao
de melhorias gerenciais. O processo representado na Figura 5.1 foi ao longo do
tempo incorporando aspectos de desenvolvimento simultneo at chegar ao que foi
denominado Desenvolvimento Integrado de Produtos DIP, representado, conforme
Figura 5.2.

DIP
Estudos
preliminares

Definio

Detalhamento e
certificao

Seriao

Phase-Out

conjunta

Figura 5.2 Representao do Desenvolvimento Integrado de Produtos da Empresa

A.
Fonte: Nascimento et. al. s/d.
O desenvolvimento integrado de produto designa uma nova maneira de tratar
a integrao das funes empresariais no projeto de avies. A idia criar processos
integrados e aumentar o escopo das equipes de projeto para incorporar mais funes
do restante da empresa e at de fora dela. Cabe aqui lembrar que a Empresa A passou
por uma reengenharia que a dividiu em processos e designou uma equipe que ficou
responsvel, exclusivamente, por esta transformao organizacional.

121

5.3.1.2 Empresa B
O processo de desenvolvimento de produtos da Empresa B est formalizado
em um documento que surgiu primeiramente com a implantao de um sistema de
qualidade. Este documento seguido em todas as suas etapas para qualquer que seja
o projeto. Da forma como est representado, o processo est complexo, pois no s
as etapas do desenvolvimento de produto, mas tambm todas as atividades
administrativas aparecem no diagrama. A Figura 5.329 oferece uma idia de como o
processo est estruturado.

Figura 5.3 Representao do processo de desenvolvimento de produtos da

Empresa B.
Este tipo de representao do processo de desenvolvimento de produtos
explicita a falta de definio por parte da empresa no que se refere sua competncia
essencial. Mesmo tendo como principal atividade o desenvolvimento de novos
produtos para emprego aeronutico, as atividades administrativas de licitao dos
fornecedores aparecem de forma mais detalhada no documento que formaliza o
processo de desenvolvimento.
29

A visibilidade da figura foi intencionalmente reduzida para preservar informaes da empresa.

122

O fluxograma da Figura 5.3 foi elaborado pelo engenheiro responsvel pelo

sistema da qualidade. Em entrevistas realizadas com tcnicos participantes do
processo e engenheiros, pode-se verificar que, de uma forma geral, os envolvidos
compreendem o processo de desenvolvimento em cada uma de suas etapas, que
podem ser resumidas em seis. A Figura 5.4 apresenta a representao simplificada do
processo.

Estudo
Preliminar

Projeto

Prototipagem

Ensaios e
Certificao

Consolidao
do Projeto

Figura 5.4 Processo de Desenvolvimento de Produto da Empresa B, excluindo as

atividades administrativas
Fonte: elaborao do autor da pesquisa
As melhorias do processo so ocasionais, porm todos os envolvidos podem
participar. A participao efetiva, carece de um melhor entendimento da atividadefim da organizao. Segundo o engenheiro responsvel pelo sistema da qualidade, a
percepo desta atividade-fim divide-se entre o desenvolvimento de produtos e a
aquisio do servio de manufatura dos produtos j desenvolvidos.

5.3.1.3 Empresa C
A empresa C no disponibilizou informaes sobre as fases especficas de seu
processo de desenvolvimento, porm garantiu que nas atividades de desenvolvimento
existem vrios pontos de controle que garantem as atividades anteriores que foram
executadas e que o processo pode avoluir para a fase seguinte.
Existem,

tambm,

sistemas

que

possibilitam

acompanhar

os

desenvolvimentos, sistemas para avaliar o andamento das certificaes, sistemas para

gerenciar modificaes e sistema para acompanhar ferramentas e peas em
fornecedores.

123

5.3.2

ENVOLVIMENTO DE STAKEHOLDERS
A segunda a terceira questes do formulrio procuraram entender a

participao dos clientes e demais stakeholders (fornecedores, acionistas,

funcionrios, etc.) no processo de desenvolvimento de produtos. Para tanto, foram
realizados questionamentos sobre os seguintes tpicos:
-

Participao formal de stakeholders no PDP;

Anlises dos inputs dos stakeholders;

Mecanismos de feedback para entender e minimizar as interaes no

projeto; e

A utilizao de times integrados de desenvolvimento.

Nesta etapa, buscou-se verificar o alinhamento das empresas com relao aos
princpios do valor, do fluxo do valor e perfeio.

Quadro 5.2 Sumrio das questes relativas ao envolvimento dos stakeholders no

processo de desenvolvimento de produtos, nas empresas A, B e C.
Empresa

Os inputs dos
stakeholders so
considerados?

Qual o nvel de
envolvimento dos
stakeholders?

Existem mecanismos de
feedback para
minimizao das
interaes?

H utilizao de
Times Integrados
de
Desenvolvimento?

Sim

Ao longo de todo o
processo. E com
mais nfase em
fases especficas.

Sim

Sim

Parcialmente

Somente no incio
do processo. E
parcialmente.

No se observou esta
preocupao.

No

Sim

Os stakeholders so
considerados
crticos para o
processo e por isso
so
sistematicamente
envolvidos ao longo
de todo o processo

Sim

Sim

124

Como observado na Quadro 5.2, as empresas tm comportamentos distintos

no que se refere ao envolvimento dos stakeholders e, sobretudo, na forma como se
organizam para tratar os inputs advindos desse envolvimento.
Em seguida, so apresentadas, de forma mais detalhada, informaes sobre o
envolvimento dos stakeholders.

5.3.2.1 Empresa A
Conforme destacado por Bernardes (2000), o atual processo de gesto de
desenvolvimento de produto da empresa A tornou-se mais voltado ao mercado e
preocupado com o atendimento e satisfao das necessidades e anseios dos clientes,
fornecedores, parceiros, acionistas e empregados.
A definio dos requisitos de alto nvel do projeto estabelecida com base
nas visitas e consultas feitas diretamente aos clientes e outros stakeholders. Segundo
o engenheiro entrevistado, at mesmo, os operadores de pista, que sinalizam para as
aeronaves durante a operao de taxiamento, foram convidados a emitir opinio.
Um dos principais mecanismos de envolvimento de stakeholders a Joint
Definition Phase. Em termos de processo, esta fase de definio conjunta do avio
substituiu uma antiga fase de definio da aeronave. O desenvolvimento da atual
famlia de produtos est sendo realizado em conjunto pela Empresa A e um grupo
previamente definido de parceiros. A Joint Definition Phase a etapa do projeto na
qual so detalhadas as exigncias de desempenho de cada um dos sistemas do avio,
assim como as exigncias de integrao funcional e fsica da aeronave
Na nova viso do processo de desenvolvimento do produto, representada na
Figura 5.2, as fases do programa passaram a ser, formalmente: estudos preliminares,
definio conjunta, detalhamento e certificao, seriao e phase out (sendo as
quatro primeiras fases componentes do processo de desenvolvimento do produto).
Como usual na Empresa A, o lanamento da nova famlia de produtos
representou a oportunidade para exercitar em grande escala as novas idias
gerenciais do Desenvolvimento Integrado de Produto DIP. No DIP, a estratgia de

125

gerenciamento de um programa sistematicamente utiliza equipes multidisciplinares

para integrar e de modo simultneo executar todos os processos necessrios. Nas
palavras de um engenheiro da Empresa A, mais do que engenharia simultnea. A
engenharia simultnea trouxe as pessoas juntas, mas no integrou os processos. O
DIP tambm aumenta a abrangncia do processo de integrao, incluindo parceiros
na fase de definio conjunta do avio e os clientes que participam de vrios fruns
de deciso e conduo do projeto como os steering comittees e os advisory boards
(Nascimento et. al. s/d).
Entre os benefcios esperados com o DIP, esto: maior foco no cliente e
produto, menor ciclo de desenvolvimento, menores custos globais, aumento da
competitividade e foco na integrao das diversas tecnologias requeridas.

5.3.2.2 Empresa B
A Empresa B tem limitaes em sua relao com os clientes e demais
stakeholders. Os clientes e usurrios finais so os que, de certa forma mais
participam e mais so envolvidos no processo de desenvolvimento do produto. Mas,
este envolvimento ocorre, com freqncia, no incio do processo, quando so
elaboradas as especificaes de projeto. A participao do cliente ao longo do
processo limita-se ao fornecimento de informaes complementares necessrias para
andamento do processo de desenvolvimento. Mesmo a participao do cliente no
incio do processo ocorre de forma limitada, pois est restrita ao preenchimento de
uma srie de documentos de solicitao de desenvolvimento e de especificaes
tcnicas mnimas necessrias.
Para a Empresa B, o principal valor desejado pelo cliente o cumprimento
dos prazos de desenvolvimento. Mas, esta identificao de valor ocorreu de forma
unilateral, sem a efetiva manifestao dos clientes.
A Empresa B terceiriza a manufatura dos produtos por ela desenvolvidos,
inclusive prottipos. Com isto as empresas de manufatura contratadas deveriam ser
elevadas ao nvel de parceiros estratgicos de desenvolvimento, mas no ocorre. Esta
relao verifica-se de forma distante entre contratante e contratado, o que revela

126

algumas disfunes na atividade de desenvolvimento de produto. A principal delas

uma complexa estrutura de garantia da qualidade, cujos ensaios de toda ordem so
realizados no s no prottipo desenvolvido, mas tambm nos lotes de produtos
recebidos. A falta de uma parceria com os fornecedores fora uma relao de
desconfiana do produto recebido.
Observou-se que tanto a forma como o cliente so envolvidos no processo
quanto a forma do envolvimento dos fornecedores responsvel direta pelos
retrabalhos existentes. Ou seja, o envolvimento espordico de clientes e fornecedores
no permite que o ciclo das interaes seja minimizado.

5.3.2.3 Empresa C
A indstria automobilstica reconhecidamente um dos setores mais
avanados na efetiva utilizao de engenharia simultnea. No caso especfico da
empresa C, a base de dados dos projetos fica na Alemanha, que se responsabiliza por
consolidar e disponibilizar as informaes sobre produtos e componentes. A
engenharia simultnea, porm no se estabelece somente com envolvimento da
matriz, fornecedores locais e externos tambm so diretamente envolvidos. Este
envolvimento simultneo de fornecedores no processo de desenvolvimento tem o
objetivo de eliminar as interaes (idas e vindas) tardias, que ocorrem com
freqncia quando se utiliza a engenharia tradicional, desta forma, obtm-se reduo
de tempo, custo e incerteza sobre as especificaes.

5.3.3

ELIMINAO DE INTERAES DESNECESSRIAS

A quarta questo do formulrio de investigao auxiliou na identificao dos

mecanismos de avaliao das informaes e das ferramentas de acompanhamento do

fluxo das informaes. Com este objetivo, foram explorados os seguintes pontos
nesta etapa:
-

As informaes necessrias ao PDP so avaliadas?

127

O fluxo das informaes monitorado de forma que elimine as interaes

indesejadas?

Quais as ferramentas utilizadas para o mapeamento e anlise do fluxo das

informaes?

Alm das interaes indesejadas, existe a preocupao com a eliminao

de outros tipos de muda?

Nesta etapa da avaliao, procurou-se verificar o alinhamento dos processos

das empresas estudadas com os princpios enxutos de fluxo de valor e perfeio.
O Quadro 5.3 apresenta um resumo das informaes obtidas.
Quadro 5.3 Sumrio das questes relativas ao fluxo de informaes no processo de
desenvolvimento de produtos, nas empresas A, B e C.
Empresa

Existe avaliao
das informaes
que causam
retrabalho?

Sim

A empresa possui
um software que
disponibiliza as
informaes e ao
mesmo tempo
possibilita avaliar de
que forma as
informaes
jusante podem
alterar
especificaes de
projeto montante.

Softwares de CAD,
principalmente o
Computer Aided Tridimensional Integrative
Application (CATIA), da
IBM, e de
acompanhamento e
evoluo de
especificaes.

Sim

No

O fluxo das
informaes
formalizado porm
no existe um
critrio para
avaliao das
informaes.

Sistema ERP.

No ativamente.

No

A empresa possui
dois sistemas
integrados de
compartilhamento
de informaes de
engenharia e
mecanismos de
reviso de projetos
associados.

Basicamente dois
softwares de
engenharia: ProEngineering e o
Computer Aided Tridimensional Integrative
Application (CATIA), da
IBM.

So poucas as
iniciativas.

Existe avaliao das

Quais as ferramentas
informaes que
utilizadas para a anlise
fluem?
do fluxo de
informaes?

Os diferentes tipos
de muda em
desenvolvimento
de produto so
identificados e
eliminados?

128

5.3.3.1 Empresa A
Os processos de desenvolvimento de produtos da Empresa A, como j citado
anteriormente, sempre foram meios de introduzir novas ferramentas de gesto e
engenharia. Em recente programa, a empresa introduziu o mock-up eletrnico,
ferramenta esta que contribuiu para a implantao da nova viso de equipe integrada
de projeto. Alm desta, outras ferramentas foram inseridas nesse programa. A
identificao e a avaliao das novas ferramentas so a funo principal do Programa
de Estratgia Tecnolgica da Empresa A. O novo sistema que est sendo utilizado,
possibilita a interao dos projetistas com o projeto por meio de um sistema de
realidade virtual. Ele permite ao engenheiro inserir sua parte do projeto no
computador e este mostra o resultado, de tal maneira que o projetista pode explorar a
parte interna do produto, como se estivesse realmente dentro e, ainda visualiza o que
ocorre quando seu projeto integrado ao conjunto que centenas de outros
engenheiros esto fazendo. Mais do que isso, esto para ser acrescidos ao sistema de
realidade virtual dispositivos que possibilitam outras formas de interao. Por
exemplo, luvas de torque permitiro aos engenheiros sentir o esforo manual
necessrio para abrir um armrio ou uma porta.
Outro software da Empresa A que atua como uma agenda eletrnica
aplicada para acompanhar a evoluo das especificaes, dando informaes sobre
desenhos,

especificaes,

suas

implementaes,

alteraes,

estado

de

desenvolvimento, ou seja, permite fazer a traceabilidade das especificaes. Para a

implantao desse software, foram precisos seis meses de adequao ao aplicativo, s
mudanas organizacionais que ele gera. O principal problema foi implementar a
cultura de formalizar documentos que antes estavam na cabea das pessoas.
Este software tambm utilizado para a gesto de requisitos, desde requisitos
de mercado at os mais detalhados. Permite fazer gesto de configurao e
integrao vertical. medida que se constri a estrutura do produto, estabelece-se
em paralelo a ligao com a rvore de requisitos (especificao de desempenho,
conformidade, qualidade). Durante a Joint Definition Phase, cada parceiro elabora os
microrrequisitos do sistema sob sua responsabilidade.

129

Para reforar a importncia desta ferramenta de gereciamento de informaes,

no desenvolvimento de projetos anteriores, o processo era diferente. A Empresa A
detalhou at os microrrequisitos que a fornecedora ou parceira teria de fabricar. Em
alguns casos, as especificaes no eram compatveis com os processos de
fabricao da fornecedora causando retrabalhos (Camargo Jr. et. al. apud
Nascimento et. al. s/d).
A empresa A, portanto, possui mecanismos importantes para verificao e
anlise do fluxo das informaes. Estes mecanismos oferecem a oportunidade de
identificao e antecipao dos possveis reflexos das interaes, ao mesmo tempo,
possibilitam o reconhecimento de mudas e sua conseqente eliminao.

5.3.3.2 Empresa B
Para o gerenciamento das informaes, a empresa B utiliza um software de
gerenciamento integrado. Esta integrao do gerenciamento foi feita de modo a
atender a organizao como um todo e com base em suas reas funcionais, no
possuindo, portanto, um mdulo especfico para o desenvolvimento de produtos. As
informaes a respeito desse processo podem ser obtidas em um mdulo do software
chamado nacionalizao que disponibiliza informaes sobre o pedido do cliente e
especificaes tcnicas.
Quanto ao fluxo de informaes entre as fases do processo de
desenvolvimento de produtos, estas podem ser obtidas por meio de um documento
fsico chamado Especificao Tcnica (ET), que acompanha o processo de
desenvolvimento do produto em todas as suas fases. No entanto, as informaes
constantes neste documento so apenas para consultas espordicas, quando do
surgimento de algum problema, sem o propsito especfico de que as informaes ali
contidas sirvam para anlise e melhoria do prprio processo.
Em uma observao direta, pde-se constatar que o desenho do projeto
mecnico de uma pea estava sem a identificao de reviso. Isto oferece fragilidade
ao processo pois possvel que se esteja utilizando uma fonte de informao

130

desatualizada, o que causaria retrabalhos desnecessrios, se esta informao fosse

considerada efetivamente desatualizada.
Com a recente certificao do sistema da qualidade, a empresa remodelou
seus processos e passou a entender o desenvolvimento de produtos, como resultado
de quatro grandes processos (Fig. 5.5):

Relao
com o
cliente

Especificao

Aquisio
t

Assistncia
Tcnica

de Projeto

Quadro 5.5 Macroprocesso do Ciclo de Desenvolvimento do Produto da Empresa

B.
De forma geral, a empresa B est muito aqum da Empresa A e da empresa C
no controle e anlise das informaes, e, conseqentemente, em seu desempenho na
eliminao das interaes. Com relao empresa B, verificou-se que a maiorias das
interaes ocorridas no projeto, diz respeito quelas atividades a jusante do processo.
Isto se deve ao fato de que a empresa B, como se pode observar na Figura 5.5,
estabelece o contato com os fornecedores (aquisio) muito tarde. Portanto, as
informaes sobre manufaturabilidade que deveriam ser incorporadas no incio do
processo, ao serem inseridas no final, acabam causando retrabalho desnecessrio.

5.3.3.3 Empresa C
A empresa C, assim como a empresa A, possui o software de engenharia
CATIA, que, alm de possibilitar a integrao de diversos times de desenvolvimento,
tambm capaz de integrar engenharia e fabricao. Alm do CATIA, a empresa
utiliza o software Pro-engineering, para o projeto de partes especficas do produto. A
utilizao destas ferramentas facilita o controle das informaes que fluem de uma
fase para outra do processo de desenvolvimento, pois as informaes ficam
disponveis para que os interessados possam acess-las a qualquer momento.

131

As iniciativas de melhoria no processo de desenvolvimento, como j

mencionado anteriormente, ficam a cargo de um departamento especfico. No se
evidenciou, por meio da entrevista realizada atividades mais robustas de eliminao
de desperdcios no processo, mesmo que o entrevistado tenha identificado uma srie
de desperdcios.
Segundo o gerente entrevistado:
Os

fluxos

de

informao

seguem

rigidamente

os

procedimentos

corporativos e revises no so to freqentes.

Conforme j mencionado, existem sistemas para avaliar o andamento das
certificaes; sistemas para gerenciar modificaes e sistema que acompanha o
andamento da elaborao de ferramentas e peas desenvolvidas por fornecedores.

5.3.4

SIMPLIFICAO DO CICLO DE DESENVOLVIMENTO

A quinta questo do formulrio serviu para verificar de que forma o ciclo de

desenvolvimento revisto e simplificado e se h preocupao com seu alinhamento

ao caminho crtico. Procurou-se, tambm, entender quais tecnologias podem ser
aplicadas para este fim.
Deve-se entender o ciclo de desenvolvimento, como algo maior do que o
processo de desenvolvimento do produto, pois alm de englob-lo, preocupa-se com
as questes de produo e de assistncia ao mercado.
Objetivando entender melhor estas questes, o formulrio procurou explorar
os seguintes tpicos:
-

Complexidade do ciclo de desenvolvimento,

Alinhamento das atividades com o caminho crtico,

Grupos multifuncionais envolvidos no processo de melhoria do ciclo de

desenvolvimento,

Tecnologias utilizadas.

132

Nesta

etapa,

buscou-se-se

verificar

alinhamento

do

ciclo

de

desenvolvimento das empresas estudadas com os seguintes princpios enxutos: fluxo,

fluxo de valor e perfeio.
O Quadro 5.4 apresenta um resumo das informaes obtidas durante esta fase
da investigao.
Quadro 5.4 Sumrio das questes relativas simplificao do ciclo de
desenvolvimento de produtos, nas empresas A, B e C.
Empresa

Procura-se
detectar
complexidades
desnecessrias no
ciclo de
desenvolvimento
do produto?

H um alinhamento
das atividades com
o caminho crtico?

Quais as tecnologias
utilizadas para a
melhoria do ciclo de
desenvolvimento?

Quem participa das

discusses sobre o
ciclo de
desenvolvimento?

Sim

O objetivo da
empresa reduzir o
quanto possvel o
ciclo do
desenvolvimento,
por meio do
alinhamento de
suas atividades com
o caminho crtico.

So inmeras as
ferramentas para este
propsito. Ex.: CAD,
CAM, CAE e CIM.

Integrantes da
clula gestora de
produto (Ncleo
Tcnico).

Eventualmente, e
por fora do
sistema da
qualidade.

No se verificou
esta inteno.

No h uma
atividade
especfica.

No h uma
atividade especfica.

Foram observadas
As questes sobre
ferramentas que
o ciclo de
possibilitam esta
desenvolvimento
melhoria, porm, no
esto centralizadas
foram observadas aes em um engenheiro.
neste sentido.

Foram observadas
ferramentas que
possibilitam esta
melhoria, porm, no
foram observadas aes
neste sentido.

As melhorias
normalmente
acontecem de
forma unilateral.

5.3.4.1 Empresa A
A Empresa A tem declaradamente uma preocupao com o ciclo de
desenvolvimento. Conforme j mostrado na Figura 5.2, seu complexo ciclo de

133

desenvolvimento de produtos foi resumido em cinco etapas formais: estudos

preliminares, definio conjunta, detalhamento e certificao, seriao e phase out.
Esta simplificao na representao do ciclo possibilitou a criao de um processo
designado Desenvolvimento Integrado de Produto DIP.
Nos ltimos anos, a empresa tem empreendido grande nfase na reduo do
tempo de ciclo baseada nas fases de seriao, por meio da aplicao dos princpios
enxutos na manufatura. Este esforo tem possibilitado a reduo do tempo do ciclo
de produo em aproximadamente 8% por semestre. Quanto ao ciclo completo de
desenvolvimento, a reduo chegou a ser de aproximadamente 50% ao longo de dez
anos.
Todas estas redues no tempo de ciclo so resultado de um grande foco no
mercado e, conseqentemente, nos clientes. Segundo a empresa, as fronteiras
nacionais tm sido deixadas de lado e o mundo tem se tornado menor, mais
integrado e mais eficiente. O que se espera da empresa para que ela possa prosperar
: virtualidade, conectividade, capacidade de adaptao, rapidez de resposta,
conscincia de mercado e inovao.
A reduo, portanto, do ciclo de desenvolvimento da Empresa A foi obtida
por meio de engenharia simultnea, novas tecnologias e novos modelos de
organizao e gesto. Como exemplo de novas tecnologias, pode-se citar a
manufatura virtual (utilizao conjunta das ferramentas de CAD, CAM e CAE) que
proporcionou, no s melhorias no processo produtivo, como tambm auxiliou na
concepo do produto.
O ciclo de desenvolvimento assim como outras questes relacionadas so
discutidos no que foi designado Ncleo Tcnico (Figura 5.6)

134

GDP

GDP

GDP

GDP
Engenheiro
Chefe

GDP

GDP

GDP

GDP

Figura 5.6 Representao do Ncleo Tcnico de Produto com seu engenheiro

chefe e respectivos gerentes de desenvolvimento de produto
Fonte: Adaptao de Nascimento et. al. s/d
O Ncleo Tcnico, tambm chamado de clula gestora, coordenado por um
Engenheiro Chefe. Participam desta clula oito Gerentes de Desenvolvimento de
Produto GDP. H um GDP para Aeronutica, outro para Estruturas, outro para
Sistemas Eletro/Eletrnico, etc.

5.3.4.2 Empresa B
Na empresa B, a preocupao com o ciclo de desenvolvimento tornou-se mais
evidente com a implantao do sistema de gesto da qualidade SGQ. O engenheiro
responsvel pela implementao do SGQ evidenciou que, por livre iniciativa, havia
mapeado todos os passos do processo de desenvolvimento de produtos da empresa e
pouca importncia havia sido dado a este trabalho. Com o processo de certificao
no SGQ, um novo fluxograma foi elaborado, arquivando-se o trabalho anterior.
Cabe ressaltar que mesmo com o novo mapeamento das atividades que
compem o processo de desenvolvimento, pouco se discutiu sobre a real importncia
de cada uma destas atividades, sendo este novo fluxograma simplesmente uma
representao do estado atual.

135

A empresa B dispe da ferramenta CAD (Computer Aided Design) que possui

recursos limitados de simulao quando no integrada a outras ferramentas de
CAM (Computer Aided Machining) ou CAE (Computer Aided Engineering). Alm
disto, no se verificou qualquer iniciativa de uso desta ferramenta para melhoria do
ciclo de desenvolvimento.
A participao no processo de melhoria do ciclo de desenvolvimento ocorre
de forma difusa: por intermdio de qualquer pessoa ligada ao processo, e at mesmo
de pessoas externas ao processo. Normalmente, esta melhoria acontece baseada em
uma ficha de ao preventiva que, segundo o manual da qualidade da empresa, serve
para eliminar a causa de uma no-conformidade potencial. A rigor isto no pode ser
considerado um processo de melhoria, mas o instrumento que a empresa utiliza
para esta finalidade.
Neste tpico, as empresas distanciaram-se ainda mais no que se refere ao
alinhamento com os princpios e prticas enxutas. A Empresa A investiga e procura
utilizar as tcnicas e ferramentas mais avanadas para a melhoria e reduo do ciclo
de desenvolvimento de seus produtos, enquanto a Empresa B procura realizar as suas
atividades de forma burocrtica e com poucos resultados. Apesar de definir prazo
como valor para os clientes, na Empresa B no existe um monitoramento do tempo
de desenvolvimento dos produtos, incorrendo, conseqentemente, na impossibilidade
de quantificar possveis redues no ciclo de desenvolvimento.

5.3.4.3 Empresa C
Neste quesito, a avaliao realizada pelo prprio entrevistado foi a mais baixa
de todas; segundo sua resposta, o ciclo tem sido acelerado de forma sistmica nos
ltimos anos, mas falta um processo de eliminao sistmica de desperdcios
relacionados ao desenvolvimento.
Na exibio de um produto experimental em uma feira de automveis,
verificou-se uma possvel demanda por este produto, que era, na verdade, uma verso
fora de estrada para um automvel j existente. A demanda pelo produto forou
uma grande reduo no tempo de desenvolvimento e um lanamento recorde no

136

mercado para a empresa. Quando questionado se o sucesso obtido neste

desenvolvimento poderia ser reproduzido em uma nova tentativa acelerada de
desenvolvimento, o gerente informou que seria muito difcil garantir a reproduo da
atividade em outro processo.

5.3.5

PRODUTOS E PROCESSOS DESENVOLVIDOS SIMULTANEAMENTE

A sexta questo do formulrio permitiu que fosse verificado o alinhamento

das empresas A e B, no que se refere ao desenvolvimento integrado e simultneo de

produtos e processos. Basicamente, foram procuradas evidncias da existncia de
times para o desenvolvimento integrado de produtos e processos.
Os seguintes tpicos tambm constaram desta avaliao:
-

Organizao para o desenvolvimento,

Extenso da utilizao de equipes multidisciplinares,

Existncia de mtricas para avaliao do processo, e o

Envolvimento dos stakeholders.

Nesta etapa, procurou-se verificar o alinhamento do ciclo de desenvolvimento

das empresas estudadas com os seguintes princpios enxutos: valor e fluxo de valor.
O Quadro 5.5 apresenta um resumo das informaes obtidas durante esta fase
da investigao.

137

Quadro 5.5 Sumrio das questes relativas ao desenvolvimento integrado de

produtos e processos, nas empresas A, B e C.
Empresa

Qual o tipo de
So utilizados
organizao para o Times Integrados de
desenvolvimento
Desenvolvimento?
de produtos e
processos?

H existncia de
mtricas para avaliao
do processo?

Os stakeholders
so envolvidos nas
decises a respeito
dos produtos e
processos?

Matricial

Sim.

Sim.

Sim.

Funcional.

Somente a
montante do
processo.

Sim.

No h o
envolvimento
contnuo dos
stakeholders ao
longo do processo
de
desenvolvimento.

Funcional

Sim

Sim

Sim

5.3.5.1 Empresa A
Conforme observado na Figura 5.6 da seo 5.3.4.1, a empresa A utiliza times
integrados para o desenvolvimento de produtos. Esta integrao no reflete apenas de
uma inovao de processos, trata-se tambm de atender a uma demanda de clientes
cada vez mais exigentes em termos de custo e prazo.
A organizao desses times integrados, chamados de Ncleos Tcnicos de
desenvolvimento, verifica-se de forma matricial conforme representao simplificada
na Figura 5.6.
Esta integrao no deve, porm, ocorrer somente no nvel zero da rvore do
produto. Ela deve se reproduzir nos diferentes nveis. Conforme Nascimento, et. al.
s/d, por este motivo que a idia de estruturas, cuja topologia se reproduz, conforme
se modifica a escala de anlise, revela-se til, pois conforme se percorre a rvore de
produto, a cada nvel, as equipes precisam reproduzir uma estrutura interna similar,
incorporando as preocupaes com produo, marketing, desejos do cliente,
engenharia, assistncia tcnica, facilidade de uso e manuteno, etc. Numa matriz,
seria como colocar entradas similares em todos os nveis da rvore de produto.

138

Figura 5.7 Representao simplificada da estrutura matricial para integrao dos

diferentes times de desenvolvimento.

Esta sucesso de estruturas que se repetem em nveis diferentes lembra a

teoria dos fractais. Obviamente, embora o formato geral lembre a teoria, estas
estruturas no so idnticas (como no caso dos Fractais) em razo das necessidades
de adaptao para fazer frente s especificidades de cada componente do produto.
Nesta estrutura matricial, verifica-se a participao dos diferentes parceiros
de desenvolvimento. Isto implica que a extenso da estrutura extrapole as fronteiras
fsicas da empresa.

5.3.5.2 Empresa B
A empresa B possui uma organizao para o desenvolvimento de produtos
extremamente funcionais. Com o advento da implementao da qualidade na
empresa, surgiu a necessidade de desenvolver uma nova estrutura organizacional,
baseada em processos (esta estrutura aparece na Figura 5.5, da seo 5.3.3.2.). A
nova organizao, no foi implementada fisicamente e nenhuma alterao no arranjo
fsico da empresa foi observada. Esta diferena entre a organizao prevista e a real

139

causa dificuldade aos envolvidos no que tange ao entendimento da importncia de

uma estrutura por processos. Como conseqncia, a integrao do time de
desenvolvimento fica restrita, como j mencionado, a uma atividade a montante do
processo.
A participao dos stakeholders nos desenvolvimentos de produtos e
processos limita-se ao fornecimento de informaes necessrias aos diferentes
departamentos funcionais da empresa.

5.3.5.3 Empresa C
Os times multidisciplinares so prticas correntes e sua formao e
responsabilidades constam do procedimento de desenvolvimento. A integrao dos
profissionais nesses grupos permite priorizar atividades otimizando resultados. Para
tanto, so usadas ferramentas de CAD/CAM/CAE j citadas. H, tambm
ferramentas para a simulao, porm sua utilizao no chega a ser comparada s da
empresa A.
Conforme o gerente entrevistado: Os times multidisciplinares so
estabelecidos nos procedimentos internos da empresa e so adaptados, conforme o
tamanho do programa, isto quando existe um programa de desenvolvimento de
uma nova plataforma, os times tm uma determinada configurao. Quando so
realizadas apenas pequenas modificaes estticas de um ano para outro, os grupos
so readequados.

5.4

CONSIDERAES SOBRE AS PRTICAS INDUSTRIAIS

Em primeiro lugar, a anlise dos casos revelou que se trata de empresas com

grandes diferenas nos mais variados aspectos, tanto no que se refere ao processo de
desenvolvimento de produtos como nas questes organizacionais e tecnolgicas. Os
produtos desenvolvidos tambm so consideravelmente diferentes.

140

Em segundo lugar, mostrou que as semelhanas existentes entre as empresas

dizem respeito sobretudo ao tipo de indstria (empresas A e B) e confiabilidade
exigida de seus produtos (empresas A, B e C).
Durante as entrevistas, ficou evidente que os envolvidos com o processo de
desenvolvimento no compreendem com exatido, como a mentalidade enxuta pode
ser aplicada ao processo de desenvolvimento de produtos. Em alguns casos,
engenheiros no sabiam sequer o significado do termo enxuto. Esta dificuldade de
compreenso revelou a necessidade de um breve esclarecimento aos entrevistados do
significado do termo e uma ligeira reviso dos princpios e prticas enxutas. A
empresa A, por possuir um programa de manufatura enxuta para seus produtos, foi a
que melhor compreendeu a proposta de melhoria do processo de desenvolvimento de
produtos baseado na aplicao de conceitos enxutos. A empresa C tem um gerente
envolvido no processo de desenvolvimento que conhece as prticas enxutas, contudo,
basicamente, sua preocupao com a entrega do valor, ultima etapa do modelo de
referncia utilizado nesta tese.
Em todos os casos, evidenciou-se que a aprovao e comprometimento da
alta administrao seriam necessrios para qualquer processo de mudana.
A partir a aplicao dos formulrios de pesquisa e apoiado nas informaes
obtidas, foi possvel avaliar o alinhamento das empresas com relao aos princpios
enxutos. A empresa A tem, em vrias etapas do processo de desenvolvimento, um
alto grau de alinhamento. Esta convergncia leva ao entendimento de que mesmo
sem uma abordagem estruturada para implementao dos princpios enxutos no
processo de desenvolvimento de produtos, a empresa caminha na direo de um
processo enxuto de desenvolvimento. A empresa B, por meio da avaliao do
questionrio, no apresentou alinhamento com os princpios enxutos. A empresa C
tambm est distante de um alinhamento maior com os princpios e prticas enxutas,
especialmente na questo cinco, em que se evidenciou a no existncia de
ferramentas especficas para a melhoria do processo de desenvolvimento. Esta
deficincia justifica, portanto, a idia, na empresa C, de que um processo de
desenvolvimento enxuto pode ser obtido simplesmente com a eliminao de
desperdcios.

141

O grfico abaixo explicita o grau de alinhamento das empresas analisadas

com base nos formulrios do anexo A.
6
5
4
Empresa A
3

Empresa B
Empresa C

2
1
0
Q1

Q2

Q3

Q4

Q5

Q6

Figura 5.8 Grau de alinhamento das empresas A, B e C com os princpios e

prticas enxutas.

Em

face

dos

problemas

identificados,

no

no

processo

de

desenvolvimento, mas tambm nos produtos que se originam desse processo,

pertinente inferir que as prticas identificadas na empresa A, a despeito das
diferenas observadas entre as empresas, podem ser teis empresa B e empresa C.
Alm do que, as semelhanas e diferenas encontradas ofereceram terreno frtil para
o desenvolvimento de uma metodologia para implementao de princpios enxutos
em processos de desenvolvimento de produtos.

142

5.5

QUADRO RESUMO DAS PRINCIPAIS CONCLUSES OBTIDAS NA

ANLISE CRUZADA DOS ESTUDOS DE CASO

Quadro 5.6 Quadro resumo das principais concluses obtidas na anlise cruzada
dos estudos de caso.
Questes Aplicadas
1.

Entendimento

das

empresas

Principais Concluses
com

relao aos princpios e prticas enxutas

Existe a necessidade de uma preparao/

treinamento a respeito dos princpios e prticas
enxutas.

preciso estabelecer a necessidade de

mudana.

Os envolvidos com o PDP, sobretudo a

gerncia, precisam comprar a idia.

2. Formalizao e compreenso do PDP

pelos envolvidos.
3. Sobre o envolvimento dos stakeholders

Os PDPs devem ser formalizados e devem

estar integrados estratgia da empresa.

Os stakeholders, muitas vezes, no so

identificados de forma correta,

As necessidades dos diferentes stakeholders

nem sempre so consideradas de forma equilibrada,

Existe uma idia de se considerar apenas as

necessidades dos consumidores finais.

4. Quanto eliminao de desperdcios

durante o processo

A preocupao com a eliminao de

desperdcios no PDP, no tratada de forma
sistemtica,

A idia de fluxo no est consolidada nas

atividades de desenvolvimento de produtos,

O arranjo fsico, assim como na manufatura,

tambm pode ser importante para o fluxo no
processo de desenvolvimento de produtos,

A representao do PDP deve considerar

apenas as atividades que criam valor.

5. Atividades simultneas

As empresas ao desenvolverem processos

simultneos levam em conta apenas a reduo do
tempo de desenvolvimento,

Empresas de menor porte tm dificuldade com

a implementao de atividades simultneas no
processo de desenvolvimento.

6. Melhoria

As empresas esto desejosas por melhoria em

seus processos,

Melhorias em processos de desenvolvimento

so obtidas baseado em mudanas culturais,

As melhorias devem ser tratadas como

objetivos de longo prazo.

143

BACKGROUND

TERICO

PARA

DESENVOLVIMENTO

DA

METODOLOGIA
Este captulo apresenta um breve desenvolvimento terico dos pontos de
referncia para elaborao da metodologia proposta para implementao de
princpios enxutos no processo de desenvolvimento de produtos. O pensamento
enxuto e o modelo de trs fases desenvolvido pelo Lean Aerospace Initiative LAI
auxiliar no entendimento do processo de criao de valor e tambm na compreenso
do momento para implementao de cada princpio no processo de desenvolvimento
de produto. Partindo do pressuposto, que o objetivo da metodologia, que ser
proposta no captulo 7, conduzir o processo de desenvolvimento de produtos a um
estado futuro enxuto, o gerenciamento de projetos aparece, como uma ferramenta
para a consecuo deste objetivo.

6.1

O MODELO DE TRS FASES PARA CRIAO DE VALOR

Tornar-se enxuto, como tradicionalmente se define, importante, mas isto

apenas uma parte da histria. O mais importante utilizar os conceitos e abordagens

enxutos para criar valor para todos os stakeholders e para todos os objetivos da
empresa (Murman et. al. , 2002).
Entender a criao de valor no difcil30, porm determinar as aes
especficas para criar valor pode ser uma tarefa difcil, principalmente em um
ambiente de constante mudana. Como se pde observar no captulo 4, grande parte
das aes que tm por objetivo a criao de valor est definida como eliminao de
desperdcios e est voltada para as operaes de manufatura. Muitas abordagens e
mtodos suportam esta eliminao sistemtica de desperdcios e podem ser
apreciados como importantes mecanismos para a criao de valor. Contudo,
utilizao de ferramentas, por exemplo mapeamento do fluxo de valor, est mais
voltada para a entrega do valor do que propriamente para a identificao do valor. A
30

Ver captulo 4.

144

proposta do Lean Aerospace Initiative LAI que a identificao, proposio e

entrega de valor devam ser feitas de forma estruturada. Para tanto, um modelo
terico para criao do ciclo do valor foi desenvolvido, baseando-se em modelos
existentes e estudos de casos (Stanke, 2001) e (Murman, 2002). Este modelo consiste
em um processo interativo e seqencial: identificao do valor, proposio do valor,
e valor entregue. Uma ilustrao deste modelo est representada figura 6.1.
Pesquisas do MIT para determinar o significado do termo valor do ciclo de
vida utilizaram este modelo para examinar o que se havia descoberto, e com isto foi
possvel verificar um excelente alinhamento do modelo de trs fases com a criao
de valor (Murman, 2002). O valor do ciclo de vida de um produto antecipa o valor do
ciclo de vida de um programa inteiro, no s em termos de custo baixo para
desenvolver ou construir o produto, inclui tambm custos de operao e suporte,
custos de renovao de plataforma, assim como outros fatores.

Identificao do
valor

Propor o valor

Valor entregue

Identificao do
valor para os
stakehoders.

Aceitar e
desenvolver a
abordagem.

Executar a
promessa.

Dinmica e Interatividade

Figura 6.1 Modelo para criao ciclo do valor

Fonte: Murman (2002).

Estes trs processos da Figura 6.1 interagem uns com os outros e com o
mundo dinmico no qual eles esto inseridos. A comparao deste modelo com
modelos existentes de gerenciamento de valor, fases de ciclo de vida e arquitetura de
sistemas deu suporte evoluo do modelo de criao de ciclo do valor e resultou em
um entendimento mais refinado de criao de valor (Stanke, 2001). Cada abordagem

145

existente oferece uma contribuio nica para o conceito de ciclo do valor.

Individualmente estas abordagens tm limitaes. Mas, por meio da criao de um
novo foco para um ciclo do valor, as vrias perspectivas combinadas superam suas
limitaes. Especialmente nos seguintes pontos: a definio de valor no fica
limitada relao entre utilidade e custo; as consideraes sobre ciclo de vida no
ficam limitadas s operaes; e os custos determinados por confiabilidade, uma
abordagem holstica de desenvolvimento do sistema, no ficam limitados somente ao
sistema, mas tambm empresa envolvida no desenvolvimento.

6.1.1

PRESSUPOSTOS
Existem vrias suposies associadas ao modelo de criao de valor.

Primeiro, supe-se que o valor um atributo multidimensional do sistema, tendo

pelo menos um conjunto de dimenses relacionadas capacidade tcnica, custo, e
momento (timing). Segundo, supe-se que todos os stakeholders a despeito de suas
diferenas individuais podem concordar em focar o valor como um atributo de
sistema baseado na sua importncia. E, talvez o mais importante pressuposto deste
modelo seja que os stakeholders tero um nvel apropriado de insight e influncia em
cada fase do processo, ou seja, identificao, proposio e entrega do valor, exigindo
uma clara comunicao e um fluxo de informao entre todos os envolvidos.

6.1.2

IDENTIFICAO DO VALOR
A identificao do valor consiste na determinao dos stakeholders, suas

necessidades e expectativas e suas contribuies para o sistema. As necessidades e

expectativas podem ser articuladas na forma de sistema de objetivos. So
considerados stakeholders quaisquer grupos ou indivduos que afetam ou so
afetados pelo alcance dos objetivos organizacionais (Freeman, 1984)31. Podem ser
includos neste grupo: clientes, usurios finais, compradores, produtores,
desenvolvedores, fornecedores, financiadores, entidades polticas e/ou comunidades.

31

Para efeito desta tese consideraremos como stakeholders aqueles tratados no captulo 4.

146

Cada stakeholder contribui com uma informao nica, considerando: parcerias e

estratgias corporativas, anlise de mercado, expectativas financeiras, necessidades
do operador ou do consumidor, restries regulatrias e certificao e o momento
para desenvolvimento do sistema (Stanke, 2001).
Aps a identificao dos stakeholders, vem a necessidade de atentar para a
identificao de qual parte do processo ou projeto ir agregar valor para cada um
destes stakeholders, e quais tipos de compensaes sero necessrias para o
balanceamento no atendimento das necessidades de todos os envolvidos. Segundo
Murman et. al.(2002), isto de certa forma complexo, pois muitos dos stakeholders
relutam em explicitar todas as suas necessidades com receio de perder fora em
negociaes futuras, ou muitos deles no conseguem articular ou antecipar todas as
dimenses de valor que so importantes. Pesquisas a respeito de como conduzir uma
efetiva anlise de mercado para produtos de consumo evidenciam esta complexidade
para o entendimento de valor. O desafio, ento, nesta fase, balancear as
perspectivas dos stakeholders.

6.1.3

PROPOSIO DO VALOR
O conceito de proposio de valor no novo, e o termo aparece de forma

extensiva na literatura atual sobre negcios. O objetivo da fase de proposio de

valor estruturar o fluxo do valor apoiado nas proposies de valor de cada
stakeholder, de forma que pessoas, grupos e empresas contribuam com seus esforos
ou recursos para o fluxo do valor.
As contribuies e expectativas identificadas podem ser traduzidas em um
conceito de sistema, arquitetura, e estrutura de programa aceita pelos stakeholders. A
negociao para balancear as vrias contribuies e expectativas de todos os
stakeholders est baseada nos objetivos comuns de alcanar o valor do ciclo de vida.
No proposto que todos os stakeholders desconsiderem suas diferenas individuais.
A proposio de um valor nico um link essencial entre os valores identificados e o
que vai ser efetivamente entregue. O objetivo geral encontrar uma proposta que

147

entregue o mximo de valor para cada stakeholder. Por decorrncia, torna-se

importante comunicar o valor acordado para todos os envolvidos.
Os stakeholders necessitam enxergar que as suas necessidades de valor esto
sendo alcanadas, e isto, muitas vezes, exigir tarefas adicionais. Por exemplo,
capturar a razo de cada deciso durante o processo de desenvolvimento de produto
importante, porque no se pode assumir que todas as pessoas que iniciaram o
processo estaro presentes ao final do mesmo. Outro exemplo se relaciona com a
necessidade de construir competncias no que tange coleta e compartilhamento de
informaes adicionais; isto no contribui diretamente para o produto final, mas
atende a empresa quando da necessidade de acesso rpido a informaes que daro
suporte s decises de gerenciamento.

6.1.4

ENTREGA DO VALOR
Desenvolver, produzir, operar e sustentar um sistema, assim como gerenciar o

programa que executa este trabalho so consideradas atividades que compem o

valor entregue. Ao mover-se para a fase da entrega do valor, o grupo de stakeholders
aumenta a preocupao com o gerenciamento da transio da programao e
arquitetura de sistema para a execuo do programa e desenvolvimento do sistema.
Apesar de parecer intuitivamente uma relao direta, a relao entre a entrega de um
determinado valor e o valor proposto pode ser complicada. Felizmente, existem
muitas estratgias, prticas, ferramentas e mtodos que auxiliam este trabalho: o
que revelam os estudos de caso de Stanke e Murman (2002). Numa dada proposta de
valor, existem mltiplas maneiras de desenvolver e aperfeioar o sistema de ciclo de
valor.
A fase de implementao, ou seja, da entrega do valor, a mais comum no
contexto de princpios e praticas enxutas. aqui onde o valor entregue tanto para
os stakeholders que participam do fluxo do valor quanto para o usurio final, quando
o produto ou servio recebido. neste momento que todas as promessas, explcitas
ou implcitas, so alcanadas.

148

Entregar valor, fazendo convergir benefcios para os stakeholders, requer uma

cadeia de atividades chamada fluxo de valor. O foco excessivo na entrega do valor
para o usurio final ou qualquer outro stakeholder cria um fluxo de valor
disfuncional que ignora outros envolvidos. O valor entregue, para Stanke e Murman
(2002), depende do valor que se agrega em cada passo ao longo do fluxo do valor.

6.2

GERENCIAMENTO DE PROJETOS
Como foi possvel notar no captulo quatro, e segundo Morgan (2002), um

dos maiores desafios no processo de desenvolvimento de produtos gerenciar e

coordenar a complexidade deste processo. Ou seja, centenas ou milhares de tarefas
tecnicamente interdependentes devem ser executadas por dezenas ou centenas de
pessoas as quais compem organizaes multifuncionais e so utilizados recursos
compartilhados, resultando em um produto nico.
O gerenciamento de projetos uma abordagem relativamente moderna e
caracteriza-se por novos mtodos de reestruturao da forma de gerenciar e da
adaptao de tcnicas especiais de gerenciamento, com o propsito de obter melhor
controle e uso dos recursos disponveis (Kerzner, 1998). A fim de entender o
gerenciamento de projetos, necessrio definir o que projeto.

6.2.1

O PROJETO
Segundo o PMI (2001), as organizaes executam trabalho. Este trabalho

envolve servios continuados e/ou projetos, embora possa haver superposio entre
os dois. Servios continuados e projetos possuem muitas caractersticas comuns; por
exemplo, ambos so:

Executados por pessoas;

Restringidos por recursos limitados; e

Planejados, executados e controlados.

149

Para Kerzner (1998), um projeto pode ser considerado em termos de uma

srie de atividades e tarefas que:

Tm um objetivo especfico e devem ser completadas dentro de certas

especificaes;

Tm datas definidas de incio e trmino;

Tm investimentos limitados (se aplicvel); e

Consomem recursos (ex.: dinheiro, pessoas e equipamentos).

Servios continuados e projetos diferem sobretudo, porque enquanto os

primeiros so contnuos e repetitivos, os projetos so temporrios e nicos. Assim,
um projeto pode ser definido em termos de suas caractersticas distintas um projeto
um empreendimento temporrio com o objetivo de criar um produto ou servio
nico. Temporrio significa que cada projeto tem um comeo e um fim bem
definidos. nico significa que o produto ou servio produzido de alguma forma
diferente de todos os outros produtos ou servios semelhantes.

6.2.2

AS FUNES DE GERENCIAMENTO
Para Kerzner (1998), o aspecto que dificulta o gerenciamento de projetos diz

respeito aos indivduos pertencentes interface projeto-funo que necessitam,

normalmente, reportarem-se a dois chefes. Gerentes funcionais e gerentes de
projetos, em virtude de seus diferentes nveis de autoridade, tratam seus
subordinados de diferentes formas, dependendo da filosofia de sua escola de
gerenciamento. Normalmente, existem cinco escolas de gerenciamento:

A escola clssica / tradicional onde a nfase colocada no objetivofim, com pouca preocupao com as pessoas;

A escola emprica onde o aprendizado ocorre pela experincia

prtica;

A escola comportamental onde o gerenciamento considerado como

sendo um sistema de relaes culturais;

150

A escola da teoria das decises onde o gerenciamento visto como

uma abordagem racional para tomadas de deciso, utilizando um
sistema de modelos e processos matemticos (ex.: pesquisa
operacional); e

A escola de sistemas onde o gerenciamento se d por meio do

desenvolvimento de modelos de sistemas, caracterizado por entradas,
processamento e sadas e da identificao direta do fluxo de recursos
(dinheiro, equipamentos, instalaes, pessoal, informao e materiais)
necessrios para alcanar determinado objetivo.

Gerentes

modernos

ainda

tendem

identificar

as

habilidades

responsabilidades de gerenciamento em termos de princpios e funes

desenvolvidas nas primeiras escolas de gerenciamento32, que so:

Planejamento

Organizao

Direo

Coordenao

Controle

Embora de estas funes gerenciais tinham sido amplamente aplicadas em

estruturas gerenciais tradicionais, tiveram de ser redefinidas para posies gerenciais
que so temporrias. O significado fundamental de cada uma dessas funes
continua o mesmo, porm suas aplicaes se modificaram para atender s
necessidades especficas do gerenciamento de projetos (Kenzner, 1998).

32

Para maiores detalhes sobre o incio das escolas de gerenciamento consultar Administrao
Industrial e Geral Fayol (1950).

151

6.2.3

GERENCIAMENTO DE PROJETO NO PROCESSO DE DESENVOLVIMENTO DE PRODUTOS

Com o objetivo de desenvolver esta tese, a abordagem de gerenciamento de

projeto dar suporte construo da metodologia proposta. Este suporte est

relacionado com os processos que nortearo a construo da metodologia. Mas, para
compreender o gerenciamento de projetos no contexto de desenvolvimento de
produtos preciso fazer algumas consideraes mais amplas sobre o gerenciamento
de projetos. Quando se observam as atividades de empresas pblicas e privadas,
nota-se que estas atividades se compem, basicamente, de operaes e projetos, que
podem ser executados de forma independente e que, muitas vezes, podem sobreporse. Tanto as operaes como os projetos necessitam de recursos de diferentes tipos,
como, por exemplo, humanos, materiais e financeiros. Por serem normalmente
limitados, estes recursos precisam de atividades gerenciais no que tange ao
planejamento, execuo e controle. De forma geral, a principal diferena entre as
operaes e os projetos que as operaes so processos contnuos e repetitivos, e os
projetos so temporrios, nicos e, frequentemente, complexos. Como j explicitado,
um dos maiores desafios em desenvolvimento de produtos gerenciar e coordenar
este complexo processo.
So alguns exemplos de projetos:
o A implantao de um sistema de informao gerencial;
o A construo de uma hidreltrica;
o A realizao da mudana de uma empresa de uma cidade para
outra; ou
o O desenvolvimento de um novo produto ou servio.
Os processos de gerenciamento dizem respeito descrio e organizao do
trabalho do projeto.
Para Romano (2003), em linhas gerais, o modelo de gerenciamento de
projetos organizado em cinco grupos de processos. Os vetores representam o fluxo
do processo onde se pode entender tambm o fluxo das informaes. Os grupos de

152

processos indicados na figura 6.2 so conectados pelas sadas de seus processos, isto
, os resultados de um tornam-se entradas de outros. As atividades dos grupos de
processos de gerenciamento vo se sobrepondo ao longo da realizao do projeto,
fazendo com que as trocas de informaes ocorram em todas as fases do projeto,
caracterizando a natureza integrada do gerenciamento de projetos. Os processos de
gerncia de projetos, que so aplicveis maioria dos projetos, esto representados
na Figura 6.2.

Processo de
incio

Processo de
Planejamento

Processo de
Execuo

Processo de
Controle

(As setas representam

fluxos de documentos e
itens documentveis)

Processo de
Encerramento

Figura 6.2 Ligaes entre os grupos de processos

Fonte: PMI (2001)
Os processos de gerncia de projetos podem ser organizados em cinco
grupos, cada um deles contendo um ou mais processos:

Processos de iniciao reconhecer que um projeto ou fase deve

comear e comprometer-se para execut-lo(a). Em geral, um projeto
no formalmente iniciado at que um estudo sobre sua viabilidade
seja realizado.

Processos de planejamento planejar e manter um esquema de

trabalho vivel para se atingir aqueles objetivos de negcios que
determinaram a existncia do projeto. O resultado deste processo ,
normalmente, um plano formal, colocado em forma de documento
escrito.

153

Processos de execuo coordenar pessoas e demais recursos para

realizar o plano. Em outras palavras o processo de execuo que
estabelece a dinmica do projeto.

Processos de controle assegurar que os objetivos do projeto esto

sendo atingidos, por meio da monitorao e da avaliao do seu
progresso, tomando aes corretivas quando necessrias.

Processos de encerramento ou concluso Formalizar a aceitao do

projeto ou fase e encerr-lo(a) de uma forma organizada.

Conforme citado anteriormente, os grupos de processos se inter-relacionam

por meio de suas entradas e sadas. As sadas (resultados) de um processo sero as
entradas (insumos) para o processo seguinte. Mesmo que esta representao induza
ao entendimento de que os processos devam ocorrer de forma seqencial, muitas
sobreposies de atividades podem verificar-se ao longo do projeto. A Figura 6.3
oferece esta representao.

Figura 6.3 Sobreposio dos grupos de processos

Fonte: PMI (2001)
A abordagem de gerenciamento de projetos torna-se til nesta tese, conforme
oferece uma estrutura gerencial para implementao da metodologia proposta.
Assim, o processo de implementao dos princpios enxutos no processo de
desenvolvimento de produtos deve ser uma interveno com incio e trmino
definidos, a estrutura da abordagem de gerenciamento de projetos, por meio de seus
grupos de processos, ser utilizada para nortear o projeto de implementao.

154

6.3

FERRAMENTAS PARA O MAPEAMENTO DO FLUXO DO VALOR EM

DESENVOLVIMENTO DE PRODUTOS
Nesta parte da tese, so descritas diversas ferramentas para anlise de

processos, que podem auxiliar os envolvidos com o desenvolvimento de produtos no

mapeamento do fluxo do valor. Segundo Millard (2001), isto deve ocorrer aps a
interpretao do fluxo de valor em termos de fluxo de informao. Algumas
ferramentas aqui descritas podem no ser exatamente destinadas ao mapeamento do
fluxo do valor, assim como o conjunto de ferramentas aqui apresentado no pretende
ser conclusivo.

6.3.1

GRFICO DE GANTT
O grfico de Gantt um tradicional mtodo para a representao, seqncia,

programao e relao de dependncia entre as diversas atividades que compem um

projeto, ou o desenvolvimento de um produto.
A Figura 6.4 apresenta um exemplo deste grfico.
2005

Atividade

2006

2007

2008

Trim 1 Trim 2 Trim 3 Trim 1 Trim 2 Trim 3 Trim 4 Trim 1 Trim 2 Trim 3 Trim 4 Trim 1 Trim 2 Trim 3 Trim 4

PT1 Gereciamento do Projeto

PT2 Relacionamento Externo
PT3 Desenvolvimento Espec. Funcionais
PT4 Produo do Grupo 1 de Espec.
PT5 Produo do Grupo 2 de Espec.
PT6 Teste de Prottipo
PT7 Mdulo Completo do Grupo 1
PT8 Mdulo Completo do Grupo 2
PT9 Produo
PT10 Avaliao pelo Usurio
Demonstrao
Avaliao Final

Figura 6.4 Exemplo de Grfico de Gantt

Fonte: Millard (2001).

155

Neste tipo de grfico, possvel observar quando cada atividade inicia e em

que data espera-se que ela termine. Em funo destes parmetros, so visualizadas no
grfico as possveis sobreposies de tarefas, ou seja, as tarefas que tero de ser
executadas em paralelo a outras. A visibilidade destas atividades em paralelo
permite, de uma forma direta, observar em quais momentos do projeto ser exigido
maior esforo, no sentido de cumprir as datas programadas. Algumas atividades, por
no apresentarem folga, sero consideradas crticas.

6.3.2

MAPA WARD
O Lean Enterprise Institute em conjunto com a empresa Ward Synthesis33

tem avanado em uma estrutura que possibilita a visualizao, simultaneidade e

natureza cclica do processo de desenvolvimento de produtos. Ao invs de empregar
flechas, so utilizadas linhas curvas para descrever o fluxo entre os passos do
processo. Estas linhas curvas representam os custos e recursos necessrios a cada
atividade. O volume de recursos e os custos envolvidos so proporcionais ao
tamanho das parbolas que as linhas descrevem.

Des envol vi mento

de M aterial
M aterial
Des enhos
Fer ramenta
Proj eto
Prelim i nar

Conceito

Tes tes
E xec uo

P roposta
Desenvol vi mento
dos tes tes

An li ses

Infra- estrutura

Especificaes de
Interf ac e/Fu nes

Tempo/ Programao

Figura 6.5 Exemplo de Mapa Ward de Fluxo de Valor

Fonte: Adaptado de Millard (2001).
33

A Ward Synthesis uma empresa cuja misso desdobrar os princpios do desenvolvimento

enxuto. Seu presidente at 2004 era o Prof. Allen Ward.

156

No mapa apresentado na Figura 6.5, o tempo est representado ao longo do

eixo horizontal e o volume de recursos necessrios para a execuo de cada tarefa
aparece no eixo vertical, no se aplicando, porm, a idia de positivo ou negativo na
utilizao dos recursos. O smbolo com um crculo formado por setas denota uma
tarefa com alto grau de interao. Uma vez que o processo mapeado, os
desperdcios podem ser identificados e removidos com o objetivo de melhorar o
processo. Nos dados da tabela 6.1, esto descritos os principais desperdcios.
Tabela 6.1 Categorizao de desperdcios
Desperdcio

Descrio

Hand-offs

Transferncia de informao:
conhecimento e ao.

Informao sem utilidade

Informao redundante ou desnecessria.

Conhecimento perdido

Lies ou experincias obtidas por meio de procedimentos de

projeto e no transferidas.

Vontade pessoal

Seleo prematura,
excessivos.

experimento

separa

responsabilidade,

inadequado

acordos

Testes para especificao Testes que falham podem ser considerados dispndios.
Espera

Raramente um processo de desenvolvimento de produtos ir

necessitar de atividades seqenciais.

Expertise Ignorado

Desperdcio de oportunidade de melhorias por meio das

pessoas.

Disperso

Reorganizao, reavaliar prioridades, desorganizao.

Ferramentas erradas

Recursos ineficientes ou errados.

Fonte. Adaptado de Ward (2000)

Como possvel observar na Figura 6.5, cada um desses desperdcios pode

ser associado a um smbolo de interao que ser colocado em lugar apropriado no
mapa. Estes smbolos auxiliam na discusso e na comunicao de idia a respeito da
remoo dos desperdcios. Um esforo adicional do mtodo Ward repousa na idia
de associar discusso da melhoria do processo de desenvolvimento de produtos a
discusso do ciclo de negcios. Identificando o timing para o ciclo inovao do
produto ou de desenvolvimento e para o ciclo do cliente, ser mais fcil para a

157

empresa entregar novos produtos quando os clientes desejarem. Esta idia parte do
princpio de que ao cliente dever ser dada a liberdade de puxar do mercado, o que
ele deseja, quando ele assim o desejar, ao invs de forar um produto no desejado.
O cliente, ento, estar com um produto que ele realmente deseja e a empresa ter
seus lucros aumentados enquanto observa a reduo do tempo nos ciclos de
desenvolvimento e a reduo da carga de recursos durante a realizao do produto.
(Millard, 2001).

6.3.3

FLUXOGRAMA
A aplicao de idias enxutas pela da utilizao de ferramentas tradicionais

de mapeamento de processo tambm foi explorada por trabalhos como Trischler

(1996). O objetivo desses desenvolvimentos utilizar o mapeamento de processos
para descobrir pontos de desperdcios e reas com oportunidades de melhorias. Para
tanto, so utilizados smbolos padres, conectados por meio de flechas de forma a
descrever um fluxo. Tambm pode ser utilizado algum tipo de codificao de cores
para indicar as atividades que agregam e no-agregam valor.
Execuo

Reviso

Deciso

Parada

Figura 6.6 Exemplo de simbologia utilizada em fluxogramas.

158

A partir do momento que cada uma das atividades no mapeamento do

processo localizada e codificada em termos de valor, o mapa pode mostrar onde os
desperdcios esto acontecendo. Estes desperdcios podem ocorrer em atividades
como: aprovaes, contagem, amostragem, movimentao, estocagem e inspees.
Discusses sobre como cada uma dessas categorias de desperdcios aplica-se a
operaes que no so de manufatura, podem ser teis na identificao das formas
mais eficientes de remov-las, Slack (1998) e Bauch (2004).

6.3.4

LEARNING TO SEE (APRENDENDO A ENXERGAR)

O mtodo learning to see (LTS) foi desenvolvido inicialmente para a

manufatura e depois adaptado para os processos de desenvolvimento de produtos.

Isto se deveu ao fato de que alguns conceitos enxutos, desperdcios e fluxo foram
correlacionados ao processo de desenvolvimento de produtos (Slack, 1998). LTS
oferece a mais tradicional ferramenta em programas de implantao dos princpios
enxutos.
Segundo Millard (2001), a anlise e mapeamento de materiais fsicos que
fluam no decorrer das operaes de manufatura, no apresentam o mesmo nvel de
dificuldade que a natureza criativa e interativa das operaes de desenvolvimento
que a engenharia impe. A partir disso, o mais importante passo para o Mapeamento
e Anlise do Fluxo do Valor veio com a introduo do mtodo desenvolvido
especificamente para implementao do mtodo LTS (Rother e Shook, 1999). Um
exemplo de um mapa gerado apoiado no uso do mtodo LTS apresentado na figura
6.7

159

PRODUCT DEFINITION
DEFINIO DO PRODUTO

Orders

Suppliers

PRODUCTION
CONTROL

Yearly Buy

MRP/LINE
MOVE

Forecast

Customer

SHOP
ORDERS
Monthly

COMPOSITES
TFO

SUB
ASSY
I

FIFO
LT = 1 Month

FINAL
ASSY &
PAINT

SHIPPING
FIFO

LT = 9 Months

COMPOSITES

FABRICATION
- Tubes
- Wire Harness
- Misc. Details

LT = 4 Months

Figura 6.7 Exemplo de mapa de fluxo do valor Learnig to See

Fonte: Millard (2001).

O princpio fundamental do mtodo LTS repousa no mapeamento do estado

atual de um processo e conseqente aplicao de tcnicas baseadas em princpios
enxutos para criar uma viso desse mesmo processo em um estado futuro. Para criar
este estado futuro, as atividades que no agregam valor ao processo dever ser
eliminadas. Esta uma atividade que visa a permanecer somente com aquelas que
criam valor real ao processo ou as que no proporcionam necessariamente valor, mas
so imprescindveis (ver captulo quatro desta tese). Tcnicas de melhoria so usadas
para regular o tempo de ciclo de cada uma das atividades.
Com o objetivo de oferecer suporte s decises de melhoria de processo,
algumas mtricas so usadas para rever e caracterizar os processos. Os dados da
Tabela 6.2 relacionam ceras mtricas empregadas no contexto da manufatura.
Aps ter sido revisado, o processo deve ser representado graficamente em um
chamado estado futuro. Assim, um plano de implementao colocado em prtica e,
ento, as mudanas so feitas. Este estado futuro melhorado para alcanar o estado
ideal. O mtodo de melhoria contnua pode auxiliar no fluxo do valor do produto.

160

Tabela 6.2 Exemplos de mtricas em manufatura

Mtrica

Descrio

Tempo de ciclo

Tempo necessrio execuo de um processo ou subprocesso.

Tempo de mudana

Tempo necessrio mudana de trabalho de um produto para

outro.

Tempo on-demand

Tempo que empregados e mquinas requerem para passar de

um produto para outro.

Tempo de processo

Tempo que um produto leva para ser transformado, a fim de

agregar valor.

Tamanhos de lotes de
produo

Quantidade de produtos do mesmo tipo produzidos durante um

perodo de produo

Estoque de produtos em
processo

Localiza, na seqncia
acumulando.

Nmero de operadores

Nmero de operadores que lidam com o produto.

Nmero de variaes do
produto

Quantidade de formas pelas quais o produto pode ser

executado.

Tamanho de embalagem

Quantidade de produtos que podem ser despachados em uma

embalagem.

Tempo de trabalho

Tempo que mquinas e empregados tm disponvel para a

produo.

Taxa de refugo

Quantidade de refugo gerado pelo processo produtivo.

produtiva, onde produtos

esto

Fonte: Adaptado de Millard (2001).

A metodologia de Anlise e Mapeamento do Fluxo de Valor utiliza uma

simbologia padro que tem como objetivo facilitar a comunicao entre os diversos
envolvidos.

161

6.3.5

DINMICA DE SISTEMAS
Mesmo que no seja um mtodo de anlise e mapeamento do valor, per se, a

modelagem por meio da dinmica de sistemas pode ser complementar no contexto de

melhorias pelas prticas enxutas. Este mtodo pode ser mais bem entendido apoiado
em Amaral e Sbragio (2003). A Figura 6.8 representa um exemplo do mapeamento
pela dinmica de sistemas e revela o alto grau de relacionamento operacional dirio
em uma empresa.

Lucro

Lucratividade

Lucro

+
+
Instalaes

Produtividade

++

- - -

Mercado

+
Tempo de
Pedido

Fora de
Trabalho

+
+

Participao
Mercado

Tempo de
Entrega

--

+ +

Ajunte de
Tempo
Tempo de
Manuseio

Diferenciao
do Produto

Reduo
Preo

+
Diversidade
Produto

+
+

Publicidade

+
+

+
+
+

Concorrncia
Interna

+
Qualidade
do Produto

Produto

Vendas
Recursos

DM

+ +

Sistema de
Informao

Atividades
de Mercado

Tamanho do
Mercado

Concorrncia
Externa

Concorrncia

Figura 6.8 Exemplo de mapa de dinmica de sistema.

Um sistema dinmico representa uma coleo de mltiplos feedbacks

construdos com o objetivo de descrever o comportamento de um problema
particular. Segundo Bakkila (1996), estes modelos so de grande utilidade, pois,
enquanto a mente humana capaz de analisar e entender a estrutura de um sistema,
no o para interpretar o comportamento desse sistema. Freqentemente, gerentes,
engenheiros e outros tomadores de deciso baseiam-se em modelos mentais, ou na
forma como eles mentalmente compreendem o sistema. Contudo, estes modelos

162

possuem falhas de lgica, e as interaes entre as questes envolvidas no sistema no

so muito claras.

6.3.6

MATRIZ DE ESTRUTURA DE PROJETO (DESIGN STRUCTURE

MATRIX DSM)
A tcnica de Matriz de Estrutura de Projeto (MEP) no somente uma

ferramenta de mapeamento, trata-se de um mtodo bem elaborado para anlise de

seqncias de tarefas em um processo que leva em conta tambm o fluxo de
informaes. Para tanto, constri-se uma matriz quadrada, com quantos elementos
forem necessrios, conforme Figura 6.9. A matriz pode ser numericamente otimizada
para a minimizar as interaes e maximizar o trabalho.
A matriz ter uma lista de todas as atividades ou subsistemas que constituem
o projeto assim como as relaes de dependncia e de troca de informaes. Isto ,
quais as informaes ou parmetros so necessrios para iniciar uma atividade, e
onde a informao gerada por esta atividade ser precisa.
A MEP prov insights para o gerenciamento de um sistema ou projeto
complexo, e tambm destaca questes sobre as informaes e requisitos necessrios,
o sequenciamento de tarefas e s respectivas interaes.
Os pontos indicam a existncia e direo do fluxo da informao (ou, em um
sentido mais amplo as relaes de dependncia) de uma atividade no projeto para
outra. Desta forma, a leitura de uma linha na matriz revela todas as relaes de
dependncia (input) da atividade que esta linha representa com outras atividades do
projeto. Como conseqncia, a leitura das colunas revelar os outputs da atividade
que a coluna representa com as demais atividades. Se considerarmos, por exemplo, a
atividade C na matriz da Figura 6.9, podemos entender que a atividade C receber
informao das atividades A e B e produzir informao para as atividades D, E, F e
G.

163

ATIVIDADES
Receber especificao A

Gerar/selecionar conceito B

Projetar cartuchos beta C

Produzir cartuchos beta D

Desenvolver programa de testes E

C

Testar cartuchos beta F

Projetar molde H

Projetar cartuchos p/ produo G

Projetar ferramenta p/ montagem I

Adquirir equipamento de manufat. J

Fabricar moldes K
Corrigir moldes L
Certificar cartuchos M
Produo inicial N

L
M

Figura 6.9 Exemplo de uma Matriz de Estrutura de Projeto

As atividades marcadas com um ponto escuro (abaixo da diagonal)

representam o fluxo da informao no sentido da execuo do projeto. As marcas
claras (acima da diagonal) so de significante importncia, pois representam um
feedback de uma atividade mais adiantada (a jusante), na ordem de execuo de um
projeto, para uma atividade anterior (a montante). Isto significa que a atividade
anterior dever ser repetida, no sentido de incorporar as novas informaes
provenientes da atividade posterior.

6.4

MECANISMOS DE INTEGRAO
Para que se possa compreender a importncia dos mecanismos de integrao

torna-se necessrio o entendimento da natureza e do processo de gerenciamento das

relaes existentes entre as equipes envolvidas no desenvolvimento de produtos

164

(Browning, 1997a, Browning, 1997b). Desta forma, os problemas de coordenao

que diminuem o desempenho global do processo podem ser evitados baseados uma
abordagem sistemtica que considere mecanismos de integrao a priori no projeto
do processo de desenvolvimento.

6.4.1

INTEGRAO DE TIMES DE DESENVOLVIMENTO

Os mecanismos de integrao so estratgias e ferramentas que auxiliam na

coordenao de um grupo funcional de desenvolvimento. Isto significa facilitar o

fluxo de informaes pelas de barreiras organizacionais, localizacionais, culturais,
etc. (Browning, 1996a; Browning, 1997b). A seguir so listadas algumas categorias
de mecanismos de integrao:

a.

Sistemas de Engenharia projetar a organizao de

forma a espelhar a arquitetura do produto. Uma
arquitetura decomposta e subdividida facilitar a
interface

entre

os

integrantes

da

equipe

de

desenvolvimento;
b.

Tecnologias de Informao e Comunicao sistemas

de CAD/CAM/CAE, e-mail, tele e videoconferncia,
banco

de

dados

comuns

padronizao

de

nomenclaturas so exemplos deste tipo de mecanismo

de integrao;
c.

Treinamento especialmente, para a formao de

equipes, auxilia no aumento da conscientizao do papel
de cada um dos envolvidos e da necessidade de
integrao;

d.

Co-localizao proximidade fsica entre os membros

das equipes;

165

e.

Reunies tradicionais encontros face-to-face para

compartilhamento de informaes e/ou tomada de
decises;

f.

Mediao Gerencial atividades de mediaes que

ocorrem de forma verticalizada (de cima para baixo);

g.

Grupos de Gerenciamento de Interface equipes que

recebem a incumbncia de garantir o andamento do
projeto, ou para mediar incidentes especficos de
interface;

6.4.2

ESTRUTURA DE INTEGRAO
Browning (1997a) prope uma estrutura para a integrao, que se assemelha

muito quela apresentada no captulo cinco, utilizada pela empresa A. Esta

estrutura est baseada em um sistema hierrquico. A hierarquia reflete o fato de que
no s os membros de uma determinada equipe devem estar integrados, mas tambm
as diversas equipes de desenvolvimento devem integram-se. Assim conclui-se que,
pelo menos um nvel a mais deve existir no processo de integrao em
desenvolvimento de produtos. O modelo proposto por Browning (1997a), possui trs
nveis de integrao. A Figura 6.10 ilustra esta estrutura de trs nveis.
o O

Primeiro

Nvel:

chamado

de

Time

Integrado

de

Desenvolvimento (TID) Grupos Funcionais de Suporte (GFS);

o O Segundo Nvel: chamado de time de sistemas; e
o O Terceiro Nvel: chamado de Time de Programa.
Os TIDs e os GFSs (se for o caso) podem ser agregados a um Time de
Sistema, que com outros TIDs e GFSs, ou mesmo com outros Times de sistemas
constituiro um Programa. Na Figura 6.10, as setas significam as mais importantes
necessidades de troca de informao (as relaes de dependncia menos intensas no
esto representadas). Os crculos tracejados destacam os agrupamentos que formam
os times de sistemas.

166

TID

Time de
Sistemas
Nvel 2

TID

TID

Nvel 1

GFS

Time de
Programa
Nvel 3

TID

Nvel 1
TID
Nvel 1

TID
Nvel 1

GFS
Nvel 1

TID
Nvel 1

Figura 6.10 Os trs nveis de integrao

possvel observar que a estrutura dos trs nveis propicia uma quantidade
mnima de sobreposio hierrquica. Programas de desenvolvimento de sistemas
complexos podem requerer nveis adicionais. Por exemplo, possvel que surjam
nveis adicionais de times de sistemas. Segundo Browning (1997a), o programa de
desenvolvimento da aeronave F/A 18E/F expandiu os nveis hierrquicos de
integrao para quatro ou cinco, com o objetivo de capturar distines de prioridades
e dimenses entre os diferentes times de sistemas.
Nota-se tambm que a natureza hierrquica da estrutura proposta prope-se a
refletir a arquitetura do produto, no a estrutura de poder da empresa ou a
organizao do programa mesmo que isto tambm seja relevante.

167

A Figura 6.11 exemplifica a composio de um time de sistema. Esta

estrutura possibilita a integrao de quatro Times Integrados de Desenvolvimento e
dois Grupos Funcionais de Suporte, assim como algumas perspectivas funcionais no
tratadas em nvel de TID. O Time de Sistema composto de representantes dos
diferentes TIDs e GFSs, representantes funcionais adicionais e um ou mais lderes
de Times de Sistemas. Cabe ressaltar que esta estrutura proposta por Browning
(1997a), tambm foi identificada na empresa A.

Lder
TID 1

Lder
TID 2

Lder
TID 1

GFS 1

Repres.
GFS 1

GFS 2

Repres.
GFS 2

Lder
TID 2

Lder do
Time de
Sistema

Lder
TID 3

Repres.
MKT
Repres.
Finan.

Lder
TID 4

Lder
TID 3

Lder
TID 4

Figura 6.11 Exemplo de composio de Time de Sistema

Fonte: Browning (1997a).

Com base nesta estrutura, Browning (1997a) props uma abordagem

sistemtica para o projeto de integrao de programas. Esta abordagem se alicera
em seis passos:

168

1 Conhecer a Arquitetura do Sistema: significa que o projeto dos

mecanismos de integrao de um sistema depender da arquitetura do prprio
sistema;
2 Designar Times Integrados de Desenvolvimento para os Componentes do
Sistema: uma vez que os componentes e subsistemas da arquitetura do produto foram
desdobrados, so designados TIDs para o desenvolvimento de cada componente;
3 Agrupar os TIDs de forma sistemtica: aps a designao dos TIDs e
GFSs que participaro do desenvolvimento dos componentes de nveis inferiores da
arquitetura do sistema, estes devero ser agregados em Times de Sistemas;
4 Aplicar Mecanismos de Integrao: determinados os TIDs e GFSs e
estabelecidas as caractersticas de interface entre os mesmos, devero ser
determinados os mecanismos facilitadores de integrao;
5 Gerenciar interfaces: depois de estabelecer a melhor estrutura
organizacional possvel e escolher, a priori, os mecanismos de integrao
apropriados, o gerenciamento do programa dever manter o fluxo constante de
informao pelo programa. Isto inclui mediar questes tcnicas por meio de
instrumentos apropriados de integrao e monitorar a eficcia da comunicao; e
6 Reavaliao: alguns mecanismos de integrao podem no ser mais
apropriados ao longo do programa. Algumas interfaces podem se tornar mais
importantes outras menos. Novas interfaces podero surgir, outras desaparecero.

169

METODOLOGIA

PARA

IMPLEMENTAO

DOS

PRINCPIOS

ENXUTOS NO PROCESSO DE DESENVOLVIMENTO DE PRODUTOS

O objetivo desta tese desenvolver uma metodologia que possibilite a
implementao de princpios enxutos no processo de desenvolvimento de produtos
que dever auxiliar na melhoria dos resultados do processo de desenvolvimento de
produtos pela implementao desses princpios.
Segundo Ferreira (1993), metodologia significa o estudo dos mtodos e,
especialmente, dos mtodos das cincias. Tate (1999) faz distino entre
metodologia, tcnica e filosofia. De acordo com o autor, a metodologia pode perder
um pouco de preciso quando comparada tcnica, porm como guia de ao supera
a filosofia. Assim a tcnica auxilia seu usurio sobre como fazer algo e a filosofia
indica o que precisa ser feito, a metodologia

contm elementos de ambos os

princpios (como, o que). Portanto, uma forma explcita de estruturar pensamentos e

aes, de forma a revelar quais passos devero ser tomados, como sero realizados e
o porqu de serem realizados em determinada ordem. Uma metodologia pode no
oferecer solues para um problema especfico, mas pode prover um mtodo de
avaliao da possibilidade de sucesso sobre de uma deciso tomada (Tate, 1999).
Nesta tese, a abordagem proposta foi chamada de metodologia, visto que
prov uma forma de estruturar o pensamento ao mesmo tempo em que oferece os
passos para tomadas de decises fundamentadas.

7.1

A CONSTRUO DA METODOLOGIA
O modelo de trs fases discutido no captulo 6 foi elaborado com a finalidade

de representar os passos para a criao de valor na empresa, sua aplicao no

ambiente de desenvolvimento foi testada por Stanke (2001), onde o escopo da
pesquisa focava programas aeroespaciais para caracterizar o ciclo de valor em
sistemas complexos. Desta pesquisa, surgiu a seguinte caracterizao para o ciclo de
valor:

170

Balanceamento entre as expectativas dos stakeholders no que se

refere efetiva performance do sistema (qualidade, custo e prazo) e os riscos
associados em oferecer o melhor valor ao longo de todo o ciclo de
desenvolvimento. (Stanke e Murman 2002).
O modelo de trs fases foi ento definido como:

Identificao
do Valor

Proposio do
Valor

Entrega do
Valor

Figura 7.1 A criao de valor como um processo interativo e adaptativo

Fonte: Murman et. al., 2002.

O objetivo principal desta estrutura, Figura 7.1, fazer com que o processo de
criao de valor torne-se mais visvel. Acompanhando o objetivo desta tese, este
modelo serviu de base para o desenvolvimento da metodologia.
O primeiro passo, porm, foi estabelecer a inter-relao de cada princpio
enxuto com as diferentes fases do modelo. Para tanto, seguiu-se os trabalhos de Slack
(1998), Stanke (2001), Stanke e Murman (2002), Murman et. al. (2002) e Bauch
(2004).

7.1.1

A IDENTIFICAO DO VALOR
Segundo Murman et.al. (2002), esta primeira fase do modelo de trs fases

destinada identificao dos stakeholders e suas necessidades ou requisitos de valor,

o que alguns tericos de negociao chamam de interesses. Slack (1998) relaciona a
identificao dos stakeholders com o primeiro princpio enxuto: valor. Desta forma,
a Figura 7.1 foi alterada de forma a relacionar o princpio do valor com a primeira
fase do modelo: identificao do valor.

171

Identificao
do Valor

Proposio do
Valor

Entrega do
Valor

Valor

Figura 7.2 O modelo de trs fases e o princpio do valor.

Nenhum outro princpio enxuto foi identificado como relacionado fase da

identificao do valor.

7.1.2

A PROPOSIO DO VALOR
Um aspecto-chave para a criao de valor a transio dos objetivos e idias

para uma arquitetura de sistemas e conceitos. Propor um determinado valor para um

sistema envolve o balanceamento das expectativas e contribuies dos stakeholders
com os objetivos do sistema, em uma base comum de criao de um ciclo do valor
Stanke (2001). Nesta fase, portanto, todas as necessidades e expectativas dos
stakeholders so reunidas para uma anlise conjunta. Uma parte da fase de
proposio do valor antecipar a seqncia de aes que resultar em valor. No caso
do processo de desenvolvimento de produtos, necessrio analisar quais etapas do
processo criaram valor. Para Bauch (2004), assim como para Womack e Jones
(2003) existem categorias para os passos do processo baseadas no potencial de
criao de valor. As categorias so:

Aes que criam valor para o cliente;

Aes que no criam valor para o cliente, mas, que, por algum motivo, so
necessrias (Muda Tipo Um); e

Aes que no criam valor para o cliente e, portanto, podem ser eliminadas
(Muda Tipo Dois).

172

Para que estas aes possam ser identificadas, preciso conhecer o fluxo do
valor, segundo princpio enxuto. A Figura 7.3 inclui o princpio do fluxo do valor no
modelo de trs fases.

Identificao
do Valor

Valor

Proposio do
Valor

Entrega do
Valor

Fluxo do
Valor

Figura 7.3 O modelo de trs fases e o princpio do valor e do fluxo do valor.

7.1.3

A ENTREGA DO VALOR
A fase da entrega do valor a mais comum no contexto das prticas enxutas,

assim, o valor proposto dever ser conduzido aos diferentes stakeholders e clientes.
Para isto, necessrio que o fluxo do valor identificado na fase de proposio de
valor esteja desprovido de mudas, para que o princpio do fluxo possa ser
implementado, ou seja, o valor flua por cada etapa do processo de desenvolvimento
do produto. Como j mencionado no captulo 4, o princpio do sistema puxado s faz
sentido no processo de desenvolvimento de produtos, quando o cliente solicita um
novo produto empresa. Quando isto ocorre, na fase de entrega do valor que este
princpio dever ser trabalhado. o caso da Empresa B no captulo 5.
A Figura 7.4 representa o modelo de trs fases com a incluso dos princpios
do fluxo e do sistema puxado.

173

Identificao
do Valor

Valor

Proposio
do Valor

Entrega do
Valor

Fluxo do
Valor

Fluxo

Sistema
Puxado

Figura 7.4 O modelo de trs fases e os princpios: do valor, do fluxo do valor, do

fluxo e do sistema puxado.

Segundo Slack (1998), o princpio da perfeio o estado futuro do processo

de desenvolvimento de produtos, aps a eliminao de todos os mudas. Este trabalho,
no sentido de se alcanar a perfeio, envolve a contnua execuo tanto de
melhorias incrementais (kaizen) como de melhorias radicais (kaikaku) no fluxo do
valor. O princpio da perfeio aquele que ir interagir com os demais princpios ao
longo de todas as trs fases, conforme pode ser observado na Figura 7.5.

Identificao
do Valor

Valor

Proposio do
Valor

Fluxo do
Valor

Entrega do
Valor

Fluxo

Sistema
Puxado

Perfeio

Figura 7.5 O modelo de trs fases e os cinco princpios enxutos.

174

7.1.4

IMPLICAES GERENCIAIS
O entendimento dos riscos associados entrega do produto um elemento

essencial de um planejamento. O gerenciamento e identificao dos riscos so,

freqentemente, considerados um problema. Em todos os projetos, existem
limitaes dos recursos que podem ser usados para evitar problemas potenciais, e
que, portanto, podem nunca vir a ocorrer. Desta forma, torna-se essencial que haja
uma abordagem proativa e planejada de gerenciamento de risco (Murman at. al.,
2002). A figura 7.6 revela que o esforo gerencial deve concentrar-se nas fases
iniciais do ciclo de desenvolvimento e que o conhecimento acumula-se nas fases
finais.

100
80

Custo
do Ciclo
do produto (%)

Comprometimento

60
40

Custo
Incorrido

20
0
Reqts

Manuf.
DP

Operao
Distrib.
Suporte

100

Custos
Acumulados

80

Custo
do Ciclo (%)

60
40

Alavancagem
Gerencial

20
0

Projeto e Produo

Mercado
DP

Figura 7.6 O esforo gerencial nas fases iniciais do ciclo de desenvolvimento do

produto
Fonte: Millard (2001).

175

Segundo Slack (1998), j citado no captulo 4, a busca pela perfeio pode ser
facilitada pelo do desdobramento de polticas, que envolvero a direo e a liderana
da alta administrao no que tange a seleo de objetivos, projetos, recursos e
programaes para a iniciativa de melhorias. Esta necessidade de um envolvimento
da direo ou da alta administrao no gerenciamento e implementao de melhorias
tambm foi verificada nos estudos de casos das prticas industriais. Desta forma,
possvel inferir que existe a necessidade de um modelo de gerenciamento que
possibilite a transposio dos princpios enxutos para o processo de desenvolvimento
de produtos.

Identificao
do Valor

Valor

Proposio do
Valor

Fluxo do
Valor

Entrega do
Valor

Sistema
Puxado

Fluxo

Perfeio

Gap Gerencial

Conceito

Estudo
Preliminar

Projeto
Detalhado

Prototipagem

Ensaios e
Testes

Figura 7.7 Representao da necessidade de uma ferramenta de gesto para

implementao dos princpios enxutos no processo de desenvolvimento de produtos.

Na Figura 7.7, pode-se observar a pertinncia das consideraes de Slack

(1998), de que preciso uma interveno gerencial para que possa ocorrer a
transposio dos princpios enxutos ao o processo do desenvolvimento de produtos.
Isto, porm, deve ser realizado de forma que, ao final, obtenha-se um processo de

176

desenvolvimento com caractersticas enxutas, isto , que utilize princpios enxutos

para melhoria de seu desempenho. As setas tracejadas da Figura 7.7 representam as
possveis contribuies que as prticas industriais correntes podem oferecer ao
modelo de trs fases.
Esta caracterstica de um processo gerencial com incio e trmino alinha-se
com a definio de projeto, o que conduz a identificao da ferramenta de
gerenciamento de projetos, como elemento integrador da metodologia de
implementao dos princpios enxutos no processo de desenvolvimento de produtos.
Os processos de inicio, planejamento, execuo, controle e trmino, considerados
bsicos no ciclo de vida de projetos (PMI, 2001), so tambm os processos-base
desta metodologia.
A pesquisa com os estudos de caso revelou um desconhecimento da Empresa
B sobre os princpios enxutos aplicados ao processo de desenvolvimento de
produtos. Por isso, a metodologia incluiu no modelo de trs fases uma fase de
preparao, na qual se objetivou a construo de uma viso enxuta para os
envolvidos, o envolvimento das pessoas e o desenvolvimento de estratgias de
implementao. A proposta da metodologia est exemplificada na Figura 7.8.
A metodologia proposta foi desenvolvida, portanto, com a seguinte estrutura
bsica: quatro fases (preparao, identificao de valor, proposio de valor e entrega
de valor); quatro processos (incio, planejamento, execuo e controle e melhoria).
Cada processo foi dividido em subprocessos, estas subdivises foram construdas
baseadas nos dados obtidos durante os estudos de caso.

177

7.1.5

MAPEAMENTO DAS FASES DE CRIAO DE VALOR EM RELA-O

AOS PROCESSOS DE GERENCIAMENTO DE PROJETOS
O processo de desenvolvimento de produtos (PDP), como j ressaltado

anteriormente, muito difcil de ser modelado. Isto porque diferentes produtos

necessitam de distintos processos, sejam de manufatura, sejam de engenharia. Mas, o
propsito desta tese desenvolver uma metodologia que possa ser generalizada aos
variados PDPs. Pretende-se alcanar este objetivo por meio de elementos
transversais, comuns aos diferentes tipos de PDP.
Tabela 7.1 Matriz cruzada entre os processos gerenciais de projetos e as fases do
modelo de referncia.

Processos de
Gerenciamento de
Projetos.

Iniciao

Planejamento

Execuo

Controle
Encerramento

Fases para criao de valor em desenvolvimento de produtos, adaptados

de Murman et.al. (2003)
Fase 0
Fase 1
Fase 2
Fase 3
Preparao
Identificao do
Proposio do
Entrega do Valor
(Implementao do
valor
Valor

(dedicada
preparao bsica
para a criao de
valor)

(dedicada
identificao das
necessidades dos
stakeholders)

(balanceamento das
necessidades dos diversos interessados
identificado na fase 1)

fluxo de valor identificado na fase 2)

Construir a viso
enxuta,
Estabelecer
necessidades
Envolver as
pessoas.
Integrar o PDP
estratgia da
empresa.
Definir escopo de
implementao,
Treinar equipes.
Estabelecer
objetivos e mtricas
Definir stakeholders,
Definir formas para a
identificao do valor.
Definir valor em
termos de: qualidade,
custo e prazo.

Mapear fluxo do valor

Realizar o PDP com
atual no PDP,
foco na criao de
Rever o PDP com base valor,
Eliminar desperdcios
na criao de um
estado futuro para o
por meio de um
fluxo do valor.
programa de
Definir mecanismos de melhoria contnua.
integrao.
O projeto de controle e melhoria acontecer em todos os processos.
O processo de encerramento acontecer quando o PDP, definido pela empresa, alcanar um
estado considerado enxuto, ou seja, quando as fases para a criao de valor forem
sistematicamente incorporadas ao processo formal de desenvolvimento de produtos.

Fonte: Elaborada pelo autor.

178

Processo de
Iniciao

IM1 Construir a viso enxuta

IM2 Estabelecer necessidades.
IM3 Envolver as pessoas
IM4 Vender a idia alta-administrao.

Processo de Planejamento

Comprometimento da Altaadministrao

Passo 2 Incio
PP1 Integrar o PDP estratgia da Empresa
PP2 Estabelecer equipes de implementao.
PP3 Desenvolver estratgia de implementao.
PP4 Definir escopo de implementao.
PP5 Treinar pessoal-chave
PP6 Estabelecer objetivos e metas (mtricas)
PP7 Definir recursos
PP8 Definir cronograma de implementao
Plano de implementao
Incluindo o WBS

Passo 3 Definio de Valor

Fase de
Identificao
do Valor

Fase de Preparao

Passo 1 Adoo da Mentalidade Enxuta

PV1 Definir stakeholders.

PV2 Definir mtodos para identificao de valor,
especficos para cada projeto.
PV3 Definir valor em termos de Qualidade, custo e Prazo.

Fase de Entrega do Valor

PF1 Mapear o fluxo do valor

PF2 Representar o fluxo da informao.
PF3 Coletar e analisar dados.

Processo de Execuo

Fase de Proposio do Valor

Passo 4 Identificar o Fluxo do Valor

Processo de Controle e
Melhoria

Esforo para a
Perfeio
Passo 5 Definir o PDP
PD1 Adequar o PDP para um fluxo de valor futuro.
PD2 Definir novo layout.
PD3 Definir mecanismos de integrao.
PD4 Estimar e justificar custos.

CP1 Avaliar o processo

de acordo com os
objetivos e mtricas
CP2 Avaliar o
progresso utilizando
matrizes de maturidade
no conceito enxuto
CP3 Institucionalizar
eventos de Kaizen
CP4 Avaliar equipes de
desenvolvimento

Passo 6 Implementar o Fluxo

EI1 Detalhar atribuies em cada fase do processo.
EI2 Implementar os mecanismos de integrao
EI3 Eliminar desperdcios.

Passo 7 Implementar o Sistema Puxado

ES1 Estabelecer mecanismos que impeam que a
informao seja empurrada (over the wall)
ES2 Estabelecer um sistema de anlise de programao
para cada projeto.

Figura 7.8 Estrutura da metodologia proposta.

Processo de
Encerramento da
Implementao dos
Princpios Enxutos no
PDP

179

7.2

DETALHAMENTO DA METODOLOGIA
Neste captulo da tese, so detalhados os passos da metodologia proposta. O

objetivo principal foi, sobretudo, oferecer uma breve descrio sobre dos tpicos
elencados no corpo da Figura 7.8. Neste sentido, este detalhamento no poder ser
confundido com um manual tcnico prescritivo, mas sim como uma seqncia de
passos que podero ser utilizados em sua totalidade, parcialmente ou at mesmo
ampliados, cujo principal objetivo conduzir o processo de desenvolvimento de
produtos a um estado considerado enxuto. De uma forma geral, cada um dos sete
passos foi subdividido em atividades que sero, para efeito de padronizao,
chamadas de etapas.

7.2.1

PASSO 1
Na fase de preparao, incia-se a metodologia. nesta fase que se procurar

transmitir a todos os participantes do processo de desenvolvimento de produtos quais

os princpios que norteiam a mentalidade enxuta. Esta fase engloba o primeiro passo
da metodologia: adoo da mentalidade enxuta. Para que este primeiro passo esteja
completo torna-se necessria a realizao de quatro etapas.
Estas foram obtidas baseadas na anlise cruzada dos casos e encontram-se
descritas no Quadro 7.1.

IM1 Construir a viso enxuta.

IM2 Estabelecer necessidades.
IM3 Vender a idia alta-administrao.
IM4 Envolver as pessoas.

Quadro 7.1 Etapas do primeiro passo.

180

IM1 Construir a viso enxuta

Pelos estudos de caso e pela literatura, ficou evidenciado que antes da
implantao de um sistema enxuto, na manufatura ou na engenharia, preciso uma
conscientizao dos envolvidos com o processo sobre os princpios e prticas
enxutas. Os estudos de caso revelaram que os envolvidos com o processo de
desenvolvimento de produtos pouco ou nada sabiam sobre a implementao dos
princpios enxutos em ambiente que no os de manufatura. Na literatura, segundo
Morgan (2002), Slack (1998), Millard (2002), Womack (2003), a construo de uma
mentalidade enxuta deve ser o primeiro passo para as empresas que desejam
implementar um processo enxuto, seja na manufatura ou na engenharia.
Este passo da metodologia mostra-se recorrente tambm em outros
empreendimentos como, por exemplo, na implantao de sistemas da qualidade,
onde a construo de um entendimento sobre os princpios da qualidade constitui o
primeiro passo para o sucesso do programa de qualidade. Na verdade, segundo
Womack e Jones (2003), uma boa idia iniciar o processo de implementao de
uma filosofia enxuta, combinando os esforos de garantia da qualidade com os
esforos de promoo dos conceitos enxutos, de forma que a melhoria da qualidade e
da produtividade, reduo de tempo de ciclo, economias de espao ou qualquer outra
dimenso de desempenho sejam consideradas igualmente e simultaneamente.
Ainda segundo Womack e Jones (2003), um dos problemas principais quando
do incio da implementao da mentalidade enxuta que os gerentes envolvidos
entendem que os especialistas em sistema de qualidade e os especialistas em tcnicas
enxutas esto solicitando que se executem atividades completamente distintas. Isto
ficou evidente nos casos investigados, quando os entrevistados alegavam que, por
possurem a certificao em sistemas da qualidade, talvez no fosse conveniente
mais um sistema.
Estas evidncias reforam a necessidade de uma etapa no processo, onde as
pessoas-chave participantes sejam esclarecidas dos princpios e conceitos bsicos da
mentalidade enxuta.

181

Para o grupo The Enterprise Transition to Lean TTL, a mentalidade enxuta

requer um profundo entendimento dos aspectos fundamentais de uma empresa e suas
interaes com seu ambiente externo.

IM2 Estabelecer necessidades

A teoria tem revelado que poucas empresas esto propensas a realizar
mudanas radicais necessrias, que as mesmas s so verificadas quando as empresas
esto desejosas de um desafio maior ou quando as mudanas representam sua prpria
sobrevivncia. De certa forma, isto apresenta uma incoerncia, pois seria mais
prudente uma mudana quando a empresa desfruta de uma sade financeira estvel.
Nas empresas analisadas tambm, foi identificado certo receio com relao adoo
de uma nova mentalidade no processo de desenvolvimento de produtos. Na empresa
A por exemplo, existe a busca constante de melhoria de processos, porm os
responsveis acreditam que a proposta de implementao de princpios enxutos no
processo de desenvolvimento de produtos assemelha-se muito s mudanas j
realizadas e, portanto, apenas algumas poucas mudanas poderiam contribuir para a
melhoria do processo. No caso da empresa B, existe uma srie de pressupostos que
fazem parte da cultura organizacional, os quais tornam os envolvidos resistentes
mudana. Na empresa C, as mudanas esto ainda em um estgio embrionrio e tm
sido planejadas por iniciativa isolada de um gerente. A proposta para estabelecer a
necessidade de mudana deve partir sobretudo da anlise comparativa entre as
distintas abordagens de melhoria, destacando sobretudo o futuro competitivo da
empresa.

IM3 Vender a idia alta-administrao

Para que estas necessidades sejam estabelecidas de forma criteriosa, e para
que os recursos estejam disponveis no momento oportuno fundamental que a altaadministrao compre a idia. Este comprometimento no se refere somente ao
aspecto financeiro. Segundo Hoppes (1995) mais importante para um gerente de
processo de mudana mostrar de forma consistente que ele est atrs dos resultados

182

do projeto e que est disposto a cumprir todas as etapas necessrias para o alcance
bem-sucedido dos resultados.
O comprometimento da alta-administrao evita que a implementao de
programas de melhorias transforme-se em apenas um conjunto de papis, ou mesmo,
em mais um programa que logo desaparecer. Este comprometimento sinaliza para a
fora de trabalho que o esforo que est sendo empreendido importante e, de certa
forma, representa o futuro da organizao da qual esta fora faz parte.

IM4 Envolver as pessoas

Existe uma barreira nos programas de mudana que se relaciona com as
crenas, usos e costumes que a fora de trabalho, em geral, tem no que se refere
forma pela qual as atividades so executadas. Isto foi observado inclusive nos casos
pesquisados, onde a proposta de uma nova forma de gesto do processo de
desenvolvimento do produto era recebida com resistncia pelos entrevistados.
Alguns pontos de resistncia esto relacionados com os seguintes tpicos:


Muitos dos participantes do processo de desenvolvimento

sentem-se ameaados quando da hiptese de mudana para um
modelo de gesto diferente daquele ao qual j estavam
habituados,

que

so,

normalmente,

altamente

departamentalizados e com escopo limitado;



A abordagem enxuta, por natureza, exige redues radicais e

contnuas dos ndices de trabalho realizado. Desta forma, os
empregados so solicitados a buscar meios contnuos de
reduo dos ndices de seu prprio trabalho;

Pode haver uma ameaa ao emprego;

As demandas por melhoria de desempenho podem assustar;

Envolver as pessoas significa fazer com que os novos princpios no se

tornem motivos de impedimento para a mudana de gesto do processo. Torna-se
necessrio, portanto, que as pessoas que integram as diversas atividades do processo

183

de desenvolvimento de produto enxerguem as mudanas como oportunidades de

melhoria. Isso s acontecer baseado no envolvimento de cada uma dessas pessoas
com o processo de mudana.

Output
O principal output deste passo o comprometimento da alta-administrao.

7.2.2

PASSO 2
Este segundo passo representa o incio, propriamente dito, da metodologia.

Durante este passo, definida a estratgia, e a estrutura de suporte colocada

disposio. aqui tambm que comea a se desenvolver o grupo multifuncional que
cuidar do processo de transformao. Este grupo dever possuir autoridade e
responsabilidade para esta transformao. O treinamento das pessoas-chave para o
processo tambm acontecer neste momento. As mtricas que sero utilizadas para
avaliar o progresso da implementao sero estabelecidas e acompanhadas. Em
linhas gerais, neste passo que os recursos bsicos necessrios ao processo de
transformao so definidos.
As etapas deste segundo passo encontram-se resumidas no Quadro 7.2.
PP1 Integrar o PDP estratgia da Empresa
PP2 Estabelecer equipes de implementao
PP3 Desenvolver estratgia de implementao
PP4 Definir escopo de implementao
PP5 Treinar pessoal-chave
PP6 Estabelecer objetivos e metas (mtricas)
PP7 Definir estrutura de suporte

Quadro 7.2 Etapas do segundo passo.

184

PP1 Integrar o PDP estratgia da empresa

Conduzir a transio do processo de desenvolvimento para um estado enxuto
torna-se mais complexo sem o respectivo alinhamento com a estratgia da empresa.
Isto ficou evidente na literatura, quando Slack (1998) dissertou sobre o valor para os
acionistas e na reviso das prticas industriais, quando das entrevistas com os
envolvidos. Mas, com exceo da empresa A, as empresas investigadas no
demonstraram nenhum procedimento para que isto ocorra. necessrio, portanto,
que as empresas ao desenvolverem seus produtos entendam as necessidades e
objetivos internos da empresa, sobretudo os de nvel estratgico. A partir da
integrem as atividades de identificao das necessidades dos clientes e fornecedores.
A viso integrada dos anseios dos diversos stakeholders o ponto de partida para
uma eficiente identificao de valor.

PP2 Estabelecer equipes de implementao

A equipe dever contemplar integrantes das diversas reas envolvidas no
processo de desenvolvimento de produtos, assim como integrantes de outras reas
que fazem contato com o PDP, tais como: fabricao ou manufatura, recursos
humanos, tecnologia de informao e gerncia de negcios. Basicamente, as
atividades deste grupo estaro voltadas para: elaborar um plano de execuo, prover
recursos, identificar e remover barreiras a implementao, monitorar e garantir que a
implementao no est afetando negativamente o desempenho atual e prover o
treinamento sobre os princpios e conceitos enxutos.

PP3 Desenvolver estratgia de implementao

Segundo a equipe TTL (Transition to Lean), do MIT, a estratgia de
implementao de princpios enxutos na manufatura deve determinar onde ser
concentrado o esforo que maximizar os objetivos globais que compem o

185

planejamento estratgico da empresa. No PDP, aps a identificao e balanceamento

das necessidades dos diferentes stakeholders (incluindo os objetivos de longo prazo
dos acionistas), a estratgia de implementao dever centralizar a seguinte questo:
Onde a equipe dever utilizar seu tempo?. Para tanto importante a identificao
das oportunidades de melhoria. Pautado no formulrio de pesquisa utilizado nesta
tese para a investigao sobre o processo de desenvolvimento de produtos, ficaram
evidentes vrios pontos de melhoria estabelecidos em funo do que preconiza a
literatura e baseado nas necessidades dos clientes. A premissa estabelecida pelo TTL
que uma implementao estrategicamente focada pode proporcionar benefcios
imediatos e duradouros empresa.

PP4 Definir escopo de implementao

Algumas empresas no tm bem definidos os limites do processo de
desenvolvimento do produto. A Empresa B, investigada no captulo desta tese que
trata das prticas industriais, um exemplo da falta de delimitao das atividades de
desenvolvimento de produtos, pois incorpora em seu fluxograma as atividades
administrativas gerais da empresa. Esta viso equivocada do processo pode levar a
perda de foco, o que prejudicaria o desenvolvimento da estratgia de implementao
(PP3). Desta forma, a definio de um escopo de implementao confunde-se com o
escopo do prprio PDP e seus respectivos pontos de contato com outras reas. Como
o escopo de implementao est diretamente relacionado ao PDP, a reviso do PDP,
previsto no PD1, dever causar algum tipo de realimentao ou interao no escopo
de implementao que dever ser revisto em funo das alteraes ocorridas no PDP.

PP5 Treinar pessoal-chave

O objetivo principal deste treinamento obter o correto entendimento dos
princpios enxutos e transmisso para os envolvidos de qual seu papel no processo de
implementao. Neste treinamento, tambm sero discutidas as ferramentas que
sero utilizadas na conduo do PDP a um estado enxuto. Algumas destas
ferramentas foram discutidas no captulo 6 desta tese. A empresa dever, em funo

186

do seu tamanho, definir grupos de treinamento e estabelecer o grau de profundidade

dos assuntos tratados nos treinamentos.

PP6 Estabelecer objetivos e metas (mtricas)

Alguns objetivos precisaro ser estabelecidos, de forma que cada um dos
envolvidos possa ao mesmo tempo identific-los e contribuir para que os mesmos
sejam alcanados. Isto poder ser feito baseado nas mtricas, tais como: reduo do
tempo de desenvolvimento, melhoria da qualidade do produto final e reduo do
custo de desenvolvimento. Estas mtricas foram estabelecidas em funo do trabalho
de Slack (1998), detalhado no captulo 4, e baseadas nas prticas industriais
investigadas que ratificaram estas mtricas como as mais importantes para o PDP.

PP7 Definir estrutura de suporte

Seu sensei34 necessitar de um lugar para sentar, mesmo que um bom
sensei no permanea sentado por muito tempo, com esta frase Womack e Jones
(2003) reforam a idia de estabelecer necessidades. A equipe que cuidar do
processo de implementao da mentalidade enxuta necessitar de suporte logstico
para execuo de suas tarefas. Esta necessidade est relacionada com recursos
materiais, humanos e tecnolgicos. Em uma das empresas pesquisadas (empresa B),
ficou evidenciado que o custo envolvido em mudanas pode representar um grande
empecilho para a implementao de qualquer programa de melhoria. Sobretudo, pelo
fato na demora das aquisies. Segundo Csillag (1995), os recursos necessrios
devem estar disponveis em tempo, pois, caso contrrio, no adiantar insistir no
processo.
As necessidades no so, porm, apenas materiais, sero precisos tambm,
por exemplo: agentes de gerenciamento de mudana, empregados treinados e
ferramentas de modelagem e simulao. Se a empresa no facilitar a obteno dos

34

Palavra que significa: professor pessoal com domnio sobre alguma rea do conhecimento. Neste
caso algum com domnio sobre as tcnicas e conceitos enxutos.

187

recursos para a mudana, o trabalho dificilmente alcanar os objetivos desejados

(Hoppes, 1995).

PP7 Definir Cronograma de implementao

Dever ser estabelecido um cronograma, especificando os prazos para o
cumprimento de cada etapa do processo de implementao da metodologia. Este
cronograma ser acompanhado e a possibilidade do no cumprimento de algum
prazo estabelecido dever ser tratada como uma oportunidade de melhoria,
desencadeando, desta forma, aes no sentido de verificar os motivos do no
cumprimento ou talvez a reviso do prazo previamente estabelecido.

Output
O output deste segundo passo ser um plano de implementao que poder
incluir um WBS (Work Brakedown Structure). O objetivo deste plano de
implementao materializar por meio de um documento formal os objetivos e
mtricas que sero alcanados durante o processo de implementao dos princpios
enxutos no processo de desenvolvimento de produtos.

7.2.3

PASSO 3
Neste terceiro passo, so consideradas as questes relativas identificao do

valor. A fase de identificao do valor exige a definio dos principais interessados

(stakeholders). Como j discutido no captulo 4 e investigado no captulo 5, a
definio dos stakeholders o principal elemento para a criao de valor, portanto, o
terceiro passo parte desta etapa. O PDP pode ser genrico e definido em fases que se
aplicaro com facilidade a empresas de diferentes indstrias (Cooper, 1983).
Entretanto, cada produto tem seu detalhamento e necessitar de tratamento
diferenciado em funo de suas particularidades. Torna-se necessrio, assim, que a
identificao de valor em termos de qualidade, prazo e custos seja adequada a cada
produto.

188

PV1 Definir stakeholders.

PV2 Definir mtodos para identificao de valor,
especficos para cada projeto.
PV3 Definir valor em termos de Qualidade, Custo e Prazo.
Quadro 7.3 Etapas do terceiro passo.

PV1 Definir stakeholders

Os stakeholders possuem, por vezes, interesses conflitantes no que tange ao
PDP. No caso da Xerox, descrito no captulo 2, podemos verificar que a busca pela
reduo do tempo de desenvolvimento, necessidade de mercado identificada pela
empresa, gerou um aumento de custos que incomodou os acionistas. Na avaliao da
empresa B, tratada no captulo 5, verificou-se que um stakeholder importante para o
desenvolvimento de produtos, o fornecedor do servio de fabricao participava
discretamente do processo, o que gera interaes tardias e desnecessrias ao
processo. A correta identificao dos interessados propiciar tambm um correto
balanceamento de suas necessidades, ento traduzidas em um pacote de valor que
atender s expectativas de todos.

PV2 Definir mtodos para identificao de valor, especficos para cada projeto.
Uma caracterstica particular para o processo de desenvolvimento enxuto
que, diferente da manufatura em srie, o processo de desenvolvimento de produtos ,
freqentemente, nico. Mesmo que, como j explanado, seja possvel definir um
modelo de processo de desenvolvimento de produtos com passos que sejam comuns
a diferentes projetos, invariavelmente os projetos tero particularidades que exigiro
anlises diferenciadas do que se entende por valor em cada um dos diferentes
projetos.
Desse modo, temos duas situaes distintas nesta etapa, quais sejam: definir o
valor para o processo de desenvolvimento de produtos, este ser comum a todos os
projetos e definir valor para cada um dos projetos em desenvolvimento. Esta

189

necessidade ficou evidente durante a investigao das prticas industriais na empresa

B. Nas entrevistas e observao dos processos, verificou-se a existncia de mais de
100 projetos sendo desenvolvidos simultaneamente. No seria produtivo fazer uma
anlise do que representa valor aos diferentes stakeholders interessados em cada um
desses projetos, ao mesmo tempo que alguns mecanismos e ferramentas de anlise de
valor para os produtos podem ser elaborados de forma transversal a todos os
projetos35.
Esta dificuldade, porm, no excluir a necessidade de podermos observar
determinados projetos com mais ateno no sentido de identificar as exigncias
especiais dos interessados. O caso da empresa M, narrado no captulo 2, retrata
bem esta situao e as possveis conseqncias da no observao desta etapa.

PV3 Definir valor em termos de Qualidade, Custo e Prazo

O valor dever ser definido em termos de qualidade, custo e prazo, pois
devero atender as expectativas dos diferentes interessados. Cada um dos projetos de
desenvolvimento tem caractersticas que so particulares e, portanto, necessitam de
avaliaes especficas em termos de qualidade, custo e prazo. O captulo 4 desta tese
aborda esta questo baseado nas pesquisas realizadas por Bauch (2004) e Slack
(1998). As empresas analisadas procuram estabelecer estas definies, porm, no se
constatou nenhuma similaridade de aes entre os procedimentos adotados pelas
empresas. Isto, contudo, pareceu coerente em funo da grande diferena entre os
produtos desenvolvidos pelas empresas analisadas.

Output
Uma lista com a definio dos stakeholders e suas principais perspectivas
quanto ao valor no PDP, possibilitar a correta distino entre as atividades que
criam valor e as que no criam valor.

35

Maiores detalhes sobre anlise de valor consultar Csillag (1998).

190

7.2.4

PASSO 4
O quarto passo da metodologia tambm o primeiro passo da fase de

proposio do valor. Nesta fase, aps definidas as necessidades bsicas para a

transio, so realizadas auditorias de posio com o intuito de verificar qual o
estado atual do processo de desenvolvimento de produtos. Esta verificao feita
fundamentada no fluxo de informaes que, como j definido anteriormente, a
principal matria-prima para o desenvolvimento de novos produtos. Uma parte da
fase de proposio do valor antecipar a seqncia de aes que resultaro em valor.
No caso do processo de desenvolvimento de produtos, preciso analisar quais etapas
do processo criaram valor

PF1 Mapear o fluxo do valor

PF2 Representar o fluxo da informao.
PF3 Coletar e analisar dados.

Quadro 7.4 Etapas do quarto passo.

PF1 Mapear o fluxo do valor

Com o objetivo de fazer com que o valor identificado flua do incio ao final
do processo de forma contnua, necessrio que, antes da proposta definitiva do que
ser considerado valor para o desenvolvimento, se reconhea o estado atual do
processo, identificando cada um dos passos pelos quais o valor dever fluir. Esta
abordagem poder parecer subjetiva, pois diferentemente da manufatura, no existe
no processo de desenvolvimento de produtos a tangibilidade dos materiais que fluem
nas operaes. Assim, como j explorado no captulo quatro, a informao
principal matria-prima do processo de desenvolvimento de produtos dever ser
acompanhada, melhorada e conduzida por meio de cada etapa do processo.

191

PF2 Representar o fluxo da informao

Aps a investigao das etapas do fluxo do valor, ser necessrio representar
o fluxo. As diferentes ferramentas utilizadas para o mapeamento de fluxo esto
descritas no captulo seis. A partir desta representao ser possvel eliminar as
atividades que no criam valor, as que no criam valor mas so necessrias e as que
efetivamente criam valor. Nas pesquisas dos captulos quatro e seis, no se
identificou nenhuma melhoria prtica no que tange ao mapeamento do fluxo de
valor. Portanto, ser preciso que cada organizao envolvida no desenvolvimento
escolha, dentre as diversas ferramentas de mapeamento do fluxo, aquela que melhor
representar o seu fluxo em particular.

PF3 Coletar e analisar dados

O desempenho do processo em seu estado atual estabelecer uma referncia
para avaliar o progresso que esteja acontecendo e para desenvolver atividades de
melhorias. Desta forma, os dados de custos, tempo de desenvolvimento, qualidade e
programao devero ser documentados.

Output
Um mapa com o fluxo do processo de desenvolvimento de produtos, cujos
fluxos de informao com a possibilidade de medies, sobre o tempo gasto com
cada uma das atividades, podero ser identificados.

7.2.5

PASSO 5
O quinto passo ainda se relaciona com a proposio do valor. Nesta fase, o

processo de desenvolvimento em uso ser revisado, para harmonizar as expectativas

dos diversos stakeholders com o caminho pelo qual estas expectativas devero fluir.
Para tanto, neste passo, sero considerados aspectos relacionados com as etapas do
fluxo de informaes, arranjo fsico, mecanismos de integrao e definio de custos.

192

PD1 Adequar o PDP para um fluxo de valor futuro.

PD2 Definir novo layout.
PD3 Definir mecanismos de integrao.
PD4 Estimar e justificar custos.

Quadro 7.5 Etapas do quinto passo.

PD1 Adequar o PDP para um fluxo de valor futuro

Aps a realizao do mapeamento do fluxo atual, sero identificadas diversas
atividades que devero ser excludas do processo por no criarem valor, assim como
sero propostas outras atividades que no existiam no processo anterior, mas que
foram includas para facilitar o fluxo da informao. AS atividades de excluso e
incluso de atividades no processo iro adequ-lo para uma nova proposta de fluxo.
Estas alteraes podem ocorrer de forma discreta, quando o processo de
desenvolvimento j estiver com alto grau de alinhamento com o fluxo de valor ou de
forma radical quando no apresentar caractersticas de um processo orientado para o
fluxo do valor. As ferramentas mencionadas no captulo seis, para mapeamento e
anlise do fluxo do valor, so exemplos de instrumentos que podem ser empregados
na adequao do PDP para um fluxo de valor futuro.

PD2 Definir novo layout

As mudanas de layout comprovadamente, tm efeito benfico na manufatura
enxuta. Segundo Womack e Jones (2004), o arranjo fsico representa um importante
mecanismo de adequao de uma linha de produo ao estado futuro com o objetivo
de eliminar desperdcios (muda)36. Mesmo que, no ambiente de desenvolvimento de
produtos, este benefcio no seja to evidente, um determinado grau de interveno

193

dever ocorrer. Se, por exemplo, o processo possuir um grande nmero de atividades
sendo realizadas simultaneamente e, por conseqncia, utilize grupos co-localizados
de trabalho, um novo layout dever ser definido. Na empresa B analisada no
captulo cinco, verificou-se que mesmo usando um processo do tipo stage gates,
houve uma alterao do arranjo fsico dos diversos setores, no sentido de adequar-se
nova viso por processos estabelecidos com base no Sistema de Gesto da
Qualidade SGQ, recm-implantado.

PD3 Definir mecanismos de integrao

Os mecanismos de integrao relacionam-se, sobretudo, com as formas pelas
quais as informaes sero compartilhadas, transmitidas e recebidas entre os
integrantes do processo de desenvolvimento de produtos. No captulo seis, foi
realizada uma breve descrio dos principais mecanismos de integrao. No captulo
cinco, que trata da reviso das prticas industriais, so destacados os principais
mecanismos utilizados pelas empresas avaliadas.

PD4 Estimar e justificar custos

O novo fluxo do valor (estado futuro) e o conseqente novo processo de
desenvolvimento de produtos, provavelmente necessitaro de investimentos, que
devero ser estimados e justificados. Contudo, as economias advindas com a
emprego dos princpios enxutos podem no ser to evidentes, o que prejudicaria as
atividades de implementao. Portanto, a etapa de convencimento da altaadministrao, sugerida no primeiro passo desta metodologia, ser til neste
momento. Assim, a avaliao do nvel de eficincia ser mais significante se for
orientada para os resultados de melhorias e efeitos sobre o sistema.

36

Ver captulo 4.

194

Output
O principal output deste passo o mapa do estado futuro, que servir para
uma constante avaliao e reviso das melhorias implementadas. O processo de
mapeamento e anlise do fluxo do valor deve ser dinmico.

7.2.6

PASSO 6
A implementao do fluxo do valor corresponde ao primeiro passo da fase da

entrega do valor. Nesta fase, o valor identificado e proposto ser conduzido at a

jusante do processo. Para tanto, sero necessrias definies sobre das atribuies de
cada passo do novo processo de desenvolvimento de produtos, assim como a
implementao dos mecanismos de integrao j definidos e a constante eliminao
de desperdcios. Portanto, as etapas desse passo foram definidas como:
EI1 Detalhar atribuies em cada passo do processo.
EI2 Implementar os mecanismos de integrao.
EI3 Eliminar desperdcios.
Quadro 7.6 Etapas do sexto passo.

EI1 Detalhar atribuies em cada passo do processo

Cada passo do desenvolvimento de produto foi detalhado, preferencialmente,
em forma de processo. Foram considerados os inputs, atividades de processamento e
outputs. Durante a reviso das prticas industriais, verificou-se que as empresas
avaliadas, em alguma medida, utilizavam abordagens baseadas em processos para o
gerenciamento do fluxo de informaes ao longo do desenvolvimento de produtos.

195

EI2 Implementar os mecanismos de integrao

O paradigma do desenvolvimento integrado de produtos tem sido reconhecido
como a abordagem preferencial ao desenvolvimento de produtos. Em programas de
desenvolvimento de sistemas complexos, o aspecto da engenharia simultnea
relacionado com o desenvolvimento integrado de produtos , normalmente, tratado
por meio de times integrados de desenvolvimento. Tais times so incumbidos de
desenvolver vrios componentes de um sistema. Segundo Browning (1997a), os
grandes desafios que se referem aos mecanismos de integrao, esto no
gerenciamento e coordenao destas ferramentas.
Uma reviso sobre os mecanismos de integrao foi apresentada no captulo
seis. Nas empresas analisadas, pode-se observar que mecanismos avanados de
integrao esto presentes no processo de desenvolvimento de produtos da empresa
A. Times integrados de desenvolvimento, ferramentas de CAD/CAM/CAE, colocalizao e encontros face-to-face, que so exemplos de alguns mecanismos
identificados na empresa A.

EI3 Eliminar desperdcios

A eliminao de desperdcios est relacionada diretamente com os princpios
enxutos e mais precisamente com o fluxo do valor. Estudos detalhados sobre os
desperdcios em ambientes de desenvolvimento foram apresentados no captulo
quatro, sendo os principais trabalhos: Slack (1998) e Bauch (2004).
Quando da avaliao das prticas industriais, um representante da empresa
B, principal responsvel pela implantao do desenvolvimento integrado de
produtos DIP, alegou que no havia desperdcio de tempo ocioso em engenharia,
pois quando vemos um engenheiro parado, na verdade, ele est elaborando
construes mentais de criao. A despeito do grau de veracidade embutida nesta
afirmao, ficou constatado durante as investigaes que os desperdcios associados
ao fluxo de informao vo alm do muda de tempo de espera. Existem outros
fatores que restringem o fluxo da informao e, por conseguinte, no criam valor ao

196

processo de desenvolvimento de produtos. Estes fatores so considerados

desperdcios (mudas) e devero ser eliminados. Mais precisamente no trabalho de
Bauch (2004), apresentada uma metodologia especfica para a eliminao de
desperdcios no fluxo da informao no contexto de desenvolvimento de produtos.

Output
As reas envolvidas devero implementar as iniciativas de melhorias com o
objetivo de se obter o fluxo desejado. Basicamente, os setores devero eliminar as
atividades consideradas desperdcios.

7.2.7

PASSO 7
Como j mencionado no captulo quatro, durante o levantamento terico, o

princpio do sistema puxado no mostrou muita aplicao no contexto de

desenvolvimento de produtos. Mas, nas revises das prticas industriais, verificou-se
um caso de desenvolvimento de produtos sob o enfoque do sistema puxado. A
empresa B, durante a avaliao, possua, aproximadamente, 150 projetos de
desenvolvimento em andamento, e cerca de 90% deles havia sido puxado pelos
clientes. Desta forma, alguns pontos foram identificados como oportunidades de
melhoria ao processo, que so, resumidamente, citados a seguir:

ES1 Estabelecer mecanismos que impeam que a

informao seja empurrada (over the wall)
ES2 Estabelecer um sistema de anlise de programao
para cada projeto.
Quadro 7.7 Etapas do stimo passo.

197

ES1 Estabelecer mecanismos que impeam que a informao seja empurrada

Nas empresas analisadas, a informao e os dados so, normalmente,
empurrados em forma de lote. Semelhante ao que ocorre no processo de
manufatura. Na empresa B, em particular, as atividades no esto plenamente
sincronizadas o que resulta em retrabalho no processo. Foram verificados gargalos
no fluxo do pacote de documentao do desenvolvimento do produto. Segundo
Morgan (2002), no processo de desenvolvimento de produtos da Toyota os
participantes concordam com um processo de envio de dados por meio de estgios,
cujos dados so puxados sempre que requisitados pela funo seguinte, e as tarefas
interfuncionais so estabelecidas de forma a maximizar a utilidade dos dados
disponveis.

ES2 Estabelecer um sistema de anlise de programao para cada projeto.

Esta etapa, de certa forma, decorrente da anterior ES1. Cada projeto de
desenvolvimento pode exigir recursos, etapas e programao diferentes, mesmo que
de uma forma geral todos os projetos percorram o mesmo caminho no fluxo do
desenvolvimento. Esta variabilidade distingue o processo de desenvolvimento do
processo de manufatura de massa, desta forma, precisa de observaes particulares
para cada um dos projetos. Esta anlise preliminar evitar que o projeto de
desenvolvimento seja encaminhado para etapas que, particularmente, sero
desnecessrias.

Output
O processo de desenvolvimento de produtos dever casar o fluxo dos projetos
com a capacidade de processo das atividades subseqentes.

198

7.2.8

ESFORO PARA A PERFEIO

O esforo para a perfeio constitui o processo de controle e melhoria. Para

que a aplicao da metodologia tenha resultados positivos, torna-se necessria a

constante avaliao dos objetivos e mtricas, estabelecidos no processo de
planejamento. Eventos de Kaizen, muito utilizados na manufatura enxuta, poderiam
ser empregados na busca de solues e melhorias no processo de implementao dos
princpios enxutos no processo de desenvolvimento de produtos.
As equipes de aplicao da metodologia tambm necessitam

de

acompanhamento, por se tratar de uma nova abordagem para a melhoria do processo

de desenvolvimento, Assim, possveis ajustes seriam necessrios nos procedimentos
utilizados pelas equipes.

Output
Como podemos observar na representao da Figura 7.8 so vrios os inputs
para este passo, exigindo, portanto, que os outpus sejam evolutivos e contnuos de
forma a propiciar a implementao da mentalidade enxuta.

7.2.9

ENCERRAMENTO DA APLICAO DA METODOLOGIA

O processo de encerramento acontecer quando o PDP, definido pela

empresa, alcanar um estado considerado enxuto, ou seja, quando as fases para a

criao de valor forem sistematicamente incorporadas ao processo formal de
desenvolvimento de produtos. Mas, o processo de melhoria definido no item 7.2.8
no deve findar-se com o encerramento do projeto de aplicao da metodologia. A
melhoria contnua ser incorporada s atividades de desenvolvimento e far parte do
novo PDP, visto que um dos princpios enxuto a perfeio.

199

Output
O processo de implementao pode ser encerrado por meio de um documento
formal contendo esta informao, porm a mentalidade enxuta permanecer e as
atividades de reviso do processo e conseqentes ajustes e melhorias devero
continuar de forma dinmica e incremental.

200

EXEMPLO DE APLICAO DA METODOLOGIA

Neste captulo, apresentado um exemplo de como a metodologia proposta

pode ser aplicada a um problema real de uma empresa, conforme os passos da

metodologia so detalhados, questes associadas com a implementao so
discutidas. Cabe, porm, ressaltar algumas limitaes identificadas para a aplicao
da metodologia.

8.1

LIMITAES PARA APLICAO DA METODOLOGIA

Esta pesquisa centralizou-se em empresas e cenrios com caractersticas

especficas, com base nas inferncias ou concluses obtidas foi possvel a construo
de uma metodologia que possibilita a aplicao dos princpios no PDP e a
conseqente melhoria do processo como um todo. Entretanto, tais especificidades
podem tambm limitar a rea para o emprego da metodologia visto que no se
mostraria aplicvel a contextos diferentes daqueles onde se realizaram as pesquisas.
As limitaes portanto relacionam-se com as seguintes caractersticas: tipos de
projetos de desenvolvimento de produto e formalizao do processo de
desenvolvimento:
Quanto aos tipos de projeto de desenvolvimento de produtos, podemos dizer
as empresas estudadas no cobriram todas as possibilidades e, portanto, os resultados
obtidos no podem ser generalizados a todos os tipos de projeto de desenvolvimento.
Os tipos de desenvolvimento, propostos por Wheelright e Clark (1992), foram
classificados em funo do grau de mudana no produto e do grau de mudana no
processo de manufatura que se acham representados na figura 8.1.
Os quatro tipos primrios de projetos de desenvolvimento, a at d,
diferem com relao ao grau de mudanas que os mesmos requerem na tecnologia de
produto e processo. O quinto tipo, e (parcerias), envolve trabalho conjunto com
outras organizaes, mesmo que qualquer um dos quatro tipos primrios possa ser
realizado em parceria, isso ocorre com maior freqncia com projetos que exijam

201

substancial mudana, excluindo, portanto, projetos derivativos de mudanas

incrementais.

d
P&D

Grau de Mudana no Produto

Grau de Mudana no Processo

Brakethrough

b
Plataforma

Derivativos

e
Parcerias

Figura 8.1 Tipos primrios de projeto de desenvolvimento

Fonte: Adaptado de Wheelright e Clark (1992)

Na Figura 8.2, podemos observar a regio de atuao no projeto de

desenvolvimento das empresas estudadas nesta tese e, conseqentemente, a regio na
qual a metodologia aplicvel.

202

d
P&D

Grau de Mudana no Produto

Grau de Mudana no Processo

Brakethrough

b
Plataforma

Derivativos

e
Parcerias

Figura 8.2 Regio de aplicao da metodologia proposta.

Na figura 8.2, pode-se observar que os projetos do tipo c e d no so

cobertos pela metodologia. Projetos do tipo d, P&D, normalmente, so conduzidos
por cientistas, engenheiros ou at mesmo gerentes. Eles comeam com uma idia, e
em seguida, so solicitados para elaborar uma programao detalhada, um resumo
dos custos envolvidos, um conjunto de especificaes e uma lista de recursos
necessrios, com vistas a tornar a idia uma realidade. Mas, estas tarefas so mais
fceis de serem ditas do que realizadas (Kerzner, 1998).
As dificuldades de planejamento e gerenciamento limitam a aplicao da
metodologia. Projetos do tipo c (braketrhough) tambm foram excludos da regio
de aplicao da metodologia, visto que exigem uma flexibilidade maior no uso dos
processos de manufatura o que, conseqentemente, impem uma maior dificuldade
no planejamento do projeto. Outro fator que levou excluso dos projetos tipo c,
foi o fato de que, durante as pesquisas, no foram observados projetos desse tipo.

203

Quanto formalizao do processo de desenvolvimento de produtos, usamos

a classificao proposta por Griffin (1997), ou seja: stage gates, funcional
seqencial, informal e nenhum processo.
Conforme Griffin, dentre as 85 empresas consideradas as melhores em suas
pesquisas, 22 conseguiam alcanar alto desempenho em desenvolvimento a despeito
da utilizao de um processo formal, deste total quatro no utilizam qualquer
processo e as 18 restantes seguem informalmente um procedimento. A situao
inverte-se quando so analisadas as empresas consideradas as demais, onde 48%
das empresas no utilizam um processo formal. Como a metodologia proposta
pressupe implementao de princpios enxutos para a melhoria do processo de
desenvolvimento de produtos, no se verifica a possibilidade de aplic-la em
empresas que no utilizam processo de formal desenvolvimento.
Desta forma, para a aplicao da metodologia foi selecionada uma empresa
que ocupasse uma posio na regio demarcada na Figura 8.7; que ao mesmo tempo,
possusse um processo formal de desenvolvimento de produtos.
O exemplo escolhido o de uma empresa do setor aeronutico que
desenvolve componentes para produo e conseqente utilizao nas aeronaves de
uso exclusivo da Fora Area Brasileira. Esta empresa ser, doravante, denominada
empresa D.

8.2

DESCRIO DA EMPRESA D
A empresa D tem uma estrutura funcional, na qual o departamento

responsvel pelo processo de desenvolvimento de produtos subordina-se diretamente

a uma diviso de engenharia. Alm do departamento de desenvolvimento de
produtos, a diviso de engenharia engloba diversos setores que cuidam dos diferentes
projetos sob a responsabilidade da organizao. Entenda-se, aqui, como projeto,
aeronaves e motores.
O departamento de desenvolvimento de produtos, composto por um
engenheiro e um tcnico, encarrega-se do recebimento das necessidades dos

204

diferentes clientes; quando verificada a viabilidade preliminar do desenvolvimento,

d inicio ao processo por meio de um departamento de estudos e projetos de
engenharia. O departamento de estudos e projetos de engenharia composto por um
tcnico, encarregado do departamento, e dois projetistas, encarrega-se da elaborao
do desenho tcnico que ser enviado ao departamento de fabricao.
O departamento de fabricao responsvel pela produo do produto final e
posterior distribuio aos interessados.

8.3

APLICAO DA METODOLOGIA PROPOSTA

O primeiro passo da metodologia a adoo da mentalidade enxuta, como no

caso da empresa D o nmero de envolvidos no processo de desenvolvimento de

produtos muito pequeno, no houve dificuldade na conscientizao dos
interessados sobre a proposta de melhoria do processo de desenvolvimento de
produtos apoiado nos princpios e prticas enxutas. A conscientizao ocorreu por
meio da explanao aos envolvidos dos princpios que norteiam a abordagem enxuta
e de que forma o processo at ento utilizado pela empresa poderia ser melhorado
baseado na utilizao desses princpios. A facilidade obtida na adoo da
mentalidade enxuta poderia no se repetir em uma empresa de maior porte com
nmero maior de envolvidos, pois a adoo da mentalidade enxuta , antes de tudo,
uma mudana de cultura, o que normalmente provoca uma resistncia natural a novas
idias.
Apesar da necessidade identificada de envolvimento da alta-administrao,
esta etapa foi suprimida do primeiro passo e, em virtude do carter experimental da
aplicao da metodologia, foi obtida somente uma autorizao para a aplicao.
O segundo passo relaciona-se com o planejamento das atividades que sero
necessrias aplicao da metodologia. Na empresa D, a integrao do PDP com a
estratgia da organizao se estabelece por meio de um documento formal que
estipula que os produtos desenvolvidos na organizao devero ser usados para
manter a operacionalidade das aeronaves, levando em conta questes de viabilidade
econmica e confiabilidade. Por se tratar de uma diretriz de cunho estratgico,

205

estipulada pela alta-administrao, esta etapa da metodologia foi considerada

cumprida.

Encerr.

Melhoria

Passo 7

Passo 6

Passo 5

Passo 4

Passo 3

Passo 2

Centro de custo
Regio sob responsabilidade

Passo 1

Aplicao da Metodologia

Diviso
Diviso
Manufatura Engenharia

Empresa D

Estrutura Funcional
Dep.to DP

Dep.to Est. Proj.

Fabricao

Figura 8.3 Matriz de responsabilidade para aplicao da metodologia proposta.

Em princpio, a equipe de implementao comps-se por um integrante do

departamento de desenvolvimento de produtos e um do departamento de estudos e
projetos, porm foi levantada a necessidade da incluso de mais um integrante: o
chefe da diviso de engenharia. Uma matriz de responsabilidade (figura 8.3) foi
elaborada para o projeto de aplicao da metodologia:
A estratgia de aplicao da metodologia considerou que a sua aplicao
deveria utilizar os recursos materiais e humanos disponveis, e seu escopo abrangeria
os setores diretamente envolvidos com o processo de desenvolvimento. Desta forma,
na matriz de responsabilidade cada interseo entre as reas funcionais e os passos da
metodologia a serem cumpridos representa o nvel de responsabilidade alocado para
cada setor.
Na empresa D, foram considerados para treinamento da aplicao da
metodologia somente os integrantes da equipe de implementao, mas, vislumbrouse a possibilidade do nmero de envolvidos ser maior, e elementos externos equipe

206

de aplicao pudessem ser treinados para servirem como agentes facilitadores do

processo.
Como objetivos e mtricas, foi estabelecido apenas um cronograma para a
aplicao da metodologia. Neste cronograma, foram determinadas as datas limites
para cumprimento de cada uma das etapas da metodologia.
O terceiro passo, tambm considerado o primeiro passo da execuo da
metodologia, pressupe a definio dos stakeholders ou interessados. No estado atual
do processo de desenvolvimento, verificou-se que o principal stakeholder
considerado pela empresa D, tambm, considerado cliente do processo, o
solicitante

do

desenvolvimento.

Ou

seja,

identificada

necessidade

do

desenvolvimento de um novo produto para o atendimento operacional de uma

determinada

aeronave,

algum

solicita

abertura

de

um

processo

de

desenvolvimento de produto. Para o departamento de desenvolvimento de produto,

este o stakeholder que deve ter suas necessidades atendidas. A partir do conceito de
stakeholder, definido durante a fase de preparao, outras possibilidades foram
consideradas para a definio dos interessados nesse processo de desenvolvimento.
Por exemplo, mesmo sendo uma das premissas estabelecidas pelo processo de
desenvolvimento, a questo da viabilidade econmica no era considerada
conscientemente como a de um stakeholder, ou seja, a necessidade da direo da
organizao. Observou-se que outro stakeholder importante s era envolvido em
eventuais situaes: o departamento de fabricao. Outro stakeholder considerado
importante na a aplicao da metodologia foi o usurio final que na figura 8.4 est
representado pelo balo equipe de manuteno. De forma geral, a definio dos
stakeholders foi alterada, conforme a Figura 8.4.

207

Stakeholder

Solicitante
do
Desenvol.

Departam
DP

Antes
Stakeholders

Solicitante do
Desenvol.

Direo da
Empresa
Departam
DP
Fabricao

Equipe de
Manuteno

Depois

Figura 8.4 A definio dos stakeholders pelo departamento de Desenvolvimento de

Produtos DP, antes e depois da aplicao da metodologia.

A identificao clara dos diferentes stakeholdrer possibilitou que etes fossem

considerados logo no incio no processo de desenvolvimento, o que possibilita a
reduo do tempo entre as interaes, ou seja, evita-se que feedbacks tardios possam
causar retrabalhos ou, at mesmo, a perda do produto desenvolvido.
Cada um dos interessados no processo de desenvolvimento de produtos tem
necessidades especficas com relao ao produto que est sendo desenvolvido e que,

208

muitas vezes, pode ser conflitante. Estas diferentes necessidades so o que podemos
chamar de valor. O Quadro 8.1 resume o entendimento de valor para cada
stakeholder.
Quadro 8.1 As diferentes perspectivas de valor para cada um dos stakeholders.
Stakeholder

Valor

Solicitante do
desenvolvimento

Significa o desenvolvimento do item em tempo para o cumprimento

dos prazos estabelecidos para a manuteno da aeronave.

Direo da empresa

a perfeita avaliao entre o custo de aquisio do produto e o

custo do desenvolvimento, quando houver, evidentemente, esta
possibilidade; e tambm o desenvolvimento do item em tempo para o
cumprimento dos prazos estabelecidos para a manuteno da
aeronave.

Departamento de
Manufatura

Um produto que seja manufaturvel de acordo com os recursos

disponveis para a fabricao e projetos (desenhos tcnicos) sem
erros.

Equipe de
manuteno

Um produto que, aps o processo de desenvolvimento, esteja de

acordo com os requisitos de operao.

Nas informaes do Quadro 8.1, observamos que a idia de valor identificada

para cada um dos interessados relativamente difusa; por exemplo, enquanto a
manufatura est presa exclusivamente s questes relativas ao processo de
fabricao, a equipe de manuteno est preocupada com a confiabilidade que o
produto ir oferecer quando incorporado ao sistema do qual faz parte. O tempo de
desenvolvimento importante tanto direo da organizao como ao solicitante do
desenvolvimento que no considerado pela equipe de manuteno ou pela
manufatura.
Esta etapa de definio dos stakeholders possibilitou que os integrantes do
processo de desenvolvimento discutissem sobre a possibilidade da participao de
integrantes dos diferentes grupos de stakeholders logo em seu incio, ou que existisse
um procedimento que tornasse obrigatria a consulta aos grupos de forma que se
pudesse identificar e equilibrar as diferentes necessidades. Um procedimento formal
para identificao do valor relativo a cada stakeholder ser elaborado. Este

209

procedimento dever conter informaes a respeito da qualidade, do custo e do prazo

relativo a cada processo de desenvolvimento.
O quarto passo diz respeito ao mapeamento do fluxo valor. Segundo Morgan
(2003), o fluxo do valor em um processo de desenvolvimento enxuto entrega aos
stakeholders o valor definido, no mais alto nvel de qualidade, no menor tempo
possvel, ao menor custo. Mas, o mapeamento no um fim em si mesmo. Para obter
sucesso na melhoria do processo de desenvolvimento de produto, preciso adequar a
ferramenta que ser utilizada no mapeamento.
Verificou-se a existncia de um fluxograma representativo do processo de
desenvolvimento, que servir de base para o mapeamento do fluxo de valor e
posterior implementao de melhorias. Conforme citado no captulo que constitui o
backgraund terico desta metodologia, existem vrias ferramentas relativas ao
mapeamento do fluxo do valor, segundo Millard (2001), nenhuma best practice foi
identificada, assim, o emprego do fluxograma mostrou-se adequado.
Cada atividade prevista no fluxograma foi revista e verificada de forma
qualitativa quanto sua pertinncia ao processo de desenvolvimento. Esta
verificao seguiu os seguintes critrios: atividades que criam valor, atividades que
no criam valor, mas so necessrias e atividades que no criam valor. As atividades
relacionadas com o Mapeamento do Fluxo do Valor (MFV) e a Anlise do Fluxo do
Valor (AFV), encontram-se esquematizadas na Figura 8.5.

Estado Atual
Processo
Atual

Ferramentas
e mtodos
disponveis
de MFV

MFV

Mtodo
Ferramenta
Melhoria

AFV

Estado Futuro

Estado Futuro

MFV

MFV

Mtodo
Ferramenta
Melhoria

AFV

Melhoria
do
Processo

Estado Ideal

MFV

Mtodo
Ferramenta
Melhoria

Mtodo
Ferramenta
Melhoria

AFV

AFV

Figura 8.5: Esquema bsico do processo de melhoria

Fonte: Adaptado de Millard (2001).

210

A Figura 8.5 estabelece como inputs do sistema o processo atual e as

ferramentas e mtodos disponveis para o mapeamento do fluxo do valor. Estes
inputs alimentam o primeiro ciclo de Mapeamento e Anlise do Fluxo do Valor.
Aps este primeiro ciclo, inicia-se o ciclo onde se comea a verificar quais os
possveis pontos de melhoria ao processo. Um novo fluxo estabelecido e sucessivas
interaes so realizadas de forma a se estabelecer um mapa do estado futuro. Este
processo continua at a obteno do que podemos chamar de um estado ideal para o
processo.
Na Figura 8.6 esto representados os fluxogramas do processo atual de
desenvolvimento de produtos da empresa D.

211

INCIO

INCIO
TENA
Prepara processo
de NAC-01

SOLICITANTE
Classifica o
material segundo a
categoria

Suprimento
Verifica
necessidade,
quantidade e prazo

PLJ/SUP
Abre
NAC-01

Categoria
"C"?

Necessrio?

ASS.TEC.
Prepara a
especificao
tcnica

Planejamento
Verifica
necessidade,
quantidade e prazo

TENA
Solicita desenho
TEEP

PLJ/SUP
Informa solicitante
o motivo da no
nacionalizao

TOFI
Solicita
modificao

TEEP
Providencia
desenho de
fabricao

PET
Dep. DP
Levanta modelo,
desenho, TO.

Dep. DP
Especifica
Projeto

TEEP
Produz esboo da
marcha

requer
marcha?

TOFI
Avalia esboo

esboo
aprovado?

PATE
Dep. DP
Coordena
fabricao

Dep. DP
Anlise
tcnicoeconmica

FIM

TEEP
Arquiva originais

B
Dep. DP
Encaminha
processo para
CABSP

TENA
Solicita
implantao

PAD

TPLJ
Implanta PN

Dep. DP
Acompanha
desenvolvimento

N
disponvel?

TENA
Verifica vida til
da aeronave

N
TENA
Atualiza
periodicamente

Maior do que
5 anos?

TENA
Envia documento
para fabricao

N
existe?

N
Disponvel?

TSUP
Verifica
disponibilidade
para importao

TENA
Verifica
necessidade de
interveno

N
acessvel?

TSUP
analisa valor do
lote mnimo

TTEC
considera
vivel?

modificar
processo?

TENA
Providencia
documento de
mudana

S
TENA
verifica
disponibilidade de
maquinrio

TOFI
Cumpre OS

INCIO

TENA
verifica
disponibilidade de
mo-de-obra

TENA
verifica
acessibilidade da
matria-prima

TCOS
autoriza OS

TENA
Convalida a
OFICINA para
produo do PN

FIM

Incio

TENA
verifica existncia
de mo-de-obra
especializada

TSUP
solicita OS

projeto
desenvolvido?

disponvel?

TENA
Coordena
emisso de IT de
acompanhamento

S
S

TENA
verifica existncia
de ferramental

existe?

ASS. PROJETO
Emite Instruo
Tcnica

IT
aprovada?

TENA
Acompanha
mensalmente a
situao

S
TENA
verifica custo de
produo no
PAMASP

custo
menor?

TTEC
Aprecia Instruo
Tcnica

prazo da IT
cumprido?

S
material
aprovado?

S
N
BT
aprovado?

TTEC
Aprecia Boletim
Tcnico

ASS. PROJETO
Emite Boletim
Tcnico

TENA
Solicita
emiso de BT

FIM

Figura 8.6: A representao do PDP da empresa D antes da melhoria.

212

Seguindo o processo de Mapeamento e Anlise do Fluxo de Valor, foi

possvel chegar representao do processo de desenvolvimento, como pode ser
verificada na Figura 8.7.
Especificao
do Solicitante

Incio

Estabelecer
requisitos
preliminare

Anlise de
viabilidade

FLUXO

Go no Go
Projeto
preliminar
Go no Go
Projeto
detalhado

Fabricao
e teste de
Produto
Go no Go
Produo

Fim

Figura 8.7: A representao do PDP da empresa D depois da melhoria.

Como observamos na figura 8.6, o processo de desenvolvimento de produtos

da empresa D visualmente detinha uma complexidade muito maior do que est
apresentada na Figura 8.7. Para alcanar essa estrutura mais simplificada uma nova
mentalidade precisou ser estabelecida em toda a equipe de desenvolvimento: a
mentalidade enxuta. Esta mudana, portanto, seguiu at aqui as seguintes fases: a
fase de preparao, onde os membros da equipe de desenvolvimento foram
preparados para a transio rumo ao pensamento enxuto; a fase de identificao do
valor, onde, com base na identificao dos diversos interessados nos resultados dos

213

processos de desenvolvimento de produtos, foi possvel a definio do valor em

termos de qualidade, custo e prazo. Na fase da proposio do valor, alm das
questes levantadas nas fases anteriores, foram levados em conta os seguintes
aspectos: a idia de eliminao de mudas e a idia de fluxo. Ou seja, o valor proposto
dever fluir de forma a ser entregue aos diversos interessados.
O primeiro procedimento adotado descarta a representao inicial do PDP
(Figura 8.6), que foi elaborada apoiada nas diferentes atividades funcionais da
empresa, o que dificultava a visualizao do fluxo do processo de desenvolvimento
do produto.
O novo mapa do processo eliminou as barreiras funcionais e reorganizou a
representao do PDP, para que pudesse explicitar a idia de fluxo. Este novo mapa
foi ento analisado com o objetivo de eliminar as atividades que no criavam valor.
Um exemplo disto foi a eliminao da atividade de aprovao da ficha de
especificaes tcnicas. Esta etapa do processo previa que aps o preenchimento da
ficha, por parte do engenheiro responsvel pelo projeto (aeronave), a mesma deveria
passar pelo crivo do chefe do departamento de DP. Outro exemplo, foi a eliminao
da etapa de aprovao do esboo da marcha de operaes para produo do
prottipo.
Na anlise do mapa do fluxo de valor, outro aspecto destacado foi a excluso
da etapa de solicitao de desenho tcnico ao departamento de estudos e projetos de
engenharia. Esta etapa foi classificada como uma atividade que no cria valor e, ao
mesmo tempo, ope-se lgica do pensamento enxuto, pois a atividade a jusante,
elaborao de desenho tcnico deveria puxar o servio, proporcionando um fluxo
contnuo ao processo.
O estado futuro do PDP da empresa D foi ento estruturado, conforme a
Figura 8.5. e segue os seguintes passos:

Incio o incio do processo tem como input uma necessidade formal do

solicitante do desenvolvimento;

Estabelecer requisitos preliminares nesta fase, so estabelecidos os

requisitos tcnicos bsicos de operao e aplicao do produto em um

214

determinado sistema. Os requisitos tambm so estabelecidos relacionados ao

prazo, possvel demanda e necessidade real de desenvolvimento.

Viabilidade de desenvolvimento a viabilidade do desenvolvimento

estabelecida em funo da disponibilidade de mo de obra (projeto e

fabricao), da disponibilidade de equipamentos e do custo de produo.
Verificada a viabilidade do desenvolvimento, o processo avana, caso
contrrio, o desenvolvimento do produto cancelado;

Projeto preliminar o projeto preliminar recebe os requisitos da fase de

requisitos preliminares e aplica os atributos de sistema para desenvolver um

conjunto de informaes. Neste ponto, o risco operacional mais bem
definido para incluir o risco de projeto ou o risco que o projeto do sistema
tem de no ser factvel em funo das restries tecnolgicas existentes.
Nesta fase, tambm, ser realizada a avaliao de um pr-prottipo virtual
cujo objetivo verificar o produto em termos geomtricos e funcionais, assim
como o desenvolvimento e avaliao da marcha de operaes (processo) para
a produo. O objetivo aqui certificar que os riscos de projetos sejam
minimizados ou at mesmo eliminados.

Projeto detalhado os outputs da etapa de projeto preliminar serviro

para a elaborao do projeto detalhado. Nesta fase, os riscos de projeto

levantados anteriormente so ainda mais reduzidos, sobretudo com base nas
mltiplas possibilidades de projeto que podero surgir. Podem ser
considerados outputs desta fase: a definio de produto (materializado em um
desenho tcnico) e os requisitos operacionais para a manufatura.

Fabricao e teste do produto esta fase recebe as informaes da fase

de projeto detalhado e realiza a prototipagem e testes de qualificao do

produto. Foi, nesta fase, que se identificou um dos maiores problemas. A
empresa enfrenta problemas de barreiras funcionais que prejudicam a
simultaneidade das atividades de detalhamento de projeto, fabricao e testes
de sistema. De um lado, a fabricao acredita que o setor de estudos e
projetos deve enviar um projeto totalmente pronto produo. Por parte do

215

departamento de estudos e projetos, existe a tentativa de satisfazer esta

necessidade da manufatura. O adequado seria que, ao se manufaturar, o
prottipo, a engenharia e a manufatura trabalhassem em conjunto no sentido
de transmitir e receber informaes necessrias s alteraes de projeto. O
principal output esperado para esta etapa o projeto qualificado para a
produo. Esta qualificao dar-se- sobretudo no que diz respeito
confiabilidade e coerncia das informaes contidas no projeto (representado,
muitas vezes, somente por um desenho tcnico).

Produo A manufatura receber, ento, o projeto qualificado e o

transformar em produto acabado. Nesta altura do processo, o risco estar

limitado capacidade produtiva.

Algumas medies seriam necessrias para a determinao do caminho

crtico deste novo PDP. No entanto, em virtude do tempo disponvel para esta
pesquisa esta etapa no foi executa durante a aplicao da metodologia.
Ficou definido que no haveria grandes mudanas no arranjo fsico dos
setores

envolvidos.

No

entanto,

foi

consenso

que

departamento

de

desenvolvimento de produtos e o departamento de estudos e projetos de engenharia

estavam fisicamente distantes da manufatura, o que propiciava o aparecimento de
muda de transporte, pois a informao que necessita fluir, muitas vezes, est sob a
forma de desenho tcnico impresso em papel.
Os mecanismos de integrao que poderiam ser utilizados na empresa D, j
estavam definidos, todavia no eram aplicados. Segundo o principal responsvel pelo
departamento de DP, existe um software para o desenvolvimento das atividades de
engenharia, incluindo a engenharia de manuteno e a de desenvolvimento de
produtos, entretanto os dados, muitas vezes, no so confiveis ou esto incompletos.
Outro problema encontrado foi a no incluso do departamento de estudos e projetos
de engenharia no mdulo de engenharia do software de gerenciamento. Isto impede
que o setor em questo verifique on-line quais os projetos pendentes que necessitam
de desenvolvimento, causando muitas vezes muda de espera, ou de transporte.

216

Observa-se tambm que os pedidos de desenvolvimento solicitados ao departamento

de estudos e projeto so empurrados para o setor, o que representa um contra-senso
mentalidade enxuta.
Outro problema identificado foi a falta de uma estrutura da rede de
informaes que integrasse os centros de usinagem aos computadores do setor de
estudos e projetos, equipados com sistemas CAD, CAM e CAE.
Desta forma, ficou definido que seria feita uma solicitao no sentido de
incluir o departamento de estudos e projetos no mdulo de engenharia e seria feito
um estudo de viabilidade da integrao entre as mquinas de controle numrico
computadorizadas (CNC), e os sistemas CAD,CAM e CAE.
As fases de efetiva implementao do novo processo de desenvolvimento de
produtos, baseadas na filosofia enxuta foram realizadas de forma parcial, pois no
houve tempo hbil para que a empresa pudesse realizar todas as alteraes
necessrias. Mas, alguns resultados puderam ser observados apoiados no
acompanhamento de um processo de desenvolvimento. Os resultados foram
classificados quanto ao tempo de desenvolvimento, qualidade do resultado final do
projeto e custo do processo de desenvolvimento.
Houve uma reduo significativa do tempo de desenvolvimento em razo da
utilizao do novo processo. Segundo dados histricos obtidos na empresa
pesquisada o tempo mdio para o desenvolvimento de um produto semelhante ao
acompanhado nesta avaliao seria de trinta dias, enquanto o desenvolvimento sob o
novo processo levou apenas dez dias, representando uma reduo de 66% do tempo
histrico.
A interao inicial entre engenharia e manufatura proporcionou um projeto
sem retrabalho pelo menos, neste acompanhamento especificamente e um
produto de acordo com as necessidades especficas de cada um dos stakeholders. Isto
significa, portanto, que o projeto tcnico era confivel no que diz respeito s
informaes nele contidas, aumentando a qualidade percebida dos operadores que se
utilizam do desenho. Segundo informao da empresa, o tempo consumido pelos

217

retrabalhos na elaborao do projeto que foram eliminados poderia , muitas

vezes, ser maior do que o tempo efetivamente gasto com o desenvolvimento.
No houve a possibilidade de obter informaes precisas a respeito do custo
de desenvolvimento, porm, a reduo da quantidade de homens-hora utilizados e a
alterao do material utilizado para a prototipagem podem representar uma
significativa reduo do custo do desenvolvimento.

8.4

AVALIAO DA METODOLOGIA PROPOSTA

A avaliao da metodologia proposta foi realizada com a equipe de

implementao da Empresa D. Os envolvidos no projeto de aplicao da

metodologia foram inquiridos com relao pertinncia de cada etapa proposta e as
respostas obtidas so apresentadas no decorrer deste captulo.
O objetivo da avaliao foi verificar a adequao da metodologia para
promoo

de mudanas

e melhorias

em

um

determinado

processo

de

desenvolvimento de produtos, assim como a adequao dos conceitos e prticas

enxutas a estas mudanas.
Os critrios de avaliao seguiram aqueles utilizados por Romano (2003), e
propostos por Fox apud Vernadat (1996). So eles:

Escopo relacionado com as atividades abrangidas pela metodologia;

Profundidade refere-se ao escopo, sob o ponto de vista do nvel de

detalhamento e de decomposio da metodologia;

Exatido complementar ao escopo e profundidade, est relacionado com

o modo pelo qual a realidade do processo de desenvolvimento entendida

pelos participantes, ou seja, define o grau de detalhes do modelo em termos
de capacidade de representao;

Competncia relacionado s reas do conhecimento abrangidas, isto ,

verifica se a metodologia relevante para resolver problemas de uma rea do

218

conhecimento, envolvida no processo de DP, ou se pode ser usada para

resolver problemas de vrias disciplinas;

Clareza capacidade da metodologia ser facilmente entendida;

Generalidade a metodologia no pode ter foco especfico em um

determinado tipo ou ambiente de desenvolvimento e, portanto, deve suportar

ampla aplicao para permitir uma avaliao de sua extenso;

Capacidade para suportar eficientemente a melhoria sem a necessidade

de grandes transformaes;

Transformao propriedade da metodologia que permite a alterao de

sua representao atual, para adequao a uma diferente aplicao;

Consistncia capacidade da metodologia expressar-se de forma unvoca;

Extensibilidade capacidade da metodologia ser expandida;

Completeza relacionado capacidade da metodologia conter toda a

informao necessria para sua aplicao;

Com base nesses critrios foram elaboradas as questes de avaliao
constantes no Quadro 8.2.

Quadro 8.2: Questes relacionadas com a avaliao da metodologia proposta.

Critrio

Questes

Escopo

Q1. A metodologia abrange todas as reas do processo de

desenvolvimento de produtos?

Profundidade

Q2.O nvel de detalhamento da metodologia (fases, processos,

passos e etapas) adequado para seu entendimento e execuo?

Exatido

Q3. A estrutura da metodologia (representada graficamente)

adequada para sua representao?

Competncia

Q4. A metodologia abrange os domnios de conhecimento

necessrios ao desenvolvimento de produtos?

Clareza

Q5. A metodologia de fcil entendimento?

219

Critrio

Questes

Generalidade

Q6. A metodologia suporta a aplicao em diferentes tipos de

desenvolvimento de produtos?

Capacidade

Q7. A metodologia permite a incorporao de diferentes tcnicas e

ferramentas de melhoria?

Transformao Q8. A metodologia suporta alteraes em sua estrutura, de forma a

tornar-se mais adequada para realizao das melhorias
necessrias?
Consistncia

Q9. A metodologia apresenta consistncia de informao, ou seja,

concordncia aproximada com os resultados obtidos e cada passo,
etapa ou fase?

Extensibilidade Q10. A metodologia permite sua expanso, ou seja, a definio de

novas atividades no previstas anteriormente?
Completeza

Q11. A metodologia contm toda a informao necessria para a

obteno das melhorias almejadas?

As questes do Quadro 8.2 foram redigidas em forma de questionrio que

foram distribudos a dois integrantes da equipe de implementao na empresa D. Um
resumo das respostas obtidas encontra-se a seguir.
No caso especfico desta empresa, a metodologia proposta conseguiu
abranger todas as reas envolvidas no processo de desenvolvimento.
(Avaliador 1).
Concordo que a metodologia permitiu que se pudesse evolveu todas as
reas do processo de desenvolvimento. (Avaliador 2).
O nvel de detalhamento da metodologia est adequado. (Avaliador 1).
O detalhamento da metodologia est adequado, mas em uma observao
preliminar, sem o devido esclarecimento acerca das atividades, a
metodologia aparenta uma complexidade maior do que aquela observada na
prtica. claro que possveis ajustes podem ser realizados. (Avaliador 2).

220

A estrutura da metodologia, representada em forma de fluxograma,

representa de forma adequada a seqncia das etapas que devero ser
executadas. (Avaliador 2).
Todas as reas de conhecimento necessrias execuo processo do
processo de desenvolvimento de produtos esto presentes na metodologia
proposta. Porm, nem sempre de forma explcita. Como exemplo posso citar
que a etapa PV3 Definir valor em termos de qualidade, custo e prazo, no
define exatamente quais as ferramentas que poderiam ser utilizadas para a
definio destes parmetros, em funo dos diferentes interessados
(Avaliador 2).
A metodologia de fcil entendimento, desde que o participante esteja
familiarizado com a viso enxuta. (Avaliador 1).
A metodologia oferece a oportunidade da utilizao de diferentes tcnicas e
ferramentas de melhoria. No caso especfico desta empresa, foi de muita
valia a utilizao do mtodo de Mapeamento e Anlise do Fluxo de Valor na
readequao de nosso processo de desenvolvimento de produtos (Avaliador
2).
Mesmo no tendo sido feita nenhuma mudana significativa na metodologia
para a aplicao na empresa, observou-se que a mesma suportaria possveis
adequaes (Avaliado 2).
A metodologia proporcionou, alm do entendimento da mentalidade enxuta,
a capacidade do entrevistado avaliar seu prprio PDP. (Avaliador 1).
Embora no tenha havido oportunidade de incluso de novas atividades,em
razo de transformao e consistncia a metodologia mostrou-se apta a uma
aplicao extensiva. (Avaliado 1)
Foi possvel observar uma consistncia no fluxo de informao previsto na
metodologia e aquele observado na prtica. (Avaliador 2).
Em que pese as vicissitudes inerentes a cada empresa a metodologia parece
oferecer toda a informao necessria a obteno das melhorias que se
almeja alcanar (Avaliador 1).

221

A metodologia proposta possibilitou uma transformao cultural na diviso

de desenvolvimento de produtos. De fato, a familiarizao com a mentalidade
enxuta, aliada a necessria conscientizao de profissionais-chave, foram
essenciais a uma incrementao de racionalidade no PDP da empresa.
empresa to-somente compete manutenir e melhorar suas atividades com
base na metodologia proposta. (Avaliador 1)

De uma forma geral, a metodologia contribuiu para a melhoria do processo de

desenvolvimento da empresa D e mostrou-se consistente com seus objetivos. Foi
observado tambm que sem o entendimento da mentalidade enxuta, seria difcil o
incio do processo de implementao. Alguns dos envolvidos no tinham qualquer
idia de que forma os princpios enxutos poderiam ser teis ao PDP, no caso de
alguns participantes, no existia sequer o entendimento do termo enxuto.
Aps a conscientizao sobre a mentalidade enxuta, e do estabelecimento da
necessidade de mudana, o processo de implementao tornou-se mais fcil.
Observou-se que a metodologia de uma forma geral de fcil entendimento.
A representao grfica da metodologia induz o entendimento de que todas as
atividades devem ser realizadas de forma seqencial, porm esta uma inferncia
equivocada, sobretudo nas etapas que compem cada um dos passos. A
simultaneidade das etapas e os passos da metodologia dependero da no relao de
dependncia entre os mesmos, assim como da quantidade de recursos necessrios
para a aplicao da metodologia.
O processo de execuo da metodologia, no qual o fluxo do valor colocado
em prtica, pareceu ser a de maior dificuldade da implementao, pois sai do campo
das idias e passa para a efetiva implementao das melhorias propostas que
conduziro o PDP a um estado futuro ideal.
necessrio, portanto, que a atividade de aplicao da metodologia seja
tratada como objetivos de mdio prazo. Efetivos resultados s podero ser
observados, aps o acompanhamento de alguns projetos executados com base no
novo PDP. Desta forma, a metodologia proposta, avaliada com relao a diversos
critrios apresentou consistncia com o objetivo desta pesquisa.

222

CONCLUSES E RECOMENDAES
Esta tese explorou a aplicao de princpios e prticas enxutas em ambientes

de desenvolvimento de produtos. No decorrer dos captulos procurou-se abordar, em

linhas gerais, a teoria relacionada tanto com os princpios e prticas enxutas como s
relacionadas ao processo de desenvolvimento de produtos, assim como as prticas
das empresas no que se refere ao processo de desenvolvimento de produtos. Em um
captulo especfico, foi proposta e avaliada uma metodologia para implementao de
princpios e prticas enxutas no PDP.
Os princpios enxutos, originalmente, compem um conjunto de tcnicas e
ferramentas que tm como objetivo a melhoria do processo de manufatura, mas que
rapidamente migraram para reas gerenciais dentro da empresa, tendo sempre como
objetivo principal a criao de valor e a eliminao de desperdcios. Para efeito desta
tese, valor foi definido como a capacidade de produto ou servio em atender os
requisitos, utilidade e custo definidos pelos diferentes stakeholders.
A dificuldade inicial para a realizao desta pesquisa foi a obteno de textos
especfico sobre a aplicao de princpios enxutos no processo de desenvolvimento
de produtos. As principais fontes de dados sobre este tema esto concentradas em
dois centros de pesquisa, o Lean Aerospace Initiative LAI, do MIT e a
Universidade de Michigan, alguns poucos trabalhos encontrados fora destes dois
centros no guardavam relao direta entre princpios enxutos e desenvolvimento de
produtos, apesar de o ttulo do trabalho, muitas vezes, sugerir tal relao.
Durante as investigaes bibliogrficas, foi constatado que ainda existem
gaps na pesquisa sobre o tema desenvolvimento de produtos enxuto. Contudo, uma
pesquisa com empresas nacionais seria, em um primeiro momento, inexeqvel, visto
que no se observou, em pesquisa exploratria, nenhuma empresa brasileira que de
fato tenha um processo de desenvolvimento enxuto. Partindo desta premissa, foi
possvel inferir que seria necessrio investigar o quanto empresas que desenvolvem
produtos esto alinhadas s prticas enxutas e de que forma, sistematicamente, seria
possvel conduzir os PDP dessas empresas a um estado considerado enxuto.

223

O objetivo geral desta tese foi, portanto, propor uma metodologia (Captulo 7)
que possibilite, de forma estruturada, o emprego dos princpios e prticas enxutas no
mtodo de desenvolvimento de produto. Para a consecuo deste objetivo, a pesquisa
apoiou-se nos resultados dos seguintes objetivos especficos: anlise das prticas
industriais, verificao de seu alinhamento com os princpios e prticas enxutas e
identificao das oportunidades de melhoria; identificao dos principais modelos
existentes para criao de valor em ambientes outros que no o da manufatura;
investigao dos mecanismos de integrao para a equipe de desenvolvimento de
produtos, com base na mentalidade enxuta; identificao de uma plataforma de
gesto que auxilie na implementao dos princpios enxutos no processo de
desenvolvimento de produtos (Captulo 5).
Alguns exemplos relacionados com os problemas encontrados no processo de
desenvolvimento de produtos foram apresentados no captulo 2 e serviram como
justificativa para a pesquisa. Os exemplos apresentados foram obtidos com base em
um caso constante da literatura e tambm em pesquisa de campo. A principal
contribuio destes casos para a tese foi a clara identificao da necessidade de se
reconhecer o que representa valor para cada um dos stakeholders, e que esta
identificao deve ocorrer o mais cedo possvel, pois quanto mais tarde, maior o
retrabalho e, conseqentemente, maior o custo de modificao de projeto.
Esta pesquisa contribuiu para a literatura de processo de desenvolvimento de
produtos aprofundando a discusso sobre a utilizao de princpios de melhoria
originalmente adotados nas prticas industriais de manufatura para melhoria tambm
do processo de desenvolvimento, o que representa uma extenso dos trabalhos
desenvolvidos pela equipe de desenvolvimento de produtos do Lean Aerospace
Initiative (Bauch, 2004; Browning, 1998; McManus e Millard 2002; McNutt, 1998).
Contribui com a identificao da necessidade de uma metodologia que possibilite a
implementao desses princpios, visto que o foco das metodologias existentes
relaciona-se exclusivamente com o mapeamento e a anlise do valor, sendo isto, na
verdade, uma atividade a jusante do processo como um todo.

224

9.1

RESULTADOS, CONTRIBUIES E LIMITAES

Na presente pesquisa, os resultados esperados podem ser classificados em

duas categorias: a primeira, compe-se das concluses e inferncias originadas da

comparao entre a literatura pesquisada e as informaes e dados colhidos durante a
investigao das prticas industriais. Estas concluses relacionam-se com as
oportunidades de melhoria no projeto de desenvolvimento baseadas na utilizao de
princpios e prticas enxutas. A segunda, constitui-se do desenvolvimento de uma
estrutura que possibilite a aplicao dos insights resultantes das inferncias
realizadas na primeira parte dos resultados.
Os principais insights obtidos foram:

Existe a necessidade de uma preparao/ treinamento a respeito destes

princpios e prticas enxutas;

preciso estabelecer a necessidade de mudana;

Os envolvidos com o PDP, sobretudo a gerncia, precisam comprar a idia;

Os PDPs devem ser formalizados e devem estar integrados estratgia da

empresa;

Os stakeholders, muitas vezes, no so identificados de forma correta;

As necessidades dos diferentes stakeholders nem sempre so consideradas de

forma equilibrada;

Existe a idia de se considerar apenas as necessidades dos consumidores

finais;

A preocupao com a eliminao de desperdcios no PDP no tratada de

forma sistemtica;

A idia de fluxo no est consolidada nas atividades de desenvolvimento de

produtos;

O arranjo fsico, assim como na manufatura, tambm pode ser importante

para o fluxo no processo de desenvolvimento de produtos;

225

A representao do PDP deve considerar apenas as atividades que criam

valor;

As empresas, ao desenvolverem processos simultneos, levam em conta

apenas a reduo do tempo de desenvolvimento;

Empresas de menor porte tm dificuldade com a implementao de atividades

simultneas no processo de desenvolvimento;

As empresas esto desejosas por melhoria em seus processos;

Melhorias em processos de desenvolvimento so obtidas baseadas em

mudanas culturais;

As melhorias devem ser tratadas como objetivos a longo prazo.

Segundo Millard (2001), o time de pesquisa em desenvolvimento de produto

do Lean Aerospace Initiative (LAI) tem observado que vrias questes relacionadas
com a aplicao de princpios enxutos no desenvolvimento de produtos no esto
respondidas. Existem vrios gaps, no que se refere ao conhecimento j produzido
sobre como o conceito enxuto pode ser utilizado nas atividades de engenharia.
Assim, as principais contribuies desta pesquisa para os estudos sobre
gerenciamento do projeto de desenvolvimento so as seguintes:

Definio de uma viso integrada do projeto de desenvolvimento de produtos,

levando em conta as etapas de identificao de valor, proposio do valor e
entrega do valor. Isto se mostrou necessrio visto que os esforos de pesquisa
atuais tm contemplado sobretudo a ltima etapa entrega de valor (Bauch,
2004; Browning, 1998; McManus e Millard 2002; McNutt, 1998);

Ampliao do modelo de trs fases, para incluso de uma fase inicial de

preparao, na qual so ajustadas as prioridades relativas dos objetivos de
desenvolvimento com base na criao de valor. Esta alterao importante por
dois motivos: primeiro, para incluir as necessidades especficas das organizaes
no que se refere ao entendimento da mentalidade enxuta; segundo, porque a
criao de valor no processo de desenvolvimento de produtos s possvel

226

quando existe um acordo mtuo (tcito ou explcito) entre os principais

stakeholders (Murman at. al.);

Identificao de uma seqncia para a implementao dos princpios enxutos no

processo de desenvolvimento de produtos, pois o modelo de trs fases para a
criao de valor cujo objetivo principal oferecer uma representao
simplificada da realidade um modelo genrico de aplicao ampla nos mais
diversos nveis organizacionais assim como no ciclo de desenvolvimento como
um todo (Stanke, 2001).

Desenvolvimento de uma estrutura metodolgica que auxilie a tomada de

deciso no projeto do processo de desenvolvimento. Esta estrutura permitir que
sejam definidas, com orientao para a criao de valor, questes relacionadas
com: tipo do desenvolvimento (ex.: stage-gates); seqncia de atividades;
planejamento de prottipos; mecanismos de comunicao entre os membros das
equipes de desenvolvimento e projetos de monitorao e controle.
Em relao s limitaes desta pesquisa, podemos destacar as seguintes: (a) o

estudo das prticas industriais, por se tratar de um tema complexo com muitas
variveis envolvidas, foi analisado baseado em estudos de caso mltiplos o que no
permite a generalizao dos resultados obtidos. (b) Tambm possvel entender que
o tipo de estudo aqui apresentado no permite o aprofundamento de questes que
possam

ser

importantes

para

entendimento

de

algumas

prticas

em

desenvolvimento de produtos e, conseqentemente, o impacto destas questes na

metodologia proposta. Como exemplo, podemos citar a anlise detalhada das
atividades desenvolvidas em cada etapa do processo de desenvolvimento de
produtos, sobretudo no que se refere aos inputs, forma de processamento e outputs.
(c) Seria necessrio

incluir na

pesquisa

empresas

que

trabalham

com

desenvolvimento de produtos breakthrough, pois por se tratarem de produtos

inovadores, tambm precisam do desenvolvimento de processos com caractersticas
especiais. Segundo Wheelwright e Clark (1992), os gerentes que lidam com
desenvolvimento de produtos breakthrough precisam oferecer aos times de
desenvolvimento certa flexibilidade no que se refere, por exemplo, ao processo de
manufatura, impedindo que sejam impostas restries s equipes em virtude das

227

tcnicas de operao, plantas e equipamentos existentes. Com base nas limitaes

expostas, sero propostas sugestes para pesquisas futuras com melhoria do processo
de desenvolvimento de produtos pela utilizao de princpios e prticas enxutas. (d) a
aplicao da metodologia proposta foi limitada em seu escopo e no incluiu a fase de
execuo em funo das limitaes impostas pela empresa.

9.2

RECOMENDAES PARA PESQUISAS FUTURAS

Embora o mtodo de estudo de caso ou pesquisa de campo seja uma profunda

observao de um evento especfico, muitas questes no puderam ser respondidas.

Algumas podem representar sugestes para futuras pesquisas e sero apresentadas a
seguir.
1. Pesquisa quantitativa sobre as prticas de processo de desenvolvimento de
produtos: muitas das observaes e insights obtidos baseados neste estudo podem
apresentar mais robustez quando da aplicao de mtodos quantitativos de pesquisa.
A utilizao de ferramentas especficas para a eliminao de desperdcios ou at
mesmo a existncia prtica dessas ferramentas no processo de desenvolvimento de
produtos pode representar uma oportunidade de pesquisa.
2. Verificao da idia de fluxo em DP: durante a anlise das prticas de DP
contidas nesta tese, verificou-se uma diversidade com relao ao entendimento do
fluxo das atividades de desenvolvimento de produtos. Uma pesquisa, com um
nmero maior de empresas, poderia mapear as melhores prticas sobre o tema.
3. Avaliao da aplicao da metodologia proposta em diferentes contextos
de desenvolvimento: o processo de desenvolvimento poder ser classificado sob
diferentes categorias ou tipos, sendo esta categorizao obtida por meio de diferentes
dimenses. Segundo Wheelwright e Clark (1992) estas categorias podem ser
divididas em: projetos derivativos, breakthrough e plataformas. Uma sugesto para
futuras pesquisas relaciona-se com a verificao mais rigorosa da aplicabilidade da
metodologia proposta em cada uma destas categorias.

228

4. Uma avaliao profunda da metodologia em uma empresa: os estudos

realizados no puderam aprofundar as anlises da aplicabilidade da metodologia
proposta. Uma avaliao profunda da metodologia em uma empresa poder
contribuir para o entendimento dos processos de melhoria em desenvolvimento de
produtos.

229

ANEXO A

FORMULRIOS DE PESQUISA

230

Avaliao do alinhamento do Processo de Desenvolvimento de Produto com as Prticas Enxutas

Decises sobre o processo de desenvolvimento de produto devem estar aliceradas em quantificaes e tradeoffs de valor que incorporem os inputs dos stakeholders envolvidos.
Questes de Diagnstico

1.

O processo de desenvolvimento de produto formalizado e compreendido?

2.

Os clientes e demais stakeholders (acionistas, funcionrios, etc.) so regularmente envolvidos no processo de desenvolvimento?

3.

As preocupaes iniciais dos stakeholders sobre o projeto e seu desenvolvimento so consideradas e incorporadas no processo to cedo quanto
possvel?

4.

As interaes desnecessrias no ciclo de desenvolvimento so removidas?

5.

O ciclo de desenvolvimento tem sido simplificado e alinhado ao caminho crtico?

6.

Produtos e processos so desenvolvidos de forma simultnea?

Nveis de Alinhamento Enxuto

Prtica Enxuta
1.

O Processo de
Desenvolvimento cria
valor para o produto.
A perfeita
compreenso de um
Processo de
Desenvolvimento de
Produtos permite a
eliminao de mudas
e a criao de valor.
Indicador Enxuto

Nvel 1

Nvel 2

Nvel 3

Nvel 4

Nvel 5

No existe um processo de
desenvolvimento de produtos
formalizado.

O processo de
desenvolvimento est
formalizado porm no
seguido e/ou os participantes
no o compreendem.

Existe um processo de
desenvolvimento de produto
formalizado e os envolvidos o
compreendem.

Existe um processo de
desenvolvimento de produto
formalizado as pessoas o
compreendem e melhorias
ocasionais so realizadas.

O processo de
desenvolvimento de produto
formalizado e constantes
revises so realizadas. Todos
os participantes compreendem
suas etapas e participam do
processo de melhoria

Estado

Estado

Estado

Estado

Estado

Estado

Estado

Estado

Estado

Atual

desejado

Atual

Atual

desejado

Atual

desejado

Atual

desejado

Estado
desejado

O processo de desenvolvimento de produto est consolidado em um documento formal.

As pessoas envolvidas demonstram ter conhecimento sobre suas etapas.

O time discute de forma sistemtica a pertinncia das etapas do processo de desenvolvimento do produto, revisando-as quando necessrio.

Escrever alguns
exemplos como
evidncia do Estado
Atual
Escreva alguns
exemplos de
oportunidades de
melhorias

229

231

Avaliao do alinhamento do Processo de Desenvolvimento de Produto com as Prticas Enxutas

Decises sobre o processo de desenv. de produto devem estar aliceradas em quantificaes e tradeoffs de valor que incorporem os inputs dos stakeholders envolvidos.
Questes de Diagnstico

1.

O processo de desenvolvimento de produto formalizado e compreendido?

2.

Os clientes e demais stakeholders (acionistas, funcionrios, etc.) so regularmente envolvidos no processo de desenvolvimento?

3.

As preocupaes iniciais dos stakeholders sobre o projeto e seu desenvolvimento so consideradas e incorporadas no processo to cedo quanto
possvel?

4.

As interaes desnecessrias no ciclo de desenvolvimento so removidas?

5.

O ciclo de desenvolvimento tem sido simplificado e alinhado ao caminho crtico?

6.

Produtos e processos so desenvolvidos de forma simultnea?

Nveis de Alinhamento Enxuto

Prtica Enxuta
2.

O Valor do Cliente
incorporado no projeto
do Produto e
processos.

Nvel 1

Nvel 2

Nvel 3

Nvel 4

Nvel 5

Na sua empresa, os inputs dos

clientes so capturados
somente no incio do processo
de desenvolvimento.

Os inputs dos clientes so

considerados de forma
quantitativa atravs de uma
ligao da alta gerncia com
os clientes e por meio de
revises ocasionais.

Os clientes esto formalmente

representados nos times
integrados de desenvolvimento
de produtos de sua empresa.
Existem mecanismos de
feedback no processo de
desenvolvimento de produtos
para entender e minimizar
interaes no projeto.

Os clientes so ativamente
envolvidos com os times
integrados de desenvolvimento
de produtos, e de forma
conjunta melhorar a eficcia e
qualidade dos produtos e
processos projetados por sua
empresa.

Os clientes esto, de forma

rotineira, envolvidos com os
times integrados de
desenvolvimento de produtos
e so membros importantes do
time. O compartilhamento de
benefcios est bem definido.
A quantificao e o
compartilhamento do valor
assim como os trade-offs de
requisitos so contnuos e
automaticamente fazem parte
do processo.

Estado

Estado

Estado

Estado

Estado

Estado

Estado

Estado

Estado

Estado

Atual

desejado

Atual

desejado

Atual

desejado

Atual

desejado

Atual

desejado

O entendimento do
valor para o cliente
permite a melhoria
contnua tanto para o
produto quanto para o
processo

Indicador Enxuto

Buscam-se os inputs dos clientes e estes inputs so utilizados de forma ativa no processo de desenvolvimento de produtos.
Os projetos satisfazem os requisitos dos clientes, sem funcionalidades desnecessrias.
O senso de time entre a empresa e o cliente para melhor definir ou redefinir os requisitos durante o processo de desenv. de produtos.

Escrever alguns exemplos

como evidncia do Estado
Atual
Escreva alguns exemplos de
oportunidades de melhorias

230

232

Avaliao do alinhamento do Processo de Desenvolvimento de Produto com as Prticas Enxutas

Decises sobre o processo de desenv. de produto devem estar aliceradas em quantificaes e tradeoffs de valor que incorporem os inputs dos stakeholders envolvidos.
Questes de Diagnstico

1.

O processo de desenvolvimento de produto formalizado e compreendido?

2.

Os clientes e demais stakeholders (acionistas, funcionrios, etc.) so regularmente envolvidos no processo de desenvolvimento?

3.

As preocupaes iniciais dos stakeholders sobre o projeto e seu desenvolvimento so consideradas e incorporadas no processo to cedo
quanto possvel?

4.

As interaes desnecessrias no ciclo de desenvolvimento so removidas?

5.

O ciclo de desenvolvimento tem sido simplificado e alinhado ao caminho crtico?

6.

Produtos e processos so desenvolvidos de forma simultnea?

Nveis de Alinhamento Enxuto

Prtica Enxuta
3.

Incorporar o valor dos

stakeholders produto
e nos processos.
O entendimento do
valor para o
stakehorders do incio
do processo
(manufatura, suporte,
etc.) permite que o
valor flua para o
cliente.
Indicador Enxuto

Nvel 1

Nvel 2

Nvel 3

Nvel 4

Nvel 5

As questes de manufatura
so consideradas no final do
processo de desenvolvimento.
Isto freqentemente resulta em
problemas de produtibilidade
ou custos de produo
desnecessrios.

Questes acerca de
manufatura e montagem so
consideradas no incio dos
projetos, porm de uma forma
simplificada. Consideraes
sobre fornecedores e custos
so limitadas.

Times multifuncionais incluem

as disciplinas de incio de
projeto assim como os
fornecedores chaves de sua
empresa.

As prioridades dos
stakeholders do incio do
processo so quantificadas no
projeto to cedo quanto
possvel e utilizadas na
avaliao e melhoria do
processo.

Os valores dos stakeholders

do incio do processo so
quantificados e balanceados
em funo dos trade-offs, e
so considerados partes
contnuas no processo de
desenvolvimento de produto.

Estado

Estado

Estado

Estado

Estado

Estado

Estado

Estado

Estado

Estado

Atual

desejado

Atual

desejado

Atual

desejado

Atual

desejado

Atual

desejado

As questes dos stakeholders so consideradas e incorporadas logo no incio e continuam ao longo do processo

As consideraes dos stakeholders so integradas ao projeto de forma a incluir implicaes de manufatura, montagem, teste e servio.

Como conseqncia da considerao do valor no incio do projeto, os produtos so produzidos de forma mais fcil e os custo do ciclo tornam-se
menores.

Escrever alguns
exemplos como
evidncia do Estado
Atual
Escreva alguns
exemplos de
oportunidades de
melhorias

231

233

Avaliao do alinhamento do Processo de Desenvolvimento de Produto com as Prticas Enxutas

Decises sobre o processo de desenvolvimento de produto devem estar aliceradas em quantificaes e tradeoffs de valor que incorporem os inputs dos stakeholders envolvidos.
Questes de Diagnstico

1.

O processo de desenvolvimento de produto formalizado e compreendido?

2.

Os clientes e demais stakeholders (acionistas, funcionrios, etc.) so regularmente envolvidos no processo de desenvolvimento?

3.

As preocupaes iniciais dos stakeholders sobre o projeto e seu desenvolvimento so consideradas e incorporadas no processo to cedo quanto
possvel?

4.

As interaes (retorno de informaes para atividades montante) desnecessrias no ciclo de desenvolvimento so removidas?

5.

O ciclo de desenvolvimento tem sido simplificado e alinhado ao caminho crtico?

6.

Produtos e processos so desenvolvidos de forma simultnea?

Nveis de Alinhamento Enxuto

Prtica Enxuta
4.

Eliminar o fluxo
desnecessrio de
informaes.

Nvel 1

Nvel 2

Nvel 4

Nvel 5

No h avaliao das
informaes que retornam
causando retrabalho.

Eventualmente o fluxo de
informao verificado.
Possveis retornos de
informaes que no sejam
desejados so eliminados.

As etapas do PDP so
analisadas de forma criteriosa
para evita o retrabalho. So
utilizadas ferramentas para
verificar as possveis revises
desnecessrias.

So utilizadas ferramentas
especficas para
acompanhamento do fluxo de
informaes no PDP. So
realizadas avaliaes
qualitativas e quantitativas do
fluxo de informao

O mapeamento e anlise do
fluxo das informaes so
executados de forma que ao
longo de todo o processo, e
atravs de ferramentas
especficas, o valor seja criado
e os mudas eliminados.

Estado

Estado

Estado

Estado

Estado

Estado

Estado

Estado

Estado

Estado

Atual

desejado

Atual

desejado

Atual

desejado

Atual

desejado

Atual

desejado

A remoo das
interaes faz com
que o PDP flua sem
retrabalho.

Indicador Enxuto

Nvel 3

Um time multifuncional revisa de forma sistemtica as etapas do Processo de Desenvolvimento de Produtos.

Ferramentas como Mapeamento do Fluxo de Valor e Matriz de Estrutura de Projeto.so utilizadas na eliminao das interaes.

A eliminao dos refluxos de informao realizada de forma a melhorar continuamente o processo e conseqentemente criar valor.

Escrever alguns
exemplos como
evidncia do Estado
Atual
Escreva alguns
exemplos de
oportunidades de
melhorias

232

234

Avaliao do alinhamento do Processo de Desenvolvimento de Produto com as Prticas Enxutas

Decises sobre o processo de desenvolvimento de produto devem estar aliceradas em quantificaes e tradeoffs de valor que incorporem os inputs dos stakeholders envolvidos.
Questes de Diagnstico

1.

O processo de desenvolvimento de produto formalizado e compreendido?

2.

Os clientes e demais stakeholders (acionistas, funcionrios, etc.) so regularmente envolvidos no processo de desenvolvimento?

3.

As preocupaes iniciais dos stakeholders sobre o projeto e seu desenvolvimento so consideradas e incorporadas no processo to cedo quanto
possvel?

4.

As interaes desnecessrias no ciclo de desenvolvimento so removidas?

5.

O ciclo de desenvolvimento tem sido simplificado e alinhado ao caminho crtico?

6.

Produtos e processos so desenvolvidos de forma simultnea?

Nveis de Capacidade

Prtica Enxuta
5.

Nvel 1

Nvel 2

Nvel 3

Nvel 4

Nvel 5

Simplificar as etapas
do processo
identificando os tipos
de mudas e
eliminando-os.

Sempre que detectada

qualquer complexidade
desnecessria no ciclo de
desenvolvimento estas so
removidas.

Sempre que detectada

qualquer complexidade
desnecessria no ciclo de
desenvolvimento estas so
removidas. Sendo observado
seu alinhamento co o caminho
crtico.

Constantes revises so
efetuadas no sentido de tornar
as atividades menos
complexas e alinhadas ao
caminho crtico.

As pessoas envolvidas com o

ciclo do desenvolvimento
realizam constantes revises
no sentido de tornar as
atividades menos complexas e
alinhadas ao caminho crtico.

A eliminao de
desperdcios o
passo principal para a
criao de valor.

Grupos multifuncionais
discutem o ciclo de
desenvolvimento e decises
com relao a melhorias so
tomadas em consenso. Onde
constantes revises so
efetuadas no sentido de tornar
as atividades menos
complexas e alinhadas ao
caminho crtico.

Estado

Estado

Estado

Estado

Estado

Estado

Estado

Estado

Estado

Atual

desejado

Atual

desejado

Atual

desejado

Atual

desejado

Atual
Indicador Enxuto

Estado
desejado

Existem atividades programadas no sentido de revisar o ciclo de desenvolvimento.

Equipes multifuncionais discutem de forma estruturada o ciclo de desenvolvimento.

Novas tecnologias que possam simplificar o ciclo de desenvolvimento so pesquisadas e avaliadas com respeito a sua aplicabilidade.

Escrever alguns
exemplos como
evidncia do Estado
Atual
Escreva alguns
exemplos de
oportunidades de
melhorias

233

235

Avaliao do alinhamento do Processo de Desenvolvimento de Produto com as Prticas Enxutas

Decises sobre o processo de desenvolvimento de produto devem estar aliceradas em quantificaes e tradeoffs de valor que incorporem os inputs dos stakeholders envolvidos.
Questes de Diagnstico

1.

O processo de desenvolvimento de produto formalizado e compreendido?

2.

Os clientes e demais stakeholders (acionistas, funcionrios, etc.) so regularmente envolvidos no processo de desenvolvimento?

3.

As preocupaes iniciais dos stakeholders sobre o projeto e seu desenvolvimento so consideradas e incorporadas no processo to cedo quanto
possvel?

4.

As interaes desnecessrias no ciclo de desenvolvimento so removidas?

5.

O ciclo de desenvolvimento tem sido simplificado e alinhado ao caminho crtico?

6.

Produtos e processos so desenvolvidos de forma simultnea?

Nveis de Alinhamento Enxuto

Prtica Enxuta
6.

Integrar o
desenvolvimento de
produtos e processos.

Derrubar feudos
funcionais permite
que a comunicao
seja corrente e que o
valor flua.

Nvel 1

Nvel 2

Nvel 3

Nvel 4

Nvel 5

O desenvolvimento realizado
numa organizao funcional, e
estas reas funcionais no so
integradas por meio de um
time interfuncional.

Times Integrados de Produtos

ou desenvolvimento
multidisciplinar so utilizados
numa pequena extenso.

Times Integrados de Produtos

ou desenvolvimento
multidisciplinar so utilizados e
forma intensiva, e mtricas so
estabelecidas a avaliao do
processo.

Times Integrados de Produtos

ou desenvolvimento
multidisciplinar so utilizados e
forma intensiva, e mtricas so
estabelecidas a avaliao e
melhoria do processo.

As definies do produto e do
processo so integradas de
forma contnua, tanto
internamente, quanto atravs
dos stakeholders do incio e do
final do processo.

Estado

Estado

Estado

Estado

Estado

Estado

Estado

Estado

Estado

Estado

Atual

desejado

Atual

desejado

Atual

desejado

Atual

desejado

Atual

desejado

Indicador Enxuto

Recursos e habilidades so balanceados entre os projetos e programas. H um extensivo compartilhamento do conhecimento.

Informaes de projeto so liberadas no momento e na forma adequada, e atinge os requisitos dos processos subseqentes.

Na sua empresa existe um entendimento amplo das diferenas. Estas diferenas so armazenadas de forma a servir de base para a construo de um
rico time multidisciplinar. As diferenas de pensamento so encorajadas, e freqentemente levam a resultados criativos.

Escrever alguns exemplos

como evidncia do Estado
Atual

Escreva alguns exemplos de

oportunidades de melhorias

234

236

ANEXO B

ROTEIRO DA ENTREVISTA

237

Princpios Enxutos no Processo de desenvolvimento de Produtos

Guia para entrevista - Avaliao da Aplicao da Metodologia
Esta entrevista foi elaborada especificamente para avaliar a adequao dos passos
utilizados na metodologia proposta para aplicao dos princpios enxutos no PDP.
Este estudo parte de uma pesquisa realizada para o programa de doutoramento em
Engenharia de Produo da Escola Politcnica da USP. A sua participao
fundamental para o alcance dos objetivos deste estudo. Sentindo-se desconfortvel
para responder qualquer pergunta, por favor decline de faz.
1. A metodologia abrange todas as reas do processo de desenvolvimento de
produtos?
2.O nvel de detalhamento da metodologia (fases, processos, passos e etapas)
adequado para o seu entendimento e execuo?
3. A estrutura da metodologia (elaborada graficamente) adequada para sua
representao?
4. A metodologia abrange os domnios de conhecimento necessrios para o D.P.?
5. A metodologia de fcil entendimento?
6. A metodologia suporta a aplicao em diferentes tipos de D.P.?
7. A metodologia permite a incorporao de diferentes tcnicas e ferramentas de
melhoria?
8. A metodologia suporta alteraes em sua estrutura, de forma a tornar-se mais
adequada para a realizao das melhorias necessrias?
9. A metodologia apresenta consistncia de informao, ou seja, concordncia
aproximada com os resultado obtidos e cada passo, etapa ou fase?
10. A metodologia permite sua expanso, ou seja, a definio de novas atividades
no previstas anteriormente?
11. A metodologia contm toda a informao necessria para a obteno das
melhorias almejadas?

238

BIBLIOGRAFIA

ABERNATHY W.J. e CLARK, K.B. Inovation: mapping the winds of creative

destruction. Research Policy 14, pag. 3-32. Elsevier Science Publishers B. V.
North-Holland: 1985.
AMARAL, Joo A. A.; SBRAGIO, Ricardo. A dinmica do projeto: uma viso
sistmica das conseqncias de aes gerenciais. So Paulo: Scortecci, 2003.
ARINEZ, J. An Equipment Design Approach for Achieving Manufacturing System
Design Requirements, Thesis (Philosophy Doctor). Cambridge: Massachusetts
Institute of Technology, 2000.
BAKKILA, Michelle V. A system dynamics analyses of the interaction between the
U.S. government and the defense aerospace industry. Thesis (Master in
Science) in aeronautics and astronautics. Massachusetts Institute of
Technology, Cambridge, 1996.
BAUCH, C. Lean Product Development: making waste transparent. Cambridge :
Massachusetts Institute of Technology, 2004.
BERNARDES, R. Embraer: elos entre Estado e mercado. So Paulo: Hucitec
Fapesp, 2000.
BERNSTEIN, Joshua I. Design methods in the aerospace industry. looking for
evidence of set-based practices. Thesis (Master in Science) in technology and
policy: Massachusetts Institute of Technology. Cambridge: 1998.
BOCANEGRA, C. Design and Implementation of Product Development Design
Decomposition (PD3), Thesis (Master in Science), Massachusetts Institute of
Technology: Cambridge, 2001.
BROW, S.L. EISENHARDT, K.M. Product development: past research, present
findings, and future directions. Academy Management Review: 20, p. 343-378,
1995.
BROWNING, Tyson R. Systematic IPT integration in lean development programs.
Thesis (Master in science) in aeronautics and astronautics: Massachusetts
Institute of Technology. Cambridge, 1996.
___________, Tyson R. Mechanisms for interteam integration: findings from five
case studies. Proceedings of the seventh annual international symposium of
INCOSE: Los Angeles, Aug. 3-7, p. 649-656, 1997.a.

239

___________, Tyson R. Exploring integrative mechanisms with view towards design

for integration. Fourth ISPE International conference on concurrent
engineering: research and applications, Aug. 20-22, p. 83-90, 1997.b.
___________, Tyson R. Sources of schedule risk in complex system development.
Proceedings of the eighth annual international symposium of INCOSE,
Vancouver: July 26-30, p. 649-656, 1998.a.
___________, Tyson R. Modeling and Analyzing Cost, Schedule, and Performance
in Complex System Product Development. Thesis (Philosophy Doctor),
Massachusetts Institute of Technology: Cambridge, 1998.b.
___________, Tyson R. "Complex System Product Development: Adding Value by
Creating Information and Reducing Risk" Lean Aerospace Initiative Report
WP99-03. MIT. Cambridge, 2001.
CAMARGO Jr., A. S. et. al. Desenvolvimento de Produtos e processos: um Estudo
de Caso do ERJ 170. Mimeo. FEA USP: So Paulo, 2000.
CARVALHO, Marly M. Medindo o sigma do processo. In: ROTONDARO, R.G.
Seis sigma: estratgia gerencial para melhoria de processos, produtos e
servios. Atlas: So Paulo, 2002. p. 164-176.
CHASE, James P. Value Creation in the Product Development Process. Thesis
(master in science). Massachusetts Institute of Technology: Cambridge, 2001.
CLARK, K. FIJIMOTO, C. Product Development Performance: strategy,
organization and management in the world auto industry: HBS Press, 1991.
CLAUSING, D. Total Quality Development: A Step-by-Step Guide to World-Class
Concurrent Engineering, ASME Press, New York, NY: 1994.
COCHRAN, David S. REYNAL, Vicente A. Axiomatic design of manufacturing
systems. Lean aerospace initiative. Center for technology, policy, and industrial
development. Massachusetts Institute of Technology. Cambridge: 1996.
COCHRAN, D. et. al. Decision Support for Manufacturing System Design
Combining a Decomposition Methodology with Procedural Manufacturing
System Design, Proceedings of the 3rd World Congress on Intelligent
Manufacturing Processes and Systems: Boston, Jun.28-30, 2000d.
CONDIT, Philip M. "Performance, Process, and Value: Commercial Aircraft Design
in the 21st Century." Speech at the World Aviation Congress and Exposition.
Los Angeles. October 22, 1996.

240

COOK, Cynthia R. Production networks revisited: causes and consequences of

supplier and customer linkages in metal manufacturing sector. Thesis (Doctor
of philosophy) Sociology. Harvard University. Cambridge: 1999.
COOPER, R. T. A process model for industrial new product development. IEEE
Transactions on Engineering Management, v. EM-30, n. 1, feb. 1983.
COOPER, Donald R. EMORY, C. W. Business Research Methods. The McGrawHill: 1995.
CSILLAG, Joo M. Anlise de valor. So Paulo: Atlas, 1995.
DONAVAN, J. TULLY, R. WORTMAN, B. The value Enterprise: strategies for
building a value-based organization. McGraw-Hill: Toronto, 1998.
DOUGLAS III, Freddie. Lean principles implementation in the program preparation
phase. Thesis (Master in Science) in engineering and business management.
Massachusetts Institute of Technology. Cambridge: 2002.
DUDA, J. A Decomposition-Based Approach to Linking Strategy, Performance
Measurement, and Manufacturing System Design, Thesis (Philosophy Doctor),
Massachusetts Institute of Technology: Cambridge, 2000.
EISENNHARDT, K. M. Building Theory from case study research. Academy of
Management Review. V. 14, n. 4, p. 532-550, 1989.
EPPINGER, S. D. at. al. A model-based method for organizing in product
development. Research Engrg. Design-Theory Appl. And Concurrent Engrg.
v.6, p. 1-13: 1994.
EPPINGER, Steven D. Three Views of Product Complexity. Presented at the LAI
Plenary. Cambridge. Abr. 2001.
FABRYCKY, W.J. Engineering Economy. Pearson Education: New Jersey, 1989.
FAYOL, H. Administrao industrial e geral. Atlas: So Paulo, 1950.
FERNANDES, Pradeep. A framework for a strategy driven manufacturing system
design in aerospace environment: design beyond factory floor. Thesis (Master
in Science) in aeronautics and astronautics: Massachusetts Institute of
Technology. Cambridge, 2001.
FERREIRA, Aurlio B. H. Dicionrio Aurlio Eletrnico v. 1.2. Nova Fronteira:
1993.
FREEMAN R E. Strategic Management: A Stakeholder Perspective. Pittman, 1984.

241

GARBO, Samuel P. Technology development and business strategy: a changing

environment impacts practices. Thesis (Master in Science) in the management
of technology. Massachusetts Institute of Technology: Cambridge, 1997.
GERWIN, D. BARROWMAN, Nicholas J. An evaluation of research on integrated
product development. Management Science. v. 48, n. 7, p. 938-953, 2002.
GONZALEZ J. F., SARAMA T. J. Lean methods above the manufacturing floor in
an military aerospace program; Thesis (S.M.), Sloan School of Management MIT, 1999.
GRIFFIN, A. PAGE, Albert L. PDMA success measurement project: recommended
measures for product development success and failure. Journal of Product
Innovation Management: v. 13, p. 478- 496, 1996.
GRIFFIN, A. PDMA Research on New Product Development Practices. Journal of
Product Innovation Management: 1997.
HAYES, Robert H. WHEELWRIGHT, S. C. Restoring our competitive edge. New
York, John Wiley e Sons, 1984.
HAQUE, B. Overview of the Lean Product Development (LPD) Research Project:
Warwick Manufacturing Group, University of Warwick, US LAI LPD
Workshop. Los Angeles, Sept. 2000.
HOPPES, John C. Lean manufacturing practices in the defense aircraft industry.
Thesis (Master in Science) in management. Massachusetts Institute of
Technology: Cambridge: 1995.
HOULT, David P. Methods of integrating design and cost information to achieve
enhanced manufacturing cost/performance trade-offs. Report. Massachusetts
Institute of Technology: Cambridge, s/d.
KAPLAN, R. NORTON, David P. The balanced scoredcard measurement that
drive performance. Harvard Business Review. Jan.- feb, p. 71-79, 1992.
KEEN, Peter G. The process edge: creating value where it counts. Harvard Business
School Press, 1997.
KERZNER, Harold. Project management: a sistems approach to planning,
scheduling, and controling. 6. ed. New York: John Wiley e Sons, 1998.
KILPATRICK, Auston M. Lean manufacturing principles: a comprehensive
framework for improving production efficiency. Thesis (Master in Science) in
mechanical engineering. Massachusetts Institute of Technology: Cambridge,
1997.

242

KIM, Y-S. et. al. Xerox docuprint N4025: final project report in the integrating the
lean enterprise class, Massachusetts Institute of Technology: Cambridge: 2000.
_________. A decomposition-based approach for the integration of product
development and manufacturing System design. Thesis (Doctor of Philosophy)
in mechanical engineering. MIT: Cambridge, 2002.
KRISHNAN, V. ULRICH, Karl T. Product Development Decisions: a review of the
literature. Management Science. v.47, n.1, p.1-21: 2001.
KIRTLEY, Aaron L. Fostering innovation across aerospace supplier networks.
Thesis (Master in Science) technology and policy. Massachusetts Institute of
Technology: Cambridge, 2002.
LAI Lean Aerospace Initiative. Output from the 1998 product development value
stream workshop: A Framework for Understanding Information Flow in the
Product Development Process. Massachusetts Institute of Technology:
Cambridge,Working Paper Series, WP01-01, Oct. 2001.
LESAT - The lean enterprise self assessment Tool. Massachusetts Institute of
Technology. Cambridge, 2001.
LENZ, R. COCHRAN, D. The application of axiomatic design to the design of the
product development organization Proceedings of the First International
Conference on Axiomatic Design: Cambridge Jun. 21-23, 2000.
LEONARD-BARTON, D. A dual methodology for case studies: sinergistic use of
longitudinal single site with replicated multiple sites. Organizational Science,
v.1, n. 3, p. 248-266, 1990.
LEEDY, P. ORMROD, J. Practical research: planning and design, seventh edition:
Prentice Hall, Upper Saddle River, 2001.
LINCK, J. A decomposition-based approach for manufacturing system design,
Thesis (Philosophy Doctor), Massachusetts Institute of Technology: Cambridge,
2001.
LIU, B. Product development processes and their importance to organizational
capabilities. Thesis (Philosophy Doctor). System Design and Management
Program. MIT. 2003.
MACHADO, Marcio C. A qualidade na indstria aeronutica, in Oliveira, O. J.
(org.) Gesto da qualidade: tpicos avanados. Thonsom Learning: So Paulo,
2004.

243

____________. O Gerenciamento do Processo de Desenvolvimento de Produtos

Com Foco na Criao de Valor. In: 4th International Conference
Iberoamerican Academy of Management. Lisboa, 2005.
____________. Criao de Valor no Processo de Desenvolvimento de Produtos:
uma Avaliao da Aplicabilidade dos Princpios e Prticas Enxutas. In: XI
Seminrio Latino-Iberoamericano de Gestin Tecnolgica ALTEC 2005.
Salvador, 2005.
MARKISH, Jacob. Valuation techniques for commercial aircraft program design.
Thesis (Master in Science) in aeronautics and astronautics. Massachusetts
Institute of Technology: Cambridge, 2002.
McMANUS, H. HARMON, E. Lean Product Development Definitions and
Concepts. presentation at the LAI Plenary. MIT and Northrop Grumman.
Cambridge. Abr. 2001.
McMANUS, Hugh, MILLARD, Richard L. Value stream analysis and mapping for
product development. Proceedings of the international council of the
aeronautical sciences. 23 ICAS Congress. Toronto: 2002. pp 6103.1-6103.10.
McNUTT, R. Reducing DoD product development Time: the role of the schedule
development process. Thesis (Philosophy Doctor). MIT: Cambridge, 1998.
MILLARD, R. Value stream analysis and mapping for product development. Thesis
(Master in Science), Massachusetts Institute of Technology: Cambridge, 2001.
MIYAKI, Dario I. Melhorando o processo: seis sigma e sistema de produo lean.
In: ROTONDARO, R.G. Seis sigma: estratgia gerencial para melhoria de
processos, produtos e servios. Atlas: So Paulo, 2002. p. 264-293.
MEYER, M. H. LEHNERD, A. P. The power of product platforms. The Free Press:
New York, 1997.
MILES, M., HUBERMAN, M. Qualitative data analysis, SAG Publications, Beverly
Hills: 1984.
MORGAN, James M. High performance product development: a systems approach
to a lean product development process. Thesis (Phd) in industrial and
operations engineering. The University of Michigan: 2002.
MURMAN, E. et. al.. Value in Aerospace Industry. Palgrave: New York, 2002.
MURMAN, E. WALTON, M. REBENTISCH, E. Challenges in the better, faster,
cheaper era of aeronautical design, engineering and manufacturing. Lean
aerospace initiative. Center for technology, policy, and industrial development.
Massachusetts Institute of Technology: Cambridge, 2000.

244

NASCIMENTO P. T., VASCONCELOS, E. e SOUZA P. C. A estrutura fractal

no desenvolvimento do jato regional da Embraer ERJ 170. No publicado: So
Paulo, s.d.
PARLETT, M., HAMILTON, D. Evaluation as illumination: a new approach to the
study of innovatory programs, in Glass, G. (Coords.), Evaluation studies
review annual, Vol. 1. Sage, Beverly Hills, 1976.
PATTON, M. Utilization-focused evaluation. SAGE publications: Beverly Hills,
1978.
PAHL, G. BEITZ, W. Engineering design, 2. ed. Springer-Verlag: London,1995.
PERRONS, Robert K. Make-buy decisions in the U.S. aircraft industry. Thesis
(Master in Science) in technology and policy. Massachusetts Institute of
Technology: Cambridge, 1997.
PMI, Project Management Institute. A guide to the project management body of
knowledge (PMBOK) Maryland: Project Management Institute. Inc, 2001.
PONPONI, Roberta A. Organizational structures for technology transition:
rethinking information flow in the integrated product team. Thesis (Doctor of
Philosophy) in technology, management and policy. Massachusetts Institute of
Technology: Cambridge, 1998.
QUIVY, Raymond. CAMPENHOUDT, Luc Van. Manual de investigaes em
cincias sociais. 2. ed. Lisboa: Gradiva, 1998.
REICHARDT, C. COOK, T. Beyond qualitative versus quantitative methods, in
Cook, T. and Reichardt, C. (eds), Qualitative and Quantitative Methods in
Evaluation Research, SAGE publications: Beverly Hills, 1979.
REYNAL, Vicente A. COCHRAN, David S. Understanding lean manufacturing
according to axiomatic design. Lean aerospace initiative. Center for
technology, policy, and industrial development. Massachusetts Institute of
Technology: Cambridge: 1996.
ROBSON, C. Real world research: a resource for social scientists and practitionerresearchers, Blackwell, Cambridge:1993.
ROMAN, Marco Antnio. Lean aerospace initiative electronic sector study. Thesis
(Master in Science) in management. Massachusetts Institute of Technology:
Cambridge, 2000.

245

ROMANO, Leonardo N. Modelo de referncia para o processo de desenvolvimento

de mquinas agrcolas. Tese (Doutorado) Engenharia Mecnica. Universidade
Federal de Santa Catarina: Santa Catarina, 2003.
ROTHER, M. e SHOOK J., Learning To See: Value Stream Mapping to Add Value
and Eliminate Muda, Lean Enterprise Institute: Brookline, MA, 1999.
SALZMAN, Rhonda A. Manufacturing system design: flexible manufacturing
systems and value stream mapping. Thesis (Master in Science) in mechanical
engineering. Massachusetts Institute of Technology: Cambridge, 2002.
SEITZ, Thomas A. Lean aerospace integration: a new framework for small
businesses. Thesis (Master in Science) in engineering and technology.
Massachusetts Institute of Technology: Cambridge, 2003.
SHILLITO, M. L. DeMARLE, D. J. Value: its measurement, design and
management. John Wiley and Sons: New York, 1992.
SLACK, R. A. The application of lean principles to the military aerospace product
development process; Thesis (Master in Science). Massachusetts Institute of
Technology: Cambridge, 1998.
SPEAR, S. BOWEN, K.: Decoding the DNA of the Toyota production system.
Harvard Business Review Article: Boston, Sept Oct 1999.
SOBEK II, D.K. Principles that shape product development systems: a ToyotaChrysler comparison. 1997. Thesis (Philosophy Doctor) Industrial and
Operations Engineering, University of Michigan, 1997.
SOBEK II, D. K.; WARD, Allen C.; Liker, Jeffrey K. Toyota's Principles of SetBased Concurrent Engineering; MIT Sloan management review. Vol. 40, No.
2, pp. 6783, 1999.
STANKE, A. A framework for achieving lifecycle value in product development.
Thesis (Master in Science). Massachusetts Institute of Technology: Cambridge,
2001.
STANKE, A. MURMAN, E. A framework for achieving lifecycle value in aerospace
product development. International Council of aeronautical sciences congress,
2002.
SUH, N. Axiomatic Design: advances and applications. Oxford University Press:
New York, 2001.
TATA, Melissa M. THORNTON, Anna C. Process capability data-based usage in
industry: myth vs. reality. MIT: Cambridge, s/d.

246

TATE, D. A Roadmap for Decomposition: Activities, Theories, and Tools for System
Design, Thesis (Doctor of Philosophy), Massachusetts Institute of Technology,
Cambridge, 1999.
TOLEDO, Nilton N. Metodologia para o desenvolvimento de produtos a serem
fabricados em srie. Tese (Doutorado). Escola Politcnica da Universidade de
So Paulo: So Paulo, 1994.
THOMSON, Paul M. Implementing a team-based organization in a unionized
manufacturing company to improve operating efficiency. Thesis (Master in
Science) in management. Massachusetts Institute of Technology: Cambridge,
1997.
TRISCHLER, William E., Understanding and Applying Value-Added Assessment:
Eliminating Business Process Waste, ASQC Quality Press: Milwaukee,
Wisconsin, 1996.
ULRICH, K. Introduction to de special issue on design and development.
Management Science, v. 47, n. 1, p. v-vi, 2001.
ULRICH, K., EPPINGER, S. Product Design and Development, Irwin McGraw-Hill,
New York, 2000.
VAUGHN, Amanda F. A holistic approach to manufacturing system design in the
defense aerospace industry. Thesis (Master in Science) in aeronautics and
astronautics. Massachusetts Institute of Technology: Cambridge, 2002.
VERSCHUREN P. DOOREWAARD H. Designing a research project. Publisher
Lemma Utrecht: 1999.
VOSS, C.; TSIKRIKTSIS, N.; FROHLICH M.; Case research for operations
management. International journal of operations and production management.
Vol. 22. N. 2. Manchester: 2002.
WARD, A.; CRISTIANO. SOBEK II.; The Second Toyota Paradox: how delaying
decisions can make better car faster. Sloan Management Review 1995
WARD, A. C. Value Stream Mapping for Product and Process Development; Ward
Synthesis, Michigan, 2000.
WACKER, J.G. A definition of theory: research guidelines for different theory
building research methods in operations management. Journal of Operations
Management. v. 16 p. 361-385, 1998.

247

WEI, Yu-Feng. Concurrent design for optimal quality and cycle time. Thesis (Doctor
of Philosophy) in mechanical engineering. Massachusetts Institute of
Technology: Cambridge, 2001.
WOMACK, J. JONES, D. e ROOS. A mquina que mudou o mundo. Campus: Rio
de Janeiro, 1996.
WOMACK, J. JONES, D. Lean Thinking: banish waste and create wealth in your
corporation. Free Press: New York, 2003.
WHEELWRIGHT, S. e CLARK, K. Revolutionizing product development: quantum
leaps in speed, efficiency and quality. 1992.
YIN, R., Case study research: design and methods, Sage Publications, Beverly Hills,
CA: 1994.
YU, Abraham Sin O. Estratgia de testes no desenvolvimento de produtos: um
estudo das dependncias probabilsticas. Tese (Livre-Docncia) Administrao.
Universidade de So Paulo: So Paulo, 2003.