Qué cubre un servicio AMS
Un AMS bien definido cubre cuatro tipos de trabajo. El mantenimiento correctivo atiende incidentes: algo que funcionaba dejó de hacerlo, desde un documento que no se emite hasta un proceso detenido. El soporte funcional resuelve dudas de los usuarios y los acompaña en tareas poco frecuentes, como un cierre anual. El mantenimiento evolutivo agrega mejoras pequeñas y medianas que no justifican un proyecto formal: un reporte nuevo, un campo, un ajuste de flujo, una automatización. Y el mantenimiento preventivo se ocupa de que los problemas no lleguen: revisión periódica del sistema, aplicación de parches, monitoreo de integraciones y de tareas programadas, y planificación de las actualizaciones de versión. En un ERP chileno entra aquí también vigilar las piezas de las que depende la facturación electrónica, como la vigencia del certificado digital y la disponibilidad de folios CAF. Lo que un AMS normalmente no cubre son proyectos nuevos de gran tamaño, que se cotizan aparte.
-
Correctivo y soporte funcional: incidentes y dudas de usuarios con tiempos comprometidos
-
Evolutivo: mejoras acotadas con cargo a una bolsa de horas mensual
-
Preventivo: parches, monitoreo, revisión periódica y planificación de actualizaciones
Niveles de servicio: qué es un SLA y qué debe decir
El corazón de un AMS es el acuerdo de niveles de servicio, o SLA por su sigla en inglés. Un SLA serio define, primero, una clasificación de severidad: no es lo mismo una caída que impide facturar que una consulta sobre un reporte. Para cada severidad fija un tiempo de respuesta, que es cuánto tarda alguien competente en tomar el caso, y un tiempo objetivo de resolución o de mitigación, que es cuánto tarda la operación en volver a funcionar aunque la solución definitiva llegue después. Define además el horario de cobertura, que puede ir desde horario hábil hasta atención continua todos los días, los canales para abrir un caso y el procedimiento de escalamiento cuando algo no se resuelve a tiempo. Conviene revisar dos detalles que suelen pasar inadvertidos: quién decide la severidad de un caso y cómo se cuenta el tiempo cuando el proveedor queda a la espera de información de tu equipo.
AMS, soporte reactivo y garantía de proyecto: tres cosas distintas
Se confunden a menudo y no son lo mismo. La garantía de proyecto cubre, por un período limitado tras la salida en vivo, los defectos de lo que el implementador entregó: si algo de lo acordado no funciona como se especificó, lo corrige sin costo. No cubre dudas de uso, cambios ni mejoras, y termina en una fecha. El soporte reactivo, o por evento, consiste en llamar a un proveedor cuando algo falla y pagar las horas que tome resolverlo; no tiene tiempos comprometidos, nadie conoce tu sistema de antemano y cada caso parte explicando el contexto desde cero. El AMS es un contrato continuo: hay un equipo asignado que conoce tu instalación, tiempos de respuesta comprometidos, trabajo preventivo y un presupuesto mensual previsible. El soporte reactivo puede ser suficiente para un sistema pequeño y estable. Cuando el ERP sostiene la facturación, la bodega o la producción, depender de la disponibilidad de alguien en el momento de la falla es un riesgo que conviene medir.
Cómo se mide un AMS
Un AMS que no se mide es solo una factura mensual. Los indicadores habituales son el cumplimiento de los tiempos de respuesta y de resolución por severidad, el volumen de casos abiertos y cerrados en el período, la antigüedad de los casos pendientes, la tasa de reapertura, que muestra si los problemas se resuelven de verdad o solo se cierran, y el consumo de la bolsa de horas separado entre correctivo y evolutivo. Esa última distinción importa: si casi todas las horas se van en corregir, el sistema tiene un problema de fondo que ninguna mesa de ayuda va a resolver. Un buen proveedor entrega un informe periódico con estos datos, analiza las causas que se repiten y propone acciones para eliminarlas, por ejemplo capacitar a un área que genera muchos casos por el mismo motivo. Pide ver un informe de ejemplo antes de contratar; dice más sobre el servicio que cualquier presentación comercial.
AMS en Odoo y AMS en SAP: qué cambia
La lógica es la misma y cambia la escala. En una instalación de SAP, el AMS suele organizarse por especialidad: consultores funcionales por módulo, como finanzas, logística o producción; un equipo técnico de programación; y la administración de la plataforma, que en modalidades como RISE with SAP queda en parte en manos del propio SAP, mientras la configuración funcional, los desarrollos y las integraciones siguen siendo responsabilidad del cliente y de su partner. En Odoo, los equipos son más compactos y un mismo consultor suele cubrir varias aplicaciones, con apoyo de desarrolladores para los módulos a medida. Hay además un tema propio de Odoo: el fabricante publica una versión nueva cada año, y planificar cuándo y cómo actualizar, sobre todo si hay desarrollos propios, es parte natural del servicio. En ambos mundos vale el mismo principio: el mejor AMS lo presta un equipo que conoce cómo y por qué se configuró tu sistema.
Cuándo contratarlo y cómo dimensionarlo
El momento natural para contratar un AMS es el término del acompañamiento posterior a la salida en vivo, cuando el equipo del proyecto se retira y la operación queda sola. También tiene sentido cuando heredas un ERP sin documentación, cuando la persona que lo sabía todo dejó la empresa, o cuando los incidentes empiezan a afectar procesos críticos. Para dimensionarlo, parte por tres preguntas: qué procesos no pueden detenerse y en qué horarios ocurren, cuántos casos genera hoy tu operación en un mes normal, y cuánto trabajo evolutivo tienes en carpeta. Con eso se define la cobertura horaria y el tamaño de la bolsa de horas. Es razonable partir con un plan acotado y ajustarlo tras unos meses con datos reales. Revisa también las condiciones de salida: la documentación, los accesos y el conocimiento del sistema deben quedar en tu empresa, no en la cabeza del proveedor.
