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
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.
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 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
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
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
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.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
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).
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
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
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.
No Capítulo 6 – Considerações finais – é discutida a realização dos objetivos deste trabalho, suas limitações e trabalhos futuros.
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
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.
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
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).
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
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
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.
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).
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.
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.
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.
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
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
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.
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.
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
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:
• 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
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.
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 Diretoria Comercial
Gerência Logís8ca Recursos humanos Atendimento ao consumidor Estratégico Tático Operacional
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.
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.
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
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
. 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.
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.
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.
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.
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
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
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
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
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.
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
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.
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.
