Sistema de EDI Intraorganizacional
Caso de estudo Sousacamp SGPS
Dissertação de Mestrado em Engenharia Informática
Daniel Alves Martins
Sob orientação do Professor Doutor Ramiro Gonçalves e do Professor Doutor Frederico Branco
ii
iii
Dissertação apresentada por Daniel Alves Martins à Universidade de Trás-os-Montes e Alto Douro para cumprimento dos requisitos necessários à obtenção do grau de Mestre em Engenharia Informática, sob a orientação do Prof. Doutor Ramiro Manuel Ramos Moreira Gonçalves,
Professor Auxiliar com Agregação do
Departamento de Engenharias da Universidade de Trás-os-Montes e Alto Douro e do Prof. Frederico Augusto dos Santos Branco, Assistente Convidado do Departamento de Engenharias da Universidade de Trás-os-Montes e Alto Douro.
iv
À minha Família que sempre me apoiou!
v
Ag
Agradecimentos
Agradeço à Sousacamp e a todos os seus colaboradores por me darem todas as condições necessárias à realização do trabalho.
O meu muito obrigado aos Orientadores, por me guiarem na direção certa. À minha namorada, Tânia, que tantas vezes me corrigiu, o meu muito obrigado! A toda a minha Família, pois sem eles não seria possível.
vi
Re
Resumo
As Organizações estão cada vez mais preocupadas com a otimização dos seus processos para, a partir daí, obter vantagens competitivas no mercado. Por detrás de qualquer negócio, empresa ou instituição existe um constante fluxo de criação e manipulação de documentos e respetivo tratamento. Em muitos casos um autêntico caos burocrático. Estes processos envolvem um grande esforço a nível de recursos humanos e a suscetibilidade a erros é elevada. A Sousacamp é um grupo da área agroalimentar que tem, na sua constituição, diversas empresas distribuídas pela Península Ibérica. As empresas do grupo fazem compras e vendas entre si aumentando a carga de papel com todas as transações efetuadas dentro do grupo.
Assim sendo, a Sousacamp necessita de uma solução de “EDI” que possa satisfazer as necessidades internas entre as empresas do grupo, mas respeitando as diferenças existentes entre elas.
Com este projeto será possível alcançar uma otimização de todo o processo de negócio do grupo, mais concretamente, no tempo gasto, nos erros, na capacidade de resposta, na segurança e nos custos envolvidos.
Todo o desenvolvimento é feito internamente com a integração dos serviços já existentes no grupo, respetivamente, a Intranet e o ERP. A solução proposta foi desenvolvida utilizando a tecnologia ASP, .NET, e linguagem C#.
vii
Ab
Abstract
Organizations are increasingly concerned with the optimization of its processes so that, from there, they gain competitive advantage in the market. In the inside any business, company or institution there is a constant flow of creation and manipulation of documents and respective treatment. In many cases a real bureaucratic chaos. These processes involve a great effort in terms of human resources and susceptibility to errors is high.
Sousacamp is a group of companies specialized in agrifood area that are distributed throughout the Iberian Peninsula. The group companies are buying and selling from each other increasing this way the load of paper with all transactions within the group.
Therefore, Sousacamp needs an internal "EDI" solution which can meet the domestic needs of the group companies, but respecting the differences between them.
With this project it will be possible to achieve an optimization of the entire business process, more precisely, the time spent, accuracy, capacity in responsiveness, security and involved costs.
The whole development is done internally with the integration of already existing services in the group, respectively, Intranet and ERP. The proposed solution was developed using ASP,. NET and C # language.
viii
PC
Palavras-chave
Troca de dados eletrónicos (EDI);
Integração; Colaboração; Sistemas Intraorganizacionais; Problemas organizacionais; Gestão tecnológica; Implementação; Desenvolvimento; Estudo de caso;
Sistema de Planeamento de Recursos (ERP);
ix
KW
Keywords
Electronic Data Interchange (EDI);
Integration; Collaboration; Intra-organizational systems; Organizational issues; Technology management; Implementation; Development; Case-study;
Enterprise Resource Planning (ERP);
x
“A experiência não é o que acontece a um homem. É o que um homem faz com o que lhe acontece.”
Thomas Jefferson (1743-1826)
xi
ÍG
Índice Geral
Agradecimentos ... v Resumo ... vi Abstract ... vii Palavras-chave ... viii Keywords ... ix Índice Geral ... xi Índice de Tabelas ... xvÍndice de Figuras ... xvii
Acrónimos ... xix
1. Introdução ... 1
1.1. Motivações, objetivos e contributos ... 1
1.2. Organização do trabalho ... 2
2. Electronic Data Interchange ... 5
2.1. Conceitos ... 6 2.2. Evolução ... 7 2.3. Propósito ... 9 2.4. Como funciona? ... 11 2.5. Standards (Padrões) ... 14 2.5.1. EDIFACT ... 14 2.5.2. X12 ... 15 2.5.3. XML ... 15 2.6. Especificação ... 15 2.7. Tradutor ... 17 2.8. Fontes de transmissão ... 18
xii 2.10. Constrangimentos na implementação ... 22 2.10.1. Custo ... 22 2.10.2. Padrões inadaptados ... 22 2.10.3. Redundância ... 22 2.11. Vantagens ... 22 2.11.1. Velocidade ... 23 2.11.2. Precisão ... 23 2.11.3. Rentabilidade... 24 2.11.4. Segurança ... 24 2.12. Limitações ... 24 2.12.1. Segurança ... 24 2.12.2. Capital investido ... 25 2.13. Síntese ... 25 3. Tecnologias de Integração ... 27 3.1. Arquitetura de integração ... 28 3.1.1. Um para um ... 29 3.1.2. BUS integração ... 29 3.2. Base de Dados ... 30
3.2.1. Arquitetura Multibase de dados ... 30
3.2.2. Base de dados partilhada ... 31
3.2.3. Base de dados intermédia ... 32
3.3. BPEL ... 33
4. A Sousacamp ... 35
4.1. História ... 36
4.2. Grupo e Empresas ... 36
4.3. Sistema de Informação ... 38
4.3.1. Infraestrutura de rede física e lógica ... 40
4.3.2. Arquitetura ... 41
4.3.3. Software, serviços e principais funcionalidades utilizadas ... 43
5. EDI intraorganizacional no grupo Sousacamp ... 47
xiii
5.2. Fase 1 – Análise (Solução Proposta) ... 54
5.2.1. Requisitos ... 54
5.2.2. Modelação Software ... 57
5.3. Fase 2 – Desenvolvimento ... 63
5.3.1. Análise da Base de Dados do ERP ... 63
5.3.2. Mapeamentos ... 68
5.3.3. Parametrizações ... 69
5.3.4. Validações ... 70
5.4. Fase 3 – Comunicação com Utilizador ... 70
5.4.1. Interface do utilizador – Front-End ... 70
5.4.2. Sistema de Alertas ... 72 5.4.3. Histórico ... 73 5.5. Fase 4 – Resultados ... 73 5.5.1. Limitações ... 73 5.5.2. Testes ... 74 6. Considerações Finais ... 79 6.1. Trabalho futuro ... 80 Bibliografia... 81 Anexos ... 85
Electronic Data Interchange For Administration, Commerce and Transport ... 86
EDItEUR XML Document Formats ... 87
Extensible Markup Language ... 88
xiv
xv
ÍT
Índice de Tabelas
Tabela 1 - Uso de standards EDI por zonas/dependências (B&N Software AG, 2001) ... 9
Tabela 2 - Exemplo de uma mensagem EDI de uma fatura ... 12
Tabela 3 – Número de documentos anuais trocados dentro do grupo ... 48
Tabela 4 - Número de todos os documentos anuais ... 48
Tabela 5 - Tipo e número de documentos trocados por ano ... 49
Tabela 6 - Tempo necessário por documento (processo manual) ... 51
Tabela 7 - Requisitos Funcionais ... 55
Tabela 8 - Requisitos Não Funcionais ... 56
Tabela 9 – Tabela ArtigoCliente ... 69
xvi
xvii
ÍF
Índice de Figuras
Figura 1 - Diferença entre o fluxo de papel e EDI (Robeson & Copacino, 1994) ... 10
Figura 2 - Ordem de Compra enviada por EDI ... 11
Figura 3 - Comunicação entre dois parceiros de negócio (Garguilo & Markovitz, 1996) ... 18
Figura 4 - Representação simples de sistema EDI por uma VAN (Gupta, 2011) ... 19
Figura 5 - Sistema de VAN típico (Gupta, 2011) ... 19
Figura 6 - Sistema EDI sobre Internet/VAN (Bidgoli, 2011)... 20
Figura 7 - Arquitetura 1 para 1 (Rognerud & Hannay, 2009) ... 28
Figura 8 - Arquitetura com bus integração (Rognerud & Hannay, 2009) ... 29
Figura 9 - Arquitetura de MDBS (Lawrence, 1999) ... 31
Figura 10 - Logotipo da Sousacamp SGPS S.A. (Sousacamp SGPS, 2011) ... 35
Figura 11 - Localização das Empresas ... 37
Figura 12 - Topologia Lógica ... 40
Figura 13 - Estrutura SI dos Hyper-V da Sousacamp ... 42
Figura 14 - Funcionalidades do Microsoft Active Directory (Microsoft Corporation, 2011) ... 43
Figura 15 - Visão Geral do MOSS (Microsoft) ... 44
Figura 16 - Exemplo de transformação (PEC -> ECL) ... 47
Figura 17 - Exemplo de transformação (GTE -> GTR) ... 47
Figura 18 - Documentos trocados dentro do grupo ... 48
Figura 19 - Processo manual do colaborador ... 50
Figura 20 - Dias úteis gastos com Documentos Internos ... 52
Figura 21 - Possível redução do tempo em 50% com EDI em dias ... 53
Figura 22 - Ciclo "ideal" de criação de documentos ... 53
Figura 23 - Diagrama Casos de Uso do Sistema EDI ... 58
Figura 24 - Processo de obtenção e alerta ... 62
Figura 25 - Processo de criação novos documentos ... 62
Figura 26 - Screenshot das operações na BD do ERP ... 64
Figura 27 - Relação entre Cabeçalho e Linhas ERP ... 66
Figura 28 - Interface EDI na Intranet ... 72
Figura 29 - Resumo da inserção ... 77
xviii
xix
Ac
Acrónimos
Nesta dissertação são utilizadas abreviaturas de designações comuns apenas apresentadas aquando da sua primeira utilização:
AIAG Automotive Industry Action Group
ANSI American National Standards Institute API Application Programming Interface ATA Autoridade Tributária e Aduaneira
B2B Business to Business
B2C Business to Consumer
BBS Bulletin Board System
BI Business Intelligence
BPMN Business Process Modeling Notation
CAE Classificação das Atividades Económicas
CICA Context Inspired Component Architecture
CMS Content Management Systems
DFA Departamento Financeiro e Administrativo
DoS Denial of Service
DSI Departamento Sistema de Informação
DW Data Warehouse
xx
HDMA Healthcare Distribution Management Association
IETF Internet Engineering Task Force
ISO International Organization for Standardization LDBS Local DataBase System
MARL Mercado Abastecedor da Região de Lisboa MDBS MultiDataBase System
MOSS Microsoft Office SharePoint Server
NIST National Institute of Standards and Technology
NWDA National Wholesale Druggists Association
OASIS Organization for the Advancement of Structured Information Standards
RDP Remote Desktop Protocol
SGBD Sistema de Gestão de Base de Dados
SGC Sistema de Gestão de Conteúdo
SGPS Sociedade Gestora de Participações Sociais
SI Sistemas de Informação
SP Stored Procedure
SQL Structured Query Language
TDCC Transportation Data Coordinating Committee
TDI Trading Data Interchange
TI Tecnologias de Informação
UCC Uniform Commercial Code
UNECE United Nations Economic Commission for Europe
1
1
1. Introdução
As Organizações estão cada vez mais preocupadas com a otimização dos seus processos para, a partir daí, obter vantagens competitivas no mercado. Por de trás de qualquer negócio, empresa ou instituição existe um constante fluxo de criação e manipulação de documentos e respetivo tratamento. Em muitos casos um autêntico caos burocrático. Estes processos envolvem um grande esforço a nível de recursos humanos e a suscetibilidade a erros é elevada. Os documentos envolvidos nestes processos são, por exemplo, documentos referentes a encomendas, vendas, transporte, etc. O Enterprise Resource Planning (ERP) agrega todos estes documentos na sua base de dados.
Para o envio de documentos de forma automática e eletróncia existe o Electronic Data Interchange (EDI), em português, Troca Eletróncia de Dados que, com as devidas normas, consegue enviar os dados (documentos) para outras organizações.
A Sousacamp é um grupo da área agroalimentar que tem, na sua constituição, diversas empresas distribuídas pela Península Ibérica. As empresas do grupo fazem compras e vendas entre si aumentando a carga de papel com todas as transações efetuadas dentro do grupo.
Assim sendo, a Sousacamp necessita de uma solução de “EDI” que possa satisfazer as necessidades internas entre as empresas do grupo, mas respeitando as diferenças existentes entre empresas.
1.1. Motivações, objetivos e contributos
O fluxo de informação nas organizações está em crescimento, muito devido a novas aquisições e desenvolvimento das mesmas, como também, às novas possibilidades de extração de nova informação a partir de dados já existentes.
2
O grupo Sousacamp tem empresas portuguesas e espanholas tendo algumas sido integradas por aquisição e outras por constituição. As dificuldades e complexidade de integração já são notáveis e a probabilidade desta situação aumentar é elevada.
O sistema de EDI é uma forma de trocar documentos de negócio por via eletrónica. Este sistema é muito utilizado entre empresas. No entanto, para empresas do mesmo grupo esta solução é pouco implementada, existindo pouca informação a esse respeito.
Na literatura o conceito de EDI interorganizacional é referido para empresas distintas, que também poderia aplicar-se aqui, no entanto, pertencendo ao mesmo grupo empresarial, e fazendo parte da cadeia logística, o sistema EDI teria de cumprir os requisitos internos, ou seja, um EDI intraorganizacional (Singh, Lai, & Cheng, 2007).
A Sousacamp investe muitos recursos, materiais e humanos, para manter o fluxo documental interno (dentro de empresas do grupo) organizado e em tempo útil. Um sistema de EDI interno seria a solução para reduzir drasticamente o tempo utilizado na inserção de documentos, bem como a integridade dos dados.
A desmaterialização dos documentos deveria ter capacidade para manter as diferenças legais e organizacionais das empresas portuguesas e espanholas, tal como também fazer um mapeamento de todas as variáveis.
Este documento irá servir como caso de estudo específico de desenvolvimento e implementação de um sistema EDI, com a integração nos sistemas já em utilização no grupo Sousacamp, tais como o ERP e a Intranet.
1.2. Organização do trabalho
Este documento está dividido em 8 capítulos que, no seu conjunto, agregam visões teóricas, práticas, ideias, resultados e conclusões.
No Capítulo 1 é apresentado um breve resumo da dissertação, ou seja, contextualização, motivações, objetivos, finalidade e estrutura.
No Capítulo 2 é feito um enquadramento mais profundo relativamente ao tema central da dissertação, o EDI.
3
O Capítulo 3 mostra algumas metodologias utilizadas e possibilidades de integração, das quais uma será escolhida para a realização deste trabalho.
No Capítulo 4, é introduzida e apresentada a Sousacamp, entidade na qual todo este tema se desenrola tornando-se, assim, caso de estudo da dissertação. É também neste capítulo onde são abordados a estrutura lógica e física dos sistemas de informação da Sousacamp de forma a melhor enquadrar as TI.
No Capítulo 5, é feita uma caracterização dos documentos dentro do grupo e a importância de um sistema EDI interno e, seguindo-se, toda solução proposta, tal como a análise e implementação, incluindo testes e resultados.
No último Capítulo, o sexto, organizam-se as ideias finais e conclusões sobre este trabalho.
4
5
2
2. Electronic Data Interchange
Nas últimas duas décadas, as tecnologias de comunicação têm evoluído de uma forma muito rápida encontrando-se, atualmente, num estado bastante amadurecido. As tecnologias de comunicação estão enraizadas na sociedade de tal forma que são utilizadas, a cada instante, de um modo quase natural.
Para chegar a este ponto foram realizadas muitas investigações na área, sendo que todo o trabalho realizado contribuiu para a constante melhoria dos sistemas e métodos de comunicação. Um desses sistemas é o EDI (Electronic Data Interchange), sobre o qual esta dissertação se irá focar.
EDI são as siglas para Electronic Data Interchange, ou seja, a troca de dados por via eletróncia. Este conceito é, por si só, insuficiente pois todas as formas de comunicação existentes entre sistemas computorizados podem-se encaixar nesta definição. De qualquer modo, o EDI é uma forma padronizada de transferência de dados, de um lugar para outro, por via eletrónica.
As organizações estão cada vez mais com um maior fluxo documental entre os seus clientes e fornecedores. Este fluxo representa uma carga elevada ao nível da necessidade de recursos humanos e, por sua vez, no aumento dos custos. Da necessidade da partilha dos documentos de forma rápida, segura e fiável, surge o EDI. Este sistema facilitou as tarefas às empresas na partilha de documentos com a ajuda de um software estabelecido em módulos, que envia os dados de um lado para outro de forma eletrónica. Trata-se de um software que pode ser visto como uma ferramenta de integração entre parceiros de negócio, pois ambas as partes têm de aceitar a sua utilização.
6
Atualmente, o EDI é largamente utilizado, visto a sua utilização ter imensas vantagens (Agi, Ballot, & Molet, 2005). O seu uso estende-se a organizações de diversos tipos, quer da área da saúde, administração educacional, governamental, a empresas de viagens e hotelaria, estatística, financeira, entre outras (Hall, 2010).
2.1. Conceitos
Segundo o NIST (National Institute of Standards and Technology) na publicação de
standards de 1996 (NIST, 1996), “EDI é o intercâmbio entre computadores de mensagens
estritamente formatadas que representem documentos de instrumentos monetários. EDI implica uma sequência de mensagens entre duas partes, cada uma das quais pode servir como remetente ou destinatário. O processamento é normalmente feito apenas por computador. A intervenção humana é usada apenas em casos de erro, análise de qualidade e para outras situações especiais.”.
James F. Robeson (Robeson & Copacino, 1994) define o EDI como sendo a partilha de dados de uma organização para outra, ou de um computador para outro, de forma estruturada. O formato utilizado para transmitir os dados é processável pelo computador e um sistema próprio de tradução e, dessa forma, é traduzido o documento numa língua compreensível.
Na mesma lógica, segundo Schniederjans e Qing Cao (Schniederjans & Cao, 2002): “EDI geralmente refere-se à troca de computador para computador de um elevado volume de informação de negócio, entre parceiros, utilizando padrões nacionais ou internacionais.”. Outra definição dada por Schniederjans e Qing Cao, mais técnica, refere os padrões ANSI X12.
O objetivo principal deste sistema não é de gerar conteúdo copiado, ou seja replicar conteúdo, mas sim, enviar e receber dados de forma eficiente. A visão profética de Robeson (Robeson & Copacino, 1994) pode ser vista a partir da sua afirmação, em que o EDI começou a ser utilizado em diversos mercados: “EDI tornou-se bastante comum em operações logísticas e alguns estimam que a partir de 1995 mais de 80% dos pedidos serão transmitidos via EDI.”.
As definições mais recentes apontam o EDI como sendo um formato padrão utilizado pelas organizações para a troca de informação processável para o negócio e computadores. “É a troca de informação interorganizacional de informação processável de negócio num formato padronizado.” (Hall, 2010).
7
Ainda há dois anos atrás o sistema EDI era apenas considerado importante e relacionado com empresas/organizações, mas as definições mais contemporâneas veem o EDI com um âmbito mais alargado. “A troca padronizada e estruturada de informação eletrónica entre duas ou mais partes, utilizando redes publicas e/ou privadas.” (Ciampa & Revels, 2012). Estas partes podem ser relacionadas com a saúde, com duas pessoas que trabalham a nível nacional, dois familiares, dois amigos, etc. Embora o conceito se tenha alargado a várias áreas nas tecnologias de informação, o conceito básico é o mesmo.
As definições complementam-se entre elas, havendo autores a destacar mais a parte técnica e processual e outros a evidenciarem o processo de negócio envolvido.
Torna-se vital saber como o EDI chegou ao seu estado atual, isto é, a sua evolução. Esta irá clarificar o propósito da sua utilização, os padrões utilizados e o respetivo processo de implementação.
2.2. Evolução
O sistema de EDI começou a ganhar notoriedade nos anos 60 (ACS GSG, 2000), quando as empresas de transportes começaram a focar-se no desenvolvimento de uma forma eficiente para transferir dados de empresa para empresa, de modo a ter a informação amplamente e convenientemente partilhada. De forma similar, as empresas ligadas ao retalho começaram a considerar mais fácil comunicar com os fornecedores utilizando um sistema de EDI. O resultado foi um sistema de EDI num formato de autodesenvolvimento que permitia às empresas monitorizar o estado dos negócios com os fornecedores. Com o passar do tempo, esta tecnologia de transferência de dados entre entidades começou a ganhar uma verdadeira forma e, finalmente, em 1985, as Nações Unidas desenvolveram o EDIFACT. Este foi o primeiro padrão para melhorar a comunicação e compatibilidade a nível internacional. Este padrão tem as siglas provenientes de “EDI For Administration, Commerce and Transport”, estando focado nessas mesmas áreas (Stanley, 2003).
O desenvolvimento do EDI começou, portanto, por volta de 1960, mas a necessidade de um sistema destes começou antes, o que viria a ser um dos impulsionadores do EDI. Em 1948, uma das maiores empresas da aeronáutica, a Air Berlin, tinha falta de coordenação entre as empresas responsáveis pelo transporte e distribuição de ingredientes gastronómicos.
8
A Air Berlin resolveu a situação idealizando um sistema de comunicação rápida, onde o sistema de telecomunicações surgiu como um grande impulsionador. Antes disso, a comunicação era feita pelo correio postal. As telecomunicações tornaram o sistema mais conveniente permitindo a confirmação de encomendas “instantaneamente” pelo telefone. A necessidade de criar um sistema de EDI não chegou nesta fase precoce, mas com o passar do tempo, como a informação era partilhada de forma manual, cada vez mais surgia erro humano, falta de credibilidade das mensagens, baixo nível de eficiência, etc. Assim, foi desenvolvido um sistema de EDI para partilhar os dados de forma eficiente, segura e autêntica. Desta forma, começaram a surgir aplicações para esta tecnologia e respetiva instalação (Sabri, Gupta, & Beitler, 2006).
Com a criação de soluções individuais começou a surgir outro problema. Os documentos enviados e recebidos tinham formatos diferentes uns dos outros. Era difícil para as companhias enviar os dados para outros parceiros por via eletrónica. Após a revolução tecnológica, em 1960, os grupos industriais reuniram esforços para conseguir um formato comum, mas mesmo esse formato foi utilizado para partilhar transações apenas da indústria, finanças, transporte e compras (Garguilo & Markovitz, 1996)
A nível internacional a pesquisa e desenvolvimento nesta área começou nos anos 70, quando todas as organizações indicaram as suas necessidades tendo em conta a troca de dados de forma eletrónica, ou seja, os formatos e padrões. Daí resultaram os padrões de EDI. Os requisitos estavam relacionados com a independência do hardware: não ambiguidade, de forma a poder ser utilizador por qualquer negociante/parceiro; não necessidade de interação humana, de forma a reduzir custos e “consciência” (awareness) das transações realizadas, duração e capacidade de ambas as partes poderem utilizar e manipular os dados (Garguilo & Markovitz, 1996). Em 1968, a TDCC (Transportation Data Coordination Committee), forneceu a solução do problema mantendo os requisitos sob consideração e definiu as três principais regras que incluem um mecanismo de comunicação independente para os dados, entidades independentes e reciprocidade inovadora e requisitos dinâmicos de negócio (Sabri, Gupta, & Beitler, 2006).
Os primeiros padrões criados e regulados pela TDCC foram utilizados pelas indústrias motoras e linhas férreas. Entretanto, os sistemas de EDI foram também adotados pelas grandes empresas da indústria automóvel americana, tais como a Ford e a Chrysler mas, com o passar do tempo, começaram a criar os seus próprios padrões, gerando uma elevada quantidade de padrões distintos na indústria automóvel. Tendo isso em conta, a AIAG (Automotive Industry
9
Action Group) desenvolveu o seu próprio padrão de EDI para lidar com a complicação de cada marca ter o seu padrão, acabando por ter sucesso. Este movimento motivou outras indústrias a padronizar o EDI, incluindo-se o ANSI (American National Standards Institute), o UCC (Uniform Commercial Code), e a NWDA (National Wholesale Druggists Association). Quase todas as grandes empresas usam alguns destes padrões mesmo não estando completamente estabelecidos (Sabri, Gupta, & Beitler, 2006).
Tabela 1 - Uso de standards EDI por zonas/dependências (B&N Software AG, 2001)
Standard Dependente da Indústria Independente da Indústria
Internacional UN/EDIFACT
Regional ODETTE (Indústria automóvel Europa) SWIFT (Bancos Europa)
Nacional VDA (Indústria automóvel Alemanha) SEDAS (Comércio Alemanha)
ANSI X.12 (USA)
TRADACOM (Inglaterra)
2.3. Propósito
Segundo Drickhamer (Drickhamer, 2003), as organizações que adotaram as novas tecnologias de informação, respetivamente os sistemas de partilha de dados e, entre eles, o EDI, obtiveram imensos benefícios. Entre elas destacam-se a Walmart que se tornou líder no retalho na América. Torna-se então vital perceber qual o propósito do EDI entre as empresas e o seu sucesso crescente no mercado.
Tradicionalmente, o sistema de troca de informação era o papel. Segundo Doyle (Doyle, 2001), quando uma entidade queria partilhar algo com outra, tinha de preparar uma carta segura (equiparável a uma carta registada), escrever a carta com palavras supérfluas, juntar toda a informação possível sobre a outra entidade e depois enviar. Depois de enviar a carta, era preciso esperar longos períodos até obter uma confirmação da receção da carta, ou uma resposta à mesma. Assim sendo, a pessoa encarregue deste processo complexo e demorado perdia bastante tempo que poderia ser investido em outras funções. Para essas mesmas pessoas, o EDI apareceu como uma revolução na forma de trabalhar: o que era feito em dias passou a realizar-se em segundos.
Esta ideia da troca de dados pode ser aplicada a qualquer empresa/organização. Por exemplo, quando uma empresa necessita de comprar algo a um fornecedor, envia o seu pedido formalizado por correio com todas as necessidades. Este é entregue no posto de correio mais
10
próximo que, por sua vez, o envia para o posto mais próximo do fornecedor, concluindo a entrega final ao fornecedor. Após este processo, o pedido estaria concluído e iniciava-se a comunicação propriamente dita.
O fluxo de todo o papel envolvido neste processo era muito demorado, sendo que o cliente e o fornecedor não conseguiam manter um contacto constante. Esta falta de informação causa muitos problemas a ambas as empresas. Tomando um construtor de automóveis como exemplo, este, para construir os seus carros, necessita de materiais que nem sempre são fabricados por si próprio, como por exemplo os pneus, mas sim fabricados por outras empresas. Dependendo da quantidade de automóveis que está a ser produzida, que por sua vez depende da procura, o construtor vai precisar de mais ou menos pneus. O fornecedor destes deve estar atualizado no que respeita às necessidades do seu cliente, para não provocar uma paragem na produção automóvel. O sistema de EDI tornou possível uma comunicação constante e, assim, fortalece as parcerias de negócio entre clientes e fornecedores. O fluxo de ambos os sistemas, papel e EDI, pode ser visto na figura seguinte:
Purchasing Buyer s Computer
Post Office Order Entry Seller s Computer P.O. P.O. Purchasing Buyer s Purchasing Application Seller s Order Entry Application EDI Flow Paper Flow
Figura 1 - Diferença entre o fluxo de papel e EDI (Robeson & Copacino, 1994)
Na Figura 1 é possível observar o impacto que o sistema de EDI consegue ter na mesma operação. Há várias etapas que deixam de ser necessárias, sendo estas as que mais tempo consumiam em todo o processo (a entrega). Com este novo fluxo criado pelo EDI é possível a utilização do potencial dos colaboradores em outras tarefas importantes para a empresa.
11
2.4. Como funciona?
O sistema EDI funciona numa forma muito sistemática e padronizada, como pode ser visto, a título de exemplo, na figura seguinte:
Figura 2 - Ordem de Compra enviada por EDI
Quando o fornecedor e o cliente partilham informação, trocando documentos. Estes são traduzidos pelo sistema de tradução do EDI, e depois enviados pelo respetivo sistema de comunicações da empresa. O documento é recebido pela outra entidade e o processo inverte-se, sendo processado o documento no tradutor e colocado no respetivo sistema. Neste, passa já a ser possível ler o documento em linguagem natural e responder ao mesmo.
Empresa A Empresa B Cliente Fornecedor Sistema de Compras do Cliente Software de Tradução EDI Sistema de Comunicação Sistema de Vendas do Fornecedor Software de Tradução EDI Sistema de Comunicação Internet, Van,…
12
O processo de EDI pode ser resumido em poucos passos:
O primeiro passo é realizado por um colaborador da empresa. Este passo consiste em reunir os documentos, ou decidir quais os documentos a serem enviados por via eletrónica. Quando os dados estiverem reunidos e inseridos no sistema (ERP ou outras aplicações), o envio é iniciado/despoletado de forma automática e/ou manual.
No passo seguinte, existe um tradutor que faz um mapeamento entre vários campos e os respetivos códigos. Esta formatação é muito mais difícil de ser inteligível. Há casos em que os tradutores fazem ficheiros específicos com formatos próprios, dependendo do cliente em causa. Veja-se este tradutor como sendo um extrator dos dados da base de dados do ERP e os generaliza nos seus campos no ficheiro de EDI (Tabela 2).
Um ficheiro em formato de EDI tem na sua constituição um conjunto de parâmetros e variáveis em forma de código. Cada código é bem estabelecido e especificado de forma a não originar ambiguidades. A Tabela 2 mostra um exemplo de um ficheiro EDI já preenchido com alguns campos de uma fatura.
Há diversas aplicações para enviar os dados eletrónicos. Os dados são enviados de um computador para outro e, geralmente existe, também, uma cópia dos mesmos em formato de correio eletrónico que funciona como uma notificação. As VAN (Value Added Network) processam os dados e reconhecem o caminho para fazer a entrega no local correto.
O computador recetor faz, então, a tradução da mensagem EDI para ser compreensível aos seres humanos. É desta forma que todo o processo ocorre (Petravick, How EDI Works, 2002).
Tabela 2 - Exemplo de uma mensagem EDI de uma fatura
UNB+UNOA:2+8437009395110+8481061777773+120911:0000+20++INVOIC' UNH+1+INVOIC:D:93A:UN:EAN007' BGM+380+20' DTM+137:20120125:102' RFF+DQ:16/12P' NAD+SCO+8437009395110::9++EMPRESAORIGEM RFF+VA:A34227074' NAD+BCO+8481061777773::9++EMPRESADESTINO RFF+VA:A39050349' NAD+SU+8437009395110::9' NAD+BY+8481061777773::9' NAD+II+8437009395110::9'
13 NAD+IV+8481061777773::9'
NAD+DP+8481061009959::9' CUX+2:EUR:4'
LIN+1++8437009395240:EN'
IMD+F+M+:::Seta Pleurothus Bandeja 200 gr' QTY+47:300.00:PCE' MOA+66:198.00' PRI+AAB:0.660' PRI+AAA:0.660' TAX+7+VAT+++:::4.0' MOA+124:7.92' LIN+2++8437009395110:EN'
IMD+F+M+:::Champiñón Blanco C/ Pie Bandeja 350' QTY+47:240.00:PCE' MOA+66:136.80' PRI+AAB:0.570' PRI+AAA:0.570' TAX+7+VAT+++:::4.0' MOA+124:5.47' LIN+3++8437009395356:EN'
IMD+F+M+:::Ajo Tierno Bandeja 100 gr' QTY+47:36.00:PCE' MOA+66:29.52' PRI+AAB:0.820' PRI+AAA:0.820' TAX+7+VAT+++:::4.0' MOA+124:1.18' LIN+4++5603366000421:EN'
IMD+F+M+:::Espárrago Verde Manojo 320 gr' QTY+47:48.00:PCE' MOA+66:69.60' PRI+AAB:1.450' PRI+AAA:1.450' TAX+7+VAT+++:::4.0' MOA+124:2.78' LIN+5++8437009395202:EN'
IMD+F+M+:::Champiñón Blanco Laminado Bandeja 2' QTY+47:300.00:PCE' MOA+66:225.00' PRI+AAB:0.750' PRI+AAA:0.750' TAX+7+VAT+++:::4.0' MOA+124:9.00' UNS+S' MOA+79:658.92' MOA+125:658.92' MOA+176:26.36' MOA+139:685.28' TAX+7+VAT+++:::4'
14 MOA+176:26.36' MOA+125:658.92' UNT+63+1' UNZ+1+20'
2.5. Standards (Padrões)
Para garantir um sistema de EDI com sucesso, deve-se aderir e utilizar os padrões mais corretos, pois a utilização de EDI sem qualquer padrão tornar-se-ia, a médio/longo prazo, problemático dentro da empresa. Daí, as associações internacionais terem desenvolvido um conjunto de padrões que podem ser adotados em qualquer empresa. No entanto, as empresas adotam geralmente alguns conjuntos à medida para ir ao encontro dos seus requisitos e das suas necessidades.
Um conjunto de padrões pode ser visto como sendo o formato estabelecido pelas organizações a fim de enviar e receber os dados. O remetente e o destinatário “compreendem” o formato utilizado e traduzem-no de forma a ser legível pelos humanos.
Existe uma abundância de fontes disponíveis para o desenvolvimento correto e bem-sucedido de um sistema EDI. No entanto, as normas que merecem um maior destaque e as que são utilizadas de forma mais ampla são os padrões X12 e EDIFACT (Korhonen & Salminen, 2003), mas estando, neste momento, o XML a ganhar cada vez mais a possibilidade de vir a ser o sucessor de êxito (Nurmilaakso, 2008). O XML será, como pode ser visto no capítulo 5, o padrão utilizado (ver anexo XML).
2.5.1. EDIFACT
O EDIFACT é o resultado de um esforço das Nações Unidas em promover o comércio a nível internacional. Este padrão foi desenhado e pensado para manter todos os princípios da comunicação em consideração. Assim, a ISO (International Organization for Standardization) e a UNECE (United Nations Economic Commission for Europe), em colaboração, estabeleceram e mantiveram este padrão internacional que pode ser utilizado num âmbito bastante alargado em qualquer indústria (Bidgoli, 2011).
15
2.5.2. X12
Para ajudar as diferentes indústrias a melhorar o sistema de comunicação, o Instituto Nacional Americano de Padrões, ANSI, desenvolveu um conjunto de padrões que ficou conhecido como X12.
O X12, também conhecido por ASC X12 pertence à ASC (Accredited Standards Committee), fundado pela ANSI em 1979. A ASC desenvolve e mantém o X12 EDI e CICA, em conjunto com padrões de XML orientados a processos de negócio. O nome X12 provém de uma designação contínua em uso na ANSI, na altura da acreditação.
Este padrão é o mais utilizado nas empresas e organizações norte americanas. Este define e indica a estrutura dos dados, em conjunto com o conteúdo e sequência, com os quais o documento deve ser apresentado e enviado. Por exemplo, existem mais de 270 palavras reservadas pelo X12 (Bidgoli, 2011).
2.5.3. XML
O XML é uma forma de representação de dados estruturada e organizada em blocos. É um padrão de elevado sucesso e com possibilidades de vir a ser o futuro padrão de EDI (Nurmilaakso, 2008), existindo já alguns padrões baseados em mensagens XML, como é o caso do EDItX (ver Anexos).
O XML foi desenvolvido em meados anos 90 (ISO 8879:1986 Standard Generalized Markup Language (SGML)) para uso específico em aplicações Web, sendo atualmente utilizado em muitos âmbitos informáticos. O XML é, assim, a base para muitos padrões para transações eletrónicas (anexo: XML).
2.6. Especificação
Cada aplicação de EDI tem o seu objetivo concreto. Para tal, existem especificações diferentes dependendo do seu propósito. Por exemplo, algumas aplicações de EDI são feitas tendo em consideração as questões de segurança das mensagens, enquanto outras são feitas para manter a eficácia das mensagens. Portanto, dependendo do que é mais importante, é escolhida uma ou outra especificação. Um tipo de especificação de EDI que tem em conta a segurança é
16
o IETF1-EDI (Internet Engineering Task Force EDI). O IETF-EDI é largamente utilizado nas organizações em que a segurança é uma prioridade, tais como organizações militares, bancárias e governamentais (Bajaj & Nag, 2005).
“As primeiras especificações de EDI não eram padronizadas e um vendedor que trabalhasse com vários clientes tinha de manter diversas versões do sistema EDI.” (Grossman & Livingstone, 2009). Para resolver este problema todos os clientes teriam de trocar o sistema de EDI para conseguirem manter um só sistema. Mas, de forma similar, isto repete-se ao longo de toda a cadeia logística, pois todos eles têm de manter versões para garantir a compatibilidade ao longo de todo o processo. No entanto, o objetivo do EDI é minimizar o tempo de transmissão das mensagens, aumentar a eficiência, ser de baixo custo e garantir a segurança na transmissão das mensagens (Grossman & Livingstone, 2009).
Atualmente existem muitas organizações que utilizam sistemas baseados em WEB-EDI. Estes sistemas permitem a criação de compras, clientes, encomendas, entre outros, a partir de uma simples interface WEB, que após validação automática insere os dados automaticamente no sistema da organização. Este tipo de EDI tornou-se bastante popular entre lojas e comércio baseado apenas na Internet (Grossman & Livingstone, 2009).
A nível organizacional, as especificações são vistas como diretrizes que são definidas em colaboração para definir e decidir quais e como são enviadas as informações. Todas as grandes organizações têm normas internas que definem o uso dos sistemas de EDI. Estas normas são muito bem analisadas devido à sensibilidade dos dados em causa e possíveis de serem enviados por EDI.
1 IETF - Internet Engineering Task Force, foi fundado em 1986. É uma organização de padrões maioritariamente
focados em segurança na Internet. Os fundos advêm principalmente da VeriSign e NSA (National Security Agency)
17
2.7. Tradutor
O sistema de EDI consegue trocar informação de um lugar para outro de forma muito rápida. No entanto, de modo a compreender como este sistema funciona e como a informação é traduzida, é indispensável analisar os dados numa perspetiva mais técnica. Esta parte do documento mostra alguns aspetos básicos do sistema de tradução e o respetivo mapeamento.
Antes de definir o processo de tradução propriamente dito, é necessário saber o que é o tradutor em EDI. Trata-se de um componente de software pertencente ao sistema de EDI que é utilizado para fazer a conversão e mapeamento dos diferentes tipos de dados usados em EDI. É este componente que é referido como sendo o tradutor de EDI (Garguilo & Markovitz, 1996).
O tradutor de EDI tem duas tarefas essenciais para o correto funcionamento de todo o sistema de EDI: a tradução/conversão e o mapeamento. Para a tradução o sistema tem de perceber o formato original da mensagem e convertê-lo no formato em uso na organização para, de seguida, mapear todos os dados para os campos corretos. Caso o sistema não consiga traduzir ou mapear os dados, estes são retornados para o remetente com mensagem de erro e o destinatário é alertado do sucedido.
Para a troca do documento o tradutor começa por criar um ficheiro simples que é escrito de acordo com a sintaxe do sistema EDI. Esse mesmo ficheiro começa a ser preenchido com informação para o recetor. Durante a receção do ficheiro, o tradutor certifica-se que este está na sintaxe e formato correto com os padrões definidos pela empresa recetora. Depois de passar por todas as validações, o ficheiro segue para ser introduzido no sistema.
O sistema quando recebe um novo ficheiro por EDI, dependendo do ficheiro e da configuração do sistema, existe uma aprovação/validação de todos os dados que, por regra, funciona em semiautomático. Tal significa que validações básicas são efetuadas imediatamente pelo próprio sistema, enquanto validações mais especializadas, tais como valores, preços, etc., são validadas pelos utilizadores responsáveis. Isto ajuda a impedir a entrada de ficheiros/dados incorretos no sistema e a ter alguma supervisão do sistema em si. Existem casos em que os parceiros fazem parte do mesmo grupo para o qual o sistema foi feito à medida. Nessa situação, todas as validações são automáticas, sem intervenção do utilizador (p.e. Indústria Automóvel).
18 Application Database Application Data File (flat-file) EDI File Communications Service Trading Partner 1 Standards Formatter Data Mapper EDI Translator Application Database Application Data File (flat-file) EDI File Communications Service Trading Partner 2 Standards Formatter Data Mapper EDI Translator Communication Network
Figura 3 - Comunicação entre dois parceiros de negócio (Garguilo & Markovitz, 1996)
Após discutir a implementação e aplicabilidade do sistema EDI, na parte seguinte será discutida a forma de transmissão para a transferência de dados EDI.
2.8. Fontes de transmissão
Para enviar e receber os dados são utilizadas diferentes formas de transmissão. Por exemplo, os parceiros de negócio podem utilizar qualquer tipo de sistema, desde que exista correspondência, ou seja, tem de haver ligação entre os parceiros. Os métodos antigos de transferência eram feitos por BBS (Bulletin Board System), VAN (Value Added Network) ou outras ligações por modem (Beckner, 2007). No entanto, a Internet é largamente utilizada devido à elevada compatibilidade com diversos protocolos (Whitman & Mattord, 2011). Mesmo assim, a maioria dos documentos continua a ser transmitida por sistema de VAN EDI.
2.8.1. Value Added Network
Value Added Network, ou seja, rede de valor acrescentado, é uma das formas de comunicação de mensagens EDI mais usadas. O seu objetivo principal é funcionar como se se tratasse de uma estação de correios. Portanto, encarrega-se de efetuar a entrega no destino
19
correto. A VAN pode ser vista como uma rede própria que tem diversas “caixas de correio” para EDI. Existem várias VANs e estas estão interligadas de forma a permitir a comunicação e o envio de mensagens EDI entre elas. Isto é, parceiros de negócio que tenham as suas caixas de correio EDI em VANs diferentes conseguem comunicar devido à interligação existente (Raciti, 1996). R equ es t: In th e f o rm o f E DI d o cu m e n t R es pons e : In t h e f o rm o f E DI d o cu m e n t
Figura 4 - Representação simples de sistema EDI por uma VAN (Gupta, 2011)
Além de funcionar como transmissor, a VAN faz também a retransmissão dos documentos, auditoria de todas as informações envolvidas e desempenha a função de Gateway. As características mais importantes para o uso das VANs em sistemas EDI são a sua eficácia na comunicação e o encaminhamento correto de dados para o destinatário. As VANs são responsáveis pela entrega, envio e armazenamento dos dados. As empresas que disponibilizam os sistemas de EDI VAN estão, geralmente, ligadas às telecomunicações, ou outra empresa com domínio em redes de comunicação. Estas empresas são consideradas prestadores de serviços junto do EDI. Business application EDI Standard message VAN EDI Standard messages Business Application
Translation Store and forward messages Translation
Figura 5 - Sistema de VAN típico (Gupta, 2011)
2.8.2. Internet
A Internet é utilizada por muitas empresas como sistema de comunicação para o EDI. Mesmo que este sistema tenha ganho muita popularidade, muitas continuam a preferir canais
20
isolados para as suas comunicações (exemplo disso são alguns governos e militares). Quase todas as grandes empresas utilizam a internet para comunicar com os seus clientes. Temos como exemplo a Bell Helicopter, empresa focada na produção e construção de helicópteros civis e militares, que utiliza o sistema de EDI com mais de 1000 fornecedores. De forma similar, a WalMart pode ser vista como outra empresa que, em 1998, adotou o EDI em grande escala para se manter em contato com os fornecedores. Esta alteração proporcionou dois elevados benefícios à empresa. Por um lado, permitiu a pequenos comerciantes enviar e receber informações da empresa de forma eficiente; por outro lado o uso da Internet, para a Walmart, possibilitou uma redução de custos, pois as VAN, anteriormente em uso, tinham custos elevados tanto para a empresa, quanto para os respetivos fornecedores. Assim sendo, a Internet possibilitou o uso do EDI sem trazer preocupações com os custos.
Outro benefício do uso da Internet em EDI é o facto de o sistema funcionar num modo “self-service”. Ou seja, os utilizadores registam-se e podem enviar pedidos à empresa, ao contrário do sistema VAN, no qual os documentos apenas podiam ser enviados caso a empresa estivesse afiliada com a respetiva empresa (Bidgoli, 2011).
Shipping System Extract and Format Notices EDI Translation EDI document Management EDI document Management EDI Translation Format Receipts Receiving System VAN or Internet
Figura 6 - Sistema EDI sobre Internet/VAN (Bidgoli, 2011)
Após discutir duas formas populares de transmissão de documentos via EDI, a parte seguinte será referente a uma implementação de sucesso.
21
2.9. Processo de implementação
Os sistemas computorizados são atualmente uma obrigação em qualquer empresa. Mas não basta ter sistemas que enviem e recebam dados. Tem de haver uma coordenação correta para que tudo funcione em perfeita simbiose. Para instalar um sistema de troca de dados eletrónico são precisos vários passos, desde avaliar, desenvolver, testar, implementar, entre outros, até chegar ao resultado final. De seguida apresenta-se um exemplo de processo de implementação de um sistema típico de EDI (Sabri, Gupta, & Beitler, 2006).
No primeiro passo, toda a informação básica tem de ser analisada. Esta informação inclui os documentos a serem utilizados, o número de parceiros de negócio com os quais irá haver troca de documentos, o volume de documentos a ser enviado, e a própria decisão de desenvolver uma solução “in-house” ou analisar propostas de empresas terceiras (outsourcing). Todos os requisitos devem ser tomados em conta. E devido ao elevado investimento adjacente a um projeto destes, devem ser tomadas todas as decisões a longo prazo.
No segundo passo é feita a tradução e mapeamento dos documentos, ou seja, neste passo todos os parceiros de negócio estão envolvidos na entrega dos seus “manuais”. Estes manuais contêm informação sobre o mapeamento específico que cada empresa possui. Isto ajuda a determinar a melhor tecnologia a utilizar no desenvolvimento do sistema EDI.
Num terceiro passo é decidida qual a forma de comunicação a utilizar, desde linhas “dial-up”, que utilizam informação direta para estabelecer contato entre as empresas, a VAN e Internet. No caso das linhas “dial-up”, estas apenas se justificam se o número de parceiros e transações for baixo, ao contrário do uso das VANs e Internet que se justifica com muitas transações e parceiros.
No último passo são iniciados os testes. Estes baseiam-se na troca de documentos de forma a existir fluxo em ambas as direções. É preciso que o sistema seja vantajoso para a empresa destinatária e remetente. Nesta fase, é também verificado se todos os mapeamentos estão a funcionar, tal como o comportamento do sistema em situações anormais ou sobre carga elevada (Sabri, Gupta, & Beitler, 2006).
Estes passos descritos acima serão os que irão ser seguidos no caso da Sousacamp e o sistema de EDI interno a desenvolver. O modelo de implementação proposto por (Sabri, Gupta,
22
& Beitler, 2006) pode não ser usado de forma rigorosa, mas sim, adaptado à realidade do grupo Sousacamp, no entanto tentará ser o mais fiel possível.
2.10.
Constrangimentos na implementação
Com a evolução tecnológica torna-se cada vez mais fácil e conveniente a implementação de um sistema EDI. No entanto, continua a haver certas limitações que se tornam obstáculos para a implementação de EDI. Seguem alguns:
2.10.1. Custo: uma das maiores barreiras na implementação é certamente o elevado investimento necessário para um bom sistema de EDI. Um plano de implementação e sua execução pode ascender a preços elevadíssimos. No entanto, no caso da indústria automóvel este custo chega a ascender a alguns milhares de euros mas, no longo prazo, há uma compensação devido às vantagens que tais sistemas trazem consigo.
2.10.2. Padrões inadaptados: O segundo entrave ao EDI são os padrões utilizados pelos diversos parceiros. Cada um usa um tipo de padrão que, em muitos casos, até foi adaptado ou desenvolvido à medida. Isto obriga a uma constante atualização com os parceiros de forma a manter o sistema operacional. Todas essas atualizações têm custos associados.
2.10.3. Redundância: Estando o EDI no centro da organização é essencial que, em circunstância alguma, nunca falhe. Para tal, é necessário que haja redundância nas comunicações e nos métodos utilizados. Isto irá aumentar, de novo, os custos e a complexidade de todo o sistema (Sabri, Gupta, & Beitler, 2006). Torna-se, assim, bastante mais complicada a resolução de problemas.
Mesmo que a implementação de um sistema EDI seja um processo complicado, as vantagens são compensatórias. Seguem algumas vantagens do uso de EDI.
2.11.
Vantagens
O uso dos sistemas de EDI a nível organizacional prova-se lucrativo a longo prazo e, em alguns casos, até a curto/médio prazo. Os benefícios do uso de EDI são imensos. Nesta parte serão analisadas quatro das maiores vantagens: a velocidade, a precisão, a rentabilidade e a segurança (Petravick, The Traditional Definition of EDI, 2002).
23
2.11.1. Velocidade
Uma das vantagens mais plausíveis para a troca de dados em formato eletrónico é a velocidade de transmissão. Foi esta a motivação inicial de todo o desenvolvimento do sistema EDI. Se todo o sistema estiver bem implementado é possível enviar um documento de um lado para outro em frações de segundos. Anteriormente teria de ser enviado à mão, com tempos de espera de alguns dias, ou até por fax, no qual era preciso ter uma cópia física, enviá-la e o recetor teria de a reintroduzir no sistema, etc.
A velocidade não está dependente da localização do parceiro de negócio, o que significa que enviar um documento para uma empresa que esteja na mesma zona geográfica, ou enviar para outro hemisfério, tem os mesmos custos associados, bem como o tempo de espera. Isto ajuda nas diferenças horárias provenientes das diferentes regiões, pois o sistema consegue funcionar em automático.
Visto os documentos chegarem muito mais rápido ao destino, dá-se uma redução no tempo de espera para o material físico em si. Ou seja, se é feita uma encomenda a outro parceiro, e visto ele receber essa encomenda em frações de segundos, ele consegue prepará-la e enviá-la no próprio dia. Tudo isto traz como consequência um melhor desempenho geral da empresa, tanto do cliente como do fornecedor.
O sistema de EDI não se limita apenas a um documento de cada vez. É possível enviar múltiplos documentos de uma só vez, o que melhora ainda mais a sua utilização na organização.
2.11.2. Precisão
A segunda grande vantagem do uso de EDI é a precisão que é oferecida pela transmissão e pelos formatos. Se analisarmos a forma tradicional de introdução de documentos nos sistemas das organizações verificamos que havia uma elevada probabilidade de os documentos se extraviarem durante o transporte e uma elevada possibilidade de erro humano na transcrição para os sistemas (Bergeron & Raymond, 1997). O uso de EDI veio omitir essas possibilidades de erro, visto que tudo é feito a nível computacional. Tal veio anular a introdução e as diversas reintroduções de documentos, promovendo probabilidades de erro menores que 1%.
24
2.11.3. Rentabilidade
A razão pela qual o sistema de EDI se torna rentável, mesmo devido ao elevado investimento inicial, é pelo facto de a empresa poder orientar os recursos utilizados nos meios tradicionais para o negócio propriamente dito. O processo de negócio melhora com a introdução do EDI (Seuring & Goldbach, 2002).
Segundo Garguilo e Markovitz (Garguilo & Markovitz, 1996), as reduções de custos prendem-se com a melhoria do tempo necessário, redução dos custos adicionais relacionados com o papel e respetivo arquivamento, espaço, entre outros.
2.11.4. Segurança
Outro beneficio oferecido pela utilização do sistema EDI é a segurança. As organizações podem enviar e receber documentos extremamente confidenciais sem comprometer a segurança dos mesmos. Tudo isto graças aos diferentes protocolos que mantêm a integridade e garantem que nenhum acesso não autorizado seja efetuado (Whitman & Mattord, 2011).
Antes deste processo, os documentos, mesmo os confidenciais, para serem entregues em outros locais, eram passados de mão em mão, o que punha em causa o sigilo da informação. O EDI reduz drasticamente esse risco, mas, tal como é sabido na era tecnológica, nada que esteja ligado a um sistema de comunicações é 100% seguro, existindo sempre um risco de violação, mas bastante inferior quando comparado com os métodos tradicionais de troca de documentos.
Mesmo com o elevado potencial proporcionado pelos sistemas de EDI, existem algumas limitações que devem ser tidas em conta.
2.12.
Limitações
Algumas limitações parecem-se com as desvantagens anteriormente referidas, mas que aqui têm outro âmbito.
2.12.1. Segurança
A segurança é uma vantagem, mas também uma limitação, pois fica ao alcance de elaboradas técnicas computacionais de criptografia e formas de ataques informáticos. Atualmente existem muitos ataques de força bruta, de DoS (Denial of Service), entre outros que
25
podem comprometer a segurança de um sistema EDI. Daí que a devida manutenção e atualização sejam fulcrais para o combate a estas forças.
Existem casos em que as empresas e organizações investem em linhas dedicadas para a troca de informações, como no caso das organizações militares ou mesmo ligadas à saúde. No sistema de EDI existem dois tipos de informação muito importantes para se manter seguras. A informação como por exemplo, contas, encomendas, guias transporte, etc. e a informação relacionada com pagamentos, tais como cartões de crédito, transferências, entre outros (Garguilo & Markovitz, 1996).
2.12.2. Capital investido
O investimento, tal como já foi referido, é avultado, principalmente quando a segurança é uma questão crítica com ligações dedicadas, ou VAN’s, pois junta-se ao investimento inicial a manutenção e constante atualização dos sistemas.
O valor investido pode ser menor utilizando a internet como meio de comunicação.
2.13.
Síntese
O sistema EDI proporciona bastantes benefícios à empresa e aos seus fornecedores/clientes. O desenvolvimento do EDI deu-se num espaço temporal muito pequeno sendo que o seu desenvolvimento não é estático, mas antes uma constante dinâmica na melhoria dos vários componentes do sistema.
O EDI facilitou a segurança, velocidade, eficácia e precisão no envio dos documentos de negócio entre os parceiros de negócio. Quem utiliza este sistema atualmente tem imediatamente uma vantagem competitiva, pois o processo de negócio fica otimizado, bem como toda a cadeia logística.
As únicas desvantagens deste tipo de sistema são mesmo o elevado custo que implica a sua implementação e a complexidade de manipulação e resolução de problemas. Apenas a partir de um número elevado de documentos é que se torna vantajoso o uso do EDI nas empresas. No entanto, mesmo com essas desvantagens, o sistema de troca de dados eletrónica tem, em perspetiva, um futuro brilhante.
26
Os negócios são cada vez mais feitos por via eletrónica, o que faria do sistema EDI e das suas vertentes (p.e. WEB-EDI) um sistema muito popular para efetuar as diversas operações de encomenda, compra, pagamento, etc. De forma similar, as suas limitações e desvantagens começariam a desvanecer devido ao crescente uso da tecnologia.
27
3
3. Tecnologias de Integração
A agregação de dados e a integração estão atualmente a tornar-se num dos maiores problemas na área de sistemas de informação. A tomada de decisões empresariais nas aquisições e fusões torna a integração fundamental para garantir a correta expansão da empresa. Como por vezes a informação, quando apresentada de outra forma, pode criar nova informação, o problema consiste em assegurar que a grande quantidade de informação, que é recolhida pelos diferentes sistemas, possa ser usada de forma a ser agregada e a dar significância à mesma. Por várias razões, atualmente, muitas empresas usam apenas um pequeno fragmento da informação retida e recolhida pelos seus sistemas. Nestas razões estão a dificuldade em criar interoperabilidade entre diversos sistemas e a complexidade em combinar fontes de dados diferentes num todo (Chorafas, 2001).
Os fabricantes de software das diversas áreas de atuação não facilitam a integração com outros sistemas. Isto observa-se em diversos aspetos (Chappell, 2009):
Falta de documentação;
Construção de software num único bloco;
Uso de designações sem sentido (variáveis, tabelas, bases de dados, colunas);
Falta de webservices para estender a funcionalidade;
Bases de dados fechadas (sem permissão);
Falta de API’s (Application Programming Interface);
Entre outros.
O objetivo de criar estes impasses é a venda de produtos dessas mesmas empresas, ou parceiros certificados, pois segundo eles são os únicos que garantem a integridade e a correta utilização dos dados. No entanto, essas soluções nem sempre se adequam na totalidade à
28
empresa e às suas necessidades. Daí surge a inevitável necessidade de desenvolver soluções à medida e que se adequem a cada caso (Chappell, 2009).
A IEEE Standard Computer Dictionary define a integração como sendo “o processo de combinar componentes de software, componentes de hardware, ou ambos num sistema global” (IEEE, 1991). Trata-se de colocar aplicações a trabalhar em conjunto que nunca antes foram intencionadas a fazê-lo. Vários departamentos na mesma empresa podem precisar de ter acesso à mesma informação, mas não ter acesso aos mesmos sistemas. Como consequência, a informação pode ser armazenada em diversos sistemas com o risco de ter dados inconsistentes. Se estes sistemas não forem corretamente integrados, os riscos de ter processos de negócios incorretos e os custos em reconciliar os dados são elevados.
Os sistemas de ERP são já uma tentativa dos fabricantes de software conseguirem integrar informação de diversos departamentos numa só aplicação. Mas, mesmo com todo o esforço, nem sempre é possível encontrar as necessidades de todos os departamentos e as especificidades dentro de cada empresa, provocando, diversas vezes, uma adaptação da empresa ao software existente em vez de ser o software a adaptar-se à empresa.
3.1. Arquitetura de integração
Em termos de arquitetura de integração há duas grandes formas de o fazer. Veja-se a Figura 7 e a Figura 8.
Figura 7 - Arquitetura 1 para 1 (Rognerud & Hannay, 2009)
Sistema B
Sistema C
Sistema D Sistema A
29
Figura 8 - Arquitetura com bus integração (Rognerud & Hannay, 2009)
3.1.1. Um para um
Nas ligações um-para-um (Figura 7) todos os sistemas estão ligados entre si partilhando a informação diretamente com o sistema que as necessite. No outro caso, é utilizado um intermediário no qual todos os sistemas estão ligados. Nas ligações um para um, a comunicação entre duas aplicações é geralmente feita com ficheiros partilhados. Antes da comunicação, ambos acordam o formato de ficheiro, localização e sistemas de locking. Atualmente, o XML é considerado o formato por defeito para a integração a nível de partilha de ficheiros (Schaefer, 2008).
O uso mais comum é a integração um-para-um pois, desta forma, o programador não necessita de ter um conhecimento tão profundo sobre cada um dos sistemas. Existem no total n2 ligações (n = número de sistemas). A partilha de ficheiro também permite que as aplicações sejam alteradas livremente desde que continuem a produzir um ficheiro consistente nos formatos estabelecidos. Assim, existe uma integração com pouca dependência. Por outro lado, um grande problema na prática acontece quando os dados não estão atualizados, fazendo com que seja necessária uma correta administração dos ficheiros, pois se uma aplicação tentar ler dados quando a outra ainda não atualizou o ficheiro, haverá leitura e processamento de dados obsoletos. Desta forma é necessário definir, por exemplo, intervalos de tempo para leitura e escrita de forma a manter os dados corretos em ambos os sistemas (Rognerud & Hannay, 2009).
3.1.2. BUS integração
A outra forma de integração é desenvolver um intermediário (integration bus) ao qual todos os sistemas estarão ligados (Figura 8). Estes apenas comunicam com o bus, que terá a
Sistema B
Sistema C
Sistema D Sistema A
30
responsabilidade de garantir a entrega da mensagem e o seu correto formato ao sistema destinatário.
Usar um bus de integração traz vantagens ao nível dos ficheiros, pois nunca são usados dados obsoletos, já que os dados são aqui obtidos logo que requisitados. É utilizada por parte dos sistemas o “push” e “pull” da informação. Outra vantagem é o facto de os sistemas continuarem a trabalhar de forma independente entre eles, sendo que a única dependência é o bus. Uma grande desvantagem desta arquitetura acontece quando o bus está offline, pois todos os sistemas ficam sem ligação a ele. Há também custos associados ao alojamento de recursos para este tipo de integração, pois o bus terá de suportar todos os outros sistemas. No entanto, este tipo de arquitetura está em crescimento nas empresas.
3.2. Base de Dados
Outra forma de efetuar integração é ao nível das bases de dados. Há diversas abordagens a este nível, por exemplo, a arquitetura multibase de dados (MDBS, Multi-DataBase System), base de dados intermédia e base de dados partilhada. A integração com bases de dados é bastante usada pois não são necessárias aplicações externas para tratar os dados, mas antes acessos diretos (Shankar, Kini, DeWitt, & Naughton, 2005).
Dentro da Sousacamp para o projeto do sistema de EDI interno foi optada por usar esta abordagem de acesso à base de dados, mais especificamente, acesso partilhado/direto. Esta forma de integração traz vantagens e desvantagens que serão explicadas mais à frente na proposta.
3.2.1. Arquitetura Multibase de dados
O MDBS é uma coleção de bases de dados interligadas de forma a partilhar os dados. O grande problema desta arquitetura é conseguir determinar o nível de integração e os respetivos dados para que se crie uma vista global coerente. Esta forma exige um elevado conhecimento de todas as bases de dados interligadas, pois não existe nenhum processo 100% automatizado para criar os esquemas (estes são a combinação dos diversos esquemas das bases de dados). Tal como na construção de Data Warehouses (DW), estas têm de conciliar todos os conflitos que possam existir em termos estruturais e semânticos. Existem várias metodologias na construção de esquemas e semânticas para a MDBS que são discutidas em (Lawrence, 1999). A vantagem na utilização deste tipo de abordagem é um único ponto de acesso aos sistemas
31
para obter dados, partilhar dados, entre outros, pois cada sistema pode continuar a ter a sua base de dados, mas que faz parte de um sistema maior. A arquitetura tem na sua constituição um gestor global de transações (GTM, Global Transaction Manager), que trata da execução de Transações Globais (GT’s, Global Transactions). Este é responsável por dividir as transações em subtransações (ST’s) para efetuar a submissão nas bases de dados locais (LDBS’s, local database systems). Cada LDBS tem associado um servidor global de transações (GTS, Global Transaction Server), que trata de converter as subtransações vindas do GTM num formato usável pelo LDBS de cada sistema. A Figura 9 demonstra toda a arquitetura.
Figura 9 - Arquitetura de MDBS (Lawrence, 1999)
As transações que não estejam sobre o controlo do GTM são permitidas em cada LDBS, como se o LDBS não estivesse a participar no MDBS.
3.2.2. Base de dados partilhada
A arquitetura de base de dados partilhada é o uso da mesma base de dados por parte de vários sistemas. Em muitos casos trata-se de uma base de dados já existente (BD de uma ERP) na qual são adicionados outros sistemas que vão consumir e editar diretamente os dados. Esta forma pode ser vista como engenharia inversa, pois para implementar tal arquitetura é necessário analisar a base de dados, esquemas, semântica, etc., para poder efetuar a integração a este nível, já que raras vezes são documentadas as organizações existentes nas bases de dados.
GTM GTS GTS GTS GTS LDBS LDBS LDBS LDBS Transações locais . . . . . Transações globais subtransações
