Você usuário de sistemas de ERP/SAP, Analistas funcionais ou Gestores, já deve ter se deparado com lentidão em alguns de seus programas, geralmente notamos e atuamos na lentidão nos momentos mais críticos, parou! então atuamos.

Mais e você Gestor que tem meta de performance ou refactoring, ou está sendo proativo, e aumentar a performance de seu ERP/SAP e consequentemente de seus negócios.

Qual a melhor forma de realizar uma avaliação de performance?

Neste artigo juntamos todo nosso time de especialistas técnicos e funcionais para apresentar um formato de avaliação de performance orientada ao negócio.

Leia o artigo na integra.

Sabemos que o SAP é um ERP gigantesco e confiável, porém precisamos de diversos desenvolvimentos e integrações para coletarmos os melhores resultados do sistema para nossos negócios. No entanto, ao longo do tempo também é comum que os sistemas começam a ficar cada vez mais lentos, seja pelo alto volume de dados, problemas de construção ABAP ou recursos físicos.

A primeira atitude que os profissionais praticam é avaliar os sistemas SAP em produção por meio de traces. Agora! Será que o trace é a melhor ferramenta para avaliar se um programa tem maior impacto no negócio da empresa? Vamos avaliar um cenário que coletamos de um cliente com dados semelhantes que apresentam para você a resposta dessa pergunta.

Vamos observar uma avaliação de ambiente de produção para ver os principais objetos com maior consumo médio de banco de dados. Nesse caso em específico os desenvolvedores compreendiam que quando um programa tem alto consumo de banco de dados, teremos muito tempo de processamento de banco de dados e um problema grave a ser corrigido.

Temos uma visão, nesse caso, que de fato temos um alto custo para executar esses objetos proporcionalmente. Essa afirmação é correta? Agora! Se eu tiver que investir em correção qual deles eu investiria?

Minha resposta é, nenhum e vou te mostrar o motivo. Se pegarmos o primeiro caso, é um programa de carga pequenininho que possui 1 único select dentro, é obvio que ele vai ter seu principal custo fazendo operação de banco de dados. Isso porque ele não possui outra lógica ABAP dentro dele. Somente seleciona dados e mostra numa tela simples o resultado. A grande maioria dos casos listados tem esse mesmo cenário e se avaliarmos seu select está acessando a base de dados com sua chave completa, ou seja, não temos oportunidade de melhoria relevante para eles.

Nesse caso, temos um custo alto de fetch que eleva o tempo de resposta por conta do volume de dados, aumentando assim o tempo de resposta da aplicação. É natural esse tempo de resposta maior quando temos grandes volumes de dados e não tem nenhum problema nisso, apenas uma situação de negócio e filtro. É correto orientar um trabalho de refactoring nesse tipo de análise de trace? No meu ponto de vista, mexer nesses itens listados não vai agregar valor ao negócio e teremos um investimento de tempo e dinheiro em objetos sem relevância para a empresa.

Agora você está se perguntando, trace não serve e como eu tenho que fazer? Qual o caminho que devo utilizar para saber onde meu investimento vai agregar maior valor pra empresa? Em meu entendimento a avaliação deve compor três dimensões, sendo ela avaliação da qualidade do código-fonte, volume de execuções em produção e volume de sustentação do objeto.

Sobre a avaliação de qualidade do código-fonte é fundamental, porque existem vários problemas de boas práticas que são produzidos nos objetos Z e que geram grandes impactos em performance. Quando avaliamos essa dimensão é possível sabermos a linha de código que possui o problema e corrigir de forma ágil, pois conheceremos o problema causador da lentidão.

Quando falamos em execuções em produção, teremos uma visão de negócio sobre os objetos que possuem maior relevância no cotidiano da empresa. Faz sentido eu corrigir um programa que é utilizado uma vez por mês? Ou faz mais sentido eu corrigir um programa que é executado 200 vezes num mesmo dia? A resposta é óbvia nesse caso e nosso esforço de investimento deve ser onde existem mais execução, ou seja, o objeto é muito utilizado. Com essa orientação, conseguiremos deixar esses processos mais rápidos, economizaremos recursos computacionais e aumentaremos a produtividade dos processos de negócio da empresa de forma mais significativa. Teremos ROI muito mais rápido desse projeto que na situação orientada pelo trace.

Já na visão de sustentação, vem para complementar as outras dimensões pois eu tenho um programa com problema, que é muito utilizado em produção e também me gera muitas horas de sustentação. Com a sua correção além de melhorar a produtividade da área de negócio, economizaremos dinheiro na sustentação. Menos suporte, significa menos custos de correção e maior foco do time em melhorias e inovações. Tudo se reflete em otimizar recursos da empresa, seja na área de TI ou na área de negócio. Olhando esses cenários de análise, pergunto para você agora: Faz sentido avaliar trace? Ou faz mais sentido avaliar as três dimensões?

As três dimensões trazem um real valor para a empresa como negócio, mas para chegarmos nesses números é manualmente impossível mensurar e determinar precisamente o problema real a atacar. Podemos observar essas dimensões no diagrama a seguir:

Esse diagrama mostra que o maior ROI possível sobre o trabalho de refactoring está associado as três dimensões que estamos abordando até o momento. Isso se dá porque o trabalho a ser executado está orientado ao impacto da área de negócio e ao volume de problemas que exigem esforço da TI para solucionar.

Por esse motivo a QAMetrik idealizou uma ferramenta capaz de analisar as três dimensões e sugerir os principais objetos que terão maior relevância para um trabalho de re-fatoração. Essa ferramenta é capaz de varrer todos os objetos do ambiente e avaliar a qualidade de todas as linhas de comando já produzidas na sua empresa. Além disso ela analisa o uso dos objetos em produção e contabiliza o volume de suporte que eles tiveram ao longo do tempo. O resultado dessa análise gera um índice que você facilmente avaliará quais objetos você precisa trabalhar, veja na imagem abaixo:

Como podemos observar na listagem acima, se compararmos com o resultado do trace não temos nenhum daqueles objeto com um índice de importância alto suficiente para trabalharmos. Esse índice de importância é um fator calculado com base nas três dimensões que estamos abordando até o momento.

Esse indice é calculado com a avaliação do ambiente que a QAMetrik Devops faz no ambiente, analisando a qualidade das linhas de código fonte, o volume de execuções do objeto em produção e o volume de chamados ou suporte que esse objeto já foi envolvido. Sobre essa base de dados extraída a ferramenta calculará o índice de relevância para direcionar para você qual é o objeto que vale mais a pena a empresa investir.

Nesse contexto, observamos que o objeto que maior relevância possui apenas 22 problemas de performance no código, mas sua relevância para a área de negócio é alta, pois possui muitas execuções e muito suporte. Se fossemos tratar apenas com uma análise fria e limitada de um trace, não conseguiríamos ter essa mesma conclusão. Dessa forma, conseguimos ter maior certeza de onde devemos investir esforços e dinheiro em nosso ambiente SAP.

Essa é uma das ferramentas disponíveis no QAMetrik Devops que ajudam as empresas a melhorar a performance de seus negócios e otimizar os seus recursos.