Todo incidente serio empieza parecido. Un mensaje de error que apunta al lugar equivocado, un usuario que describe el síntoma a medias y un reloj de SLA corriendo. El trabajo difícil casi nunca es aplicar la corrección — es descubrir cuál de las doce causas plausibles ocurrió realmente. Quien ya investigó producción lo sabe: el cuello de botella nunca fue escribir la nota del ticket, fue cruzar señales dispersas.

Ahí es donde la IA ayuda de verdad — y no donde el discurso de mercado suele ubicarla. Un asistente no adivina la solución de un incidente SAP. Él dirige la investigación: lee el dump entero sin saltarse una línea, cruza la evidencia de una transacción con la de otra, propone una hipótesis y, lo más valioso, indica qué prueba confirma o descarta esa hipótesis. A continuación, tres investigaciones reales — todas anonimizadas — y el método que quedó de ellas.

El cuello de botella nunca fue la corrección

En la mayoría de los incidentes, la corrección final cabe en una línea: activar un repositorio, quitar un alias, ajustar la validez de una condición. Lo caro es armar la cadena causal hasta ella. Vale la asimetría conocida por cualquier equipo de soporte: el mensaje de error dice dónde se detuvo el programa, no por qué se detuvo.

Esto no es exclusivo del ERP: la misma asimetría aparece en la regla de firewall que «desaparece» y en el permiso de nube que solo falla en horario pico. Por eso tratamos la investigación como disciplina de soporte, no como talento individual.

Tres investigaciones

1. Los jobs que debían existir y no existían

El síntoma llegó desde el negocio: aprobaciones detenidas, workflow que no avanzaba. La lectura natural del equipo fue que alguien había borrado o suspendido los jobs. Pero la programación no mostraba jobs suspendidos: mostraba ausencia — decenas de rutinas estándar que deberían estar ahí no existían.

La pregunta cambió de «¿quién detuvo los jobs?» a «¿quién debería haber creado esos jobs?». Esas rutinas técnicas no nacen a mano: las genera el Technical Job Repository (transacción SJOBREPO). Con el repositorio desactivado, nada se genera — y nada acusa error, porque para el planificador no hay nada mal. La corrección fue activarlo y mandar a regenerar.

La tentación era crear los jobs a mano: habría funcionado por algunas semanas y se habría roto en el siguiente paquete de actualización.

2. La bandeja de entrada que dejó de listar tareas

La bandeja de tareas de Fiori dejó de listar aprobaciones en un ambiente de producción. El error en el navegador era genérico — fallo al cargar la lista. Ninguna pista sobre autorización, workflow o servicio.

La evidencia apareció al comparar la configuración del servicio OData con la de un sistema de calidad donde todo funcionaba. El servicio de tareas corre en modo multiorigen: consulta varios orígenes y junta el resultado. En producción había un alias extra apuntando al propio mandante local, heredado de una configuración antigua — y un origen inválido derribaba la respuesta entera en vez de ser ignorado.

Quitar el alias devolvió la bandeja al aire en minutos. Lo que importa es el método: la comparación entre ambientes fue la evidencia. Leyendo solo producción, ese alias nunca habría parecido sobrante.

3. El error fiscal que apuntaba a la dirección equivocada

Este es el caso favorito de quien disfruta un mensaje engañoso. Un asiento fiscal fallaba con un error que citaba el domicilio fiscal. Equipos enteros han perdido días en este punto: revisan la dirección del proveedor, el código de jurisdicción, el maestro del centro. Todo consistente, y el error continúa.

La causa estaba en otro lugar. Una condición de impuesto del cálculo tenía registro válido solo a partir de una fecha futura, y el documento era anterior a ese inicio de validez. Sin registro válido para la fecha, el cálculo no cierra — y el mensaje cita el domicilio fiscal, que es donde el programa se rinde, no donde está el problema.

Fíjese en la forma de la pista: no es un valor equivocado, es una fecha. Cruzar la fecha del documento con la validez de los registros es la verificación mecánica que la IA hace en segundos y que un humano cansado se salta, porque «eso ya se verificó».

El método en cuatro tiempos

Los tres casos siguen el mismo diseño — simple lo bastante para caber en una tarjeta, riguroso lo bastante para que nadie se salte una etapa.

1. Síntoma. Lo que el usuario ve, con precisión: qué documento, qué usuario, a qué hora, qué cambió desde la última vez que funcionó.
2. Hipótesis. Una causa plausible, escrita como una afirmación comprobable. «Es autorización» no es hipótesis; «falta el objeto X para el perfil Y» sí lo es.
3. Evidencia. La prueba que confirma o derriba la hipótesis: comparar con un ambiente sano, reproducir con otro usuario, mirar la validez de un registro.
4. Corrección. Aplicada en ambiente controlado, transportada con registro de lo que se hizo y por qué.

Saltarse el tercer tiempo es el error más caro del soporte. Sin evidencia, la «corrección» es la primera hipótesis aplicada con prisa — y acierta en una parte razonable de los casos, lo que es pésimo: la parte que acierta le enseña al equipo a seguir adivinando. El incidente reaparece semanas después con otra ropa, nadie conecta un caso con el otro, y así nace un backlog de problemas crónicos.

Qué cambia en el AMS cuando entra la IA

Tres efectos aparecen de forma consistente en el soporte SAP. Ninguno es «la IA resolvió el ticket».

• Tiempo hasta la primera hipótesis. Es el indicador que más cae. Leer un dump completo y correlacionarlo con el log del sistema y el historial de transportes de esa ventana es trabajo de lectura, no de genialidad — y es lo que la IA hace sin cansarse. El analista llega al punto de decisión con tres hipótesis ordenadas, no con una pantalla en blanco.
• Transferencia de conocimiento. Un junior con un asistente que exige hipótesis y evidencia investiga con el formato de un senior. Le falta el repertorio del «ya vi esto antes», pero deja de saltarse etapas — y el repertorio se construye exactamente ahí, un caso a la vez.
• Documentación que nace del incidente. El registro del ticket deja de ser un párrafo escrito con prisa y se vuelve subproducto de la investigación: síntoma, hipótesis descartadas, evidencia y corrección. La base de conocimiento pasa a guardar lo que nadie documenta y todo el mundo rehace — las hipótesis derribadas.

Los límites honestos

Vale decir lo que la IA no hace — descubrirlo en medio de una crisis sale caro.

• No ve aquello a lo que no tiene acceso. Sin el log, la configuración y la comparación con el ambiente sano, trabaja solo con lo que usted escribió — y razona muy bien sobre una realidad incompleta.
• Se equivoca con confianza. Una hipótesis equivocada llega con la misma redacción segura que la correcta. Por eso el tercer tiempo no es opcional: la evidencia existe para arbitrar entre la IA y usted.
• Nada sustituye la prueba en ambiente controlado. Corrección validada en calidad y transportada con rastro. La sugerencia de un asistente no justifica un cambio en producción.
• El dato sensible no va al prompt. Anonimice antes: los dumps y los logs llevan nombres, documentos, valores y a veces credenciales. Es una regla de seguridad como cualquier otra — y debe estar en la política de uso, no en la buena voluntad de quien está con prisa.

Para profundizar, dos materiales de Inove Academy ayudan a convertir esto en rutina. La guía rápida de AMS y SLA muestra cómo estructurar plazos, colas y gobernanza — incluida la separación entre incidente y problema, que es lo que le da lugar formal al análisis de causa raíz en el contrato. Y el material de prácticas SAP reúne los estándares de configuración y transporte que reducen la posibilidad de que el incidente exista.

Al final, la IA no trajo un detective nuevo a la mesa. Trajo un asistente incansable, que lee todo e insiste en preguntar qué evidencia sostiene la conclusión. La investigación sigue siendo humana — solo que ahora empieza mucho más cerca del final.