Qué ocurre tras entregar monitoreo disponibilidad

La entrega del software marca el inicio de una nueva fase, y es en ese momento cuando los gerentes y dueños sienten la presión de que todo siga funcionando sin interrupciones. En este artículo encontrarás lo que ocurre realmente después de la firma, quién debe responder ante fallas, qué incluye el mantenimiento y cómo proteger tu inversión.

Lo que empieza el día de la entrega

• El proyecto se firma, pero el conocimiento no se transfiere. En la práctica, el equipo técnico entrega documentación mínima y el cliente recibe un sistema listo para usar, sin saber cómo se gestionan los logs, los umbrales de alerta o los procesos de escalamiento.
• Los SLA se convierten en promesas vagas. Muchos contratos indican “disponibilidad del 99,9%”, pero no especifican qué métricas se usan ni cómo se medirán en la realidad peruana, donde la SUNAT y la facturación electrónica exigen reportes horarios.
• Los primeros 30 días son críticos. Estadísticas de proyectos en Perú muestran que el 27 % de los incidentes críticos aparecen en el primer mes, porque el equipo interno aún no domina los paneles de monitoreo.
• Se activan los procesos de recepción. El responsable de TI debe validar que los dashboards de observabilidad estén operativos, que los umbrales de CPU, memoria y latencia coincidan con los acuerdos y que los tickets de prueba se cierren sin retraso.

Quién responde cuando algo falla

• Responsabilidad del proveedor. El contrato debe incluir un anexo de “Nivel de Servicio” que detalle tiempos de respuesta (ej. 1 h para incidentes críticos, 4 h para medianos) y canales de comunicación (correo corporativo, ticketing interno). Exigir que este anexo esté firmado antes de la entrega evita discusiones posteriores.
• Responsabilidad interna. Tu empresa debe designar un “Dueño del Servicio” que reciba las alertas, valide la gravedad y escale al proveedor según lo pactado. En Perú, es habitual que el Jefe de Operaciones asuma este rol.
• Escalamiento formal. Define una tabla de escalamiento con nombres, cargos y tiempos de respuesta. Por ejemplo, si el proveedor no responde en 1 h, el siguiente nivel debe ser el gerente de proyecto, con un plazo máximo de 2 h.
• Qué exigir por escrito. Además del SLA, solicita:
  • Registro de cambios (change log) accesible en todo momento.
  • Informe semanal de disponibilidad con métricas reales.
  • Compensación económica o extensión de contrato si se supera el umbral del 99,9 % en un mes.

Mantenimiento: qué es y qué no

• Corrección de errores (bug‑fix). Incluye la solución de fallas que impiden el funcionamiento normal. Se cubre dentro del período de garantía, típicamente 12 semanas después de la entrega.
• Mejoras (enhancements). Son cambios que añaden funcionalidades o afinan el rendimiento, como ajustar el umbral de alerta de latencia de 2 s a 1,5 s. Estas no están cubiertas por la garantía y se cotizan por separado.
• Rehacer (re‑engineering). Cuando el cliente solicita una re‑arquitectura completa, por ejemplo migrar de una base de datos on‑premise a la nube, se trata como un nuevo proyecto.
• Mantenimiento preventivo. Consiste en actualizar agentes de monitoreo, parchar sistemas operativos y validar que los certificados de seguridad (incluido SSL) estén vigentes. En Perú, la normativa de la SUNAT obliga a mantener los certificados actualizados para la facturación electrónica.
• Qué no es mantenimiento. No incluye soporte a usuarios finales que no estén vinculados al monitoreo, ni la capacitación continua del personal de TI más allá del entrenamiento inicial de 2 semanas.

Cómo evitar quedar atrapado

• Accesos claros y documentados. Exige que el proveedor entregue credenciales de administrador, tokens API y claves SSH en un documento cifrado. Guarda copias en una bóveda de contraseñas interna.
• Copias de seguridad verificadas. No basta con que el proveedor afirme que hace backup. Solicita al menos dos copias: una en la nube pública (p. ej. AWS S3) y otra en un data‑center local, con pruebas de restauración cada 30 días.
• Documentación completa. Incluye diagramas de arquitectura, listas de métricas monitorizadas, scripts de alertas y procedimientos de escalamiento. Esta documentación debe estar en un repositorio accesible para tu equipo.
• Propiedad del código y de los artefactos. Asegúrate de que el contrato indique que el código fuente, los scripts de despliegue y los playbooks de Ansible pertenecen a tu empresa desde el primer día.
• Auditoría post‑entrega. Programa una auditoría interna a los 60 días que verifique que los indicadores de disponibilidad coinciden con lo pactado y que los procesos de respuesta están operativos.

Conclusión

Quien haya leído hasta aquí entiende que la entrega no es el final del proyecto, sino el inicio de una fase donde la claridad contractual, la asignación de responsabilidades y la documentación son claves para evitar interrupciones. Con acuerdos de SLA bien definidos, un plan de mantenimiento estructurado y controles de acceso y backup, tu empresa mantiene la disponibilidad del sistema bajo control, incluso cuando el proveedor ya no está presente.