¿Qué ocurre después de la entrega de tu código

La entrega del proyecto parece el final del camino, pero para el gerente o dueño la verdadera prueba empieza justo después. En este artículo verás qué debes vigilar una vez que recibes el software y cómo garantizar que tu inversión siga generando valor sin quedar atrapado en una dependencia indeseada.

Lo que empieza el día de la entrega

Nadie menciona en la fase de negociación que el día en que el proveedor firma el acta de entrega también marca el inicio de una nueva etapa de gestión. En Perú, la normativa de SUNAT exige que la facturación electrónica esté operativa en un plazo que no siempre coincide con la entrega del código, por lo que el proyecto puede quedar en pausa mientras se alinean los procesos internos.

En ese momento deberías contar con:

• Acta de entrega firmada que detalle los módulos entregados, versiones y entorno de despliegue.
• Inventario de artefactos: repositorios Git, bases de datos, scripts de despliegue y configuraciones de infraestructura.
• Plan de transición que incluya capacitaciones y transferencia de conocimientos a tu equipo interno.

Si alguno de estos puntos falta, la primera señal de alerta es que la propiedad del código fuente todavía está en la sombra del proveedor. No basta con recibir el ejecutable; necesitas los derechos y los medios para replicar, compilar y mantener el software por tu cuenta.

Quién responde cuando algo falla

Una vez en producción, los fallos son inevitables. La clave está en definir responsabilidades claras y tiempos de respuesta en el contrato.

• Soporte de nivel 1 (incidentes menores): el proveedor debe responder en 4 horas hábiles y ofrecer una solución provisional en 24 horas.
• Incidentes críticos (caídas que afectan facturación o cumplimiento SUNAT): la respuesta debe ser inmediata, con un tiempo máximo de 1 hora para iniciar la investigación y 8 horas para restablecer el servicio.
• Corrección de bugs: el contrato debe establecer un plazo de 2 semanas para errores de prioridad media y 5 días para críticos.

Exige que todo quede por escrito en una cláusula de SLA (Service Level Agreement). Además, solicita un registro de tickets accesible para tu equipo, de modo que puedas auditar el cumplimiento.

Si el proveedor no cumple, la cláusula de penalización debe contemplar descuentos en los pagos mensuales o la posibilidad de rescindir sin penalidad después de 30 días de incumplimiento reiterado.

Mantenimiento: qué es y qué no

El mantenimiento se divide en tres categorías que a menudo se confunden:

1. Corrección – arreglar errores que aparecen después de la entrega. No implica cambios de funcionalidad.
2. Mejora – añadir pequeñas funcionalidades o ajustes que el negocio solicita, normalmente con un alcance limitado (≤ 10 % del código original).
3. Rehacer – una re‑arquitectura o ampliación sustancial (≥ 30 % del código). En este caso se trata prácticamente como un nuevo proyecto y debería presupuestarse aparte.

Es esencial que el contrato especifique qué incluye el mantenimiento estándar y qué se considerará trabajo extra. Por ejemplo, la adaptación a nuevas versiones de la normativa SUNAT o la integración con un ERP diferente debe quedar claramente fuera del paquete básico.

Además, define un horario de soporte: si tu operación depende del sistema 24 / 7, el proveedor debe ofrecer cobertura fuera de horario con los mismos tiempos de respuesta que los incidentes críticos.

Cómo evitar quedar atrapado

La dependencia del proveedor se vuelve problemática cuando pierdes el control técnico del proyecto. Aquí tienes los pasos prácticos para mantener la autonomía:

• Accesos completos: solicita usuarios administrativos a todos los entornos (desarrollo, pruebas, producción) y verifica que puedas crear nuevas credenciales.
• Copias de seguridad del repositorio: guarda una réplica del código en un repositorio interno (por ejemplo, Azure DevOps o GitLab auto‑hosted). La copia debe incluir historial de commits y etiquetas de versiones.
• Documentación exhaustiva: arquitectura, diagramas de flujo, dependencias externas, scripts de despliegue y manuales de operación. Exige que la documentación sea entregada en formato markdown o PDF y que se actualice cada vez que se haga un release.
• Propiedad del código fuente: el contrato debe declarar que todos los derechos de autor, licencias y patentes del software desarrollado pertenecen a tu empresa desde el momento de la firma del acta de entrega.
• Plan de salida: establece un proceso de transferencia que incluya un período de co‑gestión de 4 semanas, durante el cual el proveedor trabaja junto a tu equipo para validar que pueden operar sin su ayuda.

Un recurso útil es crear un inventario de dependencias externas (APIs, servicios en la nube, librerías de terceros). Cada dependencia debe estar acompañada de su licencia y de un plan de contingencia en caso de que el proveedor decida descontinuarla.

Checklist rápido

• No tienes acceso al repositorio. El software funciona, pero cada cambio depende de un ticket al proveedor.
• La documentación está incompleta. Los técnicos pierden tiempo recreando diagramas que deberían estar disponibles.
• Los SLA no están firmados. Los incidentes críticos tardan días en resolverse y la operación sufre.

Conclusión

Quien ha llegado hasta aquí entiende que la entrega del software es solo el punto de partida. La propiedad del código fuente, los SLA claros, un plan de mantenimiento bien delimitado y una estrategia de salida son los pilares para que tu empresa peruana siga beneficiándose sin quedar atada a un único proveedor. Con estos lineamientos podrás transformar la entrega en una verdadera ventaja competitiva y mantener el control total de tu inversión tecnológica.