Al recibir el software desarrollado, la sensación de alivio suele ir acompañada de dudas: ¿qué pasa si el sistema falla? ¿Cómo se asegura la continuidad sin depender del mismo proveedor? En este artículo encontrarás respuestas concretas para que tu empresa mantenga el control y minimice riesgos después de la entrega.
Lo que empieza el día de la entrega
- No es el final del proyecto: la firma del acta de entrega marca el cierre de la fase de desarrollo, pero abre la etapa de operación y soporte.
- Entregables obligatorios: código fuente completo, repositorios con historial de commits, documentación técnica (arquitectura, dependencias, scripts de despliegue) y credenciales de acceso a los entornos de producción y pruebas.
- Plazos de transición: la práctica recomendada en Perú es acordar un período de knowledge transfer de 2 a 4 semanas, durante el cual el equipo del proveedor capacita a tu personal interno.
- Checklist rápido:
- ¿Se entregó el código bajo licencia que permite su uso, copia y modificación?
- ¿Existen los scripts de automatización para despliegue en servidores propios o en la nube?
- ¿Se incluye la configuración de facturación electrónica (SUNAT) y los conectores a sistemas locales?
Quién responde cuando algo falla
Responsabilidades claras
| Aspecto | Expectativa del cliente | Lo que debe constar por escrito |
|---|---|---|
| Incidencias críticas (caída del ERP, pérdida de datos) | Respuesta < 4 horas | SLA de tiempo de respuesta y plan de contingencia |
| Errores menores (bugs de UI, reportes incorrectos) | Resolución < 10 días hábiles | Procedimiento de registro y priorización de tickets |
| Actualizaciones de seguridad (parches de vulnerabilidad) | Aplicación < 15 días después del aviso | Obligación de notificar vulnerabilidades y proveer parche |
Qué exigir en el contrato
- Cláusula de soporte post‑entrega con niveles de servicio (SLA) detallados.
- Penalizaciones por incumplimiento de los tiempos acordados.
- Derecho de auditoría: acceso a logs y a la infraestructura para validar que el problema se está gestionando.
- Procedimiento de escalamiento: contactos directos y tiempos máximos de escalado.
Ejemplo práctico peruano
En una empresa de retail que implementó un módulo de facturación electrónica, el proveedor tardó 22 días en aplicar un parche de seguridad obligatorio por SUNAT, superando el SLA de 15 días. La cláusula de penalización permitió reclamar una compensación del 5 % del valor del proyecto y, más importante, obligó al proveedor a mejorar su proceso interno.
Mantenimiento: qué es y qué no
- Corrección: solución de bugs y vulnerabilidades dentro del alcance original del proyecto.
- Mejora: incorporación de funcionalidades que no estaban en el scope inicial, normalmente con un nuevo contrato o ampliación.
- Rehacer: refactorizaciones extensas o migraciones a nuevas plataformas; no forman parte del mantenimiento estándar y deben cotizarse por separado.
Tipos de mantenimiento y sus tiempos
| Tipo | Actividad típica | Tiempo estimado por incidencia |
|---|---|---|
| Correctivo | Reemplazo de código defectuoso | 1‑3 días hábiles |
| Adaptativo | Ajustes por cambios regulatorios (ej. SUNAT) | 3‑7 días hábiles |
| Perfectivo | Optimización de rendimiento o UI | 5‑15 días hábiles |
| Preventivo | Revisiones de seguridad trimestrales | 2‑4 días hábiles |
Lo que no cubre el mantenimiento estándar
- Desarrollo de módulos totalmente nuevos (ej. módulo de gestión de talento).
- Cambios de arquitectura (pasar de monolito a microservicios).
- Migración a otra nube o a infraestructura on‑premise distinta.
Cómo evitar quedar atrapado
- Accesos y credenciales: solicita al proveedor la entrega de todas las claves de bases de datos, servidores y servicios en la nube antes de la firma final.
- Copias de seguridad: establece una política de backups internos; al menos una copia completa del repositorio y de la base de datos debe almacenarse en un entorno controlado por tu empresa.
- Documentación exhaustiva:
- Diagramas de arquitectura con componentes externos (APIs de SUNAT, bancos, etc.).
- Guías de instalación paso a paso y scripts automatizados.
- Registro de versiones de dependencias (librerías, frameworks).
- Propiedad del código: el contrato debe especificar que el código fuente, la documentación y los derechos de uso son transferidos en su totalidad a tu empresa.
- Plan de salida: incluye un cronograma de 6 a 8 semanas para una eventual migración a otro proveedor, con entregables claros (código, documentación, acceso).
Sin cláusula de propiedad
- Riesgo alta dependencia, costos de cambio impredecibles
Con cláusula de propiedad
- Ventaja autonomía total, posibilidad de migrar o internalizar
Conclusión
Quien llega hasta aquí entiende que la entrega del software es solo el inicio de una fase crítica. Definir responsabilidades, establecer SLA claros, diferenciar lo que incluye el mantenimiento y asegurar la propiedad total del código son pasos indispensables para que tu empresa mantenga el control y evite depender de un único proveedor. Con estos lineamientos podrás planificar la operación diaria, responder rápidamente a incidentes y, si en algún momento decides cambiar de socio tecnológico, hacerlo con confianza y sin sorpresas.
