¿Qué ocurre tras la entrega del software a medida?

En la práctica, la fase post‑entrega es la que más genera incertidumbre en gerentes y dueños de empresas. Después de firmar el proyecto, la realidad se vuelve operativa: ¿quién responde si algo falla?, ¿qué incluye realmente el mantenimiento? y, sobre todo, ¿cómo asegurarse de que tu inversión no quede atrapada en un “código sin dueño”. En este artículo encontrarás respuestas concretas para que tu empresa continúe sacando valor del desarrollo de software a medida.

Lo que empieza el día de la entrega

El día que el equipo de Kovensa entrega el código, la mayoría de los directivos piensan que el proyecto ha concluido. Lo que nadie cuenta antes de firmar es que la entrega es solo el inicio de una nueva etapa operativa. En Perú, la normativa de SUNAT exige que los sistemas de facturación electrónica estén validados y actualizados; si tu software a medida gestiona facturas, la entrega debe ir acompañada de un plan de pruebas de certificación que suele durar entre 2 y 4 semanas.

Además, el contrato debe especificar claramente:

• Fecha límite de aceptación: normalmente 10 días hábiles para que tu equipo valide que el sistema cumple con los requisitos funcionales.
• Periodo de garantía: 4 semanas de corrección de errores críticos sin costo adicional.
• Entregables de transición: manuales, diagramas de arquitectura y credenciales de acceso al entorno de producción.

Sin estos puntos, el día de la entrega puede convertirse en una jornada de “¿y ahora qué?”.

Quién responde cuando algo falla

Una vez el software está en producción, la responsabilidad se reparte entre tres actores clave:

1. El cliente (tu empresa) – Debe reportar incidentes mediante el canal acordado (ticket, correo o herramienta de gestión). El reporte debe incluir evidencia (capturas, logs) y la prioridad del problema.
2. El proveedor (empresa de desarrollo de software en Perú) – Tiene un SLA (Service Level Agreement) que define tiempos de respuesta:
   • Incidente crítico (pérdida total del servicio): respuesta en 2 horas, solución o solución parcial en 24 horas.
   • Incidente mayor (funcionalidad esencial afectada): respuesta en 4 horas, solución en 48 horas.
   • Incidente menor (incidencia estética o funcionalidad no esencial): respuesta en 12 horas, solución en 5 días hábiles.
3. El equipo interno de TI – Responsable de validar que los cambios propuestos por el proveedor no rompan la infraestructura existente y de aplicar los parches en los entornos de staging antes de pasar a producción.

Qué exigir por escrito: un anexo al contrato que detalle los SLAs, el proceso de escalamiento (incluyendo contactos de nivel 2 y 3) y la penalidad por incumplimiento (por ejemplo, descuento del 5 % del valor mensual del soporte por cada día de retraso).

Mantenimiento: qué es y qué no

El término “mantenimiento” suele confundirse con “mejora” o “rehacer”. En el contexto peruano, donde la normativa fiscal puede cambiar cada año, es vital distinguir tres categorías:

• Mantenimiento correctivo: reparación de errores detectados después de la entrega. Está cubierto por la garantía y, posteriormente, por el contrato de soporte.
• Mantenimiento adaptativo: ajustes necesarios para cumplir con cambios regulatorios (por ejemplo, nuevas versiones de la facturación electrónica SUNAT). Normalmente se cotiza por hora o por “ticket” y se agenda trimestralmente.
• Mantenimiento evolutivo: incorporación de nuevas funcionalidades o mejoras de usabilidad. No forma parte del soporte básico y requiere un nuevo alcance de proyecto.

Lo que no es mantenimiento:

• Reescritura completa del código por motivos de arquitectura obsoleta. Eso es un nuevo proyecto.
• Capacitación continua del personal. La capacitación inicial está incluida; sesiones posteriores deben contratarse aparte.

Cómo evitar quedar atrapado

El riesgo más frecuente es que la empresa quede sin acceso pleno al software después de la entrega. Para evitarlo, asegúrate de que el contrato contemple:

• Accesos completos: credenciales de administrador a bases de datos, servidores y repositorios de código (Git, Bitbucket, etc.).
• Copias de seguridad: entregas de backups completos de bases de datos y del código fuente en formato comprimido, almacenados en al menos dos ubicaciones distintas.
• Documentación técnica: diagramas de arquitectura, guías de despliegue, listado de dependencias y versiones de librerías usadas.
• Propiedad intelectual: cláusula que transfiera los derechos de autor del software a tu empresa, evitando licencias limitadas que impidan modificaciones futuras.

En Perú, la Ley de Protección de Datos Personales (Ley 29733) exige que el responsable del tratamiento de datos tenga control total sobre los mecanismos de seguridad. Si el proveedor retiene el acceso al código, la empresa podría incumplir la normativa en caso de una fuga de datos.

Conclusión

Quien ha llegado hasta aquí comprende que la entrega del desarrollo de software a medida es solo el punto de partida. La claridad en los acuerdos de responsabilidad, la definición precisa de mantenimiento y la garantía de propiedad y acceso son los pilares que evitan sorpresas costosas. Con estos elementos bien documentados, tu empresa podrá maximizar el retorno de la inversión y mantener la continuidad operativa sin depender indefinidamente de un único proveedor.