Después de la entrega: qué gestionar y evitar

La entrega del proyecto parece el final, pero en la práctica es el comienzo de una nueva fase que puede convertirse en un dolor de cabeza si no sabes qué controlar. En este artículo encontrarás los puntos críticos que debes vigilar desde el día de la entrega hasta los primeros meses de operación.

Lo que empieza el día de la entrega

Ese momento en que el proveedor te entrega el código, la documentación y la capacitación es, a menudo, más una ceremonia que una garantía de que todo funcionará sin sorpresas. Lo que pocos mencionan antes de firmar es que la entrega incluye:

• Checklist de aceptación: verifica que cada requerimiento funcional esté marcado como cumplido y que exista evidencia (screenshots, reportes de pruebas).
• Entorno de pruebas: el proveedor debe dejarte una copia idéntica del entorno productivo (bases de datos, configuraciones de servidor, variables de entorno) para que tu equipo pueda replicar cualquier incidencia.
• Acceso a repositorios: las credenciales de Git, SVN o la herramienta que se haya usado deben entregarse con derechos de administrador, no solo de lectura.
• Plan de transición: un cronograma de al menos dos semanas donde el equipo del proveedor acompañe a tu personal en la puesta en marcha y en la resolución de los primeros tickets.

Sin estos elementos, la “entrega” se convierte en una simple transferencia de archivos que no garantiza continuidad ni seguridad.

Quién responde cuando algo falla

Una vez en producción, los fallos son inevitables. Lo que importa es quién los atiende y en qué plazo.

1. Responsabilidad contractual: el contrato debe especificar claramente el Service Level Agreement (SLA) para incidencias críticas (p. ej., tiempo de respuesta ≤ 4 horas, tiempo de solución ≤ 24 horas). Si el proveedor no cumple, el acuerdo debe contemplar penalizaciones o créditos.
2. Niveles de soporte:
   • Nivel 1 (primer contacto): atención telefónica o ticket en 30 minutos.
   • Nivel 2 (análisis técnico): diagnóstico y propuesta de solución en 2 horas.
   • Nivel 3 (desarrollo y despliegue): solución definitiva en 24 horas para incidentes críticos, 72 horas para no críticos.
3. Exigencias por escrito: solicita al proveedor un registro de incidentes que incluya fecha, descripción, prioridad, responsable y tiempo de resolución. Este documento será la base para evaluar el cumplimiento del SLA.
4. Escalamiento: define una cadena de escalamiento que incluya al gerente de proyecto, al director de operaciones y, en caso de incumplimiento, a la gerencia de la empresa proveedora.

En Perú, la normativa de la SUNAT exige que los sistemas de facturación electrónica mantengan disponibilidad mínima del 99 % mensual. Por lo tanto, tu contrato debe reflejar este requerimiento y prever sanciones por interrupciones que pongan en riesgo la emisión de comprobantes.

Mantenimiento: qué es y qué no

El mantenimiento no es un concepto monolítico; se divide en tres categorías que debes distinguir en el contrato:

• Correctivo: solución de errores que impiden el funcionamiento esperado. No incluye mejoras de funcionalidades.
• Evolutivo: incorporación de nuevas características o adaptación a cambios regulatorios (por ejemplo, actualizaciones de la normativa de la SUNAT).
• Preventivo: actividades programadas como parches de seguridad, optimización de bases de datos y pruebas de rendimiento.

Lo que no es mantenimiento

• Re‑desarrollo completo: si el proyecto necesita una re‑arquitectura porque la tecnología está obsoleta, eso se considera un nuevo proyecto, no mantenimiento.
• Capacitación continua: la formación del personal es un servicio adicional; el mantenimiento solo cubre la transferencia de conocimiento ya documentada.
• Soporte de hardware: la infraestructura (servidores, redes) es responsabilidad del área de TI de tu empresa o del proveedor de infraestructura, no del desarrollador de software.

Un buen contrato de mantenimiento suele destinar entre el 15 % y el 25 % del esfuerzo total del proyecto durante el primer año, con revisiones trimestrales para ajustar el alcance.

Cómo evitar quedar atrapado

El riesgo más grande es depender exclusivamente del proveedor para acceder al código o a la infraestructura.

1. Accesos y credenciales: al cierre del proyecto, exige la entrega de todas las claves (repositorios, servidores, bases de datos, cuentas de cloud). Verifica que los accesos funcionen antes de firmar el acta de cierre.
2. Copias de seguridad: solicita al menos dos copias completas del código y de la base de datos: una almacenada en tu propio repositorio interno y otra en un servicio de backup externo (por ejemplo, Amazon S3 o Azure Blob).
3. Documentación completa:
   • Diagramas de arquitectura (infraestructura, flujos de datos).
   • Manual de instalación y despliegue paso a paso.
   • Guía de configuración de parámetros críticos (claves de API, certificados).
4. Propiedad intelectual: el contrato debe dejar claro que los derechos de autor y la licencia de uso pertenecen a tu empresa. Evita cláusulas de “uso exclusivo del proveedor”.
5. Plan de salida: incluye una cláusula que establezca un período de 30 días para que el proveedor transfiera todo el conocimiento y los artefactos antes de que pueda rescindir el contrato.

• No tienes acceso al repositorio. Tu equipo no podrá aplicar parches ni investigar la causa de un error.
• Falta de documentación de arquitectura. Cada cambio futuro dependerá de la memoria del proveedor.
• El contrato no menciona propiedad del código. El proveedor podría negarse a entregarte el código fuente.

Conclusión

Al leer este artículo, tu empresa ya sabe que la entrega es solo el inicio de la relación con el proveedor. Debes exigir un checklist de aceptación, definir claramente quién responde y en qué plazos, distinguir entre los tipos de mantenimiento y asegurarte de que todos los accesos, copias y documentación estén bajo tu control. Con estos pasos, evitas sorpresas, reduces costos de soporte y mantienes la continuidad operativa, incluso frente a cambios regulatorios de la SUNAT o a la necesidad de evolucionar el sistema.

Una entrega bien gestionada protege tu inversión y garantiza que el software siga aportando valor después del lanzamiento.