Embed Size (px)
Citation preview
UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ
DEPARTAMENTO ACADÊMICO DE INFORMÁTICA
CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO
FELIPE LUIZ BILL
SISTEMA DE GESTÃO INTEGRADA PARA MICRO E PEQUENAS EMPRESAS DE TRANSPORTE RODOVIÁRIO DE CARGAS
TRABALHO DE CONCLUSÃO DE CURSO
CURITIBA
2013
FELIPE LUIZ BILL
SISTEMA DE GESTÃO INTEGRADA PARA MICRO E PEQUENAS EMPRESAS DE TRANSPORTE RODOVIÁRIO DE CARGAS
Monografia apresentada à disciplina de Trabalho de Conclusão de Curso do curso de Bacharelado em Sistemas de Informação da Universidade Tecnológica Federal do Paraná, como requisito parcial para obtenção do título de Bacharel.
Orientador: Prof. Dr. Alexandre Reis Graeml
CURITIBA
2013
TERMO DE APROVAÇÃO
Sistema de gestão integrada para micro e pequenas empresas de transporte rodoviário de cargas
Por
Felipe Luiz Bill
Esta dissertação foi apresentada às_______________________________________
do dia XX de abril de 2013 como requisito parcial para a obtenção do título de
BACHAREL EM SISTEMAS DE INFORMAÇÃO da Universidade Tecnológica
Federal do Paraná. O candidato foi arguido pela Banca Examinadora composta
pelos professores abaixo assinados. Após deliberação, a Banca Examinadora
considerou o trabalho__________________________________________________
(aprovado, aprovado com restrições, ou reprovado)
_________________________________ Prof. Dr. Alexandre Reis Graeml (UTFPR)
Orientador
_________________________________ Prof. Me. Fabiano Scriptore Carvalho
(UTFPR) Co-orientador _________________________________ Prof.Me. Luiz Augusto Pelisson
(UTFPR) Co-orientador Visto da coordenação:
______________________________ Prof.ª Dr.ª Mariângela de O. Gomes Setti
Coordenadora do Curso de Bacharelado em Sistemas de Informação
Aos meus pais Eli e Márcia, pelo apoio incondicional.
Aos meus irmãos Guilherme e Gustavo, pelo exemplo.
AGRADECIMENTOS
Dentre as pessoas que cruzaram meu caminho, muitas simplesmente
passaram, outras me acompanharam e me direcionaram. Certo de que o convívio
com estas últimas foi determinante para a formação de meu conhecimento, e acima
de tudo para a formação de minha pessoa, deixo minhas mais sinceras palavras de
gratidão.
Agradeço ao meu orientador o Professor Alexandre Reis Graeml pela sua
dedicação e pela orientação deste trabalho. Também agradeço aos meus co-
orientadores, os Professores Fabiano Scriptore Carvalho e Luiz Augusto Pelisson,
assim como agradeço às Professoras da disciplina de Trabalho de Conclusão de
Curso Marília Abrahão Amaral e Mariângela Gomes Setti, e a todos os demais
professores com quem convivi durante a graduação, pelo conhecimento
compartilhado.
A todos os meus colegas, pelas experiências divididas, em especial aos meus
amigos Leandro Piekarski do Nascimento, Lucas Hauptmann de Almeida, Lucas
Longen Gioppo e William Hitoshi Tsunoda Meira.
Em qualquer empresa, a tecnologia da informação exerce feitos poderosos sobre a vantagem competitiva, tanto no custo, quanto na diferenciação.
(PORTER, Michael)
RESUMO
BILL, Felipe. Sistema de gestão empresarial para micro e pequenas empresas de transporte rodoviário de cargas. 2013. Monografia (Bacharelado em Sistema de Informação) – Departamento Acadêmico de Informática, Universidade Tecnológica Federal do Paraná. Curitiba, 2013.
Esta pesquisa apresenta uma abordagem teórico-conceitual acerca das questões de implantação de sistemas de gestão empresarial com foco em micro e pequenas empresas de transporte rodoviário de cargas. Discute os conceitos de Enterprise Resources Planning bem como conceitos de transporte de cargas secas e fracionadas. O estudo envolveu uma pesquisa-ação em uma empresa característica desse segmento, a partir da qual se obteve subsídios para o desenvolvimento e na qual foram testadas as funcionalidades implementadas. Traz como resultado um modelo e um protótipo de um sistema de gestão empresarial para micro e pequenas empresas de transporte rodoviário de cargas.
Palavras-chave: Sistema de gestão empresarial. Enterprise Resources Planning. ERP. Transporte rodoviário de cargas. Micro e pequenas empresas.
ABSTRACT
BILL, Felipe. Enterprise resources planning system for micro and small companies of road haulage. 2013. Monografia (Bacharelado em Sistemas de Informação) – Departamento Acadêmico de Informática, Universidade Tecnológica Federal do Paraná. Curitiba, 2013.
It presents a theoretical-conceptual approach of relevant questions for the deployment an enterprise management system with focus on micro and small companies of road haulage. It discusses the concepts of Enterprise Resources Planning systems, as well as aspects of the transporting of less than full truck loads. Complemented by an action research on a typical firm of this segment, from which it received development grants and in which the features implemented were tested. As result, the study provides a model and a prototype enterprise resources planning system for micro and small companies of road haulage.
Keywords: Enterprise Resources Planning. Road haulage. Micro and small companies.
LISTA DE ILUSTRAÇÕES
Figura 1 - Distribuição das empresas por faixa de pessoal ocupado ........................ 18
Figura 2 - Visão funcional. ......................................................................................... 23
Figura 3 - Benefícios dos sistemas ERP ao longo do tempo .................................... 24
Figura 4 - Evolução do transporte rodoviário de cargas ............................................ 29
Figura 5 - Cronograma previsto para o projeto .......................................................... 34
Figura 6 - Cronograma efetivo do projeto .................................................................. 34
Figura 7 - Modelo de processos de negócio .............................................................. 39
Figura 8 - Organograma de uma empresa de transporte .......................................... 41
Figura 9 - Planilha eletrônica utilizadas na gestão dos processos ............................ 43
Figura 10 - Sistema legado ........................................................................................ 44
Figura 11 - Visão de casos de uso ............................................................................ 45
Figura 12- Detalhamento dos casos de uso do protótipo .......................................... 46
Figura 13 - Visão lógica ............................................................................................. 47
Figura 14 - Visão de implantação .............................................................................. 48
Figura 15 - Visão de implementação ......................................................................... 49
Figura 16 - Cálculo do valor do frete ......................................................................... 50
Figura 17 - Projeto conceitual de dados .................................................................... 57
Figura 18 - Projeto lógico de dados ........................................................................... 58
Figura 19 - Diagrama de transição de estados – Coleta ........................................... 59
Figura 20 - Diagrama de transição de estados - CT-e .............................................. 60
Figura 21 - Diagrama de transição de estados – Manifesto de viagem .................... 60
Figura 22 - Diagrama de transição de estados - Relação de entregas ..................... 61
Figura 23 - Diagrama de transição de estados – Fatura ........................................... 62
Figura 24 - Cadastro de clientes ................................................................................ 63
Figura 25 - Cadastro de CTe ..................................................................................... 64
Figura 26 - Cadastro de CTe: cálculo do valor do frete ............................................. 64
Figura 27 - Manual de instalação: estrutura de diretórios ......................................... 75
Figura 28 - Manual de instalação: configuração do banco de dados ........................ 76
Figura 29 - Interface gráfica do menu principal ......................................................... 77
Figura 30 - Interface gráfica do menu Comercial ...................................................... 77
Figura 31 - Interface gráfica do formulário de clientes .............................................. 78
Figura 32 - Interface gráfica do menu Operacional ................................................... 79
Figura 33 - Interface gráfica do formulário de CTe(1) ............................................... 79
Figura 34 - Interface gráfica do formulário de CTe(2) ............................................... 81
Figura 35 - Interface gráfica do formulário de emissão de CTe ................................ 82
Figura 36 - Interface gráfica do formulário de baixa de entregas .............................. 82
LISTA DE TABELAS
Tabela 1 - Aquisições ................................................................................................ 33
Tabela 2 - Custos referentes aos recursos humanos ................................................ 37
Tabela 3 - Composição do custo total do projeto ...................................................... 37
LISTA DE QUADROS
Quadro 1 - Recursos humanos .................................................................................. 35
Quadro 2 - Papéis/Responsáveis .............................................................................. 36
Quadro 3 - Partes envolvidas .................................................................................... 42
Quadro 4 - RQFN1 - Cadastrar clientes .................................................................... 51
Quadro 5 - RQFN2 - Alterar cadastro de clientes ...................................................... 52
Quadro 6 - RQFN3 - Pesquisar clientes .................................................................... 52
Quadro 7 - RQFN4 - Cadastrar conhecimentos de transporte .................................. 53
Quadro 8 - RQFN5 - Excluir conhecimentos de transporte ....................................... 53
Quadro 9 - RQFN6 - Cancelar conhecimentos de transporte ................................... 54
Quadro 10 - RQFN7 - Baixar conhecimentos de transporte ...................................... 54
Quadro 11 - RQFN8 - Emitir conhecimentos de transporte ....................................... 55
Quadro 12 - RQFN9 - Pesquisar conhecimentos de transporte ................................ 55
LISTA DE SIGLAS
BI Business Intelligence
CEP Código de Endereçamento Postal
CNPJ Cadastro Nacional de Pessoas Jurídicas
CPF Cadastro de Pessoas Físicas
CRM Costumer Relationship Management
CT-e Conhecimento de Transporte eletrônico
DACT-e Documento Auxiliar do CT-e
DDL Data Definition Language
ER Entidade-Relacionamento
ERP Enterprise Resources Planning
ICMS Imposto sobre Circulação de Mercadorias e Serviços
IE Inscrição Estadual
MPEs micro e Pequenas Empresas
MVC Model-View-Controller
MPN Modelagem de Processos de Negócio
MRP Manufacturing Resource Planning
PU Processo Unificado
SCM Supply Chain Management
SEBRAE Serviço Brasileiro de Apoio às Micro e Pequenas Empresas
SEFAZ Secretaria da Fazenda
SPED Sistema Público de Escrituração Digital
RG Registro Geral
RQFN Requisito Funcional
UF Unidade Federativa
UML Unified Modeling Language
TI Tecnologia da Informação
SUMÁRIO
1. Introdução ........................................................................................................... 17
1.1. Objetivo principal ............................................................................................. 19
1.2. Objetivos específicos ....................................................................................... 19
1.3. Justificativa ...................................................................................................... 19
1.4. Estrutura do documento .................................................................................. 20
2. Estado da arte .................................................................................................... 22
2.1. Características e histórico dos sistemas de gestão integrada ......................... 22
2.2. A inovação tecnológica como estratégia de competitividade .......................... 25
2.3. O transporte rodoviário de cargas no Brasil .................................................... 28
3. Metodologia ........................................................................................................ 31
3.1. Concepção ....................................................................................................... 31
3.2. Elaboração ....................................................................................................... 31
3.3. Construção ...................................................................................................... 32
3.4. Transição ......................................................................................................... 32
4. Gestão do projeto ............................................................................................... 33
4.1. Aquisições ....................................................................................................... 33
4.2. Tempo .............................................................................................................. 33
4.3. Recursos humanos .......................................................................................... 35
4.4. Custos .............................................................................................................. 36
5. Resultados .......................................................................................................... 38
5.1. Modelo dos processos de negócio .................................................................. 38
5.2. Visão ................................................................................................................ 40
5.2.1. Problema ...................................................................................................... 40
5.2.2. Ambiente ...................................................................................................... 41
5.2.3. Solução ......................................................................................................... 44
5.3. Arquitetura ....................................................................................................... 44
5.3.1. Visão de casos de uso ................................................................................. 45
5.3.2. Visão lógica .................................................................................................. 46
5.3.3. Visão de implantação ................................................................................... 47
5.3.4. Visão de implementação .............................................................................. 48
5.4. Especificação ................................................................................................... 49
5.4.1. Regras de negócio ....................................................................................... 50
5.4.2. Requisitos ..................................................................................................... 51
5.5. Modelo de dados ............................................................................................. 56
5.5.1. Modelo conceitual ......................................................................................... 56
5.5.2. Modelo lógico ............................................................................................... 57
5.5.3. Modelo Comportamental .............................................................................. 58
5.6. Interface do sistema com o usuário ................................................................. 63
5.7. Resultados da implantação do sistema ........................................................... 65
6. Considerações finais .......................................................................................... 67
Bibliografia ................................................................................................................. 69
Glossário .................................................................................................................... 72
Apêndice A – Manual de instalação .......................................................................... 75
Apêndice B – Manual de uso ..................................................................................... 77
17
1. Introdução
A globalização vem exigindo cada vez mais a busca por soluções em
competitividade, independentemente do segmento de mercado ou porte das
organizações. Mesmo as micro e pequenas empresas (MPEs) devem ser
enxergadas em escala global, pois estão dentro da cadeia de suprimentos (SCM)
como prestadoras de serviços de empresas maiores. Impulsionadas pelas
exigências que esse novo contexto introduziu, as organizações têm investido em
inovação tecnológica como estratégia de diferenciação. Nesse sentido, os sistemas
Enterprise Resources Planning (ERP) podem representar tal diferenciação,
fornecendo vantagem competitiva por meio de controles mais amplos sobre os
processos de negócio; bem como agilidade e confiabilidade sobre as informações,
permitindo uma tomada de decisão mais rápida e inteligente (MENDES e
ESCRIVÃO FILHO, 2007).
Esse tipo de sistema – também conhecido como sistema de gestão
empresarial, ou sistema de gestão integrada – teve sua origem nos setores
industriais produtivos e, portanto, muitas características ligadas à manufatura
persistem até hoje. Embora tais sistemas tenham aumentado sua abrangência,
cobrindo quase todo tipo de segmento de mercado, isso incorreu na necessidade de
customizá-los de acordo com cada tipo de negócio. Quanto maior a customização,
maior é o custo de implantação, treinamento e consultoria, o que restringe o acesso
de MPEs a esse tipo de solução (CAMPOS e CARVALHO, 2009). Apesar de essa
abrangência-customização ser considerada um dos princípios básicos dos sistemas
de gestão empresarial (HABERKORN, 2003), o número de soluções dedicadas a um
único tipo de negócio tem crescido consideravelmente. Nesse sentido, no segmento
de transporte e logística, em razão das particularidades de sua natureza, os
sistemas de gestão empresarial especializados são considerados fundamentais para
o sucesso do negócio (PELEIAS, et al., 2009).
18
Figura 1 - Distribuição das empresas por faixa de pessoal ocupado
Fonte: LOPES, CARDOSO e PICCININI (2008)
No Brasil, quanto ao porte, o setor de transporte e logística é um dos setores
cuja participação mais significativa é de micro e pequenas empresas, de acordo com
o exposto na Figura 1. Conforme levantamento realizado em 2005 pelo Ministério
dos Transportes, havia cerca de 60 mil empresas formalizadas nesse setor (PNLT,
2007 apud LOPES, CARDOSO e PICCININI, 2008). Dessas empresas, segundo os
critérios de classificação do SEBRAE, 92% são micro empresas (até 9 funcionários)
e 7% são de pequeno porte - de 10 a 49 empregados (IBGE, 2005 apud LOPES,
CARDOSO e PICCININI, 2008). O desempenho do setor é muito baixo quando
comparado aos níveis internacionais, tendendo a ser menor quanto menor for a
empresa, em razão da falta de padronização dos processos, controle e acesso a
informações (LOPES, CARDOSO e PICCININI, 2008).
Dentre os diversos modais de transporte (ferroviário, marítimo, aéreo,
rodoviário, entre outros), no Brasil, o mais difundido é o transporte rodoviário de
cargas, tendo sido responsável pela movimentação de 58% do volume de produção
industrial dentro do país em 2005 (LOPES, CARDOSO e PICCININI, 2008). Cabe
mencionar que, nesse mesmo ano, o transporte rodoviário de cargas secas
respondeu por 48,3% da receita líquida operacional do transporte (LOPES,
CARDOSO e PICCININI, 2008). Entende-se por cargas secas o transporte de
produtos manufaturados, ensacados ou embalados. No escopo deste trabalho serão
consideradas apenas as empresas que atuam sobre o modal terrestre, sendo as
cargas conduzidas em veículos com baú ou carroceria, ou seja, não serão
19
consideradas as questões pertinentes a outros modais ou às peculiaridades do
transporte rodoviário de líquidos em veículos específicos.
1.1. Objetivo principal
Levando em consideração o contexto apresentado, este trabalho tem como
objetivo geral desenvolver um sistema de gestão integrada para MPEs de transporte
rodoviário de cargas secas.
Dentre as delimitações principais do escopo deste trabalho, vale ressaltar que
ele não se propõe a resolver problemas relacionados a outras modalidades de
transporte, focando-se no modal rodoviário nacional de cargas secas; bem como
não se propõe a solucionar problemas de logística integrada (quando o
transportador armazena o estoque do cliente e decide quando entregar as
demandas deste).
1.2. Objetivos específicos
São objetivos específicos deste trabalho:
• elaborar um modelo de processos de negócio de uma micro empresa de
transporte rodoviário de cargas;
• desenvolver um projeto de software de um sistema de gestão empresarial,
de baixo custo, voltado estritamente para o modelo de negócio definido; e
• implementar um protótipo com base nesse projeto, com o intuito de
demonstrar sua aplicabilidade.
1.3. Justificativa
Dado o contexto acima descrito, uma das principais motivações para a
realização deste trabalho é a carência do segmento de pequenas e micro empresas
de transporte por um sistema de gestão empresarial de baixo custo. Considerando
que a maior parte do setor de transporte e logística no Brasil é composta por MPEs,
a solução proposta por este projeto deve ter um custo condizente com a realidade
20
financeira desse segmento, o que não é oferecido pelos softwares encontrados no
mercado atualmente.
Ademais, pode-se considerar como uma motivação complementar ao
desenvolvimento deste trabalho, a oportunidade de mercado que o Sistema Público
de Escrituração Fiscal (SPED) criará. No final da década de 90 houve um grande
impulso em direção à adoção de sistemas ERP em países como os Estados Unidos,
Inglaterra, Alemanha, entre outros, em razão das exigências de seus governos para
a declaração eletrônica de impostos (CAMPOS e CARVALHO, 2009). Em função do
SPED, outro grande impulso deve ocorrer no Brasil. No setor de transporte
rodoviário de cargas, o SPED será realizado por meio do Ajuste SINIEF 09/2007,
que institui o Conhecimento de Transporte Eletrônico (CT-e) e o Documento Auxiliar
do Conhecimento de Transporte Eletrônico (DACT-e) como meios exclusivos para
emissão de documentos fiscais no setor. Esse ajuste entra em vigor em Agosto de
2013 para as empresas optantes pelo Lucro Presumido e em Dezembro de 2013
para as empresas optantes pelo Simples Nacional (BRASIL, 2007).
1.4. Estrutura do documento
Nesta seção, são descritos os assuntos discutidos em cada capítulo deste
trabalho.
No Capítulo 2 – Estado da arte – são discutidos temas relacionados aos
sistemas de gestão empresarial, inovação tecnológica, competitividade e logística e
transporte no Brasil, conforme apresentados na literatura.
No Capítulo 3 – Metodologia – são descritos os procedimentos que
conduziram à realização deste trabalho.
No Capítulo 4 – Gestão do projeto – são detalhados os aspectos relacionados
aos recursos necessários à realização deste trabalho, incluindo recursos humanos,
custos e prazos.
No Capítulo 5 – Resultados – são apresentados os resultados obtidos pelo
desenvolvimento deste projeto, como a especificação, modelos e diagramas.
21
No Capítulo 6 – Considerações finais – é discutida a realização dos objetivos
deste trabalho, suas limitações e trabalhos futuros.
22
2. Estado da arte
Neste capítulo são apresentados os aspectos relacionados ao tema deste
trabalho, com base no referencial teórico publicado na área. Serão abordados os
seguintes aspectos: características e histórico dos sistemas de gestão integrada, a
inovação tecnológica como estratégia de competitividade e o transporte rodoviário
de cargas no Brasil.
2.1. Características e histórico dos sistemas de gestão integrada
Enterprise Resources Planning (ERP) - ou Sistema de Gestão Empresarial -
significa organização e planejamento dos recursos, de modo a fornecer controle
sobre os processos de negócio e transparência para a cadeia de suprimentos, além
de permitir a tomada de decisão rápida e inteligente (PADILHA e MARINS, 2005).
Considera-se que esses sistemas aumentam a integração e a confiabilidade sobre o
negócio, por meio de um fluxo de informações único, respaldado por uma base de
dados integrada (PADILHA e MARINS, 2005). Esses sistemas promovem o acesso
às informações eliminando as barreiras àqueles que estão nos níveis hierárquicos
mais altos, proporcionando confiabilidade e transparência (SANTOS, LIMA e
CARVALHO, 2010).
A fim de proporcionar a integração das diversas áreas funcionais de uma
organização, os sistemas ERP propõe uma nova perspectiva: a visão de processos.
Em detrimento da visão por departamentos, na qual cada departamento é
responsável apenas pelas partes do processo de negócio que lhe competem, a
visão de processos impõe que as atividades sejam enxergadas através das áreas
funcionais da empresa, sendo que sua vantagem advém de uma melhor análise e
controle dos workflows (fluxos produtivos) (PADILHA e MARINS, 2005).
Os sistemas ERP tiveram sua origem na manufatura industrial no início da
década de 1960, em função da necessidade do controle de materiais. Do controle de
estoques, ao cálculo de custos e preços, surgiu o MRP (Material Requirements
Planning). Por meio da inclusão de procedimentos para o planejamento da
capacidade produtiva, esse sistema evoluiu para a versão MRP II, que permitia
23
analisar os recursos necessários à produção e os tempos das operações de
manufatura, facilitando a programação produtiva (HABERKORN, 2003).
O termo ERP somente foi introduzido no final da década de 1980, sendo
utilizado para designar sistemas MRP II que também contemplavam os processos
de negócio dos departamentos de contabilidade, finanças, vendas, distribuição,
recursos humanos, dentre outros (HABERKORN, 2003). Hoje, fala-se inclusive sobre
a tendência de enxergar as organizações dentro das cadeias produtivas, ligando
fornecedores (Supply Chain Management) a consumidores (Customer Relationship
Management) (PADILHA e MARINS, 2005). Publicações têm cada vez mais
destacado a integração das empresas com as atividades de SCM e CRM (MENDES
e ESCRIVÃO FILHO, 2007). A Figura 2 ilustra a organização dos módulos de um
sistema de gestão integrada.
Figura 2 - Visão funcional.
Fonte: PADILHA e MARINS (2005)
24
Em razão de sua origem na área de produção industrial, os sistemas ERPs
em geral ainda guardam características relacionadas à manufatura. Isso dificulta a
obtenção dos seus benefícios, quando aplicado a empresas prestadoras de serviços
(PELEIAS, et al., 2009). Segundo Biancolino e Riccio (2011), cerca de 70% das
implantações de sistemas ERP chegam ao seu final oferecendo menos
funcionalidades aos usuários do que as previstas originalmente como necessárias
ao pleno atendimento do fluxo de informações das empresas. A Figura 3 mostra a
relação entre o uso e os benefícios de um ERP.
Figura 3 - Benefícios dos sistemas ERP ao longo do tempo
Fonte: BIANCOLINO e RICCIO (2011)
Essa diferença entre as potencialidades planejadas e os benefícios
alcançados ocorre muitas vezes em razão da má adequação dos parâmetros do
sistema ao tipo de negócio, pois as funcionalidades de um sistema ERP
representam uma solução genérica que reflete uma série de considerações sobre a
forma como as empresas operam em geral (PADILHA e MARINS, 2005).
Embora seja considerada um dos princípios básicos dos sistemas ERP
(HABERKORN, 2003), a parametrização deve ser entendida como a possibilidade
25
de manipular o sistema de modo a extrair informações conforme a necessidade da
organização, sem a produção de código, a exemplo do que oferecem os sistemas
ERP de código aberto ERP5 e Compiere (SERRANO e SARRIEGI, 2006).
Parametrização pode ser enxergada como normas, políticas e processos
(CONTADOR e NANINI, 2004). Em suma, deixa de ser a adequação completa do
sistema ao segmento de negócio e passa a ser apenas um ajuste fino em relação às
mínimas particularidades da empresa, de modo a proporcionar o pleno uso de suas
potencialidades.
Além do uso pleno dos sistemas de gestão integrada, o alcance da
competitividade exige modificações na cultura organizacional e uma reengenharia
dos processos de negócio. O conceito de competitividade associado aos sistemas
ERP não advém do suposto dinamismo que o sistema proporciona e sim da cultura
organizacional, de modo que o objetivo deixa de ser a simples aquisição do software
e passa a ser o alinhamento estratégico do negócio para potencializar o uso da TI
(CONTADOR e NANINI, 2004). Ainda sobre esse alinhamento estratégico, Silva e
Pereira (2006) consideram fundamental a assimilação de novos processos, de modo
a otimizar as funcionalidades da TI.
2.2. A inovação tecnológica como estratégia de competitividade
A competitividade global exige decisões rápidas (CAMPOS e CARVALHO,
2009). Para alcançar tal competitividade, as empresas investem cada vez mais em
inovação tecnológica. Todavia, antes de tratar da inovação tecnológica como
diferencial estratégico, é importante caracterizar competitividade e competência.
Competência pode ser definida como um conjunto de habilidades e tecnologias que
permite a uma empresa oferecer determinado benefício. As competências podem
ser classificadas em: flexibilidade estratégica (gerenciar riscos), competência de
inovação (novos produtos e tecnologias), ou capacidade de absorção e liderança de
mercado (BIANCOLINO e RICCIO, 2011). Contudo, vale salientar que, dada a
disponibilização da mesma tecnologia aos concorrentes, a exemplo dos sistemas
ERP, por si própria, essa não mais pode ser considerada como diferencial de
competitividade da organização (BIANCOLINO e RICCIO, 2011).
26
Independente do setor ou porte de uma empresa, toda organização deve ser
analisadas sob a perspectiva da competitividade em escala mundial (PADILHA e
MARINS, 2005). Ainda que uma MPE não apresente as mesmas características de
uma grande empresa, é importante salientar que a passagem de uma dimensão a
outra ocorre em função de mudanças qualitativas, em detrimento das quantitativas
(SILVA e PEREIRA, 2006). As micro e pequenas empresas são apenas ambientes
menos complexos (BRODBECK, 2004) e seria “inconsequente desconsiderar as
particularidades e peculiaridades desse segmento, principalmente a característica
referente à disponibilidade de recursos para investimento em tecnologia” (MENDES
e ESCRIVÃO FILHO, 2007). Deve-se salientar ainda outra característica própria da
estrutura organizacional das MPEs, no que concerne ao número limitado de
funcionários e aos diversos papéis que esses assumem (MENEZES e GUEVARA,
2010).
Embora a competitividade possa ser alcançada por meio da estratégia de
competição por preço, essa é considerada pouco efetiva pela maioria das empresas
(CONTADOR e NANINI, 2004). Sobre a diminuição dos custos e tamanho do setor
de TI, as empresas estão cada vez mais comprando pacotes ERP prontos
(HOLLAND e LIGHT, 1999), como uma estratégia de terceirização do setor de TI
(PADILHA e MARINS, 2005). Entretanto, considera-se que a visão distorcida da
redução de custos levou a muitos insucessos em implantações de sistemas ERP
(BRODBECK, 2004). Além da diminuição dos custos de TI, segundo Ozen, Basoglu
e Daim (2008), são objetivos da adoção de um ERP:
• descentralizar a informação tornando-a disponível em tempo real;
• prover ferramentas tecnológicas que facilitem a gestão;
• criar uma base que permita o crescimento;
• melhorar o controle e a sinergia, identificando indicadores de desempenho
dos processos;
• trocar informações eletronicamente;
• inovar para acompanhar ou ultrapassar concorrentes;
Sistemas ERP são indicados para empresas em crescimento, com quadro
financeiro positivo, para sustentar o alto investimento, pois o valor de retorno efetivo
é previsto apenas no longo prazo (SANTOS, LIMA e CARVALHO, 2010). Somado
27
ao retorno de investimento em longo prazo, cabe salientar o alto custo desses
sistemas, sendo o valor médio de 15 milhões de dólares, ou aproximadamente $50
dólares por usuário por mês (PADILHA e MARINS, 2005). Para contornar esse
problema, os sistemas ERP de código aberto fornecem uma boa solução, abrindo
novas oportunidades para MPEs (CAMPOS e CARVALHO, 2009). Todavia, a
implantação bem sucedida de um ERP de código livre depende de empresas de
consultoria confiáveis (SERRANO e SARRIEGI, 2006). Além disso, vale ressaltar
que custos menores podem significar qualidade inferior de serviço (CAMPOS e
CARVALHO, 2009).
Em função do custo elevado, os sistemas ERP ficaram restritos a grandes
empresas (SERRANO e SARRIEGI, 2006). Ademais, as empresas de pequeno
porte costumam apresentar uma percepção incorreta sobre a relação entre o
investimento em tecnologia da informação e seu retorno, pois os benefícios
operacionais gerados pelos ERPs tornam-se presentes no cotidiano das empresas
com maior antecedência que os benefícios gerenciais e estratégicos (BIANCOLINO
e RICCIO, 2011). Os benefícios reais somente serão percebidos no longo prazo, o
que leva ao não reconhecimento do ERP como uma competência capaz de gerar
vantagens competitivas. Contudo, as empresas devem reconhecer que a ausência
de sistemas integrados de gestão empresarial pode gerar uma desvantagem
competitiva (BIANCOLINO e RICCIO, 2011).
A fim de viabilizar baixos custos a esses sistemas, deve-se analisar sua
composição, bem como, deve-se propor alternativas que incorram na diminuição
desses valores. Segundo Padilha e Marins (2005), os custos relacionados aos
sistemas ERP são de: treinamento, integração, conversão de dados, consultoria,
pessoal e prazo de implantação. Quanto à integração - adequação dos parâmetros
do sistema ao segmento de negócios do cliente - pode-se considerar que a
estratégia de sistemas dedicados minimiza esse custo, sendo que o valor residual é
devido aos ajustes finos em relação às particularidades da empresa. Um dos
aspectos críticos desta etapa é a adequação das organizações aos processos
contábeis definidos pela legislação vigente, sendo um dos fatores que implica no
aumento dos custos da implantação do sistema (PELEIAS, TREVIZOLI, et al., 2009).
Um dos pontos favoráveis à adoção de software nacional é a adequação facilitada à
conformidade tributária e às restrições jurídicas (PADILHA e MARINS, 2005). Nesse
28
sentido, as soluções dedicadas a um único segmento de negócio podem ser mais
vantajosas, pois somente é necessário adequá-las a um único conjunto de
conformidades legais.
Além de promover a visão de processos e a gestão integrada (funcional e
hierárquica), os sistemas ERP têm apresentado tendências em termos de gestão da
cadeia produtiva, apelo ao mercado de MPEs, modularização, Business Intelligence,
entre outros (PADILHA e MARINS, 2005). Business Intelligence (BI) é uma
expressão genérica, utilizada para designar tecnologias de exploração de dados,
com aplicações que permitem às empresas a análise de correlações e tendências, e
facilitam a tomada de decisão (PADILHA e MARINS, 2005). A respeito do foco nas
MPEs, o principal entrave à difusão dos sistemas de gestão integrada consiste na
diminuição dos custos, visto que o preço deve ser condizente com a realidade
financeira dessas empresas.
2.3. O transporte rodoviário de cargas no Brasil
Desde o início dos anos 1990, tanto nos Estados Unidos e Europa, quanto no
Brasil, as empresas têm seguido a tendência de terceirizar processos de negócio
que fogem de sua core competence (principal processo de negócio da organização).
Essa tendência foi evidenciada pela intensa contratação de serviços de operadores
logísticos (WANKE e FLEURY, 2006). Operadores logísticos, prestadores de
serviços logísticos, empresas de logística contratada, ou transportadores são
empresas que realizam coleta e entrega de bens de consumo produzidos por
terceiros. Os transportadores eventualmente realizam processos de montagem de
carga, desconsolidação, embalagem, etiquetagem, gerenciamento da cadeia de
suprimentos, reposição de estoques, entre outros.
No Brasil, o principal serviço prestado pelos operadores logísticos é o
transporte de carga seca. Não são consideradas cargas secas: perecíveis, líquidos e
granel (LOPES, CARDOSO e PICCININI, 2008). O transporte desse tipo de carga é
realizado predominantemente por meio do modal rodoviário.
29
Figura 4 - Evolução do transporte rodoviário de cargas
Fonte: LOPES, CARDOSO e PICCININI (2008)
Ainda que esse segmento tenha apresentado crescimento considerável (vide
Figura 4), o percentual de participação de empresas informais ainda é muito
elevado, o que contribui para a falta de qualidade do setor (LOPES, CARDOSO e
PICCININI, 2008). Em 2005, havia cerca de 60 mil empresas formalizadas. Contudo,
vale ressaltar que a participação operacional das empresas informais superou 80%
da movimentação do mercado em 2003 (LOPES, CARDOSO e PICCININI, 2008).
Nesse sentido, não são consideradas informais apenas as empresas sem
constituição jurídica, mas também aquelas que apresentam as seguintes
características: baixo nível de renda, trabalho por conta própria, atraso tecnológico,
ambiente precário, falta de registro contábil, entre outros (LOPES, CARDOSO e
PICCININI, 2008).
Dois dos principais entraves ao crescimento e melhoria da qualidade desse
setor são a dificuldade de contratação e a manutenção de pessoal qualificado
(WANKE e FLEURY, 2006). Isso decorre do receio de perder o controle de sua
logística e, consequentemente, do nível de serviço prestado, conforme a
organização expande seus negócios. Nesse sentido, o ERP pode ser utilizado de
forma a suportar o crescimento, planejando e mantendo o controle e a qualidade dos
processos, além de colaborar para a manutenção do conhecimento dentro da
organização (WANKE e FLEURY, 2006).
30
Este levantamento bibliográfico é complementado por uma pesquisa em uma
empresa característica do segmento. Os aspectos do modelo de negócio, seus
problemas e necessidades são apresentados nos resultados deste projeto, que
estão descritos no Capítulo 5.
31
3. Metodologia
A metodologia escolhida para o desenvolvimento deste projeto é descrita em
termos de um ciclo de vida de desenvolvimento de sistemas. Para a realização deste
trabalho, optou-se pela utilização do processo unificado (PU): uma metodologia de
desenvolvimento iterativa e incremental, centrada na arquitetura e orientada a casos
de uso (KRUCHTEN, 2003). As atividades do PU são organizadas em 4 fases:
concepção, elaboração, construção e transição. Este capítulo descreve tais fases,
as atividades realizadas e seus resultados.
3.1. Concepção
A concepção consiste em atividades relacionadas à análise. Nessa fase
ocorrem a modelagem de processos do negócio e o levantamento de requisitos. A
primeira tem como objetivo identificar aspectos da estrutura e da dinâmica da
organização onde o sistema será implantado (KRUCHTEN, 2003); a segunda,
estabelecer o entendimento comum entre a organização e os desenvolvedores
acerca das funcionalidades, capacidades e restrições do sistema (SOMMERVILLE,
2011). Os pacotes de trabalho resultantes desta fase são:
• o modelo de negócios; e
• a especificação do projeto.
3.2. Elaboração
A elaboração tem como objetivo transformar os requisitos e regras de negócio
em um projeto de software. Os resultados desta fase consistem em um conjunto de
modelos e diagramas do projeto de software e um protótipo estrutural e evolutivo da
arquitetura do sistema. Protótipos estruturais e evolutivos são aqueles utilizados
para consolidar a base do sistema, não sendo descartados posteriormente
(KRUCHTEN, 2003). Os pacotes de trabalho resultantes desta fase são:
• a arquitetura do sistema; e
• o projeto do sistema.
32
3.3. Construção
A construção consiste na transformação do projeto em código executável.
Nessa fase são realizados testes unitários intercalados entre as atividades de
desenvolvimento. Cada funcionalidade tem seu projeto refinado e é desenvolvida e
testada por meio de incrementos pontuais (KRUCHTEN, 2003). Ao término desta
fase são realizados os testes de integração. Esses testes têm como objetivo verificar
se o sistema foi desenvolvido de forma correta e se supre as necessidades e
expectativas do cliente (SOMMERVILLE, 2011). Atendidos os critérios de aceite, o
sistema passa do ambiente de desenvolvimento para o ambiente de produção. O
pacote de trabalho resultante desta fase é o sistema executável.
3.4. Transição
O propósito desta fase é garantir uma transição suave para o ambiente de
produção. Além da implantação em si, deve-se levar em conta aspectos de
distribuição, instalação e migração de bases de dados e sistemas legados. Nessa
fase são desenvolvidos os manuais de instalação e de usuário (KRUCHTEN, 2003).
O pacote de trabalho resultante desta fase é o manual de uso.
33
4. Gestão do projeto
O gerenciamento do projeto tem como propósito planejar, executar, controlar
e corrigir o projeto (KRUCHTEN, 2003). Um projeto é um esforço temporário para
criar um produto exclusivo, sendo seu término determinado quando os objetivos são
atingidos, ou quando se conclui que não é possível atingi-los (PMI, 2008). Nesse
sentido, o objetivo deste projeto era desenvolver um sistema de gestão integrada
para micro e pequenas empresas de transporte rodoviário de cargas condizente com
a realidade financeira desse segmento. O propósito deste capítulo é descrever a
composição dos custos do projeto em função do tempo e do escopo, a fim de
demonstrar que era possível realizar tal projeto com baixo custo. Nesse sentido, são
discutidos: aquisições, recursos humanos, tempo e os custos propriamente ditos.
4.1. Aquisições
Aquisições são bens ou serviços necessários para a realização do projeto e,
que não são desenvolvidos pela organização executora, ou seja, devem ser
adquiridos de terceiros (PMI, 2008). A Tabela 1 apresenta as aquisições previstas
para a implantação deste projeto e seus respectivos valores estimados, assim como
os valores incorridos.
Tabela 1 - Aquisições
Itens Valor estimado Valor incorrido
Microcomputador R$ 1000,00 R$ 890,00
Certificado digital A3 (válido por 3 anos)
R$ 350,00 R$555,00
Impressora matricial R$ 300,00 R$ 350,00
TOTAL R$ 1650,00 R$ 1795,00 Fonte: autoria própria
4.2. Tempo
Dados os pacotes de trabalho definidos no ciclo de vida deste projeto, as
atividades que resultarão nesses são definidas e sequenciadas, originando o
34
cronograma, conforme sugerido em PMI (2008). A Figura 5 apresenta o cronograma
previsto para este projeto.
Figura 5 - Cronograma previsto para o projeto
Fonte: autoria própria
Figura 6 - Cronograma efetivo do projeto
Fonte: autoria própria
35
A Figura 6 apresenta o cronograma efetivo do projeto. Em comparação ao
cronograma previsto, percebe-se que sua realização foi iniciada com um mês de
antecedência, o que permitiu a intensificação dos testes e treinamentos na etapa de
transição do projeto. Ademais, a utilização de padrões de projeto diminuiu o esforço
necessário para a implementação de determinados aspectos do código,
compensando o aumento imprevisto do esforço demandado para a realização de
outras particularidades.
O prazo de execução é um fator decisivo para a viabilidade de um projeto,
pois garante competitividade diante da concorrência. Nesse aspecto, outro ponto
positivo dos sistemas especializados para MPEs reside no fato da necessidade de
customização ser menor (PADILHA, 2004), permitindo a realização desta tarefa em
prazos menores, sem necessariamente mobilizar equipes grandes. Essa redução
nos custos e tempo dos processos de implantação incorre em maior satisfação dos
clientes (PELEIAS, et al., 2009).
4.3. Recursos humanos
A gestão de recursos humanos envolve identificar e definir funções,
responsabilidades e relacionamentos dentro de um projeto (PMI, 2008). O conjunto
dessas responsabilidades e comportamentos é denominado papel. Um papel pode
ser realizado por uma única pessoa ou por uma equipe de desenvolvimento
(KRUCHTEN, 2003). O Quadro 1 apresenta os papéis previamente identificados
para o desenvolvimento deste projeto.
Quadro 1 - Recursos humanos
Papel Responsabilidades Habilidades exigidas
1. Gerente de projetos
Controlar e coordenar as
atividades.
Experiência em
gestão de projetos
de software.
2. Analista de sistemas
Identificar problemas e
necessidades do cliente.
Especificar requisitos e casos de
Experiência em
projeto unificado.
36
uso.
3. Arquiteto de sistemas
Projetar a arquitetura do sistema
(módulos, subsistemas, camadas
e interfaces).
Experiência em
projetos com a
tecnologia JAVA.
4. Projetista de aplicação
Projetar os modelos de software. Experiência em
modelagem UML.
5. Projetista de banco de dados
Projetar e implementar o banco de
dados utilizado no sistema.
Experiência em
projetos de bancos
de dados.
6. Desenvolvedor Implementar código, testar
unidades e desenvolver interfaces
gráficas.
Experiência em
desenvolvimento
com a tecnologia
JAVA.
7. Testador Validar o sistema. Experiência em
testes. Fonte: autoria própria
O Quadro 2 relaciona os papéis descritos no Quadro 1 e seus responsáveis.
Quadro 2 - Papéis/Responsáveis
Papéis Responsável
1,2,3,4,5,6 e 7 Felipe Luiz Bill Fonte: autoria própria
4.4. Custos
O custo total estimado para um projeto é equivalente à soma dos custos das
aquisições e das contratações. Considerando que os papéis descritos no Quadro 1
foram realizados por um único desenvolvedor de sistemas, o custo das contratações
foi igual ao tempo de contratação multiplicado pelo valor da mão-de-obra. A Tabela 2
apresenta os custos referentes aos recursos humanos (incluindo os encargos
trabalhistas estimados), ao passo que a Tabela 3 apresenta o custo estimado total
deste projeto.
37
Tabela 2 - Custos referentes aos recursos humanos
Papel Custo estimado por mês
Tempo de contratação
Custo estimado
Desenvolvedor de sistemas R$ 4.000,00 5 meses R$20.000,00 Fonte: autoria própria
Tabela 3 - Composição do custo total do projeto
Custo estimado total
Aquisições (referente à Tabela 1) R$1.650,00
Recursos humanos (referente à Tabela 2) R$20.000,00
TOTAL R$21.650,00 Fonte: autoria própria
38
5. Resultados
Neste capítulo são apresentados os resultados deste trabalho. Conforme
sugere o processo unificado, o projeto deve ser tão detalhado quanto necessário
para eliminar ambiguidades e aspectos dúbios (KRUCHTEN, 2003). Nesse sentido,
são apresentados apenas os seguintes modelos e diagramas:
• modelo de processos de negócio;
• visão de casos de uso;
• visão lógica do sistema (diagrama de pacotes);
• visão de implantação (diagrama de deployment);
• visão de implementação (diagrama de componentes);
• modelo conceitual de dados (diagrama de classes);
• modelo lógico de dados (diagrama entidade-relacionamento); e
• modelos comportamentais (diagramas de transição de estados).
Por fim, são apresentadas as interfaces do sistema com o usuário.
5.1. Modelo dos processos de negócio
A modelagem de negócios tem como objetivo representar a estrutura e a
dinâmica da organização onde o sistema será implantado. Isso facilita a identificação
dos problemas e necessidades do cliente e; por conseguinte, a definição dos
requisitos do sistema. O processo unificado sugere a utilização de modelos UML
para tal representação, pois sua conversão para os modelos de software torna-se
mais fácil (KRUCHTEN, 2003).
Por meio dos modelos de processo de negócio, é possível identificar quais
pontos podem ser aperfeiçoados ou reaproveitados. “A reengenharia começa com o
reuso, passa pelo reuso e termina com o reuso de processos” (DANEVA, 2004), o
que faz da Modelagem de Processos de Negócio (MPN) um fator essencial para
alinhar o sistema ERP e os processos de negócio do cliente. Segundo Silva e
Pereira (2006), são diretrizes da MPN:
39
• capturar e formalizar os processos empresariais;
• gerar diferentes visões do negócio;
• decompor os processos funcionalmente;
• decompor a organização, do ponto de vista hierárquico;
• projetar um sistema em módulos;
• classificar os processos estáticos e dinâmicos;
• separar entre atividades e recursos; e
• adequar os processos com os registros do sistema.
Figura 7 - Modelo de processos de negócio
Fonte: autoria própria
A Figura 7 representa as principais atividades de negócio de uma empresa de
transporte rodoviário de cargas. Nesse modelo, não estão representados processos
auxiliares como: atividades contábeis, de recursos humanos, entre outros. As
40
relações de dependência entre os casos de uso de negócio indicam as atividades
predecessoras de cada processo de negócio.
5.2. Visão
Com base nos processos de negócio identificados no modelo da Figura 7, e
respaldado pelo referencial teórico obtido pelo levantamento bibliográfico realizado
neste trabalho, obteve-se uma visão geral do tipo de organização onde o sistema
será implantado, bem como de suas necessidades. Essa visão é detalhada a seguir
nos seguintes aspectos: problema, ambiente e solução. Em problema, são descritas
as necessidades do cliente; em ambiente, a solução provisória ora utilizada por ele
para contornar essas necessidades; e em solução, os aspectos gerais da solução
definitiva que este trabalho propõe.
5.2.1. Problema
Os processos de negócio de uma empresa de transportes muitas vezes não
são coordenados ou controlados. Quando muito, isso é feito por meio de formulários
impressos ou planilhas eletrônicas descentralizadas, de modo que a informação
pode se perder, ser redundante ou contraditória. Ademais, o acesso à informação
pode se tornar moroso, o que gera problemas à gestão do negócio e falta de
transparência aos consumidores e fornecedores.
No tocante às conformidades legais, as empresas de transporte devem
realizar suas obrigações tributárias principal e acessória. A obrigação principal tem
por objeto o pagamento de tributo; e a acessória, as prestações positivas ou
negativas no interesse da arrecadação e fiscalização desses tributos. Em outras
palavras, a obrigação acessória diz respeito à emissão de documentos fiscais
(BRASIL, 1966). Nesse sentido, outro problema encontrado pelas empresas de
transporte diz respeito à emissão eletrônica de documentos fiscais relativos às
atividades de negócio realizadas: os conhecimentos de transporte eletrônico.
41
5.2.2. Ambiente
A caracterização do ambiente de uma organização representa como ela é
organizada internamente e as partes envolvidas no negócio. Essa representação
permite identificar como as diversas partes (internas e externas) contornam os
problemas relacionados à informação. A Figura 8 apresenta um organograma de
uma microempresa de transporte rodoviário de cargas. Nesse caso, vale destacar
que as questões pertinentes às finanças, aos contratos de venda e à prestação de
contas competem exclusivamente ao nível estratégico. Ademais, em empresas
desse porte, as questões acerca de recursos humanos nas filiais são resolvidas de
modo descentralizado, ou seja, cada filial tem autonomia para decidir sobre esses
problemas. O atendimento ao consumidor também é realizado localmente.
Figura 8 - Organograma de uma empresa de transporte
Fonte: autoria própria
O Quadro 3 apresenta uma breve descrição dos principais papéis (internos e
externos) envolvidos no ambiente de uma empresa de transporte rodoviário de
cargas.
Finanças Contabilidade Comercial Diretoria
Gerência
Logís8ca
Recursos humanos
Atendimento ao
consumidor
Estratégico
Tático
Operacional
42
Quadro 3 - Partes envolvidas
Partes envolvidas Papel
Diretores da transportadora Obter informações resumidas sobre os
processos financeiros operacionais
globais para melhor coordená-los e
controlá-los.
Gerentes da transportadora Obter informações resumidas sobre os
processos operacionais locais para
melhor coordená-los e controlá-los.
Operadores da transportadora Obter e fornecer informações sobre os
processos operacionais, a fim de realizá-
los.
Gerente financeiro Obter informações sobre os processos
operacionais finalizados para realizar a
cobrança sobre os serviços prestados.
Gerente comercial Obter informações sobre o uso e a
capacidade das linhas para decidir sobre
o preço do serviço e investimento sobre
as rotas.
Atendimento ao consumidor Fornecer informações acerca do
andamento dos processos operacionais,
bem como sobre cotações de serviços.
Instituição bancária Realizar cobranças pelos serviços
prestados por meio de boletos
bancários.
Seguradora Obter relatórios de mercadorias
transportadas para realizar o seguro.
Contabilidade terceirizada Obter relatórios de serviços prestados
para apurar, pagar e declarar impostos.
Secretaria da Fazenda Obter informações acerca dos serviços
prestados para exigir as obrigações
tributárias principal e acessória. Fonte: autoria própria
43
Conforme citado anteriormente, para contornar os problemas relacionados à
informação, as empresas de pequeno porte que não dispõem de um sistema de
gestão integrada costumam utilizar planilhas eletrônicas. Tais planilhas contêm
dados dos clientes, motoristas, parceiros, veículos, custos, contas, operações
realizadas, etc. Essas planilhas podem ser consideradas no projeto de um sistema
de gestão integrada como sistemas legados. Em relação à conversão de dados,
Padilha (2004) afirma que a compatibilidade com sistemas legados é outro fator que
incorre no aumento do tempo necessário para a implantação e, consequentemente,
em custos maiores.
Figura 9 - Planilha eletrônica utilizadas na gestão dos processos
Fonte: autoria própria
Contudo, pode-se considerar que muitas MPEs sequer possuem um sistema
legado, minimizando esse fator de custo. As figuras 9 e 10 ilustram um exemplo de
planilha eletrônica utilizada para a gestão de informações em uma empresa de
transporte de cargas.
44
Figura 10 - Sistema legado
Fonte: autoria própria
Sistemas legados possuem informações sobre a estrutura organizacional,
cultura e processos de negócio. Inevitavelmente, tais sistemas determinam o
impacto da mudança, em razão da dependência da organização em relação aos
processos do sistema (HOLLAND e LIGHT, 1999).
5.2.3. Solução
Em face dos problemas e necessidades identificados em um ambiente típico
de uma microempresa de transporte rodoviário de cargas, bem como em função das
restrições e premissas discutidas no levantamento bibliográfico, este trabalho propôs
o desenvolvimento de um sistema computacional para a gestão dos processos de
negócio. A arquitetura e as funcionalidades dessa solução são detalhadas nos
próximos itens.
5.3. Arquitetura
O projeto de arquitetura descreve a organização e a estrutura geral de um
sistema (SOMMERVILLE, 2011). “Architecture is what remains when you cannot take
45
away any more things and still understand the system and explain how it works”
(KRUCHTEN, 2003, p.82). Sugere-se o uso de 5 visões para representar a arquitetura
de um sistema: casos de uso, lógica, implementação, implantação e processos. Em
virtude deste projeto não prever a existência de processos paralelos, essa visão não foi
nem projetada, nem descrita.
5.3.1. Visão de casos de uso
Casos de uso são fluxos de ações entre um ator e o sistema, que produzem
resultados de valor observável para um ator específico. Casos de uso podem ser
utilizados para capturar os requisitos do projeto (KRUCHTEN, 2003). Esses
requisitos podem ser definidos em dois níveis de detalhamento: os requisitos de
usuário e de sistema. Os requisitos de usuário são descrições de alto nível, ao
passo que os requisitos de sistema são detalhamentos dessas descrições. Um
requisito de usuário pode ser expandido em diversos requisitos de sistema
(SOMMERVILLE, 2011). Nesse sentido, a visão de casos de uso (Figura 11)
apresenta todos os requisitos de usuário deste projeto.
Figura 11 - Visão de casos de uso
Fonte: autoria própria
46
. Os casos de uso realizados pelo protótipo - resultado deste projeto – são
detalhados por meio de requisitos de sistema, sendo que os casos de uso
correspondentes são detalhados na Figura 12, e suas descrições constam na
Especificação.
Figura 12- Detalhamento dos casos de uso do protótipo
Fonte: autoria própria
5.3.2. Visão lógica
Visando facilitar a transformação deste projeto em um sistema web, optou-se
por utilizar o padrão de arquitetura conhecido como MVC (model-view-controller).
Nesse padrão, as classes são divididas em função de suas responsabilidades,
sendo a apresentação e a interação separadas dos dados do sistema
(SOMMERVILLE, 2011). Essa independência entre as camadas permite transformar
o aplicativo desktop em um sistema web, por meio da simples substituição da
camada de visão. Os pacotes de classes, suas dependências e responsabilidades
são representados na Figura 13.
47
Figura 13 - Visão lógica
Fonte: autoria própria
5.3.3. Visão de implantação
A visão de implantação representa a topologia do hardware em que o sistema
é executado. Nessa topologia, cada nó corresponde a um “elemento físico que
existe em tempo de execução e representa um recurso computacional” (BOOCH,
RUMBAUGH e JACOBSON, 2012). Essa visão é representada por um diagrama de
componentes. A Figura 14 apresenta a visão de implantação deste projeto.
48
Figura 14 - Visão de implantação
Fonte: autoria própria
5.3.4. Visão de implementação
A visão de implementação descreve a organização dos componentes de
software. Um componente é uma classe não trivial que possui uma interface e um
propósito bem definidos (KRUCHTEN, 2003). A Figura 15 apresenta e descreve os
principais componentes e artefatos deste projeto.
49
Figura 15 - Visão de implementação
Fonte: autoria própria
5.4. Especificação
A especificação de requisitos de software é uma declaração formal de suas
funcionalidades, capacidades e restrições. Essa especificação é resultado do
processo de engenharia de requisitos, ou o “processo de descobrir, analisar,
documentar e verificar requisitos” (SOMMERVILLE, 2011). Entre as técnicas de
descoberta de requisitos, consta a modelagem de casos de uso. O conjunto de
casos de uso representa todas as interações possíveis com o sistema. Como casos
de uso não são eficazes para elicitar restrições de domínio, estas são descritas
separadamente em termos de regras de negócio.
O nível de detalhamento do documento de requisitos varia conforme o tipo de
projeto. Se o projeto for crítico ou em tempo real, é necessário um maior
detalhamento (SOMMERVILLE, 2011). Como este projeto não envolve um sistema
crítico, os requisitos serão descritos somente com o detalhamento necessário para
evitar ambiguidade. Ainda nesse sentido, somente são detalhados os requisitos que
são realizados no protótipo resultado deste projeto.
50
5.4.1. Regras de negócio
Regras de negócio estão diretamente ligadas a restrições de domínio. Essas
restrições advêm de relações da estrutura organizacional, procedimentos de negócio
e conformidades com a legislação vigente (KRUCHTEN, 2003). Nesse sentido, para
o desenvolvimento deste projeto, foi observada apenas a regra de negócio
relacionada ao cálculo do valor de frete, representada pela Figura 16.
Figura 16 - Cálculo do valor do frete
Fonte: autoria própria
Para efeitos do cálculo do valor do frete, deve ser considerada a alíquota de
12% para operações interestaduais iniciadas no Paraná que destinem bens e
mercadorias aos estados de Minas Gerais, Rio Grande do Sul, Rio de Janeiro, Santa
51
Catarina e São Paulo e 7% para operações interestaduais iniciadas no Paraná que
destinem bens e mercadorias ao Distrito Federal e demais estados (PARANÁ,
2008). Ademais, as operações internas no estado no Paraná, bem como as
operações iniciadas em outros estados não devem ter o valor do ICMS destacado.
5.4.2. Requisitos
Dadas as restrições impostas pelas regras de negócio, pode-se especificar os
requisitos do sistema. Requisitos são descrições do que o sistema deve fazer e dos
serviços que deve fornecer. Em suma, requisitos são “funcionalidades, capacidades
e restrições do sistema, que refletem as necessidades do cliente” (SOMMERVILLE,
2011). Os quadros entre o Quadro 4 e o Quadro 12 contêm as especificações dos
requisitos de sistema deste projeto.
Quadro 4 - RQFN1 - Cadastrar clientes
Função: Cadastrar clientes
Descrição: o sistema deve persistir o cadastro de clientes
Entradas CNPJ, CPF, IE, RG, Razão Social, Nome Fantasia, CEP, UF, Município,
Bairro, Endereço, Telefone
Saídas • Cadastro efetuado com sucesso!
• Formulário incompleto!
• Já existe um cliente cadastrado com esse CNPJ / CPF!
Pré-condições • Nenhum outro cliente pode ter sido cadastrado com o mesmo
CNPJ ou CPF.
Pós-condições • Nenhum outro cliente poderá ser cadastrado com o CNPJ ou CPF
do cliente recém-cadastrado.
• O cliente recém-cadastrado pode ser referenciado por outras
funcionalidades.
Destino Tabela Clientes
Ação
1. O usuário insere os dados do cliente e submete o formulário para
cadastro.
2. O sistema valida os campos obrigatórios e a unicidade do
CNPJ/CPF.
3. Se o cadastro for válido, o sistema persiste os dados.
Fonte: autoria própria
52
Quadro 5 - RQFN2 - Alterar cadastro de clientes
Função: Alterar de cadastro de clientes
Descrição: o sistema deve permitir alterações em cadastros de clientes.
Entradas CNPJ, CPF, IE, RG, Razão Social, Nome Fantasia, CEP, UF, Município,
Bairro, Endereço, Telefone
Saídas • Cadastro alterado com sucesso!
• Formulário incompleto!
• Já existe um cliente cadastrado com esse CNPJ / CPF!
Pré-condições Caso o CNPJ ou CPF sejam alterados, nenhum outro cliente pode ter sido
cadastrado com o mesmo CNPJ ou CPF.
Pós-condições Nenhum outro cliente poderá ser cadastrado com o CNPJ ou CPF do
cliente recém-alterado.
Destino Tabela Clientes
Ação 1. O usuário busca um cliente.
2. O sistema preenche o formulário com seus dados.
3. O usuário altera os dados e submete o formulário.
4. O sistema valida a alteração e persiste os dados.
Fonte: autoria própria
Quadro 6 - RQFN3 - Pesquisar clientes
Função: Pesquisar clientes
Descrição: o sistema deve permitir a pesquisa de clientes
Entradas CNPJ/ CPF, IE/RG, Razão Social ou Nome Fantasia
Saídas • Um cliente encontrado
• Mais de um cliente encontrado
• Nenhum cliente encontrado
Pré-condições Nenhuma
Pós-condições Nenhuma
Destino Tabela Clientes
Ação 1. O usuário define o parâmetro de busca (CNPJ/CPF/IE/RG/Razão
Social/Fantasia)
2. O usuário insere o argumento da busca e submete os dados.
3. Se o sistema encontrar um único resultado, o formulário é
preenchido com os dados do mesmo.
4. Se o sistema encontrar mais de um resultado, o usuário deve
selecionar um dos clientes e o sistema preenche o formulário com
os dados do mesmo.
5. Se o sistema não encontrar nenhum resultado, um alerta é exibido.
Fonte: autoria própria
53
Quadro 7 - RQFN4 - Cadastrar conhecimentos de transporte
Função: Cadastrar conhecimentos de transporte
Descrição: o sistema deve persistir o cadastro de conhecimentos de transporte
Entradas Remetente, Destinatário, Redespacho (se houver), Origem, Destino,
Responsável pelo pagamento do frete, Número da Nota Fiscal, Peso,
Volumes, Valor, Valor do Frete
Saídas • CT-e cadastrado com sucesso!
• Formulário incompleto!
• A nota fiscal deste cliente já foi cadastrada em outro CT-e!
Pré-condições Nenhuma outra Nota Fiscal do mesmo Remetente pode ter sido cadastrada
em outro CT-e
Pós-condições Nenhum outro CT-e pode ser cadastrado com a Nota Fiscal recém
cadastrada.
Destino Tabela CT-e e Tabela Nota Fiscal
Ação
1. O usuário insere os dados do CT-e e submete o formulário para
cadastro.
2. O sistema calcula o valor do frete.
3. O sistema valida os campos obrigatórios e a unicidade da Nota
Fiscal.
4. Se o cadastro for válido, o sistema persiste os dados.
Fonte: autoria própria
Quadro 8 - RQFN5 - Excluir conhecimentos de transporte
Função: Excluir conhecimentos de transporte
Descrição: o sistema deve permitir a exclusão de conhecimentos de transporte
Entradas CT-e a excluir
Saídas • CT-e excluído com sucesso!
• Não é possível excluir tal CT-e, pois o mesmo já foi emitido!
Pré-condições CT-e não pode ter sido emitido. Nesse caso, só é possível cancela-lo.
Pós-condições O registro do CT-e é removido permanentemente do sistema.
Destino Tabela CT-e e Tabela Nota Fiscal
Ação 1. O usuário informa o CT-e a excluir.
2. O usuário solicita a exclusão do CT-e.
3. O sistema valida a exclusão e remove o registro.
Fonte: autoria própria
54
Quadro 9 - RQFN6 - Cancelar conhecimentos de transporte
Função: Cancelar conhecimentos de transporte
Descrição: o sistema deve permitir o cancelamento de conhecimentos de transporte
Entradas CT-e a cancelar
Saídas • CT-e cancelado com sucesso!
• Não é possível excluir tal CT-e, pois o mesmo já foi baixado!
Pré-condições CT-e não pode ter sido baixado.
Pós-condições O CT-e cancelado não pode ser baixado.
Destino Tabela CT-e
Ação 1. O usuário informa o CT-e a cancelar.
2. O usuário solicita o cancelamento do CT-e.
3. O sistema valida e cancela o CT-e.
Fonte: autoria própria
Quadro 10 - RQFN7 - Baixar conhecimentos de transporte
Função: baixar conhecimentos de transporte
Descrição: o sistema deve permitir a baixa de conhecimentos de transporte
Entradas CT-e a baixar
Saídas • CT-e baixado com sucesso!
• Não é possível baixar tal CT-e, pois o mesmo já foi cancelado!
• Não é possível baixar tal CT-e, pois o mesmo ainda não foi emitido!
Pré-condições CT-e não pode ter sido cancelado.
CT-e deve ter sido emitido.
Pós-condições O CT-e baixado não pode ser cancelado.
Destino Tabela CT-e
Ação 1. O usuário informa o CT-e a baixar.
2. O usuário solicita a baixa do CT-e.
3. O sistema valida e baixa o CT-e.
Fonte: autoria própria
55
Quadro 11 - RQFN8 - Emitir conhecimentos de transporte
Função: Emitir conhecimentos de transporte
Descrição: o sistema deve permitir a emissão de conhecimentos de transporte
Entradas CT-e a emitir e número do CT-e
Saídas • CT-e emitido com sucesso!
Pré-condições Nenhuma
Pós-condições CT-e pode ser baixado ou cancelado.
Destino Tabela CT-e e Tabela Nota Fiscal
Ação 1. O usuário informa o CT-e a emitir e seu número.
2. O sistema emite o CT-e.
Fonte: autoria própria
Quadro 12 - RQFN9 - Pesquisar conhecimentos de transporte
Função: Pesquisar conhecimentos de transporte
Descrição: o sistema deve permitir a pesquisa de conhecimentos de transporte
Entradas Número do CT-e ou da Nota Fiscal
Saídas • Nenhum CT-e encontrado!
• Um CT-e encontrado.
• Mais de um CT-e encontrado.
Pré-condições Nenhuma
Pós-condições Nenhuma
Destino Tabela CT-e e Tabela Nota Fiscal
Ação 1. O usuário informa o parâmetro de busca e o argumento.
2. O usuário submete o formulário.
3. Se houver apenas um resultado, o sistema preenche o formulário
com os dados do mesmo.
4. Se houver mais de um resultado, o usuário deve selecionar qual
CT-e deseja visualizar.
5. Se não houver nenhum resultado, o sistema emite um alerta.
Fonte: autoria própria
56
5.5. Modelo de dados
Assim que os requisitos tiverem sido levantados, deve-se criar um modelo de
dados de alto nível (ELMASRI e NAVATHE, 2005). O modelo de dados representa
as entidades do domínio do problema, seus atributos e relacionamentos. Esse
modelo é composto por três visões: a conceitual, a lógica e a comportamental. A
primeira representa as entidades do domínio do problema e seus relacionamentos; a
segunda, a realização desse modelo sob a perspectiva do banco de dados; e a
última, os ciclos de vida dos objetos complexos.
5.5.1. Modelo conceitual
As metodologias de modelagem de objeto, como a Unified Modelling
Language (UML), têm se tornado cada vez mais populares em projetos de software
e banco de dados. Isso decorre da semelhança entre os diagramas de classes e
entidade-relacionamento, o que facilita a tradução entre ambos (ELMASRI e
NAVATHE, 2005). “Classes são abstrações dos itens que fazem parte do
vocabulário do problema” (BOOCH, RUMBAUGH e JACOBSON, 2012). A Figura 17
apresenta o modelo de dados conceitual deste projeto.
57
Figura 17 - Projeto conceitual de dados
Fonte: autoria própria
5.5.2. Modelo lógico
Realizado o modelo conceitual de dados, a próxima etapa no projeto de
banco de dados consiste na própria implementação do banco de dados (ELMASRI e
NAVATHE, 2005). A Figura 18 apresenta o modelo lógico de dados deste projeto. A
principal diferença entre o modelo lógico e o conceitual está na definição da
integridade referencial entre as entidades, por meio das chaves estrangeiras de
cada tabela do banco de dados.
58
Figura 18 - Projeto lógico de dados
Fonte: autoria própria
5.5.3. Modelo Comportamental
O modelo comportamental define os estados que as entidades complexas do
modelo de dados podem assumir, bem como as transições que podem realizar. Para
tal representação, são utilizados diagramas de transição de estados. Esses
diagramas descrevem o ciclo de vida e o comportamento de uma entidade individual
(BOOCH, RUMBAUGH e JACOBSON, 2012). Das entidades do domínio do
problema apresentadas no diagrama da Figura 17, apenas estas possuem ciclos de
vida complexos: Coleta, CT-e, Manifesto, Relação de Entrega e Fatura.
59
O diagrama da Figura 19 representa o ciclo de vida de uma coleta. Quando
solicitada por um cliente, uma coleta é cadastrada no sistema. Feito isso, o operador
decide qual veículo/motorista da empresa a realizará, delegando tal coleta ao
veículo/motorista escolhido. Por fim, efetuada a coleta, essa passa ao estado final
“Realizada”. Uma coleta também pode ser cancelada pelo cliente, porém não pode
ser excluída do sistema.
Figura 19 - Diagrama de transição de estados – Coleta
Fonte: autoria própria
A Figura 20 representa o ciclo de vida de um conhecimento de transporte.
Quando uma coleta chega em uma filial do transportador, um operador cadastra a
nota fiscal do cliente no sistema e calcula o valor do frete. Em seguida, o CT-e é
emitido, recebendo um número identificador da SEFAZ. Uma vez emitido, somente é
possível cancelá-lo ou baixá-lo, não sendo possível alterá-lo ou excluí-lo. A baixa
ocorre quando é realizada a entrega da mercadoria.
60
Figura 20 - Diagrama de transição de estados - CT-e
Fonte: autoria própria
O ciclo de vida de um manifesto de viagem é representado pela Figura 21. A
emissão de um manifesto sinaliza o início do transporte entre as filiais da empresa.
A baixa de um manifesto representa a chegada do veículo transportador na filial de
destino.
Figura 21 - Diagrama de transição de estados – Manifesto de viagem
Fonte: autoria própria
61
O diagrama da Figura 22 se refere ao ciclo de vida de uma relação de
entregas. A emissão de uma relação de entregas sinaliza que o veículo de
distribuição deixou a filial de destino em direção ao destinatário final. A baixa de uma
relação de entregas representa que todas as mercadorias a que a relação se refere
foram entregues. Por conseguinte, todo conhecimento de transporte associado a
uma relação de entregas é automaticamente baixado quando ocorre sua baixa.
Figura 22 - Diagrama de transição de estados - Relação de entregas
Fonte: autoria própria
A Figura 23 representa o ciclo de vida de uma fatura. A emissão de uma
fatura vincula um boleto bancário a uma relação de conhecimentos de transporte. A
baixa de uma fatura sinaliza o pagamento realizado pelo cliente.
62
Figura 23 - Diagrama de transição de estados – Fatura
Fonte: autoria própria
63
5.6. Interface do sistema com o usuário
Dado que este projeto tinha como restrição principal o baixo custo de
implantação e que a necessidade do treinamento de usuários incorre em custos,
buscou-se elaborar as interfaces do sistema com o usuário de modo a incrementar a
facilidade de uso. Nesse sentido, o projeto de interação com a ferramenta deve ter
como objetivos: a diminuição da necessidade que os usuários apresentam em
aprender novas interfaces e processos; a acomodação das capacidades da
ferramenta às demandas das tarefas; e a remoção dos aspectos dos menus e telas
desnecessários a determinados tipos de usuários (OZEN, BASOGLU e DAIM, 2008).
As figuras 24, 25 e 26 apresentam exemplos da interface do sistema com o usuário.
Ainda no sentido de diminuir a necessidade de treinamento, cartilhas podem ser
utilizadas como manuais rápidos do passo-a-passo para relembrar novos processos
(MARKHAM e WEBB, 2012). Esses procedimentos passo-a-passo constam no
Apêndice B – Manual de uso.
Figura 24 - Cadastro de clientes
Fonte: autoria própria
64
Figura 25 - Cadastro de CTe
Fonte: autoria própria
Figura 26 - Cadastro de CTe: cálculo do valor do frete
Fonte: autoria própria
65
5.7. Resultados da implantação do sistema
A relevância da implantação de um sistema computacional para a gestão de
negócios decorre da introdução da perspectiva de processos, em razão da
possibilidade de controlá-los e mensurá-los, viabilizando sua melhoria contínua
(SILVA e PEREIRA, 2006). Tal melhoria pode ser alcançada por meio da proposta
de uma nova metodologia para a execução dos procedimentos de negócio ou por
meio do redesenho dos processos existentes (PADILHA e MARINS, 2005). Embora
o uso de sistemas ERP permita o redesenho dos processos de negócio, isso exige
um grande esforço de comprometimento da organização, principalmente por parte
da alta gerência (MENDES e ESCRIVÃO FILHO, 2007). Ademais, o redesenho dos
processos pode causar um grande impacto organizacional.
Acerca da preocupação com a diminuição desse impacto, diversas estratégias
podem ser adotadas na implantação de sistemas ERP. A implantação pode ser:
total, por meio da substituição de todos os sistemas legados por um novo; por meio
de franquias, quando as filiais operam processos diversos; ou por meio do método
slam-dunk, no qual se define o planejamento de implantação incremental dos
processos-chave, método muito utilizado por empresas que projetam um
crescimento através do ERP (PADILHA e MARINS, 2005). Uma das estratégias
alternativas consiste na implantação do ERP com o mínimo de customizações
possível, de modo a utilizar toda a potencialidade do sistema antes de incrementá-
las (HOLLAND e LIGHT, 1999). Por essa razão, os ERP são divididos em módulos,
de modo a permitir que as empresas implantem somente aqueles que lhes são
necessários. Havendo a necessidade de ampliar o sistema, a modularização é um
fator de facilitação (MENDES e ESCRIVÃO FILHO, 2007). Evidências demonstram
que a maior parte das organizações não implanta os módulos de seu ERP de uma
única vez (BIANCOLINO e RICCIO, 2011). Por esse motivo, optou-se pela
implantação incremental de módulos do sistema na empresa onde a pesquisa-ação
deste projeto foi realizada.
Em relação à estratégia de melhoria dos processos, este trabalho propôs
somente o redesenho de processos existentes. Ainda que a percepção correta dos
resultados seja possível somente em longo prazo, pode-se perceber que a
66
implantação deste projeto surtiu efeitos imediatos sobre a questão da agilidade e
confiabilidade no acesso à informação.
67
6. Considerações finais
Os sistemas de gestão integrada têm alto custo devido à necessidade de
customização em função do segmento de negócio, pois esse tipo de sistema ainda
guarda muitas características remanescentes de sua origem nos setores industriais
de produção. O alto investimento inibe o acesso das MPEs a esses sistemas. No
Brasil, um dos setores cuja participação mais significativa é de micro e pequenas
empresas é o setor de transporte rodoviário de cargas. Uma alternativa encontrada
por empresas desse segmento foi a utilização de sistemas especializados. Contudo,
muitos desses sistemas apresentam visão departamentalizada em detrimento da
visão de processos, não sendo caracterizados como sistemas ERP efetivos e, por
conseguinte proporcionando benefícios menores.
Este trabalho teve como objetivo o desenvolvimento de um sistema ERP
voltado a empresas de transporte rodoviário de cargas. Em razão das restrições de
prazo e do escopo estritamente acadêmico, propôs-se apenas a realização de um
protótipo, com o intuito de demonstrar a possibilidade de desenvolver tal projeto
dentro das limitações de custo. Conforme discutido, a obtenção da percepção de
valor da implantação deste ERP somente será possível em longo prazo, contudo
pode-se considerar que a agilidade e confiabilidade no acesso à informação
proporcionada pelo sistema demonstraram-se satisfatórias. Em face dos resultados
obtidos e a da demonstração da viabilidade econômica deste projeto, pode-se
considerar que os objetivos foram realizados. Cabe ressaltar que a realização
desses objetivos está restrita somente ao propósito do protótipo como um sistema
de gestão dos processos operacionais e não como um ERP completo.
Ademais, cabe salientar que este trabalho limitou-se ao estudo exclusivo dos
problemas inerentes ao modal de transporte nacional rodoviário de cargas secas e
dos sistemas de gestão integrada como ferramentas de apoio aos processos
administrativos, sem considerar as particularidades de outros modais ou as
possibilidades de desenvolver um sistema de apoio à decisão, um sistema integrado
com outros softwares, etc. Portanto, como possíveis refinamentos deste trabalho,
pode-se apontar:
68
• o estudo de outros modais de transporte;
• o estudo do transporte multimodal;
• o estudo dos aspectos do transporte rodoviário internacional;
• o desenvolvimento e integração de um sistema contábil;
• a comunicação com o sistema da SEFAZ para a emissão de CT-e;
• a interoperabilidade com os sistemas bancário, de seguradoras, de
rastreamento de veículos, entre outros; e
• a portabilidade de funcionalidades do sistema para smartphones e outras
plataformas móveis.
Ainda sobre os possíveis trabalhos futuros, pode-se citar: a elaboração de um
Data Warehouse com previsão de demanda e planejamento de capacidade,
utilizando técnicas de inteligência artificial e técnicas de projeção estatística.
Ademais, considera-se essencial no âmbito do planejamento operacional o
desenvolvimento de um sistema para otimizar a itinerarização e a alocação dinâmica
de coletas e entregas em janelas de tempo determinadas.
69
Bibliografia
BIANCOLINO, C.; RICCIO, E. Inovação, gerenciamento por competências e o valor
de uso dos sistemas ERP em sua fase de pós-implementação. Revista de Administração e Inovação, São Paulo, v. 8, n. 2, p. 164-189, abr/jun 2011.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML - Guia do Usuário. Rio de
Janeiro: Elsevier, 2012.
BRASIL. Lei nº 5.172, de 25 de Outubro de 1966. Sistema Tributário Nacional, 1966. Disponível em:
<http://www.receita.fazenda.gov.br/Legislacao/CodTributNaci/ctn.htm>. Acesso em:
28 Março 2013.
BRASIL. Ajuste SINIEF Nº 09, 25 de Outubro de 2007. Institui o Conhecimento de Transporte Eletrônico e o Documento Auxiliar do Conhecimento de Transporte Eletrônico., 2007. Disponível em:
<http://www.fazenda.gov.br/confaz/confaz/ajustes/2007/AJ_009_07.htm>. Acesso
em: 28 Março 2013.
BRODBECK, Â. Sistemas ERP no Brasil: teoria e casos. RAE-Eletrônica, São
Paulo, v. 3, n. 1, p. 2-3, jan/jun 2004.
CAMPOS, R. D.; CARVALHO, R. D. Uma análise de aspectos relacionados ao
desenvolvimento e adoção de Enterprise Resouces Planning livre de código aberto.
Gest. Prod., São Carlos, v. 16, n. 4, p. 667-678, out-dez 2009.
CONTADOR, J.; NANINI, H. Os sistemas enterprise resources planning - ERP
tornam as empresas mais competitivas? Revista de Administração e Inovação,
São Paulo, v. 1, n. 2, p. 20-30, 2004.
DANEVA, M. ERP Requirements engineering practice: lessons learned. IEEE Software, v. 4, p. 26-33, Mar/Abr 2004.
ELMASRI, R.; NAVATHE, S. R. Sistemas de Banco de Dados. 4. ed. São Paulo:
Pearson, 2005.
70
HABERKORN, E. Gestão Empresarial com ERP. São Paulo: Saraiva, 2003.
HOLLAND, C.; LIGHT, B. A critical success factors model for ERP implementation.
IEEE Software, v. 1, p. 30-36, Mai/Jun 1999.
KRUCHTEN, P. The rational unified process: an introduction. 3. ed. [S.l.]: Addison-
Wesley, 2003.
LOPES, S.; CARDOSO, M.; PICCININI, M. O transporte rodoviário de carga e o
papel do BNDES. Revista do BNDES, Rio de Janeiro, v. 14, p. 35-60, 2008.
MARKHAM, S.; WEBB, J. User adoption of enterprise resources planning systems.
Oxford Journals - ITNOW, p. 40, March 2012.
MENDES, J.; ESCRIVÃO FILHO, E. Atualização tecnológica em pequenas e médias
empresas: proposta de roteiro para aquisição de sistemas integrados de gestão
(ERP). Gest. Prod., São Carlos, v. 14, n. 2, p. 281-293, maio-ago 2007.
MENEZES, P.; GUEVARA, F. Maximizacion de los beneficios de los sistemas ERP.
Revista de Gestão da Tecnologia e Sistemas de Informação, São Paulo, v. 7, n.
1, p. 5-32, 2010.
NASCIMENTO, S. et al. Proposição de uma metodologia baseada no balanced
scoreboard para suporte à gestão estratégica de uma transportadora de carga
fracionada. Revista Gestão Organizacional, v. 1, n. 2, p. 90-101, jul/dez 2008.
OZEN, C.; BASOGLU, N.; DAIM, T. Impact of man-machine interaction factors on
enterprise resource planning (ERP). Rev. Adm. UFSM, Santa Maria, v. 1, n. 1, p. 26-
26, jan/abr 2008.
PADILHA, T. Tempo de implantação de sistemas ERP: Análise da influência de
fatores e aplicação de técnicas de gerenciamento de projetos. Gestão e Produção,
São Paulo, v. 11, n. 1, p. 65-74, jan-abr 2004.
PADILHA, T.; MARINS, F. Sistemas ERP: características, custos e tendências.
Revista Produção, São Paulo, v. 15, n. 1, p. 102-113, Jan/Abr 2005.
71
PARANÁ. Decreto Nº 6.080 de 28.09.2008. Regulamento do imposto sobre circulação de mercadorias e prestação de serviços no estado do Paraná, 2008.
Disponível em:
<http://www.sefanet.pr.gov.br/dados/SEFADOCUMENTOS/106201206080.pdf>.
Acesso em: 2013 Março 28.
PELEIAS; Trevizoli, José C.; CORTES, Pedro L.; GALEGALE, Napoleão V..
Pesquisa sobre a percepção dos usuários dos módulos contábil e fiscal de um
sistema ERP para o setor de transporte rodoviário de cargas e passageiros. Revista de Gestão da Tecnologia e Sistemas de Informação, São Paulo, v. 6, n. 2, p. 247-
270, 2009. ISSN 1807-1775.
PMI. PMBOK® Guide. 4. ed. [S.l.]: [s.n.], 2008.
SANTOS, A.; LIMA, J.; CARVALHO, E. Benefits of ERP systems implementation in business in Brazil: case studies. Information Systems and Technologies (CISTI).
Santiago de Compostela: [s.n.]. 2010. p. 1-6.
SERRANO, N.; SARRIEGI, J. Open source software ERPs: a new alternativa for an
old need. IEEE Computer Society, v. 6, n. 1, p. 94-97, Mai/Jun 2006.
SILVA, F.; PEREIRA, N. Modelagem de processos de negócio na implementação de
ERPs nacionais em PMEs. Revista Produção, São Paulo, v. 16, n. 2, p. 341-352,
Maio/Ago 2006.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson, 2011.
WANKE, P.; FLEURY, P. Transporte de cargas no Brasil: estudo exploratório das
principais variáveis relacionadas aos diferentes modais e às suas estruturas de
custo. IPEA. Rio de Janeiro, p. 409-464. 2006.
72
Glossário
Carga completa / Veículo dedicado
Único processo de coleta e entrega, ou seja, envolve apenas um remetente e um
destinatário. Ocorre quando a mercadoria preenche completa ou quase
completamente a capacidade do veículo de transporte, ou a mercadoria tem como
destino uma região onde o transportador não possui uma filial.
Carga fracionada
Carga composta por mercadorias diversas, de remetentes variados para
destinatários distintos. Os veículos de coleta abastecem o veículo de viagem com as
mercadorias coletadas ao longo do dia em um processo chamado cross-docking.
Além disso, mercadorias remanescentes de coletas anteriores também consolidam a
carga fracionada, que é transportada entre as filiais e dividida entre os veículos de
distribuição na filial de destino.
Carga seca
Produtos manufaturados, embalados ou ensacados, que não exigem o transporte
por meio de um veículo específico, como frigoríficos, betoneiras, cegonhas ou pipa.
Coleta
Procedimento realizado por um veículo de pequeno porte, chamado de veículo de
coleta. Consiste na obtenção –por parte do operador logístico - de uma mercadoria
para realizar seu transporte.
CT-e
Conhecimento de transporte eletrônico. Versão virtual da obrigação tributária
acessória, ou seja, equivalente eletrônico da negativa de prestação de serviço.
CTRC
Conhecimento de transporte rodoviário de carga. Obrigação tributária acessória.
73
Cubagem
Proporção volume/peso utilizada para calcular o valor do frete quando a mercadoria
possui um volume muito grande e pouco peso.
Entrega
Última etapa do processo operacional. Consiste em conduzir uma mercadoria até
seu destinatário final.
Fatura
Relatório de serviços prestados a determinado cliente, utilizado para realizar a
cobrança dos mesmos. Cada fatura é associada a um boleto bancário.
Frete mínimo
Valor mínimo cobrado pelo serviço prestado pelo transportador, quando o peso,
volume ou valor da mercadoria não atinge um limite mínimo.
Frete peso
Percentual cobrado sobre o peso da mercadoria.
Frete valor
Percentual cobrado sobre o valor da mercadoria
GRIS
Taxa de gerenciamento de risco, proporcional ao valor da mercadoria e ao risco do
transporte da mesma.
Manifesto de viagem
Relatório de mercadorias transportadas em determinado veículo. Não é um
documento fiscal.
Posição de entrega
Informação solicitada pelos clientes da transportadora acerca dos processos
operacionais.
74
Redespacho
Quando o transportador não oferece o serviço de entrega em determinada região,
ele o faz por meio de parcerias com outras empresas, cuja área de serviço
contempla tal região. Esses parceiros são chamados de redespachos.
Relação de entregas
Relatório de entregas por veículo de distribuição. Cada relação de entregas é
constituída em função da região das entregas, a fim de otimizar o uso dos veículos.
O processo de dividir e sequenciar essas entregas é chamado de itinerarização.
Tabela de fretes
Espécie de contrato entre o transportador e seu cliente. Estabelece o valor cobrado
pelo serviço prestado.
Veículo de coleta e distribuição
Veículo de pequeno porte, com capacidade média de 4 toneladas e 25 metros
cúbicos. Esses veículos atuam dentro dos municípios onde o transportador possui
filiais.
Veículo de viagem
Veículos de grande porte, com capacidade média de 12 toneladas e 70 metros
cúbicos. Esses veículos atuam no transporte interestadual.
75
Apêndice A – Manual de instalação
Requisitos:
• JAVA 7.0.150
Este manual de instalação descreve os procedimentos necessários para
instalar o sistema a que este trabalho se refere. Para utilizar esse sistema, siga os
seguintes passos:
1. crie um diretório conforme a estrutura ilustrada na Figura 27;
2. descompacte o arquivo “log.rar” dentro do diretório “log”;
3. crie uma nova base de dados PostgreSQL;
4. execute os scripts do arquivo “log/ddl.txt” em sua nova base de dados; e
5. abra o arquivo “log/src/resources/bd.properties” e aponte as configurações
para o seu servidor de banco de dados, conforme a Figura 28;
Figura 27 - Manual de instalação: estrutura de diretórios
Fonte: autoria própria
76
Figura 28 - Manual de instalação: configuração do banco de dados
Fonte: autoria própria
77
Apêndice B – Manual de uso
Este manual de uso descreve como utilizar o sistema de gestão integrada a
que este trabalho se refere. A Figura 29 apresenta a interface gráfica do menu
principal. Para acessar os menus Comercial e Operacional, basta clicar sobre esses
botões na barra superior da tela.
Figura 29 - Interface gráfica do menu principal
Fonte: autoria própria
Para acessar o formulário de clientes, basta selecionar o botão Cliente,
conforme ilustra a Figura 30.
Figura 30 - Interface gráfica do menu Comercial
Fonte: autoria própria
78
Para cadastrar um novo cliente, basta preencher o formulário da Figura 31 e
selecionar o botão Salvar. As máscaras abaixo são obrigatórias para o cadastro de
clientes:
• CNPJ / CPF 000.000.000-00 ou 00.000.000/0000-00
• CEP 00000-000
• Telefone (00) 0000-0000 ou (00) 00000-0000
Figura 31 - Interface gráfica do formulário de clientes
Fonte: autoria própria
Para pesquisar clientes cadastrados, basta selecionar o parâmetro de busca
(CNPJ/CPF , IE/RG, Razão Social ou Nome Fantasia), fornecer o argumento de
busca e selecionar o botão Pesquisar.
Para alterar o cadastro de um cliente, basta pesquisa-lo, alterar os dados no
formulário e selecionar o botão Salvar.
79
Figura 32 - Interface gráfica do menu Operacional
Fonte: autoria própria
Para acessar o formulário de Conhecimento de Transporte, basta selecionar o
menu Operacional e o botão CTe, conforme a Figura 32.
Figura 33 - Interface gráfica do formulário de CTe(1)
Fonte: autoria própria
80
Para cadastrar um novo CTe, deve-se indicar no formulário da Figura 33:
• o responsável pelo pagamento do frete;
• a filial de origem da operação;
• a filial de destino;
• o código da operação:
o 6932 para operações iniciadas fora do Paraná;
o 5352 para operações internas no Paraná, cujo remetente seja um
tomador comercial;
o 5353 para operações internas no Paraná, cujo remetente seja um
tomador industrial;
o 6352 para operações interestaduais iniciadas no Paraná, cujo
remetente seja um tomador comercial;
o 6353 para operações interestaduais iniciadas no Paraná, cujo
remetente seja um tomador indústria;
• a natureza do produto;
• a espécie do produto;
• o remetente e o destinatário; e
• o redespacho, se houver.
Feito isso, deve-se cadastrar as notas fiscais referentes ao novo CTe, informando o
peso, quantidade de volumes, valor e o número de cada nota fiscal. Em seguida,
basta selecionar a tabela utilizada para o cálculo do frete e selecionar o botão
Salvar. Antes de cadastrar o novo CTe, o sistema exibirá os valores da composição
do cálculo do frete e dos tributos (vide Figura 34).
81
Figura 34 - Interface gráfica do formulário de CTe(2)
Fonte: autoria própria
Para pesquisar um CTe cadastrado, deve-se selecionar o parâmetro de busca
(número do CTe ou Nota Fiscal), indicar o argumento da busca e selecionar o botão
Pesquisar.
Para excluir um CTe, deve-se pesquisa-lo e selecionar o botão Excluir.
Somente é possível excluir um CTe que ainda não foi emitido.
Para cancelar um CTe, deve-se pesquisa-lo e selecionar o botão Cancelar.
Somente é possível cancelar um CTe que já foi emitido, mas ainda não foi baixado.
Vale destacar que, para pesquisar um CTe que ainda não foi emitido, deve-se
informar o número de uma das notas fiscais a que esse CTe se refere.
82
Figura 35 - Interface gráfica do formulário de emissão de CTe
Fonte: autoria própria
Uma vez cadastrado um CTe, o mesmo constará na tabela do formulário de
emissão de CTe, conforme a Figura 35. Para emitir um CTe, deve-se seleciona-lo
nessa tabela, informar seu número e clicar no botão Emitir.
Figura 36 - Interface gráfica do formulário de baixa de entregas
Fonte: autoria própria
Uma vez emitido um CTe, o mesmo constará na tabela do formulário de baixa
de entregas, conforme a Figura 36. Para baixar uma entrega realizada, para
selecionar o CTe desejado e clicar no botão Baixar.
