Você está na página 1de 169

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
Tabela 2: Participao de Mercado das Principais Empresas Produtoras de Sistemas
PDM em 1996.....................................................................................................61
Tabela 3: Participao de Mercado das Principais Empresas Produtoras de Sistemas
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
engenharia simultnea.
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
engenharia simultnea.
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
tcnicas de resoluo problemas
FMEA de processo

desenvolv. do
conceito do
sistema de
manufatura

QFD
FMEA de processo
capabilidade de processo
poka yoke

planejamento
do processo

tcnicas de resoluo problemas

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:


Tabela 2: Participao de Mercado das Principais Empresas Produtoras de
Sistemas PDM em 1996
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:
Tabela 3: Participao de Mercado das Principais Empresas Produtoras de
Sistemas PDM em 1997
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

DIMENSO: DESENVOLVIMENTO DE PRODUTOS


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

DIMENSO: DESENVOLVIMENTO DE PRODUTOS


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
a - abordagem por tarefa
b- abordagem por projeto
c abordagem por programa
d abordagem por toda a empresa
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
a - abordagem por tarefa
b- abordagem por projeto
c abordagem por programa
d abordagem por toda a empresa

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
a - abordagem por tarefa
b- abordagem por projeto
c abordagem por programa
d abordagem por toda a empresa

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