Un Sistema Interno Antiguo: ¿Repararlo o Reconstruirlo?
Mientras se pospone la decisión entre reconstruir y mejorar, el costo sigue acumulándose. Este documento establece cinco señales que identifican el punto de reemplazo, un método para comparar el costo de mantener frente al costo de reemplazar, y un procedimiento de ejecución para migrar de manera incremental en lugar de reconstruir completamente.
La situación que enfrentan las empresas hoy
Las empresas que operan un sistema interno de más de diez años generalmente se encuentran en la misma situación. El sistema sigue funcionando. No hay interrupciones importantes. Simplemente, una pequeña solicitud tarda dos semanas, y solo una persona en la empresa puede manejarla.
Este estado es peligroso porque el problema empeora gradualmente. Un sistema que se detiene de repente recibe un presupuesto de inmediato. Pero un sistema que se vuelve un poco más lento y un poco más exigente cada año pasa con un veredicto anual de "también superamos este". Deja que se acumulen suficientes de esos años y tres cosas llegan a la vez.
Primero, la persona que entiende el sistema se jubila. Las reglas comerciales no documentadas se van con ellos. En segundo lugar, el soporte de seguridad para la tecnología subyacente termina. Una vez que un lenguaje o versión de base de datos queda fuera de soporte, no aparece ningún parche incluso cuando se encuentra una vulnerabilidad. Tercero, ya no se pueden adjuntar nuevos requisitos. Las solicitudes de soporte móvil, integración de servicios externos o análisis de datos son rechazadas con "el sistema actual no puede hacer eso".
Cuando las tres cosas llegan juntas, la única opción que queda es una reconstrucción completa. Y una reconstrucción completa es la opción más cara y más peligrosa disponible.
Cinco señales que justifican considerar un reemplazo
Si se aplican tres o más de los siguientes, es hora de comenzar a considerar un reemplazo.
1. El costo del cambio es asimétrico. Agregar un solo campo a una pantalla toma días. Si el tiempo de desarrollo para una solicitud que parece trivial para los usuarios no difiere mucho del de una importante, la estructura ya no puede absorber cambios.
2. El mantenimiento recae en una sola persona. Un sistema que solo una persona puede tocar convierte las vacaciones y la renuncia de esa persona en un riesgo empresarial. Este es un problema estructural, no un problema de personal.
3. El soporte para la tecnología subyacente ha terminado. Verifique las fechas oficiales de finalización de soporte para el tiempo de ejecución del lenguaje, el marco y la base de datos en uso. Si ya han pasado, un incidente de seguridad es solo cuestión de tiempo.
4. No se puede extraer datos. Si producir las cifras necesarias para una decisión de gestión requiere que alguien escriba consultas a mano, o que abra varias pantallas y las totalice manualmente, el sistema está reteniendo los datos.
5. Las soluciones alternativas están proliferando. Si el área que los usuarios comerciales gestionan en hojas de cálculo en lugar de en el sistema está ampliándose, el sistema no está reflejando las operaciones reales. Debido a que estos procesos paralelos no están registrados en ningún lado, el problema es invisible si solo se observa el sistema.
Calcule el costo de mantenerlo
Las discusiones sobre reemplazo suelen estancarse en la pregunta "sigue funcionando, así que ¿por qué gastar dinero?" Responder a eso requiere mostrar en cifras que mantener el sistema también incurre en costos. Sume los siguientes cuatro elementos.
| Elemento de costo | Método de cálculo |
|---|---|
| Costo de retraso | Solicitudes de cambio anuales × días promedio de espera × costo de oportunidad por día |
| Costo de soluciones alternativas | Horas de gestión duplicada en hojas de cálculo y similares × 12 meses × costo laboral por hora totalmente cargado |
| Costo de manejo de errores | Errores de datos anuales × horas para remediar por caso × costo laboral por hora totalmente cargado |
| Costo de riesgo | Número de componentes fuera de soporte × costo de recuperación esperado por incidente × probabilidad de ocurrencia |
Los primeros tres son costos que ya se están pagando pero que no se contabilizan. El cuarto aún no ha ocurrido, pero se acumula como una probabilidad.
El siguiente es un ejemplo hipotético destinado a ilustrar el método de cálculo; los valores reales variarán según las circunstancias de cada empresa. Con 30 solicitudes de cambio al año, un tiempo de espera promedio de 10 días por solicitud, y el costo de oportunidad de esa espera establecido en 150,000 KRW por día, el costo de retraso solo es de 45,000,000 KRW al año. Agregue dos departamentos que gastan cinco horas a la semana en gestión duplicada de hojas de cálculo y, con un costo laboral por hora totalmente cargado de 25,000 KRW, otros 13,000,000 KRW al año.
Si el total es de 58,000,000 KRW al año, en tres años son 170,000,000 KRW. Solo en este punto existe una cifra que se puede comparar con el costo de reemplazo. Mantener el sistema no es gratis; es un gasto por el cual no llega ninguna factura.
Por qué una reconstrucción completa es peligrosa
Una vez que se decide el reemplazo, el primer enfoque que viene a la mente es una reconstrucción completa: detener el sistema antiguo, construir el nuevo y cambiar todo de una vez en un día determinado. Es intuitivo, pero conlleva tres riesgos.
El beneficio es cero hasta que finalice el proyecto. En una reconstrucción de doce meses, la organización paga durante once meses y no siente ninguna mejora en absoluto. Si el entorno empresarial cambia durante ese período, el proyecto se ve presionado para ser cancelado.
Los requisitos se vuelven obsoletos a mitad de camino. Los requisitos establecidos en el inicio difieren de lo que el lado empresarial desea un año después. Si se refleja la diferencia, el cronograma se retrasa; si no se refleja, se completa un sistema obsoleto.
El riesgo se concentra en el corte. Debido a que todas las funciones cambian a la vez, no hay una forma fácil de retroceder si algo sale mal el día del cambio. Y casi siempre algo sale mal, porque el sistema existente invariablemente retiene reglas de excepción que nadie recuerda.
Migración incremental como alternativa
En lugar de un reemplazo total, hay un enfoque que deja el sistema existente en su lugar y mueve funciones una a la vez. La secuencia es la siguiente.
Etapa 1 — Delimitar los límites
Divida el sistema actual en bloques de funcionalidad. Separe según líneas operativas como pedidos, inventario, liquidación y personal, pero trace las líneas en función de quién posee los datos. Donde varios bloques escriben directamente en las mismas tablas, ese punto se convierte en el mayor obstáculo más adelante.
Al trazar límites, siga el flujo de datos en lugar del organigrama. Dos departamentos que modifican conjuntamente los mismos datos forman un solo bloque; por el contrario, un solo departamento puede dividirse donde sus datos son completamente separados.
Etapa 2 — Separar primero las lecturas
La tarea más segura es la funcionalidad de consulta. Las características que solo leen datos, como tableros, estadísticas e informes, se pueden construir en el nuevo sistema sin afectar al existente. Si fallan, las pantallas existentes permanecen en su lugar, por lo que retroceder es fácil, y los usuarios comerciales sienten la mejora de inmediato.
Hay un beneficio adicional en esta etapa. Construir la funcionalidad de consulta expone problemas en los datos existentes. Registros de clientes duplicados, fechas en formatos rotos y filas con valores de código vacíos se descubren aquí. Conocer estos problemas antes de mover la funcionalidad de escritura es muy importante.
Etapa 3 — Migrar la funcionalidad de escritura
Una vez que las consultas hayan validado el enfoque, mueva las funciones de entrada y edición. Dos sistemas manejarán los mismos datos durante un período, así que designe un lado como la fuente de verdad. Si ambos son editables, surgirán inconsistencias, y rastrearlas toma más tiempo que la migración misma.
Es más seguro secuenciar la migración comenzando con funciones de bajo uso y un radio de impacto reducido. Pero mover funciones que nadie usa no proporciona validación, así que una función que se utiliza genuinamente pero que podría soportar un día de inactividad es el mejor punto de partida.
Etapa 4 — Reducir el sistema existente
Elimine las funciones migradas del sistema existente. Si las deja, algunos usuarios de negocio continuarán utilizando las pantallas antiguas, y terminará manteniendo dos sistemas de forma permanente. Posponer esta etapa es la razón más común por la que la migración incremental falla.
Si la eliminación es difícil, al menos bloquee el acceso y cambie la función a solo lectura. Luego, fije una fecha para desactivarla por completo. Un plan de desmantelamiento sin una fecha no se ejecuta.
Qué enfoque tomar
| Situación | Enfoque adecuado |
|---|---|
| Las reglas de negocio están documentadas y el alcance es pequeño | Reconstrucción completa |
| Las reglas sobreviven solo en el código | Migración incremental |
| No se permite la interrupción del servicio | Migración incremental |
| El soporte para la tecnología subyacente ya ha terminado | Migre primero las áreas críticas para la seguridad |
| Los usuarios de negocio están trabajando alrededor del sistema en hojas de cálculo | Migre primero las áreas que se han eludido |
Una reconstrucción completa no siempre es incorrecta. Donde el alcance es pequeño, las reglas de negocio están documentadas y unas pocas horas de inactividad son aceptables, cambiar todo de una vez es más rápido y más barato. El criterio decisivo no es la antigüedad del sistema, sino dónde están registradas las reglas.
Qué causa realmente problemas en la migración de datos
Schedules slip because of data rather than feature development. Older systems accumulate conditions such as these.
- The same customer registered several times under different spellings
- Dates, telephone numbers and business registration numbers formatted differently by period
- Rows with mandatory fields left empty
- Data still referencing code values that no longer exist
- Rows merely flagged as deleted but in fact still present
Discover these problems during the migration stage and the schedule will certainly slip. Investigate in advance, before work begins, and decide first what will be cleaned up and what will be discarded. Attempt to clean all historical data perfectly and the migration itself will never finish. Cleaning only the last few years and retaining the rest as read-only archive is often the realistic course.
An opportunity to redesign security and access rights
Replacement is also a rare opportunity to put the security regime in order. Older systems generally have loose permission boundaries and are run with most staff able to see more data than they need. Settle the following items as part of the migration.
Minimisation of access rights. Separate visibility so that each role sees only the data it needs. Carry the existing system's permission structure across unchanged and the old problems come across with it.
Storage location and retention period for personal data. Document which personal data is stored where and when it is destroyed. Where the move is to the cloud, the country in which data is stored must also be confirmed.
Retention of processing records. Record who changed what and when. Older systems frequently lack these records, leaving no way to trace the cause when something goes wrong.
How to persuade the executive
Replacement budgets are rarely approved on technical arguments. Explanations such as "the architecture is outdated" or "technical support has ended" do not register as urgent with the person signing off. Recast them as the following three.
The money leaking now. The total of the delay, workaround and error costs calculated above. The essential point is that this is already being spent even without replacement.
What cannot be done. Compile a list of the requests turned down over the past year on the grounds that the current system cannot support them. Where any of them connect to revenue or customer attrition, put those first. Lost opportunity is a stronger argument than maintenance cost.
The worst case. Estimate the duration and cost of recovery if the sole maintainer resigns, or if an incident occurs in an out-of-support component. Low probability still moves a decision when the scale is large.
Having presented all three, request approval for the first stage of the incremental migration only. Ask for the entire budget at once and the review period lengthens, while the situation deteriorates further in the meantime.
Setting the schedule and the staffing
Schedule is what most often goes wrong in an incremental migration. Account for three things in advance.
Put the business side's time into the schedule. The scarcest resource in a migration project is not developers but business users who know the rules. They participate while carrying their day jobs, so unless the available hours are agreed in advance, the schedule slips at every validation step.
Include the parallel operation period in the calculation. Even after a function has been moved, both systems must run together for a time. Operational load actually increases during that period. Fail to reflect this in the schedule and budget and you will be short of people at the final stage.
Allow separate time for data clean-up. The data integrity problems discussed above can proceed in parallel with development, but they require their own time and their own owner. Bury them inside the development schedule and they will certainly slip.
What to check when working with an external supplier
It is often impractical to carry out a migration with internal staff alone. If you are considering an external supplier, confirm the following before signing.
Does the deliverable include documentation. Receive only code and the same problem recurs a few years later. Business rule specifications, data structure descriptions and operating procedures must all be included in the deliverables.
Is the handover arrangement defined for after the migration. Internal staff must be able to operate the system once the build is complete. Specify the handover period and the scope of training in the contract.
Can the contract be split by stage. Contract for the whole thing at once and it becomes difficult to change direction midway. A structure in which the first stage is performed and the remainder decided afterwards is safer for both parties.
Are the rights to our data clear. If real data is used during development, document what data moves where and how it is destroyed on completion.
What to prepare before starting
Whichever approach is taken, secure the following three things before work begins.
Documentation of the current business rules. Rules that exist only in code are invariably lost during migration. A perfect specification is not required, but exception handling and approval conditions must at least be written down.
A data integrity review. Survey the current state against the items set out above and decide the scope of the clean-up.
A rollback plan. For each stage, define how to reverse it if something goes wrong. A stage that cannot be reversed is by that fact too large a stage, and is a signal that it must be broken down further.
Summary
The cost of an ageing system appears in the form of delay and dependency rather than outages. That is why it is recognised late.
- Review the five signals: cost of change, concentration of expertise, end of technical support, data accessibility, and workarounds.
- Calculate the cost of keeping the system across four items — delay, workarounds, errors and risk — to produce a figure comparable with the cost of replacement.
- If the rules survive only in the code, a full rebuild is dangerous.
- Move query functionality first, and always remove migrated functions from the existing system.
- Investigate data integrity before work begins and fix the scope of clean-up in advance.
- Take the opportunity to redesign access rights and the personal data retention policy at the same time.
More important than whether to replace is not deferring the decision. If three of the five signals apply, beginning the review this year is cheaper than a full rebuild next year.