Rescate de proyectos de software fallidos

Un sistema que no entra en producción rara vez es solo un problema de TI. Puede retrasar facturación, obligar a duplicar capturas, dejar aprobaciones sin evidencia o concentrar decisiones operativas en una persona que conoce los archivos y las excepciones. El rescate de proyectos de software fallidos comienza al reconocer que el costo no está únicamente en lo ya invertido: está en la operación que sigue funcionando con controles insuficientes, información dispersa y procesos manuales.

Para una empresa con múltiples áreas, reglas de negocio y sistemas heredados, reemplazar el proveedor o reiniciar el desarrollo no es automáticamente la respuesta correcta. A veces conviene corregir una plataforma existente; otras, aprovechar solo ciertos componentes y reconstruir las piezas críticas. La decisión debe partir de evidencia técnica y operativa, no de la frustración acumulada durante el proyecto.

Cuándo un proyecto requiere intervención

Un proyecto suele considerarse fallido cuando se suspendió, excedió presupuesto o no cumplió lo prometido. Sin embargo, hay señales menos visibles y más peligrosas. La plataforma puede estar en producción, pero depender de hojas de cálculo para conciliar datos, requerir ajustes manuales diarios o entregar información que nadie considera confiable para tomar decisiones.

También es frecuente que el software resuelva una parte aislada del proceso, mientras las integraciones con ERP, sistemas de acceso, inventarios, bancos o herramientas de terceros permanecen incompletas. El resultado es una operación fragmentada: cada área conserva su propia versión de la información y los responsables invierten tiempo en discutir cuál dato es correcto antes de poder actuar.

Una intervención se vuelve prioritaria cuando aparecen cuatro condiciones de forma recurrente:

• Las incidencias se corrigen sin identificar su causa raíz y reaparecen en cada cierre, corte o periodo de alta demanda.
• Los responsables no pueden explicar con claridad qué módulos están terminados, qué reglas de negocio faltan y qué cambios afectan a otras áreas.
• El conocimiento técnico está concentrado en un desarrollador, un proveedor o un usuario clave sin documentación suficiente.
• La dirección carece de visibilidad sobre el avance real, el costo pendiente y el riesgo de continuar con la arquitectura actual.

No todos estos síntomas exigen una reconstrucción completa. Sí exigen detener la improvisación. Seguir agregando funcionalidades sobre una base inestable puede convertir un problema recuperable en una dependencia costosa y difícil de sustituir.

El rescate de proyectos de software fallidos empieza con diagnóstico

Antes de comprometer fechas, tecnologías o alcances, es necesario establecer una línea base. El diagnóstico no consiste en revisar pantallas o contar pendientes en una herramienta de gestión. Debe contrastar el estado del código, la arquitectura, los ambientes, la seguridad, las integraciones y los datos con el proceso que el negocio necesita controlar.

La revisión técnica responde preguntas concretas: ¿el sistema puede desplegarse de forma repetible?, ¿existen respaldos y mecanismos de recuperación?, ¿las interfaces con otros sistemas tienen manejo de errores?, ¿el código cuenta con pruebas suficientes?, ¿hay componentes obsoletos o vulnerabilidades conocidas? Estas respuestas determinan si la plataforma tiene una base viable para evolucionar.

La revisión operativa es igual de relevante. Un requerimiento aparentemente sencillo, como autorizar una orden, puede implicar montos, centros de costo, perfiles, sustituciones, políticas internas y evidencia para auditoría. Si el proveedor anterior desarrolló pantallas sin modelar esas reglas, el problema no se corrige agregando un botón. Se debe rediseñar el flujo con los usuarios responsables y definir qué información debe ser trazable.

Un diagnóstico serio también separa hechos de percepciones. Es habitual escuchar que el proyecto está “al 80 por ciento”, cuando ese porcentaje mide pantallas construidas, no procesos probados de punta a punta. El avance útil se verifica con escenarios reales: captura, validación, integración, excepción, aprobación, consulta y reporte. Si un flujo crítico no puede ejecutarse con datos representativos, no está terminado.

Decidir entre estabilizar, reconstruir o sustituir

Con el diagnóstico en mano, la organización puede elegir una ruta con mayor control. Estabilizar es adecuado cuando la arquitectura es mantenible, el modelo de datos conserva integridad y las fallas están concentradas en módulos, integraciones o reglas mal implementadas. En este caso, la prioridad es reducir incidencias, documentar, probar y liberar correcciones en etapas controladas.

Reconstruir componentes es conveniente cuando existen partes funcionales que vale la pena conservar, pero el núcleo del sistema impide escalar, integrar o asegurar la información. Puede tratarse del módulo de autorizaciones, del motor de cálculo, de una aplicación móvil o de la capa de integración. Esta alternativa requiere definir cuidadosamente la convivencia temporal entre la solución anterior y la nueva para no interrumpir la operación.

Sustituir la plataforma completa tiene sentido si el código no es recuperable, los datos no son confiables, la seguridad es insuficiente o el costo de mantener la solución supera el de construir una base nueva. Es la opción con mayor alcance inicial, pero también puede ser la más responsable cuando el sistema actual representa un riesgo operativo o normativo.

La decisión depende del nivel de criticidad. Un portal interno con baja carga admite una transición gradual distinta a la de una plataforma que controla cobranza, mantenimiento industrial, accesos, comercio internacional o movimientos financieros. En procesos críticos, la velocidad sin control suele generar una segunda falla.

Recuperar el gobierno del proyecto

El rescate no se limita al desarrollo. Un proyecto llega a una situación crítica cuando nadie puede decidir con precisión qué se hará, quién validará cada entrega, cómo se medirán los resultados y qué cambios quedan fuera del alcance inmediato. Recuperar el gobierno significa volver visibles esas decisiones.

El trabajo debe dividirse en etapas con objetivos verificables. Cada etapa necesita un alcance delimitado, responsables del lado del negocio y de TI, criterios de aceptación, riesgos identificados y una demostración funcional. Los pagos vinculados a entregables validados ayudan a alinear la inversión con avances reales, en lugar de financiar actividad sin resultados comprobables.

También conviene definir un comité operativo con capacidad de resolver prioridades. Su función no es revisar cada detalle técnico, sino evitar que las decisiones relevantes se diluyan entre áreas. Debe resolver conflictos de proceso, confirmar reglas de negocio, priorizar incidencias y aprobar cambios que afecten presupuesto, fechas o continuidad.

La documentación debe ser práctica. Diagramas de integración, catálogo de reglas, inventario de ambientes, procedimientos de despliegue y matriz de permisos son activos de continuidad, no burocracia. Permiten que la empresa reduzca la dependencia de personas clave y evalúe proveedores con mayor objetividad en el futuro.

La migración de datos requiere el mismo rigor

Un sistema rescatado puede fallar aunque el código sea correcto si inicia con información incompleta, duplicada o sin correspondencia con la realidad operativa. La migración debe identificar fuentes, propietarios de datos, reglas de limpieza, criterios de homologación y evidencias de conciliación.

No basta con cargar registros históricos. Es necesario acordar qué datos son indispensables para operar, cuáles deben conservarse solo para consulta y cómo se validará que saldos, inventarios, expedientes o estados de trámite coincidan antes y después del cambio. Este trabajo suele revelar definiciones contradictorias entre áreas, pero resolverlas es parte del beneficio: una plataforma centralizada no puede sostenerse sobre criterios ambiguos.

Las pruebas deben incluir volumen, concurrencia, permisos y excepciones reales. Un usuario de almacén, un aprobador financiero y un administrador no recorren el sistema de la misma forma. Validar solo el caso ideal deja sin respuesta los escenarios que más afectan la operación diaria.

La continuidad empieza después de liberar

Poner una corrección en producción no cierra el rescate. Durante las primeras semanas se requiere monitoreo, soporte con niveles de atención definidos y un mecanismo para clasificar incidencias sin mezclar errores críticos con solicitudes de mejora. Esa disciplina evita que el equipo vuelva a operar en modo reactivo.

La evolución posterior debe conservar una visión de arquitectura. Cada nueva integración, automatización o módulo tiene que reforzar el control del ecosistema, no crear otra isla de información. Para ello se necesitan ambientes separados, controles de cambios, respaldos probados y métricas que muestren adopción, tiempos de proceso, errores y disponibilidad.

Four Sides Group aborda este tipo de iniciativas con diagnóstico sénior, etapas validadas y un proceso certificado ISO 9001:2015. La experiencia acumulada desde 2008, con más de 60 sistemas en producción y nueve verticales atendidas, permite dimensionar el rescate como un problema de continuidad empresarial, no como una simple corrección de código.

Un proyecto fallido no define la capacidad digital de una empresa. Lo que sí puede definirla es la decisión de recuperar control sobre sus procesos, sus datos y su inversión antes de que la operación aprenda a convivir permanentemente con el riesgo.