Dúvida

Quais são as melhores práticas de arquitetura e configuração do Gestão Empresarial | ERP para sustentar uma operação de mais de 80.000 pedidos por dia?

Solução

O objetivo deste artigo é compartilhar um Case de Sucesso de utilização do Gestão Empresarial | ERP onde há possibilidade de sustentar uma operação de mais de 80.000 pedidos integrados e faturados diariamente, comprovando que a correta utilização dos recursos do sistema junto com um processo arquiteturalmente correto garante uma excelente Performance e atendimento de grandes volumetrias.

Além disso, pode ser listado o seguinte objetivo adicional:

• Disponibilizar um conjunto de artefatos nativos, parametrizações e customizações que viabiliza uma operação de venda com as seguintes caraterísticas:
  • Operação fluída, automática, sem necessidade de intervenção humana;
  • Operação robusta, resiliente, com alta capacidade de escala e performance;
  • Processo comuns em segmentos do comércio/varejo/atacado distribuição.

1. Processo definido para essa operação com garantia de melhor performance

O processo de faturamento é composto dos seguintes sub-processos:

• Entrada de pedidos: a Entrada de Pedidos ocorre através de um WebServiuce customizado, que por sua vez chama um WebService nativo. Isso é realizado para que algumas informações não enviadas de um sistema externo sejam já preenchidas adequadamente pelo WebService customizado, antes da chamada do WebService nativo;
• Geração de Pré-Faturas: as Pre-Faturas geradas são do módulo de Expedição, e são gerada através da chamada de um WebService nativo, que é chamado através de uma regra personalizada (que possui o contexto de negócio das Pre-Faturas que podem ser geradas);
• Integração com WMS de Terceiros: essa integração é realizada utilizando o Senior Connect, que é um grande aliado para integrações mais complexas que exigem definição de fluxos específicos de integração com tecnologias de integração diferentes;
• Faturamento das Pre-Faturas: o faturamento é realizado através de processos agendados de rotina de código 71;
  • O processo de comunicação com eDocs é realizado via WebServices de forma assíncrona (isso é definido na tela F191CPT). Para grandes volumetrias de integração, é imprescindível que não seja utilizada integração síncrona com eDocs;
• Emissão de boletos: esse processo é efetuado após a autorização da NF-e no eDocs e o retorno do eDocs ser registrado (é um processo posterior, não sendo executado diretamente no retorno do eDocs para o ERP);
• Ressuprimento: esse processo é personalizado (via regra, vinculado a um processo agendado), executando transferências de estoques entre a Matriz e as Filiais.
   

2. Visão de como estavam definidos os processos antes e como ficaram os processos depois da revalidação arquitetural para execução das rotinas

Abaixo segue uma tabela comparativa de antes e depois, junto com os ganhos observados em cada alteração.

Ainda na visão de "Antes" e "Depois", abaixo seguem algumas informações adicionais sobre essas visões.

A definição do "Depois" não foi algo definido "da noite para o dia". Exigiu estudo arquitetural para chegar nas melhores formas de atender os processos, além de mudanças faseadas, para que no fim houvesse um grande ganho de Performance.

Em um primeiro momento (o "Antes" bem "Antes" mesmo), o processo de faturamento estava definido assim:

Geração de NF-e -> Integração síncrona com eDocs -> Geração de boleto -> Ressuprimento -> Compensação, caso existisse.

Em um segundo momento, a alteração realizada foi na integração do ERP com o eDocs, ficando assim o processo:

• Primeira parte do processo: Geração de NF-e -> Integração assíncrona com eDocs
• Segunda parte do processo: Retorno da Autorização -> Geração de boleto -> Ressuprimento -> Compensação, caso existisse.

Em um terceiro momento, a alteração realizada foi em filas de processamento posteriores a autorização da NF-e, ficando assim o processo:

• Primeira parte do processo: Geração de NF-e -> Integração assíncrona com eDocs
• Segunda parte do processo: Retorno da Autorização -> Geração de boleto -> Ressuprimento -> Compensação, caso existisse.
  • Fila de processamento do Ressuprimento
  • Fila de compensação de títulos

3. Dicas adicionais para evolução em um cenário como esse

Para uma análise desse tipo de cenário, é importante quebrar os processos para analisá-lo e fazer alterações neles em separado.

Após a evolução na performance de um processo menor, pode-se então evoluir para uma análise em um segundo processo, deixando o primeiro processo ainda "parado".

Exemplo:

• Atuar primeiro na verificação da entrada de Pedidos no ERP;
• Após ter um ganho na performance dessa parte, ir para a etapa posterior (exemplo: Geração de pre-Fatura), mas fazendo análises sem que a base de dados esteja sendo afetada pela entrada de Pedidos (então, obviamente, isso é uma análise a ser efetuada em ambiente de homologação, onde entrada de pedidos pode ser parada);
• Após a análise e melhoria no processo de geração de Pre-fatura, então validar a execução dos dois processos ao mesmo tempo (entrada de pedido e geração de pre-fatura);
• Depois que os dois processos estiverem com uma performance boa quando executados juntos, então foca-se em processo posterior de faturamento (deixando os dois processos anteriores parados);
• Após a aplicação de melhorias isoladas no processo de faturamento, então pode-se ativar os três processos simultâneos (entrada de pedido, geração de pedidos e faturamento);

• E assim deve-se fazer a análise sucessivamente de acordo com os processos envolvidos.

   

Observação

Para mais informações sobre o questões relacionadas a Performance/Lentidão/Travamentos do Gestão Empresarial | ERP, consulte o artigo ERP - Performance/Lentidão/Travamentos - Onde é possível encontrar informações diversas sobre questões relacionadas a Performance/Lentidão/Travamentos (índice).