Sistemas internos obsoletos, ¿deberíamos repararlos o construir nuevos?

La situación actual que enfrenta la empresa

Las empresas que han utilizado sistemas internos durante más de 10 años suelen estar en la misma situación. El sistema sigue funcionando. No hay grandes fallos. Sin embargo, una pequeña solicitud puede tardar 2 semanas, y solo hay una persona en la empresa que puede manejar esa solicitud.

La razón por la que esta situación es peligrosa es que los problemas se están agravando gradualmente. Un sistema que se detiene de repente recibe presupuesto de inmediato. Sin embargo, un sistema que se ralentiza poco a poco y requiere más atención pasa cada año con "este año también hemos sobrevivido". Con el tiempo, se acumulan tres problemas al mismo tiempo.

Primero, el encargado que conoce el sistema se retira. Las reglas de trabajo no documentadas desaparecen con él. Segundo, el soporte de seguridad para la tecnología base se termina. Los lenguajes o versiones de bases de datos que ya no tienen soporte no recibirán parches incluso si se descubren vulnerabilidades. Tercero, no se podrán agregar nuevas demandas. Demandas como la adaptación móvil, la integración de servicios externos y el análisis de datos son constantemente rechazadas con "eso no se puede hacer con el sistema actual".

Cuando se presentan las tres cosas al mismo tiempo, 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 que indican que se debe considerar un reemplazo

Si se cumplen tres o más de los siguientes elementos, es momento de considerar un reemplazo.

1. Los costos de cambio son asimétricos. Agregar un solo elemento a la pantalla puede llevar días. Si el tiempo de desarrollo para requisitos menores y mayores no varía mucho a los ojos del usuario, la estructura ya no puede soportar cambios.

2. Solo hay un personal de mantenimiento. Un sistema que solo puede ser manejado por una persona específica representa un riesgo para el negocio si esa persona se toma vacaciones o se retira. Esto no es un problema de personal, sino un problema estructural.

3. El soporte para la tecnología base ha finalizado. Verifique la fecha de finalización del soporte oficial para el runtime del lenguaje, el framework y la base de datos que está utilizando. Si ya ha pasado, un incidente de seguridad es solo cuestión de tiempo.

4. No se pueden extraer datos. Si el responsable tiene que escribir consultas directamente para obtener los números necesarios para la toma de decisiones o tiene que abrir varias pantallas para sumar manualmente, significa que el sistema está reteniendo los datos.

5. Está aumentando el trabajo alternativo. Si el área de trabajo está gestionando en Excel en lugar de en el sistema, significa que el sistema no refleja la realidad del trabajo. Este trabajo alternativo no se registra en ninguna parte, por lo que no se ven problemas solo al observar el sistema.

Calcule los costos de mantenimiento

The reason discussions about replacement often stall is usually, "It's still working, so why spend money?" To answer this question, you need to show with numbers that maintenance also incurs costs. Sum the following four items.

Los tres primeros elementos son costos que ya se han incurrido pero que no se registran en ninguna cuenta. El cuarto elemento aún no ha ocurrido, pero es un costo acumulativo en función de la probabilidad.

A continuación se muestra un ejemplo hipotético para ilustrar el método de cálculo, y los valores reales varían según las condiciones de cada empresa. Si hay 30 solicitudes de cambio al año y el tiempo promedio de espera es de 10 días, con un costo de oportunidad diario de 150,000 wones debido a la espera, el costo por retraso es de 45 millones de wones al año. Si además dos departamentos dedican 5 horas a la semana cada uno a la gestión duplicada en Excel, se suman 13 millones de wones al año, basándose en un costo total por hora de 25,000 wones.

Si el total es de 58 millones de wones al año, en 3 años serán 170 millones de wones. Este es el primer número que puede compararse con el costo de reemplazo. El mantenimiento no es gratuito, es un gasto que no aparece en la factura.

Razones por las que una reconstrucción completa es arriesgada

Una vez que se decide el reemplazo, la primera idea que surge es la reconstrucción total. Detener lo viejo, crear lo nuevo y cambiar todo de una vez en un día. Es intuitivo, pero conlleva tres riesgos.

Los beneficios son 0 hasta el final del proyecto. Si se trata de una reconstrucción de 12 meses, durante 11 meses la organización solo pagará costos sin experimentar ninguna mejora. Si el entorno de gestión cambia durante este período, el proyecto enfrentará presión para ser detenido.

Los requisitos se vuelven obsoletos a mitad de camino. Los requisitos organizados al inicio son diferentes de los requerimientos del negocio un año después. Si se reflejan esas diferencias, los plazos se retrasan, y si no se reflejan, se completa un sistema obsoleto.

El riesgo se concentra en el momento de la transición. Dado que todas las funciones se cambian a la vez, si surgen problemas el día de la transición, no habrá una forma clara de revertirlo. Y los problemas casi siempre ocurren, porque siempre quedan reglas excepcionales en el sistema existente que nadie recuerda.

Una alternativa es la migración por etapas.

En lugar de una sustitución completa, existe un enfoque que consiste en trasladar funciones de manera gradual, manteniendo el sistema existente. El orden es el siguiente.

Paso 1 — Delimitar

Divida el sistema actual en bloques funcionales. Sepárelos por unidades de trabajo como pedidos, inventario, liquidación y recursos humanos, pero trace la línea según quién posee los datos. Si varios bloques están modificando la misma tabla directamente, ese punto se convertirá en el mayor obstáculo más adelante.

Cuando dibuje límites, siga el flujo de datos en lugar de la estructura organizativa. Si los departamentos están divididos pero están trabajando juntos en los mismos datos, son un solo bloque, y si los datos están completamente separados dentro de un mismo departamento, pueden ser divididos.

Paso 2 — Separar desde la lectura

La primera tarea más segura es la función de consulta. Funciones que solo leen datos, como tableros, estadísticas e informes, pueden crearse en el nuevo sistema sin afectar al sistema existente. Incluso si falla, la pantalla existente permanece, por lo que es fácil revertir, y el personal operativo notará mejoras de inmediato.

Hay un efecto secundario adicional que se obtiene en esta etapa. Al crear la función de consulta, se revelan problemas en los datos existentes. Se descubren clientes duplicados, fechas con formato incorrecto y filas con valores de código vacíos. Es importante identificar estos problemas antes de trasladar la función de escritura.

Fase 3 — Transferencia de funciones de escritura

Once verification through queries is complete, move the input and modification functions. During this time, both systems will handle the same data, so designate one as the original. Allowing both to be edited simultaneously will lead to discrepancies, and finding those discrepancies will take more time than the previous process itself.

Es más seguro abordar primero las funciones con baja frecuencia de uso y un alcance limitado. Sin embargo, si comienza trasladando funciones que nadie utiliza, no habrá validación, por lo que las funciones que realmente se utilizan y que pueden detenerse por un día son el mejor punto de partida.

Paso 4 — Reducir el sistema existente

Elimine las funciones trasladadas del sistema existente eliminando. Si se dejan, algunas áreas de trabajo seguirán utilizando la antigua interfaz, lo que resultará en el mantenimiento permanente de ambos sistemas. Retrasar este paso es la razón más común por la que las migraciones por fases fracasan.

If removal is difficult, at least block access and change to read-only. Also, set a date for when it will be completely removed. Plans for removal without a date will not be executed.

¿Cuál elegirás?

No siempre es incorrecto realizar una reconstrucción completa. Si el alcance es pequeño, las reglas de trabajo están documentadas y se permiten algunas horas de interrupción, a menudo es más rápido y económico hacer el cambio de una vez. El criterio de juicio no es la antigüedad del sistema, sino dónde están registradas las reglas.

What actually causes problems in data migration

Las razones por las que los plazos se retrasan suelen ser datos, no el desarrollo de funciones. Los sistemas antiguos acumulan estados como los siguientes.

• Hay múltiples registros para el mismo cliente, solo con diferentes etiquetas.
• El formato de fecha, número de teléfono y número de identificación fiscal varía según el período.
• Existen filas vacías que son obligatorias.
• Aún hay datos que hacen referencia a códigos que ya no existen.
• Las filas que solo tienen marcado para eliminar están mezcladas con las que realmente permanecen.

Estos problemas, si se descubren en etapas anteriores, definitivamente retrasarán el cronograma. Investigue y defina el alcance a organizar y lo que se debe descartar antes de comenzar. Intentar limpiar todos los datos pasados perfectamente puede hacer que la migración nunca termine. A menudo es más realista limpiar solo los datos de los últimos años y almacenar el resto en modo de solo consulta.

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

El reemplazo también es una rara oportunidad para organizar el sistema de seguridad. Los sistemas antiguos generalmente tienen una separación de permisos laxa, y la mayoría de los responsables pueden ver más datos de los necesarios. Durante el proceso de migración, defina los siguientes elementos juntos.

Minimizar el acceso. Asegúrese de que solo se muestren los datos necesarios según el rol. Si simplemente traslada la estructura de permisos del sistema existente, también trasladará problemas antiguos.

Ubicación y período de almacenamiento de la información personal. Organice qué información personal se almacena, dónde y cuándo se eliminará. Si se está trasladando a la nube, también debe verificar el país donde se almacenan los datos.

Preservation of processing history. Keep track of who changed what and when. Many old systems lack this record, making it difficult to trace the cause when problems arise.

Cómo persuadir a la alta dirección

El presupuesto de reemplazo generalmente no se aprueba por razones técnicas. Explicaciones como "la estructura está obsoleta" o "el soporte técnico ha terminado" no transmiten la urgencia a los tomadores de decisiones. Presente el cambio en tres aspectos.

La cantidad que se está filtrando ahora. Es la suma de los costos de retraso, desvío y error calculados anteriormente. La clave es que ya se están gastando sin necesidad de reemplazo.

Lo que no se ha podido hacer. En el último año, haga una lista de los requisitos rechazados por la razón de "no es posible con el sistema actual". Si hay elementos que se relacionan con la pérdida de ingresos o la fuga de clientes, colóquelos al principio. La pérdida de oportunidades es un argumento más fuerte que el costo de mantenimiento.

En el peor de los casos. Calcule el tiempo y costo de recuperación si el único responsable se retira o si ocurre un incidente en un componente cuyo soporte ha finalizado. Aunque la probabilidad sea baja, si la magnitud es grande, influye en la toma de decisiones.

After presenting three items, request approval for only the first step of phased migration. Asking for the entire budget at once will lengthen the review period, and in the meantime, the situation will worsen.

¿Cómo se establecerán el cronograma y el personal?

El cronograma es a menudo lo que más se desvía en la migración gradual. Tenga en cuenta tres cosas de antemano.

Incorpore el tiempo del personal en el cronograma. En proyectos anteriores, el recurso más escaso no fue el desarrollador, sino el responsable del área que conoce las reglas de negocio. Como participan mientras realizan su trabajo principal, si no se acuerda de antemano el tiempo disponible, los plazos se retrasan en cada fase de validación.

Incluya el período de operación paralelo en el cálculo. Después de trasladar la funcionalidad, es necesario operar ambos sistemas durante un tiempo. Durante este período, la carga operativa aumenta. Si esto no se refleja en el cronograma y el presupuesto, habrá escasez de personal en la etapa final.

Reserve un tiempo separado para la organización de datos. Los problemas de consistencia que se tratarán más adelante pueden avanzar en paralelo con el desarrollo, pero requieren tiempo y personal dedicados. Si se ocultan dentro del cronograma de desarrollo, inevitablemente habrá retrasos.

Verificar al trabajar con proveedores externos

A menudo es difícil realizar la transición solo con personal interno. Si está considerando proveedores externos, verifique lo siguiente antes de firmar un contrato.

¿Se incluyen documentos en los entregables? Si solo se recibe el código, el mismo problema volverá a surgir años después. Deben incluirse en los entregables el documento de definición de reglas de negocio, la descripción de la estructura de datos y el manual de procedimientos operativos.

¿Está definido el método de transferencia después de la implementación? Una vez finalizada la construcción, el personal interno debe ser capaz de operar. Especifique el período de transferencia y el alcance de la capacitación en el contrato.

¿Se puede dividir el contrato en etapas? Si se contrata todo de una vez, es difícil cambiar de dirección a mitad de camino. Realizar la primera etapa y luego decidir sobre las siguientes es una estructura segura para ambas partes.

¿Está clara la autoridad sobre nuestros datos? Si se utilizan datos reales durante el proceso de desarrollo, documente qué datos se mueven, a dónde van y cómo se eliminan después de la finalización.

Prepárese antes de comenzar

Independientemente del método, asegúrese de obtener las siguientes tres cosas antes de comenzar.

Documentación de las reglas de negocio actuales. Las reglas que solo están en el código se omitirán en el proceso de migración. No tiene que ser una especificación perfecta, pero asegúrese de dejar por escrito al menos el manejo de excepciones y las condiciones de aprobación.

Verificación de la integridad de los datos. Investigue el estado actual basado en los elementos organizados anteriormente y defina el alcance de la organización.

Plan de reversión. Defina "¿cómo revertir si surge un problema?" en cada etapa. Las etapas que no se pueden revertir son señales de que son demasiado grandes y deben ser divididas en partes más pequeñas.

Organización

El costo de un sistema obsoleto se manifiesta no como fallos, sino en forma de retrasos y dependencias. Por eso se reconoce tarde.

• Revise cinco aspectos: costos de cambio, concentración de personal, finalización del soporte técnico, accesibilidad de datos y trabajo de desvío.
• Calcule los costos de mantenimiento en cuatro categorías: retrasos, alternativas, errores y riesgos, y conviértalos en cifras comparables con los costos de reemplazo.
• Si las reglas solo permanecen en el código, una reconstrucción completa es arriesgada.
• Comience trasladando la función de consulta y asegúrese de eliminar las funciones trasladadas del sistema existente.
• Investigate data integrity before starting and define the scope of cleanup in advance.
• Rediseñe las políticas de acceso y almacenamiento de datos personales en esta oportunidad.

Lo más importante no es si reemplazar, sino no posponer la decisión. Si se cumplen tres de cinco señales, es más económico comenzar la revisión este año que hacer una reconstrucción completa el próximo año.