¿Qué ocurre realmente después de entregar

Al cerrar el contrato y recibir la primera versión del sistema, la verdadera prueba comienza. En este artículo verás qué debes vigilar, qué exigir y cómo evitar sorpresas una vez que el software está en producción.

Lo que empieza el día de la entrega

Nadie habla de la jornada en que el proyecto pasa de “en desarrollo” a “en producción”. La entrega no es solo una firma; es el inicio de una fase que consume entre 15 % y 20 % del tiempo total del proyecto.

• Checklist de validación: antes de firmar, solicita una lista de pruebas ejecutadas, resultados y evidencias de cobertura. Sin ella, cualquier error queda fuera del alcance contractual.
• Plan de transición: debe incluir horarios de puesta en marcha, personal de soporte interno y externo, y un cronograma de 2 a 4 semanas para estabilizar el entorno.
• Acceso a entornos: exige credenciales de producción, staging y backup desde el primer día. Sin acceso inmediato, el equipo de TI de tu empresa pierde capacidad de respuesta.

Quién responde cuando algo falla

En la práctica, la responsabilidad se diluye entre el proveedor, el integrador y tu propio equipo. Define claramente lo siguiente en el contrato:

1. Nivel de servicio (SLA): tiempo máximo de respuesta (ej. 4 horas) y tiempo de resolución (ej. 24 horas) para incidencias críticas.
2. Procedimiento de escalamiento: quiénes son los contactos de segundo y tercer nivel, y en qué plazo deben intervenir.
3. Penalizaciones: cláusulas de descuento o bonificación si los SLA no se cumplen.
4. Soporte post‑entrega: especifica cuántas horas de soporte están incluidas y a qué costo se facturará el exceso.

Ejemplo de cláusula: “El proveedor garantiza una respuesta inicial en 2 horas hábiles y solución definitiva en 48 horas para fallas que impidan la operación del módulo de facturación electrónica, de acuerdo a los requisitos de SUNAT.”

Qué exigir por escrito

• Registro de incidencias: cada ticket debe contener descripción, prioridad, tiempo de respuesta y solución.
• Informe de causa raíz: para fallas recurrentes, solicita un análisis que detalle el origen y las acciones correctivas.
• Plan de mejora: si el software requiere ajustes, el proveedor debe presentar un roadmap con fechas y recursos asignados.

Mantenimiento: qué es y qué no

El mantenimiento no es sinónimo de “cualquier cambio”. Se divide en tres categorías claras:

• Correctivo: arregla errores que impiden el funcionamiento. Normalmente está cubierto por la garantía de 3 meses a 6 meses post‑entrega.
• Adaptativo: ajustes menores para cumplir con cambios regulatorios (por ejemplo, nuevas versiones de la facturación electrónica de SUNAT). Suelen negociarse por hora o por sprint.
• Evolutivo: mejoras de funcionalidad o ampliaciones de módulos. No forman parte del contrato de mantenimiento básico; requieren un nuevo presupuesto.

Lo que NO es mantenimiento: rediseñar la arquitectura, migrar a otra base de datos o agregar módulos que no estaban contemplados en el alcance inicial.

Comparativa de cobertura

Cómo evitar quedar atrapado

El riesgo de depender de un único proveedor es real, sobre todo en el contexto peruano donde la normativa de datos y la continuidad operativa son críticas.

• Accesos y credenciales: exige la entrega de todas las claves, tokens y certificados al finalizar el proyecto. Guarda copias en un gestor de contraseñas corporativo.
• Copias de seguridad y repositorios: el código fuente debe estar en un repositorio propio (GitLab, Azure DevOps, etc.) con al menos dos copias en diferentes ubicaciones.
• Documentación completa: incluye diagramas de arquitectura, manuales de instalación, guía de configuración y procedimientos de recuperación ante desastres. Cada documento debe estar versionado.
• Propiedad intelectual: el contrato debe especificar que los derechos de autor del software desarrollado pertenecen a tu empresa, con licencia de uso ilimitada y sin restricciones.
• Plan de salida: define un proceso de transferencia en caso de terminación del contrato, con plazos (30 días) y entregables claros.

• No tienes acceso al código. Tu equipo no podrá aplicar parches ni adaptar el sistema a nuevos requerimientos.
• La documentación está incompleta. Cada cambio futuro dependerá de la disponibilidad del proveedor y generará costos inesperados.
• Los SLA no están firmados. Las incidencias se resolverán según la buena voluntad del proveedor, sin garantías de tiempo.

Conclusión

Quien ha llegado hasta aquí entiende que la entrega es solo el punto de partida. La clave está en formalizar responsabilidades, definir claramente qué cubre el mantenimiento y garantizar la propiedad total del activo digital. Con contratos bien estructurados, accesos seguros y documentación exhaustiva, tu empresa evitará quedar atrapada y podrá aprovechar el software a medida como una ventaja competitiva sostenible.

Después de la entrega, el éxito depende de acuerdos claros, mantenimiento diferenciado y control total del código.