El rendimiento de SAP en el punto de mira: cuando los procesos se unen a la observabilidad

S/4 Hana y ECC funcionan en paralelo, los proyectos Rise modifican los modelos operativos, y BTP y las interfaces integran estrechamente los sistemas SAP con los sistemas ajenos a SAP. Estas dependencias hacen que la transparencia integral sea aún más importante.

Los problemas de rendimiento de SAP no son fallos clásicos, sino efectos del sistema. Se produce un cuello de botella allí donde confluyen las transacciones, las ejecuciones por lotes y las integraciones, a menudo precisamente en los momentos en que el negocio es más vulnerable. Los cierres mensuales, las oleadas de envíos, las actualizaciones de precios o las cargas de las campañas modifican los patrones según los cuales funcionan los sistemas. Esta presión adicional puede provocar inestabilidad en la ruta crítica del proceso.

A esto se suma la diversidad técnica que rodea hoy en día a SAP. Las capas de base de datos y de aplicaciones son solo una parte del panorama general. Los sistemas de identidad y autorización, las latencias de red, las pasarelas de API, el middleware y los servicios en la nube también influyen en los tiempos de respuesta. Por eso, quien quiera identificar las causas debe analizar toda la ruta de la transacción, y es precisamente aquí donde entra en juego la observabilidad moderna.

Seguimiento de paisajes híbridos

La supervisión de SAP ha demostrado su eficacia a lo largo de décadas. Indica de forma fiable si un sistema está disponible y dónde se producen los cuellos de botella. Sin embargo, en entornos híbridos con numerosos puntos de integración, cualquier visión aislada llega a sus límites. No porque la supervisión sea insuficiente, sino porque las dependencias que traspasan los límites del sistema proporcionan el contexto decisivo. El problema fundamental es el aislamiento de los datos: cada equipo solo ve una parte, y falta el contexto del proceso. Esto dificulta establecer una conexión coherente entre causa y efecto a lo largo de una transacción. Hoy en día, las integraciones suelen ser el factor decisivo. iDocs que no se procesan, trabajos que fallan o servicios BTP que se vuelven inestables bajo carga. Ahí es donde surgen las interrupciones que frenan los procesos de negocio. En la práctica, esto suele manifestarse en síntomas que, en un primer momento, parecen indicar un problema interno de SAP. Una transacción se ralentiza porque un servicio externo tarda en responder al ser invocado. Una ventana de procesamiento por lotes se desplaza porque un trabajo anterior tarda demasiado en ejecutarse y bloquea los procesos posteriores. O bien, los iDocs se acumulan porque los reintentos se producen en cascada y las interfaces entran en estado de error bajo carga. Sin un contexto integral, solo queda buscar en vistas aisladas.

Transacciones en el contexto del proceso

En entornos SAP híbridos, ya no basta con fijarse en sistemas individuales. La observabilidad debe hacer visibles las transacciones a lo largo de sus rutas reales y correlacionar las señales técnicas. Solo cuando se analizan conjuntamente las métricas, los registros, los rastros y los eventos de negocio es posible identificar de forma fiable los cuellos de botella. Para ello, es fundamental disponer de una visión actualizada de las dependencias y su cadena de efectos. Cuando se identifica qué base de datos, qué servidor de aplicaciones, qué llamada a la interfaz o qué tarea está ralentizando una transacción, la resolución de problemas se vuelve más comprensible. De este modo, los equipos dejan de trabajar en el síntoma y pasan a abordar la causa en el flujo de trabajo.

Para que esto funcione, se necesita algo más que una recopilación de puntos de medición aislados. Un proceso moderno de observabilidad debe reunir señales procedentes de SAP, la capa de integración y la infraestructura, y correlacionarlas de tal manera que las anomalías técnicas se conviertan en una causa comprensible. Es fundamental la capacidad de analizar las transacciones a lo largo de sus rutas, mantener actualizadas las dependencias de forma continua e integrar las señales de los procesos de tal manera que la priorización no se base en la intensidad de las alertas, sino en el impacto que tienen en los procesos críticos.

Observabilidad basada en la inteligencia artificial

En entornos híbridos de SAP, los umbrales clásicos suelen resultar insuficientes debido a los perfiles de carga dinámicos y a las dependencias cambiantes. Un umbral estático puede resultar demasiado bajo en el siguiente nivel de escalabilidad y demasiado alto en la siguiente ventana de procesamiento por lotes. Por ello, el análisis basado en IA no trabaja principalmente con límites fijos, sino con patrones de comportamiento. Detecta desviaciones respecto al estado normal, establece relaciones entre las señales y agiliza el análisis de las causas. En este sentido, es importante establecer prioridades en función del impacto en el negocio. No todas las desviaciones constituyen una incidencia, y no todas las anomalías técnicas afectan a una ruta crítica del proceso. La relevancia solo surge cuando queda claro qué transacción se ve afectada, si la anomalía repercute en los indicadores clave del proceso y si se perfila una tendencia. Precisamente en entornos SAP, en los que las transacciones de diálogo, el procesamiento en segundo plano y las integraciones actúan simultáneamente, esta clasificación determina si los equipos actúan de forma específica o se pierden en hipótesis paralelas.

La correlación no implica causalidad

La correlación es una señal valiosa, especialmente en entornos distribuidos, en los que pueden producirse muchas anomalías al mismo tiempo. Sin embargo, el paso decisivo consiste en establecer relaciones causales a partir de coincidencias temporales. Un aumento del tiempo de respuesta en el diálogo de SAP, un pico en la base de datos y una tasa de errores en un servicio conectado pueden estar correlacionados temporalmente sin que los tres tengan la misma causa. Quien se base únicamente en las correlaciones corre el riesgo de realizar una escalada errónea. Esto cuesta tiempo y genera fricciones entre los equipos. El análisis causal se centra en las dependencias y las relaciones de causa-efecto. Se pregunta qué componente se encuentra realmente en la ruta crítica y qué cambios se producen a continuación. Esa es la diferencia entre una alarma, que solo describe que algo es inusual, y un diagnóstico, que explica por qué el proceso se ve afectado. Desde el punto de vista técnico, es importante contar con un modelo de rastreo uniforme, por ejemplo, basado en OpenTelemetry. Esto permite analizar las transacciones de SAP junto con los componentes ajenos a SAP siguiendo la misma lógica y rastrear las causas a lo largo de la ruta.

Lenguaje común: observabilidad

Un aspecto que a menudo se subestima de la observabilidad moderna de SAP es la cuestión del público objetivo. La monitorización clásica habla el lenguaje de las TI: carga de la CPU, tiempos de respuesta, índices de error. Esto es relevante para los equipos de Basis y los SRE, pero resulta de poca utilidad para el departamento de negocio, que quiere saber si el proceso «Order-to-Cash» funciona correctamente.

Los eventos empresariales cubren esta laguna. Los datos técnicos de telemetría se complementan con eventos y métricas relevantes para el negocio. De este modo, se puede visualizar, por ejemplo, cuántos pedidos se han procesado en un intervalo de tiempo determinado, cuántos iDocs se encuentran en estado de error o cómo ha variado el tiempo de tramitación de un proceso de contabilización en comparación con el periodo de referencia.

Esta visión del proceso puede integrarse con señales técnicas, de modo que los equipos no trabajen en los síntomas, sino en las causas que se encuentran en el flujo de transacciones.

Esto cambia la base sobre la que se toman las decisiones. Cuando el equipo de base, el SRE, el soporte de SAP y el departamento especializado acceden a los mismos datos, se crea un lenguaje común. Las prioridades se definen de forma más objetiva, ya que se hace visible el impacto empresarial de una avería. Y la pregunta „¿El sistema está en buen estado o no?“ se sustituye por la pregunta más relevante: „¿El proceso funciona o falla?“.

Proceso de gestión de incidencias modificado

Muchas organizaciones han ido optimizando su análisis de causas a lo largo de los años. Sin embargo, en entornos híbridos de SAP, este enfoque llega a sus límites: una incidencia se remite a la sala de crisis, varios equipos comprueban sus herramientas en paralelo y el resultado suele ser una hipótesis que solo se verifica a posteriori.

Una visión conjunta de la observabilidad cambia el enfoque. En lugar de capturas de pantalla aisladas, se crea una línea de eventos conjunta a partir de señales técnicas y relacionadas con los procesos. Esto reduce las consultas y agiliza los traspasos entre equipos. Las revisiones posteriores a los incidentes también ganan en solidez, ya que se pueden rastrear la causa y el efecto a lo largo de la ruta de la transacción. De este modo, la gestión de incidencias se convierte, paso a paso, en un modelo operativo que aprende.

Asesor en modernización

Los proyectos Rise trasladan las dependencias y la responsabilidad operativa. Por eso, la observabilidad antes, durante y después de la migración es un factor decisivo para el éxito. Antes de la migración, hay que fijarse en los valores de referencia y las rutas críticas. ¿Qué transacciones son críticas para el negocio?, ¿cuáles son los tiempos de respuesta normales? y ¿qué interfaces determinan el rendimiento del proceso? Sin esta referencia, cualquier desviación se convertirá más adelante en un tema de debate en lugar de en un diagnóstico.

Durante las fases paralelas, lo que cuenta son las mediciones comparativas. Si algunas partes del entorno ya se ejecutan en la nube y otras siguen en las instalaciones, las desviaciones en la latencia, las tasas de error o el rendimiento deben detectarse a tiempo. De lo contrario, un problema no se detectará hasta que llegue al departamento correspondiente.

Tras la puesta en marcha, la observabilidad sigue siendo fundamental, ya que los entornos en la nube cambian más rápidamente. El escalado, las nuevas dependencias y los cambios en los patrones de integración pueden generar nuevos tipos de errores. Una visión integral ayuda a clasificar estos efectos antes de que se consoliden como un riesgo para los procesos.

Factores que facilitan la modernización de SAP

La supervisión de SAP no es un fin en sí misma. En entornos híbridos, no basta con fijarse en valores aislados. La observabilidad ayuda a explicar las causas de los problemas y a priorizarlos en el contexto de los procesos. Por eso, quien desee perfeccionar su estrategia de supervisión no debería buscar en primer lugar más puntos de medición, sino relaciones sólidas.

El avance decisivo se produce cuando la telemetría técnica, las rutas de las transacciones y las señales de los procesos se integran en una vista común. Entonces, la pregunta „¿el sistema está bien o mal?“ se convierte en una cuestión que realmente afecta al funcionamiento. ¿Funciona el proceso? Y, si no es así, ¿cuál es la causa? (Fuente: Dynatrace)