UM ESTUDO SOBRE O MAPEAMENTO ENTRE AS CLASSES DO ERP5 E A LINGUAGEM CIMOSA

Transcrição

1 31 de Julho a 02 de Agosto de 2008 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

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 2

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 3

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 4

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 5

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). Na próxima seção será abordado sobre o ERP5 e suas características mais importantes. IV CNEG 6

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 ( escrito na linguagem Python ( 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 7

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 8

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 9

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 10

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 11

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 12

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 13

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 14

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 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 15

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 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 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 16

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 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 17

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 Vista de Função Domínio Relacionamento de Domínio Atividade de Empresa Operação Funcional Processo de Domínio Processo de Negócio Evento Vista de Informação Objeto de Empresa Vista de Objeto Vista de Recursos Capabilidade Conjunto de Capabilidades Recurso Entidade Funcional Vista de Organização Unidade de Organização Célula de Organização Elemento de organização Classes do ERP5 Activities Movement Conjunto de Activities Conjunto de Activities Considera-se qualquer objeto do Framework do ERP5 Considera-se qualquer pasta ou classe criada sobre os objetos do Framework do ERP5 Capacity Conjunto de Capacity Pearson / Machine Conjunto de Pearson / Machine Node/Organization Metanode/ Organization IV CNEG 18

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 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. Operação Funcional Operações funcionais são unidades, ou átomos, de funcionalidade, usadas no comportamento da atividade. Processo de Domínio É uma seqüência de atividades de uma empresa com condições iniciais bem definidas e fornecendo um resultado final definido. Processo de Negócio Processos de negócios são subprocessos similares a processos de domínio. ERP5 Activities (Forte) Uma pasta que centraliza todas as informações sobre a produção e consumo de recursos. 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. Conjunto de Activities (Forte) Uma pasta que centraliza todas as informações sobre conjunto de activities. 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 ERP 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 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. Vista de Objeto Vista de objetos é uma imagem ou aparência do estado de um ou mais objetos de empresa em um dado instante. ERP5 Classes Objetos do Framework (Média) Considera-se objetos de empresa as pastas ou classes originais do Framework do ERP5. Objetos derivados do Framework (Média) Considera-se aqui vista de objeto qualquer pasta ou classe criada sobre os objetos do Framework do ERP5. Quadro 2 Vista de Informação CIMOSA e classes ERP5 IV CNEG 19

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 Capabilidade Refere-se à funcionalidade de uma atividade de empresa ou de um recurso. Conjunto de Capabilidades São conjunto de elementos de capabilidade. 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 tornandose parte de uma entidade funcional agregada. Entidade Funcional São todos recursos ativos capazes de executar operações funcionais de uma atividade e fazer algum papel no curso do processo. ERP5 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 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. 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. 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 ERP 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. 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. Quadro 4 Vista de Organização CIMOSA e classes ERP5 Node/ Organization (Média) São relativos a entidades físicas e podem receber e enviar recursos. Metanode/ Organization (Média) São um conjunto de nodes. IV CNEG 20