Otimização da integração de sistemas em um operador logístico internacional: um estudo de caso

Universidade do Minho Escola de Engenharia Pedro Henrique Maia da Fonseca Otimização da Integração de Sistemas em um Operador Logístico Internacional: Um Estudo de Caso Março de 2025 Universidade do Minho Escola de Engenharia Pedro Henrique Maia da Fonseca Otimização da Integração de Sistemas em um Operador Logístico Internacional: Um Estudo de Caso Dissertação de Mestrado em Engenharia e Gestão Industrial Trabalho efetuado sob a orientação do Professor Doutor José Pedro Domingues Teixeira Professor Doutor Nélson Bruno Martins Maques Costa Março de 2025 ii “ Se a vida não me abrir as portas, eu viro chaveiro E se essa não for minha hora, eu altero os ponteiros E se o sol não nasce pra todos, eu acordo mais cedo ” CHS iii DIREITOS DE AUTOR E CONDIÇÕES DE UTILIZAÇÃO DO TRABALHO POR TERCEIROS Este é um trabalho académico que pode ser utilizado por terceiros desde que respeitadas as regras e boas práticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licença abaixo indicada. Caso o utilizador necessite de permissão para poder fazer um uso do trabalho em condições não previstas no licenciamento indicado, deverá contactar o autor, através do RepositóriUM da Universidade do Minho. Licença concedida aos utilizadores deste trabalho Atribuição CC BY https://creativecommons.org/licenses/by/4.0/ iv AGRADECIMENTOS A conclusão desta dissertação marca o fim de um percurso desafiante, repleto de aprendizagens e crescimento. Este trabalho não teria sido possível sem o apoio de várias pessoas e instituições, às quais expresso a minha mais sincera gratidão. Em primeiro lugar, agradeço à Universidade do Minho, pela formação académica de excelência e pelo ambiente de estímulo intelectual que proporcionou ao longo desta jornada. Um agradecimento especial aos meus orientadores, Prof. José Pedro e Prof. Nélson, pelo acompanhamento e pelas orientações ao longo do desenvolvimento desta dissertação. Agradeço também à Rangel pela oportunidade de desenvolver este estudo. Deixo um reconhecimento especial ao meu orientador na empresa, Hélder, e a todos os membros da equipa de Corporate IT e do DSI, cujo apoio e disponibilidade foram fundamentais para o sucesso desta investigação, tornando a minha experiência na empresa mais enriquecedora. Gostaria de expressar um profundo agradecimento à Laurinha, pelo apoio incondicional e pelas palavras de incentivo que, por vezes duras, foram sempre necessárias. A tua amizade, desde o primeiro dia da universidade, tornou todo este percurso mais leve e divertido. Ao Maré, pela amizade, companheirismo e por toda a ajuda ao longo do nosso estágio e desta dissertação, especialmente nas nossas tardes no Nova Arcada, onde, entre conversas, escutaste pacientemente as minhas ideias e contribuíste de forma crucial, principalmente na formatação do trabalho. Aos meus amigos, que, de diversas formas, tornaram esta jornada mais motivadora e tiveram a paciência gentil de me ouvir falar interminavelmente sobre a minha dissertação. E cada um do seu jeito através de palavras de encorajamento, momentos de descontração ou simplesmente pela presença, fizeram de tudo para que eu conseguisse concluir o desafio dessa dissertação. Agradeço também à família que a Praxe me deu, que me acompanhou ao longo de toda a minha vida académica e fez com que a minha integração em terras estrangeiras ocorresse da melhor forma possível. Por fim, expresso a minha mais profunda gratidão ao meu Pai, a minha Mãe e aos meus irmãos, pelo amor incondicional, pelo apoio constante em todas as fases da minha vida e pelo incentivo incansável para que eu perseguisse os meus sonhos. Sem o vosso suporte, esta caminhada teria sido imensamente mais difícil, para não dizer impossível. v A minha querida namorada, pelo carinho, paciência e compreensão nos momentos mais exigentes. Sem você, terminar esta dissertação teria sido um desafio ainda maior. Obrigado por me motivares sempre a seguir em frente. A todos, o meu muito obrigado! vi DECLARAÇÃO DE INTEGRIDADE Declaro ter atuado com integridade na elaboração do presente trabalho académico e confirmo que não recorri à prática de plágio nem a qualquer forma de utilização indevida ou falsificação de informações ou resultados em nenhuma das etapas conducente à sua elaboração. Mais declaro que conheço e que respeitei o Código de Conduta Ética da Universidade do Minho. vii OTIMIZAÇÃO DA INTEGRAÇÃO DE SISTEMAS EM UM OPERADOR LOGÍSTICO INTERNACIONAL: UM ESTUDO DE CASO RESUMO A presente dissertação explora oportunidades de otimização na integração de sistemas empresariais em um operador logístico internacional, com foco na reestruturação das interações entre os sistemas de gestão utilizados. O estudo centrou-se na modernização desses processos, promovendo melhorias na governança de dados, eficiência operacional e escalabilidade das integrações tecnológicas. Para alcançar esses objetivos, foi desenvolvida uma proposta de arquitetura funcional que substitui práticas tradicionais por abordagens mais robustas e alinhadas às melhores práticas do setor. A proposta contempla o uso da camada de aplicação nativa em conjunto com o middleware para garantir maior segurança e rastreabilidade, a definição de novas validações para fortalecer a qualidade dos dados e a adoção de processamento síncrono entre sistemas para assegurar maior confiabilidade na troca de informações. A análise detalhada dos processos de integração permitiu identificar oportunidades de otimização, culminando na formulação de um modelo mais eficiente e resiliente. Espera-se que, ao adotar essa abordagem, seja possível reduzir intervenções manuais, minimizar falhas operacionais e estabelecer uma base tecnológica mais sólida para futuras expansões e inovações. Embora os resultados sejam teóricos, a avaliação qualitativa da proposta indica benefícios potenciais significativos, como a redução do esforço técnico na resolução de falhas, a melhoria da consistência dos dados e o fortalecimento da governança dos sistemas. Complementarmente, este trabalho contribui para a literatura acadêmica ao explorar a integração de sistemas no setor logístico, um tema ainda pouco aprofundado em comparação com outras indústrias. Com a otimização das integrações e a adoção de práticas tecnológicas mais avançadas, esta dissertação oferece um referencial estruturado para futuras implementações, sugerindo estudos adicionais sobre a viabilidade técnica e econômica da proposta e sua adaptação a diferentes contextos organizacionais e geográficos. PALAVRAS-CHAVE: ERP, Governança de Dados, Integração de Sistemas, Logística, SAP viii OPTIMIZATION OF SYSTEM INTEGRATION IN AN INTERNATIONAL LOGISTICS OPERATOR: A CASE STUDY ABSTRACT This dissertation explores opportunities for optimizing system integration in an international logistics operator, focusing on the restructuring of interactions among the management systems in use. The study centers on modernizing these processes, promoting improvements in data governance, operational efficiency, and the scalability of technological integrations. To achieve these objectives, a functional architecture proposal was developed, replacing traditional practices with more robust approaches aligned with industry’s best practices. The proposal includes the use of the native application layer alongside middleware to enhance security and traceability, the establishment of new validation mechanisms to strengthen data quality, and the adoption of synchronous processing between systems to ensure greater reliability in information exchange. A detailed analysis of integration processes allowed the identification of optimization opportunities, culminating in the formulation of a more efficient and resilient model. By adopting this approach, it is expected to reduce manual interventions, minimize operational failures, and establish a more solid technological foundation for future expansions and innovations. Although the results are theoretical, a qualitative assessment of the proposal suggests significant potential benefits, such as reduced technical effort in troubleshooting, improved data consistency, and strengthened system governance. Additionally, this study contributes to academic literature by exploring system integration in the logistics sector, a topic still underexplored compared to other industries. By optimizing integrations and adopting more advanced technological practices, this dissertation provides a structured reference for future implementations, suggesting further studies on the technical and economic feasibility of the proposal and its adaptation to different organizational and geographical contexts. KEYWORDS Data Governance, ERP, Logistics, SAP, System Integration xv ÍNDICE DE TABELAS Tabela 1 - Fases do Action Research no Projeto .................................................................................. 5 Tabela 2 - Fases do Ciclo de Vida do BPM ......................................................................................... 21 Tabela 3 - Etapas do Modelo de Escrita Direta na Base de Dados ...................................................... 46 Tabela 4 - Continuação - Etapas do Modelo de Escrita Direta na Base de Dados ................................ 47 Tabela 5 - Etapas do Modelo de Escrita Através da Camada de Aplicação .......................................... 51 Tabela 6 - Continuação - Etapas do Modelo de Escrita Através da Camada de Integração................... 52 Tabela 7 - Integrações tipo Configuração ........................................................................................... 58 Tabela 8 - Integrações Tipo Processo de Negócio .............................................................................. 59 Tabela 9 - Use Cases As-Is ................................................................................................................ 80 Tabela 10 - Cenários que Devem Ser Abrangidos .............................................................................. 83 Tabela 11 - Países Que Utilizam o NIF Como Identificador Fiscal ....................................................... 85 Tabela 12 - Países Onde o Grupo Possui Unidades de Negócio .......................................................... 85 Tabela 13 - Use Cases To-Be .......................................................................................................... 102 Tabela 14 - Ganhos Esperados ....................................................................................................... 107 Tabela 15 - Continuação Ganhos Esperados ................................................................................... 108 Tabela 16 - Propostas de KPIs ........................................................................................................ 113 xvi LISTA DE ABREVIATURAS, SIGLAS E ACRÓNIMOS 3PL -- Third-Party Logistics ABAP -- Advanced Business Application Programming API -- Application Programming Interface APS -- Advanced Planning and Scheduling BI -- Business Intelligence BPD -- Business Process Diagrams BPM -- Business Process Management BPMN -- Business Process Model and Notation CNPJ -- Cadastro Nacional de Pessoa Jurídica CPF -- Cadastro de Pessoa Física CRM -- Customer Relationship Management DAF -- Departamento Administrativo e Financeiro DSI -- Departamento de Sistemas da Informação EAI -- Enterprise Application Integration ERDO -- Eduardo Rangel Despachante Oficial ERP -- Enterprise Resource Planning ERP II -- Extended Enterprise Resource Planning ESB -- Enterprise Service Bus FI -- Financial Accounting iPaaS -- Integration Platform as a Service IoT -- Internet of Things KPI -- Key Performance Indicator xvii LSP -- Logistic Service Provider MDM -- Master Data Management MIS -- Management Information Systems MM -- Materials Management MRP -- Material Requirements Planning MRP II -- Manufacturing Resource Planning NIF -- Número Identificador Fiscal OMG -- Object Management Group PP -- Production Planning RFC -- Registro Federal de Contribuintes RDL -- Rangel Distribuição e Logística RIAM -- Rangel Internacional Aéreo e Marítimo RPA -- Robotic Process Automation RT -- Rangel Transitários SAP -- System Applications and Products SCM -- Supply Chain Management SD -- Sales and Distribution SI -- Sistemas de Informação TIBCO -- The Information Bus Company TI -- Tecnologias da Informação TMS -- Transportation Management System TSI -- Tecnologias e Sistemas de Informação WMS -- Warehouse Management Systems 1 1. INTRODUÇÃO O Capítulo Um apresenta o enquadramento da dissertação intitulada " Otimização da Integração de Sistemas em um Operador Logístico Internacional: Um Estudo de Caso ", desenvolvida no âmbito do estágio curricular do segundo ano do Mestrado em Engenharia e Gestão Industrial. Inicialmente, são definidos os objetivos da investigação, destacando sua relevância para a modernização da gestão de sistemas empresariais no setor logístico. Em seguida, descreve-se a metodologia adotada para a condução do estudo, detalhando a abordagem utilizada na análise e formulação da proposta de otimização. Por fim, é apresentada a estrutura do documento, proporcionando uma visão geral dos capítulos que compõem a dissertação e da forma como os temas foram organizados ao longo do trabalho. 1.1 Enquadramento No cenário competitivo atual, as grandes corporações enfrentam desafios constantes para evoluir seus processos e tecnologias, garantindo eficiência operacional e inovação. Para manterem sua posição no mercado global, essas organizações precisam lidar com obstáculos internos e externos, que vão desde a complexidade dos seus próprios sistemas até à adaptação a diferentes contextos regulatórios e culturais. No setor logístico, essas dificuldades tornam-se ainda mais evidentes. Operadores logísticos internacionais, como o Grupo Rangel, que contam com várias empresas dentro do grupo, cada uma com sistemas de gestão específicos às suas realidades operacionais, enfrentam o desafio adicional de garantir a comunicação eficiente entre essas plataformas heterogêneas. Além disso, precisam gerir uma ampla gama de serviços e manter uma presença global, o que exige a integração de operações em diversas regiões, cada uma com suas especificidades normativas, culturais e tecnológicas. A necessidade de alinhar sistemas organizacionais e informáticos a esse ambiente dinâmico intensifica os desafios associados à transformação digital e à interoperabilidade entre plataformas, demandando soluções que promovam a padronização dos processos sem comprometer a flexibilidade necessária para atender às exigências locais. Um dos principais fatores críticos nesse contexto é a integração eficiente dos sistemas de informação, especialmente dos Enterprise Resource Planning - ERP, que desempenham um papel essencial na gestão de processos operacionais, recursos humanos, conformidade legal e demais 2 funções empresariais. Em empresas multinacionais como a Rangel, que operam com múltiplas unidades de negócio e prestam serviços entre si, garantir a fluidez da troca de informações e a compatibilidade entre diferentes sistemas é essencial para manter a eficiência e a confiabilidade das operações. Além disso, algumas dessas integrações envolvem sistemas sujeitos a regulamentações específicas de cada país, tornando o desenvolvimento de soluções personalizadas indispensável para assegurar conformidade e desempenho adequados. Diante desse cenário, aprimorar as integrações entre os sistemas de informação torna-se um fator estratégico para a competitividade global. Uma arquitetura tecnológica robusta e bem estruturada possibilita uma operação mais ágil, resiliente e adaptável às exigências de cada região onde a empresa atua. Assim, a modernização dessas integrações não apenas melhora a eficiência interna, mas também fortalece a capacidade da organização de atender às demandas do mercado global em constante transformação. 1.2 Objetivos O principal objetivo desta dissertação é revisar as integrações de dados entre os sistemas de gestão existentes em um operador logístico internacional, propondo uma nova arquitetura funcional que melhore a eficiência, a governança da informação e a escalabilidade dos sistemas. O estudo inclui um levantamento detalhado das integrações atuais As-Is , a identificação de oportunidades de melhoria e a formulação de uma solução funcional idealizada To-Be , que poderá orientar futuras implementações técnicas. Para atingir esse objetivo, foram definidos os seguintes objetivos específicos: • Analisar as integrações atuais entre os sistemas empresariais, identificando limitações e pontos críticos. • Propor uma nova arquitetura funcional To-Be para otimizar a comunicação entre os sistemas e fortalecer a governança de dados. • Estruturar uma abordagem de integração mais robusta, resiliente e sincronizada, reduzindo dependências de intervenções manuais. • Desenvolver um modelo padronizado de integração de sistemas empresariais, com potencial de replicação em diferentes geografias. • Criar diretrizes para futuras implementações tecnológicas, possibilitando uma configuração mais ágil e eficiente de novos sistemas. 3 Com a concretização desses objetivos, espera-se alcançar os seguintes resultados: ➢ Desenvolvimento de uma base de conhecimento e documentação estruturada para apoiar futuras melhorias no processo de integração. ➢ Definição de uma arquitetura funcional mais eficiente e resiliente, alinhada às melhores práticas de integração de sistemas empresariais. ➢ Redução de falhas e aumento da eficiência na monitorização e manutenção das integrações. ➢ Melhoria na comunicação entre sistemas em diferentes geografias, facilitando a escalabilidade e a expansão das operações. ➢ Contribuição para a literatura acadêmica sobre integrações de sistemas de informação no setor logístico, um tema ainda pouco explorado em comparação com outras indústrias. 1.3 Justificativa de Investigação A adoção de sistemas de gestão empresariais integrados tem se consolidado como um pilar essencial para a competitividade no setor logístico, permitindo maior eficiência operacional e embasando a tomada de decisões com dados confiáveis. No entanto, a integração entre esses sistemas ainda representa um desafio significativo, exigindo não apenas a adaptação de processos internos, mas também a interoperabilidade com diferentes plataformas e uma gestão eficaz das mudanças organizacionais. Nesse contexto, a investigação sobre a otimização das integrações em um operador logístico internacional justifica-se tanto pela sua relevância prática quanto pela necessidade de aprofundar a compreensão dos impactos e das melhores estratégias para implementação desses sistemas. A complexidade das operações logísticas, somada à diversidade de tecnologias utilizadas, torna a integração entre sistemas um fator crítico para garantir visibilidade operacional, fortalecer o controle financeiro e otimizar a gestão de recursos. Dessa forma, analisar as estratégias adotadas e os desafios enfrentados pode gerar insights valiosos para outras empresas do setor que lidam com cenários semelhantes. Além da contribuição prática, esta dissertação busca preencher uma lacuna relevante na literatura acadêmica. Grande parte dos estudos sobre integração de sistemas concentra-se em setores como manufatura e varejo, enquanto a logística, apesar da sua crescente importância global, ainda recebe pouca atenção nesse âmbito. Assim, este trabalho não apenas aprofunda a discussão teórica 4 sobre o tema, mas também propõe diretrizes aplicáveis à realidade do setor logístico, oferecendo uma abordagem que alia fundamentação científica e aplicabilidade prática. 1.4 Metodologia de Investigação Este projeto de investigação será realizado no contexto empresarial da Rangel, com o objetivo de revisar e propor melhorias no processo de integração entre os sistemas ERP e Transportation Management System - TMS da organização. A necessidade desta investigação surge devido aos desafios enfrentados na gestão eficiente dos fluxos de dados entre esses sistemas, impactando a qualidade da informação, a eficiência operacional e a rastreabilidade dos processos logísticos. A metodologia adotada neste estudo baseia-se na abordagem de Action Research , conforme definida por Saunders et al. (2023). Esta estratégia é particularmente adequada para a realidade da empresa, pois combina investigação científica com a resolução de problemas organizacionais, permitindo que o investigador participe ativamente do contexto estudado. A Action Research caracteriza-se pelo envolvimento direto do investigador com a organização e seus colaboradores, promovendo um ambiente colaborativo que visa a implementação de mudanças e melhorias contínuas (O’Brien et al., 2022). De acordo com Coughlan & Coghlan (2002), esta abordagem envolve dois paradigmas fundamentais: tomar medidas concretas para resolver problemas identificados e, simultaneamente, gerar conhecimento sobre essas ações. Dessa forma, o estudo não se limita à observação passiva dos processos, mas busca intervir na realidade organizacional, testar soluções e documentar os impactos resultantes das mudanças implementadas. A escolha desta metodologia justifica-se pela sua capacidade de proporcionar resultados práticos para a empresa, enquanto contribui para o avanço do conhecimento na área de integração de sistemas empresariais. O processo investigativo adotado para este estudo foi estruturado em cinco fases sequenciais, seguindo o ciclo iterativo proposto por O’Brien et al. (2022), apresentado na Figura 1 Essas etapas foram adaptadas à realidade da Rangel e às particularidades da integração entre o ERP e o TMS, garantindo que as atividades fossem conduzidas de maneira sistemática e alinhadas com os objetivos estratégicos da organização. As fases da investigação estão descritas detalhadamente na Tabela 1 onde são especificadas as atividades realizadas em cada etapa do estudo. 5 Tabela 1 - Fases do Action Research no Projeto Dessa forma, a metodologia adotada permite um equilíbrio entre teoria e prática, assegurando que as soluções propostas sejam embasadas em evidências empíricas e tenham aplicabilidade real no ambiente organizacional. Além disso, a abordagem iterativa possibilita ajustes contínuos ao longo do projeto, garantindo que as estratégias implementadas estejam alinhadas com as necessidades e desafios enfrentados pela organização. Fase: Descrição 1. Diagnóstico Esta fase consistiu em uma análise crítica e avaliação do estado atual das integrações. A avaliação foi apoiada pela análise dos dados da plataforma Helpdesk e das integrações existentes, utilizando ferramentas e técnicas específicas para identificar limitações e áreas passíveis de melhoria. 2. Planejamento das Ações Com base nas oportunidades de melhoria identificadas na fase de diagnóstico, foi elaborado um plano de ações detalhado. Este plano incluiu a organização de um projeto piloto, orientado para resolver os problemas diagnosticados e otimizar as integrações existentes. 3. Implementação das Ações Durante esta fase, as ações delineadas no plano foram executadas. A implementação envolveu levantamentos das integrações, requisitos funcionais e a arquitetura futura, sendo conduzida de forma a garantir a efetiva integração dos sistemas e a introdução das melhorias propostas. 4. Avaliação dos Resultados Após a implementação das ações, foi realizada uma análise crítica dos resultados alcançados. A comparação entre o estado inicial e o estado desejado da arquitetura de integração permitiu avaliar a eficácia das intervenções realizadas, identificando as lacunas restantes e as áreas de sucesso. 5. Especificação da Aprendizagem Esta fase envolveu a identificação das descobertas e conclusões gerais do estudo. A documentação detalhada do processo permitiu não apenas a continuidade do trabalho, mas também a aplicação dos resultados obtidos em futuros projetos e contextos semelhantes. 6 Adicionalmente, uma revisão da literatura foi conduzida inicialmente para contextualizar o estudo e aprofundar o conhecimento sobre as temáticas relacionadas com as integrações de sistemas ERP. A análise e documentação contínua ao longo do projeto garantiram a integração e aplicação dos conhecimentos adquiridos, estabelecendo uma base sólida para futuras investigações e desenvolvimentos na área. 1.5 Resultados Esperados Este estudo tem como principal expectativa a documentação detalhada da arquitetura de integração atual As-Is , bem como a definição de lógicas e fluxos para uma proposta de arquitetura funcional futura To-Be . Especial atenção foi dada ao processo de criação de clientes, por sua relevância estratégica como base para diversos outros processos de negócio, sendo essencial para garantir eficiência operacional e uma gestão de dados precisa e confiável. Diante das limitações de tempo impostas ao projeto, a investigação concentrou-se na análise e estruturação detalhada da arquitetura vigente, fornecendo uma base sólida para futuras melhorias. Espera-se que, ao final do trabalho, seja possível propor um modelo de integração mais eficiente, capaz de atender aos requisitos técnicos fundamentais, como a adoção de práticas de Master Data Management - MDM e a implementação de um sincronismo eficaz de dados entre os sistemas. Outro resultado esperado é a obtenção de um entendimento mais claro e um alinhamento estratégico sólido do estado atual das integrações, incluindo a formalização de definições de governança Figura 1 - Fases do Action Research (O’Brien et al., 2022) 7 e a padronização das lógicas de integração. No caso específico do processo de criação de clientes, a proposta busca torná-lo mais estruturado e sincronizado, minimizando falhas operacionais, como erros manuais, e assegurando que as informações sejam centralizadas, validadas e mantidas de forma consistente dentro do sistema empresarial. Além disso, a integração com o sistema de gestão de transportes foi projetada para seguir os princípios da arquitetura funcional estabelecida, garantindo maior confiabilidade e alinhamento com as melhores práticas de mercado. 1.6 Estrutura da Dissertação Esta dissertação está organizada em oito capítulos, estruturados de forma a proporcionar uma visão clara e progressiva sobre a otimização das integrações de sistemas em um operador logístico internacional. O Capítulo Um, Introdução, estabelece o contexto do estudo, apresentando os objetivos da dissertação, a justificativa da investigação, a metodologia adotada e a estrutura do documento. Esse capítulo serve como base para os temas explorados ao longo da pesquisa. No Capítulo Dois, Revisão Bibliográfica, são discutidos os principais conceitos e teorias relacionados com a integração de sistemas empresariais, fornecendo o suporte teórico necessário para o desenvolvimento do estudo. São abordados os desafios da interoperabilidade entre sistemas, as melhores práticas identificadas na literatura e a evolução das arquiteturas de integração. O Capítulo Três, Apresentação da Empresa, contextualiza a organização onde o estudo foi realizado, descrevendo sua história, missão, valores e estrutura organizacional. Além disso, apresenta uma visão geral dos processos de integração existentes, auxiliando no entendimento do ambiente operacional e estratégico da empresa. No Capítulo Quatro, Análise da Situação Atual das Integrações, examina-se o estado atual das integrações entre os sistemas da empresa, identificando desafios, limitações e oportunidades de melhoria. São analisados os principais problemas enfrentados e suas implicações operacionais, fornecendo a base para a formulação da proposta de reestruturação. O Capítulo Cinco, Revisão das Integrações, apresenta o projeto-piloto " Re-think ERP Integrations RIAM ", que tem como objetivo aprimorar as integrações entre os sistemas ERP e TMS da organização. O capítulo descreve as etapas do projeto, incluindo o mapeamento das integrações atuais As-Is e, por fim, aborda o alinhamento estratégico necessário para a implementação das melhorias propostas. 14 O ERP II trouxe avanços significativos na gestão estratégica das empresas, incorporando novos módulos, como SCM, CRM, Business Intelligence - BI e Advanced Planning and Scheduling - APS. Com a evolução das tecnologias, surge em 2010 o conceito de ERP III, que representa o modelo atualmente utilizado e em constante desenvolvimento (Costa, 2022). Esta nova geração de sistemas reforça a conectividade digital e a integração com plataformas externas, promovendo uma visão global e mais eficiente das operações empresariais. A seguir, a Figura 2 ilustra uma visão geral da estrutura dos sistemas ERP. Figura 2 - Estrutura dos Sistemas ERP (Slack & Brandon-Jones, 2021) Os sistemas ERP operam a partir de uma base de dados centralizada, que coleta, processa e disponibiliza informações para os diversos módulos que compõem a solução, garantindo suporte integral às operações da empresa. Essa estrutura integrada permite que, à medida que novos dados são inseridos no sistema, todas as informações correlacionadas sejam atualizadas automaticamente. Esse mecanismo acelera a execução dos processos, proporciona maior controle sobre as operações e confere mais agilidade à tomada de decisão, tornando as empresas mais responsivas e eficientes (Davenport, 1998; Klaus et al., 2000). Além de consolidar e otimizar a gestão interna, os ERP possuem a capacidade de se integrar com outras soluções tecnológicas, ampliando a eficiência dos processos organizacionais e aprimorando a experiência do cliente. A flexibilidade desses sistemas possibilita a sua conexão com diferentes plataformas de software por meio de APIs e conectores personalizados. Adicionalmente, aborda- 15 gens como Enterprise Service Bus - ESB e Integration Platform as a Service - iPaaS são amplamente utilizadas para fortalecer a interoperabilidade entre sistemas empresariais, garantindo um fluxo contínuo e consistente de informações (SAP, 2025b). Em suma, a evolução dos ERP reflete a crescente necessidade das organizações de integrarem os seus processos de forma eficiente e estratégica. Com a contínua modernização dessas soluções, os ERP desempenham um papel central na transformação digital das empresas, permitindo uma gestão mais ágil, automatizada e orientada a dados. 2.3.2 Sistemas de Gestão de Transportes: Funcionalidades e Impactos Operacionais Os sistemas de gestão de transporte Transportation Management System desempenham um papel essencial na otimização das operações logísticas, proporcionando maior eficiência no planejamento e execução das atividades relacionadas ao transporte de mercadorias. Essas soluções tecnológicas permitem uma gestão mais precisa e integrada das operações, oferecendo funcionalidades como monitorização em tempo real, roteirização otimizada, alocação eficiente de recursos e controle de custos de frete. Além disso, um TMS possibilita uma maior visibilidade da cadeia de transporte, facilitando a tomada de decisões estratégicas e garantindo o cumprimento dos prazos estabelecidos (Paksoy et al., 2021). De acordo com os mesmos autores, um TMS permite rastrear os veículos com elevada precisão, monitorizar a movimentação de mercadorias e consolidar envios, maximizando a ocupação dos veículos e otimizando os custos logísticos. Além disso, essas ferramentas digitais proporcionam maior controle sobre as negociações com transportadores, garantindo uma gestão mais eficaz das rotas e do planeamento operacional. A implementação desse tipo de tecnologia nas operações logísticas reduz não apenas os custos operacionais, mas também melhora a agilidade e a confiabilidade dos processos, minimizando atrasos e promovendo um fluxo de trabalho mais eficiente (Laeequddin et al., 2012). A adoção de um TMS contribui diretamente para o aumento da produtividade dos modais de transporte utilizados pelas empresas. Segundo De Castro (2013),um dos principais benefícios desse sistema é a capacidade de planeamento detalhado da alocação de cargas dentro dos veículos, otimizando o uso do espaço disponível e reduzindo desperdícios. O TMS também permite sincronizar os processos de carga e descarga entre diferentes instalações, impactando diretamente a redução de custos com transporte e aprimorando a eficiência operacional. 16 O planeamento logístico eficiente é um desafio complexo, pois envolve múltiplas variáveis interligadas, como roteirização, alocação de frotas, gestão de motoristas, segurança, restrições de trânsito e economia de combustível. Nesse contexto, a implementação de um TMS torna-se fundamental para integrar esses fatores e garantir uma operação eficiente e competitiva (Goettems et al., 2019). Essa tecnologia proporciona benefícios como a redução do tempo de espera dos motoristas nos pontos de carregamento, otimização da consolidação de cargas, rastreamento detalhado dos custos de transporte e monitoramento em tempo real da performance operacional. Além disso, a centralização de informações e a disponibilidade de indicadores de desempenho favorecem uma tomada de decisão mais informada, garantindo maior previsibilidade e segurança nas operações logísticas. Os desafios logísticos enfrentados pelas empresas de transporte incluem tempos excessivos de carga e descarga, dificuldades na roteirização e monitoramento de veículos, bem como falhas na confirmação de entregas (Franco, 2012). A tecnologia desempenha um papel central na mitigação desses problemas, permitindo que a informação sobre o status das entregas seja inserida no sistema imediatamente após a conclusão do serviço, garantindo maior confiabilidade no fluxo de dados (Camargo et al., 2013). A avaliação da eficácia de um TMS deve considerar atributos essenciais como confiabilidade, tempo de resposta e conformidade com regulamentações legais. Em um ambiente dinâmico e de alta demanda, a confiabilidade do sistema é fundamental para manter um fluxo operacional contínuo e atender às exigências de clientes que dependem do transporte ágil e eficiente de mercadorias (Bowersox & Closs, 2020). A conformidade regulatória, por sua vez, garante que a operação esteja alinhada com legislações vigentes, políticas institucionais e requisitos contratuais estabelecidos com clientes internos e externos (Luciano & Testa, 2011). Outro fator crítico na implementação de um TMS é a precisão das informações geradas pelo sistema. Conforme destacado por Griepentrog et al. (2013), a previsibilidade das variações de tempo e espaço depende diretamente da confiabilidade dos dados registados, especialmente em ambientes sujeitos a múltiplas incertezas externas. Além disso Steadieseifi et al. (2014) ressaltam a importância do gerenciamento em tempo real de documentações essenciais, como licenças, impostos, taxas e comprovantes de pagamento. O uso de um TMS não apenas permite o rastreamento contínuo dos veículos, como também proporciona um controle fiscal eficiente, reduzindo riscos e garantindo a conformidade com as exigências regulatórias. 17 Em síntese, a implementação de um sistema de gestão de transportes traz benefícios significativos para as operações logísticas, permitindo um melhor aproveitamento dos recursos, a redução de custos operacionais e a melhoria da visibilidade sobre os processos de transporte. A adoção de tecnologias como o TMS representa um passo essencial para a modernização da cadeia de suprimentos, garantindo maior eficiência, segurança e competitividade no setor de transportes. Além disso, a integração do TMS com outros sistemas empresariais, como o ERP, possibilita um fluxo de trabalho contínuo e automatizado, otimizando a comunicação entre diferentes setores da empresa e fortalecendo a tomada de decisões baseada em dados. 2.4 Integrações de Sistemas: Estratégias e Desafios A crescente dependência das empresas em múltiplos sistemas de informação gerou a necessidade de estratégias eficazes de integração. Desde os primeiros esforços de interoperabilidade nos anos 1990, como o sistema desenvolvido pela Universidade de Minnesota para unificar bancos de dados populacionais, até as modernas abordagens baseadas em APIs e iPaaS, a integração evoluiu significativamente para acompanhar as necessidades das organizações e as novas tecnologias disponíveis (SAP, 2025a). A integração de sistemas pode ser definida como o processo de conectar diferentes aplicações, bases de dados e plataformas tecnológicas para que operem de maneira unificada, garantindo um fluxo contínuo de informações e uma experiência coesa para os usuários (Pant & Hsu, 1995). Segundo Chang (2006) e Themistocleous et al. (2001), essa integração pode ser orientada a dados, focada na consistência e no compartilhamento de informações entre sistemas, ou orientada a processos, permitindo que diferentes aplicativos colaborem na execução de fluxos de trabalho organizacionais. Entre os principais motivos para a integração de sistema, destacam-se tanto fatores internos, como a necessidade de expandir funcionalidades de ERPs e CRMs ou otimizar processos de Business Intelligence , quanto fatores externos, como a globalização, regulamentações governamentais e fusões empresariais (Lam & Shankararaman, 2007). No entanto, essa integração também impõe desafios significativos, que podem ser classificados em três grandes categorias: constrangimentos técnicos, funcionais e sócio organizacionais (Silva, 2004). Os desafios técnicos incluem a coexistência de plataformas legadas, dificuldades de comunicação entre sistemas com arquiteturas diferentes e problemas de performance causados pela falta de padronização dos modelos de dados (Silva, 2004) . Muitos sistemas foram desenvolvidos sem 18 uma estrutura organizacional robusta, levando a falhas na escalabilidade e dificuldades de adaptação a novas tecnologias. No aspeto funcional, a integração enfrenta barreiras como a redundância e dispersão de dados, que ocorrem quando a informação é armazenada em múltiplos sistemas sem sincronização adequada, resultando em inconsistências e falhas na tomada de decisão. Além disso, fluxos de informação lentos e dependentes de documentação física podem reduzir a agilidade organizacional e gerar elevados custos operacionais (Silva, 2004). Já os desafios sócio-organizacionais refletem a resistência à mudança, falhas na comunicação entre departamentos e a falta de uma cultura organizacional voltada para a colaboração digital. Empresas que não promovem uma governança eficaz da informação frequentemente enfrentam dificuldades na implementação de soluções integradas, comprometendo sua competitividade (Legner & Lebreton, 2007). Para superar essas dificuldades, as empresas precisam adotar estratégias eficazes de integração, alinhadas às melhores práticas do mercado. Diferentes métodos de integração podem ser empregues para conectar aplicações e garantir a interoperabilidade entre sistemas, sendo os mais comuns: integração ponto a ponto, Enterprise Application Integration - EAI, ESB e iPaaS. A integração ponto a ponto é a forma mais básica de conexão entre sistemas, onde cada aplicação é diretamente conectada a outra por meio de código personalizado. Essa abordagem pode funcionar bem em cenários com poucas aplicações, mas rapidamente se torna inviável à medida que o número de integrações cresce, devido à complexidade de manutenção e escalabilidade (SAP, 2025d). Uma alternativa mais estruturada é a EAI que utiliza um hub centralizado para conectar múltiplos sistemas, reduzindo a necessidade de conexões diretas entre aplicações. Esse modelo melhora a escalabilidade e facilita a troca de informações entre sistemas distintos, sendo muitas vezes implementado com o uso de ESB, uma infraestrutura que atua como um barramento de comunicação entre aplicações, permitindo maior flexibilidade e governança na integração (Erasala & Yen, 2002). Outra abordagem moderna é a adoção de iPaaS, uma solução baseada em nuvem que possibilita a integração entre aplicações locais e em nuvem de maneira automatizada. O iPaaS oferece ferramentas para mapeamento de dados, orquestração de eventos e gerenciamento de fluxos de integração, reduzindo significativamente o tempo e o custo de implementação de integrações (SAP, 2025d). 19 A integração baseada em APIs também se tem tornado cada vez mais relevante, permitindo a comunicação entre sistemas por meio de interfaces padronizadas. As APIs desempenham um papel fundamental na modernização das infraestruturas empresariais, pois facilitam a criação de integrações flexíveis e escaláveis, permitindo que aplicações compartilhem dados de maneira segura e eficiente (IBM, 2025). A implementação bem-sucedida de uma arquitetura integrada traz diversos benefícios para as organizações, incluindo melhoria na colaboração entre departamentos, acesso unificado à informação, redução de custos operacionais e aumento da eficiência dos processos empresariais. Empresas que utilizam sistemas bem integrados podem responder mais rapidamente a mudanças no mercado, minimizar riscos operacionais e aprimorar a experiência do cliente ao garantir fluxos contínuos de dados e processos. Além disso, a integração de sistemas proporciona maior confiabilidade e governança da informação, possibilitando um monitoramento mais eficaz das operações, garantindo conformidade regulatória e aumentando a rastreabilidade dos dados organizacionais. Diante da crescente complexidade dos ambientes empresariais e da digitalização acelerada, a integração de sistemas continuará a desempenhar um papel estratégico na transformação digital das organizações, sendo um fator crítico para a competitividade e inovação no mercado global. 2.5 Ferramentas Aplicadas ao Longo do Projeto Ao longo do desenvolvimento deste projeto, diversas ferramentas foram aplicadas para estruturar a análise, identificar problemas e fundamentar a proposta de melhorias na integração entre os sistemas ERP e TMS. Essas ferramentas desempenharam um papel essencial na compreensão do contexto atual, na modelação dos processos e na definição da arquitetura futura. Entre os principais métodos utilizados, destacam-se o Diagrama de Ishikawa, empregado para a análise das causas dos problemas de integração, e a Modelação de Processos de Negócio, que permitiu mapear de forma estruturada o fluxo de criação de clientes. Além disso, a Notação BPMN foi utilizada para representar graficamente os processos, facilitando a identificação de pontos críticos e oportunidades de melhoria. As subseções a seguir detalham a aplicação dessas ferramentas, evidenciando sua relevância na construção das soluções propostas. 20 2.5.1 Diagrama de Ishikawa Segundo Mello et al. (2016), o Diagrama de Causa e Efeito, também conhecido como Diagrama de Ishikawa, é utilizado para achar causas prováveis que contribuem para um efeito. Suas aplicações são: permitir com que a equipa possa identificar, explorar e demonstrar através de gráficos possíveis fatores, ou seja, causas relacionadas a um problema ou condição efeito. O diagrama de Ishikawa pode ser empregado para a investigação de um efeito negativo, e corrigi-lo, ou bem como o de um efeito positivo, e incorporá-lo ao processo. Essa ferramenta permite que as equipas analisem, de maneira estruturada, os fatores que podem influenciar determinado problema, agrupando-os em categorias principais. O diagrama organiza as causas potenciais em categorias como: métodos, mão de obra, materiais, máquinas, gestão e meio ambiente, dependendo do contexto do problema. Essas categorias são representadas como ramificações que convergem para o problema ou efeito principal, facilitando a visualização das relações entre causas e efeitos (ver Figura 3). O Diagrama de Ishikawa é amplamente empregado em ambientes industriais, logísticos e de qualidade para promover uma análise mais sistemática e colaborativa. A sua aplicação facilita a identificação de causas-raiz, permitindo que as equipas desenvolvam soluções mais eficazes para mitigar falhas e otimizar processos. No contexto desta dissertação, essa abordagem foi essencial para a análise dos problemas identificados nas integrações entre o SAP e o BluJay, proporcionando uma visão clara das limitações do modelo atual e servindo de base para a proposta de melhorias na arquitetura futura. Figura 3 - Exemplo de Diagrama de Causa e Efeito 21 2.5.2 Gestão de Processos de Negócio O Business Process Managemet - BPM é essencial para estruturar e otimizar os fluxos operacionais, garantindo maior alinhamento entre a gestão e as tecnologias da informação. Silva e Pereira (2015) definem a gestão de processo de negócio como um conjunto de competências e métodos que permite identificar, modelar e aperfeiçoar processos organizacionais, promovendo eficiência, transparência e automação. Já Rosemann et al. (2006) define a gestão de processos de negócio como uma abordagem estruturada e integrada para compreender, documentar, modelar, analisar, testar, executar e aprimorar continuamente os processos empresariais e os recursos envolvidos, com o objetivo de maximizar a eficiência e o desempenho organizacional. O ciclo de vida do BPM é composto por cinco fases principais, conforme apresentado na Tabela 2. Essas fases estruturam a evolução dos processos desde a conceção até à sua melhoria contínua (Devillers, 2011). Tabela 2 - Fases do Ciclo de Vida do BPM Fase: Descrição: Desenho Identificação e definição dos processos de negócio, considerando tarefas, responsabilidades e sistemas envolvidos. Modelação Criação de modelos detalhados dos processos, utilizando padrões como BPMN, para documentar e padronizar os fluxos de trabalho. Execução Implementação dos processos modelados, com integração de sistemas para automatizar e otimizar a sua execução. Monitorização Acompanhamento do desempenho dos processos por meio de métricas e dashboards , permitindo uma avaliação contínua. Otimização Ajuste e melhoria dos processos com base nos dados monitorizados, garantindo um ciclo contínuo de aperfeiçoamento. 22 2.5.3 Modelação de Processos de Negócio A modelação de processos de negócio é uma prática essencial para a compreensão e otimização dos fluxos operacionais dentro das organizações. Segundo Chinosi e Trombetta (2012), a Modelação de Processos de Negócio surgiu na década de 1960 no campo da engenharia de sistemas e, inicialmente, era utilizada para melhorar a eficiência e a qualidade dos processos empresariais. A partir da década de 1990, as empresas passaram a substituir termos como “procedimentos” e “funções” por conceitos mais abrangentes, como “processos” e “ workflows ”, refletindo uma visão mais integrada e dinâmica da gestão empresarial. Já Padilla (2014) descreve a modelação de processos de negócio como uma atividade que representa, por meio de uma notação gráfica padronizada, o comportamento esperado de um negócio, ou seja, a forma como os processos devem ser executados para cumprir suas tarefas e alcançar os seus objetivos. Essa abordagem permite visualizar, de maneira estruturada, a sequência de atividades, os responsáveis por cada etapa e as interações entre diferentes sistemas e departamentos. Para Pourshahid et al. (2009), a documentação e representação gráfica dos processos de negócio é denominada de Modelação de Processos de Negócio, sendo um método estruturado que permite aos stakeholders analisar os processos de forma detalhada e identificar potenciais pontos de melhoria. A modelação de processos desempenha um papel crucial na identificação de ineficiências, gargalos e oportunidades de melhoria, sendo amplamente utilizada para documentar tanto o estado atual de um processo As-Is quanto a sua configuração ideal após otimizações To-Be . 2.5.4 Notação Business Process Model and Notation - BPMN A BPMN é uma notação gráfica utilizada para representar visualmente processos de negócio através de diagramas conhecidos como Business Process Diagrams - BPD. Essa notação fornece um padrão compreensível tanto para analistas de negócio, que elaboram os primeiros esboços dos processos, quanto para os desenvolvedores técnicos responsáveis pela sua implementação e para as equipas que monitorizam sua execução operacional (BPMN, 2025; Chinosi & Trombetta, 2012). Originalmente publicada em 2004 pela Business Process Modeling Initiative, a BPMN teve sua adoção expandida devido ao crescente interesse das empresas nessa abordagem de modelação. Em 2006, tornou-se um padrão oficial do Object Management Group - OMG, organização responsável pela definição de padrões tecnológicos (Chinosi & Trombetta, 2012; OMG, 2025). 23 A notação BPMN é composta por um conjunto de elementos gráficos organizados de forma intuitiva, permitindo a criação de diagramas que são facilmente interpretáveis por analistas de negócio (White, 2004). Esses elementos estão distribuídos em quatro categorias principais: Objetos de Fluxo, Objetos de Conexão , Swimlanes e Artefactos (Chiarello et al., 2014). Os Objetos de Fluxo representam todas as ações que ocorrem dentro de um processo de negócio, determinando seu comportamento. São divididos em Eventos, que indicam o início, o meio ou fim de um processo; Atividades, que representam as ações executadas; e Gateways , utilizados para modelar decisões e regras de fluxo (Chinosi & Trombetta, 2012). Os Objetos de Conexão são responsáveis por estabelecer relações entre os elementos do processo. Existem três tipos principais: Fluxo de Sequência, que define a ordem das atividades; Fluxo de Mensagem, que indica a troca de informações entre participantes do processo; e Associações, utilizadas para vincular artefactos a elementos do fluxo (Chinosi & Trombetta, 2012). As Swimlanes , uma das características mais distintivas da BPMN, são utilizadas para organizar os elementos do BPD de acordo com os papéis ou unidades organizacionais envolvidas. Elas são divididas em Pools , que representam entidades independentes dentro do processo, e Lanes , que subdividem os pools para detalhar responsabilidades. Os Artefactos fornecem informações complementares aos processos sem afetar diretamente seu fluxo. Entre os principais artefactos estão as Anotações, utilizadas para adicionar descrições e comentários; os Grupos, que organizam visualmente conjuntos de elementos; e os Data Objects , que representam dados manipulados durante a execução do processo (Chinosi & Trombetta, 2012). Com a evolução da BPMN ao longo dos anos, novos elementos foram introduzidos para ampliar sua capacidade de modelação. A versão BPMN 2.0, por exemplo, trouxe um conjunto expandido de símbolos e funcionalidades, incluindo maior suporte para interações humanas, refinamento na correlação de eventos e a formalização da execução semântica dos modelos. Além disso, essa versão resolveu ambiguidades presentes nas versões anteriores e introduziu modelos específicos para conversação e coreografia, permitindo uma representação mais precisa das interações entre diferentes entidades dentro de um processo (Chinosi & Trombetta, 2012; Silva & Pereira, 2015). Embora a BPMN tenha evoluído significativamente, a maioria dos utilizadores continua a utilizar apenas um subconjunto dos seus elementos, priorizando aqueles que desempenham um papel fundamental na modelação de processos de negócio (Silva & Pereira, 2015). 30 4. DESCRIÇÃO E ANÁLISE DO ESTADO ATUAL DAS INTEGRAÇÕES O Capítulo Quatro apresenta uma análise detalhada do modelo atual de integração entre os sistemas de gestão utilizados pelo Grupo Rangel, destacando os desafios enfrentados e as oportunidades de melhoria na comunicação entre o ERP System Applications and Products - SAP, o TMS BluJay e o middleware . A crescente complexidade das operações logísticas e a necessidade de um fluxo de informação contínuo e confiável tornam essencial a revisão da arquitetura funcional adotada, garantindo que os dados sejam processados com segurança, rastreabilidade e governança. Inicialmente, são abordadas as características da arquitetura atual As-Is , evidenciando as fragilidades da abordagem existente, como a dependência da escrita direta na base de dados, que compromete a integridade das informações. Em seguida, é apresentada uma análise dos impactos dessas limitações na eficiência operacional e nos processos de negócio da organização. A partir desse diagnóstico, propõe-se uma nova arquitetura To-Be , baseada no uso da camada de aplicação do SAP para a intermediação das integrações, garantindo maior controle e confiabilidade no tratamento dos dados. Por fim, este capítulo discute a importância de consolidar o SAP como MDM dentro da organização, fortalecendo a centralização das informações críticas e a conformidade com as melhores práticas de gestão de dados. A transição para essa nova abordagem, alinhada às recomendações da SAP e aos requisitos operacionais da Rangel, representa um avanço significativo na integração dos sistemas e na eficiência dos processos internos. 4.1 Conceitos e Pressupostos Os conceitos e pressupostos apresentados nesta secção serão utilizados ao longo da dissertação, servindo como base para a compreensão dos temas abordados. O objetivo desta secção é clarificar as definições adotadas, garantindo que o leitor compreenda o significado dos termos e conceitoschave no contexto da integração de sistemas. A integração de sistemas de informação refere-se ao desafio de conectar sistemas informáticos distintos, permitindo a partilha de recursos, como dados e funcionalidades. A escolha da abordagem de integração mais adequada depende da natureza de cada sistema envolvido. O conceito de integração, neste contexto, diz respeito à conexão de dois ou mais sistemas, independentemente 31 de estarem dentro da mesma organização ou em diferentes entidades. Essa integração pode ocorrer em múltiplos níveis, como entre repositórios de informação distintos, dentro de uma mesma aplicação ou entre diferentes aplicações. Além disso, a integração de sistemas está diretamente relacionada à interoperabilidade, garantindo que diferentes sistemas possam comunicar e interagir, independentemente das tecnologias envolvidas. Para efeitos desta dissertação, considera-se um sistema informático qualquer solução digital que viabilize a gestão e exploração da informação dentro de uma organização. Esses sistemas podem ser referidos como aplicativos, aplicações, pacotes aplicacionais, soluções informáticas ou módulos aplicacionais, dependendo do seu âmbito e funcionalidades. No que diz respeito à arquitetura de sistemas, esta pode ser definida como um modelo estruturado que combina diferentes componentes tecnológicos para atingir um objetivo específico. Adicionalmente, o termo "processo de integração" é aqui compreendido como um conjunto estruturado de tarefas organizacionais que podem envolver pessoas, aplicações e documentos. Quando informatizados e automatizados, os processos tornam-se um elemento essencial na integração de sistemas, permitindo a interligação fluida entre diferentes aplicações informáticas. A governança de sistemas de informação é outro conceito fundamental para a integração eficaz de sistemas. A governança define a estrutura de tomada de decisão e a alocação de responsabilidades no contexto da gestão organizacional, garantindo que as políticas, processos e tecnologias adotados estejam alinhados com os objetivos estratégicos da empresa. Por fim, o conceito de Middleware que se refere a uma camada tecnológica que atua como intermediária entre diferentes sistemas, facilitando a troca de informações, o transporte de dados e a comunicação entre diversas aplicações. Esse tipo de tecnologia desempenha um papel essencial na integração eficiente de SI, promovendo uma maior conectividade e interoperabilidade entre diferentes plataformas e infraestruturas tecnológicas. A definição clara destes conceitos é essencial para compreender os desafios e estratégias abordados ao longo desta dissertação, permitindo uma análise estruturada e fundamentada da integração de SI no contexto organizacional. 32 4.2 Principais Causas dos Problemas Identificados A identificação das principais causas de problemas nas integrações do Grupo Rangel teve início com uma série de reuniões realizadas com as equipas responsáveis pelos sistemas ERP e TMS. Esses encontros tiveram como objetivo compreender os desafios enfrentados na operação diária, além de levantar as possíveis causas das ineficiências nos processos de integração. Através dessas interações, foi possível mapear dificuldades recorrentes e coletar perceções dos intervenientes diretos, fornecendo uma visão mais ampla sobre os impactos dessas falhas no desempenho organizacional. Durante a investigação sobre as ineficiências nos processos de integração entre sistemas ERP, identificou-se uma série de fatores que intensificam a complexidade e os desafios já existentes. Esses fatores exacerbaram os problemas identificados, sublinhando a necessidade de adotar uma metodologia estruturada para uma análise clara das causas-raiz. Para sistematizar essas descobertas, elaborou-se o diagrama apresentado na Figura 7, que é uma representação visual que esclarece as causas contribuintes para as ineficiências observadas. Figura 7 - Diagrama de Causa e Efeito dos Problemas de Integração de Sistemas 33 Essa ferramenta, conhecida como diagrama de causa e efeito ou Diagrama de Ishikawa, é crucial para identificar, organizar e categorizar de maneira sistemática as possíveis causas que fundamentam as ineficiências encontradas, permitindo assim uma abordagem mais direcionada e efetiva na resolução dos problemas nos processos de integração. O diagrama categoriza as causas em seis áreas principais: Máquinas, Pessoas, Medição, Métodos, Material e Ambiente. Essas categorias ajudam a organizar as causas que contribuem com os problemas de integração e fornecem uma visão clara de como cada grupo de fatores contribui para as dificuldades observadas. MÁQUINAS A categoria Máquinas no diagrama aborda problemas tecnológicos que afetam a integração dos sistemas ERP. O uso de uma versão antiga da linguagem Advanced Business Application Programming - ABAP e sistemas desatualizados em relação aos últimos lançamentos da SAP são exemplos claros de como desafios tecnológicos podem impedir a eficácia das integrações. A obsolescência da infraestrutura tecnológica limita a capacidade de aproveitar novas funcionalidades e melhorias, comprometendo a eficiência e a segurança dos dados. PESSOAS Na categoria Pessoas, problemas como a falta de clareza nas responsabilidades de suporte e a ausência de rotinas de controle de qualidade definidas destacam-se como causas significativas de ineficiências. O suporte fragmentado entre diversas equipas e a falta de visão integrada aumentam os desafios, resultando em múltiplos handovers e atrasos na resolução de problemas, afetando diretamente a fluidez das operações de integração. MEDIÇÃO Sob Medição, a análise dos dados do Helpdesk revelou um crescimento no número de erros reportados, indicativo de falhas nos sistemas integrados. A capacidade de monitorizar e medir a eficácia dos processos de integração é crucial, e deficiências nesta área podem levar a diagnósticos tardios de problemas, complicando ainda mais as operações. 34 MÉTODOS Os Métodos utilizados para a integração dos sistemas são frequentemente inadequados ou desatualizados. A falta de validações claras nas configurações e dados essenciais, juntamente com protocolos de mudança deficientes e a ausência de uma definição clara de processos, são barreiras que impedem uma integração eficaz e eficiente, contribuindo para a prevalência de erros e inconsistências. MATERIAL Em Material, a perda de conhecimento essencial devido à saída dos responsáveis originais pelas integrações ilustra como a falta de documentação adequada pode impactar negativamente a gestão e a execução das integrações de sistemas ERP. A falta de informações precisas e acessíveis resulta em dependência excessiva de conhecimento tácito, que é vulnerável a perdas irreparáveis quando há mudanças na equipa. AMBIENTE Finalmente, a categoria Ambiente reflete como a estrutura das integrações, projetada para uma realidade operacional antiga e incapaz de acompanhar o crescimento e as mudanças no volume de negócios, cria um cenário propenso a falhas e ineficiências. Cada uma dessas categorias do Diagrama de causa e efeito contribui de maneira única para as dificuldades enfrentadas nas integrações de sistemas ERP no Grupo. Ao entender e abordar as causas em cada categoria, a organização pode melhorar significativamente a eficiência e a eficácia de suas operações integradas. 4.3 Análise do Helpdesk A identificação dos principais problemas de integração evidenciou diversas falhas estruturais que impactam diretamente a confiabilidade e a eficiência dos processos. No entanto, para compreender a extensão desses desafios e quantificar os impactos operacionais, tornou-se essencial recorrer 35 a dados concretos sobre incidentes relacionados ás falhas de integração. Nesse contexto, os registos do Helpdesk revelam-se uma fonte valiosa de informação, permitindo analisar a frequência e a gravidade dos problemas enfrentados pelas equipas no uso dos sistemas ERP e TMS. O Grupo Rangel utiliza um sistema de suporte digital, o Helpdesk, para gerir solicitações de suporte técnico, melhorias evolutivas, bem como pedidos de novos projetos e desenvolvimentos. Esse sistema desempenha um papel essencial na gestão dos processos de integração, permitindo que os key users registem tickets detalhados sobre as configurações e ajustes necessários. Os tickets registados no Helpdesk abrangem uma ampla gama de pedidos e, por isso, precisam passar por um processo de triagem antes de serem direcionados às equipas responsáveis. Esse processo é realizado pelo DSI, que analisa cada solicitação para identificar sua origem, classificar sua criticidade e definir qual equipa será responsável pelo suporte. Dependendo da natureza do ticket , as demandas podem variar desde problemas de hardware e solicitações de acesso até a resolução de erros e bugs em sistemas, incluindo questões relacionadas às integrações entre plataformas. Além de ser um canal estruturado para a gestão de incidentes e melhorias, o Helpdesk também desempenha um papel fundamental na documentação e rastreabilidade das intervenções realizadas. Isso garante maior transparência no acompanhamento das solicitações, enquanto permite uma análise contínua da eficiência dos processos de suporte e desenvolvimento dentro da organização. Com o objetivo de obter uma visão mais abrangente sobre a evolução da demanda por suporte, foi desenvolvido um relatório analítico em Power BI , consolidando dados desde 2020 até o presente. Esse relatório permite monitorizar o volume e a natureza dos tickets endereçados ao Corporate IT, com especial atenção às ocorrências relacionadas a integrações com o BluJay. 36 A análise dos dados revela uma tendência crescente no número de solicitações ao longo dos anos. Em 2020, foram registados 733 pedidos destinados à equipa de Corporate IT, dos quais menos de 10 estavam diretamente ligados a processos de integração. Em 2021, o número total de tickets registados aumentou para 1.053, refletindo um crescimento na necessidade por suporte técnico. Dentre esses, 34 pedidos, ou seja, 3,23%, estavam diretamente relacionados a integrações, representando uma fração relativamente pequena do total de solicitações, mas ainda assim exigindo aproximadamente 26 horas de trabalho, o que correspondia a 3,22% das 807,45 horas totais dedicadas pelo Corporate IT ao suporte técnico ao longo do ano.por suporte técnico, conforme ilustrado na Figura 8. Em 2022, o número total de tickets registados aumentou significativamente, atingindo 1.754 solicitações, refletindo um crescimento expressivo na demanda por suporte técnico. Dentre essas, 385 requisições — equivalente a 21,96% dos pedidos — estavam relacionadas a integrações BluJay, representando uma parcela considerável do total de tickets. Esse aumento também se traduziu em um crescimento substancial no tempo de suporte dedicado a essas ocorrências, totalizando 640,5 horas, o que corresponde a 19,9% das 3.218,59 horas totais de suporte prestadas pela equipa de Corporate IT ao longo do ano, conforme ilustrado na Figura 9. Figura 8 - Dados Helpdesk 2021 Figura 9 - Dados Helpdesk 2022 37 Em 2023, foram registados um total de 1.408 tickets, dos quais as integrações BluJay representaram a principal fonte de demanda por suporte, com 514 solicitações — o equivalente a 37,5% do total de erros, conforme ilustrado na Figura 10. O tempo dedicado à resolução dessas ocorrências totalizou 1.348 horas, representando 42,9% das 3.142 horas de suporte prestadas pela equipa de Corporate IT ao longo do ano, evidenciando o impacto operacional dessas falhas e indicando um crescimento significativo em relação aos anos anteriores. Em 2024, no período de janeiro até setembro, foram registados 950 tickets no total. As integrações BluJay continuam a representar uma das principais fontes de demanda por suporte, com 372 tickets — o equivalente a 38,7% do total de solicitações, conforme ilustrado na Figura 11. O tempo despendido na resolução dessas ocorrências totalizou 505 horas, o que corresponde a 37,1% das 1.346 horas de suporte registadas nesse período, demonstrando um impacto operacional ainda expressivo, embora com uma redução em relação ao ano anterior. A análise temporal dos tickets de suporte registados revela uma variação intrigante nos volumes anuais, com números notavelmente reduzidos nos anos de 2020 e 2021. Investigando as causas Figura 10 - Dados Helpdesk 2023 Figura 11 - Dados Helpdesk 2024 38 dessa discrepância, descobriu-se que predominavam erros sistemáticos na classificação dos tickets durante esses períodos. Frequentemente, incidentes relacionados com integrações eram erroneamente classificados como solicitações gerais ou eram atribuídos diretamente à categoria SAP, sem a devida consideração por sua natureza específica. Essa falha de classificação foi progressivamente corrigida com a implementação de diretrizes claras e rigorosas para a categorização dos tickets , o que contribuiu para uma melhoria substancial na precisão dos registos subsequente. Adicionalmente, identificou-se um crescimento significativo no tempo dedicado às atividades de suporte associadas às integrações com o sistema BluJay. Esse crescimento culminou em 2023, um ano em que cerca de 50% das horas totais de suporte técnico da equipa de Corporate IT foram empregues exclusivamente em resolver desafios relacionados à integração. Este aumento substancial não apenas sublinha a complexidade crescente das demandas de integração, mas também ressalta a urgência de revisar e aprimorar os processos de integração. 4.4 Arquitetura das Integrações no Grupo Rangel O Grupo Rangel é composto por diversas empresas, cada uma com necessidades operacionais específicas, atendidas por sistemas de gestão adaptados às suas exigências. Entre essas unidades, destacam-se a Rangel Internacional Aéreo e Marítimo e a Rangel Transitários, que utilizam versões customizadas de um sistema de gestão de transportes Transportation Management System . No centro da infraestrutura tecnológica do grupo está um Enterprise Resource Planning centralizador, o SAP, responsável pela consolidação e gestão de informações essenciais, incluindo processos financeiros, recursos humanos e administração de clientes e fornecedores, garantindo conformidade com requisitos legais e fiscais. A interação entre esses sistemas ocorre por meio de uma arquitetura de integração que viabiliza a troca automatizada de dados. Esse mecanismo permite que as informações sejam compartilhadas entre os diferentes sistemas utilizados pela organização, possibilitando a comunicação entre as diversas unidades de negócio e a padronização dos processos operacionais. 4.4.1 SAP: Systems, Applications and Products A SAP foi fundada em 1972, na Alemanha, por cinco engenheiros da IBM, com o objetivo de desenvolver um software empresarial configurável e adaptável às necessidades específicas de cada organização. A principal inovação proposta pelos fundadores foi a criação de um sistema que 39 permitisse a integração em tempo real dos processos de negócios, proporcionando maior eficiência e controle sobre as operações empresariais. Com o lançamento dos softwares originais SAP R/2 e SAP R/3, a SAP consolidou-se como a principal referência global em ERP, estabelecendo um padrão para a gestão integrada de processos empresariais. Essas soluções permitiram às empresas centralizar e automatizar diversas funções, como gestão financeira, logística, compras e controle de produção, garantindo maior consistência e confiabilidade das informações (SAP, 2025c). Os modelos de negócios tradicionais, por sua vez, costumavam descentralizar a gestão dos dados, com cada departamento armazenando suas informações em bancos de dados separados. Esse método dificultava a partilha de informações entre diferentes áreas da empresa, aumentava a redundância de dados e gerava ineficiências operacionais, como altos custos de armazenamento e um maior risco de inconsistências nos dados. A principal vantagem das soluções SAP está na centralização do gerenciamento de dados, eliminando silos informacionais e garantindo que todas as funções empresariais trabalhem com uma única versão da verdade. Dessa forma, os colaboradores de diferentes departamentos podem aceder a insights em tempo real, otimizando a tomada de decisão e garantindo um melhor alinhamento estratégico entre as áreas de negócio. Além disso, essa abordagem melhora a rastreabilidade e a segurança das informações, reduzindo erros operacionais e possibilitando um maior controle sobre os processos internos (SAP, 2025c). 4.4.2 BluJay Solutions O BluJay é uma referência global no desenvolvimento de software para logística e gestão da cadeia de abastecimento, oferecendo soluções avançadas para otimizar operações de transporte e distribuição. No contexto da crescente globalização e da necessidade de maior eficiência operacional, a adoção dessas tecnologias permite que as empresas agilizem processos, aprimorem a visibilidade em tempo real das operações e proporcionem uma experiência superior aos clientes (BluJay Solutions, 2025). A Rangel implementou o BluJay TMS como parte de sua estratégia para digitalizar e otimizar a gestão de transportes. Em um primeiro momento, a RIAM adotou esta solução para automatizar o gerenciamento de transportes aéreos e marítimos, focando na melhoria da produtividade, inovação e visibilidade end-to-end . Esse sistema permite a seleção e negociação com transportadoras, 46 Diante desses desafios, a arquitetura proposta To-Be adota um modelo que prioriza a utilização da camada de aplicação do SAP como intermediário para todas as integrações. Essa mudança visa garantir que os processos de negócio sigam as regras definidas no ERP, evitando que dados críticos sejam manipulados sem as devidas validações. Com essa abordagem, as informações passam a ser processadas de forma mais segura e estruturada, reduzindo significativamente os riscos associados à atualização direta na base de dados. Tabela 3 - Etapas do Modelo de Escrita Direta na Base de Dados Etapa: Descrição: 1. Início do Processo A integração é disparada no BluJay quando modificações de configuração ou processos de negócio específicos são necessários, gravando uma nova informação no sistema. Este gatilho é fundamental para sincronizar as atualizações pertinentes entre os sistemas. 2. Escrita Direta na Base de Dados Após o gatilho inicial, o TIBCO executa a escrita direta das informações nas tabelas Z4 da base de dados do SAP. Essa etapa abrange desde alterações em configurações como centros de custo e gestores de cobrança, até dados operacionais essenciais. 3. Disparo de um Job Através da Camada de Aplicação Subsequentemente, um job automatizado na camada de aplicação do SAP é ativado para verificar as novas entradas, assegurando que os dados recebidos estejam prontos para processamento subsequente. 4. Adição de Lógica de Negócio e Mapeamentos A camada de aplicação então aplica lógicas de negócio e realiza mapeamentos utilizando tabelas Staging5 para a transformação intermediária dos dados. 5. Retorno dos Dados as Tabelas Z Os dados processados são devolvidos às tabelas Z, confirmando que todas as alterações e verificações necessárias foram aplicadas. 4 Tabelas personalizadas no SAP para necessidades específicas que não são cobertas pelas tabelas padrão 5 Tabelas temporárias utilizadas para preparar e ajustar os dados antes de serem processados ou movidos para as tabelas de produção 47 Tabela 4 - Continuação - Etapas do Modelo de Escrita Direta na Base de Dados Etapa: Descrição: 6. Escrita Final nas Bases de Dados Standard do SAP Finalmente, os dados validados e finalizados são transferidos para as tabelas standard6 da base de dados do SAP, consolidando a integração e assegurando conformidade com os padrões do sistema. 7. Comunicação com o BluJay via status Ao término do processo, o TIBCO notifica o BluJay sobre a integração bem-sucedida dos dados, atualizando o status para refletir a conclusão da transação. A CAMADA DE APLICAÇÃO SAP: FUNCIONAMENTO E IMPORTÂNCIA O SAP é estruturado com base em uma arquitetura de três camadas, composta pela camada de apresentação, camada de aplicação e camada de banco de dados. Essa organização modular permite um alto grau de escalabilidade, segurança e desempenho no processamento das operações empresariais. A camada de apresentação é responsável pela interface do usuário, permitindo a interação com o sistema por meio de um ambiente gráfico intuitivo ou de interfaces baseadas na web. Já a camada de banco de dados gerencia o armazenamento e a recuperação das informações, garantindo a persistência e integridade dos dados. No centro dessa arquitetura encontrase a camada de aplicação, considerada o núcleo do SAP, pois processa toda a lógica de negócios e garante a execução adequada dos processos organizacionais (SAP Learning, 2024b). A camada de aplicação desempenha um papel essencial dentro do SAP, pois gerencia a execução de regras de negócio, comunicação entre sistemas, gerenciamento de transações e segurança dos dados. Uma de suas principais funções é a execução da lógica de negócios, onde módulos essenciais do SAP, como Financial Accounting - FI , Materials Management - MM, Sales and Distribution - SD e Production Planning , - PP realizam processos críticos como processamento de pedidos de vendas, fechamento contábil e movimentação de estoques. Além disso, essa camada é responsável pelo gerenciamento de sessões dos usuários, garantindo a autenticação e o controle de acessos por meio do sistema de login corporativo, além de distribuir as conexões de forma otimizada através do balanceamento de carga. Outra função essencial é a execução de programas, onde códigos 6 Tabelas pré-configuradas pelo SAP usadas para armazenar dados de acordo com as regras de negócio padrão do sistema. 48 desenvolvidos na linguagem proprietária da SAP, ABAP, e, em alguns casos, Java, são interpretados e executados para garantir a funcionalidade do sistema (SAP Learning, 2024a). Seguir as regras e os processos padronizados pelo SAP é essencial para manter a integridade e a consistência dos dados. As operações realizadas na camada de aplicação garantem que todas as validações, transações e regras de negócio sejam respeitadas. No entanto, quando atualizações são feitas diretamente na base de dados, essas garantias são comprometidas, resultando em riscos significativos para o funcionamento do sistema. Segundo os autores Help Portal (2025); Monk & Wagner (2019) e Oliveira (2017), contornar a camada de aplicação do SAP e realizar atualizações diretamente no banco de dados pode resultar em diversos problemas. Dentre os principais problemas podemos destacar: a violação das lógicas de negócio, pois o SAP executa cálculos fiscais, validações de consistência e diversas regras automatizadas que garantem que os dados inseridos estejam corretos. Ao atualizar diretamente o banco, essas regras são ignoradas, podendo gerar dados inconsistentes que afetam processos posteriores, como facturamento, relatórios financeiros e conformidade regulatória. Outro problema grave é a violação da integridade referencial, uma vez que o banco de dados utiliza chaves primárias e estrangeiras para manter a coerência entre as tabelas. Inserções diretas podem ignorar essas restrições, resultando em registos órfãos ou dados duplicados, tornando-se um risco para a confiabilidade das informações armazenadas. Além disso, a falta de controle transacional é um fator crítico. A camada de aplicação do SAP gerencia transações de forma segura, garantindo que todas as operações relacionadas sejam completadas com sucesso ou revertidas em caso de falha. Atualizações diretas no banco podem interromper esse processo, gerando inconsistências, como a gravação parcial de dados ou a falha em reverter transações incorretas. A segurança do sistema também é comprometida, uma vez que a camada de aplicação possui mecanismos robustos de autenticação, permissões e auditoria. Ao modificar dados diretamente no banco, essas camadas de proteção são contornadas, permitindo que usuários mal-intencionados alterem ou excluam informações sem que isso seja devidamente registado nos registos de auditoria do SAP. Outro impacto significativo é a dificuldade de auditoria e rastreamento. O SAP mantém registos detalhados de todas as alterações feitas através da aplicação, permitindo um monitoramento eficaz das operações realizadas pelos usuários. No entanto, quando dados são alterados diretamente no banco, essas modificações não são devidamente rastreadas, dificultando investigações em caso de falhas ou inconsistências. 49 Além disso, a inserção direta de dados pode comprometer funcionalidades críticas do sistema, pois muitos processos no SAP dependem de eventos automatizados, como geração de documentos fiscais, notificações e cálculos contábeis. Se esses eventos forem ignorados devido a uma inserção direta, as operações subsequentes podem falhar, gerando retrabalho e aumentando o risco de erros operacionais. Por fim, a incompatibilidade com atualizações e migrações é uma consequência importante. O SAP está em constante evolução, recebendo atualizações periódicas que podem alterar a estrutura das tabelas e das lógicas internas. Alterações diretas no banco podem quebrar compatibilidades com versões futuras, tornando o sistema mais difícil de manter e aumentando os custos de suporte técnico a longo prazo. A arquitetura de três camadas do SAP desempenha um papel fundamental na garantia da eficiência, segurança e integridade dos dados empresariais. A camada de aplicação, em particular, é responsável por executar as regras de negócio, gerenciar transações e garantir a comunicação estruturada entre os sistemas. As atualizações diretas no banco de dados, ao contornar essa estrutura, comprometem a consistência dos dados, a integridade referencial, a rastreabilidade e a segurança das operações. Assim, para manter a confiabilidade e a eficiência do sistema, é essencial que todas as interações com o SAP sejam realizadas por meio da camada de aplicação, respeitando as melhores práticas recomendadas e garantindo a continuidade operacional da empresa. 4.5.2 Integração Utilizando a Camada de Aplicação Buscando solucionar os desafios e limitações do modelo atual de integração, o diagrama da arquitetura ideal apresentado na Figura 15 foi desenvolvido a partir de uma análise criteriosa, fundamentada na revisão da literatura acadêmica, na consulta a informações oficiais da SAP e na colaboração com especialistas da equipa Corporate IT, incluindo programadores ABAP. Esse modelo representa a arquitetura funcional ideal para a integração entre os sistemas ERP do Grupo Rangel, abrangendo especificamente as interações entre BluJay, TIBCO e SAP. A conceção dessa nova arquitetura tem como objetivo central aumentar a confiabilidade e eficiência do processo de integração, garantindo a conformidade, integridade e consistência dos dados em todas as etapas do fluxo de informação. Para estruturar essa revisão da integração, foram estabelecidos dois requisitos não funcionais essenciais, definidos pela equipa responsável pelo projeto. O primeiro requisito envolve a adoção 50 do SAP MDM, enquanto o segundo requisito estabelece a necessidade de um processo de integração síncrono, assegurando a atualização instantânea dos dados entre os sistemas. Dentro deste novo modelo, o SAP assume o papel de MDM, um sistema abrangente de processos, políticas e ferramentas destinado a garantir a uniformidade, precisão e governança dos dados mestres em toda a organização. O conceito de MDM refere-se à centralização e padronização das informações críticas da empresa, evitando inconsistências e redundâncias nos diferentes sistemas interligados. Ao desempenhar esse papel, o SAP garante que todas as unidades de negócio operem com dados confiáveis e atualizados, possibilitando uma visão única e integrada da informação em tempo real. Esse fator é crucial para a tomada de decisões estratégicas, a eficiência operacional e a conformidade com normas e regulamentos internos e externos. Além disso, a implementação de um processo de integração síncrono representa um avanço técnico significativo dentro desta arquitetura. Esse modelo de sincronização permite que as atualizações entre os sistemas ocorram em tempo real, eliminando problemas associados a informações desatualizadas e garantindo que todos os sistemas refletem os mesmos dados simultaneamente. Em um ambiente dinâmico e de alta complexidade como o da Rangel, onde alterações nas informações de clientes, pedidos e faturação ocorrem constantemente, essa abordagem é fundamental para evitar discrepâncias, melhorar a rastreabilidade e assegurar maior confiabilidade nos processos operacionais. Esses princípios foram determinantes na conceção da nova integração, garantindo que o sistema não apenas atenda às exigências funcionais da organização, mas também esteja alinhado com as melhores práticas tecnológicas e seja implementado de forma sustentável e escalável. A nova arquitetura não apenas otimiza a gestão e distribuição dos dados, mas também promove maior eficiência e transparência na comunicação entre os sistemas envolvidos. Essa abordagem estruturada fortalece a base tecnológica da organização, permitindo operações mais ágeis e decisões mais bem fundamentadas. A Figura 15 apresenta a proposta final para a arquitetura de integração, consolidando as mudanças e melhorias discutidas, destacando o papel do SAP como MDM, o TIBCO como middleware integrador e a implementação de um fluxo síncrono de comunicação entre os sistemas ERP e TMS. 51 O processo de integração é iniciado com a ativação das APIs nativas do SAP, desencadeada pelo BluJay quando uma configuração ou processo de negócio necessita de integração com o SAP. Essa ativação cria um ponto de contato inicial essencial para a receção e o processamento seguro dos dados (Ver Tabela 5 e Tabela 6): Tabela 5 - Etapas do Modelo de Escrita Através da Camada de Aplicação Etapas: Descrição: 1. Sinal de Ativação da Camada de Aplicação O processo começa quando o BluJay envia um sinal ao TIBCO comunicando o início do processo de integração. O TIBCO por sua vez sinaliza ao SAP para a ativação de sua camada de aplicação. As APIs fornecidas pela camada de aplicação do SAP, estabelecendo uma interface segura para a receção e processamento dos dados. 2. Tratamento dos Dados e Mapeamento de Interfaces Após a receção do sinal, o TIBCO assume o papel de formatação e mapeamento das interfaces. Isso garante que os dados do BluJay sejam transformados e preparados conforme os requisitos específicos do SAP. 3. Tratamento dos Dados e Mapeamento de Interfaces As APIs da camada de integração comunicam com o TIBCO, criando uma ponte entre os dados processados e a camada de aplicação. Esta comunicação assegura a transferência estruturada e controlada das informações. Figura 15 - Modelo com Escrita Através da Camada de Aplicação 52 Tabela 6 - Continuação - Etapas do Modelo de Escrita Através da Camada de Integração Etapas: Descrição: 4. Inserção dos Dados nas Tabelas Standard Após a interação, a camada de aplicação do SAP executa as logicas de negócio e insere os dados nas tabelas standard do SAP, alinhando os às estruturas e controles padrão do sistema para facilitar o gerenciamento e a análise. 5. Inserção nas Tabelas Z SAP Paralelamente, os dados são também registados nas tabelas Z, adaptadas para atender às necessidades específicas do Grupo Rangel, proporcionando uma flexibilidade adicional na gestão de dados não padronizados. 6. Confirmação da Integração Uma vez concluída a integração, o SAP sinaliza ao TIBCO e esse por sua vez notifica o sistema BluJay, atualizando o status da integração para refletir o sucesso do processo. 7. Gravação nas Bases de Dados BluJay Finalmente, os dados previamente configurados em SAP são registados nas bases de dados do BluJay, assegurando a consistência entre os sistemas e permitindo que as informações atualizadas estejam disponíveis para operações futuras. Na arquitetura proposta, o SAP assume o papel de MDM, um sistema centralizado responsável pela governança e padronização dos dados dentro da organização. O conceito de MDM refere-se a um conjunto de processos, metodologias e ferramentas que garantem a qualidade, consistência e confiabilidade das informações utilizadas nos diferentes sistemas empresariais. Ao estruturar o SAP como MDM, a Rangel busca consolidar uma única fonte de verdade para os dados críticos, assegurando que todas as operações baseadas nessas informações estejam alinhadas e livres de duplicidades ou inconsistências. Essa abordagem reforça a necessidade de um modelo de integração síncrono, garantindo que as atualizações ocorram em tempo real e evitando discrepâncias entre os sistemas. Com isso, a empresa melhora a rastreabilidade dos dados, otimiza a gestão de informações essenciais para a operação e fortalece a conformidade com as melhores práticas da indústria. A implementação do SAP como MDM, aliada à substituição da escrita direta na base de dados pela camada de aplicação, estabelece uma infraestrutura tecnológica mais robusta e preparada para suportar o crescimento e a evolução contínua da organização. Essa mudança não apenas 53 fortalece a governança dos dados, mas também garante maior eficiência na tomada de decisões estratégicas e operacionais. 4.5.3 Comparação Entre os Modelos A análise da arquitetura das integrações revela duas abordagens distintas para a integração entre o BluJay e o SAP: a escrita direta na base de dados, que contorna a camada de aplicação, e a integração via camada de aplicação, que centraliza a validação e o processamento dos dados antes do armazenamento definitivo. Cada uma dessas abordagens possui impactos significativos na integridade das informações, na segurança do sistema e na sustentabilidade das operações. A camada de aplicação desempenha um papel fundamental como intermediário no fluxo de integração. É responsável pela execução das lógicas de negócio, validações e mapeamentos de dados, garantindo que as informações sigam as regras definidas pelo SAP antes de serem persistidas no banco de dados. Esse modelo de integração segue as melhores práticas recomendadas pela SAP e proporciona maior consistência e confiabilidade, ao assegurar que os dados estejam em conformidade com a estrutura relacional das tabelas e as regras empresariais estabelecidas. Além disso, a camada de aplicação facilita a escalabilidade e manutenção do sistema, permitindo maior rastreabilidade das alterações, auditoria eficiente das transações e implementação automatizada de validações críticas. Por outro lado, a escrita direta na base de dados, que é o método atualmente em uso, ignora essas verificações essenciais, o que pode comprometer a integridade dos dados e aumentar o risco de falhas operacionais. Essa abordagem pode levar a inconsistências nos registos, erros na reconciliação financeira, falhas em processos fiscais e dificuldades na adaptação a futuras atualizações da plataforma SAP. Como não há mediação da camada de aplicação, os registos inseridos podem não ser validados corretamente, gerando impactos significativos em processos críticos, como facturamento, gestão de crédito e conformidade regulatória. Além disso, esse modelo dificulta a implementação de novas funcionalidades e torna a manutenção do sistema mais onerosa e suscetível a erros manuais. A análise da arquitetura funcional evidenciou que a dependência da escrita direta na base de dados compromete significativamente a integridade, segurança e rastreabilidade das informações dentro do ecossistema de sistemas da Rangel. Como alternativa, a adoção da camada de aplicação do SAP para intermediar as integrações representa um avanço fundamental na padronização e 54 governança dos dados, garantindo conformidade com as melhores práticas recomendadas pela SAP e promovendo maior confiabilidade nos processos de integração. Além disso, a consolidação do SAP como MDM reforça a centralização e a qualidade dos dados críticos, possibilitando a adoção de processos mais seguros e eficientes na gestão da informação. Esse novo modelo de arquitetura não apenas melhora a robustez e a escalabilidade do sistema, mas também alinha a organização às exigências futuras, garantindo maior flexibilidade para lidar com a evolução dos processos e das tecnologias envolvidas. 55 5. REVISÃO DAS INTEGRAÇÕES O Capítulo Cinco oferece um exame meticuloso das iniciativas do Grupo Rangel para aprimorar suas operações por meio de uma revisão sistemática das integrações entre seus sistemas ERP. Ele introduz o Projeto-piloto: “Re-think ERP Integrations RIAM ", uma empreitada focada em reavaliar e otimizar as integrações de sistemas para alinhar a tecnologia da informação com as estratégias empresariais e operacionais da empresa de forma mais precisa. Essa revisão é crucial para aumentar a eficiência, minimizar redundâncias e garantir que os sistemas de TI estejam adequadamente sincronizados com as necessidades dinâmicas de um ambiente de negócios globalizado. O capítulo avança detalhando o levantamento e a modelagem dos processos de integração existentes, proporcionando uma visão clara de como os sistemas estão atualmente interconectados. Além disso, discute-se o envolvimento e as responsabilidades dos principais atores, bem como o alinhamento estratégico que norteia o projeto. 5.1 Projeto-piloto: Re-think ERP Integrations RIAM Após uma análise aprofundada da situação das integrações no Grupo, a equipa de Corporate IT assumiu a liderança do projeto devido ao seu papel estratégico na gestão dos sistemas críticos da empresa. Responsável pelo SAP, e pela orquestração das integrações com o BluJay, o Corporate IT garante a centralização, integridade e governança dos dados, além de assegurar a comunicação eficiente entre os sistemas de gestão empresarial e de transporte. A complexidade dessas integrações exigia uma abordagem especializada, tornando essa equipa a mais qualificada para liderar a iniciativa, pois reúne tanto o conhecimento técnico necessário quanto uma visão abrangente dos processos de negócio impactados. Diante desses desafios, foi criado o projeto “Re-think ERP Integrations RIAM" , com o objetivo de repensar e otimizar as integrações entre o SAP e as demais plataformas utilizadas pela empresa. Como se tratava de um projeto piloto, a sua abrangência foi estrategicamente delimitada para focar exclusivamente na revisão das integrações da unidade RIAM, ou seja, nas interações entre o SAP e o BluJay TMS. Esse projeto serviria como referência para futuras iniciativas de reestruturação das integrações em outras áreas da empresa. Com base no mapeamento detalhado dos principais problemas e causas das falhas nas integrações, permitiu um alinhamento estratégico com o líder da equipa do projeto para definir abordagens eficazes de resolução. Com isso, delineou-se um plano estratégico estruturado, garantindo 62 6.1 Ciclo De Vida Do Cliente Primeiramente, o processo de criação de clientes se destaca por integrar configurações críticas que garantem o funcionamento eficiente e a continuidade do ciclo de vida do cliente dentro da organização. O processo de criação de clientes não apenas inicia o relacionamento comercial (ver Figura 17), mas também sustenta todo o ciclo de vida do cliente, integrando configurações sistêmicas e processos de negócio essenciais. Figura 17 - Ciclo de Vida do Cliente 63 O ciclo de vida do cliente, constitui um processo estruturado e interdependente que abrange desde o primeiro contato com o cliente até à cobrança final e a avaliação de novas oportunidades de negócio. Cada etapa deste ciclo desempenha um papel estratégico ao integrar configurações sistêmicas e processos de negócio, com destaque para a etapa de criação do cliente, que atua como o ponto de partida para viabilizar todas as operações subsequentes. PRIMEIRA ETAPA: CRIAÇÃO DO CLIENTE O ciclo de integração de clientes inicia-se com o primeiro contato como apresentado na Figura 18, no qual a intenção do cliente em adquirir um serviço é avaliada. Este momento é crucial, pois uma resposta positiva impulsiona o processo para a próxima etapa: a elaboração de um orçamento. Após a aprovação do orçamento, o processo evolui para uma fase central e estruturante, a criação do cliente no sistema. Durante esta etapa inicial, são implementadas configurações essenciais e processos de negócio específicos que facilitam a integração efetiva do cliente ao sistema, garantindo a fluidez das operações subsequentes. Um aspeto deste processo é a associação de um gestor de cobrança ao novo cliente. Este gestor é responsável pela gestão financeira relacionada ao cliente, monitorando créditos, pagamentos e recebíveis, o que é fundamental para manter a saúde financeira da relação comercial. Paralelamente, a definição das condições de pagamento para clientes que solicitam crédito é outro passo importante. Esta definição precisa ser alinhada com o tipo de serviço oferecido, assegurando que as práticas de controle financeiro sejam mantidas e que haja consistência operacional. Esta Figura 18 - Etapa Criação do Cliente 64 configuração é uma peça-chave para sustentar o relacionamento comercial em bases sólidas e transparentes, facilitando a gestão de expectativas e compromissos financeiros de ambas as partes. SEGUNDA ETAPA: PRODUÇÃO Após a criação do cliente, o processo avança para a etapa de produção, detalhada na Figura 19. Nesta fase, definem-se e realizam-se os serviços contratados, mobilizando configurações e processos de negócio essenciais para garantir a eficiência operacional e financeira. As configurações de Centros de Lucro e Centros de Custo são fundamentais para assegurar que todos os custos e receitas relacionados com o serviço sejam corretamente registados e atribuídos, permitindo uma análise detalhada da rentabilidade e do desempenho financeiro. Além disso, os Códigos de Fornecedores são utilizados para identificar os fornecedores responsáveis pela execução dos serviços, garantindo o registo correto das operações e sua categorização conforme as normas organizacionais e legais, o que é crucial para manter a integridade das operações e a precisão nos relatórios financeiros e de gestão. Figura 19 - Etapa Produção 65 TERCEIRA ETAPA: COBRANÇA Durante a fase de cobrança, que constitui a fase final no ciclo de vida do cliente conforme ilustrado na Figura 20, os serviços realizados são faturados. Este processo não só consolida as transações comerciais, mas também ativa uma série de configurações sistêmicas essenciais para garantir a precisão e consistência dos registos financeiros. O Centro de Custo é crucial para determinar a correta alocação dos custos associados ao serviço prestado. Adicionalmente, o Tipo de Documento especifica o formato da fatura e as informações que ela deve conter, como o código de IVA e as configurações de faturação Intercompany se aplicadas, essenciais para o cumprimento das normativas fiscais e operacionais. Nesta etapa, o Processo de Faturação é meticulosamente executado, formalizando os serviços através de registos que suportam o controle financeiro e contábil da empresa. Concluída a faturação, avalia-se se o cliente tem interesse em contratar novos serviços. Se afirmativo, o ciclo é reiniciado com a definição do próximo serviço a ser oferecido; se não, o ciclo se encerra, marcando o fim de uma jornada de serviço com o cliente. 6.2 Desafio Das Geografias O segundo aspeto relevante está associado ao contexto particular da RIAM, que, como uma unidade especializada do Grupo realiza operações logísticas em escala global. Esse modelo de negócio expõe a organização a um conjunto diversificado de requisitos legais e normativos, que variam de acordo com as geografias em que atua. Um dos principais desafios desse cenário é o preenchimento do Identificador Fiscal dos clientes, um elemento fundamental no cadastro de novos clientes, cuja nomenclatura e regras variam consideravelmente entre os países. Figura 20 - Etapa Cobrança 66 A falta de padronização nesse processo tem gerado diversos problemas operacionais. Em algumas geografias fora da União Europeia, é possível cadastrar clientes sem incluir um Identificador Fiscal, ou mesmo utilizar identificadores genéricos como por exemplo: 999 999 999 e 123 456 789 que, posteriormente, são atribuídos a outros clientes causando problemas na correta identificação dos clientes como exemplificado na Figura 21. No exemplo ilustrativo, observa-se a complexidade da gestão de dados entre diferentes sistemas. No sistema BluJay, um cliente denominado Cliente A é registado com um ID operacional 10 e um Número Identificador Fiscal - NIF de 999 999 999. Contudo, ao transferir esses dados para o sistema SAP, ocorre uma discrepância: além de registar o Cliente A com os mesmos ID e NIF, identifica-se um segundo cliente, Cliente B, com um ID operacional de 60, mas compartilhando o mesmo NIF do Cliente A. Esta situação sugere uma falha na gestão de identificação fiscal, evidenciando a duplicidade de registos com o mesmo identificador fiscal. Tal prática não só complica a identificação precisa dos clientes, como também destaca a falta de um método consistente e eficaz para a gestão unificada dos registos nos sistemas. A ausência de um identificador fiscal exclusivo para cada cliente leva à dependência excessiva em nomes para a diferenciação dos registos, aumentando substancialmente o risco de duplicações, erros transacionais e inconsistências no cadastro. Estes problemas minam diretamente a integridade dos dados e representam obstáculos significativos à gestão eficaz das informações dos clientes. Portanto, a seleção do processo de criação de clientes como foco central deste projeto reflete sua relevância estratégica para a Rangel e a urgência em abordar os desafios específicos que afetam a qualidade e a confiabilidade dos dados. Ao enfrentar estas questões críticas, o projeto visa não apenas aprimorar os fluxos de trabalho associados à gestão de clientes, mas também assegurar a conformidade com os requisitos legais e operacionais vigentes nas diversas regiões em que a Figura 21 - Exemplo de Erro no Cadastro do Cliente 67 empresa atua. Tal abordagem é essencial para reforçar a estrutura sobre a qual se apoia o desempenho empresarial, promovendo uma base mais sólida e confiável para o futuro da organização. 6.3 Arquitetura Atual As-Is : Criação De Cliente O mapeamento do processo de criação de clientes, documentado em formato BPMN, foi desenvolvido através de uma colaboração estreita entre as equipas de negócios e equipas do DSI. Este esforço conjunto envolveu a participação ativa dos principais atores do processo. Do lado das equipas de negócios, os key users utilizadores do SAP da DAF, juntamente com os key users do BluJay da RIAM, desempenharam um papel crucial. Estes profissionais contribuíram com insights funcionais sobre os processos, delineando os gatilhos e os passos detalhados de suas responsabilidades operacionais. Eles forneceram uma perspetiva essencial sobre as exigências práticas e as etapas necessárias para a execução efetiva do processo de criação de clientes. Por outro lado, as equipas do DSI nomeadamente o Corporate IT e o Transportes IT, ofereceram conhecimentos técnicos fundamentais. Contribuindo com explicações sobre o funcionamento das integrações e as responsabilidades envolvidas nas configurações e criações nos sistemas. Sua contribuição foi vital para esclarecer os mapeamentos de interface e as parametrizações que viabilizam as integrações, garantindo que todos os aspetos técnicos fossem adequadamente endereçados. O objetivo principal deste mapeamento foi alcançar uma compreensão aprofundada das particularidades e das validações necessárias no processo de criação de clientes. Foi essencial identificar todos os participantes do processo e entender suas funções e responsabilidades específicas. Esta abordagem colaborativa visou promover um alinhamento eficaz entre todas as partes envolvidas, consolidando o conhecimento que anteriormente se encontrava disperso entre diferentes equipas. Tal consolidação foi fundamental para superar os desafios de uma visão fragmentada e facilitar uma compreensão integrada e coesa do processo, essencial para a eficácia e eficiência das operações futuras. 6.3.1 Mapeamento da Integração: Criação de Cliente Nesta subseção, apresenta-se o mapeamento detalhado do processo de criação de clientes apresentado no Apêndice 1 – Criação de Cliente As-Is, desenvolvido a partir de consultas aos especia- 68 listas internos da empresa e da análise de documentação técnica. O objetivo principal desta modelagem é identificar, de forma funcional, os eventos mais relevantes ao longo das etapas de integração, permitindo uma avaliação crítica da eficiência e da necessidade de cada fase envolvida. O processo foi modelado utilizando a notação BPMN, amplamente reconhecida como padrão na modelagem de processos de negócio devido à sua versatilidade e clareza. A escolha dessa linguagem possibilita uma representação visual precisa das interações entre os sistemas e os departamentos envolvidos, além de evidenciar a integração com os sistemas de informação existentes. O mapeamento foi organizado em três grandes partes, que refletem as divisões funcionais do processo: Gestão de Dados e Integração com BluJay e TIBCO; Tratamento e Validação no SAP; Avaliação de Crédito e Configuração Final As imagens apresentadas ao longo desta seção ilustram de maneira detalhada as etapas-chave do processo de criação de clientes e as suas interdependências. A modelagem desenvolvida oferece uma visão sistêmica e integrada, facilitando a identificação de oportunidades de melhoria e contribuindo para o aprimoramento da eficiência dos fluxos operacionais da organização. GESTÃO DE DADOS E INTEGRAÇÃO ENTRE BLUJAY E TIBCO A Figura 22 a seguir ilustra a primeira etapa do processo de criação de clientes, com foco na gestão inicial de dados e na integração entre os sistemas BluJay e TIBCO. Essa etapa é crucial para garantir que as informações do cliente sejam corretamente geradas, validadas e transmitidas para os sistemas subsequentes. Figura 22 - Gestão de Dados e Integração entre BluJay e TIBCO As-Is 69 CONTEXTO INICIAL O processo de integração de clientes inicia-se no contexto da prospeção comercial como pode ser visto na Figura 23, marcado pela necessidade de gerar um código específico para o cadastro de novos clientes. Este passo inicial é crucial, pois estabelece a base para a interação subsequente com o cliente e envolve várias etapas críticas. Num primeiro momento, o cliente solicita um orçamento, representando o primeiro contato formal com a empresa. Após análise e negociação, o cliente aceita o orçamento, desencadeando a necessidade de criar um cadastro específico no sistema. Neste momento, o cliente é classificado inicialmente, definindo seu status operacional na empresa. Os clientes são categorizados como " Non-Financial " durante a etapa de prospeção, quando ainda não realizam atividades financeiras ativas com a empresa. Esta categorização é típica para novos cadastros onde as interações ainda estão sendo exploradas. Por outro lado, clientes que decidem formalizar a relação comercial e avançam para a fase de produção são classificados como " Financial ". Esta mudança de status indica um cadastro completo, integrando o cliente ao processo produtivo e financeiro da empresa. A geração do código de cliente no sistema BluJay constitui o primeiro registo formal das informações do cliente, armazenadas na base de dados BluJay. Esta base é fundamental, pois garante a disponibilidade das informações, essenciais para as etapas subsequentes do processo de integração, assegurando uma transição suave e a continuidade das operações comerciais. ATIVIDADES DO SISTEMA BLUJAY Figura 23 - Contexto Inicial Figura 24 - Atividades do Sistema BluJay 70 Após a conclusão da criação inicial do cliente, a etapa subsequente foca-se na gestão e integração dos dados dentro do sistema BluJay como visto na Figura 24. Nesta fase, a equipa de Transportes IT desempenha um papel crucial ao identificar e validar o código de cliente gerado anteriormente, assegurando que este esteja em conformidade com os padrões estabelecidos e que reflita com precisão as informações do cliente. Uma vez validado o código, este é transmitido para uma camada de integração dedicada. Nesta fase, os dados são processados e adequadamente preparados para uma comunicação eficiente com outros sistemas corporativos. TRANSMISSÃO VIA MIDDLEWARE A fase final desta etapa evidenciada na Figura 25 envolve a utilização do TIBCO, que desempenha um papel essencial como intermediário entre os sistemas BluJay e SAP. Esta plataforma middleware assegura o tratamento adequado, a preparação e a transmissão eficaz dos dados do cliente para o SAP. Inicialmente, o TIBCO recebe as informações do cliente encaminhadas pela camada de integração, estabelecendo-se como a conexão primordial entre os sistemas. Em seguida, os dados recebidos são processados e tratados. Este passo é vital para garantir que as informações mantenham sua integridade e consistência, além de estarem em conformidade com os requisitos do sistema SAP. Finalmente, após a preparação adequada, o middleware procede com a transmissão dos dados validados ao sistema SAP. Este processo é crucial para assegurar a continuidade efetiva no fluxo de criação de clientes, facilitando a integração transversal dos dados através das plataformas tecnológicas da empresa, garantindo assim a eficácia e a precisão no registo e gestão dos dados de clientes. Figura 25 - Transmissão via Middleware 71 TRATAMENTO, VALIDAÇÃO NO SAP E INTEGRAÇÃO COM BLIJAY A Figura 26 ilustra a segunda etapa do processo de criação de clientes, com ênfase no mapeamento, validação e integração no sistema SAP. Esta etapa desempenha um papel fundamental ao garantir que os dados do cliente sejam devidamente expandidos e configurados no SAP ERP. Figura 26 - Tratamento e Validação no SAP As-Is 78 crédito autorizado para o cliente, que é estabelecido com base nos resultados da análise de crédito. Adicionalmente, um gestor de cobrança é designado para gerir as finanças e monitorar o crédito do cliente, garantindo a adesão às práticas financeiras. Também se define a condição de pagamento, estipulando o prazo máximo para a quitação do crédito. Com estas definições implementadas, o cliente torna-se capacitado para realizar transações dentro dos parâmetros estabelecidos, assegurando a correta gestão das informações financeiras. Com isso, o ciclo de gestão de crédito no sistema é concluído. Para complementar o entendimento deste processo e aprofundar a análise da arquitetura atual, é fundamental explorar os principais Use cases relacionados com a criação de clientes. Estes casos de uso permitem visualizar de forma estruturada os diferentes cenários operacionais, as interações entre sistemas e utilizadores, bem como as exceções que podem ocorrer ao longo do processo. O mapeamento dos use cases da arquitetura atual fornece uma perspetiva prática sobre o funcionamento das integrações, ajudando a identificar pontos críticos, fragilidades e oportunidades de melhoria que serão fundamentais para a definição da arquitetura futura. 6.3.2 Use Cases da Arquitetura Atual As-Is No contexto da análise de integrações, os use cases representam uma ferramenta fundamental para a compreensão de como os processos operacionais ocorrem na prática. Um use case descreve, de forma estruturada e objetiva, as interações entre os utilizadores (atores) e os sistemas envolvidos, permitindo visualizar não apenas o fluxo principal das atividades, mas também cenários alternativos e exceções que podem ocorrer ao longo do processo. Esta abordagem torna-se particularmente relevante em ambientes complexos, onde diferentes sistemas e equipas interagem para garantir a execução eficiente dos processos de negócio. No âmbito deste estudo, os use cases desempenham um papel crucial ao fornecer uma visão detalhada dos diferentes cenários relacionados com o processo de criação de clientes, evidenciando o fluxo de informações entre o SAP e o BluJay. Eles destacam como os dados são inseridos, validados, processados e transmitidos entre os sistemas, permitindo identificar pontos críticos que podem impactar tanto a eficiência operacional quanto a integridade das informações. Esses pontos críticos incluem falhas de integração, áreas de retrabalho e lacunas nos mecanismos de validação de dados, que podem comprometer a qualidade das informações e a continuidade dos processos de negócio. 79 Além de oferecer uma perspetiva técnica, a análise dos use cases complementa o mapeamento das integrações com uma abordagem orientada aos processos de negócio, facilitando a identificação de oportunidades de melhoria e a definição de requisitos mais precisos para o desenvolvimento da arquitetura futura To-Be . Essa combinação entre a análise técnica e a perspetiva operacional permite não apenas compreender como o processo funciona atualmente, mas também identificar alterações que possam gerar ganhos de eficiência, reduzir erros e melhorar a governança dos dados. O levantamento dos use cases para o processo de criação de clientes foi realizado de forma colaborativa, com o objetivo de capturar a realidade operacional da arquitetura atual As-Is de maneira precisa e abrangente. O processo envolveu, principalmente, entrevistas com stakeholders do processo, conduzidas com colaboradores das áreas operacionais, técnicas e de gestão, incluindo key users do SAP e do BluJay, responsáveis pelo uso diário dos sistemas e pela execução dos processos de integração. Essas entrevistas permitiram identificar os principais desafios enfrentados, as exceções mais frequentes e as interações críticas entre os sistemas, oferecendo uma compreensão aprofundada dos fatores que afetam a performance e a confiabilidade das integrações. Além das entrevistas, foi realizada uma análise dos processos existentes, abrangendo o estudo de fluxos de trabalho documentados e das práticas operacionais em vigor. Este mapeamento foi fundamental para identificar pontos de falha, gargalos e lacunas na automação, permitindo uma compreensão mais profunda das causas subjacentes aos problemas de integração. O mapeamento do processo utilizou a notação BPMN, que proporcionou uma visão gráfica clara dos fluxos de trabalho e das interações entre sistemas. No entanto, enquanto o BPMN se concentra em representar graficamente os processos, os use cases complementam essa abordagem ao traduzir, de forma descritiva e orientada ao utilizador, os cenários operacionais mapeados, facilitando a compreensão das atividades do ponto de vista funcional. Na Tabela 9, apresenta-se a descrição dos principais use cases relacionados com o processo de criação de clientes no modelo atual As-Is . Estes casos ilustram tanto o fluxo principal de atividades quanto os cenários alternativos, evidenciando os pontos críticos da integração entre o SAP e o BluJay. 80 Tabela 9 - Use Cases As-Is Use Case Atores Envolvidos Objetivo Fluxo Principal Exceções ao Fluxo Criação de Cliente no TMS Negócio RIAM, Transportes IT, Corporate IT Ilustrar o processo de criação de um novo cliente no BluJay e a sua integração com o SAP. 1. O negócio cria um cliente no BluJay. 2. O código de cliente BJ é enviado ao SAP. 3. O SAP verifica se o cliente já existe no sistema. 4. Se não existir, o cliente é criado. 5. O SAP devolve as configurações de crédito ao BluJay. - Falha na comunicação entre SAP e BluJay. - Duplicação de registos por ausência de validação robusta. - Erros na sincronização de dados. Atualização de Dados Mestres do Cliente Departamento Financeiro, Corporate IT, Transportes IT Garantir a atualização de informações do cliente no SAP e sincronização com o BluJay. 1. O utilizador atualiza os dados do cliente no SAP. 2. O SAP envia as alterações para o BluJay. 3. O BluJay aplica as alterações e confirma o sucesso da operação. - Falhas de sincronização entre SAP e BluJay. - Dados desatualizados em operações críticas. - Inconsistências devido a erros de integração não detetados. A análise dos use cases apresentados visa aprofundar a compreensão dos processos de integração entre o SAP e o BluJay, complementando o mapeamento realizado anteriormente. Estes use cases oferecem uma perspetiva prática sobre o funcionamento dos processos, destacando não apenas o fluxo principal das atividades, mas também as exceções e desafios operacionais que podem surgir. A seguir, são descritos e analisados os use cases relacionados ao processo de criação e gestão de clientes. CRIAÇÃO DE CLIENTE NO TMS Este use case ilustra o processo de criação de um novo cliente no sistema de transporte BluJay e sua integração com o SAP. Os atores envolvidos incluem a equipa de negócio da RIAM, o departamento de Transportes IT e o Corporate IT, que juntos garantem que o processo seja concluído de forma eficiente. O objetivo deste use case é demonstrar como o cliente é criado inicialmente no BluJay, com o código do cliente sendo posteriormente enviado para o SAP. 81 No fluxo principal, o processo inicia-se com a criação do cliente no BluJay, seguida da verificação no SAP para identificar se o cliente já existe no sistema. Se o cliente não existir, ele é criado no SAP e, em seguida, o SAP devolve as configurações de crédito ao BluJay. Entre as exceções ao fluxo, destacam-se as falhas na comunicação entre o SAP e o BluJay, que podem interromper o processo de integração, a duplicação de registos devido à falta de validações robustas para verificar a existência prévia do cliente, e erros de sincronização de dados, que resultam em informações inconsistentes entre os sistemas. Estas exceções podem causar retrabalho, perda de dados e impactar a continuidade operacional, sendo frequentemente identificadas apenas quando afetam diretamente as operações do negócio. ATUALIZAÇÃO DE DADOS MESTRES DO CLIENTE Embora não esteja diretamente representado no mapeamento do processo de criação de clientes, o use case de atualização de dados mestres do cliente é fundamental para a gestão contínua da qualidade dos dados. Este processo envolve a DAF, o Corporate IT e o Transportes IT, refletindo a importância da colaboração entre diferentes áreas para garantir a integridade dos dados. O objetivo deste use case é assegurar que as alterações nos dados do cliente sejam atualizadas de forma sincronizada entre o SAP e o BluJay. O fluxo principal começa com o utilizador a realizar alterações nos dados do cliente no SAP. Após a atualização, o SAP envia essas alterações para o BluJay, onde são aplicadas e confirmadas. Este processo é crítico para garantir que informações relevantes, como dados de faturação e condições de pagamento, estejam sempre atualizadas em ambos os sistemas, evitando discrepâncias que possam afetar as operações do negócio. Nas exceções ao fluxo, identificam-se falhas de sincronização entre o SAP e o BluJay, que podem resultar em dados desatualizados em um dos sistemas, impactando processos como faturação e gestão de contratos. Além disso, erros de integração não detetados podem permanecer ocultos até que provoquem falhas operacionais mais evidentes, aumentando o risco de impacto negativo nas operações da empresa. Os use cases apresentados complementam de forma significativa o mapeamento da integração descrito anteriormente, proporcionando uma perspetiva mais detalhada e orientada aos processos de negócio. Enquanto o mapeamento com o BPMN foca na representação gráfica dos fluxos de integração e das interações entre sistemas, os use cases permitem uma compreensão mais prática e funcional dos processos. 82 Além disso, os use cases ajudam a identificar de forma mais precisa os pontos críticos do processo de integração, como falhas de comunicação, duplicação de registos e inconsistências de dados, que podem não ser evidentes apenas com o mapeamento BPMN. Em suma, a combinação do mapeamento da integração com a análise dos use cases oferece uma visão abrangente e detalhada do processo de criação e gestão de clientes, permitindo uma melhor identificação das limitações do modelo atual e contribuindo para o desenvolvimento de soluções mais eficazes na arquitetura futura. 6.4 Especificação Funcional: Criação De Clientes A segunda etapa do projeto chamada de especificação funcional To - Be consiste no levantamento de requisitos funcionais, sendo um processo fundamental para a conceção e implementação da nova integração destinada à criação de clientes. Neste capítulo, serão apresentados os temas relacionados com a definição e documentação desses requisitos, que desempenham um papel essencial na garantia de que as funcionalidades desenvolvidas atendam às necessidades do negócio e solucionem os problemas identificados anteriormente. Os requisitos funcionais descrevem, de maneira objetiva e detalhada, as funcionalidades e comportamentos esperados do sistema, representando um elo direto entre as demandas dos stakeholders e as soluções tecnológicas propostas. Para a definição dos requisitos funcionais, foram conduzidas novas reuniões com os intervenientes e stakeholders , permitindo uma compreensão aprofundada das necessidades e expectativas relacionadas com o processo de criação de clientes. Durante essas sessões, o foco foi a identificação de soluções específicas que resolvessem os problemas previamente mapeados, como a duplicação de cadastros, as inconsistências nos dados e as falhas de validação no sistema atual. Esse diálogo contínuo e colaborativo assegurou que os requisitos funcionais fossem alinhados com os objetivos do projeto, garantindo uma integração eficaz e a melhoria da gestão dos dados mestres no sistema SAP. Dessa forma, o levantamento dos requisitos funcionais representa uma etapa crítica para a transformação do processo, pois estabelece as bases para o desenvolvimento de soluções que promovem a consistência e integridade das informações corporativas. A abordagem sistemática adotada ao longo desse processo busca, assim, assegurar que os desafios identificados sejam efetivamente endereçados, contribuindo para a eficiência operacional e para a qualidade dos registos gerenciados pela organização. 83 6.4.1 Levantamento de Requisitos Funcionais Nesta seção, serão apresentados os requisitos funcionais para o processo de criação de clientes, com o objetivo de atender aos diferentes cenários operacionais e garantir a integração eficiente com o sistema SAP. Esses requisitos foram definidos em estreita colaboração com as áreas de negócio e os intervenientes do projeto, considerando as particularidades de cada contexto e buscando otimizar a qualidade e a eficácia do processo como um todo. Do ponto de vista das áreas de negócio, foram identificados quatro cenários principais apresentados na Tabela 10, que abrangem a diversidade de situações relacionadas com a criação de registos de clientes: Tabela 10 - Cenários que Devem Ser Abrangidos Cenários: Descrição: Clientes que utilizam como identificador fiscal o NIF Neste cenário, a validação do identificador fiscal é indispensável para assegurar a conformidade com os requisitos legais e a consistência dos dados nos sistemas corporativos, especialmente em geografias onde o NIF é o padrão reconhecido. Clientes das geografias onde o grupo possui unidades de negócio Este cenário abrange os clientes situados em regiões onde o grupo opera diretamente. Para esses casos, o identificador fiscal a ser utilizado deve respeitar os formatos específicos de cada localidade, conforme definido nas configurações internas do sistema. Essa abordagem visa garantir o alinhamento às particularidades fiscais locais e assegurar a precisão dos dados no cadastro. Clientes com identificador fiscal diferente do NIF Este cenário é projetado para atender a casos em que clientes possuem identificadores fiscais válidos, mas que não correspondem ao NIF, resultando em variações no preenchimento das informações. Tal abordagem assegura que as especificidades de cada identificador fiscal, conforme as regulamentações do país de origem do cliente, sejam respeitadas. Clientes sem identificador fiscal ou sem obrigatoriedade de uso Para clientes provenientes de regiões onde não há identificador fiscal atribuído ou onde sua utilização não é obrigatória, o sistema deve ser capaz de processar a ausência deste dado. Isso requer a adoção de critérios mínimos obrigatórios para a criação do cadastro, de forma a prevenir inconsistências e manter a integridade dos registos. 84 Dessa forma, os cenários e apresentados constituem uma base para o desenvolvimento do novo processo de integração. Essa abordagem visa não apenas resolver os desafios operacionais identificados, mas também promover a centralização, a confiabilidade e a eficiência na gestão dos dados mestres dos clientes, contribuindo para a excelência operacional e a sustentabilidade do sistema. REQUISITOS FUNCIONAIS Nesta seção, serão detalhados os requisitos funcionais do ponto de vista das áreas de negócio, estabelecidos para assegurar a eficiência e a conformidade no processo de criação de clientes. Esses requisitos refletem as necessidades operacionais mapeadas durante as reuniões com os intervenientes e são fundamentais para tratar os diferentes cenários identificados. CLIENTES QUE UTILIZAM O NIF COMO IDENTIFICADOR FISCAL O primeiro requisito funcional identificado está relacionado à validação do NIF como identificador fiscal padrão em geografias configuradas no sistema SAP. Como o SAP é um sistema desenvolvido por uma empresa alemã, suas configurações standard estabelecem o NIF como o formato de identificação fiscal para os países que integram suas definições de referência. Dessa forma, quando um cliente pertence a um dos países configurados no sistema, como ilustrado na Tabela 11, o SAP reconhece automaticamente a presença de um identificador fiscal no formato NIF. O NIF segue um padrão específico composto por nove dígitos numéricos no formato - XXX XXX XXX, aplicável a diversos países, independentemente de sua localização geográfica ou de sua associação à União Europeia. A Tabela 11 apresentada evidencia que, além de países europeus como: Alemanha, França e Portugal, o SAP também considera como utilizadores do NIF outros países fora da União Europeia, incluindo Angola, Moçambique, Estados Unidos, Mônaco, etc. Assim, a implementação deste requisito funcional assegura que, independentemente da região, o identificador fiscal utilizado seja validado no formato NIF, promovendo consistência, conformidade e integridade no processo de criação de registos no sistema SAP 85 . CLIENTES DAS GEOGRAFIAS ONDE O GRUPO POSSUI UNIDADES DE NEGÓCIO Este requisito funcional visa assegurar que, para clientes localizados em geografias onde o grupo possui unidades de negócio, o identificador fiscal utilizado esteja em conformidade com o formato padronizado apresentado na Tabela 12 .Este controle é fundamental para garantir a consistência e a integridade dos dados, facilitando a integração e o atendimento às exigências fiscais de cada país. Tabela 11 - Países Que Utilizam o NIF Como Identificador Fiscal Tabela 12 - Países Onde o Grupo Possui Unidades de Negócio 86 Na Tabela 12, é possível verificar a correspondência entre os países onde o grupo opera e os tipos de identificadores fiscais aceitos. Por exemplo, enquanto Portugal, Angola e Moçambique utilizam o NIF, o Brasil adota formatos específicos como Cadastro de Pessoa Física - CPF e o Cadastro Nacional de Pessoa Jurídica - CNPJ, e o México utiliza o Registro Federal de Contribuintes - RFC. Essa variabilidade reflete as particularidades regulatórias de cada região, que devem ser respeitadas no momento do registo dos clientes. CLIENTES COM IDENTIFICADOR FISCAL DIFERENTE DO NIF OU DAS GEOGRAFIAS DE OPERAÇÃO DO GRUPO Este requisito funcional tem como propósito garantir que, independentemente de o cliente estar associado a geografias que utilizam o NIF como padrão ou a regiões onde o grupo possui unidades de negócio, qualquer identificador fiscal fornecido seja devidamente registado no cadastro. Tal diretriz visa assegurar que o sistema seja flexível e abrangente, permitindo o registo de clientes provenientes de diferentes localizações, enquanto mantém a conformidade com os requisitos fiscais específicos apresentados. Ao implementar esta abordagem, o objetivo é estabelecer um cadastro consistente e adaptável, capaz de responder às necessidades únicas de clientes inseridos em contextos regulatórios diversos, promovendo maior eficiência no atendimento e na integração das operações dentro do sistema. CLIENTES SEM IDENTIFICADOR FISCAL OU SEM OBRIGATORIEDADE DE USO Este requisito funcional tem como objetivo atender aos clientes provenientes de geografias onde não há identificador fiscal atribuído ou em casos em que o seu uso não é obrigatório. Isso pode incluir, por exemplo, empresas de pequeno porte que, devido às suas características e regulamentações locais, não possuem um cadastro fiscal empresarial formalizado. Alguns exemplos de países que-se poderiam se enquadrar nesse cenário incluem regiões com regulamentações fiscais menos estruturadas ou onde o registo de empresas de pequena dimensão ainda é incompleto. Países como Haiti, Afeganistão e Laos, conhecidos por apresentarem desafios em termos de infraestrutura e formalização de negócios, são exemplos que ilustram esse contexto. Ao incluir essa possibilidade, o requisito busca deixar o sistema ser mais inclusivo, permitindo o registo de clientes sem obrigar a existência de um identificador fiscal, mas garantindo que todas as demais informações essenciais sejam registadas de forma consistente e organizada. Isso reforça a adaptabilidade 87 do cadastro e a sua capacidade de atender a uma ampla gama de contextos comerciais e regulatórios. 6.5 Arquitetura Futura To-Be : Criação de Clientes O subcapítulo Arquitetura Futura To-Be representa a fase final do projeto, na qual é apresentada a solução proposta (ver Apêndice 2 – Criação de Clientes To-Be) para atender aos requisitos funcionais e técnicos previamente identificados. Nesta etapa, o foco está na modelagem detalhada dos processos de negócios utilizando a notação BPMN. O fluxograma que ilustra a integração proposta pode ser encontrado abaixo, proporcionando uma visão geral da solução. A seguir, serão detalhadas as principais modificações sugeridas, destacando como cada ajuste contribui para alcançar maior eficiência e alinhamento com as necessidades do negócio, bem como a gestão eficaz de dados mestres. 6.5.1 Preenchimento de Dados Mínimos e Validação para Integração com o SAP Figura 36 - Preenchimento e Validação dos Dados Mínimos 94 Diferente da arquitetura atual, onde o processo começa com a criação do cliente diretamente no BluJay e o código do cliente é transmitido ao SAP sem validações antecipadas, a nova abordagem proposta integra uma série de verificações preliminares antes do registo no BluJay. Essas verificações são realizadas usando o SAP como o ponto de controle, garantindo que todos os dados do cliente sejam consistentes e atualizados antes de sua inserção no sistema. CRIAÇÃO DO CLIENTE EM SAP Após a sequência inicial de verificações relativas à geografia e ao identificador fiscal do cliente, o sistema SAP procede com o registo de um novo cliente (ver Figura 48). Esta etapa é fundamentada nos resultados das validações anteriores, assegurando que os dados mínimos, nomeadamente o Identificador Fiscal apenas seja armazenado de forma correta e garantindo um meio de identificação único para os clientes. A validação inicial questiona: "O cliente é de uma geografia que possui Identificador Fiscal?" (ver Figura 49). Este passo é crucial, pois estabelece a base para como o identificador fiscal do cliente será tratado Figura 47 - Validação de Cadastro Prévio na Empresa Que se Quer Criar o Cliente Figura 48 - Etapa de Criação do Cliente em SAP 95 dentro do sistema. Se a resposta for afirmativa e existir um identificador fiscal já preenchido nos dados mínimos fornecidos, o sistema avança para o subprocesso de Validação do Identificador Fiscal. Este subprocesso verifica a precisão e a conformidade do identificador fiscal com os padrões estabelecidos, garantindo a integridade dos registos. Por outro lado, se a resposta for negativa, ou seja, se não houver um identificador fiscal associado ao cliente na geografia especificada, o sistema segue para o subprocesso de Atribuição de ID Único. Este passo envolve a criação de um identificador único para o cliente dentro do SAP, assegurando que todas as transações futuras possam ser adequadamente rastreadas e gerenciadas, mesmo na ausência de um NIF padrão. Esta abordagem sistematizada garante que todos os clientes, independentemente de sua localização geográfica ou da especificidade fiscal, sejam tratados de maneira uniforme e consistente no sistema SAP. SUBPROCESSO DE VALIDAÇÃO DO IDENTIFICADOR FISCAL O subprocesso de validação do Identificador Fiscal apresentado na Figura 50 começa com a verificação da morada do cliente, uma etapa importante que determina a aplicabilidade das normas fiscais específicas relacionadas com sua localização geográfica. Esta validação, realizada através dos dados mínimos Figura 49 - Validar a Utilização de Qualquer Identificador Fiscal Figura 50 - Subprocesso de Validação do Identificador Fiscal 96 fornecidos, é importante para assegurar que o cliente esteja sujeito às normas fiscais apropriadas para a sua região geográfica, garantindo conformidade com os requisitos fiscais locais e internacionais. Após a validação da morada, o sistema procede à avaliação do uso do NIF pelo cliente. Se o cliente utilizar o NIF, indicando sua localização numa região que exige tal identificador, este é registado no campo 'Nº ID Fiscal-IVA' no sistema SAP. Caso contrário, se o cliente não utilizar o NIF — seja por estar em uma região que não exige este tipo de identificador ou por usar um diferente — o sistema direciona para o preenchimento de um identificador fiscal alternativo nos campos 'Nº ID Fiscal 1' ou 'Nº ID Fiscal 2'. Esta flexibilidade permite acomodar clientes de diferentes regiões, garantindo que todos os identificadores fiscais sejam corretamente registados no sistema. Com o identificador fiscal apropriadamente inserido, o processo avançará para a fase final de criação do cliente no SAP. Este passo é vital para a validação completa do identificador fiscal e desempenha um papel fundamental na garantia da integridade dos dados dos clientes. SUBPROCESSO DE ATRIBUIÇÃO DE ID ÚNICO O subprocesso de atribuição de Identificador Único - ID Único - no SAP como mostra a Figura 51 iniciase com uma validação manual dos dados mínimos do cliente, essencial para identificar possíveis correspondências já existentes no sistema. Esta etapa assume uma importância crítica, especialmente para clientes oriundos de regiões que não utilizam um identificador fiscal padrão, exigindo a verificação de nomes ou emails já registados para evitar duplicações e assegurar a integridade dos dados. Se durante a validação forem encontrados registos correspondentes no sistema, esses dados preexistentes serão aproveitados para continuar com o cadastro do cliente. Esta abordagem não só otimiza o processo de registo, evitando redundâncias, como também mantém a continuidade das informações dentro do sistema. Figura 51 - Subprocesso de Atribuição de ID Único 97 Na situação em que não haja correspondências, procede-se à atribuição de um ID operacional ao cliente. Este código de identificação é único e sequencial, composto por um prefixo alfanumérico que representa a geografia do cliente, seguido de um número que denota sua sequência de registo. Este identificador único é registado no campo 'Nº ID Fiscal 1', garantindo uma identificação precisa e organizada dentro do SAP. A conclusão deste processo resulta na criação de um ID único, permitindo a subsequente inclusão do cliente no SAP. Este procedimento não só assegura a precisão dos dados registados como também reforça a conformidade fiscal, contribuindo para uma administração eficiente dos registos de clientes. Assim, mesmo clientes de regiões sem um identificador fiscal específico podem ser identificados de forma única através do ID Operacional, assegurando uniformidade nos processos independentemente das variações geográficas e fortalecendo a integridade e rastreabilidade dos dados em toda a organização. CRIAÇÃO DO CLIENTE EM SAP Após a definição dos campos específicos que armazenarão o identificador fiscal do cliente, o processo de registo do cliente na Base de Dados SAP é formalmente iniciado (ver Figura 52). Neste ponto crucial, as informações validadas do cliente são cuidadosamente inseridas na base de dados do SAP, levando à geração de um código único SAP. Esse código, que identifica exclusivamente o cliente dentro do sistema SAP, é crucial para o rastreamento interno e a gestão de interações futuras. Para as integrações com o BluJay, no entanto, o identificador fiscal do cliente torna-se o código primário utilizado, assegurando a uniformidade e a precisão na sincronização entre os dois sistemas. Figura 52 - Registo na Base de Dados SAP 98 VALIDAÇÃO DO GRUPO DE CRÉDITO Nessa etapa da arquitetura futura apresentada na Figura 53, o processo de gestão de crédito no SAP começa com a verificação da existência de um grupo de crédito para o cliente. Um grupo de crédito no SAP é definido por: plafond, gestor de cobrança e condições de pagamento, que estabelecem a estrutura de crédito do cliente. Este procedimento não sofre alterações na solução proposta, mantendo a consistência entre o cenário atual e o futuro. Para novos clientes ou aqueles que não possuem um grupo de crédito estabelecido, o processo inicia com a definição de um plafond. Esta fase é importante para determinar o limite de crédito que será aplicado nas transações comerciais do cliente. Após estabelecer o plafond, o processo avança para outras configurações essenciais, como a nomeação de um gestor de cobrança e a definição das condições de pagamento. 6.5.3 Avaliação de Crédito e Configuração Final A Figura 54 é a representação da fase final do processo de integração de criação de clientes, com ênfase na avaliação de crédito e configuração final do cliente dentro do sistema BluJay. Este segmento é crucial para a verificação e processamento dos dados dos clientes, assegurando que todas as informações sejam precisas e efetivamente integradas antes de sua inserção definitiva no sistema de gestão. Figura 53 - Validações de Grupo de Crédito 99 INTEGRAÇÃO DE DADOS CLIENTE SAP-BLUJAY Figura 54 - Avaliação de Crédito e Configuração Final Figura 55 - Integração dos Dados do Cliente SAP para Blujay 100 Na arquitetura futura proposta, o processo de integração de clientes entre o SAP e o sistema BluJay foi significativamente aprimorado para aumentar a eficiência e precisão na gestão de dados (ver Figura 55). Esta etapa começa com a receção do código SAP no TIBCO, encarregado de preparar e estruturar os dados para integração. Assim que os dados estão devidamente formatados, eles são transmitidos ao BluJay Na nova estrutura, a equipa de Transportes IT do BluJay realiza um mapeamento da interface para as informações do cliente recebidas do SAP. Este passo é fundamental para assegurar que os dados sejam corretamente interpretados e implementados no sistema BluJay, estabelecendo o cliente como tipo "Financial" com base nas informações originadas do SAP. A criação do cliente segue com a geração de um código específico no BluJay, que facilita sua identificação única dentro do sistema. Esta abordagem reforçada garante que todos os dados do cliente em BluJay sejam consistentes com os registos centralizados no SAP. Contrastando com o cenário atual, onde o fluxo de integração começava com a receção do código do cliente SAP no TIBCO sem estruturações prévias adequadas, o que podia resultar em sincronização e precisão deficientes dos dados entre o SAP e o BluJay. AVALIAÇÃO E CONFIGURAÇÃO DE CRÉDITO DO CLIENTE Figura 56 - Avaliação e Configuração de Crédito do Cliente 101 Na arquitetura futura proposta, o fluxo de integração mantém esta etapa sem alterações significativas em relação ao cenário atual como evidenciado na Figura 56. Este estágio final do processo começa com a atualização dos dados mestre do cliente no sistema. Segue-se uma verificação para avaliar se as condições de crédito pré-existentes atendem às necessidades atuais do cliente. Se as condições forem consideradas adequadas, o processo de integração é concluído. Caso contrário, inicia-se uma solicitação de ajustes no crédito. Esta solicitação envolve a elaboração detalhada das necessidades específicas, incluindo a identificação do solicitante, a definição do limite de crédito ( plafond ), o prazo de pagamento estabelecido e os argumentos comerciais justificativos. Cada solicitação é meticulosamente avaliada conforme as políticas de crédito da empresa, assegurando que as decisões financeiras sejam aplicadas de forma consistente e alinhada com os padrões corporativos. 6.5.4 Use Cases Arquitetura Futura To-Be A definição de use cases para a arquitetura futura proposta To-Be desempenha um papel essencial na validação das melhorias projetadas para o processo de criação de clientes e sua integração entre SAP e BluJay. Esses use cases permitem não apenas ilustrar o funcionamento dos novos fluxos operacionais, mas também demonstrar como as otimizações impactam diretamente a eficiência, reduzem erros e fortalecem a governança de dados. Ao traduzirem os requisitos funcionais em cenários práticos de utilização, os use cases garantem que a arquitetura To-Be esteja alinhada às necessidades do negócio e às melhores práticas de integração. A abordagem adotada para a definição dos use cases To-Be baseou-se nos seguintes pilares: levantamento dos requisitos funcionais, análise das lacunas identificadas no modelo As-Is e alinhamento com as melhores práticas de integração recomendadas. Primeiramente, os requisitos foram estruturados com base nas necessidades operacionais previamente mapeadas e nas expectativas das equipas envolvidas no processo de integração. Em seguida, as fragilidades detetadas na arquitetura atual foram analisadas para garantir que os novos fluxos abordassem os principais pontos críticos, tais como falhas de sincronização, ausência de validações robustas e dependência de processos manuais. Os use cases To-Be foram projetados para garantir uma arquitetura mais resiliente, modular e adaptável às necessidades da organização, minimizando riscos e garantindo um fluxo de dados mais preciso e confiável. Além disso, a definição desses use cases seguiu um princípio de escalabilidade, permitindo que os aprimoramentos implementados no processo de criação de clientes possam futuramente ser replicados para outros fluxos operacionais dentro do ecossistema de sistemas da organização. 102 Na Tabela 13, serão apresentados e analisados os principais use cases da arquitetura To-Be , demonstrando a evolução do processo e os ganhos esperados com as novas abordagens de integração. Tabela 13 - Use Cases To-Be Use Case Atores Envolvidos Objetivo Fluxo Principal Exceções ao Fluxo Criação de Cliente no TMS Negócio RIAM, Transportes IT, Corporate IT Garantir a criação estruturada de clientes no BluJay e sua correta integração com o SAP, minimizando falhas e duplicações. 1. O negócio insere os dados mínimos obrigatórios no BluJay. 2. O sistema valida os dados e verifica a existência do cliente no SAP. 3. Caso não exista, o cliente é criado no SAP e suas configurações de crédito são atribuídas. 4. O SAP devolve as configurações de crédito e manda sinal para criar o cliente em BluJay. - Falha na Validação: Dados incompletos ou incorretos impedem a criação do cliente. - Duplicação de Registos: O identificador fiscal já existe no sistema. - Erro na Comunicação: Falha na sincronização impede a finalização da criação do cliente. Validação de Identificador Fiscal Corporate IT Garantir que os clientes sejam criados com um identificador fiscal único e válido, reduzindo erros manuais e inconsistências. 1. O utilizador insere os dados minimos do cliente no BluJay. 2. O sistema verifica automaticamente se o identificador fiscal ou o ID Único já existe no SAP. 3. Se existir, os dados do cliente são carregados automaticamente, evitando duplicações. 4. Caso não exista, a criação do cliente prossegue com preenchimento manual do cadastro do cliente. - Identificador Fiscal Inválido: O sistema rejeita números incorretos e solicita revisão manual. - Dados Divergentes: Caso os dados carregados do SAP não coincidam com os informados pelo utilizador, uma validação adicional é necessária. Validação e Envio de Dados Mínimos Negócio RIAM, Transportes IT Garantir que os dados enviados do BluJay para o SAP sejam completos e validados antes da integração. 1. O negócio tenta criar o cliente. 2. O BluJay valida os dados antes de permitir a integração. 3. Se aprovados, o processo segue normalmente. 4. Se houver erro, o utilizador recebe um alerta para correção. - Campos Obrigatórios Faltando: a Equipa de Transporte IT rejeita a integração e solicita correção. - Formato Inválido: Dados inseridos de maneira incorreta impedem a sincronização. 103 Os use cases definidos para a arquitetura proposta To-Be demonstram avanços significativos na estruturação do processo de criação de clientes, garantindo maior eficiência, segurança e governança dos dados. A implementação de validações automáticas e mecanismos robustos de sincronização visa corrigir as fragilidades do modelo atual, minimizando erros e reduzindo a necessidade de intervenções manuais. CRIAÇÃO DE CLIENTE NO TMS No modelo To-Be , o processo de criação de clientes passa a contar com validações estruturadas que garantem a inserção correta dos dados desde a sua origem. No modelo As-Is , a ausência de um controle rigoroso permitia a criação de clientes com informações incompletas ou inconsistentes, resultando em falhas de sincronização e necessidade de correções manuais. Com a nova abordagem, antes de ser enviado ao SAP, o sistema BluJay valida os dados inseridos, verificando a existência do cliente e garantindo que todas as informações obrigatórias estejam preenchidas corretamente. A implementação dessa validação prévia elimina um dos principais problemas da versão As-Is : a duplicação de clientes. No processo anterior, clientes poderiam ser criados mais de uma vez caso variações no identificador fiscal não fossem detetadas. Agora, o sistema identifica automaticamente clientes já existentes e bloqueia a criação de registos redundantes, assegurando maior integridade dos dados. Além disso, melhorias na comunicação entre os sistemas reduzem falhas na transmissão de informações, garantindo que todas as configurações de crédito sejam corretamente atribuídas ao cliente no momento da sua criação. As exceções ao fluxo incluem a possibilidade de dados incompletos ou inválidos, que, no modelo proposto, geram um alerta automático para o utilizador antes que a criação do cliente seja concluída. Com isso, evita-se a propagação de informações incorretas nos sistemas, promovendo maior qualidade e segurança na base de dados. VALIDAÇÃO DE IDENTIFICADOR FISCAL Outro avanço relevante na nova arquitetura é a introdução de uma validação automática do identificador fiscal no momento da criação do cliente. No modelo As-Is , a ausência desse controle permitia que clientes fossem registados sem um identificador válido ou, em alguns casos, com identificadores genéricos, levando a problemas fiscais e operacionais. No To-Be , o sistema verifica de forma automatizada se o identificador fiscal informado já existe no SAP. Caso esteja registado, os dados do cliente são carregados automaticamente, evitando a necessidade de preenchimento manual e minimizando erros. 110 O modelo To-Be propõe um processo mais complexo, mas estruturado, com validações adicionais e uma arquitetura modular. Apesar de exigir maior esforço de configuração inicial, essa abordagem garante maior robustez e resiliência, permitindo que o sistema suporte melhor demandas crescentes e mudanças futuras. Os ganhos esperados incluem maior estabilidade e redução da necessidade de intervenções corretivas, além de maior escalabilidade para suportar operações mais complexas no futuro. 7.1.6 Preparação para Expansões No modelo atual, a falta de flexibilidade da arquitetura dificulta a integração de novos sistemas ou a expansão para novas geografias, resultando em altos custos e longos prazos de implementação. A arquitetura To-Be foi projetada para ser modular e adaptável, permitindo que novos sistemas ERP sejam integrados de forma eficiente. Além disso, o uso de APIs nativas do SAP facilita a padronização dos fluxos de dados, reduzindo a complexidade de configurações específicas para cada geografia. O principal ganho teórico aqui é a redução significativa de custos e tempos associados a futuras expansões, possibilitando uma maior agilidade na entrada em novos mercados e no alinhamento com as demandas globais. 7.1.7 Conformidade com Boas Práticas A escrita direta na base de dados no modelo atual viola as recomendações da SAP, comprometendo a capacidade de obter suporte técnico oficial e aumentando os riscos associados à manutenção do sistema. O modelo To-Be segue integralmente as boas práticas recomendadas pela SAP, incluindo o uso da camada de aplicação e APIs. Isso não apenas melhora a segurança e a confiabilidade do sistema, mas também assegura maior suporte técnico, compatibilidade com futuras atualizações e redução de custos de manutenção a longo prazo. Esse alinhamento com padrões reconhecidos também promove uma maior longevidade da solução, garantindo que a organização se beneficie de inovações futuras sem a necessidade de reconfigurações complexas. 111 7.2 Impactos Organizacionais Esperados A adoção da arquitetura To-Be proposta neste estudo tem o potencial de gerar impactos significativos na organização, tanto no âmbito operacional quanto na gestão estratégica. Ao abordar diretamente as limitações do modelo atual As-Is e propor melhorias no fluxo de integração e na governança de dados, a nova arquitetura tem a expectativa de promover avanços que transcendem os aspetos técnicos, influenciando de forma positiva a cultura organizacional e a eficiência dos processos internos. Em primeiro lugar, a implementação da nova arquitetura pode contribuir de maneira substancial para a melhoria da eficiência operacional e da gestão de dados organizacionais. A centralização das informações no ERP, combinada com a validação rigorosa dos dados antes de sua integração, reduz significativamente erros operacionais, duplicação de registos e inconsistências entre sistemas. Com processos mais confiáveis e bem estruturados, as operações tornam-se mais ágeis e organizadas, permitindo que os colaboradores dediquem mais tempo a atividades estratégicas, reduzindo o esforço gasto com correções manuais e retrabalho. No caso específico da equipa de suporte ao sistema SAP, que atualmente investe uma grande parcela de tempo na resolução de problemas relacionados às integrações, a nova arquitetura permitirá que esses colaboradores se concentrem em atividades de desenvolvimento e melhorias contínuas, agregando mais valor às operações organizacionais. Além disso, a adoção da nova arquitetura exigirá mudanças culturais dentro da organização, especialmente em relação a capacitação das equipas e ao alinhamento entre os departamentos. Os colaboradores operacionais, responsáveis pela coleta dos dados mínimos necessários para a criação de clientes nas diversas geografias, deverão ser capacitados para garantir que essas informações sejam inseridas de forma correta e completa, respeitando a obrigatoriedade de identificadores fiscais válidos. Essa mudança representa uma rutura com práticas anteriores, como o uso de identificadores fiscais genéricos ou a ausência de preenchimento adequado. O incentivo à adoção de padrões mais rigorosos para entrada de dados não apenas reforça a confiabilidade das informações no ERP, mas também contribui para uma transformação cultural que será essencial para o sucesso da integração. Por fim, espera-se que a nova arquitetura fortaleça a governança de dados, promovendo maior transparência e controle nos processos organizacionais. Com a documentação dos fluxos de integração e dos processos agora devidamente formalizada, a governança de dados será consolidada, com responsabilidades claramente definidas. Práticas anteriormente comuns, como o excesso de handovers entre equipas, que frequentemente resultavam em confusões e perda de informações, deverão ser eliminadas. Essa transformação cultural, ao estabelecer limites claros e evitar transferências desnecessárias de responsabilidade, trará maior clareza e eficiência aos processos internos. Além disso, essa estruturação 112 fortalecerá o comprometimento dos colaboradores com os padrões organizacionais definidos, contribuindo para o alinhamento estratégico da empresa. Em suma, a adoção da nova arquitetura To-Be não apenas moderniza os processos de integração e gestão de dados, mas também promove uma transformação organizacional mais ampla. Com ganhos expressivos na eficiência operacional, alinhamento cultural e transparência nos processos, esses avanços posicionam a organização de forma estratégica para enfrentar desafios futuros com maior resiliência e adaptabilidade. 7.3 Possíveis Métricas e Indicadores de Sucesso A implementação da arquitetura To-Be visa otimizar a eficiência operacional e a estrutura organizacional da empresa. Para medir esses impactos, torna-se essencial a utilização de métricas e KPIs que permitam avaliar a efetividade das mudanças. A análise dos dados do Helpdesk revelou um crescimento significativo na proporção de tickets de suporte relacionados a erros de integração entre SAP e BluJay, com impacto direto na alocação de recursos da equipa de suporte. Em 2023, foram registados 1.408 tickets, dos quais 514 (36,5%) se referiam a falhas de integração, consumindo 1.348 horas de suporte 49,5% do tempo total da equipa de Corporate IT. Até setembro de 2024, 961 tickets foram reportados, sendo 372 ou seja 38,7% dos tickets atribuídos a integrações, totalizando 505 horas de suporte. Com a nova arquitetura, espera-se uma redução significativa do número de tickets de erro e do tempo médio de resolução, permitindo que a equipa de suporte dedique mais tempo a iniciativas estratégicas. Além dos KPIs já existentes – número de tickets de erros de integração, tempo médio de resolução– novas métricas podem ser implementadas para quantificar os benefícios esperados, tais como as apresentadas na Tabela 16 .A implementação desses KPIs permitirá à organização acompanhar os resultados da adoção da nova arquitetura de maneira estruturada e orientada a dados. Além disso, a avaliação contínua desses indicadores fornecerá informações para ajustes futuros, garantindo que as melhorias propostas contribuam efetivamente para a eficiência operacional e a governança organizacional. 113 Tabela 16 - Propostas de KPIs KPI: Descrição: Objetivo pós-implementação: Erros de integração Ocorrência de falhas como duplicação de clientes, inconsistências nos dados transferidos entre os sistemas e problemas de validação que comprometem a integridade da informação. Diminuir Tempo de processamento entre ERP e TMS Mede o tempo necessário para que uma transação realizada no ERP seja refletida no TMS. Esse indicador avalia a eficiência da sincronização de dados e o impacto do processamento síncrono no tempo de resposta dos sistemas. Diminuir Taxa de aceitação pelos stakeholders internos Mede a adesão dos colaboradores às novas práticas e processos implementados, incluindo o correto preenchimento de identificadores fiscais e a inserção de dados conforme os padrões definidos. Aumentar Confiabilidade dos dados integrados Percentual de registos aceites na primeira tentativa de integração, sem a necessidade de correção ou reenvio. Também avalia a frequência de falhas nas validações dos dados antes da integração. Aumentar Tempo de treinamento necessário Tempo médio necessário para capacitar os colaboradores na utilização das novas práticas e sistemas, refletindo o esforço organizacional exigido para adaptação às mudanças. Diminuir 114 8. CONCLUSÃO E TRABALHOS FUTUROS No Capítulo Oito, são apresentadas as principais conclusões desta dissertação, com uma síntese dos resultados alcançados e dos contributos do trabalho para a melhoria da integração entre os sistemas SAP e BluJay no Grupo Rangel. Além disso, são reconhecidas as limitações do estudo, que abriram espaço para futuras investigações, e são sugeridas linhas de trabalho que poderão complementar e aprofundar os resultados obtidos, contribuindo para o avanço no campo da logística e da gestão de integrações organizacionais. 8.1 Conclusão dos Resultados da Investigação Este projeto de investigação teve como foco a revisão e reestruturação das integrações entre os sistemas ERP - SAP e TMS - BluJay no Grupo Rangel, uma organização de referência no setor logístico. Inserido em um contexto operacional altamente complexo, o estudo buscou analisar as limitações do modelo atual das integrações entre os sistemas e propor uma nova arquitetura funcional futura To-Be , capaz de atender às necessidades dos utilizadores e superar os desafios identificados, promovendo ganhos operacionais e organizacionais significativos. A investigação permitiu a identificação detalhada das limitações do modelo As-Is , evidenciando problemas críticos que impactavam diretamente a eficiência e confiabilidade das integrações. Entre as principais lacunas, destacam-se: a escrita direta na base de dados do SAP, a ausência de validações robustas, as inconsistências de dados entre sistemas e a falta de governança formal nos processos de integração. Essas limitações não apenas comprometeram a precisão e a rastreabilidade das informações, mas também resultaram em um elevado volume de tickets de suporte classificados como problemas de integração. Esse cenário desviava recursos valiosos da equipa técnica para a resolução de falhas repetitivas, em detrimento de atividades de melhoria e inovação. A documentação dessas lacunas foi essencial para estabelecer uma base sólida para o desenvolvimento de soluções mais alinhadas às melhores práticas do setor. Com base na análise do modelo atual, foi desenvolvida uma proposta para a arquitetura To-Be, delineando melhorias relevantes que visam mitigar os problemas identificados. Entre as alterações sugeridas, destacam-se a substituição da escrita direta na base de dados pelo uso da Camada de Aplicação nativa do SAP — medida que assegura maior aderência às boas práticas e reforça a segurança e integridade dos dados — a introdução de validações sistemáticas antes da inserção de informações no ERP e o 115 processamento síncrono entre os sistemas, que busca melhorar a fluidez e confiabilidade da comunicação entre plataformas. Essas propostas foram concebidas a partir de uma análise crítica das limitações observadas e fundamentam-se em boas práticas de integração de sistemas empresariais. Embora ainda não tenham sido implementadas, os ganhos projetados apontam para melhorias significativas na governança de dados, na escalabilidade da solução e na eficiência do processo de criação de clientes — considerado estratégico dentro da operação. O projeto também evidencia potenciais avanços organizacionais, ao promover maior alinhamento entre departamentos, capacitação das equipas operacionais envolvidas na gestão de dados e formalização de responsabilidades associadas à governança da informação. Mesmo sem uma aplicação prática imediata, a dissertação oferece uma contribuição relevante ao proporcionar uma visão estruturada das fragilidades do modelo atual e ao propor caminhos concretos para sua evolução. A limitação do âmbito — centrado no processo de criação de clientes — e a ausência de validação prática abrem possibilidades para investigações futuras, que poderão explorar a aplicação da proposta em outros fluxos e contextos operacionais. Em síntese, esta investigação representa um avanço na compreensão das barreiras técnicas e organizacionais à integração de sistemas num operador logístico internacional e estabelece uma base teórica sólida para futuras implementações. 8.2 Reconhecimento de Lacunas e Limitações Gerais Embora esta pesquisa tenha atingido seus objetivos principais e oferecido contribuições relevantes para a integração entre os sistemas SAP e BluJay no Grupo Rangel, é importante reconhecer algumas limitações que restringiram o alcance e a profundidade da análise realizada A principal limitação do estudo reside na ausência de uma implementação prática da arquitetura To-Be , o que impediu a obtenção de dados concretos para medir os impactos reais das melhorias propostas. Dessa forma, a análise permaneceu no campo teórico e qualitativo, fundamentando-se em projeções estruturadas a partir do diagnóstico da situação atual. Embora bem embasadas, essas projeções ainda carecem de validação em contexto operacional real. Além disso, o âmbito do estudo foi intencionalmente delimitado ao processo de criação de clientes, escolhido por seu caráter estratégico para a organização, deixando de fora outros fluxos igualmente relevantes, como faturamento, gestão de fornecedores e controle financeiro, que também poderiam beneficiar-se de abordagens similares. A ausência de dados práticos limitou a capacidade de estimar com precisão os impactos operacionais da proposta, como ganhos em eficiência, redução de falhas ou benefícios financeiros diretos. Ainda assim, essa limitação não compromete o valor da contribuição deste trabalho. Ao contrário, reforça seu 116 papel como base inicial para futuras iniciativas que possam aprofundar a análise aqui desenvolvida. A aplicação prática da arquitetura To-Be será fundamental para validar os pressupostos teóricos apresentados, possibilitando mensurações mais concretas de indicadores como a confiabilidade das integrações, o tempo de resposta entre sistemas e a consistência dos dados ao longo do fluxo operacional. Além disso, a realização de uma análise de custos e viabilidade em diferentes cenários organizacionais poderá oferecer insights adicionais sobre os recursos necessários para a aplicação da solução e os benefícios econômicos associados. Outras oportunidades incluem a realização de testes em geografias adicionais, considerando as especificidades regionais e legais que podem impactar a integração entre sistemas, e a expansão da arquitetura para processos complementares, como a integração de dados financeiros, gestão de transportes e indicadores de desempenho organizacional. Essas iniciativas não apenas fortalecerão os resultados já apresentados, como também ampliarão o impacto prático e acadêmico deste trabalho, contribuindo ainda mais para o avanço da gestão integrada no setor logístico. 8.3 Contribuição Para a Área de Estudo Esta dissertação oferece contribuições significativas tanto para a literatura académica como para o setor logístico, ao abordar de forma prática e detalhada os desafios e soluções associados à integração entre os sistemas SAP e BluJay. Uma das principais inovações deste trabalho reside em diminuir a lacuna existente na literatura, que frequentemente aborda setores como manufatura e retalho, negligenciando o setor logístico, apesar da sua crescente complexidade e relevância. A investigação apresentada concentra-se na realidade desafiante de uma empresa logística de grande dimensão, como o Grupo Rangel, explorando de que forma os processos de integração tecnológica podem ser otimizados para melhorar a eficiência operacional e reforçar a governança de dados. Adicionalmente, este estudo propõe uma abordagem prática que pode ser replicada em organizações com estruturas e desafios similares aos do Grupo Rangel. A análise das limitações do modelo atual AsIs e a conceção de uma nova arquitetura funcional To-Be constituem um referencial técnico e metodológico que pode servir de orientação para outras empresas que enfrentam dificuldades semelhantes no âmbito da integração de sistemas. Este caráter aplicado é reforçado pela apresentação de melhorias baseadas em práticas recomendadas internacionalmente, tais como a utilização de API nativas do SAP, a implementação de validações rigorosas para os dados e a introdução de processamento síncrono entre sistemas. 117 A dissertação também oferece insights relevantes sobre a integração Enterprise Resource Planning - Transportation Management System , uma área crítica para o setor logístico em um cenário de crescente globalização e exigência por maior precisão e agilidade nos serviços. A arquitetura To-Be proposta serve como um modelo conceitual útil para a reestruturação de processos-chave, como a criação de clientes, promovendo maior potencial de confiabilidade na transferência de informações entre sistemas e maior alinhamento com as necessidades operacionais das organizações. Assim, o trabalho contribui para o aprofundamento do conhecimento técnico e organizacional no setor logístico, oferecendo diretrizes iniciais que podem orientar futuras implementações e validações práticas de soluções mais integradas e eficazes. Por fim, esta investigação destaca a importância de uma atenção mais direcionada ao setor logístico na produção académica e técnica, incentivando o desenvolvimento de soluções integradas e personalizadas para as necessidades específicas deste segmento. Ao combinar uma análise das limitações do modelo atual com uma proposta de melhorias funcionais, o trabalho reforça o entendimento sobre os processos de integração ERP-TMS e estabelece uma base sólida para futuras investigações e implementações no campo da logística e da gestão tecnológica. 8.4 Recomendações Para Trabalhos Futuros Embora esta investigação tenha atingido os seus objetivos principais e fornecido uma análise detalhada das limitações e potenciais melhorias no modelo de integração entre o ERP e o TMS, existem várias oportunidades para expandir e aprofundar o estudo, garantindo uma avaliação mais abrangente dos impactos da arquitetura proposta. Uma das principais recomendações para trabalhos futuros é a validação prática da arquitetura To-Be , através da sua implementação e monitorização em ambiente real. A análise dos resultados obtidos poderá ser realizada com base nos KPIs sugeridos, como a redução de erros de integração, o tempo médio de processamento entre sistemas e a melhoria na fiabilidade dos dados. A validação prática permitirá não apenas confirmar os benefícios teóricos delineados nesta dissertação, mas também identificar desafios adicionais que possam surgir durante a implementação. Outro aspeto fundamental a ser explorado é a necessidade de monitorização ativa com alarmes, através do desenvolvimento de sistemas capazes de detetar e reportar falhas automaticamente. A introdução de mecanismos de monitorização em tempo real traria ganhos substanciais para a governança de dados, possibilitando uma resposta proativa a erros e assegurando a estabilidade das integrações. Além disso, 118 um sistema de alertas bem estruturado pode minimizar o tempo de resposta da equipa técnica e reduzir significativamente o impacto operacional das falhas. Além do processo de criação de clientes, a expansão da arquitetura To-Be para outros processos críticos representa uma oportunidade relevante para a evolução da pesquisa. Processos como facturamento, gestão de transportes e controle financeiro também dependem de integrações robustas e fiáveis para garantir a eficiência das operações. Avaliar a aplicabilidade da arquitetura To-Be nestes contextos poderia fornecer uma visão mais completa dos seus benefícios e desafios, permitindo um refinamento contínuo do modelo. A realização de uma análise económica detalhada sobre os custos e benefícios da implementação da arquitetura To-Be também constitui uma linha de investigação valiosa. A identificação do investimento necessário, dos potenciais retornos financeiros e das economias geradas pela redução de erros e pela otimização dos processos contribuiria para fundamentar a tomada de decisão organizacional, tornando o modelo mais viável do ponto de vista estratégico e financeiro Por fim, recomenda-se um estudo da arquitetura To-Be em diferentes geografias, avaliando a sua adaptabilidade a distintos contextos regionais. Empresas logísticas operam frequentemente em múltiplas jurisdições, onde requisitos regulatórios, fiscais e operacionais variam significativamente. A aplicação da arquitetura em diferentes regiões permitiria verificar a sua flexibilidade e eficácia, garantindo que as soluções propostas possam ser replicadas e ajustadas conforme necessário. Desta forma, os caminhos sugeridos para trabalhos futuros complementam as contribuições deste estudo, permitindo a sua validação prática e expansão para novos cenários e processos. A continuidade da investigação neste domínio reforçará a maturidade das soluções propostas, consolidando a importância de abordagens tecnológicas estruturadas para a otimização da integração de sistemas no setor logístico. 119 REFERÊNCIAS BIBLIOGRÁFICAS Anthuanett, L., & Padilla, N. (2014). Transformation of Business Process Models: A Case Study . ApiX-Drive. (2024). What is Tibco and How It Works | ApiX-Drive . https://apixdrive.com/en/blog/other/what-is-tibco-and-how-it-works Balasubramanian, K., Schmidt, D. C., Molnár, Z., & Lédeczi, Á. (2008). System Integration using ModelDriven Engineering * . Baskerville, R. L., Myers, M. D., & Yoo, Y. (2020). Digital first: The ontological reversal and new challenges for information systems research. MIS Quarterly: Management Information Systems , 44 (2), 509– 523. https://doi.org/10.25300/MISQ/2020/14418 BluJay Solutions. (2025). BluJay TMS Reviews . https://www.selecthub.com/p/tms-software/blujay-tms/ Bowersox, D. J., & Closs, D. J. (2020). Supply Chain Logistics Management (M. Education, Ed.; 5th ed.). BPMN. (2025). BPMN Specification - Business Process Model and Notation . https://www.bpmn.org/ Camargo, L., Magno, B., & Alegre, P. (2013). Proposta de Solução de Redução do volume de Devoluções em uma Distribuidora de Bebidas . Carvalho, J. Á. (2010). Tecnologias e sistemas de informação: uma área científica orientada às necessidades de conhecimento dos profissionais envolvidos na contínua transformação das organizações através das tecnologias da informação. Encontros Bibli: Revista Eletrônica de Biblioteconomia e Ciência Da Informação , 1–25. https://doi.org/10.5007/1518-2924.2010v15nesp2p1 Carvalho, J. C. (2020). Logística e Gestão da Cadeia de Abastecimento (3rd ed.). Sílabo Edições. Chang, J. F. . (2006). Business process management systems : strategy and implementation . Auerbach Publications. Chen, I. J., & Popovich, K. (2003). Understanding customer relationship management (CRM): People, process and technology. Business Process Management Journal , 9 (5), 672–688. https://doi.org/10.1108/14637150310496758 Chiarello, M. A., Emer, M. C. F. P., & Neto, A. G. S. S. (2014). An Approach of Software Requirements Elicitation Based on the Model and Notation Business Process (BPMN). Lecture Notes on Software Engineering , 65–70. https://doi.org/10.7763/lnse.2014.v2.96 Chinosi, M., & Trombetta, A. (2012). BPMN: An introduction to the standard. Computer Standards and Interfaces , 34 (1), 124–134. https://doi.org/10.1016/j.csi.2011.06.002 Cordeiro Marques, M. A. (2017). A Gestão De Stocks Numa Empresa De Serviços: O Caso Grupo Rolear . Universidade do Algarve. 126 Apêndice 2 – Criação de Clientes To-Be Figura 58 - Criação de Clientes To-Be 127 Apêndice 3 – Mapeamentos e Use Cases As-Is Figura 59 - Mapeamento As-Is Centro de Custo Figura 60 - Use Cases Centro de Custo 128 Figura 61 - Mapeamento As-Is Gestor de Cobrança Figura 62 - Use Case Gestor de Cobrança 129 Figura 64 - Mapeamento As-Is Condição de Pagamento Figura 63 - Mapeamento As-Is Nova Condição de Pagamento 130 Figura 65 - Use Cases Condições de Pagamento 131 Figura 67 - Mapeamento As-Is Centro de Lucro Figura 66 - Use Case Centro de Lucro 132 Figura 68 - Mapeamento As-Is Códigos de IVA Figura 69 - Use Cases Códigos de IVA 133 Figura 71 - Use Case Tipo de Documento Figura 70 - Mapeamento As-Is - Tipo de Documento 134 Figura 72 - Mapeamento As-Is Rúbricas Figura 73 - Use Case Rúbricas 135 Apêndice 2 – Subprocesso de Emissão de Crédito RIAM Figura 74 - Subprocesso de Emissão de Crédito RIAM