Todo incidente sério começa parecido. Uma mensagem de erro que aponta para o lugar errado, um usuário que descreve o sintoma pela metade e um relógio de SLA correndo. O trabalho difícil quase nunca é aplicar a correção — é descobrir qual das doze causas plausíveis realmente aconteceu. Quem já investigou produção sabe: o gargalo nunca foi escrever a nota do chamado, foi cruzar sinais dispersos.

É aí que a IA ajuda de verdade — e não onde o discurso de mercado costuma colocá-la. Um assistente não adivinha a solução de um incidente SAP. Ele dirige a investigação: lê o dump inteiro sem pular linha, cruza a evidência de uma transação com a de outra, propõe hipótese e, o mais valioso, indica qual teste confirma ou descarta essa hipótese. A seguir, três investigações reais — todas anonimizadas — e o método que ficou delas.

O gargalo nunca foi a correção

Na maioria dos incidentes, a correção final cabe em uma linha: ativar um repositório, remover um alias, ajustar a validade de uma condição. O caro é montar a cadeia causal até ela. Vale a assimetria conhecida de qualquer time de sustentação: a mensagem de erro diz onde o programa parou, não por que parou.

Isso não é exclusividade do ERP: a mesma assimetria aparece na regra de firewall que “some” e na permissão de nuvem que só falha em horário de pico. Por isso tratamos investigação como disciplina de sustentação, não como talento individual.

Três investigações

1. Os jobs que deveriam existir e não existiam

O sintoma chegou pelo negócio: aprovações paradas, workflow que não andava. A leitura natural do time foi que alguém apagou ou suspendeu os jobs. Mas o agendamento não mostrava jobs suspensos: mostrava ausência — dezenas de rotinas padrão que deveriam estar ali não existiam.

A pergunta mudou de “quem parou os jobs?” para “quem deveria ter criado esses jobs?”. Essas rotinas técnicas não nascem à mão: são geradas pelo Technical Job Repository (transação SJOBREPO). Com o repositório desativado, nada é gerado — e nada acusa erro, porque para o agendador não há nada errado. A correção foi ativar e mandar regerar.

A tentação era criar os jobs à mão: funcionaria por algumas semanas e quebraria no próximo pacote de atualização.

2. A caixa de entrada que parou de listar tarefas

A caixa de tarefas do Fiori parou de listar aprovações em um ambiente de produção. O erro no navegador era genérico — falha ao carregar a lista. Nenhuma pista sobre autorização, workflow ou serviço.

A evidência apareceu ao comparar a configuração do serviço OData com a de um sistema de qualidade onde tudo funcionava. O serviço de tarefas roda em modo multi-origem: consulta várias origens e junta o resultado. Na produção havia um alias extra apontando para o próprio mandante local, herdado de configuração antiga — e uma origem inválida derrubava a resposta inteira em vez de ser ignorada.

Remover o alias devolveu a caixa ao ar em minutos. O que importa é o método: a comparação entre ambientes foi a evidência. Lendo só a produção, aquele alias nunca pareceria sobrando.

3. O erro fiscal que apontava para o endereço errado

Este é o caso favorito de quem gosta de mensagem enganosa. Um lançamento fiscal falhava com erro que citava domicílio fiscal. Times inteiros já perderam dias nesse ponto: revisam endereço do fornecedor, código de jurisdição, cadastro do centro. Tudo consistente, e o erro continua.

A causa estava em outro lugar. Uma condição de imposto do cálculo tinha registro válido só a partir de uma data futura, e o documento era anterior a esse início de validade. Sem registro válido para a data, o cálculo não fecha — e a mensagem cita o domicílio fiscal, que é onde o programa desiste, não onde o problema está.

Repare no formato da pista: não é um valor errado, é uma data. Cruzar a data do documento com a validade dos registros é a conferência mecânica que a IA faz em segundos e que um humano cansado pula, porque “isso já foi verificado”.

O método em quatro tempos

Os três casos seguem o mesmo desenho — simples o bastante para caber em um cartão, rigoroso o bastante para ninguém pular etapa.

1. Sintoma. O que o usuário vê, com precisão: qual documento, qual usuário, qual horário, o que mudou desde a última vez que funcionou.
2. Hipótese. Uma causa plausível, escrita como afirmação testável. “É autorização” não é hipótese; “falta o objeto X para o perfil Y” é.
3. Evidência. O teste que confirma ou derruba a hipótese: comparar com um ambiente saudável, reproduzir com outro usuário, olhar a validade de um registro.
4. Correção. Aplicada em ambiente controlado, transportada com registro do que foi feito e por quê.

Pular o terceiro tempo é o erro mais caro da sustentação. Sem evidência, a “correção” é a primeira hipótese aplicada com pressa — e ela acerta em parte razoável dos casos, o que é péssimo: a parte que acerta ensina o time a continuar chutando. O incidente reaparece semanas depois com outra roupa, ninguém liga um caso ao outro, e é assim que nasce um backlog de problemas crônicos.

O que muda no AMS quando a IA entra

Três efeitos aparecem de forma consistente na sustentação SAP. Nenhum é “a IA resolveu o chamado”.

• Tempo até a primeira hipótese. É o indicador que mais cai. Ler um dump completo e correlacionar com o log de sistema e o histórico de transportes daquela janela é trabalho de leitura, não de genialidade — e é o que a IA faz sem cansar. O analista chega ao ponto de decisão com três hipóteses ordenadas, não com uma tela em branco.
• Transferência de conhecimento. Um júnior com um assistente que exige hipótese e evidência investiga no formato de um sênior. Falta-lhe o repertório do “já vi isso antes”, mas ele para de pular etapa — e o repertório se constrói exatamente aí, um caso por vez.
• Documentação que nasce do incidente. O registro do chamado deixa de ser um parágrafo escrito às pressas e vira subproduto da investigação: sintoma, hipóteses descartadas, evidência e correção. A base de conhecimento passa a guardar o que ninguém documenta e todo mundo refaz — as hipóteses derrubadas.

Os limites honestos

Vale dizer o que a IA não faz — descobrir isso no meio de uma crise sai caro.

• Ela não vê o que não tem acesso. Sem o log, a configuração e a comparação com o ambiente saudável, ela trabalha só com o que você digitou — e raciocina muito bem sobre uma realidade incompleta.
• Ela erra com confiança. Hipótese errada chega com a mesma redação segura da hipótese certa. Por isso o terceiro tempo não é opcional: a evidência existe para arbitrar entre a IA e você.
• Nada substitui teste em ambiente controlado. Correção validada em qualidade e transportada com rastro. Sugestão de assistente não justifica mudança em produção.
• Dado sensível não vai para prompt. Anonimize antes: dump e log carregam nome, documento, valor e às vezes credencial. É uma regra de segurança como outra qualquer — e precisa estar na política de uso, não na boa vontade de quem está com pressa.

Para ir mais fundo, dois materiais da Inove Academy ajudam a virar isso rotina. O guia rápido de AMS e SLA mostra como estruturar prazos, filas e governança — inclusive a separação entre incidente e problema, que é o que dá lugar formal à análise de causa raiz no contrato. E o material de práticas SAP reúne os padrões de configuração e transporte que reduzem a chance de o incidente existir.

No fim, a IA não trouxe um detetive novo para a mesa. Trouxe um assistente incansável, que lê tudo e insiste em perguntar qual evidência sustenta a conclusão. A investigação continua humana — só que agora começa bem mais perto do fim.