Sistemas internos obsoletos: ¿repararlos o construirlos de nuevo?

La situación a la que se enfrentan hoy las empresas

Las empresas que llevan más de diez años utilizando un mismo sistema interno se encuentran casi siempre en la misma situación. El sistema sigue funcionando. Tampoco hay incidencias graves. Sencillamente, una petición menor tarda dos semanas y en toda la compañía solo hay una persona capaz de atenderla.

Este estado resulta peligroso porque el problema empeora de forma gradual. A un sistema que se detiene de golpe se le asigna presupuesto de inmediato. En cambio, un sistema que se vuelve algo más lento y algo más costoso de mantener cada año se despacha con un «este año también hemos ido tirando». Cuando se acumulan varios años así, tres circunstancias se presentan a la vez.

Primera: la persona que conoce el sistema se jubila o deja la empresa, y con ella desaparecen las reglas de negocio que nunca se documentaron. Segunda: finaliza el soporte de seguridad de la tecnología de base; las versiones de lenguaje o de base de datos sin soporte no reciben parches aunque se descubran vulnerabilidades. Tercera: deja de ser posible incorporar nuevos requisitos; peticiones como el acceso desde móvil, la integración con servicios externos o el análisis de datos se rechazan una y otra vez con un «con el sistema actual eso no se puede hacer».

En el momento en que las tres circunstancias coinciden, la única opción que queda es la reconstrucción completa. Y la reconstrucción completa es la opción más cara y más arriesgada.

Cinco señales de que conviene plantearse la sustitución

Si concurren tres o más de los siguientes puntos, ha llegado el momento de iniciar el estudio de sustitución.

1. El coste del cambio es asimétrico. Añadir un solo campo a una pantalla lleva varios días. Si el plazo de desarrollo de una petición que el usuario percibe como trivial apenas difiere del de una petición importante, la estructura ya no es capaz de asumir cambios.

2. Solo hay una persona de mantenimiento. Un sistema que únicamente una persona concreta puede tocar convierte sus vacaciones y su eventual marcha en un riesgo para el negocio. No es un problema de recursos humanos, sino un problema estructural.

3. El soporte de la tecnología de base ha finalizado. Compruebe las fechas oficiales de fin de soporte del entorno de ejecución del lenguaje, del framework y de la base de datos que utiliza. Si ya han pasado, el incidente de seguridad es cuestión de tiempo.

4. No se pueden extraer los datos. Si para obtener las cifras necesarias en la toma de decisiones alguien tiene que escribir consultas a mano, o abrir varias pantallas y sumar manualmente, el sistema está reteniendo los datos.

5. Aumentan los procesos paralelos. Si el área de negocio gestiona en hojas de cálculo un ámbito cada vez más amplio en lugar de hacerlo en el sistema, significa que el sistema no refleja el trabajo real. Como estas soluciones alternativas no quedan registradas en ninguna parte, mirando solo el sistema el problema no se aprecia.

Calcule el coste de mantener

El motivo por el que el debate sobre la sustitución no avanza suele ser el argumento de «si funciona, por qué gastar dinero». Para responder a esa pregunta hay que demostrar con cifras que mantener también genera coste. Sume las cuatro partidas siguientes.

Las tres primeras partidas son costes que ya se están desembolsando pero que no figuran en ninguna cuenta. La cuarta es un coste que todavía no se ha producido, pero que se acumula en términos probabilísticos.

Lo que sigue es un ejemplo hipotético destinado a mostrar el método de cálculo; los valores reales varían según las condiciones de cada empresa. Si se reciben 30 peticiones de cambio al año, con una espera media de 10 días por petición, y se estima el coste de oportunidad diario de esa espera en 150.000 KRW, solo el coste del retraso asciende a 45.000.000 KRW anuales. Si a ello se añade que dos departamentos dedican cada uno cinco horas semanales a la doble gestión en hojas de cálculo, con un coste laboral total por hora de 25.000 KRW, se suman otros 13.000.000 KRW al año.

Si el total es de 58.000.000 KRW anuales, en tres años son 170.000.000 KRW. Es en este momento cuando aparece por primera vez una cifra comparable con el coste de la sustitución. Mantener no es gratis: es un gasto por el que no llega ninguna factura.

Por qué la reconstrucción completa es arriesgada

Una vez tomada la decisión de sustituir, el primer método que viene a la mente es la reconstrucción completa: detener lo antiguo, construir lo nuevo y cambiarlo todo de una vez un día determinado. Es intuitivo, pero conlleva tres riesgos.

El beneficio es cero hasta la finalización del proyecto. En una reconstrucción de doce meses, durante once la organización solo paga costes y no percibe ninguna mejora. Si el entorno empresarial cambia en ese periodo, el proyecto queda bajo presión de cancelación.

Los requisitos envejecen por el camino. Los requisitos definidos al inicio no coinciden con las necesidades del área de negocio un año después. Si se incorpora esa diferencia, el calendario se retrasa; si no se incorpora, lo que se entrega es un sistema ya obsoleto.

El riesgo se concentra en el momento del cambio. Como todas las funcionalidades cambian a la vez, si surge un problema el día de la transición no hay una forma sencilla de dar marcha atrás. Y el problema surge casi siempre, porque en el sistema antiguo quedan sin falta reglas de excepción que ya nadie recuerda.

La migración incremental como alternativa

En lugar de la sustitución completa, existe la posibilidad de mantener el sistema existente y trasladar las funcionalidades una a una. El orden es el siguiente.

Fase 1 — Trazar las fronteras

Divida el sistema actual en bloques funcionales. Sepárelos por unidades de negocio —pedidos, inventario, facturación, recursos humanos—, pero trace la línea en función de quién es el propietario de los datos. Si varios bloques modifican directamente la misma tabla, ese punto se convertirá más adelante en el mayor obstáculo.

Al trazar las fronteras, siga el flujo de los datos y no el organigrama. Aunque los departamentos estén separados, si modifican conjuntamente los mismos datos forman un único bloque; y aunque se trate de un solo departamento, si los datos están completamente separados es posible dividirlo.

Fase 2 — Separar primero la lectura

La primera iniciativa más segura son las funcionalidades de consulta. Los cuadros de mando, las estadísticas y los informes, que solo leen datos, pueden construirse en el nuevo sistema sin afectar al existente. Aunque fallen, la pantalla antigua sigue disponible, de modo que dar marcha atrás es sencillo y el área de negocio percibe la mejora de inmediato.

Esta fase aporta además un efecto colateral. Al construir las funcionalidades de consulta salen a la luz los problemas de los datos existentes: clientes duplicados, fechas con el formato roto, filas con el valor de código vacío. Es importante conocer estos problemas antes de trasladar las funcionalidades de escritura.

Fase 3 — Migrar las funcionalidades de escritura

Una vez completada la verificación mediante la consulta, se trasladan las funcionalidades de alta y modificación. Como durante un tiempo ambos sistemas manejarán los mismos datos, designe uno solo de ellos como origen. Si se permite modificar desde ambos lados, se producirán discrepancias, y localizarlas consume más tiempo que la propia migración.

En cuanto al orden, lo prudente es empezar por las funcionalidades de uso poco frecuente y alcance reducido. Ahora bien, si se empieza por funcionalidades que no utiliza nadie no habrá verificación posible, de modo que el mejor punto de partida es una funcionalidad que se use realmente pero que pueda detenerse durante un día.

Fase 4 — Reducir el sistema existente

Las funcionalidades ya migradas deben eliminarse del sistema existente. Si se dejan, una parte del área de negocio seguirá utilizando las pantallas antiguas y se acabará manteniendo indefinidamente ambos sistemas. Aplazar esta fase es la causa más frecuente del fracaso de una migración incremental.

Si la eliminación resulta difícil, bloquee al menos el acceso y déjelas en modo de solo lectura. Y fije una fecha concreta para su retirada definitiva. Un plan de limpieza sin fecha no llega a ejecutarse.

Cuál de las dos opciones elegir

La reconstrucción completa no siempre es un error. Si el alcance es reducido, las reglas de negocio están recogidas por escrito y se admiten unas horas de interrupción, cambiarlo todo de una vez resulta más rápido y más económico. El criterio no es la antigüedad del sistema, sino dónde están registradas las reglas.

Lo que realmente causa problemas en la migración de datos

La causa de los retrasos en el calendario no suele ser el desarrollo de funcionalidades, sino los datos. En los sistemas antiguos se acumulan estados como los siguientes.

• Un mismo cliente registrado varias veces con grafías distintas
• Formatos de fecha, de teléfono y de número de identificación fiscal que difieren según la época
• Filas con campos obligatorios vacíos
• Datos que siguen referenciando valores de código ya suprimidos
• Filas marcadas como eliminadas que en realidad permanecen mezcladas con el resto

Si estos problemas se descubren durante la fase de migración, el calendario se retrasa sin remedio. Investíguelos de antemano, antes de empezar, y determine primero qué ámbito se depura y cuál se descarta. Si se pretende depurar a la perfección todos los datos históricos, la migración no terminará nunca. En muchos casos resulta más realista depurar únicamente los últimos años y conservar el resto en modo de solo consulta.

Una oportunidad para rediseñar la seguridad y los permisos de acceso

La sustitución es también una ocasión poco frecuente para ordenar el sistema de seguridad. Los sistemas antiguos suelen tener una separación laxa de permisos y funcionan con la mayoría del personal en disposición de ver más datos de los necesarios. Defina los siguientes puntos durante el proceso de migración.

Minimización de los permisos de acceso. Diferencie los accesos de modo que cada rol vea únicamente los datos que necesita. Si se traslada tal cual la estructura de permisos del sistema existente, con ella se trasladan también sus defectos.

Ubicación de almacenamiento y plazo de conservación de los datos personales. Determine qué datos personales se almacenan, dónde y cuándo se destruyen. En caso de migrar a la nube, hay que verificar además en qué país quedan almacenados los datos.

Conservación del registro de operaciones. Deje constancia de quién modificó qué y cuándo. Es frecuente que los sistemas antiguos carezcan de este registro y que, ante un problema, no sea posible rastrear su origen.

Cómo convencer a la dirección

El presupuesto de sustitución no suele aprobarse con argumentos técnicos. Explicaciones como «la estructura está obsoleta» o «el soporte técnico ha finalizado» no transmiten urgencia a quien firma. Preséntelas transformadas en los tres puntos siguientes.

El importe que se está perdiendo ahora. Es la suma de los costes de retraso, de procesos paralelos y de errores calculados anteriormente. Lo esencial es que ya se están desembolsando aunque no se sustituya nada.

Lo que no se está pudiendo hacer. Elabore la lista de las peticiones rechazadas durante el último año con el argumento de que «no es posible con el sistema actual». Si alguna de ellas está vinculada a la facturación o a la pérdida de clientes, colóquela en primer lugar. El lucro cesante es un argumento más potente que el coste de mantenimiento.

El peor escenario. Calcule el plazo y el coste de recuperación en caso de que la única persona responsable deje la empresa o de que se produzca un incidente en un componente sin soporte. Aunque la probabilidad sea baja, una magnitud elevada mueve la decisión.

Tras presentar los tres puntos, solicite la aprobación únicamente de la primera fase de la migración incremental. Si se pide todo el presupuesto de una vez, el periodo de estudio se alarga y, entretanto, la situación empeora.

Cómo planificar el calendario y los recursos

En la migración incremental, lo que más a menudo se desvía es el calendario. Incorpore de antemano tres consideraciones.

Incluya en el calendario el tiempo del área de negocio. En un proyecto de migración, el recurso más escaso no son los desarrolladores, sino las personas del área de negocio que conocen las reglas. Como participan sin dejar sus tareas habituales, si no se acuerda previamente el tiempo disponible, el calendario se retrasará en cada fase de verificación.

Incluya en el cálculo el periodo de operación en paralelo. Incluso después de trasladar una funcionalidad hay que operar ambos sistemas conjuntamente durante un tiempo. En ese periodo la carga operativa aumenta en lugar de disminuir. Si no se refleja en el calendario y el presupuesto, en la última fase faltará personal.

Reserve un periodo específico para la depuración de datos. Los problemas de integridad de los datos que se tratan más adelante pueden abordarse en paralelo al desarrollo, pero requieren tiempo y personas propias. Si se ocultan dentro del calendario de desarrollo, el retraso es seguro.

Qué verificar al trabajar con un proveedor externo

En muchos casos resulta difícil llevar a cabo la migración únicamente con recursos internos. Si valora recurrir a un proveedor externo, verifique lo siguiente antes de firmar.

¿Los entregables incluyen documentación? Si solo se recibe el código, el mismo problema se repetirá al cabo de unos años. Los entregables deben incluir la definición de las reglas de negocio, la descripción de la estructura de datos y el manual de procedimientos operativos.

¿Está definida la forma de traspaso posterior a la migración? Una vez finalizada la implantación, el personal interno debe poder operar el sistema. Especifique en el contrato el periodo de traspaso y el alcance de la formación.

¿Es posible contratar por fases? Si se contrata todo de una vez, resulta difícil cambiar de rumbo a mitad de camino. Un esquema en el que se ejecuta la primera fase y después se decide sobre las siguientes es más seguro para ambas partes.

¿Están claros los derechos sobre nuestros datos? Si durante el desarrollo se utilizan datos reales, establezca por escrito qué datos se desplazan, adónde y cómo se destruyen una vez finalizado el trabajo.

Qué preparar antes de empezar

Con independencia del método elegido, asegure estos tres puntos antes de empezar.

Documentación de las reglas de negocio vigentes. Las reglas que solo existen en el código se pierden sin falta durante la migración. No hace falta una especificación perfecta, pero deje por escrito al menos la gestión de excepciones y las condiciones de aprobación.

Revisión de la integridad de los datos. Examine el estado actual conforme a los puntos recogidos anteriormente y determine el ámbito de depuración.

Plan de reversión. Establezca para cada fase cómo se da marcha atrás si surge un problema. Una fase que no se puede revertir es, por eso mismo, una fase demasiado grande, y constituye la señal de que hay que dividirla en partes más pequeñas.

Resumen

El coste de un sistema obsoleto no se manifiesta en forma de averías, sino en forma de retraso y dependencia. Por eso se percibe tarde.

• Revise las cinco señales: coste del cambio, concentración del conocimiento en una persona, fin del soporte técnico, accesibilidad de los datos y procesos paralelos.
• Calcule el coste de mantener con las cuatro partidas —retraso, procesos paralelos, errores y riesgo— y conviértalo en una cifra comparable con el coste de la sustitución.
• Si las reglas solo existen en el código, la reconstrucción completa es arriesgada.
• Empiece migrando las funcionalidades de consulta y elimine sin falta del sistema existente todo lo ya migrado.
• Investigue la integridad de los datos antes de empezar y fije de antemano el ámbito de depuración.
• Aproveche la ocasión para rediseñar a la vez los permisos de acceso y la política de conservación de datos personales.

Más importante que decidir si sustituir o no es no aplazar la decisión. Si concurren tres de las cinco señales, iniciar el estudio dentro de este año sale más barato que acometer una reconstrucción completa el año que viene.