Dissertação para Aplicação de Um Sistema PLM

Universidade de So Paulo
Escola de Engenharia de So Carlos
Utilizao de sistemas PDM em ambientes de

engenharia simultnea: o caso de uma implantao em
uma montadora de veculos pesados
Rogerio Omokawa
Dissertao apresentada Escola de

Engenharia de So Carlos, da Universidade
de So Paulo, como parte dos requisitos para
obteno do ttulo de Mestre em Engenharia
Mecnica.
ORIENTADOR: Prof. Dr. Henrique Rozenfeld
So Carlos
1999
S se pode alcanar um grande

xito quando nos mantemos fiis
a ns mesmos
Friederich Nietzsche
Rogerio Omokawa
Aos meus pais, pela vida e ao

meu irmo e a Andria, por
terem feito de mim uma pessoa
melhor.
Rogerio Omokawa
AGRADECIMENTOS
Ao Professor Henrique pela oportunidade, pela orientao e pelas aulas de
vida
Aos companheiros do Grupo de Engenharia Integrada: Adriana, Bianca,
Cristiano, Daniel Capaldo, Daniel Dupas, Edmundo, Eduardo Chup, Fernandinho,
Francis, Lucas, Lus, Marcel, Marcelo, Renato, Srgio e Vander, pelas batalhas que
vencemos.
A todo pessoal do NUMA (Ncleo de Manufatura avanada).
A todos do HPTD principalmente ao Dr. Baake, pela oportunidade de
desenvolver o trabalho na prtica, Leni e ao Srgio pelo apoio e auxlio durante a
realizao do estudo de caso.
s pessoas que responderam ao questionrio e que auxiliaram no
desenvolvimento deste trabalho, principalmente ao Lino pela ateno e interesse.
Ao Enio da Embraer e ao Adalberto da Datavision, pelo auxlio prestado no
incio deste trabalho.
Ao meus tios Laura e Tadao pelo apoio antes e durante a realizao deste
trabalho.
Ao Departamento de Engenharia pelo auxlio e ateno.
FAPESP (Fundao de Amparo pesquisa do Estado de So Paulo) pela
bolsa de estudo concedida.
A todos que, de uma forma ou de outra, contriburam neste trabalho e que no
foram citados.
Meu muito obrigado.
Rogerio Omokawa
SUMRIO
LISTA DE FIGURAS .................................................................................... I

LISTA DE TABELAS................................................................................. III
LISTA DE ABREVIATURAS E SIGLAS .................................................. V
RESUMO ....................................................................................................VII
ABSTRACT .............................................................................................. VIII
1. INTRODUO ..........................................................................................1
1.1. JUSTIFICATIVA........................................................................................2
1.2. OBJETIVOS .............................................................................................2
1.3. PERGUNTAS DA PESQUISA ......................................................................3
1.4. MTODO .................................................................................................3
1.5. LIMITAES DA PESQUISA......................................................................5
1.6. ETAPAS GERAIS DO TRABALHO ..............................................................6
1.6.1. Reviso Geral da Bibliografia ........................................................6
1.6.2. Desenvolvimento dos Objetivos e do Mtodo................................6
1.6.3. Reviso Bibliogrfica Detalhada ....................................................7
1.6.4. Desenvolvimento da Forma de Coleta dos Dados..........................7
1.6.5. Escolha do Caso .............................................................................8
1.6.6. Coleta de Dados..............................................................................8
1.6.7. Apresentao e Anlise dos Dados.................................................9
2. O DESENVOLVIMENTO DE PRODUTOS E A ENGENHARIA
SIMULTNEA.........................................................................................................10
2.1. A ABORDAGEM TRADICIONAL (SEQENCIAL) DE DESENVOLVIMENTO
DE PRODUTOS E SEUS PROBLEMAS ..........................................................................10
2.2. FASES DO DESENVOLVIMENTO DE PRODUTOS ......................................12
2.3. A ENGENHARIA SIMULTNEA E A CLASSIFICAO DOS ELEMENTOS QUE
A SUPORTAM ..........................................................................................................18
2.3.1. A Classificao Segundo SYAN (1994) ......................................18
2.3.1.1. Processos...............................................................................19
2.3.1.2. Ferramentas Computacionais ...............................................25
2.3.1.3. Tcnicas Formais ..................................................................26
2.3.1.4. Mtodos de Troca de Dados..................................................27
2.3.2. A Classificao Segundo CARTER & BAKER (1992)...............27
Rogerio Omokawa
2.3.2.1. A Dimenso da Organizao ................................................28

2.3.2.2. A Dimenso da Infra-estrutura da Comunicao .................29
2.3.2.3. A Dimenso dos Requisitos ...................................................29
2.3.2.4. A Dimenso do Processo de Desenvolvimento de Produtos .30
2.3.3. Definies de Engenharia Simultnea..........................................31
2.4. O DESENVOLVIMENTO DE PRODUTOS COMO PROCESSO.......................32
2.5. NECESSIDADES DE GERENCIAMENTO DE DADOS EM UM AMBIENTE DE
ENGENHARIA SIMULTNEA .....................................................................................35
3. GERENCIAMENTO DE DADOS DE PRODUTO ..............................39
3.1. HISTRICO ...........................................................................................39
3.2. TERMINOLOGIA ....................................................................................41
3.3. FUNCIONALIDADES DE SISTEMAS PDM................................................44
3.3.1. Cofre de Dados .........................................................................45
3.3.2. Fluxo de Trabalho e Gerenciamento de Processos.......................47
3.3.3. Gerenciamento da Estrutura de Produto/Gerenciamento de
Configurao ......................................................................................................48
3.3.4. Classificao e Recuperao ........................................................51
3.3.5. Gerenciamento de Projetos...........................................................53
3.3.6. Comunicao e Notificao..........................................................53
3.3.7. Transporte de Dados.....................................................................54
3.3.8. Converso de Dados .....................................................................55
3.3.9. Servios de Visualizao e Comentrios (markup)......................57
3.3.10. Administrao.............................................................................58
3.4. MERCADO DE SISTEMAS PDM .............................................................58
3.5. ESTRATGIAS DE IMPLANTAO A PARTIR DE COMPLEXIDADES
................................................................................................................63
3.5.1. Implantao por Projeto ...............................................................64
3.5.2. Foco em uma Funcionalidade do Sistema PDM ..........................66
3.5.3. Introduo de um Arquivo Central...............................................67
TCNICAS
3.6. BENEFCIOS DA IMPLANTAO DE SISTEMAS PDM..............................67

4. CARACTERIZAO DO AMBIENTE PESQUISADO EM
RELAO ENGENHARIA SIMULTNEA ...................................................70
4.1. ESCOLHA DO CASO ...............................................................................70
4.2. DADOS GERAIS DA EMPRESA E DO AMBIENTE DE DESENVOLVIMENTO
DE PRODUTOS ..........................................................................................................71
4.3. CARACTERIZAO DO AMBIENTE EM RELAO AO GRAU DE
UTILIZAO DE ENGENHARIA SIMULTNEA ...........................................................72
4.3.1. A Pesquisa Realizada ...................................................................72
4.3.2. Aplicao da Metodologia e Resultados ......................................74
Rogerio Omokawa
5. A CARACTERIZAO DA IMPLANTAO DO SISTEMA PDM

NO AMBIENTE DE ENGENHARIA SIMULTNEA ........................................80
5.1. REALIZAO DA PESQUISA DE CAMPO .................................................80
5.2. APRESENTAO DOS DADOS ................................................................81
5.2.1. Deciso da Implantao e Escolha do Sistema.............................81
5.2.2. Estratgia de Implantao e Metas ...............................................82
5.2.3. Caractersticas do Sistema PDM ..................................................83
5.2.3.1. Cofre de Dados e Gerenciamento de Documentos ...........84
5.2.3.2. Fluxo de Trabalho e Gerenciamento de Processos...............84
5.2.3.3. Gerenciamento da Estrutura de Produto ..............................85
5.2.3.4. Classificao e Recuperao ................................................85
5.2.3.5. Gerenciamento de Projetos ...................................................85
5.2.3.6. Comunicao e Notificao ..................................................85
5.2.3.7. Transporte de Dados .............................................................85
5.2.3.8. Converso de Dados .............................................................86
5.2.3.9. Servios de Visualizao e Comentrios (markup)...............86
5.2.3.10. Administrao .....................................................................86
5.2.3.11. Inte.......................................................................................86
5.2.4. Requisitos de Gerenciamento de Dados e Funcionalidades que os
Suprem................................................................................................................87
5.2.5. Dificuldades Encontradas e Benefcios Obtidos ..........................90
5.2.5.1. Infra Estrutura.......................................................................90
5.2.5.2. Sistema...................................................................................90
5.2.5.3. Usurio..................................................................................91
5.2.5.4. Comunicao entre o Time de Implantao e o Time de
Desenvolvimento ............................................................................................91
5.2.5.5. Vantagens ..............................................................................92
5.2.6. Situao Atual e Prximos Passos................................................92
6. CONCLUSES E TRABALHOS FUTUROS.......................................94
ANEXOS .......................................................................................................99
ANEXO 1: QUESTIONRIO DE AVALIAO DE UTILIZAO DE ENGENHARIA
SIMULTNEA ...........................................................................................................99
ANEXO 2: ROTEIRO DE ENTREVISTA PARA A CARACTERIZAO DA
IMPLANTAO DO SISTEMA ..................................................................................122
ANEXO 3: RESULTADOS DA APLICAO DO QUESTIONRIO DE AVALIAO
DE UTILIZAO DE ENGENHARIA SIMULTNEA ....................................................127
REFERNCIAS BIBLIOGRFICAS .....................................................147
OBRAS CONSULTADAS .........................................................................152
Rogerio Omokawa
LISTA DE FIGURAS
Figura 1: Caractersticas do Desenvolvimento de Produtos.......................................11

Figura 2: Fases do Desenvolvimento de Produtos .....................................................13
Figura 3: Fases do Processo de Desenvolvimento de Produtos .................................14
Figura 4: Composio de um Time de Desenvolvimento de Produtos Multidisciplinar
............................................................................................................................19
Figura 5: Organizao Matricial.................................................................................20
Figura 6: Estrutura Funcional.....................................................................................21
Figura 7: Estrutura de Gerente de Produtos Peso Leve .......................................22
Figura 8: Estrutura de Gerente Peso Pesado ........................................................23
Figura 9: Estrutura de Time de Execuo de Projetos ...............................................24
Figura 10: Utilizao de Tcnicas no Processo de Desenvolvimento de Produtos....26
Figura 11: Definio de Processo de Negcio ...........................................................33
Figura 12: Viso Holstica da Empresa ......................................................................34
Figura 13: Product Data Management........................................................................42
Figura 14: reas Funcionais de PDM e EDM ........................................................43
Figura 15: Funcionamento do Cofre de Dados .......................................................46
Figura 16: Fluxo de Trabalho de Aprovao de Desenhos ........................................47
Figura 17: Viso Funcional x Viso de Montagem....................................................49
Figura 18: Estrutura do Produto - Relacionamento entre Peas.................................50
Figura 19: Estrutura do Produto - Relacionamento Pea - Documento .....................50
Rogerio Omokawa
ii
Figura 20: Combinao de Todas as Formas de Estrutura de Produto.......................51

Figura 21: Sistema de Classificao de 3 Nveis........................................................52
Figura 22: Transporte de Dados .................................................................................55
Figura 23: Desenho do CAD com Comentrio ..........................................................57
Figura 24: Mercado Mundial de Sistemas PDM ........................................................59
Figura 25: Nveis de Complexidade de Sistemas PDM .............................................64
Figura 26: Economia em Custo de Trabalho Direto...................................................68
Figura 27: Mapa das Dimenses ................................................................................75
Figura 28: Mapa das Dimenses com Transferncia das Respostas Positivas...........76
Figura 29: Mapa das Dimenses Situao Atual.....................................................77
Figura 30: Mapa das Dimenses Situao Atual x Situao Ideal I........................78
Figura 31: Mapa das Dimenses Situao Atual x Situao Ideal II ......................79
Rogerio Omokawa
iii
LISTA DE TABELAS
Tabela 1: Participao de Mercado das Principais Empresas Produtoras de Sistemas

PDM em 1996.....................................................................................................60
PDM em 1996.....................................................................................................61
PDM em 1997.....................................................................................................62
Tabela 4: Funcionalidades x Requisitos .....................................................................89
Tabela 5: Resultado do Nvel Atual do Fator-Chave Integrao dos Times............128
Tabela 6: Resultado do Nvel Atual do Fator-Chave Autoridade ............................129
Tabela 7: Resultado do Nvel Atual do Fator-Chave Treinamento e Educao.......130
Tabela 8: Resultado do Nvel Atual do Fator-Chave Suporte de Automao..........131
Tabela 9: Resultado do Nvel Atual do Fator-Chave Gerenciamento do Produto ...132
Tabela 10: Resultado do Nvel Atual do Fator-Chave Dados Sobre o Produto .......133
Tabela 11: Resultado do Nvel Atual do Fator-Chave Feedback.............................134
Tabela 12: Resultado do Nvel Atual do Fator-Chave Definio de Requisitos......135
Tabela 13: Resultado do Nvel Atual do Fator-Chave Metodologia de Planejamento
..........................................................................................................................136
Tabela 14: Resultado do Nvel Atual do Fator-Chave Perspectiva de Planejamento
..........................................................................................................................137
Tabela 15: Resultado do Nvel Atual do Fator-Chave Validao ............................138
Tabela 16: Resultado do Nvel Atual do Fator-Chave Normas................................139
Tabela 17: Resultado do Nvel Atual do Fator-Chave Banco de Dados dos
Componentes ....................................................................................................140
Rogerio Omokawa
iv
Tabela 18: Resultado do Nvel Atual do Fator-Chave Processo de Projeto.............141

Tabela 19: Resultado do Nvel Atual do Fator-Chave Otimizao..........................142
Tabela 20: Resultado do Nvel Ideal da Dimenso Organizao .............................143
Tabela 21: Resultado do Nvel Ideal da Dimenso Infra-Estrutura de Comunicao
..........................................................................................................................144
Tabela 22: Resultado do Nvel Ideal da Dimenso Requisitos ................................145
Tabela 23: Resultado do Nvel Ideal da Dimenso Desenvolvimento de Produtos .146
Rogerio Omokawa
LISTA DE ABREVIATURAS E SIGLAS
APQP:
Advanced Product Quality Planning
CAD:
Computer Aided Design
CAE:
Computer Aided Engineering
CAM
Computer Aided Manufacturing
CAPP:
Computer Aided Process Planning
DFMA:
Design For Manufacturing and Assembly
EDM:
Engineering Data Management, Engineering Document Management,

Electronic Data Management, Electronic Document Management
ERP:
Enterprise Resource Planning
ES:
Engenharia Simultnea
FMEA:
Failure Mode and Effect Analysis
IGES:
Initial Graphics Exchange Specification
ISO9000: International Organization for Standardization, srie 9000

JIT:
Just In Time
PDES:
Product Data Exchange System
PDM:
Product Data Management

Rogerio Omokawa
vi
PDT:
Product Development Team
QFD:
Quality Function Deployment
QS9000:
Quality System, srie 9000
SET:
Standard dEchange et de Transfert
STEP:
Standard for the Exchange of Product Model Data
DXF
Data eXchange File
HPGL
Hewlett-Packard Graphics Language
TIFF
Tagged Image File Format
VDA-FS:
Verband der Deutschen Automobilindustrie-FlchenSchnittstelle
Rogerio Omokawa
vii
RESUMO
OMOKAWA, R. (1999). Utilizao de sistemas PDM em ambientes de engenharia

simultnea: o caso de uma implantao em uma montadora de veculos pesados.
So Carlos. 154p. Dissertao (Mestrado) - Escola de Engenharia de So Carlos,
Universidade de So Paulo.
A engenharia simultnea e os sistemas de gerenciamento de dados de produto

(PDM), apesar de serem uma ajuda preciosa para que as empresas enfrentem as
novas condies de sobrevivncia no mercado atual, no so muito conhecidos.
Alm disso, existem poucos trabalhos cientficos relacionados implantao e ao
auxlio deste tipo sistema no gerenciamento de dados em ambiente de engenharia
simultnea. Neste trabalho procura-se levantar, segundo a bibliografia, as
necessidades de gerenciamento de dados em ambientes de engenharia simultnea;
comparar as necessidades de gerenciamento de dados encontradas na bibliografia
com as necessidades de um caso de implantao real; levantar quais funcionalidades
de sistemas PDM (product data management) suprem as necessidades encontradas; e
caracterizar um projeto de implantao real de um sistema PDM em um ambiente de
engenharia simultnea.
Palavras-chave:
sistemas
de
gerenciamento
de
dados
de
produto;
gerenciamento de dados; PDM; engenharia simultnea.
Rogerio Omokawa
viii
ABSTRACT
OMOKAWA, R. (1999). Use of PDM systems in concurrent engineering

environments: a case study of an implementation in a multinational heavy vehicles
industry. So Carlos. 154p. Dissertao (Mestrado) - Escola de Engenharia de So
Carlos, Universidade de So Paulo.
The concurrent engineering and the product data management systems

(PDM), although being a precious aid to allow the companies to face the new
survival conditions in the current market, are not very well-known. Besides that, few
scientific works related to the implementation of this kind of system and their usage
in the data management of data in a concurrent engineering environment are
available. The objectives of this work are: to rise, according to the bibliography, the
needs of data management in a concurrent engineering environment; to compare
those needs with the ones of a real implementation case; to rise which functionality
of PDM (Product Data Management) systems supply the founded needs; and to
characterize a project of a real PDM system implementation in an environment of
concurrent engineering.
Keywords: product data management system; data management; PDM;

concurrent engineering.
Rogerio Omokawa
1. INTRODUO
Devido ao atual nvel de competio entre as empresas, surgiram diversas

teorias para auxiliar as empresas a sobreviver neste ambiente.
Segundo CLARK & FUJIMOTO (1991) e CLAUSING (1994), para muitas
empresas, a sobrevivncia no mercado depende de sua capacidade de aperfeioar o
processo de desenvolvimento de produto com os objetivos de reduzir o tempo de
desenvolvimento, garantir a qualidade e diminuir o custo dos produtos. Para
alcanarem estes objetivos, muitas empresas comearam a utilizar a filosofia de
Uma das caractersticas da utilizao desta filosofia o uso dos dados
gerados nos estgios iniciais do desenvolvimento, sem estarem completos
(PRASAD, 1996). Para que estes dados estejam disponveis no momento certo, para
a pessoa certa, necessrio que sejam bem gerenciados. Para organizar e gerenciar
efetivamente estes dados, os sistemas de gerenciamento de dados de produto
comearam a ser utilizados, possuindo um grande potencial para auxiliar na
implantao da engenharia simultnea.
apresentada a seguir a justificativa deste trabalho, e logo aps a
metodologia utilizada, e as etapas da realizao do trabalho. Em seguida
apresentada a reviso bibliogrfica sobre os temas abordados. Por fim, so
apresentados os captulos relativos ao trabalho prtico e a concluso.
Rogerio Omokawa
1.1. JUSTIFICATIVA
A engenharia simultnea e os sistemas de gerenciamento de dados de produto
(PDM), apesar de serem uma ajuda preciosa para que as empresas enfrentem as
novas condies de sobrevivncia no mercado atual, no so muito conhecidos.
Alm disso, existem poucos trabalhos cientficos relacionados implantao deste
tipo sistema e o auxlio destes no gerenciamento de dados em ambiente de
Existe tambm uma grande dificuldade por parte das empresas no
levantamento e necessidades de gerenciamento de dados e na escolha do sistema de
acordo com este levantamento.
1.2. OBJETIVOS
Os objetivos deste trabalho so:
levantar, segundo a bibliografia, as necessidades de gerenciamento de dados em

ambientes de engenharia simultnea;
comparar as necessidades de gerenciamento de dados encontradas na bibliografia

com as necessidades de um caso de implantao real;
levantar quais funcionalidades de sistemas PDM (product data management)

suprem as necessidades encontradas; e
caracterizar um projeto de implantao real de um sistema PDM em um

ambiente de engenharia simultnea.
Rogerio Omokawa
1.3. PERGUNTAS DA PESQUISA

As perguntas advindas dos objetivos do trabalho e que delimitam o tema de
trabalho so:
1. Quais so as necessidades de gerenciamento de dados em um ambiente de
engenharia simultnea, segundo a bibliografia?
2. Quais so as necessidades de gerenciamento de dados em um ambiente de
engenharia simultnea no caso de um projeto de desenvolvimento de produto?
3. Quais funcionalidades do sistema PDM atendem s necessidades
levantadas?
4. Quais so as caractersticas do processo de implantao de um sistema
PDM em um ambiente de engenharia simultnea?
A primeira pergunta respondida atravs da reviso da bibliografia e as
outras trs pela pesquisa de campo.
apresentado a seguir o mtodo utilizado no trabalho.
1.4. MTODO
Conforme os objetivos propostos e segundo DANE (1990), que considera a
pesquisa descritiva como o tipo de pesquisa utilizada para examinar um fenmeno
para defini-lo melhor ou para diferenci-lo de outros fenmenos, como uma pesquisa
que procura capturar as caractersticas de um objeto, de uma pessoa ou de um evento
em um dado momento, mesmo que estas caractersticas mudem ao longo do tempo,
este trabalho caracterizado como uma pesquisa descritiva.
O mtodo utilizado neste trabalho a pesquisa de campo, onde o objeto de
anlise uma implantao de um sistema PDM em um projeto de desenvolvimento
de um produto. Este mtodo foi escolhido porque, segundo DANE (1990), a pesquisa
Rogerio Omokawa
de campo particularmente indicada para pesquisas exploratrias e descritivas, como

o caso desta pesquisa.
Pesquisa de campo um rtulo geral aplicado a uma coleo de mtodos de
pesquisa que incluem a observao direta de eventos naturais. Por observao direta
entende-se o exame do evento assim que ele ocorre, podendo eventualmente ser o
exame do evento gravado. E eventos naturais so eventos que no so criados,
sustentados ou descontinuados somente para o objetivo da pesquisa (DANE, 1990).
Na pesquisa de campo os eventos so coletados, gravados e codificados por um
pesquisador que no participa dos eventos, caracterizando assim a observao
sistemtica do caso.
As tcnicas empregadas para a coleta de dados so o questionrio de
respostas fechadas e a entrevista de respostas abertas, procurando utilizar as
melhores caractersticas de cada uma delas.
O questionrio utilizado quando necessria a checagem dos dados por
parte do entrevistado, no realizando assim presso para respostas imediatas. O
modelo de respostas fechadas adotado para facilitar a resposta do questionrio,
sendo as alternativas bem definidas. Este questionrio utilizado para caracterizar o
grau de utilizao da filosofia de engenharia simultnea no ambiente de implantao.
As entrevistas so utilizadas para levantar quais so as caractersticas de
gerenciamento de dados da empresa, para levantar quais so as caractersticas do
processo de implantao do sistema PDM e para verificar quais funcionalidades do
sistema atendem s necessidades levantadas. Estas entrevistas com respostas
abertas so utilizadas porque as respostas dependem da experincia do entrevistado
e de dados no documentados. As respostas abertas permitem que o entrevistado
fique vontade para responder s questes, sem que haja uma delimitao das
respostas.
Independente do mtodo escolhido, a realizao de uma reviso bibliogrfica
e de extrema importncia para se conhecer e se analisar as informaes cientficas
Rogerio Omokawa
existentes sobre o tema da pesquisa, obtendo embasamento terico para suportar o

tema e para preparar e realizar o trabalho prtico.
1.5. LIMITAES DA PESQUISA

Segundo DANE (1990), a pesquisa de campo no mais ou menos vlida que
qualquer outro mtodo, porm como qualquer outro tipo de pesquisa ela possui
algumas limitaes.
Esta pesquisa realizada atravs do estudo de caso da implantao de um
sistema PDM em um ambiente de desenvolvimento especfico. O estudo de caso
permite um grande contato com a empresa, com o processo de implantao e com o
pessoal envolvido, sendo difcil porm generalizar os resultados obtidos, pois o
ambiente de implantao difere muito de uma empresa para outra, assim como as
caractersticas do sistema e o tempo de implantao.
Alm disso, nas entrevistas para levantamento dos dados podem ocorrer erros
de interpretao tanto por parte do entrevistado, quanto do entrevistador. O
entrevistado pode ainda alterar as respostas de acordo com os interesses da empresa
em disponibilizar algumas informaes. As respostas podem tambm ser
influenciadas pelas caractersticas pessoais do entrevistador (modo de falar, sexo,
etc.) (KIDDER & JUDD, 1986).
No questionrio escrito tambm podem haver problemas de interpretao das
questes. Alm de existir a falta de controle do contexto no qual as questes so
realizadas (KIDDER & JUDD, 1986).
So tomadas medidas para diminuir o impacto dos erros decorrentes das
entrevistas e da aplicao do questionrio, porm estes erros podem ser apenas
minimizados e no completamente excludos.
Rogerio Omokawa
1.6. ETAPAS GERAIS DO TRABALHO

So apresentadas a seguir as etapas deste trabalho:
1.6.1. Reviso Geral da Bibliografia

Para DANE (1990), a reviso bibliogrfica deve ser realizada antes da coleta
de qualquer dado e possui como finalidade:
evitar a duplicidade de pesquisa, ou seja, conduzir uma pesquisa j realizada por

outro pesquisador sem apresentar diferenas;
utilizar as pesquisas realizadas para evitar os problemas conceituais e de

procedimento j cometidos; e
obter uma perspectiva cientfica do tema da pesquisa, pois a cincia envolve o

acmulo de conhecimento e o estudo de pesquisas e teorias existentes permite
determinar qual a contribuio do projeto para a base de conhecimento.
Visando estes objetivos, realizada uma pesquisa bibliogrfica dos principais
temas abordados neste trabalho, como engenharia simultnea, sistemas PDM, e de

mtodos e tcnicas de pesquisa.
A pesquisa bibliogrfica realizada em duas etapas. Esta primeira etapa
realizada para se conseguir uma viso geral do tema de trabalho e uma base terica
para o desenvolvimento dos objetivos e da metodologia de trabalho. A segunda
etapa, reviso bibliogrfica detalhada, realizada para se conseguir uma viso mais
detalhada sobre o tema.
1.6.2. Desenvolvimento dos Objetivos e do Mtodo

Os objetivos desta pesquisa advm de problemas prticos do crescimento da
utilizao dos sistemas PDM e conseqente aumento das implantaes destes
sistemas, e da existncia de poucos trabalhos cientficos que abordam a implantao
Rogerio Omokawa
desses sistemas e o auxlio no gerenciamento de dados em ambientes de engenharia

simultnea. Com base na reviso bibliogrfica so desenvolvidos os objetivos e a
metodologia compatveis com as caractersticas da pesquisa (Itens 1.2 e 1.4).
1.6.3. Reviso Bibliogrfica Detalhada

Aps a definio dos objetivos e da metodologia, realiza-se uma reviso
bibliogrfica abrangente e detalhada sobre o tema de pesquisa. Consegue-se assim
formar uma base de conhecimentos para o desenvolvimento do trabalho, bem como a
formao da viso de que este trabalho pode contribuir como referncia para futuras
implantaes de sistemas PDM.
A reviso bibliogrfica (Captulos 2 e 3) realizada atravs da identificao e
da leitura de livros e artigos de engenharia simultnea. No caso de sistemas PDM,
alm dos livros e artigos, so consultados catlogos de sistemas, sites da internet e
publicaes de empresas de consultoria, pois grande parte do material encontrado
provm de estudos destas empresas. Os dados selecionados so organizados,
registrados e classificados em assuntos
1.6.4. Desenvolvimento da Forma de Coleta dos Dados

De acordo com o mtodo escolhido, no caso a pesquisa de campo,
desenvolvido uma forma de coleta de dados. Neste trabalho so utilizados um
questionrio de questes fechadas e um roteiro de entrevista com questes
abertas (Item 1.4).
O questionrio, da metodologia criada por CARTER & BAKER (1992),
utilizado para caracterizar o grau de utilizao da filosofia de engenharia simultnea
na empresa onde realizado o estudo de caso.
O roteiro de entrevista visa levantar quais so as caractersticas de
gerenciamento de dados da empresa e as caractersticas da implantao do sistema
PDM. Durante este desenvolvimento so realizadas algumas entrevistas a
Rogerio Omokawa
profissionais para testar e melhorar o questionrio e roteiros de entrevistas. Nas

entrevistas a estes profissionais, procura-se sempre que possvel evitar interrupes,
utilizando um ambiente calmo e reservado.
1.6.5. Escolha do Caso

A escolha da empresa a ser estudada (Item 4.1) ocorre segundo dois critrios:
possuir ambientes de desenvolvimento de produtos onde se aplica a filosofia da
engenharia simultnea e possuir um sistema PDM implantado ou em fase de
implantao neste ambiente.
1.6.6. Coleta de Dados

Aps o desenvolvimento do questionrio e do roteiro de entrevistas so
realizadas vrias visitas a empresa escolhida para aplic-los, realizando assim o
estudo de caso.
Durante estas visitas so realizadas entrevistas para se avaliar a existncia de
caractersticas
adicionais
levantadas
pela
bibliografia
em
relao
ao
gerenciamento de documentos. So entregues, durante as visitas, questionrios para

avaliar o grau de utilizao da filosofia de engenharia simultnea.
Durante as entrevistas so realizadas tambm questes para se levantar as
caractersticas de implantao do sistema. Nestas entrevistas procura-se evitar
interrupes utilizando um ambiente calmo e reservado, sendo as respostas anotadas
em papel.
Alm das entrevistas e aplicao do questionrio, no perodo de
acompanhamento do trabalho na empresa procura-se tomar um contato maior com a
empresa, com as pessoas e com o ambiente do projeto.
Rogerio Omokawa
1.6.7. Apresentao e Anlise dos Dados

Aps a coleta dos dados obtidos com o questionrio e as entrevistas, os dados
so organizados, considerando-se sua pertinncia e relevncia, e transformados em
um texto estruturado (Captulos 4 e 5). Neste texto so apresentadas a caracterizao
da empresa em relao engenharia simultnea, as necessidades de gerenciamento
de documentos e as caractersticas da implantao do sistema PDM.
Rogerio Omokawa
10
2. O DESENVOLVIMENTO DE PRODUTOS E A ENGENHARIA

SIMULTNEA
Atualmente, o sucesso de uma empresa est diretamente ligado sua

capacidade de entender as necessidades do cliente e de desenvolver rapidamente
produtos, com um preo justo, para atenderem a essas necessidades (CARTER &
BAKER, 1992).
Neste captulo apresenta-se a definio de desenvolvimento de produtos
seqencial e dos problemas desta abordagem. Apresenta-se tambm a abordagem de
engenharia simultnea e as necessidades de gerenciamento de dados em ambientes
que utilizam esta filosofia.
2.1. A
ABORDAGEM
TRADICIONAL
(SEQENCIAL)
DE
DESENVOLVIMENTO DE PRODUTOS E SEUS PROBLEMAS

Nesta abordagem tradicional, o desenvolvimento de produtos realizado de
maneira seqencial, sendo que cada estgio tem de ser completado para que o estgio
seguinte tenha incio (SYAN, 1994).
Uma definio de desenvolvimento de produtos segundo esta abordagem
dada por WOODSON (1966, p.3), que considera o desenvolvimento de produtos
como uma atividade de tomada de deciso interativa para produzir os planos a partir
dos quais os recursos so convertidos, preferencialmente otimizados, em sistemas ou
aparelhos para satisfazer as necessidades humanas.
Rogerio Omokawa
11
No incio de qualquer desenvolvimento de produtos existe um elevado grau

de incerteza. Esta incerteza diminui no decorrer do desenvolvimento, mas
justamente no incio que se seleciona a maior quantidade de solues construtivas.
As escolhas de alternativas ocorridas no incio do ciclo de desenvolvimento so
responsveis por 60 a 95% do custo do produto final (SYAN, 1994). O custo de
modificao aumenta ao longo do ciclo de desenvolvimento, pois quanto mais tarde
for realizada uma mudana, um nmero maior de decises j tomadas podem ser
invalidadas. Alm disso, o processo de desenvolvimento seqencial faz com que o
nmero de alteraes ocorra muito tardiamente (Figura 1) (ROZENFELD &
VEGA, 1995, p. 212).
grau de incerteza
qtde de escolhas
influncia no custo
custo modificao
$ 85%
?
tempo
tempo
$
tempo
tempo
Figura 1: Caractersticas do Desenvolvimento de Produtos

Com Base em ROZENFELD & VEGA, 1995, p. 212
Alm das alteraes que ocorrem muito tardiamente, fazendo com que os
custos de desenvolvimento aumentem, existem outros problemas:
o desenvolvimento de produtos seqencial baseado na premissa de que uma

nova fase no pode comea sem que a fase precedente tenha sido completada.
Isto significa um aumento no tempo de desenvolvimento de produto (PRASAD,
1996);
a linearidade das fases do desenvolvimento de produto faz com que uma parte
significativa (50 a 80%) dos custos de manufatura sejam decididos antes dos
engenheiros de manufatura comearem a fazer parte do projeto (PRASAD,
1996);
Rogerio Omokawa
12
os prazos de lanamento muitas vezes no so cumpridos, fazendo com que o

produto final no sirva mais ou no seja mais vivel ao mercado alvo (PRASAD,
1996);
a especificao do produto insuficiente, levando a um excessivo nmero de

modificaes (SYAN, 1994);
pouca ateno dada para os processos de manufatura nos estgios de projeto,

causando alteraes caras em ferramentas e outros equipamentos (SYAN, 1994).
Muitos desses problemas so resolvidos com a aplicao da engenharia
simultnea, filosofia apresentada no item 2.3.

So apresentadas a seguir as fases do desenvolvimento de produtos de acordo
com WHEELWRIGHT & CLARK (1992) e de acordo com ROZENFELD (1997).
2.2. FASES DO DESENVOLVIMENTO DE PRODUTOS

Segundo WHEELWRIGHT & CLARK (1992), o desenvolvimento de
produtos dividido em quatro fases: desenvolvimento do conceito, planejamento do
produto, engenharia do produto/processo e finalmente produo piloto/aumento da
produo (Figura 2).
Ainda segundo os mesmos autores, nas duas primeiras fases
desenvolvimento do conceito e planejamento do produto as informaes de
oportunidades de mercado, possibilidades tcnicas, e requisitos da produo devem
ser combinadas para se definir a arquitetura do novo produto. Isto inclui seu projeto
conceitual, mercado alvo, requisitos em investimentos e impacto financeiro. Antes
que o programa de desenvolvimento de produto seja aprovado, a empresa deve
validar o conceito atravs de testes em pequena escala, da construo de modelos e
da discusso com potenciais clientes.
Rogerio Omokawa
13
Fase
Desenvolvimento
do Conceito
Planejamento
do Produto
Engenharia do
Produto/Processo
Produo
Piloto/Aumento da
Produo
Aprovao do
Programa
conceito
Liberao
Primeiro
Final de
Prottipo Engenharia
projeto/planejamento
produto
processo
Introduo no
Mercado
produo piloto
aumento da produo
Figura 2: Fases do Desenvolvimento de Produtos

Com Base em WHEELWRIGHT & CLARK, 1992, p. 7
Uma vez aprovado, o projeto entra na fase de detalhamento da engenharia de
produto/processo. A principal atividade nesta fase o projeto e construo de
prottipos e o desenvolvimento de ferramentas e equipamentos a serem utilizados na
produo em larga escala. No centro do detalhamento da engenharia de
produto/processo est o ciclo de projetar construir testar. Os produtos e
processos gerados no conceito so incorporados em um modelo de trabalho, que
depois submetido a testes que simulam o produto em uso. Caso ocorram problemas,
os engenheiros buscam mudanas para melhorar o projeto, e o ciclo projetar
construir testar repetido. A concluso desta fase de detalhamento da engenharia
marcada pela liberao da verso final, que indica que o projeto est pronto para
iniciar uma produo piloto.
Na fase de produo piloto os componentes individuais so construdos e
testados em equipamentos de produo. Durante esta fase, muitas unidades do
produto so produzidas e os processos de manufatura novos ou modificados, para
serem executados em um nvel de produo comercial, so testados. Neste estgio
Rogerio Omokawa
14
todo o ferramental e equipamentos devem estar prontos e todos os fornecedores de

peas devem estar aptos a produzir em um volume comercial.
A fase final do desenvolvimento o aumento da produo. O processo foi
refinado e melhorado, mas tem de ser testado para operar com um alto volume de
produo. Nesse aumento, a empresa inicia a produo em um nvel relativamente
baixo, e assim que a organizao e seus fornecedores desenvolvem confiana em sua
capacidade de produo e comercializao, vai-se aumentando seu volume at atingir
as metas iniciais de produo, custo e qualidade.
J ROZENFELD (1997), em um primeiro nvel, divide a fase de
desenvolvimento de produtos em sete fases, mais uma fase que acompanha todo o
desenvolvimento, onde so avaliadas todas as decises tomadas em outras fases,
realizando-se aes corretivas para eventuais problemas (Figura 3). Esta
representao baseada na forma adotada pelo APQP (Advanced Product Quality
Planning)
da
QS9000
(CHRYSLER
CORPORATION;
FORD
MOTORS
COMPANY; GENERAL MOTORS CORPORATION, 1995).

Existe tambm um segundo nvel de representao mais formalizada que no
ser apresentado neste trabalho.
Idia Diretrizes Conceito Projeto Prottipo Piloto
Lanamento
Conceber
Produto
Conceituar
Produto
Proj. Produto e Processo
Homologar
Produto
Homologar
Processo
TreinarEmpresa
Empresa
Treinar
Produo
Avaliao e Aes Corretivas
Figura 3: Fases do Processo de Desenvolvimento de Produtos

Fonte: ROZENFELD, 1997, p. 4
Rogerio Omokawa
15
A descrio de cada fase, segundo ROZENFELD (1997), realizada a seguir:

Conceber Produto: quando se pensa em um novo produto. Tem incio com idias
vindas de informaes de mercado, anlises encomendadas ou realizadas pelos
dirigentes, observaes de concorrentes, necessidades de melhoria, opinio de
clientes, etc. Aps uma anlise de atratividade decide-se pensar nesta idia. Um
grupo composto por pessoas da alta gerncia e um coordenador de produto definem
as diretrizes do produto, como custo, retorno esperado, data de lanamento,
especificao final do produto, etc. Este coordenador acompanhar todo o ciclo de
vida do produto.
Conceituar Produto: Consiste em complementar as diretrizes obtidas anteriormente,
com uma definio detalhada das caractersticas tcnicas do produto. Esta atividade
desempenhada por um time multifuncional, composto por engenheiros de qualidade,
processo, projeto, marketing, entre outros. O coordenador de produto lidera esse
time. Aplicam-se aqui tcnicas de engenharia simultnea, com nfase no QFD
(quality function deployment) e princpios de DFMA (design for manufacturing and
assembly). O trabalho eficaz desta equipe tambm suportado por sistemas de
workgroup computing.
Todas as possveis informaes criadas nesta fase so arquivadas de forma
sistemtica, garantindo a sua reutilizao em fases posteriores. J se toma aqui
algumas decises de make or buy, graas ao uso de sistemas de oramento. Neste
ponto pode-se convidar fornecedores para participar do desenvolvimento. Os
conceitos especificados nesta fase so valorados, as diretrizes so detalhadas e
validadas. E finalmente, toma-se a deciso em conjunto com o grupo de concepo
se a empresa deve investir mais recursos no detalhamento do melhor conceito.
Projetar Produto: quando se realiza o detalhamento do produto. Tambm
desenvolvido por um time multifuncional, porm com pessoas de perfil mais
operacional que o anterior. Informaes de produtos semelhantes so recuperadas de
forma sistemtica, para que possam ser reutilizadas. Ento, novos desenhos e
processos so elaborados em detalhes. So avaliadas suas caractersticas
determinantes e estas so calculadas e verificadas atravs de simulaes. Pode-se
Rogerio Omokawa
16
utilizar aqui um prottipo eletrnico do produto, que custa menos em relao

construo do prottipo real, chegando a substitu-lo em alguns casos.
Antes do detalhamento de um componente, toma-se a deciso definitiva de
make or buy, na maior parte das vezes confirmando aquela tomada na fase de
conceituao. No entanto aqui j devem ser tomadas decises quanto procedncia
do item, ou seja, qual o fornecedor, amarrando-se o fornecimento e seu preo, para
que surpresas no aconteam na poca de sua produo.
Um princpio para o trabalho das pessoas nessa fase a qualidade assegurada
nos servios. Isso garante a liberao das informaes produzidas em um estgio
para que o time d continuidade aos trabalhos dependentes dessa informao, antes
da sua aprovao, garantindo assim um trabalho paralelo.
A qualquer momento desta atividade, um membro do time pode considerar
um item como sendo crtico. Isto pode significar que o item pode ter uma
complexidade incompatvel com a empresa ou demandar um longo tempo de
desenvolvimento. Esse tempo
resultante de importao, desenvolvimento de
dispositivos, prottipos, etc. Nesses casos chamada uma reunio extra de todos os
membros do time, a fim de liberar com maior rapidez os itens crticos. Eles so ento
considerados gargalos do desenvolvimento e comeam a ser acompanhados com
maior preciso.
No final da fase de detalhamento acontecem reunies para definir os
potenciais de falhas do projeto e processo que sero verificados durante a
homologao do produto e processo respectivamente. Nesta fase so utilizados
conceitos da QS 9000, uma evoluo da ISO 9000, aplicando-se particularmente a
tcnica de FMEA (failure model & effect analysis). No detalhamento so obtidas
tambm outras informaes, tais como fluxo de processo; carta de controle estatstico
de processo; croquis de fabricao, de set-up de equipamento e de inspeo; lista de
ferramental, etc.
Rogerio Omokawa
17
Homologar Projeto:. Define-se um programa de testes do produto, um plano de

processo do prottipo, itens a serem comprados e servios externos para a sua
construo.
A seguir, tem-se as atividades de planejamento, fabricao e montagem do
prottipo. So ento realizados testes e uma avaliao sobre os resultados obtidos.
So aplicadas aqui tcnicas de anlise de experimentos. Ao final monta-se um
relatrio dos testes realizados. Com base neste relatrio e tendo-se em mos as
possveis falhas levantadas durante o Projetar Produto, finaliza-se o FMEA de
produto e homologa-se o produto. Verifica-se o cumprimento das diretrizes de
produto, por meio de reunies com as equipes envolvidas no seu desenvolvimento.
Homologar Processo: Com o prottipo aprovado, parte-se para a definio de um
cronograma interno de implantao do produto na empresa. So detalhados os planos
de montagem aps a fabricao de um lote piloto, deve-se verificar a capacidade da
empresa em obter o produto desejado. So verificados as falhas do FMEA de
processo e tomadas medidas pertinentes para elimin-las.
Treinar Empresa: Consiste em obter as informaes finais sobre o produto, tais
como: manuais de manuteno, aplicao, etc. Com esse material so realizados
cursos e palestras para pessoas das reas de marketing, vendas, assistncia tcnica,
planejamento e fabricao, a fim de divulgar os conceitos e caractersticas do novo
produto. Sistemas de informao para apoio s outras atividades da empresa,
relacionados com o produto, tais como software de apoio a vendas ou assistncia
tcnica, so desenvolvidos nesta fase. Procura-se aqui reaproveitar as informaes de
outras fases.
Apesar da representao em fases, elas apresentam uma grande sobreposio,
como mostra a Figura 3. Ou seja, uma atividade de uma fase pode ser iniciada antes
que a fase anterior seja finalizada, desde que a informao necessria ao seu
desenvolvimento j esteja disponvel.
Como mostrado no item 2.1, a abordagem tradicional de desenvolvimento
de produtos apresenta vrios problemas, tais como alto custo e alto tempo de
Rogerio Omokawa
18
desenvolvimento. No item 2.2 - Fases do Desenvolvimento de Produtos, algumas das

caractersticas de engenharia simultnea, como por exemplo paralelismo de
atividades, utilizao de ferramentas como QFD e FMEA, so citadas.
A filosofia de engenharia simultnea, com o uso de tcnicas, ferramentas e
processos,
visa
eliminar
ou
minimizar
os
problemas
apresentados
pelo
desenvolvimento tradicional de produtos. Esta filosofia apresentada a seguir.
2.3. A
ENGENHARIA
SIMULTNEA
CLASSIFICAO
DOS
ELEMENTOS QUE A SUPORTAM

A engenharia simultnea tambm conhecida por outros nomes, tais como
engenharia concorrente, projeto concorrente, desenvolvimento de produtos
integrados e projeto em time (SYAN, 1994). Neste trabalho ser empregado o termo
engenharia simultnea (ES).
Segundo HALL (1991), engenharia simultnea caracterizada pela
simultaneidade do projeto e processo de manufatura de um produto.
Alguns elementos tais como formao de um time multifuncional,
reorganizao da estrutura organizacional, utilizao de sistemas computacionais,
etc. suportam a implantao bem sucedida da ES. So apresentados a seguir
classificaes desses elementos segundo alguns autores.
2.3.1. A Classificao Segundo SYAN (1994)

Segundo SYAN (1994), existem quatro classes que suportam a ES:
processos, ferramentas computacionais, tcnicas formais e mtodos de troca de
dados. Cada uma dessas classes so apresentadas, em detalhe, a seguir:
Rogerio Omokawa
19
2.3.1.1. Processos
Existem basicamente dois aspectos desta classe de suporte de ES: a

abordagem de time e a organizao estrutural da empresa. Estes dois aspectos so
detalhados a seguir:
a) A Abordagem de Time
So abordadas aqui as caractersticas do time multidisciplinar de
desenvolvimento de produtos. Segundo SYAN (1994) este time deve conter pessoas
de vrios departamentos da empresa, como mostrado na Figura 4, incluindo tambm
os principais fornecedores e clientes.
engenharia do
produto
compras
engenharia de
manufatura
Time
Multidisciplinar
financeiro
fornecedores
marketing
vendas
vendedores
especialistas:
maquinas
ferramentas
moldes
semi condutores
clientes
Figura 4: Composio de um Time de Desenvolvimento de Produtos

Multidisciplinar
Com Base em SYAN, 1994, p. 14
Uma caracterstica importante deste time na ES ser responsvel por todo o
projeto e possuir autoridade para as decises. Esta atitude requer treinamento dos
membros do time e da gerncia para ser efetivo.
Rogerio Omokawa
20
Alm disso, para que a ES tenha sucesso preciso que exista a comunicao
efetiva entre os seus integrantes. Esta comunicao envolve as pessoas, a troca de
dados entre os sistemas utilizados tais como CAD/CAM e, talvez a atividade mais
importante do time multidisciplinar, a documentao e gerenciamento das
informaes e das decises realizadas, para que possam ser recuperadas sempre que
necessrio (SYAN, 1994).
b) Estrutura Organizacional
A forma com que a empresa se organiza para o desenvolvimento de produtos,
influi neste desenvolvimento. Existem vrias maneiras da empresa se organizar.
Segundo SYAN (1994), a organizao matricial (Figura 5) a que mais se adapta
s empresas que utilizam a abordagem de engenharia simultnea. Este tipo de
organizao compreende a superposio ou cruzamento de dois tipos de estruturas: a
funcional ou departamental (permanente) e as estruturas de projetos (transitrias, que
existem apenas enquanto durarem os projetos nos quais as pessoas esto alocadas),
permitindo a formao dos times multifuncionais.
Gerncia
Dep. 1
Dep. 2
Projeto A
A1
A2
Projeto B
B1
B2
Projeto C C1
Dep. 3
B3
C3
Organizao do Projeto
Organizao
Departamental
A1: pessoas do
departamento 1
que trabalham no
projeto A
B2:pessoas do
departamento 2
que trabalham no
projeto B
.
.
.
Figura 5: Organizao Matricial

Com Base em CHIUSOLI, 1996, p. 29
Rogerio Omokawa
21
CLARK & FUJIMOTO (1991) E CLAUSING (1994) so mais completos

que SYAN (1994) na identificao das formas de organizao do desenvolvimento
de produto. CLARK E FUJIMOTO (1991) identificam quatro formas de
organizao: estrutura funcional tradicional, estrutura de gerente de produtos peso
leve, estrutura de gerente de produto peso pesado e estrutura de time de execuo
do projeto. CLAUSING (1994), identifica ainda uma quinta forma: a estrutura de
time de desenvolvimento de produtos independente.
Na estrutura funcional tradicional (Figura 6), no existe uma pessoa
responsvel por todo o desenvolvimento de produtos. Os gerentes funcionais so
responsveis pela alocao de recursos e pela coordenao dos esforos de
desenvolvimento dos departamentos (CLARK & FUJIMOTO, 1991).
Na Figura 6, cada departamento (D1 - engenharia, D2 - marketing, etc.)
supervisionado por um gerente funcional (GF). Os engenheiro (ou pessoas de outras
reas) que trabalham em um determinado projeto so representados pelos crculos
quadriculados nos departamentos.
Departamento 1, 2, 3, ...
GF
GF
D1
GF
D2
Gerente
Funcional
(GF)
GF
D3
D4
Dn
Pessoal do Departamento
Envolvido em um Determinado
Projeto
Figura 6: Estrutura Funcional

Fonte: CLARK & FUJIMOTO, 1991, p. 254
Rogerio Omokawa
22
No desenvolvimento de produtos utilizando a estrutura de gerente de

produtos peso leve (Figura 7), a organizao bsica continua sendo funcional, e o
nvel de especializao comparvel ao encontrado no modelo funcional. A
diferena est na presena do gerente do produto (GP), que coordena as atividades de
desenvolvimento atravs de representantes (R). Estes representantes so o elo de
ligao das pessoas de um grupo com os demais grupos de outros departamentos e o
GP. O GP coordena o pessoal envolvido no projeto diretamente ou atravs de seus
representantes. A rea delimitada pelo retngulo tracejado onde o GP exerce forte
influncia.
Os principais objetivos do gerente de produto so: coletar informao do
status do trabalho e ajudar a resolver conflitos dos membros/departamentos nos
grupos funcionais (CLARK & FUJIMOTO, 1991).
GF
GF
D1
GF
D2
GF
D3
GF
D4
Dn
Assistentes
do GP
R
Gerente do
Produto (GP)
R
Representante
rea de grande
influncia do GP
Figura 7: Estrutura de Gerente de Produtos Peso Leve

Fonte: CLARK & FUJIMOTO, 1991, p. 254
Estes GP so chamados pesos leve porque no possuem acesso direto s
pessoas do nvel de trabalho, apenas aos representantes, e possuem menos status e
poder que os gerentes funcionais. Nesta estrutura os GP no possuem um contato
Rogerio Omokawa
23
direto com o mercado e nem responsabilidades em relao ao conceito do produto

(CLARK & FUJIMOTO, 1991).
No desenvolvimento de produtos utilizando a estrutura de gerente de
produtos peso pesado (Figura 8), apesar da organizao ser essencialmente
funcional, o gerente de projetos possui mais responsabilidade e influncia. O trabalho
deste gerente ocorre junto com aos representantes das reas funcionais e aos
engenheiros do nvel de trabalho do projeto. A interseo entre o mercado e a zona
de influncia do gerente (Figura 8), indica que os gerentes tambm so responsveis
pela criao do conceito (integrao externa), alm de um contato com os clientes
(CLARK & FUJIMOTO, 1991).
GF
GF
D1
GF
D2
GF
D3
GF
D4
Dn
Conceito
R
GP
Mercado
Figura 8: Estrutura de Gerente Peso Pesado

Fonte: CLARK &FUJIMOTO, 1991, p. 254
Apesar de trabalhar sobre uma organizao funcional, so organizados times
responsveis por todo o desenvolvimento do produto.
As estruturas de gerentes de produtos peso - leve e peso - pesado so
variaes da estrutura matricial citada por SYAN (1994) como sendo s que mais se
adaptam ambiente de engenharia simultnea.
Rogerio Omokawa
24
Na estrutura de time de execuo de projeto (Figura 9), o time sai da

estrutura funcional e trabalha todo o seu tempo no desenvolvimento de um produto.
As pessoas se reportam somente ao gerente de produto e ao fim do projeto elas
reassumem suas posies na estrutura organizacional (CLARK & FUJIMOTO,
1991).
GF
GF
D1
GF
D2
GF
D3
GF
D4
Dn
Mercado
Conceito
R
GP
Figura 9: Estrutura de Time de Execuo de Projetos

Fonte: CLARK &FUJIMOTO, 1991, p. 254
No desenvolvimento de produtos atravs de um time de desenvolvimento de
produtos independente, proposto por CLAUSING (1994) as pessoas so membros
apenas do time, no possuindo um lugar na estrutura funcional. Esta estrutura se
assemelha estrutura de time de execuo de projeto, sem a necessidade de
dissoluo do time aps o trmino do projeto. Esta forma de organizao torna o
produto o foco das atenes do time.
Segundo CLAUSING (1994), qualquer uma das trs ltimas formas de
organizao (estrutura de: time de desenvolvimento de produtos independente, time
de execuo de projetos e gerente peso pesado) podem ser utilizadas com
sucesso em ambientes de engenharia simultnea, sendo que a escolha de uma das trs
depende somente das caractersticas da empresa.
Rogerio Omokawa
25
2.3.1.2. Ferramentas Computacionais

Atualmente as ferramentas computacionais so utilizadas em todas as reas
do desenvolvimento do produto, como em pesquisa de marketing, engenharia,
planejamento e controle da manufatura, etc.
Uma das reas onde mais se utiliza estas ferramentas a engenharia, onde so
empregados, por exemplo, sistemas de projeto e manufatura auxiliada por
computador (CAD/CAM - computer aided design/computer aided manufacturing),
planejamento do processo auxiliado por computador (CAPP computer aided
process planning), engenharia auxiliada por computador (CAE computer aided
engineering), ferramentas de modelagem, de simulao e planejamento da produo
e custeio (SYAN, 1994).
Estas ferramentas podem gerar milhares de desenhos de peas, e informaes
relacionadas a estas peas, para cada projeto. Estas informaes so especificaes
do produto, simulaes, relatrios de anlises e testes, relatrios de custos,
informaes de manufatura, etc. Torna-se ento essencial a utilizao de um sistema
de gerenciamento de dados. Para isso, os sistemas de gerenciamento de dados de
engenharia/produto (EDM/PDM engineering data management/product data
management) tm sido muito utilizados (SYAN, 1994).
Estas ferramentas devem funcionar de maneira integrada e efetiva num
ambiente de ES, alm disso as necessidades de novas ferramentas devem ser
identificadas. Para que isso ocorra, necessrio o levantamento de:
como o processo de desenvolvimento realmente opera na empresa;
quais ferramentas so utilizadas, quais operam de maneira integrada e como

funcionam;
quais so os sistemas que operam isolados em departamentos funcionais e como

eles podem operar compartilhando informaes com outros sistemas;
Rogerio Omokawa
26
estgios do desenvolvimento de produtos que envolvem atividades repetitivas e

que podem ser automatizadas.
2.3.1.3. Tcnicas Formais

A lista de tcnicas formais existentes que auxiliam o desenvolvimento de
produtos muito extensa. Ela inclui tcnicas como: desdobramento da funo
qualidade (QFD quality function deployment), projeto de experimentos, mtodo
Taguchi, projeto para manufatura (DFM design for manufacturing), projeto para a
montagem (DFA design for assembly), tcnicas de reduo de estoque (JIT just
in time), programas de melhoria contnua e ferramentas de custeio (SYAN, 1994).
O uso destas tcnicas auxilia engenheiros e projetistas a garantir um nvel
mnimo de qualidade. Apesar disso, nenhuma tcnica oferece uma soluo universal.
Escolher as tcnicas certas, no tempo certo do ciclo de desenvolvimento de produtos
um conhecimento essencial para os membros do time. A Figura 10 mostra quando
vrias tcnicas so aplicadas.
QFD
definio de
requisitos
QFD
tcnicas de resoluo problemas
DFM
desenvolv.
do conceito
QFD
FMEA de produto
Taguchi
DFM
detalhamento
do projeto
QFD
FMEA de processo
desenvolv. do
conceito do
sistema de
manufatura
QFD
FMEA de processo
capabilidade de processo
poka yoke
planejamento
do processo
manufatura
servio e
suporte
Figura 10: Utilizao de Tcnicas no Processo de Desenvolvimento de Produtos

Fonte: SYAN, 1994, p. 19
Rogerio Omokawa
27
2.3.1.4. Mtodos de Troca de Dados

Atualmente a maior parte das empresas utiliza sistemas computacionais em
grande parte dos seus processos, e muito importante que estes sistemas troquem
informaes entre si. Uma maneira de certificar-se que isto acontea adquirir todos
os sistemas de um mesmo fornecedor e que sejam compatveis entre si, situao que
na maioria das vezes no possvel (SYAN, 1994).
Existe tambm a opo por utilizar arquivos de formatos neutros, onde
sistemas diferentes se comunicam uns com os outros atravs destes arquivos.
Atualmente, existem vrios tipos de padres que fornecem suporte para a troca de
dados. Os mais comuns so (SYAN, 1994):
IGES (initial graphics exchange specification);
SET (standart dechange et de transfert);
VDA-FS(Verband der Deutschen Automobilindustrie-Flchenschnittstelle);
PDES (product data exchange system);
STEP (standard for the exchange of product data).

Mais detalhes sobre os padres de dados so dados no item 3.3.8.
2.3.2. A Classificao Segundo CARTER & BAKER (1992)

Segundo CARTER & BAKER (1992), a ES dividida em quatro dimenses
distintas, mas que interagem entre si. So elas: a dimenso da organizao, da infraestrutura da comunicao, dos requisitos do produto e do desenvolvimento do
produto.
A seguir, cada uma destas dimenses detalhada:
Rogerio Omokawa
28
2.3.2.1. A Dimenso da Organizao

Segundo CARTER & BAKER (1992), a cultura e a poltica organizacional
em uma empresa normalmente se opem engenharia simultnea. necessrio ento
uma reorganizao da empresa para suportar a implantao da ES.
Nessa reorganizao importante considerar dois aspectos : o papel do
gerente e o papel do time de desenvolvimento de produtos (PDT product
development team).
Os gerentes desempenham um papel importante na preparao da mudana
da cultura da empresa para a implantao do ambiente de ES. Cabe aos gerentes criar
os times de desenvolvimento de produtos e dar-lhes autonomia e responsabilidade
para tomar decises. Os gerentes devem ainda determinar as necessidades tcnicas e
profissionais do time e fornecer o treinamento e as ferramentas necessrias
(CARTER & BAKER, 1992).
Para isso, os gerentes devem possuir uma viso ampla da ES, tendo em vista
o projeto com foco no cliente e o relacionamento dos projetos com a organizao.
Eles tambm devem trabalhar junto com as demais pessoas da organizao para que
todos possam se preparar para o choque cultural devido s mudanas provocadas
pela ES (CARTER & BAKER, 1992).
A formao do time (nmero de integrantes, conhecimentos tcnicos de cada
pessoa, etc.) e as caractersticas do gerente variam de empresa para empresa, e at
mesmo de projeto para projeto, dependendo das caractersticas da empresa e do
escopo, durao e grau de dificuldade do projeto.
O PDT deve assumir a autoridade e responsabilidade por sua decises, sendo
que a colaborao entre os membros do time um dos aspectos mais importantes do
trabalho. As decises e aes do time devem sempre ser relacionadas com as
estratgias da empresa e requisitos dos clientes (CARTER & BAKER, 1992).
Rogerio Omokawa
29
2.3.2.2. A Dimenso da Infra-estrutura da Comunicao

A segunda dimenso de um ambiente de ES a infra-estrutura de
comunicao qualquer sistema, equipamento, ou software que facilita a
transferncia de informaes relativa ao produto. ES requer que um ou mais times
trabalhem
compartilhem
informao
em
um
ambiente
integrado
de
desenvolvimento de produtos. Por esta razo, uma comunicao efetiva vital para o
sucesso da implantao desse ambiente (CARTER & BAKER, 1992).
A complexidade do produto determina o nmero de reas envolvidas e ambos
determinam o tipo de infra-estrutura necessria para o compartilhamento da
informao. Quanto mais componentes e reas, mais variado e no integrado so os
dados, requerendo assim uma infra-estrutura mais complexa que possa integrar os
dados e manter todas as pessoas informadas sobre as atividades realizadas no
ambiente de ES (CARTER & BAKER, 1992).
Com poucas reas envolvidas no PDT, com um time pequeno e com o
produto e os requisitos de cliente e da empresa simples, pode-se necessitar apenas de
um correio eletrnico para manter o time informado sobre as tarefas de projeto. Com
mais reas envolvidas, pode-se utilizar uma base de dados de projeto aliada a
ferramentas para a automatizao de fluxos de trabalho (workflows) do
desenvolvimento de produtos.
As informaes relevantes da empresa, incluindo as das outras trs
dimenses, devem permear esta dimenso e ficarem disponveis para quando os
membros do time necessitarem (CARTER & BAKER, 1992).
2.3.2.3. A Dimenso dos Requisitos

Na ES a interpretao de requisitos amplificada para incluir todos os
atributos que tm impacto na satisfao do cliente, incluindo os requisitos de projeto
e os requisitos internos. O foco desta dimenso so os requisitos do cliente, que
devem ser utilizados desde a especificao do conceito at a validao de decises do
projeto (CARTER & BAKER, 1992).
Rogerio Omokawa
30
Para tanto, a empresa deve determinar o que o cliente quer. Certificando-se

tambm que o produto esteja de acordo com os padres internos (da empresa) e os
padres externos (da indstria).
2.3.2.4. A Dimenso do Processo de Desenvolvimento de Produtos

Vrias empresas nos anos 90 comearam a perceber que somente mudanas
organizacionais ou a utilizao de ferramentas modernas no eram suficientes para se
tornarem competitivas no cenrio mundial. Faltava uma viso integrada do
desenvolvimento do produto desde a concepo do projeto at a manufatura.
A dimenso do processo de desenvolvimento de produtos envolve os
processos que conectam todas as atividades do projeto. O cerne desta dimenso o
bom projeto, que pode superficialmente ser definido como aquele que atende aos
requisitos do cliente e tambm atende aos requisitos da empresa (desenvolvido
dentro dos prazos e custos previstos). Alm disso, um bom projeto deve possuir um
baixo nmero de alteraes de engenharia durante o processo de desenvolvimento.
Para atender aos requisitos do cliente so utilizadas ferramentas como, por exemplo,
o desdobramento da funo qualidade (QFD) (CARTER & BAKER, 1992).
Esta dimenso procura integrar o processo de desenvolvimento do produto,
integrando o grupo de desenvolvimento, compartilhando os dados do produto por
toda a empresa e identificando ferramentas e mtodos que auxiliem e otimizem o
processo de desenvolvimento como um todo.
Existem, como identificados durante este captulo, vrios elementos de
suporte da engenharia simultnea. Vrios autores apresentam definies de ES
baseados em muitos destes elementos. So apresentado a seguir algumas definies
de ES segundo autores diferentes.
Rogerio Omokawa
31
2.3.3. Definies de Engenharia Simultnea

Apesar das mudanas organizacionais e do emprego de tcnicas e de
ferramentas computacionais, faltava uma viso abrangente do desenvolvimento de
produtos para que a engenharia simultnea fosse implantada. Para suprir esta
necessidade, o conceito de processos comeou a ser utilizado.
Muitos autores, com ser visto a seguir, consideram esta viso por processos
como de fundamental importncia para o sucesso da engenharia simultnea, sendo
que alguns deles conceituam ES a partir desta viso:
Engenharia simultnea consiste em repensar o processo de transformar uma
idia num produto, seguindo-se vrias tcnicas e considerando as fases do
desenvolvimento de produtos simultaneamente ao se tomar as decises de um projeto
(EVANS, 1991).
Engenharia simultnea uma abordagem sistemtica para o desenvolvimento
concorrente e integrado de produtos, incluindo manufatura e manuteno. O objetivo
desta abordagem fazer com que as pessoas considerem todos os elementos do ciclo
de vida do produto, do conceito at a obsolescncia, incluindo qualidade, custo,
planejamento e requisitos (CARTER & BAKER, 1992).
Engenharia simultnea uma metodologia para desenvolvimento de projetos
que prope a realizao de muitos processos pertencentes ao ciclo de vida do produto
de forma simultnea (paralela), usando um time de projeto multidisciplinar e
dinmico e ferramentas automatizadas para a realizao dos processos componentes
(COSTA, 1994).
Engenharia simultnea consiste no aumento de clareza e unidade durante o
desenvolvimento do produto. Clareza significa aumento no processo de
simultaneidade, focado na qualidade, custos e distribuio, com nfase na satisfao
do cliente. Unidade significa uma melhora na integrao da organizao, no
envolvimento do membros do time e em relacionamentos estratgicos com os
fornecedores (CLAUSING, 1994).
Rogerio Omokawa
32
Segundo CRISTVO E GONALVES FILHO (1995), a engenharia

simultnea um modelo de gesto utilizado para aprimorar o processo de
desenvolvimento de novos produtos, em busca de maior competitividade. Segundo
os mesmos autores, a engenharia simultnea proporciona o envolvimento de
responsveis por manufatura, mtodos, qualidade, manuteno e suprimentos.
Engenharia simultnea a filosofia utilizada no processo de desenvolvimento
(ou alterao) de produtos, com base na sinergia entre seus agentes, suportados por
recursos e mtodos integrados, visando: um aumento da qualidade do produto, com
foco no cliente; uma diminuio do ciclo de desenvolvimento e a conseqente
diminuio de custos (ROZENFELD, 1995).
Neste trabalho adota-se a definio apresentada por ROZENFELD por ser
mais abrangente.
A abordagem de processos, como mostrado neste item, muito importante
para suportar a ES, sendo utilizada por diversos autores. O conceito de processos e
de desenvolvimento de produtos com essa viso apresentada a seguir.
2.4. O DESENVOLVIMENTO DE PRODUTOS COMO PROCESSO

Segundo a definio utilizada neste trabalho, ES uma filosofia utilizada no
processo de desenvolvimento de produtos. importante ento definir o que um
processo e tambm o desenvolvimento de produtos de acordo com esta viso de
processos.
Segundo DAVENPORT (1994, p. 6), processo simplesmente um conjunto
de atividades estruturadas e mtricas destinadas a resultar num produto especifico
para um determinado cliente ou mercado.
De outra maneira, processo de negcio um fenmeno que ocorre dentro
das empresas. Ele contm um conjunto de atividades, associadas s informaes que
manipula, utilizando os recursos e a organizao da empresa. Forma uma unidade
coesa e deve ser focalizado em um tipo de negcio, que normalmente est
Rogerio Omokawa
33
direcionado a um determinado mercado/cliente, com fornecedores bem definidos

(Figura 11) (ROZENFELD, 1996, p.27).
Fornecedor
Informao
Processo de
Negcio
Atividades
Cliente
Informao
Organizao
Recursos
Figura 11: Definio de Processo de Negcio
Fonte: ROZENFELD, 1996, p.37
Segundo ROZENFELD (1996), a viso da empresa por processos de negcio
facilita o gerenciamento de recursos, pois fornece uma viso sistemtica destes
recursos, mostrando quais recursos so compartilhados por mais de um processo.
Com base na viso por processos de negcio, CLARK & FUJIMOTO (1991,
p.20) definem o desenvolvimento de produtos como: o processo pelo qual uma
organizao transforma dados sobre oportunidades de mercado em informaes para
a fabricao de um produto comercial.
A viso por processos auxilia tambm na obteno de uma viso global da
empresa, ROZENFELD (1996) chama esta viso global de viso holstica.
Segundo ele, a viso holstica de uma empresa eqivale a se ter uma imagem
nica, sinttica de todos os elementos da empresa, que normalmente podem ser
relacionados a vises parciais abrangendo suas estratgias, atividades, informaes,
recursos e organizao, assim como suas inter-relaes (Figura 12). Como recursos
deve-se entender os recursos financeiros que a empresa utiliza, seus equipamentos de
produo e de trabalho, os mtodos e tcnicas empregadas, hardware, software, etc.
Rogerio Omokawa
34
O conceito de organizao aqui empregado mais abrangente do que o normalmente

conhecido. Ele considera a estrutura organizacional e suas inter-relaes, a sua
cultura, as pessoas e sua qualificao, as formas de comunicao, assim como a
capacidade de aprendizado da organizao (ROZENFELD, 1996, p. 25).
Estratgias
Atividades
Recursos
tcnicas/mtodos
equipamentos
hardware
software
rec. financeiros
Informaes
Organizao
estrutura
cultura
aprendizagem
pessoas
Figura 12: Viso Holstica da Empresa

Fonte: ROZENFELD, 1996, p.36
Segundo o mesmo autor, com a viso holstica as decises tomadas relativas
a uma viso se tornam mais seguras, pois a influncia desta deciso sobre as outras
vises so observadas em primeiro lugar. Esta caracterstica muito importante
durante a implantao da ES, pois esta filosofia influencia todas estas vises parciais.
Deste modo problemas especficos durante a implantao da ES podem ser
discutidos sem a perda da abrangncia. No entanto, impossvel representar o todo
de forma completa. Este todo algo abstrato, que forma uma unidade na mente dos
dirigentes (ROZENFELD, 1996, p.25). Com esta viso holstica, podem ser
identificados alguns aspectos importantes para a implantao da ES.
Um dos grandes problemas levantados (SYAN, 1994; CARTER & BAKER,
1992) o gerenciamento dos dados no ambiente de engenharia simultnea. Para
SYAN (1994), como citado no item 2.3.1.1, esta comunicao envolve as pessoas, a
Rogerio Omokawa
35
troca de dados entre os sistemas utilizados tais como CAD/CAM e a documentao e

gerenciamento das informaes e das decises realizadas (talvez a atividade mais
importante do time multidisciplinar), para que possam ser recuperadas sempre que
necessrio.
Para CARTER & BAKER (1992) todas as informaes relevantes da
empresa devem ficar disponveis para quando os membros do time necessitarem.
Neste contexto, mesmo com a utilizao da abordagem por processos e da viso
holstica, que ajuda a identificar os problemas e as relaes com outras vises, este
um grande desafio a ser resolvido.
A seguir so mostradas algumas necessidades de gerenciamento de dados em
ambientes que utilizam a filosofia de ES.
2.5. NECESSIDADES
DE
GERENCIAMENTO
DE
DADOS
EM
UM
AMBIENTE DE ENGENHARIA SIMULTNEA

Segundo AFSARMANESH et al. (1994), o principal requisito da abordagem
de engenharia simultnea a disponibilidade de todos os dados relacionados a
qualquer atividade do ciclo de vida do produto, para todos os membros do time que
necessitem acess-los.
As necessidades de gerenciamento dos dados do produto dependem muito das
caractersticas da empresa na qual o ambiente de engenharia simultnea funciona.
Muitas destas necessidades so aplicveis tambm ao desenvolvimento de produtos
seqencial, mas que se tornam muito mais importantes em um ambiente de
engenharia simultnea. So apresentadas a seguir algumas dessas necessidades,
segundo SHEDLER (1994):
fornecer um mtodo de acesso, para garantir que os dados acessados sejam

completos, consistentes e protegidos contra modificaes no autorizadas em
cada estgio de ciclo de desenvolvimento de produtos;
Rogerio Omokawa
36
gerenciar relacionamentos entre os dados, para que se possa saber onde as

modificaes foram realizadas e quais outros dados foram afetados;
recuperar dados para o desenvolvimento de produtos, para reduzir o time to

market e reduzir o custo de desenvolvimento;
gerenciar todos os tipos de dados, no s uma pequena poro que armazenada

no computador;
possuir gerenciador de arquivos, para que os arquivos de dados possam ser

criados e manipulados em um rede de computadores sem que o usurio tenha que
saber onde o arquivo est localizado ou que sintaxe o computador usa;
suportar uma estrutura hierrquica de arquivos e peas;
permitir ao usurio encontrar dados com base em informaes de engenharia

(nmero da pea, data de criao de um desenho, etc.);
permitir cpias de segurana, arquivamento e recuperao dos dados;
utilizar padres adotados pela empresa (unidades de medida, bordas de desenho,

etc.);
suportar controle de reviso e verso dos documentos;
visualizar os documentos em formatos padres (GIF, processador de texto, CAD,

etc.)
possibilitar comentar o documento com texto e grficos eletronicamente, e sem

alterar o documento original;
Segundo COSTA (1994), as necessidades de gerenciamento so:
compartilhar a base de conhecimento: armazenar o conhecimento de vrios

projetos existentes na empresa com o intuito de evitar erros j cometidos e
estender os acertos para toda linha de produtos;
Rogerio Omokawa
37
compartilhar os dados grficos: desenhos de detalhe, modelos tridimensionais,

imagens de representao de anlise de engenharia, etc.
Segundo TAVARES et al. (1994), as necessidades de gerenciamento so:
disponibilizar as informaes geomtricas e tecnolgicas para todas as atividades

que necessitarem;
proteger as informaes.
Segundo HITCHINS (1994), as necessidades de gerenciamento so:
cadastrar e relacionar peas e componentes;
localizar onde os componentes so utilizados (where-used);
listar quais componentes so utilizados em cada montagem (composed off);
possibilitar a criao de estruturas de produto a partir dos dados cadastrados;
possibilitar a criao de estruturas de produtos alternativas para uma mesma

pea;
gerenciar informaes de montagem;
permitir vrias vises da estrutura de produto;
possibilitar a localizao de componentes semelhantes para serem utilizados em

projetos atuais;
possibilitar o congelamento dos documentos, impedindo a alterao, em vrios

estgios do desenvolvimento, para permitir que possam ser examinados;
mostrar o impacto de alteraes ocorridas em documentos do projeto. Por

exemplo, indicar quantos componentes e quantos projetos sero alterados com
alteraes em um desenho de componente.
Rogerio Omokawa
38
Segundo SYAN (1994), os sistemas de gerenciamento de dados de produto

so essenciais para gerenciar os dados em um ambiente de engenharia simultnea.
Muitas empresas utilizam estes sistemas para suprir as necessidades de
gerenciamento de dados apresentadas.
No prximo captulo os sistemas de gerenciamento de dados, o mercado, as
formas de implantao e os benefcios da utilizao destes sistemas, bem como as
funcionalidades desses sistemas, utilizadas para o gerenciamento de dados e de
processos, sero detalhados.
Rogerio Omokawa
39
3. GERENCIAMENTO DE DADOS DE PRODUTO
Um dos maiores desafios para a implantao bem sucedida da engenharia

simultnea o gerenciamento de todos os dados relativos ao produto, pois com o uso
desta filosofia os dados podem ser utilizados, se que estejam completos, nos estgios
iniciais do desenvolvimento (PRASAD, 1996). Alm disso necessrio que estes
dados estejam disponveis sempre que necessrio, pois de 40% a 50% do tempo de
desenvolvimento gasto na comunicao e na transmisso de informaes
(WARNECKE & ZEIHSEL, 1995).
Os sistemas de gerenciamento de dados de produto, conhecidos como
sistemas PDM (product data management), tm sido considerado como uma das
melhores solues para superar o desafio de gerenciar dados e processos durante o
processo de desenvolvimento de produtos.
Neste captulo so apresentados o histrico dos sistemas PDM, suas
terminologias, suas principais funcionalidades, o mercado desses sistemas, as
estratgias para implantao e os benefcios da implantao deste tipo de sistema.
3.1. HISTRICO
Nas ltimas dcadas as empresas de manufatura fizeram investimentos
significativos em automao de vrios processos do ciclo de vida dos produtos.
Infelizmente, o uso de softwares para suportar cada uma destas tecnologias resultou
em ilhas de automao que podem ser caracterizadas por (DICKERSON, 1996):
manuteno de sistemas computacionais incompatveis entre si e que

normalmente so desenvolvidos e suportados por diferentes fornecedores para
Rogerio Omokawa
40
finanas, engenharia, controle de verso do produto, planejamento do processo,

etc.;
necessidade de se manter pelo menos duas estruturas de produto devido a falta de

integrao de dados e sistemas, uma estruturada de acordo com as necessidades
da engenharia e a outra de acordo com as da manufatura;
gerao de uma grande quantidade de dados de projeto em um curto perodo de

tempo, que torna o controle manual destes dados extremamente difcil, se no
impossvel; e
proliferao e manuteno de conversores para troca de dados entre sistemas

incompatveis.
Durante a dcada de 80, as empresas sentiram a necessidade de um
gerenciamento mais eficiente dos dados e da estrutura de produto e da automao das

ordens de alterao de engenharia (ECO engineering change order).
Devido falta de sistemas comerciais disponveis, estas empresas foram
foradas a desenvolver solues internamente. Estas solues se originaram na
engenharia, com o objetivo de armazenar os arquivos em um local seguro, rastrear os
trabalhos em processo, e expedir revises e aprovaes de alteraes de engenharia
(DICKERSON, 1996).
No final dos anos 80 muitos fornecedores de software, conscientizando-se
da necessidade e das oportunidades de negcio associadas ao desenvolvimento de
sistemas PDM, introduziram a primeira gerao comercial destes sistemas. Alguns
destes fornecedores ofereceram sistemas PDM independentes de outros softwares de
engenharia. Entretanto, a maior parte j estava no negcio de vendas de softwares
CAD/CAE/CAM (projeto, engenharia e manufatura auxiliada por computador), e
percebendo os problemas de gerenciamento de dados, comearam a adicionar o
sistema PDM sua linha de produtos. Eles tipicamente focaram as vendas de
sistemas PDM aos clientes que j utilizavam seus sistemas CAD/CAE/CAM
(HOW, 1996, p.1).
Rogerio Omokawa
41
Esta primeira gerao de sistemas PDM foi desenvolvida para reforar

procedimentos de engenharia (HOW, 1996), controlando apenas documentos e
processos bem definidos, como por exemplo o ciclo de aprovao de desenhos.
Recentemente, entretanto, outras reas do ciclo de vida do produto tm sido
alvo de melhorias, sendo que a diminuio do time-to-market o maior objetivo de
grande parte das empresas. Para auxiliar na melhoria dessas reas, foi desenvolvida
uma segunda gerao de sistemas PDM, que suporta todo o ciclo de vida do produto
- desde a concepo inicial at a obsolescncia do produto. Eles suportam prticas de
engenharia simultnea tanto em uma fase conceitual do projeto, quanto em um
processo de alterao de engenharia bem definido (HOW, 1996).
Atualmente, sistemas PDM so ferramentas que gerenciam todos os dados e
processos relacionados ao produto, durante todo o ciclo de vida (HOW, 1996).
3.2. TERMINOLOGIA
Segundo PIKOSZ (1997, p.8), PDM define os processos que so utilizados
para transmitir e gerenciar dados do produto que so criados e detalhados em
diferentes reas da empresa.
J sistemas PDM referem-se a sistemas que possuem funes para organizar,
acessar e controlar todos os dados relativos a um produto, e gerenciar o ciclo de vida
do produto. Estes sistemas podem trabalhar com uma grande variedade de softwares
e com sistemas tradicionais, no computacionais, que geram ou usam dados do
produto, tais como, documentos em papel. O sistema tambm pode trabalhar com
uma combinao de computadores, estaes de trabalho, e hardware associados
(MILLER et al., 1994, p.6)
Para DICKERSON (1996), sistemas PDM so aqueles que integram e
gerenciam os processos, aplicaes, e informaes que definem os produtos ao longo
de sistemas distribudos e vrias mdias na empresa. Sistemas PDM incorporam
Rogerio Omokawa
42
todas as informaes relativas ao produto, incluindo documentos impressos,

documentos eletrnicos, arquivos digitais e registros de banco de dados.
Ao longo do desenvolvimento dos sistemas de gerenciamento de dados
surgiram diversas terminologias, tais como: product data management (PDM),
engineering data management (EDM), engineering document management (EDM),
electronic data management (EDM), product information management (PIM),
computer integrated and program information management (PIM), technical data
management (TDM) e outras (MILLER et al., 1994).
O CIMDATA (1996) e DICKERSON (1996) utilizam o termo product data
management ou PDM como um termo amplo, que engloba todos os conceitos das
terminologias acima (Figura 13).
Product Data Management

(PDM)
Engineering Data Management
Engineering Document Management
Computer Integrated and Program Information Management
Electronic Data Management
Technical Data Management
Figura 13: Product Data Management

J SWANTON (1997) utiliza dois termos para identificar os sistemas de
gerenciamento de dados: electronic document management (EDM) e product data
management (PDM) (Figura 14). A diferena entre os dois termos est nas reas
englobadas por cada um deles.
Rogerio Omokawa
43
Projeto
PDM
Ger. configuraes
Ger. projeto
Produto
Manufatura
EDM
Processo de ECO
Dados de processo
Dados de fornecedores
Estrutura de produto
Dados de produto
em processo
Integrao com CAD
Manuais
ia
ec
p
Es
Gerenciamento de Documentos
a
liz
Docs. gerais
Cofre, Busca, Visualizao e Fluxo de Trabalho
Figura 14: reas Funcionais de PDM e EDM

Com Base em SWANTON, 1997, p.10
Como mostrado na Figura 14, existe uma base comum de gerenciamento de

documentos entre os sistemas PDM e EDM, e existe tambm uma diviso de reas
funcionais em quatro grupos. Os sistemas EDM so aqueles que englobam as reas
de manuais e da manufatura. J os sistemas PDM englobam as reas de projeto, do
produto e da manufatura, existindo uma sobreposio dos sistemas na rea de
manufatura.
As descries da base comum e das reas funcionais so realizadas a

seguir:
gerenciamento de documentos: a base comum a ambas as terminologias e se

refere a funes bsicas para organizar e controlar arquivos. includa aqui a
funcionalidade de cofre de dados, que armazena e controla as modificaes dos
documentos. A maioria dos sistemas inclui tambm uma infra-estrutura para
montar fluxos de trabalho, que entre outras funes controlam o roteamento dos
documentos na empresa (SWANTON, 1997);
Rogerio Omokawa
44
manuais: so funcionalidades que gerenciam o material de marketing e

publicaes tcnicas, alm de procedimentos da empresa e manuais on-line
(SWANTON, 1997);
manufatura: cobre as atividades de fabricao do produto, incluindo aplicaes

de fluxo de trabalho para liberar as informaes do produto para a manufatura,
criao de planos de processo, etc. Alm de disponibilizar dados para os
fornecedores. (SWANTON, 1997);
produto: o domnio da engenharia. Os dados gerenciados normalmente so

desenhos que esto sendo trabalhados. Esto includos aqui integrao com
sistemas CAD e gerenciamento da estrutura de produto. Algumas ferramentas
como visualizao 3D, ajudam a simular a montagem virtual das peas
(SWANTON, 1997);
projeto: uma rea utilizada apenas para produtos complexos, como por
exemplo aeronaves, navios, etc., quando um gerenciamento de projetos detalhado
necessrio. O status de cada desenho individual controlado de acordo com
prazos, para garantir que o projeto seja cumprido no tempo estipulado. Alm
disso, informaes detalhadas do gerenciador de configuraes (por exemplo,
vrias vises da estrutura de produto) so geradas e podem ser mantidas devido a
normas, manuteno do produto, ou por motivos de contrato (SWANTON,
1997).
Neste trabalho utiliza-se o termo PDM (product data management) utilizado
por SWANTON (1997) (Figura 14).
3.3. FUNCIONALIDADES DE SISTEMAS PDM

As funcionalidades de sistemas PDM variam muito de sistema para sistema,
existindo desde sistemas com apenas funcionalidades de cofre de dados e fluxo de
trabalho, que gerenciam apenas documentos de sistemas CAD at sistemas com
Rogerio Omokawa
45
todas as funcionalidades, e que gerenciam vrios tipos de dados. O CIMDATA

(1996) e DICKERSON (1996) definem como funcionalidades dos sistemas PDM:
Principais Funcionalidades
cofre (vault) de dados;
fluxo de trabalho (workflow) e gerenciamento de processos;
gerenciamento da estrutura do produto/gerenciamento de configurao;
classificao e recuperao;
gerenciamento de projetos;
Funcionalidades de Apoio
comunicao e notificao;
transporte de dados;
converso de dados;
servios de visualizao e comentrio (markup);
administrao.
A seguir cada uma destas funcionalidades ser detalhada.
3.3.1. Cofre de Dados

O cofre de dados (vault) e a base de dados, responsveis pelo
gerenciamento de documentos, so o ncleo dos sistemas PDM (PIKOSZ, 1997). A
base de dados gerencia os meta-dados (dados sobre os dados), e o cofre
responsvel pela segurana, controle e armazenamento dos dados (Figura 15)
Rogerio Omokawa
46
gerenciados pelo sistema PDM (CIMDATA, 1996). Estes dados podem incluir a
combinao de (MILLER et al., 1994):
dados produzidos por sistemas CAD, CAM, CAE ou outros sistemas de

engenharia ou manufatura;
dados produzidos por aplicativos de escritrio (processador de texto, planilha

eletrnica, etc.);
referncias para dados no digitais ou outros dados externos;
dados gravados em um sistema gerenciador de base de dados;
formulrios eletrnicos como ordens de alterao de engenharia (ECO).
Item 2
Item 7
Item 3 Item 8
Item1
Item 4
Item 5
Metadados
1 facear
2 desbastar
3 retificar
G01 07 67
G97 46 83
D26 95 21
Controle de Acesso
Vault
Figura 15: Funcionamento do Cofre de Dados

Todos esses dados e documentos so colocados sob controle do cofre por
um mecanismo conhecido como check-in, que pode ser utilizada na criao,
atualizao e aprovao. Dados ou arquivos que so reincorporados depois de terem
sido modificados podem ser mantidos como uma nova verso ou como uma nova
reviso, mantendo o original ou verso anterior intacta para futura consulta, caso
necessrio ( MILLER et al., 1994).
Rogerio Omokawa
47
Existe tambm o mecanismo de check-out, que utilizado quando o usurio

necessita de um dado ou arquivo que j est sob controle do cofre. O check-out de
dados pode ser requisitado, desde que o usurio possua permisso (Figura 15).
Quando realizado o check-out de um documento, o sistema PDM informa a
qualquer outro usurio que tente utilizar este documento que uma alterao est em
progresso e no permite que outro usurio altere simultaneamente o mesmo
documento, gerando incompatibilidades (PIKOSZ & MALMQVIST, 1996).
Alm disso o cofre mantm um histrico de todos os dados, com
informaes de quando e por quem esses dados foram acessados.
3.3.2. Fluxo de Trabalho e Gerenciamento de Processos

Conforme GEORGAKOPOULOS et al. (1995), fluxo de trabalho (workflow)
uma coleo de atividades organizadas de modo a realizar um processo. Uma
atividade pode ser executada por um ou mais sistemas de software, um ou mais
grupos de pessoas, ou uma combinao desses.
Desenhar
Componente
Calcular
Componente
Detalhar
Componente
Aprovar
desenho
Figura 16: Fluxo de Trabalho de Aprovao de Desenhos

A funcionalidade de fluxo de trabalho e gerenciamento de processos definem
e implementam automatizaes de processo e fluxos de trabalho, como por exemplo
Rogerio Omokawa
48
o fluxo de aprovao de desenhos (Figura 16) no processo de desenvolvimento de

produtos (CIMDATA, 1996).
3.3.3. Gerenciamento da Estrutura de Produto/Gerenciamento de Configurao

A funcionalidade de gerenciamento da estrutura de produto cria e mantm as
montagens, as configuraes do produto, as estruturas de produto (BOM bill of
material) e todos os elementos gerenciados pelo sistema PDM relativos a esta
estrutura. Esta funcionalidade deve fornecer mecanismos para permitir ao usurio
encontrar facilmente informaes relacionados com peas e estruturas de produto
(MILLER et al., 1994).
Muitos sistemas PDM oferecem a capacidade de se definir vrias vises de
uma mesma estrutura de produto. O usurio escolhe qual das vises (viso
funcional, viso de montagem, etc.) ele deseja ver apresentada (Figura 17). O sistema
PDM mantm estas vises a partir de uma nica estrutura de produto, mantendo a
integridade da estrutura (MILLER et al., 1994).
O sistema pode permitir ainda que o usurio defina peas alternativas,
substitutas e opcionais na mesma estrutura. Esta capacidade permite reduzir o
nmero de estruturas de produto a serem criadas e um melhor gerenciamento de
alteraes destas estruturas.
Rogerio Omokawa
49
Vista Funcional
corpo
corpo
reservatrio
reservatrio
carga
carga
regulagem
regulagem
tinta
tinta
caneta
caneta
reforo
reforo
ponta
ponta
Vista de Montagem
cilindro
inferior
cilindro
inferior
cilindro
superior
ponta
do
cilindro
tubo
tinta
ponta
metlica
ponta do
cilindro
reteno
reteno
no
nobolso
bolso
grampo,
bolso
aparncia
aparncia
faixa
decorativa
montagem
montagem
cilindro
cilindro
inferior
inferior
faixa
decorativa
ponta
metlica
tubo
tinta
cilindro
superior
grampo,
bolso
caneta
caneta
montagem
montagem
refil
refil
montagem
montagem
cilindro
cilindro
superior
superior
Figura 17: Viso Funcional x Viso de Montagem

Com Base em MILLER et al., 1994, p.22
O sistema tambm pode permitir relacionamentos entre peas (Figura 18), de
peas com documento (Figura 19), de peas com reviso e documentos e
combinaes destes relacionamentos (Figura 20).
Rogerio Omokawa
50
Figura 18: Estrutura do Produto - Relacionamento entre Peas

Fonte : MILLER et al., 1994, p.26
Desenho de detalhamento
FONE
Relatrio de testes
Dados de marketing
Figura 19: Estrutura do Produto - Relacionamento Pea - Documento

Fonte: MILLER et al., 1994, p.26
Rogerio Omokawa
51
Reviso A
Reviso B
Reviso C
FONE
Rev. A
Desenho
de detalhamento
Rev. B
Rev. A
Rev. B
Relatrio de testes
Dados de marketing
Figura 20: Combinao de Todas as Formas de Estrutura de Produto

Fonte: MILLER et al. , 1994, p.27
3.3.4. Classificao e Recuperao

Na classificao so associados atributos (por exemplo material, fornecedor,
no caso de peas) aos componentes (peas, documentos, etc.), para que itens
similares possam ser agrupados de modo que eles possam ser posteriormente
recuperados. A funcionalidade de classificao/recuperao utilizada para localizar
documentos, peas, componentes padres, processos e objetos (CIMDATA, 1996).
Na classificao/recuperao de peas, cada pea possui sua prpria lista de
atributos, por exemplo: material, fornecedor, etc. Atravs destes atributos so
realizadas as recuperaes, por exemplo, de peas similares.
Os documentos podem ser classificados da mesma forma para especificar o
tipo de documento. As classes de documentos podem incluir especificao de
venda, desenho, modelo slido, etc. Cada documento pode ter atributos como,
autor, revisor, verso, etc.
Rogerio Omokawa
52
Um exemplo de classificao dado pela Figura 21, onde a classificao

realizada em trs nveis. No primeiro nvel, o sistema divide a populao heterognea
em classes de objetos com caractersticas similares (por exemplo: peas prismticas,
peas rotacionais, etc.).
peas prismticas
chapas
paraleleppedos
peas rotacionais
discos
engrenagens
eixos
Atributos
material = SAE 8640
n. escalonamentos = 3
dimetro maior (mm) = 50
comprimento (mm) = 120
Descritores
caractersticas adicionais e
comentrios
Classificao: estrutura da populao de objetos

Atributos: comparao entre objetos
Descritores: especificados para cada objeto
Figura 21: Sistema de Classificao de 3 Nveis

Fonte: OLIVEIRA, 1998, p.35
Esse agrupamento de objetos similares possibilita que sejam relacionados, no
segundo nvel, os atributos especficos de cada classe. O eixo possui como atributos
o material, o nmero de escalonamentos, a dimenso do dimetro maior e o
comprimento. Se fosse uma chapa, existiriam atributos diferentes, como a espessura.
Por meio desses atributos, possvel comparar objetos de uma mesma classe durante
a recuperao de informaes, bem como utilizar ferramentas refinadas de busca
como funes de filtro (igualdades, desigualdades e operadores booleanos),
selecionando-se assim o melhor para a aplicao desejada (OLIVEIRA, 1998).
Rogerio Omokawa
53
De acordo com as especificaes que representam, os atributos podem

assumir valores numricos discretos ou strings (cadeias de caracteres), ou ainda ser
um flag do tipo TRUE/FALSE (OLIVEIRA, 1998).
No terceiro e ltimo nvel, encontram-se os descritores, os quais permitem
que caractersticas adicionais e comentrios sejam atribudos ao objeto (OLIVEIRA,
1998).
O CIMDATA (1996) pondera que a implantao do sistema de classificao
pode ser facilitada com a utilizao de bibliotecas padres para objetos considerados
commodities (componentes eletrnicos, tubos e conexes, rolamentos, ferramentas
para usinagem, etc.), as quais so fornecidas pelos prprios fornecedores ou pelas
normas de padronizao (DIN, ISO, SAE, etc.).
3.3.5. Gerenciamento de Projetos

Atualmente todos os sistemas PDM fornecem somente a mnima
funcionalidade de gerenciamento de projetos, como por exemplo informaes sobre
o status das tarefas. Normalmente a capacidade de manipular o agendamento de
recursos e analisar o caminho crtico das atividades fornecida por outros sistemas
comerciais de gerenciamento de projeto e que so integrados ao sistema PDM
(MILLER et al., 1994).
3.3.6. Comunicao e Notificao

Comunicao de aplicativos para o envio de mensagens, imagens, arquivos e
outros dados uma das funcionalidades mais importantes do sistema PDM e a base
para a criao de ambientes de engenharia simultnea. Esta funcionalidade permite
aos usurios serem notificados, manualmente ou automaticamente, quando eles
possuem uma tarefa a ser realizada (como uma reviso ou aprovao de um desenho,
por exemplo) ou quando existe uma alterao proposta ou implementada, que pode
provocar um impacto nos dados que o usurio estiver utilizando (MILLER et al.,
Rogerio Omokawa
54
1994). Como por exemplo a mudana dimensional de uma pea, que causa mudanas
em todo o conjunto.
Alguns sistemas PDM tm seu prprio sistema de e-mail para informar aos
usurios quando uma nova reviso est pendente ou uma verso foi aprovada. Outros
sistemas PDM utilizam sistemas de e-mail de terceiros ao invs de utilizar um
sistema proprietrio. Esta funcionalidade trabalha em conjunto com a funcionalidade
de fluxo de trabalho, vista anteriormente.
3.3.7. Transporte de Dados

Normalmente, sistemas PDM fornecem funcionalidades de transporte de
dados para que os usurios finais, que acessam as informaes, no necessitem saber
onde a informao est fisicamente e como mover estes dados. Com a ajuda de
sistemas PDM, o usurio pode escolher os dados a serem transportados (atravs de
parmetros) e informar o sistema PDM para onde ele quer que os dados sejam
movidos (por exemplo para o cofre de dados de um outro projeto).
O sistema PDM isola os usurios dos comandos dos sistemas operacionais e
da rede. O transporte de dados ocorre da seguinte forma: um usurio localiza o dado
desejado utilizando mtodos de procura do sistema, depois o dado transportado
(checked out) do cofre do PDM para o local desejado (como por exemplo o espao
de trabalho do usurio) (MILLER et al., 1994).
Um exemplo do uso desta funcionalidade o trabalho de um time
multidisciplinar geograficamente distribudo. No importa que o usurio esteja
localizado geograficamente longe do cofre de dados, ele pode escolher qual dado
ele necessita e realizar uma cpia para sua rea de trabalho, sem necessitar saber
onde o dado est fisicamente localizado (Figura 22).
Rogerio Omokawa
55
Cpia
cofre de dados
rea de trabalho
do usurio
Figura 22: Transporte de Dados

A funcionalidade de transporte de dados pode suportar as seguintes
operaes:
copiar ou mover arquivos requisitados pelo usurio;
copiar ou mover arquivos automaticamente, quando apropriado (em resposta a

um evento);
enviar arquivos para um usurio com agendamento prvio.
3.3.8. Converso de Dados

Sistemas PDM gerenciam arquivos produzidos por diferentes aplicativos.
Estes arquivos quando so transportados de um aplicativo para outro freqentemente
devem ser convertidos para formatos diferentes ou para um formato neutro.
Esta converso pode ser realizada de maneira automtica pelo sistema PDM
ou pode ser realizada pelo usurio, quando necessrio (MILLER et al., 1996).
Rogerio Omokawa
56
Segundo BARRA1 apud AGUIAR (1995), foram desenvolvidos vrios

padres para troca de dados, tais como IGES (Initial Graphics Exchange
Specification - EUA), SET (Standard dEchange et de Transfert Frana ) e VDAFS (Verband der Deutschen Automobilindustrie-Flchenschnittstelle Alemanha).
Porm vrias deficincias foram
encontradas atravs do uso destes padres,
podendo-se destacar:
as ambigidades de suas definies;
restries no que se refere ao escopo de dados de produtos representados;
inflexibilidade no que concerne forma de implementao;
falta de procedimentos para verificao de conformidade;
ineficincia e impreciso das implementaes.

Para que estas deficincias fossem supridas, foi criado o STEP (Standard for
the Exchange of Product Model Data). O STEP (ISO 10303) um padro

internacional de troca e representao de dados do produto, cujo objetivo fornecer
um mecanismo neutro capaz de descrever os dados do produto ao longo do ciclo de
desenvolvimento do produto, independente do tipo de sistema (TAVARES, 1994).
Esses dados poderiam estar armazenados em arquivos e ou em bancos de dados
compartilhados.
A utilizao do padro STEP permitir aos sistemas PDM gerenciarem
melhor todas as informaes relativas ao ciclo de vida do produto, alm de permitir a
estes sistemas funcionarem como ferramentas de troca e distribuio de dados
(DICKERSON,1996).
BARRA, R.A. (1994). On the implementation of systems for realistic visualization of STEP
models. Berlim. Tese (Doutorado) Universidade Tcnica de Berlim apud AGUIAR, A.F.S.
(1995). Sistemtica de seleo de sistemas computacionais para o auxlio s atividades de
engenharia. So Carlos. 139p. Dissertao (Mestrado) - Escola de Engenharia de So Carlos,
Universidade de So Paulo. p.16
Rogerio Omokawa
57
3.3.9. Servios de Visualizao e Comentrios (markup)

Fornece ao usurio a capacidade de visualizar, de realizar comentrios e de
converter imagens de um padro para outro. Os servios de imagem possuem
(CIMDATA, 1996):
suporte para visualizao de vrios padres de arquivos como: PDES/STEP,

IGES, DXF, HPGL e TIFF;
visualizador de arquivos CAD incorporado ao sistema, para os sistemas CAD

mais populares;
integrao com sistemas de visualizao produzidos por terceiros.

A funo de comentrio permite ao usurio fazer observaes ou anexar notas
para outros usurios em um arquivo, sem mudar o contedo original do arquivo. Um

exemplo dado na Figura 23, onde comentrio para especificar as tolerncias no
desenho do eixo feito em vermelho, sendo que o comentrio s visvel para o
projetista que realizar as correes.
Figura 23: Desenho do CAD com Comentrio
Rogerio Omokawa
58
3.3.10. Administrao
As funcionalidades de administrao incluem suporte para definir e manter
meta-dados, gerenciar as autorizaes dos usurio, e gerenciar arquivamentos e
backups (MILLER et al., 1994).
Alguns exemplos de meta-dados incluem: identificao do criador do dado
gerenciado; cdigo de identificao do fornecedor, no caso de peas compradas; e
verses de desenhos.
As autorizaes de usurio incluem desde as opes de ler, escrever, copiar e
editar associados a sistemas operacionais de computadores, at o acesso para a
alterao de processos da empresa. Alm disso, alguns sistemas PDM fornecem
funes para manuteno de redes, backup e recuperao de informaes (MILLER
et al., 1994).
3.4. MERCADO DE SISTEMAS PDM

Os sistemas PDM, apesar de serem uma tecnologia recente se comparada
outras ferramentas computacionais de apoio (sistemas CAx), tm apresentado um
expressivo crescimento nos ltimos anos. De acordo com o relatrios do CIMdata o
mercado mundial de PDM cresceu 31% em 1996 (CIMDATA, 1997) e 22% em
1997, chegando a $1,1 bilhes, e h expectativas de que o mercado cresa 18% por
ano at o ano 2000, chegando a $2,5 bilhes (CIMDATA, 1998).
O maior segmento de mercado a Amrica do Norte com 44% de
participao em 1996, apesar da diminuio da participao que era de 55% em
1995. Os investimentos europeus representaram 38% do mercado mundial em 1996,
contra 33% em 1995. Enquanto que a participao Asitica, impulsionada pelas
vendas Japonesas, passaram de 12% em 1995 para 18% em 1996 (Figura 24). No
foram encontrados dados sobre o mercado deste tipo de sistema no Brasil/Amrica
Latina.
Rogerio Omokawa
59
Participao
Mundial (%)
60
1995
1996
50
40
30
20
10
0
Amrica do Norte
Europa
sia
Regio
Figura 24: Mercado Mundial de Sistemas PDM

A partir dos dados apresentados pode-se notar que existe um crescimento
global do mercado de sistemas PDM, e tambm um aumento do uso desses sistemas
em diferentes mercados, principalmente o asitico (Figura 24). Neste mesmo
relatrio so apresentados os lderes do mercado de PDM:
Rogerio Omokawa
60
Tabela 1: Participao de Mercado das Principais Empresas Produtoras de

Sistemas PDM em 1996
Fonte: CIMDATA, 1997, p.2
Empresa
Participao no
mercado
Computervision
8%
Metaphase Technology
7%
IBM
6%
Documentum
5%
Intergraph
4%
Sherpa
4%
Formtek
4%
EDS/Unigraphics
3%
Altris Software
3%
NEC
3%
Rogerio Omokawa
61
J segundo SWANTON (1997) o mercado dividido da seguinte forma:

Fonte: SWANTON, 1997, p.7
Empresa
Computervision2
16%
Documentum
9,7%
Formtek
9%
Sherpa
9,4%
SDRC3
8,3%
Hewlett-Packard
5,5%
Intergraph
3,8%
Interleaf
Participao no
mercado
3%
EDS/Unigraphics
2,8%
NovaSoft
2,7%
Workgroup Technology
2,6%
IBM
2,4%
Cimage
2,1%
Adra
1,6%
Incluindo rendimentos associados ao visualizador de CAMU (Computerized Assembly
Mock-UP)
3
Inclui rendimentos de PDM de 1996 da Control Data Corp. (CDC), adquirida pela SDRC
Rogerio Omokawa
62
Empresa
Participao no
mercado
Consensys
1%
Applicon
0,7%
Autodesk
0,7%
Agile
0,3%
Matra Datavision
0,3%
Outros
18,2%
No relatrio de 1997 do CIMdata (CIMDATA, 1998) foi apresentado

algumas alteraes na participao do mercado de sistemas:
Fonte: CIMDATA, 1998, p.8
Empresa
Participao no
mercado
Metaphase Technology
7%
IBM
6%
Documentum
5%
EDS/Unigraphics
5%
Intergraph
4%
Aspect Development
4%
Sherpa
4%
Parametric Technology Corp.
3%
Computervision Corp.
3%
Rogerio Omokawa
63
Empresa
Participao no
mercado
Siemens
2%
A partir da anlise da participao dos maiores fornecedores, possvel

tambm notar que o mercado no dominado por uma nica empresa , sendo que as
10 maiores dominam aproximadamente 50% do mercado e o restante do mercado
dividido entre dezenas de outras empresas (Tabela 1, Tabela 2 e Tabela 3).
Alm disso, segundo o CIMdata (CIMDATA, 1998), o mercado de sistemas
PDM possui uma grande segmentao, que tende a aumentar no futuro, sendo que
cada segmento possui fornecedores especficos. Alguns fornecedores focam em
vendas de sistemas com muitas funcionalidades, enquanto que outros se concentram
em
funcionalidades
especficas
tais
como
gerenciamento
de
documentos/componentes ou ainda fluxo de trabalho.

Existe a tendncia de ocorrerem compras de empresas produtoras de sistemas
PDM por outras do setor, como por exemplo a compra da Computervision pela
Parametric Technologies em 1997 e tambm de acordos para combinar as
tecnologias desenvolvidas por duas ou mais empresas. Outra tendncia tambm a
entrada de fornecedores de sistemas ERP (Enterprise Resource Planning) no mercado
de sistemas PDM (CIMDATA, 1998).
3.5. ESTRATGIAS DE IMPLANTAO A PARTIR DE COMPLEXIDADES

TCNICAS
Segundo PIKOSZ et al. (1997), existem quatro nveis de complexidade na
implantao de sistemas PDM (Figura 25). No nvel mais simples est a
implantao/funcionamento do cofre de dados e do gerenciamento de documentos,
num segundo nvel esto o gerenciador do fluxo de trabalho e da estrutura de
produto, num terceiro nvel esto as funcionalidades de interface com outros sistemas
de tecnologia da informao (TI), e no nvel mais complexo est o suporte para todo
Rogerio Omokawa
64
o ciclo de vida do produto, no qual todos os dados so gerenciados desde o conceito
nvel de complexidade
do produto at a obsolescncia.
suporte para todo o

ciclo de vida
comunicao com outros
sistemas de TI
gerenciamento do gerenciamento da
fluxo de trabalho estrutura de produto
cofre de dados e gerenciamento
de documentos
Figura 25: Nveis de Complexidade de Sistemas PDM

Fonte: PIKOSZ, 1997, p.23
Baseados no espao de tempo em que se alcanam estes nveis de
complexidade, o mesmo autor apresenta trs estratgias para a implantao de
sistemas PDM: implantao por projeto, foco em uma funcionalidade do sistema
PDM e implantao de um arquivo central.
3.5.1. Implantao por Projeto

Utilizando esta estratgia, as funcionalidades dos quatro nveis de
complexidade so implantadas no decorrer do desenvolvimento de um produto. Esta
estratgia causa pouca mudana no restante da empresa, e tem como objetivo criar
um modelo de desenvolvimento de produtos integrado, para depois aplic-lo ao
restante da empresa.
Este modelo integrado uma ferramenta para melhorar a comunicao no
time de desenvolvimento de produtos, permitindo o suporte para comunicao desde
o incio do processo. Os dados de todo o processo de desenvolvimento ficam
acessveis a todos os participantes do time, que podem verificar sempre que
Rogerio Omokawa
65
necessrio o status do projeto. Esta estratgia permite uma rpida implantao do

sistema, passando por todos os nveis de complexidade listados na Figura 25.
Para criar um cofre de dados digitais e gerenciar a implantao das

funcionalidades referentes ao primeiro nvel de complexidade, o projeto deve
comear a armazenar todos dados desde o incio do processo (por exemplo: lista com
requisitos do produto, planejamento das atividades de desenvolvimento, etc.). O
segundo nvel de complexidade alcanado quando o projeto comea a ser detalhado
em subsistemas e se cria um modelo de desenvolvimento de produtos integrado, onde
a funcionalidade fluxo de trabalho (workflow) pode ser introduzida para automatizar
os processos de alterao de engenharia (PIKOSZ, 1997).
O terceiro nvel seria possibilitar a troca de dados do sistema PDM com
outros sistemas de informao. Um exemplo tpico a criao de uma interface entre
os sistemas PDM e ERP (Enterprise Resource Planning).
O nvel final permitir o suporte para o completo ciclo de vida desde a fase
de concepo/conceituao do produto at a obsolescncia do produto.
Uma das principais vantagens desta estratgia de implantao a de que
pode-se obter uma viso de todo o processo de implantao em um projeto, e em um
perodo relativamente curto de tempo, antes de estender o sistema para a empresa
inteira. A grande desvantagem deste tipo de estratgia a de possui maior
possibilidade de falha devido ao alto e rpido nvel de complexidade alcanado.
A utilizao de funcionalidades de sistemas PDM em todas as fases do
desenvolvimento do produto tem um impacto muito grande na metodologia de
trabalho, sendo portanto muito importante a participao dos membros do time de
desenvolvimento de produtos na implantao.
recomendvel, para reduzir o risco de falha, que o primeiro projeto a
utilizar o sistema PDM utilize arquivos duplicados, com cpias no sistema PDM e no
sistema antigo. Isto requer que as pessoas do time coloquem os mesmos dados duas
vezes, podendo causar frustrao e a no utilizao do sistema PDM. Uma maneira
Rogerio Omokawa
66
de se evitar esta situao e reduzir o risco de falha programar interfaces entre os

sistema PDM e o sistema antigo ao invs de forar as pessoas a utilizar dois sistemas
separados.
3.5.2. Foco em uma Funcionalidade do Sistema PDM

A segunda estratgia prega a introduo de uma funo do sistema PDM em
um departamento, por exemplo o departamento de engenharia.
So razes para se escolher implantar uma funcionalidade do sistema PDM:
suportar uma funcionalidade chave, ou uma funcionalidade que atualmente no
suportada pelos sistemas atuais da empresa, ou ainda suportar uma funcionalidade
onde o aumento da eficincia e aceitao dos usurios possa ser identificada. Um
exemplo tpico deste tipo de estratgia a aplicao da funcionalidade de fluxo de
trabalho em processos da empresa que so longos e rotineiros.
Outro modo de aplicao desta estratgia a introduo da funcionalidade de
estrutura de produto, que cria e gerencia as estruturas de produto e conecta os
modelos criados em CAD s respectivas peas nas estruturas. Esta aplicao
proporciona o gerenciamento de um grande nmero de montagens de CAD com a
capacidade de gerenciar as verses dos arquivos e das estruturas de produto, alm de
integrar o sistema CAD ao PDM.
As duas variantes desta estratgia de implantao esto no segundo nvel de
complexidade, sendo que a condio bsica a de existir uma base de dados com
meta-dados e um cofre de dados, sendo que apenas parte dos dados e meta-dados
sero utilizados, pois nem todos os dados da empresa sero afetados.
A introduo de uma funo do sistema PDM por vez associada a um risco
menor que a primeira estratgia, pois os nveis de complexidade so alcanados em
um tempo maior, havendo mais tempo para testes e familiarizao do sistema por
parte do usurio. Embora seja necessria a participao de usurios, este tipo de
implantao pode ser realizada em grande parte por especialistas (PIKOSZ, 1997).
Rogerio Omokawa
67
Este tipo de estratgia pode motivar a implantao de outras funcionalidades

do sistema PDM na medida que seja bem sucedida.
3.5.3. Introduo de um Arquivo Central

A terceira estratgia suportar o arquivo central da empresa e o ciclo de vida
de todos os documentos da empresa. O primeiro passo nesta estratgia converter
documentos em papel para o formato digital. Um segundo passo permitir o acesso
rpido aos documentos, que pode ser realizado por funes de visualizao ou
utilizando a intranet da empresa. O terceiro passo permitir possibilidades de
armazenagem eficientes, diretamente das ferramentas computacionais que a empresa
utiliza.
Esta estratgia a menos complexa (primeiro nvel de complexidade) e
tambm a mais fcil de se executar sem falhas. Ela pode ser executada por
especialistas desde que seja bem especificada. O especialista pode customizar o
sistema off-line e introduzi-lo somente aps a funcionalidade ter sido verificada.
O potencial para suportar o desenvolvimento integrado de produtos menor
que as outras estratgias, mas um arquivo digital central d empresa todo suporte
para acesso rpido aos documentos arquivados. O nvel de mudana na empresa
muito baixo, e a criao de um arquivo digital serve como base para futuras
implantaes de outras funcionalidades mais complexas.
3.6. BENEFCIOS DA IMPLANTAO DE SISTEMAS PDM

Segundo MCINTOSH (1995), os benefcios esperados com a implantao de
um sistema PDM dependem do tipo, tamanho e escopo do sistema a ser considerado.
Alm disso, estes benefcios normalmente advm da combinao da implantao do
sistema com a utilizao de conceitos como a engenharia simultnea.
Apesar das diferenas, alguns benefcios comuns maioria das implantaes
de sistemas PDM podem ser citados, tais como:
Rogerio Omokawa
68
reduo nos custos: pode ser atribuda predominantemente reduo nos custos
de trabalho de engenharia e manufatura (ganhos de mais de 25% podem ser
obtidos) como resultado da reduo do tempo utilizado em atividades associadas
ao manuseio de informaes. Entre estas atividades podemos citar a procura, a
checagem da validade e a movimentao dos dados entre processos
(DEPARTMENT OF TRADE AND INDUSTRY, 1995);
De acordo com MILLER et al. (1994), j no terceiro ano a economia
proporcionada pelo sistema, levando-se em conta apenas as pessoas que utilizam
diretamente o sistema, se torna maior que o gasto com a implantao e
manuteno do sistema (Figura 26). E a partir disso os gastos com o sistema
passam a ser decrescentes, enquanto que a economia passa a ser crescente.
1200
1000
Gastos com Implantao/Manuteno
800
K($)
Economia em Trabaho Direto
600
400
200
0
Ano 1
Ano 2
Ano 3
Ano 4
Ano 5
Figura 26: Economia em Custo de Trabalho Direto

Fonte: MILLER et al., 1994, p.76
reduo do time to market: algumas pesquisas com empresas mostram ganhos em

at 25% (DEPARTMENT OF TRADE AND INDUSTRY, 1995);
Rogerio Omokawa
69
reduo do nmero de alterao de engenharia (ECO) em at 80% (CARROL,

1996);
respostas rpidas aos requisitos do cliente (MILLER et al.,1994);
otimizao do uso dos recursos computacionais (MILLER et al.,1994).

A reviso bibliogrfica (Captulos 2 e 3) tem como objetivo principal formar
uma base de conhecimentos para o desenvolvimento do trabalho. Esta base de

fundamental importncia para parte prtica do trabalho, cuja descrio e resultados
so mostrados a seguir.
Rogerio Omokawa
70
4. CARACTERIZAO DO AMBIENTE PESQUISADO EM

RELAO ENGENHARIA SIMULTNEA
Neste captulo descrito o processo de escolha do ambiente pesquisado,

conforme item 1.6.5. So apresentadas tambm as caractersticas da empresa e
tambm a caracterizao do ambiente de desenvolvimento de um produto da empresa
em relao engenharia simultnea (conforme itens 1.6.4, 1.6.6 e 1.6.7 das etapas
gerais do trabalho).
4.1. ESCOLHA DO CASO

A escolha do caso realizada em paralelo com o desenvolvimento do
questionrio e dos roteiros de entrevista, atividades descritas no item 1.6.
Para se escolher a empresa a ser estudada, foram realizadas visitas a vrias
empresas fornecedoras de sistemas PDM, congressos ligados ao tema e possveis
empresas usurias. Durante estas visitas, foi constatado que apesar do crescimento do
mercado mundial de sistemas PDM (Item 3.4), poucas empresas no Brasil
implantaram ou esto implantando este tipo de sistema.
Tambm se verificou que vrias empresas esto em processo de escolha de
um sistema PDM, existindo tambm as empresas que esto esperando que outras
empresas do setor implantem antes este tipo de sistema para que possam analisar os
benefcios e as dificuldade desta implantao.
A empresa escolhida foi pr-selecionada devido ao fato de estar implantando
um sistema PDM, por ser uma das poucas montadoras que est desenvolvendo
Rogerio Omokawa
71
produtos no Brasil e tambm porque em algumas entrevistas no estruturadas, a

pessoas envolvidas no desenvolvimento de produtos, foi detectada a possibilidade de
o ambiente de desenvolvimento utilizar a filosofia de ES. A caracterizao do grau
de utilizao de ES, requisito bsico para o desenvolvimento do trabalho, descrito
no item 4.3. apresentado a seguir os dados gerais da empresa e do ambiente de
desenvolvimento.
4.2. DADOS
GERAIS
DA
EMPRESA
DO
AMBIENTE
DE
DESENVOLVIMENTO DE PRODUTOS
Os dados apresentados aqui foram levantados atravs da coleta de dados com
o departamento de marketing e atravs de dados obtidos com os membros do time de
desenvolvimento.
A empresa faz parte de um grande grupo multinacional com presena em
vrios pases, sendo o desenvolvimento e a fabricao de caminhes apenas um dos
negcios da empresa.
No Brasil, onde ela atua desde 1956, existem cerca de 10.000 funcionrios
produzindo desde caminhes leves at os extra pesados, alm de chassis para nibus.
Os veculos produzidos do empresa boa parte do mercado nacional de caminhes,
sendo que em alguns segmentos ela lder de mercado.
A forma com que o processo de desenvolvimento do produto ocorre nova
dentro da empresa em termo de organizao, utilizando a abordagem de times
multifuncionais e de uma estrutura organizacional similar a estrutura de time de
execuo de projetos (Item 2.3.1.1).
O desenvolvimento de produtos realizado por cerca de 70 pessoas que
trabalham direta ou indiretamente no desenvolvimento de produtos. Muitas das
informaes relativas a este processo so confidenciais, pois o produto ainda est em
desenvolvimento. A caracterizao do ambiente do ponto de vista da ES
apresentada a seguir.
Rogerio Omokawa
72
4.3. CARACTERIZAO DO AMBIENTE EM RELAO AO GRAU DE

UTILIZAO DE ENGENHARIA SIMULTNEA
4.3.1. A Pesquisa Realizada

O questionrio utilizado para esta caracterizao foi retirado da metodologia
criada por CARTER & BAKER (1992), cujo principal objetivo auxiliar, atravs do
uso de tecnologias, ferramentas, tarefas e habilidades das pessoas no balanceamento
das quatro dimenses da engenharia simultnea (Item 2.3.2) em um ambiente de
desenvolvimento de um produto.
Esta metodologia composta de quatro partes (CARTER & BAKER, 1992):
questionrio de avaliao da empresa: auxilia na determinao do estado atual

do ambiente de desenvolvimento de produtos da empresa em relao s quatro
dimenses da engenharia simultnea (CARTER & BAKER 1992);
matriz dos mtodos: auxilia na determinao, dimenso por dimenso e

abordagem por abordagem, dos mtodos de ES que a empresa necessita para
desenvolver um produto especfico com sucesso. a viso de ES que a empresa
deveria possuir (tanto o questionrio de avaliao quanto a matriz dos mtodos se
encontram no Anexo 1 deste trabalho);
mapa das dimenses: auxilia na determinao das variaes entre onde a

empresa est e onde ela deveria estar com relao a cada dimenso da ES. Este
mapa ilustra o que necessrio para implementar as dimenses de maneira
balanceada (CARTER & BAKER 1992);
guia de prioridades: auxilia na determinao de prioridades para balancear as

dimenses da ES na empresa (CARTER & BAKER 1992).
Como o objetivo caracterizar o grau de utilizao da engenharia simultnea
no ambiente onde realizado o estudo de caso, so utilizados neste trabalho as trs

primeiras partes da metodologia, que so responsveis por esta caracterizao.
Rogerio Omokawa
73
Atravs do questionrio de avaliao da empresa (Anexo 1) procura-se

avaliar o nvel de utilizao das vrias dimenses da ES: dimenso da organizao,
da infra-estrutura da comunicao, dos requisitos do produto e do desenvolvimento
de produtos. Mais detalhes de cada uma destas dimenses so fornecidas no item
2.3.2.
O objetivo de cada parte do questionrio apresentado no incio de cada
tpico no questionrio que se encontra no Anexo 1.
A matriz dos mtodos (Anexo 1) ajuda a avaliar qual deve ser o nvel de
utilizao das dimenses (chamadas de abordagens) para conseguir todos os
benefcios da ES. Cada uma das quatro abordagens possveis so apresentadas a
seguir:
abordagem por tarefa: aplicado quando o produto possui uma unidade principal e
requer somente poucas pessoas para desenvolv-lo;
abordagem por projeto: aplicado a produtos que possuem mais componentes e

requerem um grupo de pessoas que possuam o mesmo conhecimento de uma
disciplina de engenharia, um time disciplinar;
abordagem por programa: se o produto requer vrias disciplinas de engenharia

para o desenvolvimento de seus componentes, cada conjunto pode necessitar de
seu prprio time. Os representantes desses times de projeto podem formar um
time multidisciplinar para gerenciar todo o processo de desenvolvimento e
promover a comunicao entre as diferentes disciplinas;
abordagem por toda a empresa: aplicado a produtos complexos que requerem

vrios times multifuncionais, que podem incluir fornecedores de peas.
importante frisar que para implementar, por exemplo, a abordagem por
programa, deve-se implementar antes a abordagem por tarefa e por projeto.

O mapa das dimenses, assim como o resultado dos questionrios,
apresentados a seguir.
Rogerio Omokawa
74
4.3.2. Aplicao da Metodologia e Resultados

Os questionrios foram distribudos a 30 membros do time multifuncional de
desenvolvimento de produtos, este nmero corresponde a aproximadamente a 40%
do total de pessoas que trabalham na atual fase de desenvolvimento. Do total de
questionrios enviados foram respondidos um total de 22 questionrios, o que
corresponde a 73% dos questionrios enviados.
As pessoas foram escolhidas de forma a refletir o ambiente de
desenvolvimento de produtos da maneira mais prxima realidade possvel.
Procurou-se entregar o questionrio a pessoas com os mais variados cargos dentro da
empresa (possuindo portanto diferentes vises do processo).
Os resultados do questionrio de avaliao da empresa e da matriz dos
mtodos foram tabulados (Anexo 3) e a seguir colocados no grfico chamado de
mapa das dimenses.
A criao deste grfico a terceira fase da metodologia de CARTER &
BAKER (1992), e o seu objetivo facilitar a visualizao de onde a empresa est
agora e onde ela deveria estar em relao engenharia simultnea.
O mapa das dimenses (Figura 27) possui quatro quadrantes representando as
quatro dimenses da ES, que so divididos de acordo com os fatores-chave para cada
dimenso. Os quatro anis concntricos representam as quatro diferentes abordagens
de ES (abordagem por tarefa, por projeto, por programa ou por toda a empresa). Os
nmeros nos anis se referem s questes no questionrio de avaliao da empresa
(Anexo 1), e so distribudos de acordo com os fatores-chave e abordagens
correspondentes (CARTER & BAKER,1992).
Rogerio Omokawa
75
Figura 27: Mapa das Dimenses

Fonte: Carter & Baker, 1992, p. 88
Para preencher o mapa das dimenses so realizados os seguintes passos:
a) Transferncia das respostas positivas (S) do resultado do questionrio de
avaliao da empresa para o mapa de dimenses, preenchendo os pontos
em branco do nmero da questo correspondente4 (pontos em vermelho
na Figura 28).
Neste caso foram consideradas as respostas positivas aquelas cujas somas
de respostas positivas, dos questionrios, foram maiores que as
negativas5. Algumas questes, nas quais a soma das respostas positivas
As respostas de todos os questionrios se encontram em tabelas no Anexo3.
Resultados em destaque no Anexo 3.
Rogerio Omokawa
76
foi a mesmo que a das respostas negativas, foram consideradas em branco

e no foi preenchido o ponto correspondente.
Figura 28: Mapa das Dimenses com Transferncia das Respostas Positivas
b) Conexo dos pontos em vermelhos mais externos de cada fileira (Figura
29).
Rogerio Omokawa
77
Figura 29: Mapa das Dimenses Situao Atual

c) De acordo com o resultado obtido a partir dos dados obtidos com a
aplicao da matriz dos mtodos (Anexo 3), a empresa necessita da
abordagem por toda a empresa.
desenhado ento uma elipse azul sobre o anel que corresponde
abordagem que o produto necessita (Figura 30).
Rogerio Omokawa
78
Figura 30: Mapa das Dimenses Situao Atual x Situao Ideal I

Comparando-se os dados obtidos com o questionrio de avaliao da empresa
(linha vermelha - Figura 30) com a abordagem de ES necessria para o
desenvolvimento de produto estudado (elipse azul - Figura 30), pode-se notar as
diferenas entre onde a empresa est com relao ES e onde ela deveria estar, com
um ambiente de ES completamente implementado.
Na regio onde a linha vermelha est sobre a elipse azul, os fatores-chave j
possuem os recursos e processos necessrios de ES para a abordagem por toda a
empresa. Mas nas regies onde a linha vermelha se encontra dentro da elipse azul, os
fatores-chave necessitam de melhorias de recursos e processos. Estes fatores-chave
so ditos desbalanceados.
Quanto maior a distncia entre as linhas vermelha e azul, maior o
desbalanceamento e maior dever ser o esforo empregado para corrigi-lo. Para
melhor se visualizar os desbalanceamentos, a rea compreendida entre a linhas foi
sombreada em azul. O mapa das dimenses com todos os dados pode ser observado
na Figura 31.
Rogerio Omokawa
79
Figura 31: Mapa das Dimenses Situao Atual x Situao Ideal II

A maior parte dos fatores-chave, da qual segundo CARTER & BAKER
(1992) so compostas as dimenses da ES, satisfazem as necessidades de recursos e
processos requeridos para o desenvolvimento de produtos em questo (Figura 31).
Apenas algumas melhorias so necessrias, sendo que o item que merece mais
ateno o fator-chave treinamento e educao, cuja situao atual a que mais se
distancia da situao ideal.
Como a maior parte dos fatores-chave so satisfeitos, sendo necessrias
melhorias em apenas alguns deles, pode-se afirmar que o ambiente no qual se realiza
o estudo de caso pode ser considerado um ambiente de ES, apto portanto para a
realizao do estudo de caso.
Rogerio Omokawa
80
5. A CARACTERIZAO DA IMPLANTAO DO SISTEMA

PDM NO AMBIENTE DE ENGENHARIA SIMULTNEA
Este captulo apresenta os dados coletados durante a pesquisa de campo.

Estes dados foram obtidos a partir de entrevistas a especialistas que atuam na
implantao do sistema PDM no ambiente pesquisado e atravs dos dados obtidos
pelo grande contato existente entre ambiente pesquisado e o pesquisador.
5.1. REALIZAO DA PESQUISA DE CAMPO

As entrevistas foram baseadas no roteiro de entrevista que se encontra no
Anexo 2. A princpio, pensou-se em desenvolver dois roteiros de entrevista, um para
levantar as caractersticas da implantao do sistema e outro para levantar as
necessidades de gerenciamento de dados da empresa (Item 2.5). Porm, durante esta
fase do trabalho, alm do desenvolvimento dos roteiros, houve algumas entrevistas
de teste para que estes fossem avaliados. Como feedback desta avaliao, optou-se
por realizar apenas entrevistas para a caracterizao da implantao.
O levantamento das necessidades de gerenciamento de dados e de
funcionalidades que as suprem foi realizado atravs de uma tabela na qual estas duas
informaes so cruzadas. Foi utilizada esta opo pois as questes levantadas
(necessidades de gerenciamento, funcionalidades e quais as funcionalidades que
suprem quais necessidades) dependem mais de consulta a material dos entrevistados
o que estenderia por demais as entrevistas.
Uma atividade que seguiu em paralelo ao desenvolvimento do roteiro de
entrevista foi escolha a das pessoas a serem entrevistadas. O critrio para a escolha
Rogerio Omokawa
81
foi identificar pessoas que possuem uma viso global da implantao e tem um
grande contato com o ambiente na qual o sistemas est sendo implantado.
Antes da entrevista foi realizado uma pequena introduo sobre os objetivos
do trabalho e a localizao da pesquisa de campo/entrevistas. As entrevistas
ocorreram como esperado no Desenvolvimento da Forma de Coleta dos Dados (Item
1.6.4). Entretanto, como j citado anteriormente, o desenvolvimento do produto um
processo que ainda est ocorrendo, fazendo com que muitas informaes se tornem
confidenciais por parte da empresa e portanto no podendo ser divulgadas.
Alm dos dados obtidos com as entrevistas, so utilizados tambm dados
obtidos no dia a dia , devido ao grande contato do pesquisador com o ambiente de
implantao. Todos esses dados foram estruturados de maneira cronolgica e so
apresentados a seguir.
5.2. APRESENTAO DOS DADOS

So apresentados os dados coletados durante a pesquisa de campo. Estes
dados so divididos em deciso da implantao e escolha do sistema, estratgia de
implantao e metas, caractersticas de sistemas PDM, requisitos de gerenciamento
de dados e funcionalidades que os suprem, dificuldades encontradas e benefcios
obtidos e situao atual e prximos passos. A seguir cada um desses itens
detalhado.
5.2.1. Deciso da Implantao e Escolha do Sistema

A deciso relativa a implantao do sistema PDM foi uma deciso estratgica
da matriz. Alm do Brasil ocorrem implantaes simultneas do mesmo sistema em
outras empresas do grupo, presente em outros pases.
Antes da deciso da implantao de um sistema PDM j eram utilizados
outros sistemas de gerenciamento que apresentavam algumas funcionalidades de
sistemas PDM. Existiam dois sistemas, um para gerenciar a estrutura de produto, de
Rogerio Omokawa
82
configuraes e variaes desta estrutura e outros sistema para gerenciamento dos

dados geomtricos gerados em CAD.
Ambos os sistemas eram baseados em mainframe, e um dos motivos da
substituio devido ao processo de substituio do mainframe por sistemas
baseados no paradigma cliente-servidor em todas as empresas do grupo relacionadas
a projetos de veculos automotores.
O sistema, que est em fase de implantao, passou por uma fase de escolha
na qual cerca de 30 sistemas foram avaliados atravs de um benchmarking. Desses
30 sistemas, foram selecionados 3 para testes mais detalhados dos produtos.
A avaliao final foi realizada atravs de um laboratrio de anlise, onde os
3 sistemas foram instalados, e envolveu analistas de sistemas, engenheiros da
empresa e representantes do fornecedor do sistema.
5.2.2. Estratgia de Implantao e Metas

A implantao do sistema realizado por uma consultoria externa (porm
do mesmo grupo) que responsvel pela definio de processos, pela implantao,
pelo treinamento e pelo acompanhamento/verificao da utilizao dos sistema.
Existem hoje nove pessoas envolvidas diretamente na implantao, havendo uma
variao, de acordo com o nvel de complexidade.
De acordo com os entrevistados, o tipo de implantao realizada a
implantao por projeto. Os responsveis pela implantao no possuam o
conhecimento da classificao realizada por PIKOSZ (1997) (Item 3.5.1), mas
afirmam que de acordo com as caractersticas apresentadas, trata-se da implantao
por projeto.
Rogerio Omokawa
83
As principais caractersticas desta implantao so:
ser um piloto mundial para futuras implantaes;
implantao do sistema PDM em um projeto de desenvolvimento de produtos,

causando pouca mudana no restante da empresa;
implantao por projeto, passando por todos os nveis de complexidade (Item

3.5.1);
criao do cofre de dados desde o incio do projeto, guardando neste estgio

todos os dados da estrutura do produto;
implantao do sistema PDM visando sua utilizao na fase de desenvolvimento

e no em todo o ciclo de vida do produto (como citado no Item 3.2).
Conforme PIKOSZ (1997) uma das principais vantagens desta estratgia a
de se obter uma viso de todo o processo de implantao em um projeto e em um

perodo relativamente curto de tempo, antes de se estender o sistema para a empresa
inteira. Segundo os entrevistados, o maior ganho por parte da empresa que est
instalando o sistema o ganho de experincia, que vai ser usado em outros projetos
de implantao, inclusive na expanso da atual implantao.
No foram definidas metas para a implantao, mas esperado uma reduo
do ciclo de desenvolvimento, que poder ser medido ao final do projeto. Tambm
no foram definidas mtricas de acompanhamento no incio do projeto, havendo
atualmente uma preocupao com este assunto.
5.2.3. Caractersticas do Sistema PDM

O sistema baseado em um produto comercial, que foi customizado. Estas
customizaes foram necessrias para se adequar o sistema PDM base (Metaphase
2.1 ) s necessidades da empresa.
Rogerio Omokawa
84
Apesar de vrias customizaes j terem sido realizadas, como a implantao

acompanha os estgios do desenvolvimento do produto, muitas das funcionalidade
do sistema ainda esto sendo desenvolvidas, pois segundo os entrevistados algumas
delas como por exemplo alguns fluxos de trabalho (workflows) s sero utilizados
daqui a alguns meses ou anos. As caractersticas do produto resultante, baseados em
critrios do CIMdata (Item 3.3), so apresentadas a seguir.
5.2.3.1. Cofre de Dados e Gerenciamento de Documentos

O sistema PDM em implantao utiliza o paradigma de orientao a objeto
para a definio e o gerenciamento dos dados do produto (informaes da estrutura
de produto, arquivos CAD, etc.). O sistema gerencia cada definio do projeto como
um objeto atravs de todo o ciclo de vida do produto. Estes objetos podem ser
manipulados pelo sistema, sem que o arquivo original seja alterado. Por exemplo,
podem ser gerados vrias cpias do objeto pea 1, na estrutura do produto, e que
possuam ligao apenas com um arquivo de CAD pea 1, .
O sistema oferece ainda vrias ferramentas para a visualizao dos objetos
gerenciados, seus atributos e seus relacionamentos. Os usurios podem ainda realizar
pesquisas na base de dados utilizando atributos e relacionamentos para localizar os
objetos necessrios. Os objetos e os relacionamentos so representados de maneira
grfica para facilitar a visualizao. Alm disso, o sistema gerencia os cdigos das
peas, que so nicos em todo o mundo.
Os mecanismos de check-in e check-out so utilizados para as modificaes
dos dados. Quando um check-out realizado, uma cpia feita do cofre para a
rea de trabalho e os dados do usurio, estao de trabalho e horrio so gravados em
um histrico. Com o check-in criada uma nova seqncia do dado para controle.
5.2.3.2. Fluxo de Trabalho e Gerenciamento de Processos

O sistema possui um sistema gerenciador de fluxos de trabalho que permite a
programao grfica de fluxos de trabalho automatizados. Alguns fluxos de trabalho
Rogerio Omokawa
85
pr-programados controlam o congelamento, reviso e liberao das peas para a

produo. Podendo futuramente estar integrado ao gerenciador de mudanas de
engenharia.
5.2.3.3. Gerenciamento da Estrutura de Produto

O sistema permite a criao, visualizao e manipulao da estrutura do
produto de uma maneira grfica, permitindo a existncia de vrias vises da
estrutura de produto (por exemplo: viso de montagem, por zonas espaciais do
produto, documentao, funo, tarefas, etc.).
5.2.3.4. Classificao e Recuperao

O sistema no utiliza as funcionalidades de classificao e recuperao,
apesar do sistema base possuir um mdulo com essas funcionalidades.
5.2.3.5. Gerenciamento de Projetos

O sistema possui poucos recursos com relao ao gerenciamento de projetos,
possibilitando apenas a visualizao das tarefas a serem realizadas.
As funes de manipulao dos recursos, e anlise do caminho crtico, no
so fornecidas pelo sistema.
5.2.3.6. Comunicao e Notificao

O sistema possui a funcionalidade de envio de mensagens automticas aos
usurios, porm atualmente no est sendo utilizada.
5.2.3.7. Transporte de Dados

O sistema trabalha em um ambiente distribudo, com a possibilidade de
acesso de dados em todo o mundo. Este transporte de dados pode ser realizado de
vrias formas, do cofre de dados para a rea de trabalho do usurio ou de um
Rogerio Omokawa
86
cofre de dados de um projeto para outro. Existindo tambm a possibilidade de

copiar o dado criando uma ligao com o dado original de modo que sempre que haja
uma modificao no dado original a cpia tambm seja alterada; copiar sem a criao
desta ligao; copiar possibilitando apenas a leitura, etc.
Com os fornecedores a troca de dados realizada por um outro sistema de
troca de dados, desenvolvido pela matriz da montadora, que possui uma interface
com o sistema PDM. A troca de dados realizada por outro software devido ao fato
dos fornecedores no possurem o sistema PDM instalado em suas empresas.
5.2.3.8. Converso de Dados

Possui capacidade de converso de dados para os formatos IGES, STEP e
HPGL. Sendo que esta no uma funcionalidade muito utilizada, pois os dados
geomtricos se encontram em apenas um formato.
5.2.3.9. Servios de Visualizao e Comentrios (markup)

O sistema no possui esta funcionalidade, existindo uma interface com um
sistema de visualizao.
5.2.3.10. Administrao
Possui as funes, que funcionam junto ao gerenciador de base de dados, de
backup, manuteno de usurios, de dados de produtos, e de base de dados.
Permitindo ainda um ambiente distribudo do sistema.
5.2.3.11. Interfaces
O sistema possui interfaces com vrios sistemas, tais como:
sistemas CAD: CATIA, AutoCAD, Mentor Graphics e um sistema desenvolvido

pela prpria empresa;
Rogerio Omokawa
87
sute de escritrio: MS Office;

Nestas duas interfaces o sistema PDM incorpora os arquivos no seu cofre
de dados, utilizando os sistemas geradores do arquivo (sistema CAD, editor de texto,

etc.) quando for necessria a modificao ou visualizao dos arquivos.
sistema de ERP desenvolvido pela empresa;
sistemas de gerenciamento de dados geomtricos desenvolvido pela empresa.
5.2.4. Requisitos de Gerenciamento de Dados e Funcionalidades que os Suprem

No houve nenhum levantamento sistemtico de necessidades no incio da
implantao. Para a obteno de uma lista de requisitos foi mostrada durante as
entrevistas a lista do item 2.5. Segundo os entrevistados as necessidades do ambiente
de ES real seriam basicamente as mesmas encontradas na bibliografia, com a adio
de algumas (com relao a possibilidade de automao do fluxo de trabalho) e a
retirada de outras.
So apresentados a seguir o resultado das entrevistas:
a) fornecer um mtodo de acesso, para garantir que os dados acessados sejam
completos, consistentes e protegidos contra modificaes no autorizadas em
cada estgio de ciclo de desenvolvimento de produtos;
b) gerenciar relacionamentos entre os dados, para que se possa saber onde as
modificaes foram realizadas e quais outros dados foram afetados;
c) recuperar dados para o desenvolvimento de produtos, para reduzir o time to
market e reduzir o custo de desenvolvimento;
d) gerenciar todos os tipos de dados, no s uma pequena poro, que so
armazenadas no computador;
Rogerio Omokawa
88
e) possuir gerenciador de arquivos, para que os arquivos de dados possam ser

criados e manipulados em uma rede de computadores sem que o usurio tenha
que saber onde o arquivo est localizado ou que sintaxe o computador usa;
f) suportar uma estrutura hierrquica de arquivos e peas;
g) permitir cpias de segurana dos dados, arquivamento e recuperao dos dados;
h) utilizar padres adotados pela empresa (unidades de medida, bordas de desenho,
etc.);
i) suportar controle de reviso e verso dos documentos;
j) visualizar os documentos em formatos padres (GIF, processador de texto, CAD,
etc.);
k) compartilhar a base de conhecimento: armazenar o conhecimento de vrios
projetos existentes na empresa com o intuito de evitar erros j cometidos e
estender os acertos para toda linha de produtos;
l) compartilhar os dados grficos: desenhos de detalhe, modelos tridimensionais,
imagens de representao de anlise de engenharia, etc.;
m) proteger as informaes;
n) cadastrar e relacionar peas e componentes;
o) localizar onde os componentes so utilizados (where-used);
p) listar quais componentes so utilizados em cada montagem (composed off);
q) gerenciar informaes de montagem;
r) permitir vrias vises da estrutura de produto;
Rogerio Omokawa
89
s) possibilitar a localizao de componentes semelhantes para serem utilizados em

projetos atuais;
t) possibilitar o congelamento dos documentos, impedindo a alterao, em vrios
estgios do desenvolvimento, para permitir que possam ser examinados;
u) possibilitar a automao de fluxos de trabalho.
Os requisitos indicados foram colocados em uma tabela e foram cruzados
com as funcionalidades do sistema PDM, para que fossem identificados quais as
funcionalidades utilizadas para satisfazer cada requisito. O resultado a apresentado
na Tabela 4, mostrada a seguir:
Tabela 4: Funcionalidades x Requisitos
A B C D E F G H I J K L M N O P Q R S T U
Cofre
de X
dados (vault)
X X X
X X
Fluxo
de
Trabalho
(Workflow)
X X X
X
Gerenciamento
da estrutura de
produto
X X
Gerenciamento
de configurao
X X
Comunicao e
notificao
Transporte
dados
de
X X X X X X
X X X
Servios
de
visualizao e
markup
Administrao
X X X
X
Rogerio Omokawa
90
A B C D E F G H I J K L M N O P Q R S T U
Interfaces
X X
Na entrega das tabelas com os resultados, os entrevistados observaram que

importante que as caractersticas de cada funcionalidade sejam melhor detalhadas,
pois apesar de alguns sistemas possurem certas funcionalidades, estas no possuem
caractersticas que satisfaam os requisitos levantados.
5.2.5. Dificuldades Encontradas e Benefcios Obtidos

So descritos a seguir algumas dificuldades encontradas durante a
implantao do sistema e os benefcios obtidos at agora.
5.2.5.1. Infra Estrutura

So as dificuldades encontradas durante a implantao e que poderiam ser
identificadas em um estudo detalhado do ambiente de implantao e do sistema.
incompatibilidade entre os sistemas da matriz (HP) e do Brasil (IBM);
subdimensionamento do espao de disco do servidor do sistema;
falta de suporte ao Wincenter (sistema que emula o ambiente Windows em

ambiente UNIX, e que permite o manuseio de arquivos MS-Office nas
Workstations).
5.2.5.2. Sistema
So apresentados os problemas quanto ao funcionamento, estabilidade e
performance do sistema.
sistema no supre as necessidades especficas do ambiente, sendo necessrio

utilizao/programao de novas funes;
Rogerio Omokawa
91
baixa performance na manipulao de geometrias CAD e documentos do MSOffice;
falta de indicao de que o sistema est processando algum comando.
5.2.5.3. Usurio
So as dificuldades dos usurios em relao ao sistema
dificuldade em entender como o sistema funciona;
viso de que a utilizao do sistema uma atividade a mais com que se

preocupar, alm da tarefas realizadas com a finalidade de desenvolvimento do
produto;
interface pouco amigvel;
falta de interface para cada tipo de usurio

Algumas destas dificuldades esto sendo resolvidas com a dedicao de uma
equipe de suporte, para dvidas e treinamentos.
5.2.5.4. Comunicao entre o Time de Implantao e o Time de Desenvolvimento

A dificuldade de comunicao entre o time de implantao e o time de
desenvolvimento foi citada como um dos principais obstculos implantao bem
sucedida do sistema. Algumas caractersticas desse problema so:
time de implantao que possui pouco poder de deciso em novas customizaes

do sistema, dificultando a implementao de novas caractersticas que supram as
necessidades levantadas junto ao usurio;
falta de documentao de todas as customizaes realizadas;
falta de um planejamento da implantao bem definido;
desenvolvimento do sistema ao mesmo tempo em que ocorre a implantao;

Rogerio Omokawa
92
falta da definio de metas e de mtricas para acompanhar a evoluo dos

trabalhos.
Grande parte das dificuldades encontradas foram resolvidas. Algumas delas
como: o problema de comunicao com o time de desenvolvimento e o pouco peso

da opinio do time de implantao na customizao do sistema, faz com que alguns
requisitos levantados ao longo do processo de implantao sejam atendidos.
Esta situao traz como principais conseqncias a necessidade de se
desenvolver solues locais que possam futuramente ter que ser substitudos por
outras solues propostas pelo grupo de desenvolvimento.
5.2.5.5. Vantagens
As vantagens com a implantao do sistema so:
gerenciamento de geometrias CAD com melhor controle de acesso e status que o

sistema anterior;
gerenciamento de toda a estrutura do produto;
armazenamento central dos dados geomtricos;
acesso rpido e fcil aos dados geomtricos;
atualizaes dos dados em tempo real;
possibilidade de reutilizao das peas.

Estas so as vantagens identificadas at agora, pois uma anlise quantitativa
das vantagens s pode ser realizada ao final da implantao do sistema.
5.2.6. Situao Atual e Prximos Passos

Algumas funcionalidades bsicas do sistema (cofre de dados, gerenciador
da estrutura de produto, interfaces com sistemas da empresa e alguns fluxos de
Rogerio Omokawa
93
trabalho) se encontram implantadas. Alm disso, foram desenvolvidos alguns

sistemas para complementar as funcionalidades do sistema para atender a requisitos
do usurio, como por exemplo um sistema para o controle de efetividade de peas
para os prottipos (qual reviso de pea vai em qual prottipo).
Atualmente tambm tem se estudado formas de se melhorar a comunicao
entre os times de desenvolvimento e de implantao, para que novas funcionalidades
sejam incorporadas ao sistema. Tambm esto sendo realizados testes para a melhora
de performance do sistema.
Como prximos passos espera-se aumentar o nmero de funcionalidades em
uso, e expandir a implantao a outras reas da empresa.
Rogerio Omokawa
94
6. CONCLUSES E TRABALHOS FUTUROS
Este trabalho consiste de uma pesquisa descritiva na qual necessidades de

gerenciamento de dados em um ambiente de ES real so levantadas e comparadas
com as encontradas na bibliografia. So analisadas tambm funcionalidades de
sistema PDM que supram a necessidades do caso real. Alm disso, so apresentadas
as caractersticas principais do processo de implantao, em estgio inicial, de um
sistema PDM.
Todas as etapas propostas no incio deste trabalho, desde a reviso geral da
bibliografia at a anlise e apresentao dos dados (item 1.6), foram realizados com
xito, alcanando os objetivos (item 1.2), propostos inicialmente para o
desenvolvimento deste trabalho.
A pesquisa bibliogrfica foi uma importante forma de obteno de dados, que
foram utilizados no decorrer de todo o trabalho. Durante a realizao desta pesquisa
foram levantadas vrias informaes sobre o desenvolvimento de produtos e a
engenharia simultnea (Captulo 2). Dentre estes dados se destacam as classificaes
dos elementos de suporte de ES segundo SYAN (1994) e CARTER & BAKER
(1992) (item 2.3).
A classificao e a metodologia proposta por CARTER & BAKER (1992) foi
utilizada durante o trabalho prtico com a finalidade de caracterizar o ambiente de
desenvolvimento de produtos em relao utilizao de elementos da ES.
Segundo os resultados da aplicao desta metodologia, o ambiente de
desenvolvimento de produtos pesquisado pode ser considerado um ambiente de ES,
Rogerio Omokawa
95
sendo necessrias algumas melhorias para que se utilize todos os recursos e

processos de ES para o desenvolvimento do produto em questo (Captulo 4).
Este trabalho est servindo de base para um estudo de modificao da forma
de treinamento, esta modificao est sendo realizada devido aos resultados obtidos
na Caracterizao do Ambiente em Relao ao Grau de Utilizao de Engenharia
Simultnea (item4.3).
Durante a pesquisa bibliogrfica tambm foram levantados dados de sistemas
PDM, tais como: histrico de desenvolvimento, funcionalidades, mercado,
estratgias de implantao e benefcios obtidos (Captulo 3). Atravs desta pesquisa,
constatou-se que o mercado de sistemas PDM um mercado em crescimento em
todo o mundo (item 3.4), e que vrios ganhos so obtidos com a implantao desses
sistemas, tais como a diminuio do tempo de desenvolvimento, a diminuio das
mudanas de engenharia e a diminuio dos custos de desenvolvimento, havendo
porm poucas publicaes a respeito da implantao destes sistemas.
O estudo de caso, realizado durante a implantao de um sistema PDM em
uma montadora de veculos pesados, esta implantao no muito comum no Brasil,
pois poucas empresas j implantaram ou esto implantando um sistema PDM. Este
estudo foi baseado em entrevistas a consultores e a pessoas de suporte e treinamento
que esto participando do processo de implantao.
Durante a coleta de dados foram pesquisados os requisitos de gerenciamento
de dados, as funcionalidades que so utilizadas para supri-los e as caractersticas do
sistema. Alm das dificuldades encontradas e de algumas melhorias ocorridas antes
do trmino da implantao.
O sistema em implantao foi escolhido e suas funcionalidades foram
customizadas (item 5.2.3) para ser utilizado de maneira distribuda por vrias filiais
do grupo espalhadas pelo mundo.
Para a implantao no Brasil no foi realizado nenhum levantamento inicial
de necessidades locais, sendo que prpria iniciativa de implantao foi tomada pela
matriz, no partindo portanto de uma necessidade da filial brasileira.
Rogerio Omokawa
96
A falta deste levantamento de necessidades locais leva programao de

funes especficas para a filial brasileira Estas customizaes do sistemas so
realizadas exclusivamente pela matriz, sendo este um processo lento, devido s
dificuldades de comunicao e dos testes que necessitam ser realizados antes de se
colocar uma funcionalidade em produo.
Existe assim uma dificuldade de se atender aos requisitos detectadas durante
a implantao do sistema. Para suprir as necessidades mais importantes tais como o
gerenciamento de efetividade das peas (ainda no disponvel no sistema) e de
ordens de alterao de engenharia (ECO engineering change order), foram
desenvolvidas solues temporrias com outros sistemas, pela empresa de
consultoria.
Foram levantadas atravs de entrevistas as necessidades de gerenciamento de
dados em um ambiente de ES. Como no houve nenhum levantamento sistemtico
anterior, o levantamento das necessidades atravs da pesquisa bibliogrfica foi
utilizado como base da entrevista. Segundo os entrevistados, as necessidades do
ambiente de ES real seriam basicamente as mesmas das encontradas na bibliografia,
com a adio de algumas (com relao a possibilidade de automao do fluxo de
trabalho) e a retirada de outras (item 5.2.4).
Estas necessidades foram ento colocadas em uma tabela, juntamente com as
funcionalidades
do
sistema
para
que
fossem
identificados
quais
dessas
funcionalidades seriam utilizadas para satisfaz-las (Tabela 4).

Com relao a caracterizao da implantao, as principais dificuldades
encontras foram em relao infra-estrutura, causado principalmente pela falta de
uma anlise preliminar do ambiente onde realizada a implantao (com o
mapeamento dos sistemas envolvidos, infra-estrutura de hardware e software, etc.) e
quanto a problemas de comunicao entre o time de implantao do Brasil e o time
de desenvolvimento que est em outro pas.
Rogerio Omokawa
97
Vrios deste problemas esto sendo atacados de maneira sistemtica

atravs da criao de foras tarefa que tm objetivos bem definidos, como por
exemplo a realizao de testes para detectar as causas da baixa performance.
Esto sendo aplicados durante a implantao vrios conceitos (ECM, BOM,
gerenciamento de dados, fluxo de trabalho, etc.), havendo vrios ganhos de
conhecimento. Alm da prpria implantao, que tem sido uma experincia muito
rica para o ganho de experincia.
Por parte da consultoria, de conceitos que acompanham o sistema PDM
(ECM, BOM, gerenciamento de dados, fluxo de trabalho, etc.), alm da prpria
implantao, tem sido uma experincia muito rica para o ganho de experincia.
No foi possvel neste trabalho nenhuma medida quantitativa dos ganhos da
empresa com a implantao do sistema, pois esta se encontra em um estgio inicial.
Alm disso, nem todos os ganhos e necessidades podem ser inteiramente conhecidos
ainda, pois novas necessidade podem surgir assim como novas funcionalidades
podem ser implementadas no decorrer da implantao.
TRABALHOS FUTUROS
Como se trata de um estudo de caso, as informaes retratam uma empresa de
um setor especifico com suas prprias caractersticas. Sendo assim, os dados obtidos
no podem ser generalizados. Porm, este trabalho pode auxiliar no levantamento
dos requisitos do ambiente de implantao e na escolha do sistema, alm de poder
contribuir na prpria implantao do sistema, atravs da descrio das dificuldades
encontradas e das vantagens obtidas, procurando-se assim evitar os erros e
maximizar os aspectos positivos.
Alm disso, este trabalho tambm pode servir de base para outros trabalhos
que procuram estudar a implantao de sistemas PDM. Um exemplo de continuidade
do trabalho poderia envolver o mesmo ambiente onde foi realizado o estudo de caso,
definindo mtricas e medindo-se as melhorias conseguidas ao final da implantao.
Rogerio Omokawa
98
Pode-se ainda estudar a influncia das caractersticas de cada funcionalidade

na satisfao dos requisitos levantados, assim como na implantao como um todo.
Rogerio Omokawa
99
ANEXOS
ANEXO 1: QUESTIONRIO DE AVALIAO DE UTILIZAO DE

ENGENHARIA SIMULTNEA
Rogerio Omokawa
100
QUESTIONRIO DE ENGENHARIA SIMULTNEA

Todas as respostas obtidas neste questionrio auxiliaro em um trabalho de
mestrado, cujo objetivo obter informaes sobre o uso da engenharia simultnea
em projetos da empresa. Tanto o nome da empresa como os nomes das pessoas no
sero divulgados.
Este questionrio baseado nas quatro dimenses da engenharia simultnea
(organizao, infra estrutura de comunicao, requisitos e desenvolvimento de
produto). As perguntas so feitas de acordo com cada dimenso e, dentro destas, elas
se dividem em questes cada vez mais especficas (dentro dos chamados fatoreschave), tentando englobar todas as abordagens do ambiente da empresa.
Para se responder este questionrio, deve-se focalizar no ambiente de
desenvolvimento do produto X. Para que essa avaliao seja realmente til, deve-se
responder s questes de modo que as mesmas relatem como est o ambiente de
desenvolvimento de produtos atual da empresa, e no de acordo com planos que se
tem em mente.
Rogerio Omokawa
101
PARTE I
Responda cada questo (sim S ou no N) da melhor maneira possvel.
Responda sim apenas se sua empresa tem implementada a ao perguntada pela
questo adequadamente. Responda todas as questes, a menos que voc no conhea
a resposta ou se a pergunta no relevante ao seu produto.
DIMENSO: ORGANIZAO
Essa parte do questionrio explora as caractersticas da empresa, no presente
momento, em termos de fatores da dimenso Organizao no ambiente de engenharia
simultnea.
Integrao dos times
Os empregados, individualmente, e os times de trabalho entendem seus
papis e tarefas no contexto de todo o processo de desenvolvimento de produtos.
S
1. As especificaes e as prioridades para as tarefas designadas so

entendidas pelas pessoas?
2. O processo de desenvolvimento de produtos entendido por cada

time disciplinar?
3. H um vocabulrio comum, prioridades e propsitos estabelecidos

para o time multidisciplinar de desenvolvimento de produtos?
4. Os requisitos, especificaes, interdependncias e prioridades dos

produtos
so
entendidos
pelo
time
da
empresa
(incluindo
consumidores e fornecedores)?
Rogerio Omokawa
102
Empowerment
Os nveis de autoridade e responsabilidade que coexistem dentro da empresa
possuem um papel significante em sua produtividade, e tanto as pessoas quanto os
times so premiados .
S
5. As decises de projeto so realizadas por supervisores e gerentes?
6. As decises de projeto so realizadas pelo time disciplinar?
7. As decises de projeto e relaes de benefcio so realizadas pelo

time multidisciplinar?
8. Os representantes do time da empresa participam de suas decises

(incluindo fornecedores e consumidores)?
9. As pessoas so responsveis pela padronizao do projeto,

completando suas tarefas em tempo e tendo responsabilidade pelos
resultados de suas tarefas?
10. Um time disciplinar responsvel pelo desenvolvimento das

especificaes de engenharia e pela sua correlao com as
especificaes interdependentes?
11. Um time multidisciplinar responsvel pelo amplo programa de

especificaes, programao e correlao dos requisitos?
12. Um time da empresa (incluindo fornecedores e consumidores)

responsvel pelo sistema de especificaes do projeto?
13. A empresa premia as pessoas, individualmente, pelas contribuies

destas?
14. A empresa premia os times pelas suas contribuies destes?
Rogerio Omokawa
103
Treinamento e educao
Os gerentes fornecem suporte de treinamento e educao apropriados para
cada pessoa e times. O treinamento inclui efetivamente como solucionar problemas,
atingir metas, pensar com criatividade, usar padres, utilizar especialistas e
trabalhar com outras disciplinas.
S
15. O treinamento fornecido adequado para cada pessoa nos

procedimentos, ferramentas e padres que ela utiliza?
16. O time disciplinar tem conscincia de outras disciplinas ,

considerando os procedimentos, ferramentas e padres?
17. Um treinamento adequado fornecido para os membros do time

multidisciplinar?
18. Um treinamento adequado dado aos membros do time da

empresa (incluindo fornecedores e consumidores)?
Suporte de automao
Gerentes garantem que as ferramentas necessrias estejam disponveis.
Essas ferramentas devem ser integradas e devem fornecer acesso aos dados do
produto.
S
19. As ferramentas de cada disciplina so fornecidas como ferramentas

stand-alone?
20. Ferramentas centralizadas so fornecidas para o time disciplinar?
21. As ferramentas de trabalho de cada pessoa so integradas com o

restante do time multidisciplinar?
Rogerio Omokawa
104
22. As ferramentas de trabalho de cada pessoa so integradas com o

time da empresa (incluindo alguns fornecedores e assistncia tcnica,
sendo disponveis on line)?
Rogerio Omokawa
105
DIMENSO: INFRA-ESTRUTURA DE COMUNICAO

Esta parte do questionrio explora onde a empresa se situa em termos de
fatores-chave que caracterizam a dimenso infra-estrutura de comunicao no
ambiente de engenharia simultnea.
Gerenciamento do produto
Modelos de comunicao efetiva so cruciais ao gerenciamento do produto e
tanto as pessoas quanto os times devem entender e monitorar suas metas e seus
papis, ajudar a planejar o processo de desenvolvimento de produtos, melhorando-o
tanto quanto necessrio.
S
23. As funcionalidades de correio eletrnico esto disponveis para

cada pessoa?
24. As funcionalidades de procura e de relatrios on-line esto

disponveis para todas as pessoas?
25. Os visualizadores on-line dados de produtos esto disponveis para

todas as pessoas?
26. Os suportes de deciso esto disponveis para todas as pessoas?
27. As revises tcnicas e as inspees so conduzidas de maneira

apropriada?
28. O gerenciamento do produtos disciplinado e consistente usado

para esforos de projeto?
29. H uma comunicao entre todos os aspectos do gerenciamento do

projeto e requisitos do sistema?
30. Os gerentes e os times de projeto interdependentes so

automaticamente e simultaneamente informados dos problemas e de
seu status?
Rogerio Omokawa
106
Dados sobre o produto

Os dados do produto so completos e precisos todo o tempo, e pessoas e
times podem acess-los, manipul-los e mud-los quando apropriado.
S
31. Os dados de desenvolvimento de produtos so controlados por

cada pessoa?
32. As pessoas do time disciplinar possuem acesso a todos os dados do

desenvolvimento de produtos relatados sua disciplina?
33.
As
pessoas
possuem
acesso
eletrnico
aos
dados
do
desenvolvimento de produtos relatados s diferentes disciplinas

envolvidas no desenvolvimento de produtos?
S
34. As pessoas e os times possuem acesso eletrnico aos dados de

desenvolvimento de produto de toda a empresa, que incluem dados dos
consumidores e fornecedores?
35. Durante o processo de desenvolvimento, as especificaes do

produto e projetos so utilizadas e documentadas de uma maneira
preestabelecida?
36. Os dados de desenvolvimento de produtos so armazenados,

controlados, alterados e revisados em uma base de dados comum a
todos?
37. Os dados na base de dados de desenvolvimento de produtos

opervel entre as vrias ferramentas de projeto?
38. Os dados de desenvolvimento, especificaes e requisitos do

produto envolvidos esto sob o controle automtico de alteraes e
verses?
Rogerio Omokawa
107
Feedback
O feedback mantm o processo de desenvolvimento de produto sob controle e
permite que as pessoas e os times manuseiem as divergncias quanto as expectativas
do consumidor, as especificaes do produto, aos padres industriais e a outros
requisitos. O feedback da reviso e inspeo gera aes corretivas, assim como
sugestes para melhorar o produto.
S
39. Os problemas so analisados atravs de suas causas de origem e

ento corrigidos?
40. Os problemas so reportados, priorizados, programados para

correo (ou rejeio) e acompanhados at que sejam corrigidos?
41. As aes corretivas, relatrios de problemas e solicitaes de

melhoria so guardados em uma base de dados e ento usados como
indicadores para satisfao do consumidor?
42. As tendncias das aes corretivas, relatrios de problemas,

solicitaes de melhoria e outras decises so analisados para melhora
contnua do processo de desenvolvimento de produtos?
Rogerio Omokawa
108
DIMENSO: REQUISITOS
Esta parte do questionrio explora os fatores-chave que caracterizam a
dimenso dos requisitos num ambiente da engenharia simultnea.
Definio dos requisitos
Uma empresa converte as necessidades do cliente em definies de
especificaes e projetos de produto. Em todo estgio deste desenvolvimento,
pessoas, times e gerentes podem checar se os requisitos, as especificaes e os
projetos atendem as necessidades do consumidor.
S
43. As expectativas do consumidor so determinadas e convertidas

para requisitos documentados do cliente ou de marketing?
44. Os requisitos dos consumidores ou de marketing so divididos em

especificaes funcionais documentadas?
45. Pode-se rastrear cada especificao funcional em relao aos

requisitos do consumidor ou de marketing que a geraram?
46. O time da empresa pode acessar os requisitos dos consumidores ou

de marketing como parte do suporte de deciso?
47. As expectativas internas obrigatrias so determinadas e

convertidas em requisitos documentados do ciclo de vida do produto?
48. Os requisitos internos so divididos em especificaes

documentadas do ciclo de vida do produto?
49. Pode-se rastrear cada especificao funcional em relao aos

requisitos do ciclo de vida dos produtos que a geraram?
50. O time da empresa pode acessar os requisitos do ciclo de vida dos

produto, como parte do suporte de decises?
Rogerio Omokawa
109
Metodologia de planejamento
Os mtodos de planejamento, avaliao e projeto de produtos podem ocorrer
de forma bottom-up ou top-down. Nesses mtodos, deve-se incluir as relaes de
anlise de benefcios e a integrao de tarefas e processos de desenvolvimento do
produto.
S
51. H um processo bottom-up de projeto, no qual todas as pessoas

contribuem para o planejamento, avaliao ou criao de produtos ou
especificaes funcionais?
52. H um processo top-down de projeto no qual requisitos dos

consumidores,
dos
produtos
ou
dos
sistemas
conduzem
especificaes documentadas para projetos de subsistemas funcionais?

S
53. obrigatrio que o time multidisciplinar considere as relaes de

benefcio que podem mudar a tecnologia do produto, arquitetura de
projeto ou desenvolvimento para o processo de manufatura?
54. Os requisitos do produto ou os requisitos do projeto de sistemas

conduzem tarefas e processos interrelacionados?
Rogerio Omokawa
110
Perspectiva de planejamento
Quando determina-se o processo de desenvolvimento necessrio para um
dado produto, a empresa inclui perspectivas de planejamento como parte do
processo.
S
55. Os documentos individuais de planejamento a curto prazo so

prioritrios para se iniciar uma tarefa?
56. A empresa requer documentos de planejamento a longo prazo para

o seu produto?
57. A empresa utiliza fases mltiplas (de vrios) anos de mtodos de

planejamento para cada famlia de produtos?
58. A empresa avalia o projeto de produto de melhor valor e, relao

ao
custo,
funcionalidade,
conformao
para
uso,
segurana,
performance e aceitao?
Validao
Os requisitos para o processo de desenvolvimento so validados avaliados
para determinar se as especificaes esto de acordo com os requisitos do
consumidor e se o processo definido permite obter o resultado pretendido.
S
59. As especificaes de cada subsistema funcional so validadas de

acordo com os requisitos do consumidor?
60. Os requisitos de disciplinas especificas so validados de acordo

com os requisitos do consumidor?
61. Os requisitos do processo e das multidisciplinas so validados em

relao aos requisitos do consumidor?
Rogerio Omokawa
111
62. So usados mtodos interativos para monitorar e alertar o time da

empresa quando ocorre falhas num requisito?
Normas
A empresa documenta e comunica s pessoas e times as convenes, linhas
guia, e procedimentos usados para a normalizao dos projetos. As normas devem
englobar os testes, a manufatura e as necessidades do consumidor.
S
63. A empresa possui um mecanismo que monitora o projeto de

acordo com as normas aplicveis?
64. A empresa utiliza normas de projeto para garantir a segurana dos

produtos?
65. A empresa usa normas de projeto para garantir testes de produtos,

manufaturabilidade e aceitabilidade?
66. A empresa revisa e melhora regularmente as normas de projeto?
Rogerio Omokawa
112
DIMENSO: DESENVOLVIMENTO DE PRODUTOS

Esta parte final do questionrio explora como a empresa atinge os fatoreschave que caracterizam a dimenso de desenvolvimento de produtos.
Banco de dados dos componentes
Quando um time parte do processo de desenvolvimento , todos os dados de
projeto e os dados de componente esto disponveis para todas as pessoas.
S
67. Cada pessoa responsvel pelo desenvolvimento de seus prprios

componentes e catlogo de componentes?
68. As mesmas normas so usadas por toda a empresa para representar

os dados dos componentes?
69. H um sistema bibliogrfico usado para gerenciar os dados de

componentes de todas as diferentes disciplinas envolvidas?
70. Os dados base do sistema bibliogrfico so ligados s ferramentas

de deciso para dar assistncia a cada projetista ao projetar
componentes ou conjuntos?
Processo de projeto
As metodologias e as validaes para o processo de projeto so
documentadas e medidas
S
71. As especificaes de processo do projeto so metodicamente

documentadas, para que as funes especficas do projeto (sistema,
software, hardware ou mecnicas), possuam repetibilidade e sejam
consistentes?
Rogerio Omokawa
113
72. A anlise determinstica usada para medir como esto as funes

de produo por exemplo, simulao lgica para medidas funcionais,
simulaes de defeitos para determinar a deteco de falhas, simulao
anloga para todos os parmetros e anlise de elementos finitos para
medidas de tolerncias mecnicas?
73. H avaliaes adequadas para o reaproveitamento de tecnologias

dos produtos e de suas unidades projetadas?
74. H mtodos adequados usados para integrar produtos e processos?
75. As informaes so extradas de projetos fsicos para atuar com

maior anlise de caractersticas do produto e sua performance?
76. So usados mtodos de anlise para considerar os processo, como

por exemplo, custos, testes, segurana, manufaturabilidade, e
aceitabilidade no estgio de projeto detalhado ou mesmo no incio do
conceito do produto?
77. As ferramentas de desenvolvimento do produto e o ambiente

computacional so inter-operveis para todas as disciplinas?
78. So utilizados sistemas de suporte de deciso e de gerenciamento

de processo?
Otimizao
Os gerentes reagem continuidade da evoluo tecnolgica
S
79. H metas para a melhoria do produto e do processo?
80. Grandes decises de projetos e seus principais fatores so

documentados, distribudos e analisados para guiar outros projetos?
Rogerio Omokawa
114
81. As ferramentas de simulao e modelagem de processos so

usadas no planejamento e melhoria dos processos de projeto?
82. Os projetos de produto, processo de desenvolvimento, requisitos e

ferramentas so sempre analisados e continuamente melhorados como
parte da estratgia de otimizao?
83. usado um programa de qualificao de fornecedores, para

selecion-los, quando h necessidade de compra de componentes de
produtos ou ferramentas?
Rogerio Omokawa
115
PARTE II
Leia as descries de cada fator-chave, e circule cada descrio cujos
mtodos so necessrios para o sucesso do desenvolvimento do produto XX. Voc
pode circular uma descrio, mais de uma, todas as quatro ou nenhuma delas. Uma
observao que pode ajudar em suas escolha notar que quanto mais complicado o
seu produto, mais descries voc ir circular para cada fator-chave.
DIMENSO: ORGANIZAO
Fatores Chave
Integrao
Times
Abordagem por
Abordagem por
Abordagem por
Abordagem por
Tarefa
Projeto
Programa
toda a Empresa
Um time
Um time
Times
possuem tarefas
disciplinar tem
multidisciplinar tem
multidisciplinares
especficas, com
uma perspectiva
uma perspectiva de
tm membros de
pouca interao
de projeto. Os
programa. Os
toda empresa,
entre engenheiros
dados no so
membros do time
incluindo
ou entre
facilmente
recebem treinamento gerncia,
disciplinas. Os
acessveis a
para entender melhor fornecedores,
dados so
outras
outras disciplinas.
manufatura,
controlados pelas
disciplinas.
Os dados so
vendas,
dos As pessoas
facilmente acessados consumidores e
pessoas.
servios.
por outras
disciplinas.
Empowerment
A gerncia
A gerncia
seleciona somente seleciona um
O time
Os times
multidisciplinar
multidisciplinares
uma pessoa para
lder para o time
seleciona seu prprio selecionam um
liderar. Pessoas
disciplinar. As
lder. O time tem
lder. Os times
tm
decises so de
autoridade para
possuem
responsabilidades. responsabilidade tomar decises, e os

times disciplinares
tomar decises e
prmios so
possuem
tomar conta das
dados ao time
responsabilidade de
disciplinas.
disciplinar.
encaminh-los.
Prmios so dados
Prmios so dados
a todos os times
ao time
multidisciplinares.
Prmios so dados do time. Os

s pessoas.
autoridade para
multidisciplinar.
Rogerio Omokawa
116
DIMENSO: ORGANIZAO
Fatores Chave
Treinamento
Educao
Abordagem
Abordagem
Abordagem por
Abordagem por toda a
por Tarefa
por Projeto
Programa
Empresa
e As pessoas
recebem
As pessoas
O time
Os times
recebem
multidisciplinar
multidisciplinares
treinamento em treinamento em recebe treinamento recebem treinamento em

especialidades
vrios
em efetividade de
efetividade de time.
especficas.
procedimentos
time. Os membros
Ferramentas interativas
de disciplinas,
do time pensam
de simulao podem ser
ferramentas e
holisticamente e
usadas para ensinar
normas.
usam ferramentas
mtodos de gerao de
como QFD. Os
dados e para forar
treinamentos so
exames de
realizados
procedimentos com
conforme situao
diferentes perspectivas.
especfica.
Suporte
Automao
de Ferramentas
tm interface
Ferramentas
Ferramentas de
Ferramentas de
centralizadas
multidisciplinas
multidisciplinas so
com disciplinas podem acessar
so integradas para integradas para cada
verticalmente.
dados de um
cada pessoa
pessoa atravs da
Dados so
projeto. Os
atravs de
empresa. Dados so
colhidos e
dados so
programas. Dados
utilizados para iniciar
so colhidos,
aes prioritrias para
guardados para colhidos e

uso futuro.
disponibiliza-
processados e
problemas ou
Disciplinas
dos para uso.
atualizados
procedimentos
com softwares
Um time de
imediatamente.
crescentes. Os times
e hardwares
disciplina pode
Um time pode
podem compartilhar
formar dados de
dados de hardware e
so disponveis formar dados

em uma
de software e
hardware e
software atravs da
plataforma
hardware.
software. A
empresa. A
sozinha. A
documentao
documentao
documentao
integrada dentro do integrada dentro de toda
criada em
ambiente de
a empresa no ambiente
sistema
desenvolvimento
de desenvolvimento de
desktop.
do produto.
produto.
Rogerio Omokawa
117
DIMENSO: INFRA-ESTRUTURA DE COMUNICAO

Fatores Chave
Abordagem por Abordagem por

Tarefa
Gerenciamento
do Produto
Abordagem por
Abordagem por toda
Programa
a Empresa
Projeto
Visualizaes
Suportes de decises
E-mail est
Relatrios on-
disponvel para
line e capacidade interativas de
cada pessoa.
de procura so
dados de produto cada pessoa.
Revises
disponveis para
esto disponveis Problemas e seus
tcnicas e
cada pessoa.
para cada pessoa. status so
inspees so
Gerncia de
Projeto do
automaticamente
conduzidas de
produto
produto e do
reportados.
maneira
disciplinada e
sistema so
apropriada.
consistente
conectados.
esto disponveis para
usada.
Dados de
Especificaes
Dados do
Dados de
Dados esto
Produto
do produto e
desenvolvimento
multidisciplinas
disponveis por toda
projeto so
de produtos so
na base de dados
empresa. Requisitos,
usados e
armazenados,
de
especificaes e dados
documentados
controlados,
desenvolvimento
do produto esto sobre
durante o
alterados e
de produtos so
o controle de verses e
processo de
passados para
inter-operveis
revises.
desenvolvimento uma base de

dados similar ou
de projeto
comum.
automticas.
Problemas so
Relatos de
Aes corretivas, A tendncia das aes
analisados por
problemas so
relatrios de
corretivas, relatos de
toda sua rota e
priorizados e
problemas e
problemas,
ento corrigidos.
programados, e
solicitaes de
solicitaes de
perseguidos at
melhoria so
melhoria e todas as
os problemas
armazenados em
outras decises so
pelas pessoas.
Feedback
entre ferramentas
serem corrigidos. uma base de
analisadas para
dados e ento
continuamente
usados como
melhorar o processo
indicadores para
de desenvolvimento
a satisfao do
do produto por toda a
cliente.
empresa.
Rogerio Omokawa
118
DIMENSO: REQUISITOS
Fatores Chave
Abordagem por
Abordagem por
Abordagem por
Abordagem por
Tarefa
Projeto
Programa
toda a Empresa
Definio de
Expectativas do
Requisitos de
Requisitos
Times por toda
Requisitos
consumidor e
consumidores ou
multidisciplinares
empresa tem
expectativas
marketing e
so buscados de
acesso on-line aos
internas so
requisitos internos especificaes
requisitos do
determinadas e
so detalhados em funcionais das
consumidor e de
convertidas para
especificaes
pessoas, voltando
marketing.
estabelecer e
funcionais
aos requisitos do
Requisitos do ciclo
documentar
documentadas e
consumidor ou de
de vida do produto
requisitos.
especificaes do
marketing e
so como parte do
ciclo de vida do
especificaes do
suporte de deciso.
produto.
ciclo de vida do
produto.
Metodologia de
O processo de
O processo do
Times
Requisitos do
Planejamento
projeto bottom-
projeto top-
multidisciplinares
produto e de
up. Todos as
down. O
consideram
projeto de sistemas
pessoas
consumidor, o
avaliaes de
conduzem a tarefas
benefcios, que
interrelacionadas e
a processos.
contribuem para o produto, ou os

planejamento,
requisitos de
podem mudar o
avaliao ou
projeto de
projeto de
criao para as
sistemas
arquitetura da
especificaes
conduzem s
tecnologia do
funcionais de
especificaes de
produto ou
produto.
documentos para
processo de
o projeto de
desenvolvimento
subsistemas
manufatura.
funcionais.
Rogerio Omokawa
119
DIMENSO: REQUISITOS
Fatores Chave
Abordagem por
Abordagem por Abordagem por
Abordagem por
Tarefa
Projeto
Programa
toda a Empresa
Perspectiva de
As pessoas
Um requisito da
Um requisito da
Um requisito da
Planejamento
documentam
empresa
empresa usar fase
empresa medir o
planejamentos
documentar o
mltiplas,
projeto do produto
prioritrios a curto planejamento a
planejando mtodos de melhor valor
prazo para
longo prazo para em todos os anos
comear uma
cada produto.
para cada famlia de custo,

produtos.
tarefa.
com relao ao
funcionalidade,
confiabilidade para
uso, segurana
performance e
aceitabilidade.
Validao
Normas
Especificaes de
Requisitos
Multidisciplinas e
Times por todas
subsistemas
especficos de
requisitos do
empresa so
individuais so
disciplinas so
processo so
automaticamente e
validados de
validados de
avaliados de acordo simultaneamente
acordo com os
acordo com os
com os requisitos
alertados quando
requisitos do
requisitos do
do consumidor.
uma falha no
consumidor.
consumidor.
Concordncia
Normas do
Normas de projeto
Normas de projeto
aplicada a normas
projetos so
so usadas para
so regularmente
de projeto so
usadas para
garantir teste de
revisadas e
monitoradas.
garantir a
produtos,
melhoradas
segurana do
manufaturabilidade
continuamente.
produto.
e aceitabilidade.
requisito ocorre.
Rogerio Omokawa
120

Fatores Chave
Abordagem por
Abordagem por
Abordagem por
Abordagem por
Tarefa
Projeto
Programa
toda a Empresa
As pessoas so
A empresa possui
Um nico sistema
O sistemas da base
dos
responsveis pelo
normas que so
de dados usado
de dados
Componentes
desenvolvimento,
utilizadas para
para desenvolver,
bibliogrficos
controle e
representar os
controlar e manter desenvolvido,
manuteno de
componentes.
os dados dos
controlado e
seus prprios
componentes, de
mantido por toda a
bancos de dados
todas as
empresa, ligado a
dos componentes.
disciplinas
uma ferramenta de
Estes dados so de
diferentes
suporte de deciso.
disciplinas
envolvidas.
Banco de Dados
especficas.
Processo de
Projeto
Mtodos padres
usada uma
A reutilizao e o
Processos so
e prticas so
anlise
compartilhamento
unidos fase de
documentados e
determinstica
da tecnologia do
conceito ou de
usados para
para medir as
produto e as
detalhamento do
gerenciar projetos
funes do
unidades de
projeto. Sistemas
e suas atividades,
produto. Mtodos
projeto so
de suporte de
para que esses
de anlises so
adequadamente
deciso e processos
sejam
usados para unir
avaliadas. O
de gerenciamento
consistentes.
os processos no
ambiente
so usados por toda
Informaes so
estgio de
computacional e
a empresa.
extradas de
conceito ou
as ferramentas de
projetos fsicos e
detalhe do projeto. desenvolvimento
so usados para
do produto so
analisar
inter-operveis
performance e
para todas as
caractersticas de
disciplinas.
produtos.
Rogerio Omokawa
121

Fatores Chave
Otimizao
Abordagem por
Abordagem por
Abordagem por
Abordagem por
Tarefa
Projeto
Programa
toda a Empresa
Metas para
Grandes decises
Ferramentas de
Projeto de produto,
melhoria do
de produtos e os
modelagens de
processo de
produto e
fatores que
processo e de
desenvolvimento,
processo so
conduzem a eles
simulao so
requisitos e
buscadas.
so
utilizadas no
ferramentas so
documentados,
planejamento e
simultaneamente
distribudos e
melhoria do
analisados e
analisados para
processo de
continuamente
guiar outros
projeto.
melhoradas como
projetos.
parte da estratgia
de otimizao da
empresa.
Programas de
qualificao de
fornecedores so
usados para
selecion-los.
Rogerio Omokawa
122
ANEXO 2: ROTEIRO DE ENTREVISTA PARA A CARACTERIZAO DA

IMPLANTAO DO SISTEMA
DADOS DE UMA PR-ENTREVISTA (COM O PRIMEIRO ENTREVISTADO)

1. DADOS DA EMPRESA
1.1. Nome
1.2. Local
1.3. Ano de instalao da empresa
1.4. Nmero de funcionrios
1.5. Qual a estimativa (em %) sobre sua participao nos seguintes mercados:
Mercado de veculos pesados no Brasil:
Mercado de veculos pesados fora do Brasil:
Qual o mercado mais importante para a empresa? Porqu?
2. CARACTERIZAO DO PRODUTO PRINCIPAL
2.1. Qual a linha de produtos atual da empresa?
2.2. Qual o produto principal? Quais suas caractersticas?
3. DADOS DO AMBIENTE DE DESENVOLVIMENTO
3.1. Quais as caractersticas do produto desenvolvido?
3.2. Qual o nmero de pessoas que trabalham no projeto? E qual a composio
do time de desenvolvimento?
3.3. Qual o cronograma de desenvolvimento?
Rogerio Omokawa
123
4. DADOS DO SISTEMA
4.1. Quem o fornecedor do sistema?
4.2. Quais as necessidades de hardware e software do sistema (arquitetura, tipo
de servidor/cliente, sistema operacional, base de dados)?
4.3. De acordo com a classificao do CIMdata, quais so as funcionalidades do
sistema escolhido?
4.4. Quais funcionalidades sero utilizadas?
4.5. Quais as customizaes realizadas no sistema?
Rogerio Omokawa
124
DADOS A SEREM COLETADOS COM TODOS OS ENTREVISTADOS

1. REQUISITOS DE GERENCIAMENTO DE DADOS
1.1. A empresa j utilizava algum tipo de sistema de gerenciamento de dados de
produto? Em caso positivo, qual o motivo da substituio?
1.2. Quais os requisitos de gerenciamento de dados de neste ambiente (Comparar
com o Item 2.5) ? Quais so os dados a serem gerenciados?
2. ESCOLHA DO SISTEMA
2.1. Existiram outras alternativas de sistema? Quais?
2.2. Quais os critrio de escolha do sistema PDM? E qual o mtodo utilizado
(anlise de valores, benchmarking, entrevistas com fornecedores) ?
2.3. Quais as pessoas responsveis pela escolha do sistema? Qual o critrio de
escolha dessas pessoas?
3. PLANEJAMENTO DA IMPLANTAO E METAS
3.1. Quais os motivos da implantao do sistema PDM?
3.2. Houve envolvimento do usurio no planejamento? Quais as contribuies?
Como foram escolhidos (quem, porqu, )?
3.3. Houve uma programao das atividades (cronograma)? Quais as fases da
implantao? Qual a durao?
3.4. Qual o tipo de implantao adotado? Qual o motivo desta escolha?
3.5. Foi definida uma mtrica para o acompanhamento do sistema? Qual?
3.6. Foi realizado um estudo de custos? Quais os fatores analisados? Qual o custo
da implantao?
3.7. Foi realizado uma anlise de impacto? Quais os fatores considerados?
Rogerio Omokawa
125
3.8. Houve envolvimento de nveis superiores?

3.9. Foram definidos objetivos/benefcios esperados?
3.10. Quais foram os passos realizados para a preparao da implantao do
sistema?
3.11. Qual o nmero de pessoas envolvidas na implantao? Quais suas funes?
4. SITUAO ATUAL
4.1. O cronograma proposto est sendo cumprido? Quais fases da implantao
foram realizadas at o momento?
4.2. realizado o acompanhamento da utilizao do sistema pelo usurio e o seu
nvel de satisfao quanto s funcionalidades/performance do sistema?
Como?
4.3. A performance do sistema est dentro do esperado? Em caso negativo,
porqu?
5. DIFICULDADES ENCONTRADAS E BENEFCIOS OBTIDOS
5.1. Quais foram as principais dificuldades encontradas durante a implantao do
sistema?
5.2. Foram detectados problemas quanto infra-estrutura (hardware, software,
rede, etc.)?
5.3. Quais as principais dificuldades encontradas pelo usurio? Quais as medidas
para sanar estas dificuldades?
5.4. Foram detectados problemas quanto ao funcionamento/performance do
sistema? Quais as medidas tomas para eliminar estes problemas?
5.5. Foram detectados problemas quanto ao planejamento de prazos e custos?
Quais?
Rogerio Omokawa
126
5.6. Quais os benefcios obtidos at agora com a implantao do sistema? Estes

benefcios esto de acordo com os benefcios esperados?
Rogerio Omokawa
127
ANEXO 3: RESULTADOS DA APLICAO DO QUESTIONRIO DE

AVALIAO DE UTILIZAO DE ENGENHARIA SIMULTNEA
CARGOS DAS PESSOAS QUE RESPONDERAM AO QUESTIONRIO
a) GPP
b) Supervisor de compras
c) Engenheiro de produto
d) Coordenador de mdulo
e) Engenheiro de produto
f) Supervisor
g) Consultor
h) Engenheiro de manufatura
i) Fornecedor de peas
j) Gerente de Informao
k) Coordenador de mdulo
l) Coordenador de mdulo
m) Consultor
n) Engenheiro de produto
o) Engenheiro de produto
p) Gerente
q) Consultor especialista
r) Engenheiro de manufatura
s) Engenheiro de compras
t) Engenheiro de compras snior
u) Consultor
Rogerio Omokawa
128
Tabela 5: Resultado do Nvel Atual do Fator-Chave Integrao dos Times

Integrao dos Times
Pesquisado
1
S
2
N
3
N
X
X
4
N
S
X
k
l
X
X
X
X
X
X
X
X
X
X
X
Resultado
15
17
Resultado
(%)
71
29
81
19
X
X
X
X
15
12
71
29
57
43
Rogerio Omokawa
129
Tabela 6: Resultado do Nvel Atual do Fator-Chave Autoridade

Autoridade
Pesquisado
5
S
6
N
X
X
X
X
X
X
X
X
X
X
11
N
X
X
Resultado 13
13 13
X
X
X
14
X
13
X
X
X
X
X
X
13
13
X
X
X
X
X
X
8
X
X
X
X
X
X
X
X
X
X
7
14
13
12
X
X
N
X
10
X
X
i
j
X
X
N
X
12
X
X
X
11
13
Resultado 65 35 35 65 65 35 67 33 65 35 62 38 65 35 60 40 45 55 35 65
(%)
Rogerio Omokawa
130
Tabela 7: Resultado do Nvel Atual do Fator-Chave Treinamento e Educao

Treinamento e Educao
Pesquisado
15
S
a
b
16
N
X
X
17
N
18
N
X
X
X
X
X
X
X
X
Resultado
12
13
14
14
Resultado
(%)
57
43
38
62
33
67
33
67
Rogerio Omokawa
131
Tabela 8: Resultado do Nvel Atual do Fator-Chave Suporte de Automao

Suporte de Automao
Pesquisado
19
S
20
N
21
N
X
X
22
N
X
X
i
j
l
m
X
X
X
X
X
X
Resultado
12
18
11
11
Resultado
(%)
63
37
95
58
42
45
55
Rogerio Omokawa
132
Tabela 9: Resultado do Nvel Atual do Fator-Chave Gerenciamento do Produto

Gerenciamento do Produto
Pesquisado
23
S
24
N
25
N
26
N
27
N
28
N
29
N
30
N
X
X
X
X
X
X
X
X
X
X
X
X
12
X
X
11 10
X
X
X
X
X
X
X
X
X
X
11 17
X
X
11
X
X
X
X
13
X
3
X
X
X
X
X
X
X
X
X
Resultado 16
X
X
10 11
Resultado 80 20 57 43 52 48 45 55 85 15 62 38 55 45 48 52
(%)
Rogerio Omokawa
133
Tabela 10: Resultado do Nvel Atual do Fator-Chave Dados Sobre o Produto

Dados Sobre o Produto
Pesquisado
31
S
32
N
33
N
X
X
X
X
36
N
X
X
X
X
X
X
X
X
X
X
X
X
X
Resultado 15
X
X
X
X
X
X
X
X
18
15
16 14
N
X
38
X
X
37
X
X
35
X
X
f
h
X
X
34
14
X
X
X
X
10 12
Resultado 71 29 86 14 71 29 16 84 67 33 70 30 44 56 60 40
(%)
Rogerio Omokawa
134
Tabela 11: Resultado do Nvel Atual do Fator-Chave Feedback

Feedback
Pesquisado
39
S
40
N
41
N
42
N
X
X
X
X
X
X
X
X
X
r
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Resultado
16
12
13
10
Resultado
(%)
76
24
71
29
24
76
56
44
Rogerio Omokawa
135
Tabela 12: Resultado do Nvel Atual do Fator-Chave Definio de Requisitos

Definio de Requisitos
Pesquisado
43
S
44
N
45
N
46
N
47
N
48
N
49
N
50
N
b
c
d
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Resultado
16
Resultado
(%)
80 20 70 30 42 58 72 28 56 44 56 44 31 69 44 56
14
X
X
X
X
X
X
X
X
X
X
X
6
11 13
11
Rogerio Omokawa
136
Tabela 13: Resultado do Nvel Atual do Fator-Chave Metodologia de

Planejamento
Metodologia de Planejamento
Pesquisado
51
S
52
N
53
54
b
c
f
g
h
i
X
X
X
X
Resultado
14
13
16
18
Resultado
(%)
82
18
76
24
84
16
95
X
X
Rogerio Omokawa
137
Tabela 14: Resultado do Nvel Atual do Fator-Chave Perspectiva de

Planejamento
Perspectiva de Planejamento
Pesquisado
55
S
56
57
58
N
i
j
k
l
X
X
m
n
X
X
X
Resultado
17
Resultado
(%)
47
53
89
11
X
X
19
16
95
84
16
Rogerio Omokawa
138
Tabela 15: Resultado do Nvel Atual do Fator-Chave Validao

Validao
Pesquisado
59
S
60
N
61
N
62
N
b
c
f
g
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Resultado
13
13
11
11
Resultado
(%)
65
35
72
28
61
39
61
39
Rogerio Omokawa
139
Tabela 16: Resultado do Nvel Atual do Fator-Chave Normas

Normas
Pesquisado
63
S
64
N
65
N
66
N
X
X
b
c
X
X
X
X
X
X
X
X
X
X
X
X
X
Resultado
16
19
17
14
Resultado
(%)
84
16
95
85
15
82
18
Rogerio Omokawa
140
Tabela 17: Resultado do Nvel Atual do Fator-Chave Banco de Dados dos

Componentes
Banco de Dados dos Componentes
Pesquisado
67
S
68
N
69
N
70
N
X
X
X
X
X
X
X
X
X
X
X
X
X
Resultado
18
15
12
11
Resultado
(%)
95
83
17
63
37
39
61
Rogerio Omokawa
141
Tabela 18: Resultado do Nvel Atual do Fator-Chave Processo de Projeto

Processo de Projeto
Pesquisado
71
S
72
S
73
N
74
N
75
N
76
N
77
N
78
N
b
c
X
X
X
X
X
X
X
X
X
X
X
X
X
X
14
18
14
Resultado 68 32 89 11 79 21 63 37 93
(%)
95
78 22 72 28
Resultado 13 6
16
15
12
13
Rogerio Omokawa
142
Tabela 19: Resultado do Nvel Atual do Fator-Chave Otimizao

Otimizao
Pesquisado
79
S
80
N
81
N
82
N
83
N
b
c
X
X
X
X
X
X
X
X
X
X
Resultado
17
10
17
12
17
Resultado
(%)
94
56
44
94
67
33
89
11
Rogerio Omokawa
143
Tabela 20: Resultado do Nvel Ideal da Dimenso Organizao

Dimenso: Organizao
Pesquisado
Integrao de
times
a b c
Autoridade
Treinamento e
educao
d a b c
d a b c
Suporte de
automao
d a b c
b
c
d
e
f
g
h
X
X
X
X
j
k
l
X
X
X
X
p
q
X X
X X
u
Resultado 2
X
X
X
3
X
X
X
10
X
X
X
X
6
10
X
X
X
10
Resultado 9 13 35 43 13 17 26 43 17 24 34 24 10 20 25 45
(%)
Lengenda
a - abordagem por tarefa
b- abordagem por projeto
c abordagem por programa
d abordagem por toda a empresa
Rogerio Omokawa
144
Tabela 21: Resultado do Nvel Ideal da Dimenso Infra-Estrutura de

Comunicao
Dimenso: Infra-Estrutura de Comunicao
Pesquisado
Ger. de produto
a
Dados de produto
d
Feedback
b
c
d
e
f
g
h
i
j
k
l
m
n
o
X
X
p
q
s
t
X
X
Resultado
10
10
Resultado
(%)
25
21
25
29
21
29
29
21
19
25
28
28
Lengenda
Rogerio Omokawa
145
Tabela 22: Resultado do Nvel Ideal da Dimenso Requisitos

Dimenso: Requisitos
Pesquisado
Definio de
requisitos
a b c
Metod. de
planejamento
a
b c
Perspectiva de
planejamento
d a
Validao
b c
d a
b c
Normas
d a
X
b c
b
c
d
e
f
g
X
X
X
j
k
l
X
X
X
X
p
q
s
t
u
Resultado
X
X
5 11
10
X
4
X
7
10
Resultado 16 34 19 31 26 15 30 30 24 21 21 34 22 30 22 26 22 22 28 28
(%)
Lengenda
Rogerio Omokawa
146
Tabela 23: Resultado do Nvel Ideal da Dimenso Desenvolvimento de Produtos

Dimenso: Desenvolvimento de Produtos
Pesquisado
BD de componentes
a
Processo de projeto
a
Otimizao
a
b
c
d
e
f
g
h
j
k
l
X
X
X
X
p
q
r
s
t
Resultado
10
10
Resultado
(%)
19
15
38
27
14
29
29
29
25
25
14
36
Lengenda
Rogerio Omokawa
147
REFERNCIAS BIBLIOGRFICAS
AFSARMANESH, H.; WIEDIJK, M.; MOREIRA, N.P.; FERREIRA, A.C. (1994).

Design of a distributed database for a concurrent engineering environment.
RBCM Journal of Brazilian Society of Mechanical Sciences. V16, n.3, 298310.
AGUIAR, A.F.S. (1995). Sistemtica de seleo de sistemas computacionais para o
auxlio s atividades de engenharia. So Carlos. 139p. Dissertao (Mestrado) Escola de Engenharia de So Carlos, Universidade de So Paulo.
BARRA, R.A. (1994). On the implementation of systems for realistic visualization of
STEP models. Berlim. Tese (Doutorado) Universidade Tcnica de Berlim.
CAMARINHA-MATOS, L.M.; OSRIO, A.L. (1994). An integrated platform for
concurrent engineering. RBCM Journal of Brazilian Society of Mechanical
Sciences. v.16, n.3, p.342-355.
CARROL, B. (1996). Benefits of EDMS/PDM (transparncia). Hudson. 69
transparncias color.
CARTER, D.E.; BAKER, B.S. (1992). Concurrent Engineering The product
development environment for the 1990s. Massachusetts, Addison Wesley
Publishing Company Inc.
CHIUSOLI, R.F.Z. (1996). Engenharia simultnea: estudo de casos na indstria
brasileira de autopeas. So Carlos. 147p. Dissertao (Mestrado) Departamento de Engenharia de Produo, Universidade Federal de So Carlos.
Rogerio Omokawa
148
CHRYSLER CORPORATION; FORD MOTORS COMPANY; GENERAL

MOTORS CORPORATION. (1995). Advanced Product Quality Planning
(APQP) and Control Plan Reference Manual, February.
CIMDATA (1996). Product data management: the definition. /folder/
CIMDATA (1997). CIMdata news: CIMdata reports PDM market grows 31% to
reach
$898
million
in
1996.
http://www.std.com/Newbury/CIMdata/pages/marketservice.htm. (14 Apr.).

CIMDATA (1998). PDM market tops $1.1 billion. Integrated Design and
Manufacturing, p.8, June.
CLARK, K.B.; FUJIMOTO, T. (1991). Product development performance: strategy,
organization and management in the world auto industry. Boston-Mass., Harvard
Business School Press.
CLAUSING, D. (1994). Total quality development: A step-by-step guide to
worldclass concurrent engineering. 2.ed. New York, ASME Press. p.1-172.
COSTA, C.P. (1994). Desenvolvendo produtos com engenharia simultnea e
workgroup computing. Mquinas e Metais, p.78-90, dez.
COSTA, H.C.B. (1996). Banco de dados. So Carlos. 80p. Apostila - Departamento
de Computao, Universidade Federal de So Carlos.
CRISTOVO, J.L.B.; GONALVES FILHO, E.V. (1995). Engenharia simultnea:
um estudo de caso real. In: ENCONTRO NACIONAL DE ENGENHARIA DE
PRODUO ENEGEP, 15, So Carlos, 1995. Anais. So Carlos,
Universidade Federal de So Carlos. v. 3, p.1672-1676.
DANE, F.C. (1990). Research methods. Belmont, California, Brooks/Cole
Publishing Company.
DAVENPORT, T.H. (1994). Reengenharia de processo: como inovar na empresa
atravs da tecnologia da informao. Rio de Janeiro, Editora Campus.
Rogerio Omokawa
149
DEPARTMENT OF TRADE AND INDUSTRY (1995). PDM focus product data

management workbook.
DICKERSON, C. (1996). Product Data Management: an overview, Association of
the Society of Manufacturing Engineers (ASME).
EVANS, S. (1991). Changing your way to a better business. Engineering Computers.
May.
GASCOIGNE, B. (1995). PDM: the essential technology for concurrent engineering.
World Class Design to Manufacture, v.2, n.1, p.38-42.
GEORGAKOPOULOS, D. et al. (1995). An Overview of Workflow Management:
From Process Modeling to Workflow Automation Infrastructure. Distributed
and Parallel Databases. v.3, p.119-153.
HALL, D. (1991). Concurrent Engineering: defining terms and techniques. IEEE
Spectrum. p. 24-25, July.
HITCHINS, S.C. (1994). Software tools for the product development process. In:
SYAN, C.S.; MENON, U. Concurrent engineering: concepts, implementation
and practice. London, England, Chapman & Hall. Cap. 10, p.163-184.
HOW the technology has evolved. (1997). http://pdmic.com/evoltech.html. (24
Aug.).
KIDDER, L.H.; JUDD, C.M.. (1986). Research methods in social relations. 5.ed.
New York, Holt, Rinehart and Winston.
MCINTOSH, K.G. (1995). Implementing engineering data management solutions.
World Class Design to Manufacture, v.2, n. 4, p.23-30.
MILLER, E.; MACKRELL, J.; MENDEL, A.; PHILPOTTS, M. (1994). PDM
buyers guide. 5.ed. Ann Arbor, CIMdata.
MILLER,
E.
(1997).
PDM
today
The
current
state
of
industry.
http://www.std.com/Newbury/CIMdata/pages/pdmlong.htm. (14 Apr.)

Rogerio Omokawa
150
OLIVEIRA, C.B.M.. (1998). Estruturao, identificao e classificao de produtos

em ambientes integrados de manufatura. So Carlos. 40p. Exame de
qualificao - Departamento de Engenharia Mecnica, Universidade de So
Paulo.
PADUA, E.M.M. (1996). Metodologia de pesquisa: abordagem terico-prtica. So
Paulo, Papirus Editora.
PIKOSZ, P. (1997). Product data management in the product development process.
Gteborg (Sweden). Thesis for the degree of licentiate of engineering Machine
and Vehicle Design, Chalmers University of Technology.
PIKOSZ, P.; MALMQVIST, J. (1996). Possibilities and limitations when
introducing PDM systems to support the product development process.
Proceedings NordDesign96. Espoo, Finland, p.165-175.
PIKOSZ, P.; MALMSTRM, J; MALMQVIST, J. (1997). Strategies when
introducing PDM systems in engineering companies. Advances in Concurrent
Engineering CE97.Rochester, MI, USA, p.425-434.
PRASAD, B. (1996). Concurrent engineering fundamentals: integrated product and
process organization. New Jersey, Prentice Hall.
ROZENFELD, H.; VEGA, H.A. (1995). Ambiente distribudo de solues para
suportar a engenharia simultnea. Mquinas e Metais, p.211-223, mar.
ROZENFELD, H. (1996). Reflexes sobre a manufatura integrada por computador
(CIM). In: WORKSHOP MANUFATURA CLASSE MUNDIAL: MITOS E
REALIDADE, So Paulo, 1996. Anais. EPUSP. p.25-38.
ROZENFELD, H. (1997). Modelo de referncia para o desenvolvimento integrado
de produtos (CD ROM).In: Encontro Nacional de Engenharia de Produo, 17,
1997. Gramado. p 1-8.
Rogerio Omokawa
151
SCHEDLER, S. (1994). Software solutions for concurrent engineering. In: SYAN,

C.S.; MENON, U. Concurrent engineering: concepts, implementation and
practice. London, England, Chapman & Hall. Cap. 12, p.201-220.
SWANTON, B. (1997). Are PDM/EDM systems really controlling product data? The
Report on Manufacturing, May, p.3-17.
SYAN, C.S. (1994). Introduction to concurrent engineering. In: SYAN, C.S.;
MENON, U. Concurrent engineering: concepts, implementation and practice.
London, England, Chapman & Hall. Cap. 1, p.3-23.
TAVARES, M. (1994). A STEP based information management system as a support
to a concurrent engineering environment. RBCM - Journal of Brazilian Society
of Mechanical Sciences. V.16, n.3, p311-317.
WARNECKE, G.; ZEIHSEL F. (1995). Systematic product development using
information and communication technology. Production Engineering, v.5, n. 1,
p.107-110.
WHEELWRIGHT,
S.C.;
CLARK,
K.B.
(1992).
Revolutionizing
product
development: quantum leaps in speed, efficiency, and quality. New York, The
Free Press.
WOODSON, T.T. (1966). Engineering Design. New York, MacGraw-Hill Book
Company. Cap. 1-3, p.1-56.
Rogerio Omokawa
152
OBRAS CONSULTADAS
AMARAL, D.C. (1997). Colaborao cliente fornecedor no desenvolvimento de

produto: integrao, escopo, e qualidade do projeto do produto estudo de caso
da indstria automobilstica brasileira. So Carlos. 192p. Dissertao (Mestrado)
- Departamento de Engenharia de Produo, Universidade Federal de So
Carlos.
BEFORE
the
PDM
project
starts:
What
should
you
know?
(1996).
http://pdmic.com/articles/artb4pdm.html. (20 July).

BROOKS, B.; SCHOFIELD N. (1995). Time-to-market: time equals money but
where does it all go?. World Class Design to Manufacture. v.2, n.6, p.4-10.
CERCOLA, O.V. (1995). ORACLE Banco de dados relacional e distribudo:
ferramentas para desenvolvimento. So Paulo, Makron Books.
GOTT, B. (1995). The product data management market. World Class Design to
Manufacture, v.2, n.4, p.18-22.
HOLLINSWORTH,
D.
(1994).
The
Workflow
Reference
Model.
http://www.aiai.ed.ac.uk/WfMC. (9 Nov.)
IZUCHUKWU, J.I. (1996). Process and technology perspectives on integrated
product development. Journal of Manufacturing Science and Engineering,
v.118, p.455-457.
JUNQUEIRA, G.B. (1994). Da engenharia tradicional engenharia simultnea no
setor industrial nacional. In: SEMINRIO DE PESQUISA.. So Paulo, 1995.
Rogerio Omokawa
153
Ncleo de Poltica e Gesto de Cincia e Tecnologia da Universidade de So

Paulo. p.1-19
KORTH, H.F; SILBERSCHATZ, A. (1989). Sistemas de banco de dados. So Paulo,
McGraw-Hill.
MDULO, D.L. (1991). Desenvolvimento de um ambiente de planejamento do
processo assistido por computador para planejamento interativo. So Carlos.
Dissertao (Mestrado) - Escola de Engenharia de So Carlos, Universidade de
So Paulo.
MOREIRA, D.A. (1994). Reengenharia: dinmica para a mudana. So Paulo,
Livraria Pioneira.
ROSENAU, Jr., M.D. (1990). Faster new product development. New York:
AMACOM.
RUDY, M. (1996). Ten steps to ensuring a successful PDM project.
http://pdmic.com/articles/art10stp.html (20 Nov.).
SDRC (1995). Manuais do Metaphase 2.1.1. Milford.
THE best of both worlds - Planning for effective coexistence of product data
management
and
MRP
II
systems.
(1997).
http://pdmic.com/articles/bestboth.html (23 Apr.).

TIBERTI, A.J. (1996). Desenvolvimento de um sistema gerenciador de fluxo de
trabalho para um ambiente de suporte a atividades de engenharia. So Carlos.
101p. Dissertao (Mestrado) - Escola de Engenharia de So Carlos,
Universidade de So Paulo.
UNIVERSIDADE DE SO PAULO. Escola de Engenharia de So Carlos. Servio
de Biblioteca (1993). Diretrizes para elaborao de dissertaes e teses na
EESC-USP. So Carlos.
VALERIANO, D.L. (1998). Gerncia em projetos, 1 ed. So Paulo, Makron Books.
Rogerio Omokawa
154
VEGA, H.A. et al. (1995). Aplicao de ferramentas CAE/CAD/CAPP em processos

de negcios definidos pela reengenharia. Mquinas e Metais. So Paulo, jun.
VIEIRA M.T.P. (1996). Banco de dados orientado a objetos.. So Carlos. 80p.
Apostila - Departamento de Computao, Universidade Federal de So Carlos.
Rogerio Omokawa

Dissertação para Aplicação de Um Sistema PLM

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Dissertação para Aplicação de Um Sistema PLM

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade de So Paulo

Escola de Engenharia de So Carlos

Utilizao de sistemas PDM em ambientes de

Dissertao apresentada Escola de

S se pode alcanar um grande

Aos meus pais, pela vida e ao

LISTA DE FIGURAS .................................................................................... I

2.3.2.1. A Dimenso da Organizao ................................................28

3.6. BENEFCIOS DA IMPLANTAO DE SISTEMAS PDM..............................67

5. A CARACTERIZAO DA IMPLANTAO DO SISTEMA PDM

Figura 1: Caractersticas do Desenvolvimento de Produtos.......................................11

Figura 20: Combinao de Todas as Formas de Estrutura de Produto.......................51

Tabela 1: Participao de Mercado das Principais Empresas Produtoras de Sistemas

Tabela 18: Resultado do Nvel Atual do Fator-Chave Processo de Projeto.............141

LISTA DE ABREVIATURAS E SIGLAS

Advanced Product Quality Planning

Computer Aided Design

Computer Aided Engineering

Computer Aided Manufacturing

Computer Aided Process Planning

Design For Manufacturing and Assembly

Engineering Data Management, Engineering Document Management,

Enterprise Resource Planning

Failure Mode and Effect Analysis

Initial Graphics Exchange Specification

ISO9000: International Organization for Standardization, srie 9000

Product Data Exchange System

Product Data Management

Product Development Team

Quality Function Deployment

Quality System, srie 9000

Standard dEchange et de Transfert

Standard for the Exchange of Product Model Data

Data eXchange File

Hewlett-Packard Graphics Language

Tagged Image File Format

Verband der Deutschen Automobilindustrie-FlchenSchnittstelle

OMOKAWA, R. (1999). Utilizao de sistemas PDM em ambientes de engenharia

A engenharia simultnea e os sistemas de gerenciamento de dados de produto

gerenciamento de dados; PDM; engenharia simultnea.

OMOKAWA, R. (1999). Use of PDM systems in concurrent engineering

The concurrent engineering and the product data management systems

Keywords: product data management system; data management; PDM;

Devido ao atual nvel de competio entre as empresas, surgiram diversas

levantar, segundo a bibliografia, as necessidades de gerenciamento de dados em

comparar as necessidades de gerenciamento de dados encontradas na bibliografia

levantar quais funcionalidades de sistemas PDM (product data management)

caracterizar um projeto de implantao real de um sistema PDM em um

1.3. PERGUNTAS DA PESQUISA

de campo particularmente indicada para pesquisas exploratrias e descritivas, como

existentes sobre o tema da pesquisa, obtendo embasamento terico para suportar o

1.5. LIMITAES DA PESQUISA

1.6. ETAPAS GERAIS DO TRABALHO

1.6.1. Reviso Geral da Bibliografia

evitar a duplicidade de pesquisa, ou seja, conduzir uma pesquisa j realizada por

utilizar as pesquisas realizadas para evitar os problemas conceituais e de

obter uma perspectiva cientfica do tema da pesquisa, pois a cincia envolve o

temas abordados neste trabalho, como engenharia simultnea, sistemas PDM, e de

1.6.2. Desenvolvimento dos Objetivos e do Mtodo

desses sistemas e o auxlio no gerenciamento de dados em ambientes de engenharia

1.6.3. Reviso Bibliogrfica Detalhada

1.6.4. Desenvolvimento da Forma de Coleta dos Dados

profissionais para testar e melhorar o questionrio e roteiros de entrevistas. Nas