O Grupo M.Video-Eldorado apresentou sua estratégia de Hacking Retail no início de 2021. Nos próximos 5 anos, planejamos dobrar o faturamento total para 1 trilhão de rublos e triplicar o sortimento, inclusive por meio do desenvolvimento de nosso próprio mercado. Os sistemas de TI “monolíticos” não são capazes de proporcionar esse crescimento em um curto espaço de tempo e desenvolvimentos fora do padrão retardam todo o processo. Os microsserviços vêm em seu socorro. Contaremos como "cortamos" um pedaço do SAP ERP e o que resultou dele.
Há alguns anos, concluímos o processo de fusão dos back office da M.Video e da Eldorado. Como resultado, a infraestrutura de TI unificada da rede de varejo passou a representar uma estrutura de três camadas: no primeiro nível, um back office unido, cujo principal sistema de contabilidade é um SAP ERP “monolítico”.
Acima está uma plataforma de microsserviço em constante expansão que fornece dados importantes para todos os sistemas frontais (preços, promoções, produtos, saldos, informações do cliente, etc.) e fornece integração de sistemas frontais com sistemas posteriores. No andar de cima, esse esquema é coroado com dois front office separados para cada uma das marcas.
Em geral, esse pacote atende às necessidades atuais do negócio. Mas eles estão crescendo constantemente, então estamos constantemente procurando por subótimas, cuja eliminação poderia melhorar o desempenho dos processos de negócios e prepará-los para uma carga de trabalho maior.
Prepare-se seriamente. A M.Video-Eldorado tem grandes planos para expandir a gama de produtos e lançar novos projetos. O crescimento esperado nos volumes de fornecimento deve ser de duas a cinco vezes. E não algum dia, mas dentro de um ou dois anos.
Longas horas de espera
Um dos gargalos que precisava ser eliminado o mais rápido possível era o algoritmo de cálculo de calendários logísticos. Vamos explicar um pouco mais detalhadamente. Existe um conceito de acessibilidade logística. Ele determina em que momento as mercadorias podem ser entregues do ponto A ao ponto B. O parâmetro de acessibilidade logística é usado por todos os front office, é acessado por aplicativos de negócios, etc. - este é um dos principais parâmetros de um produto como unidade logística.
O calendário contém informações completas sobre a possibilidade de movimentação de mercadorias entre o fornecedor, entrepostos centrais e regionais e lojas em ambas as redes. Se a remessa estiver programada para hoje, o calendário de hoje será usado. Mas amanhã perderá sua relevância e será necessário aplicar "amanhã".
Para aumentar a estabilidade do trabalho dos processos logísticos, o cálculo era realizado diariamente com três dias de antecedência. Esta solução tem sido entregue como uma "muleta" no SAP ERP devido à velocidade de implementação. O processo demorou de 9 a 11 horas! O teste com uma carga mais alta mostrou que o sistema não conseguiu fazer o cálculo mesmo em 24 horas. Para alcançar uma produtividade qualitativamente superior com um aumento significativo de volumes, era importante tirar este serviço do monólito ...
Situação atual
O algoritmo de cálculo de calendários logísticos, que faz parte do SAP ERP, era um pacote de procedimentos PL / SQL disponibilizado pela SAP na forma de solução de caixa customizada. O cálculo de cada um dos três calendários nele contidos foi feito "do zero", levando em consideração todas as condições de cada cadeia de suprimentos. Conseqüentemente, a maioria dos cálculos em cada estágio simplesmente se duplicou. Essa era a lógica de funcionamento do produto, e não tínhamos recursos para eliminar totalmente o débito técnico.
Além disso, o algoritmo deixou cadeias de suprimento "lixo" duplicadas nos calendários finalizados. Isso levou a um aumento no tamanho do banco de dados. Em vez dos 10 milhões de registros necessários, o banco de dados pode conter de 20 a 30 milhões e a limpeza manual necessária.
A ferramenta original não atingiu o estado ideal em um dia. Foi introduzido há muito tempo e, ao longo de todo o período de operação, foram introduzidas inúmeras melhorias, iniciadas por clientes empresariais. Um fluxo de mudanças graduais ao longo dos anos levou ao surgimento de várias imprecisões, algumas das quais não estavam totalmente refletidas nas especificações.
Ao mesmo tempo, tratava-se de uma ferramenta crítica de negócios, da qual dependiam as atividades de centenas de lojas da rede varejista. Portanto, a abordagem para o desenvolvimento do produto teve que ser muito cuidadosa, mas rápida.
Retire um pedaço do "monólito"
Percebendo que o potencial de crescimento da produtividade do SAP ERP nessa área (aliás, não típico de um serviço de ERP) se esgotou, nos voltamos para os microsserviços. A M.Video-Eldorado vem desenvolvendo essa direção há vários anos.
Temos nossa própria plataforma de microsserviços executando mais de uma centena de microsserviços. Foi necessário criar uma série de serviços baseados no mesmo algoritmo do módulo original do sistema ERP. Queríamos manter a lógica geral dos cálculos, mas evitamos repetir os mesmos processos.
O trabalho foi realizado em três direções principais. Primeiro, foi necessário otimizar o algoritmo SAP eliminando cálculos desnecessários dele. Em segundo lugar, foi necessário eliminar o surgimento de cadeias de suprimentos duplicadas, levando ao acúmulo de registros desnecessários no banco de dados. Em terceiro lugar, era necessário eliminar imprecisões nos resultados do algoritmo original, que dificultam a otimização dos processos de negócios.
Lembre-se de que SAP ERP é um dos principais back-systems da empresa, que recebe dados de todos os front-systems. Apesar de o cálculo dos calendários ter que ser transferido para microsserviços, as próprias etapas de aquisição individuais, a movimentação de mercadorias ainda era criada no sistema de contabilidade central.
Para gerar calendários logísticos, o SAP ERP fornece mais de 20 tabelas com configurações recebidas de usuários empresariais. É com base nestes dados que a plataforma de microsserviços realiza os cálculos. O próprio ERP também os usa para cálculos internos ao criar o segundo e o terceiro braços de entrega. Portanto, era impossível simplesmente extrair todo o processo do monólito e transferi-lo.
Diagrama do processo:
1 e 3 - O processo através do SAP PI recebe dados com configurações para cálculo de calendários do SAP ERP;
2 e 4 - Registro dos dados recebidos do ERP no banco de dados;
5 - O processo leva uma das versões dos dados armazenados em seu banco de dados (por padrão - a versão mais recente). Em seguida, calcula os calendários com base nesses dados e os armazena em uma tabela de preparação. Durante a operação, o processo pede informações sobre os objetos.
6 - Os dados são transferidos da mesa intermediária para a mesa produtiva no mesmo formato em que o processo os recebe do SAP ERP.
7 - Excluir dados antigos com configurações de calendário do banco de dados.
Ferramentas, tempo, recursos
Como criamos microsserviços há vários anos, não tivemos dúvidas particulares sobre a escolha das ferramentas de desenvolvimento. Uma combinação bem-dominado de Java 11 e Primavera Bota
2 entrou em ação Nenhuma mágica no código, apenas coisas padrão para Java -. Colecções, interfaces, etc.
Nós inicialmente construído o novo algoritmo de modo que todas as operações com mesas foram completamente realizados em RAM, e não usando consultas SQL dentro do banco de dados.
Por parte da equipe de operação do SAP ERP, foram feitos preparativos para a transferência dos dados mestre para a plataforma de microsserviços para cálculo de calendários. Demorou cerca de 40 horas.
No futuro, eles só precisariam apoiar o projeto. O trabalho principal, é claro, recaiu sobre os ombros dos engenheiros da própria plataforma. A lógica do algoritmo foi essencialmente recriada. Do ERP, foram retirados apenas dados mestre e princípios básicos de negócios para o cálculo de calendários. Isso levou mais 150 horas.
Em geral, a implantação do projeto demorou cerca de seis meses. Passamos dois meses sozinhos em vários autotestes baseados em diferentes abordagens. A pilotagem do novo instrumento continuou por cerca de um mês. Durante este período, calculámos simultaneamente dois tipos de calendários - antigo e novo, estudámos e comparámos os resultados, era extremamente importante certificar-nos de que o serviço não se deteriorava e que o cálculo estava correcto. Só depois disso decidiu-se transferir a nova ferramenta para o ambiente de produção.
resultados
O que conseguimos no final? O calendário agora é calculado apenas uma vez. Em seguida, suas instâncias para cada um dos três dias são obtidas como resultado de alguns pequenos cálculos adicionais associados à mudança de datas. O volume do banco de dados é mantido automaticamente em um estado ideal devido à ausência de um complemento "muleta", a carga no sistema ERP diminuiu.
Mas o principal resultado que temos conseguido é a redução do tempo de geração do calendário de 9-11 horas para ... 10 minutos! Há muito trabalho pela frente, o futuro aumento múltiplo de carga na infraestrutura de TI ainda exigirá melhorias, mas vencemos essa dívida técnica.