Integração com sistemas de back-end é a chave para o sucesso de qualquer solução de execução em campo de varejo. É importante alavancar seu investimento em sua solução ERP existente, especialmente se for uma solução poderosa e capaz como SAP ECC ou S4 / HANA.
A Spring está na vanguarda desse problema, tendo implementado inúmeras integrações com a SAP nos principais clientes de CPG nos últimos 15 anos e também por ser um parceiro da SAP e pertencer parcialmente à SAP (SAPphire Ventures).
A CONA Services, LLC selecionou a Spring Global há 4 anos com base em várias razões. Uma delas foi a solução deles ter uma boa aderência ao modelo de dados do SAP para Vendas e Merchandising. Isso permitiu à CONA entrar em produção com o primeiro engarrafador em menos de quatro meses. A integração da Spring é escalável e de alto desempenho, o que permite à CONA obter e inicializar os dados do sistema rapidamente para dar suporte a mais de 12.000 usuários.
David South, Diretor de arquitetura CONA Services - Uma empresa de serviços de TI da Coca-Cola(Coke One North America)
Com mais de 15 anos de experiência nesta área, encontramos vários ambientes diferentes, e conseguimos superar vários desafios de integração que muitas empresas de CPG enfrentam. Com isso, selecionamos cinco fatores críticos a serem considerados ao selecionar um fornecedor de execução para sua força de campo, relacionado à integração com SAP:
- Aderência do modelo de dados: sim, você pode criar novas entidades, objetos e APIs de maneira genérica ou dinâmica, mas se o modelo de dados do seu provedor tiver poucas entidades padrão ou se for simplificado demais, a lógica de integração será complexa e difícil de manter, levando a mais custos de instalação e operação. A Spring evoluiu seu modelo de dados para ficar muito próximo do modelo de dados SAP ao longo dos anos, em alguns casos até tendo as mesmas entidades equivalentes, especialmente para uma estrutura de dados tão complexa quanto a parte de precificação. Isso simplifica bastante o esforço de integração, pois fica muito próximo de um mapeamento 1:1, com lógica de transformação de dados mais simples. Isso contribui para um projeto de configuração rápida, mas também para um ótimo desempenho e fácil manutenção;
- A configurabilidade precisa ser granular: mesmo tendo um modelo de dados aderente, você ainda precisa de flexibilidade para configurar novos campos, novas entidades e a API exposta relacionada para integração. Além disso, a flexibilidade da camada da API deve considerar o gerenciamento de versões, pois você não deseja interromper os fluxos existentes ao criar novos. A configurabilidade para se adaptar às diferentes circunstâncias de como sua instância do SAP está configurada também é muito importante. Por exemplo, a capacidade de alternar entre os modos síncrono e assíncrono e escolher modos específicos, dependendo da interface específica. Em nossa experiência, às vezes é importante reutilizar uma interface existente do SAP, e a maneira como algumas interfaces funcionam pode não ter um bom desempenho se você tiver apenas um modo síncrono. Em outros casos, ser síncrono e realmente aguardar o retorno da integração é importante, pois seu processo de negócios no SAP pode exigir isso. Portanto, é importante ter esse tipo de configurabilidade interface por interface.
- Mantendo a integridade, com atenção ao desempenho: os sistemas transacionais usados para conectar-se ao SAP geralmente dependem de muitas verificações de integridade de dados para garantir que todas as transações sejam totalmente consistentes. As propriedades ACID (Atomicidade, Consistência, Isolamento, Durabilidade) são essenciais para qualquer sistema transacional. No entanto, às vezes esse tipo de garantia tem um alto custo em termos de desempenho (muitas validações) e também no custo de implementação de projetos de integração, pois você realmente precisa garantir uma ordem exata de chamadas para cada interface, o que pode ser uma tarefa assustadora. Uma orquestração de integração típica pode ter até 400 interfaces de integração diferentes, e a dinâmica de cada fluxo de trabalho na implementação do SAP pode não garantir a ordem de chamadas facilmente. Por exemplo, você pode usar grupos de clientes como “Target Groups”, fazendo referência a lojas de clientes específicas, mas uma loja específica pode não estar atualizada quando é referenciada pelo grupo, causando um erro de dependência na integração. Nossa abordagem é garantir que todas as validações necessárias sejam executadas, mas também permitindo que as solicitações falhem e sejam re-executadas posteriormente, de forma manual ou automaticamente, usando uma estrutura de cache. Os pontos principais são:
- Você pode reutilizar sua lógica de integração atual, não necessariamente seguindo uma ordem exata de chamadas, e agendar uma re-execução do processamento
- Às vezes, é melhor falhar rapidamente e ingerir alguns dados (registros que estão OK), retendo apenas o registros com erros de referência, que podem ser re-importados posteriormente.
- Ter a capacidade de armazenar em cache solicitações de integração e re-executar solicitações dependentes sem precisar re-enviar os dados do SAP é um recurso importante, pois gera melhor desempenho e simplifica o lado SAP da sua integração.
Todas essas características ajudam a garantir um bom desempenho de integração, custo reduzido de implementação, mantendo o nível adequado de integridade dos dados.
4. Extração de dados direcionada do SAP: as vezes, usar interfaces SAP padrão (BAPIs padrão) é demais para as necessidades de uma solução de execução de varejo, tanto em termos de registros quanto de campos.. Em nossa experiência, isso leva a mapeamentos complexos e também a problemas de desempenho, pois algumas vezes apenas alguns registros são alterados (por exemplo, para “Business Partners”), mas a interface exposta atinge um grande número de registros e campos, não apenas retardando o processo de integração, mas também usando um muitos recursos desnecessários do servidor. Além disso, no lado da solução de execução em campo, você pode ter a integração com duração de horas, gerando processamento extra e, possivelmente atrasando o acesso a dados de importantes processos de campo (por exemplo, uma atualização em um ticket de serviço de um ativo implantado na loja, como geladeiras, regulados por SLAs). Resolvemos esse problema de várias formas, e uma delas seria através do uso de uma arquitetura de referência para um conector SAP, que pode ser instalado como uma RFC dentro do ERP, para extrair apenas os campos específicos necessários para uma solução típica de execução de varejo (por exemplo, campos específicos para “Business Partners”) e também apenas as alterações desde o último acesso à API. Tivemos ganhos de desempenho de até ~ 60% para grandes quantidades de registros, como 500 mil parceiros de negócios, por exemplo.
5. Escalabilidade e desempenho reais devem ser comprovados por uma simulação: obviamente, a escalabilidade é essencial para qualquer projeto de integração, que precisa ser elástica e adaptável às suas demandas, caso contrário você terá uma grande capacidade investida que raramente é usada ou atingirá um gargalo se houver um aumento não planejado da integração (por exemplo, uma campanha crítica de curto prazo leva a milhões de registros de condições de preços relacionados à promoção). Além do ponto muito importante sobre realmente planejar com antecedência e considerar seus benchmarks de escalabilidade e desempenho dentro de uma margem de segurança, nossa experiência provou que simular o comportamento do sistema pode realmente fazer a diferença. As soluções de execução em campo que dependem do acesso offline do aplicativo móvel geralmente funcionam com uma arquitetura de middleware, o que significa que você pode ter conflitos entre a sincronização de dados de dispositivos móveis e a carga transacional da integração à SAP. Como é muito difícil antecipar todos os problemas possíveis, fazer uma simulação pode realmente ajudá-lo a encontrar problemas críticos com antecedência e corrigi-los antes que seja tarde demais. A Spring investiu em uma ferramenta de simulador capaz de reproduzir cargas de produção reais ou simuladas, executando a lógica de processamento disparada pela sincronização de dispositivos móveis, acesso ao portal da web, execução de processos em lote e também a carga de integração com o SAP. Para sistemas transacionais críticos, como vendas em campo, não se arrisque a entrar no ar sem executar primeiro uma simulação realista. Abaixo está um diagrama com uma visão simplificada da configuração de simulação que usamos:
Conectar-se de uma maneira eficiente e econômica com o SAP é obviamente fundamental para qualquer solução de execução de varejo, pois o SAP é normalmente a principal fonte para seus dados mestre e dados transacionais, portanto, é crucial ter um parceiro que realmente entenda a complexidade envolvida e com um produto preparado para os possíveis problemas decorrentes de um projeto de integração com SAP.
Se você tem interesse em ver uma demo da Spring Global ou se tem questões sobre integração com SAP, por favor nos você pode entrar em contato conosco aqui.