¿Qué ocurre después de entregar tu sistema? Guía

La entrega de un sistema es solo el inicio de una relación operativa; pronto sentirás la presión de que todo funcione sin interrupciones. En este artículo encontrarás qué debes vigilar desde el primer día, quién debe responder ante fallas, qué incluye realmente el mantenimiento y cómo proteger tu inversión.

Lo que empieza el día de la entrega

Cuando el contrato se firma y el proyecto se declara “entregado”, la mayoría de los gerentes creen que el trabajo termina. En la práctica, ese mismo día se activan varios procesos que rara vez se discuten en la negociación:

• Validación de entornos: el equipo de TI debe comprobar que el hosting seleccionado (nube pública, VPS o servidor propio) está configurado según los requerimientos de arquitectura, con puertos, firewalls y balanceadores listos.
• Checklist de puesta en marcha: incluye pruebas de conectividad con SUNAT para facturación electrónica, verificación de certificados SSL y revisión de logs de auditoría inicial.
• Transferencia de credenciales: se entregan usuarios, claves de API y tokens de acceso a los sistemas de monitoreo. Cada credencial debe registrarse en un registro de control de cambios.
• Capacitación de usuarios clave: los jefes de operaciones y los responsables de soporte reciben una sesión práctica de 2‑4 horas para ejecutar procesos críticos (carga de datos, generación de reportes, cierre de ciclo).
• Acuerdo de nivel de servicio (SLA) firmado: aunque el contrato principal ya lo incluya, el SLA detalla tiempos de respuesta, ventanas de mantenimiento y penalizaciones por incumplimiento. Sin este documento, cualquier reclamo queda en el aire.

En esta fase, la falta de documentación clara o de pruebas de integración puede generar retrasos que se traducen en horas de inactividad costosas para la empresa.

Quién responde cuando algo falla

Una vez que el sistema está en producción, la responsabilidad de resolver incidentes recae en varios actores, y es crucial que cada uno tenga sus obligaciones bien definidas.

Actor	Responsabilidad principal	Tiempo máximo de respuesta	Qué exigir por escrito
Proveedor de hosting	Garantizar disponibilidad de la infraestructura (hardware, red, energía)	15 min para incidentes críticos	SLA con métricas de uptime ≥ 99.9 % y reporte de incidentes diario
Equipo de desarrollo (Kovensa)	Corregir errores de código, vulnerabilidades y fallos de integración	1 h para fallas que impiden la operación del negocio	Registro de incidencias, plan de mitigación y cronograma de solución
Equipo interno de TI	Gestionar accesos, aplicar parches de SO y coordinar cambios de configuración	30 min para incidentes de seguridad interna	Procedimientos de escalamiento y lista de contactos 24/7
Auditor interno / cumplimiento	Verificar que la respuesta cumpla con la Ley 29733 y requisitos de SUNAT	48 h para auditorías post‑incidente	Informe de cumplimiento y evidencia documental

Qué exigir por escrito

• Un registro de incidentes que incluya fecha, hora, descripción, causa raíz y acciones tomadas.
• Un plan de contingencia actualizado que detalle pasos a seguir en caso de caída total del hosting.
• Reportes mensuales de disponibilidad y cumplimiento de SLA, con métricas claras y comparativas.

Sin estos compromisos, la empresa queda a merced de tiempos de respuesta arbitrarios y puede enfrentar sanciones regulatorias si la interrupción afecta la facturación electrónica.

Mantenimiento: qué es y qué no

El término “mantenimiento” suele usarse como paraguas, pero en la práctica engloba tres actividades distintas:

1. Corrección – Solución de bugs y vulnerabilidades que aparecen después de la entrega. No incluye cambios de funcionalidad.
2. Mejora – Optimización de procesos, incorporación de módulos menores (por ejemplo, un nuevo reporte de ventas) que no alteran la arquitectura principal.
3. Re‑desarrollo – Cambios estructurales que requieren rediseñar componentes, como migrar de una base de datos relacional a una NoSQL por motivos de escala.

Lo que NO es mantenimiento

• Soporte de primer nivel: atender consultas de usuarios sobre cómo usar la herramienta no forma parte del contrato de mantenimiento, a menos que se haya acordado un paquete de soporte.
• Capacitación continua: sesiones de formación periódicas son servicios adicionales.
• Gestión de licencias de terceros: la renovación de licencias de software de terceros (p.ej., ERP comercial) corresponde al cliente.

Ejemplo de planificación

• Corrección: 1‑2 horas semanales de tiempo de desarrollo, con un máximo de 8 horas por mes para bugs críticos.
• Mejora: 4‑6 horas mensuales, planificadas en sprints de 2 semanas.
• Re‑desarrollo: se negocia como proyecto independiente, con entregas parciales cada 6‑8 semanas.

Esta distinción ayuda a evitar sorpresas en la factura y permite a la gerencia presupuestar con precisión.

Cómo evitar quedar atrapado

El riesgo más grande después de la entrega es perder el control sobre el activo tecnológico. Sigue estos cuatro pasos para mantener la soberanía de tu inversión.

• Accesos: exige la entrega de todas las credenciales, claves SSH, tokens de API y usuarios de base de datos. Regístralas en un gestor de contraseñas corporativo y revisa que existan al menos dos usuarios con privilegios equivalentes para evitar dependencia de una sola persona.
• Copias de seguridad: define una política de backup que incluya al menos 3 copias (diaria, semanal y mensual) almacenadas en sitios geográficamente separados. Verifica la restauración cada 30 días.
• Documentación: solicita diagramas de arquitectura, scripts de despliegue, versiones de librerías y un manual de operaciones. La documentación debe estar versionada en un repositorio accesible (Git, SVN) y actualizada tras cada cambio.
• Propiedad del código: el contrato debe estipular que el código fuente, bases de datos y scripts son propiedad de tu empresa. Incluye una cláusula que permita la transferencia sin costo si decides cambiar de proveedor.

Al cerrar el proyecto con estos elementos, la empresa mantiene la capacidad de migrar, escalar o incluso contratar a otro partner sin interrupciones.

Conclusión

Después de la entrega, la verdadera prueba es la operatividad diaria. Debes asegurarte de que el día de puesta en marcha haya una lista de verificación completa, que las responsabilidades frente a incidentes estén claramente asignadas y documentadas, y que el mantenimiento se entienda como tres servicios diferenciados. Finalmente, protege tu inversión garantizando accesos, copias de seguridad y documentación que te permitan actuar sin depender exclusivamente del proveedor. Con estos pasos, tu empresa transforma la entrega de un software en una base sólida para crecer sin sobresaltos.

Lo esencial después de la entrega: validar, asignar responsabilidades, definir mantenimiento y asegurar la propiedad del activo.