anÁlise das funcionalidades de integraÇÃo entre … · apÊndice a – descriÇÃo do sistema...
TRANSCRIPT
Tese Apresentada à Divisão de Pós-Graduação do Instituto Tecnológico de Aeronáutica como
parte dos requisitos para obtenção do Título de Mestre em Ciência no Curso de Engenharia
Aeronáutica e Mecânica na Área de Mecatrônica e Dinâmica de Sistemas Aeroespaciais.
MARCOS LEANDRO SIMONETTI
ANÁLISE DAS FUNCIONALIDADES DE
INTEGRAÇÃO ENTRE SISTEMAS CAD/PDM E ERP
Prof. Dr. Luís Gonzaga Trabasso
ORIENTADOR
Prof. Dr. Homero Santiago Maciel
CHEFE DA DIVISÃO DE PÓS-GRADUAÇÃO
Campo Montenegro
São José dos Campos, SP, Brasil
2002
ANÁLISE DAS FUNCIONALIDADES DE
INTEGRAÇÃO ENTRE SISTEMAS CAD/PDM E ERP
MARCOS LEANDRO SIMONETTI
Composição da Banca Examinadora:
Prof. Dr. Arnoldo Souza Cabral Presidente - ITA
Prof. Dr. Luís Gonzaga Trabasso Orientador – ITA
Prof. Dr. Paulo Corrêa Lima UNICAMP
Prof. Dr. João Murta Alves ITA
Prof. Dr. Nizam Omar ITA
ITA
SUMÁRIO
RESUMO
ABSTRACT
CAPÍTULO I – INTRODUÇÃO 01
1.1 – Caracterização do problema em estudo 01
1.2 – Objetivos do trabalho 03
1.3 – Justificativas do trabalho 04
1.4 – Conteúdo do trabalho 05
CAPÍTULO II – PROCESSO DE DESENVOLVIMENTO DE PRODUTOS 08
2.1 – Desenvolvimento integrado de produtos (DIP) 10
2.2 – Engenharia simultânea 11
2.3 – Dados de definição do produto 18
2.4 – Dificuldades organizacionais 22
2.5 – Ferramentas computacionais 23
CAPÍTULO III – DESCRIÇÃO DAS FERRAMENTAS COMPUTACIONAIS 27
3.1 – Banco de dados e modelagem de dados 27
3.2 – Aplicativos CAD – Projeto Auxiliado por Computador 31
3.3 – Engenharia auxiliada por computador – CAE 35
3.4 – Manufatura auxiliada por computador – CAM 36
3.5 – Planejamento do processo auxiliado por computador – CAPP 38
3.6 – Intercambio de dados de produtos entre aplicativos CAD 39
3.7 – Sistemas ERP – Planejamento dos Recursos de Empresas 44
3.8 – Sistemas PDM – Gestão de dados de produtos 49
3.8.1 – Funções básicas de um sistema PDM 53
3.8.2 – Funcionalidades dos PDM 55
3.8.3 – Classificação de componentes 56
3.8.4 – Classificação de documentos 57
3.8.5 – Estrutura do produto 57
3.8.6 – Administração de processos do PDM 58
3.8.7 – União hierárquica 58
CAPÍTULO IV – FUNCIONALIDADES INTEGRÁVEIS 62
4.1 – Estrutura do produto – BOM (Lista de Materiais) 62
4.2 – Utilização da BOM 71
4.2.1 – Estruturas múltiplas e visões 72
4.2.2 – Pseudo-itens e itens fantasmas 73
4.3 – Identificação de produtos 74
4.4 – Os efeitos da falta de acurácia 74
4.5 – Administração da estrutura do produto 75
4.6 – Engenharia de configuração 75
4.7 – Tecnologia de grupo 78
4.8 – Visualização de arquivos 80
CAPÍTULO V – TÉCNICAS DE INTEGRAÇÃO 81
5.1 – Pessoas e papéis 81
5.2 – Transferência de arquivos 82
5.3 – Aplicação de programas de interface - API 83
5.4 – Acesso direto à base de dados 85
5.5 – Integração homogênea 85
5.6 – Integração homogênea com sistemas de diferentes fornecedores 86
5.7 – Interfaces baseadas em objetos distribuídos 86
5.8 – Estratégia de administração da estrutura do produto 87
CAPÍTULO VI – INTEGRAÇÃO DOS SISTEMAS CAD/PDM E ERP 95
6.1 – Descrição da empresa A 95
6.2 – Descrição da empresa B 96
6.3 – Características relevantes na integração CAD/PDM – ERP 97
6.4 – Descrição do fluxo de atividades 103
CAPÍTULO VII – CONCLUSÕES E SUJESTÕES PARA TRABALHOS FUTUROS 107
7.1 – Conclusões 107
7.2 – Sugestões para trabalhos futuros 109
REFERÊNCIAS BIBLIOGRÁFICAS 110
APÊNDICE A – DESCRIÇÃO DO SISTEMA SAP R/3 116
A.1 – Sistema SAP R/3 116
A.1.1 – Cadastro de material 117
A.1.2 – Administração de documentos no sistema SAP R/3 119
A.1.3 – Conexão com o sistema SAP R/3 121
A.1.4 – Interface do sistema SAP R/3 com sistemas de CAD e PDM 122
A.1.5 – Interface por diálogo 123
A.1.5.1 – Programa de interface com o sistema SAP R/3 – API 124
A.1.5.2 – Biblioteca de funções 125
A.1.6 – Interface por chamada de funções remotas – RFC 126
A.1.7 – Visualização de documentos CAD 128
APÊNDICE B – DESCRIÇÃO DO SISTEMA SMARTEAM 130
B.1 – Sistema SmarTeam 130
B.1.1 – Arquitetura do sistema SmarTeam 131
B.1.2 – Administração da estrutura do produto 132
APÊNDICE C – INTERFACE DE INTEGRAÇÃO ENTRE O SISTEMA SMARTEAM E
SISTEMAS ERP 133
C.1 – Software de interface SmartGateway 133
C.1.1 – Modelo de comunicação da integração 135
LISTA DE FIGURAS
Figura 1.1 – Integração dos aplicativos durante o ciclo de desenvolvimento do produto. 04
Figura 2.1 - Comparação entre o projeto seqüencial e o projeto desenvolvido simultaneamente
(SHENEIDER, 2001). 14
Figura 2.2 – Evolução do custo durante a vida do produto (BEDWORTH, 1991). 15
Figura 2.3 – Etapas do desenvolvimento de um novo produto (DIETER, 1991). 17
Figura 2.4 – Três principais atividades a serem integradas no desenvolvimento de produtos
(ANDREASEN, 1987). 18
Figura 3.1 - Modelo virtual do produto DMU (Digital mockup). 34
Figura 3.2 – Análise por elementos finitos – CAE. 36
Figura 3.3 - Elaboração de estratégia de usinagem – CAM. 37
Figura 3.4 – Utilização dos sistemas CAx nas empresas de autopeças (SOUZA, 2001). 39
Figura 3.5 - Padrões de troca de dados disponíveis em uso nas empresas do setor de autopeças
(SOUZA, 2001). 43
Figura 3.6 – Fluxograma MRP. 45
Figura 3.7 – Abrangência do MRP e do MRP II (GIANESI, 2000). 46
Figura 3.8 – Evolução dos sistemas de gestão corporativos. 47
Figura 3.9 - Estrutura típica de funcionamento de um sistema ERP. 49
Figura 3.10 - Departamentos que utilizam regularmente o sistema EDM/PDM (SOUZA,
2001). 51
Figura 3.11 – Cenário típico de administração de dados de produtos CAD-PDM. 60
Figura 4.1 – Desenho do produto final – Trem de pouso. 64
Figura 4.2 – Componentes do produto final desmontado – Trem de pouso explodido. 64
Figura 4.3 – Estrutura do produto para a lista de materiais da figura 4.1. 66
Figura 4.4 – Objetos da estrutura do produto – (OLIVEIRA, 1999). 69
Figura 4.5 – Relação entre os componentes do produto. 69
Figura 4.6 – Avião: exemplo de produto com grande número de variáveis. 77
Figura 5.1 – Classificação das abordagens técnicas de integração (ZANCUL, 1999 b). 87
Figura 5.2 – Classificação das empresas segundo seu ramo de atividade (MILLER, 2001). 88
Figura 5.3 – Utilização de sistemas PDM e ERP de acordo com o tipo de atividade da
empresa (MILLER, 2001). 89
Figura 5.4 – Primeira estratégia de integração. 91
Figura 5.5 – Segunda estratégia de integração. 92
Figura 5.6 – Terceira estratégia de integração. 93
Figura 6.1 – Fluxo de dados de engenharia. 105
Figura A.1 – Estrutura modular do sistema SAP R/3. 117
Figura A.2 – Cadastro de material. 118
Figura A.3 – Criação de documento no sistema SAP R/3. 120
Figura A.4 – Representação do fluxo dos dados de engenharia no sistema SAP R/3. 121
Figura A.5 - Transferência de dados entre as duas plataformas. 124
Figura C.1 - Sincronização do servidor ERP. 136
LISTA DE TABELAS
Tabela 2.1 – Trabalhos mais relevantes sobre teoria de projetos (TATE, 2001). 09
Tabela 3.1 - Comparação de padrões para intercâmbio de dados de produtos (KERN, 1997).42
Tabela 3.2 – Comparação entre os sistemas CAD, EDM, PDM e ERP. 61
Tabela 4.1 – BOM - Lista de materiais do trem de pouso. 65
Tabela 5.1 - Comparação da integração entre sistemas de suporte ao desenvolvimento de
produtos. 94
Tabela 6.1 – Principais questões a serem assumidas pelas empresas em busca da integração
entre as informações de projeto e manufatura. 100
Tabela A.1 – Comparação entre os tipos de interface de integração. 128
GLOSSÁRIO
API: Aplication Programming Interface - Aplicação de programa de interface.
BOM: Bills of Material - Lista de materiais.
CAD: Computer Aided Design - Projeto auxiliado por computador.
CAE: Computer Aided Engineering - Engenharia auxiliada por computador.
CAM: Computer Aided Manufacturing - Manufatura auxiliada por computador.
CAPP: Computer Aided Process Planning - Planejamento de processos auxiliado por
computador.
CAx: Computer-Aided anything - Abreviação genérica para CAD, CAE, CAM, CAPP e etc.
CN: Control Numerical - Controle numérico.
CNC: Computer Numerical Control - Comando numérico computadorizado.
CCM: Centro de Competência em Manufatura.
CORBA: Common Object Request Broker Arquitecture - Padrão industrial de definição
controle e comunicação de objetos orientados.
DBMS: Data Base Management System - Sistema de gerenciamento de banco de dados.
DCOM: Distributed Component Object Model - Arquitetura de gerência de dados
desenvolvida pela empresa Microsoft.
DIP: Desenvolvimento integrado de produtos.
DLL: Dynamic Link Library - Biblioteca de ligação dinâmica.
DMU: Modelo digital do produto.
EDM: Engineering Data Management - Administração dos dados de engenharia.
ER: Entidade relacional.
ERP: Enterprise Resource Planning - Sistema de gestão corporativo.
ERP II: Sistema de gestão da cadeia de suprimentos.
ES: Engenharia simultânea.
GIS: Geographical information system - Sistema de informação geográfico.
IGES: Initial Graphics Exchange Specification – Padrão para especificação de alterações
gráficas.
MRP: Material Requirements Planning - Planejamento de recursos de materiais.
MRP II: Manufacturing Requirements Planning - Planejamento de recursos de manufatura.
OMG: Object Management Group - Grupo de empresas desenvovedoras do padrão CORBA.
OODB: Object Oriented Data Bases - Banco de dados orientados a objetos.
PC: Personal Computer - Computador pessoal.
PCP: Planejamento e controle da produção.
PDM: Product Data Management - Software de Administração de dados de produtos.
PN: Part Number - Número do item.
RFC: Remote Function Call - Função de comunicação remota.
SAP R/3: Software comercial de gestão corporativo.
SET: Standart D’enchange et Transfer – Padrão para transferência de alterações.
STEP: Standard for the Exchange of Product Data - Padrão neutro que representa o produto
em toda seu ciclo de vida.
UNIX: Sistema operacional multi-tarefas.
W3C: World Wide Web Consortium - Entidade responsável pela definição das regras técnicas
da Internet.
XML: eXtended Markup Language - Linguagem computacional utilizada para descrever
informações estruturadas.
Todas as marcas e nomes usados nesta dissertação pertencem aos seus respectivos
proprietários.
“A mente que se abre a uma nova idéia jamais volta ao seu tamanho original”
Albert Einstein
RESUMO
O atual processo de globalização inseriu as empresas em novos desafios. Um desses
desafios, fortemente relacionado com a estratégia competitiva das empresas é o de
desenvolver produtos cada vez melhores com tempo de desenvolvimento (lead times) e custos
cada vez menores.
As empresas têm investido grande quantidade de recursos em aplicativos
computacionais que auxiliam o processo de desenvolvimento de novos produtos, como os
aplicativos de projeto auxiliado por computador – CAD – sistemas de gestão de dados do
produto – PDM – e sistemas de gestão corporativos – ERP.
Estes aplicativos atualmente são utilizados de maneira isolada dentro das empresas, de
maneira a formar ilhas de automação entre os usuários destes sistemas.
Este trabalho visa apresentar as principais dificuldades e vantagens na utilização de
soluções integradas no processo de desenvolvimento de produtos, assim como a análises
técnicas do processo de integração entre os sistemas CAD/PDM com os sistemas ERP.
Para demonstrar o processo de integração foram analisadas as potencionalidades de
integração dos sistemas computacionais do Centro de Competência de Manufatura, e suas
funcionalidades integráveis.
ABSTRACT
The current globalization process has challenged the companies in many ways. One of
these, strongly related to the competitive strategy of the companies, is to develop quality
products with shorter lead times and smaller prices.
The companies have been investing great amounts of resources in computer systems
that aid the development process of new products such as the Computer Aided Design –
CAD, Product Data Management - PDM systems, and Enterprise Resource Planning - ERP.
These applications now used up to now in an isolated way inside the companies,
forming automation islands among the users of these systems.
This work seeks to present the main difficulties and advantages in the use of integrated
solutions in product development process as well as technical analyses of the integration
process between CAD/PDM systems and ERP systems.
To demonstrate the integration process, the potentiality of integration of computer
systems from the Competence Center of Manufacturing (Centro de Competência de
Manufatura) and its integrated functionalities were analyzed.
AGRADECIMENTOS
Ao professor Luís Gonzaga Trabasso pela orientação, amizade e confiança.
A professora Carmem, por todo o apoio a realização deste trabalho.
Aos demais professores do programa de pós-graduação, pelos ensinamentos durante
todo o período do mestrado e pelo auxílio na realização deste trabalho.
Aos demais companheiros do programa de pós-graduação, por toda a ajuda e por me
aturarem durante este período.
Aos amigos do Centro de Competência em Manufatura.
A todos que, de uma forma ou de outra, contribuíram neste trabalho e que não foram
citados.
Meu muito obrigado.
DEDICATÓRIA
Aos meus pais José e Inês, pelo amor e por sempre apoiarem nos meus estudos.
1
CAPÍTULO I – INTRODUÇÃO
1.1 – Caracterização do problema em estudo
No período de 1400 até aproximadamente 1700, a civilização moderna atravessou seu
primeiro surto econômico. Foi a Revolução Comercial, erradicando a economia estática da
Idade Média e substituindo-a por um capitalismo dinâmico, dominado por comerciantes,
banqueiros e construtores navais. Na seqüência, a humanidade passa pela Revolução
Industrial, estendendo-se aos domínios da produção. Tanto quanto é possível reduzi-la a uma
fórmula sintética, segundo DURAN (1958) pode-se dizer que a Revolução Industrial
compreendeu:
• A mecanização da indústria e da agricultura;
• A aplicação da energia à indústria;
• O desenvolvimento do sistema fabril;
• Uma expansão sem precedentes dos meios de transportes e comunicação;
• Um aumento notável do domínio capitalista em quase todos os campos da atividade
econômica.
A Revolução Industrial induziu o aparecimento de múltiplas inovações, entre elas, os
primeiros progressos da tecnologia e inovações mecânicas, causando uma diferenciação dos
fabricantes com relação à facilidade com que se adaptavam ao novo sistema e absorviam
essas novas tecnologias, atingindo o mercado com seus produtos com mais facilidade e em
menor tempo. Para isso havia uma necessidade de agilizar o processo produtivo
(TOMAZETI, 2001).
As grandes inovações tecnológicas que marcaram o fim do segundo milênio,
especialmente nas áreas de telecomunicações, informática, engenharia, etc., associadas à
2
globalização da economia, produziram e continuam produzindo profundas transformações nas
pessoas e instituições, como conseqüência dos necessários ajustes aos novos paradigmas e
modelos socioeconômicos.
Com a globalização da economia, foram acrescidos às empresas novos desafios.
Segundo BREMER (1995), isto aconteceu porque a globalização propiciou a oferta e a
comercialização de produtos em diferentes países, aumentando assim o número de
concorrentes. Conseqüentemente, ocorreram grandes mudanças nos critérios de
competitividade, que passaram a ser definidos, segundo BREMER (1995), por parâmetros
mundiais como qualidade do produto, preço, prazo de entrega e diversificação, entre outros.
Estes parâmetros têm provocado profundas mudanças no perfil fabril, forçando os
empreendimentos industriais a uma constante melhoria da produtividade. Esta realidade
sugere ações para que sejam produzidos bens que satisfaçam as necessidades mercadológicas,
através da diversificação de produtos e diminuição do ciclo de vida dos produtos. Para
sobreviver neste mercado cada vez mais competitivo, as empresas necessitam adotar novas
técnicas de gestão e de inovação tecnológica, segundo BATOCHIO (1991).
Durante as últimas duas décadas, empresas de diferentes setores têm apresentado
resultados práticos que demonstram a importância do processo de desenvolvimento do
produto num mercado competitivo. Para ser competitiva, uma companhia tem que ser a
primeira a comercializar um produto novo (SVENSSON, 2000), e em muitas das vezes, estes
produtos devem ser personalizados. Assim, o sucesso de uma empresa está diretamente ligado
à sua capacidade de atender as necessidades dos clientes através do desenvolvimento de
produtos e serviços.
Diante deste contexto, surgiram diversas propostas para auxiliar as empresas a atingir
seus objetivos e sobreviver neste ambiente, dentre elas a de Desenvolvimento Integrado de
Produto - DIP.
3
Na sua essência, o DIP é uma abordagem de projeto que busca a integração do projeto
do produto ao planejamento de sua produção. Procura-se ainda na fase conceitual do produto,
antecipar e solucionar problemas dos vários estágios do ciclo de vida do produto, tais como:
fabricação, montagem, testes, qualidade, assistência técnica, estocagem, expedição e
reciclagem, entre outros (LOUREIRO, 1994).
A necessidade de preparar profissionais dentro de uma filosofia integrada de
desenvolvimento de produto, que abrange toda filosofia DIP, desde a sua concepção até a
manufatura, utilizando ferramentas computacionais e conceitos atualizados motivaram a
implantação do Centro de Competência em Manufatura (CCM) nas dependências do Instituto
Tecnológico de Aeronáutica (ITA), local escolhido para estudo de caso deste trabalho.
1.2 - Objetivos do trabalho
• Análise dos métodos e técnicas que possibilitem a integração de sistemas de CAD,
PDM e ERP dentro da proposta DIP;
• Análise das funcionalidades computacionais integráveis em ambientes de engenharia
simultânea;
• Análise das principais características que determinam as abordagens de integração a
serem utilizadas pelas empresas;
• Introduzir critérios que auxiliem o processo de implantação de interfaces de integração
entre sistemas CAD/PDM e ERP;
A síntese dos objetivos traduz na contribuição que descreve as possibilidades técnicas
de integração entre os aplicativos computacionais utilizados no processo de desenvolvimento
de produtos apresentado na figura 1.1.
4
Figura 1.1 – Integração dos aplicativos durante o ciclo de desenvolvimento do
produto.
1.3 - Justificativas do trabalho
As empresas brasileiras apresentam uma grande dificuldade na adoção e execução da
proposta de desenvolvimento integrado de novos produtos (COSTA, 1995), devido à falta de
recursos para a implementação de sistemas computacionais integrados e de um método que
aborde as funcionalidades integráveis claramente. Atualmente não há um procedimento
sistemático para avaliar qual é a melhor forma de integrar aplicativos CAD/PDM com
sistemas de ERP, sendo este assunto restrito a empresas de consultoria.
CAD
CAE
CAM
OUTROS.
PDM ERPINTERFACE
EMANÁLISE
5
Segundo MILLER (2001), não há uma solução única (que atenda todos os casos)
quando se deseja integrar sistemas PDM e ERP. Este trabalho procura apresentar as
características genéricas encontradas no processo de integração independente de questões
comerciais.
1.4 - Conteúdo do trabalho
Além desse capítulo, esta dissertação foi organizada de acordo com a seguinte
estrutura:
Capítulo II – Processo de Desenvolvimento de Produtos
Este capítulo apresenta um histórico do desenvolvimento integrado de produto e suas
principais características e ferramentas.
Capítulo III - Descrição das Ferramentas Computacionais
Para o estudo da integração e implementação de aplicativos de software e
equipamentos utilizados na engenharia para o desenvolvimento de novos produtos, deve-se
primeiramente conhecer os sistemas computacionais e os meios que permitem sua integração.
Neste capítulo é apresentada uma descrição dos sistemas computacionais que foram
escolhidos como objeto de estudo de integração de documentos de engenharia.
6
Capítulo IV - Funcionalidades Integráveis
O propósito deste capítulo é analisar as características do produto determinantes em
seu processo de criação cujas alterações influenciam no projeto do produto assim como os
métodos de integração destas características nos diversos setores de desenvolvimento do
produto.
Capítulo V – Técnicas de Integração
Existem atualmente várias técnicas de integração entre sistemas CAD/PDM e ERP.
Cada técnica representa um nível de complexidade e funcionalidades criadas para atender
necessidades empresariais específicas. Este capítulo apresenta as técnicas de integração entre
sistemas PDM e ERP tratadas neste trabalho, válidas igualmente para integração de sistemas
CAD com sistemas ERP.
Alguns autores empregam diferentes nomenclaturas para se referir à mesma
abordagem de integração, o que motivou a iniciativa de uniformizar a nomenclatura utilizada
neste trabalho.
Capítulo VI – Integração dos sistemas CAD/PDM e ERP
Este capítulo apresenta considerações de ordem prática na integração entre sistemas
CAD, PDM e ERP, de maneira a exemplificar o processo de gerenciamento de dados do
produto durante seu ciclo de vida. Para isto é feita uma comparação entre empresas que se
utilizam deste tipo de integração.
7
Capítulo VII – Conclusões e sugestões para trabalhos futuros
São apresentados os resultados encontrados: análises comparativas, sugestões de
procedimento, dificuldades encontradas durante todo o processo de integração de sistemas
CAD/PDM com sistemas ERP. As conclusões decorrem da análise dos resultados obtidos.
Este capítulo apresenta sugestões e abordagens para futuros trabalhos sobre o assunto de
integração entre sistemas CAD/PDM e ERP.
8
CAPÍTULO II – PROCESSO DE DESENVOLVIMENTO DE PRODUTOS
Pesquisas na área de desenvolvimento de produtos e as técnicas associadas são
realizadas atualmente em todo o mundo, no intuito de suportar as necessidades industriais. Os
primeiros esforços na área de desenvolvimentos de produtos tiveram início na Alemanha,
sendo datado de 1852 segundo TATE (2001) (ver tabela 2.1). Pode-se correlacionar a posição
de destaque da Alemanha no cenário mundial como a maturidade do país na área de
desenvolvimento de produtos.
Assim, a habilidade de projetar novos produtos é obtida através do estudo de técnicas
de projeto e da experiência com problemas reais, segundo LOUREIRO (1994).
9
Pesquisador
Publicação
Ano
F. Redtenbacher Prinzipen der Mechanik und des Mashinenbaus 1852 F. Reuleaux and C. Moll Konstruktions für den Maschinenbau 1854 F. Reuleaux Teorestische Kinematic: Gründzüge einer Theorie des
Maschinenwesens 1875
C. Bach Die Maschinenelemente 1881 A. Riedler Das Machinenzeichnen 1913 A. Erkens Beiträge zu Knostruktionserziehurg 1928 F. Kesselring Die starke Konstruktion 1942 H. Wörgerbaur Die Technik des Konstruierens 1943 F. Zwicky The Morphological Method of Analysis and Construction 1948 G. Niemann Maschinelemente 1950 F. Kesselring Betwertung von Konstruktionen 1951 G. S. Altshuller On the Psychology of Inventive Creativity 1956 R. Matousek Konstruktionslehre des Allgemeinen Maschinenbaus 1957 M. Asimow Introduction to Design 1962 A. Leyer Maschinenkonstruktionslehre 1963-71 H. A. Simon The Science of Design 1969 J. C. Jones Design Methods 1970 W. Rodenacker Methodishes Konstruinren 1970 G. S. Altshuller Algorithm of invention 1973 R. Koller Eine Algoritmisch-physikalisck Orienterte
Konstruktionsmethodik 1973
V. Hubka Theorie der Maschinensysteme 1973 VDI 2222 Blatt 1 Konzipieren Thechnisher Produkte 1973 F. Hansen Konsttruktionswissenschaft – Grundlagen und Methoden 1974 K. Roth Aufbau und Handhabung von Konstruktionskatalogen 1974 V. Hubka Theorie der Konstruktionsprozesse 1976 F. Olsson Systematik Konstruktion 1976 G. Taguchi Jikken Keikakuho (Eng. Trans. System of Experimental Design) 1977-78 G. Pahl and W. Beitz Konstruktionslehre 1977 N.P. Suh, A. C. Bell and D.C. Grossard
On an Axiomatic Approch to Manufacturing and Manufacturing System
1978
G. Nadler The Planning and Design Approch 1981 G. Boothroyd and P. Dewhurst
Design for Assembly – A Designer’s Handbook 1983
S. Pugh Further development of the Hypothesis of Static/Dynamic Concepts in Product Design
1985
D. G. Ullman Mechanical Design Methodology 1986 J. Hauser and D. Clausing The House of Qualitty 1988
Tabela 2.1 – Trabalhos mais relevantes sobre teoria de projetos (TATE, 2001).
10
2.1 – Desenvolvimento Integrado de Produtos (DIP)
O conceito de DIP pode ser definido como o resultado da integração das seguintes
contribuições:
• Técnicas de integração da manufatura por computador;
• Conceito de engenharia simultânea;
• Conceito de qualidade total;
• Técnicas de administração dos dados do produto;
• Técnicas de administração da configuração;
• Postura cultural que permita a reunião dessas técnicas e conceitos de forma harmônica
e construtiva.
Na fase inicial do desenvolvimento de um produto, as informações de oportunidades
de mercado, possibilidades técnicas, e requisitos da produção devem ser combinadas para se
definir a estrutura do novo produto. Isto inclui seu projeto conceitual, mercado alvo,
necessidades de investimentos e impacto financeiro.
Segundo SLACK (1999) o objetivo da atividade de desenvolvimento de produto é
satisfazer as necessidades dos consumidores, portanto, o desenvolvimento começa no
consumidor e termina nele próprio. O projeto começa com idéias vindas do consumidor e
termina na sua tradução em uma nova especificação.
Devido ao fato de o DIP se tornar, cada vez mais, uma atividade multidisciplinar,
fatores como: linguagem comum para a comunicação do projeto, educação para o projeto,
ambiente de trabalho e condução do trabalho em grupo de pessoas, adquirem cada vez mais
relevância, levando à organização de times multidisciplinares de projeto (LOUREIRO, 1994).
11
Time multidisciplinar é um pequeno número de pessoas com habilidades
complementares que estão comprometidas com um propósito, conjunto de metas de
desempenho e abordagens comuns para os quais elas se consideram mutuamente
responsáveis.Para que o DIP tenha sucesso, é preciso que exista a comunicação efetiva entre
os integrantes do time de projeto. Esta comunicação envolve as pessoas, a troca de dados
entre os sistemas computacionais utilizados e, talvez a atividade mais importante, a
documentação e gerenciamento das informações e decisões realizadas, para que possam ser
recuperadas sempre que necessário. Estas informações por sua vez, dependem cada vez mais
de um suporte computacional (AGUIAR, 1995).
A característica multidisciplinar inserida no DIP foi fator determinante para a busca de
uma nova abordagem para o projeto de engenharia, a abordagem por engenharia simultânea
(Loureiro, 1994).
2.2 – Engenharia Simultânea
Desde o começo do processo de industrialização, o desenvolvimento de novos
produtos era realizado de forma seqüencial, ou seja, cada área funcional da empresa, após
executar suas atividades de desenvolvimento, transferia a documentação para o departamento
seguinte. Os profissionais envolvidos nesta abordagem de desenvolvimento tradicional eram
especialistas, que conheciam muito bem o escopo técnico dos produtos, mas que não tinham
visão do todo em relação ao processo de desenvolvimento de produtos. Essa abordagem era
possível uma vez que esses produtos não possuíam grande sofisticação tecnológica.
Com o avanço da tecnologia e da crescente complexidade dos produtos, essa
abordagem tornou-se ineficiente. Além disto, as empresas começaram a apresentar diversos
problemas e limitações, tais como: dificuldade de projetar com simplicidade, falta de atenção
12
com a qualidade do produto, tempos excessivos de desenvolvimento, inexistência de
integração entre as fases de projeto e produção, falta de foco no cliente, pouco envolvimento
com fornecedores no desenvolvimento de produtos e falhas no processo de melhoria contínua
(ZANCUL, 2001).
Pela proposta da engenharia simultânea, as atividades do processo de desenvolvimento
passaram a ser efetuadas de forma concorrente.
A engenharia simultânea é um conceito inserido na proposta de desenvolvimento
integrado de produto, que tem como proposta detalhar o projeto de um produto enquanto
simultaneamente desenvolve a capacidade de produção, capacidade de suporte de campo e
qualidade, entre outros. A filosofia de engenharia simultânea é uma abordagem de projeto que
possibilita a integração entre as diversas etapas do ciclo de vida dos produtos (LOUREIRO,
1994).
A engenharia simultânea promove o desenvolvimento simultâneo de atividades
diferentes, em oposição ao processo convencional, ou seja, uma atividade começa antes que a
anterior esteja concluída, de forma que haja trabalho simultâneo, por isso espera-se uma
redução no tempo de desenvolvimento de produtos. Com a utilização da estratégia da
engenharia simultânea no desenvolvimento de produto, tem-se um maior conhecimento do
produto, já no início de seu desenvolvimento, aumentando-se desta maneira, o conhecimento
necessário para as decisões no estágio inicial do desenvolvimento. (SOUZA, 2001).
A engenharia simultânea é utilizada como solução para o aumento da eficiência e para
a redução do tempo de desenvolvimento do produto. O processo de desenvolvimento
convencional (serial ou seqüencial), onde os sistemas para o desenvolvimento de produto não
se comunicam e diferentes funções são realizadas de modo seqüencial, provoca atrasos na
concepção final do produto, pois durante o projeto se dificuldades aparecerem em uma
atividade, isto pode exigir que o projeto seja interrompido parado, enquanto a
13
responsabilidade volta para a etapa anterior (SLACK, 1999). Esse fenômeno é conhecido
como oscilação de projeto.
Diversos autores como BEDWORTH (1991), DIETER (1991), VALERIANO (1998)
argumentam que a engenharia simultânea em sua essência é a integração do projeto do
produto e planejamento de processo em uma atividade comum.
De acordo com LOUREIRO (1994), a engenharia simultânea é uma abordagem
integrada para o projeto de engenharia que antecipa para a etapa de concepção, o
planejamento dos processos e o planejamento da produção, contrariamente do que acontece na
estrutura departamental tradicional (seqüencial), que advêm do principio da divisão do
trabalho, segundo MACHLINE (1976). A engenharia simultânea promove uma maior
produtividade na atividade de projeto, redução do número de mudanças de engenharia, menor
custo, maior qualidade, produtividade e prazo menor para lançamento dos produtos, devido ao
menor tempo de desenvolvimento, embora se aumente o tempo e os recursos gastos na fase
conceitual do projeto como apresentado na Figura 2.1. Isto se deve as oscilações no projeto,
onde alterações necessitam ser feitas em fases finais do projeto necessitando ser refeitas e
retornar algumas fases do desenvolvimento. A engenharia simultânea integra, para o
desenvolvimento do produto, os setores de projeto, manufatura, pós-venda, qualidade,
embalagens e marketing entre outros.
14
Figura 2.1 - Comparação entre o projeto seqüencial e o projeto desenvolvido
simultaneamente (SHENEIDER, 2001).
Com a engenharia simultânea, os problemas típicos dos modelos seqüenciais de
desenvolvimento de produtos são eliminados ou minimizados. Pode-se citar, por exemplo, as
constantes mudanças do projeto em virtude de problemas identificados tardiamente (em fases
posteriores do desenvolvimento), as dificuldades para a fabricação e montagem dos produtos
entre outras (SHENEIDER, 2001).
A atividade de concepção do produto tem um efeito importante no custo de sua
produção, pois muitas das decisões tomadas durante a fase conceitual do produto definirão a
5%
30%
15% 55% 25%
15% 35% 20%
Conceituar Detalhar Revisar Validar
Projeto Seqüencial
Projeto Simultâneo
40%ECONOMIA
Tempo
15
parcela majoritária de seu custo. Faz sentido, portanto, avaliar as diversas opções com as
quais o projetista se depara em termos de seu efeito no custo de manufatura (SOUZA, 2001).
De acordo com a figura 2.2, (BEDWORTH, 1991), 70% dos custos de produção de
um produto são determinados durante a fase de formulação conceitual do projeto, embora na
fase desenvolvimento apresente um baixo custo (aproximadamente 20%), isto justifica um
investimento maior na fase conceitual de desenvolvimento do produto, visto que alterações do
projeto em fases posteriores acarretariam um custo total muito maior.
Figura 2.2 – Evolução do custo durante a vida do produto – BEDWORTH (1991).
100
25
75
50
Custo do Ciclo de Vida
(Porcentagem Acumulada)
70%
85%
95%
1% 7%
18%
50%
D
esen
volv
imen
todo
conc
eito
D
esen
volv
imen
to e
m la
rga
esca
la
Pr
oduç
ão
O
pera
ções
eSu
porte
TEMPO
Dem
ostra
ção
Val
idaç
ão
Custo Determinado
Custo Incorrido
16
DIETER (1991) apresenta na figura 2.3, as fases de desenvolvimento do produto,
delimitando as fases em que são utilizadas as ferramentas de CAD e CAM. BEDWORTH
(1991), VALERIANO (1998), ROZENFELD (1997), LOUREIRO (1994), SHENEIDER
(2001), BERNARDES (1999), apresentam maneiras particulares para descreverem as fases do
desenvolvimento do produto, mas todos são unânimes quanto à necessidade de serem
elaboradas de maneira integrada entre os diversos setores da empresa, através da formação de
times multidisciplinares, onde os integrantes necessitam ter uma visão holística do negócio
(ROZENFELD, 2001).
A falta de uma linguagem comum entre os diversos setores de uma industria é a maior
razão de confusão durante as diferentes fases do projeto (LOUREIRO, 1994), resultando,
conseqüentemente, na fragmentação dos dados de projeto. A documentação inclui arquivos
CAD, desenhos de componentes dimensionados, esboços, desenhos de processo, modelos de
sólidos 3D. É difícil, senão impossível, manter a consistência da informação através dessas
representações.
Para o desenvolvimento do produto de forma simultânea, o ambiente de trabalho deve
ser adequado, permitindo uma forte interação das pessoas envolvidas nos processos de
desenvolvimento, seja no compartilhamento de dados de projeto ou na tomada decisão em
grupo (SOUZA, 2001).
A engenharia simultânea tem sido implementada através de um conjunto de
ferramentas que integram principalmente os setores de projeto e manufatura. A figura 2.4
apresenta uma visão mais ampla, onde estão destacadas as fases de desenvolvimento do
produto vista pelos principais setores da empresa (marketing, projeto e produção),
demonstrando as necessidades de integração dos setores em cada fase.
17
Figura 2.3 – Etapas do desenvolvimento de um novo produto (DIETER, 1991).
O uso da engenharia simultânea no ambiente de desenvolvimento de produtos permite
melhor utilização dos recursos disponíveis e maior interação das pessoas envolvidas no
processo de desenvolvimento.
Especificar o Produto
Conceituar e Desenvolver Produto
Monitorar Performance do Produto
Analisar os Detalhes do Projeto
Construir de Protótipo
Gerar Programa CN para MáquinasFerramentas e Equipamentos Automatizados
Manufaturar Produto
Gerar Desenhos Detalhados
Analisar Críticamente as Características do Projeto
Criar Detalhes do Projeto
Testar Protótipo
Despachar Produto
Testar o produto final
Base de DadosDo Produto
CAD
CAM
ModificaçãoNo Projeto
Histórico de Testese Dados Atuais
18
Figura 2.4 – Três principais atividades a serem integradas no desenvolvimento de produtos
(ANDREASEN, 1987).
2.3 - Dados de definição do produto
Dados de produtos são entendidos como todas as informações relacionadas com os
produtos. Diversos departamentos tratam de diferentes dados de produto, incluindo recursos
financeiros, recursos humanos, e possivelmente também recursos industriais como, por
exemplo, a matéria-prima com a qual o produto é manufaturado, segundo PELTONEN
(2000).
Os dados de definição do produto são aqueles relacionados ao produto e aos processos
necessários para a sua definição, desde a concepção à sua obsolescência. Muitos dos dados
A
NECESSIDADE
A
NECESSIDADE
Determinaçãodo tipo deProdução
Determinação dos tipos de
Produtos
VendasPreparação
para aVenda
Investigação de
Mercado
Investigação dos
Usuários
Determinaçãodas
NecessidadesBásicas
Determinaçãodos
Princípios deProdução
Conceituaro
Produto
Consideraçõesdos tipos deProcessos
ProjetoPreliminar
doProduto
PreparaçãoPara
Produção
Modificaçõespara
Fabricação
Produção
Adaptaçãoem
ProdutosNegócio
Fase 0
Reconhecimentodas Necessidades
Fase 1
Investigaçãodas
Necessidades
Fase 2
Definiçãofuncional
doProduto
Marketing
Desenvolvimento de Produtos
Produção
Fase 3
ProjetarProduto
Fase 4
Preparaçãodo
Produto
Fase 5
Execução
19
administrados dentro de uma companhia industrial podem ser considerados como dados de
produto, como por exemplo: especificações, manuais, cálculos, programas de computador,
modelos de CAD de peças, modelos de CAD de ferramental, modelos de protótipo virtual,
atributos de peças, listas de peças, peças alternativas e substitutas, fotografias, desenhos,
esboços, vídeos, modelos e resultados de CAE, processos de fabricação, programas CN,
componentes de software existentes no produto, documentação de modificações de
engenharia, correspondências, resultados de ensaios, planos de projeto, etc (MILLER, 2001).
As informações referentes aos produtos são os recursos mais importantes em uma
empresa. Segundo MILLER (2001), os dados de representação do produto representam o
ativo intelectual da empresa (seu know-how). Por isto, muitas empresas reconhecem que os
seus dados referentes aos produtos devem ser armazenados e administrados de maneira
eficiente e segura, investindo em soluções que atendam essas necessidades. Além disso, é
necessário que estes dados estejam disponíveis sempre que necessários, pois de acordo com
OMOKAWA (1999), de 40% a 50% do tempo de desenvolvimento é gasto na comunicação e
na transmissão de informações e de 25% a 30% do tempo é gasto na procura de informações
(MARKUS, 1998).
Os processos de definição do produto compreendem os fluxos de trabalho nas áreas
que criam, e/ou usam os dados de produto, não sendo limitados ao departamento de
engenharia de produto ou à própria empresa (fornecedores e parceiros), como por exemplo:
modificações de engenharia, liberação de peças para produção, revisões de projeto, relatórios
de problemas em protótipos, relatório de ensaios, controle de dados em análise, aprovação de
clientes, liberação de manuais de manutenção, etc.
Os processos de definição do produto são complexos, dinâmicos e não lineares, isto é,
nem sempre começam no mesmo ponto, passam por etapas definidas e terminam em uma
20
tarefa específica, muitas vezes, somente após o término de uma atividade é que as próximas
atividades são definidas.
Segundo MILLER (2001), muitos são os motivos que justificam a grande dificuldade
em gerenciar os dados de definição de produto, como:
• Existem em grande volume e a cada dia são criados novos dados;
• São gerados por diferentes aplicações, muitas vezes em sistemas operacionais
diferentes;
• São armazenados em diferentes meios (papel, disco magnético, microfilmes, etc.);
• São armazenados em formatos variados (arquivos de texto, dados numéricos, dados
gráficos e de voz, vetorizados, em bancos de dados variados, etc.);
• São originados em diferentes áreas e locais;
• São usados por muitas áreas e locais;
• Estão dispersos e em “poder” de quem os origina;
• Precisam ser mantidas diferentes versões (não só a última);
• Sofrem muitas revisões (nem sempre controladas);
• São submetidos a diferentes sistemas de classificação e de identificação;
• Podem existir em diferentes estágios de definição (em processo, em revisão, liberado,
como projetado, como fabricado, etc);
• Existem duplicação e redundância de dados;
• Precisam ser mantidos em segurança por muitos anos;
• São usados durante todo o ciclo de vida do produto.
Estes problemas são particularmente críticos em setores de projeto em CAD, onde
muitos projetos complexos e documentos passam por várias fases de revisão, como parte de
21
seu ciclo de desenvolvimento. As revisões incorretas de projetos resultam na necessidade de
mudanças adicionais no produto projetado (BRAGA, 2000).
Com o passar do tempo, o número de informações aumenta em decorrência de novos
produtos, assim como novas especificações em produtos já existentes ao longo de seu ciclo de
vida, segundo SVENSSON (2000). Organizar e administrar estes projetos em bancos de dados
seguros é extremamente importante. Além disto, projetistas e engenheiros precisam assegurar
que a revisão de um item seja identificada corretamente e que possa ser reconhecida nas
diversas fases do projeto.
Diante de todos estes problemas, muitas são as conseqüências ao não se gerenciar os
dados e processos como:
• Dificuldade para encontrar dados que normalmente não estão atualizados (30% do
tempo de projeto);
• Dificuldade para se tomar decisões (decisões são tomadas com base em dados
incompletos e/ou errados);
• Dificuldade por parte dos projetistas (não analisam todas as alternativas do projeto e,
nem sempre, adotam a melhor solução);
• Dificuldade em manter histórico do desenvolvimento do produto;
• Dificuldade de criação de protótipo que represente o projeto (os protótipos nem
sempre representam o projeto, o que leva a perda de peças, ferramentais e tempo gasto
em ensaios);
• Dificuldade em cumprir cronogramas e orçamentos.
Assim, se faz necessário armazenar os documentos em bancos de dados, facilmente
acessíveis por todas as pessoas envolvidas no desenvolvimento do produto. Os sistemas
22
computacionais que gerenciam os dados de engenharia de produtos são chamados de PDM
(Product Data Management).
2.4 - Dificuldades Organizacionais
Apesar do surgimento dos aplicativos de CAD, que permitem que todos os desenhos
de projetos sejam elaborados, desde o início, na forma digital, a realidade não é bem assim.
No mundo ainda há muitos desenhos sendo feitos manualmente. Além disso, existe o legado
da era pré-CAD (projetos feitos antes da implantação dos aplicativos de CAD).
Praticamente todas as companhias têm milhares de documentos técnicos que
necessitam ser digitalizados e armazenados em sistemas digitais. D’ISSY (2001) apresenta o
resultado de pesquisas feitas por institutos especializados que estimam que 65% dos desenhos
técnicos produzidos no mundo ainda estão em papel, 22% em outras mídias e apenas 13% em
sistemas CAD. Acrescenta ainda que no mundo, existem de 2 a 3 bilhões de desenhos, sendo
87% são não eletrônicos. São gastas 43 milhões de horas/homem para localização de cópias
de documentos em arquivos analógicos, que hoje ocupam uma área de 14 milhões de m2,
sendo que 10% dos documentos são perdidos ou mal arquivados.
A complexidade do produto determina o número de áreas envolvidas e ambos
determinam o tipo de infra-estrutura necessária para o compartilhamento da informação.
Quanto mais componentes e áreas, mais variado e não integrados são 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 engenharia simultânea
(OMOKAWA, 1999).
As necessidades de gerenciamento de dados do produto dependem muito das
características da empresa na qual o ambiente DIP está inserido. Muitas destas necessidades
23
são aplicáveis também ao desenvolvimento seqüencial (departamental) de produtos, mas que
se tornam muito mais importantes em um ambiente de engenharia simultânea devido a sua
proposta de integração.
A infra-estrutura necessária de comunicação é qualquer sistema, equipamento ou
software que facilite ou habilite a transferência de informações relativa ao produto entre os
diversos setores da indústria e as diversas pessoas ou times envolvidos no projeto. A
engenharia simultânea requer que um ou mais times trabalhem e compartilhem informações
em um ambiente integrado de desenvolvimento de produtos. Por essa razão, uma
comunicação efetiva é vital para o sucesso do projeto do produto.
Uma opção tecnológica para os problemas de gestão de documentos, está no uso de
ferramentas computacionais específicas para este fim. Devido à necessidade de uma lógica de
funcionamento, por parte dos aplicativos de software e das pessoas envolvidas, normalmente
muitas dificuldades acompanham o processo de implementação dos aplicativos de
gerenciamento quando não se estabelece um procedimento para o fluxo de trabalho a ser
realizado. Assim, as ferramentas computacionais de gestão de documentos só devem entrar
em funcionamento quando o fluxo de trabalho estiver completamente definido. A partir desse
ponto, as etapas do projeto podem ser automatizadas, pois as etapas do desenvolvimento do
produto estarão explicitas, possibilitando a execução de atividades paralelas, independentes
entre si, quebrando assim a relação seqüencial das tarefas realizadas.
2.5 – Ferramentas computacionais
A abrangência da engenharia simultânea não se limita a fatores de natureza
organizacional, como os mencionados anteriormente, mas também a fatores de natureza
computacional, incluindo as ferramentas computacionais, protolocos de comunicação,
24
interfaces para integração, entre outros. Atualmente, as ferramentas computacionais são
utilizadas em todas as áreas do desenvolvimento do produto em uma empresa, tais como
marketing, engenharia, planejamento e controle da manufatura, entre outras.
Uma das áreas que mais se utiliza estas ferramentas é a engenharia (concepção do
produto), onde são empregados aplicativos computacionais de projeto e manufatura auxiliados
por computador (CAD/CAM), planejamento do processo auxiliado por computador (CAPP),
engenharia auxiliada por computador (CAE) – ferramentas de modelagem, de simulação e
planejamento da produção e custeio.
Assim, na mesma proporção em que aumenta o volume de informação nas
organizações, aumenta seu risco de fragmentação e perda, ocasionando prejuízos em tempo e
dinheiro. Esta deficiência, inerente às organizações, pode ser minimizada, através do uso de
uma aplicação computacional colaborativa, que preserve as informações eletronicamente e de
forma centralizada, onde as pessoas interessadas tenham acesso à informação no tempo e na
forma corretos. Também é possível modelar os processos estudados, uma vez que estes sejam
conhecidos, proporcionando o armazenamento do conhecimento adquirido, tornando-se
essencial para tanto, a utilização de um sistema de gerenciamento de dados. Para isso, foram
criados os sistemas de gestão de dados de engenharia e dados do produto EDM (Engineering
Data Management) e PDM (Product Data Management), e de gerenciamento de dados
corporativos ERP (Enterprise Resource Planning).
Muitas empresas estão adotando o uso conjunto de ferramentas de gerenciamento de
dados do produto - PDM - e de gestão corporativa – ERP -. A combinação desses sistemas
numa empresa implica na necessidade de integração, pois em muitas situações eles utilizam
dados comuns (ZANCUL, 1999 b).
As ferramentas computacionais devem funcionar de maneira integrada e efetiva num
ambiente DIP. No entanto, apesar das promessas de vantagens competitivas proporcionadas
25
pela engenharia simultânea serem grandes e estimulantes, obtê-las na prática não é uma tarefa
trivial (SHENEIDER, 2001 e BEDWORTH, 1991).
O estudo das técnicas de integração de ferramentas computacionais inclui a descrição
dos sistemas computacionais e das possíveis funcionalidades a serem integradas. Os subsídios
necessários para isso normalmente são obtidos através das respostas aos seguintes
questionamentos:
• Como o processo de desenvolvimento realmente ocorre na empresa?
• Quais ferramentas são utilizadas, quais operam de maneira integrada e como
funcionam?
• Quais são os sistemas que operam isolados em departamentos funcionais e como eles
podem operar compartilhando informações com outros sistemas?
• Quais são as etapas do desenvolvimento de produtos que envolvem atividades
repetitivas e que podem ser automatizadas?
O ciclo de vida de um produto abrange todos os processos relativos a um produto
desde sua idealização até sua obsolescência, passando pelas etapas de projeto, produção e
distribuição. Analisando o encadeamento de informações no ciclo de vida do produto é
possível visualizar duas etapas distintas, o desenvolvimento do produto e a produção
(manufatura).
As informações criadas no desenvolvimento do produto devem estar corretas e
atualizadas para atender as necessidades da produção. Segundo BOURKE (2001 b), a
principal causa dos fracassos nas primeiras aplicações de sistemas MRP (Material
Requirements Planning) foi à ineficiência do gerenciamento das informações no ciclo de vida
do produto, ou seja, as informações chegavam aos sistemas MRP incorretas ou desatualizadas.
26
Dessa forma, o sistema PDM desempenha uma função de integrador dentro da
empresa. O sistema PDM deve ser capaz de se integrar a outros sistemas tanto para receber
como para fornecer informações.
A integração entre sistemas PDM e ERP nas fases de desenvolvimento da lista de
materiais - BOM (ver seção 4.1) reduz as oportunidades de erros comumente encontrados em
sistemas não integrados. Erros, como a inconsistência ou perda de dados de produto em fases
avançadas do projeto, podem ser eliminados. Com a capacidade do sistema PDM em
administrar e criar mudanças de engenharia, a BOM pode refletir um elo de ligação com a
precisão necessária para o planejamento dos componentes (BOURKE, 2001 a).
O ciclo de mudanças de engenharia pode ser reduzido substancialmente pela
disponibilidade de informações no momento que esta se faz necessária para muitos usuários,
contrastando com os volumosos pacotes de documentação que circulam dentro de uma
empresa. O completo gerenciamento das informações do produto ao longo de seu ciclo de
vida só é possível através da adequada integração entre os sistemas PDM e ERP (BOURKE,
2001 a).
Em futuros empreendimentos de engenharia simultânea, a integração entre ferramentas
de PDM e ERP será a fundamental para a administração do ciclo de vida total do produto,
com uma vantagem competitiva para as companhias que dominam o processo estratégico de
integrar informações entre PDM e ERP (BOURKE, 2001 a).
27
CAPÍTULO III – DESCRIÇÃO DAS FERRAMENTAS COMPUTACIONAIS
Para o estudo da integração e implementação de aplicativos de software e
equipamentos utilizados na engenharia para o desenvolvimento de novos produtos, deve-se
primeiramente conhecer estes sistemas e os meios que permitem sua interface ou integração.
Devido à importância das ferramentas computacionais apresentadas no capítulo 2,
neste capítulo é apresentada a descrição dos sistemas computacionais envolvidos na
integração de documentos de engenharia.
Segundo AGUIAR (1995), os critérios para classificação de sistemas computacionais
dedicados à engenharia podem ser classificados em critérios funcionais, critérios técnicos e
critérios comerciais. Neste trabalho serão tratados apenas os critérios funcionais e técnicos,
por opção de escopo.
Os critérios funcionais são aqueles relacionados às necessidades de informação ou
processos da empresa. Já os critérios técnicos são aqueles que definem características
computacionais do sistema (AGUIAR, 1995).
3.1 – Banco de dados e modelagem de dados
Esta seção discute os aspectos mais importantes da gerência de banco de dados para a
implementação de bancos de dados de produtos. Conhecer a forma como as informações
digitais são armazenadas é fundamental para o entendimento dos possíveis modelos de gestão
dos documentos do produto durante seu ciclo de vida.
Modelos de dados são usados para estabelecer o fundamento arquitetônico de bancos
de dados. Cada modelo de dados tem como objetivo “modelar o mundo” de uma maneira tão
28
acurada quanto possível. Segundo KERN (1997), os modelos de dados podem ser
classificados em:
• Hierárquicos: neste modelo, o banco de dados tem uma estrutura de árvore na qual
cada registro tem apenas um ascendente, com a exceção do registro-raiz, que não tem
ascendente. O modelo hierárquico permitiu a fundamentação para os primeiros
sistemas de gerência de banco de dados;
• Rede: é uma generalização do modelo hierárquico. O modelo de rede permite que
cada registro tenha vários ascendentes e descendentes, como em um grafo;
• Relacional: o modelo relacional suporta a abstração de sistemas de banco de dados
que podem ser visualizados como coleções de tabelas e relacionamentos entre
tabelas;
• Orientado a objeto: este paradigma tem os tipos abstratos de dados, a herança, e a
identidade como seus aspectos fundamentais. Definem uma base de dados em termo
de objetos, suas propriedades e operações. Suporta o modelo de dados
disponibilizado inicialmente através de linguagens de programação orientadas a
objeto.
Há também os modelos de dados semânticos, que são apresentados por conceitos com
um nível de abstração mais alto. Sua aplicação não está restrita a um dos quatro modelos
acima. O modelo semântico mais conhecido é o modelo Entidade-Relacionamento (ER).
Ao se observar à natureza dos dados de um ambiente de negócios, nota-se que dados
enquadram-se bem em tabelas ou arquivos contínuos, e são especialmente adequados para a
gerência por sistemas relacionais (KERN, 1997). Estes dados são cadeias de caracteres e
números organizados em registros de tamanhos fixos, com apenas uma versão (a atual) dos
dados em um certo momento.
29
Dados em um ambiente de engenharia, como aqueles manipulados por sistemas CAD,
dificilmente enquadram-se em tabelas ou arquivos contínuos. Dados de aplicações de
engenharia são, além de números e cadeias de caracteres, também gráficos, vetores e matrizes,
etc. Objetos de engenharia variam em tipo e tamanho e relacionam-se conforme malhas
complexas (KERN, 1997).
Sistemas de gerência de banco de dados DBMS (Data Base Management System),
gerenciam dados independentemente de qualquer aplicação. Eles oferecem ferramentas para
executar tarefas de gerência de dados, como: controle de acesso concorrente, evolução do
esquema de banco de dados, e controle da unicidade da informação.
Os DBMSs que suportam o modelo relacional têm sido muito bem sucedidos no
gerenciamento de dados de negócios. No entanto, eles apresentam uma série de insuficiências
quando usados para gerenciar aplicações complexas, como desenhos gerados em sistemas
CAD.
Os Bancos de Dados Orientados a Objeto (OODB) emergiram como uma extensão do
modelo de dados oferecido pelas linguagens de programação objeto - orientadas (FERMAN,
2001). Segundo KERN (1997) o processo de definir uma versão inicial de um projeto de
engenharia e alterar este projeto é muito semelhante ao processo de definir objetos e refiná-los
sucessivamente, especificando restrições e construindo hierarquias de objetos. Neste sentido,
a orientação a objetos é um modelo genérico que facilita o mapeamento do modelo mental de
objetos do projetista para o sistema de ferramentas de projeto de engenharia, e da interface do
usuário para as ferramentas do sistema subjacente.
O uso de banco de dados baseados em objetos acelera o acesso dos programas
necessários para acessar as informações (WHEELER, 1994). Originalmente introduzidos pela
engenharia como uma forma conveniente de recuperar informações de projeto, o seu uso tem
30
também se espalhado a aplicações financeiras e comerciais. Os objetos identificam, tanto os
dados, como os atributos utilizados para processar os dados.
Os objetos contêm informações sobre o uso dos dados e seu processamento. Os
objetos de peças acabadas normalmente contêm informações sobre o processamento do
produto acabado ou os materiais a serem utilizados. Um elemento importante na compreensão
dos objetos é o conceito de classe. As classes definem os gabaritos para os objetos comuns,
que também são conhecidos como tipos de objetos. Dentro de um tipo de objeto, os objetos
individuais são instâncias da classe, com armazenamento nela alocado. Cada parte de um
produto acabado pode ser um objeto, e o produto global pode, também, ser considerado um
objeto (WHEELER, 1994).
Atualmente duas arquiteturas principais apóiam objetos distribuídos:
• O padrão industrial de definição, controle e comunicação de objetos orientados -
CORBA (Common Object Request Broker Arquitecture) desenvolvido por um grupo
de empresas - OMG (Object Management Group) - que padronizaram esta
arquitetura;
• A arquitetura DCOM desenvolvida pela Microsoft. A arquitetura DCOM é limitada
por não ser utilizada em plataformas que utilizam sistemas operacionais UNIX
(utilizado pela maioria dos servidores de PDM e MRP).
Uma bicicleta pode ser tomada como exemplo que tem diferentes perspectivas ou
atributos para pessoas diferentes. Para o projetista, é um dispositivo mecânico com rodas; para
a criança, os atributos são os de um brinquedo, enquanto que os pais a vêem como um risco
potencial de acidente; um atleta verá o objeto-bicicleta da perspectiva de um equipamento
bem projetado. Os dados não mudam; mudam apenas os atributos utilizados pelos
observadores para processar os dados.
31
Existem muitas razões pelas quais utilizam-se bancos de dados:
• Recuperação de dados: o banco de dados é protegido contra problemas de hardware,
falhas de mídias, e alguns erros de usuários;
• Compartilhamento entre usuários: múltiplos usuários podem acessar o banco de dados
ao mesmo tempo;
• Compartilhamento entre aplicações: múltiplos programas aplicativos podem ler ou
escrever dados no mesmo banco de dados. Um banco de dados é um meio neutro que
facilita a comunicação entre programas aplicativos;
• Segurança: os dados podem ser protegidos contra acessos de leitura ou escrita não
autorizados;
• Integridade: pode-se especificar regras que os dados devem satisfazer;
• Extensibilidade: os dados podem ser adicionados para banco de dados sem
desorganizar programas aplicativos existentes. Os dados podem ser reorganizados para
um desempenho mais adequado;
• Distribuição de dados: o banco de dados pode ser particionado entre vários lugares,
arquiteturas computacionais ou plataformas de hardware.
3.2 - Aplicativos CAD – Projeto Auxiliado por Computador
Desde o início dos tempos, o homem tem usado basicamente duas maneiras de
representar suas idéias acerca de um objeto, de forma que sejam compreendidas por outras
pessoas: através de esculturas (fabricando modelos físicos em três dimensões) ou através de
desenhos (representando em perspectiva ou vistas ortogonais), utilizando-se de processos de
codificação e decodificação de desenhos (FERNEDA, 1999).
32
Até cerca de 30 anos atrás, quase todos os desenhos produzidos no mundo eram feitos
através de processo manual, que apresentava os seguintes problemas:
• Baixa produtividade devido à produção de desenhos estar diretamente ligada à
habilidade do desenhista;
• Erros de representação geométrica e erros de cotas que seriam detectados durante a
montagem dos equipamentos;
• Alterações no desenho muitas vezes implicam em refaze-lo totalmente;
Os aplicativos CAD ou projeto auxiliado por computador envolve qualquer tipo de
atividade de projeto, que faz uso interativo do computador para desenvolver modelos
geométricos de um projeto de engenharia. Os sistemas CAD mais simples se baseiam em
modelagem em duas dimensões - 2D que produzem plantas e elevações do projeto de uma
forma semelhantes aos desenhos convencionais feitos em prancheta. Os sistemas mais
sofisticados são baseados em modelagem em três dimensões - 3D que são capazes de
representar exatamente um objeto de forma tridimensional, sendo também empregados para
gerar lista de materiais e outros conjuntos de instruções para as atividades subseqüentes de
produção.
Segundo SLACK (1999), os sistemas CAD se destacam com relação aos processos
manuais devido a sua capacidade de armazenar e recuperar dados de projeto rapidamente. As
alterações podem ser feitas muito mais rapidamente com o uso de bibliotecas padronizadas de
formas e elementos construtivos diminuíram a possibilidade de erros no projeto.
Com a introdução de sistemas CAD, é automatizada as atividades de rotina pelo
computador, otimizando assim o trabalho do projetista e possibilitando que ele utilize maior
parte de seu tempo em trabalho criativo, testando rapidamente, por exemplo, várias opções
construtivas.
33
As principais razões que justificam a implantação de um sistema CAD segundo
FERNEDA (1999) são:
• Aumentar a produtividade do projetista;
• Melhorar a qualidade do projeto;
• Melhorar as comunicações durante o desenvolvimento e execução de um projeto;
• Criar uma base de dados para manufatura.
Segundo GAMA (1999), os sistemas CAD são classificados em três categorias: high,
middle e low-end. Programas de CAD “high-end” (por exemplo, CATIA,
UNIGRAPHICS) são programas com grande capacidade de solução, normalmente usados
em industrias automobilística, aeroespacial, naval, petrolífera, entre outras empresas que
necessitam sistemas sofisticados. Programas de CAD “middle-end”, muito usados por
industrias do setor mecânico, apresentam grande capacidade de solução, porém para
problemas específicos, como montagens, modelagem de sólidos e superfícies. Os programas
denominados “low-end” (por exemplo, AutoCAD) que são os programas mais populares,
principalmente devido ao baixo custo se comparados aos anteriores, apresentam um conjunto
de ferramentas eficientes para desenho e boa flexibilidade para projetos simples (GAMA,
1999).
Atualmente os sistemas CAD high-end que incorporaram modelos geométricos
volumétricos, ou seja, 3D (tridimensionais), permitem a utilização do modelo virtual do
produto DMU (Digital mockup), como apresentado na figura 3.1. A aplicação do DMU no
ambiente de trabalho simultâneo habilita o uso da realidade virtual, ou seja, a aplicação de um
modelo virtual do produto. Este garante aos projetistas envolvidos no desenvolvimento de
produto a realização de simulações de forma realística no computador, de acordo com
SCHÜTZER (1999). Nas simulações realizadas com o produto no computador, é possível
34
visualizar e verificar, por exemplo, as falhas de montagem do produto, colisões entre
componentes, espaços disponíveis para passagem de cabos e acessórios, etc. Estes problemas
podem ser claramente identificados e corrigidos pelos projetistas, ainda no estágio inicial do
desenvolvimento do produto.
Para a visualização do produto e a utilização da realidade virtual, é necessário que as
empresas trabalhem com modelos que permitam a visualização volumétrica do produto. Para
isso, são necessários a utilização de sistemas CAD com modelos geométricos 3D, que
permitem esta visualização (SOUZA, 2001).
Figura 3.1 - Modelo virtual do produto DMU (Digital mockup).
35
3.3 - Engenharia Auxiliada por Computador - CAE
A partir dos modelos criados pelos sistemas CAD, o computador pode ser usado em
trabalho de análise, que pode envolver cálculos de tensão-deformação, transferência de calor
ou o uso de equações diferenciais para descrever o comportamento dinâmico de sistemas que
estão sendo projetados. (FERNEDA, 1999). Estes aplicativos computacionais são
denominados CAE e permitem ao projetista aplicar aos modelos geométricos, modelos
matemáticos que garantam a integridade e adequação do componente ou conjunto analisado à
finalidade que se destina.
Normalmente, a primeira fase do processo de desenvolvimento de um produto é feita
com o auxílio de um sistema CAE, onde se define o produto. O sistema auxilia a
determinação das especificações tecnológicas do produto como, dimensões, resistência dos
materiais e análise de tensões, através da construção e teste de protótipos virtuais. A utilização
do CAE pode reduzir custos e diminuir o tempo de lançamento de novos produtos (SOUZA,
2001).
A figura 3.2 apresenta uma aplicação de um sistema CAE, onde uma análise de
elementos finitos é realizada em um modelo geométrico e os níveis de solicitação com relação
aos esforços são aplicados na peça.
36
Figura 3.2 – Análise por elementos finitos - CAE
3.4 - Manufatura auxiliada por computador - CAM
Os sistemas computacionais de auxilio a manufatura CAM surgiram em meados dos
anos 50 com o desenvolvimento de máquinas-ferramenta numericamente controladas. No
inicio, estas máquinas eram programadas através de cartões de papel perfurados.
O desenvolvimento de sistemas CAD evidenciou a necessidade de comunicação entre
diferentes programas independentes, que possibilitasse o compartilhamento e transmissão de
dados eficientemente. Simultaneamente, o uso de programas gráficos e interativos cresceu
rapidamente.
Os sistemas CAM utilizam o modelo geométrico criado em um sistema CAD para
elaborar por exemplo, a rotina de usinagem. E esta rotina é simulada em ambiente gráfico
para verificar e eliminar/minimizar situações de trabalho indesejáveis (ver figura 3.3). Feita a
37
elaboração da trajetória de usinagem a ser utilizada para a fabricação do componente, o
aplicativo CAM converte o programa gerado pela simulação para um programa de controle
numérico – CN - específico do comando numérico computadorizado CNC (Computer
Numerical Control) utilizado pela máquina que executará a rotina de fabricação propriamente
dita.
Uma das vantagens da programação CNC é que um programador pode gerar e
fornecer ao comando da máquina-ferramenta, as instruções necessárias em linguagem da
máquina sem a necessidade de fazer cálculos, como por exemplo, a interpolação de pontos da
trajetória da ferramenta, o que resulta em um programa produzido numa fração do tempo que
seria requerido normalmente e, adicionalmente, livre de erro humano (FERNEDA, 1999).
Figura 3.3 – Elaboração de estratégia de usinagem - CAM
38
3.5 - Planejamento do Processo Auxiliado por Computador - CAPP
Para que uma operação de manufatura seja eficiente, todas as atividades envolvidas
devem ser planejadas. Esta atividade tradicionalmente é feita pelo planejador de processos.
Planejamento de processos está relacionado a seleção de métodos de produção: ferramentas,
dispositivos de fixação, máquinas, seqüência de operações e montagem.
A seqüência de processos e operações a serem realizadas, as máquinas a serem
utilizadas, o tempo padrão para cada operação, e outras informações são documentadas em
uma folha de processo. Quando elaborada manualmente, esta tarefa é trabalhosa e demorada,
dependente da experiência do planejador de processos. A tendência atual é de manter a folha
de processos no computador e a peça ser identificada por um código, quando necessário a
mesma pode ser consultada no computador.
O planejamento de processos auxiliado por computador – CAPP, executa a tarefa de
planejamento de processos considerando toda a operação como um sistema integrado, então
cada operação individual e passos envolvidos na fabricação de cada peça são coordenados e
executados eficientemente de modo confiável.
No estudo realizado por SOUZA (2001), pode-se notar que o uso de sistemas CAPP
ainda é bastante incipiente nas industrias de autopeças (first tier), como apresentado na figura
3.4.
39
Figura 3.4 – Utilização dos sistemas CAx nas empresas de autopeças (SOUZA, 2001).
3.6 - Intercâmbio de dados de produtos entre aplicativos CAD
O processo de desenvolvimento de produto requer uma combinação eficaz entre uma
imensa quantidade de informações sobre o produto, que depende, por sua vez, do uso das
tecnologias de informação e comunicação.
Por causa da variedade de sistemas CAD de diferentes características e fornecedores, a
comunicação e intercâmbio de dados entre estes sistemas tornaram-se um problema.
A natureza complexa dos dados de engenharia pode dificultar a integração das
aplicações. KERN (1997) aponta duas dificuldades principais que têm impedido a integração
efetiva de sistemas CAD:
96
44 4826
20
40
60
80
100
Uso nasEmpresas de
Autopeçasem porcentagem
CAD CAE CAM CAPP
40
1 - Os sistemas CAD atuais foram projetados para entrada e saída de dados, em vez de
informação;
2 - As ferramentas CAD atuais operam em níveis de abstração diferentes de um produto.
Portanto, a qualidade da modelagem da informação (dados com significado ou
semântica-restrições, regras, procedimentos) sobre produtos é um dos fatores mais
importantes para a integração de sistemas CAD. Além disso, os dados precisam ser trocados
entre aplicações que estão baseadas em modelos de dados distintos, o que cria a necessidade
de tradução dos dados (KERN, 1997).
Uma vez que as aplicações usam modelos de dados diferentes e podem funcionar em
ambientes diferentes, há uma lacuna que impede a comunicação de informações sobre
projetos.
Há soluções informais triviais para o problema de intercâmbio de dados de produtos,
incluindo: enviar desenhos em papel, reentrar dados em um formato específico, ou eliminar o
problema através da determinação de que todas as partes envolvidas devem usar um mesmo
sistema CAD. Na maior parte dos casos, entretanto, estas soluções não são aceitáveis, sendo
necessário traduzir os dados de um sistema para outro.
Diante das dificuldades na troca de informações entre os diversos aplicativos CAD,
fez-se necessário um padrão, um formato de arquivo capaz de ser compreendido por todos os
aplicativos, que permita o intercâmbio de dados digitais. Para isto, faz-se uso de arquivos de
formatos neutros, através dos quais, diferentes sistemas se comunicam uns com os outros
(OMOKAWA, 1999, FERNEDA, 1999 e AGUIAR, 1995).
Padrões visam estabelecer formatos e regras de armazenamento que permitam o
intercambio de dados. Na mesma linha, os metadados (dados sobre dados) armazenados em
bancos de dados fornecem a notação descritiva para dados armazenados e visam facilitar a
41
construção de consultas e permitir estabelecer correlações de dados em um nível mais
abstrato. Metadados descrevem o conteúdo, a qualidade, a condição e outras características
relevantes do dado. A legenda de um mapa, por exemplo, é puramente metadado.
Para permitir a portabilidade dos dados, os desenvolvedores de sistemas CAD devem
providenciar tradutores para pré-processar os dados para o formato neutro e pós-
processadores para ler os dados do formato neutro.
As primeiras especificações para intercâmbio de dados tratavam, genericamente, de
dados geométricos. Entre estas, a mais conhecida é o DXF (Data Interchange Format),
formato proprietário da Autodesk, e os padrões IGES (Initial Graphics Exchange
Specification) desenvolvido nos Estados Unidos, SET (Standart D’enchange et Transfer)
desenvolvido na França, e VDA/FS (Verband der Deutschen Automobilindustrie-
Flächschittstelle) desenvolvido na Alemanha.
Os padrões mencionados, não representam modelos de produtos para todo o ciclo de
vida. Para isto, a Organização Internacional de Padronização (ISO) desenvolveu o Padrão
para o Intercâmbio de Modelos de Dados de Produtos (ISO 10303-1 1992), conhecido como
STEP (Standard for the Exchange of Product Data). O padrão STEP visa representar todas as
informações sobre um produto em todo o seu ciclo de vida, desde a concepção à reciclagem.
Assim, este padrão abrange também: estilo, concepção, projeto, avaliação, ferramentas de
fabricação e controle de qualidade, reciclagem, etc. Desta maneira, diferentes aplicativos
podem trocar informações através de um formato padrão definido por STEP (KERN, 1997).
A tabela 3.1 apresenta uma comparação descritiva de vários padrões para o
intercâmbio de dados de produtos, onde ACIS é o núcleo do modelo geométrico adotado por
vários sistemas CAD comerciais, entre eles: AutoCAD, CADKEY, MicroStation, Solid
Designer, SolidEdge (KERN, 1997).
42
IGES SET VDA-FS STEP ACIS
Escopo
• Modelos estruturais
• Modelos de superfície • Modelos
sólidos • Modelos para
análise de elementos
finitos • Desenhos
técnicos
• Modelos estruturais
• Modelos desuperfície • Modelos
sólidos • Desenhos
técnicos
• Modelos de
superfície
• Modelos de produtos para todo o ciclo de vida do produto
• Modelos estruturais
• Modelos de superfície • Modelos
sólidos
Características da
especificação
• Coleção de entidades
• Formato de arquivo
• Coleção deentidades
• Formato dearquivo
• Coleção deentidades
• Formato dearquivo
• Especificação formal de um
modelo de produto
• Definição formal de
sintaxe de arquivo
• Núcleo de um
modelador geométrico
Tabela 3.1 - Comparação de padrões para intercâmbio de dados de produtos (KERN, 1997).
Somente os sistemas CAD cujos bancos de dados forem originados em STEP
oferecerão reais benefícios, pois serão capazes de armazenar completamente os projetos com
informações geométricas e tecnológicas de todos os produtos, podendo assim os seus usuários
transferir dados a todos os seus clientes sem causar re-trabalho. A figura 3.5 apresenta os
padrões utilizados atualmente nas indústrias de autopeças (first tier) no Brasil.
43
Figura 3.5 - Padrões de troca de dados disponíveis em uso nas empresas do setor de autopeças
(SOUZA, 2001).
A partir do final da década de noventa, com a consolidação do uso da internet e
aplicações globalizadas, uma nova forma de transmitir informações tem se destacado,
chamada XML (eXtended Markup Language). A linguagem XML é um formato normalizado
definido e recomendado pelo World Wide Web Consortium (W3C - entidade responsável pela
definição das regras técnicas da Internet) para a troca de qualquer tipo de informação. XML é
uma linguagem para descrever informações estruturadas1, independentes de qualquer
aplicação, sistema operativo ou base de dados, totalmente aberta sem depender de qualquer
tecnologia, portanto extremamente genérica e flexível (CORVALÃO, 2002).
1 Por dados estruturados entende-se: planilha eletrônica, parâmetros de configuração, transações financeiras, desenhos técnicos, entre outros, que podem ser transmitidos na internet nesta estrutura.
95
195
3220
40
60
80
100
Uso nasEmpresas de
Autopeçasem porcentagem
IGES VDA-FS/IS STEP CAD/CAD
59
DXF
44
XML caracteriza-se como um método para inserir dados estruturados em um arquivo
texto, provendo um método universal para descrever os dados, através da integração de dados
de diversas fontes, de várias aplicações e múltiplas visões dos dados (CORVALÃO, 2002).
XML tem despertado grande interesse dos desenvolvedores em geral, por ser um
“ótimo caminho” para descrever a essência da estrutura de dados, e ser usado como um
modelo para transmitir dados de um local para outro.
Com a proliferação de aplicações baseadas em documentos para a internet e
conhecendo a forma como os dados são estruturados no padrão XML, abre-se uma grande
oportunidade de integração dos mais diferentes sistemas computacionais com a tarefa de
evitar replicação, facilitar o desenvolvimento e padronizar as diversas estruturas de dados.
3.7 - Sistemas ERP – Planejamento dos Recursos de Empresas
Os atuais sistemas ERP originaram-se dos sistemas de gerenciamento das necessidades
de materiais MRP (Material Requirements Planning). A partir da necessidade de produtos
finais, os sistemas MRP calculam quanto e quando produzir e comprar as diversas matérias
primas e componentes (ver figura 3.6). No entanto, além de garantir a disponibilidade dos
materiais, é necessário garantir que há capacidade suficiente para produzir as quantidades
planejadas. A inclusão do cálculo de necessidades de capacidade nos sistemas MRP fez com
que um novo tipo de sistema fosse criado; um sistema que já não calculava apenas as
necessidades de materiais, mas também as necessidades de outros recursos do processo de
manufatura. Este sistema foi nomeado Manufacturing Requirements Planning - MRP II.
45
Figura 3.6 – Fluxograma MRP.
O MRP II diferencia-se do MRP pelo tipo de decisão de planejamento que orienta:
enquanto o MRP orienta as decisões de o que, quanto e quando produzir e comprar, o MRP II
engloba também as decisões referentes a como produzir, ou seja, com que recursos, como
apresentado na figura 3.7 (GIANESI, 2000).
Ordem PlanejadaOrdem Planejada
Retirada de MateriaisRetirada de Materiais
Previsão do MaterialPrevisão do Material Vendas / DistribuiçãoVendas / Distribuição
Gerenciamento de Demanda
Gerenciamento de Demanda
MRPMRP
Processamento da OrdemProcessamento da Ordem
Movimento de Entrada de Estoque
Movimento de Entrada de Estoque
Liquidação da OrdemLiquidação da Ordem
Recebimento de MateriaisRecebimento de Materiais
Recebimento de FaturaRecebimento de FaturaPlan
ejam
ento
de
Cap
acid
ade
Plan
ejam
ento
de
Cap
acid
ade
Cus
teio
Cus
teio
Ordem de ProduçãoOrdem de Produção Requisição de ComprasRequisição de Compras
Ordem de ComprasOrdem de Compras
Estoque
EA C D
B
Estoque
EA C D
B
EA C D
B
Planejamento PreliminarPlanejamento Preliminar Necessidade de VendasNecessidade de Vendas
46
Figura 3.7 – Abrangência do MRP e do MRP II (GIANESI, 2000).
Com o objetivo de ampliar ainda mais a abrangência destes sistemas de gestão, foram
desenvolvidos sistemas mais sofisticados como apresentado na figura 3.8, capazes de suportar
as necessidades de informação de diversos processos do negócio, os quais recebem o nome de
ERP.
O ERP (Enterprise Resource Planning) é um termo genérico para o conjunto de
atividades executadas por um software multi-modular com o objetivo de auxiliar o fabricante
ou o gestor de uma empresa nas importantes fases de seu negócio, incluindo desenvolvimento
de produto, compra de itens, manutenção de inventários, interação com fornecedores, serviços
a clientes, contabilidade, finanças, recursos humanos e acompanhamento de ordens de
produção.
Sistema de
apoio às
decisões de
COMO(RECURSOS PRODUTIVOS)
O QUE
QUANTO
QUANDO
MRP
MRPII
47
Atualmente, as empresas fornecedoras de sistemas ERP apresentam novas versões de
seus sistemas intitulados ERP II, por apresentarem funções que permitem a integração de
sistemas ERP de diversas corporações, o que representa consideráveis vantagens, para uma
maior integração de toda uma cadeia de suprimentos.
Figura 3.8 – Evolução dos sistemas de gestão corporativos.
Os sistemas ERP são compostos por uma base de dados única e por módulos que
suportam diversas atividades dos processos de negócio das empresas. Este banco de dados
interage com todos os aplicativos do sistema. Elimina-se, desta forma, a redundância e re-
digitação de dados, o que assegura a integridade das informações obtidas.
Cada sistema de ERP oferece um conjunto de módulos (aplicativos) para aquisição.
Estes são os pacotes funcionais, individualizados para cada unidade de negócio dentro da
MRPManufatura
Finanças
Estratégia
Serviços
Departamento Empresa Corporação Cadeia deSuplimentos
MRP II
ERP
ERP II
48
organização (financeiro, engenharia, planejamento, administração de materiais, contabilidade,
etc,), o que confere ao ERP a característica de um sistema de grande porte.
O ERP permite que a empresa padronize seu sistema de informação. Dependendo das
aplicações, o ERP pode gerenciar um conjunto de atividades que permitam o
acompanhamento dos níveis de fabricação em balanceamento com a carteira de pedidos ou
previsão de vendas. O resultado é uma organização com um fluxo de dados consistente que
flui entre as diferentes interfaces do negócio. Assim, como o ERP não conhece a fronteira
entre os departamentos, por apresentar uma estrutura integrada numa base de dados única (ver
figura 3.9), é possível modelar os processos do negócio, tendo como conseqüência uma maior
consistência aos processos da empresa, uma vez que são executados sempre da forma como
foram modelados inicialmente. Na essência, o ERP propicia a informação correta, para a
pessoa correta e no momento correto.
Embora os sistemas ERP da atualidade já sejam bastante abrangentes e seus
fornecedores continuem aumentando sua abrangência com a inclusão de novas
funcionalidades, os sistemas de ERP não possuem todas as funcionalidades necessárias para
apoiar as atividades do processo de desenvolvimento de produtos, como por exemplo, a
capacidade de gerenciamento total dos documentos de engenharia (CAD), ou seja, o
desenvolvimento de produtos requer sistemas mais específicos, complementares aos sistemas
ERP. A integração entre os sistemas complementares de engenharia com os sistemas ERP é
bastante complexa, tanto no que se refere ao projeto conceitual da integração quanto à sua
implantação (ZANCUL, 1999 a).
49
Figura 3.9 - Estrutura típica de funcionamento de um sistema ERP.
3.8 - Sistemas PDM – Gestão de dados de produtos
Durante a última década, as empresas (de grande e médio porte principalmente)
fizeram investimentos significativos em tecnologias de informação, de maneira a automatizar
vários processos do ciclo de vida de seu produto. Esta demanda, nutriu o crescimento rápido
das ferramentas de projeto e fabricação auxiliadas por computador. Porém esta tendência
resultou em um fenômeno conhecido como ilhas de automação, onde os sistemas operam de
maneira isolada entre si (MÁRKUS, 1998).
A geração de uma quantidade enorme de dados do projeto de produtos num período
pequeno de tempo faz com que o controle manual destes dados se torne extremamente difícil,
se não impossível, de acordo com MÁRKUS (1998), proliferando conseqüentemente, os
tradutores entre sistemas incompatíveis.
Base dedados
Controladoriae Finanças
Planejamento da Produção
Administraçãode Materiais
SuporteTécnico
Distribuiçãoe Vendas
Relatório à Diretores e Acionistas
Gestão de Recursos Humanos
FOR NECEDORES
CLIETES
50
No começo dos anos oitenta, foi desenvolvida uma nova classe de aplicativo chamada
de administração dos dados de criação EDM (Engineering Data Management), tendo como
propósito comum, prover a administração da configuração de produtos, de maneira a integrar
as ilhas de automação. O EDM basicamente permite definir os elementos do produto,
controlar mudanças e localizar as mudanças feitas, como um suplemento para as ferramentas
de CAD/CAE/CAM. O EDM é bastante limitado por só suportar dados gerados por
ferramentas de CAD/CAE/CAM específicas.
Diante desta limitação, no final dos anos oitenta, surgiram sistemas EDM mais
avançados, os quais recebem o nome de PDM (OMOKAWA, 1999).
D’ISSY (2001) faz uso de uma linguagem metafórica ao afirmar que o computador é
um grande armário em que as pessoas inserem seus documentos, e no momento de encontra-
los, caso não haja uma organização metódica, será tão difícil ou mais do que procurar os
documentos em papéis.
O termo PDM normalmente tem um âmbito mais restrito. Tipicamente os sistemas
PDM têm as raízes nos aspectos de engenharia de desenvolvimento de produto, sendo
considerado ideal para a gestão de dados de engenharia que incluem desenhos e listas de
materiais, segundo PELTONEN (2000). Na sua maioria, os sistemas PDM, não estão
preocupados com os processos operacionais, logísticos ou de vendas das empresas, não
tratando de custos, preços ou qualquer outro assunto financeiro da empresa.
Os sistemas PDM também suportam as atividades de configuração de produtos, visto a
grande necessidade que algumas empresas apresentam de produzirem produtos específicos
para determinados clientes, havendo a necessidade de acrescentar ou substituir itens da
plataforma base do produto segundo MESIHOVIC (2000), (ver seção 4.6 engenharia de
configuração).
51
A utilização de sistemas PDM auxilia a implementação da engenharia simultânea,
pois estes sistemas fornecem meios para integração e para o gerenciamento das informações
do produto e do processo de desenvolvimento de produtos conforme as necessidades da
empresa (MILLER, 2001).
Atualmente, o desenvolvimento de produto deve estar integrado com todas as
atividades, áreas e informações da empresa. Para atender essa necessidade, as versões mais
atuais dos sistemas PDM (chamados de PDM de segunda geração), atendem grande parte das
necessidades de engenharia, gerenciando os modelos CAD e aplicando o conceito DMU, os
recursos de coordenação dos fluxos de atividades de decisão, aprovação e ordenamento de
tarefas, e modificações realizadas sobre os modelos. A figura 3.10 apresenta os diversos
setores de empresas de autopeças (first tier) em que os sistemas PDM são utilizados.
Figura 3.10 - Departamentos que utilizam regularmente o sistema EDM/PDM (SOUZA, 2001).
Os dados de produtos que não são geridos por um sistema PDM como, por exemplo,
informações referentes ao planejamento da produção, inventário, venda, canais de distribuição
entre outros, devem ser administrados por outros sistemas. Ao invés de se usar um grande
5060 60
3020
40
60
80
100
Uso de EDM/PDMnas empresas de
autopeçasem porcentagem
6050
Desenvolvimentoe projeto
Fabricação Compras Controladoriae contabilidade
Marketing Vendas eDistribuição
52
número de sistemas separados, é comum uma empresa fazer o uso de sistemas ERP para este
propósito.
O objetivo dos sistemas ERP como visto na seção 3.5, é de gerenciar completamente
todos os dados dentro de uma empresa, assim, as funções tipicamente incluídas em um
sistema de PDM deveriam fazer parte do sistema ERP. De fato, os sistemas ERP mais
recentes apresentam algumas funções de PDM, às vezes como módulos separados. Até o
momento, no entanto, a funcionalidade de PDM em sistemas de ERP é bastante limitada.
Conseqüentemente, um sistema ERP raramente consegue substituir um sistema PDM.
Um sistema PDM (especializado) é mais completo do que as funções de PDM
existentes em sistemas ERP. MILLER (2001) apresenta alguns pontos negativos em utilizar
módulos de PDM presente em sistemas ERP:
• Não apresenta uma filosofia voltada para o projeto-engenharia (apresenta uma
filosofia voltada para a produção);
• Não é especializado;
• Não é flexível;
• Não é fácil de configurar o módulo;
• Não dispõem de funções de gerenciamento de documentação suficientes;
• Não dispõem de funções de gerenciamento de fluxo de trabalho suficientes;
• Não dispõem de funções de gerenciamento de configuração suficientes;
• Não existem muitos usuários no mundo;
• Não existem muitos consultores no mundo.
Entre esses dois sistemas há, porém, uma forte necessidade de compartilhar dados
comuns.
53
Muitos sistemas PDM (por exemplo, SmarTeam apresentado no apêndice B),
utilizam o paradigma de orientação a objeto para a definição e o gerenciamento dos dados do
produto (informações da estrutura do produto, arquivos CAD, etc.). O sistema gerência cada
definição do projeto como um objeto através de todo o ciclo de vida do produto. Estes objetos
podem ser manipulados pelo sistema, sem que o arquivo original seja alterado (OMOKAWA,
1999). Por exemplo, podem ser geradas várias cópias do objeto “peça 1”, na estrutura do
produto, e que possuam ligação apenas com um arquivo de CAD “peça 1”.
3.8.1 - Funções básicas de um sistema PDM
Embora, até o momento não exista uma definição universal para o termo PDM, pode-
se listar os módulos básicos que um PDM deve incluir.
Segundo CIMDATA (1996), PDM é uma tecnologia usada para administrar:
• Todas informações relacionadas com o produto: qualquer informação que descreve o
produto, assim como informações de seus componentes, configurações, documentos,
arquivos CAD/CAE/CAM, informações de autorizações de acesso a arquivos, etc;
• Todos os processos relacionados com o produto: definição e administração dos
processos, incluindo informações de autorização (qual usuário criou ou alterou a
informação e quando isto aconteceu) e distribuição.
Segundo PELTONEN (2000), existe um consenso razoável quanto às funções básicas
que um sistema PDM deve prover:
• Armazenar com segurança os documentos e outros arquivos em um banco de dados
com acesso controlado. Em muitas companhias, a primeira motivação por implantar
um PDM vem da frustração de pessoas que não conseguem achar os documentos que
54
procuram. A única informação que essas pessoas dispõem é alguma referência do local
que estes arquivos podem se encontrar dentro dos servidores. Pode haver muitas
cópias de um mesmo documento em localizações diferentes, e mesmo, duas pessoas
podem fazer mudanças contraditórias em duas cópias do mesmo documento;
• Associar objetos por atributos (por exemplo, material, fornecedor, no caso de peças).
Os atributos provêem de informações necessárias sobre o objeto, tendo grande
utilidade no processo de busca de documentos;
• Administrar a evolução temporal de um objeto por revisões seqüentes;
• Administrar as variantes de um objeto. Por exemplo, a configuração de um usuário
para um produto particular pode ser disponível em idioma diferente;
• Administrar os procedimentos de inspeção de versões associadas aos objetos;
• Administrar a divisão recursiva de um objeto em componentes menores (itens
dependentes do objeto);
• Administrar as mudanças que afetam múltiplos objetos;
• Administrar as visões múltiplas de um objeto;
• Administrar as representações múltiplas de documentos;
• Possuir ferramentas de visualização;
• Dispor de ferramentas de integração. Do ponto de vista do usuário, a utilização de um
sistema PDM depende muito do quanto este sistema é integrado com outras
ferramentas de uso diário no ambiente de trabalho;
• Prover a gestão de componentes. A administração de componente padrão comprado de
terceiros.
55
3.8.2 - Funcionalidades dos PDM
Ao inserir ou efetuar qualquer alteração em um arquivo CAD gerenciado em um
sistema PDM, os sistemas PDMs utilizam-se de um mecanismo chamado de “vault” ou cofre.
Este mecanismo (vault) é responsável pela segurança, controle e armazenamento dos dados,
garantindo sua integridade, ao passo que a base de dados é responsável pelo gerenciamento
dos meta-dados (dados sobre dados).
Todos os dados novos (arquivos), inseridos no sistema são criados na vault e quando
uma alteração é feita em algum dado (um arquivo, por exemplo), o que acontece de fato, é a
criação de uma cópia modificada dos dados, que incorpora a revisão dos dados originais. Por
exemplo, um arquivo de desenho CAD é armazenado na base de dados do sistema PDM.
Quando este desenho sofrer uma alteração, ele será salvo novamente no sistema PDM,
recebendo um indicativo, um atributo, de que é uma revisão do desenho original, sem que o
original seja excluído. O desenho original neste caso, não deve ser excluído por uma série de
razões, como por exemplo, o fato de já estar sendo usado em produtos no mercado.
O PDM ainda permite que estes dados sejam controlados como versões e dados
obsoletos, ou seja, conforme o arquivo (desenho) for recebendo alterações, a cada nova
alteração do arquivo, uma nova versão deste arquivo será criada, e quando o produto
associado a este arquivo não estiver mais em uso, este pode ser arquivado como obsoleto. Um
exemplo desta situação é um livro, que é revisado várias vezes, após seu lançamento no
mercado, de acordo com suas vendas. Este livro pode ser re-editado, ou seja, cada nova edição
é uma nova versão do livro de origem (que pode ir para o mercado ou não, dependendo de
aspectos comerciais). Normalmente após o fim da publicação de cada versão, os documentos
são arquivados pela editora, que pode, em um momento posterior, reutiliza-lo ou exclui-lo de
seus arquivos.
56
Como uma grande quantidade de dados é gerada, são utilizadas técnicas para
classificar estas informações de maneira ágil e fácil.
A classificação de dados é uma capacidade fundamental dos sistemas PDM. As
informações semelhantes são agrupadas em classes através da utilização de atributos que
descrevem as características essenciais de cada componente em uma determinada classe.
As classes contêm objetos que são organizados em um grupo, como desenhos,
cotações, especificações, contas, clientes, podendo também ser pré-definidas. No sistema
SmarTeam (ver apêndice B) por exemplo, as classes definidas são chamadas: projetos,
documentação, clientes, fornecedores e partes. Isto significa que para cada objeto, o usuário
pode visualizar a informação pertinente sobre a documentação, partes e clientes, ou visualizar
a estrutura do projeto.
3.8.3 - Classificação de componentes
Os componentes (peças, partes de um produto) são inseridos no banco de dados,
respeitando uma variedade de classes, que representam as necessidades organizacionais da
empresa. Esses componentes são normalmente agrupados em classes normalmente nomeadas
com o título do respectivo projeto. Isto permite que todos os componentes criados sejam
organizados facilmente em uma estrutura hierárquica. Assim, cada item, pode receber seus
próprios atributos, como por exemplo, certos componentes podem ser registrados como
opcionais. Este tipo de flexibilidade facilita a manutenção das listas de materiais - BOM,
apresentada na seção 4.1.
57
3.8.4 - Classificação de documentos
Os documentos podem ser classificados de acordo com componentes e montagens de
componentes. Cada documento pode ter uma variedade de atributos (número de itens, autor,
data de entrada). Ao mesmo tempo, um documento pode apresentar relações com outros
documentos ou outros componentes mantidos como dependente em sua estrutura. Como no
caso de um arquivo referente a um conjunto, este arquivo deve manter vínculo de dependência
com arquivos referentes a outros itens do conjunto (montagem), assim como deve manter
dependência com arquivos referentes a análises (elementos finitos, cinemática, por exemplo)
realizados no componente ou conjunto que representa.
3.8.5 - Estrutura do Produto
As informações referentes a um componente também podem ser acessadas através da
estrutura do produto (ver seção 4.1). Assim, para qualquer componente selecionado, as
relações da montagem entre seus componentes devem ser mantidas e especificadas para cada
tipo de processo de fabricação. Isto significa que uma lista completa dos materiais pode ser
criada de maneira a permitir a inclusão de documentos e itens, ou para um produto completo
ou para os sub-conjuntos. Uma vantagem a ser realçada é a habilidade que permite modelar
diferentes estruturas do produto, como, por exemplo, estruturas referentes a aspectos de
fabricação, financeiro, montagens. Assim, é possível que usuários de diferentes
departamentos ou atividades da empresa visualizem a estrutura do produto, de acordo com
suas necessidades.
58
3.8.6 - Administração de processos do PDM
A administração dos processos controla os usuários que criam e modificam os dados.
Normalmente, o processo de administração do sistema tem três funções básicas, segundo
MARKUS (1998):
• Administrar o que acontece com os dados quando algum usuário os manipula;
• Administrar o fluxo de dados entre as pessoas;
• Manter registrados todas as alterações e movimentos dos itens anteriores, de maneira a
preservar um histórico do projeto.
Isto se faz necessário, devido ao fato de que alguns dos objetos de engenharia passam
por muitas mudanças de projeto durante o curso de seu desenvolvimento, envolvendo
modificações realizadas anteriormente (no passado) para os dados de engenharia subjacentes.
3.8.7 - União hierárquica
Os sistemas PDM são projetados para organizar os dados de um projeto dentro de uma
estrutura hierárquica na forma de árvores com relação pai e filho (ver seção 4.1). Os vínculos
são criados quando são inseridas referências externas a um arquivo ou quando o arquivo é
armazenado. A figura 3.11 apresenta uma seqüência de atividades de um sistema PDM
durante o processo de desenvolvimento de um novo produto a partir de um sistema CAD.
Segundo MILLER (2001), ao se implantar um sistema PDM em uma empresa, os
seguintes ganhos são esperados:
• Redução dos custos de engenharia (pelo menos 10%);
• Redução dos custos de manufatura (10 a 25%);
59
• Redução do ciclo de desenvolvimento (25 a 50%);
• Redução do processo de modificações de engenharia (25 a 50%);
• Redução do número de modificações de engenharia (25 a 50%);
• Redução do custo de desenvolvimento de novos produtos;
• Redução do custo de novos produtos;
• Melhora na qualidade de produtos e serviços.
60
Figura 3.11 – Cenário típico de administração de dados de produtos CAD-PDM
Um desenho é
criado em CAD
O desenho é “armazenado” na base de
dados do PDM
A legenda do desenhoé inserida no PDM
O desenho é conferidoe inserido na “vault”
pelo sistema PDM
Referencias externassão inseridas ao desenho no PDM
O PDM administra o ciclo de vida do desenho• habilita a entrada e saída do desenho da estrutura
• Cria liberações (release) para o desenho• Verifica a entrada e saída de novas liberações
O sistema CAD
Modifica o desenho
O PDM “recupera” o desenhoe anexa as suas referências externas
e é atualizado na base de dados
61
A tabela 3.2 apresenta de forma comparativa os aspectos funcionais e técnicos dos
sistemas CAD, EDM, PDM e ERP.
Critério Opções
Origem
CAD EDM PDM ERP
Campo Funcional Projeto Produto Manufatura Corporação
Funcionais
Escopo de Aplicação Operações Grupos de
Trabalho Departamental Empresarial
Flexibilidade Baixa Média Alta Alta
Dados Gerenciados
Arquivos Específicos Arquivos Gerais Registros de
Base de Dados Registros de
Base de Dados Base de Dados Proprietária Relacional Orientada a
Objetos Relacional/Orientada
a Objetos Arquitetura
Independente Cliente/Servidor Cliente/Servidor Cliente/Servidor
Técnicos
Plataforma PC/UNIX PC/UNIX PC/UNIX PC
Tabela 3.2 – Comparação entre os sistemas CAD, EDM, PDM e ERP.
62
CAPÍTULO IV – FUNCIONALIDADES INTEGRÁVEIS
O propósito deste capítulo é analisar as características do produto que são
determinantes no processo de criação de novos produtos, assim como os métodos de
integração destas características nas diversas fases do processo de desenvolvimento do
produto.
Aparentemente, todos os atributos de um produto têm influência no processo de
desenvolvimento dos produtos e devem ser examinados.
A representação das características do produto começam com a determinação da
estrutura do produto, definida através da lista de materiais e de modelos baseados em
características (POPOV, 1998 b).
Autores como BEDWOTH (1991), PELTONEN (2000), SVENSSON (2000), POPOV
(1998 c) e OLIVEIRA (1999), apresentam a estrutura do produto como sendo a principal
funcionalidade a ser integrada entre os sistemas PDM e sistemas ERP.
A estrutura do produto possui uma posição de destaque entre as informações
fundamentais do produto, pois ela representa o ingrediente primário numa base de dados
totalmente integrada bem como o alicerce para a definição total do produto, sendo também
um elemento que gera integração, uma vez que suas informações são compartilhadas por
diversos departamentos numa empresa, influenciando decisivamente no sucesso do produto
(OLIVEIRA, 1999).
4.1 - Estrutura do produto – BOM (Lista de Materiais)
OLIVEIRA (1999) utiliza o termo lista de materiais BOM (Bill of Materials) como
sinônimo de estrutura do produto. Uma lista de materiais - BOM é uma estrutura dos dados do
63
produto que representa o produto final através de suas montagens, quantidade de itens e suas
relações (POPOV, 1998 c). A estrutura desta lista, permite o acesso das informações sobre os
itens por vários departamentos de uma empresa. Também ajuda os sistemas computacionais
em suas pesquisas referentes a diversos aspectos do produto: peso, quantidade e outros. A
BOM pode ser também, fonte de problemas, quando ela é estruturada de maneira conveniente
apenas para um departamento específico, o que causa problemas para outros departamentos.
As figuras 4.1 e 4.2 apresentam esquematicamente um trem de pouso, que é usado
como exemplo para descrever a estrutura de um produto, que pode ser vista na tabela 4.1.
64
Figura 4.1 – Desenho do produto final – Trem de pouso.
Figura 4.2 – Componentes do produto final desmontado – Trem de pouso explodido.
65
Lista de materiais
Trem de pouso – 10001 Número do item Quantidade Descrição Material
31000 01 Fixação Al. 2024T6
32000 01 Suporte Al. 2024T6
33000 01 Garfo Al. 7075T4
31100 02 Parafuso de Fixação M10
Al. 2024T6
31200 01 Estrutura da fixação
Al. 2024T6
32100 01 Estrutura do suporte
Al. 7075T4
32200 02 Parafuso de Fixação M12
Al. 2024T6
33100 01 Haste Al. 7075T4
33200 01 Estrutura do garfo
Aço 4340
33300 01 Trava Al. 7075T4
33110 01 Vareta Aço 4340
33120 01 Miolo Al. 7075T4
33130 01 Estrutura da haste
Al. 2024T6
33140 02 Parafuso da Coluna
Al. 2024T6
33320 02 Parafuso de Fixação M20
Al. 2024T6
33121 01 Êmbolo Al. 2024T6
33122 01 Tubo Al. 2024T6
33123 01 Retentor Al. 7075T4
33310 01 Haste da trava Al 7075T4
Tabela 4.1 – BOM - Lista de materiais do trem de pouso.
66
PELTONEN (2000) apresenta a estrutura do produto como uma das propriedades
fundamentais que representa virtualmente qualquer produto, descrito pelo arranjo de uma
estrutura hierárquica da divisão do produto em componentes, que são, por sua vez, divididos
em sub componentes, etc. O termo estrutura do produto refere-se a este arranjo hierárquico
dos componentes de um produto. O termo BOM é comumente usado para descrever este
arranjo hierárquico dos componentes (ver figura 4.3), embora PELTONEN (2000),
SWENSON (2000), POPOV (1998 a) tratem os dois termos (BOM e estrutura do produto) de
maneira distinta pelo fato da BOM representar todos os materiais utilizados no processo de
fabricação e na entrega do produto ao cliente como por exemplo, embalagens e manuais do
produto.
Figura 4.3 – Estrutura do produto para a lista de materiais da tabela 4.1.
Parafuso defixação M10
N.31100Qtd. 02
GarfoN.33000Qtd. 01
SuporteN.32000Qtd. 01
Parafuso defixação M12
N. 32200Qtd. 02
FixaçãoN. 31000Qtd. 01
Parafusoda ColunaN.33140Qtd. 02
HasteN. 33100Qtd. 01
TravaN.33300Qtd. 01
VaretaN.33110Qtd. 01
MioloN.33120Qtd. 01
Parafuso defixação M20
N.33320Qtd. 02
RetentorN.33123Qtd. 01
ÊmboloN.33121Qtd. 01
Nível 0
Nível 1
Nível 2
Nível 3
PAI
FILHO
PAI
PAI
FILHO
FILHO
Trem de PousoN. 10001Qtd. 01 PAI
FILHO
Nível 4
Estruturado garfoN. 33200Qtd. 01
Estrutura dafixação
N.31200Qtd. 01
Estrutura dosuporte
N.32100Qtd. 02
Haste datrava
N.33310Qtd. 01
Estrutura dahaste
N.33130Qtd. 01
TuboN.33122Qtd. 01
67
A figura 4.3 apresenta um arranjo hierárquico de um produto em uma estrutura de
“árvore”, (SVENSSON, 2000). A decomposição e o conteúdo da estrutura pode variar e
depender do propósito do arranjo. Do ponto de vista de engenharia, é um arranjo funcional
referente a sistemas e sub-sistemas. Do ponto de vista de manufatura, é um arranjo da
montagem preferencial do produto, conhecida normalmente de BOM, devido ao fato deste
termo estar constantemente relacionado com as atividades de fabricação, refletindo a
montagem de produtos (SVENSSON, 2000).
Segundo definiu a AMERICAN PRODUCTION AND INVENTORY CONTROL
SOCIETY – APICS (1992), BOM é uma lista de todas as sub-montagens, componentes
intermediários, matérias-primas e itens comprados que são utilizados na fabricação e/ou
montagem de um produto, mostrando as relações de precedência e quantidades necessárias de
cada item, como apresentado na figura 4.3.
Possíveis enganos na utilização do termo estrutura do produto e BOM, se devem ao
fato da estrutura do produto se tratar de uma lista de materiais de forma ‘incompleta’ e a
BOM se tratar de uma estrutura que representa o produto de uma forma mais ampla, podendo
conter outros objetos, tais como, instruções de trabalho ou ferramentas requeridas para
suportar o processo de manufatura.
Neste trabalho, os termos estrutura do produto e BOM são usados como termos
similares em diversas passagens, embora seja respeitada a diferença inerente ao uso destes
termos em aplicações específicas expostas nas definições anteriores.
Devido à grande diversidade de objetos que a BOM pode conter, é necessário definir
uma nomenclatura padrão para que o uso de cada um deles seja diferenciado e entendido
(OLIVEIRA, 1999). Segundo a APICS (1992), os objetos da BOM podem ser classificados
em:
68
• Item (item): qualquer matéria-prima, peça, embalagem, componente, sub-montagem,
montagem ou produto único manufaturado ou comprado;
• Componente (component): matéria-prima, peça ou sub-montagem que é utilizada
numa montagem de nível mais alto, ou em outro item (componente é filho de um
item). Esse termo pode incluir também embalagens no caso de itens finais;
• Peça (part): geralmente um item isolado comprado ou fabricado que é usado como
componente e não é uma montagem ou sub-montagem, nem matéria-prima.
A BOM é baseada na relação, pai e filho entre os itens, assim o item que está sendo
produzido é chamado item pai, e os itens requeridos na sua produção são chamados de itens
filho ou componentes. Dessa forma, o item chamado “Haste” apresentado na figura 4.5 é o
item pai e o item chamado “Miolo”, o item filho. Como este item (Haste) é utilizado na
montagem do “Trem de Pouso”, o “Trem de Pouso” assume o papel de item pai e a “Haste” se
torna o item filho. Assim, cada vez que é acrescentado um item filho, é acrescentado na BOM
um novo nível.
A figura 4.4 apresenta os objetos da estrutura do produto, assim como sua abrangência
e limitação.
69
Figura 4.4 – Objetos da estrutura do produto (OLIVEIRA, 1999).
Figura 4.5 – Relação entre os componentes do produto.
Peça(Compradas e Fabricadas)
Componente (item filho)(matéria-prima, embalagem, sub-montagens,
montagens)
Item (item pai)
Nível 2
Nível 3
Nível 4
Nível 0
Embolo
Miolo
Haste
Trem dePouso
70
Segundo OLIVEIRA (1999), uma BOM multi-nível é formada quando as BOMs de
um nível são associadas desde as matérias-primas e itens comprados até o produto final; isso
ocorre através da técnica chamada de explosão da BOM como a apresentada na figura 4.5.
Alguns padrões internacionais definem um número fixo de níveis na estrutura do
produto, diferenciados por nomes. Por exemplo, o padrão militar americano MIL-STD-280A
(comumente usado no seguimento aeronáutico), define oito níveis para a estrutura do produto,
nomeando-os de: sistema, subsistema, componente, grupo, unidade, montagem, sub-
montagem e item, onde cada nível determina uma definição diferente, embora permitam uma
certa arbitrariedade tanto para se nomear quanto para fixar os níveis (PELTONEN, 2000).
A forma com que as estruturas de produto são definidas determina a quantidade de
níveis e de componentes por nível que as estruturas apresentarão. Em um sistema MRP, por
exemplo, quanto maior for o número de estruturas presentes, o número de níveis por estrutura
e o número de componentes por nível, mais complexo será o cenário de gerenciamento, que
inclui maior número de transações de apontamentos (registro de documento), de manutenção,
maior probabilidade de erro e mais cálculos para o algoritmo executar (com a correspondente
implicação sobre o tempo de processamento do sistema e, por conseguinte sobre a freqüência
de execuções).
As estruturas encontradas nas situações práticas podem ser horizontais (quando
possuem muitos componentes com poucos níveis), verticais (quando apresentam poucos
componentes por níveis e vários níveis) ou complexos (quando possuem vários níveis e
muitos componentes por níveis). Quando se define a arquitetura das estruturas do produto,
deve-se ter uma postura extremamente crítica, no sentido da simplificação de níveis, e de
componentes por nível. Entretanto, a análise crítica deve ser feita levando em conta as
estruturas lógicas e o sistema produtivo, para que se possa chegar ao melhor desenho da
71
BOM. Em muitos casos, os níveis da estrutura da BOM estão relacionados com o processo de
montagem do produto (GIANESI, 2000).
A BOM também pode anexar instruções de trabalho ou ferramentas requeridas para
suportar o processo de manufatura, desta forma, todos os itens utilizados direta ou
indiretamente na produção do produto podem ser visualizados.
Um bom projeto pode inclusive reduzir substancialmente o número de estruturas de
produtos em um sistema ERP, com as evidentes vantagens de manutenção facilitada, maior
eficiência e rapidez nas execuções do sistema MRP.
4.2 - Utilização da BOM
Um sistema MRP necessita das informações da estrutura do produto. A definição de
qual vai ser a arquitetura da BOM usadas pelo sistema MRP (presentes como funcionalidade
nos sistemas ERP) tem grande importância para o desempenho do sistema MRP (GIANESI,
2000).
Teoricamente, a BOM pode e deveria ser criada automaticamente pelos sistemas
CAD, mas na pratica, há normalmente a intervenção humana ou re-digitação. Segundo
SVENSSON (2000), as razões principais para isto são:
• Dificuldade de localizar mudanças na BOM e efetivar a transferência dos dados
através do sistema de projeto. Muitas mudanças, como por exemplo, diferentes
fornecedores ou diferentes transportadoras, não afetam o projeto, mas tem um impacto
muito grande na logística dos sistemas industriais;
• Necessidade da existência de uma estrutura do produto diferenciada. É freqüentemente
necessário que um grupo de componentes semelhantes de produtos diferentes sejam
criados para serem produzidos em grandes lotes ou comprados eficientemente.
72
Os sistemas PDM habilitam alterações e implementações na BOM, criando as
alterações para o processo de fabricação de maneira a adequar as informações para uso no
sistema MRP (SVENSSON, 2000). Assim os sistemas podem usar a BOM para administrar a
configuração dos produtos de acordo com as necessidades de manufatura. (ver seção 4.6 -
engenharia de configuração).
4.2.1 - Estruturas múltiplas e visões
Não é necessariamente verdadeiro afirmar que um produto apresenta uma estrutura do
produto única. Por exemplo, um produto pode ter estruturas distintas para as atividades de
manufatura e para atividade de manutenção. Estas diferentes estruturas são chamadas de
visões do produto (PELTONEN, 2000).
Uma forma de atender as necessidades dos diversos segmentos da empresa é criar uma
estrutura genérica para o produto. O problema com este procedimento é que todas as visões de
um único produto precisam ser contempladas na mesma estrutura de arranjo, o que acaba
dificultando a sua utilização, devido ao grande número de detalhes (PELTONEN, 2000).
Se as visões diferentes de um produto necessitam ter estruturas diferentes, uma
solução simples seria assumir uma estrutura única e completa, na qual as diferentes visões são
habilitadas por filtros que permitem a exibição apenas dos dados desejados. Para que isto seja
possível, deve-se estabelecer um mecanismo que permita representar as informações
equivalentes.
73
4.2.2 - Pseudo-itens e itens fantasmas
Existem dois tipos especiais de itens, os pseudo-itens e os itens fantasmas. Itens
fantasmas são aqueles produzidos no processo de manufatura, possuindo “pais” definidos,
porém não são tipicamente estocados. De acordo com OLIVEIRA (1999), apesar de existirem
fisicamente, são rapidamente consumidos como componentes do item de nível imediatamente
superior na BOM. Um exemplo seria a sub-montagem de dois itens presentes em um mesmo
nível. Os sistemas de MRP geralmente reconhecem os itens fantasmas, e planejam suas
necessidades, entretanto esses itens não são programados, e geralmente possuem lead time
zero.
Pseudo-itens são agrupamentos artificiais de componentes utilizados para fins de
planejamento. Ao contrário dos itens fantasmas, entretanto, os componentes do pseudo-item
não podem ser manufaturados juntos para produzir um item pai que exista fisicamente. Por
essa razão os pseudo-itens nunca possuem inventário. Pseudo-itens são, por exemplo,
agrupamentos de pedidos de itens idênticos (parafusos), pertencentes a produtos distintos,
com o intuito de otimizar o processo de fabricação, compras e logística.
Os itens fantasmas e pseudo-itens são itens que constam na estrutura, mas para os
quais não são emitidas ordens de produção. Tudo se passa em termos de planejamento, como
se os itens fantasmas e pseudo-itens não estivessem na estrutura. Assim, seus filhos são
considerados como filhos de seus pais, quando for realizada a explosão no MRP (GIANESI,
2000).
74
4.3 - Identificação de produtos
OLIVEIRA (1999) apresenta os números do item PN (Part Number) como
informações fundamentais para a construção e eficiência da BOM, assim como o são sua
correta definição a partir de regras claras de criação, alteração e controle.
A APICS (1992) define o número de identificação (tradução livre de PN – part
number ou item number) como um número que serve para identificar de forma única um item.
Esse número pode ser classificado em:
• Significativo (significant part number): PN que contém certas informações sobre o
item. Ex: PN 123 M 456. Onde: 123 representa o material, a letra M representa que o
item é fabricado e o número 456 representa o número do desenho de engenharia;
• Não significativo (nonsignificant part number): PN que não contém informações sobre
o item. É um identificador e não descreve o item.
4.4 - Os efeitos da falta de acurácia
Segundo GIANESI (2000), os efeitos da falta de acurácia dos dados da estrutura do
produto são extremamente prejudiciais para o desempenho do sistema MRP, assim como os
efeitos da falta de acurácia dos dados de posição de estoques. Suponha o leitor, por exemplo,
que tenha havido alteração de engenharia, com a substituição de um componente. Os
desenhos novos (dos produtos atualizados) foram para a produção, e os antigos foram
removidos. Mas por alguma imperfeição de procedimento, digitação, atenção ou outro, a
informação da alteração do produto não foi refletida no sistema de gestão, ou seja, a estrutura
de produtos da base de dados do ERP continua inalterada. O planejamento continuará,
evidentemente, programando suas ordens de compra e produção baseadas na estrutura antigas.
75
O planejamento continuará programando o componente que não é mais usado e não
programará o novo componente. O resultado é falta de componentes na linha de produção e
atraso na entrega do produto (GIANESI, 2000).
4.5 - Administração da estrutura do produto
A administração da estrutura de configuração é a habilidade de administrar elementos
de um produto ou projetar a estrutura das relações entre os elementos.
A administração da estrutura do produto é um componente importante no
planejamento da produção. Todos os dados armazenados na BOM são usados em várias
atividades no planejamento da produção. Por exemplo, o departamento de planejamento pode
utilizar a BOM para desagrega-la através do sistema MRP e quantificar as ordens de
produção ou compras necessárias, de maneira a avaliar os custos envolvidos na produção de
um determinado produto (POPOV, 1998 c).
Nos sistemas PDM, um componente pode ser compartilhado de forma que dois
componentes fisicamente idênticos são descritos pelo mesmo objeto de componente em uma
estrutura do produto. Isto é necessário, quando dois componentes fisicamente idênticos são
projetados e em seu processo de fabricação necessitem de identidade própria (serem tratados
de maneira distinta), (PELTONEN, 2000).
4.6 - Engenharia de Configuração
Configuração de produto é um tipo especial de atividade de projeto, na qual a
atividade chave é o ajuste de uma gama de componentes pré-projetados que só podem ser
montados ou conectados um nos outros de modos específicos. Segundo MESIHOVIC (2000),
76
muitos são os produtos que apresentam configurações complexas, por apresentarem grande
número de itens opcionais ou produtos personalizados como na figura 4.6. Alguns exemplos
típicos deste tipo de produto são carros e aviões. Segundo fontes do departamento de
configuração da Empresa Brasileira de Aeronáutica – EMBRAER, um de seus produtos o
ERJ–145, um jato comercial para 50 passageiros (o número de lugares é uma das variáveis da
configuração), a aeronave possui mais de 20.000 itens e cada unidade necessita ser
personalizada de acordo com a necessidade do cliente o que faz com que sejam alterados mais
de 1000 itens de uma aeronave para outra. Segundo GOLTZ (2000), no projeto de um
submarino são necessários mais de 100.000 desenhos e se for levado em consideração todas
às alterações sofridas durante o projeto deste produto, este número aumenta algumas centenas
de milhares.
Os sistemas configuradores são implementados principalmente como configuradores
para atividades de vendas, como módulos de sistemas ERP. A BOM provem o histórico da
configuração do produto que é requerida e inclui o número dos itens. Assim, os
configuradores presentes nos sistemas ERP provêem um apoio limitado para tais produtos,
necessitando de ferramentas que apóiem configurações de produtos que contém itens pré-
projetados, parametrizados e modificáveis (MESIHOVIC, 2000).
77
Figura 4.6 – Avião: exemplo de produto com grande número de variáveis.
Para atender esta necessidade, as empresas utilizam sistemas PDM na configuração de
produtos integrados, para apoiar o desenvolvimento de configurações de produtos altamente
variáveis, garantindo uma personalização dos produtos.
Os sistemas PDM provêm a rastreabilidade de todos os dados e informações exigidas
para projetar, fabricar de maneira a manter e apoiar durante todo o ciclo de desenvolvimento
do produto. Os sistemas PDM também provêm apoio à modelagem dos processos.
Configuradores de produtos são sistemas que usam informações de definição de produtos no
processo de entrega para uma rápida e correta configuração das variantes dos produtos de
modo a atender as exigências dos clientes.
78
4.7 - Tecnologia de grupo
Muitas peças são similares com relação a forma e método de manufatura.
Tradicionalmente, cada peça é vista como única e é produzida em lotes individualizados.
Tecnologia de Grupo é um conceito que procura tirar vantagem das similaridades geométricas
e de fabricação entre as peças a serem produzidas.
Este conceito, inicialmente desenvolvido na Europa por volta de 1900, inicia com a
classificação das peças e registro das mesmas em arquivos ou em pastas. O conceito evoluiu
nos anos 50 e o termo tecnologia de grupo foi utilizado pela primeira vez em 1959
(PELTONEN, 2000).
A difusão do conceito ocorreu paralelamente à disponibilidade de computadores nos
anos 70.
A similaridade nas características de peças semelhantes possibilita a obtenção de
benefícios através da classificação e codificação destas peças em famílias. Observações em
fábricas indicam que é comum a existência de similaridades entre as peças, estas observações
consideram as peças individuais de cada produto (PELTONEN, 2000).
Como exemplo, consideremos uma bomba d’água, ela pode ser decomposta em
componentes básicos como: motor, eixos, vedações, flanges, etc. Apesar da variedade de
bombas manufaturadas, cada um destes componentes é basicamente o mesmo em termos de
projeto e métodos de fabricação. Conseqüentemente todos os eixos podem ser colocados na
família de eixos. Durante o processo de projeto, o projetista pode examinar todas as partes já
feitas pela empresa para determinar se uma peça com as características desejadas já existe
(LOUREIRO, 1994).
79
Este conceito torna-se importante em vista da crescente demanda do mercado por
grande variedade de produtos, cada um em menor quantidade. Nestas condições manter a
eficiência em operações em lote é difícil.
As principais vantagens da tecnologia de grupo são:
• Torna possível a padronização do projeto de peças e minimização da duplicação de
projetos. Os projetos de peças novas podem ser feitos utilizando projetos similares já
desenvolvidos;
• Facilita a construção e acesso a informações em bancos de dados;
• Custos de manufatura podem ser estimados mais facilmente, e informações estatísticas
sobre materiais, processos, número de peças e outros fatores podem ser facilmente
obtidos;
• Planos de processo podem ser padronizados e programados mais eficientemente,
ordens de produção podem ser agrupadas aumentando a eficiência, e a utilização de
máquinas é melhorada. Tempos de preparação são reduzidos, e as peças são
produzidas mais eficientemente e com melhor qualidade. Ferramentas similares,
dispositivos de fixação e máquinas são compartilhadas na produção de famílias de
peças.
Embora um sistema PDM possa prover apoio na administração da configuração de
produtos, é importante entender que o grau de configuração de um produto está baseada no
próprio produto e não no sistema de informação. Normalmente, isto significa que o próprio
produto tenha uma estrutura modular de forma que uma variante particular do produto possa
ser criada combinando um subconjunto satisfatório dos módulos disponíveis (PELTONEN,
2000).
80
A integração entre os aplicativos PDM e ERP é o um ponto de gargalo importante nas
empresas que necessitam de sistemas de configuração de produtos mais abrangentes
(MESIHOVIC, 2000).
4.8 – Visualização de arquivos
Os sistemas PDM e ERP possuem ferramentas de visualização de arquivos
padronizados para arquivos de sistemas CAD específicos, de maneira que o usuário visualize
estes arquivos sem a utilização de um aplicativo CAD. O usuário pode selecionar uma
estrutura de produto e visualizar o mockup digital deste produto através da representação
gráfica dos documentos do produto.
A visualização é uma ferramenta fundamental de apoio à engenharia simultânea usada
principalmente para mockups digitais, avaliações e especificações, assim como na troca de
documentos utilizados. O recurso de visualização também pode ser usado através de redes de
computadores (internet) entre parceiros de projeto ou clientes de maneira a prover uma re-
alimentação imediata de informações das necessidades do cliente.
Alguns sistemas PDM e ERP apresentam a capacidade de visualização da estrutura do
produto em desenhos em duas e três dimensões, de maneira a garantir uma administração
mais eficaz do ciclo de vida do produto.
81
CAPÍTULO V – TÉCNICAS DE INTEGRAÇÃO
As características de uma integração entre sistemas CAD e PDM com ERP devem ser
definidas de acordo com as necessidades específicas de cada empresa. Um exemplo de
integração é a transferência de uma estrutura de produto funcional de um sistema CAD ou
PDM, utilizado pela engenharia, para uma estrutura de montagem em um sistema ERP,
utilizado pela manufatura.
A especificação de uma abordagem de integração muitas vezes é condicionada não só
pelas necessidades da empresa, mas também pelas soluções técnicas disponíveis para
viabilizar a conexão entre os sistemas. Dessa forma, é necessário que haja um compromisso
entre os requisitos conceituais e as soluções técnicas disponíveis para garantir uma
implementação eficiente (ZANCUL, 1999 b).
Existem atualmente várias técnicas de integração destes sistemas. Cada técnica
representa um nível de complexidade e funcionalidades criadas para atender necessidades
empresariais específicas. As técnicas de integração entre sistemas PDM e ERP tratadas neste
capitulo, são válidas igualmente para integração de sistemas CAD com sistemas ERP. Alguns
autores empregam diferentes nomenclaturas para se referir à mesma abordagem de integração,
o que motivou a iniciativa de uniformizar a nomenclatura utilizada.
5.1 - Pessoas e Papéis
A forma mais simples de transferência de dados entre os sistemas PDM e ERP é
baseada em pessoas e papel. As técnicas de integração baseadas em pessoas e papéis são
freqüentemente negligenciadas em discussões de integração de sistemas. As integrações da
maioria dos sistemas industriais são realizadas por pessoas que usam papéis e reuniões,
82
fazendo a entrada e re-entradas dos dados manualmente. Este é um processo lento, propenso a
erros, e caro, mas reflete a realidade de que os recursos para construir integrações
automatizadas são limitados. Vale ressaltar que nem todas as organizações podem justificar os
custos de implementação de integração com customizações complexas (FERMAN, 2001).
Segundo ZANCUL (1999 b), as abordagens de técnicas de integração são classificadas
de acordo com o “Grau de Integração” e com a “Complexidade de Implantação” onde:
• “Grau de Integração”: é considerado como o nível de integração entre os dois
sistemas. O “Grau de Integração” é maior quanto maior for a quantidade de dados
compartilhados e quanto menor for a necessidade de dados redundantes.
• “Complexidade de Implantação”: refere-se à dificuldade técnica em se implantar a
abordagem desejada.
5.2 - Transferência de arquivos
Técnicas de transferência de arquivos automatizam a extração, armazenamento, e
carregamento de dados por arquivos (o arquivo do sistema de origem é armazenado num
disquete ou enviado via rede de comunicação). Isso reduz drasticamente os erros (de
digitação) e ainda mantém a geração e utilização isolados um do outros. Este isolamento evita
que as mudanças na substituição de um dos sistemas possa afetar o outro. Normalmente os
diferentes aplicativos (CAD/PDM e ERP) são desconectados gerando a transferência de
arquivos manualmente e atualizando-os através de cronogramas de trabalho. A transferência
dos arquivos não é realizada em tempo real, sendo necessário que ambos os sistemas
mantenham cópias dos dados transferidos que precisam ser mantidos atualizados (FERMAN,
2001).
83
A conectividade dos arquivos transferidos é relativamente fácil uma vez que as
pessoas geram conectividade através de papéis e entendem seu funcionamento. Normalmente,
a transferência de arquivos envolve mudanças mínimas no processo do negócio. Somente a
entrada dos dados é automatizada; as pessoas fazem a transferência dos dados de um sistema
para outro. Este tipo de mudança de documentos em papel para arquivos é freqüentemente
justificado como uma redução de custo, devido ao grande número de erros de digitação e aos
custos operacionais envolvidos.
Embora a maioria dos formatos de arquivos a serem transferidos são padrões internos
da empresa ou de fornecedores para clientes, existem alguns formatos padronizados como o
STEP e XML tratados na seção 3.6.
As empresas estão cientes que o aumento do volume de dados transferidos e dos
diferentes tipos de dados transferidos entre os sistemas se tornaram complexos e difíceis de
serem mantidos.
Muitas empresas adotam a conectividade de transferência de arquivos digitais através
da efetiva integração entre os aplicativos (CAD, PDM e ERP), para melhorar a eficiência da
integração e reduzir os dados redundantes. Embora a seleção da técnica de transferência de
arquivos normalmente esteja baseada em redução de custo, a transferência de arquivos
normalmente é considerada estratégica (FERMAN, 2001).
5.3 - Aplicação de programas de interface - API
A abordagem de integração utilizando aplicação de programas de interface – API
(Aplication Programming Interface) é atualmente muito empregada na integração de sistemas
PDM com sistemas ERP, bem como na integração dos sistemas CAD diretamente com os
sistemas ERP. Para isso, é necessário que pelo menos um dos sistemas suporte esse recurso,
84
permitindo que as funções internas sejam acessadas pelo outro sistema através de programas
específicos de integração.
Em alguns casos, a utilização de APIs elimina a necessidade de se manter dados
redundantes, permitindo o acesso em tempo real ao outro aplicativo (que necessita utilizar
estes dados). Os programas de integração também podem ser executados continuamente,
aguardando apenas a requisição de utilização, ao invés de serem iniciados manualmente ou
em um período de tempo pré-determinado. Isso resulta em um maior “Grau de Integração”, de
acordo com ZACUL (1999 b).
Para se utilizar uma API, é necessário que um aplicativo, por exemplo, o ERP,
permita a utilização de suas regras organizacionais internas e de segurança pelos usuários do
outro sistema (CAD/PDM). Uma das maiores dificuldades da integração por APIs é a sua
complexidade. As particularidades das APIs de cada fornecedor resultam na necessidade de
mão-de-obra especializada para o desenvolvimento dos programas de integração. Deve-se
destacar, também, que se um dos aplicativos (CAD, PDM ou ERP) for substituído, o
programa de integração precisa ser refeito. A utilização de “kits” de integração desenvolvidos
pelos fornecedores de sistemas PDM e ERP através de parcerias de desenvolvimento entre os
fabricantes dos aplicativos envolvidos tem facilitado a integração entre estes sistemas
(FERMAN, 2001).
Segundo ZANCUL (1999 b), a integração por API pode ser implantada de modo uni-
direcional ou bi-direcional. Uma integração uni-direcional pode ser desenvolvida, por
exemplo, para transmitir a estrutura de produto do sistema PDM diretamente para o ERP. Em
uma integração bi-direcional, a transferência de dados ocorre tanto do PDM para o ERP como
vice-versa. A transferência bi-direcional resulta em um maior “Grau de Integração” em
comparação com a unidirecional. Porém, a “Complexidade de Implantação” também é maior.
85
5.4 - Acesso direto à base de dados
Segundo FERMAN (2001), a integração por API é simplificada quanto ambos os
sistemas utilizam um mesmo banco de dados, de maneira que a comunicação é feita
diretamente com o banco de dados, (ZANCUL, 1999 b). Evita-se assim utilizar API’s com
sistemas e transações. Comandos de bancos de dados diretos provêem um acesso rápido às
informações do sistema, mas corre-se o risco de corromper o sistema a curto ou longo prazo.
Este corrompimento em curto prazo acontece, normalmente, devido a falta de compreensão
do sistema que está subordinado a um banco de dados de uso complexo (ZANCUL, 1999 b).
Para melhor entender este problema, pode ser feita uma analogia com uma conta bancária, se
uma pessoa possuir dois talões de cheque, quando for verificar seu saldo, deverá checar os
cheques lançados pelos dois talões, ou seja, quando, por exemplo, o sistema ERP alterar
algum dado, deve haver regras que garantam a atualização dos dados no sistema PDM ou vice
e versa. O corrompimento no longo prazo acontece, por sua vez, devido a mudanças
evolutivas normais no sistema inseridas pelo fornecedor do sistema (evolução do software) ou
pela implantação da interface por pessoas que desconhecem a arquitetura da integração.
Assim, a integração direta ao banco de dados é desaconselhada, recomendando-se a utilização
de APIs (FERMAN, 2001).
5.5 - Integração Homogênea
A utilização de um sistema ERP para a administração de documentos de engenharia
ainda é muito limitada como já foi discutido na seção 3.7, porém é utilizada por empresas que
não priorizam o processo de desenvolvimento de produtos (ver seção 5.8) de acordo com
86
ZANCUL (1999 b). Normalmente nestes casos, os aplicativos CAD são integrados aos
sistemas ERP via API.
5.6 - Integração homogênea com sistemas de diferentes fornecedores
ZANCUL (1999 b) apresenta a possibilidade de se integrar sistemas PDM e ERP de
diferentes fornecedores utilizando-se uma mesma base de dados, o que resultaria em um
maior grau de integração, porém existe a necessidade de grandes adaptações no sistema
(implementações funcionais na linguagem de origem) o que resultaria em uma maior
complexidade de implantação.
5.7 - Interfaces baseadas em objetos distribuídos
As linguagens de programação orientadas a objetos são técnicas adotadas pela maioria
dos sistemas PDM e ERP, e outros desenvolvedores de sistemas. A tecnologia de objetos
permite decompor sistemas grandes e complexos em sistemas menores, bem definidos
estáveis e autônomos como observado na seção 3.1. Objetos distribuídos provêem uma forma
dinâmica de alterações nos servidores utilizados (FERMAN, 2001).
A figura 5.1 apresenta as técnicas de integração entre sistemas PDM e ERP tratadas
neste capítulo.
87
Figura 5.1 – Classificação das abordagens técnicas de integração (ZANCUL, 1999 b).
5.8 - Estratégia de administração da estrutura do produto
A responsabilidade da gestão dos dados do produto (setor de projeto ou setor de
manufatura) varia entre as empresas, dependendo do ramo de negócio da empresa. Segundo
MILLER (2001), de acordo com a complexidade de projeto e a complexidade de manufatura,
do produto, pode-se classificar as empresas em empresa centralizadas em projeto e empresa
focadas em manufatura, como apresentado na figura 5.2.
Transferênciade
Arquivos
IntegraçãoHomogênea
IntegraçãoHomogênea
Com DiversosFornecedores
InterfaceBaseada em
Objetos
APIUni-direcional
APIBi-direcional
Acesso Direto a
Base de Dados
Grau deIntegração
Complexidadede Implantação
88
Figura 5.2 – Classificação das empresas segundo seu ramo de atividade (MILLER,
2001).
Esta classificação de tipo de atividade de empresa (centrada em projeto ou centrada em
manufatura) é fundamental para se estabelecer à integração entre os sistemas PDM e ERP,
pois de acordo com a atividade da empresa, normalmente se pode definir a influência de um
determinado sistema (PDM ou ERP), (MILLER, 2001). Isto acontece, porque normalmente os
sistemas PDM são priorizados por empresas com atividades centradas em projeto ao passo
que os sistemas ERP são priorizados por empresas com atividades centradas em manufatura,
como apresentado na figura 5.3.
Software Automobilística
Aeronáutica
Computadores
Telefones
Satélites
Bens deConsumo
Autopeças
Eletrodomésticos
MáquinasFerramenta
Centrados em Manufatura
Centrados emEngenharia Impacto da Manufatura
Baixo Alto
Impactodo
Projeto
Alto
Baixo Fixadores
89
Figura 5.3 – Utilização de sistemas PDM e ERP de acordo com o tipo de atividade da
empresa (MILLER, 2001).
Atualmente, os segmentos de desenvolvimento de produtos que utilizam de sistemas
PDM e ERP, usam com uma certa freqüência dois tipos de cadastros de materiais para um
produto: a BOM de projeto e a BOM de manufatura. Normalmente, quando a empresa possui
duas BOMs (projeto e manufatura), a BOM de projeto é utilizada pelo setor de projeto e,
conseqüentemente, no sistema PDM, e a BOM de manufatura é usada no sistema ERP para
atender as atividade de manufatura. Estas estruturas apresentam algumas diferenças, pois, os
projetistas listam os itens de acordo com a relação (dependência e independência – pai e filho)
entre eles. Mas isto não é suficiente para representar as restrições de manufatura ou
Centrados em Manufatura
Centrados emEngenharia Impacto da Manufatura
Impactodo
Projeto
Alto
Baixo
Baixo
Alto
ERP
+
PDM
ERP+
PDM
PDM
ERP
90
tolerâncias, necessitando de um arranjo diferente que assegure a sua manufatura (POPOV,
1998 c).
Foram identificados, segundo SVENSSON (2000), três estratégias entre as
companhias que usam sistemas PDM e ERP. Na primeira estratégia apresentada na figura 5.4,
cada departamento da empresa trabalha com estruturas de manufatura separadas no sistema
PDM e no sistema ERP. Quando os componentes recebem o status revisado no sistema PDM
(normalmente no departamento de projeto), eles podem ser transferidos para o sistema ERP
(normalmente no departamento de planejamento da produção). Esta é uma estratégia bastante
comum e a vantagem mais importante é que cada domínio (projeto ou manufatura) pode
trabalhar com uma estrutura do produto para seu respectivo propósito. Porém, há problemas
associados devido à dificuldade de trabalhar em paralelo, quando o projeto e o planejamento
da produção não trabalham nos mesmos sistemas de informação. Outro problema é o aumento
do número de sistemas computacionais que crescem com o número de domínios.
91
Figura 5.4 – Primeira estratégia de integração
Uma segunda estratégia apresentada na figura 5.5 seria inserir no sistema PDM, a
estrutura utilizada pelo projeto e a estrutura utilizada para a manufatura. As estruturas do
produto e para manufatura são elaboradas no sistema PDM. Quando todo o planejamento da
produção estiver pronto, então a estrutura de manufatura é transferida para o sistema ERP.
Esta estrutura só deve ser transferida quando esta apresentar o status revisado no sistema
PDM. Quando a estrutura do produto for alterada no sistema ERP, é necessária a
transferência de dados do sistema ERP para o sistema PDM para manter idêntica a estrutura
nos dois sistemas.
A principal vantagem desta estratégia é que as estruturas do produto para uso da
manufatura e do projeto estão em um mesmo sistema de computador, o que facilita a análise
em paralelo das fases iniciais do processo de desenvolvimento do produto. Todas as
atualizações podem ser feitas na fase inicial em um mesmo sistema quando a freqüência de
alterações for alta. Isto elimina a transferência de dados da estrutura do produto entre o PDM
Sistema PDM Sistema ERP
Estrutura de projeto Estrutura de manufatura
Atualização e transferência da Estrutura do Produto
92
e o ERP nas fases iniciais do projeto. Uma desvantagem desta estratégia é a existência da
estrutura referente a manufatura em dois sistemas distintos. Outra desvantagem é evidenciada
quando são feitas alterações no sistema ERP, uma vez que as atualizações também devem ser
feitas no sistema PDM.
Figura 5.5 – Segunda estratégia de integração.
Uma terceira possível estratégia apresentada na figura 5.6 é inserir diversas visões da
estrutura do produto (projeto, manufatura) em um único sistema ERP. Pode ser utilizado o
módulo de PDM de um sistema ERP para tarefas de administração de documentos e
gerenciamento das alterações de engenharia. A vantagem mais óbvia é a ausência de
atualizações e transferência de dados entre sistemas. A desvantagem é a limitação das funções
de PDM oferecidas pelos sistemas ERP. Os sistemas ERP neste caso necessitam de interfaces
Sistema PDM Sistema ERP
Estrutura de projeto e de manufatura
Atualização e transferência da Estrutura do Produto
Estrutura de manufatura
93
com sistemas CAD, que não são, atualmente, tão completas como as encontradas nos sistemas
CAD-PDM.
Figura 5.6 – Terceira estratégia de integração
Segundo LOUREIRO (1994), o momento em que a integração dos sistemas
(transmissão dos dados) deve se realizar é somente após a aprovação do projeto
(conseqüentemente aprovação da BOM) pelo time de projeto. Entretanto, a qualquer instante,
qualquer novo dado ou alteração pode ser fornecido ao sistema PDM por qualquer um dos
participantes das etapas do ciclo de vida do produto. Esse dado ou alteração não deve ser
incluído na estrutura de dados até a reunião do time de projeto, onde são decididas quais
alterações serão incorporadas na estrutura do produto. Todos integrantes do time de projeto
têm acesso à estrutura do produto atual, mas essa estrutura só é alterada em reunião.
A tabela 5.1 apresenta de forma comparativa a integração entre os sistemas de suporte
ao desenvolvimento de produtos.
Sistema ERP
Estrutura de projeto e de manufatura
94
INTEGRAÇÃO
CAD - CAD
CAD - PDM
CAD - ERP
PDM - ERP
Objetivo
Transferência de arquivos entre departamentos,
empresas e sistemas CAD
Habilitar a total gestão dos
arquivos CAD de maneira
segura e organizada
Habilitar a transferência de
dados do produto entre os
departamentos de projeto e
manufatura
Habilitar a transferência de
dados do produto entre os
departamentos de projeto e
manufatura
Meios de integração
Através de APIs ou através de
padrões neutros
Através de APIs ou através de
padrões neutros
Através de APIs ou através de
padrões neutros
Através de APIs ou através de
padrões neutros
Dificuldade
Os sistemas
CAD devem ser capazes de
reconhecer o padrão utilizado pelo sistema que
originou o arquivo
O sistema PDM deve ser capaz de reconhecer o
padrão ou linguagem de programação utilizado pelo sistema CAD
Os sistemas CAD e ERP devem
possuir APIs que
habilitem o reconhecimento
de padrões neutros e APIs que permitam o acesso a funções
do sistema oposto
Os sistemas PDM e ERP
devem possuir APIs que
habilitem o reconhecimento
de padrões neutros e APIs que permitam o acesso a funções
do sistema oposto
Usuários
Departamentos que se utilizam sistemas CAD
distintos
Empresas
centradas em projeto
Empresas
centradas em manufatura
Empresas que utilizam sistemas
PDM e ERP durante o ciclo
de vida do produto
Tabela 5.1 - Comparação da integração entre sistemas de suporte ao desenvolvimento de
produtos.
95
CAPÍTULO VI – INTEGRAÇÃO DOS SISTEMAS CAD/PDM E ERP
As empresas brasileiras que possuem o processo de desenvolvimento de produtos
apresentam diferentes realidades quanto às suas necessidades de integração. Para se ter uma
visão parcial desse cenário e exemplificar o processo de escolha da solução de integração,
foram analisadas duas empresas, denominadas neste trabalho de empresa A e empresa B.
6.1 – Descrição da empresa A
A empresa A é uma multinacional do ser automotivo que desenvolve, projeta, produz,
comercializa e atende a pós-venda de transmissões mecânicas de alto desempenho,
componentes para carros de passeio e caminhões leves. A empresa A é certificada pelas
normas QS-9000 e ISO – 14000, e fornece componentes e sistemas para as principais
montadoras do país.
Sua estrutura do produto inclui produtos complexos (com grande número de itens e
grande número de alterações) como veículos que podem ser montados em várias
configurações, conforme sua aplicação (tipo de motor, tipo de freio, com ou sem ar
condicionado, etc.).
A empresa A também controla as aplicações de revisão pela data de implementação na
linha de montagem. Existem vários itens que possuem peças alternativas. O controle de
opcionais, data de aplicação de revisões e peças alternativas é executado em sistema ERP
desenvolvido pela corporação a qual ela faz parte.
De acordo com as figuras 5.2 e 5.3, podemos classificar a empresa A como uma
empresa com fortes características tanto de manufatura como de projeto, assim, com
necessidade de utilização de sistemas PDM e ERP.
96
A empresa A ainda esta no processo de busca de uma solução para integrar o
aplicativo PDM (Metaphase) e o aplicativo ERP. A implantação desta interface é uma
questão estratégica da empresa, que depende de decisões da diretoria da empresa para que se
concretize. Uma dificuldade adicional para a empresa é o fato de utilizar um sistema ERP
desenvolvido pela própria empresa (não comercial), tendo a necessidade de desenvolvimento
de APIs e regras de acesso a informação para sistemas externos (CAD/PDM), o que torna esta
implementação complexa e extremamente custosa.
6.2 – Descrição da empresa B
A empresa B é uma multinacional do setor metalúrgico, fabricante de equipamentos
para geração de energia e certificada pelas normas ISO – 9002 e ISO – 14000.
A empresa B necessita que seus desenhos em CAD contenham a lista de peças com as
mesmas informações da nomenclatura de seu sistema ERP. As principais necessidades da
empresa B são:
• Centralizar as informações em uma única base de dados (nomenclatura e
gerenciamento de documentação);
• Preenchimento automático e consistente da legenda nos desenhos;
• Reduzir o ciclo de desenvolvimento do produto;
• Integração de todos os processos envolvido na fabricação.
De acordo com as figura 5.2 e 5.3, podemos classificar a empresa B como uma
empresa centrada em atividades de manufatura, não necessitando de funcionalidades
específicas de um PDM.
Para atender as necessidades, a empresa B implantou o módulo de gerenciamento
eletrônico de documentos em seu sistema ERP e decidiu-se pela implantação de uma interface
97
entre o sistema CAD utilizado (AutoCAD) e o módulo de gestão de documentos eletrônicos
do seu sistema ERP (SAP R/3) de maneira a:
• Preencher a lista de peças dos desenhos de maneira automática, conforme a base de
dados do sistema ERP utilizado pela empresa B (SAP R/3);
• Customizar a lista de materiais conforme a necessidade dos clientes da empresa B
(cliente diferente em cada projeto).
A empresa B é a pioneira na implantação de interface entre os aplicativos CAD e ERP
no Brasil. Segundo informações das empresas que comercializam sistemas ERP, nenhuma
outra empresa implantou uma interface entre sistemas CAD ou PDM com sistemas ERP.
6.3 – Características relevantes na integração CAD/PDM – ERP
De maneira a auxiliar o processo de implantação de interfaces entre os sistemas
CAD/PDM e ERP, foi elaborada uma análise dos sistemas CAD, PDM e ERP utilizados no
Centro de Competência em Manufatura CCM do ITA, apresentando as diretrizes básicas da
integração entre esses aplicativos.
O CCM está localizado no ITA, ocupa uma área de 650 m2 e foi concebido para ser
composto por três áreas técnicas complementares, dentro do conceito de DIP: Projeto e
Análise de Produtos, Planejamento da Produção e Fabricação.
O principal objetivo do CCM é disseminar o conceito de DIP – Desenvolvimento
Integrado de Produtos – bem como a metodologia de sua implementação para estudantes e
profissionais da área de engenharia. Para alcançar esses objetivos, as atividades do CCM
incluem, além de educação, pesquisa, projetos com indústrias, seminários e workshops.
98
O CCM desenvolve atividades de ensino e pesquisa na área de desenvolvimento
integrado de produtos e pode ser classificado pelas figuras 5.2 e 5.3 como uma instituição
centrada em atividades de projeto.
Atualmente, o CCM dispõem aplicativos de CAD “high-end” comercial CATIA V5,
aplicativo PDM comercial SmarTeam (descrito no apêndice B) e aplicativo ERP comercial
SAP R/3 (descrito no apêndice A). O Aplicativo SmarTeam utilizado pelo CCM já possui
interface com o aplicativo CATIA V5, aplicativos Microsoft Office e com outros sistemas
CAD comerciais (Autocad, Solid Edge, Solidworks, entre outros).
Como forma de apoiar futuras implantações de interface entre sistemas PDM e ERP
por empresa brasileiras, o trabalho realizado no CCM focou principalmente este tipo de
interface (PDM – ERP). Desta maneira o CCM neste trabalho foi classificado como uma
empresa com características tanto de manufatura como de projeto (similar à empresa A) que
dispõem de sistemas CAD, PDM e ERP comerciais.
Não são todas as empresas que possuem seus problemas identificados, muitas vezes
desconhecendo os problemas que podem ser solucionados através da implantação de uma
interface entre os sistemas PDM e ERP. Assim, durante o processo de identificação das
possíveis ferramentas a serem utilizadas na otimização do processo de desenvolvimento de
produtos, muitas questões devem ser esclarecidas.
Nem sempre há uma solução única que atenda todas necessidades das empresas, vários
são os critérios a serem considerados na decisão de qual ferramenta deve ser utilizada para
integrar as informações do setor de projeto com o setor de manufatura, como escopo, objetivo,
negócio, cultura da empresa entre outros.
A tabela 6.1 apresenta as principais questões a serem consideradas pelas empresas de
maneira comparativa entre as empresas A e B e o CCM.
99
QUESTÕES A SEREM
ANALISADAS
EMPRESA - A
EMPRESA - B
CCM
É possível utilizar as
funcionalidades do sistema
ERP já utilizado na empresa?
NÃO
SIM
NÃO
O sistema ERP utilizado
apresenta funções de PDM?
NÃO
SIM
SIM
As funções de PDM presentes
no sistema ERP são suficientes
para atender as necessidades
de DIP da empresa?
Não possui esta função
SIM
NÃO
A empresa pode esperar e por
quanto tempo por versões
futuras de seu sistema ERP
que atendam as necessidades?
Sem previsão
As funções atuais atendem as
necessidades
NÃO atendem o cenário
proposto, que se utiliza
aplicativo PDM.
O fornecedor de ERP tem uma
equipe capacitada disponível
para implementar esta
interface?
Não possui experiência em
integração entre sistemas
ERP e PDM
Existem empresas de
consultoria que já
implementaram esta interface
em outros países
Existem empresas de
consultoria que já
implementaram esta
interface em outros países
O sistema ERP utilizado pela
empresa permite a integração
com sistemas PDM?
Sim, porém necessita de alto
grau de customização
Sim, existem interfaces
comerciais entre os sistemas
CAD e ERP utilizado pela
empresa.
Sim, existe interface
comercial entre os sistemas
PDM e ERP utilizado pela
empresa.
Já existe alguma interface
comercial certificada entre o
sistema ERP e PDM utilizado
pela empresa?
NÃO
A empresa utiliza módulo de
controle de alterações de
documentos digitais do sistema
ERP para atender suas
necessidades de PDM
SIM
100
Quais são as alternativas para
esta integração?
Desenvolvimento de
interface entre o sistema ERP
e o sistema PDM utilizado
(Metaphase)
Desenvolvimento ou compra de
interface entre sistema ERP
utilizado (SAP R/3) com o
sistema CAD utilizado
(AutoCAD)
Desenvolvimento ou
compra de interface entre
sistema ERP utilizado (SAP
R/3) com o sistema PDM
utilizado (SmarTeam)
Quais os pontos a considerar
nesta decisão?
Retorno sobre investimento
Impacto no processo DIP
Retorno sobre investimento
Impacto no processo DIP
Impacto no processo DIP
A empresa trabalha de maneira
centrada em projeto ou
centrada em manufatura?
Apresenta as duas
características
Centrada em manufatura
Centrada em projeto, mas
para o cenário proposto a
empresa apresenta as duas
características.
Tabela 6.1 – Principais questões a serem assumidas pelas empresas em busca da integração
entre as informações de projeto e manufatura.
Antes da implantação da interface entre os sistemas CAD/PDM com sistemas ERP
vários critérios (comuns para todas as empresas) devem ser analisados de maneira a garantir
uma boa implementação da interface como:
• Treinamento e capacitação dos profissionais envolvidos;
• Seleção do sistema;
• Recursos de software envolvidos (sistema operacional, por exemplo);
• Recursos de hardware necessários;
• Possibilidade de integração com outros sistemas;
• Garantia de manutenção da interface;
• Conhecimento de como a interface foi implantada em outras empresas.
101
Uma dificuldade encontrada pela empresa B foi à resistência por parte de seus
colaboradores (funcionários) na utilização desta interface assim como elevado número de
erros no seu uso (por exemplo, erros na criação de cadastro de material a partir do aplicativo
CAD). Este tipo de dificuldade é bastante comum na implantação de novas ferramentas
computacionais como PDM e ERP, assim como dificuldade de ordem prática no inicio de
operação.
As principais vantagens resultantes desta integração, relatadas pela própria empresa B
são:
• Entradas de novos dados uma única vez (com único cadastro não é necessário
confeccionar várias listas de materiais);
• Os itens não precisam ser re-digitados (itens que já estão contidos na base de dados
do sistema ERP, não precisam ser recadastrados);
• Consistência da lista de materiais do desenho com a nomenclatura do sistema ERP
(um exemplo é a necessidade de conter no desenho o número do item e o código
deste documento no cadastro do sistema ERP);
• Redução do ciclo de trabalho (com a redução do número de lista de materiais, foi
possível diminuir o ciclo da engenharia e como existem usuários do sistema ERP por
toda a empresa, o documento pode ser localizado e visualizado no sistema ERP de
forma ágil e com as informações atualizadas para o uso);
• Vínculo entre componentes CAD e ERP (as entidades do sistema CAD possuem
vínculo em tempo real com o sistema ERP);
• Acesso aos dados nos dois sentidos (é possível ter acesso as informações partindo do
sistema CAD ou do ERP);
102
• Existência de interface também com módulos de equipamentos (o mesmo vinculo
feito com o cadastro de materiais, pode ser feito com o cadastro de equipamentos no
sistema ERP);
• Todos os documentos podem ser gerenciados pelo sistema ERP (auxilia a procura,
status, versão, etc.).
Esta interface CAD – ERP se mostrou bastante flexível como relatado pela empresa B,
porém foram necessárias várias implementações para atender as necessidades específicas da
empresa. A interface CAD – ERP habilita as seguintes funções durante o fluxo de trabalho
(seqüência de atividades realizadas durante o desenvolvimento do produto):
• Criar um registro de informação de cada documento no sistema ERP para cada
desenho, a partir do menu do sistema CAD, com alguns campos já preenchidos
(caminho para o arquivo, usuário, etc.);
• Armazenar as informações da legenda do desenho no sistema ERP;
• Criar o conjunto (representado pelo desenho) como material no sistema ERP, a partir
da interface CAD-ERP (O sistema ERP mantém um link entre o desenho e o
material);
• Criar um material para cada item, ou ligação com material existente;
• Gerar a BOM mantendo sempre a ligação entre o desenho e os itens da BOM
(sistema inteligente que edita o desenho, baseado nas modificações efetuadas nos
dados do sistema ERP);
• Controlar as alterações através de ligação entre os desenhos e as alterações de
engenharia.
103
6.4 – Descrição do fluxo de atividades
De maneira a se tornar didática o processo de integração proposto neste trabalho (caso
CCM), um ambiente simples é usado como exemplo. O ambiente consiste em um sistema
PDM e um sistema ERP, onde o problema consiste em manter as informações usadas no
projeto e na fabricação atualizadas, quando uma mudança ocorre na estrutura do produto.
Foram adotadas três etapas do desenvolvimento de um produto, as quais representam o foco
principal deste estudo.
Etapas do ciclo de vida do produto:
1 - O ciclo de vida do produto em estudo se inicia no departamento de marketing e vendas de
uma empresa, onde, a partir de uma necessidade de mercado e um estudo técnico econômico,
tem-se a necessidade ou oportunidade da criação de um novo produto;
2 - Em seguida, os requisitos do produto são encaminhados para a engenharia, onde é
elaborada uma análise de projeto. Nesta etapa, são elaborados e revisados inúmeros desenhos
do produto sendo inclusive construído um protótipo do produto. Para isto, é necessária a
criação de:
• Lista de materiais do produto;
• Elaboração do cadastro dos materiais;
Durante a segunda etapa, muitos documentos em forma de arquivos eletrônicos são
gerados, como desenhos em planilhas e textos referentes ao produto.
Desta maneira, o usuário de um sistema CAD, por exemplo, ao concluir um trabalho
(desenho) não necessita “salvar” seu arquivo no disco rígido do computador onde o arquivo
foi gerado ou qualquer outro utilizado para esta finalidade, mas irá salvar o arquivo,
diretamente em um banco de dados gerenciado por um sistema PDM.
104
3 – Nesta terceira etapa, após de validado o produto pela engenharia, os materiais e
componentes necessários à produção de uma unidade deste produto é enviado ao setor de
planejamento. Em seu planejamento, será definido o plano de produção deste produto,
emitindo ordens de compra e ordens de fabricação específicos para cada material e
componente deste produto. Para o planejamento da produção, os planejadores necessitam
normalmente de quatro informações básicas que são:
• O que será fabricado ou comprado – esta informação esta presente no cadastro dos
materiais;
• Com que será fabricado ou montado para se obter o produto – esta informação esta
presente na lista de materiais de produção do produto;
• Como será manufaturado o produto – esta informação esta presente nos roteiros de
fabricação do produto;
• Onde o produto será manufaturado – esta informação esta presente no cadastro de
centro de trabalho a serem utilizados na manufatura;
Dando seqüência ao fluxo dos documentos referentes ao produto dentro do ciclo de
vida tradicional de um produto, as informações do produto são encaminhadas para diversos
outros setores dentro de uma empresa. De maneira a tratar as informações de forma integrada
entre os diversos setores de uma corporação industrial, utilizam sistemas de gestão
corporativos ERP. Assim, as informações provenientes das atividades de engenharia devem
ser inseridas nos sistemas ERP para que estas possam suprir os diversos setores que utilizam
estas informações para se dar seqüência ao ciclo de vida neste estágio de desenvolvimento
não somente do produto, mas na corporação como um todo. A estrutura do produto e os
materiais e componentes utilizados para compor o produto devem ser cadastrados no sistema
ERP para que estes possam ser utilizados pelos planejadores da produção no tradicional
105
sistema de gestão de materiais MRP de maneira a emitirem suas ordens de compras e ordens
de produção.
Embora os sistemas ERP apresentem esta capacidade mesmo limitada de administrar
os dados de engenharia, estes sistemas não dispõem de integração com sistemas CAD.
A Figura 6.1 apresenta o fluxo dos dados propostos nesta integração, seguindo do
estagio de projeto para o estagio de manufatura obedecendo a seguintes fases:
1 - fase de idéias (CAD);
2 - fase de projeto (PDM);
3 - fase de produção (ERP);
4 - conclusão (ERP).
Figura 6.1 - Fluxo dos dados de engenharia
O controle do fluxo de informações entre os sistemas PDM-ERP é sempre transmitida
do sistema PDM para o sistema ERP. Isto tem como causa principal, que os usuários do
sistema PDM irão sempre executar os comandos de criar novo item, lançamentos, etc. As
atividades no sistema ERP sempre serão uma resposta para as ações causadas pelo sistema
PDM. Conseqüentemente, o controle de fluxo compara a ordem cronológica do projeto e
processo de fabricação requerido para conceber o projeto do produto, completar o projeto e
CAD PDM ERP
106
fabricar o produto. Esta é a razão para que a transmissão seja sempre na direção do PDM para
o ERP. Este tipo de relação é conhecido como Mestre-Escravo, onde o PDM funciona como
mestre.
Considerando que o controle de fluxo é sempre enviado para as etapas posteriores,
então o fluxo de dados também deve ser. Porém isto não é completamente verdade desde que
os principais dados dos itens estiverem no sistema, o número de identificação do material,
deve ser transmitido na direção oposta, do ERP para o PDM. Há outros dados que também
devem ser transmitido para o PDM (dependendo da necessidade de cadastro destes dados na
base de dados dos sistemas PDM). A explicação disto é que estes valores são enviados para o
PDM como retorno de valores de chamadas de funções inicializadas pelo PDM através do
sistema de operações, nunca sendo inicializadas pelo ERP.
Para a analise do processo de integração, foram utilizados o sistema PDM comercial
SmarTeam e o sistema ERP comercial SAP R/3 que são detalhados nos apêndices A e B
respectivamente. O sistema SmarTeam dispõem na forma de módulo um software de interface
com sistemas ERP denominado comercial de SmartGateway o qual é descrito no apêndice C.
107
CAPITULO VII – CONCLUSÕES E SUJESTÕES PARA TRABALHOS FUTUROS
7.1 – Conclusões
A implantação da integração CAD/PDM-ERP inclui aspectos tanto tecnológicos como
organizacionais. A utilização da interface CAD/PDM-ERP em uma rede de computadores
diminui as barreiras para que as pessoas os utilizem, tornando mais natural essa utilização.
Quanto maior o grau de integração, maior o impacto das ferramentas de
desenvolvimento integrado de produtos na elaboração de novos produtos.
Infelizmente, nem todos os sistemas (CAD, PDM, ERP) são criados da mesma
arquitetura devido a diferenças quanto à finalidade do projeto, e a tecnologia utilizada. É
importante conhecer e entender as diferenças entre os sistemas que estão sendo utilizados,
para um melhor planejamento do processo de integração.
Em um ambiente ideal, todos os sistemas compartilham definições comuns,
identificam objetos e há somente uma cópia de qualquer informação. Muitos sistemas forçam
ao usuário a tomar decisões de maneira a adquirir outros produtos de sua propriedade para
suportar a integração. É freqüentemente difícil trabalhar com os planos e tabelas de um
produto em banco de dados.
Para integrar dois sistemas com padrões definidos, o usuário deve isolar ambos os
sistemas proprietários através de uma interface padrão. Isso permite que os especialistas de
cada sistema possam trabalhar independentemente.
As características de integração entre sistemas CAD e PDM com ERP devem ser
definidas de acordo com as necessidades específicas de cada empresa e pelas soluções
técnicas disponíveis para viabilizar a interação entre os aplicativos computacionais. Existem
atualmente várias técnicas de integração destes sistemas, onde cada técnica representa um
nível de complexidade e funcionalidades criadas para atender necessidades empresariais
108
específicas. A principal técnica utilizada pelas empresas para automatizar o processo de
transferência de dados do produto entre a fase de projeto e manufatura é através de programa
específicos de interface (APIs) entre os aplicativos computacionais.
Observando o processo de implantação das interfaces, pode-se notar que a “fórmula”
para uma boa integração está na fase de refinamento. O usuário deve implementar a
integração básica primeiro, e então ampliar a integração que as funcionalidades utilizadas nas
fases mais incipientes do projeto. As semelhanças entre os sistemas diminuem quando se
soma complexidade para a funcionalidade de integração.
A estrutura do produto possui uma posição de destaque entre as informações
fundamentais, pois ela representa o primeiro passo para a elaboração de uma base de dados de
produto totalmente integrada. A BOM é também um elemento que gera integração uma vez
que seus dados são utilizados na realização das atividades de diversas áreas da empresa, como
engenharia, qualidade, PCP, compras, manutenção, custeio, marketing, vendas e
configuração, assistência técnica e tecnologia de informação. Assim, a forma como é
gerenciada, controlada e estruturada pode diretamente influenciar o sucesso da empresa.
Vários são os motivos que justificam e implantação de interfaces entre os aplicativos
computacionais de gestão de dados do produto como: a necessidade de centralizar
informações em uma única base de dados, redução do ciclo de desenvolvimento do produto,
automatização dos processos de gestão e consistência dos dados do produto.
As principais características que determinam a abordagem de integração a ser utilizado
por uma empresa dependem do ramo de negócio da empresa, por exemplo, se a empresa esta
centrada em projeto ou centrada em manufatura, de acordo com a complexidade de projeto e
manufatura de seu produto.
Nem sempre há uma solução única que atenda todas necessidades das empresas, vários
são os critérios a serem considerados na decisão de qual ferramenta deve ser utilizada para
109
integrar as informações do setor de projeto com o setor de manufatura, como escopo, objetivo,
negócio, cultura da empresa entre outros.
7.2 – Sugestões para trabalhos futuros
A partir do trabalho realizado, pode-se ampliar a análise da integração entre os
sistemas CAD/PDM e sistemas ERP, assim como verificar outras possibilidades e
características de integração através da:
• Ampliação do escopo de empresas de manufatura discreta de alta série (por exemplo,
automobilistica);
• Associação de métricas e indicadores que estejam relacionados com o impacto antes e
depois da aplicação de técnicas de integração nos ambiente de engenharia de maneira
a comprovar a influência das técnicas de integração.
110
REFERÊNCIAS BIBLIOGRAFICAS
AGUIAR, A. F. S. Sistemática de seleção de sistemas computacionais para auxílio às
atividades de engenharia. 1995. 139 f. Dissertação (Mestrado em Engenharia Mecânica) –
Faculdade de Engenharia de São Carlos, Universidade de São Paulo, São Carlos.
AMERICAN PRODUCTION AND INVENTORY CONTROL SOCIETY. APICS
Dictionary. 7.ed. Falls Church, VA: American Production and Inventory Control Society,
1992.
ANDREASEN, M. M. e HEIN, L. Integrated Product Development, London, IFS Ltd, 1987.
202p.
BANCROFT, N. H; SEIP, H; SPRENGEL, A. Implementing SAP R/3. 2. ed. Greenwich,
Manning Publications Co. 1997. 310p.
BATOCCHIO, A. Um modelo de índice de automação relacionada à flexibilidade e a
produtividade dos sistemas de manufatura. 1991. 301 f. Tese (Doutorado em Engenharia
Mecânica) – Faculdade de Engenharia Mecânica, Universidade Estadual de Campinas,
Campinas.
BERNARDES, R. Gestão estratégica da inovação tecnológica. Curso de extensão, São José
dos Campos, Centro Técnico Aeroespacial, 1999. v. 2.
BRAGA, M. A. Além do PDM. Cadware, ano 4, n. 11, p. 30-31, set/out, 2000.
BREMER, C. F. Proposta de uma metodologia para o planejamento e implantação da
manufatura integrada por computador. 1995. 197 f. Tese (Doutorado em Engenharia
Mecânica) – Escola de Engenharia de São Carlos, Universidade de São Paulo, São Carlos.
BEDWORTH, D. D. et al. Computer-integrated design and manufacturing. New York,
NY. McGraw-Hill, 1991. 653p.
111
BOÓR, F; KOVÁCS, J; MIKÓ, B. Capabilities of the workflow management system. [Sl]:
CONFLOW, 1997. (Document No. CONFLOW. 97.11)
BOURKE, R. W. New directions in the aerospace and defense industry: the integration of
product data management and enterprise resource planning systems. Disponível em:
<http://www.bourkeconsulting.com/views.html>. Acesso em: 18 dez 2001. [a]
BOURKE, R.W. Product information management. Disponível em:
<http://www.pdmic.com/article/artprod.html>. Acesso em: 20 out 2001. [b]
CIMDATA. Product data management: the definition.: A Technology Guide, An
Introduction to Concepts and Benefits, 1992.
COSTA, S. S. L; CAULLIRAUX, H. M. Manufatura integrada por computador: sistemas
integrados de produção – estratégia, organização, tecnologia e recursos humanos. Rio de
Janeiro. Editora Campus Ltda, 1995, 420p.
CORVALÃO, E. D; OLIVEIRA, I. C. XML e modelagem de dados. Disponível em: <
http://www.eps.ufsc.br/~kern/infmod2k/infmod2k.pdf>. Acesso em: 15 jan 2002.
CRUZ, T. Workflow: a revolução na arte de administrar. Tecnologia Hoje, Disponível em:
<http://www.ietec.com.br/techoje>. Acesso em: 17 jul 2001.
D’ISSY, M. Mercado continua com bilhões de arquivos em papel. Cadesign, n. 77, 18-19,
2001.
DIETER, G. E. Engineering design. 2. ed. New York, NY. McGraw-Hill, 1991. 721p
DURAN, W. História da civilização, São Paulo, Editora Nacional, 1958. v. 18
FERMAN, J. E. ERP to PDM integration. Disponível em:
<http://WWW.pdmic.com/IPDMUG/wp_erp_pdm.shtml>. Acesso em: 13 out 2001.
FERNEDA, A. B. Integração metrologia, CAD e CAM: uma contribuição ao estudo de
engenharia reversa. 1999. 102 f. Dissertação (Mestrado em Engenharia Mecânica) – Escola de
Engenharia de São Carlos, Universidade de São Paulo, São Carlos.
112
GAMA, E. B. CAD versus AutoCAD, Cadware, ano 3, n. 11, p. 6, jan/fev, 1999.
GIANESI, I. G. N; CORRÊA, L. H; CAON, M. Planejamento, programação e controle da
produção. São Paulo: Atlas, 2000. 411 p.
GOLTZ, M; GRIGOROVA, K; BOÓR. F. Specification of interdependencies between
product structure and process execution. [Sl]: CONFLOW, 1998. (Document n.
CONFLOW. 98.07)
GOLTZ, M; GRIGOROVA, K; BOÓR, F; PALOTAI, R. Final project report. [SI]:
CONFLOW, 2000. (Document n. CONFLOW.00.09)
KERN, V. M. Manutenibilidade de modelos de dados de produtos compartilhados em
rede interoperável. 1997. 97 f. Tese (Doutorado em Engenharia de Produção) –
Universidade Federal de Santa Catarina, Florianópolis.
LOUREIRO, G. QFD auxiliado por computador em abordagens por engenharia
simultânea, 1994. 292 f. Dissertação (Mestrado em Engenharia Mecânica Aeronáutica) –
Instituto Tecnológico de Aeronáutica, São José dos Campos.
MACHLINE, C; MOTTA, I. S; WEIL, K. E; SHOEPS, W. Manual de administração da
produção. 3. ed. Rio de Janeiro: Editora da Fundação Getulio Vargas, 1976. v. 1.
MÁRKUS. T; SZÉCSI. Z. Capabilities of the product data management system. [Sl]:
CONFLOW, 1998. (Document n. CONFLOW.97.10)
MESIHOVIC, S; MALMQVIST, J. Product data management (PDM) system support for the
engineering configuration process. In: EUROPEAN CONFERENCE ON ARTIFICIAL
INTELLIGENCE, 14 th., 2000, Berlin. Proceeding… ECAI, 2000.
MILLER, E. BILELLO, P. PDM e ERP Integration. (CD ROM). In: CIMdata 2001. Palm
Spring, California. 2001.
113
OLIVEIRA, C. B. M; Estrutura, identificação e classificação de produtos em ambientes
integrados de manufatura. 1999. 104 f. Dissertação (Mestrado em Engenharia Mecânica) –
Escola de Engenharia de São Carlos, Universidade de São Paulo, São Carlos.
OMOKAWA, R. Utilização de sistemas PDM em ambientes de engenharia simultânea: o
caso de uma implantação de uma montadora de veículos pesados. 1999. 152 f. Dissertação
(Mestrado em Engenharia Mecânica) – Escola de Engenharia de São Carlos, Universidade de
São Paulo, São Carlos.
PELTONEN, H. Concepts and na implementation for product data management. 2000.
188 f. Tese (Doutorado em Ciência da Computação) - Helsinki University of Technology,
Helsinki.
POPOV, K; GRIGOROVA, K; TSANEVA, D. Product characteristics determining
engineering processes. [Sl]: CONFLOW, 1998. (Document n. CONFLOW.97.12) [a]
POPOV. K; GRIGOROVA. K. Capabilities of the process modeling tool. [Sl]: CONFLOW,
1998. (Document n. CONFLOW.97.07) [b]
POPOV, K; TSANEVA, D; KARADJOV, K; GRIGOROVA, K; HRISTOVA, P.
Mechanisms required to enable concurrent engineering workflow. [Sl]: CONFLOW,
1998. (Document n. CONFLOW.98.01) [c]
ROZENFELD, H; SILVA, S. L. Uma proposta de gestão do conhecimento no
desenvolvimento de novos produtos. disponível em:
<http://www.competenet.org.br/evento/henrique_rozenfeld.pdf> Acesso em: 10 out 2001.
ROZENFELD, H. Modelo de referência para o desenvolvimento integrado de produtos.
(CD ROM). In: Encontro Nacional de Engenharia de Produção, 17, 1997. Gramado. P 1-8.
SAP AG. SAP R/3: Online Documentation.Walldorf. SAP AG, 2001: 1 CD-ROM.
114
SCHÜTZER, K; SOUZA, N, L. Implantação do digital mockup na indústria
automobilística: conquistando vantagens competitivas. In: Anais do 1º Congresso Brasileiro
de Desenvolvimento do Produto, Belo Horizonte, Ago. 1999, pp. 305-314.
SHENEIDER, H.M. A engenharia simultânea e a sua importância competitiva,
Tecnologia Hoje. Disponível em: <http://www.ietec.com.br/techoje> Acesso em: 17 jul 2001.
SLACK, N; CHAMBERS, S; HARRISON, A; JOHNSON, R; HARLAND, C.
Administração da produção. Atlas, 1999, 728p. 3a ed.
SMARTEAM: SmarTeam administrator’s guide : Tel Aviv. SmarSmart Solutions Ltd. 2000.
1 CD-ROM. Version 4.0.
SMARTERP: Administrator’s Guide For Smarterp: Tel Aviv. SmarSmart Solutions Ltd.
2000. 1 CD-ROM. Version 4.0.
SOUZA, N. L. Definição de critérios para identificação do perfil tecnológico de empresas
para implementação do modelo virtual do produto. 2001. 112 f. Dissertação (Mestrado em
Engenharia de Produção) – Faculdade de Engenharia Mecânica e de Produção, Universidade
Metodista de Piracicaba, Santa Bárbara do Oeste.
SVENSSON, D. MALMQVIST, J. Strategies for product structure management in
manufacturing firms. Proceedings of DETC’00, Paper No DET2000/CIE-14607, Baltimore,
MA, USA. 2000.
TATE, D. A Roadmap for decomposition activities, theories and tools for system design.
Ph.D. Thesis, Dept. of Mechanical Engineering, Massachusetts Institute of Technology,
Cambridge, MA USA. February 1999. Disponível em: <axiom.mit.edu/Thesis/dtate/ch1.pdf>
Acesso em: 10 jul 2001.
TOMAZETI, C. A; SERPA, J. A; VIGOTO, R. G. O passado e presente da engenharia
simultânea. Disponível em: <http://www.nupes.cefetpr.br>. Acesso em: 12 jun 2001.
115
VALERIANO, D. L. Gerência em projetos – pesquisa, desenvolvimento e engenharia.
Makron Books do Brasil editora Ltda, 1998.
VIGOLO, R. G; JÚNIOR, A. S; TOMAZETI, C. A. A engenharia simultânea aplicada em
nível organizacional. Disponível em: <http://www.nupes.cefetpr.br>. Acesso em: 12 jun
2001.
ZANCUL, E.S; ROZENFELD, H. Sistematização das funcionalidades de um sistema ERP
que apóiam o processo de desenvolvimento de produtos. In: XV Congresso Brasileiro De
Engenharia Mecânica, Anais, 1999. [a]
ZANCUL, E. S; GUERRERO, V; ROZENFELD, H; OLIVEIRA, C.B.M. Análise das
abordagens de integração entre sistemas PDM e ERP, VIII Congresso e Exposição
Internacional da Tecnologia da Mobilidade – SAE BRASIL 99. São Paulo, 1999. [b]
ZANCUL, E. S; ROZENFELD, H. Engenharia simultânea. Disponível em:
<http://www.numa.org.br>. Acesso em 27 nov 2001.
WHEELER, T. O manual dos sistemas abertos. Editora Campus, 1994, 364p.
116
APÊNDICE A – DESCRIÇÃO DO SISTEMA SAP R/3
Neste apêndice é descrito o sistema ERP utilizado na elaboração das análises.
A.1 - Sistema SAP R/3
O aplicativo SAP R/3 é um software de ERP desenvolvido pela empresa SAP AG,
composto de diversos módulos interligados entre si através de um banco de dados único. Seus
diferentes módulos englobam todas as áreas empresariais, tais como materiais, administração
e planejamento da produção, recursos humanos, contabilidade e finanças entre outros. Em
função das funcionalidades de PDM e MRP se apresentarem sobrepostas, o aplicativo PDM
do SAP R/3 funciona como administrador de documentos, classificação, administração de
estrutura do produto e administração de projeto (MÁRKUS, 1998).
O sistema SAP R/3 apresenta uma estrutura cliente/servidor, com a qual cada usuário
tem acesso ao servidor de aplicações como um cliente através de um software de interface
com o usuário chamado de SAPgui (Grafical User Interface).
A figura A.1 apresenta a estrutura modular do sistema SAP R/3.
117
Figura A.1 – Estrutura modular do sistema SAP R/3.
A.1.1 - Cadastro de material
O registro mestre de material é a principal fonte de dados específicos de material de
uma empresa. É usado em todos os componentes do Sistema Logística R/3 (SAP AG, 2001).
Os dados contidos no registro mestre de material são necessários para muitas funções
do Sistema de Logística R/3, como, por exemplo:
• Dados de compras para processamento de pedidos;
• Dados de administração de estoques para lançamentos de movimentos de mercadorias
e administração do inventário;
• Dados de contabilidade para avaliação de material nos movimentos de mercadorias ou
na revisão de faturas;
R/3
Cliente/Servidor
Vendas eDistribuição
Administraçãode Materiais
Planejamentoda Produção
Administraçãoda Qualidade
Manutenção
RecursosHumanos
ContabilidadeFinanceira
Controladoria
Tesouraria e Investimentos
Sistemasde Projetos
Workflow
SoluçõesSetoriais
118
• Dados de planejamento de materiais para MRP.
O mestre de material é projetado para refletir a estrutura da empresa de modo a
permitir que o gestor administre os dados de material de forma centralizada, sem
sobrecarregar os conjuntos de dados com informações redundantes (SAP AG, 2001).
A figura A.2 apresenta à tela de apresentação do cadastro de um material no mestre de
material do sistema SAP R/3.
Figura A.2 – Cadastro de material
119
A.1.2 - Administração de documentos no sistema SAP R/3
O sistema SAP R/3 provêm maneiras de conexão de seus documentos com
documentos criados por outros aplicativos. Estes documentos são chamados arquivos
originais e o formato do arquivo de um documento original é igual ao original (.doc, .dwg,
.igs, stp).
Ao conectar um documento como um arquivo original, é necessário inserir o tipo de
aplicação e o local onde este arquivo será armazenado assim como seu caminho (path).
Porém, o sistema não consegue identificar se o arquivo sofreu alguma alteração. Isto significa
que o usuário deve alterar o status do documento manualmente, de forma a identificar cada
alteração. A figura A.3 apresenta a tela de criação de um documento no sistema SAP R/3.
120
Figura A.3 – Criação de documento no sistema SAP R/3.
Normalmente os arquivos são armazenados no próprio servidor de aplicação. Se o
documento necessitar ser retido para fins de segurança da documentação, eles podem ser
armazenados no banco de dados do sistema SAP R/3. A figura A.4 apresenta o fluxo dos
dados de engenharia no sistema SAP R/3.
121
Figura A.4 – Representação do fluxo dos dados de engenharia no sistema SAP R/3.
A.1.3- Conexão com sistema SAP R/3
O sistema SAP R/3 padrão apóia conexões e vínculos de chamadas para muitos
objetos como o mestre de material, estrutura dos componentes, mestre de equipamentos e os
registros informativos dos documentos, tornando possível o acesso a todos esses objetos. Isso
significa, por exemplo, que um desenhista pode exibir o cadastro mestre de material e pode
inserir um documento, ou seja, anexar um arquivo de CAD no sistema SAP R/3 de forma a
vincular uma dependência de autorização para este arquivo. Porém, há duas exigências que
devem ser atendidas: é necessário registrar este documento no mestre do sistema e conectar os
documentos que irão utilizar-se deste objeto. Isso deve ser definido na configuração do
aplicativo ERP (BANCROFT, 1997).
Desenhosem CAD
ProgramasNC
DescriçõesTécnicas
Documentostexto
Arquivos de programas
Documentos
SAP
Objetos SAP
• Mestre de Materiais• Mestre de Equipamentos• …• …
122
A.1.4 - Interface do sistema SAP R/3 com sistemas de CAD e PDM
Se um aplicativo CAD/PDM é conectado ao SAP R/3 por meio de uma interface, é
possível criar fora de um sistema de CAD/PDM todos os itens e conjuntos que são gerados no
mestre de material e registro destes documentos, como por exemplo, o número do item (a
interface vai se dar do sistema ERP para o CAD/PDM). Além disto é possível construir a
estrutura do produto existente no cadastro mestre de material comumente chamada de conta
de material.
Alguns fabricantes de software desenvolvem soluções específicas de interface entre os
sistemas CAD e PDM com sistemas ERP (no caso SAP R/3). Um desses provedores é a
empresa Eigner+Partner, que provêem interfaces para os aplicativos CAD comerciais
AutoCAD e PRO/Engineer, permitido que os aplicativos CAD executem as seguintes
funções no sistema SAP R/3:
• Administração de atributos do sistema SAP R/3;
• Administração do registro mestre de material;
• Criação, alteração e visualização de contas de material;
• Administração de documentos e informações do registro de documentos;
• Administração de informações de manutenção da planta;
• Acesso ao sistema SAP R/3 por meio de correio eletrônico.
A interface do sistema SAP R/3 com sistemas de CAD/PDM pode ser feita das
seguintes maneiras segundo SAP AG (2001):
• Interface por diálogo;
123
• Interface por diálogo através de comunicação por função remota - RFC (Remote
Function Call).
A.1.5 - Interface por diálogo
A interface de comunicação com sistemas CAD suporta a transferência de dados
bidirecionais em tempo real entre o sistema externo (CAD) e o sistema SAP R/3. Neste caso,
o aplicativo SAP R/3 funciona como um servidor.
A interface inclui os seguintes componentes:
• Integração com as bibliotecas funcionais do sistema SAP R/3;
• Plataforma de hardware para os programas de interface com o sistema SAP R/3.
Antes de acessar a API individual que habilita o funcionamento do sistema externo, a
biblioteca de função R/3-CAD deve ser conectada à aplicação de engenharia (CAD).
A figura A.5 representa a transferência dos dados entre as duas plataformas.
124
.
Figura A.5 - Transferência de dados entre as duas plataformas
A.1.5.1 - Programa de Interface com o sistema SAP R/3 - API
O programa de interface CAD-ERP realiza as seguintes funções:
• Recebe comandos do sistema externo (CAD), reconhece os dados solicitados pelo
banco de dados do sistema SAP R/3, e converte esses dados para o formato requerido
para a transferência. Estes dados são então transferidos ao sistema externo. Se os
dados forem alterados no sistema externo, deve-se alterar também os dados no sistema
SAP R/3;
R/3
Cliente/Servidor
Vendas eDistribuição
Administraçãode Materiais
Planejamentoda Produção
Administraçãoda Qualidade
Manutenção
RecursosHumanos
ContabilidadeFinanceira
Controladoria
Tesouraria e Investimentos
Sistemasde Projetos
Workflow
SoluçõesSetoriais
Programa deInterface
R/3 - CAD
CAD
PDM
GIS
SAP – CAD
Biblioteca
De
Funções
Programade aplicaçãoEspecífico
Porta deEntrada
doSoftware
Programade aplicaçãoEspecífico
Programade Aplicação
Específico
Plataforma R/3 Plataforma de Engenharia
CAD- A
CAD-B
CAM
125
• Confere os dados recebidos do sistema externo para consistência, transfere os dados
para a transação no sistema SAP R/3 na forma apropriada para que o banco de dados
seja atualizado;
• Assegura que um dado seja alterado se o banco de dados do sistema SAP R/3 for
alterado como resultado dos dados transferidos do sistema externo.
A.1.5.2 - Biblioteca de funções
A biblioteca de funções R/3 é um conjunto de sub-programas escritos na linguagem de
programação C.
Cada sub-programa especifica uma função quando se comunica com o programa de
interface do aplicativo SAP R/3. Antes que o usuário possa ter acesso às funções individuais
do sistema, a biblioteca de funções deve ser instalada na aplicação de engenharia. Para fazer
isto, um programa com a aplicação específica para cada sistema CAD/PDM comercial deve
ser instalado na aplicação.
A maioria das funções pode ser configurada de acordo com as exigências do usuário.
Alguns exemplos de funções são:
• Conectar o sistema SAP R/3;
• Desconectar o sistema SAP R/3;
• Criar cadastro de material;
• Reservar número de material;
• Alterar cadastro de material;
• Visualizar cadastro de material;
• Criar registro de documento;
126
• Alterar registro de documento;
• Criar BOM;
• Alterar BOM;
• Visualizar BOM.
O formato dos dados transferido entre o sistema CAD/PDM e o sistema SAP R/3 são
definidos em tabelas no sistema SAP R/3. Essas tabelas devem ser transferidas ao sistema
CAD/PDM de forma que os dados enviados estejam no mesmo formato como os dados
devem ser recebidos. Os dados neste caso só são enviados quando uma alteração ocorrer na
tabela. A função responsável por este acionamento, se chama função de sincronização e
normalmente ocorre sem o acionamento do usuário (automaticamente).
Durante a instalação do aplicativo SAP R/3, o administrador do sistema (usuário)
pode definir quais dados serão transferidos e em qual ordem, assim como o tamanho dos
campos a serem preenchidos.
A.1.6 – Interface por chamada de funções remotas – RFC
Ao conectar uma interface por chamada de funções remotas – RFC (Remote Function
Call), é possível acessar as transações do aplicativo SAP R/3 diretamente de uma aplicação
técnica (aplicativo CAD/PDM, por exemplo).
Uma vez que a conexão é estabelecida, e a RFC esteja funcionando, podem ser feitas
comunicações a partir de sistemas externos. Esta conexão é estabelecida por uma seção de
SAPgui ativa, podendo utilizar-se também das telas apresentadas pelo SAPgui para a
comunicação com o SAP R/3.
127
Uma série inteira de módulos de função pode ser acessada através de uma RFC. Para
isto foram desenvolvidas funções especiais para a interface com sistemas CAD e PDM. A
maioria destes módulos habilita o acesso a transações do sistema SAP R/3 facilmente, e
permite a transferência de dados.
Se for preciso, pode-se ainda usar funções API elaboradas especialmente para se
conectar com sistemas CAD diretamente.
As RFC funcionam apoiando as transações de diversos módulos do ERP para as
seguintes áreas de aplicação:
• Administração de documentos;
• Cadastro de materiais;
• Registros no plano mestre de alterações;
• Fluxo de documentos por correspondência eletrônica;
• Manutenção de plantas industriais (registro mestre de equipamentos, localização
funcionais, notificações de manutenção e ordens de manutenção).
A principal função da RFC é localizar objetos no sistema através de seus códigos, por
classes, parâmetros do sistema SAP R/3, estrutura do produto e local onde é usado.
Quando se esta trabalhando com uma conexão via RFC, existe a possibilidade de se
usar os API de interface por diálogo. Isso permite a transmissão de dados para o sistema R/3.
A tabela A.1 apresenta de forma comparativa as formas de integração prevista no
sistema SAP R/3.
128
Interface por diálogo
Interface por função de
comunicação remota – RFC
Diálogo
Permitido pelas aplicações
externas
Feito através das próprias telas
do sistema
Acesso ao sistema
As funções do sistema SAP
R/3 estão ligadas às
aplicações do servidor do
banco de dados externo
O sistema SAP R/3 e as
aplicações externas são
ativados alternadamente
Comunicação
Através de API que fazem a
comunicação entre o sistema
SAP R/3 e as bibliotecas de
funções CAD
Através de funções de
comunicação remota - RFC
Transferência de dados
Por seqüência de dados
Com estrutura de dado em RFC
(campos, estruturas, tabelas)
Dificuldade da interface
Usuário definido por APIs
Integração por diálogo RFC
Tabela A.1 – Comparação entre os tipos de interface de integração.
A.1.7 - Visualização de documentos CAD
No sistema SAP R/3, a visualização dos desenhos em duas e três dimensões são
realizadas diretamente de um terminal onde esteja instalado o SAPgui. Esta capacidade está
disponível em uma versão do aplicativo chamada “mySAP.com” que permite ainda a
utilização de alguns comandos básicos para uma melhor visualização (zoom, rotação,
conversão de arquivo para padrões gráficos, etc.).
129
O sistema SAP R/3 recebe a informação do produto de um sistema de CAD
diretamente ou indiretamente através dos arquivos CAD vinculados a sistemas PDM. Nos
aplicativos CAD, os projetistas criam os modelos em três dimensões para a construção das
montagens, definindo a relação espacial de cada componente. O processo de conversão de
arquivos provido pelo SAP R/3 faz com que os correspondentes modelos em três dimensões
sejam armazenados em seu banco de dados. Para a integração do sistema CAD neste caso,
cada documento (arquivo) é tratado individualmente pelo sistema ERP, pois como o sistema
não é capaz de distinguir os documentos, deve-se tomar o cuidado de anexar o documento
correspondente na estrutura do produto.
130
APÊNDICE B – DESCRIÇÃO DO SISTEMA SMARTEAM
Neste apêndice é descrito o sistema PDM utilizado na elaboração das análises.
B.1 - Sistema SmarTeam
SmarTeam é um aplicativo PDM desenvolvido pela empresa Solution Ltda que pode
ser totalmente customizado, sendo destinado a suprir diversas necessidades das empresas de
engenharia. SmarTeam provê um ambiente que auxilia e melhora o controle de arquivos,
controle de versão, localização, e outras atividades mais específicas.
O sistema SmarTeam habilita a completa administração da fase de projeto, desde o
primeiro projeto criado até o seu lançamento final para produção. Isto é feito através de
características que habilitam a criação e a edição, provendo a visualização e o controle de
qualquer tipo de documento com completa precisão e segurança. Todas informações
relacionadas ao produto são mantidas e administradas pelo SmarTeam. O software de PDM
não projeta o produto, mas disponibiliza um ambiente de apoio ao projeto de produtos em
todos seus aspectos e fases.
SmarTeam é um aplicativo PDM que apresenta funcionalidades de criar, editar,
visualizar e controlar desenhos de CAD. Permite também a administração dos desenhos e de
referencias externas, como também montagens e seus componentes (SMARTEAM, 2001).
A estrutura dos dados é organizada por projetos criados, de maneira a ordenar e
permitir uma maior facilidade de visualização e localização dos documentos. Assim, os
projetos são a classe mais alta na estrutura dos dados do SmarTeam. Cada projeto apresenta
sua própria árvore de documentos onde são exibidos todos os desenhos e documentos
131
associados com o projeto em uma estrutura hierárquica. Assim quando um novo arquivo é
criado, seu nome aparece como um objeto na estrutura hierárquica apropriada com relações de
dependência do tipo pai e filho.
As informações referentes ao arquivo são visualizadas e editadas nas chamadas
“folha”, com o perfil do arquivo. Cada página da folha de perfil representa uma tabela
respectiva a:
• Folha de perfil: exibe as propriedades gerais do arquivo;
• Folha de anexos: exibe os objetos que estão anexados a este arquivo (exemplo: onde é
usado);
• Folha de notas: exibe todas as notas escritas pelos usuários, permitindo acrescentar
novas notas;
• Revisão: exibe o histórico de revisões de cada arquivo, permitindo a visualização do
estado atual de revisão;
• Visualização: permite visualizar o arquivo (desenho).
B.1.1 - Arquitetura do sistema SmarTeam
A arquitetura do SmarTeam é baseada em API’s que suportam os conceitos básicos
das operações de PDM. Sua arquitetura básica é baseada no conceito de objetos orientados. O
modelo dos dados é montado em uma hierarquia de classes que podem ser modificadas pelo
usuário (SMARTEAM, 2001).
O ambiente de trabalho do SmarTeam é o Windows. O Software é desenvolvido
usando técnicas de codificação através de objetos orientados para o desenvolvimento de
ferramentas para o Windows.
132
Basicamente, os dados administrados pelo SmarTeam podem ser armazenados de
uma maneira distribuída. Porém, os meta-dados devem ser contidos em um único banco de
dados.
B.1.2 - Administração de estrutura de produto
As estruturas dos produtos podem ser importadas dos sistemas CAD, criadas ou
modificadas pelo SmarTeam. Sua integração com os sistemas CAD (via API’s) suporta o
envio das estruturas de forma bi-direcional e apóia a configuração da estrutura de conjuntos.
O SmarTeam administra todos os serviços de transporte de arquivos de um sistema
para outro. Traduz vários formatos como, por exemplo, o IGES que podem ser executados por
programas externos, sendo possível a geração de várias extensões, por exemplo, DWG, que é
uma extensão bastante comum aos aplicativos de CAD.
O enfoque tecnológico é baseado na arquitetura Microsoft e Java, que torna o
ambiente de trabalho bastante familiar aos usuários.
133
APÊNDICE C – INTERFACE DE INTREGRAÇÃO ENTRE O SISTEMA
SMARTEAM E SISTEMAS ERP
Neste apêndice é descrito a software de interface entre o sistema SmarTeam e
sistemas ERP.
C.1 - Software de interface SmartGateway
Para acionar as APIs do sistema SAP R/3, o sistema SmarTeam utiliza-se de um
software de interface opcional ao SmarTeam que forma um vínculo intrínseco entre o PDM
e o ERP chamado de SmartGateway, da mesma maneira que um vínculo intrínseco existente
entre a fase de projeto e a fase de produção de um produto.
Os dados necessitam ser enviados para o sistema ERP e ser inseridos em locais
apropriados (em campos específicos na tela do sistema). Devido a diferenças em
terminologias, até mesmo de idiomas, esta correspondência não é sempre clara, embora já
esteja prevista pelos sistemas através de APIs.
A relação exata entre os dados do SmarTeam que são de “preocupação” do ERP, e a
atual versão no ERP dos dados enviados pelo SmartGateway, definem uma série de
caminhos que mapeiam os dados dos itens do SmarTeam com os itens do ERP. Às vezes,
estes caminhos não seguem uma lógica para seus dados do tipo um para um. Teoricamente,
também pode ser um para muitos, muitos para um e muitos para muitos.
Os dados do PDM são enviados para o ERP em eventos e certas ações pelo próprio
usuário do PDM. As ações do usuário, conseqüentemente causam outras ações no sistema
PDM. Adequadamente estas ações resultantes são chamadas de eventos dentro do sistema
134
SmarTeam. Isto a primeira vista, parece ser um caso de transferência de dados que acontece
imediatamente após o evento acontecer neste PDM, sendo uma lei simples de causa e efeito.
O SmartGateway permite um mapeamento abrangente podendo ser programado para ser
acionado, quando um evento do PDM esta pendente e não esta pronto para ser enviado do
sistema PDM para o sistema ERP, durante este evento de pré-evento. (Muitas vezes os
eventos do PDM são demorados para permitir que os dados sejam enviados
intencionalmente).
Esta metodologia interna deve ser customizada pelos administradores do sistema,
decidindo quais dados devem ser transferidos por quais usuários entre estes dois sistemas
(PDM e ERP) e em que momento isto deve ser feito, tendo em mente que tipo de impacto isto
pode causar no planejamento das atividades industriais.
A relação entre os dados do PDM e dos dados do ERP que definem quais itens dos
dados do PDM será inseridos no ERP são chamados de mapeamento de atributos.
A determinação sobre quando um dado particular deve ser transferido, como resultado
de um evento do PDM, e quais operações devem ser acionados no ERP para direcionar estes
dados no ERP, é chamada de mapeamento de operações.
Usando um sistema de mapeamento de operações presente no SmartGateway, o
administrador também pode definir que tipo de resposta o PDM apresentará ao usuário
quando for executada uma operação com o ERP. Assim, é apresentada uma janela do
mapeamento das operações para o gerenciamento da integração, de uma forma geral
atribuindo implicitamente o mapeamento de operação. Por exemplo, pode-se observar na lista
do mapeamento de operações que o arquivo de um desenho em um PDM é um objeto
mapeado pelo ERP e um arquivo que representa um desenho de conjunto no PDM é visto
como estrutura de itens no sistema ERP.
135
C.1.1 – Modelo de comunicação da integração
Normalmente, se há muitos usuários PDM em uma única instalação, todos os usuários
(clientes) comunicam-se com um único banco de dados, através de API residente na máquina
do usuário em uma rede de computadores.
Por outro lado, a integração com o ERP, ocorre através de um programa que ativa este
cliente, delegando a maioria do trabalho de sincronização do servidor do ERP a partir de
comandos específicos do usuário. Deste modo, o cliente precisa notificar ao servidor os
eventos que aconteceram no PDM. Por exemplo, um evento de liberação notificará o servidor,
que por sua vez irá informar o ERP que algo deve ser feito. Os usuários do PDM comunicam-
se com o sincronizador do servidor ERP através da tecnologia de modelos de distribuição de
componentes objetos DCOM (Distributed Component Object Model). O sincronizador do
servidor ERP então se comunica com adaptadores ERP específicos que se comunicam com
sistemas ERP particulares, como o sistema SAP R/3 em exemplo.
Na Figura C.1, pode-se observar o modelo do sincronizador do servidor ERP.
Observa-se que o sincronizador do servidor ERP opera em três níveis. O módulo que faz a
comunicação entre o cliente do PDM e passa esta informação para o módulo de “execução”.
O módulo de execução, então notifica o sistema ERP do que aconteceu. Uma vez que vários
sistemas ERP utilizam métodos diferentes de comunicação, torna-se necessário um adaptador
exclusivo para se comunicar com cada sistema ERP. Adicionalmente, há um adaptador
genérico, que não se comunica com nenhum sistema ERP específico. As informações e
comandos do PDM são escritos em um formato de arquivo texto e usa o formato XML.
Assim, qualquer sistema (ERP) que consiga analisar o conteúdo deste tipo de arquivo, pode
fazer uso destas informações.
136
Figura C.1 – Sincronização do servidor ERP.
Os sistemas PDM e ERP armazenam objetos primários em seus bancos de dados. Nos
sistemas PDM, os objetos apontados são arquivos e outros dados de engenharia, enquanto nos
ERP, os objetos apontam ‘materiais’ (no conceito de ERP, material representa um item, e não
necessariamente o material do qual o item é feito.). O SmartGateway une os objetos destes
dois sistemas.
Os materiais nos sistemas ERP têm um código único de identificação, também
chamado de número do material. Quanto este número é inserido no PDM como o número do
material correlato, este código, auxilia para o mapeamento dos objetos entre os sistemas.
Geralmente, os atributos de classe do sistema PDM pode ser acessado para o campo de
tipo de objeto no ERP, neste caso, o mapeamento entre o atributo do sistema PDM e o campo
do sistema ERP é referido com mapeamento de atributos. Este mapeamento é estabelecido no
mapeamento de objetos mencionado acima.
PDM – Cliente 1
AplicaçõesOracle SAP
AdaptadorXML
AdaptadorOracle
PDM – Cliente 2
ERPGenérico
ArquivoXML
ERP Sincronizador de Servidor
AdaptadorSAP
COM
HTTP RFC
DCOM
ClientesPDM
SincronizaçãoServidor
ServidoresERP
137
Os eventos do sistema PDM podem localizar operações automaticamente no sistema
ERP, de maneira semelhante ao processo de mapeamento de operações. Por exemplo, uma
operação de alteração no sistema PDM pode ativar a criação de um objeto no sistema ERP
como resultado de um mapeamento de operação. A criação de um objeto no sistema ERP
estabelece o mapeamento de objetos através do mapeamento de atributos pré-definidos.
O SmartGateway é dividido em vários componentes, onde cada um cumpre um papel
diferente. Todos estes componentes são genéricos no SmartGateway com exceção do
adaptador da Biblioteca Dinâmica de Ligação - DLL (Dynamic Link Library) que tem que ser
configurado para um sistema de ERP particular.
Para que a interface se estabeleça, os seguintes componentes devem ser ativados
(SMARTERP, 2000):
• Gerenciador de Integração ERP: de maneira a permitir a administração de serviços e
mapear os atributos do sistema PDM para os campos do sistema ERP é utilizado o
gerenciador de integração ERP, este gerenciador, é uma ferramenta administrativa que
é usada para configurar o componente de sincronização do servidor. O Gerente de
Integração ERP permite o administrador do PDM configurar as várias ações
disponíveis ao sincronizador, como traçar para cada uma destas ações um evento
específico do sistema PDM, assim como pode ser usado para traçar atributos e anexar
estruturas de um evento do sistema PDM. Na maioria das vezes que um usuário do
PDM estiver inconscientemente (por engano) usando o ERP, ele será notificado das
alterações e que um objeto esta sendo criado no ERP. Ao salvar um arquivo do CAD,
ele pode não saber que esta enviando informações para o PDM e de lá para o ERP.
Isto é comum no caso de novos usuários. Assim, o administrador deve configurar o
sistema ligando as ferramentas de integração;
138
• Mecanismos do ERP: para que o PDM permita o uso do SmartGateway, o banco de
dados do PDM precisa conter as classes internas requeridas pelo SmartGateway. Para
que seja possível a integração com sistemas ERP específicos, o PDM deve prover
atributos especiais que lhe permitam acrescentar o ERP. Assim, o SmartGateway
classifica e soma atributos facilmente através do mecanismo chamado SmartWizard;
• Sincronizador: o sincronizador é o componente que notifica o servidor quando um
evento acontece dentro SmarTeam. Adequadamente, este componente serve como um
filtro para o SmartGateway. Ele é configurado para acionar uma ação específica
quando um determinado evento acontecer. Assim, uma ação pode ser pedir um pouco
mais de informação de um adaptador de ERP específico, para “rodar” uma rotina, ou
não fazer nada. Dependendo do qual evento aconteceu, o sincronizador decidirá qual
ação irá executar;
• O Adaptador de ERP: adaptador é um tipo de biblioteca que define a interface que
precisa ser implementada pelo adaptador. O sincronizador e o adaptador precisam de
acesso para esta informação. O adaptador é o vínculo final entre SmarTeam e o
sistema de ERP. Esta biblioteca é específica a um sistema de ERP e configurado com
códigos de utensílios para este propósito;
• Utilitários do Adaptador: a união dinâmica das bibliotecas contém uma implementação
de métodos de ajuda (help), usada por ambos, o sincronizador e o próprio adaptador.
Por exemplo, as implementações de uma interface para objetos de ERP residem neste
adaptador.
Por ser integrado a um outro sistema, detalhes específicos da necessidade do sistema
devem ser levados em conta em sua comunicação. O adaptador ERP deve ser projetado
139
pensando nisto, e é então muito específico a cada sistema ERP. Um adaptador diferente tem
que ser “escrito” para cada sistemas de ERP a ser utilizado.
O aplicativo SmartGateway é capaz de mapear os objetos, e então estabelecer a
comunicação entre o SmarTeam com qualquer outro sistema de banco de dados.
Especificamente, além de sua habilidade para integrar a sistemas de ERP, pode integrar
também para outro sistemas de PDM.
FOLHA DE REGISTRO DO DOCUMENTO
1. CLASSIFICAÇÃO/TIPO
TM
2. DATA
28 Maio 2002
3. DOCUMENTO N°
CTA/ITA-IEM/TM-002/2002
4. N° DE PÁGINAS
139 5. TÍTULO E SUBTÍTULO: Análise das funcionalidades de integração entre sistemas CAD/PDM e ERP.
6. AUTOR(ES):
Marcos Leandro Simonetti
7. INSTITUIÇÃO(ÕES)/ÓRGÃO(S) INTERNO(S)/DIVISÃO(ÕES): Instituto Tecnológico de Aeronáutica. Divisão de Engenharia Mecânica-Aeronáutica –
ITA/IEM
8. PALAVRAS-CHAVE SUGERIDAS PELO AUTOR:
Integração; CAD; PDM; ERP 9.PALAVRAS-CHAVE RESULTANTES DE INDEXAÇÃO:
Desenvolvimento de produtos; Integração de sistemas; Planejamento de processos automatizados por computador; Programas de aplicação (computadores); Engenharia de produção. 10. APRESENTAÇÃO: X Nacional Internacional
ITA, São José dos Campos, 2002. 139p.
11. RESUMO:
O atual processo de globalização inseriu as empresas em novos desafios. Um desses desafios, fortemente relacionado com a estratégia competitiva das empresas é o de desenvolver produtos cada vez melhores com tempo de desenvolvimento (lead times) e custos cada vez menores.
As empresas têm investido grande quantidade de recursos em aplicativos computacionais que auxiliam o processo de desenvolvimento de novos produtos, como os aplicativos de projeto auxiliado por computador – CAD – sistemas de gestão de dados do produto – PDM – e sistemas de gestão corporativos – ERP.
Estes aplicativos atualmente são utilizados de maneira isolada dentro das empresas, de maneira a formar ilhas de automação entre os usuários destes sistemas.
Este trabalho visa apresentar as principais dificuldades e vantagens na utilização de soluções integradas no processo de desenvolvimento de produtos, assim como as análises técnicas do processo de integração entre os sistemas CAD/PDM com os sistemas ERP.
Para demonstrar o processo de integração foram analisadas as potencionalidades de integração dos sistemas computacionais do Centro de Competência de Manufatura, e suas funcionalidades integráveis.
12. GRAU DE SIGILO: (X ) OSTENSIVO ( ) RESERVADO ( ) CONFIDENCIAL ( ) SECRETO