En el inventario de cualquier organización grande hay aplicaciones a medida que nadie recuerda haber encargado. Resolvieron un problema real hace ocho o diez años, siguen funcionando y su proveedor cambió de dueño, se disolvió o dejó de responder. Nadie las ha tocado desde entonces porque no ha hecho falta, y ese es exactamente el problema.
Conviene decirlo sin dramatismo. Una aplicación antigua que hace su trabajo no es un fallo de gestión, es una inversión que salió bien. Lo que falla no es el programa, es que la relación que lo mantenía vivo terminó sin que nadie lo formalizara. El día que haya que cambiar algo, integrarlo con otro sistema o corregir un fallo de seguridad, aparece que no está ni el código, ni la documentación, ni el contacto.
El riesgo tiene tres formas y las tres caben en un informe. La primera es la parálisis, cuando un cambio normativo obliga a tocar el programa y no hay quien lo toque. La segunda es la seguridad, porque toda aplicación se apoya en componentes de terceros que envejecen y acumulan fallos conocidos que nadie está corrigiendo. La tercera es la trazabilidad frente al cliente y frente al regulador, que preguntan cada vez más a menudo quién mantiene el software que trata sus datos.
El software a medida no se rompe. Se queda huérfano, y eso solo se nota el día que hay que cambiarlo.
Lo que se firma antes de encargar
Estas cláusulas no encarecen un desarrollo, pero se piden antes de la primera factura. Después ya no se negocian. Sirven como criterio de revisión de contratos y como anexo reutilizable para compras.
- Propiedad y entrega del código. Que el código fuente es de la organización y se entrega en cada versión, no solo al final. Sin esto, todo lo demás sobra.
- Depósito del código. Una copia en un repositorio propio desde el primer día, con cuentas de la organización, no del proveedor.
- Lista de componentes de terceros. Qué librerías y servicios lleva dentro y en qué versión. Es lo que permite saber, años después, si un fallo publicado afecta.
- Quién parchea y en cuánto tiempo. Un compromiso escrito de corregir fallos de seguridad con plazo propio, distinto del de las mejoras.
- Durante cuánto tiempo. Los años de mantenimiento incluidos y el precio de renovarlos, para que la renovación no sea una negociación desde cero.
- Documentación mínima. Cómo se instala, dónde se configura y qué hace falta para levantarlo en una máquina nueva. Una página bien hecha vale más que un manual de cien.
- Salida ordenada. Qué entrega el proveedor si la relación termina y en qué plazo, incluyendo los datos en un formato legible sin su programa.
- A quién llamar. Una persona con nombre y un canal, con el compromiso de avisar si esa persona cambia.
Cuatro pruebas sobre lo que ya está en producción
Las aplicaciones heredadas no admiten cláusulas retroactivas, pero sí cuatro pruebas que caben en un ciclo y dan evidencia para el informe.
- Quién la hizo y si sigue existiendo. Cruza el inventario de aplicaciones con el maestro de proveedores. Las que no casan son la primera lista de trabajo.
- Dónde está el código. Pide la ruta del repositorio y comprueba el acceso con una cuenta de la organización. Si nadie contesta, recuperarlo más tarde cuesta mucho más que pedirlo ahora.
- Sobre qué está montada. Versión del sistema operativo, de la base de datos y del entorno de ejecución. Si alguna está fuera de soporte, la aplicación hereda ese problema entero y el hallazgo tiene dueño.
- Qué pasaría si mañana no arranca. Cuánto aguanta el proceso de negocio sin ella y si existe una copia desde la que reconstruirla, con fecha de la última restauración probada.
Ninguna de esas preguntas es técnica en el fondo. Todas son preguntas de dependencia, del mismo tipo que las que ordenan el universo de riesgo del plan anual, como se ve en lo que van a auditar los equipos este ciclo.
El próximo desarrollo a medida se va a encargar igual, porque a menudo es la decisión correcta. La diferencia entre encargarlo bien y encargarlo mal no está en el precio ni en el plazo, está en ocho líneas del contrato que se escriben una vez. Y lo que queda en el expediente es la prueba de que la aplicación seguirá siendo de la organización el día que el proveedor deje de existir.
