El go-live no es el final
La mayoría de los proyectos presupuestan la construcción y tratan el soporte como un agregado opcional. En sistemas críticos esa distribución está invertida: el sistema se construye una vez y se opera durante años.
Lo que determina si una plataforma sigue siendo confiable al tercer año no es la calidad del código inicial, sino si alguien se ocupó de las actualizaciones, de los cambios de regulación y de los incidentes que aparecieron en el camino.
Qué incluye
Administración y mantenimiento remoto de sus sistemas, Mesa de Ayuda para reporte y seguimiento de incidentes, monitoreo, y aplicación de actualizaciones planificadas en ventanas acordadas con su operación.
Los niveles de suscripción se definen según la criticidad de cada sistema. No tiene sentido pagar cobertura de máxima disponibilidad para una plataforma que puede esperar al día siguiente, ni tenerla insuficiente para la que sostiene la atención al cliente.
Cómo debe estar escrito un SLA
Con niveles de severidad diferenciados. Un error de formato en un reporte y una caída del canal transaccional no pueden tener el mismo tiempo de respuesta comprometido.
Con consecuencias definidas ante incumplimiento. Un SLA sin consecuencia es una declaración de intenciones. Las penalizaciones no compensan el daño operativo, pero alinean incentivos.
Con un esquema de escalamiento. Los proyectos críticos no pueden depender de la disponibilidad de una persona.
Reportería
Cada período entregamos el detalle de incidentes atendidos, tiempos de respuesta y resolución contra lo comprometido, y trabajo preventivo ejecutado.
Esa evidencia sirve para dos cosas: que usted evalúe si el servicio cumple, y que su organización tenga documentación de la gestión de sus sistemas cuando alguien se la pida.