UM ESTUDO SOBRE O MAPEAMENTO
ENTRE AS CLASSES DO ERP5 E A
LINGUAGEM CIMOSA
Angela Teresa Rochetti (UNESP) angela.rochetti@yahoo.com.br Renato de Campos (UNESP) rcampos@feb.unesp.br Roberto Giamei Galera (UNESP) roberto_galera@uol.com.br
Resumo
Para o aumento da capacidade gerencial e competitiva das empresas um dos principais aliados são os chamados Sistemas Integrados de Gestão ou Enterprise Resource Planning (ERP). Porém, para as pequenas e médias empresas este tipo de sistema pode ser inviável devido ao seu alto custo que envolve consultoria, parametrização e implantação. Devido a isto os ERPs livres de código aberto têm ganhado uma aceitação cada vez maior, oferecendo vantagens como diminuição dos custos e o acesso ao código, tal como o sistema ERP5. Mas para usufruir destas vantagens são necessários métodos adequados para o levantamento de requisitos de negócios, e ferramentas de modelagem e de desenvolvimento apropriados. O objetivo principal deste artigo é comparar e mapear os construtores da linguagem de modelagem de empresa de CIMOSA (Computer Integrated Manufacturing Open System Architecture) com as classes do ERP5, visando facilitar a passagem do modelo de requisitos de negócios de empresas para o modelo de desenvolvimento ou de customização deste sistema.
Abstract
To increase the management capacity and improve businesses one of the main allies are the Enterprise Resource Planning (ERP). But for small and medium enterprises this type of system can be impracticable because of its high cost which involves consulting, customization and deployment. Because of this the free open source ERP has gained an increasing acceptance, offering advantages such as lower costs and access to the code, as the system ERP5. But to enjoy these benefits are necessary methods for the business requirements definition, and appropriates modeling and development tools. The main objective of this article is to compare and map the enterprise modeling language of
IV CNEG 2
CIMOSA (Computer Integrated Manufacturing System Open Architecture) to the classes of ERP5, to facilitate the passage of the model of the business requirements for the development or customization model of the system.
Palavras-chaves: ERP5, CIMOSA, MODELAGEM DE EMPRESA, BUSINESS MODELING
IV CNEG 3
1. INTRODUÇÃO
No atual contexto econômico mundial, altamente competitivo e globalizado é importante entender uma empresa como um sistema aberto que interage com o ambiente externo e frente a isso novas habilidades gerenciais são exigidas. Muitas empresas têm alterado suas estratégias organizacionais a fim de se tornarem capazes de atuar nesse ambiente. Mesmo para uma empresa que vende e produz um item numa remota cidade do interior, sua gerência tem que ser tão eficiente quanto a mais eficiente empresa de seu setor (HEBERKORN, 2003)
Para o aumento da capacidade gerencial e competitiva, a empresa deve ter uma visão global e integrada e para isso é necessário que a mesma seja representada por um modelo, o qual servirá como referência para os seus elementos quer sejam pessoas ou sistemas, fornecendo apoio para uma avaliação apurada dos recursos no processo de negócios.
Entre outros fatores a complexidade dos produtos e serviços oferecidos requer um adequado gerenciamento dos processos de negócio envolvidos e para que processos de negócio sejam integrados ou controlados por computador, é necessário que estes sejam formalizados, assim como os objetos utilizados, manuseados ou processados por eles. Além dos processos, o mesmo deve acontecer com as informações utilizadas ou geradas, os recursos requeridos, e também as responsabilidades e autoridades necessárias para o seu controle (VERNADAT, 1996).
A correta identificação e modelagem dos processos de negócio, além de descrever a estrutura e comportamento da empresa e auxiliar na integração dos processos, é a base para adoção e implantação de novos sistemas de informação, os quais permitem tratar e transmitir as informações necessárias entre o sistema físico e o sistema de gestão da empresa.
Com relação aos sistemas de informação os sistemas integrados de gestão (ERP) existem em diferentes níveis e valores, sendo que no caso das pequenas e médias empresas a sua adoção pode ser inviável devido ao seu alto custo que envolve consultoria, parametrização e implantação. Devido a isto os ERPs livres de código aberto têm ganhado uma aceitação cada vez maior, oferecendo vantagens como diminuição dos custos e o acesso ao código.
Segundo Carvalho e Campos (2007), para os sistemas de ERP de código aberto, a falta de métodos adequados e de ferramentas de modelagem e desenvolvimento podem inviabilizar
IV CNEG 4 as vantagens oferecidas pela disponibilidade do código, como no caso do ERP5, um ERP de código aberto.
A arquitetura do ERP5 incorpora desde sua concepção conceitos avançados como banco de dados orientados a objetos e sistema de gestão de conteúdo, sincronização de dados entre diferentes instalações, tendo ainda um método claro de modelagem de processos e conseqüentemente de geração de código fonte (SMETS-SOLANES; CARVALHO, 2003)
Com relação a modelagem de processos a arquitetura CIMOSA(CIM Open System Architecture) é considerada uma das mais completas metodologias para a modelagem de empresas. Conceitualmente CIMOSA fornece um conjunto pré-definido de classes genéricas de objetos de empresas representados através de gabaritos que é a base de sua linguagem. Estes gabaritos são “modelos” padronizados de descrições para cada construtor do modelo da empresa.
É grande a necessidade de um linguagem mais adequada para a modelagem de processos, que facilite a análise dos requisitos e a conseqüente transformação de um modelo de requisitos de empresa no software, mais especificamente o software ERP5.
Frente a essa necessidade, este artigo pretende comparar e mapear os construtores de linguagem CIMOSA e as classes do ERP5 visando sistematizar a passagem do modelo de requisitos de uma empresa, supondo utilizar a linguagem CIMOSA, para o desenvolvimento e customização do ERP5.
Neste artigo será abordado nas próximas seções: os sistemas ERPs, o desenvolvimento de sistemas, o sistema ERP5, a linguagem de modelagem CIMOSA, comparação de CIMOSA e as classes do ERP5 e finalmente as considerações finais para este trabalho.
2. METODOLOGIA
Com relação a natureza trata-se de uma pesquisa aplicada, pois o objetivo deste trabalho será gerar conhecimentos para a solução dos problemas relacionados com a implantação de ERPs.
Quanto a forma de abordagem do problema trata-se de uma pesquisa qualitativa pois a fonte de coleta de dados será o próprio sistema de gestão empresarial ERP5, no qual o processo e o seu significado são os focos principais de abordagem.
IV CNEG 5 Do ponto de vista dos objetivos essa pesquisa é exploratória por proporcionar a familiaridade com o problema, que é a utilização da modelagem do negócio para a devida implantação do ERP5, o qual será operado na prática.
Com relação aos procedimentos técnicos a pesquisa é predominantemente bibliográfica e de aspectos experimental para a avaliação das variáveis e do objeto de estudo da proposta.
3. SISTEMAS ERP
Conhecidos como Sistemas Integrados de Gestão ou Enterprise Resource Planning, têm sido amplamente utilizados por organizações de todos os porte, mas principalmente pelas empresas de médio a grande porte. Segundo Davenport (1998) apud Gonçalves et al. (2004) a implantação destes sistemas é bastante complexa e dispendiosa e nem sempre atende as expectativas do cliente.
A comercialização dos ERPs normalmente é feita na forma de pacotes de software, isto é, em módulos para que a implantação possa ser feita de acordo com as necessidades dos clientes. O investimento no processo de implantação de cada módulo é sempre elevado e o resultado nem sempre é o esperado (GONÇALVES et al., 2004).
Normalmente os ERPs trazem embutidos em suas rotinas o que são chamadas pelos desenvolvedores de sistemas de “melhores práticas”, que geralmente forçam as empresas que adotam um ERP incorporar essas práticas do sistema em seu negócio. Para Davenport (1998), isso significa “colocar a empresa no sistema empresarial” podendo acarretar que processos característicos da organização, sejam trocados por processos genéricos de um ERP e com isso diminuindo a vantagem competitiva relacionada às características intrínsecas da organização.
As customizações são admitidas nos pacotes ERPs, mas segundo Hong (2002) apud Gonçalves et al. (2004), são desencorajadas pelos desenvolvedores temendo a degradação da performance e integridade do sistema, além de elevar o custo de sua implantação.
4. DESENVOLVIMENTO E ADAPTAÇÃO DE SISTEMAS
Segundo Sommerville (2003) existem muitos processos de software diferentes, mas as atividades comuns entre eles são:
IV CNEG 6 Especificação de software – também conhecida como engenharia de requisitos, na
qual se levantam as funcionalidades e restrições em sua operação;
Projeto e especificação de software – é o processo de conversão de uma especificação de sistema em um sistema executável;
Validação do Software – garantir que o software faz o que o cliente deseja;
Evolução do Software – o software precisa evoluir para atender às necessidades mutáveis dos clientes.
Em se tratando de ERPs surge a necessidade do correto levantamento dos requisitos a fim de identificar os processos de negócio da organização antes da implantação, cujo objetivo é avaliar se os processos devem ser modificados, modernizados ou mantidos (MENDES; ESCRIVÃO, 2002). Nesse contexto entra a modelagem dos processos de negócios, na qual o modelo deve representar a realidade expressa em uma linguagem ou formalismo (AZEVEDO; CAMPOS, 2002).
Muitas são as técnicas, formalismos ou linguagens utilizadas para a modelagem de processos, uma das candidatas pode ser a adoção do Processo Unificado (UP- Unified Process), por ser uma metodologia estabelecida especificamente para o desenvolvimento de software. Jacobson et al. (1999) apresentam as origens do UP desde o processo Objectory (com primeira versão em 1987) passando pelas contribuições do Processo Rational Objectory (em 1997) até o Processo Unificado da Rational – RUP (KRUCHTEN, 2003 apud CAMPOS, 2006).
O propósito do UP, como qualquer outro processo de desenvolvimento de sistemas, é determinar um conjunto de atividades necessárias para transformar requisitos em sistemas de software. As suas fases são: Levantamento de Requisitos, Análise e Projeto, Implementação, Teste, e Implantação, além de estar diretamente ligado com a Linguagem de Modelagem Unificada (UML), a qual não é uma linguagem de computador nem um processo, mas sim uma linguagem de comunicação que servirá para comunicar a representação de um software em diversos estágios (MEDEIROS, 2004).
IV CNEG 7
5. ERP5
O projeto do sistema ERP5 segue a linha de sistemas livres de código aberto, também conhecido como open source. Este projeto está sendo desenvolvido por um grupo de empresas e instituições de ensino e pesquisa da França e do Brasil entre outros. O ERP5 foi criado para ser um framework de desenvolvimento bem flexível para aplicações empresariais e promete ser uma solução de alta tecnologia para as pequenas e médias empresas sem resultar a altos custos de mudanças e manutenção (SMETS-SOLANES, 2003).
Trata-se de um sistema avançado que oferece solução para empresas baseado no open source da plataforma Zope (http://www.zope.org), escrito na linguagem Python (http://www.python.org). Dentre os componentes chave do Zope usados no ERP5, existe ainda o banco de dados do objeto (ODB), o sistema de workflow (DCWorkflow): o Content Management Framework (CMF) que é uma infra-estrutura para adicionar ou remover contextos e o Zope Page Templates (ZPT) baseada no XML.
De acordo com Carvalho e Monnerat (2007) o sistema possui características importantes como:
Multi: o sistema é multi-usuário, multi-organização, multi-linguagem, multi-moeda, multi-custo e multi-cenário;
Meta: oferece vários níveis de detalhes para um mesmo processo de gestão;
Distribuído: utiliza mecanismos de sincronização avançados que permitem a distribuição e compartilhamento de dados sem a necessidade de conexão permanente com a rede;
Baseado em objetos: o emprego de um conjunto de objetos permite modelar e implementar sistemas complexos de suporte a decisão;
Livre: toda a informação gerada, tecnologias e metodologias desenvolvidas, são livremente disponibilizadas pelo site do projeto.
O modelo incorpora desde a sua concepção um banco de dados orientados a objetos, sistema de gestão de conteúdo e sincronização de dados entre diferentes instalações, tendo ainda um método claro de modelagem de processos e geração de código fonte.
Segundo Carvalho e Monnerat (2007), o ERP5 é um modelo abstrato o suficiente para envolver todos os componentes básicos de negócios devido aos cinco conceitos abstratos os quais serão a base do processo empresarial, conforme ilustra figura 1.
IV CNEG 8 Resource: descreve o recurso utilizado para realizar o processo empresarial, tais como
características individuais, produtos, máquinas, etc.
Node: entidade empresarial que recebe e envia os „resource‟. Pode estar relacionado com uma entidade física (tais como instalações industriais) ou abstrata (como uma conta bancária). Metanodes são „nodes‟ que contém outros „nodes‟, como empresas. Path: descreve como o „node‟ acessa o „resource‟ de outro „node‟. Também pode ser o
processo de troca que define como um cliente obtém um produto de um fornecedor. Movement: descreve a movimentação dos „resources‟ entre os „nodes‟ de um
determinado momento e por um período de tempo. Por exemplo, uma alteração do estoque de matéria prima de uma fábrica. Os „movements‟ são a realizações dos „paths‟.
Item: uma instância do „resource‟. Por exemplo, um Driver de CD é um „resource‟ do computador, enquanto o CD driver part number 23E982, é um item dele.
Figura 1- Principais Classes do ERP5. Fonte: (CARVALHO; MONNERAT, 2007).
O ERP5 pode associar qualquer coisa a uma de suas categorias, por exemplo uma categoria de recursos (tais como serviços, matéria-prima, habilidade ou dinheiro) ou uma categoria de organizações (tais como um grupo de empresas, um grupo de pessoas ou uma cadeia de varejo) (SMETS-SOLANES; CARVALHO, 2003).
O sistema é capaz de proporcionar a customização administrando benefícios computacionais. A noção de variação permite que um único descritor recurso represente milhões de variações de um determinado produto sem criar milhões de registros em um banco de dados e sem ter que criar um número de produto para cada alteração de um mesmo produto.
O ERP5 possui um Framework, constituído de um conjunto de pastas sob forma de objetos e seus atributos, onde cada uma detém documentações auto-suficientes e eventuais
IV CNEG 9 subpastas, podendo ser exportado e importado de uma pasta. Consequentemente, cada documento representa um objeto raiz em uma pasta com todos os seus sub-objetos bem como todos os objetos os quais podem relacioná-lo. A figura 2 mostra o framework do ERP5.
Figura 2 - Framework do ERP5.
Fonte: (SMETS-SOLANES; CARVALHO, 2003)
É importante entender que o ERP5 é um programa centrado em documentos „document-driven‟, e por isso usa o Zope e seus Content Management Framework (CMF) que originalmente foi desenvolvido como uma ferramenta de desenvolvimento da web que fornece opções para gerenciar os documentos desta. Com o tempo, percebeu-se que poderia ser usado como um incremento para qualquer tipo de aplicativo baseado na web.
Conforme visto até aqui a implementação de ERP5 está baseado no modelo abstrato, mas do ponto de vista interface com o usuário um sistema real ERP5 é um banco de dados de documentos que contém uma coleção de pastas com as instruções do modelo empresarial (SMETS-SOLANES, 2008).
Para um melhor entendimento do modelo, ainda de acordo com o mesmo autor, a seguir são apresentadas as descrições de pastas de forma a explicitar o modelo de administração de conteúdo do ERP5:
Person : Esta pasta centraliza informações sobre pessoas, e é implementada como uma extensão da pasta „member‟ do Framework de administração de conteúdo do Zope. Assim, pode conter arquivos pessoais, documentos, etc, se relacionando ou mesmo envolvendo as classes Node, Amount, Delivery.
IV CNEG 10 Organization :Esta pasta centraliza informações sobre organizações. Não obstante, criar uma organização exige definir sua posição na classificação global do ERP5. Isto é requerido porque sempre são nomeadas pessoas para uma organização, e a tarefa exige apontar uma folha da classificação global. Esta pasta pode ligar-se a um perfil empresarial (opcional) e a um perfil de cliente (opcional), sendo assim, esta pasta obtém o relacionamento com as classes Metanode, Amount e Delivery.
Orders: Centraliza todas as informações sobre pedidos, sendo que os mesmos são representados como objetos de entrega que são como uma coleção de objetos de „movement‟. Uma vez que um pedido é criado e aceito, uma cópia deste é gerada como um objeto de Delivery para criar objetos de Movements no Workflow de simulação. Orders possui associações com própria classe Orders, Movement, Delivery. Resource: Em Resource centraliza todas as informações sobre a descrição dos
recursos e metarecursos envolvidos em um processo de negocio. Um metarecurso pode ser, por exemplo: tempo de montagem, dinheiro, matéria prima, etc. Resource simplesmente são descrições de um produto ou de um serviço. Objetos de perfil padrão que incluem preço base, variação de preço, preço por quantidade, condições fiscais, etc. Esta pasta envolve associação com as classes Order, Movement, Delivery. Machine: Centraliza as informações sobre máquinas, como setup, e outros
parâmetros. Esta pasta se relaciona com a classe Node.
Item: Itens representam os objetos do mundo real que são transportados e transformados. Todas as informações de remessa podem ser itens elementares ou Containers. Esta pasta centraliza informações de localização dos itens e tem relacionamentos com Item e Containers.
Invoice: Uma fatura é implementada de uma maneira bem parecida com um pedido que pode ser entregue. Esta pasta centraliza todas as informações sobre faturas. Possui referências de objetos de entrega que representam remessas de bens e pagamentos. Esta pasta possui como principal relacionamento a classe Delivery.
Activities : Esta pasta centraliza todas as informações sobre a produção e consumo de recursos. Atividades são implementadas como objetos de Delivery, uma coleção de objetos de Movements e Delivery.
IV CNEG 11 Design: Todos os modelos de produtos que podem ser fabricados estão centralizados nesta pasta. Projetos são implementados como um conjunto de objetos de Transformation coletados em um único documento.
Transaction: Transaction centraliza todas as informações de contabilidade. Pertence ao workflow de simulação e que movem formulários de recursos de dinheiro de uma conta para outra, trabalhando assim todo tipo de movimentação como conta bancária, despesas e custos. Tem como principal relacionamento o Delivery.
Build Order: É responsável por centralizar os documentos de planejamento da produção. Build Orders são considerados casos especiais de Orders. Seu relacionamento principal é o Delivery.
Parternships: Parternship centraliza informações contratuais e organizacionais. Uma coleção de relações entre objetos de Path e objetos de Profile que definem condições comerciais para aquela parceria.
Account: Nesta pasta existe a organização das hierarquias de contas. São implementadas contas como Node e objetos Metanode. Contas múltiplas permitem fazer contabilidade de várias organizações. Esta pasta tem como associação principal o Node e o Metanode.
Delivery: Movimentos de objetos de Delivery pertencem ao workflow de simulação. Esta pasta organiza a informação sobre entregas de bens e serviços, interiormente ou para clientes.
Simulations: Toda a informação de simulação é armazenada nesta pasta, a mesma contém objetos de Movements. Movimentos são implementados como pastas que contém causalidade, as quais contêm movimentos, etc. Isto posto, considera-se a permissão de representar o processo da geração de movimento baseado em regras. Se relaciona com as classes Movement, Application e Tracking.
Rule: A pasta Rule centraliza definições de regras de negócios e as suas prioridades para transferência de informações, bem como a necessidade de organização da mesma. Categories: Define uma classificação global de todos os documentos. A pasta Category permite definir a coleção de categorias independentes. Pertencer a uma categoria é definido pelo ajuste de uma lista de palavras-chave dentro de um assunto, sendo que esta pasta tem como relacionamentos principais as classes Metanode e Node.
IV CNEG 12 Report: Permite definir relatórios em uma coleção de objetos. Relatórios são definidos pelo fornecimento de uma lista de categorias como país, consumidor, organização. Os relatórios permitem exibir uma seleção de objetos através de uma lista ou uma lista hierárquica e fornecer valores estatísticos para seleção.
Na próxima seção será abordado sobre a arquitetura CIMOSA e suas características mais importantes.
6. CIMOSA
Uma empresa é descrita por um conjunto de modelos interrelacionados. Cada modelo possui sua própria finalidade e cobre uma parte ou um subconjunto da empresa, ou representa um aspecto da empresa sob uma dada perspectiva (VERNADAT, 1996).
Computer Integrated Manufacturing Open System Architecture (CIMOSA) é uma arquitetura para o projeto e integração de empresas que fornece, entre outros conceitos e componentes, uma linguagem e um processo de modelagem que define atividades para a modelagem dos aspectos de uma empresa (CIMOSA Association, 1996).
Em um nível macro, CIMOSA vê toda a empresa como uma coleção de domínios (DM1, DM2 e DM3), definindo áreas funcionais responsáveis por objetivos da empresa. Um domínio é constituído de uma coleção de processos centrais (chamados processos de domínios - PD1, PD2 e PD3) e interage com outros domínios (RD12, RD13 e RD14) pela troca de requisições (eventos) e objetos (referenciados por suas vistas). Cada processo de domínio é uma cadeia completa de atividades da empresa (AEi), disparado por eventos, e produzindo um resultado final bem definido.
IV CNEG 13 Figura 3 - Visão Macro de modelagem CIMOSA.
Fonte: (Adaptado de Kosanke, 1995)
No próximo nível de análise, cada processo de domínio de um domínio a ser analisado é definido em termos de suas atividades de empresa, que são passos de processamento dentro de um processo transformando objetos e requerendo recursos para sua execução. Atividades podem ser agrupadas dentro de um processo de domínio em subprocessos, chamados processos de negócios (PNi) e são ligadas por um conjunto de relações causais ou de precedência chamadas regras de comportamento (RCi) formando uma rede de atividades.
Atividades de Empresa possuem entradas e saídas que descrevem os objetos de empresa transformados pela atividade, os objetos de controle das atividades e os recursos necessários para a atividade na forma de vistas de objetos. Cada atividade de empresa também pode ser decomposta e detalhada em passos de processamento elementares, chamados operações funcionais(OF), a qual requisitos de agentes ou entidades funcionais(EF) necessários para sua execução, devem ser expressos, conforme figura 4.
IV CNEG 14 Figura 4 – Decomposição de Atividades de Empresas.
Fonte: (Adaptado de Kosanke, 1995)
E finalmente, quando as estruturas funcionais, de informação, e de recursos estiverem especificadas, a estrutura de organização necessária para garantir coordenação própria e distribuição de responsabilidades, pode ser definida em termos de unidades de organização, células de organização, níveis de decisão, autoridades e responsabilidades.
Para o suporte a esta visão de modelagem CIMOSA oferece uma linguagem de modelagem cujos construtores são consistentes e não redundantes e que cobrem os vários aspectos da empresa como vistas de função, de informação, de recursos e de organização.
(CIMOSA Association, 1996), conforme figura 5.
Figura 5 - Elementos de Construtuores CIMOSA. Fonte: (Adaptado de Kosanke, 1995)
Comparada com outras metodologias de modelagem, as principais vantagens de CIMOSA segundo Vernadat (1996) são:
IV CNEG 15 Cobrir adequadamente os aspectos funcionais e comportamentais de sistemas de
empresas;
Suportar a descrição da especificação de projeto e implementação do sistema de acordo com os requisitos de usuários (processo de derivação);
Restringir o conjunto de blocos de construções possíveis, forçando vendedores fornecer componentes padrões;
Estar em linha com os padrões internacionais em desenvolvimento;
Único método de modelagem o qual satisfaz os princípios de separação de domínios de uma empresa, generalidade, reusabilidade, decomposição funcional, separação de funcionalidade e comportamento, separação de processos e recursos, e conformidade todos juntos.
Conforme Vernadat (1996) e (Association CIMOSA, 1996) serão descritas a seguir os aspectos de modelagem Funcionais, de Informação, de Recursos e de Organização.
6.1. MODELAGEM DE ASPECTOS FUNCIONAIS
O objetivo de um método de modelagem funcional é descrever a funcionalidade da empresa e o comportamento no nível de detalhe necessário pelo usuário de negócios. A maioria dos métodos de modelagem funcional é baseada na decomposição funcional, isto é, funções do sistema modelado são decompostas em subfunções, as quais resultarão em atividades ou processos e que podem então ser conectadas através de relações de precedência para modelar os processos de negócios da empresa.
Para suportar esse aspecto CIMOSA define seus construtores em termos de um modelo formal. A razão para isso é que o modelo de processo de uma empresa deve ser processável por computador para apoiar a análise (qualitativa e quantitativa), simulação, e representação do modelo de empresa. Os construtores são também definidos por meio de gabaritos de descrição. Uma vez que o modelo está completo, ele deve ser auto-explicativo e fornecer uma documentação completa e precisa das operações da empresa.
Os seguintes construtores são usados para modelagem funcional em vários níveis de modelagem de CIMOSA: domínio, relacionamento de domínio, evento, processo de domínio, processo de negócio, atividade de empresa, e operação funcional.
IV CNEG 16
O domínio pode ser considerado como um módulo gerenciável que pode interagir com outros domínios caracterizando o relacionamento de domínio. Um domínio compreende um conjunto de processos centrais, que são os processos de domínio. Os eventos representam qualquer acontecimento (solicitado ou não) requisitando algum processamento. A decomposição
de um domínio em subfunções resulta em processos intermediários chamados de processo de
negócio, que decomposto em subfunções são as atividade de empresa, cujo comportamento é definido por uma operação funcional, isto é, um script ou algoritmo que represente uma função que não pode mais ser decomposta.
6.2. MODELAGEM DE ASPECTOS DE INFORMAÇÃO
O propósito da modelagem de informação é fornecer uma representação do sistema de informação de uma empresa em vários níveis de modelagem. Um sistema de informação é feito de dados e informações usadas, armazenadas e processadas para as necessidades de usuários e aplicativos da empresa. Seu propósito é gerenciar os dados e informações da empresa para suporte às atividades do sistema físico e de decisão da empresa.
CIMOSA define dois principais construtores para a modelagem de informação: objeto de empresa e vista de objetos.
Objetos de empresa representam entidades do mundo real da empresa, possuindo uma identidade e existência própria, caracterizados por seu ciclo de vida e descritos por um conjunto de propriedades intrínsecas. Vistas de objetos de informação referem-se a entidades de informação, que representam dados de objetos do mundo real (natureza de informação).
Esta distinção diferencia o fluxo de informação e o fluxo de material em um modelo. No modelo, as vistas de objetos são constituídas de elementos de informação extraídos de objetos da empresa ou atributos derivados, como uma imagem ou aparência do estado de um ou mais objetos em uma dado instante como documentos, formulários, telas de computador, arquivos de dados, etc.
6.3. MODELAGEM DE ASPECTOS DE RECURSOS
De forma geral, um recurso é qualquer coisa que é requerida para executar algo, uma entidade
humana ou técnica, que contribui para a realização da funcionalidade de atividades de processos de negócio. Processos de negócios define „o que‟ deve ser feito e „como‟ deve ser feito, já os recursos são agentes ou atores que fazem o trabalho.
IV CNEG 17 Nesta vista, os construtores CIMOSA são: entidade funcional, recurso, capabilidade e
conjunto de capabilidade.
Entidade funcional é aquela capaz de enviar requisições e executar operações funcionais, uma entidade funcional engloba todos os recursos ativos que executam operações funcionais de uma atividade, dentro ou fora da empresa como mandar, receber, processar mensagens (requisições ou dados), ou ainda armazenar informações. Recursos quando não são entidades funcionais, são chamados de componentes, isto é, recursos passivos (objetos que não proporcionam funcionalidades por si só). Eles precisam ser usados ou manipulados por entidades funcionais tornando-se parte de uma entidade funcional agregada. Os recursos por sua vez fornecem as capabilidades ou conjunto de capabiliades, isto é, são elementos que podem referir-se à funcionalidade de uma atividade de empresa e são definidos por um nome, um valor e possivelmente uma unidade.
6.4. MODELAGEM DE ASPECTOS DE ORGANIZAÇÃO
A estrutura organizacional, apesar de imaterial, é a espinha dorsal da empresa. Ela estrutura a empresa em uma hierarquia de unidades de decisão. Cada unidade pertence a um nível organizacional, possui um horizonte de planejamento, possui responsabilidades e autoridades sobre as unidades organizacionais de nível mais baixo, e se reporta a uma unidade de nível superior. Cada nó na hierarquia define restrições e objetivos para seus nós de mais baixo nível.
Uma unidade de organização pode representar um centro de decisão consistindo de uma ou mais pessoas, um centro de trabalho, uma seção, até um departamento inteiro.
Os aspectos de organização de uma empresa são, então, relativos a união entre pessoas (competências) e tarefas (processos), caracterizada pelo seu comportamento e dinâmica, necessitando portanto, ser flexível.
A vista de organização CIMOSA fornece os construtores: unidade de organização, célula de organização e elemento de organização.
O construtor Unidade de organização é um elemento da organização, definido por sua lista de capabilidades, responsabilidades e autoridades dentro de uma estrutura de organização, associados e descritos por uma função de tomada de decisão ou solução de problemas. Cada unidade de organização pertence a apenas uma célula de organização, que é uma agregação de unidades de organização definindo uma área organizacional da estrutura de organização.
A seguir serão feitas comparações dos construtores de linguagem CIMOSA e as classes do ERP5 visando adequar o levantamento de requisitos e facilitar a passagem deste modelo para o modelo de desenvolvimento do ERP5.
IV CNEG 18
7. COMPARAÇÃO
Nesta seção será apresentada uma comparação entre os construtores da linguagem CIMOSA e os conceitos abstratos do ERP5, especificamente o seu Framework. A proposta dessa comparação contempla identificar aspectos da linguagem CIMOSA que possuem algum grau de correspondência. As correspondências encontradas serão classificadas em Fraca, Média e Forte.
A fim de facilitar a comparação é apresentado abaixo um quadro com os construtores CIMOSA e as respectivas classes do ERP5 que possuem alguma correspondência. Os construtores que não tiverem correspondência com o ERP5 ficam em branco.
CIMOSA Classes do ERP5 Vista de Função
Domínio
Relacionamento de Domínio
Atividade de Empresa Activities Operação Funcional Movement
Processo de Domínio Conjunto de Activities Processo de Negócio Conjunto de Activities Evento Vista de Informação Objeto de Empresa Considera-se qualquer objeto do Framework do ERP5 Vista de Objeto
Considera-se qualquer pasta ou classe criada sobre os objetos do Framework do ERP5
Vista de Recursos
Capabilidade Capacity
Conjunto de Capabilidades Conjunto de Capacity
Recurso Pearson / Machine
Entidade Funcional Conjunto de Pearson / Machine
Vista de Organização
Unidade de Organização Node/Organization Célula de Organização Metanode/ Organization Elemento de organização
IV CNEG 19
7.1. COMPARANDO VISTA DE FUNÇÃO
Comparando a vista de função CIMOSA, pode-se relacionar os construtores Atividade de Empresa, Operação Funcional, Processo de Domínio e Processo de Negócio, com as classes do ERP5 Activities, Movements, Conjunto de Activities, conforme ilustra o quadro 1.
CIMOSA ERP5
Atividade de Empresa
Um conjunto de ações elementares executados para realizar alguma tarefa dentro de uma empresa, requerendo tempo e recursos para sua execução, e transformado um estado de entrada em um estado de saída.
Activities (Forte)
Uma pasta que centraliza todas as informações sobre a produção e consumo de recursos.
Operação Funcional
Operações funcionais são unidades, ou átomos, de funcionalidade, usadas no comportamento da atividade.
Movements (Média)
Movimentos são onde recursos de planejamento atual acontece, podem incluir submovimentos gerados pelas regras de negócios e podem ser associados a outros movimentos através de causalidades.
Processo de Domínio
É uma seqüência de atividades de uma empresa com condições iniciais bem definidas e fornecendo um resultado final definido.
Conjunto de Activities (Forte)
Uma pasta que centraliza todas as informações sobre conjunto de activities.
Processo de Negócio
Processos de negócios são subprocessos similares a processos de domínio.
Conjunto de Activities (Forte)
Uma pasta que centraliza todas as informações sobre conjunto de activities. Quadro 1 –Vista de Função CIMOSA e classes ERP5
7.2. COMPARANDO VISTA DE INFORMAÇÃO
Comparando a vista de informação CIMOSA, pode-se relacionar os construtores Vista de Objeto e Objeto de Empresa com qualquer uma das classes do ERP5, conforme ilustra o quadro 2.
CIMOSA ERP5
Objeto de Empresa
Objetos de empresa representam entidades do mundo real da empresa, possuindo uma identidade e existência própria. Eles são caracterizados por seu ciclo de vida e são descritos por um conjunto de propriedades intrínsecas.
Classes Objetos do Framework (Média) Considera-se objetos de empresa as pastas ou classes originais do Framework do ERP5.
Vista de Objeto
Vista de objetos é uma imagem ou aparência do estado de um ou mais objetos de empresa em um dado instante.
Objetos derivados do Framework (Média) Considera-se aqui vista de objeto qualquer pasta ou classe criada sobre os objetos do Framework do ERP5.
IV CNEG 20
7.3. COMPARANDO VISTA DE RECURSOS
Comparando a vista de recursos CIMOSA, pode-se relacionar os construtores Capabilidade, Conjunto de Capabilidades, Recurso e Entidade Funcional, com as classes do ERP5 Capacity, Person ou Machine, conforme ilustra o quadro 3.
CIMOSA ERP5
Capabilidade
Refere-se à funcionalidade de uma atividade de empresa ou de um recurso.
Capacity (Fraca)
Uma quantia máxima ou mínima de recurso que uma interconexão pode produzir em um dado período de tempo. Conjunto de Capabilidades
São conjunto de elementos de capabilidade.
Conjunto de Capacity (Fraca)
Pasta que centraliza uma quantia máxima ou mínima de recurso que uma interconexão pode produzir em um dado período de tempo.
Recurso
São classificados em entidades funcionais e componentes, que são recursos passivos (objetos que não proporcionam funcionalidades por si só). Eles precisam ser usados ou manipulados por entidades funcionais tornando-se parte de uma entidade funcional agregada.
Pearson ou Machine (Forte)
Pearson centraliza informações sobre pessoas, pode conter arquivos pessoais, documentos, etc.
Machine pasta centraliza as informações sobre máquinas.
Entidade Funcional
São todos recursos ativos capazes de executar operações funcionais de uma atividade e fazer algum papel no curso do processo.
Conjunto de Pearson ou Machine
(Forte)
Conjunto de informações sobre pessoas e/ou máquinas, etc.
Quadro 3 –Vista de Recursos CIMOSA e classes ERP5
7.4. COMPARANDO VISTA DE ORGANIZAÇÃO
Comparando a vista de organização CIMOSA, pode-se relacionar os construtores Unidade de Organização, Célula de Organização, com as classes do ERP5 Node e Metanode, conforme ilustra o quadro 4.
CIMOSA ERP5
Unidade de Organização
Uma unidade de organização é um grupo de um ou mais entidades funcionais responsável por tomar decisões e cada unidade de organização pertence a uma célula de organização.
Node/ Organization (Média)
São relativos a entidades físicas e podem receber e enviar recursos.
Célula de Organização
É uma agregação de unidades de organização e/ou (outras) células de organização definindo uma área organizacional da estrutura de organização.
Metanode/ Organization (Média) São um conjunto de nodes.
IV CNEG 21
8. CONSIDERAÇÕES SOBRE AS CORRESPONDÊNCIAS
De acordo com as comparações feitas da vista de função, vista de informação, vista de recursos e vista de organização de CIMOSA com as classes do ERP5, observou-se que:
Na comparação da vista de função a qual possui sete construtores, quatro possuem correspondência, sendo que três destes foram classificados com correspondência forte e um com correspondência média.
Para a comparação da vista de informação, dos seus dois construtores, ambos possuem correspondência classificada como média para os dois.
Em vista de recursos a comparação também foi possível para os quatro construtores desta vista, sendo dois classificados com correspondência fraca e dois com correspondência forte.
E finalmente na comparação da vista de organização dos seus três construtores, dois possuem correspondência classificadas como média.
9. CONCLUSÃO
Através da comparação realizada pode ser verificado que dos construtores da linguagem CIMOSA, que entre todas as vistas totalizam dezesseis construtores, somente quatro deles ficaram sem uma classe correspondente no ERP5. Percebeu-se que as classes do ERP5 não cobrem totalmente a fase de levantamento de requisitos, evidenciando certa dificuldade devido ao fato de que nem todos os construtores estão com um grau de correspondência classificado como médio ou forte.
Porém, como o ERP5 mostra-se flexível para aplicações empresariais, sem resultar altos custos de mudanças e manutenção e CIMOSA é uma arquitetura para o projeto e integração de empresas que fornece, entre outros conceitos e componentes, uma linguagem e um processo de modelagem dos aspectos de uma empresa, conclui-se, portanto, que seria interessante investir na customização do ERP5 para que suas classes fossem adaptadas de forma a cobrirem a fase de levantamento de requisitos.
Ficando com sugestão de atividade futura o estudo de como proceder essa customização.
IV CNEG 22
10. REFERÊNCIAS
AZEVEDO, J.D; CAMPOS, R. Modelagem de Arquiteturas de Negócio com UML: Um
Facilitador para a Integração de Sistemas Organizacionais. IX Simpósio de Engenharia de
Produção, Bauru, 2002.
CAMPOS, R. (2006) Projeto enviado ao CNPQ (Edital Universal), 2006
CARVALHO, R.A.; CAMPOS, R. Propostas para o Processo de Desenvolvimento do
Sistema ERP5, In: XXVII Encontro Nacional de Engenharia de Produção, Foz do Iguaçu, PR,
2007, Disponível em: < www.abepro.org.br>. Acesso em: 10 abr. 2008.
CARVALHO, R.A.; MONNERAT, R. ERP5: Designing for Maximum Adaptability, In: Oram, A.; Wilson, G., Beautiful Code, ISBN:0596510047, 2007, cap. 21, p. 339-351.
CIMOSA Association, CIMOSA technical baseline, CIMOSA Association, Stockholmerst 7, D-70731, Boblingen, Germany, 1996
GONÇALVES, F.R.; PESSOA, M.C.; PRADO, J.P. Uma Proposta de Utilização de UML na
Implantação de Sistemas ERP, In: Congresso Brasileiro de Computação, UFRGS, 2004,
Disponível em: < www.niee.ufrgs.br/cbcomp/cbcomp2004>. Acesso em: 20 mar. 2008. HEBERKORN, E. Gestão Empresarial com ERP, São Paulo, 2003.
KOSANKE, K. CIMOSA Overview and Status. Netherlans: Computer in Industry. v.27, n.2, p.101-109, 1995.
MEDEIROS, E.S. Desenvolvendo Software com UML, Ed. Pearson, São Paulo, 2004
MENDES, J.V.; ESCRIVÃO FILHO, E. Sistemas Integrados De Gestão Erp Em Pequenas
Empresas: Um Confronto Entre O Referencial Teórico E A Prática Empresarial, São Paulo,
UNIFEI, 2002. Disponível em:<www.scielo.br/pdf/gp/v9n3/14570.pdf>. Acessado em: 20 abr. 2008.
SMETS-SOLANES, J.P. ERP5:a Technical Introductio. ,2002, Disponível em:< https://cps.erp5.org/sections/free/erp/linuxtag.pdf >. Acessado em: 25 abr. 2008.
SMETS-SOLANES, J.P.; CARVALHO, R.A. ERP5: A Next-Generation, Open-Source ERP
Architecture. IEEE IT Professional. , v.5, n.4, p.38 - 44, 2003.
SMETS-SOLANES, J.P., CARVALHO, R.A. An Abstract Model For An Open Source Erp
System: The Erp5 Proposal, In: Eighth International Conference on Industrial Engineering,
Cornell University, Ithaca, NY, USA, 2002.
IV CNEG 23 VERNADAT, F. B. Enterprise modeling and integration, Principles and Applications, Chapman & Hall, 1996.
