A auditoria de mudanças SAP gira em torno de uma pergunta simples de fazer e difícil de responder: cada alteração que chegou à produção foi autorizada, testada e aprovada antes de chegar lá, e existe evidência disso? Em muitas empresas, a resposta existe, mas está espalhada em e-mails, planilhas, chamados e na memória do time. E vira uma força-tarefa toda vez que o auditor pede uma amostra.

Este artigo explica o que os controles gerais de TI (ITGC) costumam avaliar na gestão de mudanças, quais evidências guardar por request e como fazer essa trilha nascer no próprio processo.

O que a auditoria de mudanças SAP avalia

Os ITGC (IT General Controls, ou controles gerais de TI) são o conjunto de controles que dá confiabilidade aos sistemas que sustentam as informações financeiras e operacionais da empresa. Gestão de mudanças é um dos seus pilares, ao lado de gestão de acessos e operações de TI.

Os critérios variam conforme a firma de auditoria e o programa de compliance de cada empresa, mas os pontos avaliados costumam se repetir:

• Autorização. A mudança tinha uma demanda legítima, aprovada por quem tem alçada para isso.
• Teste. Houve validação em ambiente de qualidade antes da produção, com evidência do resultado.
• Aprovação para produção. Alguém com papel definido liberou a ida para produção, e essa decisão ficou registrada com data.
• Segregação de funções. Quem desenvolve não é quem aprova nem quem importa em produção. O tema conversa diretamente com a matriz de segregação de funções (SoD).
• Acesso restrito à produção. Alterações diretas em produção, fora do fluxo de transporte, são exceção controlada.
• Mudanças emergenciais. Quando a urgência atropela o fluxo normal, a aprovação e a documentação precisam vir depois, dentro de um prazo definido.

Quais evidências guardar para cada request

Na prática, o auditor seleciona uma amostra de mudanças do período e pede para ver a história de cada uma. Uma trilha completa costuma reunir:

• a demanda ou chamado que originou a mudança, com a justificativa;
• a especificação funcional e técnica que descreve o que foi feito;
• o vínculo entre a demanda e as requests de transporte geradas;
• a evidência do teste em QAS e de quem validou;
• a aprovação para produção, com papel, nome e data;
• o registro do import em produção, com data e responsável;
• para emergências, a aprovação posterior e a análise do motivo.

O sistema de transporte da SAP registra boa parte do que acontece tecnicamente com a request. Mas ele, sozinho, não costuma responder à parte de negócio: por que a mudança existe, qual especificação ela atende e com base em qual teste ela foi aprovada. É justamente essa parte que costuma faltar quando a amostra chega.

Por que a evidência se perde no caminho

Raramente falta controle por descuido do time. O mais comum é que cada etapa da mudança tenha sua própria ferramenta e o registro fique fragmentado:

• a especificação está em um arquivo de texto com várias versões;
• o teste foi validado por e-mail ou mensagem;
• a aprovação aconteceu numa reunião e não foi registrada;
• o controle do que sobe para QAS e produção está numa planilha;
• uma mesma request concentra objetos de várias demandas diferentes.

Esse último ponto merece atenção. Requests grandes, com objetos de demandas distintas, dificultam ligar cada alteração à sua aprovação. É um problema antigo, que abordamos ao falar dos desafios de requests jumbo em projetos SAP.

Para quem usa o ChaRM, há ainda uma decisão no horizonte. O fim da manutenção do SAP Solution Manager obriga muitas empresas a repensar onde a gestão de mudanças vai morar, como explicamos no artigo sobre o fim do SAP Solution Manager em 2027.

O custo de montar a evidência no fechamento

Quando a trilha não nasce no processo, ela precisa ser reconstruída depois. E a reconstrução quase sempre cai sobre as mesmas pessoas que estão sustentando o ambiente no período mais sensível do ano.

O custo não é só de horas. Evidência reconstruída tem menos valor do que evidência gerada no momento da decisão, e lacunas na amostra podem virar apontamento de deficiência de controle. A combinação de auditoria e fim de ano é especialmente delicada, porque coincide com congelamentos e janelas de mudança apertadas, tema que exploramos ao explicar por que outubro a dezembro é a janela mais arriscada para mudar o SAP.

Mudança emergencial: o ponto mais sensível

A GMUD emergencial é onde a trilha mais costuma se romper. A pressão para restabelecer a operação é legítima, e o fluxo normal fica de lado. O risco está no depois: se a aprovação posterior e o registro do motivo não acontecem, a mudança fica sem evidência.

Um volume alto de emergências também chama a atenção do auditor por si só, porque pode indicar que o processo normal não está dando conta. Detalhamos causas e saídas no artigo sobre por que a GMUD emergencial ainda é tão comum no SAP. Correções via SAP Notes seguem a mesma lógica e merecem o mesmo cuidado, como mostramos no guia sobre como aplicar, testar e transportar SAP Notes.

Como fazer a evidência nascer no processo

A virada está em deixar de tratar a auditoria como um evento e passar a tratá-la como subproduto do fluxo de trabalho. Alguns princípios ajudam:

• Toda request ligada a uma demanda. Sem demanda, não há request. Isso cria a rastreabilidade desde a origem.
• Aprovação por papel, registrada na etapa. Cada passagem de DEV para QAS e de QAS para produção tem um aprovador definido, e a decisão fica gravada junto com a mudança.
• Segregação aplicada pelo fluxo. O próprio processo impede que a mesma pessoa desenvolva, aprove e importe.
• Import em produção controlado e em sequência. Dependências e conflitos de objetos são verificados antes do release, não depois do incidente.
• Evidência guardada com a mudança. Especificação, teste e aprovação ficam no mesmo lugar que a request, prontos para consulta por quem tem acesso.

O guia de governança de transportes SAP aprofunda a parte técnica, e o artigo sobre gestão de mudanças (GMUD) no SAP traz a visão de processo. Se a especificação é o elo fraco, vale ver também o que uma especificação funcional e técnica SAP precisa ter.

Um teste rápido para fazer no seu ambiente

Escolha dez requests importadas em produção no último trimestre. Para cada uma, tente responder, sem pedir ajuda a quem fez: qual demanda a originou, onde está a especificação, qual foi a evidência de teste, quem aprovou a ida para produção e quando ela foi importada.

Se as respostas saem em minutos, o processo está gerando evidência. Se dependem de procurar e-mails e perguntar para pessoas, é um bom sinal de que a próxima auditoria vai consumir mais tempo do que deveria.

Onde a QAMetrik entra

A Mineração Taboca passou a conduzir as mudanças de TI por um único fluxo de governança, e o case de simplificação de auditorias no SAP traz outro exemplo de governança aplicada à rotina de auditoria.

É essa lógica que o MoveOn leva para a jornada inteira da mudança SAP: da especificação ao import em produção, com aprovação por papel e trilha de auditoria gerada no fluxo de cada request. Para saber como está o seu processo hoje, o QA Assessment é um bom ponto de partida. E, se preferir conversar sobre o seu cenário, fale com a nossa equipe.

Perguntas frequentes

O que é ITGC?

ITGC, sigla de IT General Controls, é o conjunto de controles gerais de TI avaliado em auditorias para garantir a confiabilidade dos sistemas que sustentam as informações da empresa. Costuma cobrir gestão de mudanças, gestão de acessos e operações de TI.

A SOX se aplica a empresas brasileiras?

A Lei Sarbanes-Oxley se aplica a empresas com valores mobiliários registrados nos Estados Unidos, o que inclui companhias brasileiras listadas por lá e subsidiárias brasileiras de grupos sujeitos à lei. Mesmo empresas fora desse escopo costumam ter controles semelhantes avaliados pela auditoria externa e por programas internos de compliance.

O STMS sozinho atende à auditoria de mudanças SAP?

O STMS registra a movimentação técnica das requests pelo landscape e permite configurar um procedimento de aprovação antes do import, o que já é parte importante da evidência. Mas a auditoria também pede a justificativa de negócio da mudança, a especificação e a evidência do teste realizado, que normalmente ficam fora dele.

Como tratar mudanças emergenciais na auditoria?

Com um procedimento definido: critérios do que é emergência, aprovação posterior dentro de prazo, registro do motivo e revisão periódica do volume de emergências. O problema raramente é a emergência em si, e sim a falta de registro depois dela.

Quem governa a mudança entrega mais rápido. Quem não governa entrega risco.