GESTÃO DE MICRO E PEQUENAS EMPRESAS (63)

Prévia do material em texto

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 é compostapor 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 
Acompetitividade 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áriode 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 NenhumaPó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