Tu software no envejece — tu negocio cambia. Y casi nadie lo planea
Hay un lamento que escucho casi cada mes en direcciones de PyME: “hace año y medio compramos este sistema y ya no nos sirve — se quedó viejo”. La frase suena razonable. El diagnóstico casi nunca lo es. El software no envejeció. El código que instalaron hace dieciocho meses sigue haciendo exactamente lo mismo que el día uno. Lo que cambió fue el negocio. Y el sistema no estaba preparado —ni presupuestado— para seguirle el ritmo.
El mito del “lo instalamos y listo”
Existe la creencia de que implementar tecnología es como comprar un escritorio: lo ponés, lo usás y te olvidás de él cinco años. Esa analogía es cara. El software empresarial se parece más a un jardín que a un mueble. Si tu empresa crece, lanza un producto, abre una plaza, cambia de proveedor o contrata gente nueva, la operación diaria se modifica. Si el sistema no se ajusta para reflejar esos cambios, empieza a generar fricción. Primero pequeña. Después intolerable.
Cuando el equipo nota que el sistema ya no describe cómo trabajan de verdad, hace lo más lógico: lo abandona y vuelve a Excel, a WhatsApp, a la libreta. No por rebelión. Por supervivencia. El “legacy” no nace el día que el fabricante deja de dar soporte. Nace el día en que la brecha entre cómo dice el sistema que trabajamos y cómo trabajamos se vuelve demasiado grande para cruzarla sin dolor.
Lo que le costó el abandono a una distribuidora en Torreón
Una distribuidora de materiales de construcción en Torreón —42 personas, ERP implementado a finales de 2023— dejó el sistema “andando solo” después del go-live. No hubo mala intención: el proyecto se cerró, el implementador se fue, y nadie heredó las 6 u 8 horas mensuales de ajuste. El dueño asumió que si funciona, no se toca.
En dieciséis meses la empresa sumó una línea de productos, cambió la política de crédito y abrió un segundo almacén. Ninguno de esos cambios entró al ERP con disciplina. Los vendedores armaban cotizaciones en hojas sueltas porque el catálogo del sistema iba atrasado. Crédito aprobaba a mano excepciones que el flujo digital no contemplaba. Almacén reconciliaba existencias dos veces: una en el sistema y otra en un Excel “de verdad”. Estimaron unas 45 horas mensuales de parches repartidas entre administración y ventas —cerca de $108,000 al año a costo cargado— antes de concluir que “el ERP ya no sirve” y pedir cotizaciones de reemplazo.
El error no fue comprar el ERP. Fue tratar la implementación como un evento y no como un ciclo. El software no se quedó viejo. La empresa creció y nadie actualizó el mapa.
La diferencia: mantenimiento técnico frente a mantenimiento de negocio
Acá está el matiz que casi nadie distingue. Reiniciar un servidor, aplicar un parche de seguridad o renovar un certificado es mantenimiento técnico. Necesario, pero insuficiente. Lo que evita que el sistema “envejezca” es el mantenimiento de negocio: revisar flujos cuando cambia una política, crear el reporte que la dirección ahora pide cada lunes, ajustar permisos cuando alguien cambia de rol, sacar del camino los workarounds que el equipo inventó el mes pasado.
Sin ese trabajo —típicamente 4 a 8 horas al mes, con dueño claro y backlog escrito— cualquier herramienta buena se convierte en legacy predecible. Con ese trabajo, el mismo sistema puede operar bien cinco años o más. La variable no es la marca del software. Es si alguien lo cuida como activo o lo abandona como gasto hundido.
Cómo evitar el ciclo “comprar → abandonar → volver a comprar”
No necesitás un departamento de TI de doce personas. Necesitás un hábito:
- Nombrá un dueño del sistema. No “TI en general”. Una persona con nombre que prioriza el backlog mensual —aunque sea tres horas a la semana.
- Separá bugs de evolución. Los errores se atienden ya. Los cambios de proceso entran a una lista priorizada: no todo lo urgente es importante.
- Reservá las horas antes de que el mes se llene. Si las dejás “para cuando haya tiempo”, nunca hay tiempo. Bloquealas en el calendario como si fueran una reunión con un cliente.
- Revisá la brecha cada trimestre. Preguntá al equipo operativo: ¿qué hacés hoy fuera del sistema que deberías hacer adentro? Esa lista es tu mapa de degradación.
- Medí uso real, no licencias pagadas. Diez asientos contratados y cuatro personas usando Excel en paralelo no es adopción: es deuda silenciosa con factura mensual.
El software no envejece. Lo que envejece es la decisión de no mantenerlo. Cada mes sin horas de ajuste acorta la vida útil del sistema que ya pagaste.
Probá el simulador: qué pasa a los 24 meses
El widget de abajo proyecta el estado de un sistema típico a los dos años según las horas mensuales de mantenimiento de negocio que le dediques. Mové el slider entre 0, 4, 8 y 16 horas. No son promesas de un fabricante: son un modelo honesto de degradación —uso real, workarounds, cobertura de procesos y la “edad percibida” que tu equipo le pone al software cuando ya no confía en él.
Línea de tiempo de salud del software
Mové el slider de horas de mantenimiento al mes y mirá qué le pasa a tu sistema a los 24 meses. Los números son un modelo ilustrativo — la dirección del deterioro es la que importa.
Tus respuestas no se guardan ni se envían — el cálculo es local en tu navegador.
Qué hacer con tu resultado
Si el simulador te dejó en Abandono o Reactivo, no lo leas como condena al software actual. Leelo como evidencia de que estás financiando el próximo reemplazo con cada mes sin mantenimiento. Antes de cotizar otro ERP o CRM, preguntate si 8 horas mensuales sobre lo que ya tenés costarían menos —en dinero y en disrupción— que otro proyecto de implementación. Si quedaste en Saludable, protegê ese hábito: es más fácil perderlo que recuperarlo. Y si estás en Evolutivo con 16 horas, confirmá que esas horas producen ventaja de negocio y no solo actividad de TI.
Es el mismo criterio que usamos al revisar el costo total de “lo gratis”: lo barato no es la licencia, es el costo de propiedad a tres años. Un sistema abandonado sale caro aunque la factura mensual se vea “aceptable”.
Checklist antes de declarar que “ya no sirve”
Antes de abrir un RFP de reemplazo, respondé con honestidad:
- ¿Cuántas horas al mes le dedicamos de verdad a ajustar el sistema a cómo operamos hoy? Si la respuesta es cero o “cuando se rompe”, el diagnóstico ya está.
- ¿Hay un dueño nombrado del backlog, o “lo ve TI cuando puede”? Sin dueño, no hay mejora continua.
- ¿Qué procesos vivos viven hoy fuera del sistema? Cada uno es una cicatriz de abandono, no una falla del fabricante.
- ¿Medimos uso real (logins, transacciones, reportes abiertos) o solo licencias pagadas?
- Si mañana metiéramos 8 horas mensuales durante un trimestre, ¿el sistema recuperaría terreno —o está genuinamente fuera de capacidad?
Si las primeras cuatro respuestas duelen, no necesitás software nuevo. Necesitás cuidar el que ya tenés. El reemplazo prematuro es la forma más cara de evitar una conversación de mantenimiento.