APLICABILIDADE DE SISTEMAS ERP NO PROCESSO DE DESENVOLVIMENTO DE PRODUTOS: UMA PROPOSTA DE ANÁLISE

Transcrição

1 APLICABILIDADE DE SISTEMAS ERP NO PROCESSO DE DESENVOLVIMENTO DE PRODUTOS: UMA PROPOSTA DE ANÁLISE Eduardo de Senzi Zancul, Eng. Henrique Rozenfeld, Dr-Ing. Núcleo de Manufatura Avançada Escola de Engenharia de São Carlos - USP Av. Dr. Carlos Botelho São Carlos SP ezancul@sc.usp.br / roz@sc.usp.br ABSTRACT: Product development process has not been considered part of the scope of almost all ERP (Enterprise Resource Planning) implementations. This happens, most of the times, because ERP potentialities to product development process has not been fully known and explored. Also, there is a great difficulty in managing problems like overlapping functions with engineering systems and integration issues. This paper presents an approach to analyze the ERP applicability in product development process. This analysis should identify the product development process activities that can be supported by ERP systems, determine the need for complementary engineering systems and specify integration points. These information can than be used to assist product development process ERP implementations. KEYWORDS: ERP Systems, Product Development, Concurrent Engineering RESUMO: O processo de desenvolvimento de produtos, na maioria das vezes, ainda não é considerado no escopo de implantação de sistemas ERP (Enterprise Resource Planning). Isso ocorre principalmente porque o potencial do ERP para o desenvolvimento de produtos não é conhecido e explorado. Existe, também, uma grande dificuldade em resolver os problemas de sobreposição de funcionalidades e de integração com os sistemas específicos de engenharia. Este artigo apresenta uma proposta para análise da aplicabilidade de sistemas ERP no processo de desenvolvimento de produtos. A aplicação dessa análise deve permitir a identificação das atividades de desenvolvimento de produtos que podem ser suportadas por sistemas ERP, a determinação da necessidade de sistemas complementares e a especificação dos pontos de integração entre o ERP e os sistemas complementares. Essas informações poderão ser utilizadas para auxiliar as empresas na implantação de sistemas ERP no processo de desenvolvimento de produtos.

2 1 INTRODUÇÃO Com o surgimento dos sistemas ERP (Enterprise Resource Planning), as iniciativas de reengenharia de processos de negócio passaram a enfatizar o projeto de processos que, além de atenderem aos objetivos estratégicos das organizações, sejam adequados às funcionalidades existentes nesses sistemas. Diversas metodologias de implantação de sistemas de informação foram adaptadas para apoiar a reestruturação de processos de negócio e a implantação de sistemas ERP. Além disso, novas abordagens específicas para a implantação de sistemas ERP surgiram, como, por exemplo, as metodologias desenvolvidas pelos fornecedores de sistemas e por firmas de consultoria. No entanto, geralmente, essas metodologias são aplicadas somente aos processos operacionais mais padronizados e estruturados, tais como: vender e distribuir, gerenciar materiais, produzir, gerenciar recursos financeiros e físicos. Na maioria das vezes, o processo de desenvolvimento de produtos não é considerado. Isso ocorre principalmente porque o potencial do ERP para o desenvolvimento de produtos não é conhecido e explorado. Existe, também, uma grande dificuldade em resolver os problemas de sobreposição de funcionalidades e de integração com os sistemas específicos de engenharia, como os sistemas CAD (Computer Aided Design), CAE (Computer Aided Engineering), CAPP (Computer Aided Process Planning), CAM (Computer Aided Manufacturing) e PDM (Product Data Management). Deve-se observar que a redução do ciclo de vida e o aumento da diversificação dos produtos faz com que as decisões tomadas na engenharia passem a ter um forte impacto nos processos logísticos e no custo das empresas. Isto evidencia que a integração entre desenvolvimento de produtos e outros processos, através do ERP, pode agilizar a tomada de decisões mais acertadas. Além disso, os fornecedores de sistemas ERP estão aumentando a abrangência dos sistemas com a inclusão de novas funcionalidades. Uma tendência é a incorporação de funcionalidades características de sistemas PDM (gerenciamento de documentos, workflow, gerenciamento de configurações, integração com sistemas CAD, entre outras) que podem ser utilizadas pelo desenvolvimento de produtos. Ao mesmo tempo, pode-se verificar que os sistemas ERP estão se tornando a espinha dorsal (backbone) dos sistemas de informação das empresas. Dessa forma, a utilização de sistemas de

3 engenharia (CAD/CAE/CAPP/CAM/PDM) deve ser analisada a partir do potencial e dos requisitos de integração dos sistemas ERP. Para que as empresas possam aumentar a aderência dos sistemas ERP no processo de desenvolvimento de produtos, é necessário, inicialmente, determinar sistematicamente as potencialidades e dificuldades da aplicação do ERP nesse processo. Este artigo apresenta uma proposta para análise da aplicabilidade de sistemas ERP no processo de desenvolvimento de produtos. A aplicação dessa análise deve permitir a identificação das atividades de desenvolvimento de produtos que podem ser suportadas por sistemas ERP, a determinação da necessidade de sistemas complementares e a especificação dos pontos de integração entre o ERP e os sistemas complementares. Essas informações poderão ser utilizadas para auxiliar as empresas na implantação de sistemas ERP no processo de desenvolvimento de produtos. Para isso, inicialmente, o processo de desenvolvimento de produtos é estudado. São apresentadas as características do desenvolvimento simultâneo de produtos e as limitações atuais dos ambientes de Engenharia Simultânea. Em seguida, são destacadas as principais características dos sistemas ERP. É apresentada, então, a proposta para a análise da aplicabilidade de sistemas ERP no processo de desenvolvimento de produtos. Por fim, são feitas considerações finais e apresentados as etapas futuras que visam a aplicação da proposta descrita. 2 O PROCESSO DE DESENVOLVIMENTO DE PRODUTOS 2.1 CARACTERÍSTICAS DO DESENVOLVIMENTO DE PRODUTOS SEQÜENCIAL Tradicionalmente, o desenvolvimento de produtos é constituído por uma seqüência ordenada de atividades, realizadas por vários departamentos da empresa. Nessa abordagem, uma atividade só é iniciada quando a atividade anterior é concluída. A Figura 1 demonstra as atividades realizadas, por diversos departamentos, em um típico desenvolvimento de produto seqüencial. A Figura 1 ilustra também como as diferentes visões descritivas das diversas unidades organizacionais levam à segmentação dos dados em bases de dados independentes.

4 Por exemplo, a descrição geométrica do produto é armazenada na base de dados do sistema CAD, utilizado pelo Departamento de Projeto. A estrutura de produto (Bill of Materials) e os planos de processo macro, gerados na fase seguinte, são armazenados na base de dados do sistema de planejamento da produção utilizado pelo Departamento de Fabricação (SCHEER, 1998). Idéia Requisitos Conceituação Projeto Planejamento Detalhamento Equipamentos BOM de Produção Planos Processo Programas CN Planos Inspeção Custeio Redução Torque... BD Marketing BD CAD BD Equipamentos BD PCP BD CN BD Qualidade BD Finanças Marketing Vendas Depto. de Projeto Ferramentaria Desenvolvimento do Produto Depto. de Fabricação Figura 1 - Desenvolvimento de produtos seqüencial (adaptado de SCHEER, 1998) Qualidade Custos Diversos problemas são decorrentes dessa forma de organização do desenvolvimento de produtos e da segmentação dos dados do produto em bases de dados independentes. Segundo PRASAD (1996), a premissa de que uma fase só possa ser iniciada quando a fase anterior for finalizada e aprovada, resulta em ciclos de desenvolvimento de produtos excessivamente longos. Além disso, devido à característica seqüencial, uma parte significativa do custo do produto (de 50% a 80%) é definida pelo Departamento de Projeto (pela especificação de soluções de projeto, materiais, tolerâncias e decisões de make or buy ), antes mesmo da análise pelo Departamento de Fabricação. Apesar de uma parte significativa do custo do produto ser definida pelo Departamento de Projeto, as decisões não podem ser tomadas com o auxílio de estimativas de custo. Isso ocorre porque a estrutura de produto e os planos de processo macro, necessários para o cálculo do custo do produto, ainda não foram gerados pelo Departamento de Fabricação. Além desses problemas do desenvolvimento de produtos seqüencial, PRASAD (1996) cita o projeto de produtos inadequados para a produção, a especificação de tolerâncias muito apertadas que resultam em operações de fabricação desnecessárias e a dificuldade de reutilização dos equipamentos de produção disponíveis (ferramental, dispositivos, entre outros).

5 2.2 O PROCESSO DE DESENVOLVIMENTO SIMULTÂNEO DE PRODUTOS Para minimizar os problemas do desenvolvimento seqüencial, muitas empresas passaram a considerar o desenvolvimento de produtos como um processo de negócio e adotaram a filosofia de Engenharia Simultânea. Um processo de negócio pode ser definido como um fenômeno que ocorre dentro das empresas. Ele contém um conjunto de atividades, associadas às informações manipuladas, utilizando os recursos e a organização da empresa. Forma uma unidade coesa e deve ser focalizado em um tipo de negócio, que normalmente está direcionado a um determinado mercado/cliente, com fornecedores bem definidos (ROZENFELD, 1997). Diversas definições de Engenharia Simultânea podem ser encontradas na literatura (CHIUSOLI, 1996). Essas definições podem variar de visões mais amplas, considerando-a como uma filosofia de gestão do desenvolvimento de produto, até outras mais específicas que a definem como um método. Segundo AMARAL (1997), o aspecto central em todas elas é o foco nas vantagens da integração de todas as atividades de desenvolvimento de produtos aliada à sobreposição das fases desse processo. Neste trabalho, a Engenharia Simultânea é empregada seguindo os enfoques mais amplos, sendo definida como a filosofia de atuação no processo de desenvolvimento de produtos, visando um aumento de qualidade do produto, uma diminuição do ciclo de desenvolvimento e conseqüente diminuição dos custos. Essa filosofia toma como base a sinergia entre os agentes do processo, que devem trabalhar em uma equipe multi-funcional formada por pessoas de diversas áreas da empresa. O trabalho dessa equipe deve ser suportado por métodos e técnicas integrados, tais como: QFD (Quality Function Deployment), FMEA (Failure Mode and Effect Analysis), Taguchi, entre outras (ROZENFELD, 1998). A Figura 2 descreve como todos os aspectos descritivos do produto podem ser gerados simultaneamente e detalhados no decorrer das fases de desenvolvimento. Na fase inicial, por exemplo, o plano de processo especifica somente a unidade da empresa em que o produto será fabricado. Isto determina a tecnologia que será empregada na fabricação, fornecendo um parâmetro dos custos envolvidos (SCHEER, 1998). Estimativas de custo mais precisas podem ser realizadas no decorrer do desenvolvimento do produto, à medida em que o plano de processo é detalhado e as operações, o seu sequenciamento, as especificações de ferramental, entre outras informações, são definidas.

6 A aplicação da Engenharia Simultânea no processo de desenvolvimento de produtos requer que todas as pessoas envolvidas tenham acesso aos dados do produto. Esse requisito significa que os dados do produto devem estar localizados em uma base de dados de descrição do produto ao invés de estarem divididos em diferentes sistemas que, além da separação física, referem-se a diferentes fases do processo de desenvolvimento de produtos (Scheer, 1998). Planejamento Conceituação Projeto Detalhamento Idéia Geometria Redução Torque... Equipamento BOM Planos Processo Planos Inspeção Custeio $ & $ $ 420 Planos de Manutenção Planos de Reciclagem Desenvolvimento Simultâneo do Produto Descrição Integrada do Produto Figura 2 - Processo de desenvolvimento simultâneo de produtos (adaptado de SCHEER, 1998) No entanto, a complexidade da implantação de uma infra-estrutura de tecnologia de informação desse tipo, que suporte a Engenharia Simultânea, é um obstáculo para a obtenção dos resultados esperados. 2.3 SITUAÇÃO ATUAL DOS AMBIENTES DE ENGENHARIA SIMULTÂNEA De acordo com GASCOIGANE (1995), até o momento a Engenharia Simultânea foi baseada na implantação e utilização de sistemas CAD/CAE/CAM e MRP (Material Resource Planning) e na reestruturação do processo de desenvolvimento de produtos para possibilitar a utilização das funcionalidades oferecidas por essas novas ferramentas. Diversos problemas fazem com que essa abordagem ainda seja insuficiente para satisfazer os requisitos do desenvolvimento simultâneo de produtos, entre os quais pode-se citar:

7 A utilização de ferramentas CAD/CAPP/CAM não integradas possibilita a automação de algumas atividades do desenvolvimento de produtos, mas os dados do produto continuam sendo armazenados em bases de dados segmentadas e, na maioria das vezes, as atividades são realizadas individualmente pelo departamentos (PRASAD, 1996). A integração desses sistemas é uma tarefa extremamente complicada devido à incompatibilidade dos dados manipulados (GASCOIGNE, 1995; HAMERI & NIHTILÄ, 1998). A intensa utilização de sistemas de engenharia não integrados leva então à proliferação descontrolada dos dados de produto, dificultando a localização dos dados gerados, o controle de acesso e o gerenciamento de versões (GASCOIGNE, 1995; PELTONEN et al, 1996; OMOKAWA, 1999). A estimativa de custos, nas fases iniciais do desenvolvimento de produtos, geralmente não leva em consideração padrões de cálculo de custo da organização. Os sistemas de engenharia não estão integrados com os sistemas de gerenciamento da produção, dificultando a transferência dos dados do produto necessários à fabricação (estrutura de produto, planos de processo, entre outros) (BOURKE, 1996; KEMPFER, 1998). Alguns desses problemas estão sendo resolvidos através da implantação de sistemas PDM e adoção da norma STEP (Standard for the Exchange of Product Model Data). Os sistemas PDM são considerados viabilizadores da Engenharia Simultânea por possuírem funcionalidades que apoiam o gerenciamento de todos os dados do produto ao longo do ciclo de vida (CIMDATA, 1996; DICKERSON, 1997). A norma STEP estabelece padrões de representação que possibilitam a integração entre sistemas de engenharia (BRADHAM, 1998). Paralelamente, um grande número de empresas tem implantado sistemas ERP para integrar seus processos de negócio, de forma que a superação das limitações atuais dos ambientes de Engenharia Simultânea só será possível se todas essas iniciativas forem consideradas em conjunto.

8 3 OS SISTEMAS ERP 3.1 CARACTERÍSTICAS DOS SISTEMAS ERP Os sistemas ERP foram concebidos para resolver o problema de fragmentação de informações manipuladas por diferentes sistemas e armazenadas em bases de dados independentes. Na maioria das grandes empresas, vários sistemas foram desenvolvidos e implantados para atender aos requisitos específicos de unidades organizacionais ou funções (tais como unidades de negócio, departamentos e cargos). Os dados manipulados por esses sistemas são armazenados em bases de dados independentes. Essa fragmentação da informação dificulta a adoção de uma abordagem por processos de negócio, uma vez que, geralmente, um processo de negócio envolve mais de um departamento da empresa. Por exemplo, os Departamento de Vendas, Produção e Finanças participam de um processo de venda de um produto. O Departamento de Vendas precisa saber se o item que será vendido está disponível no estoque ou quando ele será produzido, a fim de informar o prazo de entrega para seu cliente. Para isso necessita de dados do Departamento de Produção. Após a venda, e Departamento de Finanças atualiza, entre outros, os dados de contas a receber. Os sistemas ERP procuram resolver esse problema utilizando uma base de dados única. Esses sistemas são compostos por uma base de dados central e por módulos que suportam diversas atividades dos processos de negócio das empresas. Os dados utilizados pelos módulos são armazenados na base de dados central para serem manipulados por outros módulos. Quando uma nova informação é manipulada por um módulo e armazenada, as informações relacionadas são atualizadas (DAVENPORT, 1998). Os sistemas ERP possuem módulos que abrangem o seguinte escopo: operações e gerenciamento da cadeia de suprimentos, gestão financeira e contábil e gestão dos recursos humanos (CORRÊA et al, 1997). Tais módulos suportam as atividades de diversos processos de negócio das empresas, entre os quais, vender e distribuir, produzir, desenvolver e gerenciar recursos humanos e gerenciar recursos financeiros e físicos. Esses processos de negócio podem ser representados pelos modelos de referência dos sistemas ERP (KELLER & TEUFEL, 1998).

9 3.2 MODELO DE REFERÊNCIA DOS SISTEMAS ERP Para descrever um processo de negócio, o modelo de referência deve representar as atividades realizadas, o fluxo de informações, os elementos organizacionais responsáveis e os recursos utilizados. O grau de detalhamento e o formalismo de representação do modelo dependem de sua utilização. Um modelo de referência é um modelo que pode ser usado como base para o desenvolvimento ou avaliação de modelos específicos. Modelos específicos podem ser derivados de modelos de referência pré definidos (VERNADAT, 1996). De acordo com o seu conteúdo, os modelos de referência podem ser classificados em: modelos de referência do setor, modelos de referência da empresa ou modelos de referência dos sistemas de informação (KIRCHMER, 1998; KELLER & TEUFEL, 1998). Os modelos de referência para um setor representam processos de negócio gerais aplicáveis a um setor da indústria. Esses modelos procuram considerar as melhores práticas para o setor, podendo ser utilizados como ponto de partida em diversas abordagens de melhoria nas empresas. Já os modelos de referência das empresas representam os processos de negócio específicos de uma empresa. Esses modelos podem descrever a situação atual das empresas (modelos as-is ) ou representar uma situação futura desejada (modelos to-be ). Os modelos de referência dos sistemas de informação são uma descrição dos processos e soluções disponíveis nos sistemas (CURRAN & KELLER, 1998). Dessa forma, os modelos de referência dos sistemas ERP descrevem os processos de negócio que são suportados por esses sistemas. Tais modelos podem ser utilizados na implantação de sistemas ERP, por exemplo, auxiliando na definição do escopo de implantação e apoiando a especificação do modelo to-be das empresas. A abordagem de utilização desses modelos depende da metodologia de implantação empregada. 3.3 UTILIZAÇÃO DO MODELO DE REFERÊNCIA NA IMPLANTAÇÃO DE SISTEMAS ERP O modelo de referência do sistema ERP assume diferentes graus de importância e pode ter várias utilizações dependendo da metodologia de implantação empregada. Pode-se citar, como exemplo, a utilização do modelo de referência do ERP em duas diferentes metodologias de implantação: Business Process Oriented Implementation of Standard Software e AcceleratedSAP.

10 A primeira fase da metodologia de implantação Business Process Oriented Implementation of Standard Software (KIRCHMER, 1998), visa a obtenção de um modelo to-be para a empresa, independentemente do sistema ERP que será implantado. A elaboração desse modelo parte da definição dos objetivos estratégicos da organização e pode ser auxiliada por modelos de referência do setor. Nessa primeira fase, o modelo da empresa não deve ser muito detalhado. Modelos de referência do ERP são utilizados somente na segunda fase, apoiando o detalhamento do modelo da empresa obtido na fase anterior. Assim, procura-se garantir que os requisitos específicos das organizações sejam considerados. Na terceira e última fase da metodologia, o sistema ERP é customizado para suportar o modelo de referência da empresa. A metodologia AcceleratedSAP (ASAP), desenvolvida pela SAP, visa possibilitar implantações rápidas do sistema SAP R/3 (SAP, 1998). Apesar de se referir a um sistema específico, essa metodologia pode ser extrapolada para outros sistemas ERP. Nela, o modelo de referência do sistema ERP é utilizado como ponto de partida para o desenho do modelo to-be da organização. Alguns requisitos específicos podem, então, ser adicionalmente especificados no modelo fornecido. A grande vantagem dessa abordagem é a garantia de que o modelo to-be será suportado pelo sistema ERP. 4 UMA PROPOSTA PARA ANÁLISE DA APLICABILIDADE DE SISTEMAS ERP NO PROCESSO DE DESENVOLVIMENTO DE PRODUTO 4.1 APLICAÇÃO DE SISTEMAS ERP NO PROCESSO DE DESENVOLVIMENTO DE PRODUTOS Independentemente da metodologia de implantação empregada, geralmente, o escopo de implantação de sistemas ERP não abrange o processo de desenvolvimento de produtos. Isso ocorre principalmente porque o potencial do ERP para o desenvolvimento de produtos não é conhecido e explorado. Além disso, existe uma grande dificuldade em definir a sobreposição de funcionalidades e resolver os problemas de integração com os sistemas específicos de engenharia. Os sistemas ERP não possuem todas as funcionalidades necessárias para atender aos requisitos das atividades do processo de desenvolvimento simultâneo de produtos. Os fornecedores de sistemas ERP tendem a desenvolver soluções genéricas que atendam aos requisitos de vários processos em

11 uma ampla gama de empresas. Já os ambientes de Engenharia Simultânea têm requisitos muito específicos que são em parte atendidos pelos sistemas de engenharia (CAD/CAE/CAPP/CAM/PDM). Apesar disso, várias funcionalidades dos sistemas ERP, espalhadas pelos seus módulos, suportam algumas das atividades do processo de desenvolvimento simultâneo de produtos. Em ambientes nos quais é vantajoso ter ferramentas específicas, um processo de integração deve ser considerado (JARDIM-GONÇALVES et al., 1997). Segundo CARUSO (1998), os sistemas ERP estão se tornando a espinha-dorsal (backbone) dos sistemas de informação das empresas. Dessa forma, a integração dos demais sistemas de informação que suportam o processo de desenvolvimento de produtos deve ser analisada a partir do potencial dos sistemas ERP. 4.2 OBJETIVO O objetivo da Proposta para Análise da Aplicabilidade de Sistemas ERP no Processo de Desenvolvimento de Produtos é sistematizar o estudo detalhado da aderência de sistemas ERP no processo de desenvolvimento de produtos, através da: Identificação das atividades do processo de desenvolvimento de produtos que podem ser suportadas pelas funcionalidades de sistemas ERP. Identificação das lacunas não atendidas pelos sistemas ERP. Determinação da necessidade de sistemas complementares. Especificação dos pontos de integração entre sistemas ERP e sistemas complementares. O resultado dessa análise deverá poder ser utilizado para auxiliar as empresas na implantação de sistemas ERP no processo de desenvolvimento de produtos. 4.3 REQUISITOS Para que o objetivo estabelecido possa ser atingido, foram determinados os requisitos essenciais para a Análise da Aplicabilidade de Sistemas ERP no processo de Desenvolvimento de Produtos: Ser independente do sistema ERP selecionado para o estudo. Ser adequada a vários formalismos de representação de modelos de referência. Possibilitar a comparação entre modelos de referência do processo de desenvolvimento de produtos e modelos de referência de sistemas ERP.

12 Possibilitar o estudo detalhado das funcionalidades de sistemas ERP selecionadas. Possibilitar a análise das funcionalidades de sistemas complementares de engenharia (CAD/CAE/CAPP/CAM/PDM). Considerar os aspectos relativos a integração de sistemas de informação. Permitir ampla aplicação prática. 4.4 UMA PROPOSTA PARA ANÁLISE DA APLICABILIDADE DE SISTEMAS ERP NO PROCESSO DE DESENVOLVIMENTO DE PRODUTOS A concepção da Proposta para Análise da Aplicabilidade de Sistemas ERP no Processo de Desenvolvimento de Produtos procurou satisfazer os requisitos especificados anteriormente. A Figura 3 apresenta uma visão geral das etapas da Análise. Obtenção dos Modelos de de Referência Comparação dos Modelos Comparação dos Modelos Estudo do ERP Protótipo Estudo do ERP Protótipo Estudo dos Sistemas de de Engenharia Determinação dos dos Pontos de de Integração Consolidação dos Resultados Figura 3 Proposta para Análise da Aplicabilidade de Sistemas ERP no Processo de Desenvolvimento de Produtos Na primeira etapa, Obtenção dos Modelos de Referência, são obtidos o modelo de referência do processo de desenvolvimento de produtos e o modelo de referência do sistema ERP. Considera-se aqui que tais modelos já existam e estejam disponíveis. Caso os modelos não sejam descritos

13 segundo o mesmo formalismo de representação, uma das representações deve ser adotada e o outro modelo deve ser adequado a ela. Essa uniformização é necessária para a segunda fase, Comparação dos Modelos. Nessa etapa, os modelos do processo e do sistema são comparados. Para isso, o grau de detalhamento utilizado é superficial, sendo suficiente a representação das atividades e do fluxo de informações. A comparação permite o agrupamento inicial das atividades em duas classes: atividades que podem ser suportadas por transações do sistema ERP ( atividades ERP ) e lacunas não apoiadas pelo ERP ( lacunas ERP ). As atividades que foram agrupadas na fase anterior são estudadas detalhadamente na terceira e quarta etapas, respectivamente: Estudo do ERP Protótipo e Estudo dos Sistemas de Engenharia. Na terceira etapa, os requisitos específicos das atividades ERP são verificados em um protótipo de um sistema ERP. Nesse caso, são utilizadas representações mais detalhadas dos modelos de referência. Paralelamente, na quarta etapa, são estudadas as funcionalidades existentes nos sistemas complementares de engenharia. As atividades do modelo do processo que podem ser apoiadas por esses sistemas são agrupadas na classe atividades sistemas engenharia. Uma sobreposição de funcionalidades é caracterizada quando uma mesma atividade do modelo do processo pertence às classes atividades ERP e atividades sistemas engenharia. A interatividade desse processo é caracterizada, na Figura 3, pelas setas ligando a terceira e quarta etapas. Um atividade classificada inicialmente com atividade ERP, por exemplo, pode ser alterada para lacuna ERP caso a verificação detalhada do ERP indique que os requisitos específicos não são atendidos. Na quinta etapa, Determinação dos Pontos de Integração, são verificadas as possíveis formas de integração entre o sistema ERP e os sistemas complementares de engenharia. São utilizados modelos detalhados representando os dados manipulados pelos sistemas. Finalmente, na Consolidação dos Resultados, é gerado um modelo de referência do processo de desenvolvimento de produtos especificando os recursos (sistema ERP e sistemas complementares) que apoiam cada uma das atividades. A seguir, cada uma das etapas da Análise são descritas detalhadamente. São apresentados os objetivos de cada etapa e as atividades realizadas.

14 4.4.1 OBTENÇÃO DOS MODELOS DE REFERÊNCIA O objetivo da primeira etapa da Análise é preparar as informações necessárias para as próximas fases. Para isso, são realizadas as seguintes atividades: Seleção do sistema ERP. Obtenção do modelo de referência do sistema ERP. Obtenção do modelo de referência do processo de desenvolvimento de produtos. Padronização do formalismo de representação dos modelos. Definição dos sistemas complementares de engenharia. Obtenção de modelos de referência, manuais e catálogos dos sistemas de engenharia. Um sistema ERP deve ser escolhido para a análise. O modelo de referência do sistema selecionado pode ser obtido com o fornecedor do sistema ou ser adquirido de firmas de consultoria. Nessa fase, também é selecionado um modelo de referência para o processo de desenvolvimento de produtos. Esse modelo pode ser um modelo to-be do desenvolvimento de produtos de uma empresa específica ou um modelo mais genérico como, por exemplo, de um setor da indústria. Para que a comparação entre os elementos do modelo seja possível, na segunda etapa da Análise, os modelos devem seguir o mesmo formalismo de representação. Dessa forma, se a representação não for a mesma, um dos formalismos é adotado e o outro modelo é adequado a ele. Nesse momento, pode-se iniciar a seleção dos sistemas de engenharia que serão analisados. Se a Análise for aplicada a uma empresa específica, são considerados todos os sistemas de engenharia que são utilizados, além de versões mais atuais desses sistemas e novos sistemas que podem vir a ser utilizados. Nem sempre esses sistemas são representados por modelos de referência. Por isso, deve-se procurar obter informações adicionais que descrevam as funcionalidades como, por exemplo, manuais e catálogos. Se possível, licenças temporárias de demonstração são solicitadas aos fornecedores COMPARAÇÃO DOS MODELOS O objetivo da segunda etapa da Análise é identificar as atividades de desenvolvimento de produtos que serão analisadas detalhadamente no sistema ERP protótipo.

15 A identificação das atividades é feita comparando-se os modelos de referência do sistema ERP e do processo de desenvolvimento de produtos. O procedimento de comparação utilizado, adaptado de KIRCHMER (1998), é apresentado na Figura 4. São necessárias as seguintes atividades: Comparação dos modelos de referência. Compilação dos resultados. O nível de detalhamento dos modelos, nessa fase, é superficial, bastando a representação das atividades e do fluxo de informações. Segundo KIRCHMER (1998), o procedimento de comparação é dificultado pelas diferenças na terminologia empregada e no nível de detalhamento dos modelos de referência. Como a descrição dos modelos não é muito detalhada, pode-se definir uma terminologia padrão ou adotar a terminologia empregada em um dos modelos (Figura 4). Devido aos diferentes níveis de detalhamento dos modelos, uma ou mais atividades do modelo do processo podem ser relacionadas a uma mais funcionalidades descritas no modelo do sistema. Definição da terminologia Modelo de de referência do do desenvolvimento de de produtos Comparação dos modelos Modelo de de referência do do sistema ERP atividades ERP lacunas ERP Figura 4 - Procedimento de comparação dos modelos de referência (adaptado de KIRCHMER, 1998) A comparação permite a identificação das atividades que, de acordo com os modelos, podem ser suportadas por transações do sistema ERP. Essas atividades são agrupadas na classe atividades ERP. As outras atividades, não apoiadas pelo ERP, são chamadas de lacunas ERP.