2014 - 2sem - Ricardo Aparecido Junior Theodoro

Ricardo Aparecido Junior Theodoro
IMPLANTAÇÃO E ESTUDO DE CASO DE UM SISTEMA

INTEGRADO DE GESTÃO EMPRESARIAL OPEN SOURCE EM
UMA EMPRESA DE PEQUENO PORTE
Trabalho de conclusão de curso apresentado ao

Instituto Federal de São Paulo, como parte dos
requisitos para a obtenção do grau de Tecnólogo
em Sistemas para Internet.
Área de Concentração: Sistemas de informação
Orientador: Prof. Roan Simões da Silva
São João da Boa Vista

2014
Autorizo a reprodução e divulgação total ou parcial deste trabalho, por qualquer
meio convencional ou eletrônico, para fins de estudo e pesquisa, desde que
citada a fonte.
Ficha catalográfica preparada pela Seção de Tratamento

da Informação do Serviço de Biblioteca – IFSP
Theodoro, Ricardo Ap. Jr.

Implantação e estudo de caso de um sistema integrado
de gestão empresarial open source em uma empresa de
pequeno porte. / Ricardo Aparecido Junior Theodoro;
orientador Roan Simões da Silva. São João da Boa Vista,
2014.
Trabalho de Conclusão de Curso, IFSP, 2014.
1. Sistemas de Gestão. 2. Sistemas ERP. 3. Open

source 4. OpenERP.
I. Implantação e estudo de caso de um sistema

integrado de gestão empresarial open source
em uma empresa de pequeno porte.
AGRADECIMENTOS
Agradeço primeiramente a Deus por ter me proporcionado todas as
condições necessárias para a realização e finalização deste trabalho.
Agradeço também a minha família, Sonia Maria Junior Theodoro, Milton de
Oliveira Theodoro e Hector Junior Theodoro por estarem sempre presentes
no meu dia a dia ajudando desde as necessidades mais básicas até as mais
complexas.
Sou muito grato também aos amigos que me acompanharam nessa grande
caminhada, pois estiveram sempre presentes tanto nos momentos bons
quanto nos ruins fortalecendo cada vez mais a amizade e o companheirismo.
Por fim, gratifico também os professores que orientaram e deram dicas para
a realização deste trabalho, principalmente ao professor orientador e aos
professores da banca de avaliação.

RESUMO
THEODORO, R. (2014). Implantação e estudo de caso de um sistema integrado de gestão

empresarial open source em uma empresa de pequeno porte. Trabalho de Conclusão de
Curso - Instituto Federal de São Paulo, São João da Boa Vista, 2014.
Este trabalho visa apresentar a implantação e o estudo de caso de um sistema de gestão

empresarial de código aberto, também conhecido como sistema ERP. Tal sistema tem como
objetivo centralizar as informações de diversas áreas da empresa, agilizando o acesso as
informações, processando os dados e facilitando nas tomadas de decisões. Foi feita uma
aplicação de um estudo de caso em uma empresa de pequeno porte do ramo alimentício
demonstrando o processo de escolha e análise dos sistemas presentes no mercado e a
aplicação de uma metodologia de implantação a qual foi realizada de acordo com a política
adotada pela corporação. Decorrente da análise da empresa, foi escolhida a adoção de um
sistema de código aberto chamado OpenERP, que demonstrou possuir maior aderência aos
requisitos levantados no processo de escolha. Como resultados deste trabalho, foram obtidas
as avaliações segundo os usuários e programadores envolvidos com o sistema, mostrando que
mesmo com uma equipe reduzida é possível a instalação de grande parte de um sistema de
gestão empresarial. Essa análise também demonstrou que a empresa obteve melhorias em
alguns processos, como por exemplo, a padronização do processo de emissão de pedidos e
menor tempo para atendimento dos mesmos. Além disso, a firma está confiante na
possibilidade de manutenção interna, tendo inclusive desenvolvido um módulo para atender
necessidades que o sistema originalmente não atendia. Porém alguns empecilhos como a falta
de conhecimento em determinadas áreas, falta de documentação adequada e o trabalho em
paralelo com as atividades diárias da empresa podem gerar atrasos no projeto. Por conta disso,
ainda não foi possível realizar a implantação da área fiscal/contábil, sendo que para tal houve
a terceirização de parte do serviço e a decisão pela espera do lançamento da nova versão do
OpenERP, que atenderá melhor às necessidades aumentando assim, o custo total de
propriedade do sistema.
Palavras-chave: Sistemas de gestão. Sistemas ERP. Open source. OpenERP

ABSTRACT
THEODORO, R. (2014). Implementation and case study of an integrated management

system open source in a small company. Course Conclusion Project – Instituto Federal de
São Paulo, São João da Boa Vista, 2014.
This project aims to present the implementation and study case of a business
administration system of open code, also known as the ERP system. It has as a goal to
centralize the diverse information from different areas of the company, making it faster the
access to information, processing data and facilitating the decision making. There was made
an application of a study case in a small company in the food department demonstrating the
decision making process and the analyses of the present systems and the application of an
implementation of a methodology that was made following the rules adopted by the
corporation. After the analyses of the company, it was chosen the adoption of an open system
code called OpenERP, which demonstrated to possess more adherences in the requirements
that were raised in the choosing process. As a result of this project, there have been obtained
the evaluations according to the users and programmers involved with the system, showing
that even with a reduced team it's possible to install a big part of a business administration
system. This analyses also showed that the company had improvements in some processes,
for instance, the standardization of the order emission process and a smaller time to attend
the same Besides that, the company in confident in the possibility of internal maintenance,
having also developed a mode to attend the necessity that the original system didn't.
Although, some troubles like the lack of knowledge in certain areas, lack of proper
documentation and the parallel work with the daily activities of the company may generate
delays in the project. Therefore, it was possible to make the implementation of the
fiscal/accounting, and for this was the outsourcing of this part of the service and the decision
to wait for the launch of a new version of the OpenERP, which will attend better the
necessities, thus increasing the total cost of the property of the system.
Keywords: Management systems. ERP systems. Open source. OpenERP.

LISTA DE FIGURAS
Figura 1 - Estrutura básica de um MRP. .......................................................... 20

Figura 2 - Módulos do OpenERP integrados ao banco de dados central. ........ 21
Figura 3 - Estrutura MVC do OpenERP. .......................................................... 22
Figura 4 - Carta escrita por Bill Gates. ............................................................. 25
Figura 5 - Metodologia de implantação. ........................................................... 33
Figura 6 - Tela de cadastro de clientes com alguns campos obrigatórios. ....... 41
Figura 7 - Tela para cadastro de produtos manufaturados .............................. 42
Figura 8 - Interface listando o módulo criado. .................................................. 47
Figura 9 - Exibição do código fonte do arquivo relatorio.py. ............................. 47
Figura 10 – Interface da lista de controle de acessos do OpenERP. ............... 48
Figura 11 – Tela de cadastro do módulo de relatório. ...................................... 49
Figura 12 – Tela de cadastro de produtos do módulo de compras .................. 52
Figura 13 – Tela de cadastro de fornecedores. ................................................ 53
Figura 14 – Tela para alteração de sequência de identificadores. ................... 54
Figura 15 – Tela de listagem dos dados cadastrados. ..................................... 56
Figura 16 – Tela de cadastro de lotes de matéria prima. ................................. 58
Figura 17 – Tela de cadastro de lista de materiais. .......................................... 61
Figura 18 – Tela inicial do OpenERP 8. ........................................................... 63
LISTA DE QUADROS
Quadro 1 – Quadro comparativo dos sistemas OpenERP, Compiere e

OpenBravo. .................................................................................... 37
Quadro 2 - Requisitos cumpridos e não cumpridos inicialmente pelo módulo
de vendas. ...................................................................................... 44
Quadro 3 – Resumo dos requisitos cumpridos e não cumpridos inicialmente
pelo módulo de relatórios de entrega. ............................................ 49
Quadro 4 – Requisitos cumpridos e não cumpridos inicialmente pelo módulo
de compras. ................................................................................... 54
Quadro 5 – Requisitos cumpridos e não cumpridos inicialmente pelo módulo
de armazém. .................................................................................. 59
Quadro 6 – Requisitos cumpridos pelo módulo de manufatura. ....................... 61
LISTA DE SIGLAS
AFL Licença Acadêmica Pública (Academic Free License)
AGPL Licença Pública Geral Affero (Affero General Public License)
BSD Distribuição de Software da Berkeley (Berkeley Software Distribution)
CEO Diretor executivo (Chief Executive Officer)
CSV Valores Separados por Vírgula (Comma Separated Values)
ERP Planejamento de Recursos Empresariais (Enterprise Resource
Planning)
FSF Fundação de Software Livre (Free Software Foundation)
GPL Licença Pública Geral (General Public License)
IP Protocolo de Internet (Internet Protocol)
LGPL Licença Pública Geral Reduzida (Lesser General Public License)
MRP I Planejamento de Necessidades Materiais(Material Requirements
Planning)
MRP II Planejamento de Recursos de Manufatura (Manufacturing Resource
Planning)
MIT Instituto Tecnológico de Massachusetts (Massachusetts Institute of
Technology)
MVC Modelo – Visualização - Controlador - (Model - View - Controller)
TCO Custo Total de Propriedade (Total Cost Ownership)
TI Tecnologia da Informação
XML-RPC Linguagem de Marcação eXtensiva – Chamada Remota de
Procedimento (eXtensible Markup Language - Remote Procedure Call)
XML Linguagem de Marcação eXtensiva (eXtensible Markup Language)

SUMÁRIO
1 INTRODUÇÃO ...........................................................................................................15
1.1 Motivação ............................................................................................................................. 15
1.2 Objetivos Gerais ................................................................................................................... 16
1.3 Objetivos específicos ............................................................................................................ 16
1.4 Organização deste trabalho ................................................................................................... 16
2 PESQUISA BIBLIOGRÁFICA......................................................................................19
2.1 Sistemas de Informação Gerenciais ...................................................................................... 19
2.2 Sistemas Integrados de Gestão Empresarial ......................................................................... 20
2.2.1 OpenERP ............................................................................................................................ 21
2.2.2 Compiere ERP.................................................................................................................... 23
2.2.3 OpenBravo ......................................................................................................................... 23
2.3 Licenças de Software ............................................................................................................ 24
2.3.1 Licenças Proprietárias ........................................................................................................ 26
2.3.2 Licenças Públicas ............................................................................................................... 26
2.3.2.1 Licença AGPL .............................................................................................................. 27
2.4 Metodologia de Implantação ................................................................................................ 28
2.5 Custo Total de Propriedade .................................................................................................. 29
2.6 Trabalhos Relacionados ........................................................................................................ 29
3 METODOLOGIA ........................................................................................................31
3.1 A empresa ............................................................................................................................. 31
3.2 Metodologia de implantação utilizada .................................................................................. 31
3.3 Recursos de hardware e backup da empresa ......................................................................... 33
3.4 Fatores considerados para a instalação do ERP .................................................................... 34
3.5 Avaliação dos sistemas disponíveis ...................................................................................... 36
3.6 Instalação da base do software e módulos iniciais ............................................................... 37

3.7 Módulo de vendas ................................................................................................................. 38
3.7.1 Módulo de vendas: levantamento de requisitos.................................................................. 38
3.7.2 Módulo de vendas: plano de ação ...................................................................................... 39
3.7.3 Módulo de vendas: implantação ......................................................................................... 39
3.8 Módulo de relatórios de entrega............................................................................................ 44
3.8.1 Módulo de relatórios de entrega: levantamento de requisitos ............................................ 45
3.8.2 Módulo de relatórios de entrega: plano de ação ................................................................. 45
3.8.3 Módulo de relatórios de entrega: implementação e implantação ....................................... 46
3.9 Módulo de compras............................................................................................................... 50
3.9.1 Módulo de compras: levantamento de requisitos ............................................................... 50
3.9.2 Módulo de compras: plano de ação .................................................................................... 50
3.9.3 Módulo de compras: implementação e implantação .......................................................... 51
3.10 Módulo de armazém ........................................................................................................... 55
3.10.1 Módulo de armazém: Levantamento de Requisitos .......................................................... 55
3.10.2 Módulo de armazém: plano de ação.................................................................................. 56
3.10.3 Módulo de armazém: implementação e implantação ........................................................ 56
3.11 Módulo de manufatura ....................................................................................................... 59
3.11.1 Módulo de Manufatura: Levantamento de requisitos ....................................................... 59
3.11.2 Módulo de Manufatura: Plano de ação ............................................................................. 60
3.11.3 Módulo de Manufatura: Implementação e implantação .................................................... 60
3.12 Módulos de Faturamento e Contabilidade .......................................................................... 61
3.13 Custos e investimentos ....................................................................................................... 63
4 RESULTADOS .......................................................................................................... 67
5 CONCLUSÕES .......................................................................................................... 69
5.1 Sugestões e recomendações para trabalhos futuros .............................................................. 71
REFERÊNCIAS ............................................................................................................... 73
Capítulo
15
1 Introdução
Para ter um melhor desempenho, tanto financeiro quanto administrativo, na gestão de
todas as áreas de uma empresa, é de extrema importância que uma organização consiga
armazenar e utilizar de maneira eficiente seus dados internos e externos. Essa utilização
eficiente dos dados fará com que os gestores da organização possam tomar decisões a partir
de informações confiáveis e adquiridas em tempo real (Laudon; Laudon, 2011).
Visando melhorar esse processo foram criados os sistemas de informação gerenciais,
os quais têm a tarefa de coletar e processar os dados para os usuários, tornando a tarefa de
análise e obtenção de informações menos complexa (Laudon; Laudon, 2011).
Em ambientes corporativos, o sistema de informação gerencial mais utilizado é o
sistema integrado de gestão, também conhecido como ERP (Enterprise Resource Planning –
Planejamento de recursos empresariais). Este sistema procura integrar todas as áreas da
empresa e assim tornar a manipulação dos dados de diferentes áreas mais ágil e confiável
(Turbam; Rainer Jr.; Potter, 2005).
O sistema de informação gerencial abordado nesse trabalho é o OpenERP1, um
sistema com código fonte aberto, permitindo que qualquer pessoa interessada no mesmo
possa alterá-lo ou apenas estudá-lo (OPENERP, 2013).
Este ERP também é gratuito e conta com uma comunidade brasileira ativa, que
trabalha em traduções e criação de módulos voltados para os padrões fiscais e contábeis
brasileiros os quais estão disponíveis para os demais usuários em seu site (OPENERP, 2013).
1.1 Motivação
A motivação para a realização deste trabalho se deve à falta de documentação
referente ao processo de implantação e utilização de sistemas ERP de código aberto.
Após pesquisas do autor, chegou-se à conclusão que há poucas publicações na área de
computação abordando em um contexto mais técnico a implantação de sistemas de gestão
empresarial.
1
Site do sistema OpenERP: https://www.openerp.com/
16
Portanto, este trabalho irá contribuir ao demonstrar, através de um estudo de caso, o

processo de implantação de um sistema ERP em uma empresa real, mostrando os erros,
acertos e dificuldades para que outros interessados tenham alguns subsídios para uma decisão
sobre implantar ou não um sistema de código aberto.
1.2 Objetivos Gerais

O objetivo do trabalho é documentar em um estudo de caso, o processo de escolha e
implantação de um sistema de gestão empresarial de código aberto em uma empresa de
pequeno porte do ramo alimentício.
Neste trabalho será apresentada cada uma das fases de implantação, citando
inicialmente os requisitos considerados e como ocorreu a análise das alternativas disponíveis
até a escolha do sistema que melhor se enquadra nas necessidades da empresa.
Neste estudo de caso, serão registrados os erros e acertos no processo de escolha e
implantação, a fim de minimizar os problemas em instalações futuras de outras empresas a
partir dessa experiência.
1.3 Objetivos específicos

Os objetivos específicos deste trabalho são os seguintes:
 Apresentar as principais diferenças entre os modelos de licenciamento

proprietário e de código aberto.
 Documentar o processo utilizado para a escolha do sistema de gestão
empresarial;
 Implantar um sistema integrado de gestão empresarial em uma empresa,
tendo um estudo de caso de uma situação real;
 Avaliar a implantação do sistema de gestão empresarial a partir da visão dos
usuários, diretores da empresa e outros envolvidos;
1.4 Organização deste trabalho

No primeiro capítulo é feita uma introdução e descrição dos objetivos deste trabalho,
os quais estão divididos em dois grupos, os objetivos específicos e os objetivos gerais.
17
No segundo capítulo é apresentada a base teórica necessária ao leitor para entender o

desenvolvimento do trabalho, podendo auxiliá-lo em momentos de dúvida sobre algum tema
ou assunto abordado na metodologia.
A metodologia envolve o processo de estudo de caso, onde serão listadas as atividades
realizadas para a implantação do sistema assim como seus erros e resoluções. O estudo será
realizado a partir de uma metodologia utilizada na empresa e após a implantação do software
abordado, será feito uma análise sobre o sistema instalado.
Os resultados desta análise serão apresentados no capítulo quatro, a partir das
avaliações feitas pela equipe técnica e apontamentos dos usuários e gestores da empresa,.
E por último, o capítulo cinco irá concluir o trabalho apresentando o corolário obtido
através da análise dos resultados alcançados no capítulo quatro.
Capítulo
19
2 Pesquisa Bibliográfica
Neste capítulo são abordados os assuntos envolvidos com o tema deste trabalho para
que o usuário possa ter uma compreensão melhor dos termos e temas utilizados durante a
metodologia.
Nele será mostrado o que são os sistemas de informação gerenciais, os sistemas
integrados de gestão empresarial assim como os softwares de licença pública abordados na
metodologia deste trabalho. Será descrito a diferença entre os diversos tipos de licenças de
software com maior foco na licença ao qual o programa utilizado neste estudo de caso
pertence.
As ferramentas e a metodologia utilizadas no decorrer do trabalho também serão resumidas de
modo a dar uma base teórica ao leitor com relação a esses itens.
2.1 Sistemas de Informação Gerenciais

Segundo Laudon e Laudon (2011) os sistemas de informação são conjuntos de
componentes que coletam, processam, armazenam e distribuem informações para auxiliar na
gerência de uma organização. Os mesmos autores também advertem para a diferença entre os
termos dados e informações, onde os dados são definidos como fatos não analisados e/ou
processados para que as pessoas possam utilizar de forma significativa. Já as informações,
representam os dados processados de forma que as pessoas consigam utilizá-los de forma útil.
Para que as organizações possam tomar decisões de maneira mais eficiente, controlar
operações, analisar problemas e criar novos produtos, há três atividades em um sistema de
informação que são necessárias: entrada, processamento e saída (Turbam; Rainer Jr.; Potter,
2005).
A entrada consiste na captura de dados dentro da organização ou em ambientes
externos ligados a ela. O processamento é a conversão dos dados brutos em informações que
serão úteis às pessoas da organização. Por fim, a saída consiste na transferência dos dados
processados para os seus usuários, que irão utilizá-los nas tomadas de decisões nas
organizações (Turbam; Rainer Jr.; Potter, 2005).
20
2.2 Sistemas Integrados de Gestão Empresarial

Os sistemas ERP são utilizados para integrar as diversas áreas de uma empresa, desde
a área de produção até a área de relacionamento com o consumidor, incluindo áreas como
compras, vendas, financeiro e recursos humanos.
Estes sistemas fazem partes dos sistemas de informações gerenciais, pois eles se
baseiam na entrada de dados e o seu processamento com o intuito de mostrar aos usuários
informações confiáveis que darão suporte às tomadas de decisão no ambiente corporativo.
Turbam, Rainer Jr. e Potter (2005) afirmam que os ERP’s estão divididos em duas
gerações conforme descrito abaixo:
Primeira geração: era utilizado para as pequenas tarefas rotineiras que a empresa tinha,
sendo desenvolvidos com o objetivo de organizar os aplicativos que funcionavam
isoladamente nestas tarefas e fazendo com que eles se integrassem. Os sistemas de gestão
empresarial da primeira geração eram conhecidos como MRP I (Material Requirements
Planning – Planejamento de Necessidades Materiais) e não forneciam informações para
planejamentos futuros dos gerentes, mostrando apenas dados de certo momento da empresa
Segunda geração: o MRP I evoluiu para o MRP II (Manufacturing Resource Planning
– Planejamento dos Recursos de Manufatura) e já estavam mais avançados em relação à
manipulação de informações, podendo fornecer estatísticas para o planejamento empresarial,
planejamento de custo e desempenho financeiro assim como mostrado na figura 1.
Figura 1 - Estrutura básica de um MRP.

Fonte: Elaboração do autor.
21
2.2.1 OpenERP
O OpenERP é um software de gestão empresarial de código aberto licenciado sob a

licença AGPL (Affero General Public License – Licença Pública Geral Affero) foi fundada
pelo atual CEO (Chief Executive Officer – Diretor Executivo), Fabien Pinckaers, em 2005. A
empresa conta com cinco escritórios, sendo dois na Bélgica, um na Califórnia, um em
Luxemburgo e um na Índia, tendo sua sede estabelecida na Bélgica. (OPENERP, 2013)
Como pode ser observada na figura 2, sua estrutura é dividida em módulos que se
integram através de um banco de dados em comum. Deste modo, o trabalho dos usuários é
minimizado, pois evita-se o retrabalho de entrada de dados, e consequentemente aumenta-se a
produtividade. Os módulos disponíveis para instalação abrangem todas as áreas de uma
empresa, indo desde a área fiscal até a de planejamento de produção. (OPENERP, 2013)
Figura 2 - Módulos do OpenERP integrados ao banco de dados central.

Segundo os desenvolvedores da empresa, o OpenERP conta com aproximadamente

350 módulos, os quais foram traduzidos para diversos idiomas, tornando a sua adequação à
empresa mais simples e rápida em relação a outros ERP’s open source disponíveis
(OPENERP, 2013).
22
A arquitetura do OpenERP, apresentada na figura 3, é baseada no modelo MVC

(Model – View - Controller) e dividida em três camadas: base de dados, servidor e cliente.
Figura 3 - Estrutura MVC do OpenERP.

Fonte: OPENERP (2013).
O módulo servidor é escrito em linguagem Python e a comunicação do cliente com o

servidor é feita por interface XML-RPC, enquanto o banco de dados utilizado é o
PostgreSQL2. Cada módulo contém os arquivos em Python para a implantação das suas
respectivas funcionalidades e os arquivos XML para a comunicação com o usuário
(OPENERP, 2013).
Atualmente, o OpenERP conta com uma comunidade brasileira que tem como
objetivo traduzi-lo e adaptá-lo para nossos padrões contábeis e fiscais. Sua principal parceira
brasileira é a empresa Akretion3, que administra grande parte dos projetos propostos na
comunidade assim como oferece cursos sobre sua implantação e uso, principalmente no
ambiente fiscal, proporcionando uma maior confiabilidade em relação as atualizações e
padronizações no ambiente fiscal brasileiro (OPENERP, 2013).
Além disso, a Akretion também oferece serviços de migração de sistemas já existentes
para o OpenERP tendo como foco principal a migração do banco de dados e a criação de
módulos personalizados (OPENERP, 2013).
2
Site do banco de dados PostgreSQL: http://www.postgresql.org/
3
Site da empresa Akretion: http://www.akretion.com/
23
2.2.2 Compiere ERP

O Compiere foi o primeiro ERP de código fonte aberto, criado no ano de 1999 por
Jorg Janke, ex-diretor de desenvolvimento da empresa Oracle e é um dos projetos mais ativos
da plataforma de downloads sourceforge. (ACCORTO, 2013)
Hoje, Jorg Janke administra o desenvolvimento do software na empresa Compiere Inc.
na cidade de Nova York dando suporte para sistemas implantados em mais de 10 países.
Em 2007 a empresa Compiere Inc. expandiu seus produtos adicionando as versões
professional, enterprise e cloud edition e manteve a versão community edition como uma
versão de código aberto. (COMPIERE, 2013)
Sua arquitetura segue o modelo MVC e assim como o OpenERP, o Compiere é
dividido em módulos, o que facilita na implementação de novas funções ou apenas a
instalação de módulos que a empresa irá utilizar assim como apresentado anteriormente na
figura 2.
Tanto o servidor, quanto os módulos deste software são escritos em linguagem Java e
o sistema está integrado ao banco de dados Oracle. Contudo, em 2006 houve um forte
investimento da Finep, um órgão ligado ao Ministério da Ciência e Tecnologia, para que
outros bancos de dados de código aberto conseguissem se integrar com o ERP, entre eles
estão o PostgresSQL e o MySQL.
Em 2008, por solicitação da empresa Compiere Inc. a página oficial da comunidade
brasileira4 foi retirada do ar já que o domínio, segundo a empresa é de sua propriedade, não
podendo pertencer a qualquer outro órgão ou pessoa física. (ADEMPIERE, 2013). Após esse
problema a comunidade brasileira migrou para o domínio do Adempiere Brasil, que é
considerado por ela o verdadeiro modelo open source do ERP Compiere (ADEMPIERE,
2013).
2.2.3 OpenBravo
O OpenBravo é um sistema desenvolvido em 1999 por dois estudantes da
universidade de Navarra, Nicolas Serrano e Ismael Ciordia. A princípio, , o sistema foi
desenvolvido somente para o gerenciamento da universidade em que estudavam e está
licenciado sob a licença GPL, tendo se expandido para outras áreas posteriormente..
4
Link usado pela comunidade brasileira do Compiere: http://www.compierebrasil.com.br
24
Umas das razões pelas quais o OpenBravo teve um grande crescimento de mercado se
deve ao seu desenvolvimento inteiramente voltado para tecnologias de internet, ou seja,
aquelas que utilizam os navegadores web para serem acessadas.
O OpenBravo é um sistema que se baseia no modelo MVC, com seu cliente e servidor
desenvolvidos utilizando a linguagem Java. Como esta linguagem é multiplataforma, o
usuário tem a liberdade de utilizá-lo em sistemas operacionais distintos, já que basta apenas
ter instalado em seu computador ou servidor o Java Virtual Machine (OFICINA1, 2014).
Os bancos de dados suportados pelo ERP em questão são Oracle e PostgreSQL, sendo
que este último é o preferencial pois é inteiramente desenvolvido sob uma licença pública
GNU.
A principal representante no Brasil é a empresa Disoft, a qual assinou um contrato
para a liderança e distribuição do software open source em 2012, contudo esta parceria existe
desde o ano de 2010 (DISOFT,2014).
Assim como o OpenERP, o OpenBravo tem uma comunidade brasileira bastante ativa.
Esta comunidade é liderada pela Disoft, que é a principal responsável pelo desenvolvimento e
customização de módulos para a adequação com as leis fiscais e contábeis brasileiras
(DISOFT,2014).
2.3 Licenças de Software

Uma licença de software descreve as ações que o usuário de um determinado
programa deve seguir para utilizá-lo, assim como para poder alterá-lo ou não dependendo do
modelo de licença. (SILVEIRA, 2004)
Na década de 50, as empresas que produziam computadores não davam muita
importância para a questão de software, mantendo o foco principalmente no hardware e
dando a liberdade para os usuários modificarem os softwares (Sabino e Kon, 2009).
Com o passar do tempo, essas empresas foram percebendo que perdiam muito
dinheiro não cobrando royalties pelas cópias. Ao perceber isso, Bill Gates em 1976, escreveu
uma carta, reproduzida na Figura 4 Na carta, Bill Gates afirma que tais licenças livres não
permitiam que fossem criados programas com qualidade. Surgiram assim as licenças de
software proprietárias e como resposta, as licenças de software livre (Sabino e Kon, 2009).
25
Figura 4 - Carta escrita por Bill Gates.

Fonte: LOCKWOOD, 2008.
Arantes (2009) chama a atenção em seu artigo para a diferença entre copyright,
direitos autorais, patentes e domínios. O autor afirma que copyright trata dos direitos à cópia e
reprodução do trabalho, a patente visa proteger os direitos do autor e os domínios são as
pessoas ou instituições aos quais se restringem os direitos de cópia.
O autor também alerta que a diferença entre a patente e o copyright, é que a patente
deve ser reconhecida e registrada legalmente, enquanto o copyright não. Sendo assim, a
patente trata mais do registro oficial do projeto ou ideia, e o copyright de maneira parecida
com o direito autoral, trata da expressão da ideia não precisando ser registrada em cartório
(ARANTES, 2009).
26
No Brasil há uma lei que protege os direitos autorais dos autores, contudo, ela tem um prazo
de validade de 70 anos após a morte do autor, tornando a obra de domínio público e dando a
permissão para que qualquer pessoa possa explorar o trabalho da forma que melhor lhe
convém.
2.3.1 Licenças Proprietárias

Licenças proprietárias são aquelas que restringem alguns direitos ao criador do
software, normalmente, direitos sobre o código fonte e suas possíveis alterações e/ou
distribuições e vendas. (FERREIRA, 2007)
Essas licenças começaram a ser utilizadas a partir do ano de 1976, após Bill Gates
escrever a carta apresentada na Figura 4. Contudo, Silveira (2004) afirma em seu livro que as
licenças proprietárias tendem a evitar o desenvolvimento do conhecimento humano, já que se
baseia no conhecimento para se criar algo, mas não o compartilha para que o mesmo continue
se desenvolvendo.
Silveira (2004) também lembra que o conhecimento cresce quando algo é
compartilhado e não fica restrito a um grupo de pessoas, empresa ou instituição.
2.3.2 Licenças Públicas

As licenças públicas são conhecidas também como licenças open source ou em
português, licenças de código aberto, pois segundo suas principais políticas, o software
desenvolvido sobre a licença pública deve deixar disponível para qualquer interessado o
código fonte da sua aplicação. (AFFERO, 2013)
Como já citado anteriormente, as licenças públicas foram criadas em resposta à
restrição de softwares em 1976, e desde então vem ganhando força principalmente com as
distribuições de sistemas operacionais baseadas em Unix.
A FSF (Free Software Foundation)5, fundada por Richard Stallman em 1985, foi a
responsável por introduzir os conceitos de software livre definindo-o como qualquer
programa de computador que pode ser usado, copiado, estudado e redistribuído sem qualquer
restrição.
5
Site da organização: https://www.fsf.org/resources/stickers
27
O site da empresa Affero6, criadora de uma das licenças pública sobre softwares
livres, afirma que tal iniciativa vai muito além de apenas um programa gratuito, ela está
ligada à liberdade de expressão, como já citado anteriormente, com o intuito de que qualquer
pessoa possa acessar seu código e aperfeiçoa-lo conforme sua necessidade ou preferência.
(AFFERO, 2013).
As principais licenças estão ligadas ao projeto GNU da FSF sendo que a maioria dos
programas de computador de código aberto publicados atualmente utiliza a GPL (General
Public License – Licença Pública Geral), LGPL (Lesser General Public License – Licença
Pública Geral Reduzida) ou a AGPL (Affero General Public License – Licensa Pública Geral
Affero), assim como o sistema central abordado nesse trabalho.
Ainda há outras licenças como a BSD (Berkeley Software Distribution) License, MIT
(Massachusetts Institute of Technology – Instituto de Tecnologia de Massachusetts) License,
Apache License V.2.0, Artistic License, Mozilla Public License 1.1, também conhecida como
MPL 1.1 e a Academic Free License (AFL) (Sabino e Kon, 2009).
2.3.2.1 Licença AGPL

A licença AGPL foi publicada em 19 de novembro de 2007 com o intuito de corrigir
falhas de sua licença antecessora, a GPL. Atualmente ela está em sua versão número 3 e não
envolve apenas software, podendo ser aplicada em outras obras open source como serviços
utilizados através de um computador (Sabino e Kon, 2009).
Esta licença procura conceder a liberdade aos novos usuários, indo muito além do
preço, segundo a AFFERO(2007), criadora da licença em questão, a licença AGPL foi
desenvolvida para garantir a liberdade de distribuir cópias, editar o código fonte e até usar
parte desse código em outros programas.
Na documentação disponível no site da empresa Affero também é citado que a licença
de software livre traz benefícios não só para os usuários, mas também para os
desenvolvedores, pois quando modificações no código fonte são feitas por terceiros e
disponibilizadas para todos que queiram utilizá-las, o software evolui, podendo assim crescer
cada vez mais com um maior número de voluntários no seu desenvolvimento (AFFERO,
2007).
6
Site da empresa Affero: http://www.affero.com.br/
28
Apesar de ser criada para corrigir as falhas de sua antecessora, a AGPL é considerada
uma licença diferente, que permite novas funções e não apenas correções da GPL.
Algumas das principais especificações feitas pela licença AGPL são: (AFFERO,
2007)
1. Disponibilizar o código fonte para qualquer pessoa que queira utilizá-lo;
2. Permissão para adicionar termos que anulem ou acrescentem algo à licença em
um projeto;
3. Direito de reutilizar, modificar e repassar o código fonte para terceiros.
2.4 Metodologia de Implantação

As metodologias de implantação são fundamentais para o sucesso do processo de
implantação de sistemas em todas as áreas. Na área de TI (Tecnologia da Informação) ela se
torna quase que obrigatória, pois além de agilizar todo o processo, facilita e eleva as chances
de sucesso na introdução do sistema.
Gonçalves (2010) cita em seu trabalho que a implantação é a parte que irá definir o
sucesso ou não na inclusão do software na corporação, e que estar preparado para fazer
manutenções nesta fase é de extrema importância, já que é no início da implantação e do uso
pelos usuários, que as falhas ocorrem em maior quantidade.
Um bom gerenciamento do escopo também fará com que a implantação tenha sua
porcentagem de chance de conclusão elevada, pois é nessa fase que serão envolvidos os
escopos de processos de negócio, as unidades da empresa que fazem parte da implantação, as
funcionalidades implementadas no ERP, a tecnologia que será substituída, atualizada e
integrada e a troca de dados entre os softwares (ALVARENGA, 2003).
Quando se trata da substituição de um sistema já existente por outro, há três tipos de
conversões de sistemas abordadas por Laudon e Laudon (2011) em seu livro. A primeira é a
conversão em paralelo onde os dois sistemas são executados em paralelo por algum tempo até
que esteja seguro em relação ao novo sistema e o antigo seja desativado. A segunda é a
conversão direta do sistema antigo, onde o mesmo é totalmente substituído pelo sistema novo
em uma data pré-determinada, o que o torna um método crítico, pois há o risco de não ter um
sistema de apoio para os casos de emergência. Por último, há a conversão em fases, a qual se
baseia em introduzir o novo sistema em camadas, ou seja, eles são divididos em módulos que
são implantados gradualmente.
29
2.5 Custo Total de Propriedade

O Custo Total de Propriedade, usualmente conhecido por sua sigla proveniente do
termo em língua inglesa TCO (Total Cost Ownership), é utilizado para auxiliar na avaliação
dos custos e dos benefícios relacionados à compra de produtos para a gestão da tecnologia da
informação (GARTNER, 2013).
Basicamente, o TCO envolve os custos relacionados a planejamento, aquisição,
operação, manutenção e alienação do produto avaliado. Isto inclui gastos com hardwares,
licenças, manutenção, upgrades, suporte técnico, tempo ocioso com falhas (downtime),
segurança, treinamento, administração, tempo de operação, entre outros (ECOS, 2013).
Os custos podem ser classificados como diretos, tais como: aquisição de hardware e
software, suporte, gerenciamento, desenvolvimento e comunicação; e custos indiretos, por
exemplo: custos com usuário final e custos a partir de perda de produtividade devido a
alguma parada (ECOS, 2013).
2.6 Trabalhos Relacionados

O trabalho de DA SILVA(2010) faz uma análise de um sistema de gestão empresarial
em uma empresa de segmento automotivo. Seu projeto faz um estudo de caso dando maior
ênfase às opiniões dos usuários após a implantação do sistema.
Foram usados questionários com perguntas avaliativas sobre o sistema e, após a
conclusão de cada pergunta, o autor faz uma análise geral tomando como base as respostas de
cada entrevistado e identifica a importância de algumas atividades como os treinamentos para
usuários (DA SILVA, 2010).
NETO(2004) faz uma abordagem de todo o processo na implantação de um sistema
ERP, em seu trabalho foi realizado um estudo de caso que envolve desde os critérios para a
seleção de um sistema, ou seja, o que é considerado pela empresa ao optar por um sistema até
a pós implantação.
Além de abordar todo o processo de implantação, NETO(2004) também apresenta
uma base teórica para o leitor entender o que está sendo feito em cada fase do seu projeto,
além dos conceitos usados, assim como a sua importância em seu meio.
Já o trabalho de LIMA(2010) aborda os softwares de licença livre de forma mais
generalizada, citando alguns casos de uso por parte do governo brasileiro em instituições de
grande porte, como por exemplo o exército, citando as suas vantagens e os cuidados que
30
devem ser tomados. LIMA(2010) aborda também alguns outros casos de implantações de
software livre realizadas com sucesso em grandes instituições e corporações.
Também são apresentadas definições de alguns sistemas operacionais de código
aberto, como o Ubuntu, Mandriva e Kurumim, citando as suas principais funções, bem como
empresas de grande porte e reconhecidas mundialmente que os utilizam.
Contudo, este trabalho se diferencia dos demais citados por ser um estudo de caso de
um sistema de gestão empresarial específico e open source, analisando todo o processo de
implantação, inclusive a escolha do sistema e uma análise pós-implantação.
O ramo de atividade empresarial também se difere dos outros trabalhos, sendo que o
local de instalação do software é relevante para a seleção de módulos e necessidades da
criação ou extensão de módulos, assim como a adequação às leis fiscais brasileiras para
atender os requisitos da empresa.
Capítulo
31
3 Metodologia
Neste capítulo será descrito o processo utilizado no estudo de caso, que envolve desde
a escolha até a implantação do OpenERP. Para o desenvolvimento do presente trabalho, será
utilizada a metodologia para o desenvolvimento de projetos adotado pela empresa alvo deste
estudo, a qual também será descrita em maiores detalhes neste capítulo.
3.1 A empresa
A empresa onde este trabalho foi realizado situa-se na cidade de São João da Boa
Vista. A mesma foi fundada no ano de 1995 e é considerada uma empresa de pequeno porte
de acordo com a artigo nº 2 do Estatuto da Micro e Pequena Empresa, os quais envolvem
número de funcionários e lucro anual. Esta empresa atua no ramo alimentício e conta com
aproximadamente 80 produtos no mercado, que são comercializados em todo o país através de
distribuidores e representantes. (BRASIL, Lei nº 9.841, de 5 de Outubro de 1999, 1999).
A necessidade da instalação de um novo sistema ERP veio após os diretores da
empresa notarem que o sistema antigo já não conseguia sanar as necessidades dos setores. Um
exemplo crítico foi o setor de faturamento ter necessidade da emissão das notas fiscais
eletrônicas, atividade que não estava disponível no sistema anterior.
Por ser uma empresa de pequeno porte a corporação conta com duas pessoas na área
de TI, as quais serão responsáveis por executarem a implantação do sistema de gestão
empresarial proposto neste trabalho.
3.2 Metodologia de implantação utilizada

Este trabalho será desenvolvido utilizando um padrão de metodologia próprio para
implantação de produtos ou projetos por escolha da própria corporação onde o sistema será
instalado, não cabendo a possibilidade da utilização de uma metodologia de implantação com
maior status no mercado de ERP’s. Esta metodologia não foi alterada, pois a mesma está
adaptada e consolidada dentro da organização, o que facilita o desenvolvimento e aceitação
dos colaboradores.
A metodologia se divide em quatro fases. Tais fases estão descritas abaixo:
32
Fase 1 – Levantamento de requisitos: Na primeira fase será feita uma análise dos
requisitos do módulo a ser instalado, observando as necessidades da área e dos principais
usuários. Planilhas, funcionalidades do sistema antigo e até mesmo tarefas realizadas
manualmente serão levadas em conta nesse levantamento, a fim de centralizar todas as
atividades possíveis no sistema.
Na fase 1 também são listadas as necessidades com relação a área de programação e
trabalhos com relação a implementação e implantação do módulo.
Fase 2 – Plano de ação: A partir dos requisitos levantados na fase 1, um plano de ação
será proposto para ser executado na fase 3, auxiliando a implantação. O plano de ação deve
incluir a organização das atividades executadas na implantação do módulo, assim como as
tarefas que representam riscos e devem ter um cuidado maior no momento de sua execução.
Nessa fase também são realizados os trabalhos de pesquisa de softwares e ferramentas
para facilitar o uso e a instalação, principalmente no caso do projeto ser de grande ou médio
porte.
Fase 3 – Desenvolvimento e Implantação: Após ter escolhido o sistema e definido o
plano de ação, é dado início à fase de implantação e migração dos dados. Nesta fase o plano
de ação apresentado na fase 2 será colocado em prática, tentando sempre seguir o que foi
planejado mas também sabendo que imprevistos podem ocorrer. A fim de diminuir as chances
de imprevistos é realizado em paralelo a esta, a fase testes. Nos testes são avaliados os acessos
aos dados importados e a simulação das atividades que serão executadas, visando corrigir os
erros encontrados de forma breve. Nesses testes o usuário utilizará o módulo trabalhado e
deve informar aos responsáveis o que pode ser melhorado e quais requisitos estão faltando.
Fase 4 – Avaliação: Nesta fase será analisado se o sistema atendeu aos requisitos
satisfatoriamente. Essa análise será realizada por meio da observação da equipe de TI, bem
como pela opinião dos usuários visando avaliar a satisfação em relação ao uso do sistema.
Os resultados dessa análise serão utilizados para o desenvolvimento futuro do sistema
e para solucionar problemas que podem afetar instalações e desenvolvimentos de outros
programas na empresa.
É importante ressaltar que na instalação de um sistema ERP, que é composto por
diferentes módulos e que abrange diferentes áreas da empresa, as fases são aplicadas aos
módulos instalados e não ao sistema integrado como um todo. Após a instalação de todos os
módulos necessários, é feita uma análise tomando como base a fase quatro da metodologia
33
descrita acima, para que assim se tenha a junção dos subprojetos e a finalização do projeto
principal.
Outra questão importante, se deve ao fato de a instalação do OpenERP ser feita em
paralelo com a substituição do sistema utilizado na empresa, ou seja, a cada fase implantada
no ERP novo a mesma será desativada no antigo a fim de adaptar os usuários de forma menos
traumática.
Na figura 5 são apresentadas as fases existentes e as suas respectivas ordens de
execução.
Figura 5 - Metodologia de implantação.

A implantação do novo sistema será feita em paralelo com o ERP já utilizado na

empresa. Este sistema de gestão empresarial vem sendo utilizado há sete anos pela corporação
e integra as áreas de vendas, faturamento, financeiro e recursos humanos, porém alguns dos
módulos do atual sistema utilizados nestas áreas, de acordo com a direção da empresa, estão
ficando defasados em relação aos requisitos atuais da empresa e sem perspectiva de
possibilidade de adequação. Diante desta situação, a direção optou por iniciar um processo de
migração de sistema.
O treinamento de usuários também está enquadrado nas atividades vitais para o
sucesso na instalação de um sistema ERP, levando em conta que um usuário mal adaptado ao
sistema pode fornecer informações errôneas sobre as funcionalidades já implantadas do
mesmo, aumentando o trabalho de outros envolvidos na implantação e alterando
consequentemente os resultados da análise pós-implantação.
3.3 Recursos de hardware e backup da empresa

Atualmente a empresa conta com dois servidores com o sistema operacional
GNU/Linux e 15 computadores ligados em rede, tanto cabeada quanto wireless.
34
Os backups das principais pastas dos servidores são feitos em discos rígidos externos,
em horários em que o uso da rede é baixo, deste modo não ocorre perda de desempenho aos
usuários que acessam as informações armazenadas nos servidores.
Para acesso externo há um link de internet dedicada com endereço IP fixo, sendo
necessário apenas configurar alguns aplicativos para que haja um redirecionamento de portas
quando o usuário for acessar o servidor em uma rede externa.
O servidor onde o sistema ERP será instalado conta com as seguintes configurações de
hardware:
 Processador Intel Xeon X3430 2.4GHz 8MB L2
 Memória 2GB DDR3(1x2GB) 1333MHz ECC UDIMM
 Unidade Óptica DVDRW
 Gavetas Hot-Swap: Gavetas Hot-Swap 4HDD SAS/SATA 3.5in
 Unidade de Disco Rígido 250GB SATA 7200rpm 3.5in Hot Swap
 Unidade de Disco Rígido 500GB SATA 7200rpm 3.5in Hot Swap
 Fonte 460W Fixa
 2 Slots PCI Express x8, 1 PCI Express x4, 2 PCI 32bits/33MHz
 Controladora de Disco RAID-BR10il SAS/SATA RAID 0,1,1E
 Rede: 2x 10/100/1000Mbps
 Portas: 7 USB, 1 Serial, 1 Vídeo
 Form Factor 5U Tower
 Gerenciamento UEFI, IBM Integrated Management Module (IMM)
 Teclado USB Preferred Pro EUA 103P
 Mouse Esfera USB 2 botões
E como sistema operacional o servidor está executando o sistema Linux Ubuntu
Server 12.04.
3.4 Fatores considerados para a instalação do ERP

A implantação ou substituição de um ERP é feita tomando todos os cuidados
possíveis, já que os dados da empresa serão manipulados constantemente. Uma má
implantação pode gerar um estresse maior para a empresa e para seus empregados, tendo
como risco o descontrole de dados e fluxos podendo levar a corporação, em casos extremos, à
falência.
35
Para uma instalação e implementação bem sucedida foram considerados alguns itens
que podem aumentar as chances de sucesso e diminuir os riscos de imprevistos durante tal
processo. São os seguintes:
 Escolha entre um sistema open source ou proprietário: No caso do uso de um ERP
de código aberto (open source) a empresa terá mais responsabilidades, pois terá
que contratar e administrar os funcionários responsáveis pelo trabalho. Porém, a
maioria dos sistemas open source, assim como os sistemas privados, possuem
empresas que prestam consultoria, ficando responsável por todo processo de
implantação e com a vantagem de que o código fonte estará disponível para a
empresa caso necessite realizar alterações.
 Disponibilidade de parceiros: A empresa procurou softwares com a maior
quantidade de parceiros e desenvolvedores para facilitar a implementação de
módulos específicos para o ramo de atuação da corporação. Identificados os
possíveis parceiros, foram analisados os serviços prestados pelas empresas e
programadores. Essa análise ocorreu através de ligações e contatos por e-mail
com clientes que utilizaram os serviços, com o intuito de verificar como foi a
conduta dos responsáveis em situações problemas e quais as medidas tomadas por
eles nesses casos.
 Divulgação: Todos os envolvidos na implementação, principalmente os usuários,
foram alertados sobre as mudanças futuras e a possível dificuldade para utilização
do sistema em um primeiro momento. Estes alertas foram feitos através de
reuniões, cartazes de avisos espalhados pela empresa, e-mails e workshops
realizados primeiramente com os principais envolvidos na implantação (diretores
e funcionários de TI) e depois com alguns funcionários que terão, a princípio,
maior contato com o sistema. É importante que os colaboradores estejam cientes
dos motivos para a alteração e saibam da sua responsabilidade para o sucesso do
processo, bem como dos benefícios esperados.
 Planejamento e treinamento: A empresa também planejou e contratou alguns
treinamentos para os funcionários que estavam diretamente envolvidos na
implementação do ERP. Para isso foi elaborado um fluxo de projeto planejando a
instalação de cada módulo. Este fluxo inclui o tempo de implementação,
integração, treinamento para os usuários e outros fatores que demandam maior
36
cuidado e que devem ser feitos com cautela e sem pressa para não haver erros de
proporções elevadas.
Após levantar os requisitos necessários para atender a empresa, foi necessário começar
uma pesquisa sobre os sistemas disponíveis no mercado e avaliar o seu custo.
Optou-se por usar um sistema open source, pois o mesmo permite que em caso de
problemas com fornecedores iniciais, outros programadores podem ser contratados já que o
sistema esta documentado sob a licença GNU.
Os sistemas de código aberto também se tornam vantajosos no custo total, já que um
sistema desse porte requer um grande investimento da empresa em sua implantação e
manutenção pós-implantação.
3.5 Avaliação dos sistemas disponíveis

Para a escolha do sistema a empresa tomou como base os processos listados no
capítulo 3.5, começando pela escolha do sistema open source, já que a empresa possui
funcionários que poderão ser capacitados para a instalação.
Dos sistemas open source pesquisados, o que mais se destacou foi o OpenERP por já
ter uma comunidade de discussão e participação na implementação e melhorias nos módulos
muito ativa e relativamente grande em relação os demais sistemas.
Contudo, o OpenERP perde pontos por sua linguagem de programação (Python) assim
como o banco de dados (PostgreSQL), pois os mesmos não eram de domínio dos funcionários
que irão trabalhar nesta área. Neste quesito, os sistemas OpenBravo e Adempiere possuem
uma linguagem de maior conhecimento entre os responsáveis pela instalação, a linguagem
Java.
Os sistemas que mais se destacaram pela quantidade de módulos, empresas e
programadores capacitados para no caso de uma possível consultoria foram o OpenERP e o
OpenBravo. Neste quesito, o sistema Compiere foi inferior, por seu histórico de divisão e
problemas relacionados ao código fonte que foi alterado de público para proprietário.
Em relação às empresas que oferecem treinamentos para a implantação dos sistemas, a
empresa concluiu que o mercado possui uma grande deficiência neste quesito. A única
empresa que apresentou contato satisfatório e que realiza treinamentos presenciais com maior
frequência é a empresa Akretion, representante do sistema OpenERP no Brasil. Com relação
as demais só foram encontrados manuais e livros para treinamento, em sua grande maioria
não traduzida para a língua portuguesa.
37
O resumo desta análise foi compilado e apresentado no quadro 1.
Quadro 1 – Quadro comparativo dos sistemas OpenERP, Compiere e OpenBravo.

REQUISITOS OpenERP Compiere OpenBravo
Domínio da linguagem de
programação pelos funcionários Baixo Elevado Elevado
de TI
Participação e colaborações nas
comunidades oficiais e não Alta Baixa Baixa
oficiais
Quantidades de módulos
Alta Baixa Média
públicos
Quantidade de programadores e
Satisfatório Baixo Satisfatório
empresas de consultoria
Ofertas de treinamentos Possui treinamentos Não possui Não possui
presenciais oficiais treinamentos treinamentos
Materiais para estudo Satisfatório Satisfatório Satisfatório
3.6 Instalação da base do software e módulos iniciais

O OpenERP opera em módulos e necessita de uma instalação base, sendo essa
fundamental para o bom funcionamento e a integração dos módulos.
Deve-se ter muito cuidado ao fazer esta instalação, visando que a base é que irá ser
responsável por implementar as tabelas e algumas das principais funções do software, como a
interface, banco de dados de usuários e permissões, entre outros.
O sistema abordado nesse trabalho necessita de uma base de dados específica para o
seu funcionamento, então a mesma foi instalada antes que se começasse a instalação do
núcleo do software. Após isso, foi feita a instalação da base do OpenERP em um dos
servidores e as alterações necessárias no sistema para o acesso via interface web dos usuários
e colaboradores.
As dificuldades surgiram conforme as configurações para manter o sistema com um
link para acesso externo estavam sendo feitas, já que o servidor usado para a instalação do
software não possuía compartilhamento de arquivos via web. Para resolver este problema foi
necessária a criação de configurações de segurança mais complexas e que dificultassem a
invasão do sistema em um possível ataque hacker.
A liberação do acesso via web no servidor foi feita através da abertura de portas
específicas para a troca de dados entre o computador cliente e o servidor ERP, assim como a
instalação do programa Apache HTTP.
38
Como a empresa já possuía um plano de internet com IP fixo não foi necessário a
contratação de um novo plano.
3.7 Módulo de vendas

O módulo de vendas possui como principal funcionalidade a realização de cotações,
aprovação e movimentação de pedidos de venda.
Nele o vendedor irá adicionar os pedidos feitos pelos clientes e caberá ao gerente de
vendas, ou seu superior, liberar ou não tal pedido para que o mesmo seja faturado, gerando
assim novas movimentações em outros setores.
A necessidade de instalar tal módulo primeiro se deve a falta de organização na
entrada de pedidos da empresa, sendo este realizado por vários meios, tais como: fax,
telefone, e-mail e talão de pedidos.
3.7.1 Módulo de vendas: levantamento de requisitos

A partir da análise proposta pela fase 1, foram levantados os seguintes requisitos
principais para serem analisados no módulo de vendas e que deverá ser capaz de proporcionar
ao usuário as funções de:
 Realização de cadastro de clientes com todos os seus dados para cálculo de
entrega e impostos tais como IPI, Substituição Tributária, ICMS, entre outros;
 Realização de cadastro de produtos com os dados para calculo de impostos,
disponibilidade em estoque, empacotamento e quantidade mínima e máxima para
a realização de pedidos de compra;
 Possibilitar que o vendedor realize pedidos de qualquer localidade com acesso a
Internet;
 Compatibilidade com diversos tipos de dispositivos, como computadores,
notebooks e visando principalmente os dispositivos móveis;
 Centralização do envio de pedidos por meio do sistema e a eliminação dos outros
meios de envio para digitação posterior pelo setor de faturamento da empresa.
 Função para a adição de tabelas de preços visando que a empresa divide os
clientes em grupos, nos quais são levados em conta os impostos locais, os
contratos realizados com redes de supermercados e distribuidores, custos de
logística e margem de lucro.
39
 Emissão de relatórios de vendas mensais e anuais para a realização de inventários

empresariais e análises de vendas por cliente, vendedor ou região ao qual o
comprador depende.
A partir desta análise serão realizadas pesquisas e observações para avaliar quais
destas funcionalidades o sistema a ser instalado irá suprir e em quais delas há um déficit. Com
isso, é possível redirecionar esforços nas implementações de novas funcionalidades para a
adaptação do sistema com os negócios da empresa, diminuindo os imprevistos de uma
implantação direta, ou seja, sem pré-pesquisas.
3.7.2 Módulo de vendas: plano de ação

O plano de ação do módulo de vendas tende a ser o mais complexo por ser o primeiro
contato com um módulo definitivo do sistema. Sabendo disso, foram tomados todos os
cuidados para diminuir os erros iniciais e que muitas vezes são descobertos muito tempo após
a finalização da instalação e o início de seu uso.
Seguem as tarefas listadas para o plano de ação deste módulo:
 Instalação da base do OpenERP no servidor;
 Liberação do sistema para acesso externo à empresa;
 Instalação do módulo de vendas e suas dependências;
 Importação de produtos, clientes e tabelas de preços;
 Treinamento dos usuários;
 Correção de possíveis problemas e bugs;
 Finalização do módulo de vendas com término de testes e alterações.
Acredita-se que com este plano, as chances de se ter imprevistos durante a execução
das atividades seja menor em caso do mesmo não ter sido feito.
3.7.3 Módulo de vendas: implantação

Com os módulos base já instalados foi iniciada a configuração do módulo de vendas
do sistema. Para este módulo, foi necessária a instalação do próprio módulo de vendas,
presente na base do ERP e o download dos módulos brasileiros que implementam as tabelas e
os registros das funcionalidades fiscais e particulares brasileiras, tais como os impostos
nacionais. Estes módulos podem ser adquiridos através do download da base de dados da
40
comunidade brasileira de suporte ao OpenERP, de modo gratuito já que todos possuem

código aberto para alterações e contribuições.
A configuração começa com a importação do banco de dados. Após alguns testes de
importação com a ferramenta presente na instalação do sistema não foi obtido sucesso na
gravação de dados e na geração da base de dados inicial. Segundo os próprios representantes
do sistema, tal funcionalidade ainda possui alguns erros de implementação que
impossibilitam, em alguns casos, a importação de dados através da interface. Estes testes
levaram em torno de duas semanas para serem executados.
Foi encontrada uma ferramenta open source desenvolvida por um dos sócios da
empresa Akretion, o francês Raphäel Valyi, que segundo sua proposta, permite fazer
importações em massa para o sistema e que utiliza como principal banco de dados o
PostgreSQL.
A API OOOR (Open Objects On Rails) é uma ferramenta criada na linguagem Ruby
com aproximadamente 2000 linhas de código e atualmente é utilizada para alterações em
massa nos bancos de dados PostgreSQL, sendo usado especialmente para o OpenERP
(AKRETION, 2014).
É uma API criada sob a licença GNU GLP e desenvolvida em grande parte pelos
proprietários da empresa Akretion, Raphaël Valyi e Renato Lima (AKRETION, 2014).
A API, desenvolvida na linguagem Ruby é de fácil instalação e manipulação,
tornando-se vantajoso para o projeto, agilizando as importações e alterações de dados,
principalmente em grande quantidade, para o banco de dados.
Após fazer a atualização do compilador da linguagem Ruby no servidor Ubuntu,
juntamente com a API OOOR Script, foi gerado um arquivo CSV (Comma Separated
Values). Este arquivo é proveniente do banco de dados do sistema ERP atual, e contém os
campos necessários e obrigatórios para a tabela de produtos acabados. Os produtos acabados
são provenientes da produção da empresa ou do fracionamento de matéria prima para a venda
a distribuidores e varejistas clientes da empresa.
O primeiro passo foi analisar quais eram os dados obrigatórios para o cadastro de
clientes. O OpenERP indica em sua interface através da cor azul alguns campos obrigatórios
como pode ser visto na figura 6. Então, esta funcionalidade foi utilizada para criar um arquivo
csv com as informações do banco de dados do sistema a ser substituído, e a montagem do
script em linguagem Ruby para uso com a API OOORScript.
41
Figura 6 - Tela de cadastro de clientes com alguns campos obrigatórios.

Os dados necessários para o cadastro de clientes no sistema são os seguintes: nome,

referência, razão social, tipo de pessoa, cnpj / cpf, tipo do endereço, rua, número, bairro, cep,
país, estado, município, telefone, e-mail, lista de preços de venda, posição fiscal, inscrição
estadual/ RG e tipo do parceiro.
Como neste cadastro o sistema ainda não possui as tabelas de preços, o campo foi
registrado com um valor nulo. Antes da finalização do módulo o mesmo deverá ser
preenchido para o cálculo de preço dos produtos de acordo com a localização do cliente e seu
contrato comercial com a empresa.
Surgiram alguns problemas na montagem do script de acesso ao banco de dados do
OpenERP. Estes problemas estavam ligados a sintaxe do código, pois a documentação da API
ainda não esta completa e por isso não tinha um arquivo ou manual em que se basear para
começar o seu uso.
Após alguns ajustes do código, os dados foram importados corretamente para o
sistema e a lista para a importação de produtos pode ser criada. Este processo levou 45 dias
para ser concluído, considerando como marco inicial o começo da utilização do programa
OOOR.
Após a importação de clientes foi iniciada a importação de produtos. Foram
registradas as unidades padrões através da interface do sistema, já que estas eram poucas e os
demais dados do sistema ERP antigo foi importado para o arquivo csv. Os dados baixados
42
foram os seguintes: nome, referência, código de barras EAN13, tipo de produto, preço de
venda base, categoria, unidade de medida padrão e classificação fiscal.
Os campos de tipo de produto, categoria, unidade de medida padrão e classificação
fiscal já foram cadastrados na instalação dos módulos ou manualmente.
O script para a importação dos dados de produto foi baseado no usado para a
importação dos dados de clientes, mudando apenas o nome dos campos do arquivo, assim
como os campos das tabelas aos quais os dados seriam vinculados e cadastrados.
Os parâmetros exigidos na importação dos dados dos produtos foram os seguintes:
nome, código de referência, preço, tipo do produto, tipo fiscal, método de aquisição, método
de reposição, origem, método de formação de custo, categoria, unidade de medida padrão,
unidade de medida de compra, valorização de inventário e classificação fiscal, conforme pode
ser observado na figura 7.
Figura 7 - Tela para cadastro de produtos manufaturados

O cadastro do produto foi feito com um preço base, pois após a importação deste itens,
serão feitos os cadastros das tabelas de preços de acordo com as politicas comerciais da
empresa. Estas atividades de importação dos dados de produto juntamente com o cadastro,
demoraram vinte dias.
43
Assim como os demais dados em grande quantidade, as tabelas de preços foram

importadas usando a API OOOR Script. O ERP conta com um cadastro da lista de preço e
uma subdivisão contendo as versões destas listas, portanto, ao importar o arquivo CSV para o
banco de dados PostgreSQL eram indicados os arquivos com os dados, a lista de preço e a sua
versão. Essa subdivisão irá facilitar as mudanças e recadastramentos de preços futuramente,
possibilitando que a empresa mantenha um histórico de suas variações de preços no software.
Após a importação das tabelas de preços foi necessário o recadastramento das tabelas
pertencentes a cada um dos clientes, já que esta informação foi perdida. Para isso, foi criado
um script baseado no banco de dados do sistema utilizado atualmente e integrado com o
banco de dados do OpenERP afim de preencher e atualizar os clientes.
Na realização de testes com as tabelas de preços cadastradas, percebeu-se que os
sistemas utilizados em paralelo estavam calculando preços diferentes para pedidos iguais.
Apesar das diferenças serem pequenas o ideal é que ambos estejam idênticos, então foram
feitas correções nos parâmetros que se diferenciavam por conterem casas decimais depois da
vírgula a mais em um do que no outro.
A importação e correção de erros nas tabelas levaram quinze dias para serem
concluídos, pois apesar de a empresa ter 12 tabelas diferentes, o código para a importação de
cada uma é o mesmo, mudando apenas o arquivo CSV utilizado.
E por último foram feitos os cadastros e a liberação de acessos de cada usuário, sendo
que o módulo possui três níveis de acesso: usuário com acesso somente aos seus pedidos,
usuário com acesso a todos os pedidos e gerente, o qual possui acesso completo ao módulo
podendo editar, visualizar e excluir qualquer informação.
Com isso foi realizado um treinamento com os vendedores da empresa e os
responsáveis pelo recebimento dos pedidos para digitação no outro sistema. O supervisor de
vendas recebeu o treinamento inicial, e ficou responsável por treinar os demais vendedores
externos, já que seu contato com eles é mais frequente. Após o treinamento, os acessos foram
liberados e cada um recebeu instruções para a mudança da senha padrão.
Ainda na primeira semana de uso foi notado que o acesso externo ao ERP estava lento,
para solucionar tal problema foram feitos testes de conexão com o servidor e chegou-se a
conclusão de que a taxa de upload estava baixa, tornando necessária a contratação de um novo
plano de internet pela empresa.
Como o local em que a empresa está situada não tem acesso a redes de fibra óptica, o
plano contratado foi de internet a rádio, que apesar da baixa velocidade será o suficiente para
44
os acessos apenas para a passagem de pedidos de venda pelos usuários. Levando em conta a
taxa de upload que será utilizada é necessário que a empresa tenha ao menos um plano de
internet com 1 Mbps de taxa de upload, o que pode variar dependendo da quantidade de
acessos feitos simultaneamente ao programa.
Com alguns meses de uso os números dos pedidos chegaram ao “SO999” e houve um
erro no software por não conseguir criar novos números de referências para os pedidos. A
solução encontrada foi a adição de mais casas decimais no menu de configurações do ERP, o
que solucionou tal problema.
Outro problema que também foi encontrado com o uso do software foi a duplicação
dos itens de alguns pedidos. Este problema foi solucionado através de consulta e postagem no
grupo da comunidade OpenERP Brasil. Tal problema já havia sido identificado por outros
usuários, e um pacote de códigos foi criado para resolvê-lo.
Com a finalização da instalação do módulo de vendas, podemos montar o quadro dos
requisitos cumpridos e os não cumpridos pelo módulo, conforme apresentado abaixo.
Quadro 2 - Requisitos cumpridos e não cumpridos inicialmente pelo módulo de vendas.

MÓDULO DE VENDAS
Requisito Status
Cadastro de clientes e cálculo de impostos Cumpriu, porém precisou de
módulo complementar
Cadastro de produtos e cálculo de impostos Cumpriu, porém precisou de
módulo complementar
Realização de pedidos via web Cumpriu completamente
Interface responsiva Não cumpriu o esperado
Centralização do envio de pedidos Cumpriu completamente
Adição de tabelas de preços de acordo com cada Cumpriu completamente
tipo de cliente
Todo este processo ocorreu em aproximadamente cinco meses, pois houve a

necessidade de um maior tempo para teste nesse novo método de passagem de pedidos e a
adequação dos vendedores e os demais envolvidos com este módulo.
3.8 Módulo de relatórios de entrega

Houve a necessidade da criação de um módulo para o registro de ocorrências em
entregas para clientes. A empresa decidiu programar este módulo para podermos analisar
melhor o nível de complexidade da criação de módulos, e a partir disso avaliar a possibilidade
45
do desenvolvimento de alguns itens ou alterações do sistema na própria empresa, diminuindo

os gastos com consultoria de empresas terceirizadas.
3.8.1 Módulo de relatórios de entrega: levantamento de requisitos

O módulo de relatórios tem como principal necessidade o controle nas divergências de
entrega, tornando aos interessados o acesso e a edição mais fácil das informações, assim como
o controle e combate aos problemas que mais incidem (falta de produtos, notas fiscais com
divergências de preço, falta de pedido no local, etc) e que geram um custo de reentrega ou
devoluções para a empresa.
Com ele também houve a chance de começar um desenvolvimento, mesmo que
simples, de um módulo para o OpenERP para que futuramente outras funções mais complexas
possam ser implementadas ou alteradas em seu código fonte.
Após ser identificada a necessidade da implantação do módulo para registro dos
relatórios de entrega, foram levantados os requisitos com a ajuda dos principais responsáveis
pelos setores de operações, faturamento e alguns motoristas com maior experiência.
As necessidades levantadas após a reunião foram as seguintes:
 Estudar o funcionamento dos módulos na aplicação base do sistema;
 Conhecimento da linguagem de programação e a sua sintaxe;
 Os campos necessários são: número do pedido, data da ocorrência, nome do
cliente, explicação da ocorrência, motoristas envolvidos, solução encontrada;
 Reutilização de dados já cadastrados no sistema, tais como, cidades, clientes e etc,
para que a reutilização de dados já cadastrados agilize a entrada de novas
ocorrências;
 O cadastro das ocorrências deve ser simples e direto, ou seja, as descrições devem
ser breves;
 Os registros devem estar organizados por data da ocorrência a fim de facilitar a
visualização dos últimos problemas adicionados à lista;
3.8.2 Módulo de relatórios de entrega: plano de ação

O módulo de relatórios de entrega foi a primeira oportunidade de se programar um
módulo inteiro para o sistema. Pensando nisso os seguintes cuidados devem ser tomados para
que o plano de ação possa ocorrer conforme o esperado.
 Criar os arquivos necessários para o módulo;
46
 Programar as funções de cadastros;

 Criar banco de dados;
 Criar interface;
 Fazer testes e correções iniciais;
 Treinamento dos usuários;
 Disponibilizar módulo para os usuários;
 Correções de problemas e bugs;
 Finalização do módulo de relatórios.
 Com este plano de ação espera-se que as chances de erros e imprevistos na escrita
do código e implantação do módulo diminuam agilizando a conclusão do mesmo
3.8.3 Módulo de relatórios de entrega: implementação e implantação

Para a criação de um novo módulo, o sistema OpenERP versão 6.1 exige que a pasta
que irá representar o módulo esteja localizada em um diretório mapeado pelo arquivo de
configuração como um diretório de módulos.
Cada pasta deve conter arquivos com nomes específicos para seu reconhecimento, são
estes:
Arquivo “__init__.py” : usado para indicar os arquivos que serão importados para a
cliação do novo módulo.
Arquivo “__openerp__.py”: arquivo onde estão as informações de nome do módulo,
versão, autor(es) do código, categoria, dependência de outros módulos, descrição, indicação
dos arquivos XML utilizados e uma variável booleana para verificar se o módulo esta
instalado.
Arquivo “nome_do_modulo.py”: contém o código para a execução das funções,
criação de tabelas e colunas no banco de dados (figura 8).
Arquivo “nome_do_modulo.xml”: arquivo onde contém os comandos para a criação
da interface, tais como, menus, relatórios e colunas.
47
Tendo estes arquivos sido criados de forma correta é possível visualizar o módulo
através da tela de listagem de módulos disponíveis para a instalação, conforme mostra a
figura 9.
Figura 8 - Interface listando o módulo criado.

Figura 9 - Exibição do código fonte do arquivo relatorio.py.

48
As tabelas e colunas no banco de dados são criadas automaticamente ao instalar o

módulo, dependendo apenas dos comandos passados no arquivo “nome_do_modulo.py” para
a criação de chaves estrangeiras, primarias e as demais formas dos campos.
Assim como já citado, a interface é criada a partir dos arquivos XML’s os quais são
listados no arquivo “__openerp__.py”. Estes arquivos possuem as informações para a criação
das colunas através de tags específicas, assim como para a criação de menus laterais e
superiores.
As maiores dificuldades estão presentes na criação do código XML já que não ainda
não foi criada nenhuma ferramenta para a pré-visualização da interface, sendo que suas tags
são de uso exclusivo do sistema em questão.
Após a escrita do código fonte o módulo foi instalado e configurado para que apenas
as contas de acessos escolhidas tivessem privilégio de acesso. Este controle de acesso pode
ser feito no próprio sistema através de uma lista de controle de acessos. Com esta lista é
possível liberar tanto o acesso a um grupo de usuários como para um usuário individual
conforme representado na figura 10.
Figura 10 – Interface da lista de controle de acessos do OpenERP.

Como mostrado na figura 11, o módulo de relatórios é algo simples e direto, exigindo
do usuário apenas a passagem dos dados e a gravação do registro já que não é necessária
nenhuma verificação desses dados.
49
Figura 11 – Tela de cadastro do módulo de relatório.

Os testes feitos basearam-se em verificar a gravação dos itens, o acesso aos campos
pré-selecionados (data, cidade, cliente, ocorrência) e a possível necessidade de novos campos
ou uma diferente forma de ordenação.
Com este teste foi verificado que o sistema estava ordenando as linhas de registro de
forma crescente de data, sendo que é mais interessante ordenar de forma decrescente por
conta da visualização dos últimos registros.
O quadro 3 mostra os requisitos cumpridos e os não cumpridos pelo módulo em
questão.
Quadro 3 – Resumo dos requisitos cumpridos e não cumpridos inicialmente pelo módulo de relatórios
de entrega.
MÓDULO DE RELATÓRIOS DE ENTREGA
Requisitos Status
Estudar funcionamento dos módulos Cumpriu completamente
Conhecimento da linguagem e sua sintaxe Cumpriu completamente
Campos necessários para cadastro de ocorrências Cumpriu completamente
Reutilização de dados já cadastrados Cumpriu completamente
Cadastro simples e direto Cumpriu completamente
Organização dos registros por data de ocorrência Cumpriu completamente
Por ser um módulo novo e de desenvolvimento totalmente feito na empresa, foram

necessários 30 dias contando do desenvolvimento até a finalização dos testes e análise da
implantação.
50
3.9 Módulo de compras

Este módulo trabalha a partir da necessidade da compra de materiais para abastecer o
estoque virtual tornando possível o planejamento de produção automático.
Com ele o usuário poderá gerar cotações de compra manualmente ou automaticamente
para o usuário, que a partir da inserção de novos dados de preços que, comparados aos
pedidos antigos, serão avaliados e passarão como resultado a vantagem ou desvantagem da
compra específica.
3.9.1 Módulo de compras: levantamento de requisitos

O módulo de compras será responsável por administrar e realizar cotações dos
produtos utilizados como matéria prima para os produtos manufaturados. Com ele espera-se
que o usuário consiga realizar as seguintes funções:
 Realizar cadastro de pedidos de materiais para cotação;
 Receber informações de impostos e gastos de entrega para cotações individuais;
 Realizar cadastro de produtos, assim como seus impostos, custos de armazenagem
e entrega;
 Visualizar com facilidade a quantidade de cada produto;
 Controlar a quantidade de material comprada através da soma dos valores de custo
dos pedidos de compra;
 Possibilidade da realização de cotações através de dispositivos mobiles;
 Emissão de relatórios contendo os valores de compras diários, semanais, mensais
e anuais a fim de acompanhar os valores gastos pela empresa com matérias prima.
Tais requisitos listados foram levantados a partir de uma reunião realizada com os
principais usuários e responsáveis pela área em questão.
Com esta análise, os responsáveis pela implantação e implementação do módulo
poderão dar maior ênfase aos pedidos dos futuros usuários.
3.9.2 Módulo de compras: plano de ação

O módulo de compras será inicialmente importante para a integração dos módulos de
vendas e armazenamento. Após a integração dos três os usuários terão um controle total dos
produtos que entrarem e saírem do estoque assim como as mercadorias para emissão e
recebimento.
 O plano de ação desde módulo será baseado nos seguintes itens:
51
 Cadastro das categorias de produtos (embalagem, ingredientes, produto pronto);

 Organizar os dados para a importação da lista de produtos;
 Importação dos produtos de compra;
 Importação dos fornecedores de matéria prima;
 Atualização da quantidade dos itens em estoque;
 Primeiros testes de cotações e confirmações de pedidos;
 Testes de controle de estoque (entrada e saída dos itens);
 Finalização da implantação do módulo de compras.
A partir deste plano de ação o módulo de vendas deve ser implementado corretamente,
tornando mais ágil a instalação do módulo de armazém e a integração entre estes dois
módulos.
3.9.3 Módulo de compras: implementação e implantação

A implantação do módulo de compras começou com o cadastro manual de alguns itens
necessários no OpenERP, os itens cadastrados foram os seguintes:
 Embalagem: produtos usados no embalo dos ingredientes como bobinas, sacos
plásticos, etiquetas, fardos, caixas de despacho, caixas primárias.
 Ingrediente: matérias-primas que por fim se tornaram produtos para venda aos
supermercados e lojas de produtos naturais.
 Intermediários: são produtos manufaturados pela empresa mas que serão usados
como matéria prima em outro processo. Esta categoria foi criada para que não
haja confusão entre o estoque de matéria-prima e produtos acabados
(manufaturados).
Estas categorias foram discutidas e cadastradas em dois dias já que é algo simples.
Após realizar este cadastro de classificação foi necessário fazer a classificação dos
itens para a exportação. Esta atividade foi realizada manualmente, aproveitando para excluir
os itens inativos e com a última compra a mais de dois anos.
Com os tipos de classificação cadastrados pode-se dar início a exportação dos dados
dos produtos. Os campos obrigatórios para a exportação segundo dados levantados através de
pesquisas em fóruns e no manual do sistema são: nome do produto, referência, se o produto
pode ser vendido e/ou comprado, tipo fiscal, método de aquisição, método de reposição,
método de formação de custo, preço de custo, categoria, unidade de medida padrão, unidade
de medida de compra e classificação fiscal do produto, conforme apresentado na figura 12.
52
Figura 12 – Tela de cadastro de produtos do módulo de compras

A partir desses dados foi montado um arquivo csv para ser utilizado em conjunto com
a ferramenta OOOR na qual foi escrito um código na linguagem Ruby para fazer a
transferência dos dados e a gravação dos produtos no banco de dados PostgreSQL. A
estrutura do código da ferramenta OOOR para o módulo de compras é basicamente igual ao
utilizado no módulo de vendas, mudando apenas as tabelas utilizadas no banco de dados e os
parâmetros importados.
Ao final da importação dos produtos foram verificados todos os cadastros
individualmente, a fim de identificar possíveis ocorrências de erros, principalmente na falta de
dados, adicionando mais quinze dias ao trabalho de instalação do módulo em questão.
Para a importação da lista de fornecedores são necessários os seguintes parâmetros:
nome do fornecedor, razão social, tipo de pessoa, cnpj ou cpf, número referência, tipo de
endereço, rua, número, bairro, cep, município, estado, país, e-mail, posição fiscal, inscrição
estadual ou rg e tipo fiscal do parceiro, conforme é mostrado na figura 13.
53
Figura 13 – Tela de cadastro de fornecedores.

Tendo estes dados em mãos foi criado o arquivo csv para a utilização em conjunto
com o script de exportação. Alguns desses fornecedores não foram cadastrados na gravação
dos dados no OpenERP por estarem faltando dados ou estarem com cnpj/ cpf ou inscrição
estadual/ rg incorretos, levando em conta que o próprio script faz uma verificação dos dados
importados.
Assim como nas outras importações, os cadastros feitos foram verificados
manualmente e corrigidos já que muitos fornecedores estavam cadastrados a muito tempo no
sistema a ser substituído, podendo faltar algum parâmetro ou contendo algum dos dados
incorretos.
O processo de seleção, verificação, importação e análise dos dados levaram
aproximadamente vinte dias.
Na importação dos produtos os itens foram cadastrados com quantidade zerada,
havendo a necessidade de atualizar estes valores para a realização dos testes e análise de
comportamento do sistema nas operações de entrada e saída de produtos.
Foram realizados testes básicos de venda, compra e utilização dos produtos como
matéria prima ou produto acabado, sempre observando se o sistema estava realizando o
processo de adição ou subtração.
Apesar de serem testes simples, foi destinado para este processo uma semana, onde foi
verificado que, assim como ocorreu no módulo de vendas, neste módulo foi necessário
54
aumentar as casas decimais no número de referência do pedido já que ele possui apenas cinco
dígitos.
A alteração deste parâmetro é feita pelo próprio sistema, onde o campo “Preencher
número” foi alterado de cinco para oito conforme apresentado na figura 14.
Figura 14 – Tela para alteração de sequência de identificadores.

Os requisitos cumpridos e não cumpridos inicialmente pelo módulo de compras estão

representados no quadro 4.
Quadro 4 – Requisitos cumpridos e não cumpridos inicialmente pelo módulo de compras.

MÓDULO DE COMPRAS
Requisitos Status
Realização de pedidos para cotação Cumpriu completamente
Cálculo de impostos e gastos com entrega Cumpriu parcialmente. Problemas com
impostos
Cadastro de produtos e impostos e demais custos Cumpriu parcialmente. Problemas com
impostos
Visualização da quantidade de produtos em Cumpriu completamente
estoque
Controle de materiais comprados juntamente com Cumpriu completamente
custo adicionais
Realização de cotações atravé de dispositivos Cumpriu parcialmente. Problemas com
mobiles interface
Emissão de relatórios de gastos Cumpriu completamente
Após a correção do problema encontrado o módulo de compras foi liberado para a

utilização sendo que os tempos entre o começo de sua instalação até a conclusão duraram
aproximadamente quatro meses, um tempo menor em relação ao módulo de vendas por não
55
haver a necessidade da importação de tabelas de preços e por já ter em mãos as ferramentas

necessárias para gravação dos dados no banco de dados.
3.10 Módulo de armazém

O módulo de armazém consiste das ordens de separação de materiais, sejam eles
matérias primas ou produtos prontos, criadas a partir do módulo de compra e do módulo de
vendas.
Com ele a área de expedição receberá as ordens de separação de pedidos para entrega
ao cliente. Tais ordens são criadas pelo sistema automaticamente, a partir dos pedidos de
vendas inseridos no sistemas pelos vendedores da empresa.
Já a área de recebimento de matéria prima terá as ordens de recebimentos, as quais são
provenientes dos pedidos de compras inseridos no módulo de compras.
3.10.1 Módulo de armazém: Levantamento de Requisitos

O módulo de armazém ira envolver dois setores distintos da empresa, porém, as
atividades desempenhadas pelos responsáveis de cada setor são muito parecidas, o que faz
com que ambos estejam reunidos em um único módulo.
O setor de expedição e estoque de produto acabado da empresa necessita que os
seguintes requisitos estejam presentes no módulo de armazém:
 Ordens de separação dos pedidos de venda;
 Tais ordens devem ter, no mínimo, o nome ou número de referência do cliente,
endereço de entrega, produtos vendidos e quantidade de cada produto;
 Necessidade de separar mercadorias em embalagens diferentes;
 Registo de inventário.
O setor de recebimento de mercadorias e estoque de matéria prima tem como
necessidade os itens da lista a seguir:
 Ordens de recebimento criadas a partir da data prevista para a chegada de
mercadoria;
 As ordens devem conter os seguintes parâmetros: nome do fornecedor, itens a
receber, quantidades, preços unitários e preço total;
 Controle de movimento de entrada e saída dos produtos;
 Registro de inventário;
 Tela para cadastro de lotes de matéria prima.
56
3.10.2 Módulo de armazém: plano de ação

Por ser um módulo que utiliza os dados provenientes dos módulos anteriormente
implantados não houve a necessidade de importação de novos dados. Deste modo, o plano de
ação do módulo de armazém ira se restringir basicamente aos cadastros feitos de forma
manual conforme a listagem a seguir:
Cadastro dos tipos de embalagens de empacotamento utilizados para expedição de
pedidos e armazenagem de matéria prima: fardos, caixas, pacotes plásticos, etc;
Cadastro de unidades de medida utilizadas para calcular o peso final da mercadoria
assim como o tamanho que esta mercadoria ira ocupar dentro do veículo;
Cadastro dos métodos de entrega da empresa para fornecedores e de fornecedores para
a empresa;
Cadastro para estoque mínimo, o qual é necessário para que o sistema possa criar
ordens de pedido de compra automaticamente.
Implementação de cadastro de lotes de matéria prima.
3.10.3 Módulo de armazém: implementação e implantação

A implantação do módulo de armazém começou com o cadastro das embalagens de
empacotamento usadas para armazenamento e expedição dos produtos. Cada embalagem
possui um nome e um tipo ao qual ela representa, este cadastro é importante para se ter uma
ideia do tamanho do item a ser armazenado.
Foram feitos os cadastros conforme o tipo de pacote de cada produto (figura 15),
alguns deles possuem embalagens iguais, assim como a quantidade embalada. Levando em
conta esta informação, alguns cadastros equivalem a mais de um tipo de produto.
Figura 15 – Tela de listagem dos dados cadastrados.

57
A atividade de levantamento de tipos de pacotes e o cadastramento no sistema levaram

aproximadamente uma semana.
O cadastro de unidades de medida será utilizado principalmente no cálculo de peso
dos itens que irão no caminhão, espaço que a mercadoria ira ocupar no estoque e no veículo
usado para seu transporte. No cadastro das unidades devem ser preenchidos todos os campos,
nome, categoria de unidade, tipo de unidade de medida e precisão do arredondamento.
Por ser um cadastro simples e rápido, os registros dos dados foram feitos em um dia.
Seguindo com os cadastros, foi dado início a gravação dos dados de tipos de
transportes utilizados, basicamente a empresa utiliza transporte através da própria frota e
através de transportadores. Outro modo de transporte também utilizado, porém em menor
escala, são os Correios.
Este cadastro será utilizado após a separação do pedido a fim de indicar para a área de
faturamento qual será o meio de transporte. Este tipo de transporte também é utilizado na área
de recebimento.
Seguindo na área de entregas, também foi necessário cadastrar os veículos utilizados
pela empresa. No cadastro de veículos foram inseridas as seguintes informações: carrier
(método de entrega onde o veículo é utilizado), nome, placa, descrição, código ANTT, país,
estado, município, ano de fabricação e ano do modelo.
Após o término destes dois cadastros foram finalizados os registros de dados de
recebimentos. Tais atividades levaram cinco dias para serem executadas e nenhum erro foi
encontrado.
Por fim foi feito o cadastro para a análise de estoque automático pelo sistema, o
estoque mínimo. Com ele o sistema ERP mostrará ao usuário quais produtos comprar e quais
estão com estoque alto tomando como base o nível de movimentação do produto.
Como já citado anteriormente, este cadastro também precisou ser feito de forma
manual já que o sistema utilizado anteriormente não tinha esta funcionalidade.
Os campos preenchidos foram os de produto, unidade de medida do produto, local do
armazém (local onde o produto será armazenado), quantidade mínima e quantidade máxima,
concluindo assim os cadastros no módulo do armazém.
Com todas as informações já cadastradas os usuários começaram a utilizar o módulo
no banco de dados de teste. Foram analisadas as ordens de recebimento e de expedição de
material criadas a partir dos módulos de venda e de compra, fazendo a análise dos produtos e
suas quantidades, assim como os fornecedores e clientes registrados em cada pedido.
58
Com a confirmação de que as ordens estavam sendo criados corretamente, os testes se

voltaram à funcionalidade de compras automáticas. Para testar esta funcionalidade, alguns
itens do estoque foram esgotados propositalmente e foi feita uma análise do comportamento
do módulo. Conforme o esperado, quando o item ficou inferior à quantidade mínima
cadastrada automaticamente foi criada uma ordem de compra para ser autorizada ou alterada
pelo responsável por compra de matéria prima.
Assim como identificado nos outros números de índices utilizados nos demais
relatórios, o índice utilizado nas ordens também teve que ser alterado, adicionando cinco
casas decimais para não ocorrer o esgotamento dos identificadores.
Por fim, foi necessária a criação de uma tela de cadastro adicional para os lotes dos
produtos de matéria prima. Este complemento de módulo foi feito com o objetivo de criar um
sub cadastro de produtos.
Para a criação do cadastro foram inseridos os seguintes campos: produto, cadastro do
produto no sistema antigo, data de chegada, lote interno, fornecedor, quantidade, unidade, lote
externo, data de emissão da nota fiscal, número da nota fiscal, data de validade do produto e
data de validade conforme pode ser observado na figura 16.
Figura 16 – Tela de cadastro de lotes de matéria prima.

Para este complemento de módulo também foi necessária a criação de um relatório

para a impressão dos dados dos produtos e seus lotes, o qual será colado nos pallets dos
produtos.
A criação de relatórios no OpenERP segue a mesma base da criação de módulos,
porém, nele há um arquivo XML que será responsável pela formatação dos dados. Este XML
é criado a partir de uma API instalada no editor de textos LibreOffice e transferida para a
pasta de arquivos do relatório.
59
O estudo destas ferramentas e a conclusão deste relatório foram realizados em

aproximadamente sete dias, sendo que a maior dificuldade foi novamente a falta de
documentação, tendo a necessidade de recorrer aos fóruns e grupos de ajuda do sistema.
A fim de fazer um resumo de quais requisitos foram cumpridos e quais não foram
inicialmente, foi criado o quadro 5.
Quadro 5 – Requisitos cumpridos e não cumpridos inicialmente pelo módulo de armazém.

MÓDULO DE ARMAZÉM
Requisitos Status
Recebimento de ordens de separação de pedidos Cumpriu completamente
Campos mínimos presentes nas ordens Cumpriu completamente
Separação em embalagens diferentes para mesmo Cumpriu completamente
produto
Recebimento das ordens de chegada de produtos Cumpriu completamente
Controle de movimento de entrada e saída de Cumpriu completamente
produtos
Registro para inventário mensal Cumpriu completamente
Tela para cadastro de lotes de matéria prima Cumpriu parcialmente. Necessidade de módulo
complementar desenvolvido internamente.
Os testes foram concretizados e o módulo começou a ser utilizado na base de dados

principal integrado aos demais módulos já trabalhados.
3.11 Módulo de manufatura

O módulo de manufatura resume-se às ordens de produção de produtos para o
reabastecimento do estoque de produtos acabados.
Neste módulo o usuário irá criar as receitas a partir dos produtos disponíveis no
estoque de matéria prima, os quais após o processo de produção serão transformados em
produto acabado alimentando o estoque dos produtos de venda.
3.11.1 Módulo de Manufatura: Levantamento de requisitos

Os requisitos necessários são os seguintes:
 O sistema deve oferecer ao usuário fácil criação e alteração de receitas, sendo
que o usuário irá adicionar primeiro os produtos de matéria prima e depois os
produtos de embalagem;
60
 Os produtos utilizados nas receitas devem estar disponíveis no estoque, caso

não estiverem disponíveis o sistema deve alertar o usuário sobre a falta do
mesmo;
 Automatizar a avaliação da necessidade de produção de acordo com o nível do
estoque, sendo que os produtos com baixa quantidade em estoque devem ter
prioridade para produção.
3.11.2 Módulo de Manufatura: Plano de ação

O plano de ação para implementação e utilização dos módulos de manufatura esta
descrito nos seguintes itens:
 Verificação das listas de materiais cadastrados no Excel;
 Cadastro das listas de materiais;
 Criação das ordens de produção;
 Testes das operações de saída e entrada de materiais.
3.11.3 Módulo de Manufatura: Implementação e implantação

A empresa possui as receitas cadastradas em planilhas do programa Excel não sendo
possível a importação automática dos dados. Sendo assim, é necessário que os cadastros
sejam feitos de forma manual.
Primeiramente as listas foram verificadas de forma a avaliar possíveis alterações e
erros para que o novo sistema receba os dados atualizados. Esta verificação foi feita pelo
responsável da área de operações e a área de qualidade.
A análise das receitas foi feita em três semanas já que a quantidade de arquivos era
grande e a verificação foi feita de forma minuciosa.
Após a verificação das listas, os cadastros de materiais foram feitos conforme a figura
17. O cadastro exige que sejam adicionados os seguintes dados: produto a ser produzido,
nome da lista, quantidade, unidade de medida do produto e componentes onde também são
registrados produtos, quantidades dos produtos e unidades de medidas.
61
Figura 17 – Tela de cadastro de lista de materiais.

Com as listas devidamente cadastradas foram criadas as ordens de produção para

testes de saídas e entradas dos produtos. Assim como nos demais números de índices
principais, a quantidade de casas decimais precisou ser aumentada para cinco.
O quadro 6 apresenta quais requisitos o módulo de manufatura cumpriu e quais os
requisitos não foram cumpridos inicialmente.
Quadro 6 – Requisitos cumpridos pelo módulo de manufatura.

MÓDULO DE MANUFATURA
Requisitos Status
Criação e alteração de receitas Cumpriu completamente
Exibição apenas dos produtos disponíveis no Cumpriu completamente
estoque
Automatização da necessidade de produção de Cumpriu completamente
acordo com o nível do estoque
Os testes foram feitos em três semanas pelos usuários e programadores.
3.12 Módulos de Faturamento e Contabilidade

Os módulos de faturamento e contabilidade foram os últimos a serem trabalhados na
implantação por depender dos demais módulos para o correto funcionamento.
Levando em conta que a instalação dos módulos de faturamento e contabilidade tem
complexidade maior em relação aos demais a empresa optou por contratar uma empresa de
consultoria especializada no OpenERP.
A empresa contratada é uma das principais parceiras do sistema OpenERP no Brasil e
conta com vários casos de implantações do sistema bem sucedidas. Essa empresa também já
ofereceu cursos aos responsáveis pela instalação e implantação da versão 6.1.
62
Os sócios de ambas as empresas e os responsáveis pela área de TI se reuniram e

optaram por realizar a migração da versão 6.1 para a versão 8 do sistema. A partir dessa
conversa também foi combinado o valor do serviço, modos de pagamento e prazos para
entrega.
Esta escolha foi tomada pelos seguintes motivos:
 A versão 8 conta com os módulos das versões anteriores e os módulos feitos
especialmente para esta versão;
 A comunidade brasileira passará a trabalhar apenas com as versões 8 e superiores
do sistema;
 Existe um projeto para que as atualizações fiscais sejam feitas através de
webservice;
 Todos os futuros treinamentos serão voltados para a versão 8.
Segundo os desenvolvedores da empresa de consultoria, o ideal é começar a instalação
pelo módulo de contabilidade e faturamento já que os dois irão envolver e depender de muitos
dados fiscais.
A fim de fazer uma importação limpa e sem erros, os diretores da empresa
contrataram alguns contadores para reverem os impostos e cadastros fiscais dos produtos,
fazendo com que o começo da implantação do OpenERP 8 sofresse um pouco de atraso.
Para que a análise de todos os produtos e todas as situações fiscais fossem feitas os
contadores necessitaram de três meses.
Enquanto as áreas fiscais estavam sendo revisadas, os desenvolvedores começaram a
montar o plano de contas da empresa. Por ainda não ter trabalhado com nenhuma empresa na
área de alimentos, foi necessário montar um plano de contas desde o início, o que aumentará o
tempo de implantação da nova versão.
A princípio a agenda para a exportação e implantação total do sistema esta
programada para um ano, podendo variar em casos de imprevistos. Sendo que a instalação da
base e o trabalho com os módulos de contabilidade e faturamento já foram iniciados (figura
18).
63
Figura 18 – Tela inicial do OpenERP 8.

Segundo os sócios da empresa de consultoria, os principais representantes do

OpenERP no Brasil estão com um projeto de atualização de dados fiscais e contábeis via
webservice. Para este serviço será cobrado uma taxa mensal de uso e seu código fonte será de
licença proprietária já que é um serviço inédito na área de ERP’s open source no país.
Visando as dificuldades que se tem com relação às constantes atualizações fiscais no
país, a solução proposta utilizando webservice tende a facilitar e agilizar o tempo de
inatividade no sistema para esse tipo de manutenção.
3.13 Custos e investimentos

Apesar de o software instalado ser open source, ainda temos alguns custos que devem
ser levados em conta para que a implantação seja feita. São custos diretos como treinamentos,
viagens, hardware, manutenção, e outros indiretos, tais como, tempo de trabalho, energia
elétrica, pagamento de um provedor para obter endereço IP fixo, internet, entre outros.
Levando em conta os gastos diretos e indiretos, foram gastos com o sistema ERP por
volta de R$ 40.000,00, incluindo os gastos com treinamento, horas trabalhadas, gastos com a
consultoria e gastos com infraestrutura. Estes gastos não serão especificados detalhadamente,
por pedido de sigilo da empresa, porém o valor informado está próximo ao valor real.
64
Em comparação aos preços de sistemas proprietários, este valor pode ser considerado
baixo sendo que um sistema proprietário é vendido por pelo menos o dobro do valor gasto até
o momento com este sistema.
Capítulo
67
4 Resultados
A avaliação foi feita visando analisar as vantagens do novo sistema com relação ao
software utilizado na empresa anteriormente, assim como ter uma opinião dos programadores
e dos envolvidos com a implantação em nível de programação.
A análise contou com o auxílio dos funcionários com maior contato com o sistema,
principalmente aqueles que acompanharam e estão acompanhando a transição dos programas.
Primeiramente, foi avaliada a eficiência no recebimento e entrega de pedidos de
vendas nos sistemas da empresa. Tal quesito foi avaliado como satisfeito pela equipe de TI e a
gerência, uma vez que houve a padronização desta funcionalidade e a eliminação dos outros
métodos de entrada de pedidos, conforme uma das propostas na instalação do módulo de
vendas.
Em segundo lugar foi avaliada a praticidade com que os responsáveis por fazer as
entradas de pedidos de vendas e compras tinham para o acesso ao sistema e a digitação. Para
os usuários que acessam o sistema na rede interna da empresa, este quesito foi avaliado como
satisfeito, porém para os usuários que acessam externamente, este quesito foi considerado
como parcialmente satisfeito, já que o acesso ainda esta um pouco lento, mesmo após a
contratação de um serviço de internet melhor.
Outra avaliação feita levou em consideração o primeiro módulo criado na empresa, o
módulo de relatórios de entrega. O intuito para este quesito foi avaliar a facilidade de
visualização e registro dos módulos no ERP, o qual foi considerado satisfeito pelos usuários
por ter uma usabilidade fácil e sua interface de cadastro ser intuitiva.
A administração dos valores de vendas e compra também foi avaliada já que antes elas
eram feitas através de consultas SQL e importadas para planilhas do programa Excel. Tal
administração foi considerada como parcialmente satisfeita, devido à limitação das
visualizações dos valores nos gráficos, visando que no Excel o usuário tem diversas opções
para esta visualização.
Já o custo total de propriedade foi avaliado como parcialmente satisfeita pois
comparado aos sistemas líderes de mercado, o custo do OpenERP não é muito alto, porém
não espera-se um aumento nos gastos com a consultoria para a atualização de versão e a
68
contratação de uma empresa para suporte nos primeiros meses até o treinamento de
capacitação dos funcionários, o que deve elevar o custo total.
Voltando-se para uma visão mais relacionada a implantação e implementação de
módulos pelos responsáveis por TI da empresa, foram avaliados alguns requisitos específicos.
Primeiramente, sobre a facilidade no suporte e na manutenção do software. Tal quesito
foi dado como parcialmente insatisfeito, já que a escassez de documentação é grande tendo
que recorrer aos grupos brasileiros de estudo do sistema.
Foi avaliada também a qualidade dos módulos com relação ao setor em que a indústria
trabalha, tal quesito foi avaliado como parcialmente satisfeito, apesar da necessidade da
implementação de alguns itens, os módulos de manufatura e armazém se mostraram bem
completos para as necessidades da empresa.
Por último, foi feita a análise da qualidade do trabalho da empresa e o cumprimento
dos prazos da empresa de consultoria. Segundo os contratantes da empresa, a comunicação
com os responsáveis pela consultoria é difícil já que em grande parte do tempo eles não estão
presentes na empresa. E com relação aos prazos a mesma esta deixando por atrasar a
implantação da versão 8 na empresa pela necessidade da espera da liberação da versão pela
OpenERP européia.
Como já citado, nesta análise dos resultados não é possível avaliar as áreas que
envolvem o setor financeiro e de faturamento da empresa, deixando a avaliação restrita
apenas aos módulos envolvendo compras, vendas, armazém e manufatura os quais já foram
trabalhados.
Analisando os procedimentos realizados para o recebimento de pedidos até a entrega
ao cliente é possível notar uma grande melhora no tempo de realização destes trabalhos,
principalmente na visualização de dados e redução de retrabalho realizado principalmente em
lançamentos de notas no sistema. Com a utilização do outro ERP os pedidos de compras e
vendas necessitavam serem lançados no sistema por todas as áreas tais como financeiro,
faturamento, fiscal e estoque. Com a instalação do OpenERP este processo é reduzido apenas
para um lançamento do pedido o qual os responsáveis por cada área verifica se os dados estão
corretos e o avançam para próxima fase.
Por opção da empresa, os módulos desenvolvidos internamente serão disponibilizados
para a comunidade de desenvolvimento do programa no Brasil, a importância deste
compartilhamento se deve ao retorno da ajuda oferecida pelos participantes de tais grupos
quando surgiram as dificuldades na implantação por falta de documentação do sistema.
Capítulo
69
5 Conclusões
Sem dúvidas a implantação e a substituição de um sistema de gestão empresarial são
mais complicadas do que se parece, até mesmo em casos mais simples como neste estudo de
caso.
Algumas observações devem ser levadas em conta para os atrasos e os problemas tidos
nesta implantação. O primeiro se deve à quantidade de pessoas, já que a empresa possui
apenas dois funcionários na área de TI, os quais também realizavam atividades do cotidiano
da corporação, não estando exclusivamente dedicados ao trabalho com o ERP. Como não há
um controle detalhado da alocação das horas por atividade destes funcionários, não foi
possível descrever o tempo gasto individualmente em cada etapa descrita no estudo de caso.
O cronograma inicial, o qual objetivava a instalação completa do sistema, foi
parcialmente cumprido levando em conta que ainda faltaram as instalações dos módulos de
faturamento e contabilidade para que o sistema ERP ficasse completo. Porém com os módulos
trabalhados foi possível realizar, ao menos que parcialmente, todos os objetivos previstos.
A possibilidade da realização de grande parte do trabalho pelos próprios
programadores da empresa, sem a participação de uma consultoria externa, se deve ao
compartilhamento de conhecimentos e conteúdos técnicos, principalmente pela comunidade
do OpenERP. Em grupos dedicados para discussões sobre o sistema, foram obtidas muitas
informações de grande valia, e a questão de o software ser open source também faz com que
tais informações fiquem mais completas com a sua utilização por novos usuários.
Em segundo lugar, não foi adotada uma metodologia consolidada, tendo sido aplicada
uma metodologia utilizada somente na empresa e que em nenhum momento havia sido usada
para um trabalho desta proporção. Como consequência, esta metodologia precisou ser alterada
em alguns pontos durante a implantação, o que resultou no atraso do cronograma previsto
inicialmente neste projeto. Provavelmente, a utilização de uma metodologia já consolidada no
mercado de implantação de ERP’s fosse a melhor forma de reduzir estes atrasos e alguns
imprevistos.
A contratação da empresa de consultoria foi necessária pelo motivo da equipe de TI
não ter o conhecimento necessário para a instalação dos módulos envolvendo as áreas de
70
contabilidade e financeiro. Contudo, por ser uma empresa especializada, esperava-se que o
cumprimento dos prazos e a análise de alguns pontos fossem melhores, tais como as
necessidades da empresa e seus módulos já disponíveis, as regras fiscais e contábeis
específicas para o ramo em que a indústria opera, os métodos de comunicação utilizados com
o cliente e a forma como a empresa lida com atrasos de tempos longos como foi o caso
ocorrido nesta contratação.
Na análise realizada com relação aos módulos já instalados, os usuários mostraram-se
em grande parte, satisfeitos com o resultado parcial e esperam que com a completa
substituição do sistema utilizado, grande parte dos processos sejam agilizados trazendo lucro
para a empresa e facilitando o trabalho de todos.
Apesar dos gastos terem sido menores do que seriam na utilização de um sistema de
código proprietário, os gastos com o ERP foram maiores do que o esperado já que no começo
do projeto não estava planejado a contratação de uma empresa terceirizada. Porém, a
contratação da empresa agilizou alguns pontos da implantação, como o trabalho com os itens
fiscais, os quais se fossem feitos pelos programadores da própria empresa, necessitariam de
um tempo maior para treinamento e entendimento desta área de grande complexidade.
Após a conclusão do projeto na empresa, os programadores estarão aptos para a
realização de reparos e possíveis trabalhos de adição de módulos ou funcionalidades. Isso
pode ser afirmado, já que estas mesmas atividades foram desenvolvidas, sendo que as
alterações realizadas foram de grande valia para os desenvolvedores e para os funcionários
com relação à utilização do sistema.
Sem dúvidas a escolha de um sistema open source facilitou o trabalho com o sistema e
fez com que a empresa tivesse mais liberdade não precisando depender no primeiro momento
de uma empresa terceirizada. Contudo, as dificuldades iniciais, juntamente com outros
problemas, refletiram em um atraso principalmente no inicio da instalação do ERP reforçando
a importância dos grupos de discussões que a maioria dos sistemas possui, porém uns mais
ativos que os outros.
A avaliação feita a partir da metodologia aplicada na empresa mostra que o nível de
aprovação dos usuários é alto. Apesar da instalação do sistema ainda não ter sido finalizada,
os módulos já instalados cumpriram com a proposta de diminuir as necessidades de
interferência humana ao sistema aumentando assim a sua confiabilidade.
71
A disponibilidade do módulo de relatórios de entrega faz com que a empresa contribua

com a comunidade aumentando a quantidade de materiais disponíveis e realizando a principal
ideia da licença de software pública, o compartilhamento dos conhecimentos adquiridos.
5.1 Sugestões e recomendações para trabalhos futuros

Recomenda-se para trabalhos futuros a continuidade do estudo de caso do sistema
OpenERP após a sua atualização de versão e implantação completa na empresa a fim de
analisar as melhoras nas atividades executadas pelos usuários.
Também fica como sugestão o estudo de caso dos outros sistemas ERP’s abordado
neste trabalho assim como uma comparação entre as mudanças de ambos os sistemas
trabalhados.
73
Referências
ACCORTO. Management Team. Em: <http://www.accorto.com/about/management.html>.

Acesso em: 09 Setembro 2013.
ADEMPIERE BRASIL. Site Compieri Brasil será tirado do ar. Em:

<http://adempierebr.blogspot.com.br/2008/10/site-compiere-brasil-ser-tirado-do-ar.html>.
Acesso em: 15 Setembro 2013.
AFFERO. GNU Affero General Public License. Vs. 3. Em:

<http://www.gnu.org/licenses/agpl.html>. Acesso em: 05 Maio 2013.
AKRETION. Openerp - OOOR Connector. Disponível em:

<http://www.akretion.com.br/open-source-contributions/openerp-ooor-connector>. Acesso
em: 17 fev. 2014.
ALVARENGA, Mário Lúcio Ferreira. Metodologia para verificação do sucesso na

implantação de ERP (Enterprise Resource Planning) baseada nos fatores críticos de
sucesso: aplicação na indústria mineira. 2003. 111 f. Dissertação (Mestrado em Engenharia
de Produção) – Programa de Pós-Graduação em Engenharia de Produção, Universidade
Federal de Santa Catarina, Florianópolis, 2003.
ARANTES, Alison Carmo. Comparativo de licenças de código aberto. Universidade

Federal de Minas Gerais, Departamento de Ciência da Computação. Belo Horizonte – MG,
2009.
LOCKWOOD, Brad. Bill Gates: Profile of a Digital Entrepreneur. Estados Unidos:

ReadHowYouWant, 2008. Disponível em:
<http://books.google.com.br/books?id=7J_EBQuPxAgC&printsec=frontcover&dq=inauthor:
%22Brad+Lockwood%22&hl=pt-BR&sa=X&ei=A5JuVKj-
C8XGsQTnm4BY&ved=0CB4Q6AEwAA#v=onepage&q&f=false>. Acesos em: 20 de
Março de 2014.
74
COMPIERE. Company. Disponível em: <http://www.compiere.com/company/>. Acesso em:

15 Setembro 2013.
DA SILVA, André Machado. Estudo de caso de implantação de um sistema ERP em uma

empresa do segmento automotivo. 2010. 47 f. Monografia (Graduação em Administração) –
Curso de Graduação em Administração, Universidade Federal do Rio Grande do Sul, Porto
Alegre.
DISOFT. ERP - Openbravo. 2014. Disponível em: <http://www.disoft.com.br/disoft-

erp.html>. Acesso em: 15 jan. 2014.
ECOS, Instituto. Custo Total de Propriedade - TCO: Análise comparativa . Disponível em:
<http://www.institutoecos.org.br/br/software/license/tco.htm>. Acesso em: 29 maio 2013.
FERREIRA, Lilian. Software livre, freeware, shareware, copyleft: entenda as licenças de

software, dez. 2007. Disponível em:
<http://tecnologia.uol.com.br/ultnot/2007/12/20/ult4213u266.jhtm>. Acesso em: 10 Outubro
2013.
GARTNER. Total Cost of Ownership (TCO). Disponível em: <http://www.gartner.com/it-

glossary/total-cost-of-ownership-tco/>. Acesso em: 29 maio 2013.
GONÇALVES, Gilberto. Implantação de um sistema de informação - Enterprise

Resource Planning (ERP): Estudo de caso em uma indústria eletrônica. [Editorial]. Revista
de Engenharia e Tecnologia, v.2, n.1, p. 57-68, Abr, 2010.
LAUDON, Kenneth C.; LAUDON, Jane P.. Sistemas de Informação Gerenciais. 9 ed. São
Paulo : Pearson, 2007.
LIMA, Jose Petri de. O uso do sistema de software livre nas empresas. Faculdade de São
Vicente - UNIBR, Administração. São Vicente – SP, 2010.
75
NETO, Esmerino Toscano de Brito. Implantação de um sistema E.R.P (Enterprise

Resources Planning): um estudo de caso. 2004. 45 f. Monografia (Graduação em Tecnologia
em Processamento de Dados) – Faculdade Paraibana de Processamento de Dados, João
Pessoa.
OFICINA1 . Openbravo. 2014. Disponível em: <http://www.oficina1.com.br/openbravo/>.

Acesso em: 25 maio 2014.
OPENERP. OpenERP Documentation. Vs.6.1 Disponível em: <

http://doc.openerp.com/v6.1/index.html>. Acesso em: 20 Abril 2013.
SABINO, Vanessa; KON, Fabio. Licenças de software livre: histórias e características.

Centro de competência em software livre, Instituto de matemática e estatística, Universidade
de São Paulo. São Paulo – SP. 2009.
SILVEIRA, Sérgio A. da. Software livre: a luta pela liberdade do conhecimento. São Paulo :
Ed. Fundação Perseu Abramo, 2004
TURBAN, Efraim; RAINER, R. Kelly; POTTER, Richard E.. Administração de tecnologia

da informação. Rio de Janeiro: Campus, 2003. 598p.

2014 - 2sem - Ricardo Aparecido Junior Theodoro

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

2014 - 2sem - Ricardo Aparecido Junior Theodoro

Enviado por

Direitos autorais:

Formatos disponíveis

Ricardo Aparecido Junior Theodoro

IMPLANTAÇÃO E ESTUDO DE CASO DE UM SISTEMA

Trabalho de conclusão de curso apresentado ao

Área de Concentração: Sistemas de informação

Orientador: Prof. Roan Simões da Silva

São João da Boa Vista

Ficha catalográfica preparada pela Seção de Tratamento

Theodoro, Ricardo Ap. Jr.

Trabalho de Conclusão de Curso, IFSP, 2014.

1. Sistemas de Gestão. 2. Sistemas ERP. 3. Open

I. Implantação e estudo de caso de um sistema

Agradeço primeiramente a Deus por ter me proporcionado todas as

condições necessárias para a realização e finalização deste trabalho.

Agradeço também a minha família, Sonia Maria Junior Theodoro, Milton de

Oliveira Theodoro e Hector Junior Theodoro por estarem sempre presentes

caminhada, pois estiveram sempre presentes tanto nos momentos bons

quanto nos ruins fortalecendo cada vez mais a amizade e o companheirismo.

a realização deste trabalho, principalmente ao professor orientador e aos

professores da banca de avaliação.

THEODORO, R. (2014). Implantação e estudo de caso de um sistema integrado de gestão

Este trabalho visa apresentar a implantação e o estudo de caso de um sistema de gestão

Palavras-chave: Sistemas de gestão. Sistemas ERP. Open source. OpenERP

THEODORO, R. (2014). Implementation and case study of an integrated management

Keywords: Management systems. ERP systems. Open source. OpenERP.

Figura 1 - Estrutura básica de um MRP. .......................................................... 20

Quadro 1 – Quadro comparativo dos sistemas OpenERP, Compiere e

AFL Licença Acadêmica Pública (Academic Free License)

AGPL Licença Pública Geral Affero (Affero General Public License)

BSD Distribuição de Software da Berkeley (Berkeley Software Distribution)

CEO Diretor executivo (Chief Executive Officer)

CSV Valores Separados por Vírgula (Comma Separated Values)

ERP Planejamento de Recursos Empresariais (Enterprise Resource

FSF Fundação de Software Livre (Free Software Foundation)

GPL Licença Pública Geral (General Public License)

IP Protocolo de Internet (Internet Protocol)

LGPL Licença Pública Geral Reduzida (Lesser General Public License)

MRP I Planejamento de Necessidades Materiais(Material Requirements

MRP II Planejamento de Recursos de Manufatura (Manufacturing Resource

MIT Instituto Tecnológico de Massachusetts (Massachusetts Institute of

MVC Modelo – Visualização - Controlador - (Model - View - Controller)

TCO Custo Total de Propriedade (Total Cost Ownership)

XML-RPC Linguagem de Marcação eXtensiva – Chamada Remota de

Procedimento (eXtensible Markup Language - Remote Procedure Call)

XML Linguagem de Marcação eXtensiva (eXtensible Markup Language)

1.1 Motivação ............................................................................................................................. 15

1.2 Objetivos Gerais ................................................................................................................... 16

1.3 Objetivos específicos ............................................................................................................ 16

1.4 Organização deste trabalho ................................................................................................... 16

2.1 Sistemas de Informação Gerenciais ...................................................................................... 19

2.2 Sistemas Integrados de Gestão Empresarial ......................................................................... 20

2.2.1 OpenERP ............................................................................................................................ 21

2.2.2 Compiere ERP.................................................................................................................... 23

2.2.3 OpenBravo ......................................................................................................................... 23

2.3 Licenças de Software ............................................................................................................ 24

2.3.1 Licenças Proprietárias ........................................................................................................ 26

2.3.2 Licenças Públicas ............................................................................................................... 26

2.3.2.1 Licença AGPL .............................................................................................................. 27

2.4 Metodologia de Implantação ................................................................................................ 28

2.5 Custo Total de Propriedade .................................................................................................. 29

2.6 Trabalhos Relacionados ........................................................................................................ 29

3.1 A empresa ............................................................................................................................. 31

3.2 Metodologia de implantação utilizada .................................................................................. 31

3.3 Recursos de hardware e backup da empresa ......................................................................... 33