La deuda técnica también se administra

El lunes en la mañana suena familiar: ventas promete una fecha, operación dice “sí, pero…”, y TI responde con un clásico: “ese módulo es viejo, no lo toques”. Nadie está cómodo, pero todos siguen. Y mientras tanto, el sistema “que todavía aguanta” empieza a cobrar peaje: más retrabajo, más excepciones, más tiempo perdido explicando por qué algo simple se volvió un caso especial.

La trampa está en creer que todo se corrige de golpe. Con sistemas heredados, intentar “dejarlo perfecto” suele ser la forma más rápida de parar la operación… o de romper lo que sí funcionaba.

Lo que todos ven

• Pantallas lentas y procesos que “a veces fallan”.
• Reportes que no cuadran: el Excel dice una cosa, el ERP/CRM otra.
• Ajustes manuales: copiar-pegar datos entre sistemas, corregir folios, reintentar timbrados, volver a capturar pedidos.
• Dependencia de 1 o 2 personas que “sí se saben el caminito”.
• Proyectos que se atoran porque “hay que arreglar primero lo de atrás”.

Desde negocio se vive como frustración y costo: promesas que se vuelven riesgo, tiempos que se estiran y un servicio al cliente que se sostiene a base de heroísmo.

Lo que realmente está pasando

La deuda técnica no es “código feo”. Es trabajo pendiente acumulado que genera intereses operativos.

Esos intereses se notan en:

1. Tiempo

• Cada excepción suma minutos invisibles.
• Cada “parche” agrega pasos.
• Cada paso manual alarga el ciclo de venta/entrega.

2. Calidad

• Datos duplicados o incompletos.
• Reglas de negocio que se aplican “según el operador”.
• Errores que no se detectan hasta que ya pegaron en facturación, inventario o cobranza.

3. Riesgo

• Un bug “pequeño” se vuelve crítico cuando el volumen sube.
• Integraciones frágiles: una actualización externa rompe el flujo.
• Conocimiento tribal: si alguien falta, se apaga un proceso.

4. Costo real (el de operación, no el de TI)

• Horas de retrabajo.
• Notas de crédito.
• Penalizaciones.
• Ventas perdidas por prometer mal o por tardar en responder.

Por eso “arreglar todo” casi nunca es el plan. El plan es administrarlo: decidir qué se atiende ya, qué se reduce en el siguiente ciclo y qué se acepta temporalmente con controles.

Hacia dónde va esto

Las empresas que mejor van a convivir con legacy no serán las que “tiren y reemplacen” más rápido. Serán las que prioricen deuda técnica por impacto operativo.

En la práctica:

• Backlog de deuda técnica con dueño y fecha, no una lista de quejas.
• Priorización con criterios de negocio (impacto, riesgo, esfuerzo), no por quién grita más fuerte.
• Evolución por partes: encapsular, integrar, automatizar y medir antes de reescribir.
• Más inteligencia operativa: datos confiables para que automatización e IA no se basen en información rota.

Lo que viene (automatización, agentes, personalización, decisiones en tiempo real) exige una base mínima: procesos consistentes y datos con trazabilidad. La deuda técnica mal administrada no solo “molesta”: te cierra opciones.

Cómo lo resolvemos en Byte IT

No llegamos con una receta. Llegamos con método y con foco en operación.

1) Escuchamos
Hablamos con quien vive el dolor: ventas, operaciones, servicio, finanzas y TI. Pedimos ejemplos concretos: “¿cuándo falla?”, “¿qué pasa después?”, “¿cuánto tarda?”, “¿qué se hace manual?”.

2) Entendemos
Mapeamos el proceso real (no el ideal) e identificamos:

• puntos de captura de datos,
• validaciones,
• integraciones,
• excepciones,
• y dónde se pierde el control.

3) Detectamos el problema real
Muchas veces el “bug” es un síntoma. Detrás puede haber:

• reglas de negocio no documentadas,
• datos maestros inconsistentes,
• colas de integración sin monitoreo,
• o un módulo usado para algo que nunca se diseñó para eso.

4) Proponemos una solución con propósito
Convertimos “deuda técnica” en iniciativas priorizadas por Riesgo, Valor y Esfuerzo:

• Riesgo: probabilidad de falla × gravedad si falla.
• Valor: horas/costo recuperado, impacto en ventas, entrega, cobranza y facturación.
• Esfuerzo: complejidad, dependencias y ventanas de despliegue.

La prioridad se defiende con números, no con opiniones.

5) Construimos con la tecnología correcta
A veces es refactor. A veces es un “parche bien hecho”. A veces es integración. A veces es automatizar un paso manual con control y bitácora. No todo necesita reescritura.

6) Medimos
Antes y después:

• tiempo de ciclo,
• tasa de error,
• retrabajo,
• incidentes,
• impacto en operación (y dinero).

7) Ajustamos
Afinamos reglas, monitoreo, alertas y capacitación. La operación siempre te enseña algo que el diagrama no vio.

8) No soltamos hasta que funcione
Si no se sostiene en la operación diaria, no cuenta. La meta no es “entregar”; es estabilizar el proceso.

Caso práctico

Una empresa de distribución trae dos dolores al mismo tiempo:

• A) Un bug intermitente: 3% de los pedidos se quedan “atorados” al facturar cuando el cliente tiene una condición comercial específica. El equipo lo rescata manualmente: reintenta, corrige datos, genera la factura a mano.
• B) Una petición de dirección: “modernizar” el módulo de pedidos porque “se ve viejo”.

A primera vista, B se ve más “estratégico”. Pero al medir:

• Pedidos al mes: 8,000
• 3% atorados: 240 pedidos
• Tiempo promedio de rescate manual: 12 minutos
• Costo operativo estimado (carga completa): $250 MXN/hora

Cálculo rápido:

• 240 pedidos × 12 min = 2,880 min = 48 horas/mes
• 48 horas × $250 = $12,000 MXN/mes solo en tiempo

Y falta lo más caro:

• retrasos de entrega,
• llamadas de clientes,
• devoluciones por promesas incumplidas,
• riesgo de que el bug crezca con temporada alta.

Decisión administrada:

1. Se atiende primero el bug (A) con enfoque de estabilidad:
   • reproducibilidad (condiciones exactas),
   • validaciones previas,
   • bitácora del evento,
   • alerta cuando un pedido cae en cola.
2. Se pospone el rediseño visual (B) y se vuelve plan por etapas:
   • separar lógica de negocio de la interfaz,
   • estandarizar datos,
   • modernizar pantallas sin romper reglas.

Resultado esperado (medible):

• bajar la tasa de pedidos atorados de 3% a <0.5%,
• recuperar ~40 horas/mes,
• reducir escalaciones a soporte,
• estabilizar el cierre de mes.

Esto no es “elegir entre TI y negocio”. Es usar TI para quitar fricción real.

Lección de negocio

La deuda técnica no se elimina por voluntad. Se reduce con decisiones repetibles.

Si tu empresa depende de sistemas heredados que todavía importan, el objetivo no es “arreglar todo”, es:

• quitar primero lo que más cuesta cada semana,
• bajar riesgos antes de que se conviertan en incidentes,
• preparar datos y procesos para automatización e IA.

Administrar deuda técnica es disciplina operativa, igual que administrar inventario, cartera o tiempos de entrega.

Checklist final

Antes de abrir un proyecto “grande”, valida esto:

1. ¿Qué duele en operación hoy (con ejemplos)?

   • “Pedidos atorados”, “reportes inconsistentes”, “captura duplicada”, etc.

2. ¿Dónde está el costo? (tiempo, retrabajo, ventas, penalizaciones)

   • Estima horas/mes y puntos de fricción.

3. ¿Cuál es el riesgo si no hacemos nada por 90 días?

   • Caídas, incumplimiento, errores contables/fiscales, pérdida de trazabilidad.

4. ¿Qué iniciativa tiene mejor relación valor/esfuerzo?

   • Busca mejoras que se sostengan, no cosmética.

5. ¿Cómo lo vas a medir antes y después?

   • Tiempo de ciclo, tasa de error, tickets, reintentos, ajustes manuales.

6. ¿Qué puedes encapsular en lugar de reescribir?

   • Integraciones con monitoreo, servicios intermedios, validaciones, colas.

7. ¿Quién es dueño del proceso, no solo del sistema?

   • Si nadie es dueño, el problema regresa.

FAQ (5 preguntas)

1) ¿Deuda técnica es solo “código viejo”?
No. Es cualquier decisión o pendiente técnico que hoy obliga a operar con parches, pasos manuales, riesgos o datos de baja calidad.

2) ¿Cómo sé si debo pagar deuda técnica o seguir parchando?
Cuando el parche aumenta el retrabajo, sube el riesgo o vuelve impredecible cada cambio. Si cada ajuste rompe otra cosa, los intereses ya son altos.

3) ¿Qué priorizo primero si todo parece urgente?
Lo que combine: alto riesgo + alto impacto operativo + esfuerzo razonable. Si además pega en ventas, cobranza o facturación, normalmente va arriba.

4) ¿Se puede mejorar un legacy sin cambiarlo completo?
Sí. Muchas mejoras vienen de estabilizar integraciones, agregar monitoreo, estandarizar datos y automatizar validaciones. Modernizar por partes reduce riesgo.

5) ¿Qué métricas sirven para demostrar avance?
Tiempo de ciclo, porcentaje de excepciones, horas de retrabajo, tickets/incidentes, reintentos de integración, errores de facturación y tiempos de respuesta al cliente.

Administrar deuda técnica es decidir con claridad y con criterio. Si tu operación depende de un legacy, ponle números al dolor, conviértelo en plan y ejecútalo por etapas. Si quieres, lo trabajamos contigo: entendemos el proceso, priorizamos con datos, construimos, medimos y ajustamos hasta que se sostenga.