El soporte AMS (Application Management Services) sobre plataformas críticas como SAP es uno de esos servicios donde el éxito es invisible y el fracaso es ruidoso. Cuando todo funciona, nadie se entera de que existe un equipo detrás monitoreando, atendiendo tickets, escalando alertas y ejecutando cambios. Cuando algo falla a las 3 de la madrugada de un domingo, ese mismo equipo es la diferencia entre una nota a pie de página en el reporte mensual y una llamada del CFO el lunes a primera hora.

Este artículo es una destilación de lecciones aprendidas operando AMS sobre sistemas SAP en modalidad 24/7/365, sin nombres ni clientes identificables. Son anécdotas reales, con sus consecuencias y sus aprendizajes, contadas con el único propósito de que quien esté armando un servicio similar no tropiece con las mismas piedras.

Qué es realmente un AMS y por qué se subestima

Un AMS no es un help desk. No es una mesa de servicios genérica. Es un servicio especializado donde el proveedor asume la operación funcional y técnica de una aplicación crítica, con responsabilidad sobre la continuidad operativa, la resolución de incidentes, la implementación de cambios menores, y en muchos casos la evolución incremental del sistema.

En el caso de SAP, esto incluye típicamente:

  • Soporte funcional sobre los módulos productivos (FI, CO, SD, MM, PP, HR, según el alcance).
  • Soporte técnico Basis (administración del sistema, transportes, monitoreo, backups, performance).
  • Desarrollos correctivos y evolutivos menores (ABAP, configuración, formularios).
  • Gestión de incidentes con SLA definido por severidad.
  • Gestión de requerimientos (change requests) con un proceso de aprobación y entrega.
  • Monitoreo proactivo del sistema y de los procesos batch críticos.
  • Soporte ante upgrades, parches, ventanas de mantenimiento y planes de contingencia.

La trampa más común al armar un AMS es venderlo (o comprarlo) como un servicio de horas de consultor a demanda. Eso es staff augmentation, no AMS. La diferencia es que el AMS asume responsabilidad sobre resultados (disponibilidad, tiempo de resolución, calidad), no sobre horas trabajadas. Esa asimetría cambia todo: el modelo de pricing, la estructura del equipo, las herramientas necesarias y, sobre todo, la forma en que se gestionan los SLAs.

Anatomía de un SLA que funciona

Los SLAs son el contrato operativo entre proveedor y cliente. Bien diseñados, alinean expectativas y permiten medir objetivamente el servicio. Mal diseñados, son la fuente principal de conflictos en un AMS.

Las dimensiones que un SLA debe cubrir

  • Severidad del incidente. Típicamente cuatro niveles, desde S1 (sistema caído o proceso crítico bloqueado, sin workaround) hasta S4 (consulta o requerimiento menor). Cada nivel debe tener una definición operativa clara, no ambigua, con ejemplos concretos. La discusión más improductiva en cualquier AMS es la que ocurre cuando el cliente clasifica un ticket como S1 y el proveedor lo baja a S3.
  • Tiempo de respuesta (Time to Acknowledge). Cuánto tarda el equipo en acusar recibo y comenzar a trabajar el ticket. Para S1 suele ser 15 minutos en horario 24/7, para S4 puede ser de varias horas en horario laboral.
  • Tiempo de resolución (Time to Resolve). Cuánto tarda en cerrarse el incidente. Es el SLA más controversial porque depende de factores que no siempre están bajo control del proveedor: disponibilidad del cliente para validar, dependencia de terceros, acceso a ambientes. Por eso muchos contratos modernos usan Time to Restore (tiempo hasta restablecer la operación, aunque sea con workaround) separado de Time to Resolve (tiempo hasta la solución definitiva).
  • Ventanas de servicio. ¿Qué cubre el 24/7? ¿Todos los incidentes o solo S1 y S2? ¿Hay horario extendido para requerimientos? Los proveedores que dicen "todo 24/7" sin matizar terminan con equipos desangrados y clientes insatisfechos porque las respuestas nocturnas son de menor calidad.
  • Indicadores de calidad. No solo tiempos. Reaperturas de tickets (cuando un ticket cerrado se vuelve a abrir porque la solución no funcionó), satisfacción del usuario, cumplimiento de cambios sin rollback, disponibilidad del sistema medida en uptime.
  • Penalidades y créditos. Qué pasa cuando se incumple. Los descuentos sobre la facturación mensual son el mecanismo más común, pero deben estar bien diseñados: penalizar demasiado lleva a que el proveedor esconda incidentes, penalizar muy poco hace que el SLA pierda peso real.
"Ningún SLA sobrevive a su primer trimestre sin ajustes. Un buen contrato incluye una revisión formal a los 90 días."

Los volúmenes reales nunca coinciden con los estimados, las definiciones de severidad siempre necesitan refinamiento, y las exclusiones (qué no cuenta para el SLA) son una conversación permanente.

La estructura del equipo: turnos, rotación y el costo invisible del 24/7

Operar un AMS 24/7/365 sobre SAP requiere una estructura humana que rara vez se dimensiona bien al inicio. La aritmética parece simple: si necesito cobertura 24/7 con un solo recurso, necesito al menos cuatro personas para cubrir turnos rotativos respetando descanso, vacaciones y ausentismo. En la práctica, si quieres cobertura con un consultor calificado en cada turno, la cifra real está más cerca de seis.

Modelo típico de niveles (tiered support)

N1

Recepción de tickets, clasificación inicial, atención de consultas básicas, ejecución de procedimientos documentados (rerun de jobs, desbloqueo de usuarios, consultas estándar). Suele ser perfil junior con guion operativo bien definido.

N2

Consultores funcionales y técnicos con experiencia en los módulos correspondientes. Resuelven la mayoría de los incidentes que escalan de N1. Hacen configuración, análisis de logs, depuración de procesos.

N3

Especialistas senior, arquitectos, expertos Basis. Atacan los problemas complejos, los que requieren conocimiento profundo del sistema o del negocio del cliente. Suelen ser pocos y compartidos entre varias cuentas.

SDM

Coordinación / Service Delivery Manager. No es un nivel técnico pero es crítico. Gestiona la relación con el cliente, los reportes, los escalamientos formales, y la priorización de la cola.

La pregunta operativa más común es cuánto del 24/7 cubrir con N1 vs N2. En la madrugada, la mayoría de los incidentes que llegan son de severidad alta (los usuarios no abren tickets de consulta a las 4 AM), pero también son los menos frecuentes. Tener un N2 sentado de guardia toda la noche para un volumen bajo es caro; no tenerlo es riesgoso.

La solución más balanceada que vimos funcionar: N1 presencial en turnos rotativos cubriendo recepción, y N2 / N3 en modalidad on-call con tiempos de respuesta acotados (típicamente 30 minutos para incidentes S1 fuera de horario). El on-call rota semanalmente y se paga adicional, sea como bono fijo o como horas extraordinarias activadas solo cuando hay llamada efectiva.

El costo invisible: el turno nocturno y el on-call tienen una tasa de rotación significativamente mayor que el turno diurno. Hay que presupuestar contratación y onboarding continuo, no como evento extraordinario sino como costo recurrente del servicio. Equipos que no entienden esto operan con turnos crónicamente subocupados y SLAs en riesgo permanente.

La gestión de escalamientos: el arte de saber cuándo gritar

Un escalamiento es la decisión consciente de subir un incidente o una situación a un nivel superior, sea técnico, jerárquico o contractual. Hacerlo bien es una habilidad que se construye con práctica y con marco. Hacerlo mal genera dos patologías opuestas: escalar todo (saturas a los seniors y diluyes la urgencia real) o no escalar nada (incidentes que crecen en silencio hasta volverse crisis).

Tipos de escalamiento que un AMS debe gestionar

  1. Escalamiento técnico. Cuando el nivel actual no puede resolver y necesita pasar el caso a un nivel superior. Debe estar definido en el procedimiento de cada tipo de incidente, con criterios objetivos: tiempo transcurrido sin avance, complejidad identificada, dependencia de conocimiento especializado.
  2. Escalamiento jerárquico interno. Cuando un incidente requiere visibilidad de la gerencia del proveedor (por riesgo de SLA, por sensibilidad política, por impacto financiero). Debe seguir un camino predefinido y rápido, no improvisado.
  3. Escalamiento al cliente. Cuando hace falta que el cliente haga algo: dar acceso, validar, aprobar un cambio urgente, contactar a un tercero. La forma más común de error aquí es no escalar a tiempo y luego justificar el incumplimiento con "estábamos esperando información del cliente". Si esperaste tres horas sin escalar formalmente, el reloj del SLA siguió corriendo.
  4. Escalamiento a terceros. Cuando se trata de un problema que excede el AMS y requiere intervención de un proveedor de red, de hosting, o del área de seguridad. Aquí la clave es documentar en el ticket cada acción tomada para mantener la trazabilidad.
01 Anécdota sin nombre

A las 23:40 de un viernes de cierre de mes, un proceso batch crítico de cierre contable empezó a fallar con un error en una tabla custom. El N1 de guardia lo escaló al N2 on-call a las 23:55. El N2 identificó que el problema era un lock en una tabla causado por un usuario que había dejado abierta una transacción y se había desconectado de la VPN sin liberar el bloqueo. Resolución técnica: trivial, soltar el lock. Tiempo total del ticket: 12 minutos desde reportado hasta resuelto.

Pero el coordinador no escaló al cliente en el momento, asumiendo que no era necesario porque "se iba a resolver rápido". El cliente se enteró por su área de finanzas a las 8 AM del sábado, cuando vio que el cierre no había corrido. La conversación del lunes no fue sobre los 12 minutos de incidente, fue sobre las 8 horas en que nadie comunicó nada.

Lección: el SLA técnico se cumplió, el SLA de comunicación se rompió. Y muchas veces el segundo importa más.

El monitoreo proactivo: el AMS que no espera al ticket

La diferencia entre un AMS reactivo y un AMS proactivo está en quién detecta primero el problema. Un AMS reactivo se entera cuando el usuario llama. Un AMS proactivo tiene alertas configuradas que disparan antes de que el usuario note algo.

Las capas de monitoreo que un AMS sobre SAP debe tener

  • Monitoreo de infraestructura. CPU, memoria, disco, conectividad de los servidores del landscape (DEV, QAS, PRD). En entornos en la nube, también costos y consumo de recursos.
  • Monitoreo del sistema SAP. Estado de los procesos de trabajo, sesiones de usuario, locks, dumps (ST22), errores de actualización (SM13), spool problems, system log (SM21).
  • Monitoreo de la base de datos. Tablespaces (para Oracle, MaxDB, HANA), tablas con crecimiento anómalo, performance de queries, deadlocks.
  • Monitoreo de procesos batch. Jobs críticos (cierre de período, transferencias, integraciones), con alerta cuando un job no inicia a tiempo, cuando falla, o cuando demora más de lo esperado.
  • Monitoreo de interfaces. IDocs en estado de error (BD87), colas de qRFC bloqueadas (SMQ1/SMQ2), errores en CPI o middleware, archivos no recibidos en el horario esperado.
  • Monitoreo de negocio. Cuando es posible, indicadores funcionales: facturas no contabilizadas al cierre del día, pedidos bloqueados por crédito por más de X horas, entregas pendientes de facturar. Esto es el siguiente nivel y rara vez se implementa bien, pero es donde el AMS realmente agrega valor.

La herramienta no es lo más importante. Solution Manager, Splunk, Dynatrace, Zabbix, Datadog, dashboards custom. Lo crítico es qué se monitorea, con qué umbrales, y quién recibe la alerta. Una alerta que llega al buzón de un grupo de correo y nadie revisa, no existe. Una alerta cuyo umbral está mal calibrado y dispara cien veces al día, se vuelve ruido.

02 Anécdota sin nombre

Un cliente tenía una interfaz nocturna que cargaba archivos de un sistema externo a SAP. Durante meses funcionó sin problemas. Una noche, el proveedor del archivo cambió el formato sin avisar. La interfaz falló, no procesó nada, y nadie se enteró porque la alerta de "interfaz fallida" estaba configurada pero el correo iba a una casilla de un consultor que ya no estaba en el proyecto.

A la mañana siguiente, ventas operó todo el día con stock desactualizado y se prometió mercancía que no existía.

Lección: las alertas son tan buenas como su destinatario activo. Auditar las listas de distribución de alertas al menos cada trimestre es una práctica de higiene que evita estos casos.

La gestión del conocimiento: el activo que más se descuida

Un AMS sin gestión del conocimiento es un AMS que reinventa la rueda en cada turno. Los consultores rotan, los clientes cambian sus procesos, las soluciones a problemas recurrentes se pierden en el correo de quien las resolvió la primera vez. El resultado: incidentes que se podrían resolver en 20 minutos toman 4 horas porque el consultor de turno no sabe que ya pasó antes.

Lo que debe estar documentado y vivo

  • Inventario de procesos críticos del cliente, con horarios, dependencias, criterios de éxito y procedimiento ante falla.
  • Runbooks operativos para los incidentes recurrentes. No documentación genérica, sino paso a paso específico: "si pasa X, ejecutar Y en transacción Z, validar W".
  • Base de conocimiento de problemas resueltos. Cada ticket cerrado de complejidad media o alta debería dejar una entrada en una KB consultable, con síntoma, causa raíz, solución aplicada y prevención.
  • Documentación de la arquitectura técnica. Diagramas de landscape, interfaces, integraciones, perfiles de autorización críticos, customizaciones relevantes.
  • Calendario operativo. Procesos por día, semana, mes, año. Cuándo corren los cierres, cuándo se hacen los upgrades, cuándo son las ventanas de mantenimiento.

La trampa más común: la documentación se hace al inicio del contrato y nunca se actualiza. A los seis meses está desactualizada, al año es contraproducente porque la gente cree que sigue siendo válida. Una práctica que vimos funcionar bien: incluir en el SLA un indicador de "cobertura de conocimiento", medido por el porcentaje de tickets resueltos cuya solución quedó documentada en la KB. Suena burocrático, pero después de tres trimestres construye un activo que cambia la economía del servicio.

Las ventanas de cambio: donde los AMS bien gestionados se distinguen

Implementar cambios sobre un sistema productivo crítico es la actividad de mayor riesgo en un AMS. Un cambio mal ejecutado puede dejar al cliente fuera de operación por horas. Por eso existen las ventanas de cambio (change windows) y los procesos formales de gestión de cambios.

Las prácticas que separan a un equipo maduro de uno inexperto

  • Calendario de cambios negociado con anticipación. Las ventanas no se piden el día anterior, salvo emergencias. Hay un calendario mensual con ventanas predefinidas (típicamente fines de semana, fuera del horario operativo del cliente).
  • Plan de implementación documentado por escrito. Qué se va a hacer, en qué orden, con qué tiempo estimado para cada paso, quién lo ejecuta. No improvisación.
  • Plan de rollback antes de empezar. Si algo sale mal, ¿cómo vuelvo al estado anterior? Si no existe un rollback claro y testeado, no se ejecuta el cambio. Esta es la regla que más se viola y la que más caro se paga cuando se viola.
  • Validación previa en ambientes no productivos. El cambio se probó en DEV, se transportó a QAS, el cliente lo validó, y solo entonces va a PRD. Saltar QAS es la receta del desastre.
  • Comunicación al cliente del inicio, del avance y del cierre. Aunque sea un fin de semana a las 3 AM. Especialmente entonces.
  • Post-implementation review. Después del cambio, se valida que todo quedó funcionando, y al siguiente día hábil se hace una revisión rápida con el cliente. Si hubo desvíos, se documentan.
03 Anécdota sin nombre

Un cliente solicitó un cambio "menor" un viernes a las 17:00, para implementar el sábado: ajustar una validación en una user-exit de SD. El equipo lo probó en QAS, todo funcionó, lo transportó a PRD el sábado a las 22:00. El domingo a las 06:00 empezaron a llamar usuarios reportando que no podían crear pedidos de venta porque la validación rechazaba todas las operaciones.

La user-exit estaba bien, pero en QAS los datos maestros no representaban el caso real de PRD, donde había una combinación de tipos de pedido que la validación nueva no contemplaba. Tiempo de resolución: 4 horas. Impacto: 8 horas de operación del lunes con un workaround manual mientras se ajustaba la lógica.

Lección: validar en QAS no significa nada si los datos de QAS no son representativos de PRD. Y un cambio "menor" no existe; existen cambios bien evaluados y cambios apresurados.

La relación con el cliente: el factor menos técnico y el más decisivo

Después de años operando AMS, una observación se repite: la calidad técnica del servicio importa, pero la calidad de la relación con el cliente importa igual o más. Un proveedor técnicamente impecable con una relación tensa pierde el contrato. Un proveedor técnicamente promedio con una relación de confianza renueva año tras año.

Las prácticas relacionales que sostienen un AMS en el largo plazo

  • Reportes mensuales que cuentan una historia, no que listan tickets. El cliente no necesita ver 300 filas de un Excel con tickets cerrados. Necesita entender qué pasó este mes, qué patrones aparecen, dónde hay riesgos, qué se viene. Un buen reporte mensual es un documento de 8-12 páginas que un ejecutivo puede leer en 15 minutos y tener una visión completa.
  • Reuniones semanales operativas y mensuales tácticas. Ritmo predecible. La reunión semanal es para resolver problemas operativos, la mensual para revisar SLAs y planificación.
  • Transparencia ante los errores. Cuando se incumple un SLA, se reconoce, se analiza la causa raíz y se presenta un plan de acción. Esconder los incumplimientos o discutirlos en lugar de reconocerlos destruye la confianza más rápido que cualquier otra cosa.
  • Continuidad del equipo principal. Los clientes valoran enormemente que las caras visibles del AMS (el coordinador, los consultores senior) se mantengan estables. La rotación constante en estas posiciones es leída como falta de compromiso del proveedor con la cuenta.
  • Iniciativas de mejora más allá del SLA. Un AMS que solo cumple SLA es un AMS reemplazable. Un AMS que propone mejoras al cliente (automatizaciones, optimizaciones, prevención de incidentes recurrentes) se vuelve socio operativo, no proveedor.

Lecciones consolidadas que sirven de checklist

Después de varios ciclos de servicio AMS, hay un conjunto de aprendizajes que se repiten y que conviene tener presentes desde el diseño del servicio:

  • El SLA es un punto de partida, no un punto de llegada. Diseñalo para revisarlo cada trimestre los primeros 18 meses.
  • El equipo es el servicio. Invertir en retención, capacitación continua y bienestar del equipo no es un gasto, es la inversión que más rinde.
  • El monitoreo proactivo paga cada centavo. Cada incidente prevenido es un cliente más satisfecho y un equipo menos saturado.
  • La documentación es el activo de mayor valor en el largo plazo. Sin documentación, cada turno empieza de cero.
  • Los cambios son la actividad de mayor riesgo. Tratarlos con la solemnidad que merecen.
  • La comunicación con el cliente vale tanto como la resolución técnica. A veces más.
  • Los escalamientos a tiempo evitan crisis. Escalar no es debilidad, es disciplina operativa.
  • Las anécdotas son el currículum oculto del equipo. Capturar lo que se aprende de cada incidente serio convierte la experiencia individual en activo colectivo.

Cierre

Un AMS bien operado no se nota, y esa es exactamente la métrica de éxito. Cuando el cliente puede dedicarse a su negocio sin pensar en si el sistema va a estar disponible, sin preocuparse por quién atenderá la llamada del sábado a las 4 AM, sin discutir cada mes sobre SLAs incumplidos, entonces el servicio está funcionando.

Llegar a ese punto no es producto de un contrato bien escrito ni de una herramienta sofisticada. Es producto de equipos que se forman durante años, de procesos que se afinan ticket a ticket, y de relaciones de confianza que se construyen incidente a incidente. Las anécdotas que contamos aquí, sin nombres, son fragmentos de ese aprendizaje. Cada equipo de AMS va a coleccionar las suyas. Lo importante es no dejar que esas lecciones se pierdan en el correo de quien las vivió.

En próximas entregas: el modelo de pricing en AMS (bolsa de horas, equipo dedicado, transaccional), cómo se hace una transición de servicio sin romper la operación, y el rol de la automatización en la operación de AMS modernos.