Chegamos na 3ª parte e final desse artigo sobre os desafios de implementação da ERP SAP S/4HANA. Aqui, vamos falar sobre as últimas frentes do projeto de implementação que são Testes e Deploy. Caso, você ainda não leu ou quer rever alguma parte dessa publicação, CLIQUE e acesse:
Testes
Testes, testes e mais testes. No final, são os resultados dos testes que confirmam o nível de risco do projeto para o momento de go-live, seja porque os testes mostraram que todas as frentes apresentam condições seguras de partir para a fase de “deploy”, seja porque eles mostraram as falhas que precisam ser endereçadas.
Um dos pontos chave de sucesso
está no cuidado de fazer um bom planejamento dos processos e cenários a serem testados, uma lista incompleta que por fim pode resultar em um indicador “falso positivo”, sinalizando que está tudo bem, quando na verdade a realidade é bem diferente. É o chamado indicador melancia – verde por fora e então, vermelho por dentro.
E o que é um teste bem planejado?
É aquele que é abrangente e ao mesmo tempo profundo, ou seja, considera uma gama de cenários e suas variações com diferentes tipos de casos.
Num projeto de implementação de um ERP SAP, é indicado haver:
● Testes de carga de dados
Usado para validar a qualidade, orquestração e performance das cargas. Os dados carregados são usados para realização de testes integrados e de usuário como forma de checar o funcionamento do sistema ERP com dados reais alimentados pelo processo de carga e conversão. Pelo menos 2 ciclos são necessários: um antes do último ciclo de testes integrados e um assim também, antes do UAT (User Acceptance Test).
● Testes integrados
Onde se valida o funcionamento do sistema ERP com as configurações, customizações, desenvolvimentos e integrações com outros sistemas. É recomendado que hajam 2 ciclos de testes integrados. No primeiro ciclo se observam os problemas e o segundo ciclo é avaliado se os problemas detectados no primeiro ciclo foram corrigidos. Pode ser necessário um ciclo adicional dependendo da quantidade de erros ocorridos no segundo ciclo.
● Testes de performance
Também conhecidos como “Stress test”, é fundamental para verificar a performance do ERP SAP quando houver grande volume de processamento simultâneo acontecendo.
A dificuldade deste teste
É gerar volume de dados para simular as várias operações acontecendo ao mesmo tempo, mas não fazê-lo pode provocar uma surpresa nada agradável de descobrir depois do go-live que uma operação simples demora preciosos minutos e não segundos como era esperado. E acreditem, apesar do SAP S/4HANA ter as bases de dados remodeladas e “in-memory”, isso por si só não é garantia de performance.
● Testes de aceitação (UAT)
User Acceptance Test ou teste de aceitação do usuário. É enfim o último teste, feito pelos usuários já treinados. São validados não somente o funcionamento do sistema ERP de forma integrada, mas também a preparação da organização para a operação do sistema e o processo de cutover, com a carga e conversão de dados. É uma espécie de test-drive.
Na frente de testes, é recomendado:
Planejar os cenários e variações da forma mais completa possível e depois fazer as adequações necessárias
Normalmente o prazo planejado para os ciclos de teste é previsto no início do projeto, em um momento em que não é conhecida a quantidade de cenários de teste e nem suas variações.
É comum que o prazo determinado no início não seja suficiente para a realização de todos os cenários e variações e a empresa terá que rever o plano do projeto para que haja o tempo necessário ou priorizar e reduzir a gama de cenários e variações para ficar compatível com o tempo planejado.
Neste último caso,
dependendo da quantidade e relevância dos cenários e variações eliminados, o indicador de testes pode apontar um bom resultado sendo que o risco de falha é significativo, apontando um “falso positivo”.
O que as empresas geralmente fazem
É garantir que os processos mais críticos sejam exaustivamente testados em todas as suas variações e para os processos menos críticos um número menor de variações sejam testadas, assumindo maior risco onde haja menor impacto para o negócio e para o cliente.
Preparar massa de testes com cuidado para atender aos vários cenários e variações
Apesar de ser previsto que a carga de dados e as integrações irão alimentar o ERP com dados suficientes para a realização dos testes, será portanto, necessário selecionar os dados que serão usados em cada cenário e variação a ser testada. Códigos de materiais, fornecedores, contas contábeis, clientes, ordens de compra e etc.
É preciso
ter uma ferramenta de registro e controle de informações usadas em testes para que todos os envolvidos igualmente saibam quais os registros foram criados nos passos anteriores para que o mesmo cenário possa evoluir até o final. A não existência desta ferramenta de registro, dessa forma fará com que as dezenas de pessoas envolvidas com os testes percam muito tempo para descobrir qual é o dado para então dar continuidade nos testes.
Ter um sistema para registrar os defeitos, controlar o progresso dos testes e gerar indicadores de resultados
Controlar a execução dos testes por fim não é tarefa fácil. Há ainda assim muita interdependência, isto é,
Muitos fatores podem interferir no progresso dos testes:
a ausência de um ou outro usuário, problemas ocorridos na carga de dados ou integração podem impedir a realização dos testes porque o dado usado nos passos anteriores não está disponível, problemas de ambiente, defeitos ocorridos em uma etapa bloqueiam o restante do cenário e outros vinculados, enfim: é desafiador.
Por isso,
para ajudar o time de gestão de testes a não se perder, é necessário ter um sistema que registre o progresso dos testes, marcando os defeitos ocorridos, informando automaticamente os cenários e passos que ficaram bloqueados por algum motivo e apurando os indicadores de desempenho dos testes.
Executar os testes com disciplina, registrar os resultados e defeitos
O teste tem como objetivo validar se determinado cenário e variação produziram os resultados esperados. Ter o registro da realização dos testes, com evidências do passo-a-passo e dos resultados de cada passo é dessa forma fundamental para validação do cenário ou identificação do problema.
Parece óbvio,
Mas em função do volume de testes e do prazo normalmente apertado para sua execução, é mais comum do que parece acontecer falha no registro de realização dos testes ou descrição incompleta do passo-a-passo. É necessário muita disciplina e atenção nessa hora.
Ter planos efetivos de resposta a risco para a fase de testes
A gestão de riscos faz parte da metodologia e sempre é realizada ao longo do projeto.
Existe
para registrar, quantificar e planejar a resposta aos riscos em qualquer etapa do projeto. Especificamente na fase de testes, é importante ter planejado qual será a resposta do time do projeto em caso de falhas ou atrasos nos testes dentro do plano do projeto.
Ou seja,
ao escolher cenários de testes que serão testados de forma reduzida por necessidade de prazo, um risco de problema na execução deste cenário é automaticamente levantado e há a portanto a necessidade de se planejar uma resposta a este risco.
Deploy
A fase de deploy acontece quando o time do projeto recebe autorização para fazer o Go-Live do sistema em ambiente de produção. O plano de cutover, que reúne as atividades das áreas de negócio e do time do projeto durante este período, deve então, ser construído e validado ao longo do desenvolvimento do projeto e deve ser testado como uma simulação pelo menos no último ciclo de teste integrado e no UAT.
Este plano
Deve ser executado passo a passo, então considerando todas as interdependências planejadas. Habitualmente, para cada processo de negócio, as operações de negócio são suspensas, dados são cadastrados, cargas são realizadas, sistemas são ativados em ambiente de produção, as integrações são ativadas,
Tudo
É conferido e validado, as operações de negócio são reiniciadas no novo sistema ERP, por exemplo, o resultado das primeiras operações é controlado e validado e só então o ERP é liberado para retomar portanto a operação em ritmo crescente até atingir o desempenho regular.
O time de suporte
Inicia os trabalhos de assistência junto com o time de projeto. Os usuários então, já treinados começam a operar o novo sistema em substituição ao antigo.
O período de deploy
Costuma incluir um período de assistência especial que normalmente tem duração de 30 a 90 dias, mas existem casos de períodos mais longos. É um período de muita tensão: problemas não identificados em nenhum dos ciclos de testes podem surgir e precisam de uma resposta rápida, usuários mesmo treinados podem ter dúvidas e inseguranças na operação do novo sistema.
As recomendações da fase de deploy são:
Planeje com cuidado o plano de cutover. É um plano que envolve atividades das áreas de negócio bem como, da consultoria implementadora. As áreas de negócio precisam entender que não é um plano somente de TI. Inclua tempo suficiente para as validações das atividades de TI e das áreas de negócio.
As atividades de cutover devem ser tratadas com prioridade. Durante sua execução, todos os recursos alocados para o plano de cutover devem manter o foco nele. É comum em contrapartida haver conflito entre as atividades de assistência à operação e as atividades do cutover. Não priorizar as atividades de cutover, em conclusão gera atrasos e demora no reestabelecimento da operação.
O time de suporte deve ser reforçado e assim como estar preparado para dar assistência rápida de forma a minimizar o impacto no início da operação. Problemas acontecerão. O que faz a diferença é a capacidade de resposta nesta fase. Esse recurso adicional é que tornará possível ao time de TI e negócios manter o foco nas atividades do plano de cutover.
Registre os defeitos e dúvidas que acontecerem nesta fase. O sistema de registros de incidentes do service desk pode tanto quanto deve ser usado já nesta fase. O controle executivo dos incidentes em outras palavras, auxilia na tomada de decisão para estabelecer ações corretivas e direcionar a alocação de recursos de suporte.
Finalizando, um projeto de implementação de ERP é considerado de alta complexidade e então, exige um esforço de gestão e um grande envolvimento das áreas de negócio. O patrocínio da alta gestão é por fim mandatório para que os recursos sejam mobilizados.
Diante desse artigo, acima de tudo, espero que traga ótimos insights para os projetos de implementação de SAP S/4HANA.
Por Daniel Arruda
Diretor de TI com mais de 25 anos de experiência.
Foi responsável por inúmeras implementações de ERP SAP ao longo de sua carreira.
+ sobre Daniel Arruda
